2012-06-06 9 views
7

Busqué y encontré algunos temas relacionados, pero todos estaban relacionados con la limitación del tamaño de los archivos o las preocupaciones de que hubiera cuotas.¿Hay un gancho lateral del servidor Git para poner la cuota en los tamaños del repositorio?

Creé un servidor Git con Gitolite como lugar para que los estudiantes compartan proyectos del curso. Todo funciona bajo un nombre de usuario en el servidor, git, con un repositorio comodín "projects/Creator/[a-zA-Z0-9]. *". Los repositorios tienen ESCRITORES y LECTORES definidos para que el usuario pueda modificar quién puede escribir y leer su repositorio.

archivos de claves SSH se implementan de modo que el usuario sólo puede crear un repositorio por:

git [email protected] clon: proyectos/bob/proyecto1 git [email protected] clon: proyectos/bob/someotherproj

y así sucesivamente. La carpeta "bob" se crea la primera vez que hacen el clon git (es su nombre de usuario).

Mi problema es que, al ser alumnos, habrá abuso y tendré que limitar el tamaño de la carpeta "bob". Las cuotas de disco no funcionan porque todas las carpetas y archivos son propiedad de git, y eso ya es limitado.

Probablemente pueda volver a diseñar esto para servir sus proyectos desde sus carpetas de inicio de Linux y así poder usar cuotas de disco, sin embargo, preferiría no tener que volver a diseñar este servidor ahora que lo tengo funcionando.

Esencialmente, que estaba buscando un gancho que hizo algo como esto shell script áspera:

foldersize=`du -s $GITPATH/projects/$USERNAME` 
if [ $foldersize > 250000 ]; then 
    echo "Quota Exceeded" 
    exit 1 
fi 

entiendo que hay ganchos del lado del servidor que se pueden escribir, quería ver si la rueda ya fue creado antes de empezar a tallarlo. Entonces, ¿algún gancho para limitar el tamaño del repositorio?

Respuesta

4

El gancho git pre-receive se puede utilizar para implementar cuotas. De la página githooks(5) hombre:

This hook is invoked by git-receive-pack on the remote repository, 
which happens when a git push is done on a local repository. Just 
before starting to update refs on the remote repository, the 
pre-receive hook is invoked. Its exit status determines the success or 
failure of the update. 

por lo que sería poner su cuota de lógica de comprobación en este guión y permitir o rechazar una actualización de entrada en función del resultado. Sería su trabajo realizar realmente la administración de cuota; Hay varias maneras de hacerlo, la más simple es confiar en la compatibilidad del sistema de archivos con las cuotas de usuario.

Sin duda podría usar su ejemplo du, aunque a medida que los repositorios crecen en tamaño, esto impondrá un retraso sustancial (y una carga de E/S) para cada actualización. Almacenar en caché los resultados de este script durante cierto tiempo probablemente sea de ayuda, aunque es obvio que alguien podría exceder su cuota si envía una actualización antes de que el caché haya expirado.

Dependiendo de cómo se organice su almacenamiento, puede buscar cuotas por directorio para los repositorios git (si su almacenamiento proviene de algo que lo soporte, como la mayoría de servidores de archivos empresariales) o usar un volumen LVM por repositorio (como sugirió here).

A pesar de las sugerencias en sentido contrario, la implementación de cuotas para un repositorio remoto es bastante común. La mayoría de los servicios de hosting git limitan su almacenamiento en disco y rechazarán las actualizaciones una vez que llegue a su límite.

+0

De acuerdo con la página de manual, el enlace previo a la recepción se puede pasar por alto con una opción --noverify ... El problema con el soporte del sistema de archivos es que todo está bajo un UID con gitolite. Supongo que tendré que volver a diseñar la solución para usar las cuotas de usuarios del nivel de sistema de archivos y varias cuentas ... y pensé que ya casi había terminado con este servidor ... suspiro. –

+0

Es por eso que mencioné las cuotas por directorio; esto resuelve el problema de "todo es un usuario". – larsks

+0

También tenga en cuenta que '--no-verify' es un argumento para' commit', no para 'push'. Un usuario remoto no puede anular su gancho 'pre-receive'. – larsks

0

git no tiene ninguna funcionalidad para implementar cuotas. No creo que haya una manera sensata que podría. ¿Qué pasaría cuando alcances tu cuota? Ya no podrá realizar commits, obtener actualizaciones de repositorios remotos o cualquier cantidad de otras actividades de mantenimiento. Más o menos 'alcanzar cuota' === 'muerte instantánea a la funcionalidad del repositorio' ...

+0

Para lo que esto se usaría, tal situación no es un gran problema. Si estuviera apoyando el desarrollo, entonces el espacio de disco es más barato que arriesgar el repositorio. –

Cuestiones relacionadas