Jak ustawić ogólnosystemowe zmienne środowiskowe w OS X Mavericks

Kiedyś używaliśmy do /etc/environmentustawiania ogólnosystemowych zmiennych środowiskowych w Mountain Lion. Wygląda jednak na to, że ten plik nie jest już czytany.

Idealnie rozwiązanie powinno mieć zastosowanie do wszystkich użytkowników i potrzebujemy go do pracy z sesjami konsoli ssh. Potrzebujemy więc tego do pracy

ssh user@mavericks-machine 'echo $MY_ENV_VAR'

Do tej pory próbowaliśmy:

• /etc/launchd.conf

  Działa dla wszystkich użytkowników, ale dotyczy tylko aplikacji „okienkowych”, tzn. Działa w terminalu, ale nie w sesji ssh.

• ~/.profile, ~/.bash_profileItd.

  Dotyczy tylko pocisków

Jakieś sugestie?

Prawidłowy plik, przed Mavericks, był ~/.MacOSX/environment.plist. To nie jest już obsługiwane.

W Darwin, a zatem w Mac OS X, właściwym miejscem do ich ustawienia jest /etc/launchd.confzastosowanie do wszystkich procesów; jeśli dotyczy konkretnie powłok użytkownika, zamiast tego użyj odpowiednich plików powłoki, w zależności od powłoki. Zobacz strony launchd.confi launchctlman, aby uzyskać więcej.

To mówi...

Jeśli Twoim celem jest, aby były one stosowane do sesji ssh, musisz mieć świadomość, że ssh, ze względów bezpieczeństwa, nie stosuje zmiennych środowiskowych w ten sposób. W rzeczywistości sesja ssh zwykle otrzymuje znacznie bardziej restrykcyjny zestaw zmiennych środowiskowych z systemu operacyjnego, ponieważ nie jest to tak zwana powłoka „login” lub „interaktywna”, jest klasyfikowana jako „nieinteraktywna” powłoka. (Zobacz man bashwięcej na temat typów powłok.) Sposób, w jaki ssh obsługuje zmienne środowiskowe, jest dobrze opisany w dokumentach i podręcznikach ssh / sshd.

W przypadku ssh - która jest jego własną powłoką, podobnie jak bash - zmienne środowiskowe dla sesji są przechowywane w ~/.ssh/environmentekwiwalencie użytkownika dla ustawienia ich dla bash lub csh itp. W odpowiednich plikach uruchamiania. Prawdopodobnie w tym miejscu chcesz ustawić zmienne ENV dla sesji użytkownika ssh, choć nie podajesz szczegółowo, dlaczego chcesz przypisywać ENV globalnie do oryginalnego postu, co byłoby pomocne w zapewnieniu rozwiązania. Sugeruję, aby ustawić je jawnie dla poszczególnych użytkowników w celu utrzymania odpowiedniego bezpieczeństwa w oparciu o każde konto zgodnie z najlepszą praktyką w zakresie najmniej restrykcyjnych uprawnień / atrybutów.

Jeśli z jakiegoś powodu chcesz zignorować wpływ tego na bezpieczeństwo, ustaw PermitUserEnvironmentw konfiguracjach ssh. Pamiętaj, że jest to wyłączone, jeśli UseLoginjest włączone. WAŻNE: Zdaj sobie sprawę, że oznacza to, że konta użytkowników ustawione /bin/falsejako używane jako ich powłoka - typowa metoda wyłączania konta użytkownika - mogą teraz potencjalnie obejść to ograniczenie i mogą stać się aktywne, co jest niebezpieczne. Wiele kont jest używanych /bin/falsejako powłoka jako oczekiwanie bezpieczeństwa.

Najważniejsze jest to, że nie powinieneś robić tego globalnie i oczekiwać, że ssh rozpowszechni ENV ze względów bezpieczeństwa. Twoje pytanie polega na celowym pytaniu, jak pokonać kilka mechanizmów, które istnieją ze względów bezpieczeństwa.

Jeśli używasz bash, to ustawienie zmiennych środowiskowych /etc/profilebędzie miało zastosowanie do wszystkich użytkowników.

Z bashpodręcznika na temat OS X Mavericks , z moim naciskiem (nie zmieniło się to w stosunku do poprzednich wersji):

Kiedy bash jest wywoływany jako interaktywna powłoka logowania lub jako nieinteraktywna powłoka z opcją --login, najpierw czyta i wykonuje polecenia z pliku / etc / profile, jeśli plik ten istnieje. Po odczytaniu tego pliku szuka ~ / .bash_profile, ~ / .bash_login i ~ / .profile, w tej kolejności, i odczytuje i wykonuje polecenia z pierwszego, który istnieje i jest czytelny.
...
Jeśli bash zostanie wywołany z nazwą sh, próbuje naśladować zachowanie startowe historycznych wersji sh tak dokładnie, jak to możliwe, przy jednoczesnym zachowaniu zgodności ze standardem POSIX. Wywoływany jako interaktywna interaktywna powłoka aktywnego logowania lub nieinteraktywna powłoka z opcją --login, najpierw próbuje odczytać i wykonać polecenia z / etc / profile i ~ / .profile, w tej kolejności.

To, czego Ty (i ktokolwiek znajdzie to pytanie) prawie na pewno szuka, jest następująca ścieżka:

/private/etc/paths

Zawsze możesz wprowadzić swoje zmiany do, /private/etc/paths.djeśli chcesz uniknąć zmiany głównego dokumentu konfiguracji domyślnych ścieżek, ale wtedy zostaną one dodane na końcu $PATHzmiennej, więc jeśli chcesz dodać katalogi z przodu $PATH(do zastąpić domyślne narzędzia systemowe, na przykład), wystarczy edytować główny /private/etc/pathsplik i dodać je na początku listy. Na przykład robię to dla folderu, w którym przechowuję garść skryptów, które sam stworzyłem, wraz z kilkoma kluczowymi narzędziami, takimi jakmozjpeg, że chcę, aby system zawsze używał zamiast domyślnych ustawień (w ten sposób wszystkie pliki jpeg zapisane przez prawie dowolny program są automatycznie kompresowane nawet o 10% więcej niż zwykłe systemowe narzędzie cjpeg je skompresuje - ja ' przeczytałem, że powodem, dla którego nie jest domyślny w większości systemów, jest to, że jest on znacznie wolniejszy, ale kiedy mówisz o czymś takim, jak 0,14 sekundy zamiast 0,02 sekundy, „wolniej o współczynnik 7” tak naprawdę nie znaczy wiele czegokolwiek ... zakładając, że to nie jest serwer, oczywiście). Wiem, że wiele osób prawdopodobnie ostrzega przed potencjalnym „niebezpieczeństwem” dokonania głębokich edycji w systemie, ale powiedziałbym, że jeśli szukasz takiej odpowiedzi, prawdopodobnie wiesz wystarczająco dużo, aby poradzić sobie z każdą nazwą narzędzia konflikty, które mogą potencjalnie powstać w przyszłości,/private/etc/pathsnaprawdę propaguje je do wszystkich użytkowników / loginów / instancji - wszystkie programy, powłoki itp. użyją ścieżek w tym pliku, aby zbudować bazę swojej $PATHzmiennej.

Szczerze mówiąc, jestem zaskoczony, że nikt tu jeszcze o tym nie wspominał. Całe to zamieszanie związane z uruchomieniem i rozproszeniem uwagi na temat zastosowań specyficznych dla SSH ... jest to rozwiązanie, którego naprawdę szuka każdy, kto szuka tego podstawowego problemu - czyste, proste do źródła, zawsze działające rozwiązanie.

Nawiasem mówiąc, w przypadku, gdy zastanawiasz się, w OS X /etcjest po prostu dowiązanie symboliczne /private/etc, dzięki czemu możesz równie łatwo zrobić sudo nano /etc/pathsto samo i dostać się w to samo miejsce. Powyższa ścieżka jest tylko pełną rzeczywistą ścieżką do pliku.

Miałem podobny problem, zwłaszcza że nie otrzymywałem ~/.bashrcźródła, gdy podłączałem się do mojego komputera przez SSH. Odkryłem, że zmiana ustawienia konfiguracji dla SSHd załatwiła sprawę. Być może twój problem dotyczy również demona SSH?

Zmodyfikuj plik konfiguracyjny usługi SSH w następujący sposób:

# /etc/sshd_config
PermitUserEnvironment yes

Następnie uruchom ponownie usługę logowania zdalnego w Preferencjach systemowych> Udostępnianie.

Z strony sshd_configpodręcznika:

 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.

(Jeśli to pomoże, napisałem, jak to przetestowałem na mojej osobistej wiki )

Jeśli inni szukają sposobu ustawiania zmiennych środowiskowych dla procesów rozpoczynanych od normalnej graficznej sesji logowania, możesz użyć /etc/launchd.conf. Aby na przykład dodać /usr/local/bindo domyślnej ścieżki, uruchom

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

i uruchom ponownie, aby zastosować zmiany. Innym sposobem na zastosowanie zmian jest uruchomienie launchctl</etc/launchd.conf;sudo launchctl</etc/launchd.confi ponowne uruchomienie procesów.

Hmm ... Począwszy od Mac OS X 10.10.5 i prawdopodobnie wcześniej, man -s5 launchd.confmówi nam: „ launchd.conf is no longer respected by the system.Mam teraz zbyt wiele rzeczy, aby umieścić zmienną fikcyjną w pliku i zrestartować, aby zobaczyć, czy to naprawdę działa, czy nie po wszystko, ale dokumentacja mówi, że to nie powinno działać.

Jestem pewien, że tak nie będzie. Zrób, man launchctla zobaczysz: „ The /etc/launchd.conf file is no longer consulted for subcommands to run during early boot time; this functionality was removed for security considerations.”

To, co możesz zrobić, to umieścić wszystkie zmienne środowiskowe, które mają być globalne, w jakimś pliku, być może wywoływanym environmentzgodnie z Linuksem lub (w przypadku, gdy Apple zdecyduje się coś z tym zrobić później - nigdy nie wiesz) environment.conf, tak jak ja, następnie zdobądź to poprzez /etc/profile:

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

lub, jeśli wolisz format kompaktowy:

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

Jeśli używasz innej powłoki niż bash i używa tej samej składni ustawiania zmiennych co bash (podobnie jak Zsh, myślę), musisz również pobrać ten plik z ogólnosystemowego pliku rc tej powłoki (np /etc/zshrc.). Jeśli używasz powłoki, która używa innej składni, np. Tcsh, musisz albo zachować podobny plik dla tej powłoki i pobrać go z ogólnosystemowego pliku rc powłoki (np. /etc/csh.cshrcDla tcsh), albo lepiej utworzyć skrypt który automatycznie go generuje, więc musisz edytować tylko jeden plik, aby dodać / zmienić zmienne. To nie jest miejsce na taki samouczek; kilka sekund w Google dowiedział się, jak przekonwertować [t] eksport zmiennych csh do składni bash, na https://stackoverflow.com/questions/2710790/how-to-source-a-csh-script-in-bash-to -Zestaw środowisko, więc prawdopodobnie jest coś, co można pójść w innym kierunku.

Z mojego doświadczenia wynika, że ​​Mac OS X odchodzi coraz bardziej od przewidywalnego zachowania pliku rc. Począwszy od co najmniej 10.8, nie wydaje się już ładować /etc/rc.common, /etc/rc.confani /etc/rc.<anything>też (ponieważ co najmniej 10.9) nie będzie ładował /etc/bash.bashrcinteraktywnych powłok nieloginowych (co z pewnością powinno działać, tak jak ładuje się ~/.bashrcdla nich, jednak od 10.10) . Z drugiej strony Fink, MacPorts i Homebrew instalują wszystkie rzeczy, więc może jeden z nich zakłóca domyślne zachowanie pliku kropkowego. YMMV.