cerhu > linux.debian.user.french

Daniel Caillibaud (16/01/2019, 15h10)
Le 16/01/19 à 11:44, Stephane Ascoet <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)
Pascal Hambourg (16/01/2019, 21h50)
Le 16/01/2019 à 14:07, Daniel Caillibaud a écrit :
> Le 16/01/19 à 11:44, Stephane Ascoet <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.
Pascal Hambourg (16/01/2019, 23h20)
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.
Jean-Michel OLTRA (17/01/2019, 08h10)
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.
Daniel Caillibaud (17/01/2019, 11h50)
Le 16/01/19 à 20:47, Pascal Hambourg <pascal> 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 Caillibaud (17/01/2019, 12h10)
Le 16/01/19 à 22:10, Pascal Hambourg <pascal> 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.
Stephane Ascoet (17/01/2019, 18h30)
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.
Pascal Hambourg (17/01/2019, 21h50)
Le 17/01/2019 à 07:02, Jean-Michel OLTRA a écrit :
> Le mardi 15 janvier 2019, Pascal Hambourg a écrit...
> 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 :
<https://www.gnu.org/software/grub/manual/grub/grub.html>

"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."
Pascal Hambourg (17/01/2019, 22h00)
Le 17/01/2019 à 10:44, Daniel Caillibaud a écrit :
> Le 16/01/19 à 20:47, Pascal Hambourg <pascal> 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/.
Pascal Hambourg (18/01/2019, 00h50)
Le 17/01/2019 à 11:00, Daniel Caillibaud a écrit :
> Le 16/01/19 à 22:10, Pascal Hambourg <pascal> 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.

> 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.
Pascal Hambourg (18/01/2019, 01h00)
Le 17/01/2019 à 17:22, Stephane Ascoet a écrit :
> Le 16/01/2019 à 22:10, Pascal Hambourg a écrit :
> 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.

> 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.
Étienne Mollier (18/01/2019, 23h40)
Bonsoir,

Pascal Hambourg, au 2019-01-18 :
> Le 17/01/2019 à 11:00, Daniel Caillibaud a écrit :
> 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 :

[..]

Bien à vous,
Eric Degenetais (19/01/2019, 00h40)
Le jeu. 17 janv. 2019 23:44, Pascal Hambourg <pascal> a
écrit :

> Le 17/01/2019 à 11:00, Daniel Caillibaud a écrit :
> sécurité
> 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 undisque
est détruit, et non toute la machine.
[..]
Pascal Hambourg (19/01/2019, 01h00)
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_l imites_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).
Eric Degenetais (19/01/2019, 10h50)
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 <pascal> a
écrit :
[..]

Discussions similaires
Partitionnement serveur - Besoin de vos conseils et experiences

partitionnement des disques de mon serveur.

partitionnement mini-serveur fichiers & web

plan de partitionnement pour serveur Web


Fuseau horaire GMT +2. Il est actuellement 12h29. | Privacy Policy