RE: Any known good configuration for mod_perl DSO?
In response to my question, Ged Haywood pointed me at a message from Chip Turner, reproduced here in part: When it comes to perl and mod_perl, we've been working to try to make sure it works reliably from RPMs. RH 7.3 should work well out of the box, as should 7.2, once all errata applied. The rest of this thread points out a few issues, though, but I think that tends to be issues with other perl modules that have shared library components. If you (or anyone else!) have specific failures or test cases you've seen, though, I'll look into it and see if it is something we can fix. That should is a big big word, as I came across Mr Turner's message in a search of the list archives -- I'm currently working with a RedHat 7.2 box with all errata applied. All Perl-related RPMs were supplied by RedHat. And I get silent failure in the form of segmentation faults. So that's why I asked my original question. Can I expect that if we upgrade our web servers to RedHat 7.3, we'll be rid of the segfault problem? Or am I looking at rolling my own RPMs or installing from source RPMs? My suspicion, confirmed by Mr Turner, is that this is tied directly to shared libraries and toolchains, and so I suspect further that the problem will go away if I build everything from scratch using source RPMs. In the meanwhile, thanks to the people who have offered tips on building from source RPMs. Right now, it looks like this is the way we're going to go. And finally, thank you to the people who recommended (many in private messages) ditching RPMs altogether and installing from source, but unfortunately that's not an option, as I thought I had made clear in my initial post. One of the reasons we're using RPMs to handle configuration management is that we have several redundant servers in production and several servers for development use, and it's important that the configuration on each server be identical. It's also important that, if we add a new server to either group, we can produce an identical configuration to the development and production clusters. Charlton
Re: Any known good configuration for mod_perl DSO?
Wilbur, Charlton wrote: Or am I looking at rolling my own RPMs or installing from source RPMs? My suspicion, confirmed by Mr Turner, is that this is tied directly to shared libraries and toolchains, and so I suspect further that the problem will go away if I build everything from scratch using source RPMs. I highly recommend building your own RPMs. It works great, you get exactly what you want (and nothing you don't want), and you can install them quickly on a cluster of machines because you don't have to recompile on each one. - Perrin
Re: Any known good configuration for mod_perl DSO?
We built our own RPM that did source level builds on our entire system. So you load the rpm and it in turn executes a build script that built our entire system. Not just apache, modperl and mason but also it rebuilt all the modules that were needed, compiled external binaries, installed the Oracle libs and drivers and auto configured all configuration files based on the host it was on and a host-configuration mapping. Seemed to work well. John- On Mon, 24 Jun 2002 17:07:52 -0400 Wilbur, Charlton [EMAIL PROTECTED] wrote: Hello collective wisdom, I have the task of making Apache, mod_perl, and HTML::Mason work together under RedHat. I know this is a problem; the most frequently recommended solution that I've found is to build everything from scratch and link it all together, without using DSOs. However, my constraints are that all configuration management must be handled using RPMs, because we have a multitude of web servers that must all be maintained in parallel. My order of preference is for using downloadable binary RPMs, followed by using SRPMs and building from scratch, and finally followed by rolling my own RPMs. So I have a couple of questions that I'm currently researching, and if anybody here knows the answers, I'd be grateful to hear them: First, is there a known good binary RPM configuration, a combination of mod_perl and apache RPMs, from RedHat or another vendor that doesn't suffer from the silent-segfault problem? Second, is it possible that building from source RPMs would prevent the problem? Occasionally I've seen problems like this arise due to differing versions of the toolchain, and building from source RPMs would ensure that the same toolchain was used to build all of the components. If I find answers to these questions elsewhere before I receive answers from this list, I'll follow up to myself and share the wisdom. Thanks, Charlton -- Charlton Wilbur [EMAIL PROTECTED]
Re: Any known good configuration for mod_perl DSO?
Hi there,
On Mon, 24 Jun 2002, Wilbur, Charlton wrote:
I have the task of making Apache, mod_perl, and HTML::Mason work together
under RedHat. I know this is a problem;
Not necessarily; look at this thread for example...
73,
Ged.
--
From [EMAIL PROTECTED] Tue Jun 25 00:08:24 2002
Date: 22 Jun 2002 23:23:01 -0400
From: Chip Turner [EMAIL PROTECTED]
To: Zac Morris [EMAIL PROTECTED]
Cc: Jeremy Weatherford [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: Re: Fascinating segfault at Apache startup
Zac Morris [EMAIL PROTECTED] writes:
Honestly though Chip I have to pipe up here.
I was a gung ho RedHat supporter when I first got involved in the
linux world, and I still believe with it's RPMs and GUI tools it's
still the best for both new users and corporate environments, but
man, if you wanna do something that not the EXACT OS version-RPM
based software version, (hmmm, like DEVELOPMENT) you are SERIOUSLY
screwed with RPM more times than not.
It depends. Usually it isn't RPM that is the problem, it's the
-other- software you've installed with RPM. Dependencies tend to be
an all-or-nothing affair, though, which makes the situation more
complicated.
So I have spent the last FIVE full days about 10 hours a day setting
up redhat 7.3 (sans as many of the RPMs as I could possible get away
with). Now granted perl 5.6.1 was one of the RPMs I *did* install,
as was sendmail (since Redhat has REALLY whacked that one up with
the assumed workstation mode, but I at least know how to FIX
that), but my apache, mod_perl, java, tomcat, etc I built entirely
from source utilizing my /opt/{appname} everything all together
strategy.
I now have a pretty swank lil server setup here. I just
successfully tested my perl/DBD::Pg connections and i'll confirm
jdbc to Pg tomorrow and I'll be set for some major develpment
efforts.
I'm not familiar with tomcat, so I can't really comment on it
specifically. But, before I came to Red Hat, I was a compile from
source guy, even on production servers. Lots of reasons, but one was
that I didn't know RPM. It seemed like a hassle to deal with it for
little things, etc... so I didn't.
My personal suggestion would be to try to work with the default OS
instead of against it. Sometimes this is impossible, but sometimes it
isn't so bad. For instance, instead of compiling straight from
source, you could take our RPMs, modify them (such as making apache
live in /opt), maybe throw in a more recent version, and see how it
works. Likewise, building tomcat, java, etc, as RPMs may save you
time later when you need to rebuild a box, or clone the system, or
should disaster strike. Recompiling, checking dependencies by hand,
etc, really is time consuming. But, of course, so is learning RPM :)
It definitely is a difficult road. Having travelled it myself,
though, I find it to be tremendously better than how I used to do
things. It depends on your own personal preferences, though, as well
as company policies, your peers' skillsets, etc. No one answer fits
everything, but I really do think that package management of some kind
(RPMs, debian, etc) offers many superiorities over recompiling from
source. YMMV :) There's no one single answer (too much context), but
in general, whatever OS you use, it usually is easier to work with it
and the tools it provides than against it.
When it comes to perl and mod_perl, we've been working to try to make
sure it works reliably from RPMs. RH 7.3 should work well out of the
box, as should 7.2, once all errata applied. The rest of this thread
points out a few issues, though, but I think that tends to be issues
with other perl modules that have shared library components. If you
(or anyone else!) have specific failures or test cases you've seen,
though, I'll look into it and see if it is something we can fix.
Cheers,
Chip
--
Chip Turner [EMAIL PROTECTED]
Red Hat, Inc.
