Вот какая ошибка у меня возникает:
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 manifests/site.pp.
Вот мой класс «Кролик»:
# 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 VM. Есть идеи? Это сводит меня с ума, я застрял на несколько часов, пытаясь разобраться.
решение1
У меня тоже такая проблема. Причина в том, что при установке пакета 'rabbitmq-server' на Ubuntu,запускается экземпляр rabbitmq. Это задумано. К сожалению.
Что касается решения, то я его пока не нашел.
Редактировать
Не знаю, так ли это у вас, но в моем случае я менял имя узла в puppet с «кролик» на что-то другое.
Краткое объяснение заключается в том, что, как я уже упоминал, установка rabbitmq-server приводит к запуску службы rabbitmq-server. По умолчанию она использует имя узла 'rabbit'.
В моем случае появился puppet, настроил rabbitmq, а затем, перед попыткой запустить службу, запустил «/etc/init.d/rabbitmq-service status», чтобы проверить, запущена ли она уже.
В идеальном мире ответ был бы «да», поскольку он действительно был запущен, но в этом случае скрипт '/etc/init.d/rabbitmq-service' использует настроенное имя узла для проверки и выяснения, запущен ли экземпляр, а когда puppet изменил имя узла в /etc/rabbitmq/rabbitmq-env.conf, это полностью нарушило способность скрипта службы определять, запущен ли он, поэтому, конечно же, скрипт возвращает 0, поскольку он не может найти запущенный экземпляр.
Затем Puppet пытается запустить новый экземпляр с новым именем узла, но это не удается, поскольку одновременно портом может владеть только одна служба, а запущенный экземпляр им уже владеет.
Чтобы исправить это, я вернул RABBITMQ_NODENAME на «rabbit», и все заработало.
Я писал об этом здесь:
http://www.standalone-sysadmin.com/blog/2014/02/rabbitmq-on-ubuntu-via-puppet/
решение2
http://blog.zugschlus.de/archives/974-Debians-Policy-rc.d-infrastructure-explained.html
Debian часто критикуют за это значение по умолчанию, и каноническим ответом является использование фреймворка политики, поставляемого с sysv-rc, чтобы избежать запуска служб. Поскольку этот механизм часто понимается неправильно, я пишу эту статью, чтобы внести еще больше путаницы в этот вопрос.
(запись в блоге не моя)