He descubierto un par de paquetes Debian que nos permiten saber si alguien está intentando conectar de forma remota con nuestra máquina: libpam-dbus y pam-dbus-notify. El primero, como se puede deducir por el nombre, es un módulo PAM que permite utilizar D-Bus para comunicarse con otros procesos. En este caso, se comunicará con el demonio de notificación y, si hemos instalado el segundo paquete, mostrará un aviso por pantalla indicando que alguien está intentando conectar con nuestro equipo, preguntando si queremos permitir o no dicho acceso.

Para que lo anterior funcione no tenemos más que instalar ambos paquetes:

# apt-get install libpam-dbus pam-dbus-notify

Tras instalar los paquetes y sus dependencias, solo tendremos que configurar los servicios que queramos que utilicen este módulo PAM. Lo más habitual será que queramos monitorizar los acceso mediante SSH a nuestra máquina, por lo que bastará modificar el archivo /etc/pam.d/sshd y añadir la siguiente línea:

# Standard Un*x authentication.
@include common-auth
auth required pam_dbus.so

Reiniciamos el servicio ssh:

# /etc/init.d/ssh restart

y solo falta reiniciar la sesión gráfica (supongo que bastaría con reiniciar el demonio de notificación) para que a partir de ahora, cuando alguien intente conectar con nuestra máquina, aparezca lo siguiente:

Notificación de intento de conexión mediante ssh

Ahora podemos permitir o denegar el acceso sin más que pulsar en el botón adecuado o si pasa el tiempo sin que pulsemos en ninguna opción se denegará el acceso.

En el trabajo tengo una cuenta de correo de administración a la que llegan correos desde cientos de servidores: mensajes de tareas ejecutadas correctamente, warnings o incluso errores al ejecutar alguna tarea de cron. Son correos generados por diferentes aplicaciones, y llegan a una única cuenta, ya que muchas de esas tareas se ejecutan como dependientes del usuario root.
Afortunadamente, gracias al servidor de correo Postfix, podemos filtrar esos mensajes para enviarlo a distintos destinatarios dependiendo del contenido de los mismos, y así repartir las tareas de administración entre varias personas.

Postfix incluye un módulo de filtrado de correos, que nos permite filtrar tanto por el contenido de las cabeceras como del cuerpo de los mensajes. Para hacer uso de uno u otro, tenemos que emplear las directivas header_checks o body_checks respectivamente. En mi caso, estoy interesado en filtrar los correos dependiendo del campo Asunto de los correos electrónicos que llegan a la cuenta de administración, por lo que usaré la directiva de configuración header_checks. Por tanto, debemos incluir una línea como la siguiente en el archivo /etc/postfix/main.cf:

header_checks = pcre:/etc/postfix/header_checks.pcre

Con esta línea estamos indicando que compruebe las cabeceras de los correos entrantes, comparándolas con expresiones regulares PCRE que están escritas en el archivo /etc/postfix/header_checks.pcre. Para que funcione este módulo, debemos haber compilado Postfix con el soporte correspondiente, o si usáis Debian como yo, instalar el paquete postfix-pcre.

El siguiente paso es crear este archivo /etc/postfix/header_checks.pcre, que en mi caso tiene el siguiente contenido:

/^Subject:.*cfengine-cron.sh$/
   REDIRECT cfengine@midominio.es

Con esto consigo que todos los mensajes que incluyan en el campo Subject (Asunto) de la cabecera el nombre de script cfengine-cron.sh sean reenviados a la cuenta cfengine@midominio.es en vez de la cuenta de administración general. No solo puede realizarse la redirección a una cuenta de correo, sino que permite otras acciones que se pueden consultar en la página de documentación de header_checks.

El último paso será reiniciar el servicio Postfix, y así, la persona encargada de administrar cfengine podrá configurar una cuenta de correo donde recibirá todas las incidencias que ocurran con la aplicación, y liberará la cuenta de administración general de ese correo.

Xen proporciona una mecanismo de migración de máquinas virtuales en caliente, pero para ello necesitamos algún medio de almacenamiento compartido (SAN, iSCSI, etc) para que funcione. Veremos que es posible migrar máquinas virtuales entre servidores Xen sin almacenamiento compartido, eso sí, en frío y tardando un poco más que la migración en caliente.

Como requisito claro está, es tener un par de servidores ya funcionando como dom0 en Xen, y memoria y espacio de almacenamiento suficiente en el servidor de destino para ejecutar la máquina virtual que vamos a migrar. En mi caso se trata de dos servidores corriendo bajo Debian Etch en arquitectura x86-64, con máquinas virtuales usando volúmenes LVM, y que llamaremos xen1 y xen2 para simplificar.

El primer paso es crear en el servidor de destino los volúmenes lógicos necesarios con el mismo tamaño que en el servidor origen. Para ello miramos el número de logical extends que emplea cada partición en el servidor original. Así, suponiendo que queremos migrar una máquina virtual llamada vm1, que usa dos volúmenes lógicos vm1-disk y vm1-swwap, usaremos el siguiente comando:

xen1:~# lvdisplay -c vg00/vm1-disk vg00/vm1-swap
/dev/vg00/vm1-disk:vg00:3:1:-1:0:8388608:1024:-1:0:0:254:10
/dev/vg00/vm1-swap:vg00:3:1:-1:0:2097152:256:-1:0:0:254:11

El valor que estamos buscando es el sexto empezando por el final, es decir, 1024 para la partición vm1-disk y 256 para la partición vm1-swap. Con estos valores, ejecutamos los siguientes comandos en el servidor de destino:

xen2:~# lvcreate -l 1024 -n vm1-disk vg00
Logical volume "vm1-disk" created
xen2:~# lvcreate -l 256 -n vm1-swap vg00
Logical volume "vm1-swap" created

El siguiente paso es preparar el área de swap que acabamos de crear en el servidor de destino:

xen2:~# mkswap /dev/vg00/vm1-swap

El paso que nos llevará más tiempo es la transferencia de la máquina virtual del servidor origen al de destino. Este tiempo dependerá del tamaño de la partición (o particiones) que tengamos que transferir. Para realizar la transferencia, usaremos la herramienta netcat. En primer lugar preparamos el servidor de destino:

xen2:~# netcat -l -p 12345 > /dev/vg00/vm1-disk

Con esto, estamos abriendo un puerto de escucha, el 12345, en el servidor de destino, y le decimos que todo lo que reciba por ese puerto lo escriba en el volumen lógico /dev/vg00/vm1-disk. Hemos de tener cuidado ya que cualquiera podría conectarse con ese puerto y mandarnos basura a la partición. Ahora toca la parte en el servidor origen:

xen1:~# dd if=/dev/vg00/vm1-disk | netcat xen2 12345

Ahora estamos diciendo que el servidor origen lea la partición /dev/vg00/vm1-disk y la envíe mediante el comando netcat al servidor xen2 (el servidor de destino) que está escuchando en el puerto 12345. Este comando debemos ejecutarlo con la máquina virtual completamente parada (no suspendida, si no tendríamos que transferir también el archivo que se crea con el estado de la máquina virtual cuando se suspende, aunque esto no lo he probado). Cuando termine la transferencia (dd muestra las estadísticas de lectura y escritura), pulsamos Ctrl+C para terminar netcat. Automáticamente se cierra la conexión en destino.

El último paso es transferir el archivo de configuración de la máquina virtual, normalmente /etc/xen/vm1.cfg, y arrancar la máquina virtual en el servidor remoto comprobando que todo ha funcionado perfectamente.

Es normal que si tenemos una máquina accesible desde Internet, de vez en cuando nos encontremos con cosas como esta en el archivo /var/log/auth.log:

Feb 13 03:59:54 server sshd[26021]: Invalid user staff from 47.43.278.456
Feb 13 03:59:56 server sshd[26027]: Invalid user sales from 47.43.278.456
Feb 13 03:59:58 server sshd[26033]: Invalid user recruit from 47.43.278.456
Feb 13 04:00:00 server sshd[26040]: Invalid user alias from 47.43.278.456
Feb 13 04:00:02 server sshd[26046]: Invalid user office from 47.43.278.456
Feb 13 04:00:04 server sshd[26054]: Invalid user samba from 47.43.278.456
Feb 13 04:00:06 server sshd[26060]: Invalid user tomcat from 47.43.278.456
Feb 13 04:00:08 server sshd[26066]: Invalid user webadmin from 47.43.278.456
Feb 13 04:00:10 server sshd[26073]: Invalid user spam from 47.43.278.456
.....
Feb 13 04:05:18 server sshd[27076]: Invalid user mailnull from 47.43.278.456
Feb 13 04:05:20 server sshd[27083]: Invalid user nfsnobody from 47.43.278.456
Feb 13 04:05:22 server sshd[27089]: Invalid user rpcuser from 47.43.278.456
Feb 13 04:05:24 server sshd[27096]: Invalid user rpc from 47.43.278.456
Feb 13 04:05:26 server sshd[27102]: Invalid user gopher from 47.43.278.456

En este ejemplo he cambiado la dirección IP del atacante, Sí, digo atacante, porque en casi 6 minutos ha efectuado 135 intentos de conexión a nuestra máquina, utilizando algunos nombres de usuarios y contraseñas por defecto, o algún que otro ataque mediante diccionario. Para evitar que consiga su objetivo, aquí os dejo algunos consejos:

Cuidado con los usuarios de prueba
Quién no ha creado alguna vez un usuario prueba con contraseña prueba (o test/test) para realizar alguna que otra prueba en nuestro sistema y después se nos ha olvidado borrarlo al finalizar. Pues juntemos esto con algún exploit local del kernel (como el que hemos sufrido hace poco con el fallo del vmsplice) y podemos ofrecer fácilmente un acceso como root a cualquier atacante.

Deshabilitar el acceso como usuario root
No deberíamos utilizar nunca la cuenta de root, salvo para realizar tareas de mantenimiento. Por tanto, siempre nos conectaremos como usuario sin privilegios, y posteriormente y solo cuando sea necesario ejecutaremos comandos como superusuario, bien con sudo, bien convirtiéndonos previamente en él mediante el comando

su -

Para evitar el acceso SSH como usuario root, debemos comprobar que en el archivo /etc/ssh/sshd_config tenemos una línea como esta:

PermitRootLogin no

Si tenemos que añadir o cambiar esta línea, no debemos olvidar reiniciar el demonio ssh para que los cambios tengan efecto

# /etc/iinit.d/ssh restart

Deshabilitar el acceso mediante contraseña
Una forma sencilla de proteger nuestra máquina personal frente a este tipo de ataques es prohibir el acceso mediante contraseña, y emplear solo un mecanismo de clave pública/privada. De este modo, solo aquellos que tengan la clave privada podrán entrar en nuestra máquina.

Para generar el par de claves, no tenemos más que ejecutar el comando:

$ ssh-keygen -t tipo -b bits

donde

• tipo es el tipo de clave que emplearemos (RSA o DSA).
• bits es el número de bits que tendrá nuestra clave. El número de bits permitidos dependerá del tipo de clave que elijamos.

También nos pedirá que protejamos la clave privada mediante una contraseña, de modo que aunque alguien la consiga, no pueda llegar a utilizarla sin conocer la frase de paso.

Solo nos queda copiar nuestra clave pública al servidor remoto al que queramos conectar. Para ello basta con ejecutar:

ssh-copy-id -i <clave_publica> <maquina_remota>

Nos pedirá la contraseña para conectar con la maquina_remota y copiará la clave pública en el archivo .ssh/authorized_keys del home del usuario.

Tras esto, comprobaremos que podemos conectar con la máquina remota sin teclear la contraseña de usuario. Os recomiendo usar algún gestor de claves, como Seahorse en Gnome, para no tener que teclear la frase de paso cada vez que queramos conectar con el servidor remoto.

El último paso, una vez hemos comprobado que podemos conectar mediante el mecanismo de clave pública y privada, es prohibir el acceso al servidor mediante contraseña. Para ello debemos comprobar que en el archivo /etc/ssh/sshd_config tenemos una línea como esta:

PasswordAuthentication no

De nuevo, si hemos tenido que modificar el archivo de configuración, deberemos reiniciar el servicio ssh.

A veces puede ser necesario disponer de una máquina Windows para realizar pruebas, como por ejemplo probar algún desarrollo web en distintos entornos, o porque nos es imprescindible ya que tenemos que usar algún software que no dispone de equivalente en GNU/Linux (como algún software propietario de gestión de algunas centralitas que cuestan varios miles de Euros). En este artículo veremos que instalar Windows en una máquina virtual en Xen no es nada complicado.

Configuración del servidor dom0
Lo primero que tenemos que tener es una máquina con el hipervisor Xen ya ejecutándose. No entraré en detalles sobre cómo hacerlo, porque existen varios tutoriales en Internet que lo explican. Una cosa que sí deberemos tener en cuenta es que el procesador de esa máquina debe disponer de tecnología de virtualización (Intel VT o AMD Pacífica). Podemos comprobarlo ejecutando:

# xm info | grep xen_caps
xen_caps : xen-3.0-x86_64 hvm-3.0-x86_32 hvm-3.0-x86_32p hvm-3.0-x86_64


Si como en este caso, os salen opciones que empiezan por hvm significará que sí disponéis de este soporte. Si por el contrario obtenéis la siguiente salida:

# xm info | grep xen_caps
xen_caps : xen-3.0-x86_64


lo siento, pero no podréis instalar Windows bajo Xen, al menos en esta máquina.

Una vez hemos comprobado que nuestro procesador cumple los requisitos, instalaremos algunos programas extra para poder aprovecharlo. En el caso de Debian, esto es tan sencillo como ejecutar:

# apt-get install xen-ioemu-3.0.3-1

Configuración de la VM domU
Ahora que nuestro servidor dispone de todo lo necesario, procederemos a la instalación de la máquina virtual propiamente dicha. En primer lugar deberemos disponer de una imagen del CD-ROM de instalación de Windows (no he probado todavía a instalar directamente desde la unidad) con su correspondiente licencia de uso. Para crearla bastará con ejecutar:

# dd if=/dev/cdrom of=windows.iso

El siguiente paso será crear la partición necesaria para instalar el sistema. Como utilizo LVM en esa máquina, crear la partición es tan fácil como ejecutar el siguiente comando:

# lvcreate -L 8G -n windows-disk vg00

con lo que habré creado un volumen lógico llamado windows-disk de 8 Gb en el grupo de volúmenes vg00.

Por último, queda definir el archivo de configuración de la máquina virtual. En mi caso es el archivo /etc/xen/windows.cfg y éste es su contenido:

#
# Configuration file for the Xen instance windows, created on
# Tue Feb 12 13:15:39 2008.
#
#
# Kernel + memory size
#
kernel = '/usr/lib/xen-default/boot/hvmloader'
builder = 'hvm'
memory = '512'
#
# Disk device(s).
#
disk = [ 'phy:/dev/vg00/windows-disk,ioemu:hda,w', 'file:/root/windows.iso,hdc:cdrom,r' ]
#
# Hostname
#
name = 'windows'
#
# Networking
#
dhcp = 'dhcp'
vif = [ 'type=ioemu, mac=00:16:3e:74:74:a5' ]
#
# Behaviour
#
on_poweroff = 'destroy'
on_reboot = 'restart'
on_crash = 'restart'
# New stuff
device_model = 'qemu-dm'
boot = 'd'
ne2000 = 1
acpi = 1
sdl = 0
vnc = 1
vncviewer = 0
nographic = 0


Resumiendo, se define la memoria y los discos que se usarán, nombre que le damos al domU, la definición de red, qué hacer cuando se apague o reinicie, y por último algunos parámetros necesarios, como que arranque desde la unidad d, el tipo de emulación de tarjeta de red, que active ACPI, y que permitamos la conexión mediante VNC al domU. De este modo, cuando arranquemos el domU, podremos conectarnos mediante VNC para completar la instalación.

Una cosa a tener en cuenta al respecto, es permitir las conexiones VNC desde otras máquinas que no sean localhost. Para ello deberemos editar el archivo /etc/xen/xend-config.sxp y cambiar la línea

(vnc-listen '127.0.0.1')

por

(vnc-listen '0.0.0.0')

Para que el cambio tenga efecto, deberemos reiniciar el hipervisor:

# /etc/init.d/xend restart

Debemos tener cuidado al habilitar el acceso VNC ya que no está protegido por contraseña, y cualquiera con acceso al servidor podría conectar.

Instalación del S.O.
El primer paso será arrancar la nueva máquina virtual:

# xm create windows.cfg

Ya desde nuestra máquina de trabajo, podremos conectarnos mediante VNC al servidor domU y continuar con la instalación de Windows. Por ejemplo, si nuestro servidor se llama xensrv y tenemos la aplicación vncviewer, podremos conectar mediante el comando siguiente:

vncviewer xensrv

A partir de aquí se continúa con el proceso normal de instalación de Windows como si lo estuviéramos instalando en nuestra máquina local. Una vez finalizada la instalación, podremos seguir conectando mediante VNC y habilitar la conexión remota mediante RDP y asegurarnos de que el usuario que vayamos a utilizar dispone de permisos para conectar remotamente.

Consideraciones finales
Una vez que ya tengamos activada la conexión remota mediante RDP, podemos cambiar las líneas del archivo de configuración:

vnc = 1
nographic = 0


por:

vnc = 0
nographic = 1


y volver a prohibir las conexiones VNC remotas, revertiendo el cambio en el archivo /etc/xen/xend-config.sxp y volviendo a reiniciar el hipervisor.

En el trabajo tenemos un servidor ftp corriendo como máquina virtual Xen. Aunque tiene varios gigas de espacio en disco, siempre termina haciendo falta más. En esta entrada explicaré paso a paso como añadir un nuevo disco “virtual” al servidor ftp, sin necesidad de “apagar” la máquina virtual.

1. Crear el nuevo disco/partición en el dom0
   En mi caso, el dom0 tiene 2 discos duros SATA de 250 Gb formando un único grupo de volúmenes LVM. Este grupo de volúmenes aún tiene libres 167,89 Gb, por lo que podremos emplear este espacio para crear un nuevo volumen lógico. Suponiendo que el grupo de volúmenes se llama vg00, lo único que debemos hacer es lo siguiente:

   xen:~# lvcreate -L 100G -n ftp-ubuntu vg00
Logical volume "ftp-ubuntu" created

   Así habremos creado un volumen lógico llamado ftp-ubuntu de 100 Gb en el grupo de volúmenes vg00. Lo he llamado ftp-ubuntu porque se usará en la máquina virtual llamada ftp, y porque albergará un mirror de ubuntu. Así será más fácil identificar luego a qué máquina virtual pertenece cada volumen lógico.

2. Crear el sistema de archivos en el nuevo volumen lógico
   Este paso es muy sencillo. Tan solo debemos ejecutar el siguiente comando:

   xen:~# mkfs.ext3 -m0 /dev/vg00/ftp-ubuntu

   Así crearemos un sistema de archivos ext3 en el nuevo volumen lógico, y reservando un 0% de expacio para root.

3. Conectar el nuevo volumen lógico al domU
   Ahora es cuando conectaremos en caliente el nuevo disco a la máquina virtual. Para ello debemos ejecutar el siguiente comando:

   xen:~# xm block-attach ftp phy:vg00/ftp-ubuntu /dev/sdb3 w

   Con ello habremos conectado el volumen lógico vg00/ftp-ubuntu al domU ftp, en el que aparecerá como /dev/sdb3, y con acceso de lectura y escritura (w).

4. Configurar el nuevo dispositivo en el domU
   Una vez conectados al domU (bien mediante ssh o mediante xm console), tendremos que crear el dispositivo de bloques para poder acceder a él:

   ftp:~# mknod /dev/sdb3 b 8 19
ftp:~# chmod 0660 /dev/sdb3

   Tendremos que editar el archivo /etc/fstab para que se monte automáticamente en cada arranque y montar el nuevo dispositivo para poder empezar a usarlo.

5. Configurar el domU para que se asigne el volumen lógico en cada arranque
   Por último solo nos quedará editar el archivo de configuración del domU (/etc/xen/ftp.cfg en mi caso) para que el volumen lógico se monte en cada arranque de la máquina virtual. Bastará con que busquemos la variable disk y añadamos el dispositivo. En mi caso, la línea queda como sigue:

   disk = [ 'phy:vg00/ftp-disk,sda1,w', 'phy:vg00/ftp-swap,sda2,w', 'phy:vg00/ftp-home,sdb1,w', 'phy:vg00/ftp-breezy,sdb2,w', 'phy:vg00/ftp-ubuntu,sdb3,w' ]

   Como podéis comprobar, el domU ftp tiene cinco volúmenes lógicos asignados: uno para el sistema raíz, montado como sda1; otro para swap, montado como sda2; otro para la partición /home, montado como sdb1; otro que alberga un mirror de breezy, montado como sdb2; y el nuevo volumen lógico que hemos creado, que se montará como sdb3.

Y listo. Hemos conseguido disponer de más espacio en el servidor ftp sin tener que parar el servicio en absoluto. Y además, gracias a LVM, podremos seguir expandiendo el espacio en el futuro sin necesidad de interrumpir el servicio. Espero que os sirva de ayuda.

Hace algunos meses escribí un post donde relataba mis relaciones con el soporte que HP daba a la distribución Debian en su gama de servidores ProLiant. La impresión que me dejó dicho “soporte” (por llamarlo de alguna manera) no era del todo positiva, y esperaba que con la liberación de la nueva versión de Debian GNU/Linux 4.0 (etch) las cosas cambiaran.

Pues bien, vía Planet Debian me entero en este post que HP ha actualizado el soporte para Debian en su gama de servidores ProLiant y BladeSystems, añadiendo como distribución soportada Debian GNU/Linux 4.0.

Espero que al menos hayan solucionado algunos de los problemas que mencionaba en el anterior post (por lo que parece, al menos sí han añadido la herramienta gráfica de configuración para las controladoras Smart Array) y que se hayan currado un poco más los paquetes Debian. Yo de momento tendré que esperar al menos al próximo lunes para poder echarle un ojo más a fondo, y probarlo en los servidores del trabajo. Si alguien se me quiere adelantar, desde esta página podéis acceder al área de descarga de las distintas herramientas (previo proceso de registro gratuito) e ir probando a ver qué tal va la cosa. Esperemos que un poco mejor.

Un mes más sin postear nada, pero creo que la espera merecerá la pena. En mi dosis diaria de “monitorización” de incoming.debian.org, que para quien no lo sepa, es donde se suben los paquetes Debian antes de ser subidos a los repositorios oficiales, me encontré con una subida bastante extraña: el paquete flashplugin-nonfree subido para… arquitectura AMD64!!!!

“Imposible”. “No puede ser”. “No he visto ninguna noticia de que ya hayan hecho el port”. Total, que animado por tan grato descubrimiento, abro una nueva terminal, su - para convertirme en root y manos a la obra:

# apt-get update
# apt-get install flashplugin-nonfree
Leyendo lista de paquetes... Hecho
Creando árbol de dependencias
Reading state information... Hecho
Se instalarán los siguientes paquetes extras:
ia32-libs ia32-libs-gtk lib32asound2 lib32gcc1 lib32ncurses5 lib32stdc++6
lib32z1 libc6-i386 linux32 nspluginwrapper
Paquetes sugeridos:
konqueror-nsplugins msttcorefonts ttf-xfree86-nonfree xfs libasound2-plugins
Se instalarán los siguientes paquetes NUEVOS:
flashplugin-nonfree ia32-libs ia32-libs-gtk lib32asound2 lib32gcc1
lib32ncurses5 lib32stdc++6 lib32z1 libc6-i386 linux32 nspluginwrapper
0 actualizados, 11 se instalarán, 0 para eliminar y 5 no actualizados.
Se necesita descargar 31,7MB/32,0MB de archivos.
Se utilizarán 85,2MB de espacio de disco adicional después de desempaquetar.
¿Desea continuar [S/n]?

Por supuesto que sí. Así que pulso Enter y mientras se descargan los paquetes puedo ver que en realidad se trata de la versión de 32 bits que se ejecutará con nspluginwrapper Bueno a ver si funciona…

Pues sí… y no. Funciona casi todo perfectamente y por fin puedo ver vídeos de youtube en mi Debian AMD64. No todos (no sé por qué) pero bastantes sí. Y funcionan la mayoría de animaciones Flash que tan de moda se han puesto en páginas web para menús y demás. Una cosa más a tachar de la lista de cosas que no puedo hacer en mi ordenador de sobremesa.

Esta era la más importante, después de que ya hace meses incluyeran soporte para arquitectura AMD64 de OpenOffice.org. Ya solo queda que por fin me funcione el plugin de Java para Firef… perdón, Iceweasel . Pero esa, es otra historia.

Guau!!! Cómo pasa el tiempo… dos meses sin escribir nada… esto no puede seguir así. La verdad es que he estado bastante ocupado con el trabajo, algunos cursos y mi vida personal. Pero tengo en preparación varios artículos/howtos sobre lo que he estado montando en el trabajo. Sobre todo algunas cosillas con máquinas virtuales en Xen, LVM, instalación de servicios… Espero que la espera merezca la pena. En breve, más.

Esta semana ha salido por fin la nueva versión estable de Debian GNU/Linux, la versión 4.0 y más conocida como Etch. Si tenemos varias máquinas o servidores, mantenerlas actualizadas puede suponer un gran gasto de ancho de banda, ya que tendremos que bajar varias veces los paquetes de actualización.

Para ahorrar ancho de banda podemos utilizar varias herramientas que nos permitirán crear un mirror local Debian y así descargar solo una vez los paquetes necesarios.

1. Configuración en el servidor

Utilizaremos una máquina con suficiente espacio en disco para crear el mirror local. Para ello, podemos utilizar el paquete debmirror para realizar la copia local del repositorio Debian. Para instalarlo bastará con ejecutar el siguiente comando:

# apt-get install debmirror

Una vez instalado, buscaremos una partición con suficiente espacio en disco, ya que esta herramienta creará un repositorio completo de las distribuciones que le indiquemos. Así por ejemplo, supongamos que tenemos una partición en la que creamos un directorio mirror. Dentro de él crearemos nuestro repositorio local de paquetes Debian ejecutando el siguiente comando (no es necesario ejecutarlo como root, tan solo tener permisos de escritura en el directorio donde vayamos a crear el repositorio):

$ debmirror --debug --method=http --dist=etch,sid --nosource --arch=i386 --host=ftp.debian.org --ignore-release-gpg debian

El comando anterior creará el repositorio local dentro del directorio debian, a partir del mirror oficial ftp.debian.org, para la arquitectura i386, sin descargar los fuentes, usando método http, para las ramas etch (estable) y sid (inestable) de Debian. Podemos obtener más ayuda de las opciones en las páginas del manual (man debmirror).

También es recomendable crear un repositorio local de los paquetes de seguridad para la distribución estable. El siguiente comando se encargará de generar este repositorio:

$ debmirror --debug --method=http --dist=etch/updates --nosource --arch=i386 --host=security.debian.org -r=/ --section=main,contrib,non-free debian-security/

El último paso será hacer accesible el repositorio para otros clientes. En la mayoría de los casos será necesario tener instalado un servidor web (como Apache), un servidor FTP (como ProFTPd) o mejor ambos. Por ejemplo, podemos crear unos enlaces desde el directorio /var/www a cada uno de los directorios creados anteriormente (debian y debian-security), con lo que los repositorios quedarán accesibles mediante protocolo HTTP:

mirror:/var/www# ls -l debian*
lrwxrwxrwx 1 root root 27 Sep 7 08:07 debian -> /home/ftp/pub/mirror/debian
lrwxrwxrwx 1 root root 37 Sep 7 08:07 debian-security -> /home/ftp/pub/mirror/debian-security/

2. Configuración en los clientes

La configuración que hay que hacer en los clientes se limita a modificar el archivo /etc/apt/sources.list para que accedan al nuevo repositorio. Así, suponiendo que nuestro servidor es accesible a través de la dirección mirror.ejemplo.com, bastará con que el archivo sources.list contenga las siguientes líneas:

deb http://mirror.ejemplo.com/debian etch main contrib non-free
deb http://mirror.ejemplo.com/debian-security etch/updates main contrib non-free

Si en vez de tener la rama estable (Etch) utilizamos la rama inestable (Sid), la lí­nea que deberá incluir el archivo será la siguiente:

deb http://mirror.ejemplo.com/debian sid main contrib non-free

]]> http://ortegaga.wordpress.com/2007/04/13/crear-un-repositorio-local-de-paquetes-debian/feed/ 4 ortegaga