Здравствуйте, уважаемые читатели моего блога!
Сегодня я поделюсь одним интересным случаем диагностики проблем в Astra Linux SE 1.6, с которым я столкнулся на днях.
Утром мне позвонил товарищ и сообщил, что возникла внештатная ситуация в работе почтового сервера — из симптомов — Thunderbird на всех компьютерах соединяется с местным почтовым сервером около двух-трёх минут.
Что стоит отметить — данная проблема проявлялась только на мандатных уровнях выше 0 (несекретно).
Пикантности ситуации добавляло то, что почтовый сервер на Astra Linux SE 1.6 был введён в эксплуатацию около недели назад (до этого эксплуатировался Astra Linux SE 1.5), и администратор чувствовал себя не слишком уверенно.
Я решил отложить дела и оказать помощь. Подключился по ssh и начал изучать систему. Дополнительно мне сообщили, что крайним действием на почтовом сервере была установка антивируса drweb — его на всякий случай удалили, но проблема не решилась.
Посмотрел .bash_history — крайними были команды диагностики (ping, top, df), также проверялись логи exim и dovecot. Далее я обнаружил запуск скрипта установки антивируса с говорящим названием install.sh.
Лично я не слишком приветствую установку с использованием чужих скриптов, если они не от производителя программного обеспечения — конкретно этот скрипт был не от производителя (прислали из другого филиала).
Если уж использовать чужой скрипт, желательно ознакомиться с его содержимым, чтобы потом не удивляться куче изменений, произведённых в тайне от администратора (и это если скрипт сделан без ошибок).
Я же посмотрел журнал exim, в котором обнаружил целую кучу сообщений, не отправленных ещё с предыдущего дня — налицо была проблема с DNS. Посмотрел /var/spool/exim — всё верно, очередь из сообщений и невозможность отправки (невозможность разрешения доменных имён).
Проверил работу DNS — всё в норме, через telnet проверил доступность удалённых почтовых серверов (подключаясь на 25 порт) — всё работает.
«Но причём же здесь уровни выше нуля?», — подумал я. На всякий случай посмотрел каталог /var/mail и обратил внимание на наличие мандатных меток — всё в наличии.
Дело становилось запутаннее. Решил проверить /etc/parsec/privsock.conf и не прогадал. Моему взору предстало это (в абсолютном пути к антивирусу могу ошибаться, но это и не важно):
/usr/bin/fly-dm
/usr/bin/nscd
/usr/bin/nslcd
/usr/sbin/named/opt/drweb.com/bin/drweb-configd
/opt/drweb.com/bin/drweb-configd.realЧто же мы тут видим?
А видим мы последствие скверной привычки не оставлять пустую строку после внесения изменений в конфигурационные файлы (последняя строка не завершилась управляющим символом разделителя строк \n).
Скрипт, честно отработав, внёс в файл /etc/parsec/privsock.conf две строки (для работы антивируса необходимо обеспечить возможность его работы с клиентами, имеющими разный мандатный контекст безопасности), но так как файл заканчивался на строке /usr/sbin/named (а не на пустой строке) — строка /opt/drweb.com/bin/drweb-configd дополнила абсолютный путь к named.
Таким образом DNS сервер лишился своих привилегий (а антивирус таковых не обрёл, но это никого не волновало, так как появились проблемы посерьёзнее :)).
Фактически почта не стала работать медленнее, она перестала работать вообще, собирая письма, но не доставляя их адресатам.
Привёл файл к нормальному виду:
/usr/bin/fly-dm
/usr/bin/nscd
/usr/bin/nslcd
/usr/sbin/named
/opt/drweb.com/bin/drweb-configd
/opt/drweb.com/bin/drweb-configd.realПерезагрузил сервер, и всё заработало — проблемы исчезли.
Внёс изменение в конфигурационный файл exim, а точнее, в правила повтора отправки сообщений — чтобы exim сдавался и сообщал о неудачах быстрее (по умолчанию пытается отправлять почту до последнего и молчит «как партизан»).
На этом завершил настройку и получил своё «большое спасибо».
Всем хорошего дня и до новых встреч.