1623 2002-11-27 12:29:09 +0300 osec (feature request) - show packages for files 2005-09-04 22:08:42 +0400 1 1 4 Development Sisyphus osec unstable all Linux CLOSED FIXED P5 enhancement --- 1 vyt legion lav ldv legion mike oldest_to_newest 1493 0 vyt 2002-11-27 12:29:09 +0300 В отчётах osec было бы удобно видеть названия пакетов, которым принадлежат модифицированные файлы (да и после модификации), и которые можно группировать по отношению к rpm-пакетам. Это может облегчить отслеживание изменений при обновлениях. --- --- 4503 1 mike 2002-11-28 23:14:36 +0300 И раз уж висит бага -- было бы замечательно иметь возможность \"no news is good news\" -- не слать писем при отсутствии отслеживаемых изменений. Вполне может быть -- включенную по умолчанию. 7868 2 mike 2002-11-28 23:14:36 +0300 И раз уж висит бага -- было бы замечательно иметь возможность \"no news is good news\" -- не слать писем при отсутствии отслеживаемых изменений. Вполне может быть -- включенную по умолчанию. 4504 3 vyt 2002-12-05 16:57:33 +0300 Ещё удобно было бы иметь опциональную возможность строить отчёты в xml, дав дорогу энтузиастам, желающим написать XSLT для форматирования результатов по вкусу ;) 7869 4 vyt 2002-12-05 16:57:33 +0300 Ещё удобно было бы иметь опциональную возможность строить отчёты в xml, дав дорогу энтузиастам, желающим написать XSLT для форматирования результатов по вкусу ;) 4505 5 inger 2002-12-06 12:30:02 +0300 Все будет в свое время. Я предпочитаю медленно добавлять новые фичи. Думаю, что со временем будут и сетевые фичи edited on: 06-12 12:30 7870 6 inger 2002-12-06 12:30:02 +0300 Все будет в свое время. Я предпочитаю медленно добавлять новые фичи. Думаю, что со временем будут и сетевые фичи edited on: 06-12 12:30 15537 7 inger 2004-06-24 13:22:39 +0400 нужны ли кому ещё перечисленные ниже фичи? 15561 8 vyt 2004-06-24 17:48:27 +0400 Мне нужны. Главное - принадлежность файлов к rpm-пакетам. 15634 9 mike 2004-06-26 11:11:18 +0400 Субъективно: - по принадлежности к пакетам: хорошо бы, но off by default по причине ресурсоемкости режима (кстати, на дальнем плане видится некая интеграция с обновлялкой с тем, чтобы результаты apt-get upgrade оттуда можно было вычесть) - XML: только не "все туда же", лучше отдельной утилитой (Виталий, напишете? :) в силу специфики запроса и относительной низкоуровневости базового инструмента (osec). - про "no news is good news" -- субъективно это правильное положение дел по умолчанию. Параноики сами включат, а присматривающим за заметным кол-вом машин не придется мудрить с ~/.procmailrc... 15712 10 inger 2004-06-28 11:51:21 +0400 Ну значит ставлю себе в 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'изм? 16509 11 inger 2004-07-05 17:55:32 +0400 Сегодня/Завтра в 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 большим количеством информации (ибо уже проходили через это ;) ). 17865 12 inger 2004-08-06 15:27:35 +0400 Уже есть в дедале - потом будет и в Сизифе