Saturday, March 26, 2011

Sys Admin Tools 0.1 - Installing and Monitoring with Icinga

Welcome to the third and final part of my 0.1 release. In this post I will discuss the steps necessary in order to in install and configure Icinga from source – at a later time I will post about installation from an RPM which a colleague of mine is working on.


We must install the prerequisites for Icinga before we move on, these include; Apache, GCC Compiler, C/C++ development libraries, and GD development libraries. Use the following command (as root or sudo) in order to install the necessary packages for RedHat Based distributions;

            yum install httpd gcc glibc glibc-common gd gd-devel libjpeg libjpeg-devel
            libpng libpng-devel net-snmp net-snmp-devel

Once you have the prerequisites installed you will need to the follow the upcoming steps in order to successfully install your Icinga Core and Icinga Web from source code.

Create your new icinga user account and give it a password
useradd –m icinga && passwd icinga

Create the required group named “icinga”
groupadd  icinga

We will then need to create a new group called “icinga-cmd” and adding the systems web user and Icinga user to this group will allow for them to use the classic web interface to send commands to Icinga.
groupadd icinga-cmd
usermod –a –G icinga-cmd icinga
usermod –a –G icinga-cmd apache

Change your current working directory to a location of your choosing and download and extract the following tarball files (as root or sudo) – the purpose of this post we will use “/usr/src” as our directory;
cd /usr/src/

Files to download;

wget http://sourceforge.net/projects/icinga/files/icinga/1.3.0/icinga-1.3.0.tar.gz/download
wget http://sourceforge.net/projects/icinga/files/icinga-web/1.3.0/icinga-web-1.3.0.tar.gz/download
wget http://sourceforge.net/projects/nagiosplug/files/nagiosplug/1.4.15/nagios-plugins-1.4.15.tar.gz/download

Next we will extract the Icinga Core and prepare it for installation;

tar –zxvf  icinga-1.3.0.tar.gz
cd /usr/src/icinga-1.3.0/
./configure --with-command-group=icinga-cmd (use the --help arguments for additional options)
            make all

To complete a full installation of Icinga from source you can simply enter the following command; “make fullinstall” – the default installation directory is “/usr/local/icinga/”. (Note: Do not start Icinga yet!)

Before we continue we must change the email address inside of the “/usr/local/icinga/etc/objects/contacts.cfg file – this address is used for notification emails, review the other options in the file for additional changes you may want to make.

Icinga does come with a Classic Web Interface already built in, use the following commands to set up and configure your web interface that will be used to administer your Icinga server – if you would like to know how to install the new Icinga-Web follow this link.
cd /usr/src/icinga-1.3.0/
            make cgis
            make install-cgis
            make install-html
            make install-webconf

Create the icingaadmin account that will be logging into the Icinga classic web interface and then restart your web server – the account is determined by the entry found in the “/usr/loca/icinga/etc/objects/contacts.cfg” file’s “contact_name” option.

            htpasswd -c /usr/local/icinga/etc/htpasswd.users icingaadmin
            /etc/init.d/httpd restart

Because Icinga is backwards compitable with Nagios, it uses all of Nagios’ available plugins – these will need to be installed as well.

            cd /usr/src/nagios-plugins-1.4.15
            ./configure --prefix=/usr/loca/icinga --with-cgiurl=/icinga/cgi-bin --with-htmurl=/icinga --with-nagios-user=icinga --with-nagios-group=icinga
            make && make install


IMPORTANT: The commands above much also be executed on ALL machines that are to be monitored by Icinga. 

You may run into the always annoying encounters with SELinux settings on RedHat distributions, to perform an easy fix you can simply set your SELinux settings to permissive mode (setenforce 0) – the Icinga documentation provides the necessary commands in order to fix the SELinux issue, the commands are found below;
            
            chcon –R –t httpd_sys_script_exec_t /usr/local/icinga/sbin/
            chcon –R –t httpd_sys_content_t /usr/local/icinga/share/
            chcon –t httpd_sys_script_rw_t /usr/local/icinga/var/rw/icinga.cmd

This concludes the installation of your new Icinga server, you are now able to start your Icinga service – be sure to add it to your start up scripts;
            chkconfig --add icinga
            chkconfig icinga on
            /etc/init.d/icinga start

In order to access your Classic Web Interface you will need to redirect yourself to the following URL – http://localhost/icinga/ or http://yourdomain.com/icinga/
IMPORTANT: If iptables is enabled you MUST add the exception for port 80 to be accepted –     iptables –A INPUT –p tcp –m tcp –dport 80 –j ACCEPT


The following video will show a very small demonstration of what Icinga looks like after it is installed, with also a simple notification sample. Note that it is a demonstration on my virtual servers at home and is not yet ready for production. 



To be continued... Stay tuned for my 0.2 release where I will 
demonstrate Icinga in action, showing configuration 
and real-time monitoring on Fedora-ARM machines.



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

Tuesday, March 22, 2011

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;



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

Tuesday, March 15, 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

Tuesday, February 1, 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
wdiff-0.6.5 Files



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



Tuesday, January 18, 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
SRPM

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