Edd Dumbill's Weblog: 'linux' articles

OSCON: what are your must-see talks?

2008-07-01T16:00:17Z

We've switched on personal schedule sharing on the OSCON web site.

When you've put together your desired schedule by starring sessions of interest, just hand out the "public view" link to let others know what you want to see.

Here's my personal schedule. In it you'll find all the plenary sessions (as co-chair I simply cannot miss these, and neither should you, however late the party!)

Also there's a fair smattering of my pet topics such as open web technologies, virtualization and dynamic languages, and a bunch of things I want to hear more about: Prophet, female participation in open source, Clutter, and of course Erlang.

I'm fascinated to find out what other people have got planned, so please publish your schedules too and let's compare notes.

Join the conversation about this post

My OSCON 2008 picks

2008-06-26T12:11:33Z

In just under a month, the tenth O'Reilly Open Source Convention will get underway in Portland.

Over ten years OSCON has developed—along with the world of open source—into an intense, exciting, informative, diverse and exhausting event. This year I've the privilege of being co-chair, along with Alison Randall. We've packed so much into the show, it's a difficult job even being able to comprehend it as a whole!

Fortunately, there's a way to start making sense of things before you arrive there, thanks to the personal scheduler. Just mark the sessions you want to go to with a star, and you'll be able to plan out your time in advance.

I wanted to list a few sessions from my own personal schedule that particularly piqued my interest. Then at the bottom of this post I'll share a discount code which can give readers of this blog 15% off OSCON registration. There's bribery for you.

Practical Erlang Programming

Largely thanks to XMPP enthusiasts and ejabberd, I've been hearing increasing amounts about Erlang, and I'd like to know enough about it to be dangerous. This three hour tutorial looks just the ticket.

Open Source Virtualization Hacks

This is one of several sessions we have on virtualization, something I'm particularly pleased about. Virtualization may be "done" at the kernel level, but I think we're only just starting out on its application. This session is by my friend and sometime co-author, Niel Bornstein, who works for Novell on just this sort of thing.

Using Puppet: Real World Configuration Management

Puppet is the piece of open source software that is most exciting to me at the moment. As a developer, it enables me to manage my machines like I'd manage my code libraries. A must-see if you've not used Puppet yet.

These are just 3 out of the 300 or so confirmed sessions. Don't forget there's a large number of events and parties happening around OSCON too.

And finally, the discount code. Use the code os08pgm when you're registering, and you'll get 15% off the ticket price.

See you in Portland!

Join the conversation about this post

Secure LDAP replication

2008-06-20T16:18:33Z

Ever the sucker for punishment, I decided to pick three difficult things and stick them all together: LDAP, SSL and replication. Here's how to make it go on Debian and Ubuntu.

The problem

You want LDAP replication to happen over the internet, and you want it to happen securely.

The caveat

I'm not going to tell you how to set up your LDAP from scratch here: I'm assuming you've reached a solution you're happy with and want to replicate it.

The solution

We're going to set up a replicating slave LDAP server, which communicates with the master over the internet via an SSL-protected connection.

Enabling replication

First up, the master LDAP server needs to be configured to permit replication.

The key lines to add to your slapd.conf include:

moduleload syncprov
index entryCSN,entryUUID eq
overlay syncprov
syncprov-checkpoint 100 10
syncprov-sessionlog 200

These load up the synchronization module, add indices which make sync go faster, and enable sync. For more detail see the OpenLDAP site.

Next you need to add a replicator user to your LDAP database, give your replicator user access to passwords as well as general read access. To create the replicator user, I made this simple LDIF file and fed it to ldapadd.

dn: cn=replicator,dc=mydomain,dc=com
objectClass: simpleSecurityObject
objectClass: organizationalRole
cn: replicator
description: LDAP replicator
userPassword: TOPSEKRIT

Once this user is in your LDAP database, you should give it read access to passwords (I assume you've already given read access to authenticated users.) I have this in my slapd.conf:

access to attrs=userPassword,sambaNTPassword,sambaLMPassword
...
   by dn="cn=replicator,dc=mydomain,dc=com" read

To check that this works, try using ldapsearch to check that the passwords are returned:

ldapsearch -x -D cn=replicator,dc=mydomain,dc=com \
  -W | grep -i password

Enter the replicator password when prompted, and you should see the encrypted passwords from your LDAP database.

Securing access

Now you've got replication enabled on the master, you will want to ensure it is available on the internet only via TLS or SSL. Here's what I added to slapd.conf to enable this:

TLSCertificateFile      /etc/ssl/certs/ldapserver_crt.pem
TLSCertificateKeyFile   /etc/ssl/private/ldapserver_key.pem
TLSCACertificateFile    /etc/ssl/certs/myCA.pem
TLSVerifyClient         demand

As you will guess from the configuration, the first two lines set the SSL key and certificate the master uses (see "A little twist" below for an important note on key permissions.) The third line tells slapd where to find my site-local certificate authority (CA), and the fourth line says slapd must require any connecting client to have a valid SSL certificate signed by the site-local CA. This is important, as it provides a second layer of access control: a replicating client must connect using a certificate you signed, plus the replicator password.

Before this enables TLS access, we must tell slapd which network interfaces to listen on. To do this, edit the SLAPD_SERVICES variable in /etc/default/slapd. Here's my configuration:

SLAPD_SERVICES="ldap://127.0.0.1/ ldap://192.168.0.1/ ldaps:///"

This enables regular LDAP on the loopback and intranet network interfaces, and LDAP/SSL on all interfaces, including the public internet.

So, with slapd restarted we are at this situation: connections are now possible from the internet, as long as they are made over SSL with a certificate signed by our site-local CA.

(In fact, you can make much finer-grained access restrictions in your configuration than I have done. Using LDAPS rather than TLS over regular LDAP is a rather broad precaution. As explained on the OpenLDAP site, the ssf= parameter can be used to require a certain level of secure connectivity on a per-user or client basis.)

Setting up the replicating server

Your slave server should have the same configuration as the master, except you can leave out the bits enabling replication.

Firstly, you'll need add to slapd.conf the replication configuration:

syncrepl rid=123
        provider=ldaps://ldapmaster.mydomain.com/
        type=refreshAndPersist
        searchbase="dc=mydomain,dc=com"
        filter="(objectClass=*)"
        scope=sub
        attrs="*"
        schemachecking=off
        bindmethod=simple
        binddn="cn=replicator,dc=mydomain,dc=com"
        credentials=TOPSEKRIT

Most of this I took as boilerplate from the OpenLDAP documentation. Items to note include:

the rid is a unique 3-digit integer per slave, used to maintain sync state
the credentials should be the password you gave the replicator user
the type can either be refreshAndPersist, or refresh. The latter institutes a simple polling replication, whose interval you can vary with the interval parameter. In our case, we do a poll and then keep the replication search open: our client gets notified immediately when there's any new data matching the replicating search.
the searchbase is an LDAP search matching the data we wish to be replicated.

And here's the /etc/default/slapd configuration:

SLAPD_SERVICES="ldap://127.0.0.1/"

The slave slapd exists only in this case to serve the local machine.

Finally, there's the tricky bit! You need to configure slapd to connect to the master server using a certificate. I'll assume you've created and signed a key and certificate pair for your slave server (see my post Low-tech SSL certificate maintenance for more on this.)

Awkwardly, the TLS configuration in slapd.conf is for the server only. Replication works as a client, and thus needs separate configuration. Furthermore, you cannot configure this globally on your machine, as the SSL certificate is a per-user only parameter (see man ldap.conf for more information on this.)

Instead, we must set it in slapd's environment. Add these two lines to the end of /etc/default/slapd:

export LDAPTLS_CERT=/etc/ssl/certs/slapd.crt
export LDAPTLS_KEY=/etc/ssl/private/slapd.key

This file is sourced as a shell script by slapd's init script. Amend the path to your certificate and keys as required. Use /etc/init.d/slapd restart and you should be good to go.

Finally, we want the slave server to be certain it's talking to the real master. So we also configure client connections to verify the SSL certificate of the peer, in ldap.conf again:

TLS_CACERT      /etc/ssl/certs/myCA.crt
TLS_REQCERT     demand

A little twist

One gotcha to notice with both client and server is that slapd runs as the openldap user by default on Debian. Also by default SSL keys are readable only by the ssl-cert group. You'll need add the openldap user to this group, otherwise it won't be able to access /etc/ssl/private.

Low-tech SSL certificate maintenance

2008-06-18T11:10:31Z

I maintain a bunch of SSL certificates, mostly signed by my own site authority. Too many not to automate, but not enough to warrant heavy machinery. Here's how I do it.

The configuration files

Each certificate needs a config to describe what's in it. I create each of these and name it with a .cnf suffix. Here's an example:

[ req ]
prompt                  = no
distinguished_name      = server_distinguished_name

[ server_distinguished_name ]
commonName              = server.usefulinc.com
stateOrProvinceName     = England
countryName             = GB
emailAddress            = edd@usefulinc.com
organizationName        = Useful Information Company
organizationalUnitName  = Hosting

[ req_extensions ]
subjectAltName=edd@usefulinc.com
issuerAltName=issuer:copy
nsCertType            = server

[ x509_extensions ]
subjectAltName=edd@usefulinc.com
issuerAltName=issuer:copy
nsCertType            = server

Let's say this config is server.cnf. I then just type make server.pem to generate the corresponding certificate and key, signed by my local certificate authority. As I don't want to attend the startup of every service, I ensure the key is password-less.

The Makefile rules

Here are the makefile steps I use to generate and sign keys.

.SUFFIXES: .pem .cnf

.cnf.pem:
        OPENSSL_CONF=$< openssl req -newkey rsa:1024 -keyout tempkey.pem -keyform PEM -out tempreq.pem -outform PEM
        openssl rsa <tempkey.pem > `basename $< .cnf`_key.pem
        chmod 400 `basename $< .cnf`_key.pem
        OPENSSL_CONF=./usefulCA/openssl.cnf openssl ca -in tempreq.pem -out `basename $< .cnf`_crt.pem
        rm -f tempkey.pem tempreq.pem
        cat `basename $< .cnf`_key.pem `basename $< .cnf`_crt.pem > $@
        chmod 400 $@
        ln -sf $@ `openssl x509 -noout -hash < $@`.0

The resultant files are:

server.pem — contains both certificate and key in one file
server_crt.pem — certificate file
server_key.pem — key file

Some notes on these steps: my site-local certificate authority is in the directory usefulCA, along with an OpenSSL config which describes my preferences. This config was created by copying and making appropriate adjustments to the default /etc/ssl/openssl.cnf which ships with Debian.

For generating certificate signing requests to ship to a commercial certificate authority, it's a bit simpler. I save the config files with a .reqcnf suffix instead, and use this rule:

.SUFFIXES: .pem .cnf .reqcnf .csr

.reqcnf.csr:
        OPENSSL_CONF=$< openssl req -newkey rsa:1024 -keyout `basename $< .reqcnf`.key -keyform PEM -out `basename $< .reqcnf`.csr -outform PEM

And finally, a rule I use to sign incoming certificate requests from other systems:

.csr.pem:
        OPENSSL_CONF=./usefulCA/openssl.cnf openssl ca -in $< -out `basename $< .csr`_crt.pem

I offer these without warranty in the hope they might be useful to somebody. They're not much more than a transcription of a how-to into a makefile, but it's just enough technology to ensure creating certificates isn't a big nuisance.

Notes

Why do I bother with a site-local CA, rather than just self-sign? It lets me bypass the annoyance of SSL warnings on clients once I've installed my own CA certificate, and gives me a coarse grained level of access control: for instance, only clients with certificates signed by my CA are allowed to access the site's LDAP server.

My personal next step with this is to integrate the certificate production process with my emerging Puppet recipes for managing local infrastructure.

Join the conversation about this post

We're all ops people now

2008-06-16T12:34:09Z

Ten years ago, most of us wouldn't have dreamt we'd be managing terabits of storage, tens of megabits of bandwidth, arrays of network-distributed services. The height of a programmer's worry would likely be choice of UI toolkit or finding the right way to indent code, and the height of consumer concern deciding which room to put the new computer in.

Now the problems associated with managing large networks are becoming real for everyone, right down to the consumer level. Stupendously large amounts of computing resource are available at an instant.

Your household probably has more than a terabyte of storage already. Issues such as single sign-on are going to hit home over the next year, as networked computing and entertainment devices profilerate. Features such as Apple's Time Machine will be increasingly vital — software that makes traditionally gnarly sysadmin tasks consumer-friendly. The rebranding of .Mac into "Mobile Me" is also a step in this direction.

The impact on developers

As software developers, we also have to cope with the effects of this resource-richness. For small sums of money we can get access to large computing clusters, geographically redundant hosting services. Our programs have left the desktop and found their new home on the web. System administration issues loom large upon us, security concerns lurk auspiciously in the corners of our minds.

Although the cost of infrastructure has dropped radically, other costs remain high and are going to stay that way. System administrators are not only grumpy, they demand high wages. Commercial software license fees spiral out of control: traditional per-CPU licensing models make little sense when you can quickly bring up tens of machines. The cost in power is already troubling large companies, and there's no reason to suspect the problems won't ripple down.

Help is at hand from a variety of technologies. If they don't yet make massive resource management trivial, they at least make it possible. Some of these also inhabit the weird territory of being both the source of a problem and a solution at the same time: virtualization, for example.

Distributed revision control systems

Distributed revision control is a technology whose time has finally come in popular circles, thanks in part to Linus Torvald's Git system. DRCS has several important impacts on today's developer:

Branching and, importantly, merging become much cheaper, allowing agile and flexible iterations of development.
Loosely connected and geographically diverse development becomes much easier. Even within a single organization it is not uncommon to find teams spanning countries, time zones. Complex multi-site VPN setups aren't necessary when a few SSH keys can do the job.
Revision control becomes packaging on the cheap. Like it or not, the mere tagging of a source tree has now become a valid option for releasing software.

All these trends lower the barrier to entry, increase collaboration and agility of development. You can the value of this as more software tools become free. Selling such tools is rapidly becoming a thing of the past, the advantages of sharing enable the developers at the sharp end to get their jobs done quicker.

However, such increased agility and, well, messiness leave other problems to solve, which the next two technologies address.

Virtualization

Hardware-as-a-service, infrastructure-as-a-service, call it what you will. The ability to create what we used to call entire machines, pick them up and move them around the network is revolutionary, and it's something that will have a real impact on regular developers. The benefits are at several levels.

Agile infrastructure — a ready supply of new machines makes it a lot easier and cheaper to test different scenarios, architectures, and to separate concerns. If things go wrong, throw away the image and start over. It's all about cutting the administration load.
A packaging solution — the new macroeconomics of software distribution mean that distributing entire machine images which communicate exclusively via the network is now a feasible way to distribute your software. We must adjust to the notion of distributing appliances, not code. We may mourn the lost crafts of creating RPMs or installers, but let's face it, it's now a waste of time.
New business models — your application can now be delivered as a black-box appliance, circumventing compatibility issues, or as a service, with virtualization part of the solution to scaling.

Configuration management

Computing is a zero-sum game, and despite our increased ability to create and distribute software, problems still exist. We just pushed them to the next level.

In good part, this next level is the problem of configuration management. We now have networks and clusters of (virtual) machines, software so agile we need six decimal places to describe its revision levels, and network and authentication paths that are starting to tangle. How do we manage that?

One thing developers crave is repeatability. That's why we love our makefiles, autoconf, Ant, rake and so on. It's the one time even the most imperative-minded programmer writes declarative code. We like to say "let the world be like this."

Our new sprawling world lacks this feature, and the best of our old toolkits — .debs, RPMs — address things only at the level of packages in a single environment.

So developers must look to the world of operations, a territory we probably thought we needn't enter. In this world the new "make" is called Puppet. You write recipes to describe how things ought to be, and Puppet will make it so.

I've been spending some time digging into Puppet, and feel excited by the confidence it's giving me. Now my applications exceed single source trees, and single machines, it gives me the means to tie the whole together. This article was going to be solely about Puppet, but that will have to wait now for another time.

It's likely you'll have played with virtual machines and distributed revision control, but have you tried Puppet yet? Give it a spin, and let your mind wander over the benefits for your organization and development approaches.

Conclusions

For developers and users alike, our world is changing. Hardware, connectivity and increasingly software is becoming cheap or free. The solidity of the old things we put value on — real things you can touch like disks — is eroding.

What really matters is our data, our creations, and their communication. If they don't quite yet exist in a universal "cloud" yet, they're certainly getting frisky.

As vendors provide solutions for consumers to manage their new domestic infrastructure, developers must look to network-aware toolkits and operations techniques to manage and get the best from their emergent infrastructures.

Also on this topic:

In search of agile infrastructure for web applications (June 2006)

Join the conversation about this post

Gandi's VM hosting beta now closed to new users

2008-06-12T13:20:08Z

I've been experimenting with Gandi's virtual hosting service recently. In fact, this blog is now hosted on it.

Gandi have created by far the easiest hosting service I've used. The web interface allows you to buy credit, create pre-installed virtual machines and log in, all in under 15 minutes. Add the ease of Ubuntu to the mix (just one of the preinstalled images you can choose from), and commissioning times for new services are low indeed.

The hosting service is based on Xen, and allows you to dynamically change the resources your VMs can access (CPU/memory/disk), on a scheduled basis if required. It has an API which provides enough functionality for you to white-label hosting as part of your own web app.

Excerpt from Gandi's explanation of the amount of resource you can allocate to a virtual machine

Gandi's service isn't yet as flexible as Amazon's EC2, but it comes at the problem from the other end — its initial offering "just works" as an alternative hosting solution, with the added flexibility their Xen infrastructure brings to the mix. Even with all its tool support, Amazon EC2 feels like stepping into an alternate universe. I'm pretty excited about the directions in which Gandi's service will develop.

And yes, now I've told you all this, unfortunately you can't yet play with the beta service if you've not got an account already. The initial success means Gandi are closing new signups for a little time to concentrate on improving their infrastructure.

The good news is that Gandi say this is the final step before the full release of the system. I can't wait! It's so good to see innovative, high-quality internet solutions coming from Europe.

Join the conversation about this post

Badges, blogging and bragging

2008-05-23T14:32:11Z

Back from my travels, it's time for a few updates. I've mostly blogged about these elsewhere, so I'll just give some pointers here.

The launch of magnetic-stripe cards at Where 2.0 went well.

We had some initial teething issues with Linux talking to the card printers, which was resolved by backing down to Linux kernel 2.6.22 from 2.6.24. I'm not entirely sure what's up with 2.6.24, but it exhibited strange behavior talking to the card printers over ethernet — as if there were MTU misconfigurations. It's a big nuisance, as 2.6.24 is the default kernel shipped with Ubuntu Hardy, an otherwise excellent release.

I've been paying some attention to OpenID 2.0 recently, as it's time for me to upgrade my OpenID accepting websites to use the new release of the specification — if for no other reason than Yahoo! OpenIDs are 2.0-only.

This investigation led me to notice XRIs again, which are the confusing underbelly of the OpenID specs. The W3C Technical Architecture Group recently advised against using XRIs. I wrote about this over on my XML.com blog.

I've not used for that blog for a long time, but will try to do so more. I've realized that I've still got a lot to say about the web, XML and open standards, and the XML.com blog seems like a good place to say it.

Finally, to brag for a short moment. Another XTech has been and gone, and this year's was a great experience for everybody involved. This quote from attendee Paul Smith summed things up nicely, as it tells me I succeeded in my main goal for the conference:

What I really liked about this conference was the mix of attendees and presenters, both from academia, and the commercial world both and small. It made it feel much more valid, and it really felt like everyone was there for the right reasons - not trying to sell anything, but out of a genuinely altruistic wish to make the web better.

My sincere thanks to everybody involved in XTech this year.

Join the conversation about this post

Smartcard authentication on Linux and Mac

2007-12-03T11:56:53Z

For various reasons, I need to secure access to some resources using two-factor authentication, and thus have been looking at smartcards. These little devices store digital keys and certificates, protected by a passphrase, and calculate digital signatures on-device. Hence the two factors: possession of the card, and knowledge of the password.

This sort of scheme is widely used by government agencies and large corporations (and largely reliant on Windows, too), but I wanted to find the low cost way in for the small operator using open source.

OpenSC on Linux

The best starting point for Linux is the OpenSC project. It supports a reasonably broad array of devices, and is well supported by Linux distributions. Using command line tools you can create keys and certificates, as you would in OpenSSL for web servers and so on, and then upload them to the smartcard.

Although OpenSSH source code has support for OpenSC, it is not compiled in by default in Debian and derived distributions. Unfortunately this means a bit of recompilation to get SSH supporting OpenSC. When that's done, you have an SSH implementation that can use an RSA key from your smartcard, and best of all, you can add this key to the ssh-agent like you would with regular keys.

The hardware

I ordered two devices, which seemed to have the best support from OpenSC, the Axalto Cryptoflex E-Gate, and an Aladdin eToken. I got these from UsaSmartCard, who have a special section in their catalogue for Open Source compatible products. Both these cards have a USB interface built-in, I didn't want to be toting around an extra card reader in addition to the tokens themselves.

On the Mac

While both the devices worked as advertised under Linux, the experience has been a lot less fruitful under Mac OS 10.5 Leopard. There is a port of the OpenSC project for Mac OS, called SCA. The promise of the integration is great: you can use the on-device keys with apps like Safari and Mail, but there is a change in the way that the daemon responsible for talking to the smartcards (pcscd) works on Leopard, which means OpenSC won't recognise the cards.

With some fiddling, I have managed to force the Cryptoflex device to work with Mac. Unfortunately the Leopard/Darwin source for OpenSSH has diverged significantly enough from the upstream OpenSSH, that I couldn't apply the OpenSC patches. Not having ssh-agent work with the smartcard is a significant nuisance for me, as it's the easiest way to patch in the extra security to deployment processes.

The Aladdin eToken just plain didn't work on Leopard. There is a report that Aladdin are working on Leopard drivers, however.

I think a small number of mainly US federal smart cards will work out of the box on Leopard, though I've seen a few complaints about these on the Apple forums. It loooks unfortunately like smartcard support slipped through the net a bit.

Conclusion

Smartcard support is relatively straightforward on Linux. On Mac OS 10.5, it looks like some waiting is in order before things will work properly.

Join the conversation about this post

Zonbu: an intersection of open source, Web 2.0 and energy efficiency

2007-08-04T13:33:26Z

Salon.com recently reviewed Zonbu, a highly compact general-purpose computer with no moving parts.

Zonbu's key features are its incredibly low power consumption, network-connected storage and that it works right out of the box without any installation. Under the covers, it's a Gentoo Linux installation with mainstream open source apps such as OpenOffice and Firefox.

Zonbu and its skins — high-powered dressing for a low-power device

Price-wise, you can get the Zonbu for as little as $99 if you commit to two years' subscription to the network storage. Understanding the open source ethos, Zonbu also offer the box without any tether for $250. As with the Mac mini, supplying the keyboard, mouse and monitor is up to you.

Preloaded with an office suite, email, IM, web browser, multimedia player, games and Skype, Zonbu is aimed at being a general computing appliance. You can't install anything else on it, but then again, that way you can't break it easily either. It sounds the sort of thing I'd be happy leaving with non-technical family and friends.

Storage with Amazon S3

Low-power solid state devices are nothing new of course, there are a variety available, and things such as the NSLU2 have been in production for some years. The novel thing about the Zonbu however is in how it manages its storage.

The Zonbu has 4GB of compact flash storage on board, which it uses as a cache for Amazon's S3 storage network. All your files get encrypted and sent to S3, and are retrieved when you need them. One really neat consequence of this is that you can get at your data via the web any time you want.

Secondly, it gives me some sense of security for my data. I don't know if Zonbu will give me the 'keys' to my data on S3, but it wouldn't be hard for them to provide an easy way to migrate out. Either way, S3 is a place I'd trust with my data.

Why Zonbu is important

Windows, and to some extent, Mac OS X, are becoming the needy children of computing, always tugging on your arm and asking you something. In contrast, Zonbu looks like a great step towards "appliance computing". Its features are more like those you'd expect from your phone or cable TV provider:

it's a black-box appliance that users don't need to care about, with little or no vulnerability to malware
the real value of the product is in the network
the system is upgraded as part of the subscription

Zonbu has the potential to change domestic computing. The low price point lowers the barrier to computer ownership. Low maintenance needs lower the technical barrier to entry and use. And Zonbu's a green and economical technology, yet as useful as the full power version.

As a company, I feel Zonbu to be a well-intentioned player because of their strong support for open source, and the ease with which you can get at your data despite its appliance nature. I hope they continue to develop in this open data direction.

Zonbu itself probably won't attain ubiquity, but it will change the marketplace and open up a new category of network-connected appliances for the home.

Nokia N800, the second time around

2007-07-02T12:45:01Z

Nokia's N800 internet tablet is an intriguing device. When I originally got one a few months back I tried to treat it purely as a consumer object, just using the installed apps and things available through the obvious point-and-click channels.

As a consequence it served mainly as a portable (and expensive) internet radio, streaming me the cricket commentary from the BBC. And when I upgraded my wireless network I somehow managed to make it WPA2 only, knocking the N800 offline. An offline N800 is an almost thoroughly useless device, so it went into the drawer and I forgot about it.

Ultimately you can't leave something that expensive unused, so I dragged it out again, fiddled the wi-fi router into compliance, and decided not to deny my hacker nature this time. The N800 is Linux underneath, so who could resist?

The result is two-edged, really: I'm a lot happier with the device, but on the other hand must conclude that the N800 is still a bit far from being consumer-ready.

Must-have software

So, what things did I install this time around that made the device happier?

Claws Mail is a nice email client that works well with my IMAP accounts, which all use SSL and TLS, have lots of messages and a deep folder hierarchy. I don't really want to write much mail on the N800, but an easy reading interface is a bonus.

The FM radio is something I can't believe I missed before. I had no idea this was in there, but plug some headphones into the N800 and they act as the antenna for an FM receiver. Desperately cute and old-world, a bit like when laptops still used to have parallel printer ports.

I had previously ignored Maemo Mapper, thinking it was useless without a GPS, but it turns out to work very nicely as a dedicated client for Google Maps, as well as several other mapping sources.

Must-do geeky bits

Try as I might to like the touch screen, the first thing I had to do with the device was find a way of not using the stylus to do sysadmin type tasks on it.

So, first stop is to get a terminal up, figure out how to use the root account, install a SSH client and server, and get my pubkey onto the N800. Now I could shell into it and use a decent keyboard.

On my local network I hate maintaining DNS if I don't have to, so the next thing I wanted was Zeroconf support in the shape of avahi. One of the quickest ways to get this going is to install the Canola media application, which uses Zeroconf to find shared music.

With these basics in place, the N800 supports APT package repositories familiar to Debian and Ubuntu users, so the device becomes a lot less weird and much more manageable. I felt the same pleasant familiarity as I did with the NSLU2.

Things to look forward to

The N800's video camera is neat, but nobody I know uses Google Talk for conferencing. Fortunately it seems that Skype for the N800 is just around the corner. Initially, video support is unlikely, but I imagine that if Skype on the N800 proves popular, it won't be far off.

The N800 is something I don't mind having kicking around the kitchen or nursery, so staying in touch with my family while I'm travelling will become a lot more fun.

Also, I'd like to get NFS running on the N800, but that requires the installation of a new kernel, which I've not quite yet had the time to do. Once that's done, all my media, photos and storage will be handily available.

Join the conversation about this post

Small bundle of sluggy joy

2007-05-31T15:56:52Z

I'm a bit late to this party, but the NSLU2—affectionately known as the 'slug'—is a piece of kit you can't afford to be without on your home or small office network.

Not much bigger than the palm of my hand, and cheaper than a ticket for a Test at Lord's, the NSLU2 is a small fileserver that serves files from attached USB disks.

What makes it particularly special is the large amount of alternative firmwares built by Linux open source developers, which allow you to extend the functionality of the NSLU2 beyond merely serving out files via SMB (the Windows file serving protocol.)

Cheap NFS serving

So what's the big deal for me? Well, like most laptop-slinging folks whose home network is predominantly wireless, I want my backup disks to sit on the network, available when needed.

It turns out it's very difficult to find a standalone network disk that properly supports Unix file system semantics such as symbolic links. Most just support SMB file sharing, with attendant limits such as no links and no files over 2GB. (I found this out the hard way with Apple's Airport Extreme.)

With the NSLU2 I was able to install the "Unslung" alternative firmware, and install good old NFS, making my backup disks available in a normal way to Linux and OS X machines alike. (How we used to complain about NFS back in the early 90s, but Windows file sharing still makes it look good!)

In the great tradition of open source there are multiple choices of Linux distributions you can install. As it was my first time round, I went for Unslung, which preserves as much as possible of the official Linksys interface, but lets you extend it. Next time, with a better idea of what I'd use the box for, I'd probably plump for Debian.

Constraints breed creativity

Inside the case, the NSLU2 is in fact a tiny Linux machine with 32MB of RAM and an Intel XScale CPU. This turns out to be plenty enough resources to serve files on a small network. Aside from my prosaic needs, the NSLU2 has been put to several more innovative uses, such as a music server for Apple ITunes and a 4-line home telephone exchange.

I've been astounded at the applications people have devised for this little box. Being fairly cheap makes it a great candidate for home automation projects. It's a great example of how limiting resources fosters innovation. Remember how games on 8-bit microcomputers were so much more ingenious than those on their more well-resourced successors?

So, I may be a little slow in finding this little hardware gem, but I wholeheartedly recommend it.

Join the conversation about this post

Living and coding on a Mac

2006-10-03T17:37:09Z

For most of this year I've been working mainly on a Macbook Pro, having deserted my Ubuntu desktop. Somebody wrote to me recently, kindly enquiring how this life was going, and asking some questions in particular.

Although of limited interest to some, I decided to answer the mail here, if for nothing else to record my views for future reference.

Q: How is developing on a Mac? Is TextMate really that good?

Developing Rails applications on a Mac is sweet, and yes, TextMate really is that good. My jilted .emacs languishes in lonely misery.

Developing other (non-Mac) stuff on a Mac is a real pain however, because nothing's where you'd expect it after years of Linux use. Like several other developers I've seen, I run Ubuntu Linux in a virtual machine under Parallels for such work.

It's not just that Macs lack apt-get (as you can get it with fink), it's that they lack the reliability of Debian or Ubuntu's package repositories to underpin it. Running Linux in a virtual machine is far easier.

On the subject of TextMate, perhaps the best compliment I can pay it is that using it reminds me of the last text editors I really felt at home in, CygnusEd and then FrexxEd on the Amiga. TextMate's most serious flaw is the inability to create split views, however. It seems to me that's a key programmers' feature, to be able to read from one source file at the same time as editing another.

Q: Is the hype about Ruby on Rails true?

I still think so. I resisted it for 6 months because I tend to be averse to anything that gets such a large amount of publicity, but then stepped aboard the train around the time of Rails 0.13.

I've not really looked back after my initial experiments seemed to bear out the claim of developing "ten times faster than PHP". I'll admit I find it hard to keep up with all the extra developments that get added at the Rails cutting edge, but then again I don't really need them. Most of those additions are refinements, rather than core changes. Constraints on my time mean I tend to write in a common Rails subset, as opposed to flexing my muscles with the obscure but clever bits.

Even if your taste isn't for Rails, then the trend that Rails, Django and friends have started is improving the web development playing field for all.

Q: What makes you happy and sad about the Mac?

The things that the Mac still scores on are:

Fonts, fonts, fonts. Despite all my many efforts at getting good letterforms on Linux, I still couldn't make it as good as OS X.
Productivity applications. I love my OmniGraffle and OmniOutliner. I'm salivating over the prospect of OmniFocus, and Quicksilver rocks my world.
Hardware. Suspend/resume without worry, video conferencing that works.

The interesting thing to me is that none of these are very difficult to surmount, for want of a little resource. The day of the Linux desktop, so perennially around the corner, will yet come.

As a balancing postscript, I will mention that there are some things that are Mac irritants to a sensible Linux person, which include filesystem case sensitivity, lack of decent SSH agent (yes, I've tried them all), not knowing what to kill -9 when things go pear-shaped, Apple's arrogance, crippled nature of some default apps (iChat won't put multiple accounts in the same window, Safari doesn't support keyboard navigation at all well, Quicktime player won't play movies fullscreen).

Join the conversation about this post

Locking down portmap on Debian

2006-09-29T13:08:15Z

Most sensible people are very wary of NFS and its potential for security holes. If you can at all help it, it's a good idea not to run NFS and portmap on a network interface with direct internet connectivity. However, this isn't always convenient.

As I needed to have NFS sharing on a host exposed to the internet, I set about finding the various places I needed to firewall. The tools I typically use to verify I've done the right things are netstat -nap on the machine concerned, to check for listening processes, and nmap from remote hosts to sniff for open ports.

Portmap and its associated programs mostly use 'tcpwrappers' for controlling access. The first step you ought to take in securing portmap is to ensure that your hosts.allow and hosts.deny files are set up to control access properly.

In /etc/hosts.deny, deny access to allcomers:

mountd: ALL
statd: ALL
portmap: ALL
rquotad: ALL

Then in /etc/hosts.allow, let the good guys through (adjust for your network):

mountd: 192.168.0.
statd: 192.168.0.
portmap: 192.168.0.
rquotad: 192.168.0.

On top of this, however, you should firewall off the ports that these programs use. As I found out, this is not as easy as it sounds. Portmap assigns random ports for some of the services it starts.

You can run rpcinfo -p to see the ports in use. An example run on one of my machines looks like this:

program vers proto   port
 100000    2   tcp    111  portmapper
 100000    2   udp    111  portmapper
 100003    2   udp   2049  nfs
 100003    3   udp   2049  nfs
 100003    4   udp   2049  nfs
 100003    2   tcp   2049  nfs
 100003    3   tcp   2049  nfs
 100003    4   tcp   2049  nfs
 100021    1   udp  32770  nlockmgr
 100021    3   udp  32770  nlockmgr
 100021    4   udp  32770  nlockmgr
 100021    1   tcp  32788  nlockmgr
 100021    3   tcp  32788  nlockmgr
 100021    4   tcp  32788  nlockmgr
 100005    1   udp   1005  mountd
 100005    1   tcp   1008  mountd
 100005    2   udp   1005  mountd
 100005    2   tcp   1008  mountd
 100005    3   udp   1005  mountd
 100005    3   tcp   1008  mountd
 100024    1   udp    863  status
 100024    1   tcp    866  status

Of these, nfs and portmapper always use the same ports, 2049 and 111, so ensure you block off these.

What about the rest? Happily, there's a way to configure them to use constant ports so we can reliably firewall them. Life would be too easy if all this configuration was in the one place, so here's how to find the different places you need to change.

nlockmgr: you're probably using the kernel NFS server, which means the port needs passing at module load time for the lockd module. Add this line into a new file, /etc/modutils/local-lockd
```
options lockd nlm_udpport=32768 nlm_tcpport=32768
```
Then run update-modules to recreate your /etc/modules.conf. The next time you boot these ports will be used for nlockmgr. If you've got the lockd statically compiled into your kernel, you'll need to pass these options as lockd.mnlm_udpport and lockd.nlm_tcpport to the kernel on boot.
status: this is the port used by statd. There's also an outgoing port, on which statd sends outgoing status requests. You can configure them by altering STATDOPTS in /etc/default/nfs-common, e.g.
```
STATDOPTS="--port 699 --outgoing-port 700"
```
mountd: you can control the port used for mountd by editing /etc/default/nfs-kernel-server and altering RPCMOUNDOPTS, e.g.
```
RPCMOUNTDOPTS="--port 962"
```

Finally, if you're running quotas, be sure to do something similar with RPCRQUOTADOPTS in /etc/default/quota.

Load-balancing Mongrel with Apache 2.0

2006-09-13T19:18:28Z

You would be forgiven for thinking that using Mongrel clusters to serve Rails applications was only a good idea if you have Apache 2.2 installed, as this is what most of the instructions on the web advise.

However, there are good reasons for still running Apache 2.0, one of them being that it's the most up to date version packaged in Debian and Ubuntu Linux. So, without mod_proxy_balancer, what can you do?

A simple solution is to use the randomizing feature in mod_apache's rewrite map feature. Say for instance you had 3 Mongrel servers, running on ports 4000 to 4002 on localhost. First create a file map.txt containing these numbers:

ports  4000|4001|4002

Then ensure the following directives are present in your virtual host configuration:

ProxyRequests Off
ProxyPassReverse / http://localhost:4000/
ProxyPassReverse / http://localhost:4001/
ProxyPassReverse / http://localhost:4002/
ProxyPreserveHost On
RewriteEngine On
RewriteMap  servers rnd:/path/to/your/map.txt
RewriteRule ^/(images|stylesheets|javascripts)/?(.*) $0 [L]
RewriteRule ^/(.*)$ http://localhost:${servers:ports}/$1 [P,L]

Of course, Apache config is complex and I advise you to test this properly — it's possible if you are not careful to leave your web server as an open proxy.

Thanks to Matt Biddulph for pointing out this method to me. I've written it up as nobody else seemed to have done so thus far.

Join the conversation about this post

In search of agile infrastructure for web applications

2006-06-17T22:57:35Z

Many advances have been made in agile software development. Frameworks such as Ruby on Rails embody agile principles by making software easy to write, easy to test, and above all, easy to change.

If only we could say the same for the infrastructure on which we develop and deploy web applications. Not every application can be a Rails one, especially where it's been up and running for years. The systems we deploy on often rely on configuration files scattered all over the filesystem, and can be complex results of years of change.

By extension, the systems we develop on often don't exactly mirror where we deploy. If we're lucky and careful, then we have a staging server which mirrors the live environment, but that's not too much of an advantage. Among other things, we need ways to evolve and refactor the live environment, and have our development environments easily track that.

I'd like to call such an environment "agile infrastructure". Infrastructure that doesn't hamper developers, and allows live configurations to change and evolve. Infrastructure that allows new things to be tried with minimum cost, and can provide the best information possible to help future planning.

Tools enable techniques, of course. It's a lot easier to be agile if you're programming in Rails rather than plain old PHP. So what are the tools enabling agile infrastructure?

Techniques I've found useful

While there's a long way to go, I'd like to describe some of the techniques I've been using to help create a flexible environment for developing a sizeable PHP/MySQL application.

Operating system

An operating system must be easy to bring into a known state with minimum interference. For this, I've found Ubuntu or Debian to be an ideal choice. Two of the main reasons include the constancy of stable releases and the fact that it's rare you need to stray outside the distribution's servers to get the software you need.

Deployment

Deploying an application shouldn't break the cleanliness of your OS build. I prefer to package deployed applications into .deb files. This enables me to build on several advantages of the package management system:

configuration file handling: deployed machines can keep individual config in /etc, which is preserved over software update.
no random state: you know for sure exactly the state of the deployed application, no random files left hanging around.
natural workflow: packages take a little bit of effort to build and deploy, which means it focuses developers on getting them right. If things do go wrong, it's very easy to roll back one version.

Source control

The case for source control, thankfully, doesn't need making these days. Yet not every source control system is created equal. Developers shouldn't be constrained by source control, it should be cheap and easy to try new ideas and merge these in later.

Not only cheap branching, but also easy merging, is required to keep development agile while still retaining the benefits of source control. Many people flock to Subversion these days, predominantly because it fixes some of CVS' more egregious misfeatures. However, merging can still be pretty difficult in Subversion.

I prefer to use a system allowing easy merging, such as svk or bazaar. Because so many of us use laptops these days, disconnected operation is also a huge boon. Bazaar-NG offers both repository-oriented and completely decentralized operation, giving the best of both worlds. It also wins the competition for least setup overhead.

Virtualization

Previously a high-powered technology, cheap virtualization is now with us. Many identical virtual machines can be quickly created to enable testing and experimentation. Deployment to virtual machines can enable hardware independence for applications, reducing another big headache.

Large organisations have it within their reach to bring new hardware online easily, and have invested much in management systems for it. Virtualization brings this in reach of small and one-man development teams.

Desktop-based virtualization

Systems such as VMWare and Parallels untether developers from their desks. I use the OS X desktop daily for its productivity software, but an Ubuntu virtual machine for a large proportion of development work. A simple keypress lets me flick between the two. The advantages of multiple desktops to hand for web development are well known. (In fact, thanks to WINE and IES4Linux I can run Internet Explorer cheaply too from the same virtual machine).

Xen virtualization

After the initial novelty wears off, one of the most tedious tasks in the world is bringing new machines online. Combined with the tendency development environments have to get crufty as new ideas and tools are tried out, this makes for increasing disparity between the development and deployment environments.

Wouldn't it be nice just to take a clean machine off the shelf, check out the source, and pick up again? Using Xen for Linux, this cheap virtualization is possible.

Sadly, Xen isn't yet a packaged part of Ubuntu, but getting it up and running on Ubuntu Dapper isn't too hard. Warning: here's where things get pretty deep. Skip this bit if you're not interested in the nitty-gritty.

I followed these steps:

Followed instructions in the Ubuntu wiki to get the first domain (vm) up and running
Installed the xen-tools package, which provides wrappers for easily creating virtual machines
Adjusted some of the xen-tools configuration (/etc/xen-tools/hook.d/20-setup-apt) to set up for Ubuntu rather than Debian
Once the virtual machine was made, adjusted its config to allow for the kernel initrd and configure the network bridge I was using

Getting over the DNS mountain

If you want it to be easy to bring new virtual machines up and down, you need to adopt a different approach to managing your DNS. You need to know how to predictably connect to a virtual machine. Yet it's going to get very boring and error prone to manage the IP address space manually in your DNS, or even to map the MAC addresses of your virtual machines in your DHCP configuration.

Help is at hand in the form of mDNS (also known as Rendezvous / Bonjour / ZeroConf). In the host machine, and in each virtual machine, I ensured the avahi-daemon and avahi-utils packages were installed, providing mDNS services. (You should also check that mdns is present in the hosts entry of /etc/nsswitch.conf).

What all this does is allow the machines (virtual or otherwise) on the network to resolve names using mDNS. So if I create 3 VMs, alpha, beta and gamma, I can access these right away using the hostnames alpha.local, beta.local and gamma.local.

Hey presto! Easily make machines appear and disappear without any need for sysadmin involvement. All the extra steps to add avahi installation can be easily scripted with xen-tools, to reduce the number of commands needed to birth a new machine to one.

With this ease of creating new machines, it's much more straightforward to experiment with server topology and conduct experiments on server environments.

Conclusion

Agile development is necessarily constrained by the infrastructure on which it is conducted. The infrastructure itself is constrained by the tools and platforms of choice.

By appropriate tool choice we can reduce the commitment and overhead of infrastructure. This enables developers to get on with the job they do best, and makes experimentation and evolution of infrastructure much simpler.

When programming, it's dangerous to fall in love with your code, as the best solution may often involve throwing half of it away. The same hazard exists with infrastructure, with bizarre and awkward effects propagating back into code and operations. Get yourself a low commitment, agile environment, and you'll be able to keep up with the pace.

Join the conversation about this post

Better subpixel rendering on Linux

2006-05-27T12:59:57Z

The move to better subpixel rendering in X windows continues. Tobias Wolf kindly pointed out to me these new patches from David Turner. Turner says "it's rather delicious" and I'm inclined to agree.

Applied to libXft and Cairo, they remove a lot of the ugly colour fringing from subpixel rendered fonts under Linux.

David posts a screenshot, which looks great on my screen (if you have a CRT or different pixel ordering, it may look horrible for you -- the disadvantage of subpixel and screenshots!)

Update: Tobias mentions another patch, which is needed to get best results.

Further update: Diego Escalante Urrelo has posted some Ubuntu packages with the patches in.

Join the conversation about this post

Catching up

2006-04-10T23:15:22Z

Most of my energy recently has been devoted to organising things for XTech 2006, now just over a month away.

Here are some XTech-related snippets:

Mozilla Corporation has joined as a co-host. We'll have six Mozilla related presentations, plus a keynote about JavaScript 2 from Mozilla CTO Brendan Eich.
The Ajax Developers' Day continues to take shape. We're looking to add a Ajax toolkit lightning demo session at the end of the day. Contact me if you or your company wants to take part in this.
BarCamp Amsterdam II will be taking place directly after XTech. This will be a free-form participant-led conference, held over the weekend. Many XTech speakers and attendees are likely to hang around to take part.

MacBook

My new computer has arrived, an Apple MacBook Pro. I know I wrote some time ago about how disappointing it was for free software advocates to be using a non-free OS, and I am rather sad about this in some ways. I'll be writing in the near future about my impressions of the platform, and reasons for buying this machine.

Writing

My latest piece on Debian has been published over at O'Reilly, Installing Software on Debian. We've been a little slow getting through the publication of these, so I'll try and hurry the next few along.

Rails

Rails continues to impress. I wish I had more time than I do to use it, as it feels so right to work with. With Matt Biddulph I'll be teaching a day on Rails at XTech 2006. In the meantime, I highly recommend Chad Fowler's Rails Recipes, it covers the most common requirements from real-world web applications.

Oh, and I'm scheduled to attend RailsConf this June. My paper was (not too surprisingly) declined for the conference, but Matt's was accepted.

Join the conversation about this post

Linux fonts: still wanting

2006-01-22T16:02:26Z

Fonts on Linux have had a chequered history. Mostly, they've been bad. Once, there was an excuse for this: GNOME and KDE were unable to render anti-aliased text, and there was a paucity of decent free TrueType fonts. Now, with Xft, Freetype and Bitstream Vera fonts things are different.

Unfortunately, it's hard to find Linux distributions that have gone the extra mile to make the fonts look good by default. Let's take a brief look through default fonts in various operating systems.

Mac OS X offers a great default, which looks good on all modern machines. No user configuration required.

Windows default is blocky, as there's no anti-aliasing to speak of, but the hinting on the fonts is excellent and they're crisp. If you dig a bit and find the crazily hidden Display properties - Appearance - Effects dialog, you can turn on ClearType.

Windows ClearType offers a pleasing level of font smoothing. Now, let's look at the GNOME default, taken from a screenshot on the GNOME 2.12 start page.

This is pretty much how default GNOME looks on any machine. In particular, it's the default look you get when you install Ubuntu. This corresponds to a setting of full hinting in the font preferences, with the font Bitstream Vera Sans. The quality of the type, however, is poor. It has a spidery and ungainly quality to it.

In and of itself, Vera is not an ugly font. There's some combination of the font's hinting and the Freetype hinting engine that conspires to make things ugly. On my desktop I've tried to work around this by altering the font settings somewhat.

The effect isn't perfect, but a lot better to look at. The font is Bitstream Vera Sans as before. To get this, I had to switch off any hinting then slowly play with the DPI setting until I get letterforms that rendered neatly.

Alas, this brings problems of its own. For a start, not all popular GNOME applications respect this setting. Firefox often gets its own idea about such matters as screen DPI, and OpenOffice.org2 completely ignores my hinting preferences and gives me nasty looking menu bars. Murray Cumming's recent GNOME for bad eyesight blog post also gets into many of these issues.

For most users without time or inclination to hunt this down the choice is either to live with the ugliness, or opt for an operating system that gets it right.

(Lest I seem churlish here, I should celebrate the amazing work done with internationalization on the Linux desktop, which continues to bring computing access to many in the world for whom choice is a luxury.)

There is one Linux distribution that makes a reasonable job of good-looking fonts. The Fedora Core 4 distribution ships with a different default font and out of the box settings giving reasonably attractive letterforms. Courtesy of OSDIR, here are GNOME and KDE screenshots. However, I'm pretty sure it doesn't solve the rest of the font integration issues.

I'm no typography expert, but I find that good-looking fonts enable me to work more effectively. And on the advocacy side, I want my Linux desktop to look as good or better than the OS X and Windows alternatives.

Lots of great effort was made getting us to the point of anti-aliased rendering and the licensing of the Bitstream Vera Fonts. Having got this far, it seems a shame not to hunt down the remaining irritations in font handling.

New series on Debian

2005-10-02T22:08:07Z

The first article in a new series I'm writing on administering Debian GNU/Linux has been published on O'Reilly Network: Installing Debian.

This opening piece is a little longer than typical for the series--installation is, after all, not easily digested into smaller chunks! Upcoming articles will deal with configuring the system for your desired use, and learning how to work with Debian's particular features and support systems.

Most of the articles will work well for Ubuntu and other systems derived from Debian. In fact, it's mostly in the details of installation that the experience varies most between the distributions.

Join the conversation about this post

Edd Dumbill's Weblog: 'linux' articles

OSCON: what are your must-see talks?

My OSCON 2008 picks

Secure LDAP replication

The problem

The caveat

The solution

Enabling replication

Securing access

Setting up the replicating server

A little twist

Low-tech SSL certificate maintenance

The configuration files

The Makefile rules

Further reading

Notes

We're all ops people now

The impact on developers

Distributed revision control systems

Virtualization

Configuration management

Conclusions

Gandi's VM hosting beta now closed to new users

Badges, blogging and bragging

Smartcard authentication on Linux and Mac

OpenSC on Linux

The hardware

On the Mac

Conclusion

Zonbu: an intersection of open source, Web 2.0 and energy efficiency

Storage with Amazon S3

Why Zonbu is important

Further reading

Nokia N800, the second time around

Must-have software

Must-do geeky bits

Things to look forward to

Small bundle of sluggy joy

Cheap NFS serving

Constraints breed creativity

Living and coding on a Mac

Locking down portmap on Debian

Load-balancing Mongrel with Apache 2.0

In search of agile infrastructure for web applications

Better subpixel rendering on Linux

Catching up

Linux fonts: still wanting

New series on Debian