I’d always intended to follow up a big hand for rfe with details of my vim-based LCFG profile / header editing environment – but seven years intervened and apparently it never crossed my mind again.

So, to cut another long story short…

I use snappy aliases “vp” and “ep” to view and edit LCFG profiles, respectively. These consist of a few DNS checks, shortcuts, a backup system, etc. but the crucial bit is the overriding of EDITOR to be a very small bash shim, which assumes you have a full checkout of the DICE LCFG headers at "$HOME/path/to/headers":

#!/bin/bash
# Define paths for "gf" goto-file support
LCFG_WORKING_COPY="$HOME/path/to/headers"
lcfgwcpath="$LCFG_INCLUDE_WC/core/include,$LCFG_INCLUDE_WC/live/include,$LCFG_INCLUDE_WC/core/packages/*,$LCFG_INCLUDE_WC/live/packages"

# rfe doesn't specify a filetype, so we have to force CPP mode.
# Also, set working path above for "gf" support.
/usr/bin/vim -c "set filetype=cpp" -c "set path=${lcfgwcpath}" $*

I activate this via my shell. You could do it, for example, with .bashrc:

function editprofile() {
  local profile args
  for profile in ${*:-$(hostname -s)}; do
    args="${args} lcfg/${profile}";
  done;
  EDITOR="$HOME/bin/pvim" rfe -S ${args};
}

This grants me significantly more useful syntax-highlighting, as well as an understanding of #include directives, which allows me to “gf” to inspect the header under the cursor.

Of course, the highlighting doesn’t understand the embedded Perl-like LCFG bits, but that’s OK, comments and macros are a significant improvement (in particular, no longer treating /^#.*$/ as a comment). On several occasions I have experimented with a special “lcfg” vim filetype but this is 99% based on CPP, and generally the bugs outweigh the benefits.

DICE users have long had the ability to add their own cron jobs, to schedule repeating tasks or to launch services on reboot¹ using the standard crontab command.

The Research and Teaching unit recently noted that users’ crontabs (sometimes required, for example, on research servers to start or check on custom services) are not routinely backed up. They are of course necessarily minimal and easy to recreate, but their fate following a disaster (or even a reinstallation) is not obvious. Even if users are aware of this limitation, it prevents us from performing a completely automated recovery where users’ crontabs are involved.

It is possible to back up crontabs on demand or routinely, but we’ve no procedure to do this on machines that typically have no other data to back up. So the purpose of this post is simply to draw attention to the above, and ask a few general questions:

• Is it well-known that crontabs are “at risk”? Does anyone care?
• Should crontabs be backed up routinely? on all servers? desktops? at all?
• Is there anything else we should be doing about this?

Comments are encouraged, below or by email.

1. crontab is the setuid executable which manages /var/spool/cron/ for this purpose. The location is notable: on DICE, the /var directory (or filesystem) consists of data which is either transient or generated and managed automatically. With the exception of some database files, this data is not typically backed up since its value is only to the running system. Indeed most cron entries on a machine are not created by users; they are configured by LCFG and (re)created automatically.
2. Note that using cron on DICE requires a few steps to work with (or around) AFS.

pgluser is a handy tool on DICE, and allows me to manage postgresql user accounts and databases in a completely automated manner. As it was primarily a tool to make my life easier, I’ve never tried particularly hard to increase its uptake. This is my attempt to help, at least for anyone considering setting up an postgresql server in an LCFG environment:

https://svn.theon.inf.ed.ac.uk/trac/wiki/PgluserAndDice

Have I missed anything?

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.
}

As the platform becomes increasingly stable, Wine apps are beginning to look like first-class citizens of an X environment. It makes sense that they should be executed as such:
# echo ':DOSWin:M::MZ::/usr/bin/wine:' > /proc/sys/fs/binfmt_misc/register


This allows DOS and Windows executables with magic number MZ to be executed as regular binaries, by passing them to the standard wine binary. Note that this does not require the file to be named '.exe' so, as ever, take care with +x!

or slightly more permanently, in very hacky LCFG:

!cron.additions mADD(winexe)
cron.owner_winexe root
cron.add_winexe @reboot "echo ':DOSWin:M::MZ::/usr/bin/wine:' > /proc/sys/fs/binfmt_misc/register"


(In theory we should be able to user the ‘kernel’ component, but it doesn’t seem to have the ability to manipulate the ‘register’ portion of fs.binfmt_misc.)

Quick reminder:

To allow a VMware guest to use a “real” MAC for one of its emulated network adaptors (specifically one outwith VMware’s own manufacturer range allocated for virtual machines) one need only add the following to its .vmx file:

ethernet0.checkMACAddress = "FALSE"
ethernet0.addressType = "static" 
ethernet0.address = "<new MAC>"

Interesting edit (22-Apr):

It appears that, although this prevents VMware restricting MACs to within its ‘manual’ range (00:50:56:[00-3F]:*), this is not sufficient to allow assignment of addresses within the VMware ‘automatic’ range (00:0C:29:*). VMware simply ignores any statically assigned MACs in this range, instead reverting to the generated MAC within that range (removing the ‘generatedAddress’ resource is not sufficient to override this). I’m still not sure if this is by accident or design.

This is my first post. I edited it, but didn’t start blogging!