Back around 2006 our public library was in need of a cheap way for patrons to browse its web-based INNOPAC catalog. Thin clients running Windows CE had been purchased for this purpose, but they turned out to be buggy and limited. I was tasked with finding a solution to the problem “on the cheap”, and being a fairly new Linux fanatic at the time, I figured I’d see what I could do using free software. This led to my first kiosk project.<\/p>\n
Since then, I’ve refined my approach time and again, deploying kiosks throughout my organization just about anywhere a web-browser kiosk can be put to use. The original library system has been completely rebuilt with newer hardware and software, but is fundamentally the same system I set up five years ago.<\/p>\n
I often see people asking about how to set up a kiosk system with Linux, and like me they usually start out going about it the wrong way; so I thought I’d write this tutorial based on my years of experience to help those getting started.<\/p>\n
<\/p>\n
Most people start working on a kiosk with the idea of taking some standard Linux desktop (like Unity or KDE) and trying to “lock it down” so users can only run a browser. I tried this too, originally (at the time, KDE 3 had a kiosk tool that let you set policies for all its 18 bajillion components); but I quickly found that locking down a fully-featured desktop environment was a pedantic, exhausting task that never ended satisfactorily. It occurred to me that I might have more luck building an environment from scratch with only<\/em> the components required.<\/p>\n That isn’t nearly as hard as you’d think. To understand how it works, let’s look at how a typical X11 desktop system functions:<\/p>\n The key here is understanding that the session script (or program) is nothing magical. It’s just an executable that the display manager runs when you log in, and when it finishes you log out. In fact, there is a very simple mechanism to override the X session and create our own customized version. When a user logs in, if the ~\/.xsession or ~\/.xinitrc file is present and executable it will (usually, depending on the display manager) be executed instead of the default session.<\/p>\n Now, I’ve said that there’s nothing magical about the session script; but those who haven’t done much tinkering with X11 desktops might be surprised to find that many of the behaviors you take for granted on a graphical desktop don’t “just happen” — they require software to make them happen. For instance, you might assume that program windows are automatically movable about the screen, are re-sizable, or have title-bars across the top with (at least) maximize, minimize, and close buttons. None of this is provided by X11, though; it’s provided by a program called the window manager<\/em>. You might also assume that graphical environments all have menus, desktop icons, or panels; again, these are provided by other programs which must be run either by the session script or one of the programs it starts.<\/p>\n Choosing the right components to launch in a session script can be subtly tricky depending on the software you need to run, the behavior you expect from it, and the need for tight security on the system. Fortunately, when it comes to desktop components the Linux world offers a lot of options, and with some persistence and a willingness to tinker you can nearly always get what you need. At the end, we’ll go through some “crash test” questions to see if your setup is really bullet-proof and ready for the road.<\/p>\n But first, let’s walk through setting up an actual kiosk.<\/p>\n<\/div>\n In this tutorial, I’ll walk through how I set up a kiosk for use at my workplace, and why I choose the different components that I do.<\/p>\n The first task is to get a basic OS install. You can do this with about any distribution of Linux you feel comfortable with, but I’d recommend taking the following aspects into consideration:<\/p>\n Based on these criteria, I’ve found Debian Stable to be a prime choice over the years. Ubuntu can also work well if you stick to LTS releases and use the minimal install media. Centos might be a third choice, though it doesn’t have as much software readily available.<\/p>\n Once you’ve picked one, install a basic, command-line installation. The Debian installation manual can be found here<\/a>.<\/p>\n<\/div>\n Once you have the basic install, we need to get a few software components on there:<\/p>\n Use aptitude<\/strong> on Debian to find and install these packages. Dependencies will, of course, be handled automatically. You might want to add the “–without-recommends” switch when installing gdm, so that you don’t pull in a lot of unnecessary GNOME packages. Also, if you prefer to do your administration parts in a GUI, you can of course install a minimal desktop like LXDE or just a simple window manager like jwm. Be aware that any other environment you install is going to show up on your login screen as a session option, so depending on the deployment situation that might be a problem.<\/p>\n We’re using Chromium here as an example kiosk application, though if you have a custom application or prefer a different web browser substitute that instead. I originally used Firefox for these, but unfortunately Firefox has become increasingly unsuited for kiosk work since version 2 (I actually ended up writing my own browser<\/a> in python, but I’m assuming you’re not that deep into this yet).<\/p>\n I chose matchbox-window-manager here because it’s simple and stays out of the way. In the past, I’ve used flwm<\/strong>, ion<\/strong>, openbox<\/strong>, or xfwm<\/strong>. I ended up switching to matchbox because it does pretty much what you want on a kiosk without any configuration.<\/p>\n<\/div>\n If you’re logged in as root at this point, make sure you’ve made a second account for administration purposes — you really don’t want to be ssh’ing around as root, it’s bad practice. You also need to make the account which the kiosk will run under; I usually just call this “kiosk”, though feel free to call it whatever seems natural to you.<\/p>\n In Debian, the “adduser” command will step you through setting up a new user account. Try “adduser kiosk” and follow the prompts.<\/p>\n<\/div>\n Time for the most important part: writing the session script. First, run these commands as root:<\/p>\n What these commands do is copy the kiosk user’s home directory to \/opt, move there, make the directory world-readable, and then create an empty but executable .xinitrc file (see note at the end of the section about .xinitrc vs .xsession). You want \/opt\/kiosk to be readable<\/em> by the kiosk user, but not writable<\/em>.<\/p>\n Now open the .xinitrc file in a text editor and copy in this text:<\/p>\n This is our session script; it’s what will be run when the kiosk user is logged in, so let’s go through it one line at a time.<\/p>\n The “xset” lines take care of an important detail: disabling screen blanking and monitor power saving. You might not want this, but most users approaching a kiosk with a black screen tend to assume it’s out of order.<\/p>\n Next, we launch our window manager, matchbox-window-manager. Note the ampersand here: without it, matchbox would be run and nothing else would happen, because the script would be waiting on matchbox to end before running the next commands. You do need one<\/em> part of the script to run indefinitely, because once the script ends the user is logged out; but you want only one<\/em> part of the script to do this. The ampersand forks matchbox’s execution to the background and continues down the script.<\/p>\n The “while true; do” line starts an infinite loop, which is later closed by the “done” line. There’s really no way out of this script other than to kill the whole display or reboot the system, and that’s what we want.<\/p>\n The “rsync” command bears some explanation. Rsync is a special copy command that, by default, only copies files that are different between the source and destination. The switches and arguments do the following:<\/p>\n Every time the rsync runs, the kiosk user will get a completely fresh home directory; this will reset anything a previous user might have tinkered with. Since it’s in an infinite loop with the actual kiosk application, resetting everything is as simple as closing the application.<\/p>\n Finally, we run our kiosk application. I’m using chromium-browser with the “–app” switch to put it in kiosk mode (replace the URL with one of your choosing). You can, of course, run any application here, but note that it’s critical the application not<\/em> fork into the background when run. Some applications (OpenOffice, for one) fork when run, and return control to the command line. If your application does this, you’ll end up with a few hundred copies before the system runs out of memory and dies. You’ll have to work out how to “block” the session some other way if your application is like this.<\/p>\n Once this file is saved, copy it to \/home\/kiosk. Reboot the system, and log in to GDM as the kiosk user. Ta-dah! You should be looking at a full-screen chromium with whatever URL you specified.<\/p>\n NOTE: as one reader discovered, apparently newer versions of GDM in Ubuntu\u00a0<\/em>don’t recognize “~\/.xinitrc”, but\u00a0do<\/strong> recognize “~\/.xsession”. \u00a0If you’re having trouble with GDM recognizing your session script, rename it to “.xsession”.<\/p>\n<\/div>\n Already this is a pretty secure setup that will keep the vast majority of people from doing anything destructive, but there are a few more things we might want to do depending on where you’re deploying the kiosk and what you think people might do (for space reasons, I can’t detail all these, but I’ll tell you where to find information):<\/p>\n Not all of these are strictly necessary, but as the voice of experience let me advise you not to underestimate the public’s ability to cause mischief on an unsecured computer!<\/p>\n<\/div>\n At this point your system is workable and secure, but depending on the situation there are some optional features we might want to add.<\/p>\n If you want the system to be a “turnkey” style system that doesn’t require login, configure GDM for auto-login. You just need to edit \/etc\/gdm\/gdm.conf, and add the following under the “[daemon]” section:<\/p>\n So your kiosk user is looking up information about an embarrassing rash, then gets a phone call and has to step away. You don’t want the next person walking up to see information about embarrassing rashes. You also want to protect your users by removing web history between users when possible.<\/p>\n In my own kiosks, I built a timer into the application<\/a> to wipe the history and return to the home page after so many minutes of inactivity. With the chromium-browser kiosk, you don’t have that option. But you can get it with a little help from xautolock<\/em>.<\/p>\n Xautolock is a utility that monitors the session for inactivity, and locks the screen after so many minutes. It doesn’t actually have to<\/em> lock the screen, though; you can tell it to run any command you want after the inactivity period has timed out.<\/p>\n Looking at our session script, all we need to do to reset the whole thing is close chromium. So the solution is simple:<\/p>\n This runs xautolock in secure mode (so it can’t be turned off), sets the inactivity timeout to 15 minutes, and runs your chromium-killing script when the timeout hits.<\/p>\n<\/div>\n Chances are, you don’t want to mess with keeping these systems up-to-date manually, and you certainly can’t expect users to launch an updater for you! So, this is the simple way to set up automatic updates on your Debian system (I wouldn’t recommend doing auto-updates on a distro that’s prone to major changes, or you might have a broken kiosk on your hands!).<\/p>\n If you have the capability to relay mail from your systems, you can configure cron-apt to email you when it upgrades or has a problem upgrading, but I’ll leave that for your homework.<\/p>\n<\/div>\n If you want your users to be able to print, you’ll need to install cups<\/strong>. Mercifully, cups comes with its own web-based configuration utility, so if you’re a little tired of hacking config files, rejoice! After installing cups, point the web browser to “http:\/\/localhost:631<\/a>” to configure printing.<\/p>\n<\/div>\n<\/div>\n Now that your system is set up, test it extensively. If possible, have some other people try to mess it up. Here is a list of some non-obvious things to try:<\/p>\n Obviously, your need for security and bullet-proof operation may vary depending on where and how you intend to deploy this system; but spend some time trying to think like a hoodlum with Unix experience, and see what you can do to secure the system against tampering.<\/p>\n<\/div>\n This is just the start of what you can do with Linux and kiosk setups. Now that you understand how to use the .xinitrc, the sky’s the limit! If you’ve created Linux kiosks, or if you’re unsure how to solve a particular problem you’re having, leave a comment and tell me all about it.\n<\/p><\/div>\n This article has proven to be somewhat popular as a resource for setting up Kiosk systems on Linux, so I’m including some links to additional resources that I’ve posted on this blog since I wrote this article:<\/p>\n It’s late 2013, Wheezy is among us; as some commenters have mentioned, gdm (version 2) is no longer an option if you’re building a kiosk on Debian stable. For wheezy, I’m recommending you use lightdm instead.<\/p>\n Simply replace “gdm” with “lightdm” in your installation procedure. To setup auto-login, run the following command:<\/p>\n Apart from that, my kiosks are still running happily using this procedure on Debian Wheezy, so nothing really needs to change. If you’re using Ubuntu, with all this Mir and Xmir business, you’re really on your own there. If you manage to get it working on Ubuntu 13.10 or higher, let us know what you did.<\/p>\n<\/div>\n<\/div>\n","protected":false},"excerpt":{"rendered":" Back around 2006 our public library was in need of a cheap way for patrons to browse its web-based INNOPAC catalog. Thin clients running Windows CE had been purchased for this purpose, but they turned out to be buggy and limited. I was tasked with finding a solution to the problem “on the cheap”, and […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[6,5],"tags":[15,16,20,22,33,14,34],"class_list":["post-181","post","type-post","status-publish","format-standard","hentry","category-floss","category-technology","tag-debian","tag-floss-2","tag-how-to","tag-instructional","tag-kiosk","tag-linux","tag-practical-tech"],"_links":{"self":[{"href":"https:\/\/alandmoore.com\/blog\/wp-json\/wp\/v2\/posts\/181","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/alandmoore.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/alandmoore.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/alandmoore.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/alandmoore.com\/blog\/wp-json\/wp\/v2\/comments?post=181"}],"version-history":[{"count":28,"href":"https:\/\/alandmoore.com\/blog\/wp-json\/wp\/v2\/posts\/181\/revisions"}],"predecessor-version":[{"id":887,"href":"https:\/\/alandmoore.com\/blog\/wp-json\/wp\/v2\/posts\/181\/revisions\/887"}],"wp:attachment":[{"href":"https:\/\/alandmoore.com\/blog\/wp-json\/wp\/v2\/media?parent=181"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/alandmoore.com\/blog\/wp-json\/wp\/v2\/categories?post=181"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/alandmoore.com\/blog\/wp-json\/wp\/v2\/tags?post=181"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}\n
Practice<\/h1>\n
Choose and install the OS<\/h2>\n
\n
Install the software<\/h2>\n
\n
User Accounts:<\/h2>\n
Configuring the session script<\/h2>\n
\r\ncp -r \/home\/kiosk \/opt\/\r\ncd \/opt\/kiosk\/\r\nchmod -R a+r .\r\ntouch .xinitrc\r\nchmod a+x .xinitrc\r\n<\/pre>\n
\r\nxset s off\r\nxset -dpms\r\nmatchbox-window-manager &\r\nwhile true; do\r\n rsync -qr --delete --exclude='.Xauthority' \/opt\/kiosk\/ $HOME\/\r\n chromium-browser --app=http:\/\/myserver\/mywebapp\r\ndone\r\n<\/pre>\n
\n
The lockdown<\/h2>\n
\n
\r\n1:2345:respawn:\/sbin\/getty 38400 tty1\r\n2:23:respawn:\/sbin\/getty 38400 tty2\r\n3:23:respawn:\/sbin\/getty 38400 tty3\r\n4:23:respawn:\/sbin\/getty 38400 tty4\r\n5:23:respawn:\/sbin\/getty 38400 tty5\r\n6:23:respawn:\/sbin\/getty 38400 tty6\r\n<\/pre>\n<\/li>\n
Tweaks<\/h2>\n
GDM autologin<\/h3>\n
\r\n[daemon]\r\nAutomaticLoginEnable=true\r\nAutomaticLogin=kiosk\r\n<\/pre>\n
Reset on Timeout<\/h3>\n
\n
xautolock -secure -time 15 -locker \/usr\/local\/bin\/kill_chromium.sh\r\n<\/pre>\n<\/li>\n<\/ul>\n
Auto update<\/h3>\n
\n
\n
Printing<\/h3>\n
Testing the system<\/h2>\n
\n
\n
\n
\n
\n
Just the beginning<\/h2>\n
2012 Update:\u00a0 Some additional resources<\/h2>\n
\n
2013 Update<\/h2>\n
\r\n\/usr\/lib\/i386-linux-gnu\/lightdm\/lightdm-set-defaults --autologin kiosk\r\n<\/pre>\n