Jekyll2026-05-15T06:26:43+02:00http://localhost:4000/feed.xmlaxaneco’s tech blogdocumentation of my private IT projectsSetup of a Guacamole HTML5 remote XFCE desktop via VNC for Ubuntu 24.042025-07-21T11:00:00+02:002025-07-21T11:00:00+02:00http://localhost:4000/doc/2025/07/21/remote-vm-with-xfceGoal of this article is to document the setup of a Guacamole HTML5 remote XFCE desktop via VNC on Ubuntu 24.04.x. The Guacamole setup is based on Ubuntu 20.04.x LTS - Guacamole HTML5 Remotedesktop Gateway installieren mit Apache Reverse Proxy (in german, written by Bernhard Linz)

Install the guacamole server

So, let’s assume we have a fresh Ubuntu 24.04.x installation on a remote machine with DNS name test.example.org running a ssh server. First, we become root:

sudo -i

Next, we install everything that is needed to run the Apache Tomcat server. We’ll need tomcat9, since tomcat10 (that is the default for Ubuntu 24.04) is not compatible with Guacamole. So we have to add the respective repostitory first.

add-apt-repository -y -s "deb http://archive.ubuntu.com/ubuntu/ jammy main universe"
apt install make libssh2-1-dev libtelnet-dev libpango1.0-dev libossp-uuid-dev libcairo2-dev libpng-dev libvncserver-dev libvorbis-dev  gcc libssh-dev libpulse-dev tomcat9 tomcat9-admin tomcat9-docs ghostscript libwebp-dev libavcodec-dev libavutil-dev libswscale-dev libjpeg-turbo8-dev libtool-bin libossp-uuid-dev libavformat-dev freerdp2-dev libwebsockets-dev libssl-dev

Now, on calling http://test.example.org:8080 we should see the standard Apache Tomcat “It works!” page.

As of July 2025, the current Guacamole version is 1.6.0, so we download the following files:

cd /usr/src
wget https://downloads.apache.org/guacamole/1.6.0/source/guacamole-server-1.6.0.tar.gz
wget https://downloads.apache.org/guacamole/1.6.0/binary/guacamole-1.6.0.war

So we have server source code and client binary.

Now we unpack the server code

tar xvzf guacamole-server-1.6.0.tar.gz

and compile it:

cd /usr/src/guacamole-server-1.6.0
./configure --with-systemd-dir=/etc/systemd/system

That should result in an output like this:

------------------------------------------------
guacamole-server version 1.6.0
------------------------------------------------

   Library status:

     freerdp ............. yes (2.x)
     pango ............... yes
     libavcodec .......... yes
     libavformat ......... yes
     libavutil ........... yes
     libssh2 ............. yes
     libssl .............. yes
     libswscale .......... yes
     libtelnet ........... yes
     libVNCServer ........ yes
     libvorbis ........... yes
     libpulse ............ yes
     libwebsockets ....... yes
     libwebp ............. yes
     wsock32 ............. no

   Protocol support:

      Kubernetes .... yes
      RDP ........... yes
      SSH ........... yes
      Telnet ........ yes
      VNC ........... yes

   Services / tools:

      guacd ...... yes
      guacenc .... yes
      guaclog .... yes

   FreeRDP plugins: /usr/lib/x86_64-linux-gnu/freerdp2
   Init scripts: no
   Systemd units: /etc/systemd/system

Type "make" to compile guacamole-server.

If that’s the case as all “yes”-entries are present, we can compile:

make
make install

Last we have to configure the dynamic linker run-time bindings:

ldconfig

Now we can start the systemd service that the installation has provided:

systemctl start guacd.service
systemctl status guacd.service

which should give us an output like

● guacd.service - Guacamole Server
     Loaded: loaded (/etc/systemd/system/guacd.service; disabled; vendor preset: enabled)
     Active: active (running) since Fri 2023-04-21 14:52:28 UTC; 6s ago
       Docs: man:guacd(8)
   Main PID: 47807 (guacd)
      Tasks: 1 (limit: 2233)
     Memory: 10.2M
        CPU: 10ms
     CGroup: /system.slice/guacd.service
             └─47807 /usr/local/sbin/guacd -f

Apr 21 14:52:28 test181 systemd[1]: Started Guacamole Server.
Apr 21 14:52:28 test181 guacd[47807]: Guacamole proxy daemon (guacd) version 1.5.1 started
Apr 21 14:52:28 test181 guacd[47807]: guacd[47807]: INFO:        Guacamole proxy daemon (guacd) version 1.5.1 started
Apr 21 14:52:28 test181 guacd[47807]: guacd[47807]: INFO:        Listening on host 127.0.0.1, port 4822
Apr 21 14:52:28 test181 guacd[47807]: Listening on host 127.0.0.1, port 4822

We stop the server in order to amend configurations:

systemctl stop guacd.service

First we create the directory

mkdir /etc/guacamole

There we create a file /etc/guacamole/guacamole.properties with the content

basic-user-mapping: /etc/guacamole/user-mapping.xml

For our purposes, this file reads like

<user-mapping>
        <!-- Per-user authentication and config information -->
        <!-- FIRST USER -->
        <authorize 
                username="test01"
                password="52c88bca7c5b3ab3e7ed8901ea1bc83f"
                encoding="md5">
                <!-- First authorized Remote connection -->
                <connection name="SSH Admin">
                        <protocol>ssh</protocol>
                        <param name="hostname">10.10.10.10</param>      
                        <param name="port">22</param>                    
                        <param name="username">test01</param>     
                        <param name="enable-sftp">true</param>
                </connection> 
                <!-- second authorized Remote connection -->
                <connection name="Terminal Server VNC">
                        <protocol>vnc</protocol>
                        <param name="hostname">127.0.0.1</param> 
                        <param name="port">5901</param>         
                        <param name="server-layout">de-de-qwertz</param>
                </connection>
        </authorize>
</user-mapping>

Of course we have to amend hostname, username, and password for our system.

The password hash can be created by

echo -n 'secretPassword' | md5sum

Finally, we have to append the Guacamole home to the environment:

echo GUACAMOLE_HOME="/etc/guacamole" >> /etc/environment

It makes sense to reboot at this point.

Now we enable the Guacamole service for automated start:

systemctl enable guacd.service

Next, we install the client:

cp /usr/src/guacamole-1.6.0.war /var/lib/tomcat9/webapps/guacamole.war

Then we have to link the property directory to the place where it is expected:

ln -s /etc/guacamole /usr/share/tomcat9/.guacamole

To speed up the tomcat restart, we have to create the following file

touch /usr/share/tomcat9/bin/setenv.sh
chmod +x /usr/share/tomcat9/bin/setenv.sh

with this content:

#!/bin/sh
export CATALINA_OPTS="$CATALINA_OPTS -Djava.security.egd=file:/dev/./urandom"

Now we can start the guacamole server:

systemctl start guacd.service

If we now browse to

http://test.example.org:8080/guacamole/

we should be offered a login and then the connection options “SSH Admin” and “Terminal Server VNC”.

The SSH connection should work already (if not, you did probably not reboot), for the VNC we need to prepare some more things, as follows.

Install the VNC server

Let’s assume that we have a user test01 as our (sudo-enabled) standard user for the machine we just prepared, and that we are now logged in as that user.

We install the needed stuff:

sudo apt install -y xfce4 xfce4-goodies tigervnc-standalone-server tigervnc-xorg-extension autocutsel xfonts-base xfonts-100dpi xfonts-75dpi

Then we create a vnc password for our (non-root) user:

vncpasswd

Next, we have to create the vnc startup file in our user home directory and make it executable:

cd
mkdir .vnc
touch ~/.vnc/xstartup
chmod 755 ~/.vnc/xstartup

The contents of this file is

#!/bin/sh
unset SESSION_MANAGER
unset DBUS_SESSION_BUS_ADDRESS
DBUS_SESSION_BUS_ADDRESS=unix:path=$XDG_RUNTIME_DIR/bus
exec startxfce4

For starting the VNC server on boot, we change to root again with sudo -i and create a service file /etc/systemd/system/vncserver@.service, as suggested by Install Xfce VNC remote desktop on Ubuntu.

[Unit]
Description=Remote desktop service (VNC)
After=syslog.target network.target

[Service]
Type=simple
User=test01
PAMName=login
PIDFile=/home/%u/.vnc/%H%i.pid
ExecStartPre=/bin/sh -c '/usr/bin/vncserver -kill :%i > /dev/null 2>&1 || :'
ExecStart=/usr/bin/vncserver :%i -geometry 1440x900 -alwaysshared -fg
ExecStop=/usr/bin/vncserver -kill :%i

[Install]
WantedBy=multi-user.target

In the Service section, we replace test01 by the username of our local user.

To enable the service by default, we make the service available at boot time by

cd /etc/systemd/system/multi-user.target.wants/
ln -s /etc/systemd/system/vncserver@.service ./vncserver@1.service

Time for a last reboot!

Then, we should be able to login to http://test.example.com:8080/guacamole with the credentials we stored in /etc/guacamole/user-mapping.xml, click on “Terminal Server VNC”, type in the VNC password we have defined before, and see a virtual XFCE screen in our browser.

That’s it! Now we have set up a Guacamole HTML5 remote XFCE desktop via VNC for Ubuntu 24.04.

For security reasons, it makes absolutely sense to add a 2FA as described in the already mentioned (german) article by Bernhard Linz. For security reasons, it makes also sense to map the Tomcat (http port 8080) via Apache or nginx reverse proxy to https, as described in the linked article.

Addena:

1

If you have a virtual server at a provider like Netcup which provides a VNC console to the machine, after the last reboot you’ll end up in a graphical login screen that produces a deadlock. To avoid being locked out you can change the default boot target:

sudo systemctl set-default multi-user.target

After a reboot you’ll see the console login again.

2

In order to start applications like Firefox etc from the command line, append the following to the .bashrc file:

XAUTHORITY=$HOME/.Xauthority
export XAUTHORITY
]]>Avoid DNS deadlock when updating Pihole2025-02-23T10:00:00+01:002025-02-23T10:00:00+01:00http://localhost:4000/doc/2025/02/23/pihole-deadlockDuring the last Pihole-Update I went into a self-manufactured deadlock in DNS resolving. That was, because during the update of Pihole the DNS resolving by Pihole itself was interrupted, and the update script waited for DNS resolving to become available again, but that would not be the case until the update script was finished. So, this was a network design problem, because the Pihole gets its IP address and its DNS server from my router, als all other clients do too. But the router gives to all clients the Pihole as DNS resolver. For that reason, the Pihole was the DNS resolver for itself, what lead to the deadlock.

To solve this, I had to make some changes at the router, which is a barebone (Qotom Q330G4) running Ubuntu 24.04 server with iptabes and isc-dhcp-server.

First, I disabled the systemd-resolved mechanis as Kristof suggested in his blog:

# Create directory
sudo mkdir -p /etc/systemd/resolved.conf.d/
# Set permissions
sudo chmod 755 /etc/systemd/resolved.conf.d/
# Disable
printf "[Resolve]\nDNSStubListener=no\n" | sudo tee /etc/systemd/resolved.conf.d/noresolved.conf
# Restart systemd-resolved
sudo systemctl restart systemd-resolved.service

Then, I set up dnsmaq as DNS resolver with the following configuration:

# /etc/dnsmasq.conf
# Set up your local domain here    
domain=example.com

# Example: The option local=/localnet/ ensures that any domain name query which ends in .localnet will be answered if possible from /etc/hosts or DHCP, but never sent to an upstream server
# don't forward requests (andrewoberstar.com/blog/2012/12/30/raspberry-pi-as-server-dns-and-dhcp)
local=/example.com/

listen-address=192.0.2.254
resolv-file=/etc/dnsresolv.conf
log-facility=/var/log/dnsmasq.log
log-queries
no-negcache
#strict-order

# Use the hosts file on this machine
expand-hosts

Here, 192.0.2.254 is the IP adress of the router.
The resolv file reads

#/etc/dnsresolv.conf 
domain example.com
search example.com

#quad9
nameserver 9.9.9.10
# cloudflare
nameserver 1.1.1.1

With this configuration, the router can work as an auxiliary DNS resolver, i.e. for the Pihole itself - not to confuse with the upstream DNS resolver configured in Pihole, that are only used when Pihole is running! (It’s complicated, I know.)

But, to let the Pihole know that the router 192.0.2.254 is ready to serve it’s DNS requests, I had to configure the router’s DHCP setting accordingly:

#/etc/dhcp/dhcpd.conf
# LAN (Internal)
subnet 192.0.2.0 netmask 255.255.255.0 {
  interface enp2s0;
  option routers 192.0.2.254;
  option domain-name-servers 192.0.2.53;
  option broadcast-address 192.0.2.255;
  default-lease-time 43200;
  max-lease-time 43200;
}

[...]

host dns {
 hardware ethernet 00:53:af:ab:cd:ef;
 fixed-address 192.0.2.53;
 option domain-name-servers 192.0.2.254;
}

With this setup, the DNS resolver for queries coming from the Pihole machine (again, not to be confused with the upstream servers configured in Piholte itself) is the router’s dnsmasq, that in turn has i.e. Clouflare and quad9 configured as external upstream servers.

Thus, when Pihole is under update and needs DNS resolution during the process (or even during normal operation), the router will provide this.
Furthermore, the router can serve as a backup DNS resolver in case Pihole is not available for other reasons, only thing is to change option domain-name-serversfrom 192.0.2.53 to 192.0.2.254 in the router’s dhcpd configuration for the LAN subnet. There will be of course no DNS filtering then (except the upstram DNS server provides it), but the DNS resolving is always provided.

]]>Connect a new exporting server to a running Prometheus instance2025-02-22T10:00:00+01:002025-02-22T10:00:00+01:00http://localhost:4000/doc/2025/02/22/nodeexporter(Reminder only, especially no full explanation of how to set up a prometheus host.)

Exporting machine: Machine that is running the node exporter/Apache exporter.
Prometheus machine: Machine that is running the Prometheus server to collect the exported telemetry data. Also may be the host for Grafana to display the data in a nice way.

On the exporting machine:

adduser pexp --system --no-create-home

Install /opt/apache-exporter and /opt/node-exporter binaries.

On the Prometheus machine, execute script

#!/bin/bash
if [ -z "$1" ]
  then
    echo "No argument supplied"
else
    sudo openssl req -new -newkey rsa:2048 -days 3650 -nodes -x509 -keyout $1_exporter.key -out $1_exporter.crt -subj "/C=DE/ST=Hamburg/L=Hamburg/O=org/OU=IT/CN=example.com" -addext "subjectAltName = IP:$1"
fi

with exporting machine public IP address as argument in order to get some transport encryption for the data between exporting machine and Prometheus machine.

Copy the [public_IP]_exporter.crt of the new exporter machine to /etc/prometheus at the prometheus machine. Copy (i.e. scp) .key and .crtfiles to exporting machine under /etc/node_exporter. Chown to pexp:root there.

On exporting machine, create /opt/node_exporter/web.yml:

tls_server_config:
  cert_file: /etc/node_exporter/[public_IP]_exporter.crt
  key_file: /etc/node_exporter/[public_IP]_exporter.key

and chown to pexp:root.

Under /lib/systemd/system create an apacheexporter.service

[Unit]
Description=Apache Exporter for Prometheus
Documentation=https://github.com/Lusitaniae/apache_exporter
After=network-online.target

[Service]
User=pexp
Restart=on-failure

ExecStart=/opt/apache-exporter/apache_exporter --web.config=/etc/node_exporter/web.yml --scrape_uri=http://localhost/server-status/?auto   --telemetry.address=0.0.0.0:9117   --telemetry.endpoint=/metrics

[Install]
WantedBy=multi-user.target

and a nodeexporter.service:

[Unit]
Description=Prometheus Node Exporter
Documentation=https://prometheus.io/docs/guides/node-exporter/
After=network-online.target

[Service]
User=pexp
Restart=on-failure

ExecStart=/opt/node-exporter/node_exporter --web.config.file=/etc/node_exporter/web.yml

[Install]
WantedBy=multi-user.target

Enable both services:

cd /etc/systemd/system/multi-user.target.wants
ln -sf /lib/systemd/system/apacheexporter.service .
ln -sf /lib/systemd/system/nodeexporter.service .

Start the services

service apacheexporter start
service apacheexporter status
service nodeexporter start
service nodeexporter status

netstat -anp should show the exporter processes listening at ports 9117 and 9100.

On the Prometheus machine, add the new config items to /etc/prometheus/prometheus.yml:

  - job_name: "new_exporter"
    scheme: https
    tls_config:
      ca_file: /etc/prometheus/[public_IP]_exporter.crt
    static_configs:
    - targets: ["[public_IP]:9100"]

  - job_name: "nextcloud-apache"
    scheme: https
    tls_config:
      ca_file: /etc/prometheus/[public_IP]_exporter.crt
    static_configs:
    - targets: ["[public_IP]:9117"]

Then, restart the Prometheus service with service prometheus restart.

Last, at the exporting machine, configure the firewall to enable incoming tcp access at ports 9100 and 9117 originating from the IP of the Prometheus host only.

In Grafana, add the new job to the node exporter charts.

]]>Setting up a Nextcloud server with Collabora Online support to migrate away from Google docs2025-02-16T10:00:00+01:002025-02-16T10:00:00+01:00http://localhost:4000/doc/2025/02/16/nextcloud-coSince some of us feel the urge to migrate our cloud data away from Google, Microsoft or other US based services, this is one way to set up a self-hosted open source service as a private cloud.

We will need a Nextcloud instance as a frontend for cloud storage and basic file handling for images, PDF, notes, markdown documents etc., and also a Collabora Online instance for providing office document capabilities.

It goes as follows:

We log in to our preferred VPS/root server provider and order a machine with 4 vCPUs and 4-8 GB RAM, which comes usually with 128 to 256 GB HDD space. (I’m with netcup - not affiliated - and took a VPS with 4 vCPUs, 8 GB RAM and 256 GB HDD at 6,84 EUR/month.) We deploy a fresh Ubuntu Server 24.04, we deploy necessary updates, we reboot.

At our DNS registrar, we register A records for nx.example.com and co.example.com for the IP of the new machine, given that we own the domain example.com.

We install an appropriate firewall and/or startup scripts. It makes sense to open ports 80 and 443 for web as well as to install an ssh server for remote access. We open port 9980 tcp only for our client IP.

Now we execute phase 1 of this great Nextcloud install instruction.

Then, we create an Apache configration nx.example.com.conf with the following contents:

<VirtualHost *:80>
        ServerAdmin webmaster@localhost
	ServerName nx.example.com
	ServerAlias nx.example.com
        DocumentRoot /var/www/nextcloud
        
        <Directory /var/www/nextcloud>
            Options Indexes FollowSymLinks
            AllowOverride All
            Require all granted
	</Directory>
        
        ErrorLog ${APACHE_LOG_DIR}/error.log
        CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>

Please be aware that we use the path /var/www/nextcloud instead of /var/www/html/nextcloud as per the tutorial.

After enabling the instance by a2ensite nx.example.com.conf and restarting Apache we switch the server to https:

apt-get install certbot python3-certbot-apache
certbot -d nx.example.com

After that, we have a running nextcloud instance and can login at https://nx.example.com. We even can view pictures and PDF documents that are supplied with the server as examples. But we cannot open the also supplied docx-Document. In order to do that, we have to setup a Collabora Online instance, which we can do at the same server.

For installing this instance we follow the official instructions until the end of point 4.

In the configuration file /etc/coolwsd/coolwsd.xml we change the following settings:

Under <ssl desc="SSL settings"> we switch enable to false and terminationto true.

Furthermore, under <net desc="Network settings"> we set the proto to IPv4 (in case we have IPv4 als the internal IP protocol at our server).

Now, we can call the URL http://nx.example.com:9980 from our browser, and we should get an “OK” as answer. That means, that our Collabora Online instance is working.

Next, we have to make this instance available to our Nextcloud server. In order to do that, we first enable some additional Apache modules for reverse proxying:

a2enmod proxy
a2enmod proxy_http
a2enmod proxy_connect
a2enmod proxy_wstunnel

After that, we can create a new Apache config for our Collabora Online service:

<VirtualHost *:80>
    ServerAdmin webmaster@localhost
    ServerName co.example.com
    ServerAlias co.example.com

 ########################################
 # Reverse proxy for Collabora Online   #
 ########################################

 AllowEncodedSlashes NoDecode
 ProxyPreserveHost On

 # static html, js, images, etc. served from coolwsd
 # browser is the client part of Collabora Online
 ProxyPass           /browser http://127.0.0.1:9980/browser retry=0
 ProxyPassReverse    /browser http://127.0.0.1:9980/browser

 # WOPI discovery URL
 ProxyPass           /hosting/discovery http://127.0.0.1:9980/hosting/discovery retry=0
 ProxyPassReverse    /hosting/discovery http://127.0.0.1:9980/hosting/discovery

 # Capabilities
 ProxyPass           /hosting/capabilities http://127.0.0.1:9980/hosting/capabilities retry=0
 ProxyPassReverse    /hosting/capabilities http://127.0.0.1:9980/hosting/capabilities

 # Main websocket
 ProxyPassMatch      "/cool/(.*)/ws$"      ws://127.0.0.1:9980/cool/$1/ws nocanon

 # Admin Console websocket
 ProxyPass           /cool/adminws ws://127.0.0.1:9980/cool/adminws

 # Download as, Fullscreen presentation and Image upload operations
 ProxyPass           /cool http://127.0.0.1:9980/cool
 ProxyPassReverse    /cool http://127.0.0.1:9980/cool

 # Compatibility with integrations that use the /lool/convert-to endpoint
 ProxyPass           /lool http://127.0.0.1:9980/cool
 ProxyPassReverse    /lool http://127.0.0.1:9980/cool
</VirtualHost>

We activate this service by a2ensite co.example.com, restart Apache and make the service available as https with certbot -d co.example.com. Although we cannot access the service directly, this step is important for integration with the Nextcloud service, which is the last step.

We log into our Nextcloud server at https://nx.example.com, click at our avatar in the upper right corner and switch to + Apps. At the left pane, we then find under “Featured Apps” the “Nextcloud Office”, which we download and enable. Then, we head over to Avatar -> Administration Settings, click on the magnifying glass in the top pane and serach for “office”. We select “Office Administration”, select “Use your own server” and put in the URL https://co.example com.
This will NOT work using the same URL as for the nextcloud server, e.g. nx.example.com, even if both services are located at the same machine!

Last, we edit the Allow list for WOPI requests with the values 127.0.0.1, [our server's IP address] and set in /etc/php/8.3/php.ini the values

memory_limit = 512M
upload_max_filesize = 64M

With these settings, we should at least get no red errors at the Nextcloud admin page. Now, we should be able to open the supplied docx document as well. Further tweaking according to the linked documentation.

That’s it, we have an integrated Cloud/Docs server where we can migrate all our files and documents to!

(We can and should now close port 9980 tcp for any external access.)

]]>Running multiple Jekyll instances on one server2023-11-19T10:00:00+01:002023-11-19T10:00:00+01:00http://localhost:4000/doc/2023/11/19/multiple-jekyll-serversSince we have already learned how to set up a single Jekyll sever, the question may come up how to run two or more Jekyll instances in parallel on the same server. This is what we’ll explain in the following.

First, we create a new blog in our existing home directory:

sudo -i
su - jekyll
export GEM_HOME="/home/jekyll/gems"
export PATH="home/jekyll/gems/bin:$PATH"
jekyll new blog1

Now, we have to create the second jekyll service unit file as /lib/systemd/system/jekyll1.service:

[Unit]
Description=Jekyll service
After=syslog.target
After=network.target

[Service]
# Added solution -- add WorkingDirectory to directory where you clone your markdown files for Jekyll to render
WorkingDirectory=/home/jekyll/blog1
# Name of the user account that is running the Jekyll server
User=jekyll
Type=simple
# Location (source) of the markdown files to be rendered
ExecStart=/usr/bin/bash /home/jekyll/start1.sh
Restart=always
StandardOutput=journal
StandardError=journal
SyslogIdentifier=jekyll1

[Install]
WantedBy=multi-user.target

where the start1.sh script reads as

export GEM_HOME='/home/jekyll/gems' 
export PATH='/home/jekyll/gems/bin:$PATH'

cd /home/jekyll/blog1 
export BUNDLE_GEMFILE='/home/jekyll/blog1/Gemfile' 
bundle exec jekyll serve --host 127.0.0.1 --port 4001

For automated start on boot, we again have to link this service under /etc/systemd/system/multi-user.target.wants:

cd /etc/systemd/system/multi-user.target.wants
sudo ln -s /lib/systemd/system/jekyll1.service .
sudo systemctl daemon-reload

For now, we can start the service manually by sudo service jekyll1 start.

We leave the reverse proxy configuration for the jekyll instance on port 4001 as an exercise to the reader.

That’s it! Now we have a second Jekyll blog running SSL encrypted behind an Apache reverse proxy.

]]>Setup of a niltalk chatserver behind an Apache reverse https proxy2023-09-13T08:00:00+02:002023-09-13T08:00:00+02:00http://localhost:4000/doc/2023/09/13/niltalk-reverse-proxySince our generic proxy approach does not work out of the box for the niltalk chat server, we will see in this post how to put everything together for this case.

We assume thet we will run the talk server at the address https://talk.example.com.

Installing niltalk

Let’s login to out target machine and be sure, that we have no open port 9000 to the outer world.

If we do not want to build the server by ourselves, we get the binary:

user@talk.example.com:/home/user$ wget https://github.com/knadh/niltalk/releases/download/v0.1.1/niltalk_0.1.1_linux_amd64.tar.gz

After unpacking, we create a target directory

user@talk.example.com:/home/user$ sudo mkdir /opt/niltalk

and copy the binary there

user@talk.example.com:/home/user$ sudo cp niltalk /opt/niltalk

For the static web templates, we need to clone the niltalk git-respository

user@talk.example.com:/home/user$ git clone https://github.com/knadh/niltalk.git

and to copy the static directory also to the target folder:

user@talk.example.com:/home/user$ sudo cp niltalk/static /opt/niltalk

To create a configuration, we have to run the server with the command

user@talk.example.com:/opt/niltalk$ sudo niltalk --new-config

This creates a file config.toml that we can amend later on as needed. For now, it makes sense to set the storage to memory:

# Storage kind, one of redis|memory|fs.
storage = "memory"

# Redis cache server.
# Rooms are cached until they expires. Messages are not cached.
#[store]
#address = "redis:6379" # Eg: 127.0.0.1:6379
#password = ""
#db = 0
#active_conns = 100
#idle_conns = 20
#timeout = "3s"

#prefix_room = "NIL:ROOM:%s"
#prefix_session = "NIL:SESS:ROOM:%s"

# InMemory store config.
[store]
# no options available.

# FileSystem store config.
# [store]
# path = "db.json"

At this point we have the chat server installed. Running it by typing sudo /opt/nilserver/nilserver should result in an open port 9000.

Creating the service

Since we want to start the talk server by default, we create a service file /lib/systemd/system/niltalk.service with the following contents:

[Unit]
Description=niltalk server
After=multi-user.target

[Service]
WorkingDirectory=/opt/niltalk
ExecStart=/opt/niltalk/niltalk --static-dir=/opt/niltalk/static
ExecReload=/bin/kill -HUP $MAINPID

[Install]
WantedBy=multi-user.target

We enable the service by linking it to the right place:

user@talk.example.com:/etc/systemd/system/multi-user.target.wants$ sudo ln -s /lib/systemd/system/niltalk.service .

Now we should be able to start and stop the service using the sudo service niltalk start and sudo service niltalk stop commands, respectively.

Apache reverse proxy

The standard approach does not work here. The talk server is using web sockets, which are not proxied/rewritten by default. So we have to amend our configuration to do that.

But first, we can go with the “standard” approach to get the certificate. The Apache talk.example.com.conf configuration reads as

<VirtualHost *:80>
        ServerAdmin webmaster@localhost
        ServerName talk.example.com
        ServerAlias talk.example.com
        ProxyPreserveHost On
        ProxyPass / http://127.0.0.1:9000/
        ProxyPassReverse / http://127.0.0.1:9000/
</VirtualHost>

So we get our certificate via sudo certbot --apache -d talk.example.com.

But now we have to add some configuration on the newly created talk.example.com-le-ssl.conf:

<IfModule mod_ssl.c>
<VirtualHost *:443>
        ServerAdmin webmaster@localhost
        ServerName talk.example.com
        ServerAlias talk.example.com

        ProxyPreserveHost On
        ProxyRequests Off
        RewriteEngine On

        RewriteCond %{HTTP:UPGRADE} ^WebSocket$           [NC,OR]
        RewriteCond %{HTTP:CONNECTION} ^Upgrade$          [NC]
        RewriteRule .* ws://127.0.0.1:9000%{REQUEST_URI}  [P,QSA,L]
        RewriteCond %{DOCUMENT_ROOT}/%{REQUEST_FILENAME} !-f
        RewriteRule .* http://127.0.0.1:9000%{REQUEST_URI} [P,QSA,L]
        RequestHeader set X-Forwarded-Proto "https"

        <Location />
                Require all granted
                ProxyPassReverse http://127.0.0.1:9000/
                ProxyPassReverseCookieDomain 127.0.0.1 talk.example.com
        </Location>

SSLCertificateFile /etc/letsencrypt/live/talk.example.com/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/talk.example.com/privkey.pem
Include /etc/letsencrypt/options-ssl-apache.conf
</VirtualHost>
</IfModule>

So basically, we are enabling the websocket use for our proxy.

In order to avoid client reconnection every 5 minutes, we use a (maybe dirty, I’m open for better solutions) workaround and set the connection timeout in /etc/apache2/apache2.conf to 12 hours:

Timeout 43200

In order to get this all working, we have to enable the Apache headers module and to restart the webserver:

$ sudo a2enmod headers
$ sudo service apache2 restart

Finally, we have to set the right IP and URL in our niltalk config file /opt/niltalk/config.toml:

[app]
# Address to listen, use "tor" to run an hidden service.
# address = "0.0.0.0:9000"
address = "127.0.0.1:9000"

# No trailing slashes.
root_url = "https://talk.example.com"

After restarting the chat server by

$ sudo service niltalk stop
$ sudo service niltalk start

we are done.

That’s it! Now we have a niltalk chatserver behind an Apache reverse https proxy.

Main source for the Apache config part: mattermost.

]]>Setup of a CalDAV server (Radicale) and integration with Mozilla Thunderbird2023-08-13T11:00:00+02:002023-08-13T11:00:00+02:00http://localhost:4000/doc/2023/08/13/caldav-server-and-thunderbird-integrationGoal of this article is to document the setup of the CalDAV server “Radicale” for synchronizing calendars between different Thunderbird clients on Ubuntu 22.04.x.

Install the CalDAV server

So, let’s assume we have an Ubuntu 22.04.x installation with running Apache on a remote machine with DNS name caldav.example.org running a ssh server. First, we become root:

sudo -i

Next, we install everything that is needed to run the Radicale 2 server:

apt-get install radicale python3-bcrypt python3-passlib apache2-utils

In the configuration file /etc/radicale/config, the following entries have to be modified:

[server]
hosts = localhost:5232
ssl = False

[auth]
type = htpasswd
htpasswd_filename = /etc/radicale/users
htpasswd_encryption = bcrypt

Now we add a user whose calendar should be synchronized:

sudo htpasswd -c -B /etc/radicale/users user01

To avoid acess rights problems, we have to change ownership of the Radicale files to the respective user:

chown -R radicale:radicale /var/lib/radicale

We can now start the server by executing the command

systemctl start radicale.service

Now we have a local running Radicale CalDAV server at port 5232:

# netstat -anp | grep 5232
tcp        0      0 127.0.0.1:5232          0.0.0.0:*               LISTEN      301430/python3

Eveen tough Radicale comes with an option to use SSL certificates, we set up a reverse proxy instead to include the certbot functionality, following the article Generic setup of a https nginx/Apache reverse proxy. Obviously, the settings here are

        ServerName caldav.example.org
        ServerAlias caldav.example.org

and

        ProxyPass / http://127.0.0.1:5232/
        ProxyPassReverse / http://127.0.0.1:5232/

After retrieving the SSL certificates via certbot, we should see a login page with user and password input fields when calling https://caldav.example.org in a browser, and we should be able to login with user01 and the corresponding password that we have created before.

We have two links available, one for creating a new addressbook or calendar and one for uploading an addressbook or calendar. For now, we can leave everything as it is, as we go for the Thunderbird integration, after finally enabling the server for automatic start:

systemctl enable radicale.service

Use CalDAV with Thunderbird

UPDATE 2025-11-01: The solution written below is outdated, there’s now a canonical way to use CalDAV with Thunderbird without addons, documented here.
Thanks to Nick for pointing that out to me.

That’s quite easy: Via Tools -> Addons and Themes we install the addons TbSync and Provider for CalDAV & CardDAV.

Then, via Edit -> Synchronization Settings (TbSync) we go to Account actions -> Add new account -> CalDAV & CardDAV. There we choose Manual configuration (since the automatic one does not work with our Radicale server, not sure if this is a server or a Thunderbird bug).

Now we return to our Radicale web frontend where we can either create a new calendar from scratch or by uploading an existing ICS file. In both cases, a new resource entry will be created, that provides an URL of the form https://caldav.example.org/user01/[some UUID]. We copy this URL to the clipboard and paste it into the Thunderbird CalDAV account information mask. Finally, we create an account name and register the user credentials (user01 plus password).

On the General Tab of the TbSync account settings, we can now enable the synchronization of the just created account and trigger a first sync via Synchronize now. After setting the Periodic synchronization to 10 minutes (or whatever you like), the Thunderbird configuration for CalDAV is done. These steps, of course, have to be repeated for every Thunderbird client that should use the calendar synchronization for user01.

That’s it! Now we have set up the CalDAV server “Radicale” for synchronizing calendars between different Thunderbird clients on Ubuntu 22.04.x.

]]>Setup of a Guacamole HTML5 remote XFCE desktop via VNC for Ubuntu 22.042023-04-03T11:00:00+02:002023-04-03T11:00:00+02:00http://localhost:4000/doc/2023/04/03/remote-vm-with-xfceTHIS POST IS OUTDATED See updated post.

Goal of this article is to document the setup of a Guacamole HTML5 remote XFCE desktop via VNC on Ubuntu 22.04.x. The Guacamole setup is based on Ubuntu 20.04.x LTS - Guacamole HTML5 Remotedesktop Gateway installieren mit Apache Reverse Proxy (in german, written by Bernhard Linz)

Install the guacamole server

So, let’s assume we have a fresh Ubuntu 22.04.x installation on a remote machine with DNS name test.example.org running a ssh server. First, we become root:

sudo -i

Next, we install everything that is needed to run the Apache Tomcat server:

apt install make libssh2-1-dev libtelnet-dev libpango1.0-dev libossp-uuid-dev libcairo2-dev libpng-dev libssh2-1 libvncserver-dev libvorbis-dev  gcc libssh-dev libpulse-dev tomcat9 tomcat9-admin tomcat9-docs ghostscript libwebp-dev libavcodec-dev libavutil-dev libswscale-dev libjpeg-turbo8-dev libtool-bin libossp-uuid-dev libavformat-dev freerdp2-dev libwebsockets-dev libssl-dev

Now, on calling http://test.example.org:8080 we should see the standard Apache Tomcat “It works!” page.

As of April 2023, the current Guacamole version is 1.5.1, so we download the following files:

cd /usr/src
wget https://downloads.apache.org/guacamole/1.5.1/source/guacamole-server-1.5.1.tar.gz
wget https://downloads.apache.org/guacamole/1.5.1/binary/guacamole-1.5.1.war

So we have server source code and client binary.

Now we unpack the server code

tar xvzf guacamole-server-1.5.1.tar.gz

and compile it:

cd /usr/src/guacamole-server-1.5.1
./configure --with-systemd-dir=/etc/systemd/system

That should result in an output like this:

------------------------------------------------
guacamole-server version 1.5.1
------------------------------------------------

   Library status:

     freerdp2 ............ yes
     pango ............... yes
     libavcodec .......... yes
     libavformat.......... yes
     libavutil ........... yes
     libssh2 ............. yes
     libssl .............. yes
     libswscale .......... yes
     libtelnet ........... yes
     libVNCServer ........ yes
     libvorbis ........... yes
     libpulse ............ yes
     libwebsockets ....... yes
     libwebp ............. yes
     wsock32 ............. no

   Protocol support:

      Kubernetes .... yes
      RDP ........... yes
      SSH ........... yes
      Telnet ........ yes
      VNC ........... yes

   Services / tools:

      guacd ...... yes
      guacenc .... yes
      guaclog .... yes

   FreeRDP plugins: /usr/lib/x86_64-linux-gnu/freerdp2
   Init scripts: no
   Systemd units: /etc/systemd/system

Type "make" to compile guacamole-server.

If that’s the case as all “yes”-entries are present, we can compile:

make
make install

Last we have to configure the dynamic linker run-time bindings:

ldconfig

Now we can start the systemd service that the installation has provided:

systemctl start guacd.service
systemctl status guacd.service

which should give us an output like

● guacd.service - Guacamole Server
     Loaded: loaded (/etc/systemd/system/guacd.service; disabled; vendor preset: enabled)
     Active: active (running) since Fri 2023-04-21 14:52:28 UTC; 6s ago
       Docs: man:guacd(8)
   Main PID: 47807 (guacd)
      Tasks: 1 (limit: 2233)
     Memory: 10.2M
        CPU: 10ms
     CGroup: /system.slice/guacd.service
             └─47807 /usr/local/sbin/guacd -f

Apr 21 14:52:28 test181 systemd[1]: Started Guacamole Server.
Apr 21 14:52:28 test181 guacd[47807]: Guacamole proxy daemon (guacd) version 1.5.1 started
Apr 21 14:52:28 test181 guacd[47807]: guacd[47807]: INFO:        Guacamole proxy daemon (guacd) version 1.5.1 started
Apr 21 14:52:28 test181 guacd[47807]: guacd[47807]: INFO:        Listening on host 127.0.0.1, port 4822
Apr 21 14:52:28 test181 guacd[47807]: Listening on host 127.0.0.1, port 4822

We stop the server in order to amend configurations:

systemctl stop guacd.service

First we create the directory

mkdir /etc/guacamole

There we create a file /etc/guacamole/guacamole.properties with the content

basic-user-mapping: /etc/guacamole/user-mapping.xml

For our purposes, this file reads like

<user-mapping>
        <!-- Per-user authentication and config information -->
        <!-- FIRST USER -->
        <authorize 
                username="test01"
                password="52c88bca7c5b3ab3e7ed8901ea1bc83f"
                encoding="md5">
                <!-- First authorized Remote connection -->
                <connection name="SSH Admin">
                        <protocol>ssh</protocol>
                        <param name="hostname">10.10.10.10</param>      
                        <param name="port">22</param>                    
                        <param name="username">test01</param>     
                        <param name="enable-sftp">true</param>
                </connection> 
                <!-- second authorized Remote connection -->
                <connection name="Terminal Server VNC">
                        <protocol>vnc</protocol>
                        <param name="hostname">127.0.0.1</param> 
                        <param name="port">5901</param>         
                        <param name="server-layout">de-de-qwertz</param>
                </connection>
        </authorize>
</user-mapping>

Of course we have to amend hostname, username, and password for our system.

The password hash can be created by

echo -n 'secretPassword' | md5sum

Finally, we have to append the Guacamole home to the environment:

echo GUACAMOLE_HOME="/etc/guacamole" >> /etc/environment

It makes sense to reboot at this point.

Now we enable the Guacamole service for automated start:

systemctl enable guacd.service

Next, we install the client:

cp /usr/src/guacamole-1.5.1.war /var/lib/tomcat9/webapps/guacamole.war

Then we have to link the property directory to the place where it is expected:

ln -s /etc/guacamole /usr/share/tomcat9/.guacamole

To speed up the tomcat restart, we have to create the following file

touch /usr/share/tomcat9/bin/setenv.sh
chmod +x /usr/share/tomcat9/bin/setenv.sh

with this content:

#!/bin/sh
export CATALINA_OPTS="$CATALINA_OPTS -Djava.security.egd=file:/dev/./urandom"

Now we can start the guacamole server:

systemctl start guacd.service

If we now browse to

http://test.example.org:8080/guacamole/

we should be offered a login and then the connection options “SSH Admin” and “Terminal Server VNC”.

The SSH connection should work already, for the VNC we need to prepare some more things, as follows.

Install the VNC server

Let’s assume that we have a user test01 as our (sudo-enabled) standard user for the machine we just prepared, and that we are now logged in as that user.

We install the needed stuff:

sudo apt install -y xfce4 xfce4-goodies tightvncserver autocutsel xfonts-base xfonts-100dpi xfonts-75dpi

Then we create a vnc password for our user:

vncpasswd

Next, we have to create the vnc startup file in our home directory and make it executable:

touch ~/.vnc/xstartup
chmod 755 ~/.vnc/xstartup

The contents of this file is

#!/bin/sh
unset SESSION_MANAGER
unset DBUS_SESSION_BUS_ADDRESS
DBUS_SESSION_BUS_ADDRESS=unix:path=$XDG_RUNTIME_DIR/bus
exec startxfce4

For starting the VNC server on boot, we normally would need a service file /etc/systemd/system/vncserver@.service, as suggested by Install Xfce VNC remote desktop on Ubuntu. Unfortunately, for Ubuntu 22.04.x this method does not longer work (it will give some mysterious “/usr/bin/startxfce4: X server already running on display :1” log entry), and we have to find a workaround. This goes as follows:

We want to login automatically on boot, so we create a service unit /lib/systemd/system/getty@.service as follows:

#  SPDX-License-Identifier: LGPL-2.1-or-later
#
#  This file is part of systemd.
#
#  systemd is free software; you can redistribute it and/or modify it
#  under the terms of the GNU Lesser General Public License as published by
#  the Free Software Foundation; either version 2.1 of the License, or
#  (at your option) any later version.

[Unit]
Description=Getty on %I
Documentation=man:agetty(8) man:systemd-getty-generator(8)
Documentation=http://0pointer.de/blog/projects/serial-console.html
After=systemd-user-sessions.service plymouth-quit-wait.service getty-pre.target
After=rc-local.service

# If additional gettys are spawned during boot then we should make
# sure that this is synchronized before getty.target, even though
# getty.target didn't actually pull it in.
Before=getty.target
IgnoreOnIsolate=yes

# IgnoreOnIsolate causes issues with sulogin, if someone isolates
# rescue.target or starts rescue.service from multi-user.target or
# graphical.target.
Conflicts=rescue.service
Before=rescue.service

# On systems without virtual consoles, don't start any getty. Note
# that serial gettys are covered by serial-getty@.service, not this
# unit.
ConditionPathExists=/dev/tty0

[Service]
# the VT is cleared by TTYVTDisallocate
# The '-o' option value tells agetty to replace 'login' arguments with an
# option to preserve environment (-p), followed by '--' for safety, and then
# the entered username.
ExecStart=-/sbin/agetty --autologin test01 --noclear %I $TERM
Type=idle
Restart=always
RestartSec=0
UtmpIdentifier=%I
TTYPath=/dev/%I
TTYReset=yes
TTYVHangup=yes
TTYVTDisallocate=yes
IgnoreSIGPIPE=no
SendSIGHUP=yes

# Unset locale for the console getty since the console has problems
# displaying some internationalized messages.
UnsetEnvironment=LANG LANGUAGE LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT LC_IDENTIFICATION

[Install]
WantedBy=getty.target
DefaultInstance=tty1

In the Service section, we replace test01 by the username of our local user.

If the service should not be enabled by default, we make the service available at boot time by

cd /etc/systems/system/getty.target.wants/
sudo ln -sf /lib/systemd/system/getty@.service .

To start the VNC server after the automatic login, we append the following line to our ~/.bashrc:

echo "/usr/bin/vncserver :1 -depth 24 -geometry 1920x1080 -localhost" >> ~/.bashrc

Time for a last reboot!

Then, we should be able to login to http://test.example.com:8080/guacamole with the credentials we stored in /etc/guacamole/user-mapping.xml, click on “Terminal Server VNC”, type in the VNC password we have defined before, and see a virtual XFCE screen in our browser.

That’s it! Now we have set up a Guacamole HTML5 remote XFCE desktop via VNC for Ubuntu 22.04.

For security reasons, it makes absolutely sense to add a 2FA as described in the already mentioned (german) article by Bernhard Linz. For security reasons, it makes also sense to map the Tomcat (http port 8080) via Apache or nginx reverse proxy to https, as described here in my blog.

]]>Generic setup of a https nginx/Apache reverse proxy2023-03-20T07:00:00+01:002023-03-20T07:00:00+01:00http://localhost:4000/doc/2023/03/20/reverse-proxyAssume we have a web site engine (web server, blog, shellinabox, you name it) running in your private network at ip 10.10.10.10 port 3500, serving http.

We want to expose this local/intern web service to the internet, without giving the internet access to our local machine. We want to use the https-protocol and proxy via web server nginx or Apache, using a (sub)domain that we own, let’s assume for simplifying reasons that this is https://sub.example.com.

Here we look at two very basic proxy setups to realize this task.

nginx

So, given that nginx is already installed, for the proxy functionality, at the server that serves https://sub.example.com, we configure a nginx site as /etc/nginx/sites-available/sub.example.com:

#
# Virtual Host configuration nginx
#

server {
        listen 80;
        server_name sub.example.com;
        
        location / {
                proxy_pass http://10.10.10.10:3500/;
                proxy_set_header Host $host;
        }
}

Next, we install certbot for obtaining SSL certificates for our server:

sudo apt-get install certbot python3-certbot-nginx

Now we have to make our website public, in order that certbot can obtain a certificate from Let’s Encrypt via the ACME protocol. We do that by making the site available:

sudo ln -s /etc/nginx/sites-available/sub.example.com /etc/nginx/sites-enabled

After that, we have to reload the nginx configuration:

sudo service nginx reload

Now we should be able to access our server via http://sub.example.comwhich is internally served by http://10.10.10.10:3500.

To obtain the certificate, we now run

sudo certbot --nginx -d sub.example.com

This will provide our server with a Let’s Encrypt certificate, create and enable a new nginx ssl configuration /etc/nginx/sites-available/sub.example.com-ssl, and modify the original config enable SSL. The automatically changed config file should now read like

#
# Virtual Host configuration nginx
#

server {
        server_name sub.example.com;
        
        location / {
                proxy_pass http://10.10.10.10:3500/;
                proxy_set_header Host $host;
        }

    listen 443 ssl; # managed by Certbot
    ssl_certificate /etc/letsencrypt/live/sub.example.com/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/sub.example.com/privkey.pem; # managed by Certbot
    include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot
}

server {
    if ($host = sub.example.com) {
        return 301 https://$host$request_uri;
    } # managed by Certbot

        listen 80;
        server_name sub.example.com;
    return 404; # managed by Certbot
}

That’s it! Now we have a local/intern web service exposed to the internet using the https-protocol via nginx.

Apache

Again we assume that the web server itself is already installed. So we configure at the server that serves https://sub.example.com an Apache site as /etc/apache2/sites-available/sub.example.com.conf:

#
# Virtual Host configuration Apache
#
<VirtualHost *:80>
        ServerAdmin webmaster@localhost
        ServerName sub.example.com
        ServerAlias sub.example.com
        ProxyPreserveHost On
        
        ProxyPass / http://10.10.10.10:3500/
        ProxyPassReverse / http://10.10.10.10:3500/
</VirtualHost>

For the proxy configuration to work, we want to be sure to have proxy functionality enabled:

sudo a2enmod proxy
sudo a2enmod proxy_http
sudo systemctl restart apache2

Next, we install certbot for obtaining SSL certificates for our server:

sudo apt-get install certbot python3-certbot-apache

Now we have to make our website public, in order that certbot can obtain a certificate from Let’s Encrypt via the ACME protocol. We do that by making the site available:

sudo a2ensite sub.example.com.conf

After that, we have to restart Apache:

sudo service apache2 restart

Now we should be able to access our server via http://sub.example.comwhich is internally served by http://10.10.10.10:3500.

To obtain the certificate, we now run

sudo certbot --apache -d sub.example.com

This will provide our server with a Let’s Encrypt certificate, create and enable a new Apache ssl configuration /etc/apache/sites-available/sub.example.com-le-ssl.conf, and modify the original config to redirect from http to https. The automatically created config file should read like

#
# Virtual Host configuration Apache
#
<IfModule mod_ssl.c>
<VirtualHost *:443>
        ServerAdmin webmaster@localhost
        ServerName sub.example.com
        ServerAlias sub.example.com
        ProxyPreserveHost On
        
        ProxyPass / http://10.10.10.10:3500/
        ProxyPassReverse / http://10.10.10.10:3500/

SSLCertificateFile /etc/letsencrypt/live/sub.example.com/fullchain.pem;
SSLCertificateKeyFile /etc/letsencrypt/live/sub.example.com/privkey.pem;
Include /etc/letsencrypt/options-ssl-apache.conf
</VirtualHost>
</IfModule>

That’s it! Now we have a local/intern web service exposed to the internet using the https-protocol via Apache.

]]>Setting up a Jekyll server with Apache reverse proxy2023-03-19T10:00:00+01:002023-03-19T10:00:00+01:00http://localhost:4000/doc/2023/03/19/jekyll-serverOK, this site runs as a Jekyll blog, so how do we do that?

First, we install Jekyll at the intended server, for Ubuntu:

sudo apt-get install ruby-full build-essential zlib1g-dev

Then, we add a designated user to run the blog:

sudo useradd jekyll

After that, we export some necessary variables for the next step:

sudo -i
su - jekyll
export GEM_HOME="/home/jekyll/gems"
export PATH="home/jekyll/gems/bin:$PATH"

To complete the Jekyll installation, we install the necessary Ruby components. Be sure that you are user jekyll and inside the /home/jekyll directory:

gem install jekyll bundler

Then, we create a new blog:

jekyll new blog

Finally, we have to create the service unit file as /lib/systemd/system/jekyll.service:

[Unit]
Description=Jekyll service
After=syslog.target
After=network.target

[Service]
# Added solution -- add WorkingDirectory to directory where you clone your markdown files for Jekyll to render
WorkingDirectory=/home/jekyll/blog
# Name of the user account that is running the Jekyll server
User=jekyll
Type=simple
# Location (source) of the markdown files to be rendered
ExecStart=/usr/bin/bash /home/jekyll/start.sh
Restart=always
StandardOutput=journal
StandardError=journal
SyslogIdentifier=jekyll

[Install]
WantedBy=multi-user.target

where the start.sh script reads as

export GEM_HOME='/home/jekyll/gems' 
export PATH='/home/jekyll/gems/bin:$PATH'

cd /home/jekyll/blog 
export BUNDLE_GEMFILE='/home/jekyll/blog/Gemfile' 
bundle exec jekyll serve --host 127.0.0.1 --port 4000

For automated start on boot, we have to link this service under /etc/systemd/system/multi-user.target.wants:

cd /etc/systemd/system/multi-user.target.wants
sudo ln -s /lib/systemd/system/jekyll.service .
sudo systemctl daemon-reload

For now, we can start the service manually by sudo service jekyll start.

For the proxy configuration to work, we want to be sure to have proxy functionality enabled:

sudo a2enmod proxy
sudo a2enmod proxy_http
sudo systemctl restart apache2

So, our Jekyll blog server is at present running at port 4000 localhost.
To publish it, we have to amend the Apache configuration as follows.

/etc/apache2/sites-available/blog.example.com.conf:

<VirtualHost *:80>
    ServerAdmin webmaster@localhost
    ServerName blog.example.com
    ServerAlias blog.example.com

    ProxyPass / http://127.0.0.1:4000/
    ProxyPassReverse / http://127.0.0.1:4000/

    ErrorLog ${APACHE_LOG_DIR}/blog.example.com.error.log
    CustomLog ${APACHE_LOG_DIR}/access.log vhost_combined
</VirtualHost>

Now it’s time to restart the web server:

sudo service apache2 restart

Then, given that certbot is installed, run

certbot --apache -d blog.example.com

in order to create a SSL-encrypted site.

That’s it! Now we have a Jekyll blog running SSL encrypted behind an Apache reverse proxy.

This post was updated 2023-11-19 to fix/clarify some service related details.

]]>