[Previo por Fecha] [Siguiente por Fecha] [Previo por Hilo] [Siguiente por Hilo]
[Hilos de Discusión] [Fecha] [Tema] [Autor]Salu2 Log Entries 07/29/2004 16:18 --SOLUTION IT --VM --2.00 hrsLa 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 hrsEl 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.0000000014al 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 hrsBerkeley 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>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>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 recoveryNormally 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 hrssvn. 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 hrsFallo 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/dbcuando 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 checklistIt 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>http://svnbook.red-bean.com/svnbook/ch06s05.html 05/24/2004 19:38 --NOTE IT --VM --1.00 hrsThe 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 umaskone that prevents access by other users.
(resuelto todos estamos en el grupo www-data y mundito)Another common problem is often encountered on Unix-like systems. As a repository is used, BerkeleyDB occasionally creates new logfiles to journal its actions. Even if the repository is wholly owned by the svn group, these newly created files won't necessarily be owned by that same group, which then creates more permissions problems for your users. A good workaround is to set the group SUID bit on the repository's db directory. This causes all newly-created logfiles to have the same group owner as the parent directory.
Once you've jumped through these hoops, your repository should be accessible by all the necessary processes. It may seem a bit messy and complicated, but the problems of having multiple users sharing write-access to common files are classic ones that are not often elegantly solved.
Mhh... hecho.. veamos si esto resuelve el problema 05/24/2004 19:20 --NOTE IT --VM --1.00 hrsFalla en el uso de subversion... cada que un usuario modifica o crea una nueva revision la BD y los archivos quedan en su posecion (uid.gid)... por lo que los subsecuentes usuarios no pueden modificarlo.
Investigar sobre el stiky bit... para que los archivos creados sean del grupo www o mundito o crear uno nuevo svn para el uso de svn.
05/24/2004 19:19 --CREATED
IT --VM
Victor Manuel Martinez Mtz.
What I Do
I build paradigms...
I work on complex ideas and make up words for them.
It is the only way.
Ted Nelson.