Come impostare le variabili di ambiente a livello di sistema su OS X Mavericks

Il file corretto, precedente a Mavericks, era ~/.MacOSX/environment.plist . Questo non è più supportato.

In Darwin, e quindi in Mac OS X, il posto giusto per impostarli è in /etc/launchd.conf da applicare a tutti i processi; se si riferiscono specificamente alle shell utente, utilizzare invece i file di shell appropriati, a seconda della shell in questione. Visualizza le pagine man launchd.conf e launchctl per ulteriori informazioni.

Detto questo ...

Se il tuo obiettivo è specificamente quello di vederle applicate per le sessioni ssh, devi essere consapevole che ssh, per ragioni di sicurezza, non applica le variabili di ambiente in questo modo. Infatti una sessione ssh normalmente riceve dal sistema operativo un insieme molto più restrittivo di variabili d'ambiente in quanto non è quella che è conosciuta come una shell "login" o "interattiva", è classificata come una shell "non interattiva". (Vedere man bash per ulteriori informazioni sui tipi di shell.) Il modo in cui ssh gestisce le variabili di ambiente è ben trattato nei documenti ssh / sshd e nelle pagine man.

Per ssh - che è la propria shell, simile a bash - le variabili di ambiente per la sessione sono memorizzate in ~/.ssh/environment come equivalente per utente di impostazione di queste per bash o csh, ecc nei relativi file di avvio. Questo è probabilmente il punto in cui si desidera impostare le variabili ENV per le sessioni ssh dell'utente, sebbene non si specifichi il motivo per cui si sta cercando di assegnare ENV a livello globale nel post originale, il che sarebbe stato utile per fornire una soluzione. Ti suggerisco di impostarli esplicitamente su un utente per utente per mantenere la sicurezza adeguata in base a ciascun account rispettando la best practice di privilegio / attributo meno restrittiva.

Se per qualche motivo desideri ignorare le implicazioni sulla sicurezza di questo, imposta PermitUserEnvironment nelle tue ssh configs. Notare che questo è disabilitato se UseLogin è abilitato. IMPORTANTE: rendi conto che ciò significa che gli account utente impostati per utilizzare /bin/false come la loro shell, il metodo tipico per disabilitare un account utente, ora possono potenzialmente aggirare questa restrizione e potrebbero ora diventare attivi, il che è pericoloso. Molti account sono impostati per utilizzare /bin/false come shell come aspettativa di sicurezza.

La linea di fondo è che non dovresti farlo globalmente e aspettarti che ssh propaghi ENV per motivi di sicurezza. La tua domanda è, in effetti, chiedendo di proposito come sconfiggere diversi meccanismi che esistono per ragioni di sicurezza.

Se utilizzi bash , l'impostazione delle variabili di ambiente in /etc/profile verrà applicata a tutti gli utenti.

Dal manuale bash su OS X Mavericks , con la mia enfasi (questo non è cambiato rispetto alle versioni precedenti):

When bash is invoked as an interactive login shell, or as a non-interactive shell with the --login option, it first reads and executes commands from the file /etc/profile, if that file exists. After reading that file, it looks for ~/.bash_profile, ~/.bash_login, and ~/.profile, in that order, and reads and executes commands from the first one that exists and is readable.
...
If bash is invoked with the name sh, it tries to mimic the startup behavior of historical versions of sh as closely as possible, while conforming to the POSIX standard as well. When invoked as an inter-active interactive active login shell, or a non-interactive shell with the --login option, it first attempts to read and execute commands from /etc/profile and ~/.profile, in that order.

Ciò che tu (e chiunque altro abbia trovato questa domanda) quasi sicuramente stai cercando è il seguente percorso:

/private/etc/paths

Puoi sempre inserire le tue modifiche nella /private/etc/paths.d se vuoi evitare di cambiare il documento di configurazione "percorsi" predefinito del sistema principale, ma poi verranno aggiunte alla fine della tua variabile $PATH , quindi se vuoi per aggiungere directory nella parte anteriore di $PATH (per sovrascrivere le utilità di sistema predefinite, ad esempio), devi solo modificare il file /private/etc/paths principale e aggiungerle all'inizio dell'elenco. Ad esempio, lo faccio per una cartella in cui memorizzo una manciata di script che ho creato io, insieme ad alcune utilità chiave, come mozjpeg , che voglio che il sistema usi sempre al posto dei valori predefiniti con cui viene ( in questo modo tutti i file jpeg salvati da quasi tutti i programmi vengono compressi automaticamente fino al 10% in più rispetto al normale sistema cjpeg che li comprime - ho letto che il motivo per cui non è predefinito sulla maggior parte dei sistemi è perché è molto più lento, ma quando parli di qualcosa come 0,14 secondi rispetto a 0,02 secondi, il "più lento di un fattore 7" non significa molto di nulla ... presumendo che non si tratti di un server, ovviamente). So che molte persone probabilmente metteranno in guardia sul potenziale "pericolo" di apportare modifiche così profondamente nel sistema, ma direi che se stai cercando una risposta come questa, probabilmente ne sai abbastanza da gestire qualsiasi denominazione di utilità i conflitti che potrebbero potenzialmente sorgere in futuro e semplicemente apportare le modifiche in /private/etc/paths li propagano realmente a tutti gli utenti / login / istanze possibili - tutti i programmi, le shell, ecc. utilizzeranno i percorsi in quel file per costruire la base della loro $PATH variabile.

Per essere onesti, sono abbastanza sorpreso che nessun altro qui ne abbia parlato. Tutto ciò che ha a che fare con il lancio e le distrazioni su usi specifici di SSH ... questa è la soluzione che chiunque cerchi per questo problema di base è davvero alla ricerca - la soluzione pulita, diretta all'origine, sempre funzionante.

A proposito, nel caso ve lo stiate chiedendo, su OS X /etc è semplicemente un collegamento simbolico a /private/etc , quindi potreste altrettanto facilmente fare sudo nano /etc/paths e arrivare allo stesso posto esatto. Il percorso sopra riportato è solo il percorso effettivo completo del file.

Ho avuto un problema simile, in particolare ~/.bashrc non è stato originato quando mi sono collegato al mio computer tramite SSH. Ho scoperto che la modifica di un'impostazione di configurazione per SSHd ha funzionato. Forse il tuo problema riguarda anche il demone SSH?

Modificare il file di configurazione del servizio SSH come segue:

# /etc/sshd_config
PermitUserEnvironment yes

Quindi riavvia il servizio di accesso remoto in Preferenze di Sistema > Condivisione.

Dalla manpage sshd_config :

 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.

(Nel caso in cui aiuti, ho scritto come ho provato questo nella mia wiki personale )

Se altri utenti cercano come impostare le variabili di ambiente per i processi avviati da una normale sessione di accesso grafica, puoi utilizzare /etc/launchd.conf . Ad esempio aggiungi /usr/local/bin al percorso predefinito, esegui

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

e riavvia per applicare le modifiche. Un altro modo per applicare le modifiche è eseguire launchctl</etc/launchd.conf;sudo launchctl</etc/launchd.conf e riavviare i processi.

Hmm ... A partire da Mac OS X 10.10.5 e probabilmente prima, man -s5 launchd.conf ci dice: " launchd.conf is no longer respected by the system. " Ho troppe cose in corso in questo momento per mettere una variabile dummy nel file e ricominciare a vedi se funziona davvero o no, dopotutto, ma la documentazione dice che non dovrebbe funzionare.

Sono abbastanza sicuro che non lo farà. Fai man launchctl e vedrai: " The /etc/launchd.conf file is no longer consulted for subcommands to run during early boot time; this functionality was removed for security considerations. "

Ciò che puoi fare è mettere tutte le variabili d'ambiente che vuoi essere global-ish in qualche file, forse chiamato environment in accordo con Linux, o (nel caso in cui Apple decida di fare qualcosa con quello più tardi - non si sa mai) environment.conf , come ho fatto io, quindi fonte questo tramite /etc/profile :

if [ -f /etc/environment.conf ]; then
   source /etc/environment.conf
fi

o, se preferisci il formato compatto:

if [ -f /etc/environment.conf ]; then . /etc/environment.conf; fi

Se usi una shell diversa da bash, e usa la stessa sintassi di impostazione delle variabili di bash (come fa zsh, penso), dovrai anche cercare questo file da quella file rc di sistema a livello di shell (ad es. /etc/zshrc ). Se utilizzi una shell che utilizza una sintassi diversa, ad es. tcsh, dovrai mantenere un file simile per quella shell e importarlo dal file rc di sistema della shell (ad esempio /etc/csh.cshrc per tcsh), o meglio ancora creare uno script che lo auto-genera, quindi solo devi modificare un file per aggiungere / modificare le variabili. Questo non è il posto giusto per un simile tutorial; alcuni secondi su Google hanno mostrato come convertire [t] csh esportazioni variabili in sintassi bash, in link , quindi probabilmente c'è qualcosa che può andare nella direzione opposta.

È stata la mia esperienza che Mac OS X si sta spostando sempre più lontano dal comportamento prevedibile del file rc. A partire da almeno 10.8, non sembra più caricare /etc/rc.common , /etc/rc.conf o /etc/rc.<anything> , né (almeno 10.9) caricherà /etc/bash.bashrc per le shell interattive non di rete (che sicuramente dovrebbe fare, solo come se carica ~/.bashrc per loro, ancora, a partire da 10.10). Poi di nuovo ho Fink, MacPorts e Homebrew che installano tutto, quindi forse uno di loro sta interferendo con il comportamento predefinito del dotfile. YMMV.