gratifiant > linux.debian.user.french

Fabrice Delvallée (14/01/2019, 07h30)
Bonjour

J'ai le projet d'installer un serveur dans mon lycée pour :

- héberger une plate-forme d'apprentissage en ligne (moodle)

- créer à la volée des images dockers contenant des notebooks python

je partirai sur :

- 2x256GO SSD en raid1 pour l'os

- 2x1TO SATA en raid1+LVM pour les données

- 64Go de mémoire

Je suis un peu perdu pour le partitionnement :(

faut-il mettre aussi LVM sur les SSD ? J'ai cru comprendre que grub

n'est pas compatible LVM, dans ce cas il me faut une partition /boot

séparée.

Merci pour votre aide
Florian Blanc (14/01/2019, 14h10)
Bonjour,
Premièrement je te conseillerais d'utiliser Proxmox tu installer le kernel
sans problème à partir de Debian :

Avant çà pour ce qui est de ton partitionnement :
Concernant les SSD
3 partitions primaire :
(même taille sur les deux disques)
Une de environs 500Mo pour ( /boot )
Une de environs 4096Mo pour ( swap )
Le reste pour ( / )
Tu configure seulement le swap et / en raid1
Tu encrypt ton swap et / via l'interface d'installation.
Après tu peux utiliser LVM mais je trouve pas nécessaire.
ensuite "grub-install /dev/sda1" "grub-install /dev/sda2"

Pour tes disques 1To tu peux faire raid1, encrypted, LVM.

L'avantage de proxmox est que ça te permettra des backups assez facilement
et tu pourras également isoler tes services.
Enfin, je te laisse découvrir.
Tu peux faire une VM Freenas utilisant tes disques de 1To.
à toi de voir.

Amicalement.

Le lun. 14 janv. 2019 à 06:24, Fabrice Delvallée <fabrice.delvallee>
a écrit :
[..]
Pascal Hambourg (14/01/2019, 21h50)
Le 14/01/2019 à 13:09, Florian Blanc a écrit :
> 3 partitions primaire :
> (même taille sur les deux disques)
> Une de environs 500Mo pour ( /boot )
> Une de environs 4096Mo pour ( swap )
> Le reste pour ( / )
> Tu configure seulement le swap et / en raid1


Pourquoi pas /boot ?

> Tu encrypt ton swap et / via l'interface d'installation.
> Après tu peux utiliser LVM mais je trouve pas nécessaire.


L'avantage de LVM est qu'on peut mettre tous les volumes logiques dans
un unique volume chiffré, donc une seule passphrase à taper au démarrage.

> ensuite "grub-install /dev/sda1" "grub-install /dev/sda2"


Il y a un léger problème : si /boot n'est pas en RAID, alors il est sur
un seul des deux disques et si ce disque tombe alors le GRUB présent sur
le disque restant sans /boot ne pourra pas démarrer le système. Pour
démarrer avec l'autre disque seul il faudrait synchroniser le contenu de
sa partition de 500 Mo avec le contenu de /boot. C'est presque du RAID 1
mais à gérer manuellement tout en maintenant les légères différences
dans les deux grub.cfg (UUID). Bref, /boot en RAID 1 serait beaucoup
plus simple et fiable, et GRUB sait le gérer.
Pascal Hambourg (14/01/2019, 22h00)
Le 14/01/2019 à 06:24, Fabrice Delvallée a écrit :
> faut-il mettre aussi LVM sur les SSD ?


Oui, j'utiliserais LVM sur les SSD pour le système, mais dans un VG
distinct des disques durs. On ne mélange pas les torchons et les
serviettes. Mieux vaut utiliser LVM et ne pas en avoir besoin que
l'inverse. Ses fonctionnalités (redimensionnement à chaud, snapshots...)
peuvent être utiles un jour.

> J'ai cru comprendre que grub
> n'est pas compatible LVM, dans ce cas il me faut une partition /boot
> séparée.


GRUB 2, la version actuelle de GRUB, est compatible avec LVM, le RAID
logiciel (sauf le RAID linear, bizarrement) et leurs combinaisons. Donc
une partition ou un ensemble RAID séparé pour /boot n'est pas
indispensable. Mais on peut préférer garder un /boot séparé hors LVM
pour intervenir plus facilement en cas de problème avec LVM (on aura au
moins le shell de secours de l'initramfs).
Florian Blanc (15/01/2019, 01h50)
à chaque mise à jour du kernel "grub-install /dev/sda1" "grub-install
/dev/sdb1" (corrigé) c'est pas la mort.
mais as you want fais toi plaisir mon ami.

Le lun. 14 janv. 2019 à 20:59, Pascal Hambourg <pascal> a
écrit :
[..]
Pascal Hambourg (15/01/2019, 08h30)
Le 15/01/2019 à 00:46, Florian Blanc a écrit :
> à chaque mise à jour du kernel "grub-install /dev/sda1" "grub-install
> /dev/sdb1" (corrigé) c'est pas la mort.


Je suppose que cela répond à l'objection que j'ai formulée à l'encontre
de ton précédent message.

Primo, il n'est pas nécessaire d'exécuter grub-install à chaque mise à
jour du noyau. GRUB n'est pas LILO. Il faut seulement mettre à jour le
fichier de configuration grub.cfg avec grub-mkconfig ou update-grub.

Secundo, l'exécution de grub-install sur d'autres disques lors d'une
mise à jour du paquet grub-pc peut être automatisée dans la
configuration du paquet avec dpkg-reconfigure.

Tertio, le problème n'est pas là. grub-install n'installe qu'une partie
de GRUB sur le disque spécifié. L'autre partie (dont le fichier de
configuration du menu de démarrage), ainsi que le noyau et l'initramfs,
sont dans /boot. Si le contenu de /boot n'est pas en RAID, donc sur un
seul disque, alors la défaillance de ce disque entraîne l'impossibilité
de démarrer le système, GRUB s'arrêtant sur le shell de secours limité
"grub rescue>". Et toute solution à base de deux partitions /boot serait
plus compliquée que /boot en RAID.
Pierre L. (15/01/2019, 10h00)
Bonjour à tous,

Le 15/01/2019 à 07:29, Pascal Hambourg a écrit :
> Le 15/01/2019 à 00:46, Florian Blanc a écrit :
> Je suppose que cela répond à l'objection que j'ai formulée à
> l'encontre de ton précédent message.
> Primo, il n'est pas nécessaire d'exécuter grub-install àchaque mise à
> jour du noyau. GRUB n'est pas LILO. Il faut seulement mettre à jour le
> fichier de configuration grub.cfg avec grub-mkconfig ou update-grub.

Humm, j'ai cette impression que la commande update-grub, suite à mise à
jour de kernel par exemple, ne mettra à jour que celui sur lequel la
machine a booté ?
En gros, si c'est GRUB2 qui est sur /dev/sda qui a lancé Debian, cette
commande ne mettra pas à jour l'amorçage dans /dev/sdb
Ou alors je suis à coté de la plaque ? Oui ca relève encore un peu du
mystique pour le moment, car pas encore pris le temps de me pencher sur
le sujet ;)

J'avoue que c'est pour cela que j'avais aussi ce petit workaround comme
Florian pour forcer aussi rapidement la mise à jour coté /dev/sdb...

> Secundo, l'exécution de grub-install sur d'autres disques lors d'une
> mise à jour du paquet grub-pc peut être automatisée dansla
> configuration du paquet avec dpkg-reconfigure.

C'est donc ici qu'il serait intéressant de cocher les 2 disques /dev/sda
et /dev/sdb afin d'avoir ce GRUB2 qui se mettrait à jour comme tu nous
le dis précédemment ?
(première image trouvée sur le net... histoire d'illustrer)


Et donc sur une installation déjà faite, un dpkg-reconfigure grub-pc
pourrait remédier à ce manque et automatiser cette MAJ de GRUB2sur les
2 disques à chaque update de kernel. Humm humm, c'est bon ca ! (si j'ai
bien compris le principe ?)
Daniel Huhardeaux (15/01/2019, 10h10)
Le 15/01/2019 à 08:52, Pierre L. a écrit :

[...]
[..]
> pourrait remédier à ce manque et automatiser cette MAJ de GRUB2 sur les
> 2 disques à chaque update de kernel. Humm humm, c'est bon ca ! (si j'ai
> bien compris le principe ?)


Sauf que le point crucial qu'a indiqué Pascal est que grub a besoin du
fichier de config qui est dans /boot. Si cette partition est sur
/dev/sda et non /dev/sdb (pas de Raid) tu as beau mettre ce que tu veux
sur /dev/sdb il ne démarrera pas si /dev/sda est absent.

Ce que tu dis est vrai si /boot *est* en Raid.
Pierre L. (15/01/2019, 10h50)
Oui effectivement, c'était sous-entendu dans mes propos !
Un /boot en miroir devra être identique sur chaque disque.

La vision dans sa globalité est donc celle-ci, à noter donc !

Oui j'avais un vague souvenir que la chose qui pouvait poser problème en
RAID1 était justement l'amorçage, ici géré par GRUB, car les secteurs
d'amorce ne sont pas en miroir... et c'est bien la seule chose qui n'est
pas "dupliquée"...

Le 15/01/2019 à 09:06, Daniel Huhardeaux a écrit :
Florian Blanc (15/01/2019, 12h00)
ah yes my /boot is in raid1 sorry :/

root@ams1:/home/panpansh# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
loop0 7:0 0 100G 0 loop
loop1 7:1 0 30G 0 loop
loop2 7:2 0 30G 0 loop
loop3 7:3 0 30G 0 loop
loop4 7:4 0 100G 0 loop
sda 8:0 0 477G 0 disk
??sda1 8:1 0 299M 0 part
? ??md0 9:0 0 298.7M 0 raid1 /boot
??sda2 8:2 0 3.8G 0 part
? ??md1 9:1 0 3.8G 0 raid1
? ??md1_crypt 253:1 0 3.8G 0 crypt [SWAP]
??sda3 8:3 0 472.9G 0 part
??md2 9:2 0 472.7G 0 raid1
??md2_crypt 253:0 0 472.7G 0 crypt /
sdb 8:16 0 477G 0 disk
??sdb1 8:17 0 299M 0 part
? ??md0 9:0 0 298.7M 0 raid1 /boot
??sdb2 8:18 0 3.8G 0 part
? ??md1 9:1 0 3.8G 0 raid1
? ??md1_crypt 253:1 0 3.8G 0 crypt [SWAP]
??sdb3 8:19 0 472.9G 0 part
??md2 9:2 0 472.7G 0 raid1
??md2_crypt 253:0 0 472.7G 0 crypt /

I have a small buffer :p

Le mar. 15 janv. 2019 à 09:44, Pierre L. <petrus> a écrit :
[..]
Florian Blanc (15/01/2019, 12h20)
"dpkg-reconfigure grub-pc" merci c'est juste parfait

Le mar. 15 janv. 2019 à 10:55, Florian Blanc <florian.blanc.adm>
a écrit :
[..]
Pascal Hambourg (15/01/2019, 21h40)
Le 15/01/2019 à 08:52, Pierre L. a écrit :
> Humm, j'ai cette impression que la commande update-grub, suite à mise à
> jour de kernel par exemple, ne mettra à jour que celui sur lequel la
> machine a booté ?


Pas du tout. update-grub se moque bien de savoir quel noyau est mis à
jour. Il recense tous les noyaux présents dans /boot et regénère
entièrement un nouveau fichier de configuration /boot/grub/grub.cfg
incluant ces noyaux.

Par défaut depuis GRUB 2.x le noyau de version la plus élevée est dans
le menu principal et les autres sont dans un sous-menu "options
avancées". Il est possible de revenir au comportement sans sous-menu des
versions précédentes (1.9x) en ajoutant l'option suivante dans
/etc/default/grub :

GRUB_DISABLE_SUBMENU=y

> En gros, si c'est GRUB2 qui est sur /dev/sda qui a lancé Debian, cette
> commande ne mettra pas à jour l'amorçage dans /dev/sdb


update-grub se contente de générer le fichier de configuration
/boot/grub/grub.cfg et se moque bien de savoir sur quel disque est
installé le chargeur GRUB qui va le lire.

>> Secundo, l'exécution de grub-install sur d'autres disques lors d'une
>> mise à jour du paquet grub-pc peut être automatisée dans la
>> configuration du paquet avec dpkg-reconfigure.

> C'est donc ici qu'il serait intéressant de cocher les 2 disques /dev/sda
> et /dev/sdb afin d'avoir ce GRUB2 qui se mettrait à jour comme tu nous
> le dis précédemment ?


Oui.

> Et donc sur une installation déjà faite, un dpkg-reconfigure grub-pc
> pourrait remédier à ce manque et automatiser cette MAJ de GRUB2 sur les
> 2 disques à chaque update de kernel.


Non. Je répète que GRUB n'est pas LILO, il n'est pas nécessaire ni utile
de le réinstaller (avec grub-install) à chaque mise à jour de noyau.
GRUB ne doit être réinstallé que lors d'une mise à jour des paquets
grub-*. C'est le fichier de configuration grub.cfg qu'il faut regénérer
(avec update-grub) lorsqu'un noyau est ajouté ou supprimé. En principe
ce n'est pas nécessaire en cas de simple mise à jour de noyau, mais les
scripts de post-installation du noyau le font quand même.
Pierre L. (16/01/2019, 10h20)
Le 15/01/2019 à 20:33, Pascal Hambourg a écrit :
>> En gros, si c'est GRUB2 qui est sur /dev/sda qui a lancé Debian, cette
>> commande ne mettra pas à jour l'amorçage dans /dev/sdb

> update-grub se contente de générer le fichier de configuration
> /boot/grub/grub.cfg et se moque bien de savoir sur quel disque est
> installé le chargeur GRUB qui va le lire. Merci Pascal pour toutes ces précisions bien utiles.


J'avais en tête le souci de la MBR dans laquelle GRUB va se positionner
pour démarrer un système.
Cependant RAID1 ne duplique pas la MBR d'un disque sur un autre.
C'était dans ce cas où la magouille du mécréant que je suis était de
lancer un grub-install sur le 2ième disque, sinon celui-ci ne pourrait
démarrer seul (en cas de crash du 1ier).
Dans ce cas il parait effectivement intéressant d'utiliser ce
dpkg-reconfigure comme précédemment cité... yes yes.
Daniel Caillibaud (16/01/2019, 11h40)
Le 14/01/19 à 06:24, Fabrice Delvallée <fabrice.delvallee> a écrit :
> Bonjour
> J'ai le projet d'installer un serveur dans mon lycée pour :
> - héberger une plate-forme d'apprentissage en ligne (moodle)
> - créer à la volée des images dockers contenant des notebooks python
> je partirai sur :
> - 2x256GO SSD en raid1 pour l'os


L'OS n'a pas besoin de tout ça, 20Go sont amplement suffisant (modulo rmq
suivante).

> - 2x1TO SATA en raid1+LVM pour les données


Si tu as des dockers, tu as intérêt à avoir ton /var/lib/docker sur ssd. Si
c'est la même partition que l'OS il faut ajouter aux 20Go précédents la
taille des images (ça peut être gros).

Et si tu as des images qui manipulent de gros volumes de données, tu leur
monte un volume qui lui est sur le hd sata classique (ssd est aussi en
sata en général).

Je sais plus trop comment fonctionne docker, s'il peut ne conserver en
mémoire qu'une seule version des lib système lorsque les images ont le même
système que l'hôte, et si ça change qqchose que les images docker soient
sur la même partition que l'OS hôte ou pas.

> - 64Go de mémoire
> Je suis un peu perdu pour le partitionnement :(
> faut-il mettre aussi LVM sur les SSD ? J'ai cru comprendre que grub
> n'est pas compatible LVM, dans ce cas il me faut une partition /boot


D'autres ont déjà répondu, tu as intérêt à tout avoir sur lvm, c'est
autrement plus simple si ça doit évoluer (et pas tellement plus compliqué
sinon).

Je mettrais sur chaque ssd

- une partition mdadm pour /boot en raid1 (/dev/md1 par ex), hors lvm donc
directement partitionné en ext4 (ou ext2, suffisant pour /boot). Ne pas
être trop radin, prévoir quand même ~256Mo min pour pouvoir mettre
plusieurs noyaux (j'ai déjà installé avec ~50Mo et regretté ensuite).

- une partition pour le swap (taille à voir suivant l'usage, 2×10Go me
parait déjà très large, si tu as besoin de plus c'est qu'il y a un pb à
régler ailleurs)

- le reste dans une partition mdadm en raid1 (/dev/md2 par ex), qui servira
de pv pour lvm, que tu pourras donc découper comme tu veux (avec un lv
pour /, et d'autres lv pour des datas)

et sur les disques classiques un seul volume mdadm en raid1 (/dev/md3 par
ex), que tu utilise en pv lvm

notes
- certains préfèrent mettre le swap en raid1, deux fois moins rapide mais
plus sûr, à toi de voir. Amha le swap doit rester exceptionnel et doit
être le plus rapide possible car la machine souffre déjà quand y'en a
besoin, donc deux partitions natives filées au kernel dans /etc/fstab
(il fait du raid0), avec l'inconvénient que si un disque lâche pendant
que l'os utilise le swap ça va crasher le système (et l'avantage que le
swap est 2× plus rapide tout le reste du temps).

- pour mettre lvm en raid1, on utilise souvent un volume mdadm comme pv
pour lvm, mais tu peux te passer de mdadm : un pv sur sda et un autre
sur sdb, en disant à lvm de gérer le raid1 lors de la création des vg
(man vgcreate pour la syntaxe, ça permet d'avoir certains lv en raid1 et
d'autres en raid0).

- si tu veux chiffrer les partitions (en général on s'en passe sur un
serveur web car on préfère qu'il reboot tout seul sans devoir se
connecter pour saisir la passphrase), la logique est différente, et ce
serait plus logique de mettre le swap dans un volume chiffré aussi.
Stephane Ascoet (16/01/2019, 12h50)
Le 15/01/2019 à 20:33, Pascal Hambourg a écrit :
> En principe ce n'est pas nécessaire en cas de simple mise à jour de
> noyau, mais les scripts de post-installation du noyau le font quand même.


Bonjour, parce qu'il est possible de mettre a jour un noyau sans monter
de version, hors cas d'une recompilation a la main???

Discussions similaires