Ownership of the Local SE Linux Policy

August 19, 2008 | etbe

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.

Starting to Blog

August 13, 2008 | etbe

The best way to run a blog is to run your own blog server. This can mean running an instance on someone else’s web server (some ISPs have special hosting deals for bloggers on popular platforms such as WordPress), but usually means having shell access to your own server (I’ve previously written about my search for good cheap Xen hosting [1]).

There are platforms that allow you to host your own blog without any technical effort. Three popular ones are WordPress.com, LiveJournal.com, and Blogger.com. But they give you less control over your own data, particularly if you don’t use your own DNS name (blogger allows you to use their service with your own DNS name).

Currently it seems to me that WordPress is the best blog software by many metrics. It has a good feature set, a plugin interface with lots of modules available, and the code is free. The down-side is that it’s written in PHP and has the security issues that tend to be associated with large PHP applications.

Here is a good summary of the features of various blog server software [2]. One that interests me is Blojsom – a blog server written in Java [3]. The Java language was designed in a way that leads to less risk of security problems than most programming languages, as it seems unlikely that anyone will write a Blog server in Ada it seems that Java is the best option for such things. I am not planning to switch, but if I was starting from scratch I would seriously consider Blojsom.

But for your first effort at blogging it might be best to start with one of the free hosted options. You can always change later on and import the old posts into your new blog. If you end up not blogging seriously then using one of the free hosted services saves you the effort of ongoing maintenance.

Lenny SE Linux on the Desktop

August 4, 2008 | etbe

I have been asked about the current status of Lenny SE Linux on the Desktop.

The first thing to consider is the combinations of policies and configurations. I will number them if only for the purpose of this post, if the numbering is considered generally helpful it could be more widely adopted to describe configurations.

Default configuration. This has the default policy and is configured with all users having the domain unconfined_t and daemons such as POP servers are allowed to access home directories of type unconfined_home_dir_t. This allows such daemons to attack privileged user accounts.
Some restricted users. This is the same as above but with some users restricted. Daemons such as POP servers are only allowed to access the home directories of restricted users. This means that if a user is to have an unconfined account and receive email they must have two Unix accounts or receive their mail under /var/spool/mail. This is one setsebool command and one (or maybe a few) “semanage login -m” commands from the default configuration.
All users restricted. The system administrator has the domain sysadm_t and users have domains such as user_t. This requires a few more semanage commands. It is equivalent to the old strict policy.
MLS. This is anything that is based around the MLS policy.

Currently I have two Desktop machines running Lenny (a test machine and my EeePC) and one server. I have only just switched my test machine to enforcing mode so have no good data on it (apart from the fact that I can boot it up and login – which is always a good start). The server is running in permissive mode because I have not yet written the policy to allow the POP server to read from unconfined_home_dir_t. I could get it working by switching from level 1 to level 2 or 3, but I want to get level 1 server policy working for the benefit of others else first.

My EeePC however is fully functional, I have been doing some work on it – that mostly means running a ssh client under GNOME but that’s OK (desktop environments such as GNOME and KDE are quite complex and demanding, getting a machine to boot and run such a desktop environment tests out many parts of the system). It’s only at level 1 for the moment because I want to get level 1 working everywhere before moving to the higher levels. I want to get things ready for real users ASAP. With the way the policy is managed now it will be possible to move from level 1 to 2 or 3 without rebooting or interrupting running services. So once users have systems running well at level 1 they can easily increase the security at a later date.

The problems that I have had are due to text relocations in libraries (see my previous post about execmod permission [1]). I’ve filed bug report #493678 against libtheora0 [2] in regard to this issue and included a patch from Fedora (which disables the non-relocatable assembly code in question). It seems that upstream have some new assembler code to try and fix this issue, so hopefully we’ll have something that can make it into Lenny!

I’ve filed bug report #493705 against libswscale0 for the same issue [3]. I included a patch to turn off the assembler code in question but that was not well received. If anyone has some i386 assembler skill and some spare time I would appreciate it if you could try and find a way to make the code position independent while losing little or no performance.

One thing to note is that I am now using an Opteron 1212 (2.0GHz dual-core) system for compiling, I run the i386 DomU with a 64bit kernel (I expect that 32bit user-space runs faster with a 64bit kernel than a 32bit kernel), and the disks are reasonably fast. Even so it takes about 15 minutes to build libswscale0 and the other packages from the same source tree. Previously I was using a 1.0GHz Pentium-3 for my Lenny i386 development until I had the libswscale0 build process go for more than 90 minutes before running out of disk space! If your build machine is old enough to only be 32bit then you should probably plan on watching a movie or going to bed while the build is in progress.

I have built packages that work around the above bugs and included them in my Lenny repository [4]. If you take the packages from that repository plus the Lenny packages then you should have a functional desktop system at level 1. I would appreciate it if people would start testing that and providing feedback. One important issue is the discovery of libraries that want shared stacks, text relocations, and executable memory. The deadline for fixing them properly is even more of a problem due to the number of people who have to be involved in a solution (as compared to the policy where I can do it on my own).

One finally problem is a bug in xdm which causes it to give the wrong context for login sessions due to having an old version of the SE Linux related code [5]. Due to a combination of this and some policy bugs you can not login with xdm. This is not a hugely important issue as most people will use gdm (which has the newer patch) or kdm (which has no SE Linux patch but can use pam_selinux.so). Also another option is wdm which works with pam_selinux.so. I’ve had a response to my bug report suggesting that there’s a bug in the patch (which was taken from gdm so maybe there’s a bug in gdm code too). I haven’t responded to that yet as I’ve been concentrating on the things that will make the most impact for Lenny.

At this stage I’m still unsure of when the release team will cut me off and prevent further SE Linux related fixes from going in Lenny. I need at least one more update to the policy packages before Lenny is released. I could release one right now with some useful improvements over what is currently in unstable, but am waiting until I get some other things fixed.

If I get everything fully working at level 1 (both client and server) before Lenny then I will provide a similar status report for users and testers of levels 2 and 3. I don’t expect that I will even get a chance to test level 4 (MLS) properly before Lenny releases.

selinux-activate

August 1, 2008 | etbe

I have written a script for Debian named selinux-activate which is included in selinux-basics version 0.3.3+nmu1 (which I have uploaded to Debian/Unstable). The script when run with no parameters will change the GRUB configuration to include selinux=1 on the kernel command-line and enable SE Linux support in the PAM modules for login, gdm, and kdm. One issue with this is that if you run the command before installing kdm or gdm then you won’t have the pam configuration changed – but as it’s OK to run the script multiple times this shouldn’t be a problem.

The new selinux-basics package will also force a reboot after relabelling all filesystems. I had tested “umount -a ; reboot -f” but discovered that “reboot -f” causes filesystem corruption in some situations (my EeePC running an encrypted LVM volume on an SD card had this problem). So I now use a regular “reboot“.

If no-one points out any serious flaws I plan to ask the release team to include this version of selinux-basics in Lenny. I believe that it will make it significantly easier to install SE Linux while also reducing the incidence of systems being damaged due to mistakes. If you edit the GRUB configuration file by hand then there is a risk of a typo making a system unbootable.

The package in question is already in my Lenny repository, see my previous post about Lenny SE Linux for details [1].

[1] http://etbe.coker.com.au/2008/07/31/installing-se-linux-on-lenny/

Installing SE Linux on Lenny

July 31, 2008 | etbe

Currently Debian/Lenny contains all packages needed to run SE Linux apart from the policy. The policy package is missing because it needs to sit in unstable for a while before migrating to testing (Lenny), and I keep fixing bugs and uploading new versions.

I have set up my own APT repository for SE Linux packages (as I did for Etch [1]). The difference is that it’s working now (for i386 and AMD64) while I released my Etch repository some time after the release of Etch.

gpg --keyserver hkp://subkeys.pgp.net --recv-key F5C75256
gpg -a --export F5C75256 | apt-key add –

To enable the use of my repository you must first run the above two commands to retrieve and install my GPG key (take appropriate measures to verify that you have the correct key).

deb http://www.coker.com.au lenny selinux

Then add the above line to /etc/apt/sources.list and run “apt-get update” to download the list of packages.

Next run the command “apt-get install selinux-policy-default selinux-basics” to install all the necessary packages and then “touch /.autorelabel” to cause the filesystems to be labeled on the next boot. Edit the file /boot/grub/menu.lst and add “selinux=1” to the end of the line which starts with “# kopt=” and then run the command update-grub to apply this change.

Then reboot and the filesystems will be relabeled. Init will be running in the wrong context so you have to reboot again before everything is running correctly (I am thinking of having the autorelabel process automatically do the second reboot).

For future reference please use the page on my documents blog – I will update it regularly as needed [2]. This post will not be changed when it becomes outdated in a few days.

Review of the EeePC 701

July 21, 2008 | etbe

I have just bought a EeePC 701 [1], I chose the old model because it’s significantly smaller than the 90x series and a bit lighter too and it had Linux pre-loaded. Also it was going cheap, while I am not paying for it I give the same attention to saving my clients’ money as to saving my own. I ruled out everything that was heavier or larger than an EeePC 901 and everything that cost more than $700. That left only the Linux version of the EeePC 901 (which I couldn’t find on sale) and the EeePC 701 as my options. I also excluded the EeePC 900 because it is bigger and heavier than the 701 but has the same CPU (and therefore can’t run Xen).

In terms of it’s prime purpose (a SSH client) 96*22 characters is the size of a konsole screen with the default (medium) font size when the window is maximised, that is 5% more characters than the standard terminal size of 80*25 but the smaller number of lines is a problem. When using the small font I can get 129*29 which I find quite comfortable to read (it would be impossible for me to read withut glasses – which means having almost average vision for someone in their 30’s). Then I can get 129*31 if I dismiss the tool bar at the bottom of the screen and could probably get another couple of rows if I removed the tabs that Konsole uses to switch between sessions. That would only be viable if using screen extensively as a single session without the ability to switch between programs is not particularly useful (I don’t think that ALT-TAB is adequate for switching between terminal sessions). When running Debian I can get 130*32 with the same font due to smaller window controls, but I’ll write more about converting to Debian in another post. Note that while the OS that ships with the Linux based EeePC machines is based on Debian, it is heavily customised and has some notable differences from a typical Debian install. It has some proprietary software, and uses unionfs for the root and /home filesystems.

The first issue is that Console (the KDE terminal program) can only be accessed from the file manager (via the tools menu or ^t), the machine clearly doesn’t have defaults for someone like me. In principle it’s a multi-user system that can be fully customised, but in practice it’s configured as a single-user machine. Once you have a Console window open you can run “su -” and the root password is the password for the “user” account.

I wonder whether I could get more than 42 rows or more than 140 columns of text that is readable. If so then I could have two console windows fully displayed on screen.

The screen is bright and clear, this is essential as the number of pixels per character is going to be low for any reasonable amount of text to be displayed on screen.

The password that you set when you first use the machine also works for “su -” (in fact that is the only real use as I expect that almost everyone will choose the automatic login option).

The display comprises a significant portion of the weight, if the screen is fully open (about 150 degrees) then it will tip over. Even when the screen is not as far open it will tip due to bumps if resting on your lap on a tram. It’s a pity that the screen is connected at the very back of the base, if the attachment point was a bit closer then it would balance better and also be easy to hold with one hand. The depth of the machine combined with the angle at the back makes it impossible for me to get a good one-handed grip from the base, so typing while standing on a moving tram or bus will be extremely difficult (unlike my iPaQ which I can use at full speed on any form of public transport). Inidentally it would be good if there was an attachment point for a wrist-strap, every camera and most mobile phones have them so it would be good to have the same safety feature in a laptop to facilitate use on public transport. Another reason for not using it as a PDA is the fact that it takes about 7 seconds to resume after hibernating (when the lid is closed).

The PSU is almost as small as that of a mobile phone! This is a major benefit as in the past I have often stored a Thinkpad PSU at a client site for 9-5 jobs as it is heavy enough that I didn’t want to carry it on public transport. The EeePC PSU is light enough that it won’t be unpleasant to carry, and small enough to fit easily into a jacket pocket.

The OS installation is very well done for the basics. It’s easy to launch applications and there is a good selection of educational programs (including the periodic table, planetarium, typing, letters, and hangman, drawing, and a link to www.skoool.com). It’s a pity that they organised the folders according to the area rather than the age, but generally the OS is very well done. Most of the reviews focus on the speed of the CPU, the RAM expansion options, etc, but miss the fact that it is a really nice machine for using as-is.

It is a much better machine for teaching children than any of the machines I’ve seen which are sold specifically for children (see my previous post about an awful computer for kids [2]). I believe that you could give an EeePC to any 3yo and have them doing something useful in a matter of minutes! The ability to freely install new software should not be overlooked when considering a computer for children to use. Someone who buys one now could use it for a few years as an ssh client and then reinstall the original OS and give it to a child as an educational toy.

It has a program to create OGG video files from it’s built-in camera and mic, at this moment it’s the only device I own that can create OGG files (this is a good thing). OGG compression takes a really long time, the Atom CPU in the 901 and 1000x series would be good for this. It’s a pity that the microphone is directly below the mouse buttons, it clearly records the mouse click used to finish recording. The version of mplayer which is installed to play OGG files can also play FLV files downloaded from youtube with youtube-dl (althrough the file association is not set). When I tried to play a MP4 file from ted.com it only gave audio (the video works on a full Debian/Etch installation).

There is a full set of office software, OpenOffice.org, Thunderbird email client, and all the other stuff you might expect.

I find that the biggest problem for using it is the size of the keyboard, I don’t think I’ll ever be able to touch-type properly on it. Not only are the keys small but the positions of non-alphabetical keys are slightly different from most keyboards. Another problem is that the space-bar needs to be pressed near the centre, I usually like to press near the end but that doesn’t work. Those issues are all trade-offs of the small size. My T series Thinkpad is reasonably portable and has a great keyboard so I have the serious typing while travelling angle covered.

One real mistake in the keyboard design is the lack of a LED to indicate whether caps-lock is enabled (there are four status LEDs, adding number five couldn’t be that expensive), this is a real problem when using the vi editor (which uses letters as editor commands and is case-sensitive). It will also occasionally cause problems when entering passwords. There is a caps-lock indicator on screen, but that is in the toolbar at the bottom of the scren (which I like to dismiss to gain an extra two lines of text). It would be good if I could display the status of the caps and num lock keys in the right side of the title-bar of the active window (the only bit of unused space on the screen).

The cooling fan makes an annoying buzz. It’s significantly louder than Thinkpads which dissipate a lot more heat.

The other problems are all software, which is OK as I plan to reinstall it. Firstly it is using Debian and shipped with the broken openssl library. There is a GUI for installing upgrades, but it recommends rebooting after installing each one! Naturally I didn’t choose to reboot, I installed the security update #1.

Then I clicked on the button to install a BIOS update. It told me that it had to reboot to apply the update and gave only one button (OK), I tried closing the window but it rebooted anyway (fortunately the vi swap file allowed me to recover this post – which I am entirely writing on the EeePC).

Aftere booting up again I discovered that the libssl bug still wasn’t fixed and that there was a second udate to apply! Why can’t they have a “apply all updates” button and also have it not automatically reboot? This must be the only Debian-based distribution that forces Windows-style reboots.

But that said, while they made some mistakes in their software it generally provides a good user experience

Xen and EeePC

July 16, 2008 | etbe

I’ve been considering the possibility of using Xen on an ASUS EeePC as a mobile test platform for an Internet service. While the real service uses some heavy hardware it seems that a small laptop could simulate it when running with a small data set (only a few dozen accounts) and everything tuned for small amounts of RAM (small buffers for database servers etc).

According to the wikipedia page about the EeePC [1] the 70x and 900 versions of the EeePC use a Celeron-M CPU. According to Wikipedia that is based on the Pentium-M (which lacks PAE support and therefore can’t run Xen).

The Fedora Tutorial about the EeePC has a copy of the /proc/cpuinfo data from an EeePC [2] which shows that the model in question (which is not specified) lacks PAE. Are there any 70x or 90x variants that have PAE? Intel sometimes dramatically varies the features within a range of CPUs…

The 901 version and the 1000 series use an Intel “Atom” CPU. According to discussion on the Gentoo Forums some Atom CPUs have the “lm” flag (64bit) but no “vmx” flag for virtualisation [3] (which means that they can run Xen paravirtualised but no KVM or hardware virtualisation for Xen), it also has PAE. This is more than adequate.

According to the Wikipedia page the Atom comes in both 32bit and 64bit variants [4]. Hopefully the 901 version and the 1000 series EeePC will have the 64bit version.

The 90x versions have support for up to 4G of RAM but the 1000 series is only listed as supporting 2G, hopefully that will be 4G or more (although I wouldn’t be surprised if Intel had a chipset supporting only 4G of address space and PCI reservations limiting the machine to 3G). But even 3G will be enough for a mobile test/development platform which should make it easier to debug some problems remotely.

The 901 is available in Australia for just under $700. It’s a little more expensive than previous EeePC variants ($500 is a magic number below which things can be purchased with significantly less consideration), but it still might be something that one of my clients will pay for.

The prime aim is to be a mobile sys-admin platform that can be carried anywhere, running a Xen simulation of the target network is an added bonus.

Any suggestions for other laptops that should be considered will be welcome. It needs to be light (1.14Kg for a 901 EeePC is more than I desire), small (a reduced display size is not a problem), and not overly expensive ($700 is more than desired).

Update: JB HiFi is selling the 1000H model [5]. The 1000H has an 80G hard disk and weighs 1.45Kg. The extra 210g and slightly larger size are a down-side, as is the extra ~$50 in price.

A comment was made that OpenVZ could be used. If that avoids the need for PAE then a 702 series would do the job (with some USB flash devices as extras). The 702 is a mere 920g.

Update: This ZDNET review shows that the 901 can only handle 2G of RAM and has an Atom CPU that is only 32bit [6].

Mobile SSH Client

July 16, 2008 | etbe

There has been a lot of fuss recently about the release of the iPhone [1] in Australia. But I have not been impressed.

I read an interesting post Why I don’t want an iPhone [2] which summarises some of the issues of it not being an open platform (and not having SSH client support). Given all the fuss about iPhones (which have just arrived in Australia) I had been thinking of writing my own post about this, but TK covered most of the issues that matter to me. One other thing I have to mention is the fact that I want a more fully powered PC with me. So even if I had a Green Phone (which doesn’t seem to be on general sale) [3] or OpenMoko [4] I would still want at least a PDA running Familiar and preferrably a laptop – I often carry both. A Nokia N8x0 series Internet Tablet [4] would satisfy my PDA needs (and also remove the need to carry an MP3/MP4 player and audio recorder).

When doing serious travelling I carry a laptop, a PDA, and a MP3 player all areas of my digital needs are covered better than an iPhone could reasonably manage. Finally mobile phones tend to not work or not work well ($1 per minute calls is part of my definition of “not well”) in other countries. While I haven’t been doing a lot of traveling recently I still try to avoid buying things that won’t work in other countries.

I had planned to just mention TK’s post in a links post. But then a client offered to buy me an iPhone. He wants me to be able to carry a ssh client with me most places that I go so that whenever his systems break I can login. Now apart from the lack of ssh client support an iPhone seems ideal. :-#

The cheapest Optus iPhone plan seems to be $19 per month for calls and data (which includes 100M of data) and $21 per month over 24 months for the iPhone thus giving a cost of $40 per month for 100M of data transfer (and a nice phone). There is a plan ofr a $19 per month iPhone, but that has a $19 per month un-capped phone plan and doesn’t sound like a good way of saving $2 per month. The “Three” phone company offers USB 3G modems for $5 per month (on a 24 month contract) and their cheapest plan is $15 per month which gives you 1GB of data per month and $0.10/M for additional data transfer. So it’s $20 per month for 1G (which requires a laptop) vs $40 per month for 100M.

Three also has a range of phone plans that allow 3G data access over bluetooth to a PC, it seems that a Nokia N8x0 tablet can be used with that which gives a result of two devices the size of mobile phones. But that costs $20 per month (on top of a regular Three bill) for a plan that offers 500M of data and still requires two devices while not giving the full PC benefits.

In the past I’ve done a lot of support work with a Nokia Communicator, so I’ve found that anything less than a regular keyboard really slows things down. While a EeePC keyboard is not nearly as good as a full sized keyboard it is significantly better than a touch-screen keyboard on a PDA (IE the Nokia N8x0 or the OpenMoko).

At the moment I’m looking at the option of carrying an EeePC with a USB Internet access device. That will cost $20 per month for net access. The cost of the EeePC is around $300 for a low-end model or about $650 for a 901 series that can run Xen (as noted in my previous post I’m considering the possibilities for having a mobile Xen simulation of a production network [5]). The savings of $20 per month over 24 months will entirely cover the cost of a low-end EeePC (ssh terminal, web browsing, and local storage of documentation) and cover most of the cost of a high-end EeePC. Another possibility to consider is using an old Toshiba Satellite I have hanging around (which I used to use as a mobile SE Linux demonstration machine) for a few months while the price on the EeePC 901 drops (as soon as the 70x series is entirely sold out and the 1000 series is available I expect that the 901 will get a lot cheaper).

Label vs UUID vs Device

July 8, 2008 | etbe

Someone asked on a mailing list about the issues related to whether to use a label, UUID, or device name for /etc/fstab.

The first thing to consider is where the names come from. The UUID is assigned automatically by mkfs or mkswap, so you have to discover it after the filesystem or swap space has been made (or note it during the mkfs/mkswap process). For the ext2/3 filesystems the command “tune2fs -l DEVICE” will display the UUID and label (strangely mke2fs uses the term “label” while the output of tune2fs uses the term “volume name“). For a swap space I don’t know of any tool that can extract the UUID and name. On Debian (Etch and Unstable) the file command does not display the UUID for swap spaces or ext2/3 filesystems and does not display the label for ext2/3 filesystems. After I complete this blog post I will file a bug report.

If you are using a version of Debian earlier than Lenny (or a version of Unstable with this bug fixed) then you will be able to easily determine the label and UUID of a filesystem or swap space. Other than that the inconvenience of determining the UUID and label will be a reason for not using them in /etc/fstab (keep in mind that sys-admin work sometimes needs to be done at 3AM).

One problem with mounting by UUID or label is that it doesn’t work well with snapshots and block device backups. If you have a live filesystem on /dev/sdc and an image from a backup on /dev/sdd then there is a lot of potential for excitement when mounting by UUID or label. Snapshots can be made by a volume manager (such as LVM), a SAN, or an iSCSI server.

Another problem is that if a file-based backup is made (IE tar or cpio) then you lose the UUID and label. tune2fs allows setting the UUID, but that seems like a potential recipe for disaster. So this means that if mounting by UUID then you would potentially need to change /etc/fstab after doing a full filesystem restore from a file-based backup, this is not impossible but might not be what you desire. Setting the label is not difficult, but it may be inconvenient.

When using old-style IDE disks the device names were of the form /dev/hda for the first disk on the first controller (cable) and /dev/hdd for the second disk on the second controller. This was quite unambiguous, adding an extra disk was never going to change the naming.

With SCSI disks the naming issue has always been more complex, and which device gets the name /dev/sda was determined by the order in which the SCSI HAs were discovered. So if a SCSI HA which had no disks attached suddenly had a disk installed then the naming of all the other disks would change on the next boot! To make things more exciting Fedora 9 is using the same naming scheme for IDE devices as for SCSI devices, I expect that other distributions will follow soon and then even with IDE disks permanent names will not be available.

In this situation the use of UUIDs or LABELS is required for the use of partitions. However a common trend is towards using LVM for all storage, in this case LVM manages labels and UUIDs internally (with some excitement if you do a block device backup of an LVM PV). So LV names such as /dev/vg0/root then become persistent and there is no need for mounting via UUID or label.

The most difficult problem then becomes the situation where a FC SAN has the ability to create snapshots and make them visible to the same machine. UUID or label based mounting won’t work unless you can change them when creating the snapshot (which is not impossible but is rather difficult when you use a Windows GUI to create snapshots on a FC SAN for use by Linux systems). I have had some interesting challenges with this in the past when using a FC based SAN with Linux blade servers, and I never devised a good solution.

When using iSCSI I expect that it would be possible to force an association between SCSI disk naming and names on the server, but I’ve never had time to test it out.

Update: I have submitted Debian bug #489865 with a suggested change to the magic database.

Below are /etc/magic entries for displaying the UUID and label on swap spaces and ext2/3 filesystems:

Continue reading →

Awful Computers for Kids

July 7, 2008 | etbe

I have just observed demonstration units of the V-Smile system [1]. They have “educational games” aimed at ages 3-5, 4-7, and some similar ranges. The first thing I noticed was that children who were able to correctly play the games were a lot older than the designated ages. For example 10yo children were playing the Scooby-Doo addition game (supposedly teaching children to add single-digit numbers) and apparently finding the non-addition part of the game challenging (I tried it myself and found catching flying hamburgers while dodging birds to be challenging enough that it was difficult to find numbers). For children who were in the suggested age-range (and a suitable age for learning the basic lessons contained in the games) the only ones who actually managed to achieve the goals were the ones who were heavily directed by their father. So my observation is that the games will either be used by children who are too old for the basic lessons or be entirely directed by parents (I didn’t observe any mother giving the amount of assistance necessary for a 5yo to complete the games but assume that it happens sometimes).

I doubt that there are many children who have the coordination needed for a platform game who have not yet learned to recognise printed letters (as supposedly taught in the Winnie the Pooh game). The Thomas the Tank Engine spelling game had a UI that was strange to say the least (using a joystick not to indicate which direction to go but instead to move a cursor between possible tracks) and I doubt that it does any good at teaching letter recognition. There was also a game that involved using a stylus for tracing the outline of a letter, as I had great difficulty in doing this (due to the poor interface and the low resolution of the touch-pad) it seems very unlikely that a young child who is just learning to write letters would gain anything from it. Strangely there was a game that involved using the touch-pad to indicate matching colors. Recognising matching colors is even easier than recognising letters and I don’t think that a child who can’t recognise the colors would be able to manage the touch-pad.

The V-Smile system seems to primarily consist of a console designed for connection to a TV but also has hand-held units that take the same cartridges. The same company produces “laptops” which sell for $50 and have a very low resolution screen and only the most basic functionality (and presumably other useless games).

Sometimes the old-fashioned methods are best. It seems that crayons are among the best tools for teaching letter recognition and writing.

But if there is a desire to use a computer for teaching, then a regular PC or laptop should do. Letter recognition can be taught by reading the text menus needed to launch games. The variety of computer poker games can be used for recognising matching colors and numbers as can the Mahjong series of games. Counting can be taught through the patience games, and the GIMP can be used for teaching computer graphics and general control of the mouse and the GUI. NB I’m not advocating that all education be done on a computer, merely noting the fact that it can be done better with free software on an open platform than on the proprietary systems which are supposedly designed for education.

Finally with a PC children can take it apart! I believe that an important part of learning comes from disassembling and re-building toys. While it’s obvious that a PC is not going to compare with a Lego set, I think it’s good for children (and adults) to know that a computer is not a magic box, it’s a machine that they can understand (to a limited extent) and which is comprised of a number of parts that they could also understand if they wanted to learn the details. This idea is advocated by Gever Tulley advocates such disassembly of household items in his TED talk “5 dangerous things you should let your kids do” [2]. Gever runs The Tinkering School [3] which teaches young children how to make and break things.

Finally I just checked some auction sites and noticed that I can get reasonably new second-hand laptops for less than $300. A laptop for $250 running Linux should not be much more expensive than a proprietary laptop that starts at $50 once you include the price of all the extra games. For an older laptop (P3) the price is as low as $100 on an auction with an hour to go. Then of course for really cheap laptops you would buy from a company that is getting new machines for their staff. It’s not uncommon for companies to sell old laptops to employees for $50 each. At a recent LUG meeting I gave away a Thinkpad with a 233MHz Pentium-MMX CPU, 96M of RAM, and a 800*600 color display – by most objective criteria such a machine would be much more capable than one of those kids computers (either V-Smile or a competitor).

Of course the OLPC [4] is the ideal solution to such problems. It’s a pity that they are not generally available. I have previously written about the planned design for future OLPC machines [5] which makes it a desirable machine for my own personal use.

etbe – Russell Coker

Linux, politics, and other interesting things

Tag Archives: Most Popular