Вот ошибка, которую я получаю:
ubuntu@sync1:/etc/puppet$ sudo /usr/bin/apt-get -q -y -o DPkg::Options::=--force-confold install rabbitmq-server
Reading package lists...
Building dependency tree...
Reading state information...
rabbitmq-server is already the newest version.
0 upgraded, 0 newly installed, 0 to remove and 2 not upgraded.
1 not fully installed or removed.
After this operation, 0 B of additional disk space will be used.
Setting up rabbitmq-server (3.2.2-1) ...
* Starting message broker rabbitmq-server * FAILED - check /var/log/rabbitmq/startup_\{log, _err\}
[fail]
invoke-rc.d: initscript rabbitmq-server, action "start" failed.
dpkg: error processing rabbitmq-server (--configure):
subprocess installed post-installation script returned error exit status 1
E: Sub-process /usr/bin/dpkg returned an error code (1)
ubuntu@sync1:/etc/puppet$
Это происходит после того, как я запускаю sudo puppet apply manifest / site.pp.
Вот мой класс Rabbit:
# See https://github.com/puppetlabs/puppetlabs-rabbitmq
class my_rabbitmq ($environment, $type, $user, $password) {
# case $environment {
# staging: {
# #@todo
# }
# production: {
# #@todo
# }
# }
#
# case $type {
# sync: {
# #@todo
# }
# async: {
# #@todo
# }
# }
class { '::rabbitmq':
delete_guest_user => true,
version => '3.2.2',
}->
rabbitmq_user { 'richard':
admin => true,
password => 'richard_password',
provider => 'rabbitmqctl',
}->
rabbitmq_user_permissions { 'richard@/':
configure_permission => '.*',
read_permission => '.*',
write_permission => '.*',
provider => 'rabbitmqctl',
}
}
Я пробую это на виртуальной машине Ubuntu 12.04 LTS. Любые идеи? Это сводит меня с ума, я часами застрял, пытаясь понять это.
У меня тоже такая проблема. Причина в том, что после установки пакета rabbitmq-server в Ubuntu запускается экземпляр rabbitmq. Это сделано намеренно. К сожалению.
Что касается решения, я его еще не нашел.
редактировать
Я не знаю, так ли это для вас, но в моем случае я менял имя узла в марионетке с «кролик» на другое.
Краткое объяснение состоит в том, что, как я уже упоминал, установка rabbitmq-server вызывает запуск службы rabbitmq-server. По умолчанию он использует имя узла "кролик".
В моем случае появился puppet, настроил rabbitmq, а затем, прежде чем пытаться запустить службу, запустил '/etc/init.d/rabbitmq-service status', чтобы проверить, запущен ли он уже.
В идеальном мире ответом было бы «да», поскольку он фактически был запущен, но в этом случае сценарий '/etc/init.d/rabbitmq-service' использует настроенное имя узла для проверки и посмотрите, запущен ли экземпляр - и когда марионетка изменила имя узла в /etc/rabbitmq/rabbitmq-env.conf, это полностью нарушило способность служебного сценария определять, был ли он запущен, поэтому, конечно, сценарий возвращает 0, потому что он не может найти работающий экземпляр.
Затем Puppet пытается запустить новый экземпляр с новым именем узла, но это не удается, потому что только одна служба может владеть портом одновременно, а он был у запущенного экземпляра.
Чтобы исправить это, я снова установил RABBITMQ_NODENAME на «кролик», и все работает.
Я писал об этом здесь:
http://www.standalone-sysadmin.com/blog/2014/02/rabbitmq-on-ubuntu-via-puppet/
http://blog.zugschlus.de/archives/974-Debians-Policy-rc.d-infrastructure-explained.html
Debian часто критикуют из-за этого значения по умолчанию, и канонический ответ - использовать платформу политик, поставляемую с sysv-rc, чтобы избежать запуска служб. Поскольку этот механизм часто понимают неправильно, я пишу эту статью, чтобы внести в этот вопрос дополнительную путаницу.
(сообщение в блоге не мое)