Erlang / RabbitMQ fails to install on Amazon Linux 2

[marji]

While provisioning a sensu master, I get an error:

TASK [sensu : Ensure Erlang & RabbitMQ are installed] **************************************************************************************************************************
fatal: [npsensu]: FAILED! => {"changed": false, "msg": "Error: Package: erlang-20.3.8.14-1.el7.centos.x86_64 (rabbitmq-erlang)\n           Requires: libtinfo.so.5()(64bit)\n", "rc": 1, "results": ["Loaded plugins: extras_suggestions, langpacks, priorities, update-motd\nResolving Dependencies\n--> Running transaction check\n---> Package erlang.x86_64 0:20.3.8.14-1.el7.centos will be installed\n--> Processing Dependency: libtinfo.so.5()(64bit) for package: erlang-20.3.8.14-1.el7.centos.x86_64\n---> Package rabbitmq-server.noarch 0:3.7.9-1.el7 will be installed\n--> Finished Dependency Resolution\n You could try using --skip-broken to work around the problem\n You could try running: rpm -Va --nofiles --nodigest\n"]}

My Ansible version (executing on Ubuntu 18.04)

ii  ansible                                  2.5.1+dfsg-1
ansible                                                     2.5.1+dfsg-1
$ ansible --version
ansible 2.5.1

A Snippet of my playbook:

# file: masters.yml
- hosts: sensu_masters
  remote_user: "{{ remoteuser | default('ec2-user')}}"
  become: yes
  become_user: root
  gather_facts: true

  vars:
  - sensu_master: true
  - sensu_include_dashboard: true                                               
  - rabbitmq_server: true
  - redis_server: true

  roles:
  - { role: "sensu", epel_version: 7 }
  # epel_version needs to be explicitly set, otherwise it installs epel 6

The server:

NAME="Amazon Linux"
VERSION="2"
ID="amzn"
ID_LIKE="centos rhel fedora"
VERSION_ID="2"
PRETTY_NAME="Amazon Linux 2"
ANSI_COLOR="0;33"
CPE_NAME="cpe:2.3:o:amazon:amazon_linux:2"
HOME_URL="https://amazonlinux.com/"

[marji]

Looking at /var/log/yum.log after I overcome this problem:

Dec 15 05:12:42 Installed: epel-release-7-11.noarch
Dec 15 05:14:41 Installed: jemalloc-3.6.0-1.el7.x86_64
Dec 15 05:14:41 Installed: redis-3.2.12-2.el7.x86_64
Dec 15 05:18:54 Installed: socat-1.7.3.2-2.amzn2.0.1.x86_64

Dec 15 05:36:08 Installed: ncurses-compat-libs-6.0-8.20170212.amzn2.1.2.x86_64

Dec 15 05:36:11 Installed: erlang-20.3.8.14-1.el7.centos.x86_64
Dec 15 05:36:11 Installed: rabbitmq-server-3.7.9-1.el7.noarch
Dec 15 05:40:06 Installed: 1:uchiwa-1.4.1-1.x86_64

It shows it was the ncurses-compat-libs missing.

And this is the cause: https://github.com/sensu/sensu-ansible/blob/2.6.0/tasks/Amazon/rabbit.yml#L57 as this code disables other repositories, therefore the dependency package cannot be installed.

Working workaround (in my playbook):

  pre_tasks:
  - name: sensu bug workaround                                                                                                                                                                                                    
    yum:
      name: ncurses-compat-libs
      state: present

[marji]

I think this PR https://github.com/sensu/sensu-ansible/pull/192 fixes it.

[jaredledvina]

Hey @marji,

Thanks for the issue, Inspec has been busted on Amazon Linux 2 for a while now. However, I opened up https://github.com/inspec/inspec/pull/3657 which got released in 3.1.3: https://github.com/inspec/inspec/blob/master/CHANGELOG.md#v313-2018-12-13

I've opened up https://github.com/sensu/sensu-ansible/pull/193 which should get us up to the latest version and ensure we're fully testing Amazon Linux 2. Once that's in, I'll re-run testing against your branch to see how it looks. Sorry for the trouble!

[jaredledvina]

Hm, interesting, I'll note that w/ my PR above, the Amazon Linux 1 and 2 integration tests passed, and didn't fail at this step: https://travis-ci.org/sensu/sensu-ansible/jobs/469044480#L915-L945

[jaredledvina]

The integration tests continue to pass for both Amazon Linux 1 and 2 off of the latest master. I'm unable to locate how this could be happening locally but, I expect it might be something to do with either a custom repo serving up a different release of erlang in addition to the repo's we lay down via this role or, potentially our integration Docker images are shipping with some other difference.

However, since I can't seem to reproduce this locally, I'll close the issue. Feel free to re-open this if you'd like to revisit it though. Ideally, we could have a way to reproduce the issue to test again.