Tag Archives: DICE

a big hand for rfe

Here are some tools that I’ve put together that make a huge difference to a clunky rfe workflow. Bored already? Don’t worry, I’ve written the script already: tl;dr

Imagine power cycling a DICE server with redundant PSUs, using our lovely power bar control files. You don’t know where it’s installed, so you have to search for it. Continue reading

Away with the PXEs

Occasionally, for the purposes of internal testing or continuity, it’s desirable to bring up a server with a duplicate MAC address. It’s a safe enough manoeuvre (so long as these machines operate on different wires) for the brief periods in which I require it but when this scenario involves the installation of a new server via our installroot PXE service, things are trickier.

Our PXE server is configured automagically by spanning map and, effectively, keyed on MAC, so it’s unlikely to present the correct configuration (reliably) when the new host differs from the old one in some way.

The workaround is to override the PXE configuration on the *existing* server (on the basis that you weren’t planning on reinstalling it, anyway, were you?):

!pxeclient.platforms mADD(new_plat_name) /* e.g. sl6_64 */

/* And, if you need to add or remove serial console support: */
!pxeclient.serial_port mSET(ttyS0) /* or () */

Post-PXE, the dhclient component is aware of subnet differences and will ensure your machine receives the correct profile for installation (though, to prevent future confusion, remove this as soon as the installer has done its work!).

Nag nag nag nag nagios

Nagios is an extremely useful tool, until it isn’t.  Which is to say, it’s nothing but a hindrance to have nagios continue to bombard you with IMs and emails when you’re already working on the problem.

Surely you can just acknowledge the fault and shut it up…?

Well, sometimes, but it is hardly convenient to break out a Firefox session when you’re attached to a serial console with your lovely secure-shell-enabled phone.  And even if you are on a DICE machine it’s a bit of a pain to have to navigate the slightly clunky Nagios UI to find the host and service you wish to silence.

I started with a dumb bash script. Continue reading

tar-a-dice?

I recently encountered a .tar file which DICE tar wouldn’t extract, giving multiple warnings:

tar:  Ignoring unknown extended header keyword `SCHILY.[...]'

before bailing out due to previous “errors”. The file in question appeared to have been created on a Mac, whose archive utility adds extended metadata to its files.


This is confirmed and fixed in May 2007, but some more venerable Linux distributions continue to ship older versions.  Tar’s behaviour is a bug, since these warnings should be non-fatal.  However, the warnings can be avoided altogether by addition of an argument:

 --pax-option="delete=KEYWORD.*"

for each problematic keyword.

[Source: Tar mailing list]

My Favourite VirtualBox Settings (as of 2.2.2)

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…