Petter Reinholdtsen

The last few days a new boot system called systemd has been introduced to the free software world. I have not yet had time to play around with it, but it seem to be a very interesting alternative to upstart, and might prove to be a good alternative for Debian when we are able to switch to an event based boot system. Tollef is in the process of getting systemd into Debian, and I look forward to seeing how well it work. I like the fact that systemd handles init.d scripts with dependency information natively, allowing them to run in parallel where upstart at the moment do not.

Unfortunately do systemd have the same problem as upstart regarding platform support. It only work on recent Linux kernels, and also need some new kernel features enabled to function properly. This means kFreeBSD and Hurd ports of Debian will need a port or a different boot system. Not sure how that will be handled if systemd proves to be the way forward.

In the mean time, based on the input on debian-devel@ regarding parallel booting in Debian, I have decided to enable full parallel booting as the default in Debian as soon as possible (probably this weekend or early next week), to see if there are any remaining serious bugs in the init.d dependencies. A new version of the sysvinit package implementing this change is already in experimental. If all go well, Squeeze will be released with parallel booting enabled by default.

These days, the init.d script dependencies in Squeeze are quite complete, so complete that it is actually possible to run all the init.d scripts in parallell based on these dependencies. If you want to test your Squeeze system, make sure dependency based boot sequencing is enabled, and add this line to /etc/default/rcS:

CONCURRENCY=makefile

That is it. It will cause sysv-rc to use the startpar tool to run scripts in parallel using the dependency information stored in /etc/init.d/.depend.boot, /etc/init.d/.depend.start and /etc/init.d/.depend.stop to order the scripts. Startpar is configured to try to start the kdm and gdm scripts as early as possible, and will start the facilities required by kdm or gdm as early as possible to make this happen.

Give it a try, and see if you like the result. If some services fail to start properly, it is most likely because they have incomplete init.d script dependencies in their startup script (or some of their dependent scripts have incomplete dependencies). Report bugs and get the package maintainers to fix it. :)

Running scripts in parallel could be the default in Debian when we manage to get the init.d script dependencies complete and correct. I expect we will get there in Squeeze+1, if we get manage to test and fix the remaining issues.

If you report any problems with dependencies in init.d scripts to the BTS, please usertag the report to get it to show up at the list of usertagged bugs related to this.

One interesting feature in Active Directory, is the ability to create a new user with an expired password, and thus force the user to change the password on the first login attempt.

I'm not quite sure how to do that with the LDAP setup in Debian Edu, but did some initial testing with a local account. The account and password aging information is available in /etc/shadow, but unfortunately, it is not possible to specify an expiration time for passwords, only a maximum age for passwords.

A freshly created account (using adduser test) will have these settings in /etc/shadow:

root@tjener:~# chage -l test
Last password change                                    : May 02, 2010
Password expires                                        : never
Password inactive                                       : never
Account expires                                         : never
Minimum number of days between password change          : 0
Maximum number of days between password change          : 99999
Number of days of warning before password expires       : 7
root@tjener:~#

The only way I could come up with to create a user with an expired account, is to change the date of the last password change to the lowest value possible (January 1th 1970), and the maximum password age to the difference in days between that date and today. To make it simple, I went for 30 years (30 * 365 = 10950) and January 2th (to avoid testing if 0 is a valid value).

After using these commands to set it up, it seem to work as intended:

root@tjener:~# chage -d 1 test; chage -M 10950 test
root@tjener:~# chage -l test
Last password change                                    : Jan 02, 1970
Password expires                                        : never
Password inactive                                       : never
Account expires                                         : never
Minimum number of days between password change          : 0
Maximum number of days between password change          : 10950
Number of days of warning before password expires       : 7
root@tjener:~#  

So far I have tested this with ssh and console, and kdm (in Squeeze) login, and all ask for a new password before login in the user (with ssh, I was thrown out and had to log in again).

Perhaps we should set up something similar for Debian Edu, to make sure only the user itself have the account password?

If you want to comment on or help out with implementing this for Debian Edu, please contact us on debian-edu@lists.debian.org.

Update 2010-05-02 17:20: Paul Tötterman tells me on IRC that the shadow(8) page in Debian/testing now state that setting the date of last password change to zero (0) will force the password to be changed on the first login. This was not mentioned in the manual in Lenny, so I did not notice this in my initial testing. I have tested it on Squeeze, and 'chage -d 0 username' do work there. I have not tested it on Lenny yet.

Update 2010-05-02-19:05: Jim Paris tells me via email that an equivalent command to expire a password is 'passwd -e username', which insert zero into the date of the last password change.

For some years now, I have wondered how we should handle laptops in Debian Edu. The Debian Edu infrastructure is mostly designed to handle stationary computers, and less suited for computers that come and go.

Now I finally believe I have an sensible idea on how to adjust Debian Edu for laptops, by introducing a new profile for them, for example called Roaming Workstations. Here are my thought on this. The setup would consist of the following:

• During installation, the user name of the owner / primary user of the laptop is requested and a local home directory is set up for the user, with uid and gid information fetched from the LDAP server. This allow the user to work also when offline. The central home directory can be available in a subdirectory on request, for example mounted via CIFS. It could be mounted automatically when a user log in while on the Debian Edu network, and unmounted when the machine is taken away (network down, hibernate, etc), it can be set up to do automatic mounting on request (using autofs), or perhaps some GUI button on the desktop can be used to access it when needed. Perhaps it is enough to use the fish protocol in KDE?
• Password checking is set up to use LDAP or Kerberos authentication when the machine is on the Debian Edu network, and to cache the password for offline checking when the machine unable to reach the LDAP or Kerberos server. This can be done using libpam-ccreds or the Fedora developed System Security Services Daemon packages.
• File synchronisation with the central home directory is set up using a shared directory in both the local and the central home directory, using unison.
• Printing should be set up to print to all printers broadcasting their existence on the local network, and should then work out of the box with CUPS. For sites needing accurate printer quotas, some system with Kerberos authentication or printing via ssh could be implemented.
• For users that should have local root access to their laptop, sudo should be used to allow this to the local user.
• It would be nice if user and group information from LDAP is cached on the client, but given that there are entries for the local user and primary group in /etc/, it should not be needed.

I believe all the pieces to implement this are in Debian/testing at the moment. If we work quickly, we should be able to get this ready in time for the Squeeze release to freeze. Some of the pieces need tweaking, like libpam-ccreds should get support for pam-auth-update (#566718) and nslcd (or perhaps debian-edu-config) should get some integration code to stop its daemon when the LDAP server is unavailable to avoid long timeouts when disconnected from the net. If we get Kerberos enabled, we need to make sure we avoid long timeouts there too.

If you want to help out with implementing this for Debian Edu, please contact us on debian-edu@lists.debian.org.

The last few weeks i have had the pleasure of reading a thought-provoking collection of essays by Cory Doctorow, on topics touching copyright, virtual worlds, the future of man when the conscience mind can be duplicated into a computer and many more. The book titled "Content: Selected Essays on Technology, Creativity, Copyright, and the Future of the Future" is available with few restrictions on the web, for example from his own site. I read the epub-version from feedbooks using fbreader and my N810. I strongly recommend this book.

Yesterdays NUUG presentation about Kerberos was inspiring, and reminded me about the need to start using Kerberos in Skolelinux. Setting up a Kerberos server seem to be straight forward, and if we get this in place a long time before the Squeeze version of Debian freezes, we have a chance to migrate Skolelinux away from NFSv3 for the home directories, and over to an architecture where the infrastructure do not have to trust IP addresses and machines, and instead can trust users and cryptographic keys instead.

A challenge will be integration and administration. Is there a Kerberos implementation for Debian where one can control the administration access in Kerberos using LDAP groups? With it, the school administration will have to maintain access control using flat files on the main server, which give a huge potential for errors.

A related question I would like to know is how well Kerberos and pam-ccreds (offline password check) work together. Anyone know?

Next step will be to use Kerberos for access control in Lwat and Nagios. I have no idea how much work that will be to implement. We would also need to document how to integrate with Windows AD, as such shared network will require two Kerberos realms that need to cooperate to work properly.

I believe a good start would be to start using Kerberos on the skolelinux.no machines, and this way get ourselves experience with configuration and integration. A natural starting point would be setting up ldap.skolelinux.no as the Kerberos server, and migrate the rest of the machines from PAM via LDAP to PAM via Kerberos one at the time.

If you would like to contribute to get this working in Skolelinux, I recommend you to see the video recording from yesterdays NUUG presentation, and start using Kerberos at home. The video show show up in a few days.

Aftenposten melder på forsiden av webavisen sin at de tror Erling Fossen provoserer nordlendinger med sine uttalelser på fotballtinget. Jeg er utflyttet nordlending, og må innrømme at jeg ikke kjennet så mye som et snev av provokasjon fra denne litt morsomme uttalelsen til Hr. Fossen. Lurer på om Aftenposten har noen kilder utenom redaksjonen for sin påstand om at nordledinger er provosert av Hr. Fossen. Må innrømme at jeg tviler på det.

Det hele bringer tankene tilbake til Sture Hansen i Hallo i Uken.

6 years ago, as part of the Debian Edu development I am involved in, I asked for a hook in the kdm and gdm setup to run scripts as root when the user log out. A bug was submitted against the xfree86-common package in 2004 (#230422), and revisited every time Debian Edu was working on a new release. Today, this finally paid off.

The framework for this feature was today commited to the git repositry for the xorg package, and the git repository for xdm has been updated to use this framework. Next on my agenda is to make sure kdm and gdm also add code to use this framework.

In Debian Edu, we want to ability to run commands as root when the user log out, to get rid of runaway processes and do general cleanup after a user. With this framework in place, we finally can do that in a generic way that work with all display managers using this framework. My goal is to get all display managers in Debian use it, similar to how they use the Xsession.d framework today.

Den norske bokbransjen har bedt om at digitale bøker må få mva-fritak slik papirbøker har det, og finansdepartementet har sagt nei. Det er et interessant spørsmål om digitale bøker bør ha mva-fritak eller ikke, og svaret er ikke så enkelt som et ja eller nei. Enkelte medlemmer av bokbransjen truer med å droppe den planlagte lanseringen av norske digitale bøker med digitale restriksjonsmekanismer (DRM) som de har snakket om å gjennomføre nå i vår, og det må de gjerne gjøre for min del.

Papirbøker har mva-fritak pga. at de fremmer kultur- og kunnskapsspredning. Digitale bøker uten digitale restriksjonsmekanismer (DRM) fremmer kultur- og kunnskapsspredning, mens digitale bøker med DRM hindrer kultur og kunnskapsspredning. Digitale bøker uten DRM bør få mva-fritak da det er salg av bøker på lik linje med salg av papirbøker, mens digitale bøker med DRM ikke bør få det da det er utleie av bøker og ikke salg.

Jeg foretrekker å kjøpe bøker, og velger dermed å la være å bruke DRM-belastede digitale bøker. Vet ikke helt hva jeg ville være villig til å betale for å leie en bok, men tror ikke det er mange kronene. Heldigvis er det mye bøker tilgjengelig uten slike restriksjoner, og de som vil ha tak i engelske bøker kan laste ned bøker som er tilgjengelig uten bruksbegresninger fra The Internet Archive. Der er det pr. i dag 1 889 313 bøker tilgjengelig. De er tilgjengelig i flere formater. Besøk oversikten over tekster der for å se hva de har.

On Tuesday, the Debian/Lenny based version of Skolelinux was finally shipped. This was a major leap forward for the project, and I am very pleased that we finally got the release wrapped up. Work on the first point release starts imediately, as we plan to get that one out a month after the major release, to include all fixes for bugs we found and fixed too late in the release process to include last Tuesday.

Perhaps it even is time for some partying?

After this first point release, my plan is to focus again on the next major release, based on Squeeze. We will try to get as many of the fixes we need into the official Debian packages before the freeze, and have just a few weeks or months to make it happen.