Une fois, un de mes amis (qui est un utilisateur expérimenté d'Unix / Linux) m'a dit que définir le shell de root sur autre chose que sh (c'est-à-dire bash ou zsh) pourrait créer des problèmes, car certains scripts pourraient supposer que le shell est sh et faire quelque chose de bizarre .
Cependant, je pense qu'Ubuntu a un shell racine par défaut défini sur bash, et Gentoo utilise également bash. Quelqu'un peut-il casser le mythe?
Réponses:
Oui. Si le système échoue lors du démarrage, vous pouvez vous connecter au shell racine. Si vous avez / usr séparé, certains shells peuvent ne pas réussir à démarrer.
Je conseillerais de créer un compte toor(uid 0, gid 0) avec un shell non standard tout en laissant la racine avec le shell par défaut.
zshet /usrest en quelque sorte endommagé, j'aurai un problème? mais mon système a /bin/shpointé vers lui /bin/bash- bashmême, pourquoi ne serait-il pas shaffecté?
zshne devrait pas y être /usr/bin/s'il est mal installé. tous les obus doivent être /bin
/binmais garde quelques fichiers dedans /usr/share. J'ai également clairement indiqué que le problème est lié à la connexion lors du démarrage (lorsqu'un service échoue).
Cela ne devrait pas être un problème.
Les fichiers shell-script codent explicitement avec quel shell ils sont exécutés. Il est encodé dans la première ligne ou d'autres programmes ou scripts exécutent un shell spécifique et donnent le script shell comme argument.
Le seul programme auquel je peux penser qui utilise les informations du shell du compte utilisateur (en plus du processus de connexion) est procmail. Vraiment drôle si votre utilisateur a défini comme shell / bin / false sur le serveur de messagerie ... Mais vous n'exécutez généralement pas procmail en tant que root.
Un autre candidat serait les lignes dans la crontab de racine. Je ne sais pas quelle est la politique de crond pour savoir quel shell utiliser.
Les scripts écrits pour le shell bourne s'exécuteront la plupart du temps contre BASH ou ZSH ou $ foo sans aucun problème.
Sur de nombreux systèmes Linux, aucun sh d'origine n'est installé, mais plutôt un lien symbolique contre / bin / bash.
Si certains scripts "supposent" simplement que le shell est explicitement sh, ils doivent être réécrits. Le mécanisme Shebang permet de choisir l'interpréteur dont votre script a besoin. Si c'est le sh, le script doit inclure #!/bin/shcomme première ligne.
Votre paramètre de shell par défaut ne devrait pas être pertinent dans ce contexte.
Je ne pense pas que changer le shell de root causerait des problèmes. Je semble me souvenir de certains unités (peut-être des variantes BSD?) Ayant tcsh comme shell par défaut pour root.
Les connexions root sont rares de toute façon. Normalement, vous vous connectez à votre propre compte, puis su ou sudo pour rooter.
Ce qui importe, c'est que le shell de root ait le moins de dépendances possible afin d'être utilisable dans un contexte de réparation système. Par exemple, c'est une bonne idée d'avoir un shell racine lié statiquement; certaines distributions livrent une version liée statiquement de bash ou zsh ou sash (un shell avec de nombreux utilitaires standard intégrés). Cependant, ce n'est pas si important si votre système peut facilement être démarré à partir d'un CD de secours ou d'une clé USB.
Le shell de connexion d'un utilisateur n'affecte pas le processus de démarrage. Vous pouvez définir ce shell à votre guise. Tous les systèmes n'ont pas bash et ils fonctionnent bien. De plus, si c'est /usr/bin/zshmal installé, tous les shells du système devraient être installés /bin. Cependant, vous ne devriez pas changer /bin/shpour pointer vers autre chose que la valeur par défaut (à moins que vous ne sachiez ce que vous faites) comme de nombreux scripts #!/bin/shqui pointent généralement vers bash, quand ils devraient avoir #!/bin/bashparce qu'ils utilisent des bashismes et d'autres comportements qui ne le feront pas travailler sur zshou dash.
bashet je suis zshen/bin
J'ai bash comme shell par défaut pour root. J'ai utilisé zsh pendant un certain temps, mais je suis ensuite retourné à bash . Le shell que vous utilisez n'a pas beaucoup d'importance.
Ce n'est qu'un problème, si plusieurs personnes ont un accès root. Dans ce cas, vous pouvez sélectionner un «dénominateur commun» qui est généralement bash, car il s'agit du shell le plus utilisé.
En ce qui concerne Solaris / illumos, la mini-FAQ Solaris Root Shell mentionne
Certains administrateurs système déconseillent toujours de modifier le shell racine sur
les systèmes Solaris. Demandez pourquoi et on vous dira peut-être que root a besoin d'un
shell lié statiquement qui ne dépend pas des
bibliothèques dynamiques sous / usr / lib. C'était vrai dans le passé, mais ce n'est pas
nécessairement le cas aujourd'hui. Solaris, lorsqu'il est correctement configuré, est comme n'importe quelle autre version d'Unix et peut prendre en charge n'importe quel shell que vous définissez, pour root ou tout autre compte.
Donc, oui, si vous utilisez Solaris ou illumos, c'est bien d'utiliser des shells autres que sh.
bash. J'ai démarré en mode mono-utilisateur pour corriger, mais cela ne fonctionnait que parce qu'il/bin/shétait toujours lié àFBSDfork debourneet nonbash.