Запуск subversion под apache и mod_python

Question

Мой сервер Apache работает под учетной записью не по умолчанию (не root). Когда он пытается запустить скрипт Python, который, в свою очередь, выполняет команду извлечения Subversion, 'svn checkout' завершается с ошибкой:

svn: Can't open file '/root/.subversion/servers': Permission denied

В то же время выполнение этого скрипта python с командой извлечения Subversion из командной строки под той же учетной записью пользователя продолжается на отлично.

Сервер Apache 2.2.6 с mod_python 3.2.8 работает на компьютере с Fedora Core 6.

Кто-нибудь может мне помочь? Большое спасибо.

Answer 1

Похоже, среда, в которой работает процесс apache, немного необычна. По какой-то причине svn считает, что необходимые ему файлы конфигурации находятся в / root. Вы можете избежать использования svn корневых версий файлов, указав в командной строке, какой каталог конфигурации использовать, например:

svn --config-dir /home/myuser/.subversion checkout http://example.com/path

Хотя это и не исправит вашу среду, по крайней мере, она позволит вам правильно запустить скрипт ...

Answer 2

Происходит то, что apache запускается с переменными окружения root, поэтому он считает, что должен найти свои файлы конфигурации в / root /. Это не вариант. что происходит, если вы запускаете sudo apache2ctl, он извлекает переменную $ HOME из sudo $ HOME = / root /

Я только что нашел решение этой проблемы сам (хотя с mod_perl, но то же самое)

запустите эту команду (если ее apache 1, удалите 2):

sudo /etc/init.d/apache2 stop
sudo /etc/init.d/apache2 start

Когда /etc/init.d/apache2 запускает apache, он устанавливает все необходимые переменные среды, под которыми должен работать apache.

Answer 3

Ну, спасибо всем, кто ответил на вопрос. Во всяком случае, я думаю, что решил тайну.

SELinux полностью отключен на машине, поэтому проблема в том, что svn co не может найти config_dir для учетной записи пользователя, под которой он работает.

Apache / mod_python не читает в среде оболочки учетной записи пользователя, на которой работает apache. Таким образом, для примера $ HOME не виден mod_python, когда apache работает под каким-то реальным пользователем (не никем)

Теперь у 'svn co' есть флаг --config-dir, который указывает на каталог конфигурации для чтения параметров. По умолчанию это $ HOME / .subversion, т.е. он соответствует домашнему каталогу учетной записи пользователя. Очевидно, что когда $ HOME не существует, mod_python переходит в корневой каталог dir (/ root) и пытается там поработать с содержимым .subversion - что, очевидно, является с треском проваливается.

положить

SetEnv HOME / home / qa

в /etc/httpd/conf/httpd.conf не решает проблему из-за того, что SetEnv не имеет ничего общего со средой оболочки - он только устанавливает среду, связанную с Apache

Аналогично PythonOption - устанавливает только переменные, связанные с mod_python, которые могут быть прочитаны с помощью req.get_options () после этого

Запуск 'svn co --config-dir / home / ...' определенно дает обходной путь для запуска из mod_python, но мешает тем, кто попытается запустить скрипт из командной строки.

Таким образом, предлагаемое (и работающее) решение состоит в том, чтобы установить переменную среды HOME до запуска appache.

Например, в скрипте /etc/init.d/httpd

    QAHOME=/home/qa
    ...
    HOME=$QAHOME LANG=$HTTPD_LANG daemon $httpd $OPTIONS

Answer 4

Ошибка «Отказано в доступе» показывает, что скрипт выполняется с учетными данными root, поскольку ищет в домашнем каталоге root файлы.

Я предлагаю вам изменить скрипт хука на что-то, что делает:

id > /tmp/id

, чтобы вы могли проверить результаты этого, чтобы убедиться, что такое uid / gid и euid / egid. Вы, вероятно, обнаружите, что он на самом деле не работает как пользователь, о котором вы думаете.

Моим первым предположением, подобно Troels, был также SELinux, но это было бы моим предположением, только если вы абсолютно уверены, что скрипт через Apache работает с тем же пользователем / группой, что и ваш ручной тест.

Answer 5

Разве журнал ошибок Apache не дает подсказки?

Возможно, это связано с SELinux. Проверьте /var/log/audit/audit.log и соответственно измените конфигурацию SELinux, если файл audit.log указывает, что это SELinux, который запрещает доступ Apache.

Answer 6

Попробуйте предоставить пользователю Apache (пользователю, под которым запущена служба apache) права r + w для этого файла.