Обновления Zimbra из России: freshclam, зеркала и лицензии

В понедельник 12 сентября 2022 года мне позвонили из проектного бюро в Химках — 24 рабочих места, конструкторы и ГИПы. Жалоба звучала так: «письма как будто уходят, а до заказчика не доходят, и так уже несколько дней». В очереди стояло 1 240 сообщений, самые старые — пятидневной давности, и часть из них уже начала возвращаться отправителям. Первую версию причины я отработал впустую, а настоящая оказалась в логе, куда никто не заглядывает.

Есть отказы, которые видно сразу: сервер лежит, веб-почта не открывается, все звонят одновременно. С ними просто. Звонок, диагноз, работа.

А есть вот такие. Почтовый клиент показывает письмо в «Отправленных». Ошибки нет. Пользователь уверен, что отправил. Получатель уверен, что ему не писали. Между ними — очередь, о существовании которой ни тот, ни другой не подозревает.

Обнаруживается это обычно через несколько дней и всегда через конфликт: заказчик спрашивает, где обещанный документ, а у вас на руках скриншот отправленного письма. Дальше выясняется неприятное — почта стояла всё это время, а самые старые сообщения уже вернулись отправителям как недоставленные, потому что почтовый сервер по умолчанию держит письмо в очереди пять суток и потом сдаётся.

Причин у зависшей очереди штук десять. Я разберу ту, которая в России встречается непропорционально часто и которая почти никогда не приходит людям в голову: сервер не может обновить базы антивируса, антивирус считается просроченным, и проверяющее звено отказывается пропускать почту. Всю почту. Не заражённую — всю.

Дальше — конкретный случай, моя неверная первая версия и то, как это чинится без переезда на другую платформу.

Проектное бюро: промышленное проектирование, 24 человека, из них полтора десятка — конструкторы и главные инженеры проектов. Офис в бизнес-центре у Ленинградского шоссе. Почта своя с 2019 года, ставили под требование заказчика хранить переписку по объектам у себя.

Позвонил ГИП, не админ — админа у них не было вовсе, приходил парень по договору раз в месяц. Формулировка была: «неделю не можем согласовать раздел, заказчик говорит, что писем не получал».

Первые команды:

$ su - zimbra -c 'zmcontrol -v'
Release 8.8.15_GA_3869.UBUNTU18_64_20190917010745 UBUNTU18_64 FOSS edition, Patch 8.8.15_P26.

$ su - zimbra -c 'zmcontrol status' | head -8
Host mail.example.ru
	amavis                  Running
	antispam                Running
	antivirus               Running
	ldap                    Running
	mailbox                 Running
	mta                     Running
	proxy                   Running

$ su - zimbra -c 'postqueue -p' | tail -1
-- 190847 Kbytes in 1240 Requests.

$ su - zimbra -c 'zmprov -l gaa' | wc -l
29

Вот что сбивает с толку сильнее всего: zmcontrol status показывает всё зелёным. Службы запущены, процессы живы, ничего не упало. Антивирус в статусе Running. Он и правда запущен — он просто отказывается делать свою работу.

1 240 писем, 186 мегабайт. Самое старое — от 7 сентября. Пять суток. То есть первые письма из очереди уже уходили обратно отправителям с отбойником, и часть сотрудников это видела, но списала на «заказчик что-то настроил у себя».

Двадцать девять ящиков на двадцать четыре человека, 180 гигабайт хранилища. Небольшая, аккуратная инсталляция, которую никто три года не трогал, потому что она работала.

Зависшая очередь у меня рефлекторно связывается с разрешением имён. Это самая частая причина: почтовый сервер лезет узнать, куда доставлять письмо, упирается в таймаут резолвера и складывает сообщение обратно в очередь. Симптом ровно такой же — письма стоят, ошибок толком нет, при ручной попытке доставки часть уходит.

Я честно отработал эту версию:

$ cat /etc/resolv.conf
nameserver 192.168.20.1
nameserver 8.8.8.8

$ dig +short MX zakazchik-domain.ru
10 mx1.zakazchik-domain.ru.

$ dig +short mx1.zakazchik-domain.ru
95.163.xx.xx

$ time dig +short MX mail.ru
...
real	0m0.041s

Резолвер отвечал за сорок миллисекунд. MX-записи получателей разрешались корректно. Разделения зон, при котором почта уходит наружу и пытается вернуться тем же путём, тоже не было — проверил.

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

$ grep 'status=deferred' /var/log/zimbra.log | tail -2
postfix/smtp[24417]: 8F2A1C0E12: to=<gip@zakazchik-domain.ru>, relay=127.0.0.1[127.0.0.1]:10024,
 delay=418302, delays=418301/0.02/0.03/0, dsn=4.5.0,
 status=deferred (host 127.0.0.1[127.0.0.1] said: 451 4.5.0 Error in processing,
 id=24417-08, virus_scan FAILED: Too many retries to talk to scanner)

$ grep -i 'ClamAV-clamd' /var/log/zimbra.log | tail -1
amavis[3311]: (03311-06) (!)ClamAV-clamd av-scanner FAILED: run_av error: too many retries

Обратите внимание на relay=127.0.0.1:10024. Письмо даже не пыталось уйти наружу. Оно застревало внутри, на переходе в проверяющее звено, и ни к какому DNS отношения не имело.

Полдня псу под хвост. Полдня на неверную версию. Обидно, но урок повторяемый: при зависшей очереди первым делом смотрите, на каком relay стоит запись status=deferred. Если там адрес обратной петли — проблема внутри сервера, и наружу можно не смотреть вовсе.

Дальше цепочка разматывается за пять минут.

$ ls -l /opt/zimbra/data/clamav/db/
-rw-r----- 1 zimbra zimbra 170274560 мар  3  2022 main.cvd
-rw-r----- 1 zimbra zimbra  57531904 мар  3  2022 daily.cld
-rw-r----- 1 zimbra zimbra    289231 мар  3  2022 bytecode.cvd

$ tail -8 /opt/zimbra/log/freshclam.log
ClamAV update process started at Mon Sep 12 08:02:14 2022
WARNING: Can't query current.cvd.clamav.net
WARNING: Invalid DNS reply. Falling back to HTTP mode.
Trying host database.clamav.net...
WARNING: Can't download daily.cvd from database.clamav.net
ERROR: Can't download daily.cvd from database.clamav.net
Giving up on database.clamav.net...
ERROR: Update failed. Your network may be down or none of the mirrors listed in /opt/zimbra/conf/freshclam.conf is working.

Базы от 3 марта 2022 года. Полгода.

Шесть месяцев подряд сервер каждые два часа стучался за обновлениями, каждые два часа получал отказ, аккуратно записывал это в файл, который никто ни разу не открыл, и продолжал работать так, будто ничего не происходит — ровно до того дня, когда антивирусный демон перестал отвечать проверяющему звену. Механика тут прозаичнее «внутреннего порога»: движок в какой-то момент отказался грузить полугодовалый набор сигнатур, сокет перестал отдавать вердикт, и проверка встала намертво.

И этот блок в логе повторялся каждые два часа, ровно по расписанию — потому что именно с такой периодичностью сервер по умолчанию ходит за обновлениями сигнатур. Проверяется одной командой:

$ su - zimbra -c 'zmprov gcf zimbraVirusDefinitionsUpdateFrequency'
zimbraVirusDefinitionsUpdateFrequency: 2h

Двенадцать неудачных попыток в сутки, полгода подряд. Никто ни разу не открыл этот файл, потому что почта до сентября всё-таки ходила — антивирус переходил в состояние «база устарела» не мгновенно, а по мере накопления расхождения версий.

Причина, по которой базы не тянулись, для российской инсталляции обыденная: обновление сигнатур упирается в ограничения по адресам, с которых идут запросы. Сервер бюро смотрел в интернет прямым белым адресом российского провайдера, и с него загрузка не проходила. Ни у кого не спрашивали, ничего не сообщали — просто не отдавали файл.

Ключевая мысль, ради которой я эту статью и пишу: просроченный антивирус не «перестаёт ловить вирусы». Он останавливает всю почту. Проверяющее звено считает, что не может выполнить проверку, и честно откладывает сообщение. Отложенные копятся, через пять суток начинают возвращаться. Бизнес при этом уверен, что у него всё работает, потому что сервер зелёный.

Четыре команды. Ничего не меняют, выполняются на живом сервере.

su - zimbra -c 'postqueue -p' | tail -1
ls -l /opt/zimbra/data/clamav/db/
tail -12 /opt/zimbra/log/freshclam.log
su - zimbra -c 'zmprov gcf zimbraVirusDefinitionsUpdateFrequency'

Трактовка:

Отдельно про zmcontrol status. Он в этой ситуации бесполезен и даже вреден: показывает antivirus Running, и человек успокаивается. Служба действительно запущена. Работать она отказывается по другой причине, и статус про это ничего не знает.

Если у вас сервер в России и вы никогда не открывали freshclam.log — откройте прямо сейчас. Это буквально одна команда, и по моему опыту примерно в трети инсталляций там ровно та же картина, просто очередь ещё не переполнилась.

Две задачи, и путать их нельзя. Сначала разморозить почту, потом чинить источник обновлений. Наоборот не выйдет — на настройку зеркала уходят часы, а письма стоят.

Шаг 1: разморозить очередь

Проверку временно снимаем и прогоняем очередь:

# снять антивирусную проверку на время работ
su - zimbra -c 'zmprov ms $(zmhostname) -zimbraServiceEnabled antivirus'
su - zimbra -c 'zmmtactl restart'

# прогнать накопившееся
su - zimbra -c 'postqueue -f'
su - zimbra -c 'postqueue -p' | tail -1

Здесь я обязан сказать неприятное. Есть популярный совет, который встречается в каждом втором обсуждении: «выключите антивирус, и всё поедет». Он работает и он вредный — потому что выключенным антивирус остаётся навсегда. Я видел серверы, где его так выключили в 2020 году и с тех пор не вспоминали. Ставьте себе срок возврата в тот же день, когда выключаете. У меня это было 16 сентября, записано в задачу.

Шаг 2: починить источник обновлений

Рабочих подхода два.

Сменить источник в конфигурации. Файл /opt/zimbra/conf/freshclam.conf, директивы DatabaseMirror либо PrivateMirror. Второй вариант надёжнее: вы поднимаете внутри своей сети машину, которая тянет базы доступным ей способом и раздаёт их почтовому серверу по HTTP. Это две разные конфигурации, а не набор строк, которые можно сложить в кучу.

Вариант А — просто сменить источник, оставив штатный механизм обновлений. В freshclam.conf остаётся одна строка:

# вариант А: другой публичный источник, инкрементальные обновления работают
DatabaseMirror mirror.example-cdn.net

Вариант Б — собственное зеркало внутри сети. Здесь строки DatabaseMirror быть не должно вовсе, иначе сервер продолжит ходить на недоступный официальный источник и складывать в лог те же таймауты:

# вариант Б: своё зеркало, инкрементальный режим обязательно выключаем
PrivateMirror http://mirror.internal.example.ru/clamav
ScriptedUpdates off

Смешивать эти два блока в одном конфиге не надо — я видел, как копируют оба разом и потом полдня не понимают, откуда в логе снова Can't download.

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

Шаг 3: вернуть проверку и убедиться

su - zimbra -c 'zmprov ms $(zmhostname) +zimbraServiceEnabled antivirus'
su - zimbra -c 'zmcontrol restart'
ls -l /opt/zimbra/data/clamav/db/
tail -5 /opt/zimbra/log/freshclam.log

Даты файлов должны стать сегодняшними, в логе — daily.cld updated вместо ошибок. Пустая очередь через полчаса после включения — подтверждение, что цепочка собралась.

Здесь я потерял ещё три часа и, признаться, чувствовал себя глупо.

Отредактировал /opt/zimbra/conf/freshclam.conf, прописал своё зеркало, проверил вручную — базы поехали. Обрадовался, включил антивирус обратно, перезапустил службы. Через двадцать минут почта опять встала.

Открываю конфигурацию. Моей правки нет. Файл в исходном виде, будто я ничего и не делал.

Разгадка в том, что этот файл сервер генерирует сам. Рядом лежит шаблон:

$ ls -l /opt/zimbra/conf/freshclam.conf*
-rw-r----- 1 zimbra zimbra  1044 сен 14 16:12 /opt/zimbra/conf/freshclam.conf
-rw-r----- 1 zimbra zimbra   987 сен 17  2019 /opt/zimbra/conf/freshclam.conf.in

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

Это относится не только к антивирусу. По той же схеме генерируется значительная часть конфигурации почтовой подсистемы, и правки «напрямую в конфиг» исчезают одинаково незаметно. Отсюда практическое правило: увидели рядом с файлом такой же с суффиксом .in — правьте шаблон, а сгенерированный файл только читайте.

После правки шаблона перезапуск, проверка, и уже устойчиво.

Базы антивируса — самая заметная часть, потому что она валит почту. Но она не единственная.

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

Если у вас бесплатная редакция, вопроса лицензии нет, зато есть вопрос обновлений самой платформы: где брать дистрибутивы и патчи и насколько устойчиво это будет работать в следующем году.

Практических выходов, которые я вижу у своих клиентов, три:

• Обслуживать имеющуюся установку силами интегратора. Зеркала баз, дистрибутивы, патч-менеджмент и мониторинг свежести берёт на себя тот, у кого это уже налажено. Дешевле всего, ничего не ломает, но остаётся зависимость от чужой инфраструктуры;
• Перейти на Carbonio CE. Тот же фундамент — Postfix, OpenLDAP, Jetty, — та же команда Zextras, живая разработка. Бесплатная редакция, вопрос лицензии снимается целиком;
• Перейти на российский продукт из реестра. Если поверх технической задачи стоит регуляторная или требование заказчика — тогда смотреть CommuniGate Pro, RuPost, Mailion, Tegu, МойОфис Почта. Технически перенос во всех случаях идёт через IMAP.

Бюро в Химках выбрало первый вариант, и я считаю это правильным для их размера. Двадцать четыре человека, 180 гигабайт, работающая инсталляция — переезжать было незачем. Им нужна была не другая платформа, а чтобы кто-то смотрел в freshclam.log.

Хронология была такая:

• 12 сентября, понедельник — заявка, полдня на версию с резолвером, вечером нашёл настоящую причину;
• 13 сентября — снял проверку, прогнал очередь. 1 240 писем ушли за девятнадцать минут. Из них 118 вернулись отбойниками ещё до моего приезда — их пришлось переотправлять руками, силами самих сотрудников;
• 14–15 сентября — зеркало баз, правка шаблона, проверка;
• 16 сентября — вернул антивирусную проверку, база от текущей даты, очередь пустая;
• с октября — свежесть баз попала в ежемесячный чек-ап, отдельным пунктом.

Работы: 12 часов, 48 000 ₽ по ставке 4 000 ₽ в час. Дальше зеркало обслуживается в рамках регламента и отдельных денег не стоит.

А теперь цена молчания. Среди 1 240 застрявших писем были три согласования по разделу проекта. Заказчик их не получил, срок выдачи сорвался, бюро выпустило раздел повторно и отправило ГИПа на объект разбираться лично. Прямые потери — примерно 70 000 ₽ на перевыпуск и командировку. Штраф по договору заказчик выставлять не стал, хотя мог: договор позволял. То есть проблема стоила дороже, чем её решение, и это ещё повезло.

Пять дней. Вот и весь запас — ровно столько письмо ждёт в очереди с того момента, как проверяющее звено отказалось работать, и потом уходит обратно отправителю. Если внутри этого срока никто не открыл лог, дальше начинаются отбойники и разговоры с контрагентами.

Что делать вам: откройте freshclam.log и посмотрите на даты файлов баз. Это одна минута. Если увидели там ошибки загрузки — пришлите мне последние двадцать строк этого лога и вывод postqueue -p | tail -1. Отвечу, сколько у вас времени до того, как встанет почта, и что дешевле в вашем случае: своё зеркало или внешнее. Ответ обычно занимает у меня час, и в половине случаев чинится за один вечер.

Почему почта встала целиком, если просто устарел антивирус?

Потому что проверяющее звено не различает «нет угрозы» и «не смог проверить». Когда антивирусный движок считает базы просроченными, он не отвечает на запрос проверки, и почтовая подсистема получает временную ошибку. Правило при временной ошибке одно: не потерять письмо, положить обратно в очередь и попробовать позже. Позже происходит ровно то же самое. В логе доставки это выглядит как status=deferred с relay=127.0.0.1:10024 и текстом про неудавшуюся проверку. Письма при этом целы, ничего не пропадает — но через пять суток почтовый сервер сдаётся и возвращает их отправителю.

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

Две команды, обе безопасные и ничего не меняют. Первая: ls -l /opt/zimbra/data/clamav/db/ — посмотрите на даты файлов main.cvd и daily.cld. Если им больше месяца, обновления не приходят. Вторая: tail -12 /opt/zimbra/log/freshclam.log — если там повторяются строки Can't download и Update failed, источник недоступен. Заодно проверьте очередь командой postqueue -p | tail -1: последняя строка покажет, сколько сообщений в ней стоит. Пустая очередь при старых базах означает, что вы поймали проблему до того, как она стала видимой — это лучший момент для починки.

Можно просто отключить антивирус и жить дальше?

Технически да, командой zmprov ms $(zmhostname) -zimbraServiceEnabled antivirus с перезапуском почтовой подсистемы. Почта поедет через минуту. Но это не решение, а инструмент разморозки на время работ, и опасность здесь бытовая: выключенным он остаётся навсегда. Я видел инсталляции, где антивирус выключили в 2020 году под точно такую же аварию и с тех пор ни разу не вспомнили. Если отключаете — ставьте себе в тот же момент задачу с датой возврата. У меня по этому случаю разморозка была 13 сентября, возврат проверки 16-го, и обе даты стояли в задаче до начала работ.

Правлю freshclam.conf, а после перезапуска правка исчезает. Почему?

Потому что этот файл сервер генерирует сам из шаблона. Рядом лежит /opt/zimbra/conf/freshclam.conf.in — правки надо вносить туда, а сгенерированный файл только читать. При каждом перезапуске служб конфигурация раскладывается из шаблонов заново и затирает всё, что вы написали руками. По той же схеме работает значительная часть конфигурации почтовой подсистемы, поэтому правило универсальное: увидели рядом с конфигурационным файлом такой же с суффиксом .in — правьте шаблон. Я на этом потерял три часа и полдня хорошего настроения.

Не проще ли переехать на другую платформу, раз обновления из России проблемные?

Не всегда, и я честно отговариваю тех, кому это не нужно. Проектному бюро в Химках переезжать было незачем: 24 человека, 180 гигабайт, аккуратная работающая установка. Им нужен был не другой продукт, а чтобы кто-то регулярно открывал лог обновлений. Зеркало баз плюс ежемесячный чек-ап закрыли вопрос за 12 часов работ. Переезд имеет смысл, когда к техническому вопросу добавляется что-то ещё: у вас коммерческая редакция и подходит срок продления лицензии, версия снята с поддержки, или заказчик требует продукт из реестра отечественного ПО. Тогда считайте Carbonio CE либо российский аналог.