Re: [suse-security] Apache upgrade from SuSE ?
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). 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 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. 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. 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. 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. 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. Mind you, I'm not complaining, just trying to give a hint where these problems might come from. cheers, oliver
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...
* Peter Poeml wrote on Tue, Jul 02, 2002 at 21:38 +0200:
On Tue, Jul 02, 2002 at 07:39:10PM +0200, Oliver Bleutgen wrote:
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 though, RPM processes such dependencies automatically.
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...)
php is linked only against /lib/lib*so :)
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.
I don't see the problem. When building upgrade packages, you use a compiler system which is excactly cd-inst plus patches. So the configure of mod_php cannot find a new openssl or ldap or whatever, since it's not installed. Well, bad example, mod_php fails anyway :). Of course especially in this example it could be possible that there is no "safe" mod_php version (well, actually I think that is true always :)) that builds with such old libs. I think the configure of mod_php is not smart with such issues. But in normal cases it should work. But of course you cannot build multiple things on the same filesystem, since it may happen that other things are installed (not part of the RPMs), theoretically. Theoretically an RPM build manager uses disk images that are restored after each package build.
It's very complex, unfortunately.
Yes, definitly it is.
Important: we assume that people have installed the previous security updates of apache. I hope that this is a fair assumption?
I think so. But I'm sure that not all servers are patched :). Isn't it possible to define the previous security update as RPM package dependency? If you say it depends on that, don't say it here, but tell it RPM :) Of course the FTP admin must make sure that the old version of the patch is still avialable, and I guess some people would be confused about it. Did we mentioned that it's very complex :)?
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?
I could imagine that not apache's dynalink failed, but the linkage of a module to a "system" lib due to changed entries or such. Well, but I though that there is a symbol table in the libs :) hum.
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.
I would suggest to rebuild the source RPM, but with apache, this is very complex (did we mentioned that complexity already?).
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.
Yes, and that's why software vendors/developer should provide backported patches. If this is not possible, problems will occure. I know that from php for instance, where you have to upgrade php on each bug, and often you have to upgrade a million libs, hack the configure m4 to make it compile...
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.
I would like correct RPM dependencies (yes, I know it's difficult and... well... complex? :)) oki, Steffen -- Dieses Schreiben wurde maschinell erstellt, es trägt daher weder Unterschrift noch Siegel.
participants (3)
-
Oliver Bleutgen -
Peter Poeml -
Steffen Dettmer