[lug] Bad Apache problem?

[D. Stimits]

Justin-lists wrote:

> Well, let me show you what the actual ldd prints out.
>
> [glowecon at oldschool glowecon]$ ldd /usr/sbin/httpd
>         libpam.so.0 => /lib/libpam.so.0 (0x40019000)
>         libpq.so.2 => /usr/local/pgsql/lib/libpq.so.2 (0x40022000)
>         libz.so.1 => /usr/lib/libz.so.1 (0x40031000)
>         libcrypt.so.1 => /lib/libcrypt.so.1 (0x4003f000)
>         libresolv.so.2 => /lib/libresolv.so.2 (0x4006c000)
>         libm.so.6 => /lib/libm.so.6 (0x4007e000)
>         libdl.so.2 => /lib/libdl.so.2 (0x400a0000)
>         libnsl.so.1 => /lib/libnsl.so.1 (0x400a4000)
>         libdb-4.0.so => /lib/libdb-4.0.so (0x400ba000)
>         libperl.so => 
> /usr/lib/perl5/5.8.0/i386-linux-thread-multi/CORE/libperl.so (0x40162000)
>         libpthread.so.0 => /lib/libpthread.so.0 (0x40271000)
>         libc.so.6 => /lib/libc.so.6 (0x402c3000)
>         libutil.so.1 => /lib/libutil.so.1 (0x40400000)
>         libexpat.so.0 => /usr/lib/libexpat.so.0 (0x40404000)
>         libssl.so.2 => /lib/libssl.so.2 (0x40424000)
>         libcrypto.so.2 => /lib/libcrypto.so.2 (0x40454000)
>         /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
>
> Apache has already been recompiled and installed again since updating 
> the glibc. I just can't think of what else could be causing this since 
> everything else on the system was unchanged (except glibc) at the time 
> the problem was noticed.
>
If one of the apache modules is involved, then the same thing is true 
for each module that links to any outside library. Are any modules 
involved with relevant features, and if so, have they also been recompiled?

D. Stimits, stimits AT attbi DOT com

> >Justin-lists wrote:
> >
> >
> >>Thanks for the reply. I am going to skip some of the questions because
> >>one of your other suggestions has led me to believe the problem was a
> >>result of the glibc updates. I ran 'ldd /usr/sbin/httpd' and checked
> >>all the shared libraries for Apache. Interestingly enough almost all
> >>of the files were updated when the glibc update completed. A couple of
> >>them for example are:
> >>[glowecon at oldschool glowecon]$ ls -l /lib/libcrypt.so.1
> >>lrwxrwxrwx    1 root     root           17 Mar 21 00:11
> >>/lib/libcrypt.so.1 -> libcrypt-2.3.2.so
> >>
> >>[glowecon at oldschool glowecon]$ ls -l /lib/libresolv.so.2
> >>lrwxrwxrwx    1 root     root           18 Mar 21 00:11
> >>/lib/libresolv.so.2 -> libresolv-2.3.2.so
> >>
> >>If we look at my up2date log we see:
> >>[Fri Mar 21 00:11:07 2003] up2date installing packages:
> >>['glibc-2.3.2-4.80', 'glibc-common-2.3.2-4.80', 
> 'glibc-devel-2.3.2-4.80']
> >>
> >>When searching google on my htaccess error a couple days ago, I came
> >>across something that talked about how libcrypt was at fault for the
> >>error. The thread I found was a couple years old though. I'll have to
> >>try and dig that up again.
> >>
> >>My assumption is that whatever changed in the shared libraries is
> >>causing Apache to behave different than it should. That would also
> >>explain why I couldn't ssh into the box until a reboot since sshd uses
> >>almost all the same crypto libraries. Now I'm just wondering how to
> >>fix this. Backing out to the older glibc is probably not a good idea
> >>and I'm not sure how to fix this in Apache? Thanks for the help,
> >>definitely don't feel quite as dumb and boggled as I did before :)
> >
> >In theory, the application will link against a symbolic link that is
> >named only after the major version number, e.g., against
> >libcrypt.so.1, and not libcrypt.so.1.2.3. In this case, it is using
> >libcrypt.so.1 which is pointing at libcrypt-2.3.2.so. This is
> >possible if none of the interface for that portion which is
> >supported in libcrypt.so.1 has changed...if libcrypt-2.3.2.so did
> >nothing but *add* new interfaces, and did not in anyway alter prior
> >interfaces, it should work. Given dependencies in tools like rpm (or
> >perhaps .deb's) might be edited by hand in some cases during a
> >release, the upgrade of apache or glibc might break if a dependency
> >is not recognized. The application will be assuming offsets inside
> >of libraries to be at some particular location, and that the shape
> >of the function signature has not changed, but in reality, it might
> >have (which would cause some serious or strange failures, depending
> >on the case). You still don't have enough information to know for
> >sure that this is what is going on, but it is a reasonable guess at
> >this point, but I personally consider it bad practice to sym link
> >from one major version to another major version, even if some part
> >of the the interface that is relevant is assumed to have not changed
> >(in this case, libcrypt.so.1 is a sym pointing to a different major
> >version library, libcrypt-2.3.2.so).
> >
> >The definitive way to solve this is to take the source for your
> >application that must link against those libraries, and recompile it
> >on your own system, causing the link stages to deal with your
> >particular case. Otherwise, you'd want to get a binary package that
> >you know was compiled against this version of glibc (or whichever
> >libcrypt, so on). If you are using rpm format, this is a case where
> >the .src.rpm with a --rebuild would be a nice fit to test it with.