Linux Kiosk

Automatic Ubuntu / Gnome lockdown scenario


This is part of an exercise to use Linux as a kiosk system. 'Kiosk System' can mean a couple of things. What's described here is howto reproduce a Ubuntu 6.06 Desktop based kiosk (with OS and Gnome desktop lockdown features) on several other computers : a way to roll out multiple identically configured kiosk systems semli-automatically.

What we do here is basically repeating the Ubuntu / Gnome lockdown described earlier, but by means of command line tools where possible, and by copying configuration files where necessary. The idea is to be able to roll out multiple replica's of the same kiosk configuration. As it happens, I haven't been able to reproduce the configuration with commands only. In order to script it, we need to copy some configuration files.

We can turn that into an advantage : we could keep 1 model kiosk (the "master"), and let other kiosks copy their configuration from it. This can even be done at regular intervals, so that we can reset the kiosks to a know state and undo whatever changes the users may have made. This is an alternative to the "deepfreeze" script that copies back a user home directory.

To be able to reproduce multiple, identical kiosks, we first install a 'textmode' basic ubuntu Linix system, then run a script that will

The Sabayon profiles are saved in etc/desktop/profiles. They can be implemented on other machines by copying (scp, wget, or any other file transfer method) them to the target system and sun /usr/bin/apply-sabayon. This has to be done while logged in as the targeted user, but we can work aropund that using su -c. That does require sabayon to be installed on the kiosks, but it can only be run by root, and we'll remove access to it from the desktop just to make sure.

Check documentation on the gnome site, Sabayon project.

Then, we use rsync to synchronise the kiosk user home directory (including gnome lockdown settings) against a model home directory on a server. We don't use a real master kiosk but a directory tree on a server, which at the same time can serve as a dhcp server, a firewall for the network, etc. This directory tree can be maintained by hand, or by rsyncing a master kiosk (eg a virtual machine ?).

This directory tree looks roughly like this :

That same server could hold a copy of the makekiosk.sh script, which you can scp to the target macgine and execute it. Removable media are, of course, also an option but I did not explore it


Script to convert a Ubuntu Dapper Drake desktop into a kiosk system

script to set up a kiosk based on a Ubuntu Dapper Drake desktop

The assumption here is that you've created a model configuration, the 'master', from which some essential files (eg the kiosk user's profile, a copy of the kiosk user's home directory, ...) to a server, from which you can copy them while setting up multiple replicas of your kiosk. On top of that, the mastercopy of the kioskuser's home can be used to synchronise the replica's against, to enforce any change in configuration you may want to roll out, and to 'deepfreeze' the kiosk user, i.e. reset the home directory to the predefined staat, no matter what changes the user(s) may have managed to implement.

To keep the desktop-profiles up to date and the home directories clean, we'll let them synchronise against model directories on a server. This can be used for an initial setup (part of the makekiosk.sh script), and for scheduled or triggered updates later (eg. to undo any changes or remove any files the user may have added to his profile, his home directory, and so on. )

This is a statement that pulls (changes in) a sabayon profile from a server:

	
	 rsync -vpogrz /etc/desktop-profiles/ root@kdunix:/srv/install/baseline/ubuntu/dirs/etc/desktop-profiles
	

This is a statement that synchronises a home directory against a model; removing files in the receiver (the kiosk) of they don't exist on the sender (the server), and setting every file in /home/... back to an exact copy of the corresponding file on the server. Note that the timestamps (-t) of the files on the server are transferred to the destination. This makes future synchronisation easier. We also use numeric ID's for ownership, so that there can be no mixups. DOn't use 'update' (-u), for this will ignore newer files on the destination; you want to undo these changes.

	
	 rsync -vpogtrz --numeric-ids --delete --force $REMOTE_STORE/home/$KIOSKUSER/ /home/$KIOSKUSER
	

Mind the trailing slashes in the src path; they avoid creation of a /dest/dest subdirectory - see the rsync man page

Just synchronising the home folder is sufficient to implement the profile. Run apply-sabayon is an alternative for offline implementation of just for good measure

This still needs some work : rsync prompts for a password, so it is not really 'unattended' until we've included a way for rsync to work without passwords (but still secure)

Usefull info :


keeping the master profile up to date

To update the master profile and configuration on the server, you can manually edit the configuration files. The changes will propagate to the replicas if you've put in place some mechanism (eg an rsync statement in a cron job, startup scripts or logon scripts).

You can also update the server by changing the configuration on a model machine, and upload or synchronise that to the files on the server.

This is a statement that sends (changes in) a sabayon profile to the directory tree from which the kiosks will get their configuration.

	
	 rsync -vpogrz /etc/desktop-profiles/ $REMOTE_STORE/dirs/etc/desktop-profiles
	

Likewise, the following statement sends (updates in) a model home directory to the server, for later use. Mind the --delete parameter : obsolete files (files that don't exist on the sender, the model, will be removed from the receiver, the server.)

	
	 rsync -vpogrz --numeric-ids --delete /home/$KIOSKUSER/ $REMOTE_STORE/dirs/home/$KIOSKUSER
	

Automatic

script

script to set up a kiosk based on a Ubuntu Dapper Drake desktop

Debian package

In stead of a script with commands to install packages, modify or replace config files, etc., we could create a debian installer package that would

Although creating a debian package is a bit more work, it provides an easy way to implement the desired configuration with a single 'apt-get install' command, and because of the versioning mechanism ing-herent to the debian installer system, we can update the configuration more easily than with a single script.



Koen Noens
July 2006

ubuntu logo gnome footprint logo linux tux Secured - Bastille Hardening Linux Questions