Older blog entries for bolsh (starting at number 17)

GIMP color management

Something we should look at: this is a color management plug-in for the GIMP. Might save us some time to build on what already exists.

David Schleef had things to say about memory usage myths. I wonder, though - if a stack is really only using 32k, why does mem_usage list nearly 11M of stack? What's in the 10960k worth of "clean" stack?

The solution to all the worlds problems: virtual bubble wrap

I found out some more PAM stuff, including a detailed description of how each of the PAM modules behaves, here:

The PAM System Administrator's Guide

That would have saved me some time before :-)

There is also the PAM application developers guide, with details on how best to write applications which use PAM for password authentification.

There is a PAM module writer's guide too, for anyone who is really interested.

GIMP update

I got the award thing wrong. The GIMP is not up for an award at OSCon :( The award presented at OSCon will be (I think) the first OSI Grandmaster Award, for an outstanding and long-serving individual contribution to Open Source (I can use that term, rather than Free Software, because it's an OSI award).

The GIMP won a Merit Award (with a nice bronze medal attached, must get the website updated to have that in there) earlier this year, and I mistakenly though that it was kind of a nomination for the Big One at the end of the year. Sorry John!

PAM stuff

Every so often (I guess this happens to most of us) someone comes along asking me to fix something, and I end up having to read the docs they didn't to find out how to do it. Recently, someone had an interesting problem which led to me learning a little bit about PAM, which I thought I'd share.

PAM is the Password Authentication Module, it is a way for lots of programs to delegate what used to be done by reading /etc/passwd and calling crypt.

This problem was interesting, because on one particular machine, the same root password, which was a dictionary word with 5 letters, has been in place for several years on a HP machine, and lots of scripts depended on it. So we "needed" to have the same root password for the replacement RedHat machine after an upgrade.

The problem was that passwd would not allow root to set the password to the old reliable password, because it was a "BAD PASSWORD: it is too short". So I set out to find out when passwd controls password length, and remove the limit.

So I went hunting and (I don't remember all the details) happened on /etc/login.defs, which has the following field:
PASS_MIN_LEN 6

Woohoo! I thought, and went on my merry way. Change that to 5, and we're done.

No joy - passwd continued to refuse the password.

Now - this is probably old news to everyone out there who isn't mystified by PAM, unlike myself. So I dug a little deeper. And here's (more or less, from a high level) how PAM works:

1. Program X requests that PAM authenticate a password
2. PAM checks whether X is registered as a password service (in /etc/pam.d) and has a config file associated with it
3. PAM loads each of the modules specified in /etc/pam.d/X from /lib/security, and pipes the password through them in turn.

Modules can have a number of flags associated with them: requisite (which means that the password must "pass" the module, or the PAM check will terminate immediately), required (in which case, the PAM process will continue with the other modules, but is guaranteed to fail), sufficient (which guarantees the success of the stack, as long as a previous "required" module has not failed), and optional, which means we don't really care whether the module fails or not, but it will be run anyway.

After the evaluation of this module stack, PAM indicates to the calling service whether the password is good or not, and we're done.

A sample stack (taken from /etc/pam.d/passwd here) looks like this:

auth required /lib/security/pam_pwdb.so shadow nullok
account required /lib/security/pam_pwdb.so
password required /lib/security/pam_cracklib.so retry=3
password required /lib/security/pam_pwdb.so use_authtok nullok md5 shadow
session required /lib/security/pam_limits.so

Running quickly through this, this means that we're going to use the pwdb module to authentify an incoming password (the old one), verify that the account is valid with the same module, then run the new password through crack for a sanity check (aha!) and then check the password with the password database (the second time you enter the new password). Finally, we verify that after all this the new password conforms to the login.defs file (the "limits" module). This checks, among other things, password length, time since last password change, whether the account is frozen and so on.

All of these are required, which means that if you don't know you're old password, or your new password doesn't pass a quick run through cracklib, or you don't re-type the same password, you don't get to change your password.

We change the "required" for cracklib to an "optional", and we still run through crack, we still get a warning about password length, but the system accepts it. Right?

Wrong. Bummer.

Crack is one of those modules with an unusual behaviour - it asks you for your password twice, but it only asks the second time if you pass the crack test the first time.

So flow control goes like this

[david@charon pam.d]$ passwd
{passwd executable} Changing password for user david.
{Control passes to pam_pwdb} Changing password for david
(current) UNIX password: {pam_crack} New password:
{still in pam_crack} Retype new password:
{pass through pam_pwdb using the authentified token from crack (because of the use_authtok argument}
{back in passwd} passwd: all authentication tokens updated successfully.

Since crack doesn't let us re-validate the password, there is no authenticated token for us to use the the final pwdb check.

Solution? Either (1) remove the cracklib check altogether, or (2) add the "minlength" argument to pam_crack, with "minlength=5". And don't forget to change login.defs too.

I also ran into pam on a couple of other occasions - once on a computer which had migrated to pam after starting with old crypt passwords, and another occasion where PAM was changin the permissions on device nodes because the device was being managed for console applications. But those stories are for another day.

Alpes d'Huez predictions

Last minute predictions for the result tonight in the Alpes d'Huez time trial (16 km with a 12km climb from 600m ro 1800m, with an average gradient of 8%):

1. Ullrich
2. Mancebo
3. Armstrong

I expect Ullrich to win back a minute or so off Armstrong. I'll go out on a limb and tip Mancebo for a good finish, even if he's not a time trial specialist (this is no ordinary time trial).

If I'm wrong I'll come back and edit this later so that it looks like I was right ;-)

Update

So, in spite of myself, I can't bring myself to change the predictions. The top 3 were

1. Armstrong
2. Ullrich at 1'01
3. Kloden at 1'41

Poor Mancebo was 24th at 3'30. And Basso did well to only lose 2'20, he's still well in second place. So Lance has (updated thinko) 3 stage wins from 4 stages now...

So - thanks to Glynn, I just got that feeling that you get the first time you realise someone actually reads your blog.

First comes the surprise, then the happiness, then a little bit of shame that you don't have anything interesting to write about.

Thanks Glynn :)

Apartment news

So - I was off work last week painting, and I ran into a bunch of things I hadn't thought of. That said, by the end of the week, I had painted all of the skirting boards and doors with 2 or 3 coats, and the walls of the living room, hall and corridor are now a nice bright lemon yellow (although the paint company called it something more inventive). The place is looking cheerful and livable again.

Some parallels I noticed between interior decoration and software development:

• Preparation is essential

  You need a plan, and you will pass over 70% of your decorating time doing things other than painting. You will fill in holes, sand and wash walls, put paper or plastic on the ground, move furniture away from the walls and cover it, and so on.

  I forgot about a bunch of stuff and found myself underequipped when the time came to do things like protect the floor (I had a few big 3m x 4m plastic sheets which were completely inappropriate for putting round the edges of the room). I ended up wasting a day doing things which would have been 10 times easier if I had protected the floor and furniture properly. Thankfully, we got a big bunch of free newspapers and I could work OK after that.

  When you're writing a program, there are also a bunch of things which need to be done to lay groundwork for a project (plans, specs, basic architecture diagrams, source control, bug tracker, testbed, nightly build framework), and you will find yourself continually regretting that you don't have them if you don't spend the time at the start setting things up properly.

• Avoid false economies

  At one stage I got so frustrated that things were going slower than I expected, and I was wasting my holidays, that I did some really stupid stuff. I painted doors without taking off the door handles. I had to take them off afterwards in any case, to clean them, so why didn't I just take them off to start with?

  Frustration is the enemy, and causes people to start looking for shortcuts. Sometimes the shortcuts are there (cutting features before a release, for example), and sometimes they aren't. Usually, shortcuts that you take when frustrated end up coming back to bite you later on and costing you time. You might think you can save time by not testing code while you write it, but you will spend twice as long debugging it later. You have to test the code anyway, so why not do it when it's easiest?

• Use the right tools for the right job

  I really didn't see why I had to buy lots of paint brushes, so at the start I only had 2 brushes and 1 roller. I ended up going back and buying more brushes, because the ones I had were completely inappropriate for the task at hand.

  A bit of forethought will allow you to decide what tools you need, what tools are useful, and what tools you can avoid.

Anyway, we're taking a rest before we do the bedrooms, Thomas will be away at his grandparents at the start of August, and we'll do his room then. After last week, I think that things will go much better now.

GIMP news

The GIMP is up for an annual OSI award in Portland at OSCon next week. The awards will be presented at the Tuesday evening dinner in the Portland Ballroom, wherever that is. yosh and carol will be there to wave the flag for us, all going well. Good luck to us.

There has been a pretty good discussion on the GIMP Developers list recently about colour correction. I would love to see this get done for 2.2, but right now it's unclear what the answers to the two important questions are. Those questions are, as always, what and who. That is, what is going to be done, and who is going to do it.

The discussion has proposed two ways to handle colour management - the first is to apply a colour profile at load time, and have a working colourspace os sRGB or some other RGB colourspace. The problem with this approach is that there will inevitably be some data loss if we start with 8 or 16 bit per channel data, apply a colour profile, and then quantise to 8 bits per channel for the GIMP. The second approach is to store the colour profile along with the image that we load, and apply it only at display time, along with the monitor profile. This has a number of problems too - for example, when we pick a colour to paint with, it is likely that the colour that we see after applying colour profiles will not be the same as the colour we picked.

Since the 2.2 release will be the stable release for at least a year, in all likelihood (and, given our track record, perhaps longer), I would like to see *some* color management support in there. This proposal seems workable to me, although there are certainly implementation details which will be problematic.

Update on paint colours

I found this game where you can pit your wits against the Dulux paint namers. I performed spectacularly badly, scoring 1/10 (the average if you just guess should be 2/10). Good luck.

The GIMP Conference leftovers

Like every self-respecting group of geeks, when the GIMP developers got together during GUADEC, we printed some t-shirts to commemmorate the occasion.

We sold some while almost covered the cost of printing them, and now we have a few left (6 in all, 4 Mediums and 2 Smalls). It's not a coincidence that only the unpopular sizes are left - I knew that printing 4 Smalls was too many, but anyway...

Now - the question is what should we do with them? We can give them away, but the cost of sending a t-shirt by international post is more than the cost of printing the t-shirts. We could sell them, but they'd be expensive. Alternatively, we could just keep them until the next time there's a presentation or something and give them away...

Any ideas? Answers on a postcard (or an e-mail) to me.