Mirror de los repositorios en LAN con Mandriva 2010.1

Juolas.

Vamos a montar un mirror local de los repositorios oficiales de Mandriva (o de los que uno quiera, HOYGAN) para agilizar las actualizaciones del parque informático que tengamos por ahí.

Los que tengan un portátil y un sobremesa, a lo mejor no le ven mucha utilidad, pero si teneis 4 máquinas en el metro cuadrado en el que aposentais el culo, mas los portátiles. O teneis una infraestructurilla en la oficina o cosas así, seguro que sopesareis el gasto de HD extra que conlleva.

La cosa se basa en configurar a tres bandas. Por un lado, necesitamos una máquina servidor, la cual contendrá un directorio donde alojaremos nuestro mirror, actualizándose periódicamente. Después las máquinas cliente (que pueden incluir a la servidora, en su vertiente de "cliente de actualizaciones") habrá que configurarlas para que busquen dichas actualizaciones en nuestro repo local.

Podemos usar, ftp, http o rsync para dar el servicio de actualización vía LAN. En esta receta, usaremos http, ya que tengo a mi buen, viejo y feo lighty currando como un campeón.

Disco:

Como mi caso particular está basado en distros de 64bits, debo ser generoso. Usemos unos 40Gb inicialmente, para alojar a /main /main32 /contrib /free y /nonfree, junto con todas sus ramas /backports /testing /release y /updates. Así, si queremos instalar algún programa, también podremos hacerlo vía LAN.

Si al acabar vemos que sobra mucho espacio (jojojo), podemos darle un meneo al tamaño de la partición, si lo estimamos conveniente. Con Diskdrake o la herramienta de particionado de discos de vuestra preferencia, creamos una nueva partición del tamaño mencionado, y la montamos, digamos en /var/www/html/repos. Una vez hecho, nos acercamos al directorio donde hemos montado la partición y con un chown -R apache:apache ./repos le damos los permisos apropiados inicialmente.

En el caso de que querais montar un repo para la distro de 32bits, con unos 30Gb va que chuta, y evidentemente, los pasos exclusivos para la distro de 64 que pongo aquí os sobran...

Obteniendo los datos:

Para los más avispados, es posible utilizar el DVD de instalación para obtener gran parte de los paquetes, pero debeis contar con que la estructura de directorios es diferente en un mirror de red, así que avisados estais.

Usemos rsync. Después de todo, nos facilitará la tarea de mantener el mirror actualizado después, así que, ¿para qué usar otro método ahora?

Bueno, pues nos buscamos un mirror oficial que tenga soporte para rsync. Yo suelo usar los de ftp-stud.hs-esslingen.de que suelen ir bastante bien, aunque hay algunos europeos más que también. Podeis guiaros por las listas de mirrors que pululan por sitios como easyurpmi, por ejemplo, para buscar el vuestro.

Vamos a asumir que los repositorios los vamos a descargar en un directorio llamado /var/www/html/repos/x86_64/media. Lo creamos y le otorgamos al usuario de sistema apache, para que pueda leer y escribir en ellos.

Los repos de Mandriva son grandes. MUY grandes.

Además de las ramas que nos interesan, también están las ramas debug, que no vamos a descargar (es lo mismo que la rama principal, pero con paquetes con símbolos de depuración y cosas así). Crearemos un pequeño archivo que rsync leerá a la hora de sincronizar los directorios, y que contiene las partes del repo que no queremos descargar y le daremos el nombre de noback: 

/debug_contrib
/debug_main
/debug_non-free 

Así, tal cual. Ahora pasamos a la sincronización del repositorio x86_64 (ojito, va todo en una línea):

[root@srv1 /]# rsync --stats --progress -avz --exclude-from=/ruta/al/archivo/noback
rsync://ftp.join.uni-muenster.de/mandrakelinux/official/2010.1/x86_64/media/ /var/www/html/repos/x86_64/media/ 

Pequeña explicación del comando:
--stats y --progress nos dan información detallada de toda la operación de sincronización de archivos, hasta de la velocidad de bajada individual. Las opciones -avz conservan información de los archivos sincronizados como propietario y permisos, por ejemplo. La opción z comprime la información antes de descargarla, aunque muchos de los servidores la tienen deshabilitada para no sobrecargar la CPU del server.

--exclude-from= nos sirve para localizar el archivo que contiene los directorios que no queremos sincronizar. Después, ponemos la ruta remota y la destino.

Ya os podeis ir a dormir, porque son un montón de GB...

(Si estais montando el repo de 32 bits, cambiad "x86_64" por "i586" en todas las rutas que he puesto y ya lo teneis listo. Y el paso que voy a poner ahora, os lo saltais)

Una vez hayamos terminado de descargar el repositorio "completo", a los que usamos 64 bits nos toca también descargarnos el /main de 32. Para ello, creamos el directorio /var/www/repos/i586/media/main y damos permisos. Luego, nos colocamos en él y ejecutamos (otra vez en una línea):

[root@srv1 /]# rsync --stats --progress -avz rsync://ftp-stud.hs-esslingen.de/mandrake/official/2010.1/i586/media/main/
/var/www/html/repos/i586/media/main/

Aquí no usamos el --exclude-from porque sincronizamos el directorio /main del servidor. La rama /debug está por encima y rsync "no la ve".

Ea, unas cuantas horas más de descarga y ya lo tenemos todo a punto.

Cuando hayamos acabado, si repasamos el arbol de directorio, veremos que los permisos y el propietario de los archivos y directorios, no son precisamente los esperados. Pues nada, chown -R apache:apache a /var/www/html/repos y listos.

Una vez terminada la descarga, pasamos a configurar el servidor web para que acepte peticiones por parte de las máquinas cliente mediante urpmi. Si sólo teneis un servidor web simple corriendo, no hay que hacer gran cosa. Si teneis varios dominios, o habeis puesto el directorio de los repos fuera de /var/www/hmtl/ os tocará crear un alias (o un enlace blando también cuela).

Una vez hayamos fijado el acceso vía http al contenido de nuestro directorio /repos, es el momento de empezar a trabajar en la actualización de los mismos.

Como he comentado, usaremos rsync. Rsync es una herramienta muy poderosa para gestionar archivos en remoto (y en local). Puedes hacer de todo: Mirrors fieles, copias incrementales, diferenciales... En nuestro caso concreto, lo que haremos será programar una instancia de rsync que actualice el contenido de los directorios que sabemos que van a cambiar, ignorando los que sabemos que no van a hacerlo. Esto es, todas las ramas /release del arbol de directorios van a ser ignoradas y el resto, serán las que se sincronicen.

Lo vamos a automatizar y meterlo en el cron.daily del sistema servidor.

Sincronización:

Empezaremos por el script que va a sincronizar los directorios. Algo así (atentos de nuevo a los saltos de línea. Las órdenes rsync van en una única línea): 

#! /bin/bash
date
echo "-------------------------------------------"
echo "Main Updates:"
rsync --delete -avz rsync://ftp.join.uni-muenster.de/mandrakelinux/official/2010.1/x86_64/media/main/updates/
/repos/x86_64/media/main/updates/
echo "-------------------------------------------"
echo "Main Backports:"
rsync --delete -avz rsync://ftp.join.uni-muenster.de/mandrakelinux/official/2010.1/x86_64/media/main/backports/
/repos/x86_64/media/main/backports/
echo "-------------------------------------------"
echo "Main Testing:"
rsync --delete -avz rsync://ftp.join.uni-muenster.de/mandrakelinux/official/2010.1/x86_64/media/main/testing/
/repos/x86_64/media/main/testing/
echo "-------------------------------------------"
echo "Main32 Updates:"
rsync --delete -avz rsync://ftp.join.uni-muenster.de/mandrakelinux/official/2010.1/i586/media/main/updates/
/repos/i586/media/main/updates/
echo "-------------------------------------------"
echo "Main32 Backports:"
rsync --delete -avz rsync://ftp.join.uni-muenster.de/mandrakelinux/official/2010.1/i586/media/main/backports/
/repos/i586/media/main/backports/
echo "-------------------------------------------"
echo "Main32 Testing:"
rsync --delete -avz rsync://ftp.join.uni-muenster.de/mandrakelinux/official/2010.1/i586/media/main/testing/
/repos/i586/media/main/testing/
echo "-------------------------------------------"
echo "Contrib Updates:"
rsync --delete -avz rsync://ftp.join.uni-muenster.de/mandrakelinux/official/2010.1/x86_64/media/contrib/updates/
/repos/x86_64/media/contrib/updates/
echo "-------------------------------------------"
echo "Contrib Backports:"
rsync --delete -avz rsync://ftp.join.uni-muenster.de/mandrakelinux/official/2010.1/x86_64/media/contrib/backports/
/repos/x86_64/media/contrib/backports/
echo "-------------------------------------------"
echo "Contrib Testing:"
rsync --delete -avz rsync://ftp.join.uni-muenster.de/mandrakelinux/official/2010.1/x86_64/media/contrib/testing/
/repos/x86_64/media/contrib/testing/
echo "-------------------------------------------"
echo "Non-Free Updates:"
rsync --delete -avz rsync://ftp.join.uni-muenster.de/mandrakelinux/official/2010.1/x86_64/media/non-free/updates/
/repos/x86_64/media/non-free/updates/
echo "-------------------------------------------"
echo "Non-Free Backports:"
rsync --delete -avz rsync://ftp.join.uni-muenster.de/mandrakelinux/official/2010.1/x86_64/media/non-free/backports/
/repos/x86_64/media/non-free/backports/
echo "-------------------------------------------"
echo "Non-Free Testing:"
rsync --delete -avz rsync://ftp.join.uni-muenster.de/mandrakelinux/official/2010.1/x86_64/media/non-free/testing/
/repos/x86_64/media/non-free/testing/
echo "-------------------------------------------"
chown -R apache:apache /repos/x86_64
chown -R apache:apache /repos/i586

Vale, es largo de narices, pero detallado. Así podremos ver los resultados de la ejecución con detalle y detectar errores. Fijaos en las dos últimas instrucciones, para restaurar el propietario de los directorios a apache.

Bueno, éste archivo lo podemos llamar "updaterepos.sh" por ejemplo, y guardarlo donde queramos. Por ejemplo en /root o en /sbin (obviamente, si trabajamos como root). Acordaos de darle permisos de ejecución.

Luego, nos vamos a /etc/cron.daily y creamos otro script, más pequeño que podemos llamar, por ejemplo callupdate:

#! /bin/bash
/sbin/updaterepos.sh >> /var/log/updaterepos.log 2>&1

En definitiva, llamamos al script grande (que en éste ejemplo está localizado en /sbin) y redirigimos la salida al archivo /var/log/updaterepos.log, para posteriores consultas.

No es por nada, pero en un par de sincronizaciones, el fichero de log alcanzará un tamaño importante. Lo solucionaremos creando una política de rotado de logs. Para ello, nos acercamos a /etc/logrotate.d y creamos un archivo llamado updaterepos con éste contenido:

/var/log/updaterepos.log {
size=10M
rotate 5
weekly
missingok
notifempty
compress
endscript
}

Nuestro log será rotado cuando alcance un tamaño de 10 megas, siendo comprobado semanalmente. Conservaremos hasta 5 copias (comprimidas).

Ea, a partir de éste momento, cada día se ejecutará el script callupdate y escribirá los resultados en /var/log/updaterepos.log.

Configuración de los clientes:

Ya tenemos un mirror sincronizado y funcional.

Llegados a éste punto, sólo hay que configurar el juego de repositorios de las máquinas cliente se conecten a nuestro servidor para hacer sus operaciones de actualización o instalación de paquetes.

Como yo tengo definido un dominio en el servidor web, me veo obligado a modificar el /etc/hosts de cada máquina cliente para que dicho dominio apunte a la ip en LAN del servidor. Estaos atentos a éso, que igual por eso cuando probeis no funcione.

Bueno, configurando los repositorios de una máquina cliente. Eliminamos los antiguos: 

[root@bestiaparda ~]# urpmi.removemedia -a
quitando el soporte «Main»
quitando el soporte «Main Updates»
quitando el soporte «Main32»
quitando el soporte «Main32 Updates»
quitando el soporte «Main Testing»
quitando el soporte «Main Backports»
quitando el soporte «Main debug»
quitando el soporte «Main Updates debug»
quitando el soporte «Main Testing debug»
quitando el soporte «Main Backports debug»
quitando el soporte «Contrib»
quitando el soporte «Contrib Updates»
quitando el soporte «Contrib Testing»
quitando el soporte «Contrib Backports»
quitando el soporte «Contrib debug»
quitando el soporte «Contrib Updates debug»
quitando el soporte «Contrib Testing debug»
quitando el soporte «Contrib Backports debug»
quitando el soporte «Non-free»
quitando el soporte «Non-free Updates»
quitando el soporte «Non-free Testing»
quitando el soporte «Non-free Backports»
quitando el soporte «debug_non-free_release»
quitando el soporte «debug_non-free_updates»
quitando el soporte «debug_non-free_testing»
quitando el soporte «debug_non-free_backports»

Y añadimos los de nuestro repositorio en LAN:

[root@bestiaparda ~]# urpmi.addmedia --distrib http://midominiofalso.nolobusques.net/repos/x86_64
añadiendo soporte «Main»
añadiendo soporte «Main Updates»
añadiendo soporte «Main32»
añadiendo soporte «Main32 Updates»
añadiendo soporte «Main Testing» (ignorado por defecto)
añadiendo soporte «Main Backports» (ignorado por defecto)
añadiendo soporte «Main debug» (ignorado por defecto)
añadiendo soporte «Main Updates debug» (ignorado por defecto)
añadiendo soporte «Main Testing debug» (ignorado por defecto)
añadiendo soporte «Main Backports debug» (ignorado por defecto)
añadiendo soporte «Contrib»
añadiendo soporte «Contrib Updates»
añadiendo soporte «Contrib Testing» (ignorado por defecto)
añadiendo soporte «Contrib Backports» (ignorado por defecto)
añadiendo soporte «Contrib debug» (ignorado por defecto)
añadiendo soporte «Contrib Updates debug» (ignorado por defecto)
añadiendo soporte «Contrib Testing debug» (ignorado por defecto)
añadiendo soporte «Contrib Backports debug» (ignorado por defecto)
añadiendo soporte «Non-free»
añadiendo soporte «Non-free Updates»
añadiendo soporte «Non-free Testing» (ignorado por defecto)
añadiendo soporte «Non-free Backports» (ignorado por defecto)
añadiendo soporte «debug_non-free_release» (ignorado por defecto)
añadiendo soporte «debug_non-free_updates» (ignorado por defecto)
añadiendo soporte «debug_non-free_testing» (ignorado por defecto)
añadiendo soporte «debug_non-free_backports» (ignorado por defecto)
    http://midominiofalso.nolobusques.net/repos/x86_64/media/main/release/media_info/20100713-095003-syn...
    http://midominiofalso.nolobusques.net/repos/x86_64/media/main/updates/media_info/20100812-161356-syn...
    http://midominiofalso.nolobusques.net/repos/i586/media/main/release/media_info/20100713-095103-synth...
    http://midominiofalso.nolobusques.net/repos/i586/media/main/updates/media_info/20100812-161352-synth...
    http://midominiofalso.nolobusques.net/repos/x86_64/media/contrib/release/media_info/20100713-095321-...
    http://midominiofalso.nolobusques.net/repos/x86_64/media/contrib/updates/media_info/20100813-102533-...
    http://midominiofalso.nolobusques.net/repos/x86_64/media/non-free/release/media_info/20100713-095404...
    http://midominiofalso.nolobusques.net/repos/x86_64/media/non-free/updates/media_info/20100813-142511...
[root@bestiaparda ~]# 

Listos. Probad a actualizar (o instalar algo pesado) y comprobareis la velocidad absurda que llega a alcanzar la operación. A la cuarta o quinta actualización grande, ya habremos amortizado el tiempo. El espacio en disco, es otra cosa...