Yay! My LUKS integration bits landed in Rawhide and will be in Fedora Core 5. In other news, the latest gnome-power-manager in Rawhide works really nicely with non-portable batteries e.g. Uninterruptible Power Supplies that supports the USB HID protocol.
New and l33t icons
Richard been kicking ass on gnome-power-manager recently - note how he even fixed my somehow pedantic requests to even make this work when hotplugging the UPS.
I’ve been hacking on and off with W. Michael Petullo on integrating LUKS into the GNOME desktop via HAL and patches are now upstream.. I think it rocks. I’ve prepared a small screencast:
Screencast of LUKS integration into GNOME
Hopefully we can get these bits into FC5; the patches themselves are pretty simple but you also need HAL and gnome-mount from CVS. I’ll do releases of the latter two later this week.
We still need some UI for setting up volumes; this should probably be integrated with gfloppy or maybe an entirely new UI for partitioning and formatting media. Fortunately, however, someone is already working on this but to do this securely we need to formalize privileges in HAL and I think there is consensus about how we want to do that.
In other news, danish are renamed in Iran. Some times, the world is so silly that it’s sad.
It’s a new year and I returned late last week from Europe - nice with relaxation but maybe a bit too much travelling… Anyway, pictures speak much more than a thousand words, or something, so nuff’ said. I’m not sure I like 2006 yet, maybe things will change.
Danish food
For new years I went to Hamburg, Germany to visit my good friend Kay Sievers - awesome to see Kay again. With Kay working for Novell and me working for Red Hat we talked a lot about the current state of our various distributions and how we can work closer together in the trenches. Specifically we discussed how to manage policy enforcing daemons and below are some of my thoughts on that.
Background
Starting with Fedora Core 1, Red Hat started shipping the system-wide bus (D-BUS) in Fedora Core, but it wasn’t until Fedora Core 3 with the advent of HAL and NetworkManager that the bus started to see extensive use.
Today, in what will become Fedora Core 5, unpriviliged applications running in a desktop session on the console can invoke methods for putting the system to sleep, configure display brightness on laptops, configure networking and mounting storage devices. With time, more and more methods will be available for configuring the hardware and/or system. All such method invocation happens in a secure way through the (unprivileged) system bus daemon that checks, validates and passes messages between the sender and receiver. Additional lock-down via e.g. SELinux security contexts are possible too but I’ve yet not seen anything use it.
Configuration
Back in the day, the traditional UNIX way for system-wide daemons prescribed using a textual configuration file somewhere in /etc - acpid and networking scripts comes to mind. With this, users had to resort to using a text editor and learn about the configuration file format; very educating and l33t for the geek hacker, but not ideal for ordinary users; not ideal for grandma. When available, UI tools simply rewrote the configuration file which most people agree is error prone and just plain wrong.
Allowing applications in the desktop session to enforce policy makes a lot of sense from a configuration point of view. Today, in the development tree of Fedora we now ship gnome-power-manager. Settings are read from gconf at /apps/gnome-power-manager. We have a nice, not horrible at least, user interface (Desktop -> Preferences -> Power Management) for configuring the policy. It is per-user, and since it uses gconf it’s possible to configure both default and mandatory settings (for lock-down), these days this can even nicely be achieved with e.g. Sabayon. In almost every way possible way it’s superior to textual configuration files. John has some good stuff about gconf here.
Also, gnome-power-manager sports a notification icon along with a menu for performing actions such as putting the system to sleep or hibernation. These days, when the kernel is in a good mood, power management just works. It’s like using my Mac.
However, there are two obvious downsides to running policy enforcing daemons in the desktop session, namely
Exactly the same problems apply for the screen saver (gnome-screen-saver), networking (nm-applet), storage management (gnome-volume-manager) and probably other things too. Wonder why there is no screen saver on the login screen? Wonder why your wireless network isn’t configured before login? That’s why.
The Opera House in Copenhagen, Denmark
A framework
To solve problems 1) and 2) above we first need some infrastructure for tracking what sessions are at the consoles attached to the system. Remember that several users can be logged in at the same console through fast user switching (even multiple sessions from the same user on one console) so we need a notion of who and what is active at each console.
The proposal is a simple D-BUS service on the system bus; in quick and dirty pseudo code it would look like this
service org.freedesktop.DBus.ConsoleTracker {
methods:
array{tupple{string sessionId,int console, bool isActive}} GetSessions();
int GetNumberOfConsoles();
int GetUnixUidFromSessionID(string sessionId);
signals:
SessionBegin(string sessionId, int console);
SessionEnd(string sessionId, int console);
SessionActivityChanged(string sessionId, int console, bool isActive);
NumberOfConsolesChanged(int numConsoles);
}
The sessionId is simply a unique identifier maintained by the ConsoleTracker service - most likely this is the X11 display number though ConsoleTracker shouldn’t rely on a certain windowing system. The isActive boolean denotes where the session is currently visible on the console. Along the way the ConsoleTracker service may also provide methods such as GetSessionBusAddress(string sessionId), it might provide properties to tell what kind of session is running (GNOME, KDE, …) but that is beyond the scope of this write-up.
A service like this (I’m sure the choice of names and methods / signals can be much improved) simply tracks sessions and, as such users logging in and out. Ideally this service is shipped with the D-BUS tarball and ideally we’d make the system bus dependent on this service insofar that we can introduce policy directives such as “at_active_console” etc. in addition to the “at_console” directive we already have.
The ConsoleTracker service should also be possible to implement without pam_console which means that we can get rid of the optional pam_console dependency in D-BUS. This also means that e.g. HAL and NetworkManager can ship D-BUS configuration files with “at_console” without the Debian people having to patch things out and only users logged in at the console may invoke methods like e.g. Suspend() to put the system to sleep. Of course, the Debian people may still change the policy because they think group membership is more correct. It’s their OS distribution after all.
Rupert spotted in Germany
Now, with the ability to track logged in users and sessions, it becomes almost trivial to write the next system-wide service, let’s call it org.freedesktop.PolicyManager. This is a daemon that reads configuration files in /etc/PolicyManager.d/ (only programs will dump files here, not people)
/etc/PolicyManager.d/power-management.conf
storage-management.conf
...
where e.g. power-management.conf contains
[policy-service]
exec=/usr/bin/my-power-manager-when-no-one-is-logged-in
id=PowerManagement
per_console=false
which simply states that the PolicyManager daemon should run the program /usr/bin/my-power-manager-when-no-one-is-logged-in when no user is logged in (the console number is passed in the environment). This configuration file also provides a unique identifier for the kind of policy service it is, in this case power management. Part of the “specification” for the PolicyManager daemon contains a list of well-defined policy services, e.g. PowerManagement, StorageManagement, ScreenSaver, NetworkManagement and so forth.
My sister has a Pony called Conny
The per_console field requires further discussion, but let us first take a look at the D-BUS interface offered by the PolicyManager daemon:
service org.freedesktop.PolicyManager {
methods:
bool ClaimPolicyService(string id);
bool ReleasePolicyService(string id);
signal:
PolicyServiceClaimed(string id, string sessionId, int console);
PolicyServiceReleased(string id, string sessionId, int console);
}
The thinking here is that when I login to the GNOME desktop, then gnome-power-manager is started and it invokes ClaimPolicyService("PowerManagement") on the PolicyManager system service. Since D-BUS now sports the ConsoleTracker service, the PolicyManager can determine what console, if any, the method call from the gnome-power-manager instance stems from. Specifically, if the method invocation stems from a process not at the console it is denied.
The PolicyManager service now kills the existing process responsible for power management, e.g. /usr/bin/my-power-manager-when-no-one-is-logged-in, and returns TRUE which means that our copy of gnome-power-manager is set to go. This daemon starts enforcing policy, e.g. suspends my laptop after inactivity and so forth.
Whenever my copy of gnome-power-manager terminates (normally when logging out), then the PolicyManager is notified through a signal on the system message bus (already part of the system bus) and starts up /usr/bin/my-power-manager-when-no-one-is-logged-in to enforce policy. Also, at any point my gnome-power-manager copy may invoke ReleasePolicyService("PowerManagement") if the user e.g. manually disables it (though it is unlikely why g-p-m would provide such functionality).
Suppose that user A is logged in at console 0, it’s session "s100", and has a copy of gnome-power-manager runnning. Now suppose that user B logs in via fast user switching at console 0, session "s101". The following happens.
First, the ConsoleTracker service emits a signal telling that session "s100" is no longer active, SessionActivityChanged("s100", 0, FALSE), and the gnome-power-manager copy in session "s100" receives this signal and stops enforcing policy (it doesn’t invoke ReleasePolicyService() though). Now another copy of gnome-power-manager for user B starts up in session "s101". It also invokes ClaimPolicyService("PowerManagement") on PolicyManager and it recieves TRUE and this copy starts enforcing policy.
When switching back to session "s100", the g-p-m copy in session "s101" stops enforcing policy, due to SessionActivityChanged("s101", 0, FALSE), and the g-p-m copy for session "s100" starts enforcing policy in response to the SessionActivityChanged("s100", 0, TRUE) signal.
Frightening Sky
The per_console field, which is FALSE in the power management example, defines whether the policy enforcing daemon is per console or per system.
For example, consider a system with two consoles, 0 and 1. Since per_console is FALSE for power management only one copy of /usr/bin/my-power-manager-when-no-one-is-logged-in is launched. When there are two user sessions, one on each console, only one of them get to enforce policy, e.g. ClaimPolicyService("PowerManagement") will fail for one of the two copies of gnome-power-manager. The loser will probably revert to only showing battery information, not enforcing policy, and it is up to the two copies to negotiate when to suspend the system. This may be done in a number of ways.
So when is per_console=TRUE useful? It’s useful for policy enforcing pieces like the screen saver or the storage manager. In general, it’s useful when you want a copy running for each console. For example, when PolicyManager starts up on a system with two consoles, it will launch two copies of the /usr/bin/my-screen-saver-when-no-one-is-logged-in (how it gets access to the X display is another matter though). Specifically, for storage management, e.g. gnome-volume-manager, one also wants to ensure that policy is only enforced for drives local to the console, e.g. only mount USB storage for the USB ports local to the console. How this is determined is beyond the scope of this write-up for ConsoleTracker and PolicyManager but it’s not difficult to imagine that this information could come from HAL.
Reusing desktop policy daemons for system use
One problem remains to be solved. How do you configure the policy for the policy daemon when no user is logged in? Also, why would you want to maintain two code bases; one for desktop case and one for the case when no use is logged in? The answer here is simply to reuse the desktop policy daemon. For instance, for power management we get
[policy-service]
exec=/usr/bin/gnome-power-manager --no-one-is-logged-in
id=PowerManagement
per_console=false
and gnome-power-manager simply don’t provide any UI (or maybe it paints the UI on top of the login screen, e.g. gdm). Since this copy of gnome-power-manager is invoked by the PolicyManager daemon it runs as nobody or some other unprivileged system user. It still reads it’s setting from gconf but since this is not a real user it will get the default settings.
With this approach the UI for gnome-power-manager may include a button “Set as system default” that simply copies the settings from the logged in users gconf schema to the system default ones in /etc/gconf/gconf.xml.defaults. This of course requires administrative privileges and we may even hide this button if we can detect whether the user is an admin or not. Notably this will also work for other policy enforcing daemons, e.g. NetworkManager’s nm-applet, the GNOME screen saver and so forth.
Confetti is Everywhere
Not tied to one desktop
I’ve used GNOME as an example above, mostly because I’m a GNOME user and developer myself, but nothing prevents KDE or XFCE to do the same. Indeed, if there is agreement on all desktops using the ConsoleTracker and PolicyManager things will “just work”. Of course, someone will have to write this stuff 
We had snow today - good thing I was working from home
How the world really is
Sunset
Today, Kristian and I drove up to Killington, VT to go skiing. It was my first time out on sloped terrain, let alone the first time in 15-20 years wearing a set of skiis.
I fought the mountain and the mountain won
After some moderate success on the learning slope, Kristian convinced me to try the green slope pictured above (or was it blue? Supposed to be an easy one either way). I was told that I looked rather freaked out after safely returning to the base camp but that it was somewhat decent attempt; go go go! Heh, things take time I guess.
Either way, it was awesome and I’m definitely going to go again soon. Especially as I shelled out quite an amount of money for skiing clothes but ended up renting the skiis, boots and other stuff.
Bokeh Galore
I also brought my camera and a set of lenses (the 10-22, 24-70, 70-200 and 2x extender) though, since the weather was quite bad, I only used my recently acquired 50mm f/1.4 - the bokeh on that one is awesome, though it’s a bit difficult to focus correctly although that is a known issue.
I realized today that I haven’t blogged in almost three months.
Conferences
In July, I went to the Desktop Developers Conference and then the Ottawa Linux Symposium after that. One busy week where I shared a room with Kay Sievers, good pal and now proud maintainer of udev (congrats Kay!). It was my first time going to one of the DDC and OLS conferences, and it was good to meet both old and new friends. Pictures here. Next up is the GNOME Boston Summit.
Hackers
Visit
An old friend Søren, from Denmark, was in California so he stopped over in Boston for a visit in the start of September. We drove down to NYC, had a good Saturday night out clubbing with friends, hung out in the city on the Sunday. Labour-day Monday, we headed south for Washington DC for another 2.5 days. Pictures here.
At the corner of 33th street and 7nd Ave
Photography
I’ve upgraded to the Canon 20D and also acquired my first L lens, the 70-200 f/2.8L zoom lens. It’s awesome. Coupled with the 2x II extender I grabbed a picture of a full moon the day before yesterday, see below. For candid shots and low-light-photography (good for capturing people that has issues with fire alarms) I still swear to my copy of the Sigma 28mm f1.8, it’s pretty good, though I do admit that I miss a zoom and eventually I’d like something like this instead
Full moon
Mass Drivers License
I passed the written test last week and the road test yesterday, so now I’m licensed to drive here in the Commonwealth of Massachusetts and, for that matter, in the rest of the US. Compared to the tests I had to take in Denmark, some 11.5 years ago, this was a piece of cake. It is pretty fortunate that I finally got this done, as after one year in the US my Danish license will stop working and that is nine days from now. Btw, thanks a million to J5 for being my sponsor.
Work
Been busy with new projects. I feel a little bit sad that this means that I’ve been slow to reply on mail on the HAL list, but this is also because life have been somewhat busy and trying lately. Fortunately Danny Kukawka and Richard Hughes have been helpful looking after the project. Also happy to see that GNOME Power Manager will soon enter Rawhide. I’ve been using g-p-m for the past few weeks and it makes the whole laptop experience better.
California
Impulse struck me last week and Wednesday I booked a quick getaway on site59.com - a site that Seth told me about. I got an awesome deal; highly recommended.
California Route One
I left for sunny California (wasn’t that sunny though) very early Saturday and arrived back in rainy Boston (very rainy when we landed) very early Wednesday. I didn’t really have any specific plans for the trip so things just happened along the way which happened to work out very well. Spent Saturday night in San Francisco (notably at the Irish Bank and The Swig) where I met and chatted with a bunch of different people including one professional photographer (which was interesting as I like to think of photography as a new hobby for me). Sunday I left for Monterey and stayed there until Tuesday.
The most amazing part of the trip was probably driving on the very amazing 90 mile stretch of Route 1 from Carmel to San Simeon. Well, pictures speak more than a thousand words.
Spent most of Wednesday catching up on mail and on meetings / IRC; still got lots of mail and issues to attend to though.
