[SPAM] Re: [mod_python] Point of frustration/disappointment

On Fri, 2005-07-29 at 09:51 -0500, Gustavo Córdova Avila wrote:
> Jim Popovitch wrote:
> >In order to make mod_python work partway, I had to install
> >python2-devel-2.2.2 on a production server (you should never 
> >have to install -devel packages on a production system)
> >
> Then take that up with redhat people, not with us, why are you whining 
> about redhat policies to us?  Making you install a "-devel" package, 
> which contains link libraries and include files for any software you 
> want to compile/link against is just plain stupid.

-devel/-dev packages aren't unique to Redhat, my Debian systems have
them too.  So does Solaris, HP-UX and AS400 systems, iirc.

> Debian nor Slackware, both of which I've used, don't have this 
> limitation: you install "python", and it contains all you need for 
> runtime, and all you need to compile against.

That is not true.  In order to compile and install mod_python you need
Apache's axps which is in a -devel on Redhat and -dev on Debian. 

> And "you should never have to install -devel packages on a production 
> server" is absolutely no reason at all.  

Agreed, although some would differ (see your next comment).

> There's absolutely nothing in a -devel package which will make a 
> production server unstable.  

..opps, I can't agree with you here.  -dev/-devel packages contain a LOT
of un-vetted scripts and code that could potentially be exploited.  Look
no further than Microsoft to see tons of examples of this.

> And if 
> you're worried about someone getting inside the server and then "having 
> the tools to build something", well, that's just dumb, by the time the 
> cracker's inside the machine it's already way too late.

You are out in left field a bit on this.  The additional un-tested
(rarely tested?) components present alternative avenues to gain info.
Remember printenv?  Root'ing a box is not the only way to compromise
data.

> >This system also has python-1.5.2 installed on it, which is
> >/usr/bin/python, due to rpm-python and yum requirements. So,
> >replacing /usr/bin/python breaks other things, including
> >production server policies.
> >
> So don't replace it.
> 
> "mod_python" doesn't load "/usr/bin/python", so you don't need that file 
> while running.  Rename it to something else, symlink your "python2" to 
> "/usr/bin/python", build mod_python, restore /usr/bin/python.  Seems 
> simple enough.
> 
> >Finally, in order to even get mod_python to work, I had to
> >edit src/Makefile (added -DEAPI)
> >
> Modifying a Makefile wasn't categorized as "cruel and unusual" in 
> development circles, last time I checked...
> 
> >It just seems plain messy to me, especially in a production
> >environment.  It's ok to have to do this in a development
> >only environment.
> >
> There you have it, do it in a development environment and copy to your 
> production environment.

You are missing my points.  If it is a messy development effort it
become messy to maintain over time, which leads to messy production
systems.  Editing a Makefile, tweaking a script, installing a -devel pkg
are not problems, they are just *more* things to track and carry over
for the next mod_python (in this case) release 6mos, 12mos, 2yrs, etc.

-Jim P.