Symptom

When installing packages on Alpine Linux, trigger scripts are failing, although installation seems to succeed (exit code being 0):

1
2
3
4
5
6
7
8
9
10
11
12
13
14
/ # apk add curl
fetch http://dl-cdn.alpinelinux.org/alpine/v3.12/main/x86_64/APKINDEX.tar.gz
fetch http://dl-cdn.alpinelinux.org/alpine/v3.12/community/x86_64/APKINDEX.tar.gz
(1/4) Installing ca-certificates (20191127-r4)
(2/4) Installing nghttp2-libs (1.41.0-r0)
(3/4) Installing libcurl (7.69.1-r1)
(4/4) Installing curl (7.69.1-r1)
Executing busybox-1.31.1-r19.trigger
ERROR: busybox-1.31.1-r19.trigger: script exited with error 127
Executing ca-certificates-20191127-r4.trigger
ERROR: ca-certificates-20191127-r4.trigger: script exited with error 127
OK: 7 MiB in 18 packages
/ # echo $?
0

Investigation

I made a custom Alpine Linux image with strace installed (built locally, using Docker). This tool prints all the system calls made by a process.

1
2
FROM alpine
RUN apk add --no-cache strace

Then, I’ve run the apk command again using strace (-f argument tracks child processes):

1
strace -f apk add curl 2>&1 | less

I looked for a trigger script execution in the output and compared with the same command ran locally. On CRI-O, it failed to run the chroot system call:

1
[pid    17] chroot(".")                 = -1 EPERM (Operation not permitted)

It appears that CRI-O doesn’t allow chroot by default.

Cure

To enable chroot by default on CRI-O, add SYS_CHROOT in the default_capabilities array in /etc/crio/crio.conf:

1
2
3
4
default_capabilities = [
	# ...
	"SYS_CHROOT",
]

Then, restart CRI-O:

1
systemctl restart crio

Package installations should work now:

1
2
3
4
5
6
7
8
9
10
/ # apk add curl
fetch http://dl-cdn.alpinelinux.org/alpine/v3.12/main/x86_64/APKINDEX.tar.gz
fetch http://dl-cdn.alpinelinux.org/alpine/v3.12/community/x86_64/APKINDEX.tar.gz
(1/4) Installing ca-certificates (20191127-r4)
(2/4) Installing nghttp2-libs (1.41.0-r0)
(3/4) Installing libcurl (7.69.1-r1)
(4/4) Installing curl (7.69.1-r1)
Executing busybox-1.31.1-r19.trigger
Executing ca-certificates-20191127-r4.trigger
OK: 7 MiB in 18 packages

Fortunately, Scaleway has hidden features in their boot process that allow to run kexec which makes it possible to run the kernel of your choice.

These features are provided by setting tags on the instance in the Scaleway console.

This guide leads you to enable kexec on your instance.

Note: This tutorial is no longer applicable since Scaleway has dropped support for bootscripts. Also, it is now possible to reinstall servers in rescue mode with EFI, a thing that wasn’t possible at the time this article was written. This article is only kept here for educational purposes.

Install a kernel on the server

For Debian:

1
apt install linux-image-amd64

For Ubuntu:

1
apt install linux-kvm # or: linux-image-generic

Check that symbolic links have been created

linux-update-symlinks is ran by APT to create symbolic links on /vmlinuz and /initrd.img.

1
ls -l /vmlinuz /initrd.img

This should point to the kernel that has just been installed in /boot.

Install a network daemon

1
apt install ifupdown

Configure it

Edit /etc/network/interfaces and comment out lines for eth0 interfaces, then add:

1
2
auto ens2
iface ens2 inet dhcp

Edit fstab for mounting disks on boot

Run blkid to get disk UUIDs.

Edit /etc/fstab so it will mount all your disks to the proper mount points on startup:

1
UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx	/         	ext4      	rw,relatime	0 1

This step is important or it will only mount /dev/vda as read-only.

If you miss this step, you can still remount it as read-write:

1
mount -o remount,rw /

Check that setup is working

I advise you to disable the services you don’t want to start at boot in your tests, as these could be killed later if you restart your instance on Scaleway console.

1
2
systemctl status # check what units you want to disable
systemctl disable ...

Then install kexec locally:

1
apt install kexec-tools

When it asks whether or not to manage boot process, choose no.

It might be useful to open now the console of your instance (a virtual TTY) on the Scaleway console, to check the output of the boot process, in case of an error. Note that it often stays blank and doesn’t work, but it is very useful when it does.

Be aware that the network interface will be renamed from eth0 to ens2. You might want to update your firewall rules accordingly.

When you are ready, run these two commands and you’ll be logged out of SSH, as kernel runs kexec:

1
2
kexec -l /vmlinuz --initrd=/initrd.img --reuse-cmdline
systemctl kexec

If server seems not responsive or failed to boot, you can restart the server on Scaleway console. Note that as networking service has been enabled, it will probably fail to start and blocks the boot process for 5 minutes. Check the console for when it happens.

Edit Scaleway tags

When you have confirmed that your setup is working, add these two tags to make Scaleway boot process to run kexec by itself:

1
2
KEXEC_KERNEL=/vmlinuz
KEXEC_INITRD=/initrd.img

Add the first tag, press space, then add the second tag, press space again.

Reboot your server (using reboot via SSH) and profit!

Note: if you previously disabled some services, you can restart these now:

1
systemctl enable --now ...

References

• How to run the stock Ubuntu Linux kernel on Scaleway using KEXEC and server tags

Its source code has been merged in Linux 5.6 and formal verification has been done for WireGuard protocol and implementation. The code base is way smaller than other related projects so it is easier to audit and maintain.

This tutorial presents an installation on a Linux-based operating system with systemd (and systemd-networkd). Other setups are also possible but I found this one simple to use, although platform-dependant. This article doesn’t cover routing Internet traffic through the private network created.

WireGuard installation

Here are instructions to install WireGuard on Debian, Ubuntu and Arch Linux. You can find other operating system instructions on the official website.

On Debian

Since Debian Bullseye, WireGuard support is directly available in the Linux kernel.

Using instructions from Debian Wiki, let’s install the wireguard package.

1
apt update && apt install wireguard

On Ubuntu

Since Ubuntu 20.04, WireGuard support has been backported in the Linux kernel (the kernel packages provide wireguard-modules), there is no need to build a kernel module. The instructions are the same as Debian:

1
apt update && apt install wireguard

On Arch Linux

Since all kernel versions are higher than 5.6 on Arch Linux, all supported kernels include the WireGuard module without any additional package.

Using instructions from ArchWiki, install the wireguard-tools package to install the WireGuard tools.

1
pacman -Syu wireguard-tools

Configuration

You need to enable the systemd-networkd service, if not done already. One advantage is that it can manage both your WireGuard setup and networking at the same time, easing the configuration. I have also used it alongside another networking daemon (like networking on Debian or dhcpcd on Arch Linux), but I recommend not doing so.

On both server and client

You need to create a pair of keys on both server and client. Each client will need to get server’s public key and the server will need to get each client’s public key. Also a pre-shared key will be created, known to each peer.

1
2
3
4
5
6
7
8
9
10
11
# go to systemd-networkd configuration directory
cd /etc/systemd/network

# create files with right permissions (640) to prevent other system users to read secrets
umask 0027
touch wg0.netdev wg0.network wg-preshared.key wg-private.key wg-public.key
umask 0022
chown root:systemd-network *

# create a pair of keys
wg genkey | tee wg-private.key | wg pubkey > wg-public.key

wg0.netdev will be used for WireGuard configuration, wg0.network for networking configuration.

On systemd versions earlier than 242, wg0.netdev will contain secrets, on later versions it’s possible to reference other created files. At the time of writing, Debian oldstable (buster) uses systemd 241, which doesn’t support that feature.

On server

On the server, you need to create the pre-shared key (or on any other peer).

1
wg genpsk > wg-preshared.key

It needs to be copied to other peers.

You can also use a different pre-shared key for each peer, if they are not trusted.

Then here are sample server configuration files. I chose to use a subnet 10.213.213.0/24, but you can also use IPv6 or even dual-stack. For IPv6, you can create a prefix in the fd00::/8 prefix, which is allocated for unique local addresses.

Make sure to change <variable> to the appropriate key value. Less-than and greater-than signs (<>) must not be kept.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
cat <<EOF > wg0.netdev
[NetDev]
Name = wg0
Kind = wireguard
Description = wg server 10.213.213.0/24

[WireGuard]
# If running systemd >= 242
PrivateKeyFile = /etc/systemd/network/wg-private.key
# If running systemd < 242
#PrivateKey = <content of local wg-private.key>
ListenPort = 51820

# For any number of client:
[WireGuardPeer]
PublicKey = <content of client's wg-public.key>
AllowedIPs = 10.213.213.2/32
# If running systemd >= 242
PresharedKeyFile = /etc/systemd/network/wg-preshared.key
# If running systemd < 242
#PresharedKey = <content of wg-preshared.key>
EOF

AllowedIPs represents here the static IP address of the client. You need to choose one per client in the subnet.

You can change ListenPort to your needs (e.g. 53 to pass through firewalls, since it uses UDP).

1
2
3
4
5
6
7
8
9
10
11
cat <<EOF > wg0.network
[Match]
Name = wg0

[Network]
Address = 10.213.213.1/32

[Route]
Gateway = 10.213.213.1
Destination = 10.213.213.0/24
EOF

Then restart systemd-networkd:

1
systemctl restart systemd-networkd

On client

Like on the server, here are sample configuration files. Make sure you change the private IP address on each client, according to server configuration.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
cat <<EOF > wg0.netdev
[NetDev]
Name = wg0
Kind = wireguard
Description = wg client 10.213.213.2

[WireGuard]
# If running systemd >= 242
PrivateKeyFile = /etc/systemd/network/wg-private.key
# If running systemd < 242
#PrivateKey = <content of local wg-private.key>

[WireGuardPeer]
PublicKey = <server's public key>
AllowedIPs = 10.213.213.0/24
Endpoint = <server's public IP address>:51820
# If running systemd >= 242
PresharedKeyFile = /etc/systemd/network/wg-preshared.key
# If running systemd < 242
#PresharedKey = <content of wg-preshared.key>
PersistentKeepalive = 25
EOF

cat <<EOF > wg0.network
[Match]
Name = wg0

[Network]
Address = 10.213.213.2/32

[Route]
Gateway = 10.213.213.1
Destination = 10.213.213.0/24
GatewayOnlink = true
EOF

When ListenPort is not entered, a random port will be chosen by systemd, this is not important for clients that connect to the server specified with Endpoint.

Then restart systemd-networkd:

1
systemctl restart systemd-networkd

Check the connection

You can check that systemd-networkd enabled the WireGuard network interface (wg0) with the networkctl command:

1
2
3
4
5
$ networkctl
IDX LINK             TYPE               OPERATIONAL SETUP     
  1 lo               loopback           carrier     unmanaged 
  2 eno1             ether              routable    configured
  3 wg0              wireguard          routable    configured

You should now be able to ping server and client addresses from each other.

If there is any issue, check the logs with journalctl -eu systemd-networkd. If you have Unknown lvalue errors, it means you used unknown configuration directives, e.g. mistyped or from a more recent systemd version.

You can also get more information using the wg command:

On server:

1
2
3
4
5
6
7
8
9
10
11
12
$ wg
interface: wg0
  public key: <redacted>
  private key: (hidden)
  listening port: 51820

peer: redacted=
  preshared key: (hidden)
  endpoint: <client's public IP address>:44195
  allowed ips: 10.213.213.2/32
  latest handshake: 24 seconds ago
  transfer: 968.57 KiB received, 50.94 MiB sent

On client:

1
2
3
4
5
6
7
8
9
10
11
12
13
$ wg
interface: wg0
  public key: <redacted>
  private key: (hidden)
  listening port: 44195

peer: redacted=
  preshared key: (hidden)
  endpoint: <server's public IP address>:51820
  allowed ips: 10.213.213.0/24
  latest handshake: 49 seconds ago
  transfer: 50.94 MiB received, 971.40 KiB sent
  persistent keepalive: every 25 seconds

Additional configuration

• [WireGuard] and [WireGuardPeer] sections in man 5 systemd.netdev (online versions: Debian, Arch, latest)
• Quick Start on official website

De nombreux articles discutent surtout du côté légal ou éthique vis-à-vis de l’anonymat (ou du pseudonymat) sur Internet, je vous conseille de lire par exemple la lettre ouverte aux députés publiée par Numendil. J’aimerais me concentrer sur la partie technique du sujet.

Je ne suis pas juriste, mais il faut d’abord chercher à définir ce terme “plateforme” qui apparaît très souvent. Disons qu’il s’agit d’un service qui permet à des utilisateurs de publier du contenu sur Internet, qui sera hébergé par un tiers (on peut aussi appelé ça réseau social, je préfère d’ailleurs ce terme). Je préfère garder une définition vaste pour l’instant, je vais parler de la taille de l’hébergeur plus tard. D’ailleurs, le statut même d’hébergeur, défini par la loi LCEN, est menacé notamment par les ayants droit qui veulent forcer l’utilisation du filtrage automatisé des contenus, mais ce n’est pas le sujet de cet article.

Aujourd’hui, n’importe qui peut créer ce genre de service, en étant particulier, association ou entreprise. Il suffit d’enregistrer un nom de domaine chez un registrar (comme OVH), puis d’installer un logiciel dédié sur un serveur (auto-hébergé ou loué chez un prestataire). Un exemple de logiciel est Mastodon qui permet non seulement d’héberger un réseau social, mais aussi d’interconnecter des instances, chacune ayant ses propres règles et thématiques, dans une fédération appelée Fediverse. Cela montre que plusieurs types d’acteurs avec des buts différents peuvent créer des espaces d’échange.

J’aimerais opposer ces acteurs aux mastodontes que sont entre autres Twitter et Facebook, deux multinationales basées aux États-Unis, qui tirent leur revenu de la publicité des annonceurs, qui est personnalisée grâce au contenu publié et aux interactions des utilisateurs de leur service. Ces acteurs sont présents sur toute la planète, or chaque pays peut avoir une vision différente sur l’anonymat sur Internet (les pays nord-européens ont en général une vision plus protectrice vis-à-vis d’Internet). Pensez-vous qu’ils vont appliquer des mesures très précises pour chaque pays ? Il y a deux possibilités : soit ils acceptent de se plier à chaque gouvernement (avec un potentiel coût en développement), en sachant que les lois peuvent changer très vite, soit ils s’y refusent en voulant harmoniser les interactions sur leur réseau social (après tout, leur réseau est mondial, et ne permet pas seulement des interactions entre utilisateurs d’un même pays).

Le problème est surtout de savoir ce que le gouvernement français souhaite. Soit ils veulent que chaque utilisateur ait une identité vérifiée et visible publiquement, soit ils veulent que chaque service collecte une information qui permettrait à la justice de retrouver l’identité d’un utilisateur. Dans le premier cas, je vois mal comment cela va diminuer le harcèlement : il est plus facile en connaissant l’identité d’une personne de trouver des éléments pour faciliter un tel harcèlement (qui existe aussi hors d’Internet où il est plus probable de connaître l’identité d’un individu). Dans le second cas, il existe déjà l’adresse IP qui, pour la majorité des cas, identifie précisément un utilisateur (les fournisseurs d’accès à Internet gardant l’historique de toutes les connexions, et les réseaux sociaux collectant aussi cette information). L’avantage de l’adresse IP est qu’elle fait partie du fonctionnement d’Internet et continuera d’exister. Le désavantage est qu’une adresse IP peut être partagée (par exemple avec le NAT, un VPN ou un réseau wi-fi public). De plus, en étant connecté depuis un autre pays, on peut être soumis à un traitement différent. Il peut donc être souhaitable d’avoir une identification authentifiée, où il est possible de vérifier l’identité précise d’un individu.

De plus, dans le premier cas, un réseau publicitaire (comme Twitter, Facebook mettant déjà en avant le fait d’utiliser son identité réelle) serait très intéressé par l’identité précise d’un utilisateur : le système des enchères publicitaires (Real Time Bidding) s’appuie sur l’échange d’informations entre plusieurs services (cette pratique est incompatible avec le RGPD mais malheureusement elle risque de continuer à exister).

Un moyen d’avoir une identification authentifiée serait d’utiliser un service d’identification tel que FranceConnect (aussi cité par Numendil) qui permet de vérifier son identité via des fournisseurs d’identité (comme La Poste ou Orange). Ce service est mis en œuvre par l’État (par la DINSIC), et est actuellement utilisé pour la connexion au site des impôts ou de la sécurité sociale, mais aussi pour une mutuelle. FranceConnect pourrait fonctionner dans les deux cas : il pourrait envoyer l’identité d’un utilisateur au réseau social (c’est le fonctionnement actuel avec les services utilisant FranceConnect), ou créer un identificateur unique par service qui permettrait à l’État, en possession de cet identificateur collecté et transmis par un réseau social, de retrouver l’identité d’un utilisateur, tout en protégeant le pseudonymat de l’utilisateur. Le fait d’avoir un identificateur unique empêcherait les réseaux sociaux de pouvoir s’échanger ces identifiants pour identifier un individu sur différents services.

Sauf qu’il y a deux problèmes vis-à-vis de l’utilisation d’un tel service d’identification. Premièrement, comment s’assurer que tous les français sont identifiables (pour leur forcer l’utilisation du service d’identification à leur inscription) ? Deuxièmement, comment permettre à n’importe qui d’accéder à ce service (vu qu’actuellement, n’importe qui peut créer un réseau social) ?

Pour le premier point, il existe des listes d’adresses IP qui permettent de les localiser (par pays, par ville, par fournisseur d’accès à Internet) comme GeoIP de MaxMind (tien, on a déjà parlé des adresses IP avant) et ainsi savoir qu’un internaute se connecte depuis la France (notons que les personnes de nationalité différente ne pourront pas être différentiés). Par contre, hors de France, seul le volontariat peut fonctionner (j’implique que cette mesure ne concerne que les français évidemment). Pour le second point, il risque d’y avoir une rupture avec l’Internet actuel qui va bénéficier aux entreprises (facilement reconnues par l’État) : il faudra forcément faire une demande officielle pour pouvoir accéder au service d’identification (et donc devenir hébergeur). Ce serait aussi une rupture avec la neutralité de l’Internet, qui je l’espère ne constitue pas seulement en l’accès équitable aux différents services sur Internet, mais qui doit aussi garantir la possibilité de devenir hébergeur.

Je pense avoir fait le tour de la partie technique. Essayez de parler de ce sujet autour de vous pour mettre au jour les différents problèmes. Si vous avez des commentaires, vous pouvez me contacter sur Mastodon.