Simon Krenger

Some services (such as MSSQL instances) include a dollar character ($) in their name. A few weeks ago, I had to add a service called “$02_JBoss Server” to our internal Nagios configuration. After searching through the Nagios documentation and FAQs, this is what I found:

For Nagios 3, add two backslashes and a second dollar (\$) symbol, like this: check_command check_command check_nt!SERVICESTATE!-d SHOWALL -l MSSQL\$$INSTANCE

The above example actually has a small error in it, because there is no second backslash (even though it says so in the description)!

The correct way to check a service named “$02_JBoss Server” is to use a definition like this:

check_command           check_nrpe_args!CheckServiceState!ShowAll "\\$02_JBoss Server"

So there I was. I just installed Nagios on a brand new Debian (6.0.3) host, I was greeted with the following error message after logging into the Nagios web interface and clicking a link that uses external commands:

Error: Could not stat() command file '/var/lib/nagios3/rw/nagios.cmd'

What? Well, after making sure my configuration is correct, I figured that this must be some kind of permission problem…

For my studies, I bought a MacBook Air with the swiss keyboard layout. The Air is really nice to carry around, since it is light, thin and features a battery that lasts for more than 6 hours of light work (e.g. working in Eclipse).

However, one thing I did not really like was the circumstance, that Apple uses a non-standard keyboard layout for its notebooks. When you are typing letters this will most likely not bother you, but as soon as you start to use special characters (such as []{}~\), you’re in trouble.

So I searched for a way to restore the standard keymap for the swiss german keyboard. Luckily, I stumbled upon this great application called Ukelele, which allows you to modify the keymap for Mac OS X.

For a proof-of-concept, I had to install a new Mantis Bug Tracker instance and after finishing the installation, the login screen greeted me with the following warning:

SYSTEM WARNING: date_default_timezone_get(): It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'UTC' for 'UTC/0.0/no DST' instead

The solution is amazingly simple. The only thing that I needed to find out was that this is a PHP error and not a MantisBT error. So after that was settled, I went on and just followed the instructions given by the warning:

To monitor our software, we use the free Nagios supervision system fitted with custom checks for our application. This way, we can make sure that not only the Operating System is properly monitored but also the core components of our application including the Application Server and the Oracle Databases.

Today I tried to update to the latest version of Nagios 3.3.1 on one of our supervision servers running Ubuntu Server. So I downloaded the package, ran “./configure” and ran “make fullinstall“. I then stumbled upon the following (quite meaningless) error:

/usr/bin/install: omitting directory `includes/rss/extlib'
/usr/bin/install: omitting directory `includes/rss/htdocs'
/usr/bin/install: omitting directory `includes/rss/scripts'
make[1]: *** [install] Error 1
make[1]: Leaving directory `/tmp/nagios-3.3.1/nagios/html'
make: *** [install] Error 2
root@watchtower:/tmp/nagios-3.3.1/nagios#

Phew. Alright, using my trusty friend Google I quickly discovered a thread on ubuntuforums.org with the solution.

I just noticed that every time I need to create a password file, I have to look up the Oracle documentation for the correct syntax of the ORAPWD arguments. So this post is mainly for my own reference and contains the proper syntax for UNIX and Windows systems as well as an example for each system.

UNIX syntax:

When I tried to run a scan with NMAP over my VPN connection, I received the following error:

PS C:\> nmap -sP 192.168.10.0/24
Starting Nmap 5.21 ( http://nmap.org ) at 2010-11-18 09:35 W. Europe Standard Time
nexthost: Failed to determine dst MAC address for target 192.168.10.0
QUITTING!

Alright… A quick search with Google revealed the following topic: http://seclists.org/nmap-dev/2008/q1/81.

After a database update from 10.2.0.1.0 to 10.2.0.5 on Windows Server 2003, we encountered the ORA-12571 error when starting the Application Server. In the log files, the error showed up as an SQLException:

java.sql.SQLException: Io exception: Connection reset by peer: socket write error

I then used TNSPing to validate the connection to the database and I basically received this result:

OK
OK
OK
ORA-12571: TNS:PACKET WRITER FAILURE

This means that there is a problem with the TNS Listener. I checked the listener log ($ORACLE_HOME\network\log\listener_name.log) for errors and saw this:

This week I purchased a OCZ Vertex 2 SSD drive for my laptop, a Lenovo ThinkPad T61p. After replacing the old HDD, I was greeted by the following error message, just after the BIOS screen:

ERROR
2100: HDD0 (Hard Disk Drive) initialization error (1)

That does not sound good. Anyway, I searched around and found one simple advice:

Don’t use the ThinkPad HDD cage and the corresponding anti-shock bumpers. The problem lies with the physical connection of the SSD. I inserted the SSD without the bumpers and the bracket and voilà : It worked flawlessly.

The SSD does not need shock-protection from the rubber bumpers, but in order to stabilise the drive I put some padding at the end of the SSD, so there is no stress on the connectors.

When you want to use the Oracle Client for 10g on Windows and your computer uses the Swiss German Region and Language options, you will stumble across the following error when trying to connect to a database with Enterprise Manager:

Error occurred at recursive SQL level 1

Now what? It turns out that this is Oracle Bug 4598613: ORA-2248 from 10.2/10.1.0.5 client with NLS_LANG set to territory SWITZERLAND. Metalink has this to say:

ORA-604 / ORA-2248 occurs when NLS_LANG is set to 
FRENCH_SWITZERLAND.WE8ISO8859P15 on the client side , 
or a similar string using territory SWITZERLAND.
eg: GERMAN_SWITZERLAND

Solution

Set your NLS_LANG to something else than GERMAN_SWITZERLAND. For example:

set NLS_LANG=AMERICAN_AMERICA.WE8MSWIN1252

To make the change persistent, edit the following Registry key:

My Computer\HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE\KEY_%ClientHomeName%\NLS_LANG