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`
|
Nom de domaine pour les machines adm : `adm.crans.org`
|
||||||
|
|
||||||
```config
|
```txt
|
||||||
FQDN : `[nom du service].adm.crans.org`
|
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
|
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
|
```txt
|
||||||
thor(config)#interface Port-Channel 3
|
thor(config)#interface Port-Channel 3
|
||||||
thor(config-if-Po3)#
|
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
|
### Mettre à jour le switch
|
||||||
|
|
||||||
> C'est pas forcément nécessaire et ça peut tout casser, si néanmoins tu
|
> 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