Summary: | нет информации в теме письма | ||
---|---|---|---|
Product: | Sisyphus | Reporter: | Sergey V Turchin <zerg> |
Component: | osec-mailreport | Assignee: | Alexey Gladkov <legion> |
Status: | CLOSED FIXED | QA Contact: | qa-sisyphus |
Severity: | enhancement | ||
Priority: | P1 | CC: | anubix, asy, erthad, legion, mike, zerg |
Version: | unstable | ||
Hardware: | all | ||
OS: | Linux |
Description
Sergey V Turchin
2004-12-23 12:07:55 MSK
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 по умолчанию. |