Назад | Перейти на главную страницу

солончак: как повторно протолкнуть ключ с соляного миньона к соляному мастеру?

В укороченная версия: Как получить test.ping работать, после ключей -Added? И как повторно нажать клавишу, если вы -Dвыбрал его с мастера?

В длинная версия: Действия по воспроизведению:

по двум RPI
установите последнюю версию Raspbian на RPI из образа 2014-09-09-wheezy-raspbian
aptitude upgrade
aptitude install build-essential python-dev javascript-common libjs-jquery msgpack-python python-async python-crypto python-git python-gitdb python-jinja2 python-m2crypto python-mako python-markupsafe python-pkg-resources python-smmap python-yaml wwwconfig-common
Добавить deb http://debian.saltstack.com/debian wheezy-saltstack main к /etc/apt/sources.list
установите соль 2014.7.0 или около того
не работает
удалить это
git clone --depth=1 https://github.com/saltstack/salt.git
sudo pip install -e ./salt
на миньоне RPI, редактировать /etc/salt/minion и изменить master: salt к IP мастера.
salt-master -l debug на один RPI, и salt-minion -l debug
salt-key -L показывает ключ миньона. salt-key -A принять это
salt --verbose '*' test.ping. Ничего не делает
salt-key -D на мастера.
стереть ключи из /etc/salt/pki/minion/... на миньоне
перезапустите миньона, чтобы сгенерировать новые ключи

Когда у меня была скомпилированная на заводе соль, test.ping ничего не делал, и трафик на SuperUser (и на сайтах арендодателей) предполагал, что я должен получить последнюю версию. По-прежнему. Поэтому, когда я это сделал, я решил попробовать переработать ключи.

Теперь я не могу заставить новые ключи миньона появиться в salt-key -L.

Отладочные записи миньона говорят только о счастливых вещах, например [DEBUG ] Attempting to authenticate with the Salt Master at 192.168.0.19 / [DEBUG ] Loaded minion key: /etc/salt/pki/minion/minion.pem.

Трассировки отладки с сервера говорят только о счастливых вещах, например generating master keys.

Затем миньон говорит SaltReqTimeoutError: after 60 seconds.

В онлайн-сообщениях об этой ошибке люди отвечают только "включен ли процессор?" стиль ответов. Да, между двумя RPI нет брандмауэра. Да, я могу использовать telnet с правильным IP и портом. Да, все работают как root в режиме отладки.

Так что же мне не хватает в моей ментальной модели этой ситуации? Если я получу ключи для работы, test.ping не будет работать. Весь проект задерживается в ожидании этой дурацкой детали конфигурации ...

inb4 кто-то просит salt --versions-report:

           Salt: 2014.7.0-n/a-43c01ef
         Python: 2.7.3 (default, Mar 18 2014, 05:13:23)
         Jinja2: 2.6
       M2Crypto: 0.21.1
 msgpack-python: 0.4.2
   msgpack-pure: Not Installed
       pycrypto: 2.6
        libnacl: Not Installed
         PyYAML: 3.10
          ioflo: Not Installed
          PyZMQ: 14.3.1
           RAET: Not Installed
            ZMQ: 4.0.4
           Mako: 0.7.0

saltstack

Для меня работает следующая процедура сброса ключа миньона (проверено на salt 2015.5.2 до 2017.7.2):

На мастере удалите текущий ключ: sudo salt-key -d <minion_name>
На миньоне перезапускаем сервис: sudo systemctl restart salt-minion (или sudo service salt-minion restart на более старой ОС, не относящейся к системе)
Вернитесь к мастеру, примите новый ключ: sudo salt-key -a <minion_name>

Пока внутренний вопрос - как восстановиться после -Dвыбор ключа - остается без ответа, ответ на внешний вопрос, естественно, заключался в том, чтобы заново создать образ SD-карты и установить версию Salt '2014.1.10' из репозиториев Aptitude.