Scenario:

In Ansible you have a list of dictionaries containing some values, e.g. a list of mount points:

mymounts:
  basedir: /srv/mymounts
  mounts:
    -
      name: first_mount
      opts: defaults
    -
      name: second_mount
      opts: noauto,x-systemd.automount,_netdev,reconnect
    -
      name: third_mount
      opts: defaults

And you want to extract a list of mount pathes combined from basedir and name for further usage, so the result looks like this:

['/srv/mymounts/first_mount', '/srv/mymounts/second_mount', '/srv/mymounts/third_mount']

I recently stumbled over a problem on my notebook running Ubuntu 16.04 “Xenial Xerus”. When trying to connect to a new, protected Wi-Fi network no password dialogue appeared, making a quick GUI connection impossible. Creating the connection manually, entering the Wi-Fi password in the “Wi-Fi-Security” setting in the process worked like a charm. Using nmtui from the terminal also worked flawlessly.

As I didn’t connect the notebook to new Wi-Fi networks in months, I didn’t encounter this error for a long time. Therefore I had a lot of problems debugging it as I installed bazillions of updates and new packages in the meantime.

I narrowed the problem down to NetworkManager not having a way of saving the Wi-Fi password, which is normally done via gnome-keyring, specifically via gnome-keyring-daemon. The daemon didn’t seem to start properly, but even starting it manually still didn’t make a difference. The logs still complained:

Okt 17 06:58:53 XPS13 NetworkManager[1064]: <info>  [1508216333.3058] device (wlan0): Activation: (wifi) access point 'MyTest' has security, but secrets are required.
Okt 17 06:58:53 XPS13 NetworkManager[1064]: <info>  [1508216333.3062] device (wlan0): state change: config -> need-auth (reason 'none') [50 60 0]
Okt 17 06:58:53 XPS13 NetworkManager[1064]: <warn>  [1508216333.3062] device (wlan0): No agents were available for this request.

Finally I found the solution in an askubuntu question. Nearly half a year ago I installed Flatpak so I could install FeedReader. One of the dependencies was dbus-user-session. This package seems to have problems with the gnome-keyring-daemon in 16.04 rendering it defective. Purging the dbus-user-session package and its dependencies solved my problem and the Wi-Fi password dialogue appeared once again.

apt purge dbus-user-session xdg-desktop-portal xdg-desktop-portal-gtk

I still had a problem with the NetworkManager applet in the tray, but this could be fixed with an apt install --reinstall network-manager-gnome and a reboot afterwards.

Nearly two months ago I published my OpenSSL scribblings post. This one is the spiritual successor, addressing Java Keystore handling this time. There are already a lot of good web sites on how to handle the keytool, so I will limit myself to the issues I encounter from time to time which are more difficult to figure out. Similar to the last post I will use COMODO as CA and ssl.example.org as domain.

Adding a new certificate to a keystore

Requirements:

• The full certificate chain
• The certificate itself
• The certificate private key

First concatenate the cert chain if not already in one file. A Comodo speciality is the occasional inclusion of Windows line breaks, so we use sed for output to substitute any occurence of these. Additionally we ensure that the certificate starts on a newline:

sed -e 's/\r$/\n/g' root-ca.pem intermediate-ca.pem > cabundle.pem

I’m currently running a couple of tests with Docker swarm mode on Scaleway. For those who don’t know Scaleway, it’s a PaaS provider which is part of online.net. Due to capped maximum prices per month and no Ingress/egress prices it’s good for smaller projects.

But small prices often also mean a couple of limitations as well. In my case I wasn’t able to run Docker swarm mode properly. I tried running a stack with a couple of web servers and Traefik as Reverse Proxy, but for some reason this didn’t work. When running a Traefik container manually in Docker, everything worked fine. But as soon as I tried using it in swarm mode context, there was no connectivity. Dockers logs showed some strange errors similar to these:

Apr 14 20:39:40 <hostname> docker[15787]: time="2017-04-14T20:39:40Z" level=error msg="Failed to write to /proc/sys/net/ipv4/vs/conntrack: open /proc/sys/net/ipv4/vs/conntrack: nno such file or directory"
Apr 14 20:39:40 <hostname> docker[15787]: time="2017-04-14T20:39:40.154260407Z" level=error msg="Failed to add firewall mark rule in sbox ingress (ingress): reexec failed: exit status 8"
Apr 14 20:41:17 <hostname> docker[15787]: time="2017-04-14T20:41:17.432619182Z" level=error msg="Failed to delete real server 10.255.0.3 for vip 10.255.0.2 fwmark 259 in sbox ingress (ingress): no such process"
Apr 14 20:41:17 <hostname> docker[15787]: time="2017-04-14T20:41:17.432762944Z" level=error msg="Failed to delete service for vip 10.255.0.2 fwmark 259 in sbox ingress (ingress): no such process"

From time to time I need to test the connectivity of applications listening on a port which has not yet been opened in the firewall. Therefore I use iptables to redirect an open port to the port the application is listening on. Lets assume I want to redirect port 80 to 8080 and port 443 to port 8443. Here’s how to do it:

First enable IP Forwarding

sysctl -w net.ipv4.ip_forward=1

Afterwards enable the redirection for said ports

iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j REDIRECT --to-port 8080
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 443 -j REDIRECT --to-port 8443

Optional: If you also want to redirect the port on the local machine, you have to set an additional iptables rule

iptables -t nat -I OUTPUT -p tcp -o lo --dport 80 -j REDIRECT --to-port 8080
iptables -t nat -I OUTPUT -p tcp -o lo --dport 443 -j REDIRECT --to-port 8443

This is of course not reboot safe. For reboot safety you need to set ip_forward in the /etc/sysctl.conf or a respective /etc/sysctl.d/ file and use the iptables-restore functionality of your distribution.

PS: This could of course also be used to circumvent firewall restrictions, e.g. to connect to SSH via another port without reconfiguring sshd. Do this at your own risk!