Diferencia entre revisiones de «Tutorial de uso de CVS»
Contenido eliminado Contenido añadido
Sin resumen de edición |
Sin resumen de edición |
||
Línea 43:
*.aux *.dvi *.ps *.log
si los ficheros de este módulo son principalmente documentos escritos en (La)TeX, ya que las extensiones mostradas arriba corresponden a los diferentes ficheros temporales creados durante el procesado del fichero fuente original para obtener el fichero listo para impresión.
Línea 54 ⟶ 53:
diff -uw
cvs -z 3
Significa que queremos que cuando usemos la orden update, automáticamente se añadan los parámetros -Pd. Algo similar ocurre con la orden diff, a la que se le añadirán los parámetros -uw.
Línea 74 ⟶ 72:
export CVSROOT=:ext:USUARIO@cvs.dominio.org:/var/lib/cvs
export CVS_RSH=/usr/bin/ssh
Donde:
Línea 99 ⟶ 97:
export CVSROOT=:pserver:USUARIO@cvs.dominio.org:/var/lib/cvs
Donde:
Línea 216 ⟶ 213:
cd directorio-del-módulo
cvs remove -f fichero
=Cómo configurar un servidor y cómo incorporar nuevos módulos al repositorio.=
==Configuración del servidor.==
Para configurar un servidor CVS con acceso remoto hay básicamente tres formas:
* rsh/ssh: Esta primera opción implica tener una cuenta equivalente en el servidor CVS y no hace falta tocar ni inetd.conf ni ejecutar el servicio pserver. La seguridad de esta solución es nula a menos que se use ssh como sustituto de rsh.
* pserver: La segunda opción usa una cuenta genérica (la misma para todo el mundo o varias diferentes si se desean, pero no son cuentas con acceso local al servidor), necesita activar pserver desde inetd.conf (o xinetd.conf, si se usa este último). La seguridad es superior al método precedente en caso de usar rsh pero inferior al uso de ssh. La gran ventaja de este método es que los usuarios de CVS no necesitan ningún tipo de acceso local al servidor.
* Kerberos: Kerberos queda fuera de juego a mi modesto entender, ya que la infraestructura necesaria para usar este método de autenticación simplemente no tiene sentido para uso de CVS fuera de un mismo dominio administrativo (sin contar la complejidad de instalación y operación de un dominio Kerberos).
En la práctica, buena parte de los servidores CVS públicos usan la opción de pserver, al no ser necesario dar de alta cuentas de sistema a los usuarios en el servidor. Si el acceso va a ser mucho mas restringido (un pequeño grupo estable y de confianza), la opción de usar ssh es claramente preferible.
Si optamos por el método pserver, deberemos añadir una línea como la siguiente en el fichero inted.conf:
cvspserver stream tcp nowait root /usr/sbin/tcpd /usr/bin/cvs -b /usr/bin -f --allow-root=/var/lib/cvs pserver
El valor /var/lib/cvs corresponde al directorio donde ubicaremos el repositorio en el servidor CVS y que denotaremos de ahora en adelante por la variable de entorno $CVSROOT.
Hay que asegurse también, en caso de estar usando TCP Wrappers (como es el caso del ejemplo) de que permitimos el acceso al servicio CVS (en el fichero /etc/hosts.allow con una línea como la siguiente. De lo contrario se van a rechazar las conexiones.
cvs: ALL
==Clases de usuarios y tipo de acceso permitido.==
El segundo punto a tener en cuenta es quién tiene acceso a los repositorios CVS y qué tipo de operaciones se pueden realizar. Basicamente, una vez creado el repositorio, se suelen realizar dos grandes grupos de operaciones:
*Adición/actualización de ficheros del repositorio (implica acceso en modo escritura). Aqui van los commit, add, remove, ...
*Actualizaciones en el cliente/creación de diferencias. Esto sólo implica acceso en modo lectura. Aqui van los checkout, update, diff, ...
El acceso en modo escritura al repositorio sólo se debe otorgar a las personas estrictamente necesarias, ya que en teoría el acceso al sistema se abre potencialmente bastante.
==Creacion inicial del repositorio==
A continuación se muestran los pasos a realizar para la creación inicial del repositorio CVS.
* Configurar /etc/inetd.conf para que lance el servidor pserver como se ha comentado arriba, en caso de usar el método de acceso pserver.
* Definir una cuenta administrativa local para CVS (en el ejemplo se llamará cvsadm) que será quien administre CVS. Esta cuenta será la propietaria de los ficheros de control del repositorio y quien pueda crear nuevos módulos en el mismo. Aprovecharemos para crear un grupo llamado cvs para gestionar más cómodamente los permisos del repositorio y sus módulos. El usuario cvsadm deberá ser parte del grupo cvs. Sin embargo esta cuenta no tienen porque tener acceso local al sistema en caso de usar el método de acceso pserver.
* Crear el repositorio en local en el servidor (en $CVSROOT), ejecutando las ordenes (si queremos colocar el respositorio en /var/lib/cvs):
export CVSROOT=/var/lib/cvs
mkdir -p $CVSROOT
cvs init
El repositorio conviene crearlo como root y tratarlo, desde el punto de vista de los permisos, como si fuera el directorio /etc. Todos sus ancestros sólo deberian ser escribibles por root. El propio $CVSROOT debería ser escribible por el administrador del servidor CVS (cvsadm, como hemos indicado más arriba). NADIE MAS debería tener permisos de escritura en dicho directorio.
Esto se hace asignando su propiedad al usuario cvsadm y haciendo al grupo cvs el grupo de $CVSROOT. Además, sería conveniente que $CVSROOT tuviera activado el bit SGID, para que los subdirectorios y ficheros que se creen debajo hereden el grupo principal del fichero o directorio (e indirectamente, por el ajuste del valor de umask que hace el propio CVS en modo pserver, el permiso de escritura para el grupo cvs y que tenga así control sobre todo lo que se introduzca allí). En resumen, $CVSROOT debería tener los permisos:
drwxr-s--- 10 cvsadm cvs 1024 Oct 2 12:31 $CVSROOT
* El usuario cvsadm será el propietario de los ficheros que haya en $CVSROOT/CVSROOT. El único fichero que es necesario que tenga permisos de escritura para los usuarios de CVS es $CVSROOT/CVSROOT/history. El resto, deben tener sólo permiso de lectura. Esto es:
$CVSROOT/CVSROOT: drwxr-x--- 2 cvsadm cvs 1024 Oct 2 12:52 CVSROOT
$CVSROOT/CVSROOT/history: -rw-rw---- 1 cvsadm cvs 9609 Oct 2 13:01 history
$CVSROOT/CVSROOT/commitlog: -rw-rw---- 1 cvsadm cvs 9609 Oct 2 13:01 commitlog (*)
$CVSROOT/CVSROOT/log.pl: -r-xr-x--- 1 cvsadm cvs 9609 Oct 2 13:01 log.pl (*)
$CVSROOT/CVSROOT/*: -r--r----- 1 cvsadm cvs 9609 Oct 2 13:01 (el resto de ficheros)
(*) Esto sólo es necesario si se va a usar la caracteristica loginfo con el script log.pl o similares. En cualquier caso, no deberia ser problemático.
* Incorporar al grupo cvs los diferentes usuarios locales que van a representar a los usuarios remotos de pserver. En concreto, en mi sistema, existen cvsadm, cvsuser y anoncvs, que representan respectivamente al administrador del servidor CVS, a los usuarios CVS con permiso de escritura en el repositorio (previa autenticación) y a los usuarios con acceso sólo lectura en modo anónimo. La idea de este grupo (como se ha comentado arriba) es poder asignar los permisos locales a los ficheros de forma que tanto el administrador como los usuarios tengan acceso a ellos.
* Si se va a usar pserver, es muy importante que los usuarios que tengan que ver con CVS (cvsadm, anoncvs y cvsuser) no puedan tener acceso local al servidor (esto es, poner una contraseña no válida, un shell no válido, etc.)
* Los módulos iniciales para cada proyecto (manual, como, programa, etc.) los debe crear el administrador del servidor CVS. Luego los puede usar cualquiera. Así garantizamos que los permisos son los adecuados, y que todo esta «controlado y en orden».
* Para funcionalidades adicionales (envio de mensaje de corre cada vez que se hace un commit, actualizacion de un log de commit en el repositorio, publicacion en el web del estado del repositorio, etc.) el propio administrador del servidor CVS se puede encargar de todo. Todo lo necesario esta en la documentación oficial de CVS.
Todo lo anterior (especialmente el tema de permisos, usuarios necesarios, etc.) son conclusiones mías despues de leer la documentacion de CVS y su FAQ. No está indicado en ningún sitio que se deba hacer exactamente así, ya que sólo se dan consejos muy generales y bastante dispersos por toda la documentación. Con esto quiero decir que habría que hacer un análisis un poco más profundo sobre el posible impacto de seguridad.
==Alta de usuarios==
===Para el método de acceso ssh===
En este caso, los usuarios de CVS son directamente usuarios del sistema. Por tanto, el administrador del sistema donde resida el servidor CVS debe dar de alta los usuarios normales y habilitar los permisos adecuados en el repositorio (y sus diferentes ficheros) para que puedan llevar a cabo el tipo de acceso deseado.
===Para el método de acceso pserver===
En este caso, tenemos que usar los ficheros $CVSROOT/CVSROOT/passwd , $CVSROOT/CVSROOT/readers y $CVSROOT/CVSROOT/writers . El primero de ellos sirve para indicar qué usuarios remotos tienen acceso al repositorio y el segundo y tercero indican qué usuarios de entre los anteriores tiene acceso en modo sólo lectura y cuáles en modo lectura/escritura, respectivamente.
El formato del primero de ellos es similar al de los ficheros de contraseñas de Apache y de hecho se puede crear y manipular con la herramienta htpasswd. Decimos similar porque no es exactamente igual, al disponer de un tercer campo opcional que nosotros si usaremos. Veamos un ejemplo:
cvsadm:8BQYT0o1J7FI6:cvsadm
anoncvs:
hermes-team:8Ba2dFouJkxI6:cvsuser
lucasiano:gA7sdFouJk9X6:cvsuser
En el ejemplo anterior tenemos cuatro usuarios remotos, pero en realidad sólo tres usuarios locales. Los usuarios «remotos» son cvsadm, anoncvs, hermes-team y lucasiano. Estos son los nombres de usuario que se usarán durante el proceso de autenticación.
Sin embargo, una vez superada la autenticación correctamente (el segundo campo del fichero es la contraseña cifrada con el método crypt estándar; si no existe, como en el caso del usuario anoncvs, valdrá cualquier contraseña), se usarán los usuarios que se indican en el tercer campo para el acceso local a los ficheros del repositorio. Esto es, el usuario remoto lucasiano en realidad será el usuario local cvsuser en el servidor y por tanto tendrá acceso a los ficheros y directorios a los que pueda acceder dicho usuario. En caso de no existir este tercer valor, el nombre de usuario remoto y el local serán el mismo.
Esta funcionalidad es muy interesante, ya que nos permite crear únicamente una cuenta de usuario local en el servidor por cada tipo de acceso diferente necesario, y agregar después cuantas cuentas remotas queramos y mapearlas al usuario local correspondiente. Como el fichero donde se realiza el mapeo es $CVSROOT/ROOT/passwd y este fichero está disponible a través del propio CVS, el administrador del servidor CVS no necesita permisos de administrador global de la máquina donde este ubicado el repositorio para dar de alta nuevos usuarios de CVS. Nótese que en este caso, el fichero con las contraseñas viaja sin cifrar por la red, con lo cual se recomienda usar el método de acceso ssh para este tipo de operaciones).
Para crear nuevos usuarios CVS podemos usar la orden htpasswd de Apache:
export CVSROOT=:ext:cvsadm@cvs.servidor.org:/var/lib/cvs
export CVS_RSH=/usr/bin/ssh
cd directorio-temporal-de-trabajo
cvs checkout CVSROOT
cd CVSROOT
htpasswd passwd usuario-nuevo (*)
New password: no-se-ve-mientras-se-escribe
Re-type new password: no-se-ve-mientras-se-escribe
vi passwd (**)
cvs add passwd (*) y (***)
cvs commit
(*) Si fuese el primer usuario del repositorio, el fichero passwd no existirá, y por tanto será necesario usar la opción -c de la orden htpasswd. De igual modo, habrá que indicar a CVS que existe un nuevo fichero llamado passwd para que lo tenga en cuenta y lo añada al repositorio al hacer el commit.
(**) Si se desea la funcionalidad de mapear el usuario remoto a un usuario local concreto, se puede editar el fichero a mano y añadir el tercer campo, separándolo del segundo por ':'.
(***) Para que esto funcione es necesario haber incluido el nombre del fichero passwd en el fichero $CVSROOT/checkoutlist previamente. (no se aconseja por motivos de seguridad a menos que el acceso administrativo a CVSse realice por medio de ssh, como se ha comentado más arriba y se ha hecho en el ejemplo mostrado).
Hemos mencionado más arriba los ficheros $CVSROOT/CVSROOT/writers y $CVSROOT/CVSROOT/readers. El proposito de ambos es poder delimitar aún más el tipo de acceso permitido a los usuarios remotos. Si un nombre de usuario aparece en el fichero $CVSROOT/CVSROOT/writers este usuario tendrá acceso a las operaciones que impliquen modificaciones al repositorio. Este fichero contiene simplemente el nombre de los usuarios «remotos», uno por línea, que tienen este tipo de acceso:
cvsadm
hermes-team
lucasiano
Si por el contrario aparece en el fichero $CVSROOT/CVSROOT/readers, sólo tendrá acceso en modo lectura y no podrá hacer ningún cambio en el repositorio. El formato es idéntico al fichero anterior.
En caso de que aparezca en ambos ficheros, obtiene acceso de sólo lectura. En caso de que no existan ninguno de los dos ficheros, el usuario obtiene acceso de escritura, así que asegúrese de crearlos durante la configuración inicial del repositorio (no vienen creados de serie).
Por último, hay que tener muy presente que el control de acceso a los módulos se hace en base a los permisos de los directorios y ficheros del repositorio. Por tanto, si se quieren módulos con usuarios completamente independientes, habrá que extender el esquema usuarios/grupos locales aquí presentado y jugar con los permisos. Esto supone una cierta complicacion para el administrador tanto del sistema como del repositorio CVS.
| |||