Icinga2 + Icingaweb2 beta3 on Centos 7

After customizing Cacti with some plugin, I thought it would be enough for our needs.

Actually, it turns out I have to install a Nagios (need to perform checks using customized commands) and I discovered Icinga, a fork from Nagios.

I used to work with Nagios in the past, so I decide to try Icinga (2 birds 1 stone).

So I installed Icinga2 with Icingaweb2 (which is still in beta, but most features are already working).

What I noticed during the setup :
- Icinga2 installation guide is complete.
- Icingaweb 2 installation guide still need to be completed.

For example, you need to know that icingaweb 2 need its own database for authentication (if database option is selected). Just compared the icinga2 sql schema and the icingaweb 2 sql schema (located in icingaweb2/etc/schema/), and you will see the tables are different.
And during the web setup, the user wasn't created. So I created a dedicated db for icingaweb2 and I imported the sql schema to the database (mysql -u root -p icingaweb_db < /icingaweb2/etc/schema/mysql.sql).

I installed the monitoring-plugins and set the define the path on one Icinga config file.

Finally, it works.

Cacti sur CentOS 7

Cela fait quelques semaines maintenant que je suis au soleil. J'entendais souvent les collègues se plaindre du réseau, alors j'ai décidé de mettre en place un petit serveur Cacti pour voir ce qu'il en ait exactement.

Donc voici un petit condensé des commandes pour mettre en place le Cacti sur CentOS7.

As a Network Forensic

Here are my first lines about how investigating on our production network.

One of my tasks in my current job is to do some "network forensic".

As a CSI agent :)
picture from http://www.critikeurs.fr/wp-content/uploads/2010/06/CSI.jpg

As a CSI agent with a crime, we have to investigate and find the cause of some network problems: link down, bad performance or lost packets (in trading rooms, the packet loss may even be more critical, it is hard to believe that banks can lose a lot of money by losing a packet). 

To be able to provide a cause to network problems, here some clues to check:

Getting the connector type on your Cisco devices using SNMP

At the end of 2013, the company where I'm currently working at, needed to know how many unused connectors are on our running devices (mainly Cisco devices).

So, I needed to know what kind of information I could get from these devices.

The simplest way to do that would be to log on each device and then check the unused connector with a show command. We could make a script that will perform the task and return the connector (unfortunately there were a lot of devices to check on). The problem with this method is that using the script or using the manual way, we have to log on the device, and the company has a "no connection" policy (and that makes you realize that the Network is a really sensible thing on the general infrastructure).

I was working on a script using SNMP polling to make my own "show interface status" merged with the "show ip int brief" and "show etherchannel summary" command, and so I looked on how the connector information was stored in the MIB...