7 ответов в этой теме

[Serge3leo]

Желательно без перезагрузки Mac OS X.

$ du -h -s /var/drweb/log
8,3G	/var/drweb/log
$ df -h /
Filesystem	 Size   Used  Avail Capacity  Mounted on
/dev/disk0s2  149Gi  134Gi   15Gi	91%	/

7% диска - для Dr.Web Ничего для Вас не жалко

[Pavel Plotnikov]

7% диска - для Dr.Web Ничего для Вас не жалко

Процент для чего?

[Anton Ivanov]

хм - да, что-то в духе logrotate не помешает

[Andrew Kargalov]

Да, действительно, проблема с логами известна. В версии 5.0.4 (которая будет совсем скоро) количество сообщений уменьшено раз в 10, формат их стал единообразным и более ли менее читаемым. Постараемся в 5.0.5 с логами навести полный порядок. Может быть не просто ротировать по расписанию, а как-то и на размер файлов смотреть тоже.

[Serge3leo]

Уточнение по сути вопроса, как правильно удалять протоколы?

• rm /var/drweb/log/{daemon,fileD}.log #(т.е. если файлы часто переоткрытваются)
• cat /dev/null > /var/drweb/log/daemon.log #(т.е. если файлы открываются на всю жизнь)
• Лучше ничего не трогать, а то "рванёт"

Быть может, есть простые инструкции по оповещению или рестарту демонов, если это необходимо?

Что сказать относительно реализации и философии протоколов:
1. Есть проблемы, например, мне посоветовали обновить 5.0.1 на 5.0.3. Как результат, я получил "бесконечное" заполнение протоколов вида:

sh-3.2# tail -20f /var/drweb/log/fileD.log 
Mon May 10 23:20:36 2010	read error, after scanning/curing composite object is clean
Mon May 10 23:20:36 2010	Scanning error : 1

Mon May 10 23:20:36 2010	file /private/var/drweb/run/drwebd.bsy.91205	type = 0	 action = 0
Mon May 10 23:20:36 2010	[91281] drwebd.bsy.91208 - cannot get file attributes with error: No such file or directory
[91281] drwebd.bsy.91208 - read error!

Mon May 10 23:20:36 2010	read error, after scanning/curing composite object is clean
Mon May 10 23:20:36 2010	Scanning error : 1

Mon May 10 23:20:36 2010	file /private/var/drweb/run/drwebd.bsy.91208	type = 0	 action = 0
Mon May 10 23:20:36 2010	[91282] drwebd.bsy.91209 - cannot get file attributes with error: No such file or directory
[91282] drwebd.bsy.91209 - read error!

Mon May 10 23:20:36 2010	read error, after scanning/curing composite object is clean
Mon May 10 23:20:36 2010	Scanning error : 1

Mon May 10 23:20:36 2010	file /private/var/drweb/run/drwebd.bsy.91209	type = 0	 action = 0
Mon May 10 23:20:36 2010	[91283] drwebd.bsy.91210 - cannot get file attributes with error: No such file or directory
[91283] drwebd.bsy.91210 - read error!

2. На них установлены странные права, к примеру:

sh-3.2# ls -la /var/drweb/log/
total 438152
drwxrwxrwx  8 root  wheel		272 10 май 22:40 .
drwxr-xr-x  9 root  wheel		306 10 май 22:40 ..
-rw-r--r--  1 root  wheel		457 10 май 23:20 FileD-err.log
-rw-r--r--  1 root  wheel		  0 10 май 22:40 FileD-out.log
-rw-r--r--  1 root  wheel		458 10 май 22:41 UpdateD.log
-rw-------  1 root  wheel   64020810 10 май 23:20 daemon.log
-rw-r--r--  1 root  wheel  160299050 10 май 23:20 fileD.log
-rw-r--r--  1 root  wheel		  0 10 май 22:40 monitor.hist

Лично мне непонятно, зачем усложнять чтение 'daemon.log' для пользователей, если любой пользователь ОС может его подменить (см. права на каталог)?

И вообще, оно чем-то обосновано, что просмотр протокола возможен только командой "sudo tail /var/drweb/log/daemon.log" (неужели по вашему меннию, каждое чтение этого протокола должно сопровождаться аудитом в "/var/log/secure.log")? Например, если Вы взглянете на '/var/log', то системные протоколы имеют разрешение чтения, либо для администраторов (группа admin), либо для всех (644). По мне так последнее предпочтительнее.

3. А оно надо повторять реализацию поддержки протоколов системы? Быть может, возможно использовать стандартные протоколы Mac OS X?

[Andrew Kargalov]

Про варианты удаления: все они приемлемы. После варианта 1 нужна перезагрузка. Вариант 2 не слишком красив, но годится. Против третьего тоже возразить сложно...

Проблема, описанная в п.1, решена в 5.0.4. Файла fileD.log вообще нет с этой версии, а SpiderGuard гораздо разумнее ведёт себя на старте и при отказах других компонентов (ну во всяком случае так задумывалось . Если что-то обнаружите такое же странное в новой версии -- пишите обязательно -- исправим. Только перезагружайтесь, пожалуйста, по просьбе инсталлятора или деинсталлятора.

О правах на файлы логов (п.2) -- согласен на столько, что уже с версии 5.0.2 права на все логи, кроме daemon.log одинаковы и позволяют любому пользователю читать их. Урезанные права на daemon.log унаследованы от родственной unix-линейки нашего антивируса. Если не возникнет серьёзных соображений так не делать в Maс OS X, с 5.0.5 daemon.log будет подчиняться общему правилу.

По п.3 мы тоже немного думали, перед тем как принять решение. Использование ASL (или syslog, если смотреть со стороны POSIX-интерфейсов) имеет свои плюсы и свои минусы для нас. Пока выглядит целесообразнее иметь хлопоты с файлами в отдельном каталоге. Возможно, когда поддержка старых версий Mac OS X станет не нужной, от этого каталога с логами откажемся.

[Serge3leo]

Про варианты удаления: все они приемлемы. После варианта 1 нужна перезагрузка. Вариант 2 не слишком красив, но годится. Против третьего тоже возразить сложно...

Спасибо.

Урезанные права на daemon.log унаследованы от родственной unix-линейки нашего антивируса. Если не возникнет серьёзных соображений так не делать в Maс OS X, с 5.0.5 daemon.log будет подчиняться общему правилу.

Как Вы знаете, в отличии от традиционных Unix в Mac OS X пользователь root отсутствует, как субъект. Это с одной стороны. С другой стороны, в отличии от "неустоявшихся" Linux, все администраторы системы входят в группу 'admin' (в т.ч. администраторы из Active Directory, если включена соответствующая галка). И с третьей стороны, системные протоколы для которых "урезаны права", такие как /var/log/secure.log, /var/log/ppp.log, /var/log/appfirewall.log и т.п. имеют права 640 для root:admin. http://developer.apple.com/mac/library/doc...Influences.html. Являются ли эти три соображения серьёзными? Кто знает?

Но, лично меня смущают права на '/var/drweb/log' - 777 root:wheel, IMHO - это большой пробел в системе безопасности системы в целом (в частности, сейчас любой пользователь или вирус может удалить daemon.log), ну если вам так надо, что бы пользователи там могли создавать протоколы поставьте хотя бы права 1777, как у каталога /tmp на всех Unix (или POSIX 1e ACL, их то же почти все поддерживают).

По п.3 мы тоже немного думали, перед тем как принять решение. Использование ASL (или syslog, если смотреть со стороны POSIX-интерфейсов) имеет свои плюсы и свои минусы для нас. Пока выглядит целесообразнее иметь хлопоты с файлами в отдельном каталоге. Возможно, когда поддержка старых версий Mac OS X станет не нужной, от этого каталога с логами откажемся.

Дело ваше, лишь бы не глючило. Хотя, строго говоря, есть ещё один, промежуточный, вариант: разместить файлы протоколов в '/Library/Logs/DrWeb' согласно http://developer.apple.com/mac/library/doc...PFileSystem.pdf. А пртоколы пользователя в '~/Library/Logs/DrWeb'.

P.S.

А тому, кто желает читать протокол daemon.log, есть обход этой проблемы:

• rm /var/drweb/log/daemon.log ; touch /var/drweb/log/daemon.log #(пользователь может быть любой, необязательно член группы администраторов);
• При рестарте, DrWeb исправит владельца и группу файла, но права доступа не восстановит;

P.P.S.

Обход проблемы переполнения диска протоколами:

• rm /var/drweb/log/* #(или слишком большие, под любым пользователем);
• Желательна перезагрузка;

Сообщение было изменено Serge3leo: 12 Май 2010 - 11:38

[Serge3leo]

P.P.S.

Обход проблемы переполнения диска протоколами:

• rm /var/drweb/log/* #(или слишком большие, под любым пользователем);
• Желательна перезагрузка;

Я себе сделал файлик для newsyslog (кодировка UTF-8), на всякий случай, что б до гигабайтов не доходил.

Прикрепленные файлы:

•  drweb.newsyslog.txt   3,59К   91 Скачано раз