Hi Oliver, On Tue, Jul 02, 2002 at 07:39:10PM +0200, Oliver Bleutgen wrote:
On Mon, Jul 01, 2002 at 10:12:21PM -0000, matthew zonderop wrote:
my apache broke after the patch...had to reinstall the perl modules and uninstall the SSL module which i dont use anyway. but only took 5 mins..rcapache restart no problem...
If you tell us what exactly broke we might be able to work out if anything was wrong and what!
Peter
Peter,
the problem with the apache upgrade seems to be that the stock apache from SuSE 7.0 was 1.3.12 (IIRC, it was definately <1.3.19).
Yes, that's right.
Then, on 28.April 2001, SuSe seems to have issued a apache 1.3.19 for suse linux 7.0, at least that is what I figure out from the fact that
Yes.
http://www.suse.de/de/support/download/updates/70_i386.html
contains links to mod_contrib.rpm, mod_perl.rpm and other modules for apache 1.3.19.
Strictly speaking those module updates should not have been necessary. The module API has not changed since back 1.3.12 days. However, there are some other package interdependencies as well -- (if you ever typed ldd /usr/lib/apache/libphp4.so you know what I mean...) so if for example openldap has been updated meanwhile as well and the API used by php has actually changed, you might end up updating a rebuilt php package as well. I.e. a package like mod_php might have to rebuilt quite often. Now the problem is not, for us, to track down these build dependencies, but to cut them down by translating them into a set of packages that need rebuilding/updating (on your system!) or not. It's very complex, unfortunately.
Irritatingly, there's no link to an apache 1.3.19 upgrade from that time, maybe you people deleted that when the new apache came out.
Do you mean the symbolic link named apache.rpm? It always points to the current rpm for convenience, so it has been changed since then.
Now came the new upgrade, and only mod_ssl and apache itself were published. People like me upgraded, got no rpm dependency problems (yes, without using --nodeps), but apache segfaulted on every request.
As the same procedure has worked for many people, I assume that there is something in your setup. A special set of modules or something else. Important: we assume that people have installed the previous security updates of apache. I hope that this is a fair assumption?
It took me some time to figure out that my apache modules were the culprits, because I _had_ checked for a previous apache upgrade which I might have omitted for some reason - and, as I said, rpm didn't complain.
You had the modules from stock 7.0 installed (hope I got you right)? They should actually work with the current apache, with the exception of mod_ssl. Do you know which specific module failed? Sometimes, when we can't avoid to make version updates of packages (and apache 1.3.12->1.3.19 is such a candidate) it can't be guaranteed that the build procedure can actually be the same. Two examples: 1) Newer apache versions (>1.3.22 or so) use an external (system installed) expat library in favor of the internal one, to avoid library symbol name clashes when a module (say, mod_perl) loads the external expat lib into the same namespace. 2) With apache 1.3.23 or so and later the accept serialization method has been made runtime configurable. The configuration style has changed. Simply and boldly offering apache 1.3.26 updates for all distributions would be prone to break a lot of things because of changes like that. It would be hard to get it right again, so everything works still as expected, the configuration files are still valid, and so on.
It would have been helpful if the advisory contained a hint about updating the apache modules, because the described update strategy _must_ fail on a stock 7.0.
As I understand it, we would need a special hint for users that have never installed one of the previous apache updates before. Wrt the texts of the module update packages, they say "update package for apache 1.3.19". Which is what they ought to say.
Mind you, I'm not complaining, just trying to give a hint where these problems might come from.
We are greatful for such help! Thanks, Peter -- VFS: Busy inodes after unmount. Self-destruct in 5 seconds. Have a nice day...