Recently I fixed my OpenVPN tunnel and figured out what was wrong with my bridge setup. Here is the complete setup that I have. Server I wanted to have as much of the configuration on the server as possible so that I could easily add more clients and wouldn't have a need to update client configuration when ever the server preferences change. Here is my OpenVPN server configuration:

mode server
tls-server
dev tap0
server-bridge 10.5.6.1 255.255.255.0 10.5.6.200 10.5.6.209
ifconfig-pool-persist /var/run/openvpn-ip.txt
keepalive 10 60
ping-timer-rem
persist-tun
push "route 10.5.6.0 255.255.255.0"
push "dhcp-option DNS 10.5.6.1"
ca /root/easy-rsa-2.0/keys/ca.crt
key /root/easy-rsa-2.0/keys/ressukka.net.key
cert /root/easy-rsa-2.0/keys/ressukka.net.crt
dh /root/easy-rsa-2.0/keys/dh1024.pem
client-to-client
up /etc/openvpn/ovpn-ressukka.sh

and the up script:

#!/bin/sh
# Bind the tunnel interface to the bridge
BRIDGE=br0
ifup $1
brctl addif $BRIDGE $1

There is nothing really special about that configuration. The server is in TLS mode configures a bridge. The keys are generated with easy-rsa by following a openvpn howto entry. The up script just binds the tap0 device to the network bridge after bringing up the device. Next I created the interface configuration by adding the following to /etc/network/interfaces:

iface br0 inet static  
 address 10.5.6.17  
 gateway 10.5.6.1  
 netmask 255.255.255.0  
 bridge-ports eth0

The trick here is to create a single bridge with just the eth0 device. We use the up script for openvpn to add the tunnel device to the bridge. Otherwise the bridge would never contain the proper devices. Client As for the client, you simply set the client to use the CA-certificate and Host key created with easy-rsa, set the hostname and tunnel type. Tunnel type is assumed to be a tun-device instead of tap, so in my case I needed to change it too. There is no need to tell the client anything else. Everything else will be negotiated through the tunnel. And since I use NetworkManager to set up my tunnels I didn't have a need to drop in to a shell even once at the client.

I've been meaning to write up on this for quite some time now, but always have something seemingly more important things to do. Most modern Linux distributions offer ways to manage network interfaces via some kind of abstraction. Usually this abstraction allows one to dynamically rename and add network interfaces. For Debian family management is done with ifupdown, while with RedHat family it's sysconfig. In addition there is NetworkManager which is a cross platform solution for dynamic network configuration (which eliminates the need to rename interfaces). Case Xenserver Usually this comes in rather handy, but on other occasions it can be a pain. A while I was helping out with an installation of a XenServer instance. This server had, for some reason, ethernet interfaces reversed in comparison to the other XenServers on the site. Luckily the service console has the network configuration in ifcfg scripts. We were easily able to reverse the interfaces by binding the interfaces to certain hardware addresses. The only problem is that the interface is renamed only when the interface is brought up. What's worse the interfaces were enumerated before the server would bring up all of the interfaces. Only eth0 was brought up for management purposes before enumerating. This means that the original eth0 was renamed to _tmp_xxxxxx. The (oh so elegant) solution was to create a script that does ifup eth1; ifdown eth1. Problem solved. Case tap0 I also experienced similar problems when I was setting up my OpenVPN tunnel. I wanted to use a bridged connection to my network, but for that I needed to create a br0 interface with tap0 as a member. It's easy enough to create ifupdown configuration to set up tap0. Hook that up to br0 and you are all set. The same problem will bite you here. The interface tap0 is actually created only when the tap0 is brought up and br0 members are added only if they are present. The solution? In my case, create a custom script that adds the device manually after it's been created properly. I was unable to find anything that works without using a custom script =( In retrospect Looking back at these cases, I should have known better. The problem was obvious and it took me way too long to figure out the cause for my problems. Then again, the utilities should be able to create a reasonable abstraction for themselves that they use to determine the actual status of the whole system. This way the trickery needed for setting up simple interface would be obsolete. You can't have it all, but you can always hope.

At least 150 people were reported killed today in an air crash at Madrid. Rest in peace, all of you will be missed.

I’ve been installing free software for library cataloguing onto Apples recently. It’s not been great (GNU/Linux is still easier and faster, in my opinion) but it has worked much better than older Macs. As well as making servers that are finally getting easier, Apple lead the way in locked-down portable players, with their iPod and iPhone devices and iTunes service. Quite rightly, free software users campaign against Apple’s use of DRM/TPM (Technical Protection Measures). One of the rallying points has been Defective by Design (DbD), an FSF initiative since 2006. Long-time readers may remember that I took part in a DbD protest at an Apple Store in September 2006:-

“I noticed the huge till queue, which was attractive for three reasons: it had no security (I guess shoplifters rarely queue for the till), most of them are standing around waiting for something to read and they are almost certainly Apple customers, so who better to inform? After I rejoined the back of the queue a few times, a security man was watching it, so I moved off and chatted to people waiting to do hands-on tests on the upper floor for a bit [...] then I moved back to leaflet the till queue again. [...] Then, I got a bit bored and started putting the leaflets into Apple’s product leaflet dispensers (in front of Apple’s - no leaflets were removed), which soon got me rumbled.”

To me, that was fine: I dislike that type of store, which tries to look like public space, but is actually privatised and controlled. My resource use was minimal (one security man escorting me out and some Saturday kid probably “cleaned” the leaflet racks) but I passed information to many Apple customers, who are one of only two groups Apple must keep happy, ultimately. Popey is a bit upset by the latest protest idea, which he describes as:-

“urging people to book slots at the Apple in-store “Genius Bar” to ask probing questions which they already know the answer to about their company policy on DRM and Free software. The ‘Genius Bar’ is an official Apple support avenue for their customers, and is a service provided inside many of their stores.”

It’s also been criticised by neuro and Pete along similar lines. I agree. It’s wasting both side’s resources. Apple don’t really need to keep their staff happy (they can hire new staff) and it offends Apple customers and shareholders. It’s not even efficient: each unit of Apple employee time wasted costs a unit of DbyD worker time and who’s got the most resources there? What are FSF thinking? It’s stupid, even without the bad press it’s had. So, this brings me in a roundabout way to answering

“I am aware of the Linux Foundation and the FSF and others, but how does SPI differentiate itself and its goals from those organizations?”

from why people don’t join SPI. In my opinion, a key difference of Software in the Public Interest is that it is managed by free software developers in a more-or-less democratic fashion. Even though I’ve failed in two elections, I still think it’s better than the alternatives. No project as unpopular as wasting Apple Store helpdesk time would ever get backed by SPI, would it?

Update: There are more notes on how aptitude performs as a Sudoku solver here. Russell Coker recently wrote a post entitled Ownership of the Local SE Linux Policy. This post has nothing to do with the substance of his post, which is a discussion of how distributions should configure SELinux by default. I know nothing about SELinux, but something that Russell said in passing caught my attention:

I am not aware of the Debian package dependencies (or those of any other distribution) being about to represent that the postfix package depends on selinux-policy-default-postfix if and only if the selinux-policy-default package is installed. Please note that I am not suggesting that we add support for such things, a package management system that can solve Sudoku based on package dependency rules is not something that I think would be useful or worth having.

(emphasis added) As it happens, a little-known fact about the Debian packaging system is that you can, in fact, describe Sudoku puzzles in it! Note for the impatient: If you want to skip all this talk and jump to the code, see debsudoku.py. For those of you who, like me, are not Sudoku-heads, here's a quick summary of the rules (for the common case of a game with 3 blocks):

1. The game is played by filling in a 9-by-9 grid with numbers between 1 and 9, inclusive. The board is divided into 9 3-by-3 blocks of grid cells in the obvious way.
2. All the cells in a column must contain different numbers.
3. All the cells in a row must contain different numbers.
4. All the cells in a block must contain different numbers.

There are many ways that you could convert a Sudoku problem into a Debian package archive, but here's a particularly simple one that is close to my summary of the rules. Create 9 * 9 * 9 = 729 packages, named cellR.C-V where R stands for row, C for column, and V for value. Each of these packages represents writing the value V in the cell (R, C). To describe the relationships of each cell to the other cells in the problem, we can create several virtual packages:

• The virtual package cellR.C represents the statement The cell (R, C) has been filled in with some value. It will be used to ensure that only one value is placed in any particular cell, and to ensure that all the cells in the puzzle are filled in with something.
• The virtual package blockR.C-V represents the statement A cell in the block (R, C) has been filled in with the value V. The block coordinates are the block-row and block-column containing the cell; for instance, the cell at (5, 8) is in block (2, 3). This package will be used to ensure that only one cell in a given block contains the same value.
• The virtual package rowR-V represents the statement A cell in the row R has been filled in with the value V. It will be used to ensure that no two cells in any given row have the same value.
• The virtual package colC-V represents the statement A cell in the column C has been filled in with the value V. It will be used to ensure that no two cells in any given column have the same value.

Converting these requirements to package dependencies is quite straightforward. For the package cellR.C-V, in block row BR and block column BC, we add these lines to the package's definition:

Provides: cellR.C, blockBR.BC-V, rowR-V, colC-V
Conflicts: cellR.C, blockBR.BC-V, rowR-V, colC-V

For instance, the cell at (5, 8) will get these provides/conflicts for V=2:

Provides: cell5.8, block2.3-2, row5-2, col8-2
Conflicts: cell5.8, block2.3-2, row5-2, col8-2

This relies on the fact that self-conflicts are ignored (see Debian Policy section 7.4). To actually describe the puzzle we want to solve, we need to add another package that requires two things:

1. Every cell contains a value.
2. The cells that the problem fixes have their fixed values.

For instance,

Package: puzzle
Depends: cell1.1, cell1.2, ..., cell5.9-3, cell6.1, ....

if we want to require that the cell at (5, 9) contains the value 3. Proof-of-concept As a proof-of-concept, I have written a hacky Python script, named debsudoku.py, that can convert ksudoku saved games into Packages files suitable for use with apt-get or aptitude. In fact, it has two modes: conflicts, which implements the conversion described above, and depends, which implements a different but logically equivalent conversion using only Depends instead of Conflicts. To use the script, save a ksudoku board without doing any work on it, then run

python debsudoku.py /path/to/the/ksudoku/board

I've only done minimal testing on this, so don't use it to fly airplanes (in fact, please don't use any Sudoku player to fly airplanes), but I did use it, in combination with aptitude, to solve a single ksudoku puzzle. Real-world evaluation Interestingly, in a test with an easy puzzle generated by ksudoku, aptitude was able to solve the puzzle in just a few seconds when it was expressed with the conflicts reduction, but failed to find a solution at all using depends (I stopped it after several minutes). I think this is due to how the depends reduction is performed. Take rows: instead of generating conflicts between cells in a row, it requires that each row contain every number between 1 and 9. The problem with this is that aptitude's resolver functions poorly when there are non-obvious conflicts in the dependency structure. It will decide to try a combination of packages that can't be installed together, but it won't realize it. As a result of this, it ends up trying many possible combinations of packages. For instance, it might try to place the number 3 in both (2, 5) and (5, 5). There is no dependency outlawing this in the depends reduction, so aptitude will happily continue trying to resolve dependencies. Since it has used 3 twice in the fifth column, it will not be able to find any way to resolve all the dependencies that state that all the numbers between 1 and 9 appear in the 5th column, but it lacks the higher-level reasoning that would allow it to break out; it will end up trying many or most of the possible ways of filling cells in before it gives up on the offending re-use of 3. Luckily, real-world package archives (what the aptitude resolver is designed to run on) don't usually look like this.

I have gotten quite some response to my blog post about the hardware test proposal thingy from Bdale. It would seem I haven't been entirely clear Someone referred me to a page by Kenshi Muto that parses 'lspci' output into a hardware compatibility list. This doesn't help. It ignores x.org stuff (which is important, too) and the page itself clearly says that it cannot guarantee whether a piece of hardware will actually work. For clarity: when I said 'Apparently all the other vendors have it, too', I really meant 'Apparently all the other GNU/Linux vendors have it, too'. People have suggested some cooperation between kernel/xorg upstream, other vendors, and perhaps something like freedesktop.org; and while that may be a good idea in and of itself, in the end Debian will have to provide something which it will call 'official' and which will tell a vendor whether or not Debian is supported on their hardware. This thing may not be fully automated or polished; it may need interactivity; but it must be something which will give a result that a product manager may want to lose some sleep over if it's not good enough. Holger also suggested we try implementing this with Debian Live, rather than debian-installer. This may be a good suggestion; a debian-live image will have a full Debian system available rather than the somewhat limited d-i environment, so writing a test should be easier. Also, I don't even want to think how testing X.org drivers would work out from within d-i. So what's left is a way to figure out how to do such a live system. I'll be posting some suggestion to the debian-devel mailinglist 'soon'.

I tried terminator (thanks go to Nicolas Valcarcel for asking me to sponsor a Debian upload, thus forcing me to try it, and Asheesh Laroia for doing a lightning talk at debconf about it), but I’m not convinced.
- More keybindings are clearly missing. You can only switch terminals using Previous/Next keybindings.
- More features would be great, like the ability to switch the position of two terminals (so you could reorganize them).
- It has some small usability problems, like the fact that the config is text-based, not using gconf, that it’s not possible to change the config without restarting it, that the title bar doesn’t display anything useful most of the time, since it prefixes the current terminal’s title with “Terminator: “, etc. So, is there any other tiling terminals manager I should try, before filing tons of feature requests on terminator? My other requirement is that it mustn’t reinvent the wheel, but use the gnome-terminal widget. Thank you.

While I enjoyed watching some of the DebConf 8 Video Team’s Excellent Service, not all of it was at convenient times for me, being several timezones away, so I used the following script to record some of the streams:-

#!/bin/sh
# Example: recordstream 09:00 09:55 -Otalk.ogv http://server:8000/stream
start=$1
end=$2
shift 2
( echo wget -q "$@" '&'
echo 'echo $! > $HOME/wget.pid' )   at $start
echo 'kill $(<$HOME/wget.pid)'   at $end

I think that’s right, but I might have fluffed a $@ for a $* or similar (I usually use the simpler rc shell but it’s not on that server yet). It uses the oft-forgotten at command for one-off timed scripts, so you’ll need the at package installed. I think it might exploit the fact that players like mplayer, VLC and ffplay don’t mind truncated streams, but it seems to work fairly reliably apart from the timing. In other Debian-related news: Debian GNU/Linux: 15 Years Old and at the Crossroads by Bruce Byfield seems an interesting summary (warning: its feedback form contains an eyetest), but doesn’t mention DebConf apart from getting its name wrong. I had the impression that there were a few “at the crossroads” type of talks at DebConf. I guess we’ll see what concrete results come out of DebConf over the next few weeks.

Besides the slides from the tutorial at UseR! 2008 that were mentioned here previously, I also gave a short talk on scripting with R in high-performance computing using our littler frontend to R. The talk introduces and extends an example related to some of the material from the tutorial itself. The slides from the talk are a little rough as the talk was somewhat ad-hoc: As session chair, I was confronted with a fairly last-minute cancellation and a 15 minute hole, and thought this would make a good little talk. It does show a nice trick for using littler with Open MPI (via snow) under the powerful slurm resource manager and batch/queue engine.

A large part of the disagreement about the way to manage the policy seems to be based on who will be the primary “owner” of the policy on the machine. This isn’t a problem that only applies to SE Linux, the same issue applies for various types of configuration files and scripts throughout the process of distribution development. Having a range of modules which can be considered configuration data that come from a single source seems to make SE Linux policy unique among other packages. The reasons for packaging all Apache modules in the main package seem a lot clearer. One idea that keeps cropping up is that as the policy is modular it should be included in daemon packages and the person maintaining the distribution package of the policy should maintain it. The reason for this request seems to usually be based on the idea that the person who packages a daemon for a distribution knows more about how it works than anyone else, I believe that this is false in most cases. When I started working on SE Linux I had a reasonable amount of experience in maintaining Debian packages of daemons and server processes, but I had to learn a lot about how things REALLY work to be able to write good policy. Also if we were to have policy modules included in the daemon packages, then those packages would need to be updated whenever there were serious changes to the SE Linux policy. For example Debian/Unstable flip-flopped on MCS support recently, changing the policy packages to re-enable MCS was enough pain, getting 50 daemon packages updated would have been unreasonably painful. Then of course there is the case where two daemons need to communicate, if the interface which is provided with one policy module has to be updated before another module can be updated and they are in separate packages then synchronised updates to two separate packages might be required for a single change to the upstream policy. I believe that the idea of having policy modules owned by the maintainers of the various daemon packages is not viable. I also believe that most people who package daemons would violently oppose the idea of having to package SE Linux policy if they realised what would be required of them. Caleb Case seems to believe that ownership of policy can either be based on the distribution developer or the local sys-admin with apparently little middle-ground [1]. In the section titled “The Evils of Single Policy Packages” he suggests that if an application is upgraded for a security fix, and that upgrade requires a new policy, then it requires a new policy for the entire system if all the policy is in the same package. However the way things currently work is that upgrading a Debian SE Linux policy package does not install any of the new modules. They are stored under /usr/share/selinux/default but the active modules are under /etc/selinux/default/modules/active. An example of just such an upgrade is the Debian Security Advisory DSA-1617-1 for the SE Linux policy for Etch to address the recent BIND issue [2]. In summary the new version of BIND didn’t work well with the SE Linux policy, so an update was released to fix it. When the updated SE Linux policy package is installed it will upgrade the bind.pp module if the previous version of the package was known to have the version of bind.pp that didn’t allow named to bind() to most UDP ports - the other policy modules are not touched. I think that this is great evidence to show that the way things currently work in Debian work well. For the hypothetical case where a user had made local modifications to the bind.pp policy module, they could simply put the policy package on hold - I think it’s safe to assume that anyone who cares about security will read the changelogs for all updates to released versions of Debian, so they would realise the need to do this. Part of Caleb’s argument rests on the supposed need for end users to modify policy packages (IE to build their own packages from modified source). I run many SE Linux machines, and since the release of the “modular” policy (which first appeared in Fedora Core 5, Debian/Etch, and Red Hat Enterprise Linux 5) I have never needed to make such a modification. I modify policy regularly for the benefit of Debian users and have a number of test machines to try it out. But for the machines where I am a sysadmin I just create a local module that permits the access that is needed. The only reason why someone would need to modify an existing module is to remove privileges or to change automatic domain transition rules. Changing automatic domain transitions is a serious change to the policy which is not something that a typical user would want to do - if they were to do such things then they would probably grab the policy source and rebuild all the policy packages. Removing privileges is not something that a typical sysadmin desires, the reference policy is reasonably strict and users generally don’t look for ways to tighten up the policy. In almost all cases it seems best to consider that the policy modules which are shipped by the distribution are owned by the distribution not the sysadmin. The sysadmin will decide which policy modules to load, what roles and levels to assign to users with the semanage tool, and what local additions to add to the policy. For the CentOS systems I run I use the Red Hat policy, I don’t believe that there is a benefit for me to change the policy that Red Hat ships, and I think that for people who have less knowledge about SE Linux policy than me there are more reasons not to change such policy and less reasons to do so. Finally Caleb provides a suggestion for managing policy modules by having sym-links to the modules that you desire. Of course there is nothing preventing the existence of a postfix.pp file on the system provided by a package while there is a local postfix.pp file which is the target of the sym-link (so the sym-link idea does not support the idea of having multiple policy packages). With the way that policy modules can be loaded from any location, the only need for sym-links is if you want to have an automatic upgrade script that can be overridden for some modules. I have no objection to adding such a feature to the Debian policy packages if someone sends me a patch. Caleb also failed to discuss how policy would be initially loaded if packaged on a per-module basis. If for example I had a package selinux-policy-default-postfix which contains the file postfix.pp, how would this package get installed? I am not aware of the Debian package dependencies (or those of any other distribution) being about to represent that the postfix package depends on selinux-policy-default-postfix if and only if the selinux-policy-default package is installed. Please note that I am not suggesting that we add support for such things, a package management system that can solve Sudoku based on package dependency rules is not something that I think would be useful or worth having. As I noted in my previous post about how to package SE Linux policy for distributions [3] the current Debian policy packages have code in the postinst (which I believe originated with Erich Schubert) to load policy modules that match the Debian packages on the system. This means that initially setting up the policy merely requires installing the selinux-policy-default package and rebooting. I am inclined to reject any proposed change which makes the initial install of of the policy more difficult than this. After Debian/Lenny is released I plan to make some changes to the policy. One thing that I want to do is to have a Debconf option to allow users to choose to automatically upgrade their running policy whenever they upgrade the Debian policy package, this would probably only apply to changes within one release (IE it wouldn’t cause an automatic upgrade from Lenny+1 policy to Lenny+2). Another thing I would like to do is to have the policy modules which are currently copied to /etc/selinux/default/modules/active instead be hard linked when the source is a system directory. That would save about 12M of disk space on some of my systems. I’ve taken the unusual step of writing two blog posts in response to Caleb’s post not because I want to criticise him (he has done a lot of good work), but because he is important in the SE Linux community and his post deserves the two hours I have spent writing responses to it. While writing these posts I have noticed a number of issues that can be improved, I invite suggestions from Caleb and others on how to make such improvements.

• [1] http://www.calebcase.com/node/2


• [2] http://lists.debian.org/debian-security-announce/2008/msg00201.html


• [3] http://etbe.coker.com.au/2008/08/18/se-linux-policy-packaging-distribution/

Share This

What I liked

• Excellent organization, orga team fully deserved all the praise they got.
• Meeting people - it was the first DebConf I attended in person, so it was a pleasure to meet lots of folks whom I’ve only known online before.
• Quite a few interesting talks (videos are available, or will be available shortly, in DebConf8 video archive). Particularly recommended: quality assurance talks/BOFs by Lucas Nussbaum, BTS development progress by Don Armstrong, method diffusion in large volunteer projects by Martin Krafft, talk and debate on OpenSSL security issue by Luciano Bello, various lightning talks.
• Deserving a special mention, a talk by Mark Shuttleworth on Debian and Ubuntu relationship. I thought that he said all the right words and, judging by reactions, attitude towards Ubuntu has changed significantly during the last year, turning from hostility to peaceful cooperation.
• Argentinian food: steaks, empanadas, alfajores.

What I did not like

• People pay much less attention to fixing RC bugs than they used to, the two BSPs organized during DebConf8 attracted only 3-5 people.
• Some nice ideas being thrown around without anyone volunteering to work on them. Not really surprising, given that most of the core teams are short on manpower.
• Almost complete lack of events targeted at engaging users and beginner contributors.
• Quite a few specialized talks, interesting (IMHO) to only a minor percentage of the attendees.
• Lots of discussions with few or no specific decisions or action items.
• Pretty long trips to and from Mar del Plata (about 30 hours door-to-door travel time for me), luggage was lost for 2 days on the way there.

What I did

• Attended about 75% of talks, tried to contribute to discussion in constructive, non-flamy ways .
• Participated in BSPs, contributed debugging information, patches or fixes for about a dozen of release critical bugs, started triaging sparc-specific bugs.
• Started working on updating the Debian kernel handbook for Lenny, about 1/3 done.
• Gave a “Google and Open Source” lightning talk.

I watched Citizen Kane several weeks ago and was shocked to learn that the major villian in the film is a political boss named Jim Gettys. Of course, a real Jim Gettys is a well known X Window System contributor who is currently working at an OLPC manager. Last night someone reminded me that OLPC's new President and COO -- who I'd always just thought of as Chuck -- is named Charles Kane! Here's a short clip from a video of the fictional Charles Kane giving a rather long speech decrying the fictional Jim Gettys! (Also in Ogg.) I haven't been this amused since I learned that the head villian in the cartoon Jem was named Eric Raymond!

"Buffalo buffalo Buffalo buffalo buffalo buffalo Buffalo buffalo" is a gramatically correct sentence! See Wikipedia for an explanation.

Following the recent post about my issues with byte swapping on amd64, I have received several answers.. Since comments were broken, Rupert sent me a good explanation of the cryptic code from OSS4. Let me remember you what it was doing: The code is indeed very simple, but it has to be decomposed carefully.. First, the author assumes that unsigned char = one byte, which seems reasonable. Then, a is initialised at the second character of the two-characters value x, and b on the first of the returned (swapped) value y. Now, the two cryptic lines can be decomposed as follows: *(b++) = *(a--), which literally means "put in b the value from a, and then increase b and decrease a. When executing the second line, a points to the first character from x, and b to the second from y. As Rupert noticed, the second call could simply have been *b = *a, but this wouldn't have been l33t enough :) Now, about the original code, namely (x 8) (x >> 8), MadCoder (salut !), as well as another anonymous comment both suggested that this would be a type error. Indeed, I had noticed the wrong right shift, but no matter how I tried, with or without mask, with unsigned short, short, or uint16_t, as suggested by MadCoder, I always get the same corrupted sound.. So, thanks for your comments, I'm now trying to dig the issue down in the code that makes use of this function. Most likely the issue comes from a wrong transtyping there.. I am also wondering what's the efficiency of the above OSS4's code with regard to (x 8) (x >> 8). Any idea ? PS: Yes, text on comments are mangled a lot. This is a basic safehtml protection, and I don't have the control over it, sorry..

On August 16th 2008 the Debian Project, joy and burden of my geek life, has turned 15 years of age. Congratulations! There have been celebrations all around the world, and we've also had a little party at our home, complete with nice unhealthy food, red wine and chocolate and strawberries for dessert. For a GNU/Linux distribution 15 years is quite a lot. We're almost the only distribution of such old age (Hi Slackware!) and there've been many, many others that didn't make it half as long. That said I am quite proud of this little project of ours and hope for many happy returns! Artwork by Andre L.R.Ferreira, source: debianart.org (whose lack of thumbnails is still immensely annoying)

Caleb Case (Ubuntu contributer and Tresys employee) has written about the benefits of using separate packages for SE Linux policy modules [1]. Firstly I think it’s useful to consider some other large packages that could be split into multiple packages. The first example that springs to mind is coreutils which used to be textutils, shellutils, and fileutils. Each of those packages contained many programs and could conceivably have been split. Some of the utilities in that package are replaced for most use, for example no-one uses the cksum utility, generally md5sum and sha1sum (which are in the same package) are used instead. Also the pinky command probably isn’t even known by most users who use finger instead (apart from newer Unix users who don’t even know what finger is). So in spite of the potential benefit of splitting the package (or maintaining the previous split) it was decided that it would be easier for everyone to have a single package. The merge of the three packages was performed upstream, but there was nothing preventing the Debian package maintainer from splitting the package - apart from the inconvenience to everyone. The coreutils package in Etch takes 10M of disk space when installed, as it’s almost impossible to buy a new hard drive smaller than 80G that doesn’t seem to be a problem for most users. The second example is the X server which has separate packages for each video card. One thing to keep in mind about the X server is that the video drivers don’t change often. While it is quite possible to remove a hard drive from one machine and install it in another, or duplicate a hard drive to save the effort of a re-install (I have done both many times) they are not common operations in the life of a system. Of course when you do require such an update you need to first install the correct package (out of about 60 choices), which can be a challenge. I suspect that most Debian systems have all the video driver packages installed (along with drivers for wacom tablets and other hardware devices that might be used) as that appears to be the default. So it seems likely that a significant portion of the users have all the packages installed and therefore get no benefit from the split package. Now let’s consider the disk space use of the selinux-policy-default package - it’s 24M when installed. Of that 4.9M is in the base.pp file (the core part of the policy which is required), then there’s 848K for the X server (which is going to be loaded on all Debian systems that have X clients installed - due to an issue with /tmp/.ICE-unix labelling [2]). Then there’s 784K for the Postfix policy (which is larger than it needs to be - I’ve been planning to fix this for the past four years or so) and 696K for the SSH policy (used by almost everyone). The next largest is 592K for the Unconfined policy, the number of people who choose not to use this will be small, and as it’s enabled by default it seems impractical to provide a way of removing it. One possibility for splitting the policy is to create a separate package of modules used for the less common daemons and services, if modules for INN, Cyrus, distcc, ipsec, kerberos, ktalk, nis, PCMCIA, pcscd, RADIUS, rshd, SASL, and UUCP were in a separate package then that would reduce the installed size of the main package by 1.9M while providing no change in functionality to the majority of users. One thing to keep in mind is that each package at a minimum will have a changelog and a copyright file (residing in a separate directory under /usr/share/doc) and three files as part of the dpkg data store, each of which takes up at least one allocation unit on disk (usually 4K). So adding one extra package will add at least 24K of disk space to every system that installs it (or 32K if the package has postinst and postrm scripts). This is actually a highly optimal case, the current policy packages (selinux-policy-default and selinux-policy-mls) each take 72K of disk space for their doc directory. One of my SE Linux server sytems (randomly selected) has 23 policy modules installed, if they were in separate packages there would be a minimum of 552K of disk space used by packaging, 736K if there were postinst and postrm scripts, and as much as 2M if the doc directory for each package was similar to the current doc directories). As the system in question needs 5796K of policy modules, the 2M of overhead would make it approach 8M of disk space. So it would only be a saving of 16M over the current situation. While saving that amount of disk space is a good thing, I think that when balanced against the usability issues it’s not worth-while. Currently the SE Linux policy packages will determine what applications are installed and automatically load policy packages to match. I don’t believe that it’s possible to have a package post-inst script install other packages (and if it is possible I don’t think it’s desirable). Therefore to have separate packages would make a significant difference to the ease of use, it seems that the best way to manage it would be to have the core policy package include a script to install the other packages. Finally there’s the issue of when you recognise the need for a policy module. It’s not uncommon for me to do some work for a client while on a train, bus, or plane journey. I will grab packages needed to simulate a configuration that the client desires and then work out how to get it going correctly while on the journey. While it would not be a problem for me (I always have the SE Linux policy source and all packages on hand) I expect that many people who have similar needs might find themself a long way from net access without the policy package that they need to do their work. Sure such people could do their work in permissive mode, but that would encourage them to deploy in permissive mode too and thus defeat the goals of the SE Linux project (in terms of having wide-spread adoption). My next post on this topic will cover the issue of custom policy. Updated to note that Caleb is a contributor to Ubuntu not a developer.

• [1] http://www.calebcase.com/node/2


• [2] http://marc.info/?l=selinux&m=121789588709977&w=2

Share This

Andrew, as already mentioned in the first comment of Eddy s post you re referring to: Ganneff announced that snapshot.d.o will become an official service (ETA: some months). Reference: 20080814211643.GA12330@xanadu.blop.info

I’ve just visited the Australian Business and IT Expo (ABITE) [1]. I haven’t been to such an event for a while, but Peter Baker sent a link for a free ticket to the LUV mailing list and I was a bit bored to I attended. The event was a poor shadow on previous events that I had attended. The exhibition space was shared with an event promoting recreational activities for retirees, and an event promoting wine and gourmet food. I’m not sure why the three events were in the room, maybe they figured that IT people and senior citizens both like gourmet food and wine. The amount of space used for the computer stands was small, and there was no great crowd of delegates - when they can’t get a good crowd for Saturday afternoon it’s a bad sign for the show. I have previously blogged about the idea of putting advertising on people’s butts [2]. One company had two women working on it’s stand with the company’s name on the back of their shorts. A representative of a company in the business of Internet advertising asked me how many hits I get on my blog, I told him 2,000 unique visitors a month (according to Webalizer) which seemed to impress him. Actually it’s about 2,000 unique visitors a day. I should rsync my Webalizer stats to my EeePC so I can give detailed answers to such questions. The IT event seemed mostly aimed at managers. There were some interesting products on display, one of which was a device from TabletPC.com.au which had quite good handwriting recognition (but the vocabulary seemed limited as it couldn’t recognise a swear-word I used as a test). Generally the event was fun (including the wine and cheese tasting) and I don’t regret going. If I had paid $10 for a ticket I probably would have been less happy with it. Updated to fix the spelling of “wine”. Not a “wind tasting”.

• [1] http://australianbusinessanditexpo.com.au/


• [2] http://etbe.coker.com.au/2008/06/15/what-is-appropriate-advertising/

Share This

This keynote reports on the current state of collaboration between Debian and Ubuntu, reports back on progress made since previous DebConf's, and looks forward to new opportunities for collaboration and development.

Debian's derivatives are a powerful part of the Debian family. They bring Debian technology and, usually, Debian values to a broader audience than Debian itself will reach. At the moment, Ubuntu is the derivative with the largest reach, bringing millions of new users to GNU/Linux and Debian specifically. Ubuntu has shifted the commercial Linux landscape from one focused on RPM-based distributions to one where DEB-based distributions have much greater commercial and consumer acceptance. In this keynote, the leader of the Ubuntu project will discuss the state of current collaboration between Debian and Ubuntu developers, articulate the roadmap of Ubuntu in the coming years, and explore ways in which Ubuntu's work can improve the state of Debian.

The talk will cover:

* Current areas of collaboration
* Toolchain, Java, Python, Debian Installer,
* OpenOffice, X.org
* GNOME and KDE
* Security
* Roadmaps and transitions

* Challenges and obstacles to collaboration
* Cultural and organisational differences
* Divergent goals and priorities
* Release management and coordination

* Frameworks for collaboration
* Patch management and submission processes
* Package review, merging and delta management
* Version control interchange
* Leadership meetings and dialogue
* Bug coordination and collaboration
* Translation coordination and management

Ubuntu is only one of many derivatives - and others are achieving tremendous success in their own ways, too. The eeePC ships a derivative of Debian, and Debian is at the heart of many excellent free software solutions. The goal of this talk will be to celebrate some of those achievements and also to look for ways to make the "family" feel more cohesive. In short, to ensure that innovation which happens in derivatives has a natural pathway back to Debian. If the leaders of other derivatives are present at DebConf, this would also be an opportunity to seek comment from them, perhaps in the form of a panel for Q&A at the end of the keynote.
Full event details