gratifiant > comp.os.* > comp.os.linux.configuration

Jo Engo (14/04/2018, 12h35)
Je note, avant de tout oublier, si ça vous intérese, lisez, sinon passez
au message suivant ^^

- J'ai finalement tout fait avec gparted, ce qui m'a évité d'avoir à
manipuler les uuid (monter /, lire le contenu de fstab, copier-coller les
uuid
- gparted m'a fait une belle frayeur en plantant au milieu du
processus. Je n'ai pas réussi à comprendre où ça a planté précisément
mais je n'ai pas eu de pertes de données, j'ai reprogrammé les opérations
qui n'avaient pas été faites
- gparted a déduit une seul opération «shrink» de réduire/déplacer/
agrandir mais c'est pas grave parce que
- gparted fait un repartitionnement «intelligent» il ne recopie que les
secteurs utilisés donc ça a été très rapide, ç'aurait sans doute été
encore plus rapide avec un deuxième disque
- j'ai supprimmé la partition /opt dont je n'ai pas l'usage et j'ai
oublié de rectifier fstab regimbage au démarrage, il (debian) me demande
le mot de passe de root que j'ai dû définir puis oublier ^^ vu que je me
sers de sudo, je ne me souviens plus de comment je m'en suis sorti en
démarrant en single ou avec SystemRescueCD que j'avais sous la main (en
fait je m'en était servi pour repartitionner -_o j'ai commenté l'entrée
de fstab et depuis tout roule
jp willm (14/04/2018, 15h32)
Le 14/04/2018 à 12:35, Jo Engo a écrit :
> Je note, avant de tout oublier, si ça vous intérese, lisez,


Merci pour le retour.
denis.paris (15/04/2018, 12h26)
Le 14/04/2018 à 12:35, Jo Engo a écrit :

> - j'ai supprimmé la partition /opt dont je n'ai pas l'usage et j'ai
> oublié de rectifier fstab regimbage au démarrage, il (debian) me demande
> le mot de passe de root que j'ai dû définir puis oublier ^^ vu que je me
> sers de sudo, je ne me souviens plus de comment je m'en suis sorti en


C'est le danger de sudo, c'est pour cela qu'il faut initialiser "root"
avec un mot de passe non trivial mais le noter soigneusement.

Cependant on a toujours la possibilité de booter d'un live CD et de
venir effacer le mot de passe root dans le fichier /etc/shadow
Doug713705 (15/04/2018, 13h33)
Le 15-04-2018, denis.paris nous expliquait dans
fr.comp.os.linux.configuration
(<5ad328f0$0$7197$426a74cc>) :

> Le 14/04/2018 à 12:35, Jo Engo a écrit :
> C'est le danger de sudo, c'est pour cela qu'il faut initialiser "root"
> avec un mot de passe non trivial mais le noter soigneusement.
> Cependant on a toujours la possibilité de booter d'un live CD et de
> venir effacer le mot de passe root dans le fichier /etc/shadow


Ou plus simplement corriger directement /etc/fstab à partir du live CD
puisque c'est le vrai problème.

Ceci dit j'ai également constaté ce comportement que je qualifierai de
stupide de la part de Debian mais qui est probablement un comportement
qu'on retrouve chez les autres "grandes" distributions (je crois que
systemd est le véritable coupable mais je n'ai pas vérifié):
- L'OS refuse du booter si une partition renseignée dans /etc/fstab
est inaccessible par l'OS (genre partition inexistante sur le disque
ou point de montage manquant).

Autant ça peut se justifier pour une parition "système" (/, /usr/, /var/,
/lib, etc) auquel cas le système crashera de toutes façons, autant pour
une partition /home/user/pr0n j'ai des doutes quant à la pertinence de
ce comportement.

Je comprends bien que le risque est de démarrer un système avec une
partition manquante et donc que des traitements automatisés *pourraient*
faire des dégats mais pour moi c'est se tromper de problème.

Si un traitement flingue un système (ou des corrompt datas) parce qu'il
lui manque le système de fichiers sur lequel il doit travaille alors c'est
le traitement qui est fautif et qui doit être corrigé.

Empecher le système de booter pour si peu c'est emmerder le sysadmin
plus que nécessaire et se laver facilement les mains en lui refilant le
bébé.
Pascal Hambourg (15/04/2018, 14h04)
Le 15/04/2018 à 13:33, Doug713705 a écrit :
> Ceci dit j'ai également constaté ce comportement que je qualifierai de
> stupide de la part de Debian mais qui est probablement un comportement
> qu'on retrouve chez les autres "grandes" distributions (je crois que
> systemd est le véritable coupable mais je n'ai pas vérifié):
> - L'OS refuse du booter si une partition renseignée dans /etc/fstab
> est inaccessible par l'OS (genre partition inexistante sur le disque
> ou point de montage manquant).


Il me semble que ce comportement est apparu avec systemd. Auparavant
l'échec d'un montage était ignoré.

> Autant ça peut se justifier pour une parition "système" (/, /usr/, /var/,
> /lib, etc) auquel cas le système crashera de toutes façons, autant pour
> une partition /home/user/pr0n j'ai des doutes quant à la pertinence de
> ce comportement.


Et comment le système sait-il que ce montage n'est pas essentiel si
l'administrateur ne lui a pas dit en ajoutant l'option "nofail" dans fstab ?

> lui manque le système de fichiers sur lequel il doit travaille alors c'est
> le traitement qui est fautif et qui doit être corrigé.


Pas d'accord. C'est le rôle du système d'init de tout mettre en place
pour que les traitements puissent fonctionner. Chacun son rôle, sinon on
n'a pas fini...
Doug713705 (15/04/2018, 14h43)
Le 15-04-2018, Pascal Hambourg nous expliquait dans
fr.comp.os.linux.configuration
(<pavf3u$28ot$1>) :

> Le 15/04/2018 à 13:33, Doug713705 a écrit :
> Il me semble que ce comportement est apparu avec systemd. Auparavant
> l'échec d'un montage était ignoré.


Le bon vieux temps ;-)

>> Autant ça peut se justifier pour une parition "système" (/, /usr/, /var/,
>> /lib, etc) auquel cas le système crashera de toutes façons, autant pour
>> une partition /home/user/pr0n j'ai des doutes quant à la pertinence de
>> ce comportement.

> Et comment le système sait-il que ce montage n'est pas essentiel si
> l'administrateur ne lui a pas dit en ajoutant l'option "nofail" dans fstab ?


On pourrait peut-être inverser le problème.
En l'absence de nofail, ne pas reporter les éventuelles erreurs.
En présence nofail et si le device n'est pas dispo alors on arrête tout.

Du coup il faudrait renommer nofail en qqchose comme halt_on_fail.

>> lui manque le système de fichiers sur lequel il doit travaille alors c'est
>> le traitement qui est fautif et qui doit être corrigé.

> Pas d'accord. C'est le rôle du système d'init de tout mettre en place
> pour que les traitements puissent fonctionner. Chacun son rôle, sinon on
> n'a pas fini...


Mais init n'a aucun moyen de savoir ce que sont ces traitements, ni
quelles sont les éventuelles conséquences de leur dysfonctionnements.

De mon point de vue la séquence pourrait être un truc comme:
- Montage des partitions
- Demarrage des services
- Un service a besoin que telle partition soit montée pour s'éxécuter
(pré-requis)
- La partition concernée n'est pas montée
- Le service n'est pas démarré (*mais* le système est malgré tout up et
on peut investiguer dessus sansavoir à retrouver un mot de passe root
que personne n'utilise. Sur de l'urgent c'est toujours relou.

Il me semble beaucoup plus logique d'émpécher le démarrage d'un seul
service défaillant plutôt que d'empécher le démarrage du système complet
pour un problème lié à un seul des services qu'il héberge.
Nicolas George (15/04/2018, 15h05)
Doug713705 , dans le message <pavhd6$1mr$1>, a
écrit :
>> Il me semble que ce comportement est apparu avec systemd. Auparavant
>> l'échec d'un montage était ignoré.

> Le bon vieux temps ;-)


Je n'ai pas l'impression que ce soit vrai.

> Il me semble beaucoup plus logique d'émpécher le démarrage d'un seul
> service défaillant plutôt que d'empécher le démarrage du système complet
> pour un problème lié à un seul des services qu'il héberge.


Tu as raison.

Et tu sais quel projet a pour objectif de réaliser exactement ça ?
systemd.
Pascal Hambourg (15/04/2018, 15h19)
Le 15/04/2018 à 14:43, Doug713705 a écrit :
> Le 15-04-2018, Pascal Hambourg nous expliquait :
>> Et comment le système sait-il que ce montage n'est pas essentiel si
>> l'administrateur ne lui a pas dit en ajoutant l'option "nofail" dans fstab ?

> On pourrait peut-être inverser le problème.
> En l'absence de nofail, ne pas reporter les éventuelles erreurs.
> En présence nofail et si le device n'est pas dispo alors on arrête tout.


L'ennui, c'est que ça a été défini d'une certaine façon et je pense que
ça date de bien avant systemd puisque la page de manuel de mount
mentionne l'option "nofail" depuis au moins Debian 6 "Squeeze" (c'est ce
que j'ai de plus ancien encore installé, flemme de regarder avant).

>> Pas d'accord. C'est le rôle du système d'init de tout mettre en place
>> pour que les traitements puissent fonctionner. Chacun son rôle, sinon on
>> n'a pas fini...

> Mais init n'a aucun moyen de savoir ce que sont ces traitements, ni
> quelles sont les éventuelles conséquences de leur dysfonctionnements.


J'hésite entre deux réponses :

a) Ce n'est pas le problème d'init. Il se contente de monter ce qu'on
lui dit de monter, et si ça échoue, il boude et l'administrateur se
débrouille.

b) Là encore, on peut informer l'init de cette dépendance. Il me semble
que systemd permet de définir des dépendances entre unités, et crée une
unité pour chaque montage.

> Il me semble beaucoup plus logique d'émpécher le démarrage d'un seul
> service défaillant plutôt que d'empécher le démarrage du système complet
> pour un problème lié à un seul des services qu'il héberge.


Ça se défend. Voir ma réponse b).
Doug713705 (15/04/2018, 15h40)
Le 15-04-2018, Nicolas George nous expliquait dans
fr.comp.os.linux.configuration
(<5ad34e2e$0$12248$426a74cc>) :

> Doug713705 , dans le message <pavhd6$1mr$1>, a
> écrit :
>>> Il me semble que ce comportement est apparu avec systemd. Auparavant
>>> l'échec d'un montage était ignoré.

>> Le bon vieux temps ;-)

> Je n'ai pas l'impression que ce soit vrai.


J'avoue que mon avis est basé sur des impressions plus que des faits.

Cependant, avant une petite mésaventure sur une Debian récente sur laquelle
j'avais supprimé une partition en oubliant de modifier le fstab, il ne
m'était *jamais* arrivé de voir un système se bloquer pour un problème
de partition "anodine" manquante.

C'était d'autant plus dommage que le mot de passe root faisait 42 chars
de long et que le clavier était en qwerty.

>> Il me semble beaucoup plus logique d'émpécher le démarrage d'un seul
>> service défaillant plutôt que d'empécher le démarrage du système complet
>> pour un problème lié à un seul des services qu'il héberge.

> Tu as raison.


C'est toujours bon de l'entendre dire :D

> Et tu sais quel projet a pour objectif de réaliser exactement ça ?
> systemd.


Ah mais je ne dis pas qu'il ne peut pas y avoir de bonnes idées parmi cet
amoncellement de n'importe quoi plus ou moins brinquebalant appelé
systemd ;-)

Par ailleurs il ne faudrait que quelques lignes de bash (probablement
moins de 10 lignes) pour obtenir le même comportement avec SysV ou un init
BSD-style.

Pour le coup attendre systemd pour résoudre ce "problème" c'est juste WTF!
Nicolas George (15/04/2018, 23h07)
Doug713705 , dans le message <pavkon$1mr$2>, a
écrit :
> Cependant, avant une petite mésaventure sur une Debian récente sur laquelle
> j'avais supprimé une partition en oubliant de modifier le fstab, il ne
> m'était *jamais* arrivé de voir un système se bloquer pour un problème
> de partition "anodine" manquante.


Je ne me rappelle pas un problème de ce genre non plus. L'information
est-elle fiable ?

> Ah mais je ne dis pas qu'il ne peut pas y avoir de bonnes idées parmi cet
> amoncellement de n'importe quoi plus ou moins brinquebalant appelé
> systemd ;-)


Non, l'amoncellement de n'importe quoi plus ou moins brinquebalant,
c'est SysV init.

> Par ailleurs il ne faudrait que quelques lignes de bash (probablement
> moins de 10 lignes) pour obtenir le même comportement avec SysV ou un init
> BSD-style.


Il faudrait largement plus de dix lignes pour obtenir quelque chose qui
marche à moitié dans les cas faciles. On le sait, les gens ont essayé.
Doug713705 (15/04/2018, 23h37)
Le 15-04-2018, Nicolas George nous expliquait dans
fr.comp.os.linux.configuration
(<5ad3bf1c$0$7184$426a34cc>) :

>> Cependant, avant une petite mésaventure sur une Debian récente sur laquelle
>> j'avais supprimé une partition en oubliant de modifier le fstab, il ne
>> m'était *jamais* arrivé de voir un système se bloquer pour un problème
>> de partition "anodine" manquante.

> Je ne me rappelle pas un problème de ce genre non plus. L'information
> est-elle fiable ?


Vue de mes yeux et résolue par moi même en supprimant la ligne fstab concernée
le tout après un facedesk de circonstance.

>> Ah mais je ne dis pas qu'il ne peut pas y avoir de bonnes idées parmi cet
>> amoncellement de n'importe quoi plus ou moins brinquebalant appelé
>> systemd ;-)

> Non, l'amoncellement de n'importe quoi plus ou moins brinquebalant,
> c'est SysV init.


C'est vrai, rien ne vaut un système init BSD-style :)

>> Par ailleurs il ne faudrait que quelques lignes de bash (probablement
>> moins de 10 lignes) pour obtenir le même comportement avec SysV ou un init
>> BSD-style.

> Il faudrait largement plus de dix lignes pour obtenir quelque chose qui
> marche à moitié dans les cas faciles. On le sait, les gens ont essayé.


Je ne parle pas de faire une bouse générique autant imbitable que non
maintenanble mais d'un script maison adapté à la situation rencontrée et
pas à celle du voisin.

En essayant de résoudre tous les cas Systemd échouera sur les mêmes éccueils
notamment le plus gros:
- Définir tous les cas possibles.

Il est totalement incensé de vouloir résoudre tous les cas et fournir un
outil qui n'en résoudra que 99% est un remède pire que le mal car il
rendra difficle voire impossible la résolution du dernier pourcent.

La seule solution envisageable est de laisser le sysadmin en charge du
bouzin faire ce pourquoi il a été engagé.

Enfin, c'est mon point de vue.
Nicolas George (15/04/2018, 23h55)
Doug713705 , dans le message <pb0gnf$ba6$1>, a
écrit :
> Je ne parle pas de faire une bouse générique autant imbitable que non
> maintenanble mais d'un script maison adapté à la situation rencontrée et
> pas à celle du voisin.


Même comme ça. Faire un script shell fiable est très difficile. C'est
précisément en partant dans cette direction que tu bâtis un truc qui va
faire n'importe quoi, typiquement le contraire de ce qu'on veut, dès
qu'il rencontre un cas imprévu.
Doug713705 (16/04/2018, 00h29)
Le 15-04-2018, Nicolas George nous expliquait dans
fr.comp.os.linux.configuration
(<5ad3ca45$0$9295$426a74cc>) :

> Même comme ça. Faire un script shell fiable est très difficile. C'est
> précisément en partant dans cette direction que tu bâtis un truc qui va
> faire n'importe quoi, typiquement le contraire de ce qu'on veut, dès
> qu'il rencontre un cas imprévu.


Très difficile, tu exagères. Tu penses déjà à vouloir résoudre des cas qui
n'existent pas dans la plupart des réalités de terrains.

Il est quand même beaucoup plus simple de résoudre un problème qu'on a
identifié localement qu'une myriade de problèmes dont on ne connait rien.

Il ne s'agit pas non plus de tenter de résoudre le problème de la
partition manquante mais simplement de savoir si les données attendues
(ici le FS) sont disponibles au moment où on en a besoin (ici au démarrage
du service).

La réponse est "oui" ou "non", pas "peut-être attends un peu on ne sait
jamais avec le réseau des fois ça peut revenir, saloperie de NFS c'est
toujours ça qui lâche, vas-y retente maintenant".

Bien sûr que le script du sysadmin du coin aura besoin d'évoluer lorsque
de nouveaux cas imprévus seront découverts mais:
- Ces cas seront peu nombreux. Logiquement le sysadmin du coin connait
son infrastructure. Il peut ne pas avoir pensé à tout mais tous les
cas possibles seront vites identfiés.
- La réactivité sera bien meilleure que celle de l'upstream qui aura
besoin d'attendre la confirmation du rapport de bug, puis devra
allouer des ressources pour réssoudre le problème. Le tout si et
seulement si l'upstream estime important de le résoudre rapidement
(et avec LP aux commandes on sait que c'est parfois difficile).
Nicolas George (16/04/2018, 10h58)
Doug713705 , dans le message <pb0jnk$ba6$2>, a
écrit :
> Très difficile, tu exagères.


Non, je n'exagère pas. Le shell est un langage très rudimentaire et
plein de pièges subtils et pénibles.

> Il est quand même beaucoup plus simple de résoudre un problème qu'on a
> identifié localement qu'une myriade de problèmes dont on ne connait rien.


Et en résolvant ce problème local, on s'en prépare deux pour plus tard.

> Bien sûr que le script du sysadmin du coin aura besoin d'évoluer lorsque
> de nouveaux cas imprévus seront découverts mais:


Et chaque nouvelle couche double le nombre de problèmes potentiels.

> - La réactivité sera bien meilleure que celle de l'upstream qui aura
> besoin d'attendre la confirmation du rapport de bug, puis devra
> allouer des ressources pour réssoudre le problème.


Et puis surtout prendre le temps de réfléchir à une solution qui marche
vraiment. C'est ça qui fait toute la différence.
Doug713705 (16/04/2018, 12h14)
Le 16-04-2018, Nicolas George nous expliquait dans
fr.comp.os.linux.configuration
(<5ad465d3$0$7190$426a74cc>) :

> Doug713705 , dans le message <pb0jnk$ba6$2>, a
> écrit :
>> Très difficile, tu exagères.

> Non, je n'exagère pas. Le shell est un langage très rudimentaire et
> plein de pièges subtils et pénibles.


C'est un outil documenté de longue date.
Les capacités et limites en sont connues depuis longtemps et il est
employé avec succès depuis des lustres.

Même si la situation change au fur et à mesure du progrès des technos
Il n'est pas devenu plus difficile du jour au lendemain sans prévenir.

Les mecs ne savent pas coder en shell et voudrait coder from scratch
un init complet /o\

>> Il est quand même beaucoup plus simple de résoudre un problème qu'on a
>> identifié localement qu'une myriade de problèmes dont on ne connait rien.

> Et en résolvant ce problème local, on s'en prépare deux pour plus tard.
>> Bien sûr que le script du sysadmin du coin aura besoin d'évoluer lorsque
>> de nouveaux cas imprévus seront découverts mais:

> Et chaque nouvelle couche double le nombre de problèmes potentiels.


N'importe quoi, ce n'est pas systématiquement le cas.
Et si ça l'était ce serait nécessairement également valable et même
pire pour systemd qui aurait tout un tas de combinaisons suppléméntaires
à traiter puisqu'il tente de traiter tous les cas.

Tous les arguments que tu peux employer contre init et une poignée de
scripts bien pensés sont totalement appliquables à systemd sauf que dans
un cas on traite parfaitement un problème local totalement cerné alors
que dans l'autre on tente de deviner quel pourrait être le problème
parmi n solutions possibles (explosion combinatoire garantie).

Si c'est pour qu'à là fin un joli "K2000" rouge à la con me chie
une erreur parce qu'il a été impossible de déterminer ce qu'il fallait
faire alors je n'ai vraiment pas besoin de cette "solution" qui n'en est
pas une.

>> - La réactivité sera bien meilleure que celle de l'upstream qui aura
>> besoin d'attendre la confirmation du rapport de bug, puis devra
>> allouer des ressources pour réssoudre le problème.

> Et puis surtout prendre le temps de réfléchir à une solution qui marche
> vraiment. C'est ça qui fait toute la différence.


Tu te rends bien compte qu'un serveur down en prod ne peut pas vraiment
attendre que l'upstream prenne une décision, que le patch soit codé,
testé, poussé, que la distribution empaquète le tout et que la mise à
jour de tout ça finisse par arriver sur un dépot.

Je ne dis pas qu'il ne faut pas prendre son temps pour faire de bons
outils mais honnêtement ça ne semble vraiment pas être le chemin pris par
systemd qui a plutôt tendance à pousser de la merde le plus vite possible.

La situation est d'autant plus grave que systemd a été adopté et poussé
en prod alors qu'il n'était clairement pas mûr, loin s'en faut !

Alors les discours sur "le temps de réfléchir", c'est juste LOL concernant
systemd.

Personne n'a vraiment réfléchi à systemd. Le truc a été poussé à la
rache ().

Ton discours serait crédible si systemd avait réèllement apporté ce qui
avait été annoncé et qu'il n'avait pas fait l'objet d'un puissant
lobbying pour être adopté en masse par les grandes distributions avant
qu'il ne soit sec obligeant tout le monde à creuser encore plus le trou
pour se sortir de la situation. Sauf que la sortie est par le haut les gars !

Ce projet est tout simplement pitoyable à plus d'un niveau.

Discussions similaires