У меня есть это /etc/profile.d/myfile.sh
:
export MYVAR=myval
У меня также есть PassEnv MYVAR
линия в <virtualhost>
раздел apache conf dir.
Это позволяет мне делать такие вещи, как:
$ echo $MYVAR
myval
$ python
>>> import os; os.getenv('MYVAR')
'myval'
$ sudo echo $MYVAR
myval
$ sudo -i
root# echo $MYVAR
myval
Но затем, несмотря на это, я получаю:
root# /sbin/service httpd restart
/sbin/service httpd restart
Stopping httpd: [ OK ]
Starting httpd: [Mon Oct 22 14:44:02 2012] [warn] PassEnv variable MYVAR was undefined
[ OK ]
И все мои попытки получить доступ к MYVAR из моих сценариев wsgi просто не работают.
Мысли? Я делаю что-то явно не так?
ИЗМЕНИТЬ для более подробной информации
У меня есть рой компьютеров / виртуальных машин и рой разработчиков, работающих над множеством проектов. мне нужен просто Центральное место для хранения информации о среде, наиболее распространенным является «среда» (dev / stage / prod). Схема, которая у нас есть (изменение *.wsgi
программно) оказывается более хрупким, чем хотелось бы.
Основные варианты, которые я вижу:
Лучше всего помещать вещи в среду оболочки, потому что нам не нужно будет писать еще больше дублированного кода "что является моей средой".
Apache не собирается читать глобальный профиль пользователя.
Большой вопрос в том, для чего вы на самом деле хотите это сделать?
То, что вы делаете, - это, как правило, неправильный способ работы с Apache, но, поскольку вы не знаете фактическую проблему, которую пытаетесь решить, не можете сказать, что вам следует делать.
Измените свой вопрос и укажите, какие переменные среды вы пытаетесь установить и почему.
ОБНОВЛЕНИЕ 1
Не совсем то, что вы делаете, но SetEnv в mod_wsgi не устанавливает переменные среды для всего процесса. Он устанавливает переменные для каждого запроса в словаре среды WSGI.
PassEnv, связанный с SetEnv, будет делать то же самое, но вместо ключа / значения, определенного в файле конфигурации Apache, он будет исходить из существующих переменных среды процесса, унаследованных Apache.
Таким образом, ни одна из директив на самом деле не влияет на установку переменной среды всего процесса для приложения WSGI, работающего под mod_wsgi. IOW, они не будут доступны через os.environ, как вам кажется.
Теперь, конкретно для PassEnv, если вы хотите, чтобы переменные среды процесса Apache также были доступны для приложения WSGI в mod_wsgi, тогда PassEnv фактически избыточен, поскольку переменные среды процесса Apache уже будут доступны.
Это связано с тем, что во встроенном режиме приложения WSGI выполняются внутри дочерних рабочих процессов Apache. Даже в режиме демона процесс-демон является прямым ответвлением родительского процесса Apache (без выполнения какого-либо отдельного приложения) и поэтому эффективно также выполняется внутри Apache.
Таким образом, PassEnv не требуется, поскольку они уже установлены.
Чтобы сделать это так, как вы хотите, вы просто делаете это не в том месте, поскольку сценарии запуска Apache init.d не будут использовать глобальный профиль входа пользователя.
Если вы используете дистрибутив Apache от Apache Software Foundation или тот, который не слишком сильно отклонился от него, правильное место для установки переменных среды для Apache находится в файле envvars в том же каталоге, что и исполняемый файл Apache. В различных дистрибутивах Linux установка Apache полностью игнорирует этот файл, и вместо этого необходимо установить их в каком-то специальном файле вместе с системными файлами Apache init.d. Что именно вы должны там делать, будет зависеть от дистрибутива Linux.
Итак, как я уже сказал, Apache не будет читать этот файл глобального профиля.
Doit в нужном месте и технически может работать, но я бы не рекомендовал полагаться на установку переменных среды, которые влияют на весь Apache.
Было бы лучше, если бы сценарий WSGI читал отдельный файл конфигурации, который устанавливает статус системы, а затем основывает его. Использование файла конфигурации специально для этой цели не так уж и волшебно, как полагаться на настройки переменных среды, поступающие из файла, который не является частью проекта, а скриптами инициализации Apache.