Entries posted in May 2006

The new job is going well. I'm starting to get the hang of it now remembering hostnames &; etc.

There are lots of pictures of beltane available - although many are not safe for work…

I've got a lot of pending Debian package uploads, but I did release a new version of xen-tools - this adds support for a "skel" directory, to copy files en masse to new images, and also allows users to specify an initrd image. This is required for the Xen 3.0 packages which recently landed in Sid.

I've written a guide to using the Xen 3.0 packages which are in unstable and that'll be published tomorrow. A couple of changes from the excellent packages which were available from DebianBase.de.

No tags | No comments

Andrew:

I'm glad you like the xen tools package - looks like you followed pretty much the same approach as I did running the new Xen 3.0 packages on Debian Sid... although I can't duplicate your sda vs hda issue. (Already reported as #366252)

I only wrote that guide after seeing the confusion of Joey Hess.

No tags | No comments

Looks like my plans for installing cfengine are hitting problems before I've even started getting very far.

By default cfengine will not copy files from the master host to the client nodes if their clocks are "too far" out of sync.

Unfortunately I cannot sync the clocks on all my nodes, much as I would like to, since UML doesn't play nice with clocks going backwards ..

On the plus side I've got a nifty script which will push updates to remote systems via a combination of rsync + dpkg - that allowed me to update 50ish machines and cause them all to start logging remotely with syslog-ng in the space of around an hour.

If I could generalise this system it might be sufficient to copy files, do minor edits, and essentially do the tasks I wanted to automate with cfengine in the first place!

In related news the more I learn of ruby the more I'm coming to dislike it…. It is just so .. un-perl!

Still ruby is nicer than daemontools ;)

No tags | No comments

I've just finished recovering from an unexpected few days away to York. Unexpected because I had only intended to spend one night there, but there was some work being carried out on the trainlines over the weekend so in the end I spent three nights there, and barely staggered home on Monday morning in time to start work at 9:30.

Still nice to spend three days with my sister, her husband, and their new cat Nero.

Once I got back I uploaded a new revision of xen-tools, so the Debian package is now bugfree.

There might be more movement in that software soon. I'm currently experimenting with rpmstrap which can be used to install non-Debian distributions. Nifty.

In other news, despite valuable suggestions, I've managed to install cfengine on 69 hosts and do useful things with it.

So far I'm mostly copying files around, restarting services, and running simple jobs from it. (e.g. installing nullmailer, setting up syslog-ng to log to a central host, etc.) Still it is all going well.

No tags | No comments

xen-tools can now create images of centos, and other RPM based distributions:

xen-create-image --hostname=test.my.flat \ 
  --ip=192.168.1.123 --dist=centos4 --rpmstrap

There are two outstanding problems:

rpmstrap doesn't seem to install the RPM of centos-release so you must either manually fetch it, or edit the /etc/yum.repos.d/CentOS-Base.repo file before "yum install foo" works correctly.

(The rpmstrap command line handling is broken (#368648) so -include=centos4-release doesn't help. Plus it wouldn't work for the other distributions.)

OpenSSH is not installed automatically because of the first problem.

Anybody who is wishing to test other targets supported by rpmstrap such as mandriva, suse, etc, or is capable of helping me fix this yum problem should look at the xen-tools CVS repository or homepage.

With a bit of feedback there could be a 1.5 release early next week.

No tags | No comments

Xen-tools now correctly installs CentOS4 installations, complete with OpenSSH access.

I've not fiddled around with rpmstrap enough to cache intelligently, but otherwise it works. (What this means is that each new installation re-fetches each .rpm package from the network, rather than caching them locally.)

This new work does bring my "design decision" into focus though. Originally xen-create-image was a simple system which did two things:

1. Install a clean version of sid/sarge/etch using debootstrap.
2. Run a series of shell scripts aftwarwards to customize the new environment install networking, and install openssh. The "hook scripts".

Hooks were implemented as a directory of shell scripts run in order, much like you'd expect from run-parts.

Simple? Neat? Yes. And no.

Because each script was based around the idea of tweaking Debian they had a lot of Debian-specific knowlege in them, and so they didn't do the right thing for CentOS4.

There are two (or more!) solutions to this problem:

1. Have per-distribution hooks: hook.d/debian, hook.d/centos4, etc.
2. Have each script decide which environment it has and do the right thing.

The first has the advantage that it is simple to understand and adding additional distributions becomes simpler to approach.

The second avoids proliferation, and seems neater to me. Anyway the decision is made for the moment to use this approach. I could be swayed the other direction when it comes to time to setup SuSE, Mandriva, etc. However in all honesty I don't actually expect to do that work myself. If you need those distros you can help, capishe?

Now to backport rpmstrap to Sarge, and make a new release…

No tags | No comments

I hope that I've built my last security update for Woody now. If so I'm going to metaphorically burn my Qemu image of Woody.

Talking of Qemu I have to say it rocks! Except under Xen. I've had a lot of problems recently using Qemus serial-port pass-through under Xen.

Using Qemu on a native kernel I can use "-serial /dev/ttyS0", and then get the Windows 2000 installation + communication software I have to talk to my mobile phone. Under Xen the communication only works one-way as far as I can see the software will talk to the phone, but the phone cannot respond.

Weird.

I made a couple of Debian uploads last night to update the packages to the latest Standards Version, including fixing a trivial bug which was almost a year old which I'd completely failed to spot. I can't believe I missed it for so long.

All being well I'll make some more trivial-update uploads shortly to ensure that I don't have any suprises before the Etch freeze.

No tags | No comments