Immae's blog

Migrate from RAID1 disk to ZFS on NixOS

2020-06-06T01:55:00+02:00

As of 2020-06-06 I only made those tests inside a VM (See below if you want to play with it too). I’m not fully at peace with the process yet to actually apply it on my server. Use at your own risk!

Edit 2020-08-13: Adjustments to the process after some advices by Linus Heckemann (sphalerite on freenode): the /boot partition stays outside of zfs and some flags are set by default on the zpool.

Edit 2020-08-25: The configuration was successfully applied. An issue occured with two ZFS pools having the same name, which prevented the system from booting. Thanks to sphalerite, BiBi and Raito_Bezarius for their supports during the hours of debugging it took to figure out the issue.

Context

I’m the happy owner of a server which holds my whole infrastructure for more than one year now, powered by NixOS for declarative deployments. When I installed it the first time, I didn’t know about ZFS and all its features (see there if you want some examples)

Since I cannot afford to reinstall everything from scratch, I had to find a way to deploy ZFS safely (i.e. without losing redundancy). This article explains step by step the choices I made.

Setup

The server has a single relevant partition mounted on / (the other partitions are BIOS boot and swap, non-relevant here). This partition is a RAID1 array, backed by two disks. The partition holding / on the underlying disks is the third one, that is /dev/md0 containing /dev/sda3 and /dev/sdb3.

The distribution of my server is NixOS, installed remotely via nixops. Some commands will rely on that fact below, but might be adapted depending on your distribution (or if you don’t use nixops)

I ordrered an additional disk to my server provider (/dev/sdc). The sole purpose of this disk is to ensure redundancy in case of failure during the process. The process itself could be adapted to not need it if you’re confident enough. It can be thrown away at the end of the process.

Play with libvirtd

Since I didn’t want to break my server, I created a libvirtd rough equivalent of my setup: three disk images, two of them mounted as RAID array. Since it is a quite specific setup, I couldn’t make a fully declarative VM handled by nixops, but I still made use of some of nixpkgs helpers.

The derivation below will produce an output with three disks image as described above:

# base_image.nix
{ system ? builtins.currentSystem, size ? "10" }:
let
  pkgs = import <nixpkgs> {};
  config = (import <nixpkgs/nixos/lib/eval-config.nix> {
    inherit system;
    modules = [ {
      fileSystems."/".device = "/dev/disk/by-label/root";

      boot.loader.grub.version = 2;
      boot.loader.grub.devices = [ "/dev/vda" "/dev/vdb" ];
      boot.loader.timeout = 0;
      boot.kernelParams = ["console=ttyS0,115200"];

      services.openssh.enable = true;
      services.openssh.startWhenNeeded = false;
      services.openssh.extraConfig = "UseDNS no";
    } ];
  }).config;
  the_key = builtins.getEnv "NIXOPS_LIBVIRTD_PUBKEY";
in pkgs.vmTools.runInLinuxVM (
  pkgs.runCommand "libvirtd-image"
    { memSize = 768;
      preVM =
        ''
          mkdir $out
          diskImage1=$out/image
          diskImage2=$out/image2
          diskImage3=$out/image3
          ${pkgs.vmTools.qemu}/bin/qemu-img create -f qcow2 $diskImage1 "${size}G"
          ${pkgs.vmTools.qemu}/bin/qemu-img create -f qcow2 $diskImage2 "${size}G"
          ${pkgs.vmTools.qemu}/bin/qemu-img create -f qcow2 $diskImage3 "${size}G"
          mv closure xchg/
        '';
      postVM =
        ''
          mv $diskImage1 $out/disk.qcow2
          mv $diskImage2 $out/disk2.qcow2
          mv $diskImage3 $out/disk3.qcow2
        '';
      QEMU_OPTS = builtins.concatStringsSep " " [
        "-drive file=$diskImage1,if=virtio,cache=unsafe,werror=report"
        "-drive file=$diskImage2,if=virtio,cache=unsafe,werror=report"
        "-drive file=$diskImage3,if=virtio,cache=unsafe,werror=report"
      ];
      buildInputs = [ pkgs.utillinux pkgs.perl pkgs.kmod ];
      exportReferencesGraph =
        [ "closure" config.system.build.toplevel ];
    }
    ''
      ${pkgs.parted}/bin/parted --script /dev/vda -- \
        mklabel gpt \
        mkpart ESP fat32 8MiB 256MiB \
        set 1 boot on \
        set 1 bios_grub on \
        mkpart sap1 linux-swap 256MiB 512MiB \
        mkpart primary ext4 512MiB -1
      ${pkgs.parted}/bin/parted --script /dev/vdb -- \
        mklabel gpt \
        mkpart ESP fat32 8MiB 256MiB \
        set 1 boot on \
        set 1 bios_grub on \
        mkpart sap1 linux-swap 256MiB 512MiB \
        mkpart primary ext4 512MiB -1
      ${pkgs.mdadm}/bin/mdadm --create /dev/md0 --metadata=0.90 --level=1 --raid-devices=2 /dev/vda3 /dev/vdb3

      # Create an empty filesystem and mount it.
      ${pkgs.e2fsprogs}/sbin/mkfs.ext4 -L root /dev/md0
      ${pkgs.e2fsprogs}/sbin/tune2fs -c 0 -i 0 /dev/md0
      mkdir /mnt
      mount /dev/md0 /mnt

      export HOME=$TMPDIR
      export NIX_STATE_DIR=$TMPDIR/state

      mkdir -p /mnt/etc/nixos

      # The initrd expects these directories to exist.
      mkdir /mnt/dev /mnt/proc /mnt/sys
      mount --bind /proc /mnt/proc
      mount --bind /dev /mnt/dev
      mount --bind /sys /mnt/sys

      # Copy all paths in the closure to the filesystem.
      storePaths=$(perl ${pkgs.pathsFromGraph} /tmp/xchg/closure)

      echo "filling Nix store..."
      mkdir -p /mnt/nix/store
      set -f
      cp -prd $storePaths /mnt/nix/store/

      mkdir -p /mnt/etc/nix
      echo 'build-users-group = ' > /mnt/etc/nix/nix.conf
      export USER=root

      ## Register the paths in the Nix database.
      printRegistration=1 perl ${pkgs.pathsFromGraph} /tmp/xchg/closure | \
          chroot /mnt ${config.nix.package.out}/bin/nix-store --load-db

      mkdir -p /mnt/nix/var/nix/profiles
      # Create the system profile to allow nixos-rebuild to work.
      chroot /mnt ${config.nix.package.out}/bin/nix-env \
          -p /nix/var/nix/profiles/system --set ${config.system.build.toplevel}

      # `nixos-rebuild' requires an /etc/NIXOS.
      mkdir -p /mnt/etc/nixos
      touch /mnt/etc/NIXOS

      # `switch-to-configuration' requires a /bin/sh
      mkdir -p /mnt/bin
      ln -s ${config.system.build.binsh}/bin/sh /mnt/bin/sh

      # Generate the GRUB menu.
      chroot /mnt ${config.system.build.toplevel}/bin/switch-to-configuration boot

      mkdir -p /mnt/etc/ssh/authorized_keys.d
      echo '${the_key}' > /mnt/etc/ssh/authorized_keys.d/root
      umount /mnt/proc /mnt/dev /mnt/sys
      umount /mnt
    ''
)

When deploying with nixops (via the libvirtd backend), you will need to make each image available. However, nixops only handles one and only one image, so we will need a bit of manual tasks. This is the nixops configuration I’m using:

# libvirtd.nix
{
  testzfs = { pkgs, lib, ... }:
  {
    fileSystems."/".device = lib.mkForce "/dev/disk/by-label/root";

    # Serial access via virsh console (quite handy for debugging)
    boot.kernelParams = ["console=ttyS0,115200"];
    boot.loader.grub.extraConfig = ''
      serial --unit=0 --speed=115200 --word=8 --parity=no --stop=1
      terminal_output serial
      terminal_input serial
    '';
    boot.loader.timeout = lib.mkForce 2;

    # You need to explicitely specify the additional disk here
    boot.loader.grub.devices = [ "/dev/sdb" ];

    deployment = {
      targetEnv = "libvirtd";
      libvirtd.baseImage = pkgs.callPackage ./base_image.nix {};
      # Additional images need to be specified explicitely here (only the sda one will be picked by nixops)
      libvirtd.extraDevicesXML = ''
        <disk type="file" device="disk" snapshot="external">
          <driver name="qemu" type="qcow2"/>
          <source file="/path/to/disk2.qcow2"/>
          <target dev="hdb"/>
        </disk>
        <disk type="file" device="disk" snapshot="external">
          <driver name="qemu" type="qcow2"/>
          <source file="/path/to/disk3.qcow2"/>
          <target dev="hdc"/>
        </disk>
      '';
    };

    # Some dummy service that writes to disk regularly
    systemd.services.nag-var = {
      description = "Some service reading and writing to /var";
      after = [ "network.target" ];
      wantedBy = [ "multi-user.target" ];
      script = ''
        #!${pkgs.stdenv.shell}
        mkdir -p /var/nagvar
        while true; do
          ${pkgs.coreutils}/bin/date > /var/nagvar/last
          ${pkgs.coreutils}/bin/sleep 10
        done
      '';
    };
  };
}

Now prepare the VM. Beware, this will rapidly fill-in your /nix/store with big images. (nix-store --delete /nix/store/*libvirtd-image* to clean them selectively if you’re doing tests)

# This command will fail due to missing images
nixops deploy --create-only
# Find the path to images at the beginning of the output. It will be
# slightly different from what you would get with nix-build due to
# some parameters given by nixops
P=/nix/store/eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee-libvirtd-image

# Stop VM.
virsh destroy nixops-...-testzfs

# Copy additional disks to places written in libvirtd.nix
# For some reason, sometimes I had to replace the first disk too in
# libvirtd folder.
cp $P/disk2.qcow2 /path/to/disk2.qcow2
cp $P/disk3.qcow2 /path/to/disk3.qcow2
chmod gu+w /path/to/disk2.qcow2 /path/to/disk3.qcow2

# Same action done by nixops on the first disk
qemu-img rebase -f qcow2 -b "" /path/to/disk2.qcow2
qemu-img rebase -f qcow2 -b "" /path/to/disk3.qcow2

# Edit libvirtd and add console configuration (in the <devices> section)
virsh edit nixops-...-testzfs
# <serial type='pty'><target port='0'/></serial>
# <console type='pty'><target type='serial' port='0'/></console>

nixops deploy --force-reboot

Now you should have a running VM containing two drives in a RAID1 array plus one unused drive, that mimics your production server, and that I used as a base for the migration process below.

In case of problem, you should be able to use virsh console to get an actual console of what’s happening on your VM (as early as grub stage). Also think of doing snapshots if you want to repeat some steps.

Migration process

Add the new disk to the RAID array

# Copy partitionning without boot partition
sfdisk -d /dev/sda | grep -v ^sector-size: | sed -e "s/21686148-6449-6E6F-744E-656564454649/0657FD6D-A4AB-43C4-84E5-0933C84B4F4F/" | sfdisk /dev/sdc

# Add the new partition to RAID array
mdadm --grow /dev/md0 --level=1 --raid-devices=3 --add /dev/sdc3

# Wait for synchronisation to finish
cat /proc/mdstat
(...)

Remove sda from the array

Beware in this step, depending on your grub configuration it could very well end up using sda for the next boot if you don’t wipe it correctly (last command of the step)

mdadm /dev/md0 --fail /dev/sda3 --remove /dev/sda3
mdadm --grow /dev/md0 --raid-devices=2

# delete old partition (so that grub doesn’t find it by error)
wipefs -a /dev/sda3

Add ZFS-specific configuration to nix

Add this to nix configuration:

boot.supportedFilesystems = [ "zfs" ];
networking.hostId = "9e16a79b";

# Maintenance target for later
systemd.targets.maintenance = {
  description = "Maintenance target with only sshd";
  after = [ "network-online.target" "network-setup.service" "sshd.service" ];
  requires = [ "network-online.target" "network-setup.service" "sshd.service" ];
  unitConfig = {
    AllowIsolate = "yes";
  };
};

And deploy:

nixops deploy
# nixos-rebuild switch

Convert sda3 to a ZFS filesystem

I wanted to use this migration to encrypt my filesystem at the same time. But doing it correctly requires specific configuration (in initrd) which I didn’t want to risk doing concurrently with the migration. So for now the password will be in cleartext (I’m aware it makes the encryption useless, but since encryption cannot be switched on later I need to activate it now. If someone obtains root access to your system during that time your encryption is screwed - he can obtain the ZFS master encryption key -, otherwise it can just be activated with a proper process later)

# Repartition your disk, it’s not recommended to have /boot in ZFS for now
# remove sda3, create a 2GB partition for /boot and create a new root partition
sfdisk --delete /dev/sda 3
fdisk /dev/sda
mdadm --create /dev/md1 --metadata=0.90 --level=1 --force --raid-devices=1 /dev/sda3
mkfs.ext4 /dev/md1
mkdir /mnt && mount /dev/md1 /mnt && echo -n "12345678" > /mnt/pass.key && chmod go-rwx /mnt/pass.key
echo -n "12345678" > /boot/pass.key && chmod go-rwx /boot/pass.key
zpool create -O xattr=sa -O acltype=posixacl -O atime=off -o ashift=12 -O mountpoint=legacy -f zpool sda4
zfs create -o encryption=on -o keyformat=passphrase -o keylocation=file:///boot/pass.key zpool/root
zfs create zpool/root/nix
zfs create -o atime=on zpool/root/var
zfs create -o sync=disabled zpool/root/tmp
zfs create zpool/root/etc
umount /mnt
mount -t zfs zpool/root /mnt
mkdir /mnt/nix && mount -t zfs zpool/root/nix /mnt/nix
mkdir /mnt/var && mount -t zfs zpool/root/var /mnt/var
mkdir /mnt/tmp && mount -t zfs zpool/root/tmp /mnt/tmp
mkdir /mnt/etc && mount -t zfs zpool/root/etc /mnt/etc
mkdir /mnt/boot && mount /dev/md1 /mnt/boot
rsync -aHAXS --one-file-system / /mnt/

Let NixOS know about new filesystem

Until there, you could do everything while keeping your system running, rebooting etc. From now on, everything must be done in one go (no reboot inbetween) or you might not be able to properly boot

Obtain your /boot uuid and replace below:

fileSystems."/"     = { fsType = "zfs"; device = "zpool/root"; };
fileSystems."/boot" = { fsType = "ext4"; device = "/dev/disk/by-uuid/5b27af91-f515-44f4-9a65-1516326d9297"; };
fileSystems."/etc"  = { fsType = "zfs"; device = "zpool/root/etc"; };
fileSystems."/nix"  = { fsType = "zfs"; device = "zpool/root/nix"; };
fileSystems."/tmp"  = { fsType = "zfs"; device = "zpool/root/tmp"; };
fileSystems."/var"  = { fsType = "zfs"; device = "zpool/root/var"; };
boot.initrd.secrets = {
  "/boot/pass.key" = "/boot/pass.key";
}

Deploy partially:

nixops deploy --dry-activate
# nixos-rebuild dry-activate

Go in maintenance mode, resynchronize and prepare next boot

systemctl isolate maintenance.target
systemctl stop systemd-journald systemd-journald.socket systemd-journald-dev-log.socket systemd-journald-audit.socket
rsync -aHAXS --delete --one-file-system / /mnt/

# Prepare next boot in zfs filesystem
NIXOS_INSTALL_BOOTLOADER=1 nixos-enter --root /mnt/ -- /nix/var/nix/profiles/system/bin/switch-to-configuration boot
# Prepare next boot in raid array - for grub
/nix/var/nix/profiles/system/bin/switch-to-configuration boot

# Unmount everything and prepare the filesystem
umount -R /mnt

# Remove sdb3 from raid array and attach it to ZFS. We still have
# the data both in raid and zfs, and no file is modified due to
# maintenance mode so they’re synchronized
mdadm /dev/md0 --fail /dev/sdb3 --remove /dev/sdb3

# Repartition /dev/sdb similarly to /dev/sda
fdisk /dev/sdb
# Add sdb3 to the /boot array
mdadm --grow /dev/md1 --level=1 --raid-devices=2 --add /dev/sdb3
zpool attach -f zpool sda4 sdb4

# Wait until it’s fully synchronized (or feel lucky and don’t wait)
zpool status

# Restart
shutdown -r now

Cleanup old system

Now that the installation is finished, you may cleanup the additional disk and profit

mdadm --stop /dev/md0
wipefs -a /dev/sdc3
shred -v /dev/sdc

Manage your session with systemd

2014-05-26T23:00:00+02:00

Introduction

A lot of distribution are making their way to "systemd" as an alternative to System V.

One of the advantages of systemd is that it offers a service management for users, and it is this system that I plan to present here to handle our session. Systemd is still under active development, including the user part. This guide reflects the big change that happened in version 206 of systemd on which most current tutorial are based. This setup has been tested on version 212.

When a user session starts (either remotely via ssh or local), an instance of systemd --user starts for that user. This instance has the role to start user services, in a similar way to process 1 but dedicated to the user. Note that by default these services disappear with the user session

Starting `systemd --user`

Before version 206 (as far as I can tell), it was the user's responsibility to start (or not) this instance. Now she cannot anymore be started by the user and it must be run by root.

It is started automatically at login provided that the pam_systemd module is active in pam for the requested session. For that, we add a line of the form

-session   optional   pam_systemd.so

The "-" indicates that it is not essential to the session. In other words: if it fails to start we don't care). With Archlinux, the file /etc/pam.d/system-login already contains this line and concerns any kind of connection (local and remote).

Systemd arrangement

Systemd separates the services and session between slice/scope/service, making heavy use of the cgroups feature (it is a way to group a collection of processes and their possible children without possible escape). A typical system running systemd then looks like that (you can obtain it with systemd-cgls):

system.slice
- service_system1.service
- service_system2.service
user.slice
- user-1000.slice
  - session-c1.scope
    - Program 1
    - Program 2
  - session-c2.scope
  - session-c3.scope
  - user@1000.service
    - systemd --user
    - service_user1000_1.service
    - service_user1000_2.service
    - service_user1000_3.service
- user-1001.slice
  - session-c4.scope
    - Program 1
    - Program 2
  - session-c5.scope
  - session-c6.scope
  - user@1001.service
    - systemd --user
    - service_user1001_1.service
    - service_user1001_2.service
    - service_user1001_3.service

Note that the services of the user ar started in a context separate to the session itself. This has to be remembered, for instance for environment variables scopes.

As soon as all the session-c*.scope of a user are exited, the corresponding user@.service will also be stopped, including all the sub-services. This is a point to remember! For instance, by default, using "timer" unit files of systemd as a replacement for cron won't work for the user if he's not there!
We'll see later how to deal with that.

User services

Comparison

User services are handled in exactly the same way as system services, except that the units are sought in different folders (see man systemd.unit). When systemd --user starts, unit default.target is started and has the role to start other necessary services.

`systemctl --user` and `dbus`

Services managed by systemd (whether system or user) are managed primarily through the command systemctl (--user), which strongly depends on a correct dbus installation. First thing to do is thus to ensure that the dbus daemon runs, both at system level (system bus) and user level (session bus). For the system part, we simply need to add a dependency to user@.service. We will also normalize the path to the session bus socket by giving the appropriate environment variable DBUS_SESSION_BUS_ADDRESS. Since user@.service is a parent of all user services, we can use it to transmit the variable

# /etc/systemd/system/user@.service.d/dbus_env.conf
[Unit]
Wants=dbus.service

[Service]
Environment=DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/%I/bus

Note

Line 2 of the file indicates that we require that the system dbus is started, while line 5 concerns the environment variable for the user's session bus. Don't confuse these services, they correspond to two different buses.

In the sequence, we will define the different services that we will need. They can be defined or activated globally or by user's choice. This depends both on the location of the unit file (/etc/systemd/user/ vs $HOME/.config/systemd/user) and on the way it is activated (with --global vs --user). Here I will define the services and sockets associated to the session dbus globally, but I will let the user chose whether he turns them on or note l'utilisateur :

# /etc/systemd/user/dbus.service
[Unit]
Description=D-Bus Message Bus
Requires=dbus.socket

[Service]
ExecStart=/usr/bin/dbus-daemon --session --address=systemd: --nofork --nopidfile --systemd-activation
ExecReload=/usr/bin/dbus-send --print-reply --session --type=method_call --dest=org.freedesktop.DBus / org.freedesktop.DBus.ReloadConfig
Restart=always
RestartSec=1

(Note that the main difference between this unit and the corresponding system unit resides in the use of --session instead of --system)

# /etc/systemd/user/dbus.socket
[Unit]
Description=D-Bus Message Bus Socket
Before=sockets.target

[Socket]
ListenStream=/run/user/%U/bus

[Install]
WantedBy=default.target

(default.target is the default activated target by systemd).

From now on, the hardest part is done. We will create a unit my_services.target alias of default.target

:::bash # $HOME/.config/systemd/user/my_services.target [Unit] Description=My services Wants=dbus.service AllowIsolate=true [Install] Alias=default.target

and then we create unit files in the same folder. Then, we activate them using the well know command systemctl, but with an argument --user. The rest of the article consists essentially in tricks and interesting specific cases.

Important notice

The directive After doesn't have the same effect for a service unit and a target unit. A service will be started only once all the unit quoted in After are ready (for the definition of ready, see man systemd.service, bloc Type=), while for a target it is assumed that the services are part of it (and can then be started concurrently to other services).

User services that last

By default, services associated to an user (everything that is below user@1001.service in the tree above) are stopped when the user disconnects. This includes timers, that we would like to use as a replacement for crontab.

We can bypass that with this command:

:::bash loginctl enable-linger user

In that case, user@.service will be started as soon as boot for the corresponding user, even when he is not there.

I won't go any further into details on how to define the equivelnt of crontabs for systemd, this kind of feature is already well explained in manual pages as well as systemd-dedicated websites (see man systemd.timer). The trick given here deals with the issue of having crontabs equivalent that last for an user even when he's not there.

Important notice

Usually crontabs send emails when there is output. As far as I know there is no such feature in systemd services and everything is logged in the journal.

Environment variables

Environment variables can become a true headache when we use services. For instance, how can we transmit variables necessary to the services like GPG_AGENT_INFO or SSH_AUTH_SOCK or even DISPLAY. One way to do it is to specify in the unit file a directive of the form

:::bash Environment=DISPLAY=:0 or :::bash EnvironmentFile=/file/to/load

The problem is that this configuration is static, and must be defined for each service separately or globally in a file like /etc/systemd/system/user@.service.d/environment.conf. We also lose the usual dynamism of configuration scripts.

Here, we will make use of the command systemctl --user import-environment to solve our problem. This command permits to import environment variables that will be included in any subsequent service. We start by creating a service setenv.service that will start a script loading the environment. As far as I am concerned, I have to different environment depending on whether I am in command line or graphical. My service file then looks like that:

:::bash # $HOME/.config/systemd/user/setenv@.service [Unit] Description=Set environment Wants=dbus.service gpg-agent.service ssh-agent.service After=dbus.service gpg-agent.service ssh-agent.service [Service] Type=oneshot Environment=SSH_AUTH_SOCK=%t/ssh_auth_sock ExecStart=%h/bin/systemd_setenv %i

And then I activate services setenv@type.service depending on my needs. Here I also defined an environment variable inside the unit. The only reason for that is that the part "%t" (/run/user/1000/) is easier to find in a unit file...

Here is an example script to define my environment:

:::bash # $HOME/bin/systemd_setenv #!/bin/zsh if [ "x$1" = "xcommon" ]; then . /etc/zsh/zprofile source $HOME/.gpg-agent-info export GPG_AGENT_INFO systemctl --user import-environment systemctl --user unset-environment PWD OLDPWD SHLVL _ MANAGERPID elif [ "x$1" = "xgraphical" ]; then export XDG_CONFIG_HOME="$HOME/.config/" export SAL_USE_VCLPLUGIN=gtk export XDG_MENU_PREFIX="lxde-" export DISPLAY=:0 systemctl --user import-environment XDG_CONFIG_HOME SAL_USE_VCLPLUGIN XDG_MENU_PREFIX DISPLAY fi As I mentionned before, I have two different environments depending on whether I started a graphical session or simply a command line connection. Note that even if I leave the graphical environment, the variables are still there! We could make use of the command :::bash systemctl --user unset-environment VARIABLE1 VARIABLE2

in the same way to destroy variables after use (in which case the setenv service has to be adapted).

The `*-agent`s

Services that are worth starting no matter if we are in a graphical or command line remote session are ssh-agent and gpg-agent. However we need to think to transmit environment variables to the process that are interested (see Above section for more information).

The service envoy should also be considered to manage these agents. I prefer to separate both agent, which is not possible with envoy.

For ssh-agent, we can directly indicate in the command where we want to put the socket, which makes things easier:

:::bash # $HOME/.config/systemd/user/ssh-agent.service [Unit] Description=ssh-agent ConditionFileIsExecutable=/usr/bin/ssh-agent [Service] ExecStart=/usr/bin/ssh-agent -d -a %t/ssh_auth_sock Restart=always [Install] WantedBy=my_services.target

For gpg-agent, we can only tell him to save the informations in a file: the socket won't end in a predictable path.

:::bash # $HOME/.config/systemd/user/gpg-agent.service [Unit] Description=gpg-agent ConditionFileIsExecutable=/usr/bin/gpg-agent [Service] ExecStart=/usr/bin/gpg-agent --daemon --write-env-file %h/.gpg-agent-info Type=forking Restart=always [Install] WantedBy=my_services.target We can then source the file $HOME/.gpg-agent-info to access the agent socket. :::bash source $HOME/.gpg-agent-info

Note

The fact that we don't have a standard place can be a problem if the agent is restarted: most probably, the socket won't be in the same place, and programs that already started won't be able to contact the agent.

Using systemd to manage your graphical session

It can be tempting to use systemd to manage also your graphical session: defining your window manager as a service and be able to switch to another window manager at will without being obliged to restart your session. This can lead to some problems as we will see later.

Graphical session as a service file

The simplest to do there is to define a unit file graphical.target (or graphical@.target if you want to define several window managers) and activate it in the .xsession script (or whichever is executed when your session starts).
It can be necessary to correctly define the environment variables at that time, in which case each uni will need the service setenv@graphical.service activated as a prerequisite (as indicated before, it it not sufficient to put it int the After directive in graphical.target).

As pointed initialy, it is tempting to define your graphical session as a service. However:
First, the command systemct returns immediatly. Thus, a .xsession file containing only something like that:

:::bash # $HOME/.xsession export DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus systemctl --user start graphical.target

won't be enough, because your graphical session will disappear as soon as it starts (NB: the export DBUS_SESSION_BUS_ADDRESS is necessary to permit dialog with systemd). There exists programs such as systemd-wait that do exactly what we want to: wait for a service to end.

The second problem can be more annoying, and comes from the difference between the user session and services. If we don't take care, we will end up with something like that:

user-1000.slice
- session-c1.scope
  - systemd-wait -q --user graphique.service failed inactive
- user@1000.service
  - systemd --user
  - graphique.service
    - openbox
    - firefox
    - xterm
    - xterm
  - service_2.service
  - service_3.service

How can this be a problem? Because the only process considered active there is systemd-wait as we put it in the .xsession file. This can have consequences for instance in right management, see next section about polkit.

Note about `slim`

As specified on Archlinux website, slim is not compatible with systemd --user (at least it wasn't at the time when this article was writtent). What does that mean, and what can we do about it?

First of all, let's have a closer look to how slim works. slim is a connexion manager, that is, a sort of replacement of login in terminal-like tty's, but with a graphical interface. This has several implications: it has to deal with the problem of starting an X server, and has to launch the user session after his connexion. But he also have to take back control once the user leaves.

As the user logs in, slim start (via pam configuration) an instance of systemd --user, as well as a session script (for instance the .xsession file). It does not have to start an X server, since it is already there.
However when the user logs out however, it doesn't restart everything and reuses the state in which it was before. In the point of view of systemd, it then ends in the "scope" of the preceding user (even if it is still a root process):

Before log out:

system.slice
- slimd.service
  - slim
  - X
user.slice
- user-1000.slice
  - session-c1.scope
    - ...
  - user@1000.service

After log out:

system.slice
- slimd.service
user.slice
- user-1000.slice
  - session-c1.scope
    - slim
    - X
  - user@1000.service

This particular behaviour is particularly annoying for the next users. In Archlinux, slim has been patched recently to avoid this (since slim 1.3.6-4, 2014-04-21), by forcing slim to quit when a session ends (argument -nodaemon), and adding a Restart directive to the systemd unit file.

Note

The Restart directive is on-failure, but the patch makes slim quit with an error on purpose.

Another solution which was the one I used until the patch, if you are not using Archlinux and don't want to patch slim, is to put a line in /etc/slim.conf of the form

:::bash # /etc/slim.conf sessionstop_cmd systemctl restart slim.service that will have the effect to restart slim at the end of each session (which essentially does the same as the patch).

Polkit and administrative rights

Systemd distinguishes between two kind of users, that is "active" and "inactive" users. For instance, if two users are both connected on the same computer (physically), then only one of them is actually "active" (unless you have several monitors). It also makes a difference whether the user is "local" or "remote". This information about a session can be obtained with the command

loginctl show-session "session"

where "session" is the id of the session (you can list session ids with loginctl list-sessions).
In particular, and that's where it is important, a service is always inactive.

Polkit is a service that permits to give (temporarily or not) more rights to a user. For instance if you can turn off the computer without typing sudo or entering a password, then most probably polkit plays a role here. These rights are aranged depending on the state of the user, whether he is active or inactive or "any".

Important

Polkit and systemd don't share the same active notions. For polkit, an active/inactive user is local and active/inactive for systemd. Any other user is in any (in particular remote users). This rule is hard-coded in function check_authorization_sync of file src/polkitbackend/polkitbackendinteractiveauthority.c in source code of polkit:

if (session_is_local)
  {
    if (session_is_active)
      implicit_authorization = polkit_action_description_get_implicit_active (action_desc);
    else
      implicit_authorization = polkit_action_description_get_implicit_inactive (action_desc);
  }
else
  {
    implicit_authorization = polkit_action_description_get_implicit_any (action_desc);
  }

I won't go into much more details about polkit here, but we can already see that an xterm started as a service, and one started directly (for instance in your .xsession) won't have the same right for polkit! We thus have to be careful about that when we want to use systemd --user as a session manager, because it will then be unable to shutdown the computer without using sudo.

Shell invocation

2014-05-11T13:40:00+02:00

Bash and Zsh shells have very different ways to start, and this can be an issue when we switch from one to the other and back.

First, we distinguish two states for the shell:

Login/non-login shell,
interactive/non-interactive shell.

Shells make different actions depending on those two states.

Login shell

To indicate to a shell that it is a login shell, the calling process will simply add a - in front of his name (thus the shell will be called -bash or -zsh). Some shells (like bash) allow command line argument to fake login shells.

In a script, we can tell wether we are a login shell or not in a simple way:

Bash:
```
shopt -q login_shell
```
Zsh:
```
[[ -o login ]]
```

Interactive shell

A shell is interactive if it is invoked without argument (or at least none that imply a command).

In a script, we can tell wether we are an interactive shell:

[[ $- == *i* ]]

(It is possible to have an interactive shell with a script, for instance if a file is sourced).

Zsh behavior when invoked

In all cases, /etc/zshenv and ~/.zshenv are sourced (in this order).
If it is a login shell, /etc/zprofile and ~/.zprofile are sourced (in this order)

Note

/etc/zprofile is chosen at compile-time and can vary depending on the system (On Archlinux it is /etc/zsh/zprofile).
If we have an interactive shell, /etc/zshrc and ~/.zshrc are sourced (in this order).
Finaly, if it is a login shell (again!), /etc/zlogin et ~/.zlogin are sourced (in this order).

Bash behavior when invoked

If it is a login and interactive shell, /etc/profile is sourced, and then the first existing one in ~/.bash_profile, ~/.bash_login, ~/.profile.
If it is an interactive non-login shell, ~/.bashrc is sourced.
Finaly, if the shell is non-interactive, $BASH_ENV is sourced (if available).

Bash behavior when invoked as sh

In many distributions, sh is simply a soft link to bash. In that case, bash will behave in a different way when invoked:

If it is an interactive login shell, /etc/profile and ~/.profile are sourced.
If $ENV is a file, it is also sourced.

Shell invocation

2014-05-10T13:40:00+02:00

Bash et Zsh (pour ceux que je connais) ont des façons très différentes de démarrer, ce qui peut créer des soucis lorsqu'on passe de l'un à l'autre.

Pour commencer, on distingue deux états du shell :

Shell de login ou non
Shell interactif ou non

et les shells font des actions différentes en fonction de ces deux états.

Shell de login

Pour indiquer à un shell que c'est un shell de login, le programme qui l'appelle met simplement un - devant son nom (ainsi le shell s'appellera -bash ou -zsh). Certains shells (bash) permettent de donner un argument à la ligne de commande pour faire comme si c'était un shell de login

Dans un script, on peut savoir qu'on est dans un login de la façon suivante :

Bash:
```
shopt -q login_shell
```
Zsh:
```
[[ -o login ]]
```

Shell interactif

Un shell interactif est tout simplement un shell invoqué sans argument (du moins aucun qui n'implique une commande)

Dans un script, on peut savoir qu'on est en mode interactif de la façon suivante :

[[ $- == *i* ]]

(Oui c'est possible d'avoir un shell interactif avec un script, par exemple lorsqu'un fichier est sourcé)

Comportement de zsh à l'invocation

Dans tous les cas, /etc/zshenv et ~/.zshenv sont sourcés (dans cet ordre).
Si c'est un shell de login, /etc/zprofile et ~/.zprofile sont sourcés (dans cet ordre)

Note

/etc/zprofile est choisi à la compilation et peut varier selon les systèmes (Sur Archlinux c'est /etc/zsh/zprofile par exemple).
Si le shell est interactif, /etc/zshrc et ~/.zshrc sont sourcés (dans cet ordre).
Enfin, si c'est un shell de login (encore !) /etc/zlogin et ~/.zlogin sont sourcés (dans cet ordre toujours).

Comportement de bash à l'invocation

Si c'est un shell de login et interactif, /etc/profile est sourcé, puis le premier existant parmi ~/.bash_profile, ~/.bash_login, ~/.profile.
Si c'est un shell interactif non login, ~/.bashrc est sourcé.
Enfin, si c'est un shell non-interactif, $BASH_ENV est sourcé.

Bash invoqué comme sh

Dans beaucoup de distributions, sh est simplement un lien symbolique vers bash. Dans ce cas, bash se comportera différemment à l'invocation :

Si c'est un shell de login et interactif, /etc/profile et ~/.profile sont sourcés
Si $ENV est un fichier, il est sourcé également

Gérer sa session avec systemd

2014-05-10T00:00:00+02:00

Introduction

De plus en plus de distributions passent à "systemd" comme alternative à l'init de System V.

L'un des avantages de systemd est d'avoir un système de services pour l'utilisateur, et c'est ce système qu'on va utiliser pour gérer notre session. systemd est encore en développement actif, notamment pour la partie utilisateur. Ce guide tient compte du grand changement qu'il y a eu suite à la version 206 et sur laquelle sont basés la plupart des guides existant actuellement, et fonctionne au moins à la version 212.

Lorsqu'une session utilisateur démarre (que ce soit à distance via ssh ou en local), une instance de systemd --user démarre pour cet utilisateur. Cette instance a pour but de démarrer des services pour l'utilisateur, de façon similaire au processus 1 mais pour l'utilisateur. À noter que par défaut ces services se terminent quand la session de l'utilisateur disparaît.

Démarrage de `systemd --user`

Avant la version 206, sauf erreur, c'était l'utilisateur qui pouvait choisir de démarrer (ou non) cette instance. Maintenant elle ne peut plus être démarrée par l'utilisateur et c'est le gestionnaire qui doit la lancer.

Elle est démarrée automatiquement à la connexion à condition que le module pam_systemd soit actif dans pam pour le type de session demandé. Pour cela, on ajoute une ligne de la forme

-session   optional   pam_systemd.so

(Le "-" indiquant que ce n'est pas essentiel à la session. Dit autrement : si ça plante c'est pas grave on continue quand même). Sous Archlinux, le fichier /etc/pam.d/system-login contient déjà cette ligne et concerne tous les types de connexion, locale ou distante.

Agencement de systemd

Systemd sépare les différents services en slice/scope/service, via l'utilisation de cgroups (une façon de regrouper un ensemble de processus et leurs éventuels descendants sans échappatoire possible). Un système typique ressemble à ceci (obtenu avec systemd-cgls) :

system.slice
- service_systeme1.service
- service_systeme2.service
user.slice
- user-1000.slice
  - session-c1.scope
    - Programme 1
    - Programme 2
  - session-c2.scope
  - session-c3.scope
  - user@1000.service
    - systemd --user
    - service_user1000_1.service
    - service_user1000_2.service
    - service_user1000_3.service
- user-1001.slice
  - session-c4.scope
    - Programme 1
    - Programme 2
  - session-c5.scope
  - session-c6.scope
  - user@1001.service
    - systemd --user
    - service_user1001_1.service
    - service_user1001_2.service
    - service_user1001_3.service

On remarque que les services de l'utilisateur sont démarrés dans un contexte distinct de la session. Il faudra donc faire attention à la propagation des variables d'environnement.

Dès que toutes les `session-c*.scope` d'un utilisateur sont quittées, le service `user@.service` correspondant s'arrête également, et avec tous les sous-services. C'est un point important à noter ! Par exemple, en l'état, utiliser les "timers" de systemd comme remplacement à cron ne marchera pas !
Heureusement, on peut passer outre et s'en sortir quand même. On verra plus bas comment faire

Les services utilisateurs

Comparaison

Les services utilisateurs sont gérés exactement de la même façon que les services système, à ceci près que les unités (unit) sont recherchées dans des dossiers différents (cf. man systemd.unit). Au lancement de systemd --user, c'est l'unité default.target qui est lancée et qui lancera à son tour les services nécessaires.

`systemctl --user` et `dbus`

Les services gérés par systemd (qu'ils soient système ou utilisateur) se gèrent essentiellement via la commande systemctl (--user), qui dépend fortement de dbus. La première chose à faire est donc de s'assurer que dbus tourne, aussi bien au niveau système (system bus pour dbus) qu'au niveau utilisateur (session bus). Pour la partie système, on va se contenter d'ajouter une dépendance à user@.service. On va également normaliser le chemin du socket pour le session bus en l'indiquant dans la variable d'environnement appropriée DBUS_SESSION_BUS_ADDRESS. Comme user@.service est parent de tous les services de l'utilisateur, on va l'utiliser pour transmettre cette variable aussi :

:::bash hl_lines="3 6" # /etc/systemd/system/user@.service.d/dbus_env.conf [Unit] Wants=dbus.service [Service] Environment=DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/%I/bus

Note

La ligne 2 du fichier indique qu'on souhaite que le service dbus système soit démarré, alors que la ligne 5 concerne la variable d'environnement pour l'utilisateur. Ce sont donc deux bus différents qu'on configure ici.

Dans ce qui suit, on va définir des différents services dont on aura besoin. Ils peuvent être définis ou activés globalement ou à la discrétion de l'utilisateur. Cela se fait soit selon l'endroit où ils sont placés (/etc/systemd/user/ vs $HOME/.config/systemd/user) soit selon la façon dont ils sont activés (avec --global vs --user). Ici je vais définir les services et sockets associés à dbus globalement, mais ils seront ensuite activés ou non selon le choix de l'utilisateur :

:::bash # /etc/systemd/user/dbus.service [Unit] Description=D-Bus Message Bus Requires=dbus.socket [Service] ExecStart=/usr/bin/dbus-daemon --session --address=systemd: --nofork --nopidfile --systemd-activation ExecReload=/usr/bin/dbus-send --print-reply --session --type=method_call --dest=org.freedesktop.DBus / org.freedesktop.DBus.ReloadConfig Restart=always RestartSec=1

(on notera que la principale différence avec le service système de même nom est dans l'utilisation de --session au lieu de --system)

:::bash # /etc/systemd/user/dbus.socket [Unit] Description=D-Bus Message Bus Socket Before=sockets.target [Socket] ListenStream=/run/user/%U/bus [Install] WantedBy=default.target

(Pour rappel, default.target est la cible activée par défaut par systemd).

À partir de là, l'essentiel est fait. On crée un fichier mes_services.target alias de default.target

:::bash # $HOME/.config/systemd/user/mes_services.target [Unit] Description=Mes services Wants=dbus.service AllowIsolate=true [Install] Alias=default.target

puis on crée des fichiers service ou autres cibles dans le même dossier. Ensuite, on les active avec la commande systemctl, fait habituellement pour gérer les services systèmes, sauf qu'ici on ajoute l'argument --user. La suite du billet consistera essentiellement en des astuces et des cas spécifiques intéressants.

Remarque importante

La directive After n'a pas le même sens pour un service et pour un target. Un service ne sera démarré qu'une fois que tous les services cités dans After sont prêts (pour la définition de être prêt, cf le man systemd.service, bloc Type=), alors que pour un target il considère que les services cités font partie de lui (et peuvent donc être démarrés en même temps que d'autres services du target). Dans certains des cas présentés dans la suite cette distinction prend sens.

Des services utilisateur qui durent

Par défaut, les services associés à un utilisateur (tout ce qui est sous user@1001.service dans l'arborescence ci-dessus) sont arrêtés lorsque l'utilisateur se déconnecte de toutes ses sessions, notamment les timers qu'on aimerait utiliser comme remplacement à la crontab.

Passer outre se fait avec la commande suivante :

:::bash loginctl enable-linger user

Dans ce cas, user@.service sera démarré dès le boot pour l'utilisateur correspondant, même lorsque celui-ci n'est pas connecté.

Je n'entre pas dans les détails sur comment définir l'équivalent des crontabs avec systemd, c'est très bien expliqué dans les pages de manuel et sur les sites dédiés à systemd (ou man systemd.timer). L'astuce ci-dessus règle le problème d'avoir des crontab qui durent pour un utilisateur même lorsque celui-ci n'est pas connecté.

Remarque importante

Pour les mails envoyés par les crontabs, c'est une autre histoire. À ma connaissance les services de systemd loggent tout dans le journal, et aucun mail ne peut être programmé directement avec les services de systemd

Les variables d'environnement

Les variables d'environnement peuvent devenir un vrai casse-tête lorsqu'on utilise les services : comment transmettre les variables d'environnement nécessaires aux services, par exemple GPG_AGENT_INFO ou SSH_AUTH_SOCK ou même DISPLAY. Une des façons de faire est de spécifier dans le fichier du service une directive de la forme

:::bash Environment=DISPLAY=:0 ou :::bash EnvironmentFile=/fichier/a/charger

Le problème est que cette configuration est statique et doit être définie pour chaque service ou globalement dans un fichier /etc/systemd/system/user@.service.d/environment.conf. On perd le dynamisme habituel des scripts de configuration.

Ici, on va faire usage de la commande systemctl --user import-environment pour pallier ce problème. Cette commande permet d'importer des variables d'environnement, qui seront incluses dans les services démarrés par la suite. On commence par créer un service setenv.service qui va s'occuper de démarrer un script pour définir l'environnement. En ce qui me concerne je définis un environnement différent lorsque je suis en ligne de commande ou en graphique, du coup mon service dépend également de cela :

et j'active les services setenv@type.service selon les besoins. Ici par exemple, j'ai aussi défini une variable d'environnement pour le service. La raison est que la partie "%t" (/run/user/1000/) est plus facile à trouver dans ce fichier que dans un script... Il ne faudra juste pas oublier de l'appliquer dans le script ensuite.

Voici un exemple de script pour définir l'environnement :

:::bash # $HOME/bin/systemd_setenv #!/bin/zsh if [ "x$1" = "xcommun" ]; then . /etc/zsh/zprofile source $HOME/.gpg-agent-info export GPG_AGENT_INFO systemctl --user import-environment systemctl --user unset-environment PWD OLDPWD SHLVL _ MANAGERPID elif [ "x$1" = "xgraphique" ]; then export XDG_CONFIG_HOME="$HOME/.config/" export SAL_USE_VCLPLUGIN=gtk export XDG_MENU_PREFIX="lxde-" export DISPLAY=:0 systemctl --user import-environment XDG_CONFIG_HOME SAL_USE_VCLPLUGIN XDG_MENU_PREFIX DISPLAY fi Ici j'ai deux environnements différents selon que j'ai démarré une session graphique ou juste une invite en ligne de commande. À noter que même si je quitte l'environnement graphique, les variables définies par ce moyen restent définies pour les services démarrés par la suite... On pourrait utiliser la commande :::bash systemctl --user unset-environment VARIABLE1 VARIABLE2

de la même façon pour détruire les variables après utilisation (auquel cas il faut adapter le service setenv pour qu'il appelle un autre script — ou le même avec des arguments différents — lorsqu'on quitte l'interface graphique).

Les `*-agent`s

Des services qui vallent le coup d'être démarrés, peu importe le type de session (graphique ou console ou distant) sont notamment les services ssh-agent et gpg-agent. Il faut cependant penser à transmettre les variables d'environnement aux processus intéressés (cf. La section correspondante pour plus d'informations).

Le service envoy peut être utilisé pour gérer ces agents. Personnellement je préfère séparer les deux agents, ce qui n'est pas possible avec envoy.

Pour ssh-agent, on peut indiquer directement dans la commande d'exécution à quel endroit on souhaite mettre le socket, ce qui facilite les choses :

Pour gpg-agent, on ne peut que lui indiquer qu'on souhaite enregistrer les informations (les variables d'environnement) dans un fichier, et on ne peut pas forcer le socket à être placée à un endroit prévisible.

:::bash # $HOME/.config/systemd/user/gpg-agent.service [Unit] Description=gpg-agent ConditionFileIsExecutable=/usr/bin/gpg-agent [Service] ExecStart=/usr/bin/gpg-agent --daemon --write-env-file %h/.gpg-agent-info Type=forking Restart=always [Install] WantedBy=mes_services.target On peut ensuite charger le fichier $HOME/.gpg-agent-info pour avoir accès à l'agent. :::bash source $HOME/.gpg-agent-info

Note

Le fait de ne pas avoir un emplacement standard peut poser problème si par exemple l'agent redémarre : selon toute probabilité, le socket ne sera pas au même endroit par la suite et les programmes déjà lancés ne sauront pas où contacter l'agent.

Utiliser systemd pour gérer sa session graphique

Il peut être tentant d'utiliser systemd pour gérer également sa session graphique : définir son gestionnaire de fenêtre préféré comme un service et pouvoir l'arrêter et switcher vers un autre gestionnaire de fenêtre à volonté sans avoir à redémarrer sa session. On verra plus tard que cela peut poser de nouveaux problèmes.

Session graphique comme service

Le plus simple dans ce cas est de définir une unité graphical.target (ou graphical@.target si on veut définir plusieurs gestionnaires de fenêtre) et de l'activer dans le fichier .xsession (ou autre selon ce qui est exécuté pour la session).
Il peut être nécessaire d'avoir les variables d'environnement correctement définies à ce moment là, auquel cas chaque unité devra avoir le service setenv@graphical.service activé (comme indiqué précédemment, il ne suffit pas de le mettre en After dans le fichier graphical.target pour qu'il soit activé avant les autres).

Définir une session graphique comme service peut sembler appréciable. Deux problèmes se posent cependant :
Le premier est que systemctl retourne immédiatement. Ainsi, un fichier .xsession contenant uniquement

:::bash # $HOME/.xsession export DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus systemctl --user start graphical.target

ne sera pas suffisante, sous peine de voir sa session graphique disparaître à peine commencée (note: le export DBUS_SESSION_BUS_ADDRESS est nécessaire pour le dialogue avec systemd). Il existe des programmes tels que systemd-wait qui vont attendre la fin d'un service donné et peut être utilisé (selon le type de session).

Le deuxième problème est plus ennuyeux : il vient de la distinction entre la session utilisateur elle-même et les services. Si on ne fait pas attention, on risque de se retrouver avec quelque chose comme ça :

user-1000.slice
- session-c1.scope
  - systemd-wait -q --user graphique.service failed inactive
- user@1000.service
  - systemd --user
  - graphique.service
    - openbox
    - firefox
    - xterm
    - xterm
  - service_2.service
  - service_3.service

Pourquoi ça peut être gênant ? Parce que essentiellement le seul programme ici qui est considéré comme actif est le programme systemd-wait qu'on a mis dans le .xsession. Un peu plus en détails sur ce que ça implique dans la section suivante sur polkit.

Note à propos de `slim`

Comme précisé sur le site d'Archlinux, slim n'est pas compatible avec systemd --user (du moins il ne l'était pas au moment de l'écriture de cet article). Qu'est-ce que cela signifie concrètement, et que peut-on y faire ?

Premièrement, un petit zoom sur le fonctionnement de slim. slim est un gestionnaire de connexion, c'est-à-dire de façon simplifiée un équivalent du login dans les tty mais en graphique. Cela a plusieurs implications : il doit s'occuper de démarrer un serveur X, et de démarrer la session de l'utilisateur après la connexion. Mais il doit aussi reprendre la main quand l'utilisateur s'en va.

Au moment de la connexion de l'utilisateur (via la configuration dans pam), slim démarre une instance de systemd --user, ainsi qu'un script de l'utilisateur. Il ne démarre pas de serveur X puisqu'il est déjà démarré.
Au moment de la déconnexion cependant, il ne redémarre pas tout et réutilise l'état dans lequel il était. Du point de vue de systemd, slim passe donc dans le "scope" de l'utilisateur précédent (même s'il est toujours lancé par root):

Avant déconnexion :

system.slice
- slimd.service
  - slim
  - X
user.slice
- user-1000.slice
  - session-c1.scope
    - ...
  - user@1000.service

Après déconnexion :

system.slice
- slimd.service
user.slice
- user-1000.slice
  - session-c1.scope
    - slim
    - X
  - user@1000.service

Ce comportement là est ennuyeux pour les sessions suivantes. Sous Archlinux, slim a été patché pendant l'intervalle d'écriture de ce billet (depuis slim 1.3.6-4, 2014-04-21) pour éviter cela, en quittant systématiquement slim à la fin d'une session (avec l'argument -nodaemon) et en ajoutant une directive Restart à l'unité systemd de slim.

Note

La directive Restart est on-failure, mais le patch fait quitter slim avec une erreur.

Une autre solution si on n'est pas sous Archlinux et qu'on ne souhaite pas patcher slim est de mettre une ligne dans /etc/slim.conf de la forme

:::bash # /etc/slim.conf sessionstop_cmd systemctl restart slim.service

qui aura pour effet de redémarrer slim à la fin de chaque session (ce qui revient essentiellement au même que le patch).

Polkit et les droits d'administration

Systemd distingue deux types d'utilisateur, à savoir les utilisateurs "actifs" et "inactifs". Par exemple si deux utilisateurs sont connectés physiquement sur le même pc, un seul est réellement "actif". Il fait également une distinction selon que l'utilisateur est local ou distant. L'information peut être obtenue avec

:::bash loginctl show-session "session"

où "session" est l'identifiant de la session (on peut lister les sessions avec loginctl list-sessions).
En particulier, et c'est là que ça va devenir important, un service est toujours inactif.

Polkit est un service qui permet de donner, temporairement ou non, plus de droits à un utilisateur. Ces droits sont classés selon l'état de l'utilisateur, actif ou inactif ou autre.

Attention

Polkit et systemd n'ont pas la même notion d'utilisateur actif : pour polkit, un utilisateur actif/inactif est local et actif/inactif au sens de systemd. Tous les autres sont any (en particulier les utilisateurs distants). Cette règle est hardcodée dans la fonction check_authorization_sync du fichier src/polkitbackend/polkitbackendinteractiveauthority.c du code source de polkit :

:::c if (session_is_local) { if (session_is_active) implicit_authorization = polkit_action_description_get_implicit_active (action_desc); else implicit_authorization = polkit_action_description_get_implicit_inactive (action_desc); } else { implicit_authorization = polkit_action_description_get_implicit_any (action_desc); }

Je n'entrerai pas plus dans les détails sur polkit dans ce billet, mais on remarque déjà qu'un xterm démarré en tant que service et un démarré directement (par exemple via le fichier .xsession) n'auront pas les mêmes droits du point de vue de polkit ! Il faut donc faire attention à cela lorsqu'on souhaite utiliser systemd --user comme gestionnaire de session, car par exemple il sera incapable d'éteindre le pc sans sudo.

Bash TCP/UDP sockets

2014-04-06T17:00:00+02:00

On peut ouvrir facilement avec bash un socket TCP ou UDP pour communiquer avec un serveur distant :

echo -n "test" >/dev/tcp/192.168.0.13/8000

(Remplacer l'ip et le port par ceux que vous voulez contacter. L'ip peut être remplacée par un nom de domaine valide).

Ça marche dans les deux sens bien sûr :

exec 42<>/dev/tcp/immae.eu/80
echo -ne "GET /blog/ HTTP/1.1\nHost: immae.eu\nConnection: close\n\n" >&42
cat <&42

Setup an IPv6 VPN with an OVH server

2014-04-02T19:20:00+02:00

Introduction

This tutorial combines a solution to two different but related problems:

The desire that machines not necessarily adjacent belong to the same LAN. This is typically the role of a VPN
The fact that the majority of the Internet (IPv4) today consists of machines hidden behind subnets and therefore is impossible to contact them publicly without using port redirection (which prevents then having two machines in the network providing the same service on the same port).

In the specific case that I will discuss, I have a personal server (by OVH), with a unique IPv4 address (198.51.100.24), and a /64 IPv6 subnet (2001:db8:200:13::/64), both fixed.

Besides that, I have several PCs with different configurations and Internet access, more or less restricted, in different networks and not necessarily connected to each other (not even in the same country) and I that I would like to connect with a virtual network.

To create the virtual network, we have two options:

Either we create a private IPv4 subnet (but then attention to headaches if by chance the machine happens to be on an identical physical network
Otherwise... We have access to no less than 2⁶⁴ IPv6 addresses via our OVH server that we can take advantage of!

Creating a virtual subnet

To create this network, I use tinc. This program is quite simple, and intuitive once you understand what a VPN is.

In this particular case, interconnectin our machines is quite simple: all of them are able to contact the server (which has a public Ipv4), so we just need to ask each of them to connect to the server. tinc will then take care the interconnection!

Common part

This part has to be done on both the clients and the server of the VPN:

We start by installing tinc (via the software manager of our favorite distribution)
tinc is able to manage multiple VPN networks, in which case the different configurations go in separate subfolders of the form /etc/tinc/NAME (NAME doesn't have to be common among the different hosts of the same network)
- On a Debian-like distribution, you need a file /etc/tinc/nets.boot that contains the list of configurations that are automatically started at boot time (provided that the service is enabled)
- On a distribution that works with systemd, you need to enable separately each tincd@NAME.service.
We create a file called tinc.conf with at least:
```
Name = HostName
Interface = vpn6

Mode = switch
```
Here Name is the name of the host in the VPN, and Interface is the interface name associated to the VPN that will be created.

It might be necessary to add a Device line if the default value is incorrect.

# The tap device tinc will use.
# Default is /dev/tap0 for ethertap or FreeBSD,
# /dev/tun0 for Solaris and OpenBSD,
# and /dev/net/tun for Linux tun/tap device.
Device = /dev/net/tun

If necessary, load the tun module

modprobe tun

We then create the public/private key pair that will be used by the host:
```
tincd -n NAME -K
```
Put the public part (.pub) in /etc/tinc/NAME/hosts/HostName (publicly readable, create the hosts directory), and keep the private part in /etc/tinc/NAME/ readable only by root.
That's it for the common part.

Server part

The server part is the more complex one. Let's go into more details:

tinc can run two scripts tinc-up and tinc-down if they are present (and executable) in /etc/tinc/NAME/tinc-{up,down} when the service starts/stops. We need to add a few commands there:
```
# tinc-up
#!/bin/bash
echo 1 > /proc/sys/net/ipv6/conf/eth0/proxy_ndp
echo 1 > /proc/sys/net/ipv6/conf/all/forwarding

ip -6 link set $INTERFACE up mtu 1280 txqueuelen 1000
ip -6 addr add 2001:db8:200:13:1::1/96 dev $INTERFACE
ip -6 route add 2001:db8:200:13:1::/80 dev $INTERFACE

ip neigh add proxy 2001:db8:200:13:1::1 dev eth0
```
and
```
# tinc-down
#!/bin/bash
echo 0 > /proc/sys/net/ipv6/conf/eth0/proxy_ndp
echo 0 > /proc/sys/net/ipv6/conf/all/forwarding

ip neigh del proxy 2001:db8:200:13:1::1 dev eth0

ip -6 addr del 2001:db8:200:13:1::1/96 dev $INTERFACE
ip -6 link set $INTERFACE down
```
Don't forget to change eth0 by the interface on which the IPv4 is linked, and the IPv6 addresses by yours.
Here I chose to use only the part 2001:db8:200:13:1::/80 for the VPN, and to assign the first of it to the server.
The line echo 1 > /proc/sys/net/ipv6/conf/eth0/proxy_ndp is important in that case because we will only provide addresses in the /64 part of it, and without this packets will not broadcast from the outside of the VPN inward (conversely, if you want to remain closed in the VPN, you can remove this line).
The explanation is a little unclear to me, but if I understood correctly the last 64 bits of the address are assumed to be local and therefore not routed. More specifically, when the server receives on eth0 a request of the form Where can I contact 2001:db8:200:13:1::42? (by the OVH router to which it is linked), he will answer me (under some conditions that we will see afterwards), and then will follow it to it's target inside of the VPN.
Now the configuration part is done for the server. We'll have to tell him afterwards who are the clients. We should keep the file /etc/tinc/Immae/hosts/HostName accessible since it will have to be transmitted to each of the clients.

Client part

I'll use here the term ServerName to design the name of the server as defined on line Name of the configuration file tinc.conf on the server.

Get /etc/tinc/Immae/hosts/ServerName on the server and put it in /etc/tinc/Immae/hosts/ (next to your own), edit it and add a line at the top of the file:
```
Address = 198.51.100.24
```
(Replace the ip address by the IPv4 address of the server, or possibly its domain name)

Edit the file tinc.conf and add the informations for him to connect to the server:

# The internet host to connect with.
# Comment these out to make yourself a listen-only connection
# You must use the name of another tinc host.
# May be used multiple times for redundance.
ConnectTo = ServerName

We will also create files tinc-up and tinc-down as on the server, but now we don't need to activate a proxy of forward:

# tinc-up
#!/bin/bash

ip -6 link set $INTERFACE up mtu 1280
ip -6 addr add 2001:db8:200:13:1::42/96 dev $INTERFACE
ip -6 route add default via 2001:db8:200:13:1::1

and

# tinc-down
#!/bin/bash

ip -6 addr del 2001:db8:200:13:1::42/96 dev $INTERFACE
ip -6 link set $INTERFACE down

Be careful of course not to chose the same ip for two clients of the same VPN.

Client-Server connexion

Here I use ClientName to designate the name chosen by a client.

Now we need to inform the server that the client is authorized in the VPN. For that, we send the file /etc/tinc/NAME/hosts/ClientName from the client to the server in the corresponding directory (keep the same name).

Finally, we need to create two (executable) files ClientName-up and ClientName-down in the subfolder hosts/ on the server to set up and destroy the proxy when the client comes and goes:

# hosts/NomDuClient-up
#!/bin/bash

ip neigh add proxy 2001:db8:200:13:1::42 dev eth0

and

# hosts/NomDuClient-down
#!/bin/bash

ip neigh del proxy 2001:db8:200:13:1::42 dev eth0

End, configuration details

Now you just need to start the different tinc services on the machines, and everyone will be interconnected and be able to access to the IPv6 Internet! To sum up, the folders /etc/tinc/NAME/ should look like that:

# Server$ ls -1R /etc/tinc/NAME
/etc/tinc/NAME:
hosts
rsa_key.priv
tinc-down
tinc-up
tinc.conf

/etc/tinc/NAME/hosts:
Server
Client1
Client1-up
Client1-down
Client2
Client2-up
Client2-down

and

# Client1$ ls -1R /etc/tinc/NAME
/etc/tinc/NAME:
hosts
rsa_key.priv
tinc-down
tinc-up
tinc.conf

/etc/tinc/NAME/hosts:
Server
Client1

Important note

By default, recent Linux distribution give priority to IPv6 for Internet connection. That means that all the connections will go through the server as soon as IPv6 is available for the requested service. To avoid that, you can edit the file /etc/gai.conf, in which a section explains exactly how to do that (i.e. give priority to l'IPv4). Note that this configuration can be triggered independently on each client (see below).

By default:

# /etc/gai.conf
#    Add another rule to the RFC 3484 precedence table.  See section 2.1
#    and 10.3 in RFC 3484.  The default is:
#
#precedence  ::1/128       50
#precedence  ::/0          40
#precedence  2002::/16     30
#precedence ::/96          20
#precedence ::ffff:0:0/96  10
#
#    For sites which prefer IPv4 connections change the last line to
#
#precedence ::ffff:0:0/96  100

To give priority to IPv4 connectivity:

# /etc/gai.conf
#    Add another rule to the RFC 3484 precedence table.  See section 2.1
#    and 10.3 in RFC 3484.  The default is:
#
precedence  ::1/128       50
precedence  ::/0          40
precedence  2002::/16     30
precedence ::/96          20
#precedence ::ffff:0:0/96  10
#
#    For sites which prefer IPv4 connections change the last line to
#
precedence ::ffff:0:0/96  100

Installer un VPN en IPv6 avec un serveur OVH

2014-03-30T22:20:00+02:00

Introduction

Ce tutoriel combine une solution à deux problèmes différents mais assez liés :

Le fait de vouloir que des machines pas forcément voisines appartiennent au même réseau local. C'est typiquement le rôle d'un VPN
Le fait que la majorité du réseau Internet (IPv4) de nos jours est constitué de sous-réseaux cachés derrière des routeurs et qu'il est donc impossible de contacter publiquement les machines de ces sous-réseaux à moins d'avoir recours à des redirections de ports (ce qui empêche du coup que deux machines du même réseau proposent le même service sur le même port).

Dans le cas précis que je vais traiter, j'ai un serveur personnel (chez OVH), possédant une unique adresse IPv4 (198.51.100.24), et un /64 en IPv6 (2001:db8:200:13::/64), toutes les deux fixes.

À côté de ça, j'ai plusieurs PCs avec des configurations diverses et des accès à Internet plus ou moins restreints, dans des réseaux différents et non nécessairement connectés entre eux (voire pas dans le même pays) et que j'aimerais relier par un réseau virtuel.

Pour créer le réseau virtuel, deux possibilités s'offrent à nous :

Soit on crée un sous réseau IPv4 privé (mais alors attention aux maux de têtes si par malheur on branche le pc sur un réseau physique identique)
Sinon...On a accès à pas moins de 2⁶⁴ adresses IPv6 via notre serveur OVH, qu'on peut mettre à profit !

Création d'un sous-réseau virtuel

Pour créer ce réseau, j'utilise tinc. C'est un programme assez simple, et assez intuitif une fois qu'on a compris en quoi consiste un VPN.

Dans ce cas particulier, la façon d'interconnecter nos machines est assez simple : toutes sont capables de se connecter au serveur (qui a une IPv4 publique). Il suffit donc de demander à chacune de s'y connecter. tinc s'occupe alors de l'interconnexion entre elles !

Partie commune

Cette partie est à faire pour chacun des hôtes du VPN, que ce soit le client ou le serveur :

On commence par installer tinc (via les paquets de votre distribution préférée)
tinc est capable de gérer plusieurs réseaux VPN, auquel cas on sépare les dossier en créant un sous-dossier dans /etc/tinc/NAME pour chaque configuration (NAME n'a pas besoin d'être le même entre les différents hôtes)
- Sur une distribution de type Debian ou dérivé, il faut un fichier /etc/tinc/nets.boot qui contienne la liste des dossiers qui sont démarrés automatiquement au démarrage (à condition que le service soit activé)
- Sur une distribution qui utilise systemd, il faut activer le(s) service(s) tincd@NAME.service séparément.
On crée le fichier de configuration tinc.conf, avec au minimum :
```
Name = NomDeLHote
Interface = vpn6

Mode = switch
```
Ici, Name désigne le nom de l'hôte dans le réseau VPN, et Interface est le nom de l'interface associée au VPN qui sera créée.

Il faut éventuellement ajouter une ligne Device si la valeur par défaut n'est pas correcte.

# The tap device tinc will use.
# Default is /dev/tap0 for ethertap or FreeBSD,
# /dev/tun0 for Solaris and OpenBSD,
# and /dev/net/tun for Linux tun/tap device.
Device = /dev/net/tun

Si nécessaire, charger le module tun

modprobe tun

On crée ensuite le couple clé publique/clé privée qu'on va utiliser pour l'hôte :
```
tincd -n NAME -K
```
Mettre la partie publique (en .pub) dans /etc/tinc/NAME/hosts/NomDeLHote (en lecture publique, créer le dossier hosts), et garder la partie privée dans /etc/tinc/NAME/ uniquement lisible par root.
Voilà pour la partie commune.

Partie serveur

La partie serveur est la partie la plus complexe. Plus en détails :

tinc peut lancer deux scripts tinc-up et tinc-down s'ils sont présents (et exécutables) dans /etc/tinc/NAME/tinc-{up,down} au moment du démarrage/de l'arrêt du serveur. Ici, on va avoir besoin d'ajouter quelques commandes :
```
# tinc-up
#!/bin/bash
echo 1 > /proc/sys/net/ipv6/conf/eth0/proxy_ndp
echo 1 > /proc/sys/net/ipv6/conf/all/forwarding

ip -6 link set $INTERFACE up mtu 1280 txqueuelen 1000
ip -6 addr add 2001:db8:200:13:1::1/96 dev $INTERFACE
ip -6 route add 2001:db8:200:13:1::/80 dev $INTERFACE

ip neigh add proxy 2001:db8:200:13:1::1 dev eth0
```
et
```
# tinc-down
#!/bin/bash
echo 0 > /proc/sys/net/ipv6/conf/eth0/proxy_ndp
echo 0 > /proc/sys/net/ipv6/conf/all/forwarding

ip neigh del proxy 2001:db8:200:13:1::1 dev eth0

ip -6 addr del 2001:db8:200:13:1::1/96 dev $INTERFACE
ip -6 link set $INTERFACE down
```
Penser à remplacer eth0 par l'interface sur laquelle arrive l'IPv4, et les IPv6 par les vôtres.
Ici, j'ai fait le choix de n'utiliser que la partie 2001:db8:200:13:1::/80 pour le VPN, et d'assigner au VPN la première de ces adresses.
La ligne echo 1 > /proc/sys/net/ipv6/conf/eth0/proxy_ndp est importante dans ce cas précis car on ne va donner des adresses que dans la partie en /64 de l'adresse et sans ça les paquets ne seront pas retransmis de l'extérieur du VPN vers l'intérieur (à l'inverse, si on veut rester fermé dans le VPN, on peut enlever cette ligne).
L'explication est un peu floue pour moi, mais si j'ai bien compris les 64 derniers bits de l'adresse sont censés être locaux et donc non routés. Plus précisément, quand le serveur recevra sur eth0 une demande de la forme où puis-je contacter 2001:db8:200:13:1::42 ? (par le routeur d'OVH auquel il est attaché), il répondra c'est moi (sous certaines conditions, on verra ensuite), puis il fera suivre à qui de droit dans le VPN.
Voilà, la partie configuration pour le serveur est essentiellement finie. Il va falloir lui faire connaître ensuite chacun des clients du VPN. On peut mettre de côté le fichier /etc/tinc/Immae/hosts/NomDeLHote car on va devoir le transmettre à chacun des clients

Partie client

J'utilise ici le terme NomDuServeur pour désigner le nom du serveur tel qu'on l'a défini à la ligne Name dans le fichier tinc.conf pour le serveur.

Récupérer /etc/tinc/Immae/hosts/NomDuServeur sur le serveur et le mettre dans /etc/tinc/Immae/hosts/ (à côté du sien), l'éditer et ajouter une ligne au début :
```
Address = 198.51.100.24
```
(Remplacer l'ip par l'adresse IPv4 du serveur, ou éventuellement son nom de domaine)

Éditer le fichier tinc.conf et ajouter les informations pour qu'il se connecte au serveur :

# The internet host to connect with.
# Comment these out to make yourself a listen-only connection
# You must use the name of another tinc host.
# May be used multiple times for redundance.
ConnectTo = NomDuServeur

On va également créer des fichiers tinc-up et tinc-down comme sur le serveur, mais cette fois on n'a pas besoin d'activer de proxy ni de forward :

# tinc-up
#!/bin/bash

ip -6 link set $INTERFACE up mtu 1280
ip -6 addr add 2001:db8:200:13:1::42/96 dev $INTERFACE
ip -6 route add default via 2001:db8:200:13:1::1

# tinc-down
#!/bin/bash

ip -6 addr del 2001:db8:200:13:1::42/96 dev $INTERFACE
ip -6 link set $INTERFACE down

Il faut bien sûr faire attention à ne pas prendre deux fois la même ip pour deux clients différents du VPN.

Connexion Client-Serveur

J'utilise ici NomDuClient pour désigner le nom choisi par un client.

Maintenant il faut faire savoir au serveur que le client est autorisé, pour cela il faut envoyer le fichier /etc/tinc/NAME/hosts/NomDuClient du client vers le serveur dans le dossier correspondant (en conservant le nom du fichier).
Finalement, il faut créer deux fichiers (exécutables) NomDuClient-up et NomDuClient-down dans le dossier hosts/ sur le serveur pour mettre en place et détruire le proxy lorsque le client apparaît et disparaît :
```
# hosts/NomDuClient-up
#!/bin/bash

ip neigh add proxy 2001:db8:200:13:1::42 dev eth0
```
et
```
# hosts/NomDuClient-down
#!/bin/bash

ip neigh del proxy 2001:db8:200:13:1::42 dev eth0
```

Fin, détails de configuration

Plus qu'à démarrer les différents services tinc sur les machines, et tout le monde sera interconnecté et pourra accéder au net en IPv6 ! Pour résumer, les répertoires /etc/tinc/NAME/ devraient ressembler à ça :

# Serveur$ ls -1R /etc/tinc/NAME
/etc/tinc/NAME:
hosts
rsa_key.priv
tinc-down
tinc-up
tinc.conf

/etc/tinc/NAME/hosts:
Serveur
Client1
Client1-up
Client1-down
Client2
Client2-up
Client2-down

# Client1$ ls -1R /etc/tinc/NAME
/etc/tinc/NAME:
hosts
rsa_key.priv
tinc-down
tinc-up
tinc.conf

/etc/tinc/NAME/hosts:
Serveur
Client1

Remarque importante

Par défaut, les distributions récentes de Linux donnent priorité à l'IPv6 pour les connexions Internet. Cela signifie concrètement que toutes les connexions vont passer en priorité par votre serveur dès lors que l'IPv6 est disponible pour le service demandé. Pour éviter cela, on peut éditer le fichier /etc/gai.conf, dans lequel une section explique justement comment faire (i.e. donner priorité à l'IPv4). Notez que cette configuration se fait au choix sur chaque client indépendamment (voir ci-dessous).

Par défaut :

# /etc/gai.conf
#    Add another rule to the RFC 3484 precedence table.  See section 2.1
#    and 10.3 in RFC 3484.  The default is:
#
#precedence  ::1/128       50
#precedence  ::/0          40
#precedence  2002::/16     30
#precedence ::/96          20
#precedence ::ffff:0:0/96  10
#
#    For sites which prefer IPv4 connections change the last line to
#
#precedence ::ffff:0:0/96  100

Pour donner priorité à l'IPv4 :

# /etc/gai.conf
#    Add another rule to the RFC 3484 precedence table.  See section 2.1
#    and 10.3 in RFC 3484.  The default is:
#
precedence  ::1/128       50
precedence  ::/0          40
precedence  2002::/16     30
precedence ::/96          20
#precedence ::ffff:0:0/96  10
#
#    For sites which prefer IPv4 connections change the last line to
#
precedence ::ffff:0:0/96  100

Immae's blog

Migrate from RAID1 disk to ZFS on NixOS

Context

Setup

Play with libvirtd

Migration process

Add the new disk to the RAID array

Remove sda from the array

Add ZFS-specific configuration to nix

Convert sda3 to a ZFS filesystem

Let NixOS know about new filesystem

Go in maintenance mode, resynchronize and prepare next boot

Cleanup old system

Manage your session with systemd

Introduction

Starting systemd --user

Systemd arrangement

User services

Comparison

systemctl --user and dbus

User services that last

Environment variables

The *-agents

Using systemd to manage your graphical session

Graphical session as a service file

Note about slim

Polkit and administrative rights

Shell invocation

Login shell

Interactive shell

Zsh behavior when invoked

Bash behavior when invoked

Bash behavior when invoked as sh

Shell invocation

Shell de login

Shell interactif

Comportement de zsh à l'invocation

Comportement de bash à l'invocation

Bash invoqué comme sh

Gérer sa session avec systemd

Introduction

Démarrage de systemd --user

Agencement de systemd

Les services utilisateurs

Comparaison

systemctl --user et dbus

Des services utilisateur qui durent

Les variables d'environnement

Les *-agents

Utiliser systemd pour gérer sa session graphique

Session graphique comme service

Note à propos de slim

Polkit et les droits d'administration

Bash TCP/UDP sockets

Setup an IPv6 VPN with an OVH server

Introduction

Creating a virtual subnet

Common part

Server part

Client part

Client-Server connexion

End, configuration details

Installer un VPN en IPv6 avec un serveur OVH

Introduction

Création d'un sous-réseau virtuel

Partie commune

Partie serveur

Partie client

Connexion Client-Serveur

Fin, détails de configuration

Starting `systemd --user`

`systemctl --user` and `dbus`

The `*-agent`s

Note about `slim`

Démarrage de `systemd --user`

`systemctl --user` et `dbus`

Les `*-agent`s

Note à propos de `slim`