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

Симптомы

DNS возвращает NXDOMAIN на записи вида:

 
dig statd.idig cluster.local

Решение

1. Откройте для редактирования файл /home/deployer/configs/coredns/corefile:

    
   vi /home/deployer/configs/coredns/corefile

2. Добавьте следующие строки в файл:

    
   :53 {prometheus 0.0.0.0:9256auto {directory /etc/coredns/common {1}reload 10s}reload 30s}cluster.local:53 {prometheus 0.0.0.0:9257auto {directory /etc/coredns/common (cluster.local) {1}reload 10s}reload 30s}

3. Перезапустите все контейнеры bind*, пример команды:

    
   systemctl restart onpremise-container-bind1

За постоянное хранение вложений отвечает сервис stz. Чтобы увеличить память, расширьте LVM-тома и в одном из контейнеров stz-valkyrie*, выполните команду:

 
pairdb_admin noncorp autoresize -i 1-3

Где 1-3 — это диапазон дисковых пар, это значение может отличаться для вашей инсталляции. Номера дисковых пар можно получить из первого столбца таблицы в веб-интерфейсе установщика: http://server-ip-address:8888/config/main/storage/mailcloud/

На примере stz-valkyrie1, чтобы попасть в контейнер используйте команду:

 
docker exec -it stz-valkyrie1 bash

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 (ca4256748af3-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-a21fdfad79a887a6) and is frozen until promotion

Решение

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

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

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

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

    
   docker exec -it autogen-tar2 bashtarantoolctl 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 есть следующие ошибки:

 
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 на странице Настройки → Шардирование и репликация БД, по кнопке Опросить базы данных.

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

Симптом:

В логах 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.

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

    
   zeptoctl buckets status!=ok

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

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

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

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

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

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 <скопированный id задачи>

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

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-бакета>

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

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

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

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

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

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

Симптомы:

• При высокой нагрузке на систему пользователи стали массово видеть ошибку с кодом 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.

Проблемы:

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

Решение:

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.

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

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. Нажмите кнопку редактировать .

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

   

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

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. В веб-интерфейсе установщика Почты перейдите на главную страницу веб-интерфейса установщика.

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

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. В веб-интерфейсе установщика Почты перейдите на главную страницу веб-интерфейса установщика.

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

Проблема может возникать для различных контейнеров с БД, рассмотри проблему на примере контейнера 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/cinemadb2mv /opt/mail/dockerVolumes/cinemadb23 /opt/mail/dockerVolumes/cinemadb3

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

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

При работе кластерной инсталляции .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"

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

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

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

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

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

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

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

   

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

   

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

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

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

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

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

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

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

   

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

   

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

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

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

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

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

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

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

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

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

2. Найдите проблемный гипервизор и нажмите на значок шестеренки справа от названия.

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

   

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

   

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 runningonpremise-container-mailapi1.service loaded activating auto-restart Mail.Ru onpremise mailapi1 service# видим, что не запустился сервис mailapi1sudo cat /etc/systemd/system/onpremise-container-pub1.service  | grep mailapi# проверяем, что для продолжения установки pub1 должна завершить установка mailapi1Wants=onpremise-container-mailapi1.serviceAfter=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 имя контейнера

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

 
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 postfixsystemctl stop postfixsystemctl mask --now postfix

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

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

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

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. Нажмите кнопку редактировать .

4. Нажмите на кнопку + Добавить.

5. В появившемся поле введите адрес вашего exchange. Например: exchange.vk.tech.

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

7. Перейдите на главную страницу веб-интерфейса установщика и запустите автоматическую установку.

   

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

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

Симптомы

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

 
2024-10-03T12:53:06.119295+03:00 m-mail sudo[26695]: deployer : TTY=pts/3 ; PWD=/home/deployer ; USER=root ; COMMAND=/bin/echo ok2024-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 root2024-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 корректно обрабатывались Календарем, нужно настроить отправку уведомлений под пользователем отличным от admin@admin.qdit:

1. Перейдите в панель администратора по адресу biz.<mail_domain>.

2. Перейдите в раздел Почта → Настройки.

3. Переключитесь на вкладку Письма календаря.

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

   

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

Симптомы

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

 
cali0: renamed from temp6ccdc4087c0docker-entrypoi[732625] vsyscall attempted with vsyscall=none ip:ffffffffff600400 cs:33 sp:7ffd3bb7fe68 ax:ffffffffff600400 si:7ffd3bb81daf di:0docker-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. Перезагрузите операционную систему.

Технический писатель: Груздев Никита