Как установить общесистемные переменные среды на OS X Mavericks

Мы привыкли использовать /etc/environmentдля установки общесистемных переменных среды на Mountain Lion. Однако, кажется, этот файл больше не читается.

В идеале решение должно применяться ко всем пользователям, и нам нужно, чтобы оно работало с сеансами консоли ssh. Итак, нам нужно, чтобы это работало

ssh user@mavericks-machine 'echo $MY_ENV_VAR'

Пока что мы попробовали:

• /etc/launchd.conf

  Работает для всех пользователей, но применяется только к «оконным» приложениям, т.е. работает в Терминале, но не в сеансе ssh.

• ~/.profileи ~/.bash_profileт. д.

  Относится только к снарядам

Какие-либо предложения?

Правильный файл, до Mavericks, был ~/.MacOSX/environment.plist. Это больше не поддерживается.

В Дарвине, а следовательно, и в Mac OS X, правильное место для их установки - /etc/launchd.confэто применение ко всем процессам; если это относится конкретно к пользовательским оболочкам, вместо этого используйте соответствующие файлы оболочки, в зависимости от рассматриваемой оболочки. Смотрите страницы man launchd.confи launchctlman для получения дополнительной информации.

Это сказал ...

Если ваша цель состоит в том, чтобы увидеть, как они применяются для сессий ssh, вам нужно знать, что ssh по соображениям безопасности не применяет переменные среды таким образом. Фактически, сессия ssh обычно получает гораздо более ограниченный набор переменных среды от ОС, поскольку это не то, что называется «входной» или «интерактивной» оболочкой, а классифицируется как «неинтерактивная» оболочка. (См. man bashБольше о типах оболочки.) Способ, которым ssh обрабатывает переменные окружения, хорошо описан в документации ssh / sshd и на страницах man.

Для ssh, который является его собственной оболочкой, переменные окружения для сеанса, похожие на bash, хранятся в ~/.ssh/environmentкачестве эквивалента для каждого пользователя, устанавливая их для bash или csh и т. Д. В соответствующих файлах запуска. Вероятно, именно здесь вы хотите установить переменные ENV для пользовательских сессий ssh, хотя вы не знаете, почему вы хотите назначить ENV глобально в исходном посте, что могло бы помочь в поиске решения. Я бы посоветовал вам установить их явно для каждого пользователя в отдельности, чтобы обеспечить надлежащую безопасность для каждой соответствующей учетной записи, следуя рекомендациям по наименее ограничительным привилегиям / атрибутам.

Если по какой-то причине вы хотите игнорировать последствия этого для безопасности, установите их PermitUserEnvironmentв своих ssh-конфигурациях. Обратите внимание, что это отключено, если UseLoginвключено. ВАЖНО: Поймите, что это означает, что учетные записи пользователей, настроенные для использования в /bin/falseкачестве оболочки - типичный метод отключения учетной записи пользователя - теперь могут потенциально обойти это ограничение и теперь могут стать активными, что опасно. Многие учетные записи настроены на использование в /bin/falseкачестве оболочки в качестве ожидания безопасности.

Суть в том, что вы не должны делать это глобально и ожидать, что ssh будет распространять ENV по соображениям безопасности. Ваш вопрос, по сути, нарочно спрашивает, как победить несколько механизмов, которые существуют по соображениям безопасности.

Если вы используете bash, то установка переменных окружения в /etc/profileбудет применяться для всех пользователей.

Из bashруководства по OS X Mavericks , с моим акцентом (это не изменилось по сравнению с предыдущими версиями):

Когда bash вызывается как интерактивная оболочка входа в систему или как неинтерактивная оболочка с параметром --login, она сначала читает и выполняет команды из файла / etc / profile, если этот файл существует. После прочтения этого файла он ищет ~ / .bash_profile, ~ / .bash_login и ~ / .profile в указанном порядке, а также читает и выполняет команды из первой, которая существует и доступна для чтения.
...
Если bash вызывается с именем sh, он пытается максимально близко имитировать поведение при запуске исторических версий sh, при этом также соответствует стандарту POSIX. При вызове в качестве интерактивной активной интерактивной оболочки входа или неинтерактивной оболочки с параметром --login сначала он пытается читать и выполнять команды из / etc / profile и ~ / .profile, в этом порядке.

То, что вы (и любой другой человек, находящий этот вопрос) почти наверняка ищут, это следующий путь:

/private/etc/paths

Вы всегда можете внести свои изменения в файл, /private/etc/paths.dесли хотите избежать изменения документа конфигурации основных путей по умолчанию для основной системы, но тогда они будут добавлены в конец вашей $PATHпеременной, поэтому, если вы хотите добавить каталоги в начале $PATH(для переопределить системные утилиты по умолчанию, например), вам просто нужно отредактировать основной /private/etc/pathsфайл и добавить его в начало списка. Например, я делаю это для папки, в которой я храню несколько скриптов, которые я сделал сам, вместе с несколькими ключевыми утилитами, такими какmozjpegя хочу, чтобы система всегда использовала вместо значений по умолчанию (таким образом, все jpeg-файлы, сохраненные практически любой программой, автоматически сжимаются на 10% больше, чем обычная системная утилита cjpeg сжимает их - я мы читали, что причина, по которой он не используется по умолчанию в большинстве систем, в том, что он намного медленнее, но когда вы говорите что-то вроде 0,14 секунды, а не 0,02 секунды, «медленнее в 7 раз» на самом деле не значит много ничего ... при условии, что это не сервер, конечно). Я знаю, что многие люди, вероятно, предупредят о потенциальной «опасности» внесения таких изменений глубоко в систему, но я бы сказал, что если вы ищете ответ, подобный этому, вы, вероятно, знаете достаточно, чтобы справиться с именами утилит. конфликты, которые могут возникнуть в будущем,/private/etc/pathsдействительно распространяет их среди всех возможных пользователей / логинов / экземпляров - все программы, оболочки и т. д. будут использовать пути в этом файле для построения базы своей $PATHпеременной.

Честно говоря, я очень удивлен, что никто здесь еще не упомянул об этом. Все, что возится с launchd и отвлекает внимание на специфические для SSH применения ... это решение, которое действительно ищет каждый, кто ищет эту основную проблему - чистое, прямое к источнику, всегда работающее решение.

Кстати, если вам интересно, в OS X /etcэто просто символическая ссылка /private/etc, так что вы можете с такой же легкостью сделать это sudo nano /etc/pathsи попасть в одно и то же место. Приведенный выше путь является просто полным фактическим путем к файлу.

У меня была похожая проблема, в частности, ~/.bashrcне было источника, когда я подключился к своей машине через SSH. Я обнаружил, что изменение настройки конфигурации для SSHd помогло. Возможно, ваша проблема также связана с демоном SSH?

Измените файл конфигурации службы SSH следующим образом:

# /etc/sshd_config
PermitUserEnvironment yes

Затем перезапустите службу удаленного входа в Системные настройки> Общий доступ.

Из 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.

(Если это поможет, я написал, как я проверял это на моей личной вики )

Если другие ищут, как установить переменные среды для процессов, запущенных из обычного графического сеанса входа в систему, вы можете использовать /etc/launchd.conf. Например, /usr/local/binчтобы добавить к пути по умолчанию, запустите

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

и перезапустите, чтобы применить изменения. Другой способ применить изменения - запустить launchctl</etc/launchd.conf;sudo launchctl</etc/launchd.confи перезапустить процессы.

Хм ... Начиная с Mac OS X 10.10.5 и, возможно, ранее, он man -s5 launchd.confговорит нам: " launchd.conf is no longer respected by the system." У меня сейчас слишком много вещей, чтобы поместить фиктивную переменную в файл и перезапустить, чтобы посмотреть, действительно ли она работает или нет после все, но в документации сказано, что это не должно работать.

Я уверен, что это не так. Сделай man launchctlи увидишь: " The /etc/launchd.conf file is no longer consulted for subcommands to run during early boot time; this functionality was removed for security considerations."

Что вы можете сделать, это поместить все переменные среды, которые вы хотите использовать в глобальном масштабе, в некоторый файл, возможно, вызванный environmentв соответствии с Linux, или (в случае, если Apple решит что-то сделать с этим позже - вы никогда не узнаете) environment.conf, как я, затем источник этого через /etc/profile:

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

или, если вы предпочитаете компактный формат:

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

Если вы используете какую-то другую оболочку, отличную от bash, и она использует тот же синтаксис установки переменных, что и bash (я думаю, что это делает zsh), вам также нужно будет получить этот файл из общесистемного rc-файла этой оболочки (например /etc/zshrc). Если вы используете оболочку с другим синтаксисом, например, tcsh, вам нужно либо сохранить аналогичный файл для этой оболочки и получить его из общесистемного rc-файла оболочки (например, /etc/csh.cshrcдля tcsh), либо лучше создать сценарий. это автоматически генерирует его, так что вам нужно всего лишь отредактировать один файл, чтобы добавить / изменить переменные. Это не место для такого урока; Несколько секунд в Google выяснилось, как преобразовать экспорт [t] csh-переменных в синтаксис bash, по адресу https://stackoverflow.com/questions/2710790/how-to-source-a-csh-script-in-bash-to -set-The-окружающая средатак что, вероятно, есть что-то, что может пойти в другом направлении.

По моему опыту, Mac OS X все дальше и дальше уходит от предсказуемого поведения файла rc. По крайней мере, с 10.8, он больше не загружается /etc/rc.common, /etc/rc.confили /etc/rc.<anything>(с, по крайней мере, 10.9) он не загружается /etc/bash.bashrcдля интерактивных нелогиновых оболочек (что он, безусловно, должен делать, точно так же, как он загружает ~/.bashrcих, по-прежнему, начиная с 10.10) , С другой стороны, у меня есть Fink, MacPorts и Homebrew, которые все устанавливают, так что, возможно, один из них мешает поведению по умолчанию в dotfile. YMMV.