В отчётах osec было бы удобно видеть названия пакетов, которым принадлежат модифицированные файлы (да и после модификации), и которые можно группировать по отношению к rpm-пакетам. Это может облегчить отслеживание изменений при обновлениях. --- ---
И раз уж висит бага -- было бы замечательно иметь возможность \"no news is good news\" -- не слать писем при отсутствии отслеживаемых изменений. Вполне может быть -- включенную по умолчанию.
Ещё удобно было бы иметь опциональную возможность строить отчёты в xml, дав дорогу энтузиастам, желающим написать XSLT для форматирования результатов по вкусу ;)
Все будет в свое время. Я предпочитаю медленно добавлять новые фичи. Думаю, что со временем будут и сетевые фичи edited on: 06-12 12:30
нужны ли кому ещё перечисленные ниже фичи?
Мне нужны. Главное - принадлежность файлов к rpm-пакетам.
Субъективно: - по принадлежности к пакетам: хорошо бы, но off by default по причине ресурсоемкости режима (кстати, на дальнем плане видится некая интеграция с обновлялкой с тем, чтобы результаты apt-get upgrade оттуда можно было вычесть) - XML: только не "все туда же", лучше отдельной утилитой (Виталий, напишете? :) в силу специфики запроса и относительной низкоуровневости базового инструмента (osec). - про "no news is good news" -- субъективно это правильное положение дел по умолчанию. Параноики сами включат, а присматривающим за заметным кол-вом машин не придется мудрить с ~/.procmailrc...
Ну значит ставлю себе в TODO для начала дополнительный фильтр, который к результатам osec_mailreport добавит из каких они пакетов. Потом обёртка вокруг запуска osec_reporter, который не будет запускать mail в двух вариантах Пока примерно картина будет такой: osec osec-cronjob - общий framework который запускает pipeline. И там же config, в котором будет описываться pipeline. Варианты: osec_reporter + mail(умолчание) osec_reporter|osec_rpms osec_reporter + mail если есть osec_reporter + mail если есть|osec_rpms Вопрос к Диме: насколько безопасно делать конфигурируемый pipeline в cronjob? Я бы хотел воспользоваться eval. eval это bash'изм?
Сегодня/Завтра в Daedalus уйдёт пробная версия osec с конфигурируемым framework новый подпакет: * osec-cronjob - сам framework * osec-mailreport - куча разных фильтров для организации отчётов через почту osec_reporter - собственно сам reporter osec_rpm_reporter - дополнительный фильтр к osec_reporter, добавляет имена пакетов osec_mailer - обёртка вокруг mail, посылает почту только если не было "No changes". Всё это хозяйство настраивается /etc/osec/pipe.conf REPORT_PIPE - pipeline для генератора отчётов SEND_PIPE - pipeline для отсылки результатов куда-либо По-умолчанию всё будет работать как обычно Вот пример конфига с полным снаряжением: -------------------- MAIL_PIPE='/bin/mail -s "[osec] Daily security check" root' REPORT_PIPE='/usr/bin/osec_reporter|/usr/bin/osec_rpm_reporter' SEND_PIPE="/usr/bin/osec_mailer" ------------------- Пожайлуста, гляньте и скажите - это то что вы хотели или нет. Я несколько не уверен в целесообразности osec_rpm_reporter - он разве что полезен для контроля своих собственных пакетов на установку (нет ли каталогов без принадлежности кому-либо?) или изменения, но вот если пакет был удалён уже из системы (соответственно из базы RPM),то osec естественно не сможет сказать какой это был пакет, тут нужно либо заниматься хранением информации о принадлежности в базе osec (что не хотелось бы), либо искать какие-либо другие источники информации, может быть сделать отдельную утилиту (и склеивать потом два отчёта в один), очень не хотелось бы перегружать сам osec большим количеством информации (ибо уже проходили через это ;) ).
Уже есть в дедале - потом будет и в Сизифе
