about:nothing

Since I first became fed up with tunnelling through to the same machine just to tail the same LCFG server log (about the third or fourth time I had to type the tiresome sequence of commands, a good few years ago) I’ve had a small function which does it for me.  However, for some reason I’d never thought to take advantage of the fact that all the logs end up tailed through my script for my manipulation, until last week.

The result of a little ANSI manipulation is a startling improvement in readability!

$ tailcfg
04/06/09 10:23:52:    publishing deferred: foo.inf.ed.ac.uk (XML)
04/06/09 10:23:52:    publishing deferred: quux.inf.ed.ac.uk (XML)
04/06/09 10:34:13:    processing: myhost [1/1, pass 1]
04/06/09 10:34:15:                1 error(s), 0 warning(s) (XML published)
04/06/09 10:34:15:    processing: netsrva [1/8, pass 2]
04/06/09 10:34:15:                (dhcp/all.map changed by myhost)
04/06/09 10:34:23:                0 error(s), 0 warning(s) (XML deferred)
04/06/09 10:34:23:    processing: netsrvb [2/8, pass 2]
04/06/09 10:34:23:                (dhcp/all.map changed by myhost)
[...]

It’s of course straightforward to achieve this. Why it took me so long to think to do it, I’m not sure.

function tailcfg() {
    ssh lcfg1 "tail -n 100 -f /var/lcfg/log/server" | sed \
        -e "s_\([1-9][0-9]* error(s)\)_`c red`\1`c off`_" \
        -e "s_\([1-9][0-9]* warning(s)\)_`c yellow`\1`c off`_" \
        -e "s_\([^1-9]0 \(error\|warning\)(s)\)_`c green`\1`c off`_g" \
        -e "s_\(processing: \)\(\<\w\+\>\)_\1`c bd`\2`c off`_"
}

Note the use of the `c` application; mine is a small binary whose source I’ve lost, but you can just as easily recreate this with a small script (I’ve left out the unused colours to save time / space…):

function c() {
    case $1 in
        red)    code='33[0;31m' ;;
        green)  code='33[0;32m' ;;
        yellow) code='33[0;33m' ;;
        bd)     code='33[1m' ;;
        off)    code='33[00m' ;;
        *)      echo "Invalid colour / state." >&2 ;;
    esac
    [[ -z ${code} ]] && return 1
    echo -e $code >&1 # note forced output to fd1.
}

VirtualBox improves with every release, and is now seems to be at a stage where it can be more than a mere curiosity for DICE users, as proven by our LCFG release test VMs, the ongoing Desktop Virtualisation project and my use of a VM as an emergency standin for failed server hardware.

Configuring the virtual machines is a process of trial-and-error, and not all settings suit all guests.  However as of version 2.2.2, this is my annotated list of my current ‘best’ DICE-on-DICE configuration:

Basic Settings:

OS Type: Linux -> Red Hat (32/64-bit)
Base Memory: (>= 384Mb ample for low-load commodity servers, but >= 1Gb apparently required for 64-bit guests)
Video Memory: >= 8Mb (for full-screen X on a DICE Host)
Boot Order: Hard Disk (with PXE on-demand only)
ACPI: Enabled (allows safe unattended shutdown, if nothing else!)
IO APIC: Disabled (causes massive clock skew if enabled)
VT-x/AMD-V: Enabled (provides some performance improvement, if mainly to host)
Nested Paging: Disabled (not yet supported on our hardware, but no harm in enabling)
PAE/NX: Enabled (of course PAE is not applicable on 64-bit, but there’s no reason to disable it on either arch)
3D Acceleration: Disabled (but worth enabling if you are using the Guest as a desktop, with Guest Additions)

Sound:

The SoundBlaster 16 device is detected, and can be used, by a DICE guest.

Note that any sound device will cause problems if you plan on running your guest ‘headless’.

Network:

Both Intel Pro (Desktop) and PCNet-Fast III devices work, providing 1Gbit and 100MBit network connections, respectively.

I’ve noticed that on Optiplex 755 hardware (on either virtual device), for each PXE boot request made by a guest, two requests are sent by the host: the first with the hosts’s MAC, and the second with the guest’s.  Clearly not ideal but I’ve not made any more detailed investigation into this: my DICE-install PXE boots are necessarily attended, and therefore easily restarted on failure.

Details on the specifics of bridged-mode network configuration can be found on the official DICE VirtualBox wiki page.

Hard Disk:

The standard ATA controller works very well. DICE + SATA will be tested soon.

Expect me to change my mind over time, not least because I note that 2.2.4 is already available…