About Archive Tags RSS Feed

 

Entries posted in April 2006

With self-inflicted wounds

6 April 2006 21:50

Debian Planet : When flaming on mailing lists isn't enough.

Calm down? Take it to email? Call each other on the phone? Please.

| No comments

 

Deep down I know there is no other way

15 April 2006 21:50

Looking over my server logs I see from the referers (sic) that somebody wrote a brief guide to using my xen-tools package under Ubuntu. It is a simple guide, but still useful since it doesnt actually need to be detailed.

I wouldn't have noticed had I not checked my server logs - so I thought it was worth suggesting that if you write documentation for any software it really is worth the time to point people to it.

I know when I started writing pieces for the Debian Administration website I often pointed software authors at any article I'd written which described their tool/software. Partly for a good chance of a knowlegable reader who would correct any glaring mistakes I might make, but mostly because I think it is the right thing to do.

| No comments

 

I'll be with my sisters, doing it for ourselves

16 April 2006 21:50

I've spent the night watching Red Dwarf and setting up a test CFEngine installation to remotely manage a number of identical hosts.

Honestly I'm not sure which I enjoyed doing the most …

CFEngine rocks:

  • Setting up common files from a central source (/etc/hosts, etc.)
  • Adding user accounts.
  • Setting up per-server files (/etc/apache2/*, etc.)

And much much more!

| No comments

 

You've got to manage

19 April 2006 21:50

Large Scale Automation

I've been revisiting CFEngine recently in anticipation of installing it on around 50 notes.

Matthew Palmer has given me a lot to think about, suggesting that maybe CFengine isn't the right tool for the job and suggesting I look at Puppet. It seems very new, and I'm not overly fond of the Rubyness - but otherwise it looks good.

There are some things that CFEngine gets right, and some things it gets wrong. One of the biggest "right" things is the split of the code:

  • There is a "scripting language" which can be used to apply changes to the local host.
  • There is a system for distributing these scripts to a number of nodes.

That strikes me as being a perfect split. The "script" file which is executed cfagent.conf is really a ruleset which is executed once on each host. The rest of the CFEngine setup is mostly concerned with distributing this file, handling updates, logging, security etc.

If I were to code a similar system that is exactly how I'd seperate it.

Now we come to the rules themselves. What do we do inside them? Well in my use of it to date I'm mostly doing a small number of things:

  • Copying files from a central host + setting permissions + groups.
  • Making minor edits to a local file.
  • Testing to see if a file contains a given string; and if not replacing it wholesale.
  • Testing that processes are running, and if so stoping/restarting/starting them
  • Executing commands (install package, adding ssh host keys, "cvs update")

So those are my primitives. They can actually be reduced further. Assume that the central server runs a HTTP server - then "copying a file" becomes "execute a command (wget/curl)".

None of these jobs is complex. None of them are things that couldn't be written with a simple scripting language such as perl, lua, etc.

It is almost tempting to write a simple rule-file-intepretter/parser. But down that path lies madness.

I'm going to install Puppet tonight and play with it. Gotta love Xen :)

If that works out nicely I might switch to using it, despite my concerns that it isn't mature and is Ruby based.

If it doesn't it becomes a choice of writing a simple intepretter + deamon which accepts SSL connections with client certificates, or living with CFEngine.

| No comments

 

In a case like this

22 April 2006 21:50

Automating Debconf Setup?

I want to automate the post-install debconf setup of a package in order to run a mass-deployment of a package.

I know that I can dump the current setup of a package with something like:

client1:~# debconf-show foo
* foo/bar: true
* foo/baz: false

However there appears to be no corresponding debconf-set command I can use to import these settings on the far side.

Am I missing something?

(Initially I thought I could use debconf-set-selections but the two formats seem to be incompatible. Unfortunately debconf-get-selections doesn't appear to output the debconf settings I was expecting it to show so I can't use that.)

| No comments

 

I can't go back to yesterday, because I was a different person then.

23 April 2006 21:50

Joey

My problem was user error - I wasn't passing the output I intended to into debconf-set-selections...

I've got debconf selections working now.

The ultimate goal was do remotely install cfengine2 via a process similar to this:

#!/bin/sh
host=$1
debconf-get-selections  |grep cfengine2/ | ssh root@$host debconf-set-selections
ssh root@$host DEBIAN_FRONTEND=noninteractive apt-get install --yes --force-yes install cfengine2
scp /var/lib/cfengine/masterfiles/inputs/*.conf root@$host:/etc/cfengine
ssh root@$host cfagent -q

| No comments

 

Don't tell me that you love me

25 April 2006 21:50

Once upon a time I wrote a simple game using SDL.

Tonight I reworked it so that it uses Lua as a scripting language. Mostly as a proof of concept since I've no real interest in recoding the game logic.

It was suprisingly easy to recode the screen layout and get the Lua script to handle drawing the status text and moving the sprites though.

I think I'll try to do something useful soon - maybe a scripted version of Othello/Reversi. Simple to code a "game board engine" which passes the mouse clicks over to the lua script to calculate validity, etc.

That'll keep me occupied for a few nights anyway.

| No comments

 

All my people...

27 April 2006 21:50

udev?

I upgraded my machine last night and it decided it didn't like the look of hotplug anymore installing udev instead.

Fine. I can be brave.

Rebooting and hoping for the best all seemed well. Until I noticed that /dev/dsp wasn't recreated.

My working system had the following modules loaded:

i810_audio             31028  0
ac97_codec             17004  1 i810_audio
soundcore               8672  2 snd,i810_audio

The system has an SIS audio system:

0000:00:02.7 Multimedia audio controller: Silicon Integrated Systems [SiS] Sound Controller (rev a0)

So how do I persuade udev to use this?

Right now I have no /dev/dsp device.

If I manually install some modules I can make the dsp device appear - but surely I shouldn't have to do that?

root@itchy:~# ls /dev/dsp
ls: /dev/dsp: No such file or directory
root@itchy:~# modprobe  snd_intel8x0  snd_pcm
root@itchy:~# modprobe snd_pcm_oss
root@itchy:~# modprobe snd_intel8x0
root@itchy:~# ls /dev/dsp
/dev/dsp
root@itchy:~# ls /dev/dsp -l
crw-rw---- 1 root audio 14, 3 Apr 27 10:26 /dev/dsp

(Obviously if this is what I'm supposed to do I can add the module names to /etc/modules - it just seems strange to me!)

| No comments

 

Every. Day. Psycho.

29 April 2006 21:50

The transition of my main desktop machine to udev seems to be complete. Thanks to the people that offered useful suggestions to my previous post.

The only additional problem I had was the loop module not being auto-loaded, causing Xen to fail. (I use loopback files for the Xen instances. Less efficient, but easier to manage, etc).

Friday was my last day of working at Noha-Systems / Intasys / Acecomm Solutions, so I've got the weekend off and then I start working at Bytemark on Tuesday. (Monday is a bank holiday in England & Scotland)

Happily this means I can stay out late on Sunday, dancing naked on a hill at The Beltane Fire Festival on Sunday Evening.

Result!

| No comments