Simon Krenger

As I am a big fan of Traefik myself and this blog is running also with Traefik in place, so I took the time to contribute support for Traefik v2 configuration to the Mozilla SSL Configuration Generator (GitHub).

In the past few months, on all my machines I have replaced Docker with Podman and mostly the transition has been quite smooth. There are still some rough edges here and there, but the overall experience of using Podman has been great!

However, when trying to start a very simple container, one often runs into the following issue:

$ podman run -p80:80 nginx:latest 
Error: error from slirp4netns while setting up port redirection: map[desc:bad request: add_hostfwd: slirp_add_hostfwd failed]

The error message looks very cryptic, but the issue is quite simple: As a regular user, one is typically not allowed to bind ports < 1024. So by trying to bind port 80, you will get the error above.

The fix is trivial, just use a port greater than 1024:

$ podman run -p8080:80 -d nginx:latest 
22d2be2966e9cb77246a8b698f9024de89f4e6d1a0edfe44209bbe4fd27aa8b5
$ curl localhost:8080
[..]
Welcome to nginx!
[..]

If you really need to use a port number lower than 1024, there are multiple ways to configure that:

• Set net.ipv4.ip_unprivileged_port_start=80or similar in your sysctl
• Add the CAP_NET_BIND_SERVICE capability to your process or user

For a few years now I have been using the pass password manager. It is a wonderfully simple way to manage passwords using PGP to encrypt passwords in text files. The same files can then be placed in a git repository, which makes replicating passwords easy.

For different reasons I am now migrating to gopass, a Go implementation of pass with a few additional features. I am using Homebrew to install gopass on my machine: brew install gopass. Theoretically, gopass should work out-of-the-box and is compatible with the old pass utility. So I was quite surprised to see an error message like this:

$ gopass github
Entry 'github' not found. Starting search...
Found exact match in 'github.com/simonkrenger'
gpg: decryption failed: No secret key

Error: failed to retrieve secret 'github.com/simonkrenger': Failed to decrypt

Strange. But decrypting the password file directly using PGP works fine:

$ gpg -d ~/.password-store/github.com/simonkrenger.gpg
[..]

If the above command using gpg does not work, check your keys using gpg --list-keys and gpg --list-secret-keys. Especially when migrating to GPG2, sometimes keys do not get imported into the new keyrings. In case you need to import the old keyring into the new format like so:

$ gpg --import ~/.gnupg/pubring.gpg
$ gpg --import ~/.gnupg/secring.gpg

But even after importing the keys, I still received gpg: decryption failed: No secret key. So after searching around I found that I need to set the GPG_TTY variable:

$ export GPG_TTY=$(tty)

It seems that not setting the GPG_TTY environment variable leads to the error above. Which is quite misleading. After setting this environment variable (and adding it to the .bash_profile), gopass works as expected.

If you have worked with remote Linux servers before, I am guessing you already encountered machines that just don’t want to reboot. This is typically due screwed-up network mounts or stuck processes, so the server will hang during shutdown. But it turns out that there are other ways to reboot a server.

One of these is the “Magic SysRq key“. To reboot a server using the SysRq trigger in the kernel, use the following two commands. First, enable the trigger:

echo 1 > /proc/sys/kernel/sysrq

Then, reboot the server the magic way by typing

echo b > /proc/sysrq-trigger

Note that this will reboot the server without unmounting or syncing the filesystems! There are also other options available via the SysRq trigger, some of them are listed in the Wikipedia article above.

So I started working with GitLab (self-hosted and gitlab.com), which led me to the CI/CD features of GitLab. When using GitLab, one can define a custom CI pipeline just by placing a .gitlab-ci.yml file in your project (just like the .travis.yml for GitHub). After each commit to the defined git branch, the pipeline is then executed.

Since I also work with Ansible playbooks a lot, I wanted to use ansible-lint to check my playbooks after each commit. In addition to that, I also added a syntax check using ansible-playbook [..] --syntax-check, as ansible-lint will not pick up all syntax errors.

So here is my .gitlab-ci.yml:

I am currently toying around with GlusterFS and I am using Ansible to deploy and configure my server.

Using the yum module, I wanted to install the Gluster server package like so:

- name: Install glusterfs-server package
  yum:
    name: glusterfs-server
    state: latest

But when executing the playbook, I received the following error on executing this module:

As I am working more and more with Linux, I am also using a virtual machine with Fedora 25 installed to play around with some things (notably Docker and Kubernetes). On Fedora 25, the default GNOME desktop environment is GNOME 3. But I personally prefer the GNOME Classic user interface.

To change the desktop environment, on login, select “GNOME Classic” as the desktop environment:

Some years ago, I wrote some examples for the WMI client on Linux. I still get a lot of queries from people trying to use the WMI client to access Windows hosts and I am often happy to help if there are any problems.

One of the latest problems occurred when trying to access a Windows host over IPv6:

$ wmic -U 'user%password' //FD00:180::0:0:0:0:0 "Select Caption From Win32_OperatingSystem" [..] UNKNOWN - The WMI query had problems. The error text from wmic is: [librpc/rpc/dcerpc_util.c:343:dcerpc_parse_binding()] Unknown dcerpc transport 'FD00' [librpc/rpc/dcerpc_connect.c:337:dcerpc_pipe_connect_ncacn_ip_tcp_recv()] failed NT status (c0000017) in dcerpc_pipe_connect_ncacn_ip_tcp_recv [librpc/rpc/dcerpc_connect.c:828:dcerpc_pipe_connect_b_recv()] failed NT status (c0000017) in dcerpc_pipe_connect_b_recv [wmi/wmic.c:196:main()] ERROR: Login to remote object. NTSTATUS: NT_STATUS_NO_MEMORY - Memory allocation error

This was quite a funny problem, because the same query seemed to work when accessing the host over IPv4. So we quickly suspected that the WMI client does not support IPv6. By looking at the underlying Samba code (e.g. dcerpc_util.c and binding.c), I guessed that this seems to be a parsing issue of some kind.

So today I tried to install the Oracle Preinstall RPM on a freshly installed Oracle Linux 7 machine. However, when I executed yum search rdbms the preinstall package was nowhere to be seen!

It turns out that we need to enable the Oracle Linux 7 “addons” repository in order to find the package. Swiss blogger Martin Berger put me on the right track.

To enable the repository, open the file /etc/yum.repos.d/public-yum-ol7.repo and find the following repository entry:

So lately I have been working a lot more with Linux networking. Consider an iptables configuration like this:

*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [7752:8249066]
[..]
-A RH-Firewall-1-FORWARD -p icmp -m icmp --icmp-type any -j ACCEPT 
-A RH-Firewall-1-FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT 
-A RH-Firewall-1-FORWARD -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT 
[..]
-A RH-Firewall-1-INPUT -j REJECT --reject-with icmp-host-prohibited 
COMMIT
# Completed on Fri Nov 21 15:44:47 2014

Ever noticed the brackets right next to the chain? What are those? What do the numbers mean?

*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [7752:8249066]

The answer is pretty easy and pretty obvious in hindsight. These numbers report

• packet counter for the chain
• byte counter for the chain

So in our example above, the OUTPUT chain matched 7752 packets and 8249066 bytes.