Поменял переменную ядра:
~> sudo sysctl vfs.usermount=1

Прописал то же самое в /etc/sysctl.conf:
vfs.usermount=1

В файле /etc/rc.conf дописал:
devfs_system_ruleset="localrules"

Создал файл /etc/devfs.rules:
[localrules=10]
add path 'da*' mode 0660 group wheel
Таким образом поменял для всех устройств, начинающихся с «da», группу на wheel и дал права на чтение и запись для владельца и группы. По-умолчанию указана группа operator, в которую я не вхожу.

Посмотрел какие права на устройстве в данный момент:
~> ls -l /dev/da0*
crw-r----- 1 root operator 0, 138 Mar 31 16:15 /dev/da0
crw-r----- 1 root operator 0, 139 Mar 31 16:15 /dev/da0s1

Переконфигурировал устройства:
~> sudo /etc/rc.d/devfs restart

Убедился, что права и группа изменились в нужную сторону:
~> ls -l /dev/da0*
crw-rw---- 1 root wheel 0, 138 Mar 31 16:15 /dev/da0
crw-rw---- 1 root wheel 0, 139 Mar 31 16:15 /dev/da0s1

Теперь надо назначить себя владельцем точки монтирования:
~> sudo chown malik:wheel /mnt/flash
Ну или, если угодно, создать свою точку монтирования:
~> mkdir ~/flash

Кстати, для монтирования CD-ROM от имени пользователя достаточно чтобы точка монтирования принадлежала этому самому пользователю, т.к. писать на CD-ROM стандартным средствами системы мы не собираемся )

И, наконец, монтирую флешку:
~> mount_msdosfs /dev/da0s1 /mnt/flash

Всё нормально – флешка подмонтирована и можно нормально работать с файлам и папками от имени пользователя, не прибегаю к правам рута.

Замечание:
Монтирование флешки с указание локальной кодировки от имени обычного пользователя возможно только после хотя бы одного монтирования из-под суперпользователя:
~> mount_msdosfs -L ru_RU.KOI8-R /dev/da0s1 /mnt/flash
mount_msdosfs: cannot find or load "msdosfs_iconv" kernel module
mount_msdosfs: msdosfs_iconv: Operation not permitted
~> sudo mount_msdosfs -L ru_RU.KOI8-R /dev/da0s1 /mnt/flash
Password:
~> sudo umount /mnt/flash
~> mount_msdosfs -L ru_RU.KOI8-R /dev/da0s1 /mnt/flash
~>


SORRY. NO SPACE IN lost+found DIRECTORY

Дело в не свободном объёме в этом разделе, а в свободных дескрипторах файлов. Для увеличения их количества принудительно подмонтируем раздел, создаём в папке «lost+found» создаём кучу файлов, удаляем их, отмонтируем раздел и снова натравливаем на него fsck:

# mount -f /dev/ad0s1f /mnt
# i=1; while [ $i -lt 10000 ]; \
 do touch /mnt/lost+found/xxx.$i; i=`expr $i + 1`;done
# rm /mnt/lost+found/xxx.*
# umount /mnt
# fsck -y /dev/ad0s1f

20070425

May  5 14:32:12  kernel: CPU: AMD-K6(tm) 3D processor (400.12-MHz 586-class CPU)
May  5 14:32:12  kernel: Origin = "AuthenticAMD"  Id = 0x58c  Stepping = 12
May  5 14:32:12  kernel: Features=0x8021bf
May  5 14:32:12  kernel: AMD Features=0x80000800

Проблема достаточно явная, но как она влияет на работу системы мне не известно – на консоль постоянно валятся вот такие ошибки:

May  5 15:22:25  kernel: calcru: negative time of -1360420 usec for pid 12137 (cc)

Поиски по Гуглу дали очень много упоминаний подобной проблемы и ниодного внятного решения для системы старше 5-й версии. Решение для младших версий не подошло, зато оно подтолкнуло меня к следующим действиям.

После некоторых раздумий я решил посмотреть переменные ядра (или как они правильно называются?) с подходящими названиями. Наиболее подходящими оказались переменные kern.timecounter.*, а среди них вот такие:

# sysctl -a | grep timecounter
...
kern.timecounter.hardware: ACPI-safe
kern.timecounter.choice: TSC(800) ACPI-safe(1000) i8254(0) dummy(-1000000)
...

На другой машине с такой же системой значение переменной kern.timecounter.hardware имело значение TSC, какое и было выставлено на данной проблемной машине:

sysctl kern.timecounter.hardware=TSC

Насколько я могу судить проблема устранилась.

Осталось только прописать новое значение упомянутой переменной в файл /etc/sysctl.conf, чтобы оно снова было выставлено после перезагрузки системы:

# tail /etc/sysctl.conf
kern.timecounter.hardware=TSC

Скачиваем с сайта www.drweb.ru дистрибутив антивируса.
Дистрибутивы версии, которую использовал я, можете скачать из моего архива:
drweb-4.28.1-freebsd4.tgz (1,4Мб)
а также фильтр drweb-smf для сендмейла:
drweb-sendmail-4.28.3-freebsd4.tgz (200Кб)

Схема проверки почты достаточно проста и понятна. Если объяснять своими (моими словами, то получается примерно так – сендмейл, получив сообщение, передаёт его фильтру drweb-smf, который, обращаясь к демону
drwebd, проверяет сообщение, если демон не находит в нём вирус, то сообщение попадает к адресату, если же в сообщении найден вирус, то фильтр, в зависимости от настроек, помещает в карантин и рассылает уведомления отправителю, получателю и администратору.

Установка и настройка сканера и демона DrWeb

Во-первых хочу отметить, что для всего есть очень даже приличные описания как на английском, так и на русском языках. Так что особых проблем у меня не возникло.

Распаковываем файл drweb-4.28.1-freebsd4.tgz и видим дерево каталогов:
etc
opt
usr
var

Раскладываем всё куда положено, и получается вот что:
/etc/drweb – конфиги демона и фильтра;
/usr/local/drweb – бинарники и дока;
/usr/local/etc/rc.d – скрипт запуска демона drwebd;
/var/drweb – временные файлы, спул, сокеты.

Правим в файле /etc/drweb/drweb32.ini некоторые ключики, связанные с путями размещения компонентов антивируса:

[BSD]
EnginePath = "/usr/local/drweb/lib/drweb32.dll"
Key = "/usr/local/drweb/drweb.key"
UpdatePath = "/var/drweb/bases"
[BSD:Daemon]
EnginePath = "/usr/local/drweb/lib/drweb32.dll"
Key = "/usr/local/drweb/drwebd.key"
UpdatePath = "/var/drweb/bases"

Демон может взаимодействовать с фильтром через TCP/IP соединение, например, если демон и фильтр работают на разных машинах. В случае же если и демон и фильтр установлены на одном копьютере, то им лучше взаимодействовать через локальный UNIX-сокет (зачем нам лишний открытый порт). Для этого нам нужно
внести несколько исправлений в конфиг /etc/drweb/drweb32.ini в раздел демона:

[BSD:Daemon]
;SocketMode = TCP (закомментировали)
;DaemonPort = 3000 (закомментировали)
SocketFile = "/var/drweb/run/drwebd.socket"
SocketMode = Unix
SocketAccess 0666

Также хотелось бы, чтобы демон работал не от имени рута, а от имени пользователя drweb, для чего, в том же /etc/drweb/drweb32.ini исправляем ключик:

User = drweb

Ну и, конечно же, должен быть создан указанный пользователь, лучше в поле пароля задать ему «*», чтобы никто не смог использовать этот логин для других целей, также папка /var/drweb должна принадлежать этому пользователю.

Теперь попробуем обновить антивирусные базы. Для этого есть скрипт /usr/local/drweb/update/update.pl. Почему он у меня сразу работать не захотел, ругался вот так:

mv: rename /tmp/drw42805.vdb0.957098969258368 to
 /var/drweb/bases/*.vdb,/var/drweb/bases/drw42805.vdb: No such file or directory

Оказалось, что неверно описаны пути к базам, исправил:

# grep update /etc/drweb/*
drweb32.ini:UpdatePath = "/var/drweb/updates"
drweb32.ini:UpdatePath = "/var/drweb/updates"

Создал указанную папку. После этого обновление работает без ошибок.

Для проверки можем запустить сканер (/usr/local/drweb/drweb), если всё нормально, то он должен сказать что-то типа этого:

Key file: /usr/local/drweb/drweb.key
Registration info:
0100003942
Evaluation Key (ID Anti-Virus Lab. Ltd, St.Petersburg)
This is an EVALUATION version with limited functionality!
To get your registration key, call regional dealer.
Loading /var/drweb/bases/drwtoday.vdb - Ok, virus records: 117
Loading /var/drweb/bases/drw42804.vdb - Ok, virus records: 123
Loading /var/drweb/bases/drw42803.vdb - Ok, virus records: 73
Loading /var/drweb/bases/drw42802.vdb - Ok, virus records: 143
Loading /var/drweb/bases/drw42801.vdb - Ok, virus records: 76
Loading /var/drweb/bases/drwebase.vdb - Ok, virus records: 29405

Отлично! Попробуем подсунуть сканеру какой-нибудь вирус. Для этого лучше использовать специальный тестовый якобы_вирус Почитайте описание этого тестового вируса в файле /usr/local/drweb/doc/readme.eicar

Скопируйте оттуда строку:

X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*

в отдельный файл, например, test.com. Этот файл и будем проверять сканером:

/usr/local/drweb/drweb test.com

В отчёте сканера должна быть строчка:

...
/usr/local/drweb/test.com infected with EICAR Test File (NOT a Virus!)
...

Ура! Сканер работает и находит вирусы.

Если я не ошибаюсь, сканер в проверке почты никак не участвует. Нас больше интересует демон drwebd. Запускаем его:

/usr/local/etc/rc.d/drwebd.sh start

Если демон нормально запустился, то в папке /usr/var/drweb/run должен быть создан сокет (специальный файл) drwebd.socket, а также отчитаться в логи:

...
Daemon is installed, UNIX socket created in file /var/drweb/run/drwebd.socket

Метод вывода логов задаётся в конфиге /etc/drweb/drweb32.ini. По-умолчанию, логи передаюся syslog-демону с типом Daemon:

SyslogFacility = "Daemon"

В документации сказано, что проверить работу демона можно с помощью клиента drwebc, который прилагается в дистрибутиве. Но, судя по всему, это не относится к данному дистрибутиву, т.к. такой программы я не нашёл. Есть правда программа /usr/local/drweb/clients/demo/drwebdc-demo, но разобраться с ней оказалось сложнее чем настроить непосредственно фильтр drweb-smf.

Установка и настройка фильтра drweb-smf

Распаковываем файл drweb-sendmail-4.28.3-freebsd4.tgz, видим две папки etc и opt. Делаем то же, что и для сканера и демона, т.е. перекладываем etc/drweb в /etc/drweb, а opt/drweb /usr/local/drweb.

Поправляем конфиг фильтра /etc/drweb/drweb_smf.conf (описание на русском языке прилагается в дистрибутиве):

[DaemonCommunication]
Address = local:/var/drweb/run/drwebd.socket

[SendmailCommunication]
Address = local:/var/drweb/run/drweb-smf.sock

[Actions]
ScanningErrors = tempfail
ProcessingErrors = tempfail

[NotificationOptions]
NotifyHashSalt = !!!Chtob_nikto_ne_dogodalsya!!!

[VirusNotifications]
SenderNotify = no

Обязательно нужно исправить первые два ключа Address. Последний ключ я выставляю в no, т.к. не считаю нужным отсылать уведомление о вирусе отправителю, т.к. мне кажется, что чаще всего обратный адрес указан фальсифицированный и лишняя нагрузка на почтовый сервер будет напрасной.

Также по умолчанию параметр ScanningErrors установлен в reject – в случае ошибок сканирования отвергать все сообщения, т.е. сообщения вернутся с ошибкой, мне кажется лучше поставить значение tempfail – временная недоступность, почтовая система будет пытаться отправить сообщение позже. Примерно то же самое относится в параметру ProcessingErrors.

Интересная, и неожиданная для меня, возможность задания списка исключений для фильтра (/etc/drweb/users.conf), т.е. вы можете указать для каких адресов проверять сообщения, а для каких не проверять. Пример файла
/etc/drweb/users.conf:

[version=2]
# не проверять входящую почту для этих адресов:
deny     to   subst     malik@mydomain.kg
deny     to   subst     igor@mydomain.kg
# для остальных проверять входящую почту:
allow    to   regex     .*

В данном случае получается, что фильтр должен проверять почту только для пользователей igor@myhost.kg и malik@myhost.kg, а почту для остальных адресов домена не проверять.

Об угловых скобках. В примерах из поставки адреса указаны без угловых скобок, но у меня точное соответствие (exact) без них никак не получалось. А вот с угловыми скобками всё отлично работает, но всё равно надёжнее указывать не точное соответствие exact, а поиск подстроки subst.

ВАЖНО!!! Однажды очень долго боролся с этими списками, пока не задал вопрос на форуме производителя DrWeb-а (спасибо Sergey Akhapkin). Короче говоря, при использовании этих списков необходимо проверить значение параметра DenyMode в конфиге почтового фильтра (drweb_smf.conf) и выставить подходящее значение.

В конце концов, запускаем фильтр (демон должен быть уже запущен) и проверяем наличие в процессах демона и фильтра:
ps xa|grep drweb

Перекомпиляция сендмейла с поддержкой milter-а

Для работы drweb-фильтра необходим сендмейл, скомпилированный с поддержкой milter-а. К сожалению, сендмейл на моей машине оказался без оной. Ну раз уж нужно перекомпилировать сендмейл скачаю последнюю версию: sendmail.8.12.3.tar.gz (1,8Мб)

Компилирую и устанавливаю сендмейл с поддержкой milter-а (все пути даются относительно папки с дисрибутивом):
- дописываю в файл devtools/Site/site.config.m4 (если такого файла нет, то
создаём):

 APPENDDEF(`conf_sendmail_ENVDEF', `-DMILTER')

- в папке libmilter говорим

 Build
 Build install

- в папке дистрибутива sendmail запускаю:

 Build -c
 Build install

Готово – скомпилировали и установили. Про стандартную настройку сендмейла не говорю, это должен знать каждый (кто взялся за установку антивируса
В моём случае, предыдущая версия сендмейла не отличалась от новой по настройкам, поэтому ничего менять не пришлось.
Запускаю и проверяю работоспособность моей почтовой системы – 25-й порт слушает, почту получает/отправляет, логи пишет – красота

Правим sendmail.cf

Чтобы сообщения передавалиь фильтру drweb-smf нужно внести некоторые изменения в конфиг сендсейла. Считается, что правильнее внесить изменения в sendmail.cf при помощи m4, но в данном случае мне этот метод показался слишком громоздким и длинным (да простят меня знатоки сенмейла Я просто, как описано в документации к фильтру, добавил несколько строк в существующий sendmail.cf:

# Input mail filters
O InputMailFilters=drweb-filter

O Milter.LogLevel=6
O Milter.macros.envfrom=i

Xdrweb-filter,  S=local:/var/drweb/run/drweb-smf.sock, F=T,T=S:5m;R:5m;E:1h

Говорим сендмейлу о необходимости перечитать свой конфиг:

kill -HUP `head -1 /var/run/sendmail.pid`

Смотрим логи сендмейла /var/log/maillog и, если всё нормально, пробуем послать сообщение с вложенным тестовым вирусом. Если возникают какие-либо проблемы – внимательно читайте логи. Можно увеличить уровень логирования в sendmail.cf:

O Milter.LogLevel=14

А также изменить в конфиге фильтра /etc/drweb/drweb_smf.conf значение параметра в секции [Logging]:

Level = Verbose

Запуск

Теперь необходимо запускать демон и фильтр при загрузке системы.
Правильнее для этого поместить скрипт в папку /usr/local/etc/rc.d При этом скрипт обязательно должен понимать ключи start и stop, и иметь расширение ‘sh’.

Учтите также, что если работа завершилась неправильно (например, комьютер перезагрузился из-за скачка напряжения), то сохранившийся сокет фильтра (/var/drweb/run/drweb-smf.sock) не позволит ему запуститься в следующий раз.

У меня получился вот такой скрипт:

#!/bin/sh

RETVAL=0
case "$1" in
    start)
        echo -n "Starting Dr. Web daemon..."
        /usr/local/drweb/drwebd
        rm /var/drweb/run/drweb-smf.sock
        /usr/local/drweb/drweb-smf
    ;;
    stop)
        echo -n "Shutting down Dr. Web daemon..."
        kill -TERM `cat /var/drweb/run/drwebd.pid | head -1`
        killall -TERM drweb-smf
    ;;
    *)
    echo "Usage: $0 {start|stop}"
    RETVAL=1
esac
exit $RETVAL

Для полного счастья осталось только регулярно запускать скрипт обновления, например, из папок /etc/periodic/daily или /etc/periodic/weekly

Ну вот вроде и всё.

Май 2002.