Расскажу историю о том, как очередная хотелка заказчика заставила меня немного под другим углом взглянуть на syslog. И так, какой самый привычный вам способ обращаться к файлу /var/log/syslog?
Если вы штатный пользователь, то, вероятно, хотите провести мониторинг логов и выяснить, где что-то пошло не так. Для этого вы пойдете искать сообщения от "подозреваемого" сервиса.
Если вы разработчик, то можете захотеть направлять туда отладочную информацию. А-ля, подключение к VPN прошло успешно, сертификат принят и т.д. Если вы пишите демон, за которым не может быть закреплен терминал, то вариант с syslog - вынужденная мера.
Так вот, пришел заказчик и говорит: "Нашим пользователям абсолютно неясна причина, по которой подключение к VPN было отклонено. То ли это ошибка в конфигах, то ли сертификат просрочен. Хочется, чтобы на рабочий стол выводилось уведомление с подробным описанием ошибки".
Принято, сделаем. Первое, что пришло в голову - использовать libnotify. Библиотека позволяет через код собирать уведомления и направлять их специальному демону (зависит от окружения) для вывода. Утилита "notify-send" демонстрирует работу API:
$ notify-send header body
Выяснить, какой процесс выступает в роли демона для уведомлений, можно следующим образом:
$ NOTIFD_ID=$(qdbus org.freedesktop.DBus /org/freedesktop/DBus org.freedesktop.DBus.GetConnectionUnixProcessID org.freedesktop.Notifications)
$ ps aux | grep $NOTIFD_ID
Короче говоря, подход этот оказался нерабочим, т.к. коды ошибок формировал демон вне пользовательской сессии, а libnotify требовал в окружении процесса переменную DBUS_SESSION_BUS_ADDRESS, которая отсутствовала...
Частично о проблеме можно почитать тут.
Дальше либо добавлять новые коды ошибок, патчить 3 утилиты "strongswan -> network manager -> nm-applet" и выводить сообщения через nm-applet, либо использовать сторонний ПОЛЬЗОВАТЕЛЬСКИЙ сервис, который бы отслеживал логи и по ним собирал уведомления.
Благо, в дистрах обычно присутствуем подсистема событий, которая работает совместно с демоном syslog-ng и позволяет реагировать на определенные логи.
В результате, задача решилась следующим образом:
1) проработан ряд конфигов, по которым производился парсинг сообщений syslog и настройка уведомлений;
2) в код strongswan добавлен вывод отладочной информации (в централизованном формате) в файл /var/log/syslog:
DBG1(DBG_CFG, "type=STRONGSWAN action='CONNECTION ERROR REPORT' body='%s'", "Не удалось загрузить сертификат клиента");
3) в правила "роспакоуки" deb пакета добавлены инструкции установки конфигов в системные директории;
С высоты текущего полета не сказал бы, что решение супер гибкое и легко масштабируемое, но правки оказались минимальными и безопасными, что особенно важно при работе с таким софтом, как strongswan.
LinuxCamp