> Il y a quelques différences tout de même, comme yum.
RHEL 5 est passé à yum (puisque RHEL 5 est basé sur FC6). Par contre il y a un plugin yum pour accéder à rhn dans RHEL 5. RHEL 5 fournit toujours up2date pour des raisons de compatibilité, mais il ne sera plus dans RHEL 6 (ça a été annoncé à la sortie de RHEL 5).
> Ce qui me gène dans sysconfig n'est pas dans le contenu, qui est proche comme le montre ma citation, mais dans l'aspect "fouilli" : rien que pour le réseau, l'information est parfois répartie sur une dizaine de fichiers, ce qui en complique la maintenance je trouve.
OK, c'est principalement sur la forme. Il y a aussi des scripts (donc programmes) dans /etc/sysconfig ce qui est tout à fait discutable (pour ma part ils ne devraient pas être là). M'enfin, c'est limité à /etc/sysconfig/network-scripts/ .
Pour info, la doc est dans /usr/share/doc/initscripts-*/sysconfig.txt .
Normalement system-config-network (marche aussi en mode texte) gère ça très bien pour 98 % des cas.
> Tests faits sur une CentOS 4, avec discution avec l'une des personnes en charge de cette distrib.
CentOS 4 est RHEL 4 qui est basé sur FC3 je crois. Au pif la distribution à 3 ans.
Tu as comparé avec une FreeBSD de la même époque ?
Ceci dit, t'as trouvé une distribution Linux qui ne t'as pas donné satisfaction avec NFS. Que dire à part "c'est la vie".
Il me semble que RHEL 4 était une des premières distributions à passer au code NFS 4. Peut-être que Red Hat a fait une connerie avec ce choix. Ben ça arrive. Faut pas que ça arrive trop souvent :-)
> Alors je m'excuse pour le mot "gnuteries"
Ça roule, c'est oublié.
> Ce qui me gène surtout c'est d'avoir fait de /bin/sh un simple lien vers /bin/bash sur nombre de distribs
Faut comprendre la raison. Tout le monde (99%) utilise/choisi bash. Au-lieu de maintenir deux shells, d'en avoir deux en mémoire, etc et bien il n'y en a qu'un. C'est une raison qu'on peut ne pas trouver suffisante, mais elle a du sens.
> alors que pour moi le shell de root par défaut devrait être minimaliste de chez minimaliste, question de sécurité
Pour l'aspect sécurité je suis très sceptique. Par définition un shell doit tout permettre (même les pires conneries de l'admin). C'est l'OS (noyau, login, ssh, selinux, etc) qui fait la sécurité.
Si c'est très minimaliste, c'est probablement un shell qu'utilise rarement les admins. Donc les risques d'erreur augmente (d'autant plus que l'admin va "s'énerver" avec ce shell minimaliste).
Si c'est pour les bugs du shell, ben bash est plus utilisé, testé, audité, etc.
Si on te suit, pourquoi pas un ls mininum, un find minimum, etc. Pourquoi pas faire de busybox le shell de root ?
Je ne peux pas démontrer que tu as tord. M'enfin l'histoire montre que les problèmes de sécurité viennent rarement de la. Il n'y a pas de daemon bash a l'écoute du réseau :-)
> quitte à lancer un bash à la main après.
Tu avances ce que tu considères comme un atout sécurité et après tu le contournes :-)
> Cela éviterait de se retrouver coincé par un truc dans /etc/bashrc lorsque l'on essaye de se connecter root sur une machine ayant un problème...
Mouaif. Il y a toujours des compromis. Tu peux te faire un sh-mini avec dedans "bash --noprofile --norc". Je crois que le boot en initlevel 1 lance un shell avec ces options (je n'ai pas envis de rebooter pour vérifier ça :-). Tu peux aussi booter avec en paramètre "init=/bin/mon_shell_mini" ou "init=/usr/bin/mc" etc.
Faut toujours évaluer les problèmes globalement et ne pas seulement s'en tenir aux principes "simplistes". Oui avec un shell minimum tu auras moins de problèmes "théoriquement". Mais es-ce que ça vaut la peine d'"emmerder" tout le monde avec un shell minimum dont le gain en sécurité/fiabilité est quasi insignifiant ? Pour ma part, et c'est subjectif, la réponse est non.
Puis il y a tellement de truc qui peuvent merder... Si dans chaque cas il faut un contournement car un utilisateur a eu le problème, ça devient une usine à gaz (et avec paradoxalement plus de possibilité pour que ça merde).
Je me rappelle qu'un débat animé sur mailing Fedora car Fedora voulait virer toutes les lib statiques et qu'aucun programme ne soit linké statiquement (même plus de bash_static). Ceux qui étaient contre étaient dans ton esprit, c'est-à-dire qu'un programme static c'est bien si la mise à jour d'une lib déconne (comme un shell mini c'est bien s'il y a une connerie dans bashrc). Le problème avec ce type de raisonnement c'est que c'est sans fin. Il faut bash en static, puis ln en static, puis vim, puis login, puis init, etc...
Une bécane qui ne boote plus, un shell qui ne marche pas et qui ne permet plus de se logguer est un vrai problème. Mais la solution n'est pas d'avoir un contournement pour chaqu'un de ces problèmes. La solution est d'utilise un CD de secours. Le CD d'installation de Fedora ou RHEL le fait et probablement que toutes les distributions le font.
Une autre solution (c'est ce que je fais) est d'installer deux systèmes. Un système mininum (2 Go sur une partition suffisse). S'il y a une catastrophe, on boote sur le système minimum.
Il y a d'autre solution évidemment. Mais il ne faut pas chercher un contournement pour un problème, mais pour un ensemble de problème. Un CD de secours ou un second système (minimum ou un mirroir du système principal) sont les bonnes solutions (à mon avis).
[^] # Re: Plaf
Posté par IsNotGood . En réponse au journal Vous savez quoi ?. Évalué à 1.
RHEL 5 est passé à yum (puisque RHEL 5 est basé sur FC6). Par contre il y a un plugin yum pour accéder à rhn dans RHEL 5. RHEL 5 fournit toujours up2date pour des raisons de compatibilité, mais il ne sera plus dans RHEL 6 (ça a été annoncé à la sortie de RHEL 5).
> Ce qui me gène dans sysconfig n'est pas dans le contenu, qui est proche comme le montre ma citation, mais dans l'aspect "fouilli" : rien que pour le réseau, l'information est parfois répartie sur une dizaine de fichiers, ce qui en complique la maintenance je trouve.
OK, c'est principalement sur la forme. Il y a aussi des scripts (donc programmes) dans /etc/sysconfig ce qui est tout à fait discutable (pour ma part ils ne devraient pas être là). M'enfin, c'est limité à /etc/sysconfig/network-scripts/ .
Pour info, la doc est dans /usr/share/doc/initscripts-*/sysconfig.txt .
Normalement system-config-network (marche aussi en mode texte) gère ça très bien pour 98 % des cas.
> Tests faits sur une CentOS 4, avec discution avec l'une des personnes en charge de cette distrib.
CentOS 4 est RHEL 4 qui est basé sur FC3 je crois. Au pif la distribution à 3 ans.
Tu as comparé avec une FreeBSD de la même époque ?
Ceci dit, t'as trouvé une distribution Linux qui ne t'as pas donné satisfaction avec NFS. Que dire à part "c'est la vie".
Il me semble que RHEL 4 était une des premières distributions à passer au code NFS 4. Peut-être que Red Hat a fait une connerie avec ce choix. Ben ça arrive. Faut pas que ça arrive trop souvent :-)
> Alors je m'excuse pour le mot "gnuteries"
Ça roule, c'est oublié.
> Ce qui me gène surtout c'est d'avoir fait de /bin/sh un simple lien vers /bin/bash sur nombre de distribs
Faut comprendre la raison. Tout le monde (99%) utilise/choisi bash. Au-lieu de maintenir deux shells, d'en avoir deux en mémoire, etc et bien il n'y en a qu'un. C'est une raison qu'on peut ne pas trouver suffisante, mais elle a du sens.
> alors que pour moi le shell de root par défaut devrait être minimaliste de chez minimaliste, question de sécurité
Pour l'aspect sécurité je suis très sceptique. Par définition un shell doit tout permettre (même les pires conneries de l'admin). C'est l'OS (noyau, login, ssh, selinux, etc) qui fait la sécurité.
Si c'est très minimaliste, c'est probablement un shell qu'utilise rarement les admins. Donc les risques d'erreur augmente (d'autant plus que l'admin va "s'énerver" avec ce shell minimaliste).
Si c'est pour les bugs du shell, ben bash est plus utilisé, testé, audité, etc.
Si on te suit, pourquoi pas un ls mininum, un find minimum, etc. Pourquoi pas faire de busybox le shell de root ?
Je ne peux pas démontrer que tu as tord. M'enfin l'histoire montre que les problèmes de sécurité viennent rarement de la. Il n'y a pas de daemon bash a l'écoute du réseau :-)
> quitte à lancer un bash à la main après.
Tu avances ce que tu considères comme un atout sécurité et après tu le contournes :-)
> Cela éviterait de se retrouver coincé par un truc dans /etc/bashrc lorsque l'on essaye de se connecter root sur une machine ayant un problème...
Mouaif. Il y a toujours des compromis. Tu peux te faire un sh-mini avec dedans "bash --noprofile --norc". Je crois que le boot en initlevel 1 lance un shell avec ces options (je n'ai pas envis de rebooter pour vérifier ça :-). Tu peux aussi booter avec en paramètre "init=/bin/mon_shell_mini" ou "init=/usr/bin/mc" etc.
Faut toujours évaluer les problèmes globalement et ne pas seulement s'en tenir aux principes "simplistes". Oui avec un shell minimum tu auras moins de problèmes "théoriquement". Mais es-ce que ça vaut la peine d'"emmerder" tout le monde avec un shell minimum dont le gain en sécurité/fiabilité est quasi insignifiant ? Pour ma part, et c'est subjectif, la réponse est non.
Puis il y a tellement de truc qui peuvent merder... Si dans chaque cas il faut un contournement car un utilisateur a eu le problème, ça devient une usine à gaz (et avec paradoxalement plus de possibilité pour que ça merde).
Je me rappelle qu'un débat animé sur mailing Fedora car Fedora voulait virer toutes les lib statiques et qu'aucun programme ne soit linké statiquement (même plus de bash_static). Ceux qui étaient contre étaient dans ton esprit, c'est-à-dire qu'un programme static c'est bien si la mise à jour d'une lib déconne (comme un shell mini c'est bien s'il y a une connerie dans bashrc). Le problème avec ce type de raisonnement c'est que c'est sans fin. Il faut bash en static, puis ln en static, puis vim, puis login, puis init, etc...
Une bécane qui ne boote plus, un shell qui ne marche pas et qui ne permet plus de se logguer est un vrai problème. Mais la solution n'est pas d'avoir un contournement pour chaqu'un de ces problèmes. La solution est d'utilise un CD de secours. Le CD d'installation de Fedora ou RHEL le fait et probablement que toutes les distributions le font.
Une autre solution (c'est ce que je fais) est d'installer deux systèmes. Un système mininum (2 Go sur une partition suffisse). S'il y a une catastrophe, on boote sur le système minimum.
Il y a d'autre solution évidemment. Mais il ne faut pas chercher un contournement pour un problème, mais pour un ensemble de problème. Un CD de secours ou un second système (minimum ou un mirroir du système principal) sont les bonnes solutions (à mon avis).