UK Linux User Groups

A couple of years ago my good friends Chris and Heidi set up their own theatre company, Boffo Theatre. As well as their own productions, they also run acting and musical classes for young people.

A few months ago I spent a hectic Saturday photographing the three members of Boffo, Chris, Heidi and Carly, as they taught their classes. They certainly work hard but all their students seemed to have a great time.

Afterwards we spent some time making new headshots for the Boffo crew and then we got to have some fun, coming up with new images for them to use in their marketing materials. It was great to have the time to experiment and be creative. Having access to an entire theatre including a well-stocked wardrobe helped too! A handful of the photos accompany this blog post.

So if you are looking for acting and musical classes for young people in the Kent area, check out the Boffo website or Facebook group.

Pin It

The next meeting will be on Monday 8th of April from 7:30 at Veritas for a social
meet-up.

Feel free to bring your Linux problems and issues down for the experts to take
a look at (laptops only, of course).

If you’re new to Linux and want a little hand-holding, do come along, or if
you just fancy a bit of geeky chat there’s always lively debate on a range of
geek and non-geek subjects.

The GNOME Foundation started the Free & Open Source Software Outreach Program for Women, OPW, in 2010. In the January-April 2013 round, many other FOSS organizations joined the program. We are happy to announce that Debian will also join in the next round from June-September and we'll offer one internship.

You can find more details about Debian's participation in the program at Debian OPW page.

Call for mentors and projects

OPW allows applicants to work on any kind of project, including coding, design, marketing, web development... The Debian Google Summer of Code projects will be offered also as possible projects for OPW, but GSoC only allows coding projects. If you have any idea of a non-coding project and you want to mentor it, please contact us in the soc-coordination mailing list adding [OPW] in subject.

OPW works in the same way as GSoC except Google doesn't play a part here. The same advice that is provided for GSoC mentors works for OPW mentors.

Call for participants

The main goal of this program is to increase the number of women in FOSS, so all women who are not yet a Debian Developer or a Debian Maintainer are encouraged to apply. There are no age restrictions and applicants don't need to be a student.

If you want to apply, you must follow three steps:

1. Choose a project from this list. There are two lists, one for GSoC and another with non-coding tasks that can be only offered by the OPW. Those lists may change and add or remove more projects in the next few weeks.

2. Make a small contribution to Debian. Projects will add a task the applicant must complete as part of the pre-selection process. If no task is provided, you are welcome to ask the mentors of the project. You can also make a different extra task of the one listed to show your skills and interest.

3. Create a page in the Debian wiki with your application. You can do so under pseudonym, but in that case, please give us information about yourself privately by email to the coordinators listed in the Debian OPW page!

Just a quick note: I will be on vacation this week in Australia. I will be checking in with work and email, but this will be more limited throughout the week.

Look forward to seeing everyone in a week! Lots of exciting things to focus on when I get back.

We are pleased to announce the 15th annual Debian Conference (DebConf14) is to be held in Portland, Oregon, USA in August 2014, with specific dates yet to be announced.

Portland is an open source hotspot in the Pacific Northwest of the US. It is a technologically savvy community, home to Intel and the adopted home of Linus Torvalds. The city plays host to many Free Software conferences including OSCON, and is where Linux Plumbers originated.

The local team has been involved in mulitple DebConfs in the past, and is excited to bring their experience and ideas to fruition in a city well-positioned to host such a prestigious event.

Foreman integrates with a bunch of systems such as DNS (BIND, AD), DHCP (ISC) and Puppet when systems get created and destroyed. It does most of this via its smart proxy architecture, where an agent (the proxy) is deployed on your other servers which gets called from your central Foreman host during "orchestration".

Most production setups are a bit more complex though with other systems we don't integrate with in Foreman, so the plugin support in version 1.1 is there to extend Foreman's capabilities. Since this means learning some Ruby and Rails, I've released foreman_hooks so admins can instead write simple shell scripts to hook straight into Foreman's orchestration feature.

I'm going to walk through a example hook to run a PuppetDB command to clean up stored data (facts, resources) when hosts are deleted in Foreman. First we'll install the plugin by adding this config file:

# echo "gem 'foreman_hooks'" > ~foreman/bundler.d/foreman_hooks.rb And then run this to install and restart Foreman: # cd ~foreman && bundle update Fetching source index for http://rubygems.org/ ... Installing foreman_hooks (0.3.1) # touch ~foreman/tmp/restart.txt

(Debian users will need to do: sudo -u foreman bundle update instead, due to packaging differences.)

Next, we'll create a hook script that runs when a managed host is destroyed in Foreman:

# mkdir -p ~foreman/config/hooks/host/destroy # cat << EOF > ~foreman/config/hooks/host/destroy/70_deactivate_puppetdb #!/bin/bash # We can only deactivate data in PuppetDB, not add it [ "x$1" = xdestroy ] || exit 0 # Remove data in PuppetDB, supplying the FQDN # # assumes sudo rules set up as this runs as 'foreman': # foreman ALL = NOPASSWD : /usr/bin/puppet node deactivate * # Defaults:foreman !requiretty # sudo puppet node deactivate $2 EOF # chmod +x ~foreman/config/hooks/host/destroy/70_deactivate_puppetdb

(on Foreman 1.2, change "host" in the path to "host/managed")

There are a few things here to note. The path we're creating under config/hooks/ refers to the Foreman object and event (see the README). For hosts we can use "create", "update" and "destroy" to extend the orchestration process and there similar events for every other object in Foreman. The 70 prefix influences the ordering with other tasks, see grep -r priority ~foreman/app/models/orchestration for more.

The script gets two arguments, the first is the event name ("destroy" etc) and very importantly for orchestration events, this can change. If an orchestration task fails, the process will get rolled back so the script will then be called with the opposite event to the one it was first called with. For example, a hook in the create/ directory will first be called with "create", then a later task may fail and it will be called again with "destroy" to revert the change. Orchestration of DNS records etc in Foreman works in the same way. Since this example is only able to remove data and not add it, the first line checks the argument and exits if it isn't asked to destroy. Other scripts should take note of value of this argument.

The second argument is the string representation of the object, i.e. the FQDN for host objects. On stdin, we receive a full JSON representation which gives access to other attributes. There are helpers in hook_functions.sh to access this data, see examples/ to get a copy.

Lastly in this example, we run the PuppetDB command to remove the data. The exit code of orchestration hooks is important here. If the exit code is non-zero, this will be treated as a failure so Foreman will cancel the operation and roll back other tasks that were already completed.

Now when the host gets deleted from either the Foreman UI or the API, the host gets deactivated in PuppetDB: # puppet node status test.fm.example.net test.fm.example.net Deactivated at 2013-04-07T13:39:59.574Z Last catalog: 2013-04-07T11:56:40.551Z Last facts: 2013-04-07T13:39:30.114Z There's a decent amount of logging, so you can grep for the word "hook" in the log file to find it. You can increase the verbosity with config.log_level in ~foreman/config/environments/production.rb. # grep -i hook /var/log/foreman/production.log Queuing hook 70_deactivate_puppetdb for Host#destroy at priority 70 Running hook: /usr/share/foreman/config/hooks/host/destroy/70_deactivate_puppetdb destroy test.fm.example.net

One area I intend on improving is being able to interact with Foreman from within the hook script. At the moment, I'd suggest using the foremanBuddy command line tool from within your script - though you shouldn't edit the object from within the hook, unless you're using the after_create/after_save events.

I hope this sets off your imagination to consider which systems you could now integrate Foreman into, without needing to start with a full plugin. Maybe we could begin collecting the most useful hooks in the community-templates repo or on the wiki.

(PuppetDB users should actually use Daniel's dedicated puppetdb_foreman plugin. I hope development of dedicated plugins down the line will happen as a natural extension.)

I look after a bunch of servers, working for Bytemark that is not a surprise, but I only touch a very small number of desktop systems.

precious - My desktop

This is the machine upon which I develop, check my personal mail, play my music & etc.

steve - My work machine

To keep the working from home separation going I have a machine I only use for work purposes.

travel/travel2 - EEPC box

I have two EEPC machines, a personal 701 and a work-provided 901.

Honestly these rarely get used. One is for when I'm on holiday or traveling, the second for when I'm on-call.

Yesterday I got round to upgrading both the toy EEPC machines to wheezy. The good news? Both of them upgraded/reinstalled easily. Hardware was all detected, sleeping, hibernation, wifi, etc all "just worked".

Unfortunately I am now running GNOME 3.x and the experience is unpleasant. This is a shame, because I've enjoyed GNOME 2.x & bluetile for the past few years.

The only other concern is that pwsafe appears to be scheduled for removal from Debian GNU/Linux - the list of open bugs shows some cause, but there are bugs there that are trivial to fix.

For the moment I've rebuilt the package and if I cannot find a suitable alternative - available for squeeze and wheezy - then I will host the package on my package repository.

In conclusion: Debian, you did good. GNOME, I've loved and appreciated you for years, but you might not be the desktop I want these days. It's not you, it's me.

The qemu ssh block device is now up to version 7 … although sadly not upstream yet.

Nevertheless by applying this patch to libguestfs you can use libguestfs to access remote disks over ssh:

$ export LIBGUESTFS_QEMU=~/d/qemu/qemu.wrapper $ export LIBGUESTFS_BACKEND=direct $ ./run ./fish/guestfish Welcome to guestfish, the libguestfs filesystem interactive shell for editing virtual machine filesystems. Type: 'help' for help on commands 'man' to read the manual 'quit' to quit the shell ><fs> add /tmp/f17x64.img readonly:true format:raw \ protocol:ssh server:onuma ><fs> run 100% ⟦▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒⟧ 00:00 ><fs> inspect-os /dev/vg_f17x64/lv_root ><fs> inspect-get-product-name /dev/vg_f17x64/lv_root Fedora release 17 (Beefy Miracle) ><fs> list-filesystems /dev/sda1: ext4 /dev/vg_f17x64/lv_root: ext4 /dev/vg_f17x64/lv_swap: swap ><fs> mount /dev/vg_f17x64/lv_root / ><fs> cat /etc/redhat-release Fedora release 17 (Beefy Miracle)

Everything just works as if this were a local disk.

There are a couple of minor caveats (the major caveat being none of this is upstream): Firstly you have to have ssh-agent set up. Secondly the remote host must be in your known_hosts file (if not, do ssh remotehost first to add it).

Although grub support in libguestfs is currently on hold because of an unfortunate situation, the latest libguestfs now supports SYSLINUX and EXTLINUX, which is (let’s be frank about this) a much simpler and more sane bootloader than grub/grub2.

In fact, you can make a bootable Linux guest real easily now. Here’s a script:

#!/usr/bin/perl # Copyright (C) 2013 Red Hat Inc. # # This program is free software; you can redistribute it and/or modify # it under the terms of the GNU General Public License as published by # the Free Software Foundation; either version 2 of the License, or # (at your option) any later version. # # This program is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the # GNU General Public License for more details. # # You should have received a copy of the GNU General Public License # along with this program; if not, write to the Free Software # Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA. # This ambitious script creates a complete, bootable guest. use strict; use warnings; use Sys::Guestfs; my $disk = "syslinux-guest.img"; # Find prerequisites. my $mbr = "/usr/share/syslinux/mbr.bin"; unless (-f $mbr) { $mbr = "/usr/lib/syslinux/mbr.bin"; unless (-f $mbr) { die "$0: mbr.bin (from SYSLINUX) not found\n"; } } print "mbr: $mbr\n"; my $mbr_data; { local $/ = undef; open MBR, "$mbr" or die "$mbr: $!"; $mbr_data = <MBR>; } die "invalid mbr.bin" unless length ($mbr_data) == 440; my $kernel = `ls -1rv /boot/vmlinuz* | head -1`; chomp $kernel; unless ($kernel) { die "$0: kernel could not be found\n"; } print "kernel: $kernel\n"; print "writing to: $disk ...\n"; # Create the disk. unlink "$disk"; open DISK, ">$disk" or die "$disk: $!"; truncate DISK, 100*1024*1024; close DISK; my $g = Sys::Guestfs->new (); $g->add_drive ($disk, format => "raw"); $g->launch (); unless ($g->feature_available (["syslinux"])) { die "$0: 'syslinux' feature not available in this version of libguestfs\n"; } # Format the disk. $g->part_disk ("/dev/sda", "mbr"); $g->mkfs ("msdos", "/dev/sda1"); $g->mount ("/dev/sda1", "/"); # Install the kernel. $g->upload ($kernel, "/vmlinuz"); # Install the SYSLINUX configuration file. $g->write ("/syslinux.cfg", <<_END); DEFAULT linux LABEL linux SAY Booting the kernel from /vmlinuz KERNEL vmlinuz APPEND ro root=/dev/sda1 _END $g->umount_all (); # Install the bootloader. $g->pwrite_device ("/dev/sda", $mbr_data, 0); $g->syslinux ("/dev/sda1"); $g->part_set_bootable ("/dev/sda", 1, 1); # Finish off. $g->shutdown ();

After running the script, you can try booting the minimal “guest” (note it only contains a kernel, not any userspace):

$ qemu-kvm -hda syslinux-guest.img

Thanks to a generous donation by Bytemark Hosting, Debian started deploying machines for its core infrastructure services in a new data center in York, UK.

This hardware and hosting donation will allow the Debian Systems Administration (DSA) team to distribute Debian's core services across a greater number of geographically diverse locations, and improve, in particular, the fault-tolerance and availability of end-user facing services. Additionally, the storage component of this donation will dramatically reduce the storage challenges that Debian currently faces.

The hardware provided by Bytemark Hosting consists of a fully-populated HP C7000 BladeSystem chassis containing 16 server blades:

• 12 BL495cG5 blades with 2x Opteron 2347 and 64GB RAM each
• 4 BL465cG7 blades with 2x Opteron 6100 series and 128GB RAM each

and several HP Modular Storage Arrays:

• 3 MSA2012sa
• 6 MSA2000 expansion shelves

with 108 drive bays in total, mostly 500GB SATA drives, some 2TB, some 600GB 15kRPM SAS, providing a total of 57 TB.

57 TB today could host roughly 80 times the current Debian archive or 3 times the Debian Snapshot archive. But remember both archives are constantly growing!

A bunch of friends and colleagues are staying at the Marriot West India Quay for the upcoming Adobe Summit. I used to live near there, so here’s some local perspective.

There is a line of pubs and restaurants along the Quay (Henry’s, Browns, La Tasca), most of which are better off skipped. One exception is Dockmaster’s House, around the back, which is a pretty good Indian restaurant.

The Marriot is just a short walk (across a bouncy bridge) to the heart of Canary Wharf (or one DLR stop if you want, but really the bridge is nicer). Canary Wharf offers more choice.

Note that if you need to do some gift shopping, there is also a mall running underneath Canary Wharf with a good selection of shops.

Note also that compared to the US, all of these restaurants will seem ridiculously expensive. Some places I’ve been to:

• Wahaca – innovative Mexican tapas from a former Masterchef contestant. Lots of small tasty dishes. Pick 3 or 4 each. Informal atmosphere.
• Canteen – “English” food like sausage and mash, roast chicken. Great comfort food. Informal.
• Plateau – posh European (fancy burger, croque monsieur). Smart. Go for the view, not the food.
• Roka – very good Japanese.
• Smolenskys – expensive English pub. Decent burger.
• Jamie’s Italian – celebrity chef Italian food. Excellent pasta. Casual. Usually quite busy. No booking unless parties of 6 or more.
• Boisdale – steak and chips with jazz. Steak isn’t up to American standards, but an ok atmosphere.
• Gaucho – steak and chips. Almost American standard.
• Le Relais de Venise L’Entrecôte – steak and chips, covered in secret sauce. Actually pretty good.
• Krüger – Need a good full English breakfast? Look no further.
• Byron – fancy burgers.
• Café Rouge – overpriced French food, chain restaurant. Food is ok though.
• Sri Nam – pretty good Thai.

For the full list, see the Canary Wharf website (which may be a bit out-of-date; the Battery Club has gone, for example).

Some other local delicacies:

• Noodle Street Pretty reasonable Chinese food, that delivers to the door.
• The Grapes, ancient boozer owned by Gandalf. Tiny, atmospheric. A 10 minute walk along the river from Canary Wharf.
• The Narrow (by celebrity chef Gordon Ramsay): picturesque and packed pub by the river, a pleasant 15 minute walk from Canary Wharf along the riverside.

 Feel free to ask if you have any questions or specific requirements.

 

Sometime this spring (when it arrives) I will buy a new desktop system. It will probably have two block devices: a traditional SATA large capacity hard drive and a much smaller and faster flash drive.

The theory says that cheap flash drives are much faster and will even probably outlive mechanical spinning disks. Flash systems do slowly go bad so use wear-levelling software in the controller to maximise life. The other problem with flash drives is that they are relatively small, so a larger drive either in the box or on the network is required given how much space life takes up...

I've no plan to join the two drives together with LVM, it seems pointless, instead they will be kept separate and one mounted onto the other. At the moment most of my systems use ext3 except one box which uses ext3 and XFS.

If I install a new box from the Wheezy ISO I'm guessing I'll get ext4 as default. I gather this is the logical upgrade from ext3 until something fancy is really ready and it is not an all singing-dancing next generation filesystem. Does anyone know how it compares with XFS on large disks or flash disks?

I'll probably use ext4 on the flash disk (root & boot file systems) and XFS on the spinning disk (/srv) as it's where I'll dump my media files which aren't small and XFS is supposed to be good for that, unless it's not worth the effort.

Nice explainer on the oddities of ARM.

https://fedoraproject.org/wiki/Architectures/ARM/Secret_Decoder_Ring

Gaffer: "Hmm, I had to spend ages on Friday sorting out an email issue for a customer, great Bank holiday I had!"
Me: "Ah well, that's what comes of part owning the business."
Gaffer: "Hrmph, mutter, mutter, grumble."