Ubuntu 18.04 LTS kiosk for web or RDP

In this article we will show how to setup a browser or RDP kiosk, based on Ubuntu server 18.04 LTS. Because we are using the server edition the kiosk system will have a very small footprint and way less packets installed when we compare it to a stripped down desktop kiosk.

First we need to install a fresh Ubuntu 18.04 LTS system. After the installation is complete, make sure to install any available updates by executing the following commands:

sudo apt-get update
sudo apt-get upgrade -y
sudo reboot

Kiosk purpose

Before we start configuring the kiosk, we first need to think what we want to show on the kiosk unit. Different content types require different applications and configurations. in this article we will show how to install and use a chrome based kiosk and a Remmina (RDP) based kiosk. Other applications/types of content are also possible but might require additional research.

The kiosk can only serve one type of content at the time.

To go with the web content kiosk, install chrome using the following command:

sudo apt-get install --no-install-recommends chromium-browser

To go with the remote desktop kiosk, install Remmina using the following command:

sudo apt-get install remmina -y

Automatic logon

Our kiosk needs to log on automatically, to achieve this we will overwrite the getty service configuration to change the way TTY1 is started (TTY1 is the default console output on most Linux based servers). To overwrite a part of the getty configuration we need to execute the following command:

sudo systemctl edit getty@tty1

The above command will create an overwrite file for the getty configuration. paste the following text in this file to enable automatic login (replace <username> with a local account on the Ubuntu server):

ExecStart=-/sbin/agetty -a <username> --noclear %I $TERM

Because the user configured in the above file will automatically logon to the system at boot, it is recommended to make sure the user can not access sensitive documents (which should not be stored on a kiosk system in any case). the selected user may be in the sudoers file, this will not present a security problem because sudo alway’s requires a password. For more information about auto logon: Muru, a user on askubuntu.com has written a very interesting answer about auto logon.

Graphical user interface

Ubuntu server has no X server and Window manager installed by default, its text only. Our kiosk needs a both a X server and a window manger to display any graphical applications.

Use the following command to install the X server (X.org) and windows manager (Openbox):

sudo apt-get install --no-install-recommends xserver-xorg x11-xserver-utils xinit openbox -y

with the GUI installed, we need to configure it. X.org will work out of the box, but openbox requires some minor configuration changes to start our kiosk application.

The Openbox configuration file is located at “/etc/xdg/openbox/autostart”. We can open it for editing with the following command:

sudo nano /etc/xdg/openbox/autostart

Replace the contents of the Openbox configuration file with one of the below ones, depending on witch packet you installed earlier.

Web content/Chrome (replace <http://your-url-here> with your desired url:

# Disable any form of screen saver / screen blanking / power management
xset s off
xset s noblank
xset -dpms

# Allow quitting the X server with CTRL-ATL-Backspace
setxkbmap -option terminate:ctrl_alt_bksp

# Start Chromium in kiosk mode
sed -i 's/"exited_cleanly":false/"exited_cleanly":true/' ~/.config/chromium/'Local State'
sed -i 's/"exited_cleanly":false/"exited_cleanly":true/; s/"exit_type":"[^"]\+"/"exit_type":"Normal"/' ~/.config/chromium/Default/Preferences
chromium-browser --disable-infobars --kiosk '<http://your-url-here>'

Remote Desktop/Remmina (change <path to remmina file> to the actual path to the desired remmina file):

# Disable any form of screen saver / screen blanking / power management
xset s off
xset s noblank
xset -dpms

# Allow quitting the X server with CTRL-ATL-Backspace
setxkbmap -option terminate:ctrl_alt_bksp

# Start Remmina in kiosk mode
remmina -c <path to remmina file>

#start remmina in normal mode (for configuration purposes)

If you don’t have a .remmina file, comment out row 10 and uncomment row 13, now when the xserver is started Remmina will start in normal mode.

The main part of the configuration is done. To start the GUI simply type “startx” in the console, the GUI can be closed by pressing ctr+alt+backspace.

Autostart Graphical user interface

We can not call a system a kiosk if we need to manually type “startx” after every reboot. So lets make sure we wont have to.

We can accomplish this by configuring the “.bash_profile” file for the auto login user. Assuming we are alredy logged on as the auto logon user, use the following commands to create or open the “.bash_profile” file for editing:

sudo nano .bash_profile

now append the following line to the file:

[[ -z $DISPLAY && $XDG_VTNR -eq 1 ]] && startx


Reboot and enjoy your kiosk 🙂


A large part of this article is based on THIS blog-post about a similar setup on a raspberry pi.

Show online Teamspeak users without the client

It might sound like a useless project, but I wanted to be able to check who was using my Teamspeak server without having to be logged on all the time.

After a short search over the world wide web, I came across the “Powerful PHP Framework” from planet teamspreak. This framework enables the user to access the Teamspeak query system and do all kinds of fun stuff. The best part is, it is publicly available at Github and it is well documented.

during my search I already found a piece of code wich did almost exactly what I wanted to do, after some alterations I had the following code:


$enter = "<br>";
if (isset($_GET['TS']))
  $enter = "\13\10";

$ts3_VirtualServer = TeamSpeak3::factory("serverquery://<queryUser>:<queryPassword>@<TeamspeakIP>:<queryPort>/?server_port=<serverPort>");

$status = "offline";
$count = 0;
$max = 0;
try {
    $status = $ts3_VirtualServer->getProperty("virtualserver_status");
    $count = $ts3_VirtualServer->getProperty("virtualserver_clientsonline") - $ts3_VirtualServer->getProperty("virtualserver_queryclientsonline");
    $max = $ts3_VirtualServer->getProperty("virtualserver_maxclients");

catch (Exception $e) {
    echo "QueryError: " . $e->getCode() . ' ' . $e->getMessage() . "</div>";

echo "TS3 Server Status: " . $status . $enter . "Clients online: " . $count . "/" . $max ; 

echo $enter.$enter;
echo "Online clients: " . $enter;

// query clientlist from virtual server and filter by platform
$arr_ClientList = $ts3_VirtualServer->clientList();
// walk through list of clients
foreach($arr_ClientList as $ts3_Client)
  if ($ts3_Client["client_platform"] != "ServerQuery")
    echo $ts3_Client . $enter;

The above code produces the following output in a browser:

TS3 Server Status: online
Clients online: 1/32

Online clients:

This did not solve my problem entirely, I wanted to show the output on my desktop and opening a webbrowser and hitting F5 every few minutes is hardly ideal. Rainmeter to the rescue!

The following Rainmeter skin will show the above output in a very basic format, but it is perfect for me 🙂





Citrix Xendesktop 7.17 part 3: publishing a Desktop

After setting up the delivery controller and configuring storefront to allow the HTML5 Receiver it is finally time to add a desktop to the mix.

In this step by step article we will be adding a single desktop in “remote PC access mode”. this means that XenDesktop wont power manage the desktop and we wont be able to mass deploy it (its not a golden image).

This might sound a little disappointing but its good for the basics, if your setting up a lab environment you probably want it this way because its way more flexible and when you have your image the way you want it, you can always re add it with a differed configuration.

Lets get started.

We start by installing the XenDesktop VDI agent on the VM. In my setup this is a Widows 10 VM but you can use all supported versions (7 to 10 at this time) and even some Linux distro’s!

After installing windows on a new VM we can start the XenDestkop/Xenapp installer. This is the same installation media used for setting up the delivery controller. Click the Start button after the XenDesktop row to start the installation.


Click the “Virtual Delivery Agent for Windows Desktop OS” button to start the installation process.


Just like I wrote earlier I’m installing in Remote PC mode. In this case i want only one VDI and i’m not interested in rolling out a new set of VDI’s after every change (lab enviroment, remember). So select “Enable Remote PC Access” and click Next to continue.


We might as well install the Receiver in the VDI, if we want to use Xenapp applications we can do it from inside the VDI (saves a lot of mouse work). Click Next to continue.


I wont be using any of the additional components in this particular VDI. If you think you need any (supportability tools and profile manager are very useful if your planning to deploy the VDI to multiple users), select them and click Next to continue.


Now we need to add specify the deliver controller. you can do this manually or using AD. I only have one delivery controller and i don’t mind typing the name. Type the FQDN for the delivery controller, use the “Test connection..” button to verify there is a delivery controller on the other side of the line. Click Add.


After clicking Add. the screen looks like the above image (but probably with an other FQDN). if you don’t want to add another delivery controller click Next to continue.


Now were able to select features, everyone wants to optimize performance so that will be an easy pick 😉 . Remote assistance is needed if we want to use the shadow functionality from Citrix Director. Real-Time audio kind of explains itself. Framehawk is new transport protocol optimized for low bandwidth WAN connections. In my case I want everything but Framehawk.

Select the features you want and click Next to continue.


The can create firewall rules for windows firewall. If you are running Windows firewall you can let the setup do its thing. Otherwise you have to make the rules yourself. Click Next to continue.


The setup has all information to start installing. It politely shows what its going to install on your system. Click Install to start installing.


The installation will take up a good 10 minutes (depending on your system). we have to wait till its finished.


After installing the setup wants you to enable call home, the Citrix telemetry service. I don’t need nor want telemetry services so thanks but no thanks. Click Next to continue.


Now the setup is truly done. After restarting the system will be good to go. Click Finish to restart the machine.


Now were done on the VDI side of things. We will continue the operation on the delivery controller with Citrix Studio.

In Citrix Studio, navigate to the Machine Catalogs tab and click the “Create Machine Catalog” link on the right side of the screen. This will open the Machine Catalog Setup wizard.


Click Next to continue.


Were adding a Desktop OS system so select the “Desktop OS” radio button and click Next to continue.


Since we only want one VDI and were not letting Xendesktop power manage it we select the appropriate radio buttons (no power management and another service or technology). Click Next co continue.


Since we only have one VDI and we might have multiple users we will be using a random pool. Click Next to continue.


We have to define the VDI’s we want to add to the pool. This is not necessary if your using an other provisioning technology like PVS or MCS. Click “Add computers…” type the name of your computer and Click OK. Since were using the latest version of Xendesktop we can live the functional level the way it is. Click Next to continue.


Type a name for the Machine Catalog and click Finish.


We have now created a Machine catalog with a machine in it 🙂 . Lets add it to a delivery group so we can start it from the Receiver.


Navigate to the “Delivery Groups” tab in Citrix Studio and click the “Create Delivery Group” link on the right side of the screen to.


At the “Create Delivery Group” wizard introduction page, click Next to continue.


At the Machines tab, select the machine catalog we created earlier, set the number of machines to 1 (we only have one machine in the catalog) and click Next to continue.


At the Users tab, we can chose to limit the availability of the desktop group to specific users and or groups. In this lab setup all users may access the delivery group so we just click Next to continue.


If we want to publish applications, this is the place to do it. Since we want to publish the entire desktop we wont publish applications. Click Next to continue.


Because a delivery group can house multiple types of desktops (for example desktops with and without GPU acceleration), we have to at least one desktop assignment. Click the “Add…” button to continue.


Type in a display name for the delivery group, this is the name the end user will see in the Receiver. We can restrict this desktop assignment rule to desktops with a specific tag. Tags can be added for individual desktops from the search tab in Citrix Studio. We can restrict which users will be able to use the desktops, in this case all users are allowed to use the published desktop. Click OK to continue.


One desktop assignment added. Click Next to continue.

For some strange reason I forgot to take a screenshot of the Summary page. Luckily the summery page displays no new information.



Assuming we have clicked the Finnish button on the summary page, we are now back at Citrix studio. It shows the newly added delivery group, so we can go and see if the desktop is added to the Receiver.


Yep, its showing up on the Receiver side of things. Lets fire it up.


One windows 10 Desktop sitting happily in a webbrowser, i love progress 🙂 .


Citrix Xendesktop 7.17 part 2: Configuring storefront for the HTML5 Reciever

In the first part of this series of articles about Xendesktop, we have installed a delivery controller and configured a empty site. In part 2 we will be configuring Citrix Storefront for use with the Receiver for web application and we will setup the necessary policy’s. This will greatly improve the enviroment for testing purposes because we wont have to install or reconfigure the Citrix Receiver application every time we want to test something.

When we start Citrix studio, there are two snap-ins loaded: Citrix Studio and Citrix storefront. When we click on The storefront snap-in we get the option to view or change stores or create a new store. Citrix adds a store by default so Click on “View or Change Stores“.


The next screen gives a list of available stores and some basic information about the selected store. We want to enable the HTML5 Receiver. to do this, Click the “Manage Receiver for Web Sites” link on the lower right site of the screen.


After clicking the link the above window appears. Click the Configure… button to continue.


Select the “Deploy Citrix Receiver” tab and choose “Always use Receiver for HTML5” at the Deployment options drop down.


Click on the “Client Interface Settings” tab and deselect “Auto launch desktop” under Web sessions, otherwise every time you open the receiver page it will attempt to launch the first available desktop. Click OK to close the dialog. Click Close on the next dialog.


Now we want to setup the default domain, this step is not necessary but it will save the trouble of retyping the domain name every time we want to login to the receiver. Click “Manage Authentication Methods” at the bottom right of the screen.


Click the gear icon next to the “User name and password” method and click on “Configure Trusted Domains”.


Select “Trusted domains only” if you only want to allow logon attempts for trusted domains. Click on Add… and type the name of your domain. Click OK to close the dialog. If you have multiple domains you can check the show domains list in logon page checkbox. Click OK to close the dialog and click OK again to close the second dialog.

Now we have Storefront ready to go, we still have to set a policy to allow WebSocket connections to all Xendesktop and Xenapp systems. Without WebSockets enabled we wont be able to use the HTML5 Receiver.

In Citrix Studio, navigate to the Policies section and click Close to close the welcome message.


This section of Citrix Studio gives an overview over the applied policies. We want to create a new policy to do this, click the Create Policy link at the right side of the screen.


After clicking the Create Policy button, the Create Policy wizard pops up. We want to enable WebSockets, so we search for “webs” or something like it. There are 3 settings shown: Allow connections, port numbers and trusted origins. for the testing purposes we only need to enable WebSockets. Press the Select link after the WebSockets connection setting.


At the Edit Setting dialog Click the Allowed radio button and click OK. Click Next on the Create Policy wizard to continue with the wizard.


Click the “All objects in the Site” radio button on the “Users and Machines” tab. If you only want to use the HTML5 receiver on specific systems or desktop groups you can also do this with the “Selected users and machine objects” option. But in this case we want all systems to be able to use WebSockets. Click Next to continue.


Add a name for the Policy and check the Enable policy checkbox. Click Finish to activate the policy.


Now we can logon to StoreFront. browse to the web-store URL and login with an AD account. You will be presented with the above screen. Since we don’t have applications or desktops the screen is empty.

In the next part we will be adding a Desktop to the mix.

Citrix Xendesktop 7.17 part 1: Setting up the controller

Citrix Xendesktop is the remote desktop solution from Citrix. Since version 7 it is completely integrated with Xenapp, the terminal server like solution from Citrix. Together these solutions are capable to overcome (almost) every workplace virtualization challenge.

I have not updated my home lab enviroment in a long time, it was still running Xenapp 7.5. And because I have a number of Xendesktop projects planned I will be setting up a brand new Xendesktop 7.17 enviroment, this setup will include all Xenapp components.

This article is a step by step installation guide for Xendesktop 1.17, lets get started.


After mounting, extracting or inserting the Xenapp/Xendesktop installation media and starting the installer we are presented with the above screen. Click the Start button next to “XenDesktop”.


Depending on the OS your using this screen may look slightly different. We want to install a new delivery controller so we will click on the Delivery Controller button.


After a short load time we are presented with the license agreement. click on the accept radio button and click Next.


We want to install all roles on the same server, click Next to continue.


I wont be using a separate MS SQL server so we can let the installer install a Express edition, click Next to continue.


The installer can open all needed default ports in Windows firewall, click Next to continue.


Click Next to continue.


Wait while the installation progresses, this may take a lot longer than 2 minutes.


The system needs to restart during the installation of the prerequisites, click Close to restart the system. After rebooting log in onto the machine and wait till the installation continues.


The setup continues where it left off.


Smart tools contain the recently introduced “cloud” features, i don’t need them in my lab environment so I select the last radio box and click Next


The the setup completed the installation, click Finish to start Citrix Studio.


We need to set up a site before we can add desktops/apps, etc. click on “Deliver applications and desktops to your users”.


Create an empty site, type a name and click Next.



The default database names are good enough for me and since we are using the default MS SQL Express installation the location is also good enough. Click Next to continue.


Because we have just installed the License server, the licenses have not yet been added. So we will use the trail for now. Click Next to continue.


Click Finish to continue.


Citrix Studio after setting up a site.

Now we have a empty site, we can set up storefront and add desktops/applications to the site but this will have to wait to the next part of this guide.



Collabora CODE, a opensource selfhosted webbased officesuite with Nextcloud integration

If your reading this article, you probably know Microsoft office. And you probably also know about Microsoft’s move to the cloud. Today I can tell you one of Microsoft’s competitors has made the same move, and its not Google.

LibreOffice is well known for its open source and free office solution unfortunately LibreOffice always needed to be installed on a Windows, Linux or MacOS operating system. Because of this it was not usable on Android, IOS and ChromeOS (and probably a number of other operating systems).

Around 2012 LibreOffice started a side project to solve this issue once and for all. This project aimed to run LibreOffice in a webbrowser, enabling all devices with a webbrowser to use this amazing piece of software.

Unfortunately this project was abandoned somewhere along the way and this amazing software never saw the light of day. And with the death of the LibreOffice web project the dream for real productivity where you are the owner of your own data also died, or so I thought.

Recently (a couple of months back but I did not have time to try it sooner) I discovered Collabora CODE. Collabora is a company which created a webbased LibreOffice, and found some spare time to integrate there product with a number of other applications. One of those applications is Nextcloud.

In this article I will outline the steps needed to install your very own Collabora CODE installation (with LetsEncrypt)  and integrate this installation  with Nextcloud, all of this without using Docker.

As with the WeKan tutorial, I am using 2 Ubuntu 16.04 Servers. One with the Nextcloud installation (WEB) and the other one with the Collobara CODE installation (CODE). This setup differs a bit from the tutorial on the Collabora webpage, but I think it is better to have your services spread out over a number of servers, rather than have them all on one server. This approach will complicate things a little. Since I only have one public IP address available I will have to use a reverse proxy to make this setup work from outside my LAN.

So first of all we have to install Collabora CODE on the “CODE” server. For this part we simply follow the instructions From the Collabora page:

# import the signing key
$ apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 0C54D189F4BA284D
# add the repository URL to /etc/apt/sources.list
$ echo 'deb https://www.collaboraoffice.com/repos/CollaboraOnline/CODE ./' >> /etc/apt/sources.list
# perform the installation
$ apt-get update && apt-get install loolwsd code-brand

When this is done we have to make sure the CODE box will communicate with the revere proxy over http (we have only one IP so no Certificates on the CODE box).  And while where editing the Collabora CODE configuration we might as well make all the necessary changes.

On the CODE box, open the Collabora CODE configuration file:

$ sudo nano /etc/loolwsd/loolwsd.xml

And make the following changes:

<!-- First we set the hostname of the collabora server. Find the following line and change the "(your collabora url office.examle.com)" to your needs  -->
<server_name desc="Hostname:port of the server running loolwsd. If empty, it's derived from the request." type="string" default="">(your collabora url office.examle.com)</server_name>

<!-- Now find the  "<ssl desc="SSL settings">" part and edit the first 2 lines to reflect the below ones-->
<enable type="bool" default="true">false</enable>
<termination desc="Connection via proxy where loolwsd acts as working via https, but actually uses http." type="bool" default="true">true</termination>

<!-- Now we need to configure the backend document storage, Find the  "<storage desc="Backend storage">" part and add 2 rules to the "WOPI" part to allow your Nextcloud domain and the Nextcloud server IP to access to CODE box -->
<!-- Make shure you escape all "." with a "\" -->
<!-- the new rules must look like this (with your extual IP and dns names of course) -->
<host desc="Regex pattern of hostname to allow or deny." allow="true">nextcloud\.example\.com</host>
<host desc="Regex pattern of hostname to allow or deny." allow="true">192\.168\.x\.x</host>

<!-- Last but not least, add the web admin console login data to the config -->
<!-- find the "<admin_console desc="Web admin console settings.">" part and edit the following 2 lines to your needs -->
<username desc="The username of the admin console. Must be set.">(loginusername)</username>
<password desc="The password of the admin console. Must be set.">(supersecretpassword)</password>

Now restart the Collabora CODE service with the following command:

$ sudo service loolwsd restart

Now we move our attention to the WEB box. Here we will need to set up our reverse proxy, install the SSL certificates and make the CODE -> Nextcloud connection.

We will start with the reverse proxy (this part is almost the same as with the WeKan tutorial).

First we need to enable the Apache reverse proxy, SSL and header mods (if the are not enabled already).

$ sudo a2enmod proxy
$ sudo a2enmod proxy_http
$ sudo a2enmod headers
$ sudo a2enmod ssl
$ sudo service apache2 restart

When this is done we will create a new virtual server config for the http version of the Collabora CODE installation, this virtual host will only be used for the Lets encrypt certificate validation, so int wont actually point to the Collabora CODE installation.

# first create a directory for the virtualhost and set the webserver user as owner
$ sudo mkdir /var/www/code
$ sudo chown www-data:www-data /var/www/code

# now create the site config
$ sudo nano /etc/apache2/sites-enabled/code.conf

# input the followin (change where needed)
<VirtualHost *:80>
    ServerAdmin <youre email address>
    DocumentRoot /var/www/code
    servername <website adres office.example.com>
    ErrorLog ${APACHE_LOG_DIR}/code_error.log
    CustomLog ${APACHE_LOG_DIR}/code_access.log combined

Now we can run the Lets encrypt cert-bot and follow the instructions onscreen (if you don’t have cert-bot installed, you can install it by typing “sudo apt-get install certbot”):

$ sudo certbot

The Cert-bot wizard will have created a file named “code-le-ssl.conf”. Open this file with your favorite editor (I use nano) and edit it to reflect the following (make changes where needed):

<IfModule mod_ssl.c>
  <VirtualHost *:443>
    ServerName <youre_site_hostname>
    SSLEngine on
    SSLProxyEngine on
    ProxyPreserveHost on
    SSLCertificateFile /etc/letsencrypt/live/<youre_site_hostname>/fullchain.pem
    SSLCertificateKeyFile /etc/letsencrypt/live/<youre_site_hostname>/privkey.pem
    Include /etc/letsencrypt/options-ssl-apache.conf
    ProxyPass / http://<code_ip>:9980/
    ProxyPassReverse / http://<code_ip>:9980/
    Header always set Strict-Transport-Security "max-age=63072000; includeSubdomains;"
    <Proxy *>
      Order deny,allow
      Allow from all
    ServerAdmin <your_email>
    ErrorLog ${APACHE_LOG_DIR}/code_error.log
    CustomLog ${APACHE_LOG_DIR}/code_access.log combined

Now restart apache2 on the webserver:

$ sudo service apache2 restart

Because you wont be visiting the Collabora CODE installation manual it is not necessary to create a redirect for the http url.

We now have a Collabora CODE installation with LetsEncrypt certificate ready to go. All that left is to connect the Collabora CODE installation to the Nextcloud installation.

To Enable the link to Nextcloud we first have to install the Colabora online app in Nextcloud. This app can be found under “Office & text” in the applications section of your Nextcloud installation to enable this app click the Enable button. If the app is enabled it will look like the picture below

Enabled Collabora Online app

After enabling the app, an extra settings item will be added to the Nexcloud admin panel. Go to the Admin panel and click the “Collabora Online” menu item. Here You can add the external url to your Collabora CODE installation. This is the same URL we added to the Collabora CODE configuration (office.examle.com). This will look like the picture below:

Collabora Online Settings


If all went well, you will now be able to create and open most office files from your Nexcloud installation and edit them directly from your webbrowser.


Images by ColoboraOffice.

source: https://en.wikipedia.org/wiki/Kanban_board

kanban with wekan: self-hosted trello-like web-app

Almost everyone knows the online productivity platform Trello. Trello is a Kanban tool and can be used virtually every problem as long as the problem involves tracking something. Whether you are trying to keep track of time, tasks or inventory, Kanban is a good way to go.

Kanban was was originally designed as a inventory control system, to help automate production lines in factory’s. Over the years countless tools (like Trello) have been created to help with using Kanban for various purposes. Nowadays lots and lots of people use those Kanban tools without knowing anything about the Kanban method. And for most of them, this works just fine.

This post is not about the Kanban method, its not even about a Kanban tool. It is about setting up a self-hosted Kanban tool.

Now the first question is, why would you host you’re own Kanban tool while there are plenty free tools on the marked? Well, it mostly comes down to security, trust and privacy. When I’m working on a project, I want to be able to put sensitive data on my carts. While this data often is not interesting for a company like Trello it might be interesting for other company’s. In my opinion the question you should be asking yourselves is, do you trust a company like Trello with the data you want to put on to there service, do you expect them not to make money of a “free” service and can this impact your business in a negative way.

So after using Trello for some time, i started looking into a good self-hosted solution. I tried a number of Kanban tools, and eventual chose for Wekan.

Source: https://wekan.github.io/
Image source: https://wekan.github.io/

Of course self-hosted applications wont work directly after you have chosen to use them, you need to run them on your own system/server (or on a cloud-hosted system, VPS, etc.).

You can get Wekan from there releases page, they serve Wekan in 4 flavors:

  • A docker container
  • A sandstorm App
  • A Ubuntu Snap package
  • A virtualbox image

because I was already planning on using a Ubuntu server for this project, the Snap package was the logical choice.

Snap packages are super easy to set up, you basically execute the command:

$ sudo snap install <snap_package_name>

On the Wekan wiki there is a short and to the point installation tutorial, but for basic installations the following will be sufficient:

$ sudo snap install wekan

After the above command completes, Wekan will be running at “http://<ip_of_the_system>:8080”.

When you navigate to the fresh Wekan installation, you don’t have a user account to log in with. in stead use the build in registration feature on the login page. The first user you will create will automatically be a administrator.

Great, now we have a working local Wekan installation. The next step is to make this installation available to the big and scary world wide web. And because we font want to send our sensitive data over the internet unencrypted, we will also implement TLS with Lets encrypt

In my situation, the server running Wekan and the main web server are 2 separate Ubuntu installations. For this to work we will use a reverse proxy, and because my main web server runs Apache it will be a Apache reverse proxy. If you are using the same installation for both, the next part will not be needed, see the Wekan wiki for more information on this.

First we need to enable the Apache reverse proxy, SSL and header mods (if the are not enabled already).

$ sudo a2enmod proxy
$ sudo a2enmod proxy_http
$ sudo a2enmod headers
$ sudo a2enmod ssl
$ sudo service apache2 restart

When this is done we will create a new virtual server config for the http version of the Wekan installation, this virtual host will only be used for the Lets encrypt certificate validation, so int wont actually point to the Wekan installation.

# first create a directory for the virtualhost and set the webserver user as owner
$ sudo mkdir /var/www/wekan
$ sudo chown www-data:www-data /var/www/wekan

# now create the site config
$ sudo nano /etc/apache2/sites-enabled/wekan.conf

# input the followin (change where needed)
<VirtualHost *:80>
        ServerAdmin <youre email address>
        DocumentRoot /var/www/wekan
        servername <website adres wekan.example.com>

        ErrorLog ${APACHE_LOG_DIR}/wekan_error.log
        CustomLog ${APACHE_LOG_DIR}/wekan_access.log combined

Now we can run the Lets encrypt cert-bot and follow the instructions onscreen (if you don’t have cert-bot installed, you can install it by typing “sudo apt-get install certbot”:

$ sudo certbot

The Cert-bot wizard will have created a file named “wekan-le-ssl.conf”. Open this file with your favorite editor (I use nano) and edit it to reflect the following (make changes where needed):

<IfModule mod_ssl.c>
    <VirtualHost *:443>
        ServerName <youre_site_hostname>
        SSLEngine on
        SSLProxyEngine on
        ProxyPreserveHost on
        SSLCertificateFile /etc/letsencrypt/live/<youre_site_hostname>/fullchain.pem
        SSLCertificateKeyFile /etc/letsencrypt/live/<youre_site_hostname>/privkey.pem
        Include /etc/letsencrypt/options-ssl-apache.conf

        ProxyPass / http://<wekan_ip>:8080/
        ProxyPassReverse / http://<wekan_ip>:8080/
        Header always set Strict-Transport-Security "max-age=63072000; includeSubdomains;"
        <Proxy *>
            Order deny,allow
            Allow from all

        ServerAdmin <your_email>

        ErrorLog ${APACHE_LOG_DIR}/wekan_error.log
        CustomLog ${APACHE_LOG_DIR}/wekan_access.log combined

Now restart apache2 on the webserver:

$ sudo service apache2 restart

You can add a redirect to the http version of the site, so you wont have to type “https://” every time you want to visit your Wekan installation.

# create a redirect index.html
$ sudo nano /var/www/wekan/index.html

# insert the following (edit where needed)

<meta http-equiv="refresh" content="0;URL=https://<your_domain_here>/" />
nothing to see here, go to <a href="https://<your_domain_here>/">this location</a> for a more useful page.

After the above changes we need to let Wekan know its new url (the one you will be using to access Wekan), this can be done using the following command:

$ sudo snap set wekan root-url="https://<your_wekan_url>"

After this last change, the Wekan service needs a restart:

$ sudo systemctl restart snap.wekan.wekan


Congratulations, You now have a working Wekan installation which is accessible from the internet.


Having the Wekan installation up and running is one thing. Maintaining it is another. Luckily over at Wekan there are a number of articles for maintaining your Wekan server, one of the most important ones is “backup and restore“. From time to time you might want to update your Wekan installation. Upgrading a snap packet is just as easy as installing it, just enter the following command:

$ sudo snap refresh wekan


Have fun with your Wekan installation



featured image from: https://en.wikipedia.org/wiki/Kanban_board