svn

Bien en algun momento tuve que implementar subversion, es probable que en la version que alguien este instalando en este momento ya no haya ningun problema (de hecho en la ultima que tengo noticia, se puede elegir entre usar Berkeley DB y otro metodo para evitar problemas, pero si alguien esta teniendo o tiene problemas con los permisos en subversion y/o con multiples usuarios accesando al repositorio no estaria de mas que leyera el siguiente texto (sacado de un log de oficina):

11/09/2004 20:46 –TESTED
IT –VM
se cierra
11/09/2004 20:46 –CLOSED
IT –n/a
09/22/2004 12:48 –PENDING
IT –VM –2.00 hrs
Hasta nueva version de subversion la solucion es la que ya se encontro.
Es decir, si se van a tener usuarios locales, mantener el numero bajo y como hack feo estar cambiando los permisos mediante cron (risky), no tener usuarios locales en la maquina donde esta el repositorio, o que estos solo accesen via svn+ssh (claro primero colocando el wrapper para svnserve) esta ultima es la solucion mas recomendada (hasta que haya modificacion en el svn)
07/29/2004 16:18 –SOLUTION
IT –VM –2.00 hrs
La solucion de Alioth (ACLS), es solo usar un metodo para la escritura… citando:
Write access is only allowed through svnserve over a ssh transport. Access control is handled through Alioth.
Decidir si dejamos esto aun para los usuarios locales…
07/29/2004 03:19 –LABOR
IT –VM –1.00 hrs
El hack parece funcionar… mas aun por que le toma casi el minuto completo hacer un commit u otra operacion a linux, con lo cual tambien se ejuta el cron «just in time»… queda pendiente el arreglar como se debe esta cosa.
07/29/2004 03:04 –ACTION
IT –VM –1.00 hrs
Cron para mantener los permisos corrido cada minuto.
Como fue detallado en el caso del servidor de debian, en el caso de muchos desarrolladores si es «riesgoso», aqui vamos a implementarlo mientras no tengamos mejor solucion.
Mandar correo al admin de debian, para ver como resolvieron el problema.
solucion propuesta:
#!/bin/bash
chmod ug+w /var/svn/mundito/db/*
chown svn.svn /var/svn/mundito/db/*
07/29/2004 02:59 –NOTE
IT –VM –2.00 hrs
-rw-rw-r– 1 svn svn 1023k Jul 29 02:49 log.0000000013
-rw-r–r– 1 vicm3 svn 232k Jul 29 02:50 log.0000000014
al llenarse el log crea uno nuevo con el usuario que estaba haciendo la ultima transaccion…
Ahora lo interesante, se puede cambiar el tamaño del log… podria dejarlo crecer no se hasta varios megas para hacer que el problema se espacie un tanto mas…
david@linux:~/borrame$ svn co file:///var/svn/mundito/
svn: Berkeley DB error while committing Berkeley DB transaction for filesystem /var/svn/mundito/db:
DB_RUNRECOVERY: Fatal error, run database recovery
/usr/local/bin/svn: line 4: 22685 Aborted /usr/bin/svn «$@»
david@linux:~/borrame$ svn co file:///var/svn/mundito/
svn: Unable to open an ra_local session to URL
svn: Unable to open repository ‘file:///var/svn/mundito’
svn: Berkeley DB error while opening environment for filesystem /var/svn/mundito/db:
DB_RUNRECOVERY: Fatal error, run database recovery

aqui el error documentado.
La otra solucion parcial seria la alliot… usar un cron (hasta que entienda lo de las ACLS).
Mhh..
07/29/2004 02:18 –NOTE
IT –VM –0.10 hrs
Berkeley DB creates logfiles as needed, each of which grows to a set maximum size before another is created. In my oft-executed repository creation script, I was very careful to set the permissions so both myself (as a local client) and remote Web users were able to access the repository. But when the first logfile filled, as I locally modified the repository, a new logfile would be created, owned by myself with permissions limited by my umask. When Apache’s mod_dav_svn, running as the www user, later attempted to access the repository and couldn’t read the new log file. BDB interpreted this error as indicating database corruption. Subsequent access to the database in any form failed.
http://radio.weblogs.com/0100148/2002/10/20.html
07/29/2004 02:03 –ACTION
IT –VM –4.00 hrs
http://alioth.debian.org/tracker/index.php?func=detail&aid=300579&group_id=1&atid=200001
el error que encontramos no es tan trivial como pareciera… de lo que leo hay dos soluciones, rapidas…
1) Crear un solo usuario con el que todos hagan uso de svn
2) Usar ACL (aun no entiendo como)
Como nota al calce este mismo problema tambien lo tuvo gnome…
Tracker: Support Requests

Submit New | Browse | Admin

[ #300579 ] permissions system is a disaster waiting to happen
Date:
2004-03-21 13:51 Priority:
8
Submitted By:
Joey Hess (joeyh) Assigned To:
Local GForge Admin (admin)
Category:
SubVersioN State:
Closed
Summary:
permissions system is a disaster waiting to happen

Detailed description:
Alioth’s subversion permissions system is broken in subtle ways that affect more active projects. First an overview of the system as I understand it:

Subversion is set up to work properly iff all files in the db/ directory are owned by user www-data, and the group of the project, and mode 664. The www-data ownership is used because alioth includes http access, and user www-data cannot be a member of every project on alioth. The anonymous svnserve processes also run as www-data. The project’s group must also be able to write to every file though, thus the 664.

There is a little problem. Berkeley db likes to make new log files, and while the fact that the db directory is g+s means they are owned by the right group, they will be owned by whatever user is running the subversion process that makes the new log file, and, with a typical umask, will be mode 644. This means that www-data will not be able to write to them.

Now, there is a nasty little cron job that runs every minute on alioth, going through and chowning and chmodding the db files, so a file can only have the bad owner and mode for a fraction of a minute. So in the typical case, with a lightly used repository, everything seems to work ok, most of the time.

We discovered today how broken this system really is when we moved the very heavily used d-i repository to subversion on alioth, and let a hundred people or so all try to check it out and commit to it at once. We have experienced four instances of the db getting wedged today. In two of these cases, there have been svnserve processes that were stuck in tight select loops:

select(0, NULL, NULL, NULL, {0, 10000}) = 0 (Timeout)
select(0, NULL, NULL, NULL, {0, 10000}) = 0 (Timeout)
select(0, NULL, NULL, NULL, {0, 10000}) = 0 (Timeout)

And had a lock on the database, preventing recovery. One of these, process 2277, may still be running. (We hacked around the locking problem.)

I don’t understand the cause of the select loops, but based on when the db got wedged and how the log files looked around then and other things, I hypothesise that the db wedge problem is at least partially caused by the following scenario:

1. user a accesses the repo, via svnserve
2. svn creates a new log file, mode 644, owned by user a.
3. user b accesses the repo, via http.
4. as it is unable to write to the new log file, the svn running as www-data
marks the db as needing recovery

Normally there would be a run of the minutely cron job in between steps 2 and 3, but with an active repository, there is no guarantee of this happening.

Of course, this is hardly the only race. Looking at your cron job, I see another race. First it chowns all files to www-data, then it goes back through and fixes the permissions. There is a race here that can result in a file owned by www-data and mode 644 existing in the repo, when the user who just created that same file with a previous subversion invocation tries to access it, fails, and wedges the repository once again.

I respectfully encourage the alioth admins to find a repository permissions setup that is not brain-damanged, or the d-i project may have to take our repository elsewhere.

Two suggestions for fixing it would be to use ACLs, or to put wrappers around all the subversion stuff that sets a sane umask. Bastian Blank has experience with successfully using ACLs with subversion; I have used the latter method successfully on multi-user subversion repositories.
07/27/2004 20:54 –ACTION
IT –VM –4.00 hrs
Revision de version, actualizacion, reincorporacion de repositorios.
Directorios u+s g+s db/
de vez en vez.. tenemos fallas aun…

07/22/2004 20:25 –ACTION
IT –VM –4.00 hrs
svn. Vian rompe el repositori… version anterior del subversion????, sticky bit a grupo al grupo mundito.
svnserve para acceso de usuarios anonimos
svn checkout svn://linux.ajusco.upn.mx/mundito
07/22/2004 20:24 –ACTION
IT –VM –3.00 hrs
Creacion de wrappers para subversion…
prueba de tortoise, svn+ssh, svn file y otras… solo se rompe al usarlo Vian
07/19/2004 15:23 –LABOR
IT –VM –2.50 hrs
Creacion del grupo svn para uso de subversion
creacion de nuevo del repositorio
aplicacion de permisos adecuados
recreacion de los repositorios del servidor
puesta a punto.
(revisar si la conexion por tortoise cvs sigue rompiendo los permisos, svnserve?)
07/19/2004 15:22 –LABOR
IT –VM –2.00 hrs
Actualizacion de version de subversion
backup del repositorio original
07/09/2004 14:25 –NOTE
IT –VM –1.00 hrs
¿Que version de svn tenemos?
¿Que base de datos usa?
¿Podemos migrar a la version mas nueva, sin romper el repositorio?
07/09/2004 14:24 –ACTION
IT –VM –2.00 hrs
Fallo en subversion, otra vez la base de datos… script para mantener los permisos de la BD svn.perm.sh
05/31/2004 13:42 –NOTE
IT –VM –2.00 hrs
Bueno cambio de grupo chmod g+s db/ -R
a todo lo que esta en las Bases de Datos…
svnadmin recovery /var/svn/mundito
veamos si ahora si jala la cosa esta .. finalmente
05/27/2004 23:13 –QUESTION
IT –VM –1.00 hrs
Vuelve a fallar en la creacion en /var/svn/mundito/db
cuando crea los logs, les asigna el gid y uid de quien los creo en lugar de los del grupo…
investigar como resolver esto.
05/24/2004 19:41 –SOLUTION
IT –VM –1.00 hrs
The svn+ssh:// server checklist

It can be quite tricky to get a bunch of users with existing SSH accounts to share a repository without permissions problems. If you’re confused about all the things that you (as an admininstrator) need to do on a Unix-like system, here’s a quick checklist that resummarizes some of things discussed in this section:
-All of your SSH users need to be able to read and write to the repository. Put all the SSH users into a single group. Make the repository wholly owned by that group, and set the group permissions to read/write.

-Your users need to use a sane umask when accessing the repository. Make sure that svnserve (/usr/local/bin/svnserve, or wherever it lives in $PATH) is actually a wrapper script which sets umask 002 and executes the real svnserve binary.

-When BerkeleyDB creates new logfiles, they need to be owned by the group as well, so make sure you run chmod g+s on the repository’s db directory.
http://svnbook.red-bean.com/svnbook/ch06s05.html
05/24/2004 19:38 –NOTE
IT –VM –1.00 hrs
The most common problem administrators run into is repository ownership and permissions. Does every process (or user) in the previous list have the rights to read and write the Berkeley DB files? Assuming you have a Unix-like operating system, a straightforward approach might be to place every potential repository user into a new svn group, and make the repository wholly owned by that group. But even that’s not enough, because a process may write to the database files using an unfriendly umask

Esta entrada fue publicada en General. Guarda el enlace permanente.

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.