DebianMuc release party, add yourself now. Saturday, at the Flaucher (Isar).Weather forecast for this week is great. Probably around 24 C on saturday, the warmest day this week I've heard. It will still be getting cold at night (after all, it's not summer yet, though we like pretending it is); so maybe we should meet rather early. Also make sure to bring some warmer clothes, too.Anyway, there is the Wiki and our mailinglist for organizing the party.

Yesterday, I wrote about our init actually being /bin/sh, since all sysvinit does it start a single shell script. Today, I'm going a bit into how services are brought up with sysv-style init. I won't be writing much about runlevels, since most users will not make use of multiple runlevels anyway. So what does a typical init script in /etc/init.d do? If you want to find out yourself, consider looking at /etc/init.d/skeleton, which is a template for init scripts. A modern init script should (as required by the LSB) start with a formatted comment with metadata such as dependencies and description. This is already trying to address some shortcomings of sysv-style init, but no actual code. The first thing most init scripts do is to check if their application is actually still installed. Init scripts are sometimes created by users, or are not automatically uninstalled since being treated as 'configuration files'; so it occurs often that the init script is still around even when the service was uninstalled. So they test if they're installed and executable. Next they probably read a configuration file, usually named /etc/default/packagename, with user settings (people used to do such changes in the init script itself, but for upgrading it proved to be a lot better to put all settings the user might want to modify there). The third step is to do the requested user action, which usually is one of 'start', 'stop', 'reload' and 'restart'. Some init scripts also have extra actions such as 'status'; not all init scripts support 'reload'. Doing such an action usually means to print out a status message and launching the service in the background (usually using the 'start-stop-daemon' daemon helper, which offers functionality to e.g. record the process PID in a file or forcing applications into the background that don't do so on their own), or locating the service (usually via a PID file, again this is commonly done using start-stop-daemon) and reloading or stopping it. Upon success, they again print a status message. An init script could be as simple as:

#!/bin/sh
if [ "$1" = "start" ]; then
  /usr/local/sbin/mycheapdaemon &
fi

There are many good reasons not to do it that way, but it will work. Some characteristics of sysv-style init scripts:

• When starting or stopping services manually, init is not involved. Or notified. (In particular this means init will still try to stop the service on shutdown, and will not try to stop services that aren't on it's list of services to stop.) - there is no system-wide state tracking.
• if a service quits, nobody notices
• init scripts do a best-effort to return a meaningful status if the startup of the service was successful. But often this is not possible (e.g. when a daemon backgrounds unconditionally before checking if it has a working configuration)
• init scripts are often run by the root user, and can sometimes even be executed successfully by non-root-users. This is particularly annoying with SELinux in 'strict' mode, that tries to differentiate between applications started by the system administrator and system services. For full protection, you need to use run_init /etc/init.d/script start, which will transition into the system user role, then start the service.
• many services aren't very cooperative and need the help of start-stop-daemon for writing pid files and/or backgrounding
• Since services are started/stopped by the admin occasionally (e.g. during upgrades), and init scripts are supposed to print a status message (these "Starting service foobar: foobard [done]" messages), they will have file descriptors open to the admins console. They will also inherit environment variables from the admin. When a daemon fails to handle them appropriately, odd things can happen. This ranges from services dying when the admin logs out (and they quite on a SIGPIPE signal triggered by the file descriptor being closed; this is why 'nohup' in the coreutils package exists. An example is IBMs tivoli backup software) to e.g. tomcat behaving differently when it has a $DISPLAY variable (i.e. started with a graphical output available).

Keep your eyes open for the next part of this series, where I'll show how some init systems improve on these issues.

Yesterday, I wrote about our init actually being /bin/sh, since all sysvinit does it start a single shell script.Today, I'm going a bit into how services are brought up with sysv-style init. I won't be writing much about runlevels, since most users will not make use of multiple runlevels anyway.So what does a typical init script in /etc/init.d do?If you want to find out yourself, consider looking at /etc/init.d/skeleton, which is a template for init scripts.A modern init script should (as required by the LSB) start with a formatted comment with metadata such as dependencies and description. This is already trying to address some shortcomings of sysv-style init, but no actual code.The first thing most init scripts do is to check if their application is actually still installed. Init scripts are sometimes created by users, or are not automatically uninstalled since being treated as 'configuration files'; so it occurs often that the init script is still around even when the service was uninstalled. So they test if they're installed and executable.Next they probably read a configuration file, usually named /etc/default/packagename, with user settings (people used to do such changes in the init script itself, but for upgrading it proved to be a lot better to put all settings the user might want to modify there).The third step is to do the requested user action, which usually is one of 'start', 'stop', 'reload' and 'restart'. Some init scripts also have extra actions such as 'status'; not all init scripts support 'reload'. Doing such an action usually means to print out a status message and launching the service in the background (usually using the 'start-stop-daemon' daemon helper, which offers functionality to e.g. record the process PID in a file or forcing applications into the background that don't do so on their own), or locating the service (usually via a PID file, again this is commonly done using start-stop-daemon) and reloading or stopping it. Upon success, they again print a status message.An init script could be as simple as:

#!/bin/sh
if [ "$1" = "start" ]; then
  /usr/local/sbin/mycheapdaemon &
fi

There are many good reasons not to do it that way, but it will work.Some characteristics of sysv-style init scripts:

• When starting or stopping services manually, init is not involved. Or notified. (In particular this means init will still try to stop the service on shutdown, and will not try to stop services that aren't on it's list of services to stop.) - there is no system-wide state tracking.
• if a service quits, nobody notices
• init scripts do a best-effort to return a meaningful status if the startup of the service was successful. But often this is not possible (e.g. when a daemon backgrounds unconditionally before checking if it has a working configuration)
• init scripts are often run by the root user, and can sometimes even be executed successfully by non-root-users. This is particularly annoying with SELinux in 'strict' mode, that tries to differentiate between applications started by the system administrator and system services. For full protection, you need to use run_init /etc/init.d/script start, which will transition into the system user role, then start the service.
• many services aren't very cooperative and need the help of start-stop-daemon for writing pid files and/or backgrounding
• Since services are started/stopped by the admin occasionally (e.g. during upgrades), and init scripts are supposed to print a status message (these "Starting service foobar: foobard [done]" messages), they will have file descriptors open to the admins console. They will also inherit environment variables from the admin. When a daemon fails to handle them appropriately, odd things can happen. This ranges from services dying when the admin logs out (and they quite on a SIGPIPE signal triggered by the file descriptor being closed; this is why 'nohup' in the coreutils package exists. An example is IBMs tivoli backup software) to e.g. tomcat behaving differently when it has a $DISPLAY variable (i.e. started with a graphical output available).

Keep your eyes open for the next part of this series, where I'll show how some init systems improve on these issues.[Update: next part]

The linux kernel includes a SCSI target infrastructure since 2.6.20. Most of the code is located in the userspace and supports iSCSI, ibm i/pSeries virtual SCSI and Xen SCSIback. To work properly it needs a bunch of patches on top of 2.6.21-rc. After I got it working I did some tests with bonnie. First the target:

Version  1.03       ------Sequential Output------ --Sequential Input- --Random-
                    -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
                 2G           32124  17 18063   6           45815   4 324.6   0

Now with the vSCSI initiator:

Version  1.03       ------Sequential Output------ --Sequential Input- --Random-
                    -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
                 2G           18513   9 16208   5           34003   3 221.4   0

And the iSCSI initiator:

Version  1.03       ------Sequential Output------ --Sequential Input- --Random-
                    -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
                 2G           31631  14 12809   4           39241   5 306.3   1

As this tests was done on one OpenPower machine, all transfers uses DMA between the two systems. The vscsi case is currently limited to 128KiB per request, maybe this is a problem.

BOF stands for Birds Of a Feather, it's an informal session run at a conference usually without any formal approval by the people who run the conference.

Often conferences have a white-board, wiki, or other place where conference delegates can leave notes for any reason. It is used for many purposes including arranging BOFs. To arrange a BOF you will usually write the title for the BOF and the name of the convenor (usually yourself if it's your idea) and leave a space for interested people to sign their names. Even though there is usually no formal involvement of the conference organizers they will generally reserve some time for BOFs. Depending on the expected interest they will usually offer one or two slots of either 45 minutes or one hour. They will also often assist in allocating BOFs to rooms. But none of this is needed. All that you need to do is find a notice-board, state your intention to have a BOF at a time when not much else is happening and play it by ear!

My observation is that about half the ideas for BOFs actually happen, the rest don't get enough interest. This is OK, one of the reasons for a BOF is to have a discussion about an area of technology that has an unknown level of interest. If no-one is interested then you offer the same thing the next year. If only a few people are interested then you discuss it over dinner. But sometimes you get 30+ people, you never know what to expect as many people don't sign up - or have their first choice canceled and attend the next on the list!

To run a BOF you firstly need some level of expert knowledge in the field. I believe that the best plan is for a BOF to be a panel discussion where you have a significant portion of the people in the audience (between 5 and 15 people) speaking their opinions on the topic and the convener moderating the discussion. If things work in an ideal manner then the convener will merely be one member of the panel. However it's generally expected that the person running the BOF can give an improvised lecture on the topic in case things don't happen in an ideal manner. It's also expected that the convener will have an agenda for a discussion drawn up so that if the panel method occurs they can ask a series of questions for members of the BOF to answer. My experience is that 8 simple questions will cover most of an hour.

One requirement for convening a BOF is that you be confident in speaking to an audience of unknown size, knowledge, and temperament. Although I haven't seen it done it would be possible to have two people acting as joint conveners of a BOF. One person with the confidence to handle the audience and manage the agenda and another with the technical skills needed to speak authoritatively on the topic.

Some of the BOFs I have attended have had casual discussions, some have had heated arguments, and some ended up as lectures with the convener just talking about the topic. Each of these outcomes can work in terms of entertaining and educating the delegates.

But don't feel afraid, one of the advantages of a BOF is that it's a very casual affair, not only because of the nature of the event but also because it usually happens at the end of a long conference day. People will want to relax not have a high-intensity lecture. One problem that you can have when giving a formal lecture to an audience is nervous problems such as hyper-ventilating. This has happened to me before and it was really difficult to recover while continuing the lecture. If that happens during a BOF then you can just throw a question to the audience such as "could everyone in the room please give their opinion on X", that will give you time for your nerves to recover while also allowing the audience to get to know each other a bit - it's probably best to have at least one such question on your agenda in case it's needed.

Note that the above is my personal opinion based on my own experience. I'm sure that lots of other people will disagree with me and write blog posts saying so. ;)

The facts which I expect no-one to dispute are:

• BOFs are informal
• Anyone can run one
• You need an agenda
• You need some level of expert knowledge of the topic

If you use grep-dctrl, sort-dctrl or tbl-dctrl, I’d like to see your use cases! I’m building a system test automaton for dctrl-tools, and I’d like to include as much real-world examples as possible so that any regressions get found before uploading. You can send example command lines (and preferably also a test file, unless it’s one of the standard Debian files like Packages) to me by email at <ajk@debian.org>, as a wishlist bug report against dctrl-tools or by a Darcs patch against the experimental repository (see instructions).

Oh well... today I upgraded a server at my workplace from Sarge to Etch. This went fairly well EXCEPT that the machine was quite slow afterwards and Samba didn't work anymore. No problem, I thought, because during the upgrade the Samba was displaying a note that I'll need to change the passdb line, because it doesn't support chained backend lists anymore.
The problem was, that this didn't help. To make a long story short:
During the upgrade the file /etc/libnss-ldap.conf has been overwritten without any notification. There's even no /etc/libnss-ldap.conf.dpkg-old file.
Apparently the QA of the Etch release failed in this particular case. Am I the only one who's using LDAP?

Update:
Meebey hinted me to have a look at the config file. The problem is, that the config file has a Debconf header, which indicates that it is handled by debconf. I'm used to edit those files anyway, because usually debconf (or the package scripts) notices if the file was changed manually and gives a warning about this issue. Well, the libnss-ldap package seems to be rather dumb and doesn't recognize when something has been changed within its configuration file. So, removing the debconf header will prevent this from happening again. Thanks, Meebey!

Wow, what a wonderful weekend was this for Debian. And, yet again, I managed to miss the live announcement and party on IRC.
So... We got a shiny, new, French DPL. Just after that, we got one last release for Sarge, and right away we got a stable Etch - Who says having a new DPL cannot speed up things? ;-) Anyway... I don't remember where I started the meme when Sarge was released (it was not on my blog, it seems)... But here it goes again:
What were you doing at...
Etch release? Having a nice time with Nadezhda, walking around this broken and dear city in my last day of vacations.
Sarge release? At my psychologist. Yes, Sarge drove us all nuts.
Woody release? Sitting at a lent workstation at Departamento de Seguridad en C mputo in my University. Of course, the announcement was broadcasted right away to everybody around me ;-) I was in NM by then, and was a bit disappointed because my work didn't appear in the release.
Potato release? Don't know... I was not yet involved with Debian by then.
[Update]: Thanks to Wouter, my old meme-starting message appeared - is he more patient than I am, or just more organized? :-) Anyway, boo for Jaws breaking old URLs (I upgraded 0.4->0.5->0.6->0.7 since then)

So, one of the reasons I've been a bit uncommunicative the last few weeks is that I've been getting my head around Coq, maybe one of the most fascinating pieces of software I've played with in a long time.

What is Coq? I don't know if I understand it well enough yet to give a complete description (the Coq tome only arrived in the mail on Friday and I have yet to make it past the introduction, what with taxes and so on). Here's my best shot:

Coq is a programming language where you write proofs as functions taking proofs of their preconditions and producing proofs of their results. That is, a proof that "If X is an integer, then X-1 X" becomes a function that accepts a proof of "X is an integer" and produces a proof of "X-1 X".

You can manipulate logical expressions more or less the way you expect. For instance, if you have in your hands a set S of natural numbers and a proof that "forall nonempty sets T of naturals, T has a least element", then you can bang these together to produce the least element of S (or rather, a proof that it exists).

I don't think this describes the theoretical underpinnings of Coq, but it does describe my experience of actually using it to prove stuff.

To get the hang of Coq, I'm working my way through basic automata theory -- regexps are done, but I couldn't work out how to express some finiteness constraints on FSMs without generating a lot of extra typing; hopefully the Coq book will have some hints. Once that's done, I'm actually tempted to try something more ambitious. [snip long digression] We'll see ... watch this space :).

It was a real rush, though, to code up these theorems and watch the computer verify them. What really fascinated me was how close to being a practical tool this is. Coq isn't at all a toy -- without quite getting all the theory yet, my intuition is that it can probably cover anything you can express in the predicate calculus (with sufficient amounts of typing, anyway), and while there are a few shortcomings, it's almost (IMO) at the point where anyone who knows some formal logic and has a little patience can prove interesting stuff. Even more suggestive of possibilities, there's a project (which I sadly haven't had time to look at) that integrates Coq with OCaml, so you can have proofs about your OCaml code verified at compile-time!

I could go on and on ... anyway, this is a really cool tool and I'd encourage any mathematically-minded person to give it a spin. The only sad thing is that I doubt I'll ever have the opportunity to explore this stuff in my day job unless/until I go back to school :-(.

Shortcomings of Coq specifically and the whole concept of correctness proofs on programs generally have been moved to a future blog post that may never appear depending on how ambitious I'm feeling this week. Rest assured that I'm aware of (some of) them, I just hit my self-imposed length limit.

[0] the reason being that I could only prove correct the formal underpinnings of the resolver; in practice, a lot of the bugs are in the interface to apt, or in apt itself, and I can hardly prove that code correct.

...Paris in the springtime. I'm just back from a great afternoon wandering around the city under a nice and "just warm enough" sun. Sure we went to the touristic places as we were accompanied by my sister's family...but I always enjoy these places even when they're crowded the way they were today (Easter Monday is a holiday here). Always plan your visits to Paris in springtime...and, of course, don't forget warning /me when coming, in case we can spend a few time enjoying the city. There's nothing I like more than driving and accompanying friends here around. Just ask Kenshi, Helen, Karunakar, Jamil and the few others Free Software friends who shared a few moments with me in the city. We would of course invite our brand new shiny DPL who already impressed me with his first DPL post.

James Dumay writes about Theo's latest flame-war.

One interesting part of the debate was Theo's response to this comment:
> We can dual license our code though and that is an
> acceptable license for Linux, the kernel.

Theo:
We? Sure, you can. But Reyk will not dual license his code, and most of the other people in the BSD community won't either, because then they receive the occasional patch from a GPL-believer which is ONLY under the GPL license, and then they are no less screwed than they would be from the code granted totally freely to companies.

The difference of course is that when you give code to companies under the BSD license you will never know what is done to it, but GPL-only patches can still be used as inspiration for new code development. Sure GPL-only code can't be copied into BSD-only code, but once you know where the bugs are they are easy to fix.

Towards the end of the debate Theo asks the following question:
David, if you found a piece of your code in some other tree, under a different license, would your first point of engatement be a public or private mail?

I can't speak for David, but after reading the discussion I would probably start by blogging about such an issue.

In Debian bug 418210 there is discussion of what constitutes a cluster.

I believe that the node configuration lines in the config file /etc/ha.d/ha.cf should authoritatively define what is in the cluster and any broadcast packets from other nodes should be ignored.

Currently if you have two clusters sharing the same VLAN and they both use the same auth code then they will get confused about which node belongs to each cluster.

I set up a couple of clusters for testing (one Debian/Etch and the other Debian/unstable) under Xen using the same bridge device - naturally I could set up separate bridges - but why should I have to?

I gave each of them the same auth code (one was created by copying the block devices from the other - they have the same root password so there shouldn't be a need for changing any other passwords). Then things all fell apart. They would correctly determine that they should each have two nodes in the cluster (mapping to the two node lines), but cluster 1 would get nodes ha1 and ha2-unstable even though it had node lines for ha1 and ha2.

I have been told that this is the way it's supposed to be and I should just use different ports or different physical media.

I wonder how many companies have multiple Heartbeat installations on different VLANs such that a single mis-connected cable will make all hell break loose on their network...

A little remembered fact is that the Debian Jr. project had a directory in the subversion repository of the CDD project at Alioth. Aside from Andreas Tille’s experimental conversion of Debian Jr. to use cdd-dev¹, there was nothing else there until today. While I was in the process of populating this directory with the junior-* metapackages and adding an external reference to the live CD config, it seemed to me that it would be better to move the whole thing to our own repository at Alioth, which I promptly did. So now you can check it out:

$ svn co svn://svn.debian.org/debianjr

As well, I registered Debian Jr. at http://cia.vc/ and configured svn so that the CIA bot will report on the #debian-jr channel at irc.debian.org for every commit. And finally, I applied for the creation of a debian-commits@lists.alioth.debian.org list. As soon as the list is created, I will hook it up to the repository so you can subscribe to commit emails.

¹ Although this seemed like a good idea at the time, for various reasons I ended up sticking with the single metapackage per category model Debian Jr. uses to this day. But I have retained this experiment in the repository under svn://svn.debian.org/debianjr/branches/EXP-cdd-dev in case we ever reverse that decision.

Most of the time when I lookup the IP addresses used in FTP and SSH scans, they belong to some network in china. And apparently the last two times when the Asus website was modified (this time exploiting another unpatched vulnerability in Microsoft Internet Explorer, with .ani files), they were loading exploit code from certain servers in China. Well, I guess you just cannot trust their regime; if it isn't actively encouraging the hacking activities, it at least completely fails to do something about them (you might recall that China tries to censor much of the Internet, but apparently they aren't able to firewall off hackers going out?). It's hard to tell what their motivations are. I guess it's military interests (i.e. having points of attack in case of a war) combined with industrial espionage. To me this means, that I can't really trust developers from China, and that I better double-check their code. While I don't assume them to be bad guys, you never know what their government might force them to do. Sorry about that.

I recently had a nice discussion on a mailinglist about #!/bin/bash vs #!/bin/sh as the shebang line in shell scripts.
In general I support to use #!/bin/sh, maybe there are some corner-cases in which it makes sense to use #!/bin/bash, I am not a shell programmer.
But since the guy from shellscripts.org (btw why shellscripts and not bashscripts?) told me that I have to use a bashism to
alter a variable outside the scope of a loop because of the created subshell and in my opinion this is a common misunderstanding I blog this.



results in 123 because the loop has its own subshell and no access to foo outside of its scope.



is the proposed bashism to solve this issue, it will result in 456.



Also results in 456 and is sh-compliant (or at-least runs in ksh93 which is the reference implementation for the POSIX standard.
What also surprised me is that this is not running in bash, dash but in zsh
I reported this as a bug in bash and dash for Debian, please correct me if I am wrong.

I recently had a nice discussion on a mailinglist about #!/bin/bash vs #!/bin/sh as the shebang line in shell scripts.
In general I support to use #!/bin/sh, maybe there are some corner-cases in which it makes sense to use #!/bin/bash, I am not a shell programmer.
But since the guy from shellscripts.org (btw why shellscripts and not bashscripts?) told me that I have to use a bashism to
alter a variable outside the scope of a loop because of the created subshell and in my opinion this is a common misunderstanding I blog this.



results in 123 because the loop has its own subshell and no access to foo outside of its scope.



is the proposed bashism to solve this issue, it will result in 456.



Also results in 456 and is sh-compliant (or at-least runs in ksh93 which is the reference implementation for the POSIX standard.
What also surprised me is that this is not running in bash, dash but in zsh
I reported this as a bug in bash and dash for Debian, please correct me if I am wrong.

As usual, Ed Felten offers a well-conceived analysis of the Cablevision decision from a technologist’s perspective (for a lawyer’s perspective, see William Patry). The money quote:

The question, in other words, was who was recording the programming. Was Cablevision doing the recording, or were its customers doing the recording? The customers, by using their remote controls to navigate through on-screen menus, directed the technology to record certain programs, and controlled the playback. But the equipment that carried out those commands was owned by Cablevision and (mostly) located in Cablevision buildings. So who was doing the recording? The question doesn t have a simple answer that I can see. This general issue of who is responsible for the actions of complex computer systems crops up surprisingly often in law and policy disputes. There doesn t seem to be a coherent theory about it, which is too bad, because it will only become more important as systems get more complicated and more tightly intereconnected.

Agency, intent/scienter, and responsibility are indeed tricky issues with software and the law. I’ve experienced the problem in my own practice. Although it arises particularly frequently in copyright disputes, it is also common in patent and trademark cases (and of course contract disputes inasmuch as clickwrap-type agreements are implicated). I don’t have any coherent theory to propose, but a more uniform framework would certainly introduce some predictability into these sorts of cases (and thus perhaps avoid litigation). Update: Mike Madison also has some interesting comments on the case.

Russell blogs about his new 22" cheap TFT monitor. You lucky bastard.
I use a 17" Dell LCD monitor at work (sorry, cannot recall the model), and I've been quite pleased with it. Granted, 1280x1024 isn't what I had gotten used to (1400x1050 on my previous laptop and previous work machine), but it does the trick - And for my current laptop, I went for a smaller machine, with a 12" wide-screen 1280x800 monitor. I still find the monitor somewhat small, and the missing 224 pixels _are_ noticeable - but the size is well worth it.
But what I've been playing at work with is changing the monitor orientation - This 17" Dell monitor can be set up vertically (1024x1280), and xrandr will merrily change the orientation. So far, I'm happy with this setup. I still feel there are some video-related quirks, and maybe the pixels are a bit off (i.e. black letters in a white background have a bit of a shadow), maybe it was visible as well in the regular configuration, but not as noticeable. But well, I feel it easier to work with for most of my work cases - For having a full-screen browser, each row is smaller and more rows fit on screen - It's quite pleasant. For doing Web development, having a horizontally split screen (one above of the other) between Emacs and the browser is quite natural. And when I use more than two frames (i.e. for following logfiles or debugging multi-factored breakages on servers ;-) ), well, they are small enough that it's similar to having the ol' regular layout.
I'd still like to get a second video card and monitor. I remember working that way in the job I left four years ago, and it was very comfortable.
BTW, Russell, for your needs I suggest you to try Ion. After all, who really needs to have a root window/background after all? :-)

At work, I recently encountered #261107 on our distantly Debian-derived server and workstation distros. It really annoyed me because installing the mysql-server package fell over in a screaming heap when it went to create the mysql user. I'd seen a bug filed internally, relating to this particular use case, and initially I thought, based on the output, that it was the MySQL package's pre-install script not quoting the string "MySQL Server", but upon further investigation with strace, it turned out to be adduser's internal call to chfn that was failing, all because of the lack of a controlling terminal. Anyway, a colleague fixed the problem, and pointed me to the abovementioned bug, and this is what strikes me as so strange: the bug has been open for approaching 3 years. I can't reproduce this bug with a stock sarge or etch install, yet I can reproduce it on an Ubuntu Dapper-derived system at will, by calling chfn -f with /dev/null redirected to stdin. If this bug was biting with any sort of regularity, there'd be people rioting, because their adduser calls would be falling over, left, right and centre. Yet it was obviously reproducible for the bug submitter, and I can reproduce it at work. There's more to it than the lack of a controlling terminal. The plot, it be thick. Update Mystery solved. Apparently if you specify terminal restrictions in /etc/security/access.conf (even explicitly restricting it to "ALL"), pam_access gets all bitter and twisted if there's no controlling terminal for the thing being authorized. Wicked.

Some more comments on AppArmor, since some people might see my previous post just as being disappointed by seeing it in Ubuntu, and not much work on SELinux. First of all, I should note that I don't have any SELinux systems I'm responsible for anymore. They still run SELinux in strict and are doing well, but I'm no longer responsible for them. So I'm actually pretty much out of SELinux development nowadays. I did some occasional policy merge to monitor policy development, and when I tried VMware, I even setup a SELinux system to check the current state. But I wouldn't call myself an active developer or even user. So I don't think I'm as biased as you might think I am. Some things why I don't trust the AppArmor people:

• their website is incredibly full of marketing blah-blah such as "AppArmor is the most effective and easy-to-use Linux application security system available today" (effective as in what?)
• their Wiki/FAQ states wildly inaccurate things about SELinux such as "To get the full power of SELinux, applications must be recompiled and linked against SELinux libraries." (no, you don't need to recompile and relink all your applications...) - and they even contradict themselves to some extend; on one hand they claim that you don't need to modify applications for use with AppArmor, on the other hand they highlight it as a feature that you can patch your apache for AppArmor to get some more security for embedded interpreters such as PHP. This is pretty much the same as with SELinux.
• they state such misleading things as "every user should give each system an afternoon's test to decide which is a better match for their needs." - sounds good at first sight, but how many admins are able to evaluate the security of a kernel-based security solution such as AppArmor or SELinux in one day? What this actually is, is an encouragement for admins to pick the security solution because of ease-of-use, not because of security considerations.

Instead they should be honest about what AppArmor can, and what it can not do. I don't doubt that it can be used to make exploits with specially crafted PDF files in evince and such simple viewer applications a lot harder, but their security is not as thorough and complete as SELinux. They are potentially vulnerable to some attacks caused by their path name based approach, or that they cannot do MAC for files with unpredictable names such as most of /proc (e.g. /proc/1234/cmdline), any kind of sockets or when file descriptors are passed from one application to another. They should also admit that since SELinux initially assigns file labels by very similar pathname/filename patterns as AppArmor uses, it maybe isn't that much harder to setup in this aspect... In fact, it's much easier in SELinux to add an additional location for font files, since all the application policies don't need to be modified or reloaded, just the new font directory needs to be relabeled. In AppArmor, you'd need to modify an 'abstraction', then reload any policy that depends on this abstraction (you probably can only reload all at the same time, so that's not too hard). To anyone with a tiny bit of computer science knowledge, it should also be obvious that the performance of reconstructing the file path and matching it against a large set of filename globs (AppArmor) necessarily is slower than just using the security label in to the files attributes (SELinux, where this globbing was done once when doing the relabeling); any performance difference that shows that SELinux is slower than AppArmor is probably caused by SELinux doing a lot more security checks than AppArmor. So even AppArmor could benefit from using labeled security... I'm cool with saying that AppArmor is easier to get started with than SELinux, but they need to be honest about the differences to SELinux and the problems with AppArmor.