Перейти к содержанию

Известные проблемы

Внимание

Вносить изменения во внутренние файлы установщика можно только при взаимодействии с поддержкой VK WorkSpace. Не изменяйте файлы установщика самостоятельно.

Как восстановить репликацию БД Tarantool

Overlord требует работы с выключенной синхронной репликацией. Убедитесь, что синхронная репликация отключена с помощью команд:

  • box.info.synchro.queue.owner — владелец синхронной очереди. Правильное значение: 0.
  • box.cfg.election_mode — тип выборов встроенных в tarantool. Правильное значение: off.

Если не будет выключена синхронная репликация, то будет конфликт с overlord.

Пример проблемы:

фев 20 11:56:18 dev15 onpremise-container-autogen-tar1[2540431]: 2026-02-20 
11:56:18.829 [42] main/103/autogen.lua box.cc:358 E> ER_READONLY: Can't modify 
data on a read-only instance - synchro queue with term 2 belongs to 1 (ca425674
8af3-488e-a21f-dfad79a887a6) and is frozen until promotion
фев 20 11:56:18 dev15 onpremise-container-autogen-tar1[2540431]: 2026-02-20 
11:56:18.829 [42] main box.cc:358 E> ER_READONLY: Can't modify data on a read-only 
instance - synchro queue with term 2 belongs to 1 (ca425674-8af3-488e-a21f
dfad79a887a6) and is frozen until promotion

Решение

  1. Найдите работающий контейнер Tarantool в системе:

    docker ps -a | grep <имя_роли>

    В качестве примера предположим, что это контейнер autogen-tar2.

  2. Перейдите в консоль Tarantool:

    docker exec -it autogen-tar2 bash
tarantoolctl connect /var/run/tarantool/tarantool.sock

  3. Проверьте, что режим выборов выключен через команду box.cfg.election_mode. Правильное значение: off.

    unix/:/var/run/tarantool/tarantool.sock> box.cfg.election_mode
---- 
off
...

    Если указано другое значение, выполните команду box.cfg{election_mode="off"}.

  4. Определите владельца очереди, с помощью команды box.info.synchro.queue.owner:

    unix/:/var/run/tarantool/tarantool.sock> box.info.synchro.queue.owner--
- 1
...

  5. Убедитесь, что текущий контейнер является владельцем синхронной очереди: box.info.id. Если id совпадает со значением из предыдущего шага, то выполните команду:

    box.ctl.demote()

    Если id не совпадает выполните две команды:

    box.ctl.promote()
box.ctl.demote()

  6. Убедитесь, что владелец синхронной очереди имеет идентификатор 0.

  7. Выполните up_container для неработающих Tarantool'ов.

Ошибки в контейнере consul при формировании кластера

Симптом:

В логах контейнера consul есть следующие ошибки:

failed to parse /etc/consul.d/server_metadata.json: 1 error occurred:   * invalid config key last_seen_unix

Решение:

  1. При формировании кластера consul, после перезагрузки ВМ, выполните команду по примеру:

    rm /opt/mailOnPremise/dockerVolumes/consul1/consul/data/server_metadata.json

  2. Повторите команду для каждого контейнера consul в кластере.

  3. Выполните шаг up_container для каждого контейнера consul в веб-интерфейсе установщика.
  4. В веб-интерфейсе установщика проверьте состояние кластера БД MySQL на странице Настройки -> Шардирование и репликация БД, по кнопке Опросить базы данных.

Наблюдаются задержки и замедления в работе etcd

Проблема преобладает на установках с сильно перегруженной сетью.

Симптом:

В логах mailetcd можно наблюдать такие предупреждения:

{"level":"warn","ts":"2025-12-19T07:24:30.529512+0300","caller":"etcdserver/util.go:170","msg":"apply request took too long","took":"5.000138281s","expected-duration":"100ms","prefix":"read-only range ","request":"key:\"/mailonpremise/overlord/clusters/snooze-queue-tar-1/\" range_end:\"/mailonpremise/overlord/clusters/snooze-queue-tar-10\" ","response":"","error":"context deadline exceeded"}

Рекомендации по устранению:

Основной способ устранения проблемы: снизить количество обращений к ETCD.

Для этого увеличьте таймаут на запросы:

  1. В веб-интерфейсе установщика перейдите на страницу Настройки -> Переменные окружения.
  2. Для всех ролей с тегом Tarantool нужно изменить переменную OVERLORD_ELECTION_TIMEOUT.
  3. В поле Значение переменной укажите (5s, 15s].
  4. Нажмите кнопку Сохранить.
  5. Выполните шаг up_container для всех машин с тегом Tarantool.

После этого важно наблюдать за состоянием системы:

  • В логах mailetcd снилизилось количество предупреждений о слишком долгих запросах.
  • Контейнеры не перезапускаются слишком часто. Можно посмотреть с помощью команды docker ps -a.
  • В дашборде Grafana Database -> Etcd, графики: RPC Rate, High Number Of Failed HTTP Requests, Client Traffic In.
  • В дашборде Grafana Database -> Overlording, графики: Overlord Restarts, Failed ETCD Requests.

Если ситуация не улучшилась, то увеличьте интервал для OVERLORD_ELECTION_TIMEOUT.

Как восстановить бакеты(bucket) в Zepto

Внимание

Перед восстановлением бакета сделайте бэкап всех реплик, которые его обрабатывают.

Бакет вышел из строя в одной из реплик

  1. Найдите бакеты вышедшие из строя:

    zeptoctl buckets status!=ok

  2. Найдите бакеты с неповторяющимся bid. Если bid не повторяется, значит бакет вышел из строя в одной из реплик.

  3. Для каждого найденного bid запустите команду:

    zeptoctl tasks schedule --fix bid=<найденный bid>

    Внимание

    Не используйте команду zeptoctl tasks schedule --fix status!=ok.

  4. Проверьте статус задач:

    zeptoctl tasks show

  5. Дождитесь пока закончатся все задачи. Для всех задач (task) со статусом status = running, значение в столбце succeeded должно стать равным цифре из subtasks.

  6. Если задачи завершится со статусом failed, то скопируйте id задачи (task) и посмотрите причины ошибки:

    zeptoctl tasks show <скопированный id задачи>

Бакет вышел из строя в двух репликах

  1. Определите какие bucketmaster работают с проблемном бакетом:

    zeptoctl buckets bid=<id проблемного бакета>

  2. Найдите файлы в директориях bucketmaster, например:

    find /opt/mailOnPremise/dockerVolumes/stz-[NAME]-bm[NUM]/zepto -name 2.bucket

  3. Сделайте копию-бекап бакета в директории всех bucketmaster, которые за ним закреплены.

  4. Скопируйте полученный файл в докер контейнер на все сервисах вида stz-*-bm.

    docker cp <путь/до/брокен/бакета> stz-[NAME]-bm[NUM]:/

  5. Чтобы определить где находится более актуальный бакет и какая ошибка возникает, выполните внутри контейнера обеих реплик команду:

    /usr/local/zepto/bin/bucketfixer --show-broken </путь/до/бакета/внутри/контейнера/id.bucket>

  6. На реплике, где более актуальный бакет, выполните:

    /usr/local/zepto/bin/bucketfixer --trim-broken --out <Введите имя бакета, который будет создан с фиксом> </путь/до/бакета/внутри/контейнера/id.bucket>

    Если актуальность бакетов одинаковая, то команду можно выполнить в любом из бакетов.

  7. Замените старый бакет на актуальный из шага 5. Путь до устаревшего бакета был получен на шаге 2.

    docker cp stz-[NAME]-bm[NUM]:<путь/до/исправленного/бакета/в контейнере> <путь из пункта 2>

  8. Выполните команду:

    zeptoctl tasks schedule --recheck-full bid=<id-бакета>

    Следить за статусом задачи можно с помощью:

    zeptoctl tasks show

  9. Если в итоге восстановился только один бакет — в одной реплике отображается статус succeeded, а в другой failed, то после завершения задачи выполните:

    zeptoctl tasks schedule --fix bid=<id-бакета>

    Так восстановится второй бакет.

  10. Если для обоих бакетов отображается статус failed, а в результате выполнения задачи выводится ошибка:

    Calling ... returned error (500): unable to read record: unexpected EOF record while scanning the data, file broken, file broken.

    То обратитесь к шагам по исправлению ошибки file broken

Ошибка file broken

  1. Измените имена бакетов, задав другое имя на каждой реплике.
  2. Перезапустите реплики с помощью systemctl.

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

    zeptoctl tasks schedule --forget bid=<bid проблемного бакета>

  4. Верните названия бакетов, которые изменялись на шаге 1.

  5. Выполните команду:

    zeptoctl tasks schedule --recheck-full bid=<id-бакета>

  6. После завершения команды, выполните:

    zeptoctl tasks schedule --fix bid=<id-бакета>

Ошибка too many replicas for bucket или bucket has location across multiple tuple

  1. Выполните команду:

    zeptoctl tasks schedule --fix bid=<id-бакета>

    После этого группа должна остаться одна группа.

  2. Перезапустите реплику, которая работает с этим бакетом.

  3. Выполните команду:

    zeptoctl tasks schedule --recheck-full bid=<id-бакета>

Пользователи массово видят ошибку 500 и память calendarapi переполнена

Симптомы:

  • При высокой нагрузке на систему пользователи стали массово видеть ошибку с кодом 500.
  • В PostgreSQL calendarpg закончилось место.
  • Высокое потребление CPU у calendarapi.

Решение:

  1. На машине с установщиком откройте для редактирования файл custom_roles.yaml.

  2. Увеличьте значение параметра shm_size:

    calendarpg:
    shm_size: "2gb"

  3. Перезапустите установщик:

    systemctl restart deployer

  4. Перейдите в веб-интерфейс установщика, в раздел Настройки -> Переменные окружения.

  5. В левом меню найдите calendarpg.
  6. Увеличьте значение переменной SHARED_BUFFERS. Новое значение не должно превышать значение указанное в параметре shm_size.
  7. Нажмите кнопку Сохранить.
  8. Выполните шаг up_container для всех машин calendarpg.

Как убрать уведомления о старых событиях при миграции календарей с MS Exchange

Проблемы:

  • Если пользователь мигрируется из Exchange, то изменения в календаре синхронизируются обратно в Exchange. Это генерирует уведомления на старые события от EWS.
  • Если при миграции пользователя не отключен сервис уведомлений в Почте VK WorkSpace, то по всем мигрированным событиям будут разосланы уведомления от календаря. События рассылаются даже по старым событиям.

Решение:

Внимание

Шаги ниже рекомендуется выполнять в технологическое окно, так как во время миграции не буду рассылаться уведомления по email.

  1. Отключите уведомления в сервисе calendar-notifyd. Выполните команду:

    vim configs/calendar/notifier/notifyd/notifyd.yaml

    В блоке ниже, в поле emails: укажите значение false:

    notification:
    service:
        channels:
            emails: false

  2. Выполните шаг up_container для всех контейнеров calendar-notifyd.

  3. Исправьте файл конфигурации /app/distr/VK/custom_configs/cexsy/etc/config.yaml. Уберите комемнтарии со следующих строк или добавьте их, если они отсутствуют:

    skip_notify_past_events:
    permille: 1000
    domains: 
        - ur_domain.ru

  4. Выполните шаг up_container для всех контейнеров calendar-cexsy.

  5. Выполните миграцию календарей по инструкции: Шаг 4. Выполните синхронизацию календарей

  6. Включите уведомления в сервисе calendar-notifyd. Выполните команду:

    vim configs/calendar/notifier/notifyd/notifyd.yaml

    В блоке ниже, в поле emails: укажите значение true:

    notification:
    service:
        channels:
            emails: true

  7. Выполните шаг up_container для всех контейнеров calendar-notifyd.

Не работает SSO после обновления до версии 1.24.3

Чтобы исправить проблему:

  1. Проверьте наличие закрывающего символа ; в конфигурационном файле $DEPLOYER_HOME/configs/swa/nginx/auth.mail.ru.conf, где $DEPLOYER_HOME — папка в которую распаковывался установщик. Например, /home/deployer:

    {{- if .products.sso }}
...
        location ~ ^/sso/clauth/?$ {
            ...
            proxy_set_header X-Real-IP   $x_k8s_real_ip; // Эта строка должна заканчиваться на ;
        }

  2. Перейдите в веб-интерфейс установщика.

  3. Перейдите в раздел Настройки -> Настройки компонентов -> Авторизация.
  4. Нажмите кнопку редактировать edit_icon.

  5. Включите опцию Включить систему ограничения SSO-авторизации по IP/группе в LDAP.

    autogen-tokens

  6. Нажмите Сохранить.

Перестала работать синхронизация с Exchange после обновления до версии 1.24

  1. На машине с установщиком откройте для редактирования файл $DEPLOYER_HOME/configs/rimap/zubr/picker-zubr.yaml, где $DEPLOYER_HOME — папка в которую распаковывался установщик. Например, /home/deployer:

    vim /home/deployer/configs/rimap/zubr/picker-zubr.yaml

  2. Добавьте сервис - 94 # arbuzapi в раздел:

    constructor:
    services:

    Общий вид раздела после изменения:

    services:
    - 12 # MEMC_NEWMAIL
    - 25 # ADDRBOOK
    - 36 # autoreply_limiter
    - 37 # PDD
    - 41 # RIMA
    - 46 # IRINA
    - 57 # SPAMABUSE
    - 62 # DOMEN
    - 64 # HERMES
    - 76 # RICO
    - 94 # arbuzapi
    - 103 # USPATH 2
    - 108 # XTAZIK
    - 130 # RIMAP-API

  3. В веб-интерфейсе установщика Почты перейдите на вкладку AdminPanel.

  4. Для всех контейнеров вида picker* выполните шаг up_container.

Не синхронизируются письма с вложениям в Exchange после обновления до версии 1.24

  1. На машине с установщиком откройте для редактирования файл $DEPLOYER_HOME/configs/rimap/envoy/envoy-rimap.yaml, где $DEPLOYER_HOME — папка в которую распаковывался установщик. Например, /home/deployer:

    vim /home/deployer/configs/rimap/envoy/envoy-rimap.yaml

  2. В раздел static_resources добавьте следующие разделы:

    static_resources:
  listeners:
    {{- genEnvoyTarListener "mfiledb" "127.0.77" false }}
    {{- genEnvoyTarListener "mpairdb" "127.0.79" false }}
  clusters:
    {{- genEnvoyTarCluster "mfiledb" "127.0.77" false }}
    {{- genEnvoyTarCluster "mpairdb" "127.0.79" false }}

  3. Откройте для редактирования файл $DEPLOYER_HOME/configs/rimap/zubr/zubr.yaml:

    vim /home/deployer/configs/rimap/zubr/zubr.yaml

  4. Обновите разделы services и variables:

    constructor:
    services:
        - 77 # FILEDB_NONCORP  
        - 79 # PAIRDB

    ...

    variables:
        filedb_noncorp_server:
        {{- range $k, $v := (index . "tarantool15::mfiledb").clusters }}
            - 127.0.77.{{$k}}:3301,127.0.77.{{$k}}:3401
        {{- end }}
        pairdb_noncorp_server:
        {{- range $k, $v := (index . "tarantool15::mpairdb").clusters }}
            - 127.0.79.{{$k}}:3301,127.0.79.{{$k}}:3401
        {{- end }}

  5. Выполните команду:

    sudo systemctl restart deployer

  6. В веб-интерфейсе установщика Почты перейдите на вкладку AdminPanel.

  7. По очереди выполните шаг up_container для всех контейнеров rimap*.

Некорректная конфигурация кластера БД после обновления до версии 1.24

Проблема может возникать для различных контейнеров с БД, рассмотри проблему на примере контейнера cinemadb*.

Если до обновления на версию 1.24 вы по каким-то причинам удаляли контейнеры cinemadb*, то после обновления возникают проблемы с нумерацией контейнеров, репликацией кластера и запуском сервисов.

Пример 1

До обновления вы по каким-то причинам удаляли контейнеры cinemadb2 и cinemadb3. И у вас остались контейнеры cinemadb1 и cinemadb4.

Решение

  1. Удалите контейнер cinemadb4.

  2. Переименуйте Volume в cinemadb2 с помощью команды:

    mv /opt/mail/dockerVolumes/cinemadb11 /opt/mail/dockerVolumes/cinemadb2

  3. В веб-интерфейсе установщика создайте новый контейнер cinemadb2.

Пример 2

После обновления у вас следующая нумерация контейнеров: cinemadb1, cinemadb11, cinemadb23.

Решение

  1. Предварительно запишите или запомните как собираетесь переименовать контейнеры cinemadb11 и cinemadb23. Например: cinemadb11 -> cinemadb2 и cinemadb23 -> cinemadb3.
  2. Остановите и удалите контейнеры cinemadb11 и cinemadb23. Если удалить только контейнер cinemadb23, то новый контейнер создастся с названием cinemadb12.
  3. В веб-интерфейсе установщика создайте новые контейнеры cinemadb2 и cinemadb3.

  4. Переименуйте Volume в cinemadb2 и cinemadb3 с помощью команд:

    mv /opt/mail/dockerVolumes/cinemadb11 /opt/mail/dockerVolumes/cinemadb2
mv /opt/mail/dockerVolumes/cinemadb23 /opt/mail/dockerVolumes/cinemadb3

  5. Выполните шаг up_container для контейнеров cinemadb2 и cinemadb3.

Расширенные транспортные правила и DLP-системы

Система расширенных транспортных правил при интеграции с внешними DLP системами может привести к дублированию исходящего почтового трафика и другим непредвиденным эффектам.

Как очистить память на диске при больших .wal файлах

При работе кластерной инсталляции .wal файлы могут занимать много места на диске. Чтобы очистить место, на примере контейнера exchange-importer-pg:

  1. Проверьте, что реплика имеет большой лаг в мастере PostgreSQL:

    docker exec exchange-importer-pgN bash -c "patronictl -c /etc/patroni/patroni.yml list"

  2. Проверьте статус реплики:

    docker exec exchange-importer-pgN psql exchange_sync postgres -c "SELECT slot_name, active FROM pg_stat_replication;"

  3. Удалите проблемный слот:

    docker exec exchange-importer-pgN psql exchange_sync postgres -c "SELECT pg_drop_replication_slot('<имя слота из пункта 2>');"

  4. Проверьте, что слот удалён:

    docker exec exchange-importer-pgN psql exchange_sync postgres -c "SELECT slot_name FROM pg_replication_slots;"

  5. Остановите проблемную реплику, для которой удалили слот:

    systemctl stop onpremise-container-exchange-importer-pgN

  6. Удалите файлы data для этой реплики:

    rm -rf /opt/mailOnpremise/dockerVolumes/exchange-importer-pgN/postgresql/data/*

  7. Запустите реплику:

    systemctl start onpremise-container-exchange-importer-pgN

  8. Передайте данные из мастера:

    docker exec exchange-importer-pgN bash -c "patronictl -c /etc/patroni/patroni.yml reinit exchange-importer-pg exchange-importer-pgN.qdit"

При запуске установщика выдалась ошибка no such file or directory

Это не ошибка, а предупреждение о том, что файлов нет, так как их действительно пока еще нет (не сформировались). Не обращайте внимание, это нормально.

После запуска установщика в веб-браузере отображается «Не удается получить доступ к сайту»?

Убедитесь, что firewall отключен.

Не проходит первая авторизация в панели администратора после установки Почты

При попытке залогинится в панель администратора под пользователем admin@admin.qdit после установки Почты возникает сообщение "Неверный пароль, попробуйте еще раз"

fmail

  1. Перепроверить, что пароль скопирован верно.

    Пароль находится в файле bizOwner.pass, файл расположен в директории с установщиком Почты onpremise-deployer_linux. Например, если установка происходила под пользователем deployer, проверить пароль можно, используя команду:

    cat /home/deployer/bizOwner.pass

  2. В веб-интерфейсе установщика перейти на вкладку AdminPanel

  3. Найти в списке контейнеров fmail1 и нажать на значок шестеренки справа от названия контейнера

    fmail

  4. Запустить выполнение шага get_biz_owner

    HowToFixWrongPasswordForAdmin

  5. Поcле того как шаг get_biz_owner будет выполнен, скопировать новый пароль из файла bizOwner.pass.

Не работает вход от имени пользователя у администратора

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

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

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

Чтобы исправить ситуацию:

  1. В веб-интерфейсе установщика перейдите на вкладку AdminPanel..

  2. Найдите в списке контейнеров autogen-tar1 и нажмите на значок шестеренки справа от названия контейнера.

    autogen-tar1

  3. Запустите выполнение шага init_autogen_tokens.

    autogen-tokens

Не удается зайти в Почту, на экране отображается колесо (буква С градиентом)

интерфейс не прогружается

Последовательность действий

  1. Проверьте, что сертификаты и DNS в порядке.

  2. Проверьте наличие ошибок в консоли браузера (инструменты разработчика, Development Tools).

    Вероятные ошибки: «ошибка загрузки login.css - 404 not found».

  3. Выполните up_container для контейнера img1:

    1. В веб-интерфейсе установщика Почты перейдите на вкладку AdminPanel.
    2. Найдите в списке контейнеров img1 и нажмите на значок шестеренки справа от названия контейнера.
    3. Выполните шаг up_container.

Установщик не может получить доступ до гипервизора

При кластерной установке после добавления гипервизора в установщике может появиться ошибка: установщик не может получить доступ до гипервизора по ssh. Это может произойти из-за того, что автоматически выбранная сетевая маска не покрывает все узлы или соединение между машинами работает по конкретному сетевому интерфейсу.

Чтобы исправить проблему:

  1. В веб-интерфейсе установщика перейдите на вкладку AdminPanel.
  2. Найдите проблемный гипервизор и нажмите на значок шестеренки справа от названия.

  3. На странице гипервизора еще раз нажмите на значок шестеренки.

    up_haproxy_pg

  4. В поле Интерфейс для межсерверного взаимодействия выберите сетевую маску, по которой установщик сможет получить доступ по SSH к гипервизору.

    up_haproxy_pg

  5. Нажмите на кнопку Обновить.

Установка зависла, и нет явной ошибки в логах

  1. Зафиксировать имя сервиса, на котором зависла установка (далее «целевой сервис»)

    Найти такой сервис можно, например, в веб-интерфейсе установщика, посмотрев, установка какого сервиса находится в статусе in progress.

    Также определить, на каком шаге зависла установка, можно по логам установщика. Для просмотра логов используйте следующую команду:

    sudo journalctl -fu deployer

  2. Проверить, какие сервисы еще не запустились и могут препятствовать установке целевого сервиса:

    sudo systemctl | grep onprem | grep -v running

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

    sudo cat /etc/systemd/system/<целевой сервис> | grep <незапущенный сервис>
Wants=<название незапущенного сервиса>
After=<название незапущенного сервиса>

  4. Устранить причину сбоя незапущенного сервиса.

Ниже приведен пример для случая, когда зависла установка сервиса pub1: 

sudo systemctl | grep onprem | grep -v running
onpremise-container-mailapi1.service loaded activating auto-restart Mail.Ru onpremise mailapi1 service
# видим, что не запустился сервис mailapi1

sudo cat /etc/systemd/system/onpremise-container-pub1.service  | grep mailapi
# проверяем, что для продолжения установки pub1 должна завершить установка mailapi1
Wants=onpremise-container-mailapi1.service
After=onpremise-container-mailapi1.service

Если деплоер зависает на этапе запуска data-compose файла, то может помочь принудительное удаление data-container'ов на виртуальной машине:

sudo docker rm $(docker ps -a | grep data-container | awk {'print $1'})

Не завершается установка обновлений

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

ошибка установки обновления

Один из самых распространенных сценариев — проблемы на шаге генерации контейнеров. В 99% случаев не запускаются какие-то из уже установленных контейнеров. Соответственно, следует начать с их починки и запуска.

Для просмотра логов установщика используется команда: 

sudo journalctl -fu deployer

Что исследовать?

  1. Получить список всех не запущенных контейнеров:

    sudo systemctl | grep onpremise | grep -v running

  2. Найти контейнеры со статусом auto-restrating.

    У этих контейнеров, как правило, более высокий приоритет на запуск, поэтому они тормозят запуск всех остальных контейнеров.

  3. Посмотреть логи конкретного контейнера

    sudo journalctl -eu 'имя контейнера'

Один из вариантов решения — удалить контейнер, чтобы systemd его пересоздал.

sudo docker rm имя контейнера

Error 1290: The MySQL server is running with the --read-only option

Примечание

В командах ниже используется директория /home/deployer/. Но если при установке Почты вы распаковали архив с дистрибутивом в другую директорию, корректно укажите ее в командах.

При установке обновлений в логах установщика:

deployer[377192]: [mirage1][add_profile_keys] add prfoile key <ParentEmail> fail: cant insert into 'mPOP.profile_keys': 
[Error 1290: The MySQL server is running with the --read-only option so it cannot execute this statement]

В веб-интерфейсе установщика красным подсвечен контейнер mirage1.

Последовательность действия для устранения ошибки:

  1. Проверить какие БД в read_only (проверяем по master)

    cat /home/deployer/main.yaml | egrep "mysql.*db:$" -A 5 | grep master | awk -F ":" '{print $NF}' | xargs -I % sh -c "echo DB=%; docker exec % mysql -uroot -e 'SELECT @@global.read_only;'"

  2. Снять read_only на master

    cat /home/deployer/main.yaml | egrep "mysql.*db:$" -A 5 | grep master | awk -F ":" '{print $NF}' | xargs -I % sh -c "echo DB=%; docker exec % mysql -uroot -e 'UNLOCK TABLES; SET GLOBAL read_only=OFF;’"

Почта не доходит до сервера

Проверить состояние и логи контейнера pub-mx.

Запущенный на машине Postfix – одна из возможных причин, почему контейнер pub-mx не стартует. Соответственно, Postfix нужно остановить и отключить.

systemctl disable postfix
systemctl stop postfix
systemctl mask --now postfix

Пользователи загружены, но адресная книга пустая

Проверить tarantool'ы в abookpdd-tar

docker exec -it abookpdd-tar1 bash
tarantool -a 3303
lua box.space[0]:len()
lua for k, v in box.space[0]:pairs() do print(v) end

Не создается документ в VK WorkDisk, и в меню «Создать» не хватает кнопок

не хватает кнопок

  1. В интерфейсе установщика перейти на вкладку AdminPanel.
  2. Найти в списке контейнеров mailetcd и нажать на значок шестеренки справа от названия контейнера.
  3. Выполнить шаг lightning_etcd_settings.

  4. Найти следующие контейнеры и выполнить для каждого из них команду up_container:

    • fcloud
    • beaver
    • lightning1

  5. Найти в списке контейнеров cld-docs и нажать на значок шестеренки справа от названия контейнера.

  6. Выполнить шаг upload_file_templates.

См. также Ошибка CE_BADBLOB при создании файла в облаке

Не создается или не включается сборщик почты

Проблема может воспроизводить при миграции, например при миграции с MS Exchange.

Симптомы

В логах контейнера biz-celery-worker-pdd*:

{"email":"user@vk.tech","status":400,"htmlencoded":true,"body":{"collect[0].server":
{"value":"exchange.vk.tech","error":"invalid"},"collect[0].port":{"error":"invalid","value":993},
"collect[0].ssl":{"value":true,"error":"invalid"}}})

В логах контейнера mpop*:

2024-09-06T14:54:48.902 E 12345 @ abcdef0123 >>> Connection error: server: exchange.vk.tech  port: 993  ssl: 1

Решение

  1. Перейдите в веб-интерфейс установщика http://server-ip-address:8888/.
  2. Перейдите в раздел Настройки -> Интеграции -> Сборщик почты.
  3. Нажмите кнопку редактировать edit_icon.
  4. Нажмите на кнопку + Добавить.
  5. В появившемся поле введите адрес вашего exchange. Например: exchange.vk.tech.
  6. Нажмите на кнопку Сохранить.

  7. Перейдите на вкладку AdminPanel и запустите автоматическую установку.

    img

  8. Подтвердить запуск автоматической установки, нажав на кнопку Запустить во всплывающем окне.

Дождитесь окончания установки.

Ошибка refused local port forward

Симптомы

В логах установщика выводится ошибка:

2024-10-03T12:53:06.119295+03:00 m-mail sudo[26695]: deployer : TTY=pts/3 ; PWD=/home/deployer ; USER=root ; COMMAND=/bin/echo ok
2024-10-03T12:53:06.129066+03:00 m-mail sudo[26695]: pam_unix(sudo: session): session opened for user root(uid=0) by deployer(uid=1007)
2024-10-03T12:53:06.130101+03:00 m-mail sudo[26695]: pam_unix(sudo: session): session closed for user root
2024-10-03T12:53:06.700493+03:00 m-mail sshd[4840]: refused local port forward: originator 0.0.0.0 port 0, target 10.132.65.24 port 2379

Решение

Ошибка возникает в случае, если в настройках SSH на машине не разрешен TCP Forwarding. Чтобы изменить настройку TCP Forwarding, в файле /etc/ssh/sshd_config установите следующее значение:

AllowTcpForwarding yes

Если ошибка была найдена во время установки Почты, то после изменения файла /etc/ssh/sshd_config перезапустите установщик, чтобы он сбросил активные ssh подключения:

sudo systemctl restart deployer

ICS файлы не обрабатываются Календарем

Чтобы файлы с расширением .ics корректно обрабатывались Календарем, нужно настроить отправку уведомлений под пользователем отличным от admin@admin.qdit:

  1. Перейдите в панель администратора по адресу biz.<mail_domain>.
  2. Перейдите в раздел Почта -> Настройки.
  3. Переключитесь на вкладку Письма календаря.

  4. В поля Логин для SMTP и Email отправителя писем введите адрес пользователя, от имени которого будут отправляться письма-уведомления.

    img

  5. Нажмите кнопку Сохранить.

Ошибка в контейнере addrbook-tar1.service при установке Почты 1.20.2

Симптомы

При попытке установки VKWorkMail 1.20.2 происходит ошибка контейнера onpremise-container-addrbook-tar1.service. В логах dmesg в момент воспроизведения проблемы присутствуют ошибки:

cali0: renamed from temp6ccdc4087c0
docker-entrypoi[732625] vsyscall attempted with vsyscall=none ip:ffffffffff600400 cs:33 sp:7ffd3bb7fe68 ax:ffffffffff600400 si:7ffd3bb81daf di:0
docker-entrypoi[732625]: segfault at ffffffffff600400 ip ffffffffff600400 sp 00007ffd3bb7fe68 error 15 likely on CPU 28 (core 0, socket 56)
Code: Unable to access opcode bytes at 0xffffffffff6003d6.

Решение

  1. Добавьте в файл /etc/default/grub строку:

    vsyscall=emulate

  2. Перезагрузите операционную систему.