Merge branch 'master' into ansible
korenstin
commit
c70834d1e5
|
|
@ -0,0 +1,109 @@
|
|||
# Réunion IN
|
||||
|
||||
* Date : Samedi 22 Juin 2024
|
||||
* Lieu : MB87 et Galène <https://galene.crans.org/group/CA>
|
||||
* Début : 14h23 - reprise à 15h20
|
||||
* Fin : 16h07
|
||||
|
||||
## Présent⋅es
|
||||
|
||||
* GaBo
|
||||
* [Chiaroush](https://wiki.crans.org/WikiChiaroush)
|
||||
* [vanille](https://wiki.crans.org/VanilleNiven)
|
||||
* lzebulon
|
||||
* Otthorn
|
||||
* [RDB](https://wiki.crans.org/WikiRDB)
|
||||
* [bleizi](https://wiki.crans.org/WikiBleizi)
|
||||
* [Aplanos](https://wiki.crans.org/WikiAplanos)
|
||||
|
||||
## Ordre du jour
|
||||
|
||||
* Clé usb d’installation de 128go avec ventoy ou équivalent pour les
|
||||
installations
|
||||
* commande des disques (si pas fait d’ici là, rappeler GaBo) (ou le faire en
|
||||
live)
|
||||
* [GaBo] Ansible est trop vieux (drop de support de certain plugin, peut pas
|
||||
relancer les playbooks. Marche encore avec ansible_2_14)
|
||||
* [Otthorn] ssh -L 1636:tealc.adm.crans.org:636 tealc.adm.crans.org pas le bon
|
||||
LDAP, faut utiliser wall-e
|
||||
* [Otthorn] Action deny sur WikiMoinMoin
|
||||
* [Lzebulon] Point sur les backups : ne semble pas fonctionner
|
||||
(backup-{thot,ft} non contactable)
|
||||
* VM Collabora
|
||||
* [Gabo] Ecriture du guide pour faire des VM dans la documentation
|
||||
* Owncloud : soucis de LDAP
|
||||
* Gitlab : à mettre à jour au plus vite (on est en 16.1)
|
||||
|
||||
### Clé USB d'installation 128 go Ventoy
|
||||
|
||||
(En référence à une conversation du 16 Mai 2024)
|
||||
Une seule clé avec plusieurs ISO plutôt que clés nombreuses avec distros
|
||||
différents -> Problèmes de sécurité, mais intéressant pour les nounous
|
||||
Le logiciel proposé (Ventoy) est plutôt répandu/réputé mais pas terrible.
|
||||
Problèmes de sécurité entre-autre.
|
||||
On propose de faire minimaliste sans utiliser le logiciel Ventoy. Ce serait
|
||||
intéressant parce que ça nous épargnerait le trousseau de clés (qui a été
|
||||
perdu il paraît), à discuter au prochain CA.
|
||||
GaBo propose de partir sur 5 clés de 128 go -> 1 clé / Nounous présentes sur
|
||||
le plateau.
|
||||
GaBo propose 64 go. 128 go lui paraît overkill. Pas de différence trop grande
|
||||
en terme de prix -> On part sur du 128 go.
|
||||
En Install Party, on fait rarement plus de 5 installs en parallèle.
|
||||
(Prendre en compte qu'il y a toujours une clé qui est perdue...)
|
||||
|
||||
Projet apprenti rigolo de créer un script qui génère les clés (mettre tel
|
||||
OS sur une clé).
|
||||
|
||||
### Commande des disques
|
||||
|
||||
Les disques sont commandés et arrivés !
|
||||
Il reste les ventilos.
|
||||
GaBo a payé avec sa carte, il attend le remboursement de la part du Trésorier
|
||||
(Macéo) pour procéder à l'achat des ventilos.
|
||||
|
||||
Avons-nous prévu un moment pour installer les nouveaux disques ? <- On en a
|
||||
discuté dans le point disques du CA.
|
||||
|
||||
### Ansible
|
||||
|
||||
On a plein de version de retard (on est en 2.14 et la version actuelle est la
|
||||
10).
|
||||
<https://endoflife.date/ansible>
|
||||
Il faudrais mette ça à jour : plugin LDAP et README en particulier et
|
||||
peut-être le plugin pass. On eput essayer de faire en même temps que
|
||||
l'install de Colabora
|
||||
|
||||
### WikiMoinMoin
|
||||
|
||||
On a des soucis avec l'action "deny" qui ne permettait de voir une page
|
||||
privée. Otthorn a fait un proof au concept de l'erreur. Il a réactivé deny,
|
||||
c'est bon. Mais on sait pas pourquoi ça avit été désactivé il y a
|
||||
longtemps.
|
||||
|
||||
### Backups
|
||||
|
||||
Faut se bouger pour aller voir VR en vrai à une de leurs permanences. C'est
|
||||
peut-être juste l'ethernet qui est débranchée. (Et potentiellement aussi
|
||||
changer pour un cable qui fonctionne)
|
||||
|
||||
Faire les backups correctement (comme l’a indiqué Otthorn, en excluant les
|
||||
trucs reliés à postgress et utilisé le hook conçu pour)
|
||||
voir dans la config ansible
|
||||
|
||||
### Colabora
|
||||
|
||||
(Pigeon : Si vous arrivez à setup colabora hésitez pas, onlyoffice c'est
|
||||
chiant je comprends rien à comment ça fonctionne)
|
||||
|
||||
### Owncloud
|
||||
|
||||
La config a disparu par magie (À enquêter)
|
||||
|
||||
### GitLab
|
||||
|
||||
Il faut mettre à jour. (On le fera vers juste après l’IN)
|
||||
|
||||
### Documentation
|
||||
|
||||
GaBo a été désigné grand gagnant de qui s'occupera de la documentation
|
||||
d'Ansible.
|
||||
|
|
@ -0,0 +1,211 @@
|
|||
# Réunion IN
|
||||
|
||||
* Date : Jeudi 29 Août 2024
|
||||
* Lieu : MB87 et Galène <https://galene.crans.org/group/CA>
|
||||
* Début : 18h58
|
||||
* Fin : 21h
|
||||
|
||||
## Présent⋅es
|
||||
|
||||
* [bleizi](https://wiki.crans.org/WikiBleizi)
|
||||
* [Pigeon Moelleux](https://wiki.crans.org/WikiPigeonMoelleux)
|
||||
* GaBo
|
||||
* [vanille](https://wiki.crans.org/VanilleNiven)
|
||||
* korenst1
|
||||
* Lzebulon
|
||||
* Shinigami
|
||||
* [Hachino](https://wiki.crans.org/WikiHachino)
|
||||
* underscore_j
|
||||
* RDB
|
||||
* Otthorn
|
||||
|
||||
## Ordre du jour
|
||||
|
||||
### Rapide compte-rendu de ce qu'il s'est passé cet été
|
||||
|
||||
Ottorn, lzebulon ont créé une vm collabora. Conséquence : découverte de
|
||||
mauvaises configurations problème entre ansible et les scripts qui sont
|
||||
dépréciés.
|
||||
|
||||
Mise à jour de gitlab
|
||||
|
||||
Au milieu de l'été. pb entre owncloud et nextcloud. impossibilité d'écrire
|
||||
(indépendant du reste). esum a résolu le pb. Owncloud a ensuite perdu sa conf
|
||||
ldap.
|
||||
Nextcloud a fini d'être configuré (paramêtre de partage et les mails (envoi
|
||||
de mail automatique pour les événements)). Nextcloud marche bien.
|
||||
Pub pour nextcloud possible.
|
||||
|
||||
pb avec Onlyoffice. Beaucoup de difficulté. Onlyoffice est packagé dans apt.
|
||||
Pas possible d'installer onlyoffice comme ça. On doit le faire à la main.
|
||||
Donc ce n'est pas ansibelisable.
|
||||
Il n'est pas possible d'utiliser onlyoffice sur téléphone (firefox) et
|
||||
limité à 20 connexions en même temps. du coup, est-ce qu'on utilise
|
||||
Collabora ou Onlyoffice ?
|
||||
|
||||
Du coup on peut passer sur collabora qui n'a pas ces problèmes.
|
||||
Sinon Otthorn a trouvé la variable à modifier.
|
||||
|
||||
```txt
|
||||
server/Common/sources/constant.js
|
||||
exports.LICENSE_CONNECTIONS = 20;
|
||||
```
|
||||
|
||||
### état sur les serveurs de backup
|
||||
|
||||
2 serveurs de backups. ft éteint par VR car fait trop de bruit. Mais il marche
|
||||
et permet de faire
|
||||
Peut-être la poussière ou les ventilos sont cassés. Bref, il faudra
|
||||
probablement faire qch.
|
||||
On ne sait pas si l'ilo marche. Mais il est possible de relancer les backups.
|
||||
|
||||
specs du serveurs chez viarezo :
|
||||
<https://wiki.crans.org/CransNostalgie/CransTechnique/LesServeurs/ServeurFt>
|
||||
|
||||
Pour thot : le serveur s'éteint spontanément après le démarrage. c'est
|
||||
probablement à cause de la sonde de température
|
||||
|
||||
On remet ft puis on réinstalle thot
|
||||
|
||||
Il existe plus simple que borg. Est-ce qu'on ne passerait pas sur truc plus
|
||||
récent. mais on garde borg pour le moment. Sinon on peut utiliser restic.
|
||||
|
||||
On s'assure que ft remarche avant de faire thot (moins urgent)
|
||||
|
||||
Pigeon : "IL FAUT REDÉMARRER AU PLUS VITE LES SERVEURS DE BACKUP"
|
||||
|
||||
Tealc : on n'arrive pas à ajouter les disques donc pk on y arriverait avec
|
||||
thot ?
|
||||
|
||||
Backup chez aurore ? -> Pas forcément une bonne idée car il y a peu de membre
|
||||
actif chez eux.
|
||||
|
||||
Chez Tuxae ? -> c'est possible on a l'accord du président.
|
||||
|
||||
Chez un hebergeur ? -> glacier. Pas chère pour écrire mais payer pour
|
||||
récupérer les données.
|
||||
|
||||
ft urgent et une fois fonctionnel, on commence sur thot. On peut aussi chiffrer
|
||||
les disques nativement avec zfs.
|
||||
|
||||
### Cephiroth
|
||||
|
||||
Le point ne bouge toujours pas. GaBo cherche la facture (c'est faux).
|
||||
|
||||
### Serveur matrix
|
||||
|
||||
De plus en plus de demande pour avoir une alternative libre à discord,
|
||||
whatsapp....
|
||||
|
||||
Mastodon -> pas adapté
|
||||
Zulipe -> pas adapté
|
||||
Mattermost -> pas adapté
|
||||
Matrix -> faire de la pédagogie. Pas le temps de faire le support technique ?
|
||||
Il est possible de faire des vocaux. Il faut présenter ça aux gens mais iels
|
||||
auront besoin d'une passphrase et ou une clef de récupération.
|
||||
|
||||
Connexion ldap (note, crans ou les deux ?) <-> matrix possible mais est-ce que
|
||||
le serveur est possible de gérer plus de connexions.
|
||||
En principal, obligation de mettre le ldap du crans. Possibilité d'utiliser la
|
||||
note via Oauth...
|
||||
Les alias ça change. On doit conserver le pk. Potentiellement, on peut ajouter
|
||||
un préfix (genre "note_").
|
||||
|
||||
Ou alors, 2 instances de matrix, une pour chaque ldap. L'une est au bde mais le
|
||||
crans s'en occupe.
|
||||
Migrer SQLite à PostgreSQL.
|
||||
Si on migre le bde, il faut que se soit très stable.
|
||||
Est-ce qu'il est possible d'avoir de la redondance sur le serveur matrix ? a
|
||||
priori oui... mais peut-être pas intégrer pas défaut à matrix.
|
||||
matrix.crans.org juste un relai (bridge irc/matrix) pour la réinstallation, il
|
||||
faut demander à Erdnaxe.
|
||||
|
||||
On garde le serveur matrix tel quel (quitte à augmenter les perfs). migre de
|
||||
SQLite à PostgreSQL. LDAP crans en priorité.
|
||||
On met element
|
||||
chat.crans.org (facile à retenir)
|
||||
FAIRE DE LA PUB !
|
||||
|
||||
5 secondes sur Mastodon selon pigeon (c'est (déjà) perdu) mais moi je pense
|
||||
que la vérité est toute autre...
|
||||
Retirer la condition "cephirot.date < mastodon.date".
|
||||
Ajouter l'affirmation "Constellation.state == Cephiroth.state"
|
||||
|
||||
### Reprise des séminaires hebdomadaires
|
||||
|
||||
On en parle Samedi (31 août (2024 je précise car oui je vous vois à lire ce
|
||||
point moulte années plutard !))
|
||||
|
||||
### état de l'imprimante
|
||||
|
||||
bref : ça marche pas
|
||||
|
||||
L'imprimante a été déplacée mais impossible de communiquer avec
|
||||
l'imprimante.
|
||||
Il faudra se poser avec des personnes de la DSI pour résoudre le pb. Mais dire
|
||||
ce qu'on a fait, il est possible que ça avance.
|
||||
pigeon pense pouvoir s'en charger mais il ne connait pas ce qu'il y a autour de
|
||||
l'imprimante.
|
||||
|
||||
On essaie de s'en occuper assez rapidement (bleizi et pigeonmoelleux)
|
||||
|
||||
### mettre les clés gpg dans le pass
|
||||
|
||||
pb de rétention des clefs gpg. pigeon a "pillé" à bleizi les clefs.
|
||||
potentiellement signer les clefs gpg des nounous.
|
||||
|
||||
Remettre de l'ordre dans le pass. thot renommé en surface sans raison (a
|
||||
priori).
|
||||
|
||||
Pour la prochaine IN, garder le pass avec gpg ou passer sur sops ou autre...
|
||||
Sinon, demander aux vielles nounous (peb, pollion) si iels veulent garder leurs
|
||||
droits nounous (ça ressemble à une invitation à partir...).
|
||||
Pour les autres, on propose de rajouter les clefs gpg dans le pass.
|
||||
|
||||
### Quand est-ce qu'on redémarre tous les serveurs qui en ont besoin
|
||||
|
||||
Près de 400 jours qu'il tourne. (pas de coupure estivale).
|
||||
Pas possible de la faire avant les prochaines vacances. En profiter pour
|
||||
refaire le cablage.
|
||||
Une réunion de préparation de la réparation.
|
||||
(redémarrage et brassage)-> prochain IN
|
||||
|
||||
### Chronolgie TODO list
|
||||
|
||||
Très urgent :
|
||||
|
||||
* Backup ft (commencé à faire les backup)
|
||||
* 1/2 qui non important (genre voyager et helloworld)
|
||||
* par ordre d'importance (genre mailman)
|
||||
* d'ici là samedi rangement, inté, séminaires
|
||||
* Cephiroth (garantie go GaBo)
|
||||
* puis on s'occupe de thot
|
||||
|
||||
on est déjà dans qq semaines :
|
||||
|
||||
* onlyoffice (la limite)
|
||||
* bleizi, pigeon -> imprimante
|
||||
* les clefs gpg dans le passe (demander à pollion et peb, s'ils veulent rester
|
||||
nounous)
|
||||
* enlever les vielles nounous (charlie, peb ? et pollion ?)
|
||||
|
||||
Le mois prochain :
|
||||
|
||||
* prévénir tout le monde que les serveurs du crans sont down
|
||||
* Backup tealc sur zéphir/cameron
|
||||
* inventaire et commander des disques d'avances (un disque en rab compatible
|
||||
pour chacun des serveurs)
|
||||
* coupure : recabler, (vérifier l'étiqueteuse)
|
||||
* PASSER LA POOL EN 4096
|
||||
* réinstaller tealc
|
||||
|
||||
Après :
|
||||
|
||||
* voir matrix
|
||||
* rediscuter de mastodon
|
||||
* Nix
|
||||
|
||||
Jamais :
|
||||
|
||||
* Constellation
|
||||
* Ceph
|
||||
File diff suppressed because it is too large
Load Diff
|
|
@ -117,7 +117,7 @@ En cas de problème, il est possible de le configurer après installation dans
|
|||
|
||||
Nom de domaine pour les machines adm : `adm.crans.org`
|
||||
|
||||
```config
|
||||
```txt
|
||||
FQDN : `[nom du service].adm.crans.org`
|
||||
```
|
||||
|
||||
|
|
|
|||
|
|
@ -0,0 +1,106 @@
|
|||
# Comment redémarrer le Crans ?
|
||||
|
||||
Le Crans dispose de beaucoup de serveurs physiques en salle opérateur de l'ENS
|
||||
(actuellement en SQ39), ainsi que beaucoup de machines virtuelles tournant sur
|
||||
les hyperviseurs. De temps en temps (environ une fois par an), vous serez
|
||||
amené⋅es à redémarrer l'entièreté des machines, par exemple pour recâbler la
|
||||
baie, et il faudra alors faire les choses dans l'ordre. Voici un petit guide
|
||||
sur comment faire précisément.
|
||||
|
||||
## Préparation
|
||||
|
||||
Tout d'abord, il faut discuter quelques semaines (~2 mois) en avance du besoin
|
||||
d'un redémarrage : ce n'est pas un acte à prendre à la légère car des personnes
|
||||
(même des vieilleux !) utilisent des services du Crans dans la vie de tout les
|
||||
jours, il faut donc éviter de les couper trop souvent. Cependant, pour faire
|
||||
des mises à jour majeures, du recâblage, des changements de serveurs, ... cela
|
||||
peut s'avérer nécessaire.
|
||||
|
||||
Il faut discuter du besoin d'un redémarrage pendant au moins 2 IN au préalable
|
||||
pour bien définir ce qu'il y a précisément à faire, et quelles seront les
|
||||
nounous présentes pour aider. Bien évidemment, les apprenti⋅es sont les
|
||||
bienvenu⋅es, mais il est impératif que des nounous soient présentes pour bien
|
||||
expliquer ce qu'il se passe.
|
||||
|
||||
Ensuite, une fois que le besoin de redémarrer est bien acté, il faut prévenir
|
||||
la **totalité** des adhérent⋅es et des ancien⋅nes adhérent⋅es du Crans avec ce
|
||||
qu'on appelle communément un "mail all". Pour cela, vous devez vous rendre sur
|
||||
la VM `re2o`, écrire le mail dans un nouveau dossier puis exécuter le script
|
||||
d'envoi de mail. Ce mail doit être envoyé au minimum deux semaines avant la
|
||||
coupure, voire plus si possible. Il ne faut pas hésiter en plus de cela de
|
||||
prévenir de nouveau les adhérent⋅es via d'autres plateformes de communications
|
||||
(newsletter BdE, Discord, ...).
|
||||
|
||||
## Avant la coupure
|
||||
|
||||
Le jour de la coupure, le mieux est de réunir toutes les personnes souhaitant
|
||||
participer (sans compter les retardaires) dans le bureau du Crans (actuellement
|
||||
en MB87). Une bonne idée est de prendre le temps qu'il faut pour clairement
|
||||
poser le plan du jour sur un tableau avec les différents objectifs à réaliser,
|
||||
potentiellement en parallèle. N'hésitez pas à vous répartir sur différentes
|
||||
tâches effectuables simultanément si vous êtes suffisamment nombreux⋅ses
|
||||
(compter au moins deux personnes dont une nounou par tâche pour ne laisser
|
||||
personne seul).
|
||||
|
||||
Vous pouvez au préalable ou par la suite récupérer les badges du Crans ouvrant
|
||||
la salle opérateur SQ39 au PC sécurité : prendre deux badges au lieu d'un est
|
||||
une plutôt bonne idée pour qu'un groupe de personnes puisse faire un
|
||||
aller-retour sans se retrouver coincé à l'extérieur. Ne pas hésiter également à
|
||||
prendre à boire, de préference dans des récipients qui ne se renversent pas
|
||||
facilement et des boissons qui ne tâchent pas trop.
|
||||
|
||||
En parallèle, vous pouvez garder une trace de toutes les actions effectuées
|
||||
dans la journée en notant tout ce que vous faites sur un pad (qui n'est pas
|
||||
hébergé au Crans) pour pouvoir retracer toutes les actions, ce qui est pratique
|
||||
lorsque que quelque chose casse (un peu souvent donc).
|
||||
|
||||
## Éteindre les serveurs
|
||||
|
||||
Pour éviter au maximum les problèmes, il est important que certaines machines
|
||||
soient éteintes avant d'autres. Voici un ordre qui fonctionne avec
|
||||
l'infrastructure actuelle :
|
||||
|
||||
- serv[ENS]
|
||||
- VM adh (passer par Proxmox sur stitch/odlyd/gulp)
|
||||
- hyperviseurs adh : stitch/odlyd/gulp
|
||||
- zamok
|
||||
- VM adm (sauf routeur-sam !, passer par Proxmox sur sam)
|
||||
- hyperviseurs adm (sauf sam !) : jack/daniel
|
||||
- cameron
|
||||
- tealc
|
||||
- sam
|
||||
|
||||
Surtout ne pas hésiter à vous ssh sur les machines au préalable pour ne pas se
|
||||
retrouver coincé car le LDAP adm est éteint.
|
||||
|
||||
## Rallumer les serveurs
|
||||
|
||||
De même que pour l'extinction, l'allumage des serveurs peut se faire dans à peu
|
||||
près n'importe quel ordre, sauf pour quelques machines importantes. Voici un
|
||||
ordre qui fonctionne avec l'infrastructure actuelle :
|
||||
|
||||
- sam et routeur-sam
|
||||
- tealc
|
||||
- cameron
|
||||
- hyperviseurs adm : jack/daniel
|
||||
- zamok
|
||||
- VM adm (passer par Proxmox sur sam)
|
||||
- hyperviseurs adh : stitch/odlyd/gulp
|
||||
- VM adh (passer par Proxmox sur stitch/odlyd/gulp)
|
||||
- serv[ENS]
|
||||
|
||||
⚠ Attention : pour zamok, vous devez redémarrer le service postfix avec
|
||||
|
||||
```bash
|
||||
sudo systemctl restart postfix.service
|
||||
```
|
||||
|
||||
après avoir rétabli le réseau et **avant** de redémarrer redisdead afin de ne
|
||||
perdre aucun mail. Plus exactement : il faut vérifier que le dossier
|
||||
`/home/mail` sur zamok contienne des centaines d'adhérent⋅es en non pas
|
||||
seulement quelques dizaines.
|
||||
|
||||
Ensuite, assurez-vous bien que **TOUS** les serveurs soient allumés, dont ceux
|
||||
de serv[ENS] ! Profitez-en alors pour faire des mises à jour nécessaires
|
||||
pendant que les adhérent⋅es ne sont pas encore de retour sur zamok et les
|
||||
autres services.
|
||||
|
|
@ -144,13 +144,67 @@ thor(config-if-Et3-4)#exit
|
|||
```
|
||||
|
||||
Puis ensuite on peut configurer le reste (VLANs et tout …) dans l'interface
|
||||
Port-Channel 3.
|
||||
Port-Channel 3. (Et non pas sur les interfaces eth).
|
||||
|
||||
```txt
|
||||
thor(config)#interface Port-Channel 3
|
||||
thor(config-if-Po3)#
|
||||
```
|
||||
|
||||
### Configurer le MLAG (Multi chassis Link AGregregation)
|
||||
|
||||
Nos switch arista supportent une feature que arista appele le MLAG. Cette feature
|
||||
permet notaments de faire du LACP avec des ports entre deux switch et donc d'avoir
|
||||
une redondance sur les switchs.
|
||||
|
||||
Il faut commencer par configurer le MLAG entre les deux switchs.
|
||||
|
||||
```txt
|
||||
TODO
|
||||
```
|
||||
|
||||
On peut ensuite configurer un lien en LACP. On configure ici les ports 3 de
|
||||
chaque switch en redondance sur le port-channel 3 / mlag 3.
|
||||
|
||||
sur le premier switch :
|
||||
|
||||
```txt
|
||||
arceus(config)#interface ethernet 3
|
||||
arceus(config-if-Et3)#channel-group 3 mode active
|
||||
arceus(config-if-Et3)#interface port-channel 3
|
||||
arceus(cofnig-if-Po3)#mlag 3
|
||||
```
|
||||
|
||||
sur le second switch :
|
||||
|
||||
```txt
|
||||
carapuce(config)#interface ethernet 3
|
||||
carapuce(config-if-Et3)#channel-group 3 mode active
|
||||
carapuce(config-if-Et3)#interface port-channel 3
|
||||
carapuce(config-if-Po3)#mlag 3
|
||||
```
|
||||
|
||||
On peut vérifier l'état des liens configurés en mlag via :
|
||||
|
||||
```txt
|
||||
carapuce(config-if-Po11)#show mlag interfaces
|
||||
local/remote
|
||||
mlag desc state local remote status
|
||||
---------- ---------- ----------------- ----------- ------------ ------------
|
||||
1 active-full Po1 Po1 up/up
|
||||
3 active-full Po3 Po3 up/up
|
||||
5 active-full Po5 Po5 up/up
|
||||
6 inactive Po6 Po6 down/down
|
||||
7 inactive Po7 Po7 down/down
|
||||
8 active-full Po8 Po8 up/up
|
||||
9 inactive Po9 Po9 down/down
|
||||
10 active-full Po10 Po10 up/up
|
||||
11 active-full Po11 Po11 up/up
|
||||
12 inactive Po12 Po12 down/down
|
||||
```
|
||||
|
||||
Il faudra configurer les vlans et autres sur les port-channel des deux switchs.
|
||||
|
||||
### Mettre à jour le switch
|
||||
|
||||
> C'est pas forcément nécessaire et ça peut tout casser, si néanmoins tu
|
||||
|
|
|
|||
|
|
@ -0,0 +1,92 @@
|
|||
# Outils de backups
|
||||
|
||||
## Présentation
|
||||
|
||||
Ce dossier contient une présentation des logiciels utilisés par le Crans pour
|
||||
faire ses sauvegardes, ou backups en anglais. On entend ici par backup une
|
||||
opération qui consiste à dupliquer de manière sécurisée (chiffrée en
|
||||
l'occurrence) sur d'autres serveurs les données des utilisateurices et des
|
||||
machines du Crans.
|
||||
|
||||
Comme dans tout le dossier [logiciels](../../../), le but n'est pas de
|
||||
réexpliquer l'entièreté des fonctionnalités mais simplement d'a voir les bases
|
||||
de compréhension.
|
||||
|
||||
## Organisation
|
||||
|
||||
Vous trouverez ici deux fichiers correspondant aux deux logiciels utilisés pour
|
||||
les backups au Crans :
|
||||
|
||||
- [borg](./borg.md) pour les logiciels borg et borgmatic ;
|
||||
- [restic](./restic.md) pour le logiciel du même nom.
|
||||
|
||||
Il est cependant fortement conseillé de lire la fin de ce fichier présentant
|
||||
certaines informations concernant les backups qu'il est important de connaître
|
||||
avant de lire plus en détails les autres fichiers détaillant plus
|
||||
spécifiquement les logiciels.
|
||||
|
||||
## Contexte
|
||||
|
||||
### Historique
|
||||
|
||||
Pour prevenir certains incidents dus à des erreurs de manipulation, le collège
|
||||
technique a mis en place en système de backups. Le but de celui-ci est de
|
||||
pouvoir, si le besoin s'en fait ressentir, aller rechercher un fichier supprimé
|
||||
ou écrasé. Bien qu'il serait possible de simplement faire une copie périodique
|
||||
des données sur un serveur distant, on lui préfère des solutions un peu plus
|
||||
développées qui permettent de faire des sauvegardes incrémentales. Fut un temps,
|
||||
la solution technique en place était le logiciel
|
||||
[BackupPC](https://backuppc.github.io/backuppc/), cependant celui-ci commençant
|
||||
à dater et ayant une faible ergonomie, nous utilisons aujourd'hui le logiciel
|
||||
[borg](https://borgbackup.readthedocs.io/) et son frontend
|
||||
[borgmatic](https://torsion.org/borgmatic/). De plus, le logiciel
|
||||
[restic](https://restic.readthedocs.io/) a été installé en parallèle pour sa
|
||||
simplicité d'utilisation : borg/borgmatic et restic cohabitent donc pour le
|
||||
moment pour que les jeunes membres actif⋅ves puissent comparer afin de faire un
|
||||
choix à long terme.
|
||||
|
||||
### Backups incrémentales
|
||||
|
||||
Avant de présenter ces logiciels, attardons nous un peu sur ce qu'on entend par
|
||||
faire des backups incrémentales. Pour cela revenons à notre piètre solution
|
||||
initiale qui consiste à copier (à grands coups de rsync, unison, scp...) toutes
|
||||
les données que l'on souhaiterait sauvegarder. Pour que ces sauvegardes soient
|
||||
utiles, il faut les réaliser assez fréquemment (quelque part entre un jour et
|
||||
une semaine disons). Cependant, à chaque nouvelle backup réalisée, celle-ci va
|
||||
venir écraser le contenu de la précédente et ainsi, on ne dispose jamais plus
|
||||
que d'une copie des données de la veille. Ainsi, des dysfonctionnements
|
||||
automatiques ou simplement de la négligence peuvent faire que l'on ne se rendra
|
||||
compte que l'on avait besoin de récupérer notre fichier il y a déjà quelques
|
||||
jours et qu'il a maintenant déjà été supprimé de la copie de sauvegarde.
|
||||
|
||||
On préfererait donc pouvoir disposer d'une collection de sauvegardes qui
|
||||
remonte sur quelques jours voir moi en fonction de la politique de rétention de
|
||||
sauvegarde qu'on mettrait en place. Par exemple, une sauvegarde pour chacun des
|
||||
septs derniers jours puis quelques unes espacée d'une semaine. Si l'on reprend
|
||||
notre solution naïve, on peut facilement en étendre l'usage pour ce nouvel
|
||||
office : on réalise une copie complète des données par jour que l'on souhaite
|
||||
sauvegarder. Suivant la politique de rétention que l'on a donné plus tôt cela
|
||||
consisterais en une quinzaine de copies distinctes des données à sauvegarder et
|
||||
donc une multiplication par quinze de la taille de celle-ci.
|
||||
|
||||
Si je jette un œil rapide à la taille que prends aujourd'hui les données
|
||||
utilisateurices, je vois qu'on utilise un peu plus de 2.5T de stockage, donc si
|
||||
l'on suit la logique, on devrait disposer d'une ou plusieurs machines
|
||||
totalisant un stockage d'environ 40T. Inutile de le dire je pense, mais cela
|
||||
fait (beaucoup) trop. Heureusement pour nous, d'un jour sur l'autre
|
||||
l'intégralité de nos données stockées ne varie pas et seule une petite partie
|
||||
change sur le cours d'une journée. Ainsi, si l'on ne stocke que les différences
|
||||
accumulé sur une journée par rapport à la veille, on se retrouvera avec une
|
||||
taille beaucoup plus raisonnable de sauvegarde. C'est ~la déduplication.
|
||||
|
||||
### Qu'est-ce que l'on sauvegarde ?
|
||||
|
||||
Au Crans, on sauvegarde deux types de données :
|
||||
|
||||
- D'un côté, on a les données d'administration, c'est une partie des disques
|
||||
de tous les serveurs (généralement le /etc et le /var sauf cas particulier),
|
||||
le home des nounous, les bases de données...
|
||||
|
||||
- De l'autre côté; on a les données des adhérents, c'est à dire : le contenu
|
||||
de leur répertoire personnel et de leur dossier mail qui au jour où j'écris
|
||||
ses lignes peut contenir au maximum 30G et 10G de données respectivement.
|
||||
|
|
@ -0,0 +1,110 @@
|
|||
# Borg
|
||||
|
||||
Page officiel de borg : <https://www.borgbackup.org/>.
|
||||
|
||||
Documentation de borg : <https://borgbackup.readthedocs.io/>.
|
||||
|
||||
Page officielle de borgmatic : <https://torsion.org/borgmatic/> (contient la
|
||||
documentation).
|
||||
|
||||
## Borg et borgmatic
|
||||
|
||||
Borg est un logiciel client/serveur permettant d'effectuer des sauvegardes
|
||||
incrémentales, dédupliquées et chiffrées par le client. Le serveur est simple à
|
||||
installer et utilise ssh comme protocole de transport entre lui et le client.
|
||||
Ainsi, il suffit de donner un accès ssh au client via une paire de clés pour lui
|
||||
autoriser à discuter avec le serveur. Quelque chose ressemblant à ça dans le
|
||||
`.ssh/authorized_keys` de l'utilisateur sur le serveur qui fera les backups :
|
||||
|
||||
```txt
|
||||
command="borg serve --restrict-to-path {{ chemin vers les sauvegardes }}",restrict {{ clé publique ssh }}
|
||||
```
|
||||
|
||||
Avec l'installation du paquet `borg` c'est la seule chose à faire sur le serveur
|
||||
et le reste du travail sera réalisé par le client. Après avoir aussi installé
|
||||
`borg` sur le client, on peut déjà commencer à faire quelques sauvegardes.
|
||||
Cependant, si l'on utilise que borg pour les faire (ce qui est possible), on se
|
||||
retrouvera avec des commandes bien trop longues dans lesquels on passe notre
|
||||
temps à spécifier des arguments plusieurs fois : comment contacter le serveur ?
|
||||
où stocker les sauvegardes ? quel politique de rétentions garder ? que faut-il
|
||||
sauvegarder ? Borgmatic est un frontend de borg qui définir une bonne fois pour
|
||||
toutes ses options dans un fichier de configuration pour ensuite n'avoir plus
|
||||
qu'à faire des appels simples à borgmatic qui pasera à borg tous les paramètres
|
||||
dont il a besoin. Le but n'est pas ici d'être exhaustif sur ce que peut/doit
|
||||
contenir ce fichier de configuration. Je vous redirige pour ça vers la
|
||||
[documentation
|
||||
officielle](https://torsion.org/borgmatic/docs/reference/configuration/). Ici,
|
||||
je vais plus chercher à vous donner quelques options minimales et des exemples
|
||||
d'utilisations de borgmatic. Commençons par donner le contenu d'un fichier de
|
||||
configuration partiel :
|
||||
|
||||
```txt
|
||||
location:
|
||||
source_directories:
|
||||
- /etc
|
||||
- /var
|
||||
repositories:
|
||||
- ssh://borg@backup-server:/folder/to/backup/to
|
||||
|
||||
storage:
|
||||
encryption_passphrase: PASSPHRASE
|
||||
ssh_command: ssh -i /etc/borgmatic/id_ed25519_borg
|
||||
|
||||
retention:
|
||||
keep_daily: 4
|
||||
keep_monthly: 6
|
||||
```
|
||||
|
||||
Dans la section `location`, on définit deux choses : ce que l'on souhaite
|
||||
sauvegarder et où on souhaite le sauvegarder. Ici on va backupé le `/etc` et
|
||||
`/var` de notre client sur un serveur distant qu'on contactera via ssh. Dans la
|
||||
section suivante, `storage`, on définit quelques options relatives au stockage
|
||||
et à comment y accéder. Premièrement, on donne la passphrase de chiffrement des
|
||||
sauvegardes (attention, si elle est perdue, les sauvegardes ne seront plus
|
||||
accessibles). Ensuite, on précise comment accéder au serveur (ici, l'information
|
||||
importante est où se trouve la clé privée pour pouvoir se connecter). Enfin,
|
||||
dans la section retention, on définit notre politique de retention : le serveur
|
||||
ne doit stocker qu'une backup quotidienne sur les 4 derniers jours, et une
|
||||
backup mensuelle sur les 6 derniers mois.
|
||||
|
||||
En supposant les autres options de fonctionnement renseignées dans le fichier,
|
||||
que je ne détaillerais pas ici, il est maintenant possible de commencer à
|
||||
utiliser le logiciel et faire nos premières sauvegardes.
|
||||
|
||||
## Créer l'archive de stockage
|
||||
|
||||
La commande suivante permet de créer l'archive où seront stockées les
|
||||
sauvegardes sur le serveur.
|
||||
|
||||
```bash
|
||||
borgmatic init -e repokey
|
||||
```
|
||||
|
||||
## Faire une première sauvegarde
|
||||
|
||||
Pour faire une sauvegarde, rien de plus simple, on appelle simplement le
|
||||
programme borgmatic sans option. Il est néanmoins possible de demander un
|
||||
affichage plus verbeux pour le débogage.
|
||||
|
||||
```bash
|
||||
borgmatic
|
||||
borgmatic -v 2
|
||||
```
|
||||
|
||||
## Lister les différentes sauvegardes dans l'archive
|
||||
|
||||
```bash
|
||||
borgmatic list
|
||||
```
|
||||
|
||||
## Monter une sauvegarde précise sur un point de montage
|
||||
|
||||
```bash
|
||||
borgmatic mount --archive {{ nom de l'archive ou latest pour la dernière }} --mount-point /mnt --path {{ chemin à monter de l'archive }}
|
||||
borgmatic mount --archive latest --mount-point /mnt --path etc/nginx/nginx.conf
|
||||
```
|
||||
|
||||
## Automatiser les backups
|
||||
|
||||
Pour réaliser des backups périodique, on peut en laisser la charge à un cron ou
|
||||
à systemd à l'aide d'un timer.
|
||||
|
|
@ -0,0 +1,138 @@
|
|||
# Restic
|
||||
|
||||
Page officielle de restic : <https://restic.net/>.
|
||||
|
||||
Documentation de restic : <https://restic.readthedocs.io/>.
|
||||
|
||||
Dépôt officiel de restic rest-server : <https://github.com/restic/rest-server>.
|
||||
|
||||
## Présentation
|
||||
|
||||
Restic est un logiciel client/serveur permettant d'effectuer des sauvegardes
|
||||
incrémentales, dédupliquées et chiffrées par le client. Différents serveurs
|
||||
sont utilisables par le client, nous présenterons ici le serveur REST de restic
|
||||
utilisant le protocole HTTP, qui est installé actuellement au Crans sur
|
||||
[thot](../../../infrastructure/machines/physiques/thot.md).
|
||||
|
||||
Pour la configuration d'un client, vous aurez besoin d'installer le paquet
|
||||
`restic` sur les machines sous debian, restic étant déjà packagé dans nixpkgs
|
||||
pour les machines sous NixOS.
|
||||
|
||||
## Configuration du serveur
|
||||
|
||||
Le choix le plus simple à mettre en place pour la partie serveur de restic est
|
||||
restic rest-server, très simple à mettre en place. Vous pouvez trouver la
|
||||
configuration actuelle dans le module restic du
|
||||
[dépôt NixOS](https://gitlab.crans.org/nounous/nixos).
|
||||
|
||||
Le fonctionnement de ce serveur REST est le suivant : le client compresse et
|
||||
chiffre ses données avec un mot de passe, vient s'authentifier en
|
||||
[basic auth](https://en.wikipedia.org/wiki/Basic_access_authentication) auprès
|
||||
du serveur, puis dépose la backup au fur et à mesure de son avancée sur le
|
||||
serveur. Chaque client dispose donc de deux mots de passe : une clef de
|
||||
chiffrement pour les données, ainsi qu'un mot de passe pour s'authentifier
|
||||
auprès du serveur REST.
|
||||
|
||||
Deux notions sont importantes à comprendre ici dans la configuration du serveur
|
||||
REST.
|
||||
|
||||
- L'option `privateRepos`/`--private-repos` : permet de faire en sorte qu'un⋅e
|
||||
utilisateurice (dans notre cas une machine) ne puisse accéder qu'à ses
|
||||
propres backups et puisse créer tous les dépôts souhaités dans un sous
|
||||
dossier à son nom. Ainsi, une fois authentifiée, la VM flirt aura accès à
|
||||
tous dépôt de la forme `restic:http://thot.adm.crans.org/flirt/<dépôt>`, ce
|
||||
qui est particulièrement pratique pour ne pas avoir à gérer les accès à la
|
||||
main pour chaque machine.
|
||||
- Les clients sont authentifiées par le serveur grâce à un fichier `.htpasswd`
|
||||
situé à la racine du dossier de données. Ainsi, si le dossier de données est
|
||||
`/backups`, le fichier d'authentification sera `/backups/.htpasswd`. Ce
|
||||
fichier est un fichier d'authentification standard : vous pouvez consulter la
|
||||
[page Wikipédia](https://en.wikipedia.org/wiki/.htpasswd) dédiée pour plus
|
||||
d'informations. Vous pouvez alors ajouter une machine à ce fichier avec la
|
||||
commande :
|
||||
|
||||
```bash
|
||||
sudo htpasswd -B /backups/.htpasswd <username> [<password>]
|
||||
```
|
||||
|
||||
Si le mot de passe n'est pas spécifié, il sera alors demandé sur l'entrée
|
||||
standard.
|
||||
|
||||
## Configuration du client
|
||||
|
||||
Théoriquement, restic est uniquement un logiciel qui s'utilise directement.
|
||||
Cependant, nous souhaitons faire des sauvegardes automatiquement en utilisant
|
||||
des systemd timer, on va donc créer plusieurs fichiers pour ne pas à avoir tout
|
||||
à spécifier directement dans les lignes de commande.
|
||||
|
||||
Actuellement, la configuration des clients restic se situe dans le dossier
|
||||
`/etc/restic` sous debian, et dans le
|
||||
[dépôt NixOS](https://gitlab.crans.org/nounous/nixos) pour les machines sous
|
||||
NixOS. Dans les deux cas, on retrouve les mêmes éléments (on donne les noms
|
||||
pour la configuration par défault des machines sous debian) :
|
||||
|
||||
- un fichier d'environnement `base.env`, contenant plusieurs variables d'environnement
|
||||
dont l'utilité précise peut être trouvée dans
|
||||
[la documentation de restic](https://restic.readthedocs.io/en/stable/040_backup.html#environment-variables).
|
||||
- un fichier `base-repo` contenant la position du dépôt (serveur REST), avec
|
||||
les identifiants de connexion, qui se présente sous la forme
|
||||
`restic:http://<username>:<password>@thot.adm.crans.org/<username>/base`.
|
||||
- un fichier `base-password` contenant le mot de passe de chiffrement des
|
||||
sauvegardes.
|
||||
- deux fichiers `base-includes` et `base-excludes` indiquant respectivement les
|
||||
dossiers inclus et exclus pour les sauvegardes.
|
||||
|
||||
En plus de cela, on trouve un service systemd `restic-base` ainsi qu'un timer
|
||||
associé dans le dossier `/etc/systemd/system/`. Ce service lancera deux
|
||||
commandes : une commande pour lancer une sauvegarde, et une commande pour
|
||||
supprimer les anciennes sauvegardes qui ne seront pas gardées en tant que
|
||||
sauvegarde journalière/hebdomadaire/mensuelle/annuelle (définies par la
|
||||
configuration).
|
||||
|
||||
## Initialiser un dépôt
|
||||
|
||||
En supposant que vous avez la configuration décrite ci-dessus, vous pouvez
|
||||
initialiser un dépôt grâce à la commande suivante :
|
||||
|
||||
```bash
|
||||
restic init --repository-file /etc/restic/data-repo --password-file /etc/restic/data-password
|
||||
```
|
||||
|
||||
## Faire une sauvegarde à la main
|
||||
|
||||
Pour faire une sauvegarde à la main, rien de compliqué, il suffit de lancer le
|
||||
service systemd normalement de la manière suivante :
|
||||
|
||||
```bash
|
||||
sudo systemctl start restic-base.service
|
||||
```
|
||||
|
||||
(Même si c'est surprenant, vous pouvez faire CTRL+C à ce moment dans votre
|
||||
terminal, la tâche continuera en fond.)
|
||||
|
||||
De plus, si la variable `RESTIC_PROGRESS_FPS` a été affectée à une valeur
|
||||
strictement positive, vous pourrez voir la progression de la sauvegarde dans
|
||||
le journal. Vous pouvez donc y accéder par la commande :
|
||||
|
||||
```bash
|
||||
sudo journalctl -xefu restic-base
|
||||
```
|
||||
|
||||
## Consulter l'état des sauvegardes
|
||||
|
||||
Pour consulter la liste actuelle des sauvegardes, vous pouvez simplement
|
||||
utiliser la commande :
|
||||
|
||||
```bash
|
||||
restic snapshots --repository-file /etc/restic/data-repo --password-file /etc/restic/data-password
|
||||
```
|
||||
|
||||
De plus, vous pouvez facilement monter une sauvegarde sur un point de montage
|
||||
avec la commande suivante :
|
||||
|
||||
```bash
|
||||
restic mount /mnt --repository-file /etc/restic/data-repo --password-file /etc/restic/data-password
|
||||
```
|
||||
|
||||
Cela bloquera alors votre terminal, et la sauvegarde sera démontée dès que vous
|
||||
quitterez votre terminal, évitant d'avoir une sauvegarde montée et oubliée.
|
||||
|
|
@ -0,0 +1,57 @@
|
|||
# Systemd
|
||||
|
||||
Systemd est une suite logiciel pour systèmes GNU/Linux. Cette suite logiciel
|
||||
fournit de nombreuses fonctionnalités, notamment pour configurer son OS et
|
||||
suivre les *daemon*\ s actifs et leurs journaux.
|
||||
|
||||
Ce document décrit *certaines* fonctionnalités de Systemd bien choisies,
|
||||
lesquelles sont jugées intéressantes pour l'administration système ou pour
|
||||
utilisateurices. Il sera sans doute découpé en plusieurs morceaux s'il devient
|
||||
trop long.
|
||||
|
||||
## Unités de configuration: un format unifiant.
|
||||
|
||||
### Services.
|
||||
|
||||
### Minuteurs.
|
||||
|
||||
### (Auto)mount.
|
||||
|
||||
## Configuration Réseau.
|
||||
|
||||
### Obtenir des adresses IPs.
|
||||
|
||||
### Configuration DNS (récursif).
|
||||
|
||||
## Journalisation.
|
||||
|
||||
### Lecture des journaux: les bases.
|
||||
|
||||
### Espaces de noms.
|
||||
|
||||
### Partage de journaux entre machines.
|
||||
|
||||
## Aspect pratique (pour utilisateurices)
|
||||
|
||||
### Chiffrement de disque.
|
||||
|
||||
### Chargeur d'amorçage.
|
||||
|
||||
## Conteneurisation et virtualisation.
|
||||
|
||||
### Conteneurisation.
|
||||
|
||||
### Virtualisation.
|
||||
|
||||
## Gestion des secrets.
|
||||
|
||||
## Trucs et astuces.
|
||||
|
||||
### Systèmes dynamiques: gestion des erreurs dans les services.
|
||||
|
||||
### Administration à distance.
|
||||
|
||||
<!-- LocalWords: IPs virtualisation utilisateurices Journalisation daemon
|
||||
<!-- LocalWords: Systemd Linux
|
||||
-->
|
||||
-->
|
||||
|
|
@ -1,198 +0,0 @@
|
|||
-*- mode: org; org-hide-emphasis-markers: t; -*-
|
||||
|
||||
#+TITLE: Description de ~systemd~ et comment l'utiliser?
|
||||
#+AUTHOR: Des nounous quelconques.
|
||||
#+EMAIL: contact@crans.org
|
||||
#+SEQ_TODO: TODO | in_progress | DONE
|
||||
#+DESCRIPTION: Pfiou que c'est fastidieux d'apprendre à parler au monde entier.
|
||||
#+INSTITUTE: Cr@ns
|
||||
#+LANGUAGE: fr
|
||||
#+STARTUP: overview
|
||||
|
||||
Le présent document est destiné aux proptiétaires de VMs au Cr@ns, mais plus
|
||||
généralement à nos membres qui souhaitent tirer le plus de ~systemd~.
|
||||
|
||||
~systemd~ est une suite logicielle qui a pour objectif de fournir une interface
|
||||
simple et unifiée à de nombreuses fonctionnalités du noyau Linux. En effet, les
|
||||
APIs Linux sont nombreuses et les utilisations multiples des mêmes interfaces
|
||||
peut être redondant.
|
||||
|
||||
Par exemple, considérons la tâche "lancer une backup" et supposons que l'on
|
||||
veuille (1) que la commande soit lancée un jour après que la dernière itération
|
||||
se soit terminée, et (2) éviter qu'une nouvelle backup soit lancée si l'ancienne
|
||||
n'est pas encore terminée. Systemd permet de paramétrer cela en quelques lignes,
|
||||
là où d'autres seraient tentés de faire un cron, dont la tâche associés commence
|
||||
par effectuer les vérications nécessaires au lancement conditionel.
|
||||
|
||||
-----
|
||||
|
||||
~systemd~ fournit un langage de configuration unifié et permet de paramétrer son
|
||||
système de manière déclarative, ce qui mène à des configurations plus sûres,
|
||||
systématiques et dont les sémantiques sont claires.
|
||||
|
||||
* Résumé succint (et partiel) des tâches effectuées par un utilitaire ~systemd~
|
||||
|
||||
| *Tâche* | *Utilitaire disponible* | Optionel (pour un système basé sur ~systemd~) |
|
||||
|--------------------------+------------------------------+-----------------------------------------------|
|
||||
| Boot loader | ~systemd-boot~ | Oui |
|
||||
| Init système (initrd) | ~systemd~ | Oui |
|
||||
| Init système | ~systemd~ | Non |
|
||||
| Gestionaire de service | ~systemd~ | Non |
|
||||
| DNS récursif | ~systemd-resolvd~ | Oui |
|
||||
| Gestion des ~$HOME~ | systemd-homed | Oui |
|
||||
| Montage de disques | ~systemd-fstab-generator~ | Pas à ma connaissance |
|
||||
| | ~systemd-gpt-auto-generator~ | Oui |
|
||||
| | ~systemd-fsck-generator~ | Peut-être |
|
||||
| Chiffrement de disques | ~systemd-cryptsetup~ | Oui |
|
||||
| | ~systemd-cryptenroll~ | Oui |
|
||||
| | ~systemd-crypttab-generator~ | |
|
||||
| Chiffrement de secrets | ~systemd-creds~ | Oui |
|
||||
| Gestion de l'horloge | ~systemd-timedated~ | Oui |
|
||||
| | ~systemd-timesyncd~ | Oui |
|
||||
| Nom d'hôte | ~systemd-hostnamed~ | Je ne sais pas |
|
||||
|
||||
** Critiques communes
|
||||
|
||||
/Cf/. la [[https://www.freedesktop.org/wiki/Software/systemd/FrequentlyAskedQuestions/][FAQ officielle]] du projet.
|
||||
|
||||
- /Il est dit que ~sd~ fait trop de choses/ !
|
||||
Ah bon ? Pourtant, ~systemd~ n'apparait pas si souvent dans le tableau ci-dessus.
|
||||
|
||||
- /Il est dit que ~sd~ est une dictature/ !
|
||||
|
||||
Je ne contribue pas, mais suis les messages postés sur les mailing list et
|
||||
parfois les issues du GitHub. Je trouve la communauté très accueillante.
|
||||
|
||||
|
||||
** Évolution de ~systemd~
|
||||
|
||||
~systemd~ évolue rapidement, pour permettre une gestion toujours plus fine des
|
||||
services, VMs, ... Certaines mises à jour de ~systemd~ retirent des
|
||||
fonctionnalités (/e.g./ ~/usr~ séparé ou ~cgroupsv1~). Lorsqu'il y a retrait d'une
|
||||
fonctionnalité, cela est au annoncé à l'avance, pour que chacun·e ait le temps
|
||||
de s'y préparer. Pour les deux exemples susmentionnés, cela a été annoncé plus
|
||||
d'un an à l'avance.
|
||||
|
||||
|
||||
* Rappel : processus de démarrage d'un ordinateur /systemd/GNU/Linux/
|
||||
|
||||
Ce paragraphe présente la manière dont les machines démarrent. Cette
|
||||
présentation se veut rapide, mais suffisante pour que chacun·e puisse comprendre
|
||||
à quelle étape de ce processus les disques d'un ordinateur sont déchiffrés,
|
||||
montés, /etc./
|
||||
|
||||
/Note/ : Je me concentrerai que sur les systèmes (U)EFI utilisant une table de
|
||||
partitions ~gpt~ (/i.e./ le disque sur lequel se trouvent les fichiers de démarrage
|
||||
contient un partitionnement ~gpt~).
|
||||
|
||||
Procédé de démarrage :
|
||||
|
||||
1. le logiciel de la carte mère est le premier élément à démarrer. Il charge
|
||||
vos paramètres (/e.g./ secure boot activé ou non) ;
|
||||
|
||||
2. le logiciel cherche à démarrer ou bien votre système d'exploitation
|
||||
directement, ou bien un /système d'amorçage/ (/bootloader/ en, anglais) ;
|
||||
|
||||
3. supposons qu'il lance ~systemd-boot~.
|
||||
~systemd-boot~ va constituer un menu avec
|
||||
- une ou plusieurs entrées pour lancer le(s) système(s) d'exploitation
|
||||
disponible(s) sur votre machine (ou en réseau),
|
||||
- une entrée pour redémarrer dans le panneau de configuration du logiciel
|
||||
UEFI,
|
||||
- une entrée pour redémarrer ;
|
||||
|
||||
4. Supposons que l'utilisateurice (ou ~systemd-boot~) choisisse un système sous
|
||||
~systemd~.
|
||||
~systemd~, qui est actuellement lancé dans un petit environnement (appelé
|
||||
/initrd/) va chercher à initialiser le système, noramment en :
|
||||
1. déchiffrant la partition racine du système (si nécessaire),
|
||||
2. montant la partition racine du sysème,
|
||||
3. pivotant sur le système final dont ~systemd~ vient de monter ~/~.
|
||||
|
||||
5. Nous sommes sur la bonne voie : le système de fichier principal est monté.
|
||||
~systemd~ monte les partitions/disques/resources réseaux supplémentaires
|
||||
requis, met en place les sous-systèmes nécessaires (journalisation, réseau,
|
||||
...).
|
||||
|
||||
L'un des derniers services démarré permet aux utilisateurices de
|
||||
s'authentifier. Le sysème a fini de démarrer.
|
||||
|
||||
|
||||
* TODO Configuration
|
||||
|
||||
** TODO Unité de configuration (~man systemd.unit~)
|
||||
|
||||
** TODO Service (~man systemd.service~)
|
||||
|
||||
** TODO Cibles (~man systemd.target~)
|
||||
|
||||
** TODO Minuteurs (~man systemd.timer~)
|
||||
|
||||
|
||||
* TODO Systemd : aspect pratique
|
||||
|
||||
** TODO Chiffrement (mots de passe, recovery key, FIDO2 ou TMP2)
|
||||
|
||||
L'utilitaire principal pour gérer le chiffrement de disques est
|
||||
~systemd-cryptenroll~.
|
||||
|
||||
** TODO Reconnaissance automatique de partitions
|
||||
|
||||
Lors de l'installation d'un système d'exploitation (avec UEFI), il y a au moins
|
||||
deux partitions :
|
||||
- une ESP (/EFI System Partition/), laquelle stocke les images de démarrage (dont
|
||||
l'éventuel boot loader) ;
|
||||
- une partition racine (root, ou ~/~), laquelle correspond au chemin ~/~ pour le
|
||||
système. C'est ici que sont généralement stockées vos applications, la
|
||||
configuration système, /etc/.
|
||||
|
||||
Pour ~systemd~, touts les points de montage sont des /unités de montage/ et le
|
||||
déchiffrement des disques est effectué via des /unités de services/. Ces unités
|
||||
sont /générées/ (/Cf./ plus bas).
|
||||
|
||||
|
||||
Lors du démarrage, il faut mettre le système de fichiers en place, /i.e./ monter
|
||||
les disques. Lors de l'installation du système d'exploitation, deux choix
|
||||
s'offrent à vous :
|
||||
- /OU BIEN/ Décrire les blocks à déchiffrer dans ~/etc/crypttab~ (/crypt table/) et
|
||||
les points de montage dans ~/etc/fstab~ (/file systems table/).
|
||||
|
||||
Ces fichiers seront inclus dans l'image de démarrage (qui est souvent appellée
|
||||
/initrd/ ou /initramfs/), afin que ~systemd~ sache quels disques déchiffrer et
|
||||
monter (et comment).
|
||||
|
||||
- /OU BIEN/ Indiquer le type de chaque partition ("X est ~/~", "Y est ~/boot~", "Z est
|
||||
~/home~", /etc./). Si tel est le cas, il n'est plus nécessaire d'inclure les
|
||||
partitions concernées dans ~/etc/fstab~.
|
||||
/Note/ : Si vous utilisez LUKS2 pour chiffrer vos disques, il n'est pas non plus
|
||||
nécessaire d'indiquer ces éléments dans ~/etc/crypttab~.
|
||||
|
||||
/Exemple/ : Partition ~/home~, troisième partition du disque ~/dev/nvme0n1~.
|
||||
Il suffit :
|
||||
- de changer le type de partition de ~/dev/nvme0n1p3~ :
|
||||
#+begin_src fdisk
|
||||
fdisk /dev/nvme0n1
|
||||
|
||||
t # change le type de partition
|
||||
3 # numéro de la partition à mettre à jour
|
||||
home # (ou 43) abbréviation pour "933ac7e1-2eb4-4f13-b844-0e14e2aef915"
|
||||
w # écrit les changements à la table de partitions
|
||||
#+end_src
|
||||
- retirer la ligne correspondant à ~/home~ dans ~/etc/fstab~ (et si la partition
|
||||
est chiffrée, de ~/etc/crypttab~ aussi),
|
||||
- régénrer les images de démarrage,
|
||||
- redémarrer et tester.
|
||||
|
||||
/Note/ : se référer à ~man systemd-gpt-auto-generator(8)~ pour une liste complète
|
||||
des tags ~gpt~ reconnus par ~systemd~.
|
||||
|
||||
|
||||
** TODO Redimension automatique de partitions
|
||||
|
||||
** TODO UKI et Secure boot
|
||||
|
||||
* TODO Réseau
|
||||
|
||||
* TODO Journalisation
|
||||
|
||||
* TODO Administration à distance
|
||||
Loading…
Reference in New Issue