Solaris 10: советы и приёмы системного администрирования

Один из пользователей попросил помочь ему с настройкой PAM аутентификации в Apache 2, на одном из наших удалённых серверов.

Казалось бы, простая до безобразия задача - скачать mod_auth_pam, скомпилировать его для Apache 2, и проверить, что всё работает. Система использует NIS, потому что я на неё смог запросто зайти.

И что же? Не тут-то было! Модуль скомпилировался запросто, но работать отказывался - в error_log'е упорно появлялись следующие строки (я разбил строку на двое, а то портится общий вид блога):



Всё это пользователь сделал сам, с моими мелкими наводками. На данной стадии он попросил дополнительной помощи, и я, дабы упростить задачу, решил:

1) Перевести эксперименты с системы пользователя на свой Solaris 10-бокс.
2) Для начала отладить процедуру для локальных пользователей, а уже потом браться за NIS

Увидев аналогичные ошибки на своей системе, я решил всерьёз взяться за PAM. Завёл строки в /etc/pam.conf специально для Apache, и добавил к ним опцию debug:



Чтобы удобнее ловилась отладочная информация, подправил /etc/syslog.conf, чтобы он включал следующие строки:



После этого стало удобнее наблюдать, что же именно происходит - по крайней мере, было ясно, что исполняется как раз та часть /etc/pam.conf, которая и была нужна. Но ошибка по-прежнему вводила меня в тупик - пользователь явно существовал, но Apache'м упорно не распознавался (опять приходится переносить строки, чтобы общий вид блога не портился):



Настал момент посмотреть, что же именно делают PAM и Apache 2, когда я ввожу запрашиваемые имя пользователя и пароль для доступа к странице. Тут я сразу вспомнил про замечательный скрипт opensnoop от товарища Брэндана Грэгга (Brendan Gregg). И данный скрипт, запущенный в отдельной консоли, тут же помог мне увидеть, в чём была проблема:



Как видно, httpd не мог открыть файл /etc/shadow (ошибка - код -1), естественно из-за ошибки доступа. Но на всякий случай это можно было проверить. Второй номер в строке про /etc/shadow - это 13, код ошибки:



Ну и после этого всё уже было делом техники:



И осталось указать в httpd.conf, чтобы Apache запускался как раз под этой группой, а не под nobody.

pS: а изначально это всё не работало на машине с NIS-доступом, потому что там в /etc/nsswitch.conf было написано не passwd: files nis, а passwd: compat, и всё использование NIS'а было сделано с помощью указания групп с помощью + и - в файлах /etc/passwd и /etc/shadow. Т.е. доступ на чтение /etc/shadow всё равно нужен, хотя реально потом это и будет обращение к NIS.

Следующим шагом наблюдения за PHP с помощью DTrace вполне может стать подобный скрипт. Он подсчитывает, сколько наносекунд провёл процесс Apache, выполняя ту или иную функцию PHP.

В ходе работы, скрипт выводит таблицу процессов Apache и скриптов PHP, в них запускаемых. Позже выводится таблица всех функций, с указанием процесса, который их выполнял, и затраченного времени.

Скрипт можно скачать тут: php-scripts-timer.d



А вот так может выглядеть типичный результат запуска этого скрипта, при параллельно открываемых с вашего сервера страниц с PHP:

Наконец-то нашёл время, и скачал PEAR модуль DTrace. Замечательная штука! Нашёл там одну маленькую проблему, и написал письмо товарщиу Фёрлонгу (Wez Furlong), который немедленно внёс изменения в исходник модуля, и теперь всё работает просто замечательно. Большущее спасибо, Wez! :)

Итак, самый первый скрипт для наблюдения за PHP: php-scripts-snoop.d



Качайте скрипт, ставьте ему chmod a+x, и после запуска его в терминале на вашем веб-сервере, можно запускать различные скрипты PHP с этого сервера, и скрипт будет докладывать, когда начинается или заканчивается выполнение того или иного PHP скрипта, и который из процессов Apache за это отвечает:



pS: да, с сегодняшнего дня решено все скрипты выкладывать для скачивания - так оно вам удобней будет. Так что в ходе обработки архивных записей блога, все скрипты будут соответствующим образом обозваны и снабжены ссылками для скачивания.