|
ALT Linux Bugzilla – Full Text Bug Listing |
| Summary: | нет информации в теме письма | ||
|---|---|---|---|
| Product: | [Development] Sisyphus | Reporter: | Sergey V Turchin <zerg@altlinux.org> |
| Component: | osec-mailreport | Assignee: | Alexey Gladkov <legion@altlinux.org> |
| Status: | CLOSED FIXED | QA Contact: | qa-sisyphus@altlinux.org |
| Severity: | enhancement | ||
| Priority: | P1 | CC: | anubix@yandex.ru, asy@altlinux.org, erthad@altlinux.org, mike@altlinux.org, zerg@altlinux.org |
| Version: | unstable | ||
| Hardware: | all | ||
| OS: | Linux | ||
1. это небезопасно (если сломают машину и отключат osec, то об этом и не узнаешь) 2. это уже сделано для сильных духом.
(In reply to comment #1) > 2. это уже сделано для сильных духом. В каком файле?
Тогда удобно было бы отражать в теме письма
Например +2 -3 ~44 означает, что добавлено 2, убрано 3, изменено 44 Так же можно использовать символ ! в случае чего-то очень страшного
Все еще достает приблизительно догадываться о пустых письмах по размеру письма
перевешиваю на нынешнего мантейнера osec
Не думаю, что эта фича востребована.
Да это не фича, а бага. Попробуй принимать такие письма с 10-и машин и читать их все, несмотря на то, что они пустые. Меня с 2-х достает читать пустые письма.
переименую название
В сизиф ушёл osec-1.2.4 в котором можно включить summary об изменениях. В pipe.conf теперь можно указывать: MAIL_PIPE='/bin/mail -s "$HOSTNAME: +$ADDED -$REMOVED ~$CHANGED" root' или MAIL_PIPE='/bin/mail -s "$HOSTNAME: $STAT" root' что будет эквивалентно: MAIL_PIPE='/bin/mail -s "$HOSTNAME: chg=$CHANGED,add=$ADDED,del=$REMOVED" root'
О! Наконец-то! Спасибо!
Может, такой формат и дать по умолчанию?
(В ответ на комментарий №12)
> Может, такой формат и дать по умолчанию?
В конфиге есть готовые примеры. Нужно только раскомментировать при наличии
пакета.
(В ответ на комментарий №12)
> Может, такой формат и дать по умолчанию?
Я хотел проверить, прежде, чем это написать :-)
(В ответ на комментарий №13)
> Нужно только раскомментировать при наличии пакета.
Чем может быть плохо раскомментировать по умолчанию ?
/etc/cron.daily/osec: line 72: ADDED: unbound variable
Предлагаю по умолчанию MAIL_PIPE='/bin/mail -s "[osec] $HOSTNAME: +$ADDED -$REMOVED ~$CHANGED" root' или MAIL_PIPE='/bin/mail -s "[osec] $HOSTNAME: $HUMAN_READABLE_STAT" root' что будет эквивалентно: MAIL_PIPE='/bin/mail -s "[osec] $HOSTNAME: +$ADDED -$REMOVED ~$CHANGED" root'
(In reply to comment #18) > Предлагаю по умолчанию > MAIL_PIPE='/bin/mail -s "[osec] $HOSTNAME: +$ADDED -$REMOVED ~$CHANGED" root' Угу, эта форма более прозрачна.
(В ответ на комментарий №19)
> (In reply to comment #18)
> > Предлагаю по умолчанию
> > MAIL_PIPE='/bin/mail -s "[osec] $HOSTNAME: +$ADDED -$REMOVED ~$CHANGED" root'
> Угу, эта форма более прозрачна.
Для меня "~" не очевиден.
(В ответ на комментарий №20)
> (В ответ на комментарий №19)
> Для меня "~" не очевиден.
Не проблема. Возьми любой другой 1 символ
Так же, поля с нулями в тему вносить не нужно.
А если одни нули можно просто фразу типа "no changed found", тогда еще лучше
читаться будет.
Мне больше нравится chg=5,add=3,del=8
(In reply to comment #22) > Мне больше нравится chg=5,add=3,del=8 Может, тогда "5 changed, 3 added, 8 deleted"? (или хотя бы с пробелами после запятых, чтоб глаз в буковках не завязал)
(В ответ на комментарий №23)
> Может, тогда "5 changed, 3 added, 8 deleted"? (или хотя бы с пробелами после
> запятых, чтоб глаз в буковках не завязал)
Если у меня получится, то ты сможешь сделать как захочешь.
(В ответ на комментарий №17)
> /etc/cron.daily/osec: line 72: ADDED: unbound variable
Это потому, что ты не сменил SEND_PIPE.
Я знаю, что не очевидно получилось.
Попробую сделать очевиднее.
(В ответ на комментарий №23)
> Может, тогда "5 changed, 3 added, 8 deleted"? (или хотя бы с пробелами после
> запятых, чтоб глаз в буковках не завязал)
Сделал 1.2.4-alt2, там есть возможность задавать CHANGED, ADDED, REMOVED и STAT
в обоих скриптах: osec.cron и osec_mailer.
Миш, если ты захочешь, то сможешь сделать любой заголовок, используя первые три
переменных. Думаю, это честно.
Исправлено в 1.2.4-alt2.
Так, все-таки, почему бы не сделать заголовок хоть немного информативным?
Оно уже информативно.
Не вижу ничего нового в pipe.conf Какая новая информация теперь есть в теме письма?
(В ответ на комментарий №30)
> Не вижу ничего нового в pipe.conf
> Какая новая информация теперь есть в теме письма?
Как я писал ранее, в pipe.conf теперь можно указывать:
MAIL_PIPE='/bin/mail -s "$HOSTNAME: +$ADDED -$REMOVED ~$CHANGED" root'
или
MAIL_PIPE='/bin/mail -s "$HOSTNAME: $STAT" root'
что будет эквивалентно:
MAIL_PIPE='/bin/mail -s "$HOSTNAME: chg=$CHANGED,add=$ADDED,del=$REMOVED" root'
Учитывая, что на вкус и цвет согласия нет, то каждый может сформировать
заголовок для себя сам.
(В ответ на комментарий №31)
> каждый может сформировать заголовок для себя сам.
Это и так понятно.
Почему бы по умолчанию не сделать заголовок хоть немного информативным?
(В ответ на комментарий №32)
> Почему бы по умолчанию не сделать заголовок хоть немного информативным?
Хорошо. В следующей версии я сделаю по умолчанию: "$HOSTNAME: $STAT"
(В ответ на комментарий №33)
> Хорошо. В следующей версии я сделаю по умолчанию: "$HOSTNAME: $STAT"
Клево, спасибо!
На сём я полностью буду удовлетворен.
(In reply to comment #33) > (В ответ на комментарий №32) > > Почему бы по умолчанию не сделать заголовок хоть немного информативным? > > Хорошо. В следующей версии я сделаю по умолчанию: "$HOSTNAME: $STAT" Переоткрою. Чуть-чуть бы доделать. Надо ещё переменную, скажем, $STATE c состояниями "PASSED и FAILED". Чтобы по ней сортировать можно было по заголовку. Можно, конечно, нагородить огород с регулярным выражением по нахождению некоторого количества нулей в выводе $STAT, но не очень удобно. И умолчание сделать "[osec] Daily security check $STATE -- $HOSTNAME".
(В ответ на комментарий №35) > Переоткрою. Чуть-чуть бы доделать. Не надо так делать -- у каждой хорошей баги должны быть чёткие начало, формулировка и конец. Когда начинаются бесконечные самоуточняющиеся портянки, незаметно растёт наклад времени на их разбор и "diff" для выяснения, что ж там ещё; теряют точность ссылки на багу в %changelog (или же приходится сопоставлять и время); многих подобное подвигает в сторону "забить". Проверено на случае, где "портянки" дошли до клинических и в итоге пришлось писать внутренний регламент. Есть отдельная проблема -- есть отдельная бага. Добавил на http://www.altlinux.org/BugTracking/BugzillaMiniHowto на всякий...
(В ответ на комментарий №36)
> Есть отдельная проблема -- есть отдельная бага.
Согласен.
P.S.
Куча проблем сваленных в один баг -- бардак, переоткрытия, переименования,
лебедь-рак-щука и т.д.
Вот ведь накинулись, а... :-) Bug 30414
Я сам не люблю всё в один баг мешать и, частенько, занимаюсь растаскиванием
одного бага на несколько. Но тут уж очень в тему: по факту баг не закрыт, так
как, по-умолчанию, информации в теме всё ещё нет.
По факту и большому опыту забить проще ;-)
(В ответ на комментарий №35)
> Можно, конечно, нагородить огород с регулярным выражением по
> нахождению некоторого количества нулей в выводе $STAT, но не очень удобно. И
> умолчание сделать "[osec] Daily security check $STATE -- $HOSTNAME".
Сделал subject:
[osec${PROFILE:+:$PROFILE}] Daily security check ($STAT) -- $HOSTNAME" root
по умолчанию.