Entries posted in December 2009

But now that I have you in my custody, I may do with you what I please.

Sunday, 27 December 2009

I sketched out a quick prototype of a Kernel ChangeLog viewer:

Choose the kernel on the left, select the changelog summary at the top and the text is shown in the bottom pane.

I spend a fair amount of time reading kernel changelogs and something like this (but with nice filtering and searching) would be useful. The only major problems I see are :

  • "Recent" changelog entries have one format, older ones have another.
  • You need to download a lot of changelog files locally for it to be useful.

Anyway if you follow kernels you might like the idea, if not the implementation. I look forward to seeing your improved version. (Doesn't free software rock? ;)

ObSubject: Aeon Flux

| 4 comments.

 

And if someone gets upset you say, "chill out"!

Friday, 25 December 2009

It was interesting to see Clint Adams describe love and dissatification with configuration management.

At work I've got control of 150(ish) machines which are managed via CFEngine. These machines are exclusively running Debian Lenny. In addition to these hosts we also have several machines running Solaris, OpenBSD, and various Ubuntu releases for different purposes.

Unfortunately I made a mistake when I setup the CFEngine infrastructure and when writing all the policies, files, etc, I essentially said "OK CFEngine controlled? Then it is Debian". (This has been slowly changing over time, but not very quickly.)

But in short this means that the machines running *BSD, Solaris, and non-Debian distributions haven't been managed as well via CFEngine as the rest, even though technically they could have been.

A while back I decided that it was time to deal with this situation. Looking around the various options it seemed Puppet was the way of the future and using that we could rewrite/port our policies and make sure they were both cleanly organised and made no assumptions.

So I setup a puppetmaster machine, then I installed the client on a range of client machines (openbsd, debian lenny, ubuntu, solaris) so that I could convince myself my approach was valid, and that the tool itself could do everything I wanted it to do.

Unfortunately using puppet soon became painful. It has primitives for doing various things such as maintaining local users, working with cronjobs, and similar. Unfortunately not all primitives work upon all platforms, which kinda makes me think "what's the point?". For example the puppet client running upon FreeBSD will let you add a local user, setup a ~/.ssh/authorized_keys file but will not let you setup a password. (Which means you can add users who can login, but then cannot use sudo. Subpar)

At this point I've taken a step back. As I think I've mentioned before I don't actually do too much with CFEngine. Just a few jobs:

  • Fetch a file from the master machine and copy into the local filesystem. (Making no changes.)
  • Fetch a file from the master machine, move it to the local system after applying a simple edit. (e.g "s/##HOSTNAME##/`hostname`/g")
  • Install a package.
  • Purge a package.
  • Setup local user accounts, with ~/.ssh handled properly.
  • Apply one-line sed-style edits to files. (e.g. "s/ENABLED=no/ENABLED=yes/" /etc/default/foo)

(i.e. I don't use cron facilities, I add files to cron directories. Similarly I don't use process monitoring, instead I install the monit package and drop /etc/monit/monitrc into place.)

There is a pretty big decision to make in the future with the alternatives being:

  • Look at Chef.
  • Stick with CFEngine but start again with a better layout, with more care and attention to portability things.
  • Replace the whole mess with in-house-fu.

If we ignore the handling of local users, and sudo setup, then the tasks that remain are almost trivial. Creating a simple parser for a "toy-language" which can let you define copies, edits, and package operations would be an afternoons work. Then add some openssl key authentication and you've got a cfengine-lite.

For the moment I'm punting the decision but I'm 90% certain that the choice is CFEngine vs. Chef vs. In-House-Fu - and that puppet is no longer under consideration.

Anyway despite having taken months to arrive at this point I'm going to continue to punt. Instead my plan is to move toward using LDAP for all user management, login stuff, and sudo management. That will be useful in its own right, and it will coincidentally mean that whatever management system we do end up using will have on less task to deal with. (Which can only be a good thing.)

ObFilm: Terminator II

| 14 comments.

 

You're gonna need a bigger boat.

Sunday, 20 December 2009

I'd like to nominate this week of the year to be :

  • National Backup Week.

(I'd pick a single date but the only date I care about is March 10th, and that has already been assigned National Fishnet Day.)

So, national backup week? This week is the week I'd like to suggest that you ensure that all the hosts, systems, and machines you care about are backed up.

Maybe not today, maybe not tomorrow, but soon they will die. If you have a system die without a backup you're screwed.

If this week is a quiet time at work, or if you're having time off, take an hour, take a few, and ensure you have backups .. current backups.

ObFilm: Jaws

| 10 comments.

 

Where the hell can I get eyes like that?

Wednesday, 9 December 2009

This week I've been mostly migrating guests from Xen to KVM. This has been a a pretty painless process, and I'm happy with the progress.

The migration process is basically:

  • Stop the Xen guest (domU).
  • Mount the filesystem (LVM-based) upon the Xen host (dom0).
  • Copy those mounted contents over to a new LVM location upon the KVM host using rsync.
  • Patch the filesystem once the rsync has been moved:
    • Create /dev nodes for the new root & swap devices.
    • Update /etc/fstab to use those devices.
  • Fiddle with routing to ensure traffic for the guest arrives at the KVM host, rather than the Xen host.
  • Hardwire static routes on the dom0 so that cross-guest traffic works correctly.
  • Boot up the new guest, and hope for the best.

The main delay in the migration comes from the rsync step which can take a while when there are a lot of small files involved. In the future I guess I should ask users to do this themselves in advance, or investigate the patches to rsync that let block devices be transferred - rather than filesystem contents.

Thankfully all of the guests I've moved thus far have worked successfully post-migration, and performance is good. (The KVM host is going to be saturated with I/O when the rsyncing of a new guest is carried out - so I expect performance to dip while that happens, but once everybody is moved it should otherwise perform well.)

So Xen vs. KVM? Its swings and roundabouts really. In terms of what I'm offering to users there isn't too much difference between them. The only significant change this time round is that I'll let users upload their own kernel and one brave soul has already done that!

ObFilm: Pitch Black

| 13 comments.

 

I feel a hate crime coming on.

Sunday, 6 December 2009

Recently I've been spidering the internet, merrily downloading content for the past few days.

The intention behind the spidering is to record, in a database, the following pieces of information for each image it stumbles across:

  • The page that contained the link to this image. (i.e. the image parent)
  • The image URL.
  • The MD5sum of the image itself.
  • The dimensions of the image.

I was motivated by seeing an image upon a website and thinking "Hang on I've seen that before - but where?".

Thus far I've got details of about 30,000 images and I can now find duplicates or answer the question "Does this image appear on the internet and if so where?".

Obviously this is going to be foiled trivially via rotations, cropping, or even resizing. But I'm going to let the spider run for the next few days at least to see what interesting things the data can be used for.

In other news I'm a little behind schedule but I'm going to be moving from Xen to KVM over the next week or ten days.

My current plan is to setup the new host on Monday, move myself there that same day. Once that's been demonstrated to work I can move the other users over one by one, probably one a day. That will allow a little bit of freedom for people to choose their downtime window, and will ensure that its not an all-or-nothing thing.

The new management system is pretty good, but I have the advantage here in that I've worked upon about four systems for driving KVM hosting. The system allows people to enable/disable VNC access, use the serial console, and either use one of a number of pre-cooked kernels or upload their own. (Hmmm security you say?)

ObFilm: Chasing Amy

| 15 comments.

 

Recent Posts

Recent Tags