Part 2: Implement Lconf with icinga and icinga-web on CentOS 6

PLEASE READ THIS BEFORE CONTINUING!


Be still!

To do: SElinux stuff.
Updated August 20th, 2012


Someone involved in Icinga recommends NagiosQL, Nconf, Lconf, and icingen for web UI based generation and configuration of icinga cfg files. There are several other nagios/icinga “configurators,” but after comparing a few (thanks Michael), and coming from using Centreon for several years, I wanted a newer system that was easy to understand. Both NConf and NagiosQL feature interactive demo web sites that you can check out.

After making my way through an extremely painful Centreon to Nconf migration, I figured out that Nconf doesn’t allow you to apply a check_command to service templates. Due to the way I used nagios and plan to use icinga, this greatly hinders me enough that I am now “stuck” looking for an alternate solution. As present in the web demo, NagiosQL clearly has this desired ability.

I’ve polled the community to see if there is an Lconf demo site available. But, due to the flexible and thorough nature of icinga’s other products, I’m going to trust that the ability to assign a check_commands to a service template is present, and start documenting implementing Lconf into my infrastructure.

If you are familiar with using Group Policies within your AD structure, then you will love Lconf, as, according to the translation of the web page, Lconf functions in a similar parent-child manner.

Looks like a dude is in the middle of doing the same exact thing I’m doing now. This dude may create a write up on installing NagiosQL shortly.

Prerequisites for Lconf

Note that I write this up as if you had followed Part 1: Implement icinga and icinga-web on CentOS6 with SElinux

OpenLDAP Installation and Configuration (the right way)
Install openldap

yum -y install openldap-clients openldap-servers

Deal with the existing OpenLDAP LDIF configuration

cp -ar /etc/openldap/slapd.d /etc/openldap/slapd.d.orig
rm -rf /etc/openldap/slapd.d/*

Modify the LDAP configuration

echo 'BASE dc=icinga,dc=cfg' >> /etc/openldap/ldap.conf
echo 'URI ldap://SERVER.domain.local' >> /etc/openldap/ldap.conf

Configure the Berkeley DB backend for OpenLDAP

mkdir -p /usr/local/var/openldap-data
chmod 0700 /usr/local/var/openldap-data/
chown -R ldap:ldap /usr/local/var/openldap-data/
echo 'set_cachesize 0 268435456 1' > /usr/local/var/openldap-data/DB_CONFIG
echo '#aka .25 GB of http://docs.oracle.com/cd/E17276_01/html/api_reference/C/dbset_cachesize.html' >> /usr/local/var/openldap-data/DB_CONFIG
echo 'set_lg_regionmax 262144' >> /usr/local/var/openldap-data/DB_CONFIG
echo '#aka 262 bytes of http://docs.oracle.com/cd/E17276_01/html/api_reference/C/envset_lg_regionmax.html' >> /usr/local/var/openldap-data/DB_CONFIG
echo 'set_lg_bsize 2097152' >> /usr/local/var/openldap-data/DB_CONFIG
echo '#aka 2 MB of http://docs.oracle.com/cd/E17276_01/html/api_reference/C/envset_lg_bsize.html' >> /usr/local/var/openldap-data/DB_CONFIG

Generate the new config
Note that this section uses ldap_PASSWORD as the password to allow binding with the DN cn=Manager,dc=icinga,dc=cfg

echo 'include /etc/openldap/schema/corba.schema' > ~/temp_slapd.conf
echo 'include /etc/openldap/schema/core.schema' >> ~/temp_slapd.conf
echo 'include /etc/openldap/schema/cosine.schema' >> ~/temp_slapd.conf
echo 'include /etc/openldap/schema/duaconf.schema' >> ~/temp_slapd.conf
echo 'include /etc/openldap/schema/dyngroup.schema' >> ~/temp_slapd.conf
echo 'include /etc/openldap/schema/inetorgperson.schema' >> ~/temp_slapd.conf
echo 'include /etc/openldap/schema/java.schema' >> ~/temp_slapd.conf
echo 'include /etc/openldap/schema/misc.schema' >> ~/temp_slapd.conf
echo 'include /etc/openldap/schema/nis.schema' >> ~/temp_slapd.conf
echo 'include /etc/openldap/schema/openldap.schema' >> ~/temp_slapd.conf
echo 'include /etc/openldap/schema/ppolicy.schema' >> ~/temp_slapd.conf
echo 'include /etc/openldap/schema/collective.schema' >> ~/temp_slapd.conf
echo 'pidfile /var/run/openldap/slapd.pid' >> ~/temp_slapd.conf
echo 'argsfile /var/run/openldap/slapd.args' >> ~/temp_slapd.conf
echo 'idletimeout 60' >> ~/temp_slapd.conf
echo 'writetimeout 60' >> ~/temp_slapd.conf
echo 'password-hash {SSHA}' >> ~/temp_slapd.conf
echo 'modulepath /usr/lib/openldap' >> ~/temp_slapd.conf
echo '' >> ~/temp_slapd.conf
echo 'database config' >> ~/temp_slapd.conf
echo 'rootdn "cn=config"' >> ~/temp_slapd.conf
echo rootpw $(slappasswd -s ldap_PASSWORD) >> ~/temp_slapd.conf
echo '' >> ~/temp_slapd.conf
echo 'database bdb' >> ~/temp_slapd.conf
echo 'suffix "dc=icinga,dc=cfg"' >> ~/temp_slapd.conf
echo 'rootdn "cn=Manager,dc=icinga,dc=cfg"' >> ~/temp_slapd.conf
echo rootpw $(slappasswd -s ldap_PASSWORD) >> ~/temp_slapd.conf
echo 'directory /usr/local/var/openldap-data' >> ~/temp_slapd.conf
echo 'mode 0600' >> ~/temp_slapd.conf
echo 'lastmod on' >> ~/temp_slapd.conf
echo 'database monitor' >> ~/temp_slapd.conf
echo 'access to *' >> ~/temp_slapd.conf
echo '        by dn.exact="cn=Manager,dc=icinga,dc=cfg" read' >> ~/temp_slapd.conf
echo '        by * none' >> ~/temp_slapd.conf

Convert the config file to LDIF config

slaptest -f ~/temp_slapd.conf -F /etc/openldap/slapd.d/
#ignore the following errors:
##bdb_db_open: database "dc=icinga,dc=cfg": db_open(/usr/local/var/openldap-data/id2entry.bdb) failed: No such file or directory (2).
##backend_startup_one (type=bdb, suffix="dc=icinga,dc=cfg"): bi_db_open failed! (2)
##slap_startup failed (test would succeed using the -u switch)
chown -R ldap:ldap /etc/openldap/slapd.d/*
chown -R ldap:ldap /usr/local/var/openldap-data/

Make sure ldap starts on boot and start it

chkconfig slapd on
service slapd start

Configure the LDAP structure

Create the LDIF for the root structure

echo 'dn: dc=icinga,dc=cfg' > ~/temp_structure.ldif
echo 'dc: icinga' >> ~/temp_structure.ldif
echo 'objectClass: domain' >> ~/temp_structure.ldif

Add the structure

ldapadd -h localhost -x -D "cn=Manager,dc=icinga,dc=cfg" -f ~/temp_structure.ldif -w ldap_PASSWORD

Install Lconf CLI, schema and populate LDAP
Note that this section uses ldap_PASSWORD as the password to allow binding with the DN cn=Manager,dc=icinga,dc=cfg

yum -y install perl-LDAP
cd
wget https://www.netways.org/attachments/download/509/LConf-1.2.tar.gz #get the latest from https://www.netways.org/projects/lconf/files
tar zxvf LConf-*.tar.gz
cd LConf*
./configure --with-lconf-cli-user=icinga --with-lconf-cli-group=icinga --with-ldap-dn="dc=icinga,dc=cfg" --with-ldap-bind-dn="cn=Manager,dc=icinga,dc=cfg" --with-ldap-bind-password=ldap_PASSWORD && make && make install
ldapadd -h localhost -x -D "cn=config" -f ./src/netways.schema.ldif -w ldap_PASSWORD
/etc/init.d/slapd restart
ldapadd -h localhost -x -D "cn=Manager,dc=icinga,dc=cfg" -f ./src/base.ldif -w ldap_PASSWORD

Install Lconf icinga-web module
Lconf must access the icinga-web database, so note the following use of the icinga_web_DBUSER_PASSWORD from Part 1 section Configure icinga-web to use both the DB users passwords.

cd
wget https://www.netways.org/attachments/download/612/lconf-icinga-mod-1.2.3.tar.gz # locate the latest https://www.netways.org/projects/lconf-for-icinga/files
tar zxvf lconf-icinga-mod-*.tar.gz
cd lconf-icinga-mod
sed s/'dbpass = "icinga_web"'/'dbpass = "icinga_web_DBUSER_PASSWORD"'/ -i ./db.ini
./install.sh
#accept all the defaults by hitting enter a few times

Configure your administrative icinga-web users to access the LConf module
1) Log on to the icinga web UI by hitting https://SERVER/
2) On the menu near the top, go to Admin\Users
3) Click on your administrative user(s), and on the settings pane (on the right side), scroll to the bottom of the Credentials tab and check off: lconf.user, lconf.admin, and lconf.testcheck (just lconf.user for users)
4) Click the Save button in the lower right hand corner.
5) Log out

Configure the LConf icinga-web module to use LDAP
1) Log on to the icinga web UI by hitting https://SERVER/
2) On the menu near the top, go to LConf\LConf Connection Manager
3) Add the following connection:

Name: localhost\dc=icinga,dc=cfg
Bind DN: cn=Manager,dc=icinga,dc=cfg
Bind Pass: ldap_PASSWORD
Host: localhost
Port: 389
Root DN: dc=icinga,dc=cfg

4) Click the Check connection button
5) After you see the “Connecting succeeded!” message, click OK then Save
6) Below Save, click the + symbol to expand the Access pane
7) Add any groups or User to Selected then click the Save changes button

Check it out. You’re sort of done (clicking on the server connection in the right pane then clicking Connect will populate the DIT).

Configure the icinga-web Lconf module to export cfg_files
Create the destination folder for the cfg_files

mkdir /etc/icinga/lconf
chown icinga:apache /etc/icinga/lconf
chmod 775 /etc/icinga/lconf
sed s@cfg_file=/etc/icinga/objects/@#cfg_file=/etc/icinga/objects/@ -i /etc/icinga/icinga.cfg #disable all existing cfg_files
echo "cfg_dir=/etc/icinga/lconf" >> /etc/icinga/icinga.cfg
service icinga restart

Configure the export bash script:
** Note that the perl script copies the file /usr/local/LConf/etc/default-templates.cfg to the root of your config, in this case /etc/icinga/lconf. /usr/local/LConf/etc/default-templates.cfg is the file that must be edited for the changes to be resilient.

echo "\#\!/bin/bash" > /usr/local/LConf/lconf_deploy.sh
echo "sudo -u icinga /bin/touch /var/icinga/icinga.chk" >> /usr/local/LConf/lconf_deploy.sh
echo "sudo -u icinga /usr/local/LConf/LConfExport.pl -o /etc/icinga/lconf -v" >> /usr/local/LConf/lconf_deploy.sh
echo 'sudo -u icinga /etc/init.d/icinga reload' >> /usr/local/LConf/lconf_deploy.sh
chmod +x /usr/local/LConf/lconf_deploy.sh
chown icinga:icinga /usr/local/LConf/lconf_deploy.sh

Configure permissions

yum -y install sudo
echo "" >> /etc/sudoers
echo "" >> /etc/sudoers
echo "## BEGIN: Lconf sudo" >> /etc/sudoers
echo "User_Alias      LCONF=apache,icinga" >> /etc/sudoers
echo 'Defaults:LCONF !requiretty' >> /etc/sudoers
echo "# allow icinga to reload the icinga config" >> /etc/sudoers
echo "LCONF ALL=(icinga) NOPASSWD: /etc/init.d/icinga reload" >> /etc/sudoers
echo "# allow icinga to touch the diag file" >> /etc/sudoers
echo "LCONF ALL=(icinga) NOPASSWD: /bin/touch /var/icinga/icinga.chk" >> /etc/sudoers
echo "# allow icinga to test the config" >> /etc/sudoers
echo "LCONF ALL=(icinga) NOPASSWD: /usr/bin/icinga -v *" >> /etc/sudoers
echo "# allow apache to execute the deployment bash script" >> /etc/sudoers
echo "LCONF ALL=(apache) NOPASSWD: /usr/local/LConf/lconf_deploy.sh" >> /etc/sudoers
echo "# allow icinga to execute the deployment perl script" >> /etc/sudoers
echo "LCONF ALL=(icinga) NOPASSWD: /usr/local/LConf/LConfExport.pl -o /etc/icinga/lconf -v" >> /etc/sudoers
echo "## END: Lconf sudo" >> /etc/sudoers

Clear the Agavi cache for the icinga-web LConf module

/usr/local/icinga-web/bin/clearcache.sh

Dealing with default-templates.cfg
Note that the export script (/usr/local/LConf/LConfExport.pl) refers to the following file for some definitions: /usr/local/LConf/etc/default-templates.cfg
Therefore, you need to declare whatever objects are contained therein.

I have generated the objects using the lconf web UI and exported an LDIF file with ldapsearch, which you can import to your LDAP easily.

Once these are imported, you should be able to export the config using the web interface.

LDIF of command definitions of centreon and nagios plugins
There are no command definitions present in the baseline Lconf LDIF, as there shouldn’t be. In Part 1, we installed both the centreon plugins (from SVN) and the nagios plugins into /usr/local/nagios/libexec/ (aka what icinga knows as the variable $USER1$ which is set in /etc/icinga/resource.cfg).

In order to use these commands freely with services in Lconf, there must be command objects present within the LDAP structure that LConf reports. In fact, these definitions must be present below the dc=icinga,dc=cfg\LConf\IcingaConfig (aka ou=IcingaConfig,ou=Lconf,dc=icinga,dc=cfg) in order for them to be exported by the LConf export script.

I have gone through the process to produce an LDIF for these commands that you can import into your LDAP structure.

Okay… let’s create our hosts and services already!
NOT DONE!
If you have a pool of servers (for example), you will likely end up wanting to apply several of the same services to them all, while you might want to apply certain services to a subset.

Lconf is designed with a tree inheritance structure in mind, which, in my opinion, is a great advantage for ease of management.

Understanding tree-based inheritance:
If you create a service object in a structural object, it will apply the service object to any object that shares its same tree level and tree levels below it.

To modify attributes of all child objects, you adjust properties of the structural object:

1) Create the structuralobject .\IcingaConfig\WindowsServers
2) Add a host below this.
3) Edit the properties of .\IcingaConfig\WindowsServers
4) You can adjust properties here and they will be inherited by the children.

You can see that almost every field available to control from a structural object.

Templates by alias:
You can easily create an alias object that links to another structural object by copying the example-alias out of the .\Examples\ container.

If you understand tree-based inheritence you should understand the effect an alias object, or what we can consider to be a “link”.

Using an alias object will take whatever objects you have in the aliased (target) structural object and apply it to the structural object containing the alias object.

1) Create a structural object .\Templates\default-windows
2) Add a service object within default-windows with the following properties:

cn: PING
lconfservicecheckcommand: check_ping!3000,80%!5000,100%

3) Make a copy of the example-alias object under .\Examples by clicking and dragging to the target of .\IcingaConfig\WindowsServers
4) Modify the properties example-alias object as:

ou: linkto_default-windows
aliasedobjectname: ou=default-windows,ou=Templates,ou=LConf,dc=icinga,dc=cfg

When you generate the config, you will see that any hosts contained in .\IcingaConfig\WindowsServers will have a service ‘PING’.

Why use both structural object property inheritance and linked alias objects?
What’s that you ask? What if you combine the two in an overlapping fashion?

Let’s take a look at how they work together:

Given:

  • The service object is child of host object. This service object has a cn ‘PING’. It has an lconfservicecheckcommand of check_ping!1000!3000.
  • The host object is in the same container as a linked alias. The target structural object of the linked alias as a service object which has a cn ‘PING’. It has an lconfservicecheckcommand of check_ping!3000!5000.
  • The structural object that is the parent of the host object has a lconfservicecheckcommand of check_ping!2000!4000.

Result:

  • Host receives a check_command check_ping!1000!3000

English please: The check_command assigned to the service object that’s directly assigned/child to the host will always win!

Given:

  • The host object is in the same container as a linked alias. The target structural object of the linked alias as a service object which has a cn ‘PING’. It has an lconfservicecheckcommand of check_ping!3000!5000.
  • The structural object that is the parent of the host object has a lconfservicecheckcommand of check_ping!2000!4000.

Result:

  • Host receives a check_command check_ping!3000!5000

English please: The check_command assigned to the template that is a sibling of the host will win!

Given:

  • The structural object that is the parent of the host object has a lconfservicecheckcommand of check_ping!2000!4000.

Result:

  • Host receives nothing.

English please: The check_command of the host isn’t an lconfservicecheckcommand, it’s an lconfHostCheckcommand.

Conclusion:

  • Use properties of lconfStructuralObjects to control settings for child objects.
  • More specific wins. Explicit object setting > Alias > Structural object

A decent strategy of design:

Note that Malte pointed out in a below comment the very useful script that `/usr/local/LConf/bin/LConfImport.pl` that takes `objects.cache` as input and imports objects, services (etc) into the LDAP tree.

I designed my tree as this:

The root:

It’s my preference to always create a root object and place all my other objects in there. You could just populate all your objects into the parent of this root object itself.

This is the parent of all the other objects below it. It is a structuralobject, which allows me to set omnipresent settings to objects that are stored below/within it (this excludes service definitions in my instance, but more on that later).

The structuralobject properties I set here are: lconfhostcontacts and lconfservicecontacts. The reason I do this because I happen to have a contact (my email) that I wish to receive ALL alerts for all hosts and services that are contained below the structuralobject.

I then create a structuralobject for each site.
Below this I create a structuralobject for each host type.

Service templates:

Below Templates I created a structuralobject that contains service definitions per host type.

I then clone the example-alias to the site\host type structureobject that contains the host definitions (above… not the Templates), and adjust the aliasedobjectname in the clone of example-alias to the dn of the Template.

Specific services:

I create any service objects that aren’t found in the service templates within/below hosts. For instance, this host is the only host that has a disk E:, so it’s not applicable for all Windows hosts, therefore I excluded it from the structuralobject svctemplateWindows.

Creating your contacts objects:

I decided to create my contacts objects within/below the default_conf structuralobject. This is kind of sloppy, but it works.

With reference:

  1. Paul Webb
    December 24, 2012 at 9:54 am

    Hi there,

    First, love these posts. They made things way clearer than they ever were for me. I went through the bottom of the LConf one and decided I needed to stop and make sure things worked thus-far before proceeding further.

    With that said, I’m having trouble getting my config from LConf to export to the /etc/icinga/lconf directory that it should appear in.

    I have commands defined, services defined, a host defined, and then aliases for the services under the host entry (Happy to send you a screenshot if that will help)…

    I do the Export Config option and get no errors. I even tried running it from the command line, and here’s what I see:

    [root@{host} /]# sudo -u icinga /usr/local/LConf/LConfExport.pl -o /etc/icinga/lconf
    OK - No errors
    [root@{host} /]# cd /etc/icinga/lconf/
    [root@{host} lconf]# ls -l
    total 16
    -rwxr-x--- 1 icinga icinga 6389 Dec 24 09:50 default-templates.cfg
    drwxr-xr-x 2 icinga icinga 4096 Dec 24 09:50 hostgroups
    drwxr-xr-x 2 icinga icinga 4096 Dec 24 09:50 servicegroups
    
    [root@{host} lconf]# cd hostgroups/
    [root@{host} hostgroups]# ls -l
    total 0
    [root@{host} hostgroups]# cd ..
    
    [root@{host} lconf]# cd servicegroups/
    [root@{host} servicegroups]# ls -l
    total 0
    [root@{host} hostgroups]# cd ..
    

    The default-templates.cfg file looks empty too. Got any suggestions on what I should be looking for?

    Thanks, in advance!

    • December 24, 2012 at 10:51 am

      Thanks for the compliment! It sounds like there’s no data where that perl script is looking, hence no errors and no data. I’m on the road right now, but take a look in that direction.

      Also don’t forget to keep an eye out for the “securing your network” project, which will help you guys deliver additional layers of security to your clients.

  2. Pemontto
    April 11, 2013 at 4:35 pm

    Hey there, once again an excellent tutorial! One minor issues I had was the icinga user being set to /bin/nologin which prevented running commands and in turn prevented config export working. Couldn’t see a step in this or the previous tutorial, easiest way to do this is:

    chsh -s /bin/bash icinga
    
    • April 11, 2013 at 4:41 pm

      Thanks for the praise!

      Hmm… Are you speaking of “external commands” in the icinga-web UI? If not, for the purpose of running the Lconf export script via the Lconf web UI, I use `sudoers` to grant access to the users `icinga` and `apache` to run several commands.

      My shells are all set to `/sbin/nologin/`. Did you try to use `sudoers`?

      Also, SELinux might be causing issues?

  3. Darren
    April 18, 2013 at 4:58 am

    Hi,

    My icinga-web is running on OpenSUSE 12.2 How to install and configure openldap + lconf on OpenSUSE?

    Thanks.

    • April 18, 2013 at 6:52 am

      I don’t have any experience with OpenSUSE, so I’d simply be googling the answer for you. Take a look at some other write-ups. I’m sure they’re out there.

  4. Vicente
    June 19, 2013 at 10:38 am

    Hi,

    I have an icinga server with many servers and services. Is it possible to migrate the icinga configuration files to lconf?

    Thx.

    • June 20, 2013 at 7:54 am

      [This contains erroneous information. See Malte’s comment below.]

      Unfortunately, to my knowledge there isn’t a specific solution for this. It would be an afternoon’s work to write something that took in cfg and generated ldif files. This would put objects into ldap, but not in any order. To be honest, it will take some grunt work, but it probably makes sense to recreate your objects, as the relationships might be of a different design.

      • July 15, 2013 at 10:50 am

        Hello Vicente and mbrownnyc,

        You don’t have to write a new import script. I´ve installed Lconf 1.3.0 and it already has an perl import script, it´s called LConfImport.pl.

        And it´s works like this:

        /usr/local/LConf/bin/LConfImport.pl -o /usr/local/icinga/var/objects.cache -v

        It imports all hosts, services, hostgroups, servicegroups, contacts, contactgroups, commands, timeperiods and templates, but it skipped my escalations :)
        The -v verbose option is usefull for debugging, because the script is not perfect. It works very well, but it struggled with my selfmade check scripts.

        The imported tree is not perfect and but you just have to rearrange it, the script saves a lot of time!

        @mbrownnyc: Thank you very much for your icinga how-tos, they saved me a lot of time too!

  5. October 4, 2013 at 5:52 pm

    Perhaps Malte can help with this issue: I’m trying to install more recent versions of Lconf and am not finding a db.ini file or another file I can enter the LDAP DB password into prior to installation.

    • October 17, 2013 at 4:35 am

      Hello music2myware,
      You have a running openLDAP Server and already imported the LConf Schema and now you want to install “LConf” and then “LConf for icinga-web”, right? (notice the difference between LConf and Lconf for icinga-web!!!)

      You set the ldap credentials as arguments when you configure and build your LConf:

      "./configure --with-lconf-cli-user= --with-lconf-cli-group= --with-ldap-dn="dc=netways,dc=org" --with-ldap-bind-dn="cn=,dc=netways,dc=org" --with-ldap-bind-password="
      

      This wiki maybe answer your questions with the recent Lconf:
      https://www.netways.org/projects/lconf/wiki

      And this is the Lconf for icinga-web wiki, also very usefull:
      https://www.netways.org/projects/lconf-for-icinga/wiki

      If this doesn’t work for you, a little bit more information about your setup would be helpful!

  6. Daniel
    November 13, 2013 at 9:02 am

    Hello All
    Very nice tutorial , following this it was very easy to set up LConf which quite an impressive tool.
    I am facing with a small problem , perhaps someone can guide me , what to do :

    • i installed the latest lconf 1.3.0 from netways site , everything works great except for exporting to cfg script
    • when i search the lconf tree using ldapsearch , all elements including cn’s can be displayed correctly
    • when i am using the lconfexport.pl script it is only creating empty directories , meaning it can only search the OU’s in the tree, so it cannot be a problem of credentials
    • do you know perhaps , what should i modify ?
      thank you

      * with ldapsearch

      # search result
      search: 2
      result: 0 Success
      # numResponses: 115
      # numEntries: 114
      

      * using lconfexport.pl

      su icinga -c '/usr/local/LConf/bin/LConfExport.pl -o /etc/icinga/lconf -v -d --full-export'
      Wed Nov 13 16:02:32 2013 | Debug: REMOVE OLD CONFIG: start - folder: /etc/icinga/lconf
      Wed Nov 13 16:02:32 2013 | Debug: REMOVE OLD CONFIG: finished - folder: /etc/icinga/lconf
      Wed Nov 13 16:02:32 2013 | Verbose: LDAP CONNECT: connect to host: 127.0.0.1, User: cn=Manager,dc=icinga,dc=cfg, Pass: ******
      Wed Nov 13 16:02:32 2013 | Verbose: LDAP SEARCH: SEARCH 'objectclass=*' ON 'ou=lconf,dc=icinga,dc=cfg'
      Wed Nov 13 16:02:32 2013 | Verbose: LDAP SEARCH: SEARCH 'ou=*' ON 'ou=Examples,ou=lconf,dc=icinga,dc=cfg'
      Wed Nov 13 16:02:32 2013 | Verbose: CREATE DIR: /etc/icinga/lconf/example-structural-object/
      Wed Nov 13 16:02:32 2013 | Verbose: LDAP SEARCH: SEARCH 'ou=*' ON 'ou=example-structural-object,ou=Examples,ou=LConf,dc=icinga,dc=cfg'
      Wed Nov 13 16:02:32 2013 | Verbose: LDAP DISCONNECT: disconnected from ldap host
      OK - No errors
      

      In /etc/icinga/lconf , only the Examples directory is created , but nothing from the already created cn . elements

  7. Malte
    November 13, 2013 at 10:07 am

    Your icinga config has to be under:

    'ou=IcingaConfig,ou=lconf,dc=icinga,dc=cfg’
    

    in the ldap tree.
    This subtree will be exported by the LConfExport.pl – afaik

    And the ldap export directory and the icinga configuration directory have to be the same, and also must be recursively readable by icinga.

    This happened in the “Create the destination folder for the cfg_files” part in line 4.

  8. Daniel
    November 13, 2013 at 11:39 am

    thank you for the fast answer

    yes you are right , the same path need to be also defined in the config.pm

    updated , but the same

    $cfg->{ldap}->{server}                   = '127.0.0.1';
    $cfg->{ldap}->{prefix}                   = 'lconf';
    $cfg->{ldap}->{binddn}                   = 'cn=Manager,dc=icinga,dc=cfg';
    $cfg->{ldap}->{bindpw}                   = 'xxxxxxxx';
    $cfg->{ldap}->{rootNode}                 = 'lconf';
    #$cfg->{ldap}->{rootDN}                   = 'ou='.$cfg->{ldap}->{rootNode}.',dc=icinga,dc=cfg';
    $cfg->{ldap}->{rootDN}                   = 'ou=lconf,dc=icinga,dc=cfg';
    #$cfg->{ldap}->{tls}->{verify}           = 'require';
    #$cfg->{ldap}->{tls}->{cafile}           = '/etc/openldap/CA.crt';
    #$cfg->{ldap}->{tls}->{sslversion}       = 'tlsv1';
    
    
    #
    # LConfExport.pl
    #
    $cfg->{export}->{user}                   = 'lconf';
    $cfg->{export}->{exportDN}               = 'ou=IcingaConfig'; # below rootDN
    $cfg->{export}->{tmpdir}                 = '/usr/local/LConf/tmp';
    $cfg->{export}->{onlydiffs}              = 0;
    $cfg->{export}->{childs}                 = 4;
    

    *output from lconfexport

    Wed Nov 13 18:36:35 2013 | Debug: REMOVE OLD CONFIG: start - folder: /etc/icinga/lconf
    Wed Nov 13 18:36:35 2013 | Debug: REMOVE OLD CONFIG: finished - folder: /etc/icinga/lconf
    Wed Nov 13 18:36:35 2013 | Verbose: LDAP CONNECT: connect to host: 127.0.0.1, User: cn=Manager,dc=icinga,dc=cfg, Pass: ******
    Wed Nov 13 18:36:35 2013 | Verbose: LDAP SEARCH: SEARCH 'objectclass=*' ON 'ou=lconf,dc=icinga,dc=cfg'
    Wed Nov 13 18:36:35 2013 | Verbose: LDAP SEARCH: SEARCH 'ou=*' ON 'ou=IcingaConfig,ou=lconf,dc=icinga,dc=cfg'
    .......................................
    .................................
    Wed Nov 13 18:36:35 2013 | Verbose: LDAP DISCONNECT: disconnected from ldap host
    OK - No errors
    

    or do you mean, that on the system you need to have the same folder structure like `/icingaconfig/lconf/icinga/cfg` ?

  9. Daniel
    November 14, 2013 at 9:38 am

    Problem solved:
    It was not a problem of directory creation. The step of creating cfg files was not reached.

    • the script cannot create cfg files because there was nothing found in the ldap.
    • I modified some search filters in the LDAPsearch statements, and now it seems to be ok. Using verbose and debug mode for lconfexport shows no error.
  10. satya krishna
    May 18, 2015 at 10:17 pm

    Hi thanks a lot for this documentation!!!!!!
    after configuring i tried to add hosts and services in Lconf but am not able to see in icinga-web.could you please help on this.

    • satya krishna
      May 18, 2015 at 10:41 pm

      am using snmp as a plugin for servers

      • May 19, 2015 at 8:06 am

        Hello Satya!

        Happy you found this documentation useful. However, it is very outdated. Lconf does support outputting icinga2 configurations via a post-processing script that is included in the current packages. I am not at all familiar with this.

        You can communicate further with the community at http://www.monitoring-portal.org/wbb/index.php and #icinga on freenode.

        Good luck!

        Matt

  11. Mohd Arif
    May 19, 2015 at 4:36 pm

    I am getting below errors while adding the LDIF files to the DN.

    ldapadd -h localhost -x -D "cn=Manager,dc=icinga,dc=cfg" -f ./src/base.ldif -w ldap_PASSWORD
    
    dding new entry "ou=IcingaConfig,ou=LConf,dc=icinga,dc=cfg"-
    ldap_add: Invalid syntax (21)-
    additional info: objectClass: value #0 invalid per syntax
    

    I went go ahead and perform other steps to complete the installation but from Icinga-web when i am trying to add any OU or Host it says to me Invalid syntax.

    Thanks in advance for helping me on this.

    Thanks & Regards,
    Mohd Arif

    • May 20, 2015 at 6:37 am

      I’m not sure what the problem is. Have you troubleshot the error?

      • satya krishna
        December 30, 2016 at 5:23 am

        Hi

        Ingraph is not showing graphs for 1 hour and 4 hours. I followed same steps provided by this link.

        Can any one help me on this where I did mistake?

        Thanks in advance.

  12. sk
    May 19, 2015 at 11:02 pm

    Thanks Matt!!!!

    Could you please provide any any useful links for monitoring EMC, Celera, Clarrion storag devices for Icinga-web

    • May 20, 2015 at 6:37 am

      Sorry I can’t help you here.

  13. Mohd Arif
    February 17, 2017 at 11:45 am

    Hello Matt,

    Today i check the E-mail in my INBOX for this post conversation.
    You you can Monitor EMC celera by NRPE. first you need to install NRPE in control station.. There are many plugin available on Nagios Exchange to Monitior celera with NRPE.
    Clarrion you can monitor with the help of the navisphere. yopu need to install the navisphere
    in your monitoring system and run the plugin by providing the credentials.

  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: