Як встановити загальносистемні змінні середовища на 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це те, що стосується всіх процесів; якщо стосується оболонок користувача, використовуйте замість них відповідні файли оболонок, залежно від оболонки. Додаткову інформацію див. На сторінках людини 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змінної.

Якщо чесно, я дуже здивований, що тут ніхто ще не згадав про це. Все, що заплутується із запуском та відволіканням на використання специфічних для 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-оточення, тож, мабуть, є щось доступне, щоб піти в іншому напрямку.

Мій досвід, як 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.