WakeOnLan, Archlinux, systemd-networkd, Asus Pro WS X570-ACE

The board has two integrated ethernet adapters, here’s the lshw data:

sudo lshw -c network 
  *-network                  
       description: Ethernet interface 
       product: I211 Gigabit Network Connection 
       vendor: Intel Corporation 
       physical id: 0 
       bus info: pci@0000:05:00.0 
       logical name: enp5s0 
       version: 03 
       serial: 24:4b:fe:<redacted>
       size: 1Gbit/s 
       capacity: 1Gbit/s 
       width: 32 bits 
       clock: 33MHz 
       capabilities: pm msi msix pciexpress bus_master cap_list ethernet physical tp 10bt 10bt-fd 100bt 100bt-fd 1000bt-fd autonegotiation 
       configuration: autonegotiation=on broadcast=yes driver=igb driverversion=5.12.8-zen1-1-zen duplex=full firmware=0. 6-1 ip=<redacted> latency=0 link=yes multicast=yes port=twisted pair speed=1Gbit/s 
       resources: irq:61 memory:fc900000-fc91ffff ioport:e000(size=32) memory:fc920000-fc923fff 
  *-network 
       description: Ethernet interface 
       product: RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller 
       vendor: Realtek Semiconductor Co., Ltd. 
       physical id: 0.1 
       bus info: pci@0000:06:00.1 
       logical name: enp6s0f1 
       version: 1a 
       serial: 24:4b:fe:<redacted>
       size: 1Gbit/s 
       capacity: 1Gbit/s 
       width: 64 bits 
       clock: 33MHz 
       capabilities: pm msi pciexpress msix bus_master cap_list ethernet physical tp mii 10bt 10bt-fd 100bt 100bt-fd 1000bt-fd autonegotiation 
       configuration: autonegotiation=on broadcast=yes driver=r8169 driverversion=5.12.8-zen1-1-zen duplex=full firmware=rtl8168fp-3_0.0.1 11/16/19 ip=<redacted> latency=0 link=yes multicast=yes port=twisted pair speed=1Gbit/s 
       resources: irq:24 ioport:d800(size=256) memory:fc814000-fc814fff memory:fc808000-fc80bfff 

It seems that the UEFI entry to activate Wake on Lan for PCIe devices only affects the Intel port, i’ve persistently activated WOL for the realtek port by adding a .link file to /etc/systemd/network/foobar.link

[Match] 
MACAddress=<redacted>
 
[Link] 
WakeOnLan=magic
# below lines are cloned from original entry in
# /usr/lib/systemd/network/99-default.link
# which is the default link file for all adapters whose section is hereby overwritten
NamePolicy=keep kernel database onboard slot path 
AlternativeNamesPolicy=database onboard slot path 
MACAddressPolicy=persistent
 
The arch wiki shows a couple of alternative ways, but this seems to be the most straight forward for me. 

Upgrade Postgresql from 11 upwards

On Ubuntu 18.04

Multiple installations (11, 12, 13) be wary of that, as pg_upgradcluster for example will always go for the hightes version.

copied configuration files for new version

cp -R  /etc/posgresql/11 /etc/posgresql/12

initialized new version db

/usr/lib/postgresql/12/bin/initdb -D /srv/postgres/12/main

stopped the current server and killed all connections

/usr/lib/postgresql/11/bin/pg_ctl -D /srv/postgres/11/main/ -mf stop

ran checked upgrade with linked files

time /usr/lib/postgresql/12/bin/pg_upgrade --old-bindir /usr/lib/postgresql/11/bin/ --new-bindir /usr/lib/postgresql/12/bin/ --old-datadir /srv/postgres/11/main/ --new-datadir /srv/postgres/12/main/ --link --check

had to fix diverse configuration file problems that are obvious when running

"/usr/lib/postgresql/11/bin/pg_ctl" -w -l "pg_upgrade_server.log" -D "/srv/postgres/11/main" -o "-p 50432 -b  -c listen_addresses='' -c unix_socket_permissions=0700 -c unix_socket_directories='/var/lib/postgresql'" start
cat pg_upgrade_server.log

mostly faulty references to configuration files, or having to make explicit the non-standard data dir location.

then the systemd related things

systemctl disable postgres@11-main
systemctl enable postgres@12-main

This place was most helpful:
https://blog.crunchydata.com/blog/how-to-perform-a-major-version-upgrade-using-pg_upgrade-in-postgresql

Some reminders for http caching

blatantly copypasted from https://httptoolkit.tech/blog/http-wtf/

No-cache means “do cache”

Caching has never been easy, but HTTP cache headers can be particularly confusing. The worst examples of this are no-cache and private. What does the below response header do?

Cache-Control: private, no-cache

It looks like this means “don’t store this response anywhere”, right?

Hahaha no.

In reality, this means “please store this response in all browser caches, but revalidate it when using it”. In fact, this makes responses more cacheable, because this applies even to responses that wouldn’t normally be cacheable by default.

Specifically, no-cache means that your content is explicitly cacheable, but whenever a browser or CDN wants to use it, they should send a request using If-Match or If-Modified-Since to ask the server whether the cache is still up to date first. Meanwhile private means that this content is cacheable, but only in end-client browsers, not CDNs or proxies.

If you were trying to disable caching because the response contains security or privacy sensitive data that shouldn’t be stored elsewhere, you’re now in big trouble. In reality, you probably wanted no-store.

If you send a response including a Cache-Control: no-store header, nobody will ever cache the response, and it’ll come fresh from the server every time. The only edge case is if you send that when a client already has a cached response, which this won’t remove. If you want to do that and clear existing caches too, add max-age=0.

Twitter notably hit this issue. They used Pragma: no-cache (a legacy version of the same header) when they should have used Cache-Control: no-store, and accidentally persisted every user’s private direct messages in their browser caches. That’s not a big problem on your own computer, but if you share a computer or you use Twitter on a public computer somewhere, you’ve now left all your private messages conveniently unencrypted & readable on the hard drive. Oops.

SpinRite 6 on external Toshiba usb disk

AFter 827 days of running time my RaspiBlitz BTC lightning node refused to mount the external hdd (Toshiba HDTB410EK3AA Canvio Basics, USB 3.0, 1TB). Smart errors of the weirdest kind. I remembered Gibson’s spammy advertisements during the Security Now! Podcast, praising SpinRite for recovery. As there was no physical damage / interaction that would have caused that i gave it a try.

After i bought the license, i downloaded the exe causing first problem, how to run on Linux? I have a Windows 7 laptop for such cases, so i executed the program and tried all the different options to create a bootable USB, finally succeeding by writing out the diskette spinrite.img to harddisk, then dd-ing it onto a usb flash drive:

dd if=/path/to/SpinRite.img conv=notrunc of=/dev/<your usb device, i.e. sda>

After rebooting the same laptop with the external USB disk attached, SpinRite started right away, and luckily for me, the drive was instantly recognized; no need for driver voodoo on the included FreeDOS distribution – that was my biggest concern. Probably the fact that the external disk is not a casing with some exotic usb-controller, but a disk with an integrated usb port helped a lot. A small downer was the unavailability of smart data for SpinRite – I don’t have a theory about that.

The first run failed with a program abort:

This is ongoing.

run openvpn in client mode automatically after linux boot

scenario: send out a raspberry pi model b rev1, all setup with raspberryi os / raspbian.

the hardware specs are nothing much, but the machine is reliable, even when apparently half the ram chips are dead….

install openvpn, then take the config file from the server you want to connect to – in my case an ovpn file generated by pivpn – and put it into the config folder `/etc/openvpn/`. if your vpn profile is password protected, just add a simple textfile with the cleartext pass and reference it in your vpn profile file like so:
askpass /etc/openvpn/passwordfilename

make sure openvpn.service is started and enabled.
systemctl enable openvpn && systemctl restart openvpn

should be it, ip a should show you the tunnel interface already.

ps: for the routing, make sure that your that your router has a static entry that sends all the traffic to the vpn subnet to the vpn server, but that is something that depends really on your own net topology.

update gnubee debian jessie to buster

thanx to https://feeding.cloud.geek.nz/posts/installing-debian-buster-on-gnubee2/

Upgrade to stretch and then buster

To upgrade to stretch, put this in /etc/apt/sources.list:

deb http://httpredir.debian.org/debian stretch main
deb http://httpredir.debian.org/debian stretch-updates main
deb http://security.debian.org/ stretch/updates main

Then upgrade the packages:

apt update
apt full-upgrade
apt autoremove
reboot

To upgrade to buster, put this in /etc/apt/sources.list:

deb http://httpredir.debian.org/debian buster main
deb http://httpredir.debian.org/debian buster-updates main
deb http://security.debian.org/debian-security buster/updates main

and upgrade the packages:

apt update
apt full-upgrade
apt autoremove
reboot

Configure Ubuntu 18.04 with grub2 to activate serial console

Thanks to hiroom2

1 /etc/default/grub

  • Change GRUB terminal to console and ttyS0. This will provide one GRUB to a monitor display and serial console.
  • Change linux kernel console to tty1 and ttyS0. This setting will be taken over to userland, and there will be two login prompt for tty1 and ttyS0.
GRUB_CMDLINE_LINUX="console=tty1 console=ttyS0,115200"
GRUB_TERMINAL="console serial"
GRUB_SERIAL_COMMAND="serial --speed=115200 --unit=0 --word=8 --parity=no --stop=1"

Wireguard scenario workstation -> vpn gateway -> private network

I’ve moved a rather hacky tinc mesh vpn solution to wireguard, all set up through an ansible playbook. the topology is rather classic:

my workstation (laptop, changing network situation) connects as a ‘client’ to two wireguard ‘servers’ as vpn gateways which are publicly accessible bastion hosts, and who also are members of a private subnet to which they ought to give access. the specific nodes are cloud instances of each Hetzner cloud and Vultr cloud.

Hetzner recently started to provide private interfaces to their cloud instances, currently the private addresses seem to be given randomly when using the cli tool, but can be specified also via their website interface. Vultr has that service already longer, however, the private ip cannot be specified and is assigned at random.

the above used terms ‘client’ and ‘server’ are a bit anachronistic, as Wireguard does not make such a difference. the ‘servers’ merely do not get endpoints to their peers in their interface configuration, as they do not initiate connections.

Generally, when running a linux vpn gateway that connects two interfaces into different subnets (here wg0 is the wireguard interface, ens10 is the interface to the cloud provider’s virtual router and a self configured private subnet) one only needs to set /proc/sys/net/ipv4/ip_forward to 1 and /proc/sys/net/ipv6/conf/all/forwarding to 1 and be done with it. The nodes in the private subnet possibly need some way of receiving the necessary route back to that vpn gateway, via some routing protocol or static routing.

I was not able to set this up neither on Hetzner, nor on Vultr, and had to instead set up NAT on the gateway via iptables, as advised here in this tutorial, by the way a good reference on how to set up Wireguard: https://angristan.xyz/how-to-setup-vpn-server-wireguard-nat-ipv6/

My theory is that the virtual routers of the cloud providers are filtering this kind of traffic, as i can see the packets running through both the wireguard interface and the private subnet interface on the vpn gateway, but cannot see them at the final node’s interface. But i could be entirely wrong.