zabbixapi gem fails to install (ubuntu 14.04)

[karolisc]

Hi Werner,

After enabling manage_resources zabbixapi gem fails to install.

Error 1:
`require': no such file to load -- mkmf (LoadError)
from extconf.rb:36

Error 2:
Error: Could not update: Execution of '/usr/bin/gem install -v 2.4.0 --no-rdoc --no-ri zabbixapi' returned 1: Building native extensions. This could take a while...
ERROR: Error installing zabbixapi:
ERROR: Failed to build gem native extension.

    /usr/bin/ruby1.9.1 extconf.rb

creating Makefile

make
sh: 1: make: not found

The module misses these packages:
sudo apt-get install ruby1.9.1-dev
sudo apt-get install build-essential

[dj-wasabi]

Hi Karolisc,

This is difficult, I would use the https://github.com/puppetlabs/puppetlabs-ruby as an requirement for the zabbix-server to solve this. Because the packages you name, aren't needed for the zabbix-* components iteself (and thus not configured in the server.pp).

But when I take a good look at the server.pp I noticed:

    if $::osfamily == 'redhat' {
      # With RedHat family members, the ruby-devel needs to be installed
      # when using an "gem" provider. If this package is not defined
      # we install it via this class.
      if ! defined(Package['ruby-devel']) {
        package { 'ruby-devel':
          ensure => installed,
        }
      }
      Package['zabbixapi'] { require => Package['ruby-devel']}
    }

This is actually piece of code which should be done by the ruby module and not my zabbix module. I don't remember why I did this and not making the ruby module as required ...

The ruby module is also only working on Debian and Red Hat, not on Ubuntu. As these are the 3 main operating systems the zabbix module supports, this is not an viable option...

Kind regards,
Werner

[karolisc]

Hi Werner,

I definitely agree with you that this should be a Lego blocks and the code should come from the ruby module.
I have looked at ruby module and I believe it does support Ubuntu too.
Snippet from https://github.com/puppetlabs/puppetlabs-ruby/blob/master/manifests/params.pp

    case $::operatingsystemrelease {
    '10.04': {
      $bundler_ensure   = '0.9.9'
      $ruby_package     = 'ruby'
      $rubygems_package = 'rubygems'
    }
    '14.04': {
      #Ubuntu 14.04 changed ruby/rubygems to be all in one package. Specifying these as defaults will permit the module to behave as anticipated.
      $bundler_ensure   = 'installed'
      $ruby_package     = 'ruby'
      $rubygems_package = 'ruby1.9.1-full'
    }

It looks like it supports Ubuntu 10.04 and Ubuntu 14.04, curious what happened to 12.04.
I have not tried the ruby module but it looks promising.

Btw.
https://forge.puppetlabs.com/puppetlabs/ruby/compatibility
states it does support: Ubuntu: 10.04, 12.04, 14.04

p.s.
I think at least the documentation should mentions something on this matter.

Karolis

[dj-wasabi]

Hi Karolisc,

Thanks for your clear and detailed answer. Will look into the ruby module. Can't promise it will be solved in the next few days (due to other (personal) stuff) but will look into it.

Kind regards,
Werner

[karolisc]

Hi Werner,

Before you made changes.... Some thoughts on the module future.
As you probably know, puppet moves to roles & profiles pattern. The forge modules should go this route as well. Do one thing but do it well.
So... puppetlabs does recommend "all" (as much as possible) the dependencies move out of the base module itself. The dependencies should be mentioned in the readme file and the implementation (roles) examples in the example directory. This way the module becomes very flexible as other people can install/configure dependent modules as they wish.

https://puppetlabs.com/presentations/practical-guide-modules-lauren-rother-puppet-labs-morgan-haskel-puppet-labs
from minute 6

Your thoughts?

Karolis

[dj-wasabi]

Hi Karolis,

Thanks for this update. I wasn't aware of this. I switched jobs some weeks ago and the new job don't use Puppet but Ansible. So lately all time was getting to know Ansible and not working on Puppet stuff.

I try to investigate this new roles & profiles this weekend and watch the video you provided. Do you think it is the correct way for puppet and the modules?

Kind regards,
Werner

[karolisc]

Hi Werner,

Sad to hear you are moving away from puppet. I just hope that the module won't be left unattended .

I believe that roles & profiles, stacks 1 currently are the only way to move forward. The idea behind all of this is simple, add one or more higher layers of abstraction.
I don't see other way how to accomplish real module re-usability only through atomic modules (Lego blocks) . The idea of atomic modules is clear but implementation could be hard. Due to the lack of the re-usability we have over 70 apache modules in the forge alone. Isn't it hilarious?. Let people them-self decide how to resolve module dependencies. Guide module users how you did solve it by examples and documentation. Please do not force people to use certain db or apache module.

If you look at modern applications all of them are some kind of application stack. So, with the above in mind I advocate to split current zabbix module into atomic zabbix module and another stacked-zabbix (profile) module.

p.s.
Congrats on new job proposal.

Karolis

[dj-wasabi]

Hi Karolis,

What you just described is one of the biggest advantages of using Ansible. I don't want to say that you should stop using Puppet and start using Ansible. First think I did with Ansible was creating an Zabbix role (Actually, now I have four.) but I discovered that there were some default plugins you could use (Like providers in Puppet).

So with the database part (mysql or postgres) I was able to create databases and users with just 2 "tasks" (https://github.com/dj-wasabi/ansible-zabbix-server/blob/master/tasks/postgresql.yml):

- name: PostgreSQL | Create database
  postgresql_db: name={{ server_dbname }}
                 state=present

- name: PostgreSQL | Create database user
  postgresql_user: db={{ server_dbname }}
                    name={{ server_dbuser }}
                    password={{ server_dbpassword }}
                    priv=ALL
                    state=present

This is the only part which I should care about with my Ansible role and which Postgres Ansible role the user wants to use is completely up to him (or her).

With this in mind, I don't think Puppet will come even close to this, unless they create a lot of Providers within the puppet core like Ansible. Don't get me wrong about Puppet, it is still an very good tool and I do miss some very nice little features in Puppet which aren't available Ansible (Like purging directory which contains configuration files which are managed by Puppet: When I create an vhost in http/conf.d/ and do an Ansible run, this file stays here whereas Puppet will delete it if it notice that is not an Puppet controlled file).

So I really like the idea that you can choose your own dependencies, but for now I use the puppetlabs modules for this module.

Kind regards,
Werner

p.s. Thanks! I'm not stopping with this module though, but the features/releases that I had planned will take some extra time now before getting release. This module is still: My Precious.. :-)

[dj-wasabi]

I just released v1.0.0 now. It is fixed.