jimpop at yahoo.com
Fri Jul 29 11:19:06 EDT 2005
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.