DTrace

Вопрос: как получить список всех лог-файлов, использующихся в Solaris?
Естественно, большинство из них известно, однако многие программы могут писать логи туда, куда вы укажете, а на большом сервере этих программ может быть достаточно, чтобы вы позабыли директории журналов. Тем не менее, можно привести некоторые отправные точки для поиска лог-файлов:
1. Файл /etc/syslog.conf содержит имена лог-файлов, которые записываются syslog-ом.
2. Директория /var/svc/log - стандартное расположение логов SMF.
3. Файлы в /etc/default, определяющие журналы для служб, не использующих syslog. Например /var/adm/sulog.

Вернемся к разговору о недокументированных трюках с DTrace, касающихся ssh, о чем мы уже писали. Тогда мы привели пример скрипта, перехватывающего пароли исходящих ssh-коннектов. После этого возможно, кому-то показалась смешным возможность с помощью DTrace получить логины и пароли для ВХОДЯЩИХ ssh-соединений. Мол, с исходящими-то ладно, DTrace просто перехватывает локальный ввод, но со входящими такого не получится, там все закодировано и ssh-программисты не зря свой хлеб едят. А вот системный администратор Manuel Burki из Цюриха так не считает и в который раз заставляет убедиться в неограниченных возможностях DTrace.

Вышедший недавно релиз Sun Studio Express содержит интереснейший модуль D-Light для анализа приложений посредством DTrace. Проект еще юн и некоторые заявленные опции отсутствуют, но открывающиеся при использовании этого плагина возможности впечатляют. Запустив студию и выбрав Tools->D-Light Tool, в развернувшемся окне модуля выбираем Instruments - тут нам доступны Clock profiler, File System Activity, Read Write Monitor и инструменты для Java. Выбираем первые два, кликаем по Select Target и выбираем предложенное первым для примера архивирование tar'ом /usr/include.

Часто администратору Solaris или программисту приходится выяснять причины падения того или иного приложения - это может быть стандартная системная или новая, только что скомпилированная и нуждающаяся в отладке программа. Все усложняется, если речь идет о многопользовательской системе, где запущено множество приложений и очень нелегко отследить причины падения сразу нескольких программ.
Ранее основным способом анализа упавшей программы было исследование core или coredump, что в принципе одно и тоже. Однако этот способ имеет свои недостатки: проблемы с безопасностью - core может содержать данные, которые пользователю знать нельзя; часто огромный размер, из-за чего найти необходимую информацию довольно затруднительно, возможно переполнение диска и послать такой файл для анализа технической поддержке просто нереально.
Можно создавать специальные встраиваемые библиотеки c обработчиками сигналов SIGBUS и SIGSEGV, однако для многопользовательской системы это плохое решение.

Продолжая разговор о применении DTrace для исследования безопасности системы, поговорим о перехвате паролей* и просто строковых данных приложений, проследим за тем, что делает тот или иной пользователь, и за тем, какие файлы и кто создает в любимой хакерами директории /tmp.

Профилирование - процесс анализа характеристик приложения, обычно ради улучшения его работы. Однако прежде, чем вы cможете профилировать программу, необходимо дать D программе возможность ограничить зарегистрированные события, связанные только с одним приложением. Есть несколько способов для достижения данной задачи. Во-первых, вы можете связать вашу D программу с одним или более процессами с помощью использования опции -c, чтобы определить выполняющуюся команду, или опции -p для определения PID'а уже выполняющегося процесса. Можно указывать множество процессов или команд для обеих опций, но первый всегда хранит свой PID в специальной макро-переменной $target. (Макро-переменные заменяются связанными с ними значениями фактически до запуска D программы, таким образом любое место в вашей D программе, где вы используете $target, будет заменено номером PID первого указанного с помощью опций -c или -p процесса). Например, можно использовать $target в предикате, чтобы ограничить выполнение пробы только для одного процесса. После того, как все ассоциированные процессы умирают, D программа также заканчивает свою работу, отобразив любой конечный вывод или выполнив пробу END.
Во вторых, можно просто передать PID процесса как параметр D программе. Любые параметры после любых опций передаются переменным 1 $, 2 $, 3 $ и т.д. (макропеременная $0 - название вашей D программы). Так как DTrace не знает о том, что ваши параметры являются процессами, при использовании этого метода D-скрипт не заканчивает свою работу при завершении процессов.