Re: Partitionnement d'un serveur web

[Eric Degenetais]

bonjour,
Le lun. 21 janv. 2019 à 10:53, Daniel Caillibaud  a écrit 
:
>
> Le 17/01/19 à 23:44, Pascal Hambourg  a écrit :
> > > Je suis pas tout à fait d'accord, on peut vouloir du raid1 pour la
> > > sécurité des datas
> >
> > Le RAID ne sert pas à ça. Ce n'est pas une sauvegarde.
>
> Tu as raison, je me suis mal exprimé et ne pensais pas déclencher ce qui a
> suivi, je voulais dire :
Tu n'as pas été le seul déclencheur :) Je présente d'ailleurs mes
excuses à Pascal Hambourg pour le ton un peu vif de mes réponses.
>
>   On peut vouloir du raid1 pour sécuriser le service qui résiste alors à la
>   perte d'un disque, ça évite la longue interruption lié à la récupération
>   du dernier backup (et la perte des modifs effectuées depuis).
Je trouve pour ma part que cette discussion a été utile, et peut-être
pas seulement à moi. Sur certaines machines, réduire drastiquement la
quantité de données perdues peut avoir un intérêt (intérêt du RAID
mirroring).
Par ailleurs, effectivement, ça ne remplace pas une sauvegarde en cas
d'incident entraînant la destruction simultanée des deux disques, ou
la corruption des données.
Les deux sont complémentaires (pour information je fais chez moi, dans
un contexte différent du serveur, de la sauvegarde historisée. Là la
problématique du volume de données perdu entre la sauvegarde et le
crash est moins aigüe : quand j'ai ajouté un contenu particulièrement
critique je lance immédiatement une sauvegarde).
> donc pas "sécurité des datas" mais plutôt qqchose comme "résilience des
> données locales".
>
> --
> Daniel
>
> Il y a trois sortes de mathématiciens : ceux qui savent
> compter et ceux qui ne savent pas.
>

Re: Partitionnement d'un serveur web

[Daniel Caillibaud]

Le 17/01/19 à 20:51, Pascal Hambourg  a écrit :
> >> il faut exécuter update-grub pour mettre à
> >> jour le menu de démarrage et pouvoir démarrer avec ce noyau.  
> > 
> > Tu es sûr ?  
> 
> Plutôt, oui. grub.cfg ne se met pas à jour tout seul.

Évidemment, toutes mes confuses, j'ai lu install et pas update :-/

> > J'ai un gros doute, ça fait longtemps que je l'ai pas fait mais je pense
> > n'avoir jamais relancé de update-grub (c'est p'tet dpkg-postinstall qui
> > s'en est chargé).  
> 
> Je n'ai pas écrit que c'était l'utilisateur qui devait le faire. En 
> l'occurrence, c'est un script installé par grub-{pc,efi-amd64...} dans 
> /etc/kernel/postinst.d/.

Oui, et ça se voit bien à chaque install / mise à jour de noyau, dpkg dit
ce qu'il fait, lancer update-grub, qui lui va lister les noyaux qu'il trouve
(pour les mettre dans le grub.cfg).


-- 
Daniel

Grâce (coup de) : Balle de charité.
Serge Mirjean

Re: Partitionnement d'un serveur web

[Daniel Caillibaud]

Le 17/01/19 à 23:44, Pascal Hambourg  a écrit :
> > Je suis pas tout à fait d'accord, on peut vouloir du raid1 pour la
> > sécurité des datas  
> 
> Le RAID ne sert pas à ça. Ce n'est pas une sauvegarde.

Tu as raison, je me suis mal exprimé et ne pensais pas déclencher ce qui a
suivi, je voulais dire :

  On peut vouloir du raid1 pour sécuriser le service qui résiste alors à la
  perte d'un disque, ça évite la longue interruption lié à la récupération
  du dernier backup (et la perte des modifs effectuées depuis).

donc pas "sécurité des datas" mais plutôt qqchose comme "résilience des
données locales".

-- 
Daniel

Il y a trois sortes de mathématiciens : ceux qui savent 
compter et ceux qui ne savent pas.

Re: Partitionnement d'un serveur web

[Pascal Hambourg]

Le 19/01/2019 à 09:48, Eric Degenetais a écrit :

C'est bien de paraphraser ce que je dis... le raid mirroring ne remplace
pas une sauvegarde externe


Ni externe ni interne. Le RAID ne remplace pas une sauvegarde. Point.
Exemple : le RAID ne protège pas contre la perte de données résultant 
d'un effacement accidentel par un rm malencontreux. Une sauvegarde, si. 
Conclusion : le RAID n'est pas une sauvegarde.



mais il réduit la perte de données provoquée par
la perte d'un disque. Donc il participe bien à la protection des données,
même s'il faut appliquer d'autres solutions complémentaires.


Voilà : le RAID ne suffit pas. Il faut autre chose qui s'appelle une 
solution de sauvegarde. Le RAID peut éventuellement faire partie d'une 
solution de sauvegarde, mais ne constitue pas une sauvegarde en tant que 
tel.

Re: Partitionnement d'un serveur web

[Eric Degenetais]

C'est bien de paraphraser ce que je dis... le raid mirroring ne remplace
pas une sauvegarde externe mais il réduit la perte de données provoquée par
la perte d'un disque. Donc il participe bien à la protection des données,
même s'il faut appliquer d'autres solutions complémentaires.
PS : j'avais bien lu Wikipedia, je m'attendais à un autre genre de
contre-argument.

Éric Dégenètais

Le ven. 18 janv. 2019 23:58, Pascal Hambourg  a
écrit :

> Le 18/01/2019 à 23:37, Eric Degenetais a écrit :
> >
> > Le miroring ne serait pas une sauvegarde ? J'avoue avoir du mal à
> > comprendre.
>
> Un peu de lecture :
> <
> https://fr.wikipedia.org/wiki/RAID_(informatique)#Les_possibilit%C3%A9s_et_les_limites_du_RAID
> >
>
> > Qu'il ne remplace pas une sauvegarde externe, OK, mais à mon
> > sens il minimise quand même pas mal la perte de donnée si seul un disque
> > est détruit, et non toute la machine.
>
> Le RAID protège seulement contre le risque de défaillance d'un disque.
> Il y a bien d'autres risques de perte de données (cf. lien ci-dessus).
>
>

Re: Partitionnement d'un serveur web

[Pascal Hambourg]

Le 18/01/2019 à 23:37, Eric Degenetais a écrit :


Le miroring ne serait pas une sauvegarde ? J'avoue avoir du mal à
comprendre.


Un peu de lecture :



Qu'il ne remplace pas une sauvegarde externe, OK, mais à mon
sens il minimise quand même pas mal la perte de donnée si seul un disque
est détruit, et non toute la machine.


Le RAID protège seulement contre le risque de défaillance d'un disque. 
Il y a bien d'autres risques de perte de données (cf. lien ci-dessus).

Re: Partitionnement d'un serveur web

[Eric Degenetais]

Le jeu. 17 janv. 2019 23:44, Pascal Hambourg  a
écrit :

> Le 17/01/2019 à 11:00, Daniel Caillibaud a écrit :
> > Le 16/01/19 à 22:10, Pascal Hambourg  a écrit :
> >> Quand on met de la redondance, ce n'est pas pour la vitesse. C'est pour
> >> la disponibilité. Si l'objectif est que le système continue à
> >> fonctionner malgré la perte d'un disque, alors un swap sans redondance
> >> ne garantit pas cette disponibilité et va à l'encontre de l'objectif. Si
> >> l'objectif n'est pas la disponibilité, alors on n'a pas besoin de RAID 1
> >> ni pour le swap ni pour le reste.
> >
> > Je suis pas tout à fait d'accord, on peut vouloir du raid1 pour la
> sécurité
> > des datas
>
> Le RAID ne sert pas à ça. Ce n'est pas une sauvegarde.
>

Le miroring ne serait pas une sauvegarde ? J'avoue avoir du mal à
comprendre. Qu'il ne remplace pas une sauvegarde externe, OK, mais à mon
sens il minimise quand même pas mal la perte de donnée si seul un disque
est détruit, et non toute la machine.

>
> > mais vouloir du swap aussi rapide que possible, quitte à risquer
> > un crash système si un disque lâche pendant l'utilisation du swap.
>
> Le RAID 0 n'est plus rapide que le RAID 1 qu'en écriture et en lecture
> séquentielle. En lecture aléatoire, le RAID 1 utilise tous les disques
> en parallèle. L'usage typique du swap fait-il plutôt des accès
> séquentiels ou aléatoires ? Si l'utilisation le justifie, on peut
> augmenter la vitesse en lecture séquentielle sans sacrifier la
> redondance avec du RAID 10.
>
> > Dans mes usages, quand ça commence à swapper ça sent mauvais, si c'est
> > juste une surcharge passagère ça passe (un gros batch bien goinfre,
> > plusieurs VMs qui consomment plus que leur moyenne simultanément mais pas
> > trop longtemps), mais sinon ça part vite en vrille (effet domino, ça swap
> > car le serveur arrive pas à fournir => les requêtes sont plus lentes =>
> > elles s'empile davantage => le serveur arrive encore moins à fournir).
> >
> > C'est d'ailleurs un argument pour ne pas mettre de swap du tout, pour que
> > les oomkill arrivent dès que ça sature sans attendre l'agonie du système
> > (même si ça devrait jamais arriver, avec un dimensionnement correct en
> > amont).
>
> Avec deux inconvénients non négligeables : le système ne tolère pas les
> surcharges passagères, et on ne choisit pas les processus à tuer, on
> doit faire confiance à l'OOM killer.
>
>

Re: Partitionnement d'un serveur web

[Étienne Mollier]

Bonsoir,

Pascal Hambourg, au 2019-01-18 :
> Le 17/01/2019 à 11:00, Daniel Caillibaud a écrit :
> > C'est d'ailleurs un argument pour ne pas mettre de swap du tout, pour que
> > les oomkill arrivent dès que ça sature sans attendre l'agonie du système
> > (même si ça devrait jamais arriver, avec un dimensionnement correct en
> > amont).
>
> Avec deux inconvénients non négligeables : le système ne
> tolère pas les surcharges passagères, et on ne choisit pas les
> processus à tuer, on doit faire confiance à l'OOM killer.

Au risque de paraître insensé, quitte à compter sur l'OOM killer
pour faire le ménage de manière efficace, autant configurer le
noyau pour déclencher un panic_on_oom, tout en redémarrant
immédiatement en cas de panic (option panic=-1 au boot, de
mémoire).  D'expérience, les tentatives de remises sur les rails
de machines ayant subit un OOM se sont souvent soldées par des
redémarrages au bout d'un temps déraisonnable, passé à se
gratter la tête essentiellement...

Certains systèmes peuvent être configurés pour ne pas autoriser
la sur-allocation de mémoire ; c'est la configuration par défaut
de l'OS au borsalino il me semble.  Dans ce cas, l'OOM killer
n'est jamais appelé car toute tentative de malloc au delà des
limites se solde par un pointeur nul et un errno réglé à ENOMEM,
voir malloc(3).  Si le service à assurer gère correctement cette
erreur lors de sa tentative d'allocation de mémoire, alors il
devient possible de remonter un message comme quoi la machine
est saturée, au lieu de commencer un nouveau traitement qui
aggraverait la situation.

Par défaut, Debian GNU/Linux est configuré pour faire de la
sur-allocation heuristique, d'où les appels à l'OOM killer en
cas de saturation de mémoire.  La documentation du noyau donne
un peu plus de détails à ce sujet :

https://www.kernel.org/doc/html/v4.19/vm/overcommit-accounting.html

Bien à vous,
-- 
Étienne Mollier 

Re: Partitionnement d'un serveur web

[Pascal Hambourg]

Le 17/01/2019 à 17:22, Stephane Ascoet a écrit :

Le 16/01/2019 à 22:10, Pascal Hambourg a écrit :


Attention : par défaut, le noyau attribue des priorités décroissantes
aux différents swaps et remplit entièrement chaque swap par ordre de
priorité. Pour distribuer les allocations entre plusieurs swaps, il faut
leur attribuer explicitement la même priorité positive avec l'option
--priority de swapon ou prio= de /etc/fstab.


Bonjour, oui, c'est l'information que j'ai aussi mais je constate sur 
mon GOBook un fonctionnement different avec certains fichiers de swap 
qu'il remplit en parallele malgre des priorites decroissantes :-o


Je n'observe pas cela sur ma machine quand j'active plusieurs swaps avec 
priorités par défaut.

Note : les fichiers de swap, c'est mal.

Oui car la version qui compte pour GRUB est la version "visible" 
présente dans les noms de fichiers de l'image du noyau 
vmlinuz-$version et de l'initramfs initrd.img-$version (qui sont 
repris dans grub.cfg), dans la sortie de uname -a pour le noyau actif 
dans le nom du paquet linux-image-*. Les mises à jour de sécurité du 
noyau sans changement de l'ABI ne modifient pas cette version. Bien 
sûr la véritable version source, présente dans la sortie de uname -v 
pour le noyau actif, change à chaque mise à jour.


Sur ma machine pro sous Devuan ascii uname -a donne:
Linux DSI-1310066 4.16.0-0.bpo.2-amd64 #1 SMP Debian 4.16.16-2~bpo9+1 
(2018-06-26) x86_64 GNU/Linux


Donc la version de MAJ de securite c'est le "9+1"?


Non, c'est 4.16.16-2~bpo9+1.

Re: Partitionnement d'un serveur web

[Pascal Hambourg]

Le 17/01/2019 à 11:00, Daniel Caillibaud a écrit :

Le 16/01/19 à 22:10, Pascal Hambourg  a écrit :

Quand on met de la redondance, ce n'est pas pour la vitesse. C'est pour
la disponibilité. Si l'objectif est que le système continue à
fonctionner malgré la perte d'un disque, alors un swap sans redondance
ne garantit pas cette disponibilité et va à l'encontre de l'objectif. Si
l'objectif n'est pas la disponibilité, alors on n'a pas besoin de RAID 1
ni pour le swap ni pour le reste.


Je suis pas tout à fait d'accord, on peut vouloir du raid1 pour la sécurité
des datas


Le RAID ne sert pas à ça. Ce n'est pas une sauvegarde.


mais vouloir du swap aussi rapide que possible, quitte à risquer
un crash système si un disque lâche pendant l'utilisation du swap.


Le RAID 0 n'est plus rapide que le RAID 1 qu'en écriture et en lecture 
séquentielle. En lecture aléatoire, le RAID 1 utilise tous les disques 
en parallèle. L'usage typique du swap fait-il plutôt des accès 
séquentiels ou aléatoires ? Si l'utilisation le justifie, on peut 
augmenter la vitesse en lecture séquentielle sans sacrifier la 
redondance avec du RAID 10.



Dans mes usages, quand ça commence à swapper ça sent mauvais, si c'est
juste une surcharge passagère ça passe (un gros batch bien goinfre,
plusieurs VMs qui consomment plus que leur moyenne simultanément mais pas
trop longtemps), mais sinon ça part vite en vrille (effet domino, ça swap
car le serveur arrive pas à fournir => les requêtes sont plus lentes =>
elles s'empile davantage => le serveur arrive encore moins à fournir).

C'est d'ailleurs un argument pour ne pas mettre de swap du tout, pour que
les oomkill arrivent dès que ça sature sans attendre l'agonie du système
(même si ça devrait jamais arriver, avec un dimensionnement correct en
amont).


Avec deux inconvénients non négligeables : le système ne tolère pas les 
surcharges passagères, et on ne choisit pas les processus à tuer, on 
doit faire confiance à l'OOM killer.

Re: Partitionnement d'un serveur web

[Pascal Hambourg]

Le 17/01/2019 à 10:44, Daniel Caillibaud a écrit :

Le 16/01/19 à 20:47, Pascal Hambourg  a écrit :


Si cela installe un nouveau noyau, cela ne correspond pas à une mise à
jour d'un noyau existant et il faut exécuter update-grub pour mettre à
jour le menu de démarrage et pouvoir démarrer avec ce noyau.


Tu es sûr ?


Plutôt, oui. grub.cfg ne se met pas à jour tout seul.


J'ai un gros doute, ça fait longtemps que je l'ai pas fait mais je pense
n'avoir jamais relancé de update-grub (c'est p'tet dpkg-postinstall qui
s'en est chargé).


Je n'ai pas écrit que c'était l'utilisateur qui devait le faire. En 
l'occurrence, c'est un script installé par grub-{pc,efi-amd64...} dans 
/etc/kernel/postinst.d/.

Re: Partitionnement d'un serveur web

[Pascal Hambourg]

Le 17/01/2019 à 07:02, Jean-Michel OLTRA a écrit :

Le mardi 15 janvier 2019, Pascal Hambourg a écrit...


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


Tiens ? Tu es sûr de ça ? Car j'avais, il y a peu, un noyau perso 4.18.6 sur
lequel tournait ma machine.
Est survenue la mise à jour (testing) qui a installé 4.19.0
Et, au boot suivant, j'ai été justement un peu surpris de retrouver mon
4.18.6 sur le menu principal et le 4.19 dans le sous-menu.


En tout cas c'est ce que j'ai toujours constaté et ce que dit la 
documentation de GRUB :



"Normally, grub-mkconfig will generate top level menu entry for the 
kernel with highest version number and put all other found kernels or 
alternative menu entries for recovery mode in submenu."

Re: Partitionnement d'un serveur web

[Stephane Ascoet]

Le 16/01/2019 à 22:10, Pascal Hambourg a écrit :


Attention : par défaut, le noyau attribue des priorités décroissantes
aux différents swaps et remplit entièrement chaque swap par ordre de
priorité. Pour distribuer les allocations entre plusieurs swaps, il faut
leur attribuer explicitement la même priorité positive avec l'option
--priority de swapon ou prio= de /etc/fstab.


Bonjour, oui, c'est l'information que j'ai aussi mais je constate sur 
mon GOBook un fonctionnement different avec certains fichiers de swap 
qu'il remplit en parallele malgre des priorites decroissantes :-o




Oui car la version qui compte pour GRUB est la version "visible" présente dans 
les noms de fichiers de l'image du noyau vmlinuz-$version et de l'initramfs 
initrd.img-$version (qui sont repris dans grub.cfg), dans la sortie de uname -a pour le 
noyau actif dans le nom du paquet linux-image-*. Les mises à jour de sécurité du noyau 
sans changement de l'ABI ne modifient pas cette version. Bien sûr la véritable version 
source, présente dans la sortie de uname -v pour le noyau actif, change à chaque mise à 
jour.


Sur ma machine pro sous Devuan ascii uname -a donne:
Linux DSI-1310066 4.16.0-0.bpo.2-amd64 #1 SMP Debian 4.16.16-2~bpo9+1 
(2018-06-26) x86_64 GNU/Linux


Donc la version de MAJ de securite c'est le "9+1"?




Ce n'est pas à ce genre de version, que je qualifie plutôt de variante, que je 
pensais.


Oui, j'aurais repondu a peu pres la meme chose a Daniel si tu ne m'avais 
pas devance.


--
Cordialement, Stephane Ascoet

Re: Partitionnement d'un serveur web

[Daniel Caillibaud]

Le 16/01/19 à 22:10, Pascal Hambourg  a écrit :
> Quand on met de la redondance, ce n'est pas pour la vitesse. C'est pour 
> la disponibilité. Si l'objectif est que le système continue à 
> fonctionner malgré la perte d'un disque, alors un swap sans redondance 
> ne garantit pas cette disponibilité et va à l'encontre de l'objectif. Si 
> l'objectif n'est pas la disponibilité, alors on n'a pas besoin de RAID 1 
> ni pour le swap ni pour le reste.

Je suis pas tout à fait d'accord, on peut vouloir du raid1 pour la sécurité
des datas mais vouloir du swap aussi rapide que possible, quitte à risquer
un crash système si un disque lâche pendant l'utilisation du swap.

Dans mes usages, quand ça commence à swapper ça sent mauvais, si c'est
juste une surcharge passagère ça passe (un gros batch bien goinfre,
plusieurs VMs qui consomment plus que leur moyenne simultanément mais pas
trop longtemps), mais sinon ça part vite en vrille (effet domino, ça swap
car le serveur arrive pas à fournir => les requêtes sont plus lentes =>
elles s'empile davantage => le serveur arrive encore moins à fournir).

C'est d'ailleurs un argument pour ne pas mettre de swap du tout, pour que
les oomkill arrivent dès que ça sature sans attendre l'agonie du système
(même si ça devrait jamais arriver, avec un dimensionnement correct en
amont).

Bref, je maintiens que le swap en raid0 m'est très utile, mais j'ai pas dit
que c'était la solution universelle.

-- 
Daniel

Rien n'est plus utile que la recherche inutile.
Carlo Rubbia, 26 novembre 1993

Re: Partitionnement d'un serveur web

[Daniel Caillibaud]

Le 16/01/19 à 20:47, Pascal Hambourg  a écrit :
> > par ex
> >apt install linux-image-4.9.0-4-grsec-amd64
> > va t'installer ce noyau (4.9 dans sa version grsec)  
> 
> Si cela installe un nouveau noyau, cela ne correspond pas à une mise à 
> jour d'un noyau existant et il faut exécuter update-grub pour mettre à 
> jour le menu de démarrage et pouvoir démarrer avec ce noyau.

Tu es sûr ?

J'ai un gros doute, ça fait longtemps que je l'ai pas fait mais je pense
n'avoir jamais relancé de update-grub (c'est p'tet dpkg-postinstall qui
s'en est chargé).

-- 
Daniel

L'argent aide a supporter la pauvreté.
Alphonse Allais

Re: Partitionnement d'un serveur web

[Jean-Michel OLTRA]

Bonjour,


Le mardi 15 janvier 2019, Pascal Hambourg a écrit...


> 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

Tiens ? Tu es sûr de ça ? Car j'avais, il y a peu, un noyau perso 4.18.6 sur
lequel tournait ma machine.
Est survenue la mise à jour (testing) qui a installé 4.19.0
Et, au boot suivant, j'ai été justement un peu surpris de retrouver mon
4.18.6 sur le menu principal et le 4.19 dans le sous-menu.

-- 
jm

Re: Partitionnement d'un serveur web

[Pascal Hambourg]

Le 16/01/2019 à 10:27, Daniel Caillibaud a écrit :


- certains préfèrent mettre le swap en raid1, deux fois moins rapide mais
   plus sûr, à toi de voir.


En ce qui me concerne c'est tout vu : si le système est en redondance, 
alors tout doit l'être, y compris et surtout le swap.



   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),


Attention : par défaut, le noyau attribue des priorités décroissantes 
aux différents swaps et remplit entièrement chaque swap par ordre de 
priorité. Pour distribuer les allocations entre plusieurs swaps, il faut 
leur attribuer explicitement la même priorité positive avec l'option 
--priority de swapon ou prio= de /etc/fstab.



   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).


Quand on met de la redondance, ce n'est pas pour la vitesse. C'est pour 
la disponibilité. Si l'objectif est que le système continue à 
fonctionner malgré la perte d'un disque, alors un swap sans redondance 
ne garantit pas cette disponibilité et va à l'encontre de l'objectif. Si 
l'objectif n'est pas la disponibilité, alors on n'a pas besoin de RAID 1 
ni pour le swap ni pour le reste.

Re: Partitionnement d'un serveur web

[Pascal Hambourg]

Le 16/01/2019 à 14:07, Daniel Caillibaud a écrit :

Le 16/01/19 à 11:44, Stephane Ascoet  a
écrit :

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


Oui car la version qui compte pour GRUB est la version "visible" 
présente dans les noms de fichiers de l'image du noyau vmlinuz-$version 
et de l'initramfs initrd.img-$version (qui sont repris dans grub.cfg), 
dans la sortie de uname -a pour le noyau actif dans le nom du paquet 
linux-image-*. Les mises à jour de sécurité du noyau sans changement de 
l'ABI ne modifient pas cette version. Bien sûr la véritable version 
source, présente dans la sortie de uname -v pour le noyau actif, change 
à chaque mise à jour.



oui, debian te propose plein de noyaux

par ex
   apt install linux-image-4.9.0-4-grsec-amd64
va t'installer ce noyau (4.9 dans sa version grsec)


Si cela installe un nouveau noyau, cela ne correspond pas à une mise à 
jour d'un noyau existant et il faut exécuter update-grub pour mettre à 
jour le menu de démarrage et pouvoir démarrer avec ce noyau.


Ce n'est pas à ce genre de version, que je qualifie plutôt de variante, 
que je pensais.

Re: Partitionnement d'un serveur web

[Daniel Caillibaud]

Le 16/01/19 à 11:44, Stephane Ascoet  a
écrit :
> Bonjour, parce qu'il est possible de mettre a jour un noyau sans monter 
> de version, hors cas d'une recompilation a la main???

oui, debian te propose plein de noyaux

  aptitude search linux-image

remonte 62 noyaux chez moi ;-)

par ex
  apt install linux-image-4.9.0-4-grsec-amd64
va t'installer ce noyau (4.9 dans sa version grsec), et par défaut ça
devrait être le noyau par défaut pour ton prochain démarrage (suivant ta
conf grub et les autres noyaux déjà installés)

-- 
Daniel

Il y a deux genre d'avocats :
ceux qui connaissent bien la loi,
et ceux qui connaissent bien le juge.
Coluche

Re: Partitionnement d'un serveur web

[Stephane Ascoet]

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???

--
Cordialement, Stephane Ascoet

Re: Partitionnement d'un serveur web

[Daniel Caillibaud]

Le 14/01/19 à 06:24, Fabrice Delvallée  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.

-- 
Daniel

C'est facile d'arrêter de fumer, j'arrête 20 fois par jour!
Oscar Wilde

Re: Partitionnement d'un serveur web

[Pierre L.]

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.

Gracias



signature.asc
Description: OpenPGP digital signature

Re: Partitionnement d'un serveur web

[Pascal Hambourg]

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.

Re: Partitionnement d'un serveur web

[Florian Blanc]

 "dpkg-reconfigure grub-pc" merci c'est juste parfait

Le mar. 15 janv. 2019 à 10:55, Florian Blanc 
a écrit :

> ah yes my /boot is in raid1 sorry :/
>
> root@ams1:/home/panpansh# lsblk
> NAMEMAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
> loop0 7:00   100G  0 loop
> loop1 7:1030G  0 loop
> loop2 7:2030G  0 loop
> loop3 7:3030G  0 loop
> loop4 7:40   100G  0 loop
> sda   8:00   477G  0 disk
> ├─sda18:10   299M  0 part
> │ └─md0   9:00 298.7M  0 raid1 /boot
> ├─sda28:20   3.8G  0 part
> │ └─md1   9:10   3.8G  0 raid1
> │   └─md1_crypt 253:10   3.8G  0 crypt [SWAP]
> └─sda38:30 472.9G  0 part
>   └─md2   9:20 472.7G  0 raid1
> └─md2_crypt 253:00 472.7G  0 crypt /
> sdb   8:16   0   477G  0 disk
> ├─sdb18:17   0   299M  0 part
> │ └─md0   9:00 298.7M  0 raid1 /boot
> ├─sdb28:18   0   3.8G  0 part
> │ └─md1   9:10   3.8G  0 raid1
> │   └─md1_crypt 253:10   3.8G  0 crypt [SWAP]
> └─sdb38:19   0 472.9G  0 part
>   └─md2   9:20 472.7G  0 raid1
> └─md2_crypt 253:00 472.7G  0 crypt /
>
> I have a small buffer :p
>
> Le mar. 15 janv. 2019 à 09:44, Pierre L.  a
> écrit :
>
>> 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 :
>> > Ce que tu dis est vrai si /boot *est* en Raid.
>>
>>
>>

Re: Partitionnement d'un serveur web

[Florian Blanc]

 ah yes my /boot is in raid1 sorry :/

root@ams1:/home/panpansh# lsblk
NAMEMAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
loop0 7:00   100G  0 loop
loop1 7:1030G  0 loop
loop2 7:2030G  0 loop
loop3 7:3030G  0 loop
loop4 7:40   100G  0 loop
sda   8:00   477G  0 disk
├─sda18:10   299M  0 part
│ └─md0   9:00 298.7M  0 raid1 /boot
├─sda28:20   3.8G  0 part
│ └─md1   9:10   3.8G  0 raid1
│   └─md1_crypt 253:10   3.8G  0 crypt [SWAP]
└─sda38:30 472.9G  0 part
  └─md2   9:20 472.7G  0 raid1
└─md2_crypt 253:00 472.7G  0 crypt /
sdb   8:16   0   477G  0 disk
├─sdb18:17   0   299M  0 part
│ └─md0   9:00 298.7M  0 raid1 /boot
├─sdb28:18   0   3.8G  0 part
│ └─md1   9:10   3.8G  0 raid1
│   └─md1_crypt 253:10   3.8G  0 crypt [SWAP]
└─sdb38:19   0 472.9G  0 part
  └─md2   9:20 472.7G  0 raid1
└─md2_crypt 253:00 472.7G  0 crypt /

I have a small buffer :p

Le mar. 15 janv. 2019 à 09:44, Pierre L.  a écrit :

> 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 :
> > Ce que tu dis est vrai si /boot *est* en Raid.
>
>
>

Re: Partitionnement d'un serveur web

[Pierre L.]

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 :
> Ce que tu dis est vrai si /boot *est* en Raid. 




signature.asc
Description: OpenPGP digital signature

Re: Partitionnement d'un serveur web

[Daniel Huhardeaux]

Le 15/01/2019 à 08:52, Pierre L. a écrit :

[...]

Bonjour à tous,
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 ?
(première image trouvée sur le net... histoire d'illustrer)
https://manual.siduction.org/static/images-common/images-grub2/grub2-convert-1.png

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. 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.

--
Daniel

Re: Partitionnement d'un serveur web

[Pierre L.]

Bonjour à tous,

Le 15/01/2019 à 07:29, Pascal Hambourg a écrit :
> 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.
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 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 ?
(première image trouvée sur le net... histoire d'illustrer)
https://manual.siduction.org/static/images-common/images-grub2/grub2-convert-1.png

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. Humm humm, c'est bon ca ! (si j'ai
bien compris le principe ?)



signature.asc
Description: OpenPGP digital signature

Re: Partitionnement d'un serveur web

[Pascal Hambourg]

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.

Re: Partitionnement d'un serveur web

[Florian Blanc]

à 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  a
écrit :

> 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).
>
>

Re: Partitionnement d'un serveur web

[Pascal Hambourg]

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).

Re: Partitionnement d'un serveur web

[Pascal Hambourg]

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.

Re: Partitionnement d'un serveur web

[Florian Blanc]

 Bonjour,
Premièrement je te conseillerais d'utiliser Proxmox tu installer le kernel
sans problème à partir de Debian :
https://pve.proxmox.com/wiki/Install_Proxmox_VE_on_Debian_Stretch
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 
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
>
> - 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
>
>

Partitionnement d'un serveur web

[Fabrice Delvallée]

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