Tengo un problema aburrido que parece que no puedo resolver.
¿Qué estoy intentando hacer?
post-review --repository-url=http://xxx.xxx.xxx.xxx/svn/testRepo2 --revision-range=6:7 --server=http://reviews.example.test/ --username=reviewposter --password=mydullpass --submit-as=admin -p --target-groups=reviewers
Todo está bien cuando intento esto desde bash iniciando sesión como mi usuario. La revisión se publica, se publica, etc. ==> Todos los permisos y otras configuraciones diversas están bien.
¿Qué sucede cuando intento esto desde el gancho posterior a la confirmación de SVN?
Los recursos están comprometidos pero la operación svn se bloquea; en realidad, el enlace posterior a la confirmación no finaliza.
¿A qué se reduce el problema?
La revisión posterior se ejecuta como el usuario que ejecuta el enlace posterior a la confirmación; en este caso, el usuario de www-data Apache. Es decir, cuando ejecuto el comando como www-data:
sudo -u www-data post-review --repository-url=http://xxx.xxx.xxx.xxx/svn/testRepo2 --revision-range=6:7 --server=http://reviews.example.test/ --username=reviewposter --password=mydullpass! --submit-as=admin -p --target-groups=reviewers -d
Obtengo (observe el parámetro -d en el comando posterior a la revisión - DEBUG):
RBTools 0.4.1
Home = /home/borislav
Password for 'www-data':
Aquí es donde se cuelga esperando que se ingrese una contraseña. La operación de confirmación no puede finalizar y simplemente permanece ahí. Ya he hablado de esto con los chicos deGrupo de Google de ReviewBoard en esta publicación.
Por otro lado, cuando hago el mismo comando con salida de depuración pero como myuser obtengo:
RBTools 0.4.1
Home = /home/borislav
HTTP GETting api/
HTTP GETting http://reviews.example.test/api/info/
Using the new web API
TTP GETting http://reviews.example.test/api/repositories/
HTTP GETting http://reviews.example.test/api/repositories/1/
HTTP GETting http://reviews.example.test/api/repositories/1/info/
HTTP GETting http://reviews.example.test/api/repositories/2/
HTTP GETting http://reviews.example.test/api/repositories/2/info/
HTTP GETting http://reviews.example.test/api/repositories/3/
HTTP GETting http://reviews.example.test/api/repositories/3/info/
HTTP GETting http://reviews.example.test/api/repositories/4/
HTTP GETting http://reviews.example.test/api/repositories/4/info/
Attempting to create review request on http://xxx.xxx.xxx.xxx/svn/testRepo2 for None
Submitting the review request as admin
HTTP POSTing to http://reviews.example.test/api/review-requests/: {'submit_as': 'admin', 'repository': 'http://xxx.xxx.xxx.xxx/svn/testRepo2'}
Review request created
Attempting to set field 'target_groups' to 'reviewers' for review request '22'
HTTP PUTting to http://reviews.example.test/api/review-requests/22/draft/: {'target_groups': 'reviewers'}
Uploading diff, size: 2316
HTTP POSTing to http://reviews.example.test/api/review-requests/22/diffs/: {'basedir': '/'}
Publishing
HTTP PUTting to http://reviews.example.test/api/review-requests/22/draft/: {'public': 1}
Review request #22 posted.
http://reviews.example.test/r/22/
Entonces, en realidad, todo lo relacionado con la publicación, etc., funciona.
Uno de los desarrolladores de ReveiwBoard declaró que"No mostramos la cadena "Contraseña para ''". Así que eso proviene de algo completamente distinto".
Estoy seguro de que es algún tipo de permiso de ejecución. Debería ejecutarse en Ubuntu Server, así que piense en Debian.
Me preguntaba si tenía alguna conexión con el paradigma de "no iniciar sesión como root" en Ubuntu.
No lo he probado en otra distribución de Linux, lo cual no es realmente una opción ya que el servidor SVN está alojado en Ubuntu Server.
Puedes comprobaresta discusión que tuvecon los chicos del grupo de gafas de ReviewBoard. Elrevisión posteriorbinario se encuentra en:/usr/local/bin/post-review
Intenté agregar permisos parawww-datospara poder ejecutarrevisión posterioren el archivo sudoers, pero sin suerte.
¿Qué solución se te ocurre?
Gracias de antemano, Borislav.
Respuesta1
La solicitud de contraseña en realidad proviene de svn, no de la revisión posterior. post-review llama al binario svn para recuperar los cambios del repositorio.
No ve la solicitud de contraseña como su usuario porque ya se ha autenticado y svn ha almacenado su información de autenticación. Aún no ha hecho esto como usuario de www-data, por lo que svn solicita la contraseña.
La forma más sencilla de solucionar este problema sería registrarse como usuario de www-data y autenticarse en el repositorio, de modo que las credenciales se almacenen en caché.