===== Изменение хостнеймов в кластере PMG =====

Представим ситуацию, когда в рабочем кластере //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//:

<WRAP prewrap>
<code>
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
</code>
</WRAP>

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

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

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

   pmgtunnel stop
   pmgtunnel start --debug
Через несколько секунд видим кое-что интересное:
   Host key verification failed
Вполне вероятно, наш сервер после смены имени не доверяет соседу при подключении по //ssh//.

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

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

<WRAP prewrap>
<code>
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
</code>
</WRAP>

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

<WRAP prewrap>
<code>
ssh -l root -o 'BatchMode=yes' -o 'HostKeyAlias=pmg2' 111.222.333.444 'openssl x509 -noout -fingerprint -sha256 -in /etc/pmg/pmg-api.pem'
</code>
</WRAP>
Тем более, что есть шанс увидеть нечто знакомое:

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

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

   pmgtunnel stop
   pmgtunnel start --debug
{{tag>Proxmox PMG Unix Debian Mail}}