Project Nagios Phase 1

As a continuation to my most recent blog post, I would like to announce that the first phase of Nagios implementation is pretty much at completion (e-mail alert has also been established). However, further research is required to get this project to where my colleagues I feel a high level of gratification has been achieved meeting overall expectation for this project. Moving forward we seek to integrate our present achievements, with Nagios across multiple platforms, thereby providing critical network alerts, whenever monitored systems have encountered a problem. This should be very interesting.

Intro to Nagios System Implementation

Hello folks I am back from my brief hiatus. Well today I will embark upon setting up the Open Source network monitoring tool Nagios, which I hope will allow myself and my colleagues to do some creative things. As a collective group we plan on testing the overall capabilities of this piece of software, which until now, has been unknown to us. It should be very interesting to see how things progress into this project. I will do my best to provide enough details, covering our progress.

Project Update: Working with Nagios

Hello folks! As a measure to offering a brief update to my current status, as far as course work goes. It has been confirmed that my new project will involve installing, configuring, and implementing monitoring capabilities to a number of different systems running on variety of architectures, within our current testing infrastructure.
Interestingly enough this project have peaked a lot of interests, and only time will tell if it can live up to the hype...ongoing developments will be updated via my blog. Stay tuned

Link to project details:Nagios

Repositories and Distribution

In this session I will discuss signing of rpm packages, which I had the opportunity of performing. In my previous blog I talked about using koji setup with the sshguard rpm package that I built from scratch. I used sshguard as the package of choice for rpm signing as well. In an effort to briefly chronicle the steps taken. I had to first create a gpg key using the following command: gpg --gen-key - then I added my gpg key macros with e-mail address details ex %_gpg_name <"email address goes here">.

I proceeded to sign the package with the command: rpm --addsign <packagename> - below is a screenshot that exhibits the process/outcome.

The second phase saw me create a "Yum Repositorty", which was pretty cool to do. I can now say that I have been able to build a package that is capable of being served to other users, for their own purposes.

To accomplish this I placed my signed package in the /var/www/html directory, thereby making it accessible via a web browser. Once that process was completed, I then created a new rpm to contain a new repo file and GPG key. I will now be working on a project, which I will create a discussion about in the next few weeks...should be interesting. I cannot disclose at the moment what this project may involved; as it tentative at the moment. I will keep you posted regarding this development.

Testing with Mock & Koji

Well folks, I am happy to say that both my "Mock and Koji" for sshguard has gone well! A brief run down, initially I had to install the mock software using "yum", then I had to add mock to the the mock group >>>using#: usermod  -G mock <username>, and then I started building with mock using#: mock -r fedora-12-x86_64 --rebuild <src. rpm> * Note: "fedora-12 linux based OS, x86_64 is the architecture employed on my system". The resultant from the above process generated a positive output.

For Koji the process was a bit similar, however, getting Koji setup involved a process of obtaining and setting up security certs for authentication (3 in total); as it is a core dependent to testing the use of Koji, on your system. Just to backtrack for a moment, the certs setup was done via my FAS2 account, and from that point, I ran the command syntax: #koji build  dist-f12  --scratch <src.rpm>. The following screenshots reflects successful testing of both tools against my sshguard package.

Here are links that offer credible information regarding the process involved with using both "Mock & Koji"  Infolink: Mock Info   ---> Using Koji

SSHGUARD SPEC FILE CREATION

I have finally conquered the first phase of my spec file creation, using a different approach. Consequently, as a result I had to place irssi spec file creation on the back burner. To briefly bring you up to speed, as to my quest in getting to this point. After series of thorough searching for packages to use for my spec file creation, I stumbled upon "SSHGUARD." My initial creation of an sshguard spec file from 'scratch', saw me encounter some problems. I tried building a spec file from an sshguard (sshguard-1.5rc4) release candidate version, which proved to be very unstable. By this, I mean I had a lot issues with error messages, such as incoherent version in %changelog section of spec file, which I wasn't able to resolve on my own, nor with the courteous assistance of my colleagues. So after consulting with one of my aforementioned colleagues, I was advised to try creating the spec file from a more stable version of  sshguard.
So I tried creating a specfile from earlier version of sshguard --> sshguard-1.4-1, but this package also had some hidden bugs with the man page. After running rpmlint -i <spec file>, I was prompted with an warning message >>warning: /usr/share/man/man8/sshguard.8.gz  `." not defined. With some additional text, which indicated that "This man page may contain problems that can cause it not to be formatted as intended."
At this point I was ready to try another package that might produce better outcome. However, in this instance persistency paid off! I decided to revert to an even earlier version of the aformentioned package, and fortunately for my efforts the results were finally favourable. Below are a couple screenshots that seeks to render the outcome mention previously.

I aim to keep you fully informed; as to my progress moving forward. Hopefully this stage will prove to be a much smoother ride.
Additional Information on sshguard can be found here: SSHGUARD

Rpmlint: Strip binaries and remove .packlist file

Upon posting my most recent blog post, which highlighted my current status, as far as building my irssi spec file goes. One of my colleagues, came across my post, and offered a viable solution to resolving the issues, to which I am currently encountering. Finally, I felt the turning point was near, as he (meaning my colleague) coincidentally ran into the same issue as I am during his spec file build for a different package. I was confident that this would be the turning point that would allow me to resolve all my issues, related to warnings, which I have been receiving...wishful thinking. However, to the credit of my colleague I was able to make the "Enchant library" happy, as it was able to employ hunspell (which is a dictionary) as a means to decipehering the language in the info message. So that is "fixed", but most of my warnings (14 of them) still lingers on.

At this time most of the warnings indicate that there are unstripped binaries/objects, and hidden files that should be deleted ".packlist."
Even after utilizing the -i switch with rpmlint, which is suppose to offer helpful information to resolving, some common issues, I am hindered from making any motivating progress. I can't believe it is taking this long to get past this point. :(

Rpmlint test warnings

Unfortunately, I am not the bearer of good news tonight. I have been shuffling between different tasks to resolve a number of warning messages, served by rpmlint. The interesting thing is that one of the warnings clearly indicates that there is a hidden file in /usr/lib64 directory path. However, whenever I issue the  rm -f command to remove the hidden file, rpmbuild -ba command is not happy. So I am back to square one, aggressively designating some research time to finish this phase of the build. At this point I am a bit concern that I maybe falling behind in getting my assigned task completed...mayday...mayday. Below is a screenshot, which renders my current warning messages.

I will be devoting some more time to see this assigned task through. Stay tuned.