Comment définir les variables d'environnement du système sous OS X Mavericks ?

Le fichier correct, avant Mavericks, était ~/.MacOSX/environment.plist . Cette fonction n'est plus prise en charge.

Dans Darwin, et donc dans Mac OS X, l'endroit approprié pour les définir est dans /etc/launchd.conf pour s'appliquer à tous les processus ; s'il s'agit d'un shell utilisateur spécifique, utilisez plutôt les fichiers shell appropriés, en fonction du shell en question. Voir le launchd.conf y launchctl pages de manuel pour en savoir plus.

Cela dit...

Si votre objectif est de voir ces variables appliquées aux sessions ssh, vous devez savoir que ssh, pour des raisons de sécurité, n'applique pas les variables d'environnement de cette manière. En fait, une session ssh reçoit normalement un ensemble de variables d'environnement beaucoup plus restrictif de la part du système d'exploitation, car il ne s'agit pas de ce que l'on appelle un shell "login" ou "interactif", il est classé comme un shell "non-interactif". (Voir man bash pour en savoir plus sur les types de shells). La façon dont ssh gère les variables d'environnement est bien couverte dans la documentation et les pages de manuel de ssh/sshd.

Pour ssh -- qui est son propre shell, semblable à bash -- les variables d'environnement de la session sont stockées dans le répertoire ~/.ssh/environment comme l'équivalent par utilisateur de la définition de ces paramètres pour bash ou csh, etc. dans leurs fichiers de lancement respectifs. C'est probablement là que vous voulez définir vos variables ENV pour vos sessions ssh utilisateur, bien que vous ne détailliez pas pourquoi vous cherchez à assigner des ENV globalement dans votre message original, ce qui aurait été utile pour fournir une solution. Je vous suggère de les définir explicitement sur une base utilisateur par utilisateur afin de maintenir une sécurité appropriée basée sur chaque compte respectif en suivant la meilleure pratique du privilège/attribut le moins restrictif.

Si, pour une raison ou une autre, vous souhaitez ignorer les implications en matière de sécurité, alors définissez les paramètres suivants PermitUserEnvironment dans votre configuration ssh. Notez que ceci est désactivé si UseLogin est activé. IMPORTANT : Sachez que cela signifie que les comptes d'utilisateur configurés pour utiliser les services de /bin/false comme leur shell - la méthode typique pour désactiver un compte d'utilisateur - peut maintenant potentiellement contourner cette restriction et devenir actif, ce qui est dangereux. De nombreux comptes sont configurés pour utiliser /bin/false comme leur coquille en tant qu'attente de sécurité.

En résumé, vous ne devriez pas faire cela globalement et attendre de ssh qu'il propage ENV pour des raisons de sécurité. Votre question est, en fait, délibérément posée sur la façon de vaincre plusieurs mécanismes qui existent pour des raisons de sécurité.

Si vous utilisez bash puis en définissant les variables d'environnement dans /etc/profile s'appliquera à tous les utilisateurs.

De la bash manuel sur OS X Mavericks avec mon accent (ceci n'a pas changé par rapport aux versions précédentes) :

Lorsque bash est invoqué en tant que shell de connexion interactif, ou en tant que shell non interactif avec l'option --login, il lit et exécute d'abord les commandes 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, et lit et exécute les commandes du premier qui existe et qui est lisible.
...
Si bash est invoqué avec le nom sh, il essaie d'imiter le plus fidèlement possible le comportement au démarrage des versions historiques de sh, tout en se conformant à la norme POSIX. Lorsqu'il est invoqué en tant que shell interactif interactif de connexion, ou en tant que shell non interactif avec l'option --login, il essaie d'abord de lire et d'exécuter les commandes de /etc/profile et ~/.profile, dans cet ordre.

Ce que vous (et toute autre personne ayant trouvé cette question) recherchez presque certainement est le chemin suivant :

/private/etc/paths

Vous pouvez toujours mettre vos modifications dans le /private/etc/paths.d si vous souhaitez éviter de modifier le document de configuration des "chemins" par défaut du système principal, mais ils seront alors ajoutés à la fin de votre fichier $PATH donc si vous voulez ajouter des répertoires à l'avant de la variable $PATH (pour remplacer les utilitaires système par défaut, par exemple), il vous suffit de modifier le fichier principal de l'application /private/etc/paths et les ajouter en haut de la liste. Par exemple, je fais cela pour un dossier dans lequel je stocke une poignée de scripts que j'ai créés moi-même, ainsi que quelques utilitaires clés, tels que mozjpeg J'ai lu que la raison pour laquelle il n'est pas utilisé par défaut sur la plupart des systèmes est parce qu'il est beaucoup plus lent, mais quand vous parlez de quelque chose comme 0. J'ai lu que la raison pour laquelle il n'est pas utilisé par défaut sur la plupart des systèmes est qu'il est beaucoup plus lent, mais quand on parle de quelque chose comme 0,14 seconde par opposition à 0,02 seconde, le "plus lent d'un facteur 7" ne signifie pas grand chose... en supposant qu'il ne s'agit pas d'un serveur, bien sûr.) Je sais que beaucoup de gens vont probablement mettre en garde contre le "danger" potentiel de faire des modifications aussi profondément dans le système, mais je dirais que si vous cherchez une réponse comme celle-ci, vous en savez probablement assez pour gérer tout conflit de nom d'utilitaire qui pourrait potentiellement survenir à l'avenir, et simplement faire vos modifications dans le fichier /private/etc/paths les propage réellement à tous les utilisateurs/logins/instances possibles - tous les programmes, shells, etc. utiliseront les chemins dans ce fichier pour construire la base de leur $PATH variable.

Pour être honnête, je suis assez surpris que personne d'autre ici ne l'ait encore mentionné. Tout ce bazar avec launchd et ces distractions à propos des utilisations spécifiques à SSH... c'est la solution que toute personne cherchant ce problème de base recherche vraiment - la solution propre, directe, qui fonctionne toujours.

Au fait, au cas où vous vous poseriez la question, sur OS X /etc est simplement un lien symbolique vers /private/etc donc vous pourriez tout aussi bien faire sudo nano /etc/paths et arriver au même endroit exact. Le chemin ci-dessus est juste le chemin réel complet du fichier.

J'ai eu un problème similaire, à savoir ~/.bashrc ne provenait pas lorsque je me connectais à ma machine via SSH. J'ai découvert que la modification d'un paramètre de configuration de SSHd faisait l'affaire. Peut-être votre problème réside-t-il également dans le démon SSH ?

Modifiez le fichier de configuration du service SSH comme suit :

# /etc/sshd_config
PermitUserEnvironment yes

Redémarrez ensuite le service Connexion à distance dans Préférences système > Partage.

De la sshd_config page de manuel :

 PermitUserEnvironment
         Specifies whether ~/.ssh/environment and environment= options in
         ~/.ssh/authorized_keys are processed by sshd(8).  The default is
         ``no''.  Enabling environment processing may enable users to
         bypass access restrictions in some configurations using mecha-
         nisms such as LD_PRELOAD.

(Au cas où cela vous aiderait, j'ai écrit comment j'ai testé cela sur mon site web. wiki personnel )

Si d'autres personnes cherchent comment définir les variables d'environnement pour les processus lancés à partir d'une session de connexion graphique normale, vous pouvez utiliser /etc/launchd.conf . Pour, par exemple, ajouter /usr/local/bin dans le chemin par défaut, exécutez

echo setenv PATH /usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin|sudo tee -a /etc/launchd.conf

et redémarrez pour appliquer les changements. Une autre façon d'appliquer les changements est d'exécuter launchctl</etc/launchd.conf;sudo launchctl</etc/launchd.conf et relancer les processus.