OpenBSD Journal

Thin client solution based on OpenBSD

Contributed by phessler on from the bang-the-drum-all-day dept.

OpenBSD developer Robert Nagy writes in to tell us about how they use OpenBSD at work:

The m:tier thin client is a small application written in Python that can be executed as a window manager replacement. It provides a clean UI for the thin client hardware in order to allow the user to easily execute all the needed applications. We have been using thin client hardware from IGEL to have a simple and usable hardware base for our thin client. The machine itself is a really simple i386 machine with enough power to support most of the needs. As usual, we have chosen OpenBSD as the operating system because of its simplicity and the fact that it’s the most secure and sane operating system out there.

In most areas thin clients are being used in offices where there can be a central server which is used by the clients to boot using pxeboot for example. In this case every time the machine gets rebooted, a clean environment will be provided for the users. Our goal was to create a thin client which can be updated and managed over the internet, but still keeping the ability to have a clean environment after a reboot. In order to achieve this we have modified the rc(8) system of OpenBSD to use memory file systems on the those parts of the system where writing data somewhere is necessary. In our setup /tmp, /home, /var/log and /var/db is always a memory filesystem. All of these memory filesystems are created on boot to have a clean start except for /var/db which gets synchronized with the on-disk data before it is being used by anything. After the filesystem setup we make sure that we populate the /home directory properly for the “thin” user, which is being used by the thin client to launch an X server and the thin client software itself.

ttys(5):
ttyC5   "/usr/bin/su - thin -c /usr/X11R6/bin/xinit" xterm on secure


rc.local(8):
install -d -o thin -g users -m 750 /home/thin
cat < /home/thin/.xinitrc
xsetroot -cursor_name left_ptr
(cd /usr/local/thinclient; ./thinclient)
EOF

As you can see the rc.local can be used to populate the home directory for the thin user to have all the necessary configuration files. After rc.local has finished running, the rc(8) script makes the whole / filesystem read-only because we do not need to write to it at all. Doing this also ensures that if the machine gets reset there will be no need to run fsck(8) and that our system will always be consistent with what we want.

The thin client software is really simple and by default it includes support for three default applications: OpenNX, Remmina and Chromium. These are the most commonly used application types on a thin client because most of the time users only use these clients to connect to other machines or just to browse the internet.

The client also has two indicators so that the user can see if the network connection and a VPN connection are up (if configured). The client regularly watches network traffic on the configured interface and also checks IPSec flows to indicate if there is a VPN tunnel running:

The client also includes a clock and a date indicator and support for rebooting and shutting the thin client down.

We have chosen OpenNX and Remmina to support remote connections to other machines because these programs include basically all needed protocols: NX, RDP, VNC and so on.

In the background a puppet client is running checking a master server over the internet using the machine’s UUID to authenticate itself to the puppet master server in order to get updates over the internet. Since the / filesystem is mounted read-only each time an update has to be applied the filesystem gets remounted read-write so that the changes can be made and then it gets remounted read-only to protect the consistency of the system.

For more details on this delightful system, please check out the homepage at http://opensource.mtier.org

(Comments are closed)


  1. By Predrag Punosevac (Oko) punosevac72@hotmail.com on

    Great post! Is there any chance that we see soon m:tier thin client in ports tree? Could you also explain the rational behind using OpenNX and Remmina? I was not aware of Remmina before so I did a bit of search. It appears that Remmina does support NX protocol although relaying on OpenSSH rather on proprietary forked SSH version. Is there anything wrong with it? I am a heavy user of OpenNX and occasional user of VNC (SSVNC) and RDP. Having a single client for multiple protocols is very appealing to me.

    1. By Robert Nagy (robert) on

      > Great post! Is there any chance that we see soon m:tier thin client in ports tree? Could you also explain the rational behind using OpenNX and Remmina? I was not aware of Remmina before so I did a bit of search. It appears that Remmina does support NX protocol although relaying on OpenSSH rather on proprietary forked SSH version. Is there anything wrong with it? I am a heavy user of OpenNX and occasional user of VNC (SSVNC) and RDP. Having a single client for multiple protocols is very appealing to me.

      We do not have any plans on putting this into the ports tree. Remmina and NX are used in different places, we just put them both into the client for the public so that we can show both of them. Actually I never tried using Remmina for NX, but I might give it a shot. I cannot say there is anything wrong with it, I just do not have an opinion yet. Indeed having a single client is appealing but most of the time we are using NX only so there is no point in using Remmina because we would not use any other protocols.

  2. By mkucharski (mkucharski) mikolaj@kucharski.name on

    Robert, what are you using on the server side of NX?

    1. By Predrag Punosevac (Oko) on

      > Robert, what are you using on the server side of NX?
      While you are waiting for Robert to answer I thought you might be interested to know how we use NX X-servers at Augusta State University. I am running proprietary NX X-server small business edition (10 concurrent sessions) on the top of PUIAS Linux 6.3. on two different machines used for High Performance Computing. One of them is a classical CPU cluster with 16 nodes and another one is a GPU based super computer. Besides lack of drivers/CUDA for GPUs in BSD/Solaris world we run lots of proprietary software like MATLAB, Mathematica and more specialized tools so BSDs are not an option. However, aside of the firewall which runs OpenBSD (of course) more than half of my users run OpenBSD as their main desktop. I use OpenBSD not just as a client for Linux machines but also to do actual scientific work (TeX, C, Python, CVS) as well as administrative stuff (mostly AWK, shell scripts). My time is probably split 97% (OpenBSD) and 3% (Linux servers).

Credits

Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]