Re: [suse-security] Apache upgrade from SuSE ?
Hi,
On Wed, Jul 03, 2002 at 12:02:47PM +0200, Oliver Bleutgen wrote:
Strictly speaking those module updates should not have been necessary.
I doubt that, from my own experiences.
Well I can not state that it works for all ~60 modules -- but for mod_php4 and mod_perl it does.
Peter, I have a small logical problem with that. You claim that the apache-1.3.19-115.rpm would run with modules of the original suse distribution, which is apache-1.3.12-120. Then, if this is so, why did SuSe release updated versions of all apache modules, when it first made the jump to apache-1.3.19-30? (that was the new version at that time, I did some searching). If the modules should work with apache 1.3.19-115 as you say, why shouldn't they have worked with apache 1.3.19-30? Either the update of the modules at that time was unnecessary, or it's still necessary today. (Or, there's some deep voodoo involved which makes the newer apache 1.3.19 "more compatible" with 1.3.12 modules than the old one - plausible?)
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.
You are right -- the older entries are superseded (i.e. removed) on that web site (which is bad IMO).
Indeed, why not just putting in a big fat warning that this upgrade is superseded. And just remove the links.
Also, looking on http://www.suse.de/de/support/security/ there is only one apache announcement-- the last one. Apparently, we did not issue an announcement at that time -- which would be bad IMO but I guess we might not have had the same infrastructure at that time compared to now). Or (!) we did issue the information about apache, but not in its own announcement but in a 2) pending vulnerabilities, solutions, workarounds section. This way, the information is hard to find because the website does list only the titles, not the affected package names, nor offers it a way to search through the announcements. This is bad IMO as well.
Well, at least we have rpm --changelog: * Fre Apr 20 2001 - poeml@suse.de - security update to Apache 1.3.19 due to a bug where, in the default installation, a very long path with many slashes could lead mod_negotiation and mod_dir/mod_autoindex to display a directory listing instead of the index.html.* files - don't define SINGLE_LISTEN_UNSERIALIZED_ACCEPT (it's already there) - update mod_ssl to corresponding version (2.8.2) - make mod_ssl subpackage require correct apache release number - don't use macro for Version how about a trip down memory lane? ;-) Oh, and about getting an older state of said webpage: http://web.archive.org/web/20011126194844/http://www.suse.com/us/support/dow... As I wasn't affected from the above bug, I didn't upgrade.
I'll stimulate discussion about what kind of improvements would be useful here. Be assured that your criticism is very helpful.
[big snippage]
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.
It looks so. I don't believe it, but it's well possible. We might dig into it further, but I can't promise anything.
You don't need to, but taking my thoughts from above into consideration - as well as the fact that two other people on this list had the same problem - I'm quite sure that I'm right. If I am right, I'd think SuSE should take a look at their testing procedures, because they issued an update package which won't work on a stock install. And this is the first configuration on which I'd expect tests to be run. Perhaps it wasn't notified because apache will startup, but not work. Anyway, it's plausible that this incidend is caused mainly by growing problems and pains with aging versions of a distribution. In summary, two thing come to mind which would have helped me: - proper rpm dependencies well, I can install rpms, that's it, so I've no idea if this is doable in all cases. - A hint in the advisory to also install the newer apache modules. Ok, thanks for taking the time to answer my ramblings ;-). cheers, oliver
On Thu, Jul 04, 2002 at 01:46:18PM +0200, Oliver Bleutgen wrote:
Hi,
On Wed, Jul 03, 2002 at 12:02:47PM +0200, Oliver Bleutgen wrote:
Strictly speaking those module updates should not have been necessary.
I doubt that, from my own experiences.
Well I can not state that it works for all ~60 modules -- but for mod_php4 and mod_perl it does.
Peter,
I have a small logical problem with that. You claim that the apache-1.3.19-115.rpm would run with modules of the original suse distribution, which is apache-1.3.12-120.
Oliver, perl and php modules from stock 7.0 do indeed not work with the latest update (segfaults upon requests just as you described)
Then, if this is so, why did SuSe release updated versions of all apache modules, when it first made the jump to apache-1.3.19-30? (that was the new version at that time, I did some searching).
If the modules should work with apache 1.3.19-115 as you say, why shouldn't they have worked with apache 1.3.19-30? Either the update of the modules at that time was unnecessary, or it's still necessary today. (Or, there's some deep voodoo involved which makes the newer apache 1.3.19 "more compatible" with 1.3.12 modules than the old one - plausible?)
It might be that we knew that updated modules were necessary, but the knowledge got lost.
Well, at least we have rpm --changelog: [...] As I wasn't affected from the above bug, I didn't upgrade.
Understandable.
If I am right, I'd think SuSE should take a look at their testing procedures, because they issued an update package which won't work on a stock install. And this is the first configuration on which I'd expect tests to be run.
We are currently taking a look, in reaction to these problems. (However, the situation in question is, as we see it, *not* the first configuration, that needs to be tested -- we expect systems being up to date with security updates to be more important/frequent.)
Perhaps it wasn't notified because apache will startup, but not work.
Good guess, but our tests do fetch pages from apache, too ;^} But all modules were up to date in our tests.
Anyway, it's plausible that this incidend is caused mainly by growing problems and pains with aging versions of a distribution.
I would love to know the exact reason.
In summary, two thing come to mind which would have helped me:
- proper rpm dependencies well, I can install rpms, that's it, so I've no idea if this is doable in all cases.
- A hint in the advisory to also install the newer apache modules.
Agreed.
Ok, thanks for taking the time to answer my ramblings ;-).
No, thanks for your patience ;) Peter -- VFS: Busy inodes after unmount. Self-destruct in 5 seconds. Have a nice day...
participants (2)
-
Oliver Bleutgen -
Peter Poeml