Simon Krenger

On one of our Debian hosts, we use bash scripts and cron jobs to automate certain tasks. One of these bash scripts downloads files from an FTP server and archives them. After upgrading the host machine to Debian 6.0.4, one of the bash scripts suddenly showed warnings:

/srv/foo/bar.sh: line 146: warning: here-document at line 140 delimited by end-of-file (wanted `EOF')

Whoops, so let’s look into it. The change was probably introduced with the new version of bash:

When setting up a new server in a highly secured network, one does not always have access to the Red Hat Network to download packages for the installation of the server. Often, a local repository is provided later on in the setup process.

This leaves us with the problem of installing the necessary packages for the Oracle database. Luckily, we can use the DVD we used for the installation of the Operating System to get all required packages.

Ok, here is a quick trick that I just found out about earlier this week. I am currently in an Oracle Database 11g: Administration 11 course and learn many new things about database administration.

One thing you will definitely encounter when working with Linux is that it is not possible to scroll back though your SQL*Plus history with the arrow keys. If you try to do so, the following happens:

SQL> select owner, count(1) from dba_tables group by owner;

OWNER				 COUNT(1)
------------------------------ ----------
[..]
SYS				      673
SIMON				       88


7 rows selected.

SQL> ^[[A     " - rest of line ignored.
SQL> command "
SQL> 

Argh! Some kind of wild character sequence appears on the command line. A quick search shows that this is a common problem. One thing that regularly happens is that you enter a SELECT statement that returns too many rows. Because the terminal buffer only contains a certain number of rows, your query disappears and you have to retype it.

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…

Today one of our developers came to me to discuss a problem and I wanted to show him something on one of our Linux machines. To check a process, I ran pstree and noticed that the formatting of the output was all wrong:

simon@atlas:~$ pstree
initââ¬âacpid
     ââapache2âââ10*[apache2]
     ââatd
[..]
     âârsyslogdâââ3*[{rsyslogd}]
     ââsshdââ¬âsshdâââbashâââping
     â      ââsshdâââbashâââpstree
     â      ââsshdâââsshdâââsh
     ââudevdâââ2*[udevd]

This is obviously just a cosmetical problem and the output is quite hard to read. When encountering something like this, the first guess would be that the encoding is somehow wrong. When checking the environment variables with env, we find that LANG is set to “en_US.UTF-8”.

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:

One excellent tool for Systems Management on Windows is the Windows Management Instrumentation (WMI), which allows you to remotely execute commands and query parameters on a Windows Host. Of course, all modern Windows systems have the WMI Client installed, but what about the Linux clients?

To get the same functionality on a Linux system (I am using Debian in this example), we need to get the following two packages from this website:

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.

When deploying a new database, one thing I usually do is to set up a logrotate configuration for the Oracle Listener log. The Oracle Listener logs every connection he makes and when using an Application Server to interface the database, this file can grow quite a bit. So we need to make sure that we properly rotate this log and compress the old logs.

To achieve this, I usually create the following configuration for logrotate: