Когда вы запускаете сервер (например, Debian), как можно сделать переменные среды постоянными и доступными для PHP?

Что я сейчас делаю на уровне ОС:

После инициализации перейдите к пользователю, которому требуется переменная, и экспортируйте переменные, затем также укажите их установку в профиле - или в / etc / environment (Debian) в случае root, чтобы учесть постоянство

Я часто делаю это с помощью "echo >>" или "sed" непосредственно в конфигурационные файлы или в каталог, в котором основная конфигурация просматривает настройки.

Для меня:

export MYVAR=foobar
echo "export MYVAR=foobar" >> /home/bradchesney79/.profile

Верхний делает переменную среды доступной при выполнении, но она исчезнет при выходе из системы. Поместив команду в ваш .profile, вы создадите ее при входе в систему.

sed -i s/export MYVAR=.*/export MYVAR=barfoo/g /home/bradchesney79/.profile 

Для тебя:

sudo -u brianchesney80 export HISVAR=something 
sudo -u brianchesney80 echo "HISVAR=something" >> /home/brianchesney80/.profile

Для каждого:

((Not fully certain how to export globally just yet))
sudo echo "OURVAR=fffoooooobbbaaarrr" >> /etc/environment

Я не люблю перезагружаться. Но я не вижу способа обойти это, чтобы включить переменные среды, установленные здесь для всех.

Итак, хотите увидеть переменные среды для другого пользователя?

sudo -u www-data printenv PATH
sudo -u www-data env

Недостаточно красивого краткого списка, предоставленного env? Пытаться:

set > /tmp/setOutput.tmp

Переменные среды (Ubuntu)

Переменные среды и оболочки

Делаем переменные среды доступными для PHP:

Стоит отметить, что переменные среды естественным образом не доступны демонизируемым службам, поскольку они не запускаются традиционно как дочерний процесс, который наследует переменные среды родительского объекта. Имейте в виду, что это барьер безопасности, установленный по очень веской причине (то, что переменные среды будут совместно использоваться без разбора, не обязательно хорошо). Моя цель - выборочно сделать доступными определенные проверяемые значения переменных среды, чтобы моя система вела себя по-другому или с правильными учетными данными, установленными и доступными для приложения в переменной - все это при создании экземпляра с помощью сценария подготовки, а некоторые из них сохраняются между перезагрузками.

Apache

Пример:

export PATH="/var/www:/var/www/html"

Аккуратный фрагмент, с его помощью вы можете проверить действительность вашего файла envvars.

sh -n /etc/apache2/envvars && echo Syntax OK || echo FAIL

В / etc / apache2 (Debian) были некоторые настройки, которые, я думаю, можно было бы использовать в блоке virtualhost ...

Пример:

SetEnv SPECIAL_PATH /foo/bin

Вышеупомянутое в блоке конфигурации виртуального хоста сервера сделает настраиваемую переменную среды доступной через $ _SERVER или аналогичное соглашение где-то, как упоминалось TMR, высмеивая меня в комментариях.

Apache httpd mod_env

В другом месте файла httpd.conf и аналогичных файлов или .htaccess вы можете установить переменные среды с помощью правил перезаписи.

RewriteRule someurl - [E=dbpass:swordfish]

Злоупотребление Apache Rewrite ... Если нужно, я думаю, ты должен. Мне вообще не нравятся файлы .htaccess, я тоже не фанат переписывания.

NGINX

Похоже, вы можете использовать модуль lua NGINX для вставки переменных окружения в сервер. Этот другой модуль тоже нужен.

При этом основное внимание уделяется PHP - если вы используете nginx с PHP - возможно, посмотрите раздел PHP ниже, который может быть лучшим решением.

env PATH;
http {
    ...
    server {
        location /path {
            set_by_lua $path 'return os.getenv("PATH")';
            ...
        }
    }
}

Цепочка в списке рассылки NGINX, открывающая возможность

Запись в блоге об использовании lua полностью

PHP

get-cfg-var () позволит вам получать значения, установленные разработчиками проекта PHP, и произвольные значения, которые вы установили. Стоит проявлять осторожность, чтобы таким образом именовать эти переменные в глобальной области видимости, и обязательно прочитайте примечания, внесенные пользователем, чтобы знать о некоторых автоматических магических манипуляциях.

Пример:

php.ini

environment_type=dev
environment_host=AWS

рандо-скрипт-что угодно.php

get_cfg_var('environment_type') // returns 'dev'
get_cfg_var('environment_host') // returns 'AWS'

---

В файле конфигурации пула php-fpm, приведенное ниже, сделает настраиваемую переменную среды доступной через $ _SERVER или аналогичное соглашение где-то, как упоминалось TMR, высмеивая меня в комментариях.

Пример:

мой-pool.conf

env[FOO] = bar

рандо-скрипт-что угодно.php

echo $_SERVER['FOO']; // returns 'bar'

Резюме

• Какой: Конечный результат, которого я ищу, - это то, что я могу создать сценарий для сервера. Из-за weaksauce у меня есть доступная оболочка и я запускаю больше сценариев bash, чем я хотел бы признать. Тем не менее, я хочу установить определенные переменные на уровне пользователя ОС и заставить их распространяться вниз, чтобы помочь мне более или менее «анонимизировать» кодовую базу моего веб-приложения.

• Зачем: Преимущество заключается в том, что многие детали, такие как ключи RSA для аутентификации (да, они вписываются в переменную среды), пароли и другие «секреты», остаются вне базы кода - вы переместили все эти «секреты» в сценарии обеспечения и, очевидно, на работающий сервер, использующий элементы управления доступом низкого уровня. ничего не нужно менять в коде, которого разработчик касается для запуска веб-приложения. Любые конфигурации или отклонения могут быть проверены и обработаны. Пишите один раз, развертывайте везде с уверенностью, все очень похоже, если не одинаково. Сценарий обеспечения автоматически помещает правильного пользователя DSN, хост и пароль для подключения к вашей базе данных в переменной среды; те переменные PHP, которые ссылаются на переменные среды, просто получают правильные значения с самого начала.

• Как: И вот мой вопрос. Какие шаги и технологии вы используете, если уже делаете это?

Редактирует:

tl; dr - удалена спорная идея о предоставлении ресурсов, сводящаяся к одной краткой теме вопроса

Я удалил упоминание об обнаружении вещей о хосте и инициализации сервера на основе результатов. Настоятельно высказывалось предположение, что такой способ инициализации сервера может быть плохой стратегией и что инструменты инициализации предназначены для объявления настроек вместо того, чтобы целевой хост узнавал что-то о себе при создании экземпляра и реагировал соответствующим образом. - А главное, второстепенно по отношению к поставленной задаче. Я хочу узнать больше о хранении данных, которые могут измениться в переменных среды, и это здорово.

- Специально упомянутое AnrDaemon нарушает принцип наименьшего удивления.

nginxphpdebianbashenvironment-variables