Category Archives: Linux

NimBUS and Regular Expressions

I recently had to configure NimBUS to send alarm upon detecting a specific log entry in /var/log/messages on a Linux system. Because this alarm was supposed to be sent by SMS , I didn’t want it to send more than one message. But since our log file has a timestamp, each entry were we found a match would be handled as a unique alarm, thus sending one message for each log entry where the mach was found.

If the string we were looking for first would appear, it would most likely show up somewhere between 5 to 50 times within an hour.It’s hard to guess, really. But we are looking for a problem that won’t solve itself, and the program checking for this problem will continue to write to the log file upon each encounter with the problem.

The way to solve this kind of problem, where we want to ignore the timestamp, is to understand how NimBUS handle incoming alarms. If it receives the same message two or more times, it would just upper the count, instead of creating a new entry in the alarm window.

Lets say our log file looks like this:

Mar 14 14:55:35 ErrorCheck: Oh noes, error detected in A51
Mar 14 14:57:32 ErrorCheck: Oh noes, error detected in A51

We only want to get one alarm, but with a count of two (actually one), not two alarms which is identical except for the timestamp. First, set up logmon to detect the correct line in the log file using regular expressions. The logmon probe supports both pattern recognition and regular expressions, so make sure to use the right one. Regex starts and end with a forward slash, otherwise it assumes pattern is used.

In this case we can use the following simple regex:

/.*ErrorCheck.*/

Of course my regex where more advanced since I had to detect other parameters as well, since the output of our program also had to be checked.

Now, with this regex in place, we are at the point where every entry will be treated uniquely. But logmon also give you the possibility to construct your own message, and to define variables. And that is what we have to do.

We can construct variables both by row or column number. Since this is a single line, we will use the column offset. So, let us create the variables:

prog = column number 4
error = column number 10

This is only a simplified view. The logmon probe has a user interface for this. Right click, add new variable (or something like that).

When this is done, add your own message text in the field saying so:

$prog: Error detected in $error

When this is set as the outbound message, NimBUS will count it instead of creating a new entry in the alarm view each time, since the message now is identical. If the error code changes, a new alarm will be sent.

Short version:

Create your own output message when using NimBUS logmon probe on a log file which has a timestamp.

(This short version was a lot better and could have saved me some time)

Running Web Server as a Virtual Machine

For several months now I’ve been planning to virtualize my home server. That’s the server hosting this blog, among other things. For starters it would give me some more room to test different applications on separate operating system, but without the hassle of dealing with several physical computers.

One of my ideas is to test web application prior to deployment. This is kind of hard now that I only have one machine. It’s would be shameful if I accidently killed the web service because of a faulty configuration. Also I have a few projects which I want to separate from the machine visible on the internet.

VMware Server is a free product which can be installed on top of either Windows or Linux, so it’s not a bare-metal hypervisor. I recommend running it on top of Linux for minimal footprint, not to mention all the rebooting you have to do with Windows. A minimal Ubuntu server installation takes less than 1GB of disc space, and use next to nothing when it comes to terms of memory.

For the moment I’m doing some testing with one mySQL server, one Apache web server and one server running Varnish, which is a cache/proxy service. It’s not because I’m expecting high load in the near future, but it’s an interesting solution.

Anyway; the next few months I expect this blog to focus more on virtualization, but I can’t guarantee anything. I would be satisfied if I keep writing semi regular, no matter the topic.

Configuring Static Routes on CentOS 4

Last night we did some upgrades on a system in our datacenter. Among other things moving a few services from physical computers to virtual ones. One of these new machines needed contact with three different physical networks, and even more subnets.
If you don’t want to read about my whole example network, skip to the “fun part”.

In this blog entry I will use some bogus internal network addresses. We had the following:

eth0 directly connected to 10.0.100.0/24
eth1 directly connected to 192.168.0.0/24
eth2 directly connected to 192.168.10.0/24

Our new (virtual) server was configured using 192.168.0.1 as default gateway, via eth1. But we also needed to reach the following networks via eth2:

  • 192.168.20.0/24
  • 192.168.30.0/24
  • 192.168.55.0/24
  • 10.50.0.0/16

Configuring this “on-the-fly” is easy. All we have to do is run the following commands as root:

route add -net 192.168.20.0/24 gw 192.168.10.5
route add -net 192.168.30.0/24 gw 192.168.10.5
route add -net 192.168.55.0/24 gw 192.168.10.5
route add -net 10.50.0.0/16 gw 192.168.10.5

As you have guessed, 192.168.10.5 is the gateway being connected to eth2. Now the following is taking place:

Traffic for 10.0.100.0/24 is directly pushed out eth0, no routing needed.
Traffic for 192.168.0.0/24 is directly pushed out eth1, no routing needed.
Traffic for 192.168.10.0/24 is directly pushed out eth2, no routing needed.
Traffic for 192.168.20.0/24, 192.168.30.0/24, 192.168.55.0/24 and 10.50.0.0/16 is pushed to gateway 192.168.10.5 via eth2.
Everything else is directed to gateway 192.168.0.1 via eth1.

Fun Part

To make this routing permanent, meaning it will return upon reboot, we need to store this information somewhere. In this case we’re using CentOS 4, so the file we need to edit is /etc/sysconfig/static-routes. Per default this file doesn’t exists, at least it didn’t on my machine, so I created one and entered the following:

any net 192.168.20/24 gw 192.168.10.5
any net 192.168.30/24 gw 192.168.10.5
any net 192.168.55.0/24 gw 192.168.10.5
any net 10.50.0.0/16 gw 192.168.10.5

Also, check the files /etc/sysconfig/network-scripts/ifcfg-ethx, replace x. Only eth1, in my example, should have a line which says “GATEWAY=192.168.0.1”. If anyone of the other files also has a line which starts with “GATEWAY”, something will most likely go wrong.

I’m not sure how interesting this is for anyone. But at least I hope someone will benefit from it. I might start some more “in-depth” articles about network configuration in the future.

Please leave a comment if you found this useful, or ask questions if there is something I can improve.

Different Fan Behaviour on ThinkPad X61 than X31

Since I got my new Lenovo ThinkPad X61, I have discovered that the CPU fan is behaving rather differently than the one I have in my IBM ThinkPad X31. That is the fan makes a lot more noise when idle on the X61.

For the record. I’m running Ubunty Hardy (8.04) on the X61 and Ubuntu Gutsy (7.04) on the X31. Both 32-bit systems.

The first thing I did was checking Launchpad.net for any known bugs. I found bug 224876 to be promising, it’s titled “Hardy does not control the CPU fan properly.”
After reading this thread I ran the tests described myself, which gave these results.

Machine temperature and fan speed when idle (X61):

$ cat /proc/acpi/thermal_zone/THM0/temperature
temperature: 41 C
$ cat /proc/acpi/thermal_zone/THM1/temperature
temperature: 42 C
$ cat /proc/acpi/ibm/fan
status: enabled
speed: 3207
level: auto

After 5 minutes of “yes | sha512sum” (X61):

$ cat /proc/acpi/thermal_zone/THM0/temperature
temperature: 76 C
$ cat /proc/acpi/thermal_zone/THM1/temperature
temperature: 78 C
$ cat /proc/acpi/ibm/fan
status: enabled
speed: 3242
level: auto

As you can see there is as good as no change in the fan speed.
However; doing the same check on my older, one core, IBM ThinkPad X31.
I get this results:

Machine temperature and fan speed when idle (X31):


$ cat /proc/acpi/thermal_zone/THM0/temperature
temperature: 44 C
$ cat /proc/acpi/ibm/fan
status: enabled
speed: 0
level: auto

Actually, the fan doesn’t start until the temperature reach 68 degrees Celsius. Then it will speeds up to around ~3500 rpm, thus keeping the processor at around 70 degrees Celsius during “yes | sha512sum”.

My question is: Why does the fan constantly run on the X61? Is it really necessary to keep the processor cool? I must say I prefer the silence of the X31 when I’m just browsing the web.

Karl Trygve has suggested that this is a result of a new design team and BIOS which is more restrictive than the one found on the X31.

Ubuntu Hardy and Hibernate Issues

As I mentioned in my last post I had some minor problems with Ubuntu Hardy (8.04) and hibernation. It didn’t always work.

However it now seems like I might have overcome this problem. At first I thought it might had something to do with my docking station. Hibernating while docked, booting up while not and vice versa. The problem was that the machine would freeze during startup after being in hibernation. So to be able to actually see what was going on, I removed the splash screen, and afther this I haven’t had any problems with hibernate what so ever.

Come to think of it, this isn’t the only time the splash screen have caused problems. I had another machine where it refused to boot as long as the splash parameter was set. Luckily, with grub, we are able to edit the boot parameters at boot. Something that wasn’t possible with LILO in the good old days.

To remove the splash screen more permanently than editing grub at each boot. You can,would be to edit the file /boot/grub/menu.1st and remove the word ‘splash’ from the kernel parameters. Just remember that this will sneak its way in the next time you upgrade the kernel. Or rather, Ubuntu upgrades your kernel. as Stian said in the first comment, edit the line “# defoptions=quiet splash” to “#defopts=”quiet nosplash” in the file /boot/grub/menu.1st. Do not remove the leading #.

Please leave a comment if you found this useful.