• Réunion précédente
• Pad de la réunion

Heure de début : 13h00

Présences :

• HgO
• Célo

Moment informel durant lequel on exprime en peu de mots comment on se sent et si on a une attente forte pour la réunion. Ce n'est pas un moment de discussion mais d'expression individuelle et ce n'est pas obligatoire

Si l'une ou l'autre personne exprime une attente forte, merci de vous en occuper en priorité ou de la noter dans le hub ou dans un point approprié.

Fin: 17h30

Pour le contexte, on a trois serveur Dell PowerEdge R620 que l'on souhaite mettre à LouiseDC en remplacement de nos serveurs HP.

On a mis 128Go de RAM (8 barrettes DDR3 de 16Go). Sur le même serveur, elles sont toutes identiques, mais ce n'est pas le cas entre chaque serveur.

On a deux CPU E5-2640 (6 cores) sur chaque serveur.

Enfin, on a préparé des disques SSD, mais ils sont pas encore branché sur le serveur. Le disque de données prévu pour Ceph n'est pas encore utilisable (car on va réutiliser ceux des HP).

On va commencer par faire un arp-scan, parce qu'un serveur, c'est jamais qu'une grosse brique internet.

$ arp-scan -l
172.16.0.97 
172.16.0.98
172.16.0.99

On se connecte en HTTPS sur ces IP. Bon à savoir: le mot de passe par défaut est calvin pour l'utilisateur root.

Une fois connecté à l'interface, on va dans l'onglet “Media connecté”. On va mettre l'iso de Debian qu'on veut utiliser.

L'ISO est stockée sur un partage NFS au niveau du Caldarium. Tharyrok nous a indiqué le chemin de l'ISO à utiliser :

abu.home.caldarium.be:/media/data/publique/tharyrok/debian-live-12.5.0-amd64-standard.iso

On clique ensuite sur “Connecter” (si un ISO est déjà présent, on le déconnecte).

On active aussi “Activer Démarrer une seule fois”

Depuis la page de résumé, on allume les serveur en allant dans “Tâches de lancement rapide”, “Alimentation sous tension / hors tension”.

On peut lancer la console pour voir ce qu'il fait (il faut accepter les popup).

Le serveur se lance puis redémarre.

On va suivre ce qu'on avait il y a fort fort longtemps pour chiffrer les serveurs:

https://wiki.neutrinet.be/fr/rapports/2022/06-11#reinstallation_de_debian_et_chiffrement_de_nam

Pendant que le serveur s'allume, on découvre qu'on peut discuter par chat via l'idrac du serveur !

On se rend compte qu'on n'arrive pas à se connecter depuis le réseau. On pensait avoir réussi mais en réalité, le serveur boot sur le disque, où proxmox est installé parce que Tharyrok a fait des tests.

Après plusieurs essais infructueux, on tente de booter depuis un disque USB, cela fonctionne avec une Ventoy et une partition de 16Gb. Autre méthode: on a utilisé la fonction qui permet de mapper l'iso depuis la console.

Pour forcer le démarrage sur le disque USB ou le CD virtuel, on tape F11 au démarrage du serveur, ce qui lance le gestionnaire de boot. Ensuite, on choisit BOOT mode, et Hard Drive pour le disque USB ou Virtual CD pour le disque virtuel. Pour un boot depuis une image sur le réseau (serveur NFS), apparemment, il faut aussi choisir le Virtual CD (c'est super intuitif).

Là, on arrive à lancer l'intsallation de Debian sur base de l'ISO. Mais l'installation échoue au moment de partitionner les disques, il dit qu'il y a un problème avec le RAID.

On l'annule et on lance un shell.

On se connecte sur le serveur. On vérifie son IP et qu'il a internet.

NB : en testant si le serveur est connecté à internet avec ping, la console est restée bloquée et ne répondait plus pour arrêter le ping. Il a fallu la redémarrer.

On lance un serveur ssh… Problème, à ce stade, on n'a pas encore ssh d'installé. On ne parvient pas à faire un apt update non plus. Et fdisk ne fonctionne pas.

En revenant en arrière, on a encorre moins de commande…

On se dit que le problème vient de la swap qui est installée sur les disques. On essaie de la supprimer en bootant sur les disques, sauf que à présent on a une erreur:

error: failure reading sector […]
error: disk mduuid/[…] not found

On va tenter de booter via un system rescue: https://www.system-rescue.org/Download/

Depuis le system rescue, on a supprimé les partitions sur les disques.

En relançant l'installation, cette fois ça passe. Le preseed est configuré pour faire toutes les opérations automatiquement donc on attend.

Après tous ces essais, on réalise qu'en fait on utilisait la mauvaise image de Debian: il fallait prendre un live debian (ce qu'on avait fait au début, mais en changeant de méthode de boot on a pris la mauvaise image).

On finit donc au bout de 4h par booter sur la bonne image.

[En fait il fallait faire F11 et choisir virtual CD pour booter sur l'iso renseigné dans “Média Connectés”… c'était tout siiiiimple /o\ (mais pas très logique)]

On fait ip a ainsi que sudo apt update et sudo apt install openssh-server pour avoir un serveur SSH et continuer depuis un terminal digne de ce nom. On lance le serveur ssh: sudo systemctl start ssh

Enfin, on donne un mot de passe à l'utilisateur user pour pouvoir s'y connecter en ssh.

On va sur l'iDrac, en se connectant en HTTPS. Les identifiants par défaut sont root et calvin.

Dans Média connecté on attache le disque sur le réseau:

abu.home.caldarium.be:/media/data/publique/tharyrok/debian-live-12.5.0-amd64-standard.iso

Ensuite, on (re)démarre le serveur via l'iDrac, et on lance la console.

Lors du démarrage, on appuie sur F11 pour lancer le gestionnaire de boot. On choisit ensuite BIOS boot, puis Virtual CD.

Le menu du Debian Live s'affiche, on démarre le live debian.

On fait ip a ainsi que sudo apt update et sudo apt install openssh-server pour avoir un serveur SSH et continuer depuis un terminal digne de ce nom. On lance le serveur ssh: sudo systemctl start ssh

Enfin, on donne un mot de passe à l'utilisateur user pour pouvoir s'y connecter en ssh:

sudo passwd user

On installe les dépendances nécessaire pour chiffrer les disques:

apt install -y cryptsetup debootstrap arch-install-scripts xfsprogs

On vérifie les disques présents avec lsblk. On voit qu'on a bien les deux disques SSD qui sont présents. S'il y avait un RAID matériel, on ne verrait qu'un seul disque. Comme ce n'est pas le cas, on va donc devoir créer un RAID software avec mdadm, qui est déjà installé dans le live Debian.

:::info Pourquoi faisons-nous un raid logiciel et pas un raid matériel ?

On flash les cartes raid pour qu'elles deviennent des cartes SAS passthrough, cela ameliore les performances mais c'est surtout utilisé pour ceph pour avoir un acces direct sans surcouche pour les OSD.

On s'est basé sur ce wiki pour flasher les cartes raid de Dell https://fohdeesha.com/docs/perc.html :::

user@debian:~$ lsblk 
NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
loop0    7:0    0 981.5M  1 loop /usr/lib/live/mount/rootfs/filesystem.squashfs
                                 /run/live/rootfs/filesystem.squashfs
sda      8:0    0 232.9G  0 disk 
├─sda1   8:1    0     1M  0 part 
├─sda2   8:2    0   4.8G  0 part 
├─sda3   8:3    0   1.9G  0 part 
└─sda4   8:4    0 226.2G  0 part 
sdb      8:16   0 232.9G  0 disk 
├─sdb1   8:17   0     1M  0 part 
├─sdb2   8:18   0   4.8G  0 part 
├─sdb3   8:19   0   1.9G  0 part 
└─sdb4   8:20   0 226.2G  0 part 
sdc      8:32   1     0B  0 disk 
sr0     11:0    1   1.4G  0 rom  /usr/lib/live/mount/medium
                                 /run/live/medium

S'il y a déjà un RAID software présent, on doit arrêter avant de pouvoir le supprimer:

mdadm --stop /dev/mdX

Dans notre cas, il y avait deux RAID (/dev/md127 et /dev/md126), on a donc fait:

mdadm --stop /dev/md126
mdadm --stop /dev/md127

Ensuite, on supprime les partitions existantes pour avoir quelque chose de propre:

fdisk /dev/sda

Et on appuie 4 fois sur d pour supprimer les 4 partitions. Enfin, on appuie p pour vérifier que tout est supprimé, et sur w pour appliquer les modifications. En cas de doute, la touche m permet d'afficher l'aide.

On fait pareil pour /dev/sdb.

À la fin, on a quelque chose comme ceci:

NAME  MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
loop0   7:0    0 981.5M  1 loop /usr/lib/live/mount/rootfs/filesystem.squashfs
                                /run/live/rootfs/filesystem.squashfs
sda     8:0    0 232.9G  0 disk 
sdb     8:16   0 232.9G  0 disk 
sdc     8:32   1     0B  0 disk 
sr0    11:0    1   1.4G  0 rom  /usr/lib/live/mount/medium
                                /run/live/medium`

On va partitionner et puis ensuite faire le raid. On va faire un raid pour la swap aussi au cas où un disque casse.

On va utiliser parted, qu'on doit installer. On pourrait aussi utiliser fdisk…

On commence avec le disque /dev/sda:

parted -s -a optimal -- /dev/sda mklabel gpt
parted -s -a optimal -- /dev/sda mkpart primary 1MiB 3MiB
parted -s -a optimal -- /dev/sda set 1 bios_grub on
parted -s -a optimal -- /dev/sda mkpart primary 3MiB 1GiB
parted -s -a optimal -- /dev/sda set 2 raid on
parted -s -a optimal -- /dev/sda mkpart primary 1GiB 5GiB
parted -s -a optimal -- /dev/sda set 3 raid on
parted -s -a optimal -- /dev/sda mkpart primary 5GiB 100%
parted -s -a optimal -- /dev/sda set 4 raid on

Puis le disque /dev/sdb:

parted -s -a optimal -- /dev/sdb mklabel gpt
parted -s -a optimal -- /dev/sdb mkpart primary 1MiB 3MiB
parted -s -a optimal -- /dev/sdb set 1 bios_grub on
parted -s -a optimal -- /dev/sdb mkpart primary 3MiB 1GiB
parted -s -a optimal -- /dev/sdb set 2 raid on
parted -s -a optimal -- /dev/sdb mkpart primary 1GiB 5GiB
parted -s -a optimal -- /dev/sdb set 3 raid on
parted -s -a optimal -- /dev/sdb mkpart primary 5GiB 100%
parted -s -a optimal -- /dev/sdb set 4 raid on

:::info Pourquoi ce partitionnement ? Aussi, pourquoi le faire avec parted et pas fdisk ? Pour pouvoir renseigner des commandes directes ?

L'outil parted permet de faire des copier/coller facilement, et d'avoir le même partitionnement sur chaque disque et chaque serveur.

Le partitionnement GPT permet d'être compatible sur tous les formats.

La petite partition de 2Mo est l'étape 0 du GRUB (avec gestion du raid et du chiffrement), qui indique où va se trouver la partition contenant le GRUB. C'est parce qu'on utilise le partitionement de type GPT qu'on a besoin de cette partition. :::

Au final, on se retrouve avec une partition de 2Mo pour le GRUB, puis une partition de 1Go pour le boot, une partition de 4Go pour la swap, et la dernière partition pour le système.

Cela donne ça :

root@debian:~# lsblk 
NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
loop0    7:0    0 981.5M  1 loop /usr/lib/live/mount/rootfs/filesystem.squashfs
                                 /run/live/rootfs/filesystem.squashfs
sda      8:0    0 232.9G  0 disk 
├─sda1   8:1    0     2M  0 part 
├─sda2   8:2    0  1021M  0 part 
├─sda3   8:3    0     4G  0 part 
└─sda4   8:4    0 227.9G  0 part 
sdb      8:16   0 232.9G  0 disk 
├─sdb1   8:17   0     2M  0 part 
├─sdb2   8:18   0  1021M  0 part 
├─sdb3   8:19   0     4G  0 part 
└─sdb4   8:20   0 227.9G  0 part 
sdc      8:32   0 136.7G  0 disk 
sdd      8:48   1     0B  0 disk 
md126    9:126  0     0B  0 md   
sr0     11:0    1   1.4G  0 rom  /usr/lib/live/mount/medium
                                 /run/live/medium

:::info On ne devrait pas utliser la swap pour ces serveurs. En plus, si on l'utilise, c'est du cache, donc pas d'infos importantes. Après, ce n'est important, c'est des sujets qui font débat, des manières de voire différemment la criticité de la swap. :::

On utilise mdadm pour créer notre RAID:

mdadm --create --verbose /dev/md0 --level=1 --raid-devices=2 /dev/sda2 /dev/sdb2
mdadm --create --verbose /dev/md1 --level=1 --raid-devices=2 /dev/sda3 /dev/sdb3
mdadm --create --verbose /dev/md2 --level=1 --raid-devices=2 /dev/sda4 /dev/sdb4

On doit avoir ce résultat:

# mdadm --create --verbose /dev/md0 --level=1 --raid-devices=2 /dev/sda2 /dev/sdb2
mdadm: Note: this array has metadata at the start and
    may not be suitable as a boot device.  If you plan to
    store '/boot' on this device please ensure that
    your boot-loader understands md/v1.x metadata, or use
    --metadata=0.90
mdadm: size set to 1044480K
Continue creating array? 
Continue creating array? (y/n) y
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md0 started.

Pas de panique ! Le warning est tout à fait normal

On ne crée pas de RAID sur la première partition, car elle va contenir le GRUB (qui ne comprend pas le RAID).

Avant de créer le système de fichier, on doit maintenant chiffrer les partitions.

On génère un fichier random qui va servir de clé de chiffrement pour la partie boot et root :

dd bs=512 count=4 if=/dev/random of=/tmp/encrypted-boot.key iflag=fullblock
dd bs=512 count=4 if=/dev/random of=/tmp/encrypted-root.key iflag=fullblock

On crée les volumes chiffrés. Grub pour l'instant ne sait pas traiter du luks 2, on doit donc prendre luks 1. Puis on monte ces volumes.

cryptsetup --type luks2 --cipher aes-xts-plain64 --hash sha512 --iter-time 5000 --key-size 512 --pbkdf argon2id --use-urandom --key-file /tmp/encrypted-root.key luksFormat /dev/md2

cryptsetup --type luks1 --cipher aes-xts-plain64 --hash sha512 --iter-time 5000 --key-size 512 --use-urandom --key-file /tmp/encrypted-boot.key luksFormat /dev/md0

cryptsetup open /dev/md2 encrypted-root --perf-no_write_workqueue --perf-no_read_workqueue --allow-discards --persistent --key-file /tmp/encrypted-root.key

cryptsetup open /dev/md0 encrypted-boot --perf-no_write_workqueue --perf-no_read_workqueue --allow-discards --persistent --key-file /tmp/encrypted-boot.key

Pour le cryptsetup open, on ajoute des options qui sont des optimisations pour les SSD.

On formate, en XFS pour le root filesystem, et EXT2 pour le boot :

mkfs.xfs /dev/mapper/encrypted-root
mkfs.ext2 /dev/mapper/encrypted-boot

On monte les deux système de fichier:

mount /dev/mapper/encrypted-root /mnt
mkdir /mnt/boot
mount /dev/mapper/encrypted-boot /mnt/boot

On peut vérifier avec lsblk que ça a pris forme. On a 4 points de montage :

user@debian:~$ lsblk 
NAME                 MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINTS
loop0                  7:0    0 981.5M  1 loop  /usr/lib/live/mount/rootfs/filesystem.squashfs
                                                /run/live/rootfs/filesystem.squashfs
sda                    8:0    0 232.9G  0 disk  
├─sda1                 8:1    0     2M  0 part  
├─sda2                 8:2    0  1021M  0 part  
│ └─md0                9:0    0  1020M  0 raid1 
│   └─encrypted-boot 253:1    0  1018M  0 crypt /mnt/boot
├─sda3                 8:3    0     4G  0 part  
│ └─md1                9:1    0     4G  0 raid1 
└─sda4                 8:4    0 227.9G  0 part  
  └─md2                9:2    0 227.8G  0 raid1 
    └─encrypted-root 253:0    0 227.7G  0 crypt /mnt
sdb                    8:16   0 232.9G  0 disk  
├─sdb1                 8:17   0     2M  0 part  
├─sdb2                 8:18   0  1021M  0 part  
│ └─md0                9:0    0  1020M  0 raid1 
│   └─encrypted-boot 253:1    0  1018M  0 crypt /mnt/boot
├─sdb3                 8:19   0     4G  0 part  
│ └─md1                9:1    0     4G  0 raid1 
└─sdb4                 8:20   0 227.9G  0 part  
  └─md2                9:2    0 227.8G  0 raid1 
    └─encrypted-root 253:0    0 227.7G  0 crypt /mnt
sdc                    8:32   1     0B  0 disk  
sr0                   11:0    1   1.4G  0 rom   /usr/lib/live/mount/medium
                                                /run/live/medium

On crée la swap:

mkswap /dev/md1

Puis installation de bookworm avec debootstrap

debootstrap bookworm /mnt 

On génère le fstab pour la debian:

genfstab -U /mnt > /mnt/etc/fstab 

On vérifie le fstab:

cat /mnt/etc/fstab

On voit qu'il a fait des trucs \o/

On chroot dans la machine debian :

arch-chroot /mnt

On utilise arch-chroot qui est un alias (un peux plus malin) de :

mount --bind /dev /mnt/dev
mount --bind /dev/pts /mnt/dev/pts
mount -t proc /proc /mnt/proc
mount -t sysfs /sys /mnt/sys
mount --bind /run /mnt/run
chroot /mnt

On remplace le contenu de /etc/apt/sources.list, parce que par défaut c'est hyper léger. On réutilise juste les dépôts qu'on a mis sur nos autres VMs :

deb http://deb.debian.org/debian/ bookworm contrib main non-free non-free-firmware
deb http://deb.debian.org/debian/ bookworm-updates contrib main non-free non-free-firmware
deb http://deb.debian.org/debian/ bookworm-backports contrib main non-free non-free-firmware
deb http://security.debian.org/debian-security/ bookworm-security contrib main non-free non-free-firmware

On installe quelques outils pour le réseau et le chiffrement :

apt update
apt install -y bash-completion kitty-terminfo locales ifupdown2 bridge-utils vlan grub2 linux-image-amd64 xfsprogs openssh-server cryptsetup cryptsetup-initramfs opensmtpd zstd wget ca-certificates uuid-runtime vim console-setup mdadm

On choisi le clavier belge et ensuite on accepte les valeurs par défaut lors des différents prompt.

On installe aussi mdadm pour qu'il puisse gérer le raid software:

apt install mdadm

On doit ensuite sauver la configuration du RAID pour qu'il démarre au.. démarrage:

mdadm --detail --scan

On vérifie que le résultat de cette commande se trouve bien dans le fichier /etc/mdadm/mdadm.conf. Quelque chose comme ceci:

# definitions of existing MD arrays

ARRAY /dev/md0 metadata=1.2 name=debian:0 UUID=7feb1f92:58693726:99168fd8:6118fd73
ARRAY /dev/md1 metadata=1.2 name=debian:1 UUID=5aafae11:ad168267:16b4826f:5b2ae7f5
ARRAY /dev/md2 metadata=1.2 name=debian:2 UUID=c96e8faf:20951c17:5289a7f9:6e226d83

On définit un mot de passe pour root:

passwd root

On autorise les connexions SSH avec mot de passe pour root, en remplaçant cette ligne dans /etc/ssh/sshd_config:

# PermitRootLogin without-password

par

PermitRootLogin yes

On va rechercher les informations liées aux partitions. La commande suivante find -L /dev/disk -samefile /dev/md2 permet de voir tous les volumes qui correspondent à /dev/md2. On fait la même chose pour /dev/md1 et /dev/md0:

$ find -L /dev/disk -samefile /dev/md2
/dev/disk/by-uuid/5ae98cfb-f1a1-4f58-abae-3a62a38c97e0
/dev/disk/by-id/md-uuid-65ce0231:81f110e0:af83f6c3:a9ec0f2b
/dev/disk/by-id/md-name-debian:2

Dans notre cas, on prend la seconde ligne (md-uuid).

À partir de ces infos, on configure CryptSetup.

Attention que la Swap est un peu un cas particulier : à chaque redémarrage il va créer un volume avec un nouveau UUID. Cela permet qu'entre deux redémarrage on ne puisse pas lire ce qu'il y avait dans la Swap.

Pour rappel, /dev/md0 c'est le boot, /dev/md1 c'est la swap, et /dev/md2 c'est la partition système.

Dans /etc/crypttab, on insère :

# <target name> <source device>         <key file>      <options>
encrypted-swap   /dev/disk/by-id/md-uuid-d27432a2:b589dadd:fb58eca5:df12dc58        /dev/urandom   swap,cipher=aes-xts-plain64:sha512,size=512

encrypted-root   /dev/disk/by-id/md-uuid-65ce0231:81f110e0:af83f6c3:a9ec0f2b        /etc/keys/encrypted-root.key
encrypted-boot   /dev/disk/by-id/md-uuid-8d303b22:22705f09:4ecdb7db:ff9b71d0        /etc/keys/encrypted-boot.key

On peut vérifier que cela correspond bien au résultat de la commande lsblk -f.

On s'occupe de générer les locales, on décommente en_US.UTF-8 dans /etc/locale.gen et on lance locale-gen.

On peut maintenant configurer grub dans /etc/default/grub. On configure grub en mode série et on active l'option cryptsetup, sinon grub n'ira pas chercher ces disques-là.

On rajoute ces lignes:

GRUB_TERMINAL_INPUT="console serial"
GRUB_TERMINAL_OUTPUT="gfxterm serial"
GRUB_SERIAL_COMMAND="serial --unit=0 --speed=115200"

GRUB_ENABLE_CRYPTODISK=y

Et on modifie la ligne GRUB_CMDLINE_LINUX_DEFAULT:

GRUB_CMDLINE_LINUX_DEFAULT="quiet console=tty0 console=ttyS0,115200"

Contrairement à ce qu'on avait fait ici, on mett tty0 pour que la console serial fonctionne. En effet, sur les HP c'est 0 et non 1.

Ce qui donne comme fichier de configuration final:

# If you change this file, run 'update-grub' afterwards to update
# /boot/grub/grub.cfg.
# For full documentation of the options in this file, see:
#   info -f grub -n 'Simple configuration'

GRUB_DEFAULT=0
GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
GRUB_CMDLINE_LINUX_DEFAULT="quiet console=tty0 console=ttyS0,115200"
GRUB_CMDLINE_LINUX=""

# Uncomment to enable BadRAM filtering, modify to suit your needs
# This works with Linux (no patch required) and with any kernel that obtains
# the memory map information from GRUB (GNU Mach, kernel of FreeBSD ...)
#GRUB_BADRAM="0x01234567,0xfefefefe,0x89abcdef,0xefefefef"

# Uncomment to disable graphical terminal (grub-pc only)
#GRUB_TERMINAL=console

# The resolution used on graphical terminal
# note that you can use only modes which your graphic card supports via VBE
# you can see them in real GRUB with the command `vbeinfo'
#GRUB_GFXMODE=640x480

# Uncomment if you don't want GRUB to pass "root=UUID=xxx" parameter to Linux
#GRUB_DISABLE_LINUX_UUID=true

# Uncomment to disable generation of recovery mode menu entries
#GRUB_DISABLE_RECOVERY="true"

# Uncomment to get a beep at grub start
#GRUB_INIT_TUNE="480 440 1"

GRUB_TERMINAL_INPUT="console serial"
GRUB_TERMINAL_OUTPUT="gfxterm serial"
GRUB_SERIAL_COMMAND="serial --unit=0 --speed=115200"

GRUB_ENABLE_CRYPTODISK=y

On crée le dossier /etc/keys qui va contenir toutes les clés de déchiffrement des disques:

mkdir /etc/keys

On les a générées tout à l'heure dans le /tmp du live cd et on va maintenant les copiers sur le disque chiffré. On sort du chroot, puis on fait:

cp /tmp/encrypted-* /mnt/etc/keys/.

On re chroot dans /mnt

Attention que le dossier /etc/keys ne doit être accessible que par root ! Donc :

chmod 0700 /etc/keys
chmod 0600 /etc/keys/encrypted-*.key

On met le même mot de passe sur boot et root (question de pratique car si les clés de déchiffrement sans uniquement dans l'initramfs, c'est pénible en cas de recovery)

Pour définir un mot de passe lisible par des humains, on utilise un petit outil qu'on installe sur notre PC :

git clone https://github.com/mbelivo/diceware-wordlists-fr
cd ./diceware-wordlists-fr
src/rolldice -e 100 wordlist_fr_5d.txt

On peut donner en paramètre l'entropie désirée et le nombre de lettre par mots générés (ici 5)

Ca génère une liste de mots, qui devient la passephrase avec les espaces. On peut en générer plusieurs jusqu'à en trouver une amusante.

Pourquoi on fait tout ça ? Parce qu'on ne peut pas faire de copier coller sur l'interface serie, sinon il manque des lettres. Donc il faut quand même un truc qui soit lisible par un humain.

On ajoute le mot de passe dans notre gestionnaire de mot de passe:

gopass insert neutrinet/servers/blue/topi/encrypted-dell

On fait pareil pour nam et bour.

Dans cryptsetup, on peut définir plusieurs slots pour déchiffrer un volume. Par exemple, on a défini deux slots :

• le fichier bin qu'on avait généré
• notre passphrase

Si cryptsetup ne trouve pas le premier, il va demander le second.

Le jour où on souhaite changer la passphrase, il faudra juste présenter à cryptsetup le fichier binaire. Et il ne faudra pas rechiffrer les disques cryptsetup luksAddKey --key-file=/etc/keys/encrypted-boot.key /dev/md0 Ca demande la passerphrase (mieux vaut la copier une fois dans son shell pour être sûr du copier / coller).

idem pour root

cryptsetup luksAddKey --key-file=/etc/keys/encrypted-root.key /dev/md2

Puis ajout de la swap à la main, dans /etc/fstab:

/dev/mapper/encrypted-swap  none        swap    sw            0       0

On désactive l'hibernation (car à chaque redémarrage, on a une nouvelle swap avec un nouveau chiffrement)

echo "RESUME=none" >/etc/initramfs-tools/conf.d/resume

Et ensuite d'autres options pour initramfs à ajouter dans le fichier de conf:

nano /etc/initramfs-tools/initramfs.conf
KEYMAP=y
COMPRESS=zstd
UMASK=0077

On rajoute une option pour ajouter les clés de chiffrement dans l'initramfs. Si le dossier cryptsetup-initrampfs n'existe pas, alors il faut installer cryptsetup-initramfs:

nano /etc/cryptsetup-initramfs/conf-hook
KEYFILE_PATTERN="/etc/keys/*.key"

Puis on met à jour l'initramfs :

update-initramfs -u

On installe Grub sur chaque disque:

grub-install /dev/sda
grub-install /dev/sdb
update-grub

On retire “os-prober” qui ne nous sert à rien :

apt remove os-prober

On modifie le hostname ! On change le fichier /etc/hostname et on lance la commande:

hostname topi.louise.neutri.net

On met ce contenu dans /etc/network/interfaces:

auto lo
iface lo inet loopback

auto  eno4
iface eno4 inet dhcp

En remplaçant l'interface eno4 par celle qui reçoit de l'internet.

Lors du démarrage, on appuie sur F2 pour entrer dans le BIOS.

On active le port série pour pouvoir taper le mot de passe:

• serial communication : redirection via com2
• serial port address : <Serial Device1=COM1,Serial Device2=COM2>
• Redirection after boot : enabled

On active le redirect after boot. C'est assez bizarre parce que sur les PowerEdge R420 il n'y a pas besoin de l'activer, mais sur les R620 on doit l'activer pour avoir la console série.

Au démarrage, GRUB nous enjoint à entrer notre mot de passe.

Soit on lance la console dans le navigateur (dans ce cas, attention: le clavier est en QWERTY!).

Soit on se connecte à l'iDrac en SSH, puis on fait:

console com2

Si jamais on se trompe dans le mot de passe (ça arrive), il faut faire:

cryptomount -a

Puis retaper le mot de passe leeeeentement en faisant le vide dans sa tête.

Ensuite, on fait:

insmod normal
normal

Si ça ne boot pas, vérifier que cryptsetup-initramfs et mdadm sont installés.

Si on veut déchiffrer les disques depuis un live cd, on installe un serveur SSH et donne un mot de passe à l'utilisateur user (voir plus haut).

Ensuite, on installe les outils pour cryptsetup et debootstrap:

apt install -y cryptsetup debootstrap arch-install-scripts xfsprogs

Puis, on déchiffre les disques:

cryptsetup open /dev/md125 encrypted-root --perf-no_write_workqueue --perf-no_read_workqueue --allow-discards --persistent
cryptsetup open /dev/md126 encrypted-boot --perf-no_write_workqueue --perf-no_read_workqueue --allow-discards --persistent

On monte les disques:

mount /dev/mapper/encrypted-root /mnt
mount /dev/mapper/encrypted-boot /mnt/boot

Et on fait arch-chroot.

Au reboot, a des erreurs de secteurs non lus au démarrage.

C'est parce que l'iso est encore lié au serveur et considéré comme un CD virtuel même si on ne boot plus dessus.

Donc, c'est normal !

Quelques ressources: - https://pve.proxmox.com/wiki/Install_Proxmox_VE_on_Debian_12_Bookworm - https://wiki.lab.ytopia.xyz/lab:lab-proxmox

On commence par mettre l'IP locale et le nom de domaine dans /etc/hosts:

127.0.0.1       localhost
172.16.0.128    topi.louise.neutri.net topi
::1             localhost ip6-localhost ip6-loopback
ff02::1         ip6-allnodes
ff02::2         ip6-allrouters

On peut vérifier avec la commande hostname --ip-address.

On télécharge la clé GPG de Proxmox:

wget https://enterprise.proxmox.com/debian/proxmox-release-bookworm.gpg -O /etc/apt/keyrings/proxmox-release-bookworm.gpg

On a adapte un peu ce qui est dans la doc de Proxmox pour tenir une convention qu'on s'est donnée, qui est celle recommandée d'apt mais que tout le monde ne respecte pas, pour stocker le fichier gpg.

Puis on ajoute le dépôt de Proxmox:

echo "deb [arch=amd64 signed-by=/etc/apt/keyrings/proxmox-release-bookworm.gpg] http://download.proxmox.com/debian/pve bookworm pve-no-subscription" > /etc/apt/sources.list.d/pve-install-repo.list

On fait une mise à jour avec ce nouveau dépôt:

apt update && apt full-upgrade

Et on installe le kernel fournit par Proxmox:

apt install proxmox-default-kernel

On reboot pour appliquer le nouveau kernel.

Après une pause café, on peut enfin installer Proxmox:

apt install proxmox-ve opensmtpd open-iscsi chrony

On retire le dépôt entreprise de Proxmox:

rm /etc/apt/sources.list.d/pve-enterprise.list

Et on supprime l'ancien kernel de Debian:

apt remove linux-image-amd64 'linux-image-6.1*'

Enfin, on met à jour le GRUB: update-grub

On peut maintenant se rendre sur l'interface web: https://172.16.0.128:8006/

Si elle n'apparaît pas, vérifier que le service pveproxy est bien démarré. S'il y a un problème avec des certificats SSL, c'est dû à une mauvaise config du fichier /etc/hosts. Il suffit de redémarrer le service.

Tharyrok a préparé le réseau avec le nouveau switch. Chaque serveur peut parler avec les autres en IPv6. Le fichier /etc/hosts est également configuré pour qu'on puisse utiliser topi, nam et bour comme raccourcis.

On commence par installer Ceph:

pveceph install --repository no-subscription

L'installateur nous demande de confirmer notre choix, cela doit ressembler à ceci:

HINT: The no-subscription repository is not the best choice for production setups.
Proxmox recommends using the enterprise repository with a valid subscription.
This will install Ceph Quincy - continue (y/N)? y
update available package list
start installation
... [APT stuff]
installed ceph quincy successfully!

reloading API to load new Ceph RADOS library...

On génère des nouvelles clés de chiffrement pour Ceph:

dd bs=512 count=4 if=/dev/random of=/etc/keys/encrypted-osd-0.key iflag=fullblock

On met les bonnes permissions sur la clé qu'on vient de générer:

chmod 0600 /etc/keys/encrypted-osd-0.key

Et on configure pour cryptsetup le disque de 2Tb (/dev/sdc) de la même manière qu'on avait fait pour les disques SSD et on monte le volume:

cryptsetup --type luks2 --cipher aes-xts-plain64 --hash sha512 --iter-time 5000 --key-size 512 --pbkdf argon2id --use-urandom --key-file /etc/keys/encrypted-osd-0.key luksFormat /dev/sdc

cryptsetup open /dev/sdc encrypted-osd-0 --perf-no_write_workqueue --perf-no_read_workqueue --allow-discards --persistent --key-file /etc/keys/encrypted-osd-0.key

cryptsetup luksAddKey --key-file=/etc/keys/encrypted-osd-0.key /dev/sdc

On ajoute le disque dans crypttab, toujours de la même façon que pour les SSD. Par contre, on n'a pas de partition sur ce disque-là, on va utiliser l'UUID scsi pour l'identifier:

# find -L /dev/disk -samefile /dev/sdc
/dev/disk/by-uuid/e3ab736a-5d09-4503-80f9-f79e54a73ed4
/dev/disk/by-path/pci-0000:03:00.0-sas-phy6-lun-0
/dev/disk/by-id/scsi-35000c5004cf940d7
/dev/disk/by-id/wwn-0x5000c5004cf940d7
/dev/disk/by-diskseq/11

:::info Pourquoi utilise-t-on l'UUID SCSI plutôt que by-uuid comme précédemment ?

Parce que c'est le numéro de série du disque physique. Comme on n'a pas créé de partition, on utilise ce qui est le plus proche possible du matériel. :::

Notre fichier /etc/crypttab ressemble donc à ceci:

# cat /etc/crypttab 
# <target name> <source device>         <key file>      <options>
encrypted-swap   /dev/disk/by-id/md-uuid-d27432a2:b589dadd:fb58eca5:df12dc58        /dev/urandom   swap,cipher=aes-xts-plain64:sha512,size=512

encrypted-root   /dev/disk/by-id/md-uuid-65ce0231:81f110e0:af83f6c3:a9ec0f2b        /etc/keys/encrypted-root.key
encrypted-boot   /dev/disk/by-id/md-uuid-8d303b22:22705f09:4ecdb7db:ff9b71d0        /etc/keys/encrypted-boot.key
encrypted-osd-0  /dev/disk/by-id/scsi-35000c5004cf940d7                             /etc/keys/encrypted-osd-0.key

Ceph a besoin que ses disques soient configurés en LVM. Donc on configure le physical volume LVM :

pvcreate /dev/mapper/encrypted-osd-0

On génère un UUID:

# uuidgen
5a964d51-ace1-403e-a196-ba1da3d09d1e

Puis on crée le volume group:

vgcreate ceph-5a964d51-ace1-403e-a196-ba1da3d09d1e /dev/mapper/encrypted-osd-0

On génère un autre UUID:

# uuidgen
dea0261c-9dc5-4667-a248-3b9482f4c00a

Et enfin on crée le logical volume, on utilise le second UUID dans le nom:

lvcreate -l100%FREE ceph-5a964d51-ace1-403e-a196-ba1da3d09d1e -n osd-block-dea0261c-9dc5-4667-a248-3b9482f4c00a

On met à jour l'initramfs, puisqu'on a rajouté une clé de chiffrement, avec l'option -k all pour cibler tous les kernels:

update-initramfs -u -k all

On a cette petite erreur :

Running hook script 'zz-proxmox-boot'..
Re-executing '/etc/kernel/postinst.d/zz-proxmox-boot' in new private mount namespace..
No /etc/kernel/proxmox-boot-uuids found, skipping ESP sync.

A priori, cela ne pose pas de problème pour la suite.

On met à jour le GRUB par acquis de conscience:

update-grub

Et on reboot \o/

On commence par créer le cluster depuis topi:

pvecm create patata

Puis, à partir des autres serveurs, on demande à rejoindre le cluster patata:

pvecm add topi

On peut vérifier l'état du cluster:

# pvecm status
...
Votequorum information
----------------------
Expected votes:   3
Highest expected: 3
Total votes:      3
Quorum:           2  
Flags:            Quorate 
...

:::warning En cas de réinstallation, il faudrait effacer les anciennes clés ssh si on reconnecte l'un des serveurs au cluster, comme ici : https://wiki.neutrinet.be/fr/rapports/2022/06-11#retour_de_nam_dans_le_cluster :::

On ajoute le paquet systemd-timesyncd pour être sûr que l'heure soit la même dans tout le cluster, sinon Ceph va râler pendant la synchronisation… :

apt install systemd-timesyncd

Comme on installe un nouveau cluster, il faut initialiser CEPH sur un des serveurs:

pveceph init --network 2001:913:1000:30::/64

Cela crée un config dans /etc/pve/ceph.conf, et elle doit se retrouver sur les autres serveurs.

On vérifie que ce fichier est bien un lien symbolique vers /etc/pve/ceph.conf (si ce n'est pas le cas, on crée ce lien symbolique):

# ls -lh /etc/ceph/ceph.conf
lrwxrwxrwx 1 root root 18 Mar 16 19:02 /etc/ceph/ceph.conf -> /etc/pve/ceph.conf

On crée les Monitors et Managers de Ceph sur chaque serveur du cluster:

pveceph mon create
pveceph mgr create

À cette étape, on doit avoir quelque chose comme ceci:

# ceph -s
  cluster:
    id:     4edfe49e-538c-4de2-9d34-5498dc2cc2f4
    health: HEALTH_WARN
            OSD count 0 < osd_pool_default_size 3
 
  services:
    mon: 3 daemons, quorum topi,nam,bour (age 119s)
    mgr: topi(active, since 4m), standbys: nam, bour
    osd: 0 osds: 0 up, 0 in
 
  data:
    pools:   0 pools, 0 pgs
    objects: 0 objects, 0 B
    usage:   0 B used, 0 B / 0 B avail
    pgs:

On peut voir que Ceph est pas content car il n'y a pas les OSD, ce qui est normal puisqu'on les a pas encore créés

Comme on utilise LVM, on doit créer l'OSD manuellement. On commence par faire un bootstrap des clés:

/usr/bin/ceph auth get client.bootstrap-osd > /var/lib/ceph/bootstrap-osd/ceph.keyring

:::info À quoi servent ces clés ? Quand on démarre un cluster ceph, plusieurs clés sont créées par défaut. En particulier, il y a les clés de bootstrap pour les MGR, MON, etc. On voit le bootstrap dans leurs capabilities. Le bootstrap permet d'initier des daemons de ceph pour rejoindre le cluster de ceph. Depuis une certaine version, tous ces deamons doivent s'authentifier les uns auprès des autres. C'est pourquoi dans la ligne ci-dessus, on va chercher la clé pour que proxmox puisse s'authentifier auprès du cluster ceph quand on monte les volumes. (Un exemple : dans la doc d'ovh pour ceph, ils expliquent cela et indiquent à leurs clients comment ajouter leur clé pour s'authentifier à leur cluster.) :::

Ensuite, on crée l'OSD avec cette commande magique:

ceph-volume lvm create --osd-id 0 --data /dev/ceph-5a964d51-ace1-403e-a196-ba1da3d09d1e/osd-block-dea0261c-9dc5-4667-a248-3b9482f4c00a

Chaque serveur aura un ID différent. Ici, topi a l'ID 0, nam l'ID 1, et bour l'ID 2.

Pour chaque serveur, il est aussi nécessaire d'utiliser la commande qui précède pour le bootstrap des clés. On crée chaque OSD sur son propre serveur.

Cela crache des stderr, mais a priori c'est normal. Ce qui est important, c'est de vérifier que les OSD sont bien up à la fin (attendre un peu si jamais ce n'est pas encore up):

ceph -s

Si jamais on a eu des soucis avec la création d'un OSD, on peut le supprimer avec toutes ces commandes:

ceph osd stop osd.0
ceph osd destroy osd.0
ceph osd purge osd.0
ceph-volume lvm zap /dev/ceph-5a964d51-ace1-403e-a196-ba1da3d09d1e/osd-block-dea0261c-9dc5-4667-a248-3b9482f4c00a

La dernière commande efface les métadonnées qui se trouvaient sur la partition LVM, voir aussi la doc: https://docs.ceph.com/en/latest/rados/operations/add-or-rm-osds/

Pour terminer, on crée la pool sur un des serveurs:

pveceph pool create data --add_storages

Par contre, on voit que la nouvelle pool est en warning:

HEALTH_WARN: 1 pools have too many placement groups
Pool data has 128 placement groups, should have 32

Si l'on reprend ce qu'on avait noté pendant l'atelier Proxmox :
Les placement de groupes sont des sous-blocs qui permettrent de régir le fait qu'on duplique une donnée ou non, qu'on change une donnée ou pas. C'est une algorithme qui gère dans quel node vont se retrouver les données. Il y a une formule pour calculer ce chiffre, mais ici OSEF (Ô CEPH, aide-nous).
Source : https://wiki.neutrinet.be/fr/rapports/2022/05-07

Il faut utiliser cette commande pour activer le pilote automatique:

ceph osd pool set data pg_autoscale_mode on

On voit dans l'interface web de Proxmox qu'il réduit peu à peu ses placements de groupe, ouf!

Enfin, on a remarqué qu'il y avait une pool mgr déjà crééé. Il est utilisé par les daemons mgr pour sauvegarder leurs paramètres. Si on l'a supprimé, il est recréé quand on démarre les mgr.

On peut vérifier que tout est correct avec:

pveceph pool ls

On a remarqué que Proxmox affichait cette erreur:

proxmox HEALTH_ERR: Module 'devicehealth' has failed: disk I/O error
Module 'devicehealth' has failed: disk I/O error

La solution :

ceph device monitoring off

En fait, CEPH s'attend à être passthrough sur les disques durs, sauf qu'il passe par du lvm, donc il ne récupère pas l'état de santé du disque.

Constamment, le kernel va contacter le watchdog pour lui dire qu'il est en vie. Si au bout de 10s il ne l'a pas contacter, le watchdog va faire une action prévue. Ici, ce sera redémarrer le système si il n'a toujours pas de nouvelle après 30 secondes supplémentaires..

Pour voir les informations liées au watchdog :

ipmitool mc watchdog get

Et pour l'activer : Dans /etc/default/pve-ha-manager on décommante la ligne :

WATCHDOG_MODULE=ipmi_watchdog

Dans /etc/default/grub, ajouter nmi_watchdog=0 dans la default grub line dans GRUBCMDLINELINUX_DEFAULT

Si au bout de 10s le watchdog n'a pas reçu de nouvelles du kernel, on va lui dire d'attendre encore 30s avant de faire un redémarrage:

echo 'options ipmi_watchdog action=power_cycle panic_wdt_timeout=30' > /etc/modprobe.d/ipmi_watchdog.conf

Le watchdog est pratique pour ne pas avoir un serveur dans un etat zombie.

On utilise la config réseau suivante:

auto lo
iface lo inet loopback

auto eno4
iface eno4 inet dhcp

auto enp5s0f1
iface enp5s0f1 inet manual
        mtu 9000
# LINK TO BACKBONE-01

auto bond0
iface bond0 inet manual
        mtu 9000
        bond-slaves enp5s0f1
        bond-miimon 100
        bond-mode 802.3ad
        bond-xmit-hash-policy layer3+4
# LACP TO BACKBONE

auto bond0.30
iface bond0.30 inet manual
        mtu 9000
# VLAN INTERNAL

auto vmbr0
iface vmbr0 inet manual
        mtu 8500
        bridge-ports bond0.30
        bridge-stp off
        bridge-fd 0
# INTERNAL VIRTUAL SWITCH

auto vmbr1
iface vmbr1 inet manual
        mtu 9000
        bridge-ports bond0
        bridge-stp off
        bridge-fd 0
# EXTERNAL VIRTUAL SWITCH

auto vmbr1.10
iface vmbr1.10
        mtu 9000
        address 10.0.10.14/24
        #gateway 10.0.10.1
        address 2001:0913:1000:10::14/64
        #gateway 2001:0913:1000:10::1
# VLAN MANAGEMENT

auto vmbr0.30
iface vmbr0.30
        mtu 8500
        address 2001:913:1000:30::4/64
# VLAN CLUSTER

Dans cette config, l'interface bond0 (bonding), permet de redonder un lien l2. On a plusieurs technologies, la plus simple est d'avoir deux interfaces connectées à un switch, mais seule la première est vraiment connectée. La seconde est en attente et s'active si la première tombe.

Mais dans notre cas on utilise le protocole 802.3ad autrement appeler LACP (actif / actif). Cela permet d'une certaine manière de doubler la bande passante, en ayant deux sessions TCP en même temps utilisant chacune toute la capacité d'un lien physique.

Pour le moment, on n'a pas encore le second lien, donc on ne voit qu'une seule interface (enp5s0f1) définie dans les bond slaves.

vmbr0 : l'interface par défaut quand on crée une VM, c'est le réseau interne.

vmbr1 : toute la communication interne publique, dont les liens de transit et de peering.

vmbr1.10 : le réseau de management

vmbr0.30 : on ne l'utilise pas encore mais c'est celui qui sert à l'interaction des proxmox dans le cluster patata (31 pour Chez Mémé).

Quand on a une interface . un chiffre, c'est un vlan de l'interface. Exemple vmbr0.10, c'est le vlan 10 de l'interface vmbr0.

On ne déclare pas le VLAN 11 (patata) car Proxmox n'en a pas besoin. On ne déclare que les VLANs utilisés par Proxmox.

Une bizarrerie si on va voir les interfaces qui y sont liées : bond0.30 sur le bridge vmbr0 et ensuite vmbr0.30. En fait, on a un vlan dans un vlan. Le switch connaît le vlan 30, et dedans on a le bridge et son vlan 30.

On fait du Vlan Q-IN-Q pour la communication entre les VM du cluster patata, cela sera le même pour chez-meme.

Lien physique - vlan10 (Management) - vlan30 (Cluster Patata)

1. Vlan11 (VM Patata)
2. Vlan30 (Proxmox & Ceph)
3. VlanXXX

Donc le switch voit le vlan 30, sans se préoccuper du second vlan. Quand le vmbr0 reçoit le paquet (le bridge pour les VM), celui-ci a été décapsulé, et le switch ne voit que le second vlan, par ex le vlan 11.

L'interface pour la communication ceph & proxmox pourrait être écrit autrement, comme ceci : bond0.30.30

Avec cette config, on peut pinguer le nouveau switch sur l'IP 10.0.10.93 \o/

TODO: Tharyrok s'assure que la branche bookworm est à jour

On lancera le playbook le 18 mars.

On a réactivé le lifecycle de Dell. Cela n'a pas vraiment de sens de l'avoir actif car les serveurs ne sont plus maintenus par Dell. Mais par contre, cela permet d'avoir les infos à jour du matériel visibles dans l'iDrac. Par exemple, le nombre de barettes de RAM, etc.

On se connecte avec un câble série DB9. Attention, si jamais on veut acheter un câble femelle-femelle, il faut faire attention à ce que ce soit un câble croisé, car chaque bout aura sa pin pour la réception associée à la pin de transmission de l'autre bout. Bref, demander conseil à Tharyrok en cas de doute.

On démarre avec CTRL+P pour changer le mot de passe temporairement. On exécute setenv RESETPASSWORD 1, puis reload. Le login est alors grpadmin, et le mot de passe pareil.

Une fois dans le machin propriétaire, on peut utiliser la commande help pour savoir ce qu'on peut faire.

Pour rappel, il y a deux boards dans le SAN, on va devoir reset les deux. Pour faire un reset complet, on utilise la commande … reset tout simplement.

S'il nous lâche qu'il peut faire son reset que sur l'active CM, cela veut dire qu'on doit brancher notre câble série sur l'autre board, et recommencer avec l'histoire du CTRL+P.

On décide de boire un shot à chaque fois qu'on doit redémarrer le serveur. Là on est à 2

On confirme la suppression de la config avec DeleteAllMyDataNow, la commande est assez explicite. Cela va redémarrer le serveur, et passer en mode secondary.

On change à nouveau le câble série pour aller sur l'autre serveur. Comme les deux modules doivent être reset, on reset le second.

Maintenant qu'on tout crâmé, on accepte de configurer la baie de stockage.

Ensuite, on dit qu'on veut lancer l'outil de configuration (setup). Il va détecter les disques et le réseau, et faire de la magie.

Quand on reset le san et qu'il redémarre, on est invité à lui choisir un petit nom. On l'a appelé san-01.

Puis on doit entrer l'interface sur laquelle on va configurer le réseau (ce sera eth0) l'adresse IP sur l'interface eth0.

Puis on lui donne une IP, le masque et la gateway.

Pour que cela fonctionne, il faut que le réseau soit correctement configuré. Sinon, il va échouer et recommencer le setup depuis le début, ce qui est un peu relou.

On branche un câble SFP+ dans le port eth0 du serveur.

On va utiliser :

10.0.32.11
255.255.255.0
10.0.32.1

On choisit ensuite le nom du groupe san-backup. On peut avoir plusieurs SAN dans un même groupe, donc on ne numérote pas ce groupe. Le nom sera commun à tous les SAN de ce groupe. Puis on donne une adresse au groupe 10.0.32.10.

Comme le groupe n'existe pas encore, le SAN demande de le créer. On accepte.

Il demande ensuite des mot de passe pour la gestion du groupe et pour le compte administrateur. On met notre mot de passe root super sécurisé habituel. Mais ! Avec une majuscule, car le SAN veut un mot de passe sécurisé.

On doit ensuite définir la stratégie de RAID. Dans la doc, il y a une commande : member <nom du membre> raid-policy <type de raid>. Cela nous donne :

member select san-01 raid-policy raid6

Avec unshow, on peut voir combien d'espace on a dans le raid. Ici, on voit qu'il a gardé un disque en spare, ce qu'on ne veut pas forcément, car cela nous fait 9,4 To au lieu de 12 To.

On lui rajoute un disque (comme ça, à chaud), et on va voir s'il change automatiquement pour passer à 12 To. Il ne le met pas à jour pour le moment. Probablement parce qu'il est encore en train de construire le raid.

On va ensuite faire un :

volume create backup 9000000MB

Il râle, peut-être aussi parce que l'étape précédente n'est pas terminée. Avec un peti volume, ça marche.

volume create backup 1024MB   
Volume creation succeeded.
iSCSI target name is iqn.2001-05.com.equallogic:8-661fc6-7891d93cd-9620000003365ede-backup.

Une fois qu'on a ça, ce volume est reconnu comme un disque réseau.

On peut ajouter des règles à ce volume, comme des contrôles d'accès, mais on ne le fera pas.

On décide de reporter la maintenance du 2 mars au 6 avril (et la maintenance du 6 avril à plus tard).

Le 2 mars, HgO et Célo ont continué l'installation des Proxmox.

Le 8 mars à 14h, HgO et Célo continuent l'installation des Ceph.

Le 10 mars, on fait le point et on avance sur soit le switch soit le SAN.

Le 18 mars à 14h, HgO et Célo continuent l'installation des serveurs.

Le 6 avril, on fait une dernière journée de préparatifs, avant le 7 avril où on place le matériel.

Le 4 mai, Neutriton reseau, mise en pratique de la refonte du reseau.

Liste d'ateliers a faire:

• Serial console
• Crash Ceph
• Flash carte raid
• PFsense
• Flash des antennes WiFi et configuration : https://doc.neutrinet.be/flash-mikrotik-cap-xl#
• Peering : https://doc.neutrinet.be/2023-08-06-peering#
• Ce rendre humain pour acceuiller de nouveaux membres

Les sujets non urgent:

• Authoritative DNS
• Collecte FreeRadius + GPON + VDSL
• Keycloak : procédures pour configurer un realm, ajouter une application, etc.
• playbook Ansible

Prochaine réunion : 08/03 à 14h

Lieu: Caldarium

Garde-Pad:

Moment informel durant lequel on exprime en peu de mots comment, à titre personnel, la réunion a été vécue que ce soit positif ou négatif. Si une ou plusieurs tension est née durant la réunion, il est peut-être nécessaire d'envisager l'une ou l'autre réunion pour y remédier.

Si il y a cette erreur :

Mar 16 19:21:35 nam.blue.neutri.net ceph-mon[59559]: 2024-03-16T19:21:35.196+0000 7fd2aba5a700 -1 mon.nam@0(probing) e0 handle_auth_bad_method hmm, they didn't like 2 result (13) Permission denied
``` 

Il faut s'assusré que tout les /var/lib/ceph/mon/ceph-xxx/keyring soit les même sur chaque serveur

## Remplacer un OSD de Ceph

On vérifie le numéro de l'OSD, la commande `df -h` nous donne l'info, sinon `systemctl status ceph-osd@x`, avec x le numéro de l'OSD.

On commence par sortir l'OSD du cluster:

ceph osd out 0

Puis on l'éteint:

ceph osd down 0 systemctl stop ceph-osd@0.service

On ferme le cryptsetup:

cryptsetup close encrypted-osd-0

Si jamais on a des soucis, on peut lister les devices chiffrés (avec une tabulation pour voir les volumes chiffrés actifs):

cryptsetup close [tab]

Et par exemple fermer le device correspondant à l'OSD de Ceph:

cryptsetup close ceph–5a964d51–ace1–403e–a196–ba1da3d09d1e-osd–block–dea0261c–9dc5–4667–a248–3b9482f4c00a

On peut ensuite remplacer le disque. Dans notre cas, le nouveau disque se trouve sur `/dev/sdf`.

On chiffre le disque:

cryptsetup –type luks2 –cipher aes-xts-plain64 –hash sha512 –iter-time 5000 –key-size 512 –pbkdf argon2id –use-urandom –key-file /etc/keys/encrypted-osd-0.key luksFormat /dev/sdf

cryptsetup open /dev/sdf encrypted-osd-0 –perf-nowriteworkqueue –perf-noreadworkqueue –allow-discards –persistent –key-file /etc/keys/encrypted-osd-0.key

cryptsetup luksAddKey –key-file=/etc/keys/encrypted-osd-0.key /dev/sdf

On récupère son UUID:

/dev/disk/by-id/ata-SamsungSSD870EVO2TB_S754NS0WA23443T /dev/disk/by-id/wwn-0x5002538f33a3d058 /dev/disk/by-path/pci-0000:03:00.0-sas-phy6-lun-0 /dev/disk/by-diskseq/26

Comme c'est un SATA, on n'a pas d'identifiant SCSI. Ce n'est pas grave, on va prendre le WWN qui est son numéro de série.

On remplace l'identifiant dans `/etc/crypttab`, ce qui nous donne ceci:

encrypted-swap /dev/disk/by-id/md-uuid-d27432a2:b589dadd:fb58eca5:df12dc58 /dev/urandom swap,cipher=aes-xts-plain64:sha512,size=512

encrypted-root /dev/disk/by-id/md-uuid-65ce0231:81f110e0:af83f6c3:a9ec0f2b /etc/keys/encrypted-root.key encrypted-boot /dev/disk/by-id/md-uuid-8d303b22:22705f09:4ecdb7db:ff9b71d0 /etc/keys/encrypted-boot.key encrypted-osd-0 /dev/disk/by-id/wwn-0x5002538f33a3d058 /etc/keys/encrypted-osd-0.key

A virer (?)
>On reformate le nouveau disque pour être sûr qu'il est vierge:
>```
>ceph-volume lvm zap /dev/sdf
>```

On purge complètement l'OSD, car on va l'ajouter par après:

ceph osd purge 0 –yes-i-really-mean-it

On crée le LVM pour Ceph:

pvcreate /dev/mapper/encrypted-osd-0

On génère un UUID:

92b0cedc-a4a7-4947-ac0c-4a9b1d60cefc

Puis on crée le volume group:

vgcreate ceph-92b0cedc-a4a7-4947-ac0c-4a9b1d60cefc /dev/mapper/encrypted-osd-0

On génère un autre UUID:

0765219a-4b5b-41a6-b210-608d12860ddb

Et enfin on crée le logical volume, on utilise le second UUID dans le nom:

lvcreate -l100%FREE ceph-92b0cedc-a4a7-4947-ac0c-4a9b1d60cefc -n osd-block-0765219a-4b5b-41a6-b210-608d12860ddb

On met à jour l’initramfs, puisqu’on a rajouté une clé de chiffrement, avec l’option -k all pour cibler tous les kernels:

update-initramfs -u -k all

Enfin, on crée le volume Ceph:

ceph-volume lvm create –osd-id 0 –data /dev/ceph-92b0cedc-a4a7-4947-ac0c-4a9b1d60cefc/osd-block-0765219a-4b5b-41a6-b210-608d12860ddb

Et on vérifie qu'on a bien tous les OSD qu'on veut:

ceph -s

## Ajout des backups chiffrés en RAID 0

mdadm –create –verbose /dev/md3 –level=0 –raid-devices=2 /dev/sdb /dev/sdc

dd bs=512 count=4 if=/dev/random of=/etc/keys/encrypted-backup.key iflag=fullblock

chmod 0600 /etc/keys/encrypted-backup.key

cryptsetup –type luks2 –cipher aes-xts-plain64 –hash sha512 –iter-time 5000 –key-size 512 –pbkdf argon2id –use-urandom –key-file /etc/keys/encrypted-backup.key luksFormat /dev/md3

cryptsetup open /dev/md3 encrypted-backup –perf-nowriteworkqueue –perf-noreadworkqueue –allow-discards –persistent –key-file /etc/keys/encrypted-backup.key

cryptsetup luksAddKey –key-file=/etc/keys/encrypted-backup.key /dev/md3

mkfs.xfs /dev/mapper/encrypted-backup

ARRAY /dev/md/1 metadata=1.2 name=debian:1 UUID=e5fa6885:9bd3a3b3:b30bd8ff:902e2071 ARRAY /dev/md/0 metadata=1.2 name=debian:0 UUID=a475501f:f6a89d29:557a3064:10bb6910 ARRAY /dev/md/2 metadata=1.2 name=debian:2 UUID=2b88960d:0b917056:a8763436:9a956a67 ARRAY /dev/md3 metadata=1.2 name=bour.louise.neutri.net:3 UUID=2190c340:3aa1ed1c:9b90069a:c699f680

ARRAY /dev/md/0 metadata=1.2 UUID=a475501f:f6a89d29:557a3064:10bb6910 name=debian:0 ARRAY /dev/md/1 metadata=1.2 UUID=e5fa6885:9bd3a3b3:b30bd8ff:902e2071 name=debian:1 ARRAY /dev/md/2 metadata=1.2 UUID=2b88960d:0b917056:a8763436:9a956a67 name=debian:2 ARRAY /dev/md/3 metadata=1.2 name=bour.louise.neutri.net:3 UUID=2190c340:3aa1ed1c:9b90069a:c699f680

/dev/disk/by-id/md-uuid-2190c340:3aa1ed1c:9b90069a:c699f680 /dev/disk/by-id/md-name-bour.louise.neutri.net:3 /dev/disk/by-uuid/929fcee4-d730-4745-833e-83b956e5f057

encrypted-swap /dev/disk/by-id/md-uuid-e5fa6885:9bd3a3b3:b30bd8ff:902e2071 /dev/urandom swap,cipher=aes-xts-plain64:sha512,size=512

encrypted-root /dev/disk/by-id/md-uuid-2b88960d:0b917056:a8763436:9a956a67 /etc/keys/encrypted-root.key encrypted-boot /dev/disk/by-id/md-uuid-a475501f:f6a89d29:557a3064:10bb6910 /etc/keys/encrypted-boot.key encrypted-osd-2 /dev/disk/by-id/wwn-0x5002538f4231063e /etc/keys/encrypted-osd-2.key encrypted-backup /dev/disk/by-id/md-uuid-2190c340:3aa1ed1c:9b90069a:c699f680 /etc/keys/encrypted-backup.key

update-initramfs -u -k all

NAME FSTYPE FSVER LABEL UUID FSAVAIL FSUSE% MOUNTPOINTS md3 crypto_LUKS 2 929fcee4-d730-4745-833e-83b956e5f057
`-encrypted-backup xfs 4481788d-7d11-44c9-a7ee-46e0bfbbea8d

UUID=4481788d-7d11-44c9-a7ee-46e0bfbbea8d /media/backup xfs rw,noatime,nodiratime,nosuid,noexec,nodev 0 2

systemctl daemon-reload

mkdir /media/backup mount /media/backup ```