[lug] Bad Apache problem?

[D. Stimits]

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.

D. Stimits, stimits AT attbi DOT com