Very very cool little bookmarklet that shows loads of cool info about the styles of an element you click on a page. Wow!

Contact me

Silona Bonewald, the lady always in a hat (she says that it’s just become an extension of her). Describe her, by her tags: open government, open data, open standards, and databases.

(watch the video if your feed reader strips it out)

Silona’s the founder of The League of Technical Votes, which allows technical people to be more involved in voting process. As part of this, she created the Transparent Federal Budget, with Bill Bradley and Jimmy Wales.

On top of all that, she’s also the open source evangelist for grid.org. The focus there is a social network for grid, cluster, and cloud computing folk - a community of communities. Best of all, this was just launched on Tuesday!

It’s also the home to UniCluster, and they’ve recently struck a deal which Intel to pop UniCluster in BIOSes. UniCluster works with Sun’s Grid Engine, as well.

She’s interested in Drizzle, for the same reason that she likes Drupal. She likes the decorator model, and she thinks its a great way to get the parallel computing solutions fixed.

Needless to say, all of the stuff she works on currently, is powered by MySQL.

So, you contribute to Open-Source? Got something to say? Want to recruit others to your project? Want to spread the word about cool stuff? Looking for recognition for your contribution? Then you should consider responding to the Call For Presentations for linux.conf.au 2009!

Submissions close in about a fortnight, so you need to get your skates on and read up on making a submission, and then submit your proposal. You won't regret it - being a speaker at linux.conf.au is very worthwhile :-)

linux.conf.au 2009 - Monday January 19 to Saturday January 24, 2009 - the conference you want to go (and be a speaker at if you've got the stuff to say!)

Just had to figure out how to change the email address for a subscriber to a Mailman mailing list, and couldn’t find anything obvious saying it so having figured it out I thought I’d blog it for future reference.

It’s actually pretty easy, and fairly obvious once you know how:

clone_member -n -r user@old.address.com user@new.address.org

In other words, for all the mailman lists on this system go through and clone the old, non-working address user@old.address.com as user@new.address.org and then the -r option tells it to remove the old address.

The -n option is there to stop you shooting yourself in the foot and tells it to only tell you what it would do without actually doing it, so you’ll need to remove that to get it to actually take the action.

Caveat - as the manual page says:

Note that this operation is fairly trusting of the user who runs it — it does no verification to the new address, it does not send out a welcome message, etc.

a

Changing a Mailman list subscribers email address

It occurred to me that Mum and her partner drink wine with food and like to try out a variety of different wines. After getting some wine recommendations from Jane I set about finding somewhere to buy some nice wines from knowledgeable staff. I had Plonk at the Fyshwick Markets suggested and they sounded good as they focus on smaller labels and more variety than you may find from a large bottle shop chain.

I grabbed my car from home at lunch today and drove over to have a look, I walked away with what I think will be a reasonably nice gift of 8 bottles of wine from them, 6 whites and two reds. The wines I got are.

• Lake George - Pinot Gris
• Lake George - Shiraz
• Brindabella Hills - Chardonnay
• Pikes Clare Valley - Reisling
• Krinklewood - Verdelho
• Pizzini - Sangiovese
• Tohu - Sauvignon Blanc
• Garden Gully - Sparkling Shiraz

The Tohu comes from Marlborough region of New Zealand, apparently this is quite an award winning wine. Three of the wines as you can see are very much local and the others are all Australian. I liked the guys I talked to in the shop and we even talked about the possibility of them supporting some mountain bike stuff with CORC.

One of the most significant tasks performed by a SE Linux system is loading the “policy“. The policy is the set of rules which determine what actions are permitted by each domain.

When I first started using SE Linux (in 2001) the kernel knew where to find the policy file and would just read the data from disk as soon as it had mounted the root filesystem. Doing such things is generally considered to be a bad idea, but it was an acceptable mechanism for an early release.

One issue is that the policy needs to be loaded very early in the system boot process, before anything significant happens. In the early days the design of SE Linux had no support for a process to change it’s security context other than by executing another process (similar to the way a non-root process in the Unix access control system can not change it’s UID, GID, or groups). Although later on support for this was added, it was only available as the request of the application (an external process could not change the context of an application without using ptrace - a concept that is too horrible to contemplate) and I am not aware of anyone actually using it. So it’s almost a requirement that there be no more than one active process in the system at the time that policy is loaded, therefore it must be init or something before init that loads the policy.

When it was decided that a user-space program had to instruct the kernel to load the policy we had to determine which program should do it and when it should be done, with the constraint that it had to be done early. The most obvious solution to this problem was to load the policy in the initramfs (or initrd as it was known at the time). One problem with this is that the initramfs is limited in size by kernel compilation options and may need to be recompiled to fit a bigger policy. As an experiment to work around this limitation I had a small policy (which covered the domains for init and the scripts needed for the early stages for system boot) loaded in the initramfs and then later in the boot process (some time after the root filesystem was mounted read/write) the full policy was loaded.

A more serious problem with including policy in the initramfs was that it required rebuilding the initramfs every time the policy changed in a significant way, of course scripts could not determine when a change was significant (neither could most users) so that required needless rebuilds (which wastes time). Even with a small policy for early booting loaded it was still sometimes necessary to change it and update the initramfs. I believe that as a general rule an initramfs should only be rebuilt when a new kernel is installed or when a radical change is made to the boot process (EG moving from single disk to software RAID, changing between AMD and Intel CPU architecture, changing SCSI controller, or anything else that would make the old initramfs not boot the machine). The initramfs that was used to boot my machine is known to actually work, the same can not be said for any new initramfs that I might generate.

But the deciding factor for me was support of machines that did not use an initramfs or initrd (such as the Cobalt machines [1] I own).

To solve these problems I first experimented with a wrapper for init. The idea was to divert the real init to another file name (or use the init= kernel command-line option) and then have the wrapper load the policy before running the real init. I never intended that to be a real solution, just to demonstrate a point. Once I had proven that it was possible to load the policy from user-space before running the real init program it was a small step to patch init to do this.

One slightly tricky aspect of this was in getting the correct security context for init. The policy has always been written to allow a domain transition from kernel_t to init_t when a file of type init_exec_t is executed. The domain kernel_t is applied to all active processes (including kernel threads) at the time the policy is loaded. So init only has to re-exec itself to get the correct context. Fortunately init is designed to do this in the case of an upgrade so this was easy to manage.

Since that time every implementation of SE Linux apart from some embedded systems has used init to load the policy.

The latest trend in Linux distributions seems to be using upstart [2] as a replacement for the old SysV Init. The Fedora developers decided to make nash (a program that comes from the mkinitrd source tree in Fedora and is a utility program for a Red Hat based initramfs) load the SE Linux policy as it would apparently be painful to patch every init to load the policy.

As far as I am aware there are only three different init programs in common use in Linux, the old SysV Init (which used to be used by everyone), Busybox (for rescuing broken systems and for embedded systems), and now Upstart (used by Ubuntu and Red Hat since Fedora 9). Embedded systems need to work differently to other systems in many ways (having the one Busybox program supply the equivalent to most coreutils in one binary is actually a small difference compared to the other things), and modifying the policy load process for embedded systems is trivial compared to all the other SE Linux work needed to get an embedded system working well. There are at least two commonly used initramfs systems (the Debian and Red Hat ones) and probably others. As one init system (SysV Init) already has SE Linux support it seems that only one needs to be patched to have complete coverage. I’ve just written a patch for Upstart (based on the version in Debian/Experimental) and sent it to an Ubuntu developer who’s interested in such things. I also volunteer to patch any other init system that is included in Debian (I am aware of minit and will patch it as soon as it’s description does not include “this package is experimental and not easy to install and use“).

It seems to me that repeating the work which was done for SysV Init and upstart for any other init system will be little effort, at worst no greater than patching an initramfs systems (and I’ll do it). As the number of initramfs systems that would need to be patched would exceed the number of init systems it seems that less work is involved in patching the init systems.

The amount of RAM required by the initramfs is in some situations a limitation on the use of a system, when I recently did some tests on swap performance by reducing the amount of RAM available to a Xen DomU [3] it was the initramfs that limited how small I could go. So adding extra code to the initramfs is not desired. While this will be a small amount of code in some situations (when I patched /sbin/init from Upstart it took an extra 64 bytes of disk space on AMD64), dragging in the libraries can take a moderate amount of space (the fact that an LVM or encrypted root filesystem causes SE Linux libraries to be included in the initramfs is something that I consider to be a bug and plan to fix).

Finally not all boot loaders support an initrd or initramfs. I believe that any decision which prevents using such sweet hardware as Cobalt Qube and Raq machines from being used with SE Linux is a mistake. I have both Qube and Raq machines running fine with Debian SE Linux and plan to continue making sure that Debian will support SE Linux on such hardware (and anything with similar features and limitations).

• [1] http://en.wikipedia.org/wiki/Cobalt_Networks



• [2] http://upstart.ubuntu.com/



• [3] http://etbe.coker.com.au/2008/05/22/xen-and-swap/

Share This

Today is our third wedding anniversary.

We're marking the occasion by having a night at the Tickle Pink Inn, which I can vouch for as being very nice indeed.

Unfortunately I ended up on-call this week, so my day off tomorrow isn't going to be as idyllic as it could have been.

It's hard to believe we've only been married three years. I think we've already been through more than a lot of married couples would have to go through in a lifetime.

Here's to at least another 50 years.

Unfortunately, despite plans, I wasn't able to attend OSCON this year even though my husband, Paul Fenwick has made it. It would have been my first time out of Australia, but I'll have to wait for that.

Still, I asked him to bring me home a present, and last night he sent me:

You asked me to bring you home a nice present. I'm actually bringing home a present from the entire Perl community for you!

You're the recipient of one of the three White Camel awards!

I struggled at first to take him seriously.

Wow.

Really, Wow.

I didn't even know I was nominated. Thankyou to the unknown person or persons who nominated me.

Someone asked me what a white camel award was; and I struggled to answer the question to my satisfaction. So I searched and found:

The White Camel reward recognises the Perl community's "unsung heroes"--those who have devoted extraordinary creativity, energy, and time to the non-technical work that supports Perl's active and loyal user community.

I think originally it was divided into three areas: Perl Advocacy, Perl User Groups, and the Perl Community with one award each; but I suspect that distinction has since been dropped.

I join a very short list of very impressive people who've also earned one of these awards and share this year with Gabor Szabo and Tatsuhiko Miyagawa who most certainly deserve their awards.

Thanks again to those who nominated me; to the judges who've honoured me; to Paul for accepting the award on my behalf and to everyone else who's offered me such lovely and sincere congratulations!

Thankyou to the folk that attended my presentation at OLS this afternoon, a good crowd and some excellent suggestions from the audience.

As I mentioned in the talk, I've put my slides up here and have made some additions based on discussions during and after the session. Starting to think this might be worth putting in a Wiki or sommet like that.

Thanks again to the folk here at the conference, those around the OzLabs lunch table and from elsewhere that contributed :)

Interested in MySQL? Drizzle? How the Sun acquisition is going for MySQL? Listen to Brian, Monty, and Tim speak about this, at the OSCON panel. Watch the video, its 20+ minutes, it starts off a bit shaky (oops), but I’m mostly happy with the rest. Enjoy.

When I saw Paul Fenwick's blog on autodie my soul leapt towards Nirvana, since I've wanted an autodie facility in Linux for a long time. Then I read the article and found it wasn't what I thought it was at all.

Let me explain.

Linux works. So some people don't update it. There's nothing wrong with that -- unless the machine on the Internet. In that case older and unsupported machines are very vulnerable to misuse. There's a lot of those machines about. I unplugged a machine running Red Hat Linux 5.2 the other day.

I'd love for all distributions to ship with an autodeath cron job. Ship the operating system with an expected expiry date, when that date arrives delete any default route. If the vendor extends maintenance then they can update the autodeath package as part of that maintenance. Similarly for an distribution "legacy" maintenance project.

Deleting the default route is sufficient. Standalone machines won't have a default route, so autodeath will have no effect, which sounds correct. Internet-connected machines will lose Internet connectivity, which sounds right. Especially if booting into single user mode and manually starting the network still works so the machine's owner has a path to doing a network-based OS upgrade.

I have a slide I use when presenting about content management systems to manglement types. Content management systems suck. They're designed that way. The main idea behind them, in a corporate context, is to allow content to be published quickly by people who don't know (much) HTML so that it fits within the existing structure. The trade-off is that it's a whole lot less flexible. Anything you want to do that doesn't fit into the built-in templates and structure is going to require some development.

The reason I use this slide is to explain that there's a middle ground in there. If you're an enormous publishing organisation with daily deadlines and a team of editors, sub-editors and content approvers, then the top-end systems are necessary. For most corporate web sites though, somewhere in the middle makes more sense.

When you demonstrate the idea of approvers and workflow that's built into most CMSes, manglement types start getting ideas. They love the idea of a defined workflow, with things getting signed off as they go through the workflow. Yet I've never worked in an organisation where the workflow features work. You always end up with one or more approvers who constantly forget their logins, forget what they're supposed to do to approve, or do the wrong thing when they're in there. It always ends up reverting to a paper-based system, printing out the content for approval. In most situations, it's a better approach. The workflow systems in most CMSes get turned off pretty quickly in most implementations.

I'm about to start specifying a new content management platform for my employer, so it's got me thinking about the complexity level we're going for. Parts of our site are quite tricky, technical bits of code and integration with other systems. But most of it is just plain content. Our current CMS is a little too far to the right on the axis I've drawn above, with seemingly-simple changes quite hard to make, involving digging through templates, schema definitions and template elements. I need to find a middle ground for the next crack at it.

Looking around at the free software content management systems, it's pretty difficult to compare them in any meaningful way. And more important to me is the company we end up using to build the thing. I'd really rather not have a PHP/MySQL platform, but two off the seemingly best-supported CMSes (Joomla and Drupal) are just that. I love the look approach taken by the Perl+XUL cyclone3, but the only companies supporting it seem to be in Europe.

So, lazyweb, can you recommend any good CMS development companies who are interested in a pretty big project? I'd like a small, nimble, free software-loving group who are well-versed in Agile development. Sydney ideally, but elsewhere in Australia is okay. Let me know.

Contact me

• Josh Brindle on SELinux in Ubuntu. They're making good progress, although the idea of SELinux is to introduce ubiquitous, generalized MAC security, so he is advocating they enable SELinux by default as is done in Fedora, and as you typically do with other OS security layers.



• John Weeks from Sun talking about OpenSolaris FMAC (introducing Flask/TE to their OS). It was interesting to see a dtrace graph of the AVC operating—a kernel mechanism for which I've developed an abstract mental model but never "seen".



• Dan Walsh Talking about his ongoing work in utilizing SELinux to create practical security features for everyday users.
  
  
  
  
  
  The above is from a demonstration where nsplugin (the framework for Firefox plugins, i.e. where flash etc. is run) is being sandboxed by SELinux, so that a flawed or malicious plugin cannot be used to snoop your keystrokes. In this case, a simulated (and trivial) exploit was blocked from capturing internet banking passwords by SELinux.
  
  
  
  Btw, Dan will be demonstrating this today during his OLS talk on Confining the User. There's a lot of really cool stuff coming in this area & the talk should be well worth attending.





• Karl MacMillan on alternatives to comprehensive least-privilege, where he described some ideas and plans for simplifying the way SELinux policy is deployed for general purpose use. He has some really promising ideas on reducing the granularity of the policy while still maintaining strong security. This can lead to simpler and smaller policy, which is important for all kinds of users.



• Peter White talked about two higher-level languages being developed to express SELinux policy, Lobster and Shrimp, which will introduce features such as type checking and object orientation to the policy language area. Peter is a Haskell guy, and it all looks very promising.