Puis-je avoir certains paramètres qui sont universels pour tous mes utilisateurs ?
Réponses
Trop de publicités?Ainsi que /etc/profile
que d'autres ont mentionné, certains systèmes Linux utilisent maintenant un répertoire /etc/profile.d/
; tout .sh
Les fichiers qui s'y trouvent seront trouvés par /etc/profile
. C'est un peu plus propre de garder votre environnement personnalisé dans ces fichiers que de simplement éditer /etc/profile
.
Si tous les services de connexion utilisent PAM et tous les services de connexion ont session required pam_env.so
dans leurs /etc/pam.d/*
alors toutes les sessions de connexion auront certaines variables d'environnement définies comme spécifié dans le fichier pam_env
Le fichier de configuration de l'entreprise.
Sur la plupart des distributions modernes de Linux, tout cela est présent par défaut - il suffit d'ajouter les variables d'environnement globales souhaitées dans le champ /etc/security/pam_env.conf
.
Cela fonctionne indépendamment du shell de l'utilisateur, et fonctionne également pour les connexions graphiques (si xdm/kdm/gdm/entrance/ est configuré de cette manière).
Étonnamment, Unix et Linux n'ont pas vraiment d'endroit pour définir des variables d'environnement globales. Le mieux que vous puissiez faire est de faire en sorte qu'un shell spécifique ait une initialisation spécifique au site.
Si vous le mettez dans /etc/profile
qui prendra soin des choses pour la plupart des utilisateurs de shells compatibles avec Posix. C'est probablement "suffisant" pour des objectifs non critiques.
Mais toute personne ayant un csh
ou tcsh
la coquille ne le verra pas, et je ne crois pas csh
a un fichier d'initialisation global.
Quelques extraits intéressants de la page de manuel de bash :
Lorsque bash est invoqué en tant qu'interpréteur de interactif, ou en tant qu'interpréteur de commandes non interactif avec l'option
--login
option, il lit et exécute d'abord les commandes du du fichier/etc/profile
si ce fichier existe. Après avoir lu ce fichier, il recherche~/.bash_profile
,~/.bash_login
et~/.profile
dans cet ordre dans cet ordre, et lit et exécute les commandes à partir de la première qui existe et qui est lisible. Le site--noprofile
L'option peut être utilisée au démarrage du shell pour inhiber ce comportement.
...
Lorsqu'un interactive qui n'est pas un shell de est lancé, bash lit et exécute les commandes de/etc/bash.bashrc
et~/.bashrc
si ces fichiers existent. Ceci peut être empêché par l'utilisation de l'option--norc
option. Le site--rcfile
L'option "file" forcera bash à lire et exécuter les commandes à partir de au lieu de/etc/bash.bashrc
et~/.bashrc
.
Jetez donc un coup d'œil à /etc/profile
ou /etc/bash.bashrc
ces fichiers sont les bons endroits pour les paramètres globaux. Mettez quelque chose comme ceci dans ces fichiers pour configurer une variable d'environnement :
export MY_VAR=xxx
Chaque processus fonctionnant sous le noyau Linux reçoit son propre environnement, unique, qu'il hérite de son parent. Dans ce cas, le parent sera soit un shell lui-même (qui génère un sous shell), soit le programme 'login' (sur un système typique).
Comme l'environnement de chaque processus est protégé, il n'est pas possible d'injecter une variable d'environnement dans chaque processus en cours d'exécution. Ainsi, même si vous modifiez le profil par défaut de l'interpréteur de commandes .rc /, cette modification n'entrera pas en vigueur avant que chaque processus ne se termine et ne recharge ses paramètres de démarrage.
Regardez dans /etc/ pour modifier les variables de démarrage par défaut pour un shell particulier. Sachez simplement que les utilisateurs peuvent les modifier (et le font souvent) dans leurs paramètres individuels.
Unix est conçu pour obéir à l'utilisateur, dans certaines limites.
NB : Bash n'est pas le uniquement sur votre système. Faites attention à ce vers quoi le lien symbolique /bin/sh pointe réellement. Sur de nombreux systèmes, il peut s'agir de tableau de bord qui est (par défaut, sans invocation spéciale) POSITIVEMENT correct. Par conséquent, vous devez prendre soin de modifier les deux ou les scripts qui commencent par /bin/sh n'hériteront pas de vos valeurs par défaut globales. De même, veillez à éviter la syntaxe qui ne fait que bash comprend lors de l'édition des deux, aka avoiding bashisms
.