November 2019

S M T W T F S
      12
34 5 678 9
10111213141516
17181920212223
24252627282930

Style Credit

Expand Cut Tags

No cut tags
Thursday, March 1st, 2012 02:15 pm

При обследовании одного сервера на предмет используемой версии OpenSSL обнаружилось, что… никакой:

# ldd apache/modules/mod_ssl.so |grep libssl
	libssl.so.1.0.0 => not found

Апач был собран афроадминистраторами из исходников. Но при сборке маршрут к библиотеке явно не указали, и в ld.so.conf тоже не написали, вот она и не находится. Тем не менее, апач таки успешно запускается, и SSL в нём каким-то чудом работает.

Дальнейшее препрарирование показало ещё более прекрасное:

# ldd apache/modules/libphp5.so |grep libssl
	libssl.so.1.0.0 => /opt/openssl/lib/libssl.so.1.0.0 (0x00002ad00e36d000)
	libssl.so.6 => /lib64/libssl.so.6 (0x00002ad0101b3000)

PHP, понятное дело, тоже был собран афроадминистраторами из исходников.

А теперь вопросы:
Вопрос 1, достаточно простой: КАК они умудрились собрать PHP с двумя разными версиями одной библиотеки одновременно?
Вопрос 2, посложнее: а нафига они это сделали?
Вопрос 3: а всё-таки как апач находит библиотеку при загрузке mod_ssl? Никаких LD_PRELOAD и LD_LIBRARY_PATH в запускающем скрипте апача нет, я проверял и в самом скрипте, и в environment’е запущенного апача.
Вопрос 4: и что надо с такими администраторами после всего этого сделать?

Оригинал этой записи в личном блоге.

Friday, March 2nd, 2012 06:53 am (UTC)
напрасно ругаешься.
сборка php с появлением lib64 перестала быть такой уж прямолинейной. добавь
к --with-libdir=lib64 этот opt. и получишь.

вобчем прежде чем называть афроадминистраторами попробуй собрать php как в дистирибутиве, со всеми своими библиотечками.