WIP: refonte documentation, ajout sites
This commit is contained in:
parent
e36f761505
commit
47f2c98432
|
|
@ -25,7 +25,7 @@ Les sites principaux sont :
|
|||
Un site principal doit répondre à certains prérequis :
|
||||
- il dispose d'au moins une baie au format _rack 19 pouces_ ;
|
||||
- il accueille des machines physiques principales avec du [matériel éligible]() ;
|
||||
- il comporte un routeur **nommé d'après le nom du site** (Par exemple, à
|
||||
- il comporte un routeur **nommé d'après le nom du site** (par exemple, à
|
||||
Fontainebleau, le routeur se nomme `fontainebleau`) ;
|
||||
- il permet un accès à Internet fibré (FTTH) via une ligne dédiée souscrite auprès
|
||||
d'un opérateur de la [FFDN]() ;
|
||||
|
|
|
|||
|
|
@ -1,50 +0,0 @@
|
|||
## Accès aux serveurs physiques de l'infrastructure
|
||||
|
||||
### Configuration SSH côté infra
|
||||
|
||||
Pour un administrateur d'infrastructure, l'accès aux serveurs de l'infra se fait sur le compte sudoer `admin666` via le compte `cominfra`, authentifié par clé SSH.
|
||||
Pour qu'un nouvel administrateur puisse accéder aux serveurs, il faut :
|
||||
|
||||
- Sur `mother`, ajouter la clé publique (ssh) du nouvel admin dans `/home/cominfra/.ssh/authorized_keys` et `/home/admin666/.ssh/authorized_keys`
|
||||
|
||||
- Sur `aunt`, ajouter la clé publique (ssh) du nouvel admin dans `/home/cominfra/.ssh/authorized_keys` et `/home/admin666/.ssh/authorized_keys`
|
||||
|
||||
### Configuration SSH client
|
||||
|
||||
host mother.libre-en-communs.org
|
||||
User cominfra
|
||||
Port 222
|
||||
SendEnv GIT_AUTHOR_NAME GIT_AUTHOR_EMAIL
|
||||
|
||||
host mother666.libre-en-communs.org
|
||||
User admin666
|
||||
Hostname mother.libre-en-communs.org
|
||||
Port 222
|
||||
ProxyCommand ssh -q -W %h:%p mother.libre-en-communs.org
|
||||
SendEnv GIT_AUTHOR_NAME GIT_AUTHOR_EMAIL
|
||||
|
||||
host aunt.libre-en-communs.org
|
||||
User cominfra
|
||||
Port 223
|
||||
SendEnv GIT_AUTHOR_NAME GIT_AUTHOR_EMAIL
|
||||
|
||||
host aunt666.libre-en-communs.org
|
||||
User admin666
|
||||
Hostname aunt.libre-en-communs.org
|
||||
Port 223
|
||||
ProxyCommand ssh -q -W %h:%p aunt.libre-en-communs.org
|
||||
SendEnv GIT_AUTHOR_NAME GIT_AUTHOR_EMAIL
|
||||
|
||||
### Procédure de connexion avec config dans ~/.ssh/config
|
||||
|
||||
Le nouvel admin n'a plus qu'à utiliser `ssh mother666.libre-en-communs.org` pour accéder au serveur `mother`
|
||||
|
||||
### Procédure de connexion sans config
|
||||
|
||||
Le nouvel admin peut utiliser `ssh -i 'CLE_PRIV' -J cominfra@mother.libre-en-communs.org:222 admin666@localhost -p 222` pour accéder au serveur `mother`
|
||||
|
||||
### Accès aux machines virtuelles
|
||||
|
||||
Si besoin, l'administrateur d'infrastructure peut accéder aux machines virtuelles qui tournent sur les serveurs, et ce depuis le compte `admin666` de n'importe quel serveur. Il suffira d'utiliser la commande `ssh <nom de machine>`.
|
||||
|
||||
Par exemple, pour accéder à la machine `dns` : `ssh dns`
|
||||
|
|
@ -1,23 +1,19 @@
|
|||
## Accès aux machines virtuelles de l'infrastructure
|
||||
|
||||
### Configuration SSH côté infra
|
||||
### Configuration SSH serveur
|
||||
|
||||
En règle générale, l'accès aux machines virtuelles ne se fait pas directement. Il faut passer par `mother` ou `aunt`.
|
||||
En règle générale, l'accès aux machines virtuelles ne se fait pas directement. Il faut passer par une machine physique.
|
||||
Pour qu'un nouvel administrateur puisse accéder à des machines, il faut :
|
||||
|
||||
- Sur `mother` ou `aunt`, ajouter la clé publique (ssh) du nouvel admin dans `/home/cominfra/.ssh/authorized_keys`
|
||||
- Sur la machine physique hypervisant la machine, ajouter la clé publique (ssh) du nouvel admin dans `/home/cominfra/.ssh/authorized_keys`
|
||||
|
||||
- Sur chaque machine virtuelle concernée, ajouter la clé publique (ssh) du nouvel admin dans `/home/admin666/.ssh/authorized_keys`
|
||||
|
||||
Note : en IPV6, la connexion directe peut être possible. A voir au cas par cas.
|
||||
|
||||
**Attention** : les noms de machines virtuelles de Chalec contiennent ".chalec.org" en suffixe.
|
||||
Note : en IPV6, bien qu'en règle générale la connexion directe soit désactivée, elle peut être autorisée au cas par cas.
|
||||
|
||||
### Configuration SSH client
|
||||
|
||||
Soit en passant par `mother`
|
||||
|
||||
host mother.libre-en-communs.org
|
||||
host machine_physique.libre-en-communs.org
|
||||
User cominfra
|
||||
Port 222
|
||||
SendEnv GIT_AUTHOR_NAME GIT_AUTHOR_EMAIL
|
||||
|
|
@ -26,33 +22,13 @@ Soit en passant par `mother`
|
|||
User admin666
|
||||
Hostname %h
|
||||
Port 22
|
||||
ProxyJump mother.libre-en-communs.org
|
||||
ProxyJump machine_physique.libre-en-communs.org
|
||||
SendEnv GIT_AUTHOR_NAME GIT_AUTHOR_EMAIL
|
||||
|
||||
host *.chalec.org
|
||||
User admin666
|
||||
Port 22
|
||||
ProxyJump mother.libre-en-communs.org
|
||||
SendEnv GIT_AUTHOR_NAME GIT_AUTHOR_EMAIL
|
||||
|
||||
Ou bien en passant par `aunt`
|
||||
|
||||
host aunt.libre-en-communs.org
|
||||
User cominfra
|
||||
Port 223
|
||||
SendEnv GIT_AUTHOR_NAME GIT_AUTHOR_EMAIL
|
||||
|
||||
match host *.a-lec.org
|
||||
User admin666
|
||||
Hostname %h
|
||||
Port 22
|
||||
ProxyJump aunt.libre-en-communs.org
|
||||
SendEnv GIT_AUTHOR_NAME GIT_AUTHOR_EMAIL
|
||||
|
||||
host *.chalec.org
|
||||
User admin666
|
||||
Port 22
|
||||
ProxyJump aunt.libre-en-communs.org
|
||||
ProxyJump machine_physique.libre-en-communs.org
|
||||
SendEnv GIT_AUTHOR_NAME GIT_AUTHOR_EMAIL
|
||||
|
||||
Pour fixer les variables Git directement dans la conf, ajouter un `SetEnv` avant `SendEnv` :
|
||||
|
|
@ -60,8 +36,6 @@ Pour fixer les variables Git directement dans la conf, ajouter un `SetEnv` avant
|
|||
SetEnv GIT_AUTHOR_NAME="Moi" GIT_AUTHOR_EMAIL="moncourriel"
|
||||
```
|
||||
|
||||
Note : avoir les deux configurations peut être utile en cas de panne de l'un ou l'autre des serveurs.
|
||||
|
||||
|
||||
### Procédure de connexion avec config dans ~/.ssh/config
|
||||
|
||||
|
|
@ -71,6 +45,6 @@ Le nouvel admin n'a plus qu'à utiliser `ssh NOM_DE_VM.a-lec.org` pour accéder
|
|||
|
||||
Le nouvel admin peut utiliser au choix :
|
||||
|
||||
- `ssh -i 'CLE_PRIV' -J cominfra@mother.libre-en-communs.org:222 admin666@NOM_DE_VM.a-lec.org -p 22`
|
||||
- `ssh -i 'CLE_PRIV' -J cominfra@machine_physique.libre-en-communs.org:222 admin666@NOM_DE_VM.a-lec.org -p 22`
|
||||
|
||||
- `ssh -i 'CLE_PRIV' -J cominfra@aunt.libre-en-communs.org:223 admin666@NOM_DE_VM.a-lec.org -p 22`
|
||||
- `ssh -i 'CLE_PRIV' -J cominfra@machine_physique.libre-en-communs.org:223 admin666@NOM_DE_VM.a-lec.org -p 22`
|
||||
|
|
|
|||
|
|
@ -2,39 +2,41 @@
|
|||
|
||||
Le but est d'intégrer une nouvelle machine physique dans le SI.
|
||||
|
||||
Configurer la machine :
|
||||
- installer une Debian stable ;
|
||||
- premier compte : admin666,
|
||||
- la mettre à jour ;
|
||||
|
||||
Remplacer le noyau par Linux-libre-lts :
|
||||
- TODO
|
||||
## Configurer la machine
|
||||
- installer une Debian stable, branche main ;
|
||||
- créer le sudoer, sans mot de passe, authentification ssh clé publique : admin666,
|
||||
- remplacer le noyau par Linux-libre-lts à l'aide du [tutoriel de la FSFLA](https://www.fsfla.org/ikiwiki/selibre/linux-libre/freesh.en.html).
|
||||
|
||||
|
||||
Installer les paquets de base :
|
||||
## Installer les paquets de base
|
||||
```
|
||||
sudo apt install etckeeper mollyguard tig lm-sensors fancontrol screen emacs-nox vrms needrestart iotop htop curl ncdu iptraf tig unzip
|
||||
```
|
||||
|
||||
Mettre l'IPV6 statique à l'image de l'IPV4 choisie :
|
||||
- éditer ̀`/etc/network/interfaces`.
|
||||
_NB: penser à configurer fancontrol ensuite._
|
||||
|
||||
Nommer la machine :
|
||||
## Paramétrage réseau
|
||||
|
||||
Il faut corriger l'IPV6 statique à l'image de l'IPV4 choisie en éditant
|
||||
̀`/etc/network/interfaces`.
|
||||
|
||||
On doit aussi nommer la machine :
|
||||
```
|
||||
sudo hostnamectl set-hostname NOM
|
||||
sudo hostnamectl set-hostname NOM@DOMAINE
|
||||
```
|
||||
|
||||
Configurer le courriel :
|
||||
- TODO
|
||||
|
||||
|
||||
Configuration du routage :
|
||||
- aller sur https://routeur.libre-en-communs.org/cgi-bin/luci/admin/network/dhcp
|
||||
On configure ensuite le routage :
|
||||
- aller sur https://routeur.libre-en-communs.org/cgi-bin/luci/admin/network/dhcp ;
|
||||
- onglet Static Leases, bouton Add :
|
||||
- Hostname : nom de PM en domaine,
|
||||
- MAC : dispo sur la machine,
|
||||
- IPv4 : choisir entre :
|
||||
- un 192.168.0.x pour infra générale (si pas un service que des commissions vont utiliser),
|
||||
- un 192.168.1.x pour infra,
|
||||
- un 192.168.2.x pour Chalec,
|
||||
- Hostname : nom de PM en domaine ;
|
||||
- MAC : dispo sur la machine ;
|
||||
- IPv4 : choisir une 192.168.0.x (réservé infra générale, pour les machines physiques).
|
||||
- valider les changements.
|
||||
|
||||
## Configurer le courriel
|
||||
|
||||
Il faut installer postfix en mode satellite et le faire envoyer les courriels vers mail.a-lec.org.
|
||||
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -2,42 +2,43 @@
|
|||
|
||||
- Creation de la VM par clonage de generic ou generic.chalec.org
|
||||
|
||||
- Aller sur https://routeur.libre-en-communs.org/cgi-bin/luci/admin/network/dhcp
|
||||
- Aller sur la page de configuration web du routeur du site concerné, dans la section
|
||||
`Network > DHCP` :
|
||||
|
||||
+ Onglet Static Leases, bouton Add
|
||||
+ Onglet `Static Leases`, bouton `Add` ;
|
||||
|
||||
- Hostname : nom de VM en domaine
|
||||
- `Hostname` : nom de VM ;
|
||||
|
||||
- MAC : dispo dans virt-manager
|
||||
- `MAC` : insérer celui dispo dans virt-manager ;
|
||||
|
||||
|
||||
- IPv4 : choisir entre :
|
||||
- `IPv4` : choisir entre :
|
||||
|
||||
+ un 192.168.0.x pour infra générale
|
||||
+ un 192.168.0.x pour infra générale (par exemple de la supervision ou du DNS) ;
|
||||
|
||||
+ un 192.168.1.x pour infra
|
||||
+ un 192.168.1.x pour infra ;
|
||||
|
||||
+ un 192.168.2.x pour chalec
|
||||
+ un 192.168.2.x pour chalec.
|
||||
|
||||
+ Valider les changements
|
||||
+ Valider les changements.
|
||||
|
||||
|
||||
- sudo virsh console NOM_DE_VM
|
||||
- Utiliser `sudo virsh console NOM_DE_VM`.
|
||||
|
||||
+ login = admin666
|
||||
+ Utiliser le `login` admin666 (pas de mot de passe) ;
|
||||
|
||||
+ sudo nano /etc/network/interfaces
|
||||
+ sudo nano /etc/network/interfaces.
|
||||
|
||||
- Changer l'IPv6 statique à l'image de l'IPv4 choisie
|
||||
- Changer l'IPv6 statique à l'image de l'IPv4 choisie ;
|
||||
|
||||
- Changer les hostnames (chaque nano signifie qu'il faut remplacer le generic ou generic.chalec.org par NOM_DE_VM)
|
||||
- Changer les hostnames (chaque nano signifie qu'il faut remplacer le generic ou generic.chalec.org par NOM_DE_VM).
|
||||
|
||||
+ sudo hostnamectl set-hostname NOM_DE_VM
|
||||
+ `sudo hostnamectl set-hostname NOM_DE_VM`
|
||||
|
||||
+ sudo nano /etc/postfix/virtual && sudo postmap /etc/postfix/virtual
|
||||
+ `sudo nano /etc/postfix/virtual && sudo postmap /etc/postfix/virtual`
|
||||
|
||||
+ sudo nano /etc/mailname
|
||||
+ `sudo nano /etc/mailname`
|
||||
|
||||
+ sudo nano /etc/postfix/main.cf && sudo postfix reload
|
||||
+ `sudo nano /etc/postfix/main.cf && sudo postfix reload`
|
||||
|
||||
+ sudo reboot
|
||||
+ `sudo reboot`
|
||||
|
|
|
|||
|
|
@ -1,30 +1,32 @@
|
|||
# Migration de machines virtuelles entre machines physiques
|
||||
# Migration de machines virtuelles entre machines physiques d'un même site
|
||||
|
||||
Il y a plusieurs méthodes de migration de machines virtuelles en mother et aunt
|
||||
Il y a plusieurs méthodes de migration de machines virtuelles d'un même site.
|
||||
|
||||
Nous prenons ici l'exemple des machines `mother` et `aunt` du site `Le Parc`.
|
||||
|
||||
## Migration "normale" d'une machine par son nom
|
||||
|
||||
Pour migrer une machine de mother à aunt :
|
||||
Pour migrer une machine de `mother` à `aunt` :
|
||||
|
||||
/opt/sharedfs/outils/migrate_to_aunt.sh NOM_DE_VM
|
||||
|
||||
Pour migrer une machine de aunt à mother :
|
||||
Pour migrer une machine de `aunt` à `mother` :
|
||||
|
||||
/opt/sharedfs/outils/migrate_to_mother.sh NOM_DE_VM
|
||||
|
||||
## Migration "normale" d'un groupe de machine par nombre
|
||||
|
||||
Pour migrer X machines de mother vers aunt :
|
||||
Pour migrer X machines de `mother` vers `aunt` :
|
||||
|
||||
/opt/sharedfs/outils/migrate_many_to_aunt.sh X
|
||||
|
||||
Pour migrer X machines de aunt vers mother :
|
||||
Pour migrer X machines de `aunt` vers `mother` :
|
||||
|
||||
/opt/sharedfs/outils/migrate_many_to_mother.sh X
|
||||
|
||||
## Migration d'urgence (P2P) de aunt vers mother (sans DRBD)
|
||||
## Migration d'urgence (P2P) de `aunt` vers `mother` (sans DRBD)
|
||||
|
||||
Pour migrer une machine de aunt vers mother lorsque DRBD ne fonctionne pas :
|
||||
Pour migrer une machine de `aunt` vers `mother` lorsque DRBD ne fonctionne pas :
|
||||
|
||||
/opt/sharedfs/outils/migrate_to_mother_p2p.sh NOM_DE_VM
|
||||
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@
|
|||
|
||||
Il faut annoncer le downtime sur isengard (cf [la procédure dédiée](supervision.md#activation-dun-downtime)).
|
||||
|
||||
## Migrer les machines virtuelles présentes sur l'hôte physique vers un autre hôte
|
||||
## Migrer les machines virtuelles présentes sur l'hôte physique vers un autre hôte, s'il y a lieu
|
||||
|
||||
Utiliser les instructions de la [procédure dédiée](migration_vm.md).
|
||||
|
||||
|
|
@ -18,7 +18,7 @@ Lancer le redémarrage avec :
|
|||
|
||||
*Ne pas utiliser la commande shutdown sauf nécessité absolue*
|
||||
|
||||
## Vérifier l'état de DRBD après redémarrage
|
||||
## Vérifier l'état de DRBD après redémarrage, s'il y a lieu
|
||||
|
||||
Avec la commande :
|
||||
|
||||
|
|
@ -26,7 +26,7 @@ Avec la commande :
|
|||
|
||||
Et vérifier que l'état est _cs:Connected ro:Primary/Primary ds:UpToDate/UpToDate_
|
||||
|
||||
## Monter la partition DRBD
|
||||
## Monter la partition DRBD, s'il y a lieu
|
||||
|
||||
Avec la commande :
|
||||
|
||||
|
|
@ -40,6 +40,6 @@ Avec :
|
|||
|
||||
en vérifiant que le statut est _running_ et qu'aucun job n'est en fail.
|
||||
|
||||
## Migrer les machines virtuelles depuis l'autre hôte vers le présent hôte physique à présent prêt
|
||||
## Migrer les machines virtuelles depuis l'autre hôte, s'il y a lieu
|
||||
|
||||
Utiliser les instructions de la [procédure dédiée](migration_vm.md).
|
||||
|
|
|
|||
Loading…
Reference in New Issue