在 apache 和 mod_python 下运行 subversion

Running subversion under apache and mod_python

提问by victorz

My Apache server runs on some non-default (not-root) account. When it tries to run a python script which in turn executes a subversion check-out command, 'svn checkout' fails with the following error message:

我的 Apache 服务器在一些非默认（非 root）帐户上运行。当它尝试运行 python 脚本，然后执行 subversion checkout 命令时，“svn checkout”失败并显示以下错误消息：

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

At the same time running that python script with subversion checkout command inside from command line under the same user account goes on perfectly well.

同时在同一用户帐户下从命令行运行带有 subversion checkout 命令的 python 脚本运行得非常好。

Apache server 2.2.6 with mod_python 3.2.8 runs on Fedora Core 6 machine.

带有 mod_python 3.2.8 的 Apache 服务器 2.2.6 在 Fedora Core 6 机器上运行。

Can anybody help me out? Thanks a lot.

有人可以帮我吗？非常感谢。

回答by Douglas Mayle

It sounds like the environment you apache process is running under is a little unusual. For whatever reason, svn seems to think the user configuration files it needs are in /root. You can avoid having svn use the root versions of the files by specifying on the command line which config directory to use, like so:

听起来您的 apache 进程运行的环境有点不寻常。无论出于何种原因，svn 似乎认为它需要的用户配置文件在 /root 中。您可以通过在命令行上指定要使用的配置目录来避免让 svn 使用文件的根版本，如下所示：

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

While not fixing your enviornment, it will at least allow you to have your script run properly...

虽然不修复您的环境，但它至少可以让您的脚本正常运行......

回答by Troels Arvin

Doesn't Apache's error log give you a clue?

Apache 的错误日志没有给您提供线索吗？

Maybe it has to do with SELinux. Check /var/log/audit/audit.log and adjust your SELinux configuration accordingly, if the audit.log file indicates that it's SELinux which denies Apache access.

也许这与 SELinux 有关。检查 /var/log/audit/audit.log 并相应地调整您的 SELinux 配置，如果 audit.log 文件表明它是拒绝 Apache 访问的 SELinux。

回答by Thomas Vander Stichele

The Permission Denied error is showing that the script is running with root credentials, because it's looking in root's home dir for files.

Permission Denied 错误表明脚本正在使用 root 凭据运行，因为它正在 root 的主目录中查找文件。

I suggest you change the hook script to something that does:

我建议您将钩子脚本更改为以下内容：

id > /tmp/id

so that you can check the results of that to make sure what the uid/gid and euid/egid are. You will probably find it's not actually running as the user you think it is.

以便您可以检查结果以确保 uid/gid 和 euid/egid 是什么。您可能会发现它实际上并没有像您认为的那样运行。

My first guess, like Troels, was also SELinux, but that would only be my guess if you are absolutely sure the script through Apache is running with exactly the same user/group as your manual test.

我的第一个猜测，就像 Troels 一样，也是 SELinux，但如果您绝对确定通过 Apache 运行的脚本与手动测试的用户/组完全相同，那么这只是我的猜测。

回答by victorz

Well, thanks to all who answered the question. Anyway, I think I solved the mistery.

嗯，感谢所有回答问题的人。无论如何，我想我解决了这个谜团。

SELinux is completely disabled on the machine, so the problem is definitely in 'svn co' not being able to found config_dir for the user account it runs under.

SELinux 在机器上被完全禁用，所以问题肯定是在 'svn co' 无法为它运行的用户帐户找到 config_dir。

Apache / mod_python doesn't read in shell environment of the user account which apache is running on. Thus for examle no $HOME is seen by mod_python when apache is running under some real user ( not nobody )

Apache / mod_python 不会在运行 apache 的用户帐户的 shell 环境中读取。因此，例如，当 apache 在某个真实用户（不是没有人）下运行时，mod_python 看不到 $HOME

Now 'svn co' has a flag --config-dir which points to configuration directory to read params from. By default it is $HOME/.subversion, i.e. it corresponds to the user account home directory. Apparently when no $HOME exists mod_python goes to root home dir ( /root) and tries to fiddle with .subversion content over there - which is obviously fails miserably.

现在 'svn co' 有一个标志 --config-dir 指向配置目录以从中读取参数。默认情况下它是 $HOME/.subversion，即它对应于用户帐户主目录。显然，当没有 $HOME 存在时，mod_python 会转到根主目录（/root）并尝试在那里摆弄 .subversion 内容 - 这显然失败了。

putting

推杆

SetEnv HOME /home/qa

SetEnv HOME /home/qa

into the /etc/httpd/conf/httpd.conf doesn't solve the problem because of SetEnv having nothing to do with shell environment - it only sets apache related environment

进入/etc/httpd/conf/httpd.conf并没有解决问题，因为SetEnv与shell环境无关 - 它只设置与apache相关的环境

Likewise PythonOption - sets only mod_python related variables which can be read with req.get_options() after that

同样 PythonOption - 仅设置 mod_python 相关变量，之后可以使用 req.get_options() 读取

Running 'svn co --config-dir /home/ ...' definitely gives a workaround for running from within mod_python, but gets in the way of those who will try to run the script from command line.

运行 'svn co --config-dir /home/ ...' 绝对提供了从 mod_python 中运行的解决方法，但会妨碍那些尝试从命令行运行脚本的人。

So the proposed ( and working) solution is to set HOME environment variable prior to starting appache.

所以建议的（和工作的）解决方案是在启动 appache 之前设置 HOME 环境变量。

For example in /etc/init.d/httpd script

例如在 /etc/init.d/httpd 脚本中

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

回答by Lathan

What is happening is apache is being started with the environment variables of root, so it thinks that it should find its config files in /root/. This is NOT the case. what happens is if you do sudo apache2ctl start, it pulls your $HOME variable from the sudo $HOME=/root/

发生的事情是 apache 是用 root 的环境变量启动的，所以它认为它应该在 /root/ 中找到它的配置文件。不是这种情况。发生的情况是，如果您执行 sudo apache2ctl start，它会从 sudo $HOME=/root/ 中提取您的 $HOME 变量

I have just found a solution to this problem myself (although with mod_perl, but same thing)

我自己刚刚找到了这个问题的解决方案（虽然使用 mod_perl，但同样的事情）

run this command (if its apache 1, remove the 2):

运行此命令（如果是 apache 1，则删除 2）：

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

When /etc/init.d/apache2 starts apache, it sets all the proper environment variables that apache should be running under.

当 /etc/init.d/apache2 启动 apache 时，它​​会设置 apache 应该在其下运行的所有适当的环境变量。

回答by pfranza

Try granting the Apache user (the user that the apache service is running under) r+w permissions on that file.

尝试授予 Apache 用户（运行 apache 服务的用户）对该文件的 r+w 权限。