Sys Admin Tools 0.1 - Icinga vs Nagios

Welcome to part two of my three part series of my 0.1 release. During this blog entry I will be discussing what I am sure many have asked when it comes to Network Monitoring Tools, “Nagios or Icinga?”. These two tools serve the exact same purpose, to monitor devices through a network, but what exactly is Nagios or Icinga?

The main differences between these two monitoring tools are strictly their architecture. Below is an image of both architectures with more information that will follow.

                              Icinga                                                         Nagios

When using the Nagios architecture each add-on that is applied will need to suit its interfaces and formats, for example if you need MySQL output you will need your own interface in order to translate it to the Nagios Core. Ultimately if you need to use 5 different output formats than you would need to write 5 different passive interfaces, making this the main structural difference between Icinga and Nagios.

However, because of Icinga’s API developers will ONLY need to know the API and program off of it. The API has the ability to translate any required output directly to the Icinga Core. Also, like Nagios, the Icinga Core communicates to a database via the Icinga Data Out Module (IDOMOD) and Icinga Data Out to Database (IDO2DB). However the IDODB differs significantly from the Nagios Data out Database (NDODB), not only does IDOMOD support the standard MySQL Database but also other popular ones such as Oracle and PostgreSQL.

Note: Icinga must be installed with IDOUtils, which is what allows Icinga to support databases outside of MySQL.

Each instance/component of the Icinga architecture (Core/WebUI&API/Database) can run on their own separate servers while still being connect to each other by a switch. The advantage to this is that if a component were to fail, for example the Icinga Core, you could have a second Icinga Core to take its job in case of emergencies.

And lastly, unlike the Nagios Web User Interface which runs on the same instance as the Nagios Core, Icinga Web is a standalone software which communicates with the database through the Icinga API.

The folks at Icinga have provided users with a comparison chart that allows for a simpler view of what Icinga has to offer over Nagios.

This concludes Part Two of my Three Part series of my 0.1 release, for any additional information regarding the difference between the Nagios and Icinga monitoring tools you can follow the links below;

http://www.icinga.org/about/nagios/

http://www.icinga.org/about/nagios/architecture/

---

Gian-Luca Casella -- Last Updated on Tuesday, March 22, 2011

Sys Admin Tools 0.1 - Analysis

This is part one of a three part posting of a project that I am working on a project for CDOT at Seneca College that deals with deploying certain System Administrative Tools not only on the various machines/architectures within the CDOT environment, but also on a series of machines within the Fedora community. This project requires us to implement, fine tune, deploy, and document the following Administrative Tools explicitly within CDOT; Icinga/Nagios, Func, and Puppet. If you are interested in knowing more about this specific project visit the SBR600 Project Page.[Sys Admin Tools for ARM Build Farm]

Throughout the course of this project I will be working with two other colleagues. Each one of them will be working on a different System Administration Tool. They have created in their own blogs so that anyone within the Fedora community and CDOT would be able to monitor their progress on their specific Administration Tools – the links to their blogs along with their respected System Administration Tool is listed below.

Pirathapan Sivalingam – Puppet

Tim Furzer  – Func

Gian-Luca Casella – Icinga/Nagios

Whats Next?
Before any actual work can take place the proper research of all of these System Administration Tools must be conducted in order to determine what the best choice is for CDOT’s machines, being a System Administrator you must realize that not everything is full proof, so some extensive testing will need to be done in order to have a very smooth deployment of these tools.

Because we will be working with a series of different machines, architectures, and operating systems both within the open-source community and specifically CDOT we need to be able to understand how their systems function. Since the machines within CDOT run on a wide variety of platforms we require vital information from them, such as their current Operating System and architecture which will allow us to completely replicate them ensuring that there is less room for error during implementation and deployment of these System Administration Tools.

If you would like to continue reading please redirect yourself to Part Two of this post, in it there will be discussion on the following; Icinga vs. Nagios.

---

Gian-Luca Casella -- Last Updated on Tuesday, March 15, 2011

Using Mock and Koji

---

Hello Readers,


The purpose of this post is to demonstrate a step-by-step procedure on how to use the mock and koji tools.

Mock is used to test that the BuildRequires for a package are accurate; creating a bare-bone chroot environment that only contains the basic build packages plus any packages that were indicated by the BuildRequires line in the spec file.

Koji is a client-server system that allows you to queue build with the Fedora build farm. This will allow you to test your packages by building them for different architectures.

Mock

Before we being we must install mock by using the yum install mock command.

Add yourself to the mock group giving you the ability to properly use the command: usermod –G mock <username>.

In order to use mock to test your package’s  BuildRequires you will need to use SRPMs that you have built in the past. The command syntax for using mock is, mock –r <architecture> <path-to-SRPM>.

NOTE: A list of architectures that mock is able to test can be found in the /etc/mock/ directory, and your systems default architecture for mock can be found in the /etc/mock/default.cfg file.

I will be using my SRPMs that I created in my previous post in order to demonstrate how the mock command is used. (gnupg-1.4.11-1.fc14.src.rpm and wdiff-0.6.5-1.fc14.src.rpm)

[gcasella@Fedora14  SRPMS]$ mock -r default wdiff-0.6.5-1.fc14.src.rpm

INFO: mock.py version 1.1.8 starting...

...
INFO: Start(wdiff-0.6.5-1.fc14.src.rpm)  Config(fedora-14-x86_64)

State Changed: lock buildroot

...

State Changed: running yum

State Changed: creating cache

State Changed: unlock buildroot

State Changed: setup

State Changed: build

INFO: Done(wdiff-0.6.5-1.fc14.src.rpm) Config(default) 3 minutes 43 seconds

INFO: Results and/or logs in: /var/lib/mock/fedora-14-x86_64/result

As you can see from the output above it took 3 minutes and 43 seconds for the mock command to complete its tests. Any errors that may arise can be found in the log files in your /var/lib/mock/<architecture>/results/ directory.

NOTE: It may seem that the mock command times out while it’s running yum. It is crucial to remember that each SRPM that is being tested for the first time will take a long time.

KOJ I

In order to use koji we must install the client software that will upload your package to the Fedora farm build. Koji requires you to have a Fedora Account System (FAS2) account, this is where you will be able to watch the status of your uploaded packages.

To install Koji use the command: yum install fedora-packager

Before using the Koji command line interface you need to perform an initial setup, luckily the Koji package includes a script which will automatically set up your Koji client. To perform the initial setup you must run the command as a non-super user: /usr/bin/fedora-packager-setup – Follow the on screen instructions and import the created certificate into your Firefox web browser. (Additional information can be found here)

The command koji build dist-f14 –scratch SRPM will allow you to queue a build request on the main koji server. The target (dist-f14) instructs koji to build the package using packages available in the Fedora 14 distribution and the –scratch option causes koji to build the package but not take it for the specific target (i.e. not include it in Fedora 14). Below is an example of the Koji command using my gnupg-1.4.11-1.fc14.src.rpm package;

[gcasella@Fedora14  SRPMS]$ koji build dist-f14 --scratch gnupg-1.4.11-1.fc14.src.rpm

Uploading srpm: gnupg-1.4.11-1.fc14.src.rpm

[====================================] 100% 00:00:44   4.50 MiB 102.81 KiB/sec

Created task: 2748409

Task info: http://koji.fedoraproject.org/koji/taskinfo?taskID=2748409

Watching tasks (this may be safely interrupted)...

...

2748409 build (dist-f14, gnupg-1.4.11-1.fc14.src.rpm): free -> open (x86-02.phx2.fedoraproject.org)

...
2748411 buildArch (gnupg-1.4.11-1.fc14.src.rpm, i686): free -> open (x86-14.phx2.fedoraproject.org)

You will notice in the output above that a Task ID will be given, with this task ID you can use the following command: koji watch-task <task ID>, alternatively you can monitor your tasks through the https://koji.fedoraproject.org website. An example of the koji watch-task <task ID> command is displayed below;

 [gcasella@Fedora14  SRPMS]$ koji watch-task 2748409

Watching tasks (this may be safely interrupted)...

2748409 build (dist-f14, gnupg-1.4.11-1.fc14.src.rpm): open (x86-02.phx2.fedoraproject.org)

  2748411 buildArch (gnupg-1.4.11-1.fc14.src.rpm, i686): open (x86-14.phx2.fedoraproject.org)

   ...

   ...

  0 free  2 open  1 done  0 failed

  2748411 buildArch (gnupg-1.4.11-1.fc14.src.rpm, i686): open (x86-14.phx2.fedoraproject.org) -> closed

  0 free  1 open  2 done  0 failed

2748409 build (dist-f14, gnupg-1.4.11-1.fc14.src.rpm): open (x86-02.phx2.fedoraproject.org) -> closed

  0 free  0 open  3 done  0 failed

2748409 build (dist-f14, gnupg-1.4.11-1.fc14.src.rpm) completed successfully

Where To Find My Files! 

I have provided links to my SRPMs from my previous posts along with a screen shot of my successful tasks performed on the Fedora build farm;

    Koji Server Screen Shot 

gnupg-1.4.11 Files

RPM

SRPM

wdiff-0.6.5 Files

RPM

SRPM

---

Gian-Luca Casella -- Last Updated on Tuesday, February 01, 2011

Creating an RPM Package

---

Hello Again Readers,

WARNING: All tasks performed in this post must NOT be done as the root user.

This post will discuss my experiences on creating an RPM Package based on the tarballs (packages) from my previous post -- gnupg-1.4.11 & wdiff-0.6.5, also including a step by step procedure on how I was successful.

Before beginning an RPM build you need to ensure you have the following installed; Fedora Packager (yum groupinstall "Fedora Packager"), this will automatically install rpmlint.

Note: yum-utils came pre-installed for me on Fedora 14 after performing a system update using the "yum update" command.

After the necessary packages were installed we then need to build the required RPM tree structure where RPM packaging will take place this can be done by using the "rpmdev-setuptree" command. This command will create the following directory structure;

[root@gcasella-fc14 ~]$ tree rpmbuild/
rpmbuild/
├── BUILD
├── RPMS
├── SOURCES
├── SPECS
└── SRPMS

Next I will provide the necessary commands and expected output to successfully build an RPM Package.


Step 1: I placed the source (.tar.gz) files into the ~/rpmbuild/SOURCES/ directory.

Step 2: Changed my current working directory to the ~/rpmbuild/SPECS/ directory and create a new spec file using the rpmdev-newspec <filename>.

Step 3: For the purpose of this post I will show a sample spec file that I had used for my gnupg-1.4.11.tar.gz RPM build. (The spec file can be found here http://fpaste.org/w9kr/)

Step 4: When the spec file was configured properly I ran the rpmbuild -ba <spec-filename> and waited for the build to complete. (Note: Some builds may take longer than others)

Step 5: If the build returned with no errors you should be able navigate to the ~/rpmbuild/RPMS/ and ~/rpmbuild/SRPMS/ directories and find your two newly created RPM Packages.

Step 6: I then tested my newly created RPM Packages by using the rpmlint  command on each of the following;

rpmlint ~/rpmbuild/SPECS/<spec-filename>
rpmlint ~/rpmbuild/RPMS/<new-RPM-package.rpm>
rpmlint ~/rpmbuild/SRPMS/<new-SRPM-package.src.rpm>

Note: The rpmlint command will show any errors/warnings that may be needed to fix before releasing.


Problems While Building

The only real problem I ran into while Building an RPM Package was during the actual build I would be told that a specific directory would not exist. I then noticed the "Name" and "Version" values MUST be the same as the name and version of the package. For example, if you use the gnupg-1.4.11.tar.gz package your spec file must contain the two pieces of data within the meta-data.

Name: gnupg

Version: 1.4.11

This was the only error that I've encountered throughout my attempts to build an RPM Package.


Where To Find My Files! 
gnupg-1.4.11 Files

RPM
SRPM

wdiff-0.6.5 Files

RPM

SRPM

---

Gian-Luca Casella -- Last Updated on Wednesday January 26th, 2011

Building from Source Code

For this post I have chosen to build the following two packages from the GNU Software Collection;

       GnuPG -- Version 1.4.11
       wdiff -- Version 0.6.5

These two packages can be obtained by using the following two commands;
       wget ftp://ftp.gnu.org/gnu/wdiff/wdiff-0.6.5.tar.gz
       wget ftp://ftp.gnupg.org/gcrypt/gnupg/gnupg-1.4.11.tar.gz

After I downloaded the two packages I extracted the contents using the tar -zxf command. I then issued the ./configure command in both directories that were created after extracting the two packages.

While using the ./configure command I ran into no problems, all the required dependencies were already installed on my Fedora 14 System. Once the ./configure command returned successful I used the time make command for both packages, the results of this command are listed below;

          gnupg-1.4.11
          real    0m38.872s
          user    0m32.281s
          sys    0m4.720s

The binary created during the make process is located in ./g10/gpg. Basic instructions on how to use this package you can type the ./g10/gpg --help command.

          wdiff-0.6.5
          real    0m1.545s
          user    0m0.932s
          sys    0m0.394s

The binary created during the make process is located in ./src/wdiff. Basic instructions on how to use this package you can type the ./src/wdiff --help command.

Glossary
./configure ---> Configures the package for the specific system.
time make ---> Determines how long it took for the make command to execute.

--------------------------------------------------------
Gian-Luca Casella