All posts by Malte

Alpine 3.23 mkimage.sh: ERROR: –usermode not allowed as root

Recently I decided to upgrade a custom Alpine ISO generator that I run to the latest version of Alpine Linux, 3.23. The task is fairly easy, but required some special attention, because the first ISO build attempt failed:

sh aports/scripts/mkimage.sh --tag "test-3.23-0.1" --outdir /export --arch x86_64 --repository https://dl-cdn.alpinelinux.org/alpine/v3.23/main --repository https://dl-cdn.alpinelinux.org/alpine/v3.23/community --profile myprofile
ERROR: --usermode not allowed as root

After some research I found that this is related to the updated version of apk, the package manager used in Alpine Linux. Version 3.x of apk brings a fair amount of new features and some slightly breaking changes such as this one.

Continue reading Alpine 3.23 mkimage.sh: ERROR: –usermode not allowed as root

Short: Automatically generate a one time password to connect to Sophos or OpenVPN Access servers

If business partners or companies use Sophos or OpenVPN Access, it is likely that they use some sort of OTP “one time password” mechanism. Either as a standalone password or as a combination of a persistent password + one time password. Usually entered one after another without any whitespace as a response to the VPN client querying upon connection buildup.

If one wanted to automate that, for example on a VPN Gateway, oathtool comes in handy. It allows to generate the right one time password using the initial setup string like that:

oathtool --totp -b "JBSWY3DPEHPK3PXP"

The resulting OTP can then be used further to authenticate with the OpenVPN commandline client.

Using WSL or MSYS2 you can also use (or compile and then use) oathtool on Windows.

Before you uninstall Avast Free Antivirus – make sure you exported your BitLocker recovery key(s)!

Avast Free Antivirus over the years really had gotten annoying. Not only do I directly know a person where even the Premium Version led to constant annoyment because it was randomly blocking internet communications via the Windows Firewall, it also caused all kinds of disturbances with its “Smart-Scan” that occur sometimes ever couple of minutes and bring up annoying popups every time they run.

Time to remove the thing.

But be aware!

After rebooting you will be asked for your BitLocker recovery key(s). And if asked, you better have them or you better have a good and recent backup of your data:

In general it is a good idea for backup your BitLocker keys, because a TPM- or simple firmware-update of your machine could also invalidate the current TPM state and require the recovery keys. Save them, store them in a safe location.

As for Avast: It would be good if within the uninstall process, they would warn you.

Start check-mk-agent.socket after WireGuard (wg-quick@)

If you run CheckMK, you likely also run some normal CheckMK-agents on Linux-, Windows- or other hosts. CheckMK in recent versions features a onboarding process which employs OpenSSL to authenticate and encrypt the communication between the CheckMK-installation and the agents. However there is no very practical way to do this with ARM-based systems for now as the binary for the initial onboarding process only exists in a x86 precompiled version.

On ARM-based hosts the “old” systemd socket solution works just fine, however, it is unencrypted and unauthenticated by default. Therefore a practical solution is to employ a VPN of your choice to secure the communication between the CheckMK-installation and CheckMK-agents.

Continue reading Start check-mk-agent.socket after WireGuard (wg-quick@)

Compile tpm2-openssl on Alpine

When using TPM 2.0 with a Alpine Linux based host in order to generate certificates, specifically certificate sign requests (CSR’s), one will inevitably stumple upon tpm2-tss and its tpm2-tss engine for OpenSSL to generate a private key which resides in the TPM 2.0 module and a CSR that can be used to generate a signed certificate by any certificate authority.

Continue reading Compile tpm2-openssl on Alpine

Quantum Spark 1570: dynamic object in the translated source column cannot be resolved. for more details see sk166457

When operating CheckPoint’s Quantum Spark 1570 and similar appliances, it is a common practice to port-forward services that should be exposed to the internet. One could create a “server”, lets say for WireGuard VPN on port 51820 and forward this specific port to one specific machine on the local network.

The Quantum Spark appliance will do the rest, like adding a firewall rule to actually allow the traffic. Et voila, you can connect to your WireGuard VPN.

However when using the dynamic NAT feature, which is the default, at some point your service, in my case WireGuard, could be blocked again. Specifically after restarting the appliance when using IPv4+IPv6.

Why is that? Dynamic NAT rules on the 1570 use Dynamic Objects (objects that reference the current IP of an interface). After reboot, especially with IPv6 auto-configuration (SLAAC/DHCPv6), the interface’s IPv6 address or prefix changed. NAT rules referencing the old dynamic object no longer match the new interface address. The firewall throws the SK166457 error.

Solution? Use a non-changing IPv6 network or set the NAT to static. Likely the NAT will be IPv4 only, so it is perfectly fine to statically bind to a single, external IPv4.

So far I had a mixed experience with CheckPoint and Quantum Spark devices. Sometimes things are overcomplicated. But the worst part: Pretty much all of CheckPoints Knowledge Base (also the sk166457 article) is behind a login wall. That would not pose a problem, but even after creating a private account, the information stays hidden to authorized personnel with some kind of special permission. Solutions therefore must be found manually. Thats bad…