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

Prima usavamo /etc/environmentimpostare variabili di ambiente a livello di sistema su Mountain Lion. Tuttavia, sembra che questo file non sia più letto.

Idealmente, la soluzione dovrebbe applicarsi a tutti gli utenti e abbiamo bisogno che funzioni con le sessioni della console ssh. Quindi abbiamo bisogno che funzioni

ssh user@mavericks-machine 'echo $MY_ENV_VAR'

Finora abbiamo provato:

• /etc/launchd.conf

  Funziona per tutti gli utenti, ma si applica solo alle applicazioni "con finestre", vale a dire funziona in Terminal, ma non in una sessione ssh.

• ~/.profile, ~/.bash_profileEcc

  Si applica solo alle conchiglie

Eventuali suggerimenti?

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

In Darwin, e quindi in Mac OS X, il posto giusto per impostarli è /etc/launchd.confda applicare a tutti i processi; se si tratta specificamente di shell utente, utilizzare invece i file shell appropriati, a seconda della shell in questione. Vedi le pagine man launchd.confe launchctlper ulteriori informazioni.

Detto ciò...

Se il tuo obiettivo è specificamente quello di vederli applicati per le sessioni ssh, devi essere consapevole che ssh, per motivi di sicurezza, non applica le variabili di ambiente in questo modo. In effetti una sessione ssh normalmente riceve un set molto più restrittivo di variabili d'ambiente dal sistema operativo in quanto non è ciò che è noto come shell "login" o "interattivo", è classificato come shell "non interattivo". (Vedi man bashdi più sui tipi di shell.) Il modo in cui ssh gestisce le variabili di ambiente è ben coperto 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 archiviate ~/.ssh/environmentcome l'equivalente per utente di impostarle per bash o csh, ecc nei relativi file di avvio. Questo è probabilmente il punto in cui desideri impostare le variabili ENV per le tue sessioni ssh dell'utente, anche se non specifichi perché stai cercando di assegnare ENV a livello globale nel tuo post originale, il che sarebbe stato utile nel fornire una soluzione. Ti suggerirei di impostarli esplicitamente su base utente per utente per mantenere la sicurezza adeguata in base a ciascun rispettivo account seguendo le migliori pratiche di privilegio / attributo meno restrittive.

Se per qualche motivo desideri ignorare le implicazioni di sicurezza di ciò, imposta le PermitUserEnvironmenttue configurazioni ssh. Si noti che questo è disabilitato se UseLoginè abilitato. IMPORTANTE: rendersi conto che ciò significa che gli account utente impostati per l'uso /bin/falsecome shell - il metodo tipico per disabilitare un account utente - ora possono potenzialmente aggirare questa restrizione e ora possono diventare attivi, il che è pericoloso. Molti account sono impostati per essere utilizzati /bin/falsecome shell come aspettativa di sicurezza.

In conclusione, non dovresti farlo a livello globale e aspettarti che ssh propaghi ENV per motivi di sicurezza. La tua domanda è, effettivamente, volutamente chiedendo come sconfiggere diversi meccanismi esistenti per motivi di sicurezza.

Se si utilizza bash, l'impostazione delle variabili di ambiente /etc/profileverrà applicata a tutti gli utenti.

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

Quando bash viene invocato come shell di login interattiva o come shell non interattiva con l'opzione --login, legge prima ed esegue i comandi dal file / etc / profile, se quel file esiste. Dopo aver letto quel file, cerca ~ / .bash_profile, ~ / .bash_login e ~ / .profile, in quell'ordine, e legge ed esegue i comandi dal primo che esiste ed è leggibile.
... e ~ / .profile, in questo ordine.
Se bash viene invocato con il nome sh, cerca di imitare il comportamento di avvio delle versioni storiche di sh il più vicino possibile, pur essendo conforme allo standard POSIX. Quando viene invocato come shell di accesso attiva interattiva interattiva o come shell non interattiva con l'opzione --login, tenta innanzitutto di leggere ed eseguire comandi da / etc / profile

Quello che tu (e chiunque altro trovi questa domanda) state quasi sicuramente cercando è il seguente percorso:

/private/etc/paths

Puoi sempre inserire le tue modifiche /private/etc/paths.dse vuoi evitare di cambiare il documento di configurazione "percorsi" predefinito del sistema principale, ma poi verranno aggiunte alla fine della tua $PATHvariabile, quindi se vuoi aggiungere directory all'inizio di $PATH(a sovrascrivere le utilità di sistema predefinite, ad esempio), dovrai solo modificare il principale/private/etc/paths file stesso e aggiungerli in cima all'elenco. Ad esempio, lo faccio per una cartella in cui memorizzo una manciata di script che ho creato da solo, insieme ad alcune utilità chiave, comemozjpeg, che voglio che il sistema utilizzi sempre al posto delle impostazioni predefinite (in questo modo tutti i file jpeg salvati praticamente da qualsiasi programma vengono compressi automaticamente fino al 10% in più rispetto a quelli che la normale utility di sistema cjpeg li comprime - I ' ho letto che il motivo per cui non è predefinito sulla maggior parte dei sistemi è perché è molto più lento, ma quando parli qualcosa come 0,14 secondi anziché 0,02 secondi, il "rallentamento di un fattore 7" non significa molto di tutto ... supponendo che questo non sia un server, ovviamente). So che molte persone probabilmente avvertiranno del potenziale "pericolo" di apportare modifiche così profonde nel sistema, ma direi che se stai cercando una risposta come questa, probabilmente conosci abbastanza per affrontare qualsiasi denominazione di utilità conflitti che potrebbero potenzialmente insorgere in futuro,/private/etc/pathsli propaga davvero a tutti gli utenti / accessi / istanze possibili: tutti i programmi, le shell, ecc. useranno i percorsi in quel file per costruire la base della loro $PATHvariabile.

Ad essere sincero, sono abbastanza sorpreso che nessun altro qui lo abbia ancora menzionato. Tutta quella confusione con launchd e distrazioni sugli usi specifici di SSH ... questa è la soluzione che chiunque cerca questo problema di base è davvero alla ricerca: la soluzione pulita, diretta alla fonte, sempre funzionante.

A proposito, nel caso ti stia chiedendo, su OS X /etcè semplicemente un collegamento simbolico a /private/etc, quindi potresti fare altrettanto facilmente sudo nano /etc/pathse arrivare allo stesso posto esatto. Il percorso sopra è solo il percorso effettivo completo del file.

Ho avuto un problema simile, in particolare ~/.bashrcnon provenivo da quando mi sono collegato alla mia macchina tramite SSH. Ho scoperto che cambiare un'impostazione di configurazione per SSHd ha funzionato. Forse il tuo problema risiede anche nel demone SSH?

Modificare il file di configurazione del servizio SSH come segue:

# /etc/sshd_config
PermitUserEnvironment yes

Quindi riavviare il servizio Accesso remoto in Preferenze di Sistema> Condivisione.

Dalla sshd_configmanpage:

 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 mi aiuti, ho scritto come l'ho provato sul mio wiki personale )

Se altri cercano come impostare le variabili di ambiente per i processi avviati da una normale sessione di accesso grafica, è possibile utilizzare /etc/launchd.conf. Ad esempio, aggiungere /usr/local/binal percorso predefinito, eseguire

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

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

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

Sono abbastanza sicuro che non lo farà. Fai man launchctle 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."

Quello che puoi fare è mettere tutte le variabili d'ambiente che vuoi essere globali in qualche file, forse chiamate environmentin linea con Linux, o (nel caso in cui Apple decida di fare qualcosa in seguito - non lo sai mai) environment.conf, come ho fatto io, quindi procuratelo via /etc/profile:

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

oppure, se si preferisce il formato compatto:

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

Se usi qualche altra shell oltre a bash, e usa la stessa sintassi a impostazione variabile di bash (come fa zsh, credo), dovrai anche estrarre questo file dal file rc dell'intero sistema della shell (ad es /etc/zshrc.). Se si utilizza una shell che utilizza una sintassi diversa, ad esempio tcsh, è necessario mantenere un file simile per quella shell e originarlo dal file rc dell'intero sistema della shell (ad esempio /etc/csh.cshrcper tcsh), o meglio creare uno script che lo genera automaticamente, quindi devi solo modificare un file per aggiungere / cambiare variabili. Questo non è il posto giusto per un simile tutorial; alcuni secondi su Google hanno scoperto come convertire [t] esportazioni di variabili csh in sintassi bash, su https://stackoverflow.com/questions/2710790/how-to-source-a-csh-script-in-bash-to -set-the-ambiente, quindi probabilmente c'è qualcosa disponibile per andare nell'altra direzione.

È stata la mia esperienza che Mac OS X si sta allontanando sempre di più dal prevedibile comportamento dei file rc. Come di almeno 10,8, non sembra più a caricare /etc/rc.common, /etc/rc.confo /etc/rc.<anything>, né (almeno dal 10,9) Sarà caricare /etc/bash.bashrcper le shell nonlogin interattive (che certamente dovrebbe fare, proprio come i carichi ~/.bashrcper loro, ancora, come di 10,10) . Poi di nuovo ho installato Fink, MacPorts e Homebrew, quindi forse uno di loro sta interferendo con il comportamento dotfile predefinito. YMMV.