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

Puppet выдает ошибку SSL, потому что мастер не работает?

На этот раз я начал с двух чистых машин.

Мой мастер работает 12.04

Версия: 2.7.11-1ubuntu2

Зависит от: ruby1.8, puppetmaster-common (= 2.7.11-1ubuntu2)

Мой клиент 10.04

Версия: 2.6.3-0ubuntu1 ~ lucid1

Зависит: puppet-common (=> 2.6.3-0ubuntu1 ~ lucid1), ruby1.8

Чтобы настроить руководство по Puppet: http://shapeshed.com/setting-up-puppet-on-ubuntu-10-04/

Для подключения мастера и клиента: http://shapeshed.com/connecting-clients-to-a-puppet-master/

Первый раз, когда я попытался подключить мастер к клиенту, не удалось SSL_connect error. Так я и сделал rm -rf /etc/puppet/ssl/ чтобы удалить все ключи в папках ssl.

Вроде заработало .... НО

client# puppet agent --server puppet --waitforce 60 --test
/usr/lib/ruby/1.8/facter/util/resolution.rb:46: warning: Insecure world writable dir /etc/condor in PATH, mode 040777
/usr/lib/ruby/1.8/puppet/defaults.rb:67: warning: Insecure world writable dir /etc/condor in PATH, mode 040777
info: Creating a new SSL key for giab10
warning: peer certificate won't be verified in this SSL session
info: Caching certificate for ca
warning: peer certificate won't be verified in this SSL session
warning: peer certificate won't be verified in this SSL session
info: Creating a new SSL certificate request for mybox123
info: Certificate Request fingerprint (md5): XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
warning: peer certificate won't be verified in this SSL session
warning: peer certificate won't be verified in this SSL session
warning: peer certificate won't be verified in this SSL session

warning: peer certificate won't be verified in this SSL session
info: Caching certificate for mybox123
err: Could not retrieve catalog from remote server: SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B: certificate verify failed
warning: Not using cache on failed catalog

It cached but then it couldn't retrieve it.

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

 * master is not running

Вот это да.... ???

master# service puppetmaster start
* Starting puppet master    [OK]
master# service puppetmaster status
 * master is not running
  1. Я думаю, что время синхронно. Что ж, мы находимся за брандмауэром, поэтому порт для синхронизации времени отключен. Я проверил с date и они кажутся нормальными.

  2. А как насчет того, что мастер не работает? Это причина?

Любая помощь приветствуется. Спасибо!


/var/lib/puppet/log/masterhttp.log

[2012-06-30 00:13:25] INFO  WEBrick 1.3.1
[2012-06-30 00:13:25] INFO  ruby 1.8.7 (2011-06-30) [x86_64-linux]
[2012-06-30 00:13:25] WARN  TCPServer Error: Address already in use - bind(2)
[2012-06-30 00:19:40] INFO  WEBrick 1.3.1
[2012-06-30 00:19:40] INFO  ruby 1.8.7 (2011-06-30) [x86_64-linux]
[2012-06-30 00:19:40] WARN  TCPServer Error: Address already in use - bind(2)
[2012-06-30 00:28:58] INFO  WEBrick 1.3.1
[2012-06-30 00:28:58] INFO  ruby 1.8.7 (2011-06-30) [x86_64-linux]
[2012-06-30 00:28:58] WARN  TCPServer Error: Address already in use - bind(2)
[2012-06-30 15:31:25] INFO  WEBrick 1.3.1
[2012-06-30 15:31:25] INFO  ruby 1.8.7 (2011-06-30) [x86_64-linux]
[2012-06-30 15:31:25] WARN  TCPServer Error: Address already in use - bind(2)

    1 S puppet    5186     1  0  80   0 - 29410 poll_s 15:44 ?        00:00:00 /usr/bin/ruby1.8 /usr/bin/puppet master --masterport=8140
    4 S root      5235  5005  0  80   0 -  2344 pipe_w 15:45 pts/0    00:00:00 grep --color=auto puppet

kill -9 5186
puppet master
service puppetmaster status
 * master is not running

У меня всегда эта ошибка, но я всегда ее игнорировал. http://pastebin.com/exbpArjv Что бы это могло значить? Синхронизация времени? Пакет не установлен? Тогда как мы вообще могли сделать марионетку?

Бегать puppet master --debug --no-daemonize и если ты придешь посмотреть

Error: Could not run: Address already in use - bind(2)

Вероятно, это означает, что кукловод уже запущен. Попробуйте проверить вывод

netstat -anpl | grep 8140

если вы видите строку со ссылкой на порт 8140 с помощью LISTEN, то, вероятно, это ваша проблема. (Главный процесс марионетки по умолчанию прослушивает порт 8140 на предмет входящих подключений от клиентов.)

Если вы следовали настройке по умолчанию для Ubuntu, apache запустится, прослушивая порт 8140.

sudo service apache2 stop

затем продолжайте конфиг.