![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
# strings libphp5.so | grep DR-DOS
DR-DOS executable (COM)
DR-DOS executable (COM)
, DR-DOS MBR, Version 7.01 to 7.03
, DR-DOS MBR, Version 7.01 to 7.03
, DR-DOS MBR, version 7.01 to 7.03
, DR-DOS MBR (IBMBIO.LDR)
, DR-DOS Bootloader (LOADER.SYS)
, DR-DOS (3.41) Bootloader
, DR-DOS Bootloader
# strings libphp5.so | grep NTLDR
NTLDR is missing
NTLDR nicht gefunden
NTLDR fehlt
NTLDR fehlt
NTLDR fehlt
NTLDR ist komprimiert
NTLDR is compressed
# strings libphp5.so | grep 'EFI '
Universal EFI binary with 1 architecture
Universal EFI binary with 2 architectures
Universal EFI binary with %ld architectures
(EFI application)
(EFI boot service driver)
(EFI runtime driver)
И там ещё много такого… Это PHP-модуль для Апача, если что.
Оригинал этой записи в личном блоге.
При обследовании одного сервера на предмет используемой версии 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: и что надо с такими администраторами после всего этого сделать?
Оригинал этой записи в личном блоге.
Я почему-то думал, что знаю про Апач практически всё, а тут внезапно оказалось, что там есть неизведанные возможности. Если кто хочет сначала поломать голову сам, то вопрос выглядит так:
требуется в целом закрыть паролем доступ к скрипту (ну или к директории, где он лежит), но если скрипт запускается с определённым параметром, то чтобы пускало и без пароля. (awstats должен показывать статистику для одного конкретного сайта (/awstats/awstats.pl?config=www.foo.com) всем желающим, а для всех остальных сайтов – только под паролем).
Оригинал этой записи в личном блоге.
Я видел много разных криво настроенных прав в веб-серверах, но ТАКОЕ — в первый раз.
Основные файлы конфигурации апача (в apache/conf/) не только читабельны, но и писабельны для пользователя, от которого этот апач работает. И SSLные ключи вместе с сертификатами тоже, хотя им даже читабельными быть не требуется.
Я на всякий случай два раза перепроверил, не поверив своим глазам. Да, так оно и есть. “Всем пофиг.”
Оригинал этой записи. Комментировать можно тут или там.
# du -sh /opt/apache/conf/
3.4M /opt/apache/conf/
Оригинал этой записи. Комментировать можно тут или там.
Задачка для админов, которые утверждают, что умеют прекрасно настраивать апач и php под ним. (Да, я тоже самоуверенно думал, что умею :).
Дано: машина с линуксом (или FreeBSD, или солярисом, не принципиально). На ней запускается несколько экземпляров апача, каждый со своей конфигурацией (естественно, на разных IP/портах).
Apache (2) и mod_php (5) установлены из стандартных пакетов/портов, кому как больше нравится, но суть в том, что бинарники и библиотеки для всех экземпляров апача одинаковы. [Это менять нельзя, таково условие задачи, обусловленное необходимостью лёгкого апгрейда стандартными средствами.] Разные только конфиги.
Соответственно, везде, где подключён mod_php5, настройки для php считываются из одного и того же файла (/etc/php5/apache2/php.ini или /usr/local/etc/php/php.ini, не принципиально). Естественно, во всех апачах настройки получаются одинаковые.
Собственно задача: у одного из апачей надо изменить некоторые параметры php, которые задаются через php.ini. Например, max_execution_time. Разрешается поменять все параметры сразу путём подсовывания другого php.ini.
Как?
Хинт: задача решаемая, но я на поиски решения потратил минут двадцать.
Оригинал этой записи. Комментировать можно тут или там.
Ну и пусть себе лежит, место ничем не хуже других. Тем более, что если просто зайти на морду сайта, то срабатывает установленный по умолчанию RedirectMatch ^/$ /apache2-default/
Если сайтов становится больше одного, то каждому надо создавать свой подкаталог. Подкаталоги логично создавать там же - в /var/www/.
А дефолтовый сайт часто оставляют. Он ловит все запросы, не адресованные к другим явно определённым сайтам, и радостно говорит It works!. Ну и пусть говорит.
Вот тут-то и прячется несколько неожиданная засада. Остальные сайты лежат аккурат в подкаталогах /var/www. Который есть DocumentRoot от дефолтового сайта.
То есть, через него можно получить доступ к файлам всех остальных сайтов.
И что особенно радостно, по умолчанию для /var/www/ включены Indexes и FollowSymLinks, а никакой перл или PHP как раз не включены. Поэтому есть сильно ненулевая вероятность, что все скрипты будут отдаваться в виде исходников.
Мораль:
1) отключайте ненужную функциональность. даже если она на первый взгляд ничему не мешает. чисто из чувства паранойи.
2) не создавайте DocumentRoot одного сайта в подкаталоге другого. а дефолтовый сайт, если вы решили его оставить, лучше перенести на уровень пониже - например, в /var/www/default
3) блоки <Directory> по возможности располагайте на глобальном уровне, ВНЕ <VirtualHost>. и ограничения доступа приделывайте к Directory, а не к VirtualHost. в качестве дополнительной защиты от непредусмотренного доступа через другой виртуальный хост.
Написано сие по результатам внимательного рассматривания собственного сервера.
А у вас, случайно, не так? :)
via
![[livejournal.com profile]](https://www.dreamwidth.org/img/external/lj-userinfo.gif){kind=small}
b_a_tUpd: ух ты! они всё перевели.
"удалить сердцевину Apacheских особенностей Сервера HTTP, которые являются всегда доступными"
"непереплетенный, предразветвляющийся сервер сети"
"довольный тайник работал ключом к URIs"
"настройка HTTP просит и удары головой ответа"
"динамически формируемое массовое действительное оказание гостеприимства"
что ни фраза - то перл.
"PHP is glue. It is the glue used to build cool web applications by sticking dozens of 3rd-party libraries together and making it all appear as one coherent entity through an intuitive and easy to learn language interface. The flexibility and power of PHP relies on the stability and robustness of the underlying platform. It needs a working OS, a working web server and working 3rd-party libraries to glue together. When any of these stop working PHP needs ways to identify the problems and fix them quickly. When you make the underlying framework more complex by not having completely separate execution threads, completely separate memory segments and a strong sandbox for each request to play in, feet of clay are introduced into PHP's system."
https://www.php.net/manual/en/faq.installation.php#faq.installation.apache2
( Для плохо владеющих английским: )
То есть, вместо внятного объяснения авторы почти открыто говорят: "мы написали такую какашку, что не гарантируем правильную работу с памятью, поэтому если уж вас угораздило её запустить, лучше делать это в отдельной песочнице, чтоб она вместе с собой не уронила соседние треды".
via
nikulina