[Ayuda] Subversion...

Victor Martinez vicm3 en linux.ajusco.upn.mx
Sab Jul 31 01:25:32 CDT 2004 

Bueno por si alguien esta migrando a subversion... desde cvs... aqui les 
van unas cosas que deberian saber y que no vienen en el manual... el 
seguimiento de una orden de servicio en la oficina. (Por cierto svn 1.0 en 
Debian, por ahi ya anda el RC nuevo, espero arregle estas ondas).
Salu2
Log Entries
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 en 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 en 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>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 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>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­one 
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 hrs
Falla 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.



 
_______________________________________________
Ayuda mailing list
Ayuda en linux.org.mx
Para salir de la lista: http://mail.linux.org.mx/cgi-bin/mailman/listinfo/ayuda/

Más información sobre la lista de distribución Ayuda