CAP

La idea del cap surge bajo la necesidad de crear un sistema de replicacion, en un principio, de ficheros entre distintos servidores. Este sistema de replicacion en un principio se contemplo la posibilidad de usar unison, pero se descarto pronto por ser un sistema de syncronizacion entre un par de maquinas, y no contemplado para varias. Fue entonces cuando probamos con csync2, que es un sistema de sincronizacion orientado a distintas maquinas. Csync2 funciona de forma que cada maquina ha de tener registradas todas las otras maquinas con las que ha de sincronizar, y aquellas con esta. De esta forma ambas son conocedoras de con quien se sincronizan. Ademas de eso han de compartir una clave comun por la cual tienen un contrato de confianza, incluyendo tambien la posibilidad de realizar la comunicacion mediante ssl. En cuanto al sistema de sincronizacion funciona de la siguiente forma :

	Cada maquina distribuye solo los cambios que tiene a las demas, siendo imposible de forma natural pedir una sincronizacion con las demas. Este punto desencadena en buscar un metodo añadido para solicitar la sincronizacion de los datos que veremos mas tarde.
	Contiene un metodo de resolucion de conflictos el cual tiene a elegir entre unos determinados estados como son el mas joven gana, el mas viejo gana, quien primero lanzo el csync gana, none, el mas grande, el mas pequeño, o incluso definir que maquina tiene mas peso de todos las registradas en csync.
	Es capaz de recordar que maquinas no se han sincronizado con ella o en que estado estan los ficheros , mediante una base de datos que tiene.

Se podria pensar que unicamente con csync2 se podria realizar la sincronizacion, pero como hemos comentado no hay una forma natural de solicitar sincronizaciones de una forma natural. Y aunque se implementara, se podria dar el caso en que algunas maquinas siempre esten apagadas cuando otras esten encendidas y viceversa. Esto produciria un estado de persecucion insolucionable. En este punto es donde entra en accion rsync. 

Para nuetro cometido utilizamos el demonio de rsync, al cual le puedes configurar modulos. Estos son rutas a ciertos path en los cuales puedes hacer un control de usuarios mediante una clave, inclusion de ficheros, exclusion, y demas cosas. En nuestro caso lo vamos a utilizar para realizar aquellos casos que se escaparian al funcionamiento normal del cap. Los casos los iremos viendo en adelante. Ya que rsync si que sera un servicio bajo peticion deberemos crear un sistema similar al dhcp, por el cual un cliente solicite una sincronizacion y alguien se la ofrezca. Pongamos por ejemplo que se enciende un servidor que ya esta unido al cap. Este enviara una especide de broadcast. Entonces los servidores responderan, mas o menos rapido ( esto depende de un valor de peso que se define en cada servidor dependiendo de que tipo de servidor sea : centro, servidor de aula, biblioteca, ...). El cliente que se conecta al que mas rapido le ha contestado y omitira las otras respuestas que llegaran mas tarde. Con el servidor que ha seleccionado lo que debera hacer es ¿enviar una sincronizacion con todos y luego pedir una sincronizacion al sevidor rsync?. En esta sincronizacion se actualizaran los datos y el estado del cap.

Casos que se pueden dar :
	* Servidor se une por primera vez
	* Servidor arranca despues de estar apagado
	* Servidor/es que ha estado fuera de la red un tiempo

Crear un CAP:
	Se tienen que crear las claves para rsyncd, para replicant de ldap, para csync2; Se tiene que añadir la variable MASTER en ¿LDAP_MODE?, se tiene que inicializar ldap y kerberos.