Every text-tool-user should know about tail! You can print the last few lines of a file or watch it growing. But there are three improved derivatives, just get into it.

I think there is no need for further explanation of tail itself, so lets begin with the first derivative.

colortail

colortail is based on tail with support for colors, so it helps to keep track of important content. Common options and parameters are resembled closely to them of tail, so it won’t be a big adjustment to new circumstances for tail fans. The content that it presents is of course the same as if it comes from tail, but colorized ;) With -k you can additional submit a configuration file that defines some regular expressions and its colors. On a Debian some examples can be found in /usr/share/doc/colortail/examples/ . In figure 1 you can see an example output of colortail on the syslog of a virtual machine.

multitail

The second tool in this article is multitail. Like colortail it can colorize the output, but all is presented in a ncurses based user interface so it is able to create multiple windows on your console. If you open a file in multitail it’s automatically in a following mode ( -f in case of tail and colortail). If you are monitoring multiple log files your console is split horizontal or vertical or a mix of both. You can pause the output, search for regular expressions and a lot more. Enter F1 to get a small help window. Figure 2 presents a sample output. Its project page keeps much more information.

logtail

logtail pursues a different goal. It’s not interested in prettifying the output, it remembers the content that was still displayed and just prints the differences to the last run. So it is an ideal tool for log analyzer, log messages doesn’t have to be parsed multiple times. logtail is written in perl, you can also monitor logfiles on different machines.

I hope I could give you some smart inspirations.

DNS look-ups are a very sensible topic. Of course you want very fast name-to-IP resolutions, but should you always use Google’s DNS server? After all they can keep track of all your network motion profile unless you are surfing by IP! Today I read about the OpenNIC Project and ran some speed tests. It’s very interesting and worthy to know about!

The project about itself:

OpenNIC (a.k.a. "The OpenNIC Project") is an organization of hobbyists who run an alternative DNS network. [...] Our goal is to provide you with quick and reliable DNS services and access to domains not administered by ICANN.

Ok, I gave it a try and implemented a Perl-script that checks the speed. It throws a dice to call one of my often used domains and digs¹ each of my predefined DNS servers to save the query time. I tested the following DNS server:

• 178.63.26.173 : one server of the OpenNIC project, located in Germany
• 217.79.186.148 : one server of the OpenNIC project, located in Germany (NRW)
• 8.8.8.8 : Google’s public DNS server, proven to be fast and reliable
• 172.16.20.53 : my ISP’s server
• 141.48.3.3 : name server of our university

Find the Perl code attached.

And here are the results after 10000 qeuries:

As you can see, my ISP’s DNS server is the fastest, they may have optimized their internal infrastructure to provide very fast look-ups to its customers. But it is also nice to see, that there is one OpenNIC server that is faster than google! And this server comes with another feature: It doesn’t track any logs! Isn’t that great!?

To find some servers near you just check their server list. Some of them don’t record logs or anonymize them, and of course all of them are independent from ICANN administrations.

I can’t recommend to use any special DNS server, but I want to advise to test them and find the best one for your demands! Feel free to post your own test results via comment or trackback.

¹ dig is part of the larger ISC BIND distribution

You may have heard about management consoles!? If a server is dead you can revive it via service console without driving the long way to the data center (often miles away).

While logged into the service console you of course have the chance to reboot the machine itself. To get to know what it is doing while booting you may want to see all the messages that are usually prompted to the terminal at the attached monitor. Unfortunately you aren’t next to the machine, and so there is no monitor attached to it, but you can force grub to prompt all messages both to terminal and to service console.

First of all you have to setup the serial console:

serial --unit=0 --speed=57600 --word=8 --parity=no --stop=1

The --unit parameter determines the COM port, here it’s COM1, if you need COM2 you should use --unit=1 . --speed defines a baud rate of 57600 bps, see your manual. To learn more about the other parameter you are referred to the Grub manual for serial. Next you have to tell Grub where to write the output:

terminal --timeout=5 console serial

This line tells grub that there are two devices, the typical console on the attached screen and our previous defined serial console. With this directive Grub waits 5 seconds for any input from serial console or the attached keyboard and will print its menu to that device where the input was generated. That means if you’re at home and press any key, Grub will show you all outputs to your serial connection, but your student assistant (who had to go to the server, by bike while raining!!) isn’t able to see whats happening. But if your assistance is faster than you and hits a key on the physically attached keyboard, he’ll see anything and you’ll look through a black window… If nobody produces any input the output is written to that device that is listed first.

Last but not least you have to modify the kernel sections of the boot menu and append something like that at the end of every kernel line:

console=tty0 console=ttyS0

That tells grub that all kernel messages should be printed to both the real console of the attached screen and the serial console. Keep in mind to modify ttyS0 to match your serial port (here it is COM1). Grub decides for the device that is listed last to also send all stdin/stdout/stderr of the init process, that means only the last device will act as interactive terminal. E.g. checks of fsck are only printed to the last device, so stay calm if nothing happen for a long time on the other one ;-)

Here is a valid example for copy and paste:

# init serial console
serial --unit=0 --speed=57600 --word=8 --parity=no --stop=1
# what device to use for grub menu!?
terminal --timeout=5 console serial
# ....
title           Debian GNU/Linux, LOCAL CONSOLE
root            (hd0,0)
kernel          /vmlinuz-SOMEWHAT-openvz-amd64 root=UUID=AAAAAAAA-BBBB-CCCC-DDDD-EEEEEEEEEEEE ro console=ttyS0 console=tty0
initrd          /initrd.img-SOMEWHAT-openvz-amd64

title           Debian GNU/Linux, LOCAL CONSOLE
root            (hd0,0)
kernel          /vmlinuz-SOMEWHAT-openvz-amd64 root=UUID=AAAAAAAA-BBBB-CCCC-DDDD-EEEEEEEEEEEE ro console=tty0 console=ttyS0
initrd          /initrd.img-SOMEWHAT-openvz-amd64

Here both Grub entries are booting the same kernel, but the first one will use the local console as interactive terminal whether the other entry takes the serial console for interactions.

By default Xfce provides screen-locking via Xscreensaver. Here is how you change it.

Xfce runs a script called xflock4 to lock the screen, to change the default behavior just foist another script on Xfce! The default path settings for searching for this executable shows, that /usr/local/bin has higher priority than /usr/bin (here is the original xflock4 located). The rest should be clear!

E.g. to use xtrlock instead of Xscreensaver you just have to link to the binary:

% ln /usr/bin/xtrlock /usr/local/bin/xflock4

On a multiuser system you may allow each user to use it’s own locking-solution. So just write a script that checks if $HOME/.screenlock is executable and runs it or falls back to a default screensaver:

#!/bin/bash

# default
DO=/usr/bin/xtrlock

# does user want smth else??
[ -x $HOME/.screenlock ] && DO=$HOME/.screenlock

$DO

Save it executable as /usr/local/bin/xflock4 - done…

I recently got very close to the floating point trap, again, so here is a little tribute with some small examples!

Because Gnu R is very nice in suppressing these errors, all examples are presented in R.

Those of you that are ignorant like me, might think that 0.1 equals 0.1 and expect 0.1==0.1 to be true, it isn’t! Just see the following:

> a=0.1
> b=0.3/3
> a
[1] 0.1
> b
[1] 0.1
> a==b
[1] FALSE

You might think it comes from the division, so you might expect seq(0, 1, by=0.1) == 0.3 contains exactly one vale that is TRUE !? Harrharr, nothing like that!

> seq(0, 1, by=0.1) == 0.3
 [1] FALSE FALSE FALSE FALSE FALSE FALSE FALSE FALSE FALSE FALSE FALSE

Furthermore, what do you think is the size of unique(c(0.3, 0.4 - 0.1, 0.5 - 0.2, 0.6 - 0.3, 0.7 - 0.4)) !? Is it one? Not even close to it:

> unique(c(0.3, 0.4 - 0.1, 0.5 - 0.2, 0.6 - 0.3, 0.7 - 0.4))
[1] 0.3 0.3 0.3

Your machine is that stupid, that it isn’t able to save such simple numbers ;) And another example should show you how these errors sum up:

> sum=0
> for (i in 1:100) sum = sum + 0.01
> sum
[1] 1
> print(sum, digits=16)
[1] 1.000000000000001

As you can see, R tells you that you summed up to exactly one, suppressing the small numerical error. This error will increase with larger calculations! So be careful with any comparisons. To not fail the next time, for example use the R build-in function all.equal for comparison:

> unique(c(0.3, 0.4 - 0.1, 0.5 - 0.2, 0.6 - 0.3, 0.7 - 0.4))
[1] 0.3 0.3 0.3
> all.equal(0.3, 0.4 - 0.1, 0.5 - 0.2, 0.6 - 0.3, 0.7 - 0.4)
[1] TRUE

Or, if you’re dealing with integers, you should use round or as.integer to make sure they really are integers.

I hope I could prevent some of you falling into this floating point trap! So stop arguing about numerical errors and start caring for logical fails ;-)

Those of you interested in further wondering are referred to [Mon08].

References

[Mon08]

David Monniaux. The pitfalls of verifying floating-point computations. ACM Trans. Program. Lang. Syst., 30(3):1–41, 2008. http://hal.archives-ouvertes.fr/hal-00128124/en/