Hi Oliver,
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.
I doubt that, from my own experiences.
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.
I know of the problems, and I think your strategy, as also used with the openssh issue, is the right one.
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.
No, I mean a link and a note at http://www.suse.de/de/support/download/updates/70_i386.html As you see, there are said modules listed at 28.April 2001, but not apache itself. Before I upgraded, I grepped this page for other occurrencies of the word "apache" and found nothing else. So I concluded that apache hasn't been updated before.
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.
Maybe the other people had done the previous update, I didn't, and at least two people on the mailing list didn't also and had seemingly the same problem.
Important: we assume that people have installed the previous security updates of apache. I hope that this is a fair assumption?
Not quite, as you see now. I don't know what the issue was on April, 28th 2001, and I don't find a security anouncement from SuSE concerning apache from that time. But I'm quite sure that _if_ it had been an issue for my servers, I had upgraded apache - but I hadn't. Look at the last openssh issue, I think it's reasonable _not_ to assume that everyone will update openssh - it's just not an issue for people with most configurations. If, in the future, SuSE updates any package which needs the new openssh (not very likely, I know) on 7.0, the same thing could happen again.
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?
After I updated mod_contrib and mod_perl, the servers ran alright - before that, segfaults on every request. But the server started up ok. Another data point: even using the src.rpm didn't help. Ok, one thing, I had mod_gzip compiled for apache 1.3.12. But I had tried to get a working apache without that - it didn't work. To elaborate, I commented out everything in httpd.conf which is related to mod_gzip. It didn't work, but after updating the two modules, itd did, in the exact same configuration.
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's absolutely no question for me that staying with the same version number and backporting security patches is the right thing to do under almost any circumstances. Esp. with apache, where there may be custom modules which depend on that very version.
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.
This is correct, but if it's true that one needs to have other, older updates to get a working server, it would be a great help to describe that in the advisory. What happend was: stock 7.0 -> apache+mod_ssl update from 18.Jun 2002 -> crash what I had to do was: stock 7.0 -> mod_contrib+mod_perl from 28.April 2001 + apache+mod_ssl from 18.Jun -> works IOW, the update from 18.Jun was dependend on the update from 28.April 2001, and that was neither mentioned in the advisory nor reflected in the rpm-dependencies.
Mind you, I'm not complaining, just trying to give a hint where these problems might come from.
We are greatful for such help!
And you are doing a great job, esp. with the last two big "incidents". cheers, oliver