Представим ситуацию, когда в рабочем кластере Proxmox Mail Gateway - нам необходимо поменять имена хостов. К примеру, такая потребность может возникнуть, если нам требуется поменять HELO.

Теоретически, мы можем поменять в файле /var/lib/pmg/templates/main.cf.in опцию smtp_helo_name таким образом, чтобы она принимала значение такое же, как и опция SMTPD Banner, доступная в GUI PMG:

 smtpd_banner = [% pmg.mail.banner %]
 smtp_helo_name = [% pmg.mail.banner %]

Однако, данные конфигурации синхронизируются во всем кластере, а если нам необходимо HELO, отличное для каждого хоста - следует менять именно имя хоста.

Отредактировать имя необходимо в следующих файлах (и перезагрузиться):

 /etc/hostname
 /etc/hosts
 reboot

Имена нод кластера, прописанных в данных файлах, должны разрешаться для каждого сервера. Т.е. один сервер должен правильным образом разрешать собственный hostname и hostname другого сервера, и наоборот.

Примерно вот так без привлечения внешних DNS (содержимое файла /etc/hosts):

 127.0.0.1 localhost.localdomain localhost
 192.168.1.1 mail1.arasaka.local mail1
 192.168.1.2 mail2.arasaka.local mail2

После поочередной перезагрузки нод в кластере одна из нод долго висит в статусе syncing? Время заняться траблшутингом!

В первую очередь можно попробовать вручную отдать команду синхронизации на нодах и посмотреть - нет ли ошибок.

 pmgcm sync
 pmgcm status

Если здесь всё ОК, но кластер продолжает висеть в статусе syncing, стоит почитать системный журнал на предмет возможных проблем с pmgmirror и pmgtunnel.

 journalctl -u pmgmirror -u pmgtunnel --since today

pmgmirror в этой связке занимается репликацией баз на все ноды кластера.
pmgtunnel туннелирует подключения к Postgres на другой ноде кластера.

После изменения имени нод я обнаружил такую ошибку, связанную с работой pmgtunnel:

database sync 'pmg_server' failed - DBI connect('dbname=Proxmox_ruledb;host=/run/pmgtunnel;port=2;','root',...) failed: connection to server o>
Is the server running locally and accepting connections on that socket? at /usr/share/perl5/PMG/DBTools.pm line 66

tunnel finished 3212 10.10.111.198
pmgtunnel[673]: restarting crashed tunnel 3306 192.168.1.1

Можно проверить статус pmgtunnel командой:

 pmgtunnel status

ОК, видим статус running. Не очень информативно.

Самое время попробовать остановить pmgtunnel и запустить заново в режиме debug.

 pmgtunnel stop
 pmgtunnel start --debug

Через несколько секунд видим кое-что интересное:

 Host key verification failed

Вполне вероятно, наш сервер после смены имени не доверяет соседу при подключении по ssh.

Попробуем сделать обновление отпечатков.

  pmgcm update-fingerprints

Посе чего получаем ошибку:

TASK ERROR: 500 update fingerprints failed: unable to get remote node fingerprint from 'xxxxxxx': command 'ssh -l root -o 'BatchMode=yes' -o 'HostKeyAlias=pmg2' 111.222.333.444 'openssl x509 -noout -fingerprint -sha256 -in /etc/pmg/pmg-api.pem'' failed: exit code 255

Почему бы не выполнить команду вручную и не посмотреть её output глазами?

ssh -l root -o 'BatchMode=yes' -o 'HostKeyAlias=pmg2' 111.222.333.444 'openssl x509 -noout -fingerprint -sha256 -in /etc/pmg/pmg-api.pem'

Тем более, что есть шанс увидеть нечто знакомое:

 Host key verification failed

Теперь самое простое решение - это попробовать с одного сервера PMG установить подключение по SSH на второй сервер. Оно должно пройти без всяких паролей потому что PMG сам устанавливает нужные ключи. Просто подключаемся и подтверждаем запрос доверия:

 ssh pmg_address

Если запрос мы подтвердили и подключение устанавливается нормально - время снова проверить проблемный pmgtunnel:

 pmgtunnel stop
 pmgtunnel start --debug