Один транспорт, один логин, один способ

Однообразие как способ не запутаться

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

Из чего складывается:

  • /configFile read — забирает то, что лежит на узле, прежде чем переписать; перечень файлов даёт /configFile listconfigfiles;
  • /configFile commit — записывает файлы, не проверяя и не перечитывая;
  • /command — test config, затем reload;
  • http-api-authorisation — ключ, которым всё это едет.

Области у составляющих разные. Уровень узла; схема закрывает всё, кроме установки MTA, — для неё нужна оболочка. Порт монитора должен быть доступен Хабу, а ключ — храниться там, где Хаб им пользуется.

Как они взаимодействуют. Вся схема — в порядке действий, потому что запись не проверяет и не вводит в действие: прочитать, записать, проверить, перечитать, а при неудаче вернуть прочитанное. Ровно эту последовательность Хаб выполняет и сегодня, только запись идёт по SSH, — так что схема про смену транспорта. Размен настоящий: путей доступа становится меньше, но один ключ достаёт и до конфигурации, и до любой команды узла.

Главная ловушка — считать запись через API применением. /configFile commit только кладёт файлы: без test config и reload узел работает на прежней конфигурации, а битый файл всплывёт при следующем перечитывании или перезапуске.
Что делает Хаб. Не применяет — схема описывает, как было бы проще. Файлы конфигурации Хаб кладёт на узел и вводит в действие по SSH (pmta test config, pmta reload), там же перезапускает службу, а состояние читает и команды управления отправляет через веб-монитор, по ключу. Транспортов два и доступов два.
Рекомендуемые значения

Порядок:

Шаг Вызов Зачем
прочитать GET /configFile?op=read увидеть расхождение с тем, что писал Хаб
записать POST /configFile с op=commit положить файлы
проверить POST /command с test config синтаксис до перечитывания
перечитать POST /command с reload ввести в действие
откатить POST /configFile с прочитанным если перечитывание не прошло
Чтение, запись без проверки, выполнение команд и ключ — из руководства (§ 8.2.1–8.2.3, § 8.4). Сама схема — наша гипотеза.
Пример в конфигурации
# записать файл, проверить и перечитать — всё по ключу
curl -s -X POST -H 'X-API-Key: KEY' 'http://127.0.0.1:8080/configFile' -F op=commit -F format=json -F file.1.name=/etc/pmta/config -F file.1.op=write -F file.1.content='@/tmp/config.new'
curl -s -H 'X-API-Key: KEY' 'http://127.0.0.1:8080/command' -F command='test config' -F format=json
curl -s -H 'X-API-Key: KEY' 'http://127.0.0.1:8080/command' -F command='reload' -F format=json
KEY — ключ из http-api-key; ответ команды разбирают по полю status, а не по коду ответа.
жёлтым — — имена директив, голубым — блоки. Так же они подсвечены и в тексте карточки.
Совместимость
PowerMTA 6.0
описана в руководстве этой версии · платформа: любая
С какой версии директива доступна, вендор указывает не для всех — здесь пометки нет. Имя встречается и в издании руководства 5.0.
Как проверить на узле
Проверить, что ключ открывает чтение конфигурации:
curl -s -H 'X-API-Key: KEY' 'http://127.0.0.1:8080/configFile?format=json-text&op=read&filename=/etc/pmta/config' | head -5
Содержимое файла в ответе — чтение работает; сверка с тем, что записывал Хаб, покажет правки мимо него.