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):<\/p>\n
11\/09\/2004 20:46 –TESTED
\nIT –VM
\nse cierra
\n11\/09\/2004 20:46 –CLOSED
\nIT –n\/a
\n09\/22\/2004 12:48 –PENDING
\nIT –VM –2.00 hrs
\nHasta nueva version de subversion la solucion es la que ya se encontro.
\nEs 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)
\n07\/29\/2004 16:18 –SOLUTION
\nIT –VM –2.00 hrs
\nLa solucion de Alioth (ACLS), es solo usar un metodo para la escritura… citando:
\nWrite access is only allowed through svnserve over a ssh transport. Access control is handled through Alioth.
\nDecidir si dejamos esto aun para los usuarios locales…
\n07\/29\/2004 03:19 –LABOR
\nIT –VM –1.00 hrs
\nEl 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 \u00abjust in time\u00bb… queda pendiente el arreglar como se debe esta cosa.
\n07\/29\/2004 03:04 –ACTION
\nIT –VM –1.00 hrs
\nCron para mantener los permisos corrido cada minuto.
\nComo fue detallado en el caso del servidor de debian, en el caso de muchos desarrolladores si es \u00abriesgoso\u00bb, aqui vamos a implementarlo mientras no tengamos mejor solucion.
\nMandar correo al admin de debian, para ver como resolvieron el problema.
\nsolucion propuesta:
\n#!\/bin\/bash
\nchmod ug+w \/var\/svn\/mundito\/db\/*
\nchown svn.svn \/var\/svn\/mundito\/db\/*
\n07\/29\/2004 02:59 –NOTE
\nIT –VM –2.00 hrs
\n-rw-rw-r– 1 svn svn 1023k Jul 29 02:49 log.0000000013
\n-rw-r–r– 1 vicm3 svn 232k Jul 29 02:50 log.0000000014
\nal llenarse el log crea uno nuevo con el usuario que estaba haciendo la ultima transaccion…
\nAhora lo interesante, se puede cambiar el tama\u00f1o del log… podria dejarlo crecer no se hasta varios megas para hacer que el problema se espacie un tanto mas…
\ndavid@linux:~\/borrame$ svn co file:\/\/\/var\/svn\/mundito\/
\nsvn: Berkeley DB error while committing Berkeley DB transaction for filesystem \/var\/svn\/mundito\/db:
\nDB_RUNRECOVERY: Fatal error, run database recovery
\n\/usr\/local\/bin\/svn: line 4: 22685 Aborted \/usr\/bin\/svn \u00ab$@\u00bb
\ndavid@linux:~\/borrame$ svn co file:\/\/\/var\/svn\/mundito\/
\nsvn: Unable to open an ra_local session to URL
\nsvn: Unable to open repository ‘file:\/\/\/var\/svn\/mundito’
\nsvn: Berkeley DB error while opening environment for filesystem \/var\/svn\/mundito\/db:
\nDB_RUNRECOVERY: Fatal error, run database recovery<\/p>\n
aqui el error documentado.
\nLa otra solucion parcial seria la alliot… usar un cron (hasta que entienda lo de las ACLS).
\nMhh..
\n07\/29\/2004 02:18 –NOTE
\nIT –VM –0.10 hrs
\nBerkeley 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.
\nhttp:\/\/radio.weblogs.com\/0100148\/2002\/10\/20.html
\n07\/29\/2004 02:03 –ACTION
\nIT –VM –4.00 hrs
\nhttp:\/\/alioth.debian.org\/tracker\/index.php?func=detail&aid=300579&group_id=1&atid=200001
\nel error que encontramos no es tan trivial como pareciera… de lo que leo hay dos soluciones, rapidas…
\n1) Crear un solo usuario con el que todos hagan uso de svn
\n2) Usar ACL (aun no entiendo como)
\nComo nota al calce este mismo problema tambien lo tuvo gnome…
\nTracker: Support Requests<\/p>\n
Submit New | Browse | Admin<\/p>\n
[ #300579 ] permissions system is a disaster waiting to happen
\nDate:
\n2004-03-21 13:51 Priority:
\n8
\nSubmitted By:
\nJoey Hess (joeyh) Assigned To:
\nLocal GForge Admin (admin)
\nCategory:
\nSubVersioN State:
\nClosed
\nSummary:
\npermissions system is a disaster waiting to happen<\/p>\n
Detailed description:
\nAlioth’s subversion permissions system is broken in subtle ways that affect more active projects. First an overview of the system as I understand it:<\/p>\n
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.<\/p>\n
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.<\/p>\n
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.<\/p>\n
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:<\/p>\n
select(0, NULL, NULL, NULL, {0, 10000}) = 0 (Timeout)
\nselect(0, NULL, NULL, NULL, {0, 10000}) = 0 (Timeout)
\nselect(0, NULL, NULL, NULL, {0, 10000}) = 0 (Timeout)<\/p>\n
And had a lock on the database, preventing recovery. One of these, process 2277, may still be running. (We hacked around the locking problem.)<\/p>\n
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:<\/p>\n
1. user a accesses the repo, via svnserve
\n2. svn creates a new log file, mode 644, owned by user a.
\n3. user b accesses the repo, via http.
\n4. as it is unable to write to the new log file, the svn running as www-data
\nmarks the db as needing recovery<\/p>\n
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.<\/p>\n
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.<\/p>\n
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.<\/p>\n
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.
\n07\/27\/2004 20:54 –ACTION
\nIT –VM –4.00 hrs
\nRevision de version, actualizacion, reincorporacion de repositorios.
\nDirectorios u+s g+s db\/
\nde vez en vez.. tenemos fallas aun…<\/p>\n
07\/22\/2004 20:25 –ACTION
\nIT –VM –4.00 hrs
\nsvn. Vian rompe el repositori… version anterior del subversion????, sticky bit a grupo al grupo mundito.
\nsvnserve para acceso de usuarios anonimos
\nsvn checkout svn:\/\/linux.ajusco.upn.mx\/mundito
\n07\/22\/2004 20:24 –ACTION
\nIT –VM –3.00 hrs
\nCreacion de wrappers para subversion…
\nprueba de tortoise, svn+ssh, svn file y otras… solo se rompe al usarlo Vian
\n07\/19\/2004 15:23 –LABOR
\nIT –VM –2.50 hrs
\nCreacion del grupo svn para uso de subversion
\ncreacion de nuevo del repositorio
\naplicacion de permisos adecuados
\nrecreacion de los repositorios del servidor
\npuesta a punto.
\n(revisar si la conexion por tortoise cvs sigue rompiendo los permisos, svnserve?)
\n07\/19\/2004 15:22 –LABOR
\nIT –VM –2.00 hrs
\nActualizacion de version de subversion
\nbackup del repositorio original
\n07\/09\/2004 14:25 –NOTE
\nIT –VM –1.00 hrs
\n\u00bfQue version de svn tenemos?
\n\u00bfQue base de datos usa?
\n\u00bfPodemos migrar a la version mas nueva, sin romper el repositorio?
\n07\/09\/2004 14:24 –ACTION
\nIT –VM –2.00 hrs
\nFallo en subversion, otra vez la base de datos… script para mantener los permisos de la BD svn.perm.sh
\n05\/31\/2004 13:42 –NOTE
\nIT –VM –2.00 hrs
\nBueno cambio de grupo chmod g+s db\/ -R
\na todo lo que esta en las Bases de Datos…
\nsvnadmin recovery \/var\/svn\/mundito
\nveamos si ahora si jala la cosa esta .. finalmente
\n05\/27\/2004 23:13 –QUESTION
\nIT –VM –1.00 hrs
\nVuelve a fallar en la creacion en \/var\/svn\/mundito\/db
\ncuando crea los logs, les asigna el gid y uid de quien los creo en lugar de los del grupo…
\ninvestigar como resolver esto.
\n05\/24\/2004 19:41 –SOLUTION
\nIT –VM –1.00 hrs
\nThe svn+ssh:\/\/ server checklist<\/p>\n
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:
\n-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.<\/p>\n
-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.<\/p>\n
-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.
\nhttp:\/\/svnbook.red-bean.com\/svnbook\/ch06s05.html
\n05\/24\/2004 19:38 –NOTE
\nIT –VM –1.00 hrs
\nThe 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<\/p>\n","protected":false},"excerpt":{"rendered":"
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 … Sigue leyendo