Ejecución de subversión en apache y mod_python

Question

Mi servidor Apache se ejecuta en alguna cuenta no predeterminada (no raíz). Cuando se intenta ejecutar un script en Python, que a su vez ejecuta una orden de pago a la subversión, 'svn checkout' se produce el siguiente mensaje de error:

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

Al mismo tiempo que se ejecuta un script en Python con la orden de pago dentro de la subversión desde la línea de comandos bajo la misma cuenta de usuario se ejecuta perfectamente.

El servidor Apache 2.2.6 con mod_python 3.2.8 se ejecuta en la máquina Fedora Core 6.

¿Alguien me puede ayudar? Muchas gracias.

Answer 1

Intente otorgar al usuario de Apache (el usuario con el que se ejecuta el servicio apache) permisos r + w en ese archivo.

Answer 2

Parece que el entorno en el que se ejecuta el proceso de apache es un poco inusual. Por alguna razón, svn parece pensar que los archivos de configuración de usuario que necesita están en/root. Puede evitar tener SVN utilizar las versiones raíz de los archivos especificando en la línea de comandos, que el directorio de configuración de utilizar, así:

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

Aunque no es la fijación de su AMBIENTE, será al menos le permiten tener la secuencia de comandos ejecutar correctamente ...

Answer 3

¿El registro de errores de Apache no le da una pista?

Quizás tiene que ver con SELinux. Compruebe /var/log/audit/audit.log y ajuste su configuración de SELinux en consecuencia, si el archivo audit.log indica que es SELinux que niega el acceso de Apache.

Answer 4

El error de permiso denegado muestra que la secuencia de comandos se ejecuta con las credenciales de la raíz, ya que está buscando en el directorio de inicio de la raíz los archivos.

me sugieren que cambie el script gancho a algo que hace:

id > /tmp/id 

para que pueda comprobar los resultados de que para asegurarse de que lo que el/GID y euid/egid UID son. Probablemente descubrirá que en realidad no se está ejecutando como el usuario que cree que es.

Mi primera conjetura, como Troels, también fue SELinux, pero eso solo sería una suposición si está absolutamente seguro de que el script a través de Apache se ejecuta exactamente con el mismo usuario/grupo que su prueba manual.

Answer 5

Bien, gracias a todos los que respondieron la pregunta. De todos modos, creo que resolví el misterio.

SELinux está completamente deshabilitado en la máquina, por lo que definitivamente el problema es que 'svn co' no puede encontrar config_dir para la cuenta de usuario bajo la cual se ejecuta.

Apache/mod_python no lee en el entorno de shell de la cuenta de usuario en la que Apache se está ejecutando. Así, por ejemplo, $ HOME es visto por mod_python cuando apache se ejecuta bajo algún usuario real (no nadie)

Ahora 'svn co' tiene un indicador --config-dir que apunta al directorio de configuración para leer los parámetros. Por defecto, es $ HOME/.subversion, es decir, corresponde al directorio de inicio de la cuenta de usuario. Aparentemente, cuando no existe $ HOME, mod_python va al directorio raíz de inicio (/ raíz) y trata de manipularlo.contenido de subversión allí, que obviamente es falla miserablemente.

poner

SetEnv INICIO/home/qa

en el /etc/httpd/conf/httpd.conf no resuelve el problema debido a SetEnv no tener nada que ver con el entorno de shell - sólo Apache conjuntos relacionados con el medio

Del mismo modo PythonOption - conjuntos única mod_python variables relacionadas que pueden ser leídos con req.get_options() después de que

Running 'svn co --config-dir/home/...' definitivamente da una solución para runni ng desde mod_python, pero se interpone en el camino de aquellos que intentarán ejecutar el script desde la línea de comandos.

Así que la solución propuesta (y de trabajo) es establecer la variable de entorno HOME antes de iniciar appache.

Por ejemplo en escritura /etc/init.d/httpd

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

Answer 6

Lo que ocurre es Apache se inició con las variables de entorno de la raíz, por lo que cree que debería encontrar sus archivos de configuración en/raíz/. Este no es el caso. Lo que ocurre es si lo hace sudo inicio apache2ctl, tira de su casa variable $ del sudo $ HOME =/root/

acabo de encontrar una solución a este problema por mí mismo (aunque con mod_perl, pero lo mismo)

ejecución de este comando (si es Apache 1, retire el 2): ​​

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

Cuando comienza /etc/init.d/apache2 Apache, establece todas las variables de entorno adecuadas que Apache debe ejecutarse bajo.