|FROM ||Ruben Safir
|SUBJECT ||Re: [NYLXS - HANGOUT] [email@example.com: [suse-security-announce] SUSE Security Announcement: samba remote denial of service (SUSE-SA:2007:016)]
|From owner-hangout-at-mrbrklyn.com Sun Feb 18 02:13:19 2007
Received: from www2.mrbrklyn.com (localhost [127.0.0.1])
by www2.mrbrklyn.com (8.13.1/8.13.1/SuSE Linux 0.7) with ESMTP id l1I7DHDc027165
for ; Sun, 18 Feb 2007 02:13:19 -0500
Received: (from majordomo-at-localhost)
by www2.mrbrklyn.com (8.13.1/8.13.1/Submit) id l1I7DHGd027164
for hangout-outgoings; Sun, 18 Feb 2007 02:13:17 -0500
X-Authentication-Warning: www2.mrbrklyn.com: majordomo set sender to owner-hangout-at-nylxs.com using -f
Received: from www2.mrbrklyn.com (localhost [127.0.0.1])
by www2.mrbrklyn.com (8.13.1/8.13.1/SuSE Linux 0.7) with ESMTP id l1I7DD7F027159;
Sun, 18 Feb 2007 02:13:15 -0500
Received: (from ruben-at-localhost)
by www2.mrbrklyn.com (8.13.1/8.13.1/Submit) id l1I7DChE027158;
Sun, 18 Feb 2007 02:13:12 -0500
Date: Sun, 18 Feb 2007 02:13:12 -0500
From: Ruben Safir
To: David Sugar
Cc: Ruben Safir , hangout-at-mrbrklyn.com
Subject: Re: [NYLXS - HANGOUT] [meissner-at-suse.de: [suse-security-announce] SUSE Security Announcement: samba remote denial of service (SUSE-SA:2007:016)]
References: <20070216004157.GD3586-at-www2.mrbrklyn.com> <20070217135900.GB9180-at-fencepost.gnu.org> <20070217151528.GA21644-at-www2.mrbrklyn.com> <20070217231236.GA22186-at-fencepost.gnu.org>
Content-Type: text/plain; charset=us-ascii
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
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:
>> 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
> 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...
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."