MESSAGE
| DATE | 2007-02-21 |
| FROM | Ruben Safir
|
| SUBJECT | Re: [NYLXS - HANGOUT] [meissner@suse.de: [suse-security-announce] SUSE Security Announcement: samba remote denial of service (SUSE-SA:2007:016)]
|
Your Phone is out, please call me ASAP and/or EMAIL me.
Ruben
On Sun, Feb 18, 2007 at 07:04:43PM -0500, David Sugar wrote:
> Debian still uses an "installation" database of "installed" packages,
> just like rpm does for rpm packages, freebsd does, etc. This is not a
> question of how the metadata eventually arrives and is stored on your
> system and maintained, but rather how packaging metadata is used to
> construct the installation package from source.
>
> In fact, for most cases I thing it matters little in the end. For
> example, most people will not choose to build grep from source if they
> do not need to, and there are not many compile time options to consider
> :). However, for what is often the most important packages (such as the
> Linux Kernel, or apache or Samba, for example), all packaging often
> fails, because each of these have needs for far greater customization
> and often different options than that which can be offered in the
> "generic" distribution. Here is where it becomes important for uses,
> whether building from source, or simply re-building a package for their
> own needs and specific options that they can then distribute to multiple
> machines, on whether or how badly packaging interferes with this
> process.
>
> What is good in BSD ports and packaging is that they support both models
> seamlessly. You can take a package that is pre-built (say grep), and
> install and maintain it along side a package that is "compiled" with
> your own options and installed through the master make files found in
> /usr/ports. At the same time, you could of course also work with a
> package that has it's own make and build tools instead.
>
> RPM based distro's could be made to work much like BSD does with
> packages and ports, although to date nobody distributes a binary RPM
> installed distribution that also includes the native "spec" files in an
> equivilent of a /usr/ports directory to allow one to quickly modify and
> rebuild a custom RPM package. Instead they often distribute SRPM's on
> additional CD's rather than naked specs ready for use, which is really
> what you do not want. However, in Debian, since you must start from
> "Debianized" sources which contain packaging build instruction rather
> than external metadata, it would be much harder to do the same there.
>
> The key question I think for whether a packaging system and distro is
> good or bad is in how readily it empower users, which is the key part
> and purpose of what you say in the apache build tools. And a key part of
> the education of users in living in the free world is for them to learn
> and understand how they are empowered and are able to compile and modify
> packages themselves rather than what they have been spoon-fed in
> prepackaged software by any given distribution, regardless of the
> packaging system used.
>
> Ruben Safir wrote:
>
> > On Sat, Feb 17, 2007 at 06:12:36PM -0500, David Sugar wrote:
> > > I find specific and different issues in Debian. Unlike every other
> > > packaging system out there (including BSD ports, gentoo, etc), they
> > > choose to stick the packaging meta-data within the distribution package
> > > (debianized source with a "debian" subdir in a modified source
> > > distribution) rather than keep it seperate. This is a fundimental
> > > design flaw.
> > >
> > > My other problem with Debian packaging is it remains overly complex.
> > > While the original RPM faq explained within half a page how to create a
> > > RPM that produces two or more output packages (something very common if
> > > you are building a library which might include a seperate -devel package
> > > with headers), the Debian maintainers document still says it is simply
> > > too complicated to explain how to do this basic task or to explain
> > > anything beyond the very simple example they do give and believe is
> > > explainable which is valueless to any real packaging situation! This
> > > alone speaks volumes to me about what is wrong in Debian packaging as an
> > > architecture; if it is too complex to even explain something basic,
> > > clearly it is designed wrong to begin with...
> > >
> >
> > Being that I'm not producing any products for distribution like you do I've
> > never dug very far into this. But if the debian packaging system is too complex
> > to make it easy to role out then that would go a long way to explaining why
> > so many fundementally broken debian packages exist and take forever to be
> > fixed. In terms of where to put the metadata, one advantage I would think
> > to a distributed mode would be that you wouldn't have a single point of
> > corruption, such as an RPM database often has.
> >
> > Apache's compiling tools are somewhat unique. Like BSD ports, it uses
> > compilation tools not only for compiling but also distribution AND are
> > designed to give Apache operators real access to the code base to encourage
> > module buidling, module fixing, and experimentation.
> >
> > Check this post from Tim Gales:
> >
> > "You are saying "Furthermore, Apache is designed to be
> > expanded by modules making professional use of Apache OUTSIDE of any
> > package management an essestial aspect of running the server."
> >
> > There is no design goal on the part of Apache developers
> > like that.
> >
> > To paraphrase the developer's quote: The top design goal for
> > the Apache server was to build a solid and dependable server
> > (and we can infer that to mean one that would not need to be
> > recompiled a lot for maintenance by either the users or
> > their distributor/third party developers.)
> >
> > Notwithstanding the fact thatApache developers have good
> > tools with which to build Apache, the developers clearly
> > wanted users to *not* have to recompile from source to
> > get diverse functionality."
> >
> >
> > Did you ever read such crap? This guy is a flat-earther. He's plucking
> > a few lines off the website to make the enourmous leap in logic to conclude
> > that to argue that Apache developers designed the server to be understood
> > within the logical construct of apt-get and for users to be dependent on third
> > party modules rather than to be active development partners in making useful
> > modules and core fixes in the core module base.
> >
> > In otherwords, this guinius has concluded that all the developement to break
> > Apache from a singular binary construct to a completely modularized tool
> > kit with the smoothest compiling and configuration tools of any project in
> > existense is not to facilitate the coders abilty to debug code more efficiently
> > through modulation and to facilitate creative expansive through a its well
> > documented modular interface and API, but it was all so that some 3rd party
> > like Microsoft or Debian can ramjet binary modules at you more smoothly.
> >
> > So of course, once this guinius makes this conclusion, its perfectly
> > understandably why it is acceptable to recieve through a tech list calls for
> > help which look like this:
> >
> > -------------------------------------------------------------------------
> >
> > Sorry to revive an old thread, but just as kind folks
> > were helping out, we had a loss in the family and I
> > dropped off the face of Nylug for a couple months.
> >
> >
> > > On Wed, Nov 01, 2006 at 10:52:28AM -0500, Seth Rothenberg wrote:
> > >> Greetings,
> > >> I have a server running apache 1.3 and using
> > >> VirtualDocumentRoot and PHP....and I want to
> > >> do the same in Apache2.
> >
> > The debian mass hosting how-to is for apache 1.3
> > I found another how-to for apache2, but either
> > there's a step missing, or a step wasn't followed
> > (by the silly guy at the keyboard).
> >
> >
> > > Hi Seth,
> > > what packages are installed wrt apache2 and php?
> > > COLUMNS=200 dpkg -l |egrep "(apache)|(php)"|grep "ii"
> >
> > The good news is,
> > I did a clean install, on a new server, and I at least got php
> > working on the default domain. But still can't get virtual domains.
> >
> > cut -c-80 cmdout
> > rothen at kx:~$ COLUMNS=200 dpkg -l |egrep "(apache)|(php)"|grep "ii"
> > apache-utils 1.3.33-6sarge3 utility programs for webservers (transitiona
> > apache2 2.2.3-3.2 Next generation, scalable, extendable web se
> > apache2-doc 2.2.3-3.2 documentation for apache2
> > apache2-mpm-prefork 2.2.3-3.2 Traditional model for Apache HTTPD 2.1
> > apache2-utils 2.2.3-3.2 utility programs for webservers
> > apache2.2-common 2.2.3-3.2 Next generation, scalable, extendable web se
> > libapache2-mod-php4 4.4.4-8 server-side, HTML-embedded scripting languag
> > php4-common 4.4.4-8 Common files for packages built from the php
> >
> > (Note, One person said "apt-get install apache2 libapache-mod-php4"
> > but that doesn't seem to be everything I need to know :-)
> >
> > rothen at kx:/etc/apache2$ diff apache2.conf apache2.conf_original
> >
> > < LoadModule php4_module /usr/lib/apache2/modules/libphp4.so
> > <
> > <
> > < AddType application/x-httpd-php .php .phtml .php3
> > < AddType application/x-httpd-php-source .phps
> > <
> >
> > The error message I get is this...
> > NameVirtualHost *:0 has no VirtualHosts
> >
> > (and google gives me a nice run-around on that:-)
> > (and of course, there are domains defined in
> > sites-enabled and sites-available)
> >
> >
> > I'd appreciate any pointers.
> > BTW, it is my guess that a proper mass-hosting install
> > has very little proprietary/security info in it,
> > if diagnosis requires a look at the actual config,
> > I can do that.
> >
> >
> > BTW, isn't this something that everyone and their brother
> > wants to do? It is STILL a pleasure adding domains
> > to my apache 1.3 server. It's just time to move up.
> > (remember that post about sharing costs with a friend?
> > he really wants Apache2, and I really want mass hosting :-)
> >
> > ------------------------------------------------------
> >
> > And thats the kicker. He really thinks that running Apache with PHP and
> > Virtual Hosts is ***hard***. My god. What was hard was understanding his
> > damn question.
> >
> >
> > > This is not to say RPM is a panecia either, and I agree the practical
> > > and imperical experiances demonstrate there is a lot yet to be improved,
> > > but at least it is easy enough for anyone to produce an RPM (or even an
> > > ebuild, or a BSD port) , and because the packaging metadata is seperate,
> > > it does not produce problems when either an upstream maintainer chooses
> > > to offer their own packaging (in debian, maybe you would re-patch the
> > > authors /debian directory? yuck) or to maintain their own varient of
> > > specific packages from that of a distribution without having to produce
> > > their own varient of impure source distributions...
> > >
> >
> >
> > Ruben
> >
> > --
> > http://www.mrbrklyn.com - Interesting Stuff
> > http://www.nylxs.com - Leadership Development in Free Software
> >
> > So many immigrant groups have swept through our town that Brooklyn, like Atlantis, reaches mythological proportions in the mind of the world - RI Safir 1998
> >
> > http://fairuse.nylxs.com DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002
> >
> > "Yeah - I write Free Software...so SUE ME"
> >
> > "The tremendous problem we face is that we are becoming sharecroppers to our own cultural heritage -- we need the ability to participate in our own society."
> >
> > "> I'm an engineer. I choose the best tool for the job, politics be damned.<
> > You must be a stupid engineer then, because politcs and technology have been attacted at the hip since the 1st dynasty in Ancient Egypt. I guess you missed that one."
--
http://www.mrbrklyn.com - Interesting Stuff
http://www.nylxs.com - Leadership Development in Free Software
So many immigrant groups have swept through our town that Brooklyn, like Atlantis, reaches mythological proportions in the mind of the world - RI Safir 1998
http://fairuse.nylxs.com DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002
"Yeah - I write Free Software...so SUE ME"
"The tremendous problem we face is that we are becoming sharecroppers to our own cultural heritage -- we need the ability to participate in our own society."
"> I'm an engineer. I choose the best tool for the job, politics be damned.<
You must be a stupid engineer then, because politcs and technology have been attacted at the hip since the 1st dynasty in Ancient Egypt. I guess you missed that one."
|
|
