Weird the way we find solutions: Story of CloudFlare, CSF, DAAP, Nagios and Myself

Strange the way I was continuously blocked by my server for port scanning. Never realized that a tiny little extension of attached to Google Chrome could be this much heart throbbing. Little did I realize that the settings to check for updates set to 1 mins could kick me off from the shell permanently. that keeps a check on intruders found the owner himself to catch this time.

It was really crazy day-by-day and started recreating the issue by hopping into logs, figuring that the request coming back to a specific port on my desktop has been the route cause.

Hey listen, I don’t download things with torrent so often. Then what else that could be bothering so much? The google search points to a harmless creative entertainer on my desktop ‘banshee’s plugin and there I go, disabled and even removed the extensions connecting to external world.

No go at all! Here it blocks again. Lets block the incoming port on my desktop. -uff yeah , never used to turn it on before but no go. Put a red signal and say – never come back again. It was just about to scream out louder. Realized that the name that I use to connect no more pings back to my server. It goes on to the and lives for ever on . – Yes, the tiny little change that was made to my domain. has taken over my DNS and I no more control the way my names work.

All that I had to do is to provide the ip instead of random dns name to get off the hook of CSF and continue browsing.

– Finding it funny and not clear – I was in the same condition when I started fixing this issue. You might figure it out little later. Keep reading.

Tags: , , , , , ,

Adaptec RAID Monitoring via Nagios

Monitoring servers with RAID controllers is made easy through and other monitoring systems. Today its quite easy to get an app installed on your mobile and configure it to display critical errors from to quickly act on. When you’re an in-charge of Infrastructure, monitoring RAID becomes very very critical.  While digging around simple ways to monitor cards, a tiny little piece of script found on exchange –
check-aacraid.py by Anchor Systems.

This script works with the Storage Manager – arcconf installed to manage RAID Cards.

Here is an excerpt from Nagios Exchange on check-aacraid script configuration for your quick reference :-

Check the health of an Adaptec raid controller using /usr/StorMan/arcconf Checks the following: Logical device status, Controller status, Failed & Degraded drives. If the battery is present: Charging status, Est of charge time left, Charge left %. And removes the log file “UcliEvt.log” that is dropped into the CWD when /usr/StorMan/arcconf is run.
Check the health of an Adaptec raid controller using /usr/StorMan/arcconf

Checks the following:
Logical device status
Controller status
Failed & Degraded drives

If battery present:
Charging status
Est of charge time left
Charge left %

And removes the log file “UcliEvt.log” that is dropped into the CWD when /usr/StorMan/arcconf is run.

Add this to your “/etc/sudoers” file using visudo
"nagios ALL=(root) NOPASSWD: /usr/StorMan/arcconf GETCONFIG 1 *"

## On RHEL & possibly others ##
Disable “Defaults requiretty” in /etc/sudoers otherwise the command will not run via NRPE.

Add this to your checkcommands.cfg

define command {
command_name check_aacraid
command_line $USER1$/check_nrpe -H $HOSTADDRESS$ -c check_aacraid
}

Add this to your servicedefs.cfg

define service {
use low-service-level
name aacraid-service
service_description aacraid
check_command check_aacraid
register 0
notification_interval 3600
}

Add the service

define service {
use aacraid-service
host_name host-with-crap-adaptec-crud
contact_groups upset-admin
}

And on the host you will be checking add this to nrpe.cfg
command[check_aacraid]=/usr/local/sbin/check-aacraid.py

Tags: , , ,

Nagios: Host not reachable

After setting up Nagios server and Client you might find to see some funny status messages. One of which is, “Host not reachable” and you will see all the Nagios clients showing up in RED status though other services are fine in status page.

This can happen due to multiple reasons. First one is obviously related to firewall issue. The other one is bit tricky but related to ping binary which is used by Nagios to ping the ip for check-host-alive status.

Nagios executes the system binaries using nagios user configured during the installation. Hence, such user must have enough privileges to execute the binary. In the above scenario, ping must be executable by the user nagios.

To resolve the issue, I added an execute bit on ping binary as follows:

chmod u+s /bin/ping

Restart or wait for Nagios to check the status of the hosts once again. Now I can see that Nagios shows the correct status of the hosts.

Configuring Nagios Client on Debian

It’s quite easy to get your server added as a Nagios client for monitoring on your centralized Nagios server.

You need few nagios packages listed below to be installed on your server first

# aptitude  install nagios-plugins nagios-nrpe-plugin nagios-nrpe-server

Aptitude will take care of the dependencies required.

Once this installation is done, Edit the nrpe configuration file which can be found at /etc/nagios/nrpe.cfg. Add the required checks and then restart nrpe server.

/etc/init.d/nagios-nrpe-server restart

You’re now ready to get the remote checks done for the server on your Nagios server.

Nagios : Remote server monitoring

You had read about nagios plugin which I use in my firefox browser in my previous articles. Let me give you an insight about nagios remote server monitoring. Nagios has been a reliable monitoring tool for many clients for years now.

Nagios comes with lots of plugins which can be used to fine tune the results. While monitoring the remote servers we need to check the service status locally on those servers to understand the condition of service status. check_nrpe is one of those tools which facilitates this feature on Nagios.

The NRPE addon is designed to allow you to execute Nagios plugins on remote Linux/Unix machines. The main reason for doing this is to allow Nagios to monitor “local” resources (like CPU load, memory usage, etc.) on remote machines. Since these public resources are not usually exposed to external machines, an agent like NRPE must be installed on the remote Linux/Unix machines.

The NRPE addon consists of two pieces:

  • The check_nrpe plugin, which resides on the local monitoring machine
  • The NRPE daemon, which runs on the remote Linux/Unix machine

When Nagios needs to monitor a resource of service from a remote Linux/Unix machine:

  • Nagios will execute the check_nrpe plugin and tell it what service needs to be checked
  • The check_nrpe plugin contacts the NRPE daemon on the remote host over an (optionally) SSL-protected connection
  • The NRPE daemon runs the appropriate Nagios plugin to check the service or resource
  • The results from the service check are passed from the NRPE daemon back to the check_nrpe plugin, which then returns the check results to the Nagios process.

Note: The NRPE daemon requires that Nagios plugins be installed on the remote Linux/Unix host. Without these, the daemon wouldn’t be able to monitor anything.

Today I found the answer for one of my questions. I wanted to monitor a server which is not directly connected to internet. I used the above mentioned NRPE plugin to check the status of MySQL service via an another server which had privilege to interact with the db server. It has been made possible via Nagios Indirect checks via check_nrpe. You can find the block diagram explaining the same below.

Its quite easy to configure this just like any other remote service checks done via nrpe daemon. Now I can monitor anything on servers which are locked in a DMZ. Nagios and NRPE made for each other.

Read more : Nagios