GNOME 3 Calendar Integration

I'm actually not supposed to be working this week (the first screenshot contains a subtle hint why), but here's a couple of screenshots of the upcoming calendar integration for the next major GNOME release:

Click to embiggen

Working in Javascript is really weird compared to C. But so far I think it's weird in a good way.

Click to embiggen

Here's the git branch with this code and here's the bug. There's still some work left to make the code look and act like the mockups. I'm really hoping we can land the bulk of this code before Christmas - the biggest blocker right now is getting events from Evolution which is stressing the capabilities of the gjs runtime and GObject Introspection. To make forward progress on the UI side, I had to switch to a in-process event source with fake events.

udisks and gnome-disk-utility - past, present and future

The past year or so I’ve been working a lot on gnome-disk-utility and DeviceKit-disks^Wudisks and I haven’t really blogged anything about it. Time to fix that!

First of all, given that the main DeviceKit daemon was killed by libudev (if you are using GLib you want GUdev instead!), we (that is, myself and other contributors) decided to rename the project - most people were cool with that; see this message for more reasons. One improvement in this area is that we’re committing to limited ABI stability - hopefully this will make things easier on distributors.

Most of the work in the udisks project been triggered by features we want in the Palimpsest Disk Utility - which is the most prominent part of gnome-disk-utility - the other part includes various desktop shell integration bits that I don’t have room to cover in this post.

On the Disk Utility side, we’re now using an user interface that scales better with many disks - in the old user interface, we used to show all partitions as children of each disk in the tree view. In the new user interface, we’re using a grid to convey the partitioning:

Also see bgo #579211

While this interface isn’t optimal for the laptop or the machine-with-only-a-single-disk cases, it works a lot better for machines with many disks

Bunch of disks

The Disk Utility also have somewhat complete support for MD RAID (aka Software RAID on Linux) - we’ll show you running arrays and also arrays not yet running. There’s a way to add/remove components and currently I’m working on creating the UI for Online Capacity Expansion (e.g. dynamically expand a RAID-5 array from 4 to 8 drives).

The SMART stuff has been revamped and there is now a way to turn off the desktop shell notifications. As it turns out a lot of our current users are like “I’m fine with using a disk that is about to fail” - kinda shocking but there you go. Another change is that we don’t consider a disk to be failing if there’s only a couple of bad sectors - the disk will have to have many bad sectors to be considered failing. This helps with all the false positives the SMART warnings generated in e.g. Fedora 11. Anyway, it seems like the desktop notifications are useful - more than a handful of people have pinged me on IRC thanking me and Lennart for this feature. Woot!

We also now have rudimentary support for showing the SAS topology - this is really useful since machines with many disks typically use dedicated disk enclosure shelves. Currently we only show SAS Expanders but the plan is to peek (and poke!) SES-2 Enclosures (and in the future also SGPIO ones) to get information about bay numbering and to toggle the FAILURE and LOCATE leds. Ideally we want to turn on the FAILURE led if a member of a RAID array is kicked or if SMART status indicates that the disk is about to fail. Ideally, we also want to do (sensible!) things like starting a RAID rebuild if a kicked RAID member is replaced by a uninitialized and same-size disk. As always, we have to be really careful about automatically doing policy things like this - especially on Linux where it is hard to make any assumptions on how the system is used.

The goal of the udisks effort is to be useful to users. For example, if you do video editing or a lot of photography, you care about IO performance. So I added a way to easily benchmark drives and RAID arrays:

RAID-6 FTW!

This feature was inspired by various similar Windows programs (a pastime on big storage forums such as this one involves trading benchmark screenshots) and the zcav program. It’s pretty cute, actually; I learned that my Intel 80GB G1 SSD only gives me 140MB/s on my Lenovo Thinkpad X61 while I get a full 270MB/s on my workstation (connected via SAS). Looks like the X61 is only using SATA 150 MB/s - a search on the tubes confirmed this. Gee! This feature is also useful when experimenting with RAID setups - for example, a 10K 36.7GB SAS disk benchmarks like this but when you put three of them together in Software RAID-5 it turns that writing is really slow. I know it’s supposed to be slow when writing to software RAID… but, really, this slow? Maybe I need to tweak some kernel tunables (which would be bad - we should be fast out of the box etc etc).

Finally, I did a really cute hack a few weeks ago - I made Palimpsest use D-Bus over TCP/IP over SSH to speak to udisks:

Bunch of servers

With the way this works we leverage SSH for authentication and Avahi for Service Discovery. The feature is still a bit rough - it needs some UI additions (such as a disconnect button) and we probably want to replace the stock OpenSSH dialog with something, uhm, less scary. There’s also the question of authorization - right now you have to connect as root in order to modify things (udisks uses polkit for authorization) - we need to figure out how we want this to work. Right now I’m thinking udisks will ship some polkit configuration bits (a .pkla file) and a udisks-admin group that administrators can add users to. We’ll see.

I’m kinda excited about the remote connectivity bits - it means that the Disk Utility is now very useful for headless server setups and said servers won’t have to run any graphical UI in order to be managed through the Disk Utility. We probably want to make the Disk Utility (e.g. Palimpsest) run on Win32 and OS X too (for users not running Linux on the desktop) for remote connectivity to e.g. Linux boxes running udisks. It shouldn’t be too hard to do this as we mainly depend on GTK+ and D-Bus.

There’s a bunch of plans for both udisks and Palimpsest. We want to add support (meaning: udisks API and Palimpsest User Interface bits) for the following things: LVM, iSCSI (both target and initiator), Enclosure Management (as mentioned above), Event logging (e.g. “raid5:md2: read error corrected”), Multi-path, Btrfs and many other useful storage technologies. There’s also a few rough edges and missing features (e.g. file system resizing) but we’ll get to that in due time.

FWIW, it’s important to realize that udisks and the Disk Utility complements, but does not replace, existing command-line tools. This means that you can go ahead and keep using your command line tools and scripts and the udisks/GNOME/Palimpsest/etc. stack will react to changes. For example, you can start/stop RAID arrays using mdadm(8), partition your disks using parted(8), create filesystems using mkfs(8), mount/umount filesystems and so on - the UI is kept up to date. While it’s approximately ten times harder (with the 10x figure being 65% accurate) to write software this way, it’s really the only way to do things on something like Linux where our set of users is as diverse as it is.

Plumbers 2009

Had a great time at Plumbers Conference last week in lovely Portland, OR. On the Friday on the conference, Kay and I gave a talk, aptly named “Replugging the Modern Desktop”. The talk covered most of the hal-ectomy that has been happening and included a couple of demos. The slides are here. UPDATE: People on IRC are telling me that the fd.o servers are not reachable, I’ve put up another copy of the slides here.

GUdev, gobject-introspection

I just committed gudev-1.0 to udev-extras. GUdev isn’t a particulary big library, it’s just a thin wrapper around libudev with integration bits for the GLib main loop and support for GObject Introspection.

While GObject introspection is very neat, see this GUdev example using Seed, I must admit the whole thing feels… half-finished?

For example, we seem to be doing the wrong thing for default annotations in some cases. Another example is the fact that gjs lacks a print() function, Seed can’t handle GStrv properties (works in gjs), lack of support for string arrays in gjs (works in Seed), neither Seed nor gjs supports Shebang support (gjs bug, Seed bug).

So all in all, trying to make my new small library introspectable.. was kinda.. much more work than I expected.. and most of the time was spent with the Seed and gjs runtimes trying to figure out what was wrong.

Anyway, I don’t want to sound all negative.. with all the work going on in this area, it looks like it’s going to rock once corner cases like mentioned above are ironed out. Rock on!

Storage handling in GNOME

The GNOME 2.26 release in Fedora 11 will ship with a completely different stack for handling storage devices. The plan is to land all this work in the upstream GNOME 2.28 release and most of that work is done already.

Basically, we’ve switched away from one daemon to another and in the process we gained a few new features.

OMG, the disk is dying - using libatasmart

including letting the user inspect what his disk is trying to tell him. Kudos goes to Lennart for adding USB support, fixing issues with false positives in libatasmart and just for providing a really good library. And it looks like it’s working.

To really make this 100% useful, we probably want some kind of directory where system vendors shipping GNOME can drop an XML file and then the user can click a button “Order new disk” and get on with their life. Of course, then we need to handle the much harder problem of backup and data migration, but, hey, we want to solve that anyway.

So I also wrote this Palimpsest Disk Utility application



Kitchen sink of disk information

which also handles things like RAID devices and support for managing things like LVM and btrfs is planned as well. We’re also looking at changing the UI to be a bit more sane - something like this perhaps

Clean, leaner, simpler? Tell us in bug #579211!

Tomas, Matthias and I also worked on a simple formatting tool suitable for replacing the venerable gfloppy tool

Formatting tool

you can see the whole series of screenshots to see how the user interaction is supposed to be like.

Finally, I just merged a series of patches to GVfs for using this new machinery

OMG, pretty RAID icon!

Building this on top of a modern storage daemon, as opposed to HAL, means that your file manager (and any other app using GIO), is instantly updated as you repartition or reformat your disks. It even works if you are using command-line tools, etc. fdisk(8) or mkfs(8) - geek comfort FTW!

We might want some extensions to GIO to make working with RAID and encrypted devices (and in the future LVM) easier (such as unlock/lock/start/stop buttons in the file manager sidepane) or maybe we’re just going to rely on the system auto-assembling such things and leave it in Palimpsest. Decisions, decisions.

Another geek-comfort I added, is the ability to show user mountable fstab entries, that’s bug #536292. I was a bit reluctant to do this, I think instead we want native support in GVfs for nfs:// yet still use the kernel filesystem driver though some kind of setuid helper. Then we’d also fix NFS servers to publish the fact they exist using Avahi and then people can discover it in Nautilus’ computer:// window. Just cleaner and easier, I think. Combined with support for bookmarks on the GIO level, this should be a dream come true for people deplying systems in the enterprise.

Most of this work is part of the bigger HAL-ectomy - my good friend Kay has a good post outlining the plans for this.

Getting GVfs and FUSE right

One of the cool things about the new IO library (GIO) in the GNOME stack is that it’s extensible. One set of extensions for GIO is provided by the GVfs package. The main (but not only) purpose of GVfs is to provide access to Virtual File Systems by having the file system backend (e.g. file system driver) running in a separate daemon process in user space - sort of similar to what the Filesystems in Userspace (FUSE) framework provides on Linux and, nowadays, most UNIX operating systems. GVfs currently includes backends for SFTP, FTP, OBEX for Bluetooth, Digital cameras and MTP devices (through libgphoto2), Compact Disc Audio, Webdav, HTTP and archive files (through libarchive) to name the most important ones.

One key difference between FUSE and GVfs, is that GVfs file system drivers are not constrained by the rather old-fashioned, limited and design-by-committee POSIX API. Instead, GIO provides (and exposes for implementation to file system drivers) a modern and powerful API that provides asynchronous IO, file monitoring (like inotify) and high-level operations as part of the standard API. The GIO API is at the right level of the stack, it’s part of the GLib tarball. This means that any application that today uses GTK+ has access to GIO. This is a pretty big deal, if you depend on GTK+ 2.14 on newer, you’ll also depend on GIO.

However, since it’s rather naive (not to mention arrogant) to think that people are going to be using only GTK+ applications, GVfs also ships with a FUSE daemon. This daemon provides a POSIX interface to the virtual file systems provided by GVfs. All the fancy high-level operations available when using GIO won’t be available (there’s no POSIX equivalent function to map to) of course, but the basic POSIX stuff (e.g. open(2), read(2) etc.) will work just fine. The way it works is that the GVfs FUSE daemon provides a mount in $HOME/.gvfs where each top-level directory represents a GVfs mount:


$ ls -1 $HOME/.gvfs
gphoto2 mount on usb%3A004,002
sftp on people.freedesktop.org
sftp on quad.local


For example, this means all the good old command line tools still work


$ stat /home/davidz/.gvfs/sftp\ on\ quad.local/home/davidz/.bashrc
File: `/home/davidz/.gvfs/sftp on quad.local/home/davidz/.bashrc'
Size: 313 Blocks: 0 IO Block: 4096 regular file
Device: 14h/20d Inode: 44 Links: 1
Access: (0600/-rw-------) Uid: ( 500/ davidz) Gid: ( 500/ davidz)
Access: 2008-10-01 14:35:28.000000000 -0400
Modify: 2008-04-25 11:55:02.000000000 -0400
Change: 2008-04-25 11:55:02.000000000 -0400


$ convert /home/davidz/.gvfs/gphoto2\ mount\ on\ usb%3A004\,002/DCIM/100NIKON/DSCN0001.JPG -dither out.jpg


and so forth. Lots of command-line people like this, at least they always like to complain when we didn’t have this back in the GnomeVFS days.

But it gets better. Today I committed a patch to GIO to ensure that GIO applications launching applications (such as the Nautilus file manager or the Evolution mailer) will always pass a FUSE path instead of the GIO URI. One implication of this is that if you launch a non-GIO application (such as mplayer or a KDE application) from Nautilus, that application will Just Work(tm) even if the file lives on a GVfs share.

I think this is a pretty big deal; now it just doesn’t matter what VFS system of the week is used in the application, it’s all POSIX as far as applications are concerned. Sure, there’s a small performance hit by having to go through the GVfs FUSE daemon (a couple of extra context switches) but for run-of-the-mill desktop applications this is insignificant. Also, as explained here it’s currently not a very smart idea to pass an URI to an application; there’s the problem we don’t have proper standards defining the URI’s we use; there’s also the problem of having to authenticate over and over again.

Finally, if the application itself is using GIO, this patch ensures we map back to a GIO URI and, thus, we bypass the FUSE daemon. This is best illustrated by the following screenshot:

Bastien in VFS heaven

As you can see from the terminal window, Eye of GNOME is being passed a FUSE path from Nautilus. But thanks to the aforementioned patch, this is getting mapped back to a GIO URI as shown in the properties dialog.

This feature won’t be available in GNOME until 2.26 (and GLib 2.20) - we’re concerned some broken applications might be examining the URI before it’s mapped back so we’re reluctant to provide it in GLib 2.18 / GNOME 2.24 for now. FWIW, we’ve been shipping patches for this feature since Fedora 9 and the feature will be in Fedora 10 as well. Other vendors are encouraged to ship these patches as well.

DeviceKit presentations

Earlier today Richard and I did a DeviceKit (the set of projects replacing HAL) presentation for some other group here at Red Hat. You can see the slides here and here.

Perhaps of interest to the GNOME community, there’s also screenshots of Palimpsest, an upcoming Disk Utility library and application for GNOME. Most of this is already available in Fedora’s development branch, dubbed Rawhide, but won’t be installed by default in Fedora 10. Right now I’m busy with PolicyKit stuff but the plan is definitely to get a gnome-disk-utility mailing list going soon and get this stuff integrated throughout GNOME (I’ve already made sure it’s easy to plug into gvfs for example).

For example, I learned the other day that my disk is failing (actually, as mjg59 pointed out, it’s wrong to use the word FAILING since it’s Old-Age. Easily fixed.). Now, it would definitely be useful to have a notification bubble indicating this. This is pretty trivial to write using the DeviceKit-disks API; just monitor the org.freedesktop.DeviceKit.Disks.Device:drive-smart-is-failing property. Of course the gnome-disk-utility libraries (there’s one at the GLib level and one at the GTK+ level) wraps this nicely. In fact the gnome-disk-utility library at the GTK+ level should probably provide the code for doing this status icon. Something to discuss. Hence why a mailing list and more community involvement in the gnome-disk-utility project is needed.

Anyway, the goal is to port the most of the Fedora desktop to use DeviceKit instead of HAL for the Fedora 11 time frame.

Resolution Independent GTK+

Got one of them big laptops where you feel tempted to use a looking glass because the pixels are so tiny? Ever feel cheated when you adjust the font size but the rest of the UI looks like crap in comparison? Or maybe ever felt dirty when hard coding pixel values in your application?

there’s also a tiny and a normal version…

Today I sent a patch to gtk-devel-list adding Resolution Independence to the GTK+ toolkit. Let’s see how that goes.

D-Bus introspection

Sure, there’s already d-feet and a similar Qt tool but for people who hate using the mouse or are allergic to X, I’ve put together this cute little hack that provides bash completion to dbus-send(1). Unfortunately it depends on the XML introspection parser from dbus-glib so it’s not straightforward to add to mainline D-Bus. Could easily go in dbus-glib though. Then again, it would be nice if libdbus included an XML introspection parser. Decisions, decisions.

Linux Plumbers Conference CFP extended!

I rarely blog these days, doing the Twitter thing instead and all. Anyway. The Call for Papers for the Linux Plumbers Conference in September in lovely Portland, Oregon has been extended until July 31st 2008. It’s a conference about the core infrastructure of Linux systems: the part of the system where userspace and the kernel interface. It’s the first conference where the focus is specifically on getting together the kernel people who work on the userspace interfaces and the userspace people who have to deal with kernel interfaces. It’s supposed to be a place where all the people doing infrastructure work sit down and talk, so that each other understands better what the requirements and needs of the other are, and where we can work towards fixing the major problems we currently have with our lower-level APIs.

I’m running the “Desktop Integration” microconf at Plumbers. I have two goals for the microconf. One is to be informative about what’s going on in the dusty hallways between the Kernel and the Free Desktop. Which I think is important at a place like Plumbers where we’re going to a lot of people working on similar problems present. The other goal is to actually try and make some headway on actual problems that require people from multiple communities working together. Such as some of the work Jon is focusing on, e.g. how to make fast-user-switching, multi-seat and terminal services Just Work(tm).

The conference is expected to sell out pretty quickly so it’s a good idea to go ahead and register for Plumbers Conference instead of procrastinating about doing it!

See you in Portland!

gnome.conf.au 2008

Am in Melbourne, VIC, Australia for linux.conf.au 2008; just gave a talk on PolicyKit, the slides are here. Only had 20 minutes so the whole thing felt a bit rushed and I didn’t get to go into much detail. Hopefully it made some sense though, otherwise checkout the design and API docs.

Politics. Mudslinging. Chocolate.

Whether Murray is right or not, I think his recent rant is rather tasteless and I agree some kind of retraction/apology is needed.

FWIW, Murray’s post certainly don’t reflect what I’ve experienced when I started participating in the GNOME project 2003-2004ish. That said, I acknowledge it may reflect what others have experienced. I don’t know. Also, I tend to stay out of politics… at least politics on that level. That said, I do appreciate others doing all this work; for a project of GNOME’s size we do need people in the foundation and some board, we need people spreading the word around GNOME, we do need to participate in standard organizations etc.

Either way, this kind of mudslinging is very unproductive for the project and everyone involved should know better. An old friend of mine once said “Can’t we just focus on the chocolate?”. This was in reaction to stupid in-company fighting and also a pun on a tv commercial from some chocolate company. The commercial involved three chocolate makers. They were making chocolate. Or rather, two of them were ranting about all sorts of non-sense and as a result they didn’t make much chocolate. At some point the third guy just had enough and he started whining. Much like me in this post.

Guys, can we please focus on the chocolate instead of all this non-sense?

Frustrated…

On Xguest, Access Control and Desktop

Dan, I think the ideas behind Xguest are nice. But your ideas about using SELinux to implement access control for users leaves much to be desired. If you think that a brutal approach of denying individual users to even access services like HAL, NetworkManager and Bluez is good, then please think again. Please realize that if you do this, the desktop experience will suddenly change. Things like networking and bluetooth applets will cease to work. The file manager will fall back to relying on /etc/mtab and /etc/fstab. I’m not sure PulseAudio will start.

The problem is that your approach is not fine grained; it’s all or nothing. And this is not really useful. For example, for NetworkManager what you want is to lock down the machine so the user can only connect to trusted networks. With e.g. trusted networks being defined as something that is defined in a file in /etc that only uid 0 can change.

I’m not sure if it’s a surprise to you, but over the past year or so I’ve been working on and off on an application-level access control mechanism (similar to various RBAC implementations but with a few innovations on top) called PolicyKit that does all this. It’s specifically designed and optimized for desktop applications but can also be useful for legacy UNIX command line apps. It puts the administrator and users back in control since it provides a way for them to gain authorizations by authenticating and also supports systems like Ubuntu that has no root password. It provides a nice user interface for human beings to manage authorizations. There’s GTK+ widgets to make it really simple to integrate into existing applications (and KDE support is underway). The list of applications that are PolicyKit enabled is growing rapidly. It’s in all the major distributions. It encourages least privilege, e.g splitting a program into privileged and non-privileged bits.

It’s not that I hate SELinux because I don’t. I think SELinux is already very useful, just look at how useful SELinux is in confining network-facing and privileged services. I also have SELinux support in PolicyKit already and I plan (with your help) to make gnome-user-share run in a dedicated SELinux context so it is authorized to punch holes in the firewall without any configuration whatsoever (today it’s totally broken since g-u-s picks a random high port number to listen on). But, Dan, frankly, I think your use of SELinux to lock down access on the desktop is misguided. It’s a bit like if all you have is a hammer, then everything looks like a nail. I feel that it’s a bit sad that that two developers, working for the same company, in the same office are trying to solve the same problems. We really ought to do better.

(Disclaimer: this post does not necessarily represent the views of my employer, Red Hat, Inc.)

Update: A few people pointed out that I sounded too confrontational in this post and maybe they’re right. As I tried (and probably failed at) to explain it’s not either/or. Surely, there’s a ton of value in using SELinux to lock down privileged mechanisms like HAL, NM, Bluez and so on. Having PolicyKit and SELinux work well together is in everyone’s best interest.

Coverage

Andy Oram wrote a nice piece on PolicyKit detailing what it is and some of the plans for the future. I also did a short walk-through recently on one of our staff meetings here at Red Hat, there are some pseudo slides here. On the topic of coverage I’ve recently add unit tests to all the library sources and gcov tells me we’re at 59%. Not too shabby.

Policy, Mechanism and Time zones

In my last post I looked at D-Bus system bus activation and provided a step-by-step guide on how to use this. In this installment we’re going to look at a specific application of system bus activation; namely how it can be used from a desktop application to do a privileged operation: setting the timezone. This example will also feature usage of PolicyKit for lock down.

When dealing with programs that needs to do privileged operations, the first thing that one needs to do is to separate the mechanism (the piece of code actually doing the privileged bits) into a separate process from the rest of the program. The main program will then simply launch a small privileged helper whenever something privileged needs to happen. This is a good idea because it’s a lot easier to review a tiny privileged helper with minimal dependencies rather than a huge program that pulls in things like GTK+, Python, image loaders and what not. Typically, the privileged helper is written in a way such that it trusts no-one; it verifies all the incoming parameters and also checks whether the program that calls it should be allowed to do so. The latter part is where PolicyKit comes in - PolicyKit is an application-level toolkit that allows a mechanism to ask “is $USER allowed to do $ACTION?”. As such, PolicyKit comes with a set of data structures to help model these constructs.

Anyway, enough boring theory; the user experience we want is that the user can click on his predefined list of time zones to set it; something like this



If the user is not privileged to do this action, we may show a dialog like this



that may (or may not) feature buttons to make the system remember that setting the time zone is OK. Such that the system won’t ask for authentication in the future. In other words, this is a one-time-pain dialog.

Let’s go through the code and see how all this works. First, we need to write a mechanism. This will need to run as uid 0 (e.g. root) and we choose D-Bus as the interface for using the mechanism. We choose a unique name for the service, org.gnome.ClockApplet.Mechanism and since we’d like to write it in C using dbus-glib, we need to write some XML to define the objects and interfaces that this service will expose. This is defined in this file. As evident, this service exposes a single object, /, that exposes a single interface org.gnome.ClockApplet.Mechanism that currently exposes a single method SetTimezone(string zonefile) where the argument to that function is a path to what time zone we want to use. The mechanism itself consists of two C files, available here and here and a single C header file, available here.

Then, exactly as in the last post we need a D-Bus configuration file and a D-Bus service file. There’s also a cheesy Makefile to tie it all together.

Now, with this mechanism in place, we can poke it via D-Bus

$ dbus-send --system --print-reply --dest=org.gnome.ClockApplet.Mechanism / org.gnome.ClockApplet.Mechanism.SetTimezone string:/usr/share/zoneinfo/Europe/Copenhagen
method return sender=:1.346 -> dest=:1.345 reply_serial=2

The usage of PolicyKit deserves some explanation. First of all, as stated in the docs, we need to declare one or more actions for our mechanism. As we only export a single action right now (setting the time zone), we declare only that one action via the PolicyKit .policy file here. When we extend the mechanism to e.g. provide functionality to set the time as well (via e.g. a SetTime(int64 secs_since_epoch) method) we can declare an action org.gnome.clockapplet.mechanism.settime in addition to our org.gnome.clockapplet.mechanism.settimezone one.

Now, whenever someone calls into the mechanism, we simply use libpolkit to query whether the caller is allowed to do the specific action:

sender = dbus_g_method_get_sender (context);
pk_caller = polkit_caller_new_from_dbus_name (system_bus_connection, sender, &dbus_error);
pk_action = polkit_action_new ();
polkit_action_set_action_id (pk_action, "org.gnome.clockapplet.mechanism.settimezone");
pk_result = polkit_context_can_caller_do_action (pk_context, pk_action, pk_caller);
polkit_caller_unref (pk_caller);
polkit_action_unref (pk_action);
if (pk_result != POLKIT_RESULT_YES) { /* bail out */ }

The system administrator can control, using the /etc/PolicyKit/PolicyKit.conf configuration file, exactly what users are allowed to do this and whether they are allowed to keep the privilege to do the action on a forever- or per-session basis. This shouldn’t be necessary since it’s possible to specify the default result for a given action. Distributors can tweak the .policy as they see fit; for example consumer-oriented distributions might want to patch this to make the defaults always be “yes” (to avoid the auth dialog entirely) and workstation-oriented distributions might want the defaults to be “auth_admin” (to require the system administrator password and not give a chance to remember the privilege). Finally, sites can override this using the system-wide configuration file, e.g. if I’m a huge site I can distribute a PolicyKit.conf file that allows certain users to always do an action, certain other users never to do an action, and finally a third set of users for whom I want them to enter their own (or the root) password. Again, see the /etc/PolicyKit/PolicyKit.conf configuration file for details.

The screenshots above show integration with the intlclock applet; that’s thanks to Matthias Clasen. I simply handed Matthias the mechanism code including a simple GTK demo application available here. This application simply attempts to call into the mechanism and if the mechanism throws the org.gnome.ClockApplet.Mechanism.NotPrivileged exception it uses PolicyKit-gnome (via the session bus) to prompt the user for authentication if applicable.

The PolicyKit stuff is mostly done; at least the plumbing is there. What I like to see is some more GNOME-ish porcelain to make this stuff even easier to use. First, it’s simply way too complicated to write dbus-glib D-Bus servers. There’s just way too much code; compare to the Python server in the last post. Second, I’d like to provide a small library with a subclassed GtkButton, e.g. PolicyKitGtkButton such that all the magic happens there and it shows e.g. a lock only if authentication will be needed. I’m also planning to do a song and dance at the Boston Summit about this. The list of users of PolicyKit right now includes only HAL. However, PackageKit, dconf and virt-manager are all in the process of picking it up. I’m also hoping NetworkManager and things like gnome-system-monitor will pick it up (for the process killing bits instead of falling back to running the entire UI as uid 0 just for this). With time, and not too much time, I’m hoping for PolicyKit to be a blessed dependency in GNOME and banish the idea of su/sudo wrappers to enable running X11 applications as uid 0.

System Bus Activation hits Fedora Rawhide

.. well, almost. Anyway, you can get packages here or wait until Rawhide opens again (it’s currently frozen for F8t1). Credit goes to Richard for finishing this work and getting it past Havoc. This is a really huge thing; it opens up a lot of possibilities for better desktop/OS integration.

Lots of pretty colors

To actually test the packages I wrote a simple test program and thought it might be useful to share it. First, you need a program that claims a name on the system bus. I just copied the one from the dbus-python repository and modified it slightly. You can see it here.

Second, as with any service on the system message bus (as opposed to the session bus which has different security characteristics) you need a file in /etc/dbus-1/system.d. Mine is named dk.fubar.Test.conf (but note that any unique file name ending in .conf will do) and is pretty much run-of-the-mill standard stuff and shouldn’t be a surprise if you’re familiar with services on the system bus. It looks like this.

Finally, for system bus activation to work you simply need to put a service file in /usr/share/dbus-1/system-services. Mine is named dk.fubar.Test.service (again, any unique name ending in .service will do) and looks like this:

[D-BUS Service]
Name=dk.fubar.Test
Exec=/usr/sbin/dbus-sysbus-test.py
User=root

and that’s it! Provided you installed everything correctly (there’s a cheesy Makefile to do this) things should Just Work(tm) and the following command should print

$ dbus-send --system --print-reply --dest=dk.fubar.Test /SomeObject dk.fubar.Test.SampleInterface.HelloWorld string:foo
method return sender=:1.517 -> dest=:1.516 reply_serial=2
array [
string "Hello"
string " from example-service.py"
string "with unique name"
string ":1.517"
]

If your service is capable of operating correctly when running as an unprivileged system user (e.g. ftp or whatever) instead of root (think least privilege), simply change the user mentioned in both the .service and .conf files.

No more polling

I just committed code to hal to take advantage of asynchronous change notification events originating from SATA AN capable drives. This means we can avoid polling the drive and this should result in fewer wakeups in libata. This also opens the opportunity for the drive itself to go into a deeper sleep state when it’s not used. So all in all this should improve laptop battery life. I haven’t tried this on a laptop just yet, but when I find a suitable one I’m sure PowerTOP will tell me.

I took this while testing this GPS receiver. Click to see where to get good coffee.

Credit goes to Kristen Carlson Accardi from Intel. She did the kernel bits, sent me a SATA AN capable drive and pointed me in the right direction. To try this out, you will need a recent kernel and also some patches not yet in Linus’ tree. See RH #204969 for details. I’m hoping this will make it into Fedora 8; the hal bits will for sure; for the kernel bits I suppose asking davej is in order.

PolicyKit release

Late last night I finally made a PolicyKit release. It’s almost ready for prime time; wait a month for 0.4 to get out and I should be able to maintain a stable API.

PolicyKit in action

With Richard’s great work on D-Bus system bus activation it looks like we’re soon going to have nice upstream frameworks for enabling the desktop to do privileged operations in a hopefully sane way. Instead of having each and every distribution on the planet write their own configuration tools. I, for one, really wants to see some effort of merging such things into upstream GNOME and KDE as far as possible.

i’m in ur RAID, striping ur disks all the way to CA

Recently I acquired a pair of 500GB USB2 hard disks that I use in a RAID-1 configuration (on two different host controllers!); you know, to store my photos and other important, uh, stuff. I had some spare time this weekend to look at fd.o #6426 so I wrote a small patch to teach HAL about Linux software RAID.

RAID rebuilding

I also whipped up patch to gnome-device-manager such as to show the new properties introduced including whether an array is running in degraded mode or is being rebuilt. It’s pretty spiffy.

All that this code is doing right now is basically just listening to kernel events (via udev and priority data on /proc/mdstat) and then representing the RAID arrays as HAL drives and volumes. It’s spiffy because the RAID drive inherits things like storage.hotpluggable from the physical components (e.g. the two USB hard disks) so in my case the RAID array simply appears in Nautilus and is totally mountable just like a regular external drive. Works out of the box. Desktop integration++. However, we can do a bit better so for GNOME 2.20 I’ll be writing some patches to gnome-vfs and gvfs. You know, to use the new HAL properties to choose some helpful icons and icon captions.

Going forward, there needs to be some way of assembling and disassembling RAID arrays; hot-adding components to degraded arrays and so on and so on. Probably neither Nautilus nor gnome-device-manager is the right approach here. And there will probably be some sort of auto-assembly happening at the system-wide level anyway, need to sort that out with Kay (the udev maintainer) and also talk to various distro maintainers too. It’s also probably also time to revive my never properly announced GNOME Disk Utility project. Actually, that’s one reason that I split the Device Manager into a shell and library component; right now the shell is around 1200 lines (compared to 4000+ for the library) and there’s no reason that the Disk Utility shell would be a lot bigger. Plus it’s always awesome to put pretty UI on top of useful infrastructure.

Tomorrow I’m leaving for The Golden State to go the Red Hat summit, then hang out with Kay Sievers and finish off the west-coast invasion with FreedomHEC. The next two weeks are going to be busy.

Battery Recall^WExchange

Just found, via the interwebs, that the battery in my 15″ Macbook Pro was recalled^Weligible for exchange almost a year ago although not for safety risks, merely because “… batteries supplied to Apple do not meet our high standards for battery performance.” [sic]. So that’s something. Anyway, since this is useful information, I wanted to add information to hal-info such that other Macbook Pro users would benefit as well. By getting spammed with a popup like this

Useful feature in g-p-m

But as it turns out this data is not easily available


$ cat /proc/acpi/battery/BAT0/info
present: yes
design capacity: 55000 mWh
last full capacity: 47150 mWh
battery technology: rechargeable
design voltage: 10800 mV
design capacity warning: 250 mWh
design capacity low: 100 mWh
capacity granularity 1: 10 mWh
capacity granularity 2: 10 mWh
model number: ASMB012
serial number:
battery type: LION012
OEM info: SMPN012


meaning it’s hard to match on anything sensible from the fdi file. Maybe this is because it’s a Smart Battery? FWIW, I can see that the sbs driver is loaded. Lazyweb, please help - as comments on my blog are busted, please provide answers personally to me or, preferably, the hal list (requires subscription).

Btw, I couldn’t find this information by poking around in Mac OS X either… but it must be there; I mean, normal non-smart batteries record make, model and serial numbers just fine via ACPI. That’s what we use to tag other recalled battery units. So I’m sure it’s possible to get at. And if Apple wanted, they could easily have similar mechanisms for displaying notifications similar to the ones we have in GNOME. But I can understand it would hurt their bottom line. I guess.. this is one interesting aspect of getting your OS from the same vendor as where you get your hardware.

Anyway, I filled out the form and a new battery is on it’s way. I guess, uh, thanks Apple. Just wish you had notified me earlier and I wouldn’t have to find out this way .

Update: I suppose this isn’t technically a Product Recall; Apple specifically uses the word Exchange instead. I guess, from a legal point of view at least, there’s a difference. To me, as a consumer, it’s doesn’t make huge difference however… hmm.. maybe we need to add a new property info.is_eligible_for_exchange to the HAL spec to avoid using the word “recall” at all in such situations. I mean, to, uh, cover our collective asses from angry hardware vendors.