Mi /etc/hosts tiene vida propia !!!

Suelo pecar de olvidar cosas como hacer algún recado, fechas importantes (cumpleaños, aniversarios, etc). En cambio, para recordar claves, ip’s, usuarios y demás tengo más facilidad. Deformación profesional es lo que me dicen en casa.
Por eso, cuando me percaté que desaparecían entradas de mi /etc/hosts dudé de si las había incluído o no.
Las incluí de nuevo, “lo habré pensado pero no lo hice”, pensé. Y el día transcurre normalmente.
Al día siguiente, cuando intento acceder de nuevo a una de las máquinas que incluí en mi fichero:
ssh: Could not resolve hostname bdp3b: Name or service not known
“Upps, pero ésto no lo incluí ya ayer?” – La vuelvo a incluir. Así pasan un par de días y me empiezo a mosquear y empiezo a despotricar y a acordarme de la madre que parió a la p*** Squeeze ésta, al Linux, etc, etc.
Y me pongo a hacer pruebas:
1. Añado una entrada
2. Reinicio el portátil
3. La entrada desaparece
4. WTF??!!
Es más, añada las líneas que añada, nunca están, parece que el /etc/hosts cada vez que reinicio, vuelve a una “versión” de hace un par de semanas. De nuevo: WTF ????!!!!!!
Me pongo a mirar los servicios que arranco por defecto: la única cosa excepcional es el vpnagentd_init. Éste es el servicio que utiliza el AnyConnect para funcionar. Pero será posible que me esté fundiendo el /etc/hosts y dejándolo tal cual estaba cuando se instaló cada vez que se arranca? Bueno, pues lo quité del arranque, añadí unas entradas nuevas y reinicié de nuevo.
Y voilá, las entradas nuevas siguen ahí.
Arranco de forma manual el servicio y se vuelven a ir !!!! Qué cabrón !!! Ahora despotrico de Cisco xDDD

PD: He modificado el script de arranque del servicio para que antes de arrancar, haga una copia del /etc/hosts y al terminar, vuelva a dejarlo como estaba.

Anuncios

DRBD + Heartbeat = DNS en alta disponibilidad

El cliente donde estoy destinado quiere sacar el DNS del AD donde ahora está y pasarlo a Linux. En paso debe ser transparente y debe ser implementado con alguna herramienta para disponer de HA para dar servicio.

Con éstas premisas lo primero que pensé fue en instalar 2 RHEL, las herramientas de clustering e implementar el recurso del DNS en él, pero no todo es tan sencillo. Para empezar, RHEL, la licencia básica que tiene el cliente, no permite la instalación de los paquetes de clustering. De hecho, es una licencia a parte que se puede adquirir una vez tengas la básica. Total, que no era una opción.

Así que, como tampoco nos iba a hacer falta todo lo que lleva detrás la suite de clustering, opté por implementar el HA con Heartbeat y como tampoco vamos a disponer de un almacenamiento compartido para la info del DNS, eché mano de DRBD. Todo ésto implementado en Debian.

Partimos de la instalación básica de la última versión de Debian con los paquetes necesarios para toda la funcionalidad que le queremos dar.  Un detalle importante, es que al particionar los discos debemos hacerlo con LVM ya que lo que va a estar sincronizado con DRBD es un volúmen lógico.

La instación en Debian como siempre:

apt-get install heartbeat drbd8-utils

También deberemos instalar el servidor DNS en ambos nodos.

apt-get install bind9

Tras la instalación tendremos que reducir el tamaño del filesystem que contiene /home, pues por defecto le da todo el espacio disponible después de particionar los demás filesystems del sistema. Para ello, desmontamos el filesystem, reducimos el filesystem, reducimos el lv y montamos de nuevo. Ahora ya tenemos disponible en el vg espacio para crear un nuevo lv para sincronizar con DRBD.

En uno de los nodos empaquetamos todo el contenido de /etc/bind y lo guardamos a salvo: tar cvf /root/bind.tar /etc/bind/*

En ambos nodos creamos un nuevo lv: lvcreate -L1G -n dnslv systemvg

Creamos el fichero de configuración /etc/drbd.conf con la siguiente info:

global {
usage-count no;
}

common {
#Velocidad de sincronización. Velocidad de la red dedicada.
syncer {rate 100M; }
}

resource r1 {
#Protocolo de sincronización:
#    A: La sincronización se da por terminada cuando es enviada al buffer TCP local
#    B: La sincronización se da por terminada cuando ha llegado al buffer remoto
#    C: La sincronización se da por termianda cuando ha sido escrita también en el disco espejo
protocol C;
startup {
wfc-timeout 15;       #Tiempo seg. de espera por lo recursos remotos en el arranque del servicio
degr-wfc-timeout 60;  #Tiempo seg. de espera por un recurso perdido hasta se marca como          degradado
}

#    net {
#        cram-hmac-alg sha1;    #Algoritmo CRAM para la clave
#        shared-secret “secret”; #Clave de autentificación
#allow-two-primaries;   #Solo si hay cluster filesystem encima
#    }

on cluster1 {
device /dev/drbd0;    #Dispositivo RAID DRBD
disk /dev/cluster1/dnslv;        #Dispositivo local miembro de DRBD
address 192.168.56.102:7788;    #Interfaz de comunicación
meta-disk internal;    #Integrado en “/dev/cluster1/dnslv”
}

on cluster2 {
device /dev/drbd0;
disk /dev/cluster2/dnslv;
address 192.168.56.101:7788;
meta-disk internal;
}
}

En internet se pueden entontrar varios ejemplos, lo más importante es el protocolo de sincronización y el tiempo de espera.

Éste fichero lo pasamos también al 2º nodo tal cual.

Inicializamos los meta-datos en ambos nodos, que pueden estar en un área dentro del propio disco (o partición o lv) o fuera. Por defecto, se incluye en el disco que se sincroniza.

[root@node1 etc]# drbdadm create-md r1
v08 Magic number not found
v07 Magic number not found
About to create a new drbd meta data block on /dev/cluster1/dnslv.
. ==> This might destroy existing data! <==
Do you want to proceed? [need to type ‘yes’ to confirm] yes
Creating meta data… initialising activity log NOT initialized bitmap (256 KB) New drbd meta data block sucessfully created.

Arrancarmos drbd en ambos nodos:

/etc/init.d/drbd start

Starting DRBD resources:    [ d0 n0 ]. ……

Comprobamos el estado de la sincronización:

[root@node1 etc]# cat /proc/drbd
version: 8.0.4 (api:86/proto:86) SVN Revision: 2947 build by buildsvn@c5-i386-build, 2007-07-31 19:17:18
. 0: cs:Connected st:Secondary/Secondary ds:Inconsistent/Inconsistent C r—
. ns:0 nr:0 dw:0 dr:0 al:0 bm:0 lo:0 pe:0 ua:0 ap:0
. resync: used:0/31 hits:0 misses:0 starving:0 dirty:0 changed:0 act_log: used:0/257 hits:0 misses:0 starving:0 dirty:0 changed:0

Ambos nodos están como secundarios, debemos haceer que uno sea el primario y que el otro sincronice desde el primero.

[root@node1 etc]# drbdadm — –overwrite-data-of-peer primary r1
[root@node1 etc]# watch -n 1 cat /proc/drbd  version: 8.0.4 (api:86/proto:86) SVN Revision: 2947 build by buildsvn@c5-i386-build, 2007-07-31 19:17:18
. 0: cs:SyncTarget st:Primary/Secondary ds:Inconsistent/Inconsistent C r—
. ns:0 nr:68608 dw:68608 dr:0 al:0 bm:4 lo:0 pe:0 ua:0 ap:0
. [>……………….] sync’ed:  0.9% (8124/8191)M finish: 0:12:05 speed: 11,432 (11,432) K/sec resync: used:0/31 hits:4283 misses:5 starving:0 dirty:0 changed:5 act_log: used:

Vemos que la barra de progreso va incrementándose, cuando finalice tendremos los 2 nodos sincronizados.

Aún cuando no haya terminado de sincronizar, ya tendremos disponible un nuevo dispositivo llamado /dev/drbd0 que se ha creado por encima del LV. Éste es sobre el que vamos a tranajar y el que se sincronizará periódicamente.

Así que vamos a ello:

mkfs.ext3 /dev/drbd0

mount /dev/drbd0 /etc/bind

root@cluster1:~# mount
/dev/mapper/cluster1-root on / type ext3 (rw,errors=remount-ro)
tmpfs on /lib/init/rw type tmpfs (rw,nosuid,mode=0755)
proc on /proc type proc (rw,noexec,nosuid,nodev)
sysfs on /sys type sysfs (rw,noexec,nosuid,nodev)
udev on /dev type tmpfs (rw,mode=0755)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=620)
/dev/cciss/c0d0p1 on /boot type ext2 (rw)
/dev/mapper/cluster1-home on /home type ext3 (rw)
/dev/mapper/cluster1-tmp on /tmp type ext3 (rw)
/dev/mapper/cluster1-usr on /usr type ext3 (rw)
/dev/mapper/cluster1-var on /var type ext3 (rw)
/dev/mapper/cluster1-logslv on /logs type ext3 (rw)
/dev/drbd0 on /etc/bind type ext3 (rw)

root@cluster1:~# cat /proc/drbd
version: 8.3.7 (api:88/proto:86-91)
srcversion: EE47D8BF18AC166BE219757
0: cs:Connected ro:Primary/Secondary ds:UpToDate/UpToDate C r—-
ns:224 nr:0 dw:1036 dr:7992 al:2 bm:42 lo:0 pe:0 ua:0 ap:0 ep:1 wo:b oos:0
root@cluster1:~#

Ahora lo que queremos es sea Heartbeat el que controle el montaje del FS, el servicio BIND y la IP que vamos a balancear entre los 2 nodos.

Para ésto tocaremos 3 ficheros:

root@cluster1:/etc/ha.d# cat ha.cf
logfacility local0
keepalive 1
deadtime 10
bcast eth0
auto_failback off
node cluster1 cluster2
root@cluster1:/etc/ha.d# cat haresources
cluster1 IPaddr::X.X.X.X
cluster1 drbddisk::dns Filesystem::/dev/drbd0::/etc/bind::ext3 bind9
root@cluster1:/etc/ha.d# cat authkeys
auth 3
3 md5 tu_password

Debemos replicar éstos ficheros en el nodo2 exactamente igual que los tenemos en el nodo1.

La opción de auto_failback off la preferimos porque lso 2 nodos son iguales y realmetne no importa que el recurso esté en uno o en otro por mucho tiempo.

Finalmente, quitamos del arranque el demonio bind y agregamos, si no lo está ya, heartbeat.

Como ejemplo pego el log del nodo2 al reiniciar el nodo1:

Sep 15 11:55:33 cluster2 kernel: [2503138.827620] block drbd0: peer( Primary -> Secondary )
Sep 15 11:55:33 cluster2 heartbeat: [6906]: info: Received shutdown notice from ‘cluster1’.
Sep 15 11:55:33 cluster2 heartbeat: [6906]: info: Resources being acquired from cluster1.
Sep 15 11:55:33 cluster2 heartbeat: [3298]: info: acquire local HA resources (standby).
Sep 15 11:55:33 cluster2 heartbeat: [3299]: info: No local resources [/usr/share/heartbeat/ResourceManager listkeys cluster2] to acquire.
Sep 15 11:55:33 cluster2 heartbeat: [3298]: info: local HA resource acquisition completed (standby).
Sep 15 11:55:33 cluster2 heartbeat: [6906]: info: Standby resource acquisition done [all].
Sep 15 11:55:33 cluster2 harc[3324]: info: Running /etc/ha.d//rc.d/status status
Sep 15 11:55:33 cluster2 mach_down[3339]: info: Taking over resource group IPaddr::X.X.X.X
Sep 15 11:55:33 cluster2 ResourceManager[3364]: info: Acquiring resource group: cluster1 IPaddr::X.X.X.X
Sep 15 11:55:33 cluster2 IPaddr[3391]: INFO:  Resource is stopped
Sep 15 11:55:33 cluster2 ResourceManager[3364]: info: Running /etc/ha.d/resource.d/IPaddr X.X.X.X start
Sep 15 11:55:33 cluster2 IPaddr[3447]: INFO: Using calculated nic for X.X.X.X: eth0
Sep 15 11:55:33 cluster2 IPaddr[3447]: INFO: Using calculated netmask for X.X.X.X: 255.255.255.0
Sep 15 11:55:33 cluster2 IPaddr[3447]: INFO: eval ifconfig eth0:0 X.X.X.X netmask 255.255.255.0 broadcast X.X.X.255
Sep 15 11:55:33 cluster2 IPaddr[3435]: INFO:  Success
Sep 15 11:55:33 cluster2 mach_down[3339]: info: Taking over resource group drbddisk::dns
Sep 15 11:55:33 cluster2 ResourceManager[3542]: info: Acquiring resource group: cluster1 drbddisk::dns Filesystem::/dev/drbd0::/etc/bind::ext3 bind9
Sep 15 11:55:33 cluster2 ResourceManager[3542]: info: Running /etc/ha.d/resource.d/drbddisk dns start
Sep 15 11:55:33 cluster2 kernel: [2503139.127167] block drbd0: role( Secondary -> Primary )
Sep 15 11:55:33 cluster2 Filesystem[3608]: INFO:  Resource is stopped
Sep 15 11:55:33 cluster2 ResourceManager[3542]: info: Running /etc/ha.d/resource.d/Filesystem /dev/drbd0 /etc/bind ext3 start
Sep 15 11:55:33 cluster2 Filesystem[3684]: INFO: Running start for /dev/drbd0 on /etc/bind
Sep 15 11:55:33 cluster2 kernel: [2503139.227146] kjournald starting.  Commit interval 5 seconds
Sep 15 11:55:33 cluster2 kernel: [2503139.227151] EXT3-fs warning: maximal mount count reached, running e2fsck is recommended
Sep 15 11:55:33 cluster2 kernel: [2503139.234844] EXT3 FS on drbd0, internal journal
Sep 15 11:55:33 cluster2 kernel: [2503139.234849] EXT3-fs: mounted filesystem with ordered data mode.
Sep 15 11:55:33 cluster2 Filesystem[3678]: INFO:  Success
Sep 15 11:55:33 cluster2 ResourceManager[3542]: info: Running /etc/init.d/bind9  start
Sep 15 11:55:33 cluster2 mach_down[3339]: info: /usr/share/heartbeat/mach_down: nice_failback: foreign resources acquired
Sep 15 11:55:33 cluster2 mach_down[3339]: info: mach_down takeover complete for node cluster1.
Sep 15 11:55:33 cluster2 heartbeat: [6906]: info: mach_down takeover complete.
Sep 15 11:55:36 cluster2 kernel: [2503141.615135] block drbd0: peer( Secondary -> Unknown ) conn( Connected -> TearDown ) pdsk( UpToDate -> DUnknown )
Sep 15 11:55:36 cluster2 kernel: [2503141.615156] block drbd0: Creating new current UUID
Sep 15 11:55:36 cluster2 kernel: [2503141.615514] block drbd0: asender terminated
Sep 15 11:55:36 cluster2 kernel: [2503141.615517] block drbd0: Terminating drbd0_asender
Sep 15 11:55:36 cluster2 kernel: [2503141.627085] block drbd0: Connection closed
Sep 15 11:55:36 cluster2 kernel: [2503141.627090] block drbd0: conn( TearDown -> Unconnected )
Sep 15 11:55:36 cluster2 kernel: [2503141.627097] block drbd0: receiver terminated
Sep 15 11:55:36 cluster2 kernel: [2503141.627100] block drbd0: Restarting drbd0_receiver
Sep 15 11:55:36 cluster2 kernel: [2503141.627102] block drbd0: receiver (re)started
Sep 15 11:55:36 cluster2 kernel: [2503141.627107] block drbd0: conn( Unconnected -> WFConnection )
Sep 15 11:55:45 cluster2 heartbeat: [6906]: WARN: node cluster1: is dead
Sep 15 11:55:45 cluster2 heartbeat: [6906]: info: Dead node cluster1 gave up resources.
Sep 15 11:55:45 cluster2 heartbeat: [6906]: info: Link cluster1:eth0 dead.

 

Cisco VPN client en Mac/Linux con certificado

Después de largas sesiones de intentos fallidos hemos encontrado el problema: el formato de los certificados. Pero vayamos por partes:

Primeramente, hemos de conseguir el software del cliente por ejemplo de aquí: http://cms.uni-konstanz.de/index.php?id=90/

En Linux tendremos que compilarlo así que nos harán falta todas las herramientas de compilación + linux-headers-`uname -e`

En Mac simplemente instalamos el mpkg.

En mi caso, para validarnos contra la GVA, necesitamos 3 certificados: el rootca.crt el accv-ca2.crt y el nuestro de firma, en formato p12.

Importamos el personal de la siguiente manera:

cisco_cert_mgr -U -op import

le pasamos el nombre del fichero y nos tiene que decir que lo ha importado correctamente.

Seguidamente tendremos que cambiar el formato de los otros 2. Resulta que la GVA nos los pasa en formato ASCII, podemos hacer un cat del fichero y ver el contenido perfectamente, pero éste formato no le gusta al software del cliente.

Gracias a un compi de la parte de Comunicaciones, mediante un strace al ejecutar el cisco_cert_mgr -R -op import vimos que cascaba en la primera línea cuando empieza a leer el certificado. Entonces investigando un poco y preguntándole al Sr. Google, convertimos el formato con:

openssl x509 -in accv-ca2.crt -inform PEM -out accv-ca2.der -outform DER

y

openssl x509 -in rootca.crt -inform PEM -out rootca.der -outform DER

Una vez cambiado el formato, ya podremos importarlos y podemos ver que están instalados:

[mfons@debian cert_new]$ cisco_cert_mgr -R -op list
Cisco Systems VPN Client Version 4.8.01 (0640)
Copyright (C) 1998-2007 Cisco Systems, Inc. All Rights Reserved.
Client Type(s): Linux
Running on: Linux 2.6.26-2-686 #1 SMP Thu Aug 19 03:44:10 UTC 2010 i686

Cert #          Common Name
——-         ————


0               Root CA Generalitat Valenciana
1               ACCV-CA2

[mfons@debian cert_new]$ cisco_cert_mgr -U -op list
Cisco Systems VPN Client Version 4.8.01 (0640)
Copyright (C) 1998-2007 Cisco Systems, Inc. All Rights Reserved.
Client Type(s): Linux
Running on: Linux 2.6.26-2-686 #1 SMP Thu Aug 19 03:44:10 UTC 2010 i686

Cert #          Common Name
——-         ————

0               XXX XXX XXX – NIF:483

De ésta forma sólo nos queda copiar el PCF que usamos en Windows y dejarlo en la carpeta de los Profiles. Arrancamos el servicio vpn_init, y arrancamos el cliente con:

vpn_client connect PROFILE

Conecta a los pocos segundos y si queremos podemos lanzarlo con un nohup y un & …

En Mac importamos éstos 3 certificados de la misma manera, él ya los organiza según sean de root o personales. También importamos el PCF sin tocar nada más. Y conectamos sin problemas.

Otra razón más para abandonar Windows.

VLC en Lenny no reproduce DVD

En una Lenny totalmetne al día con todos los codecs correctamente instalados y la última versión de VLC, tras intentar reproducir un DVD original no hace ni p*** caso.

Tras mucho googlear resulta que el problema estaba en la región que trae el DVD que parece que al VLC no le gusta mucho.

Como siempre, Linux nos provee de todo lo necesario:

debian:/home/mfons# apt-get install regionset
Leyendo lista de paquetes… Hecho
Creando árbol de dependencias
Leyendo la información de estado… Hecho
Se instalarán los siguientes paquetes NUEVOS:
regionset
0 actualizados, 1 se instalarán, 0 para eliminar y 0 no actualizados.
Necesito descargar 12,2kB de archivos.
Se utilizarán 41,0kB de espacio de disco adicional después de esta operación.
Des:1 http://ftp.caliu.cat lenny/main regionset 0.1-3 [12,2kB]
Descargados 12,2kB en 0s (26,6kB/s)
^[[DSeleccionando el paquete regionset previamente no seleccionado.
(Leyendo la base de datos …
111632 ficheros y directorios instalados actualmente.)
Desempaquetando regionset (de …/regionset_0.1-3_amd64.deb) …
Procesando disparadores para man-db …
Configurando regionset (0.1-3) …
debian:/home/mfons#regionset
regionset version 0.1 — reads/sets region code on DVD drives
Current Region Code settings:
RPC Phase: II
type: NONE
vendor resets available: 4
user controlled changes resets available: 5
drive plays discs from region(s):, mask=0xFF

Would you like to change the region setting of your drive? [y/n]:y
Enter the new region number for your drive [1..8]:2
New mask: 0xFFFFFFFD, correct? [y/n]:y
Region code set successfully!
debian:/home/mfons# regionset
regionset version 0.1 — reads/sets region code on DVD drives
Current Region Code settings:
RPC Phase: II
type: SET
vendor resets available: 4
user controlled changes resets available: 4
drive plays discs from region(s): 2, mask=0xFD

Would you like to change the region setting of your drive? [y/n]:n
debian:/home/mfons#

Le paso la región 2, que según la Wikipedia corresponde a Europa occidental.

Recuperando HFS+

HFS+ es el tipo de filesystem basado en B-Tree usado en los Mac. Nunca había tenido ningún problema, había sufrido numerosos cortes de luz y apagados drásticos y se había recuperado sin problemas. Hasta ayer.

Ayer se volvió a ir la luz en casa durante poco rato.  Fueron un par de minutos en los que el SAI respondió sin problemas, y el servidor, único aparato en él enchufado, se mantuvo intacto. El iMac no corrió la misma suerte. Se volvió a apagar de manera sucia.

Resulta que el FS se la quedado corrupto tras el brusco apagado y cuando intenta arrancar, no lo consigue.

Antes de empezar a cacharrear, el siempre querido SystemRescueCD acudió a mi rescate. Arranqué con el CD, monté la partición del iMac y por scp pasé toda la carpeta del usuario del iMac al sevidor. Bufff, salvados! Tras ésto ya me puse a chequear el disco y, efectivamente, está hecho una mierda:

Dejo algunas capturas hechas con la cámara del eeepc (qué cosa más apañá!)

La cosa se pone seria, tras unas 8 veces de chequear y solucionar problemas en el FS, intentar regenerar el catálogo del B-Tree, forzar a que arranque y no se qué pererías más, el tema no avanza.

Mientras escribo éstas líneas está intentando arrancar en Safe Mode y tampoco. Voy a probar a arrancar desde el DVD de instalación y intentar pasar un chequeo del FS desde la Utilidad de discos.

15-01-2010

La cosa empieza a ponerse complicada:

Formateando la unidad de disco como ext3 no hay ningún problema. La vuelvo a formatear como HFS+ para la instalación de Mac OS X, nada, no detecta disco.  La reparticiono todo el disco con la propia utilidad del DVD del Mac OS X y ahora, al instalar, casi terminando el primer DVD casca diciendo que en éstos momentos no puede instalar, que lo intente más tarde…. me cagonnnnn…..

Ésta mañana he puesto a descargar Leopard, probaremos a ver…

Instalaciones para vagos

Los ingredientes son los siguientes: PXE+DHCPD+TFTP+NFS

Primero hemos de instalarnos un servidor para correr todo ésto, en mi caso he elegido una Lenny 64bits que se he instalado en un blade HP ProLiant BL460c G1 con 2 Quad Core a 3Ghz y 8GB de ram.

La instalación sencilla: apt-get install dhcp3-server tftp-hpa nfs-common nfs-kernel-server

No voy a explicar demasiado la configuración del DHCP, sólamente, que en mi caso y para evitar problemas y probar la funcionalidad, el rango de IP’s que sirvo es 1 sóla y además eligiendo la mac. Con el parámetro next-server hacemos referencia al servidor para el PXE+TFTP y con filename el nombre de la imagen.

ddns-update-style none;
option domain-name “install”;
option domain-name-servers x.x.x.x;
default-lease-time 600;
max-lease-time 7200;
log-facility local7;
subnet x.x.x.0 netmask 255.255.255.0 {
next-server x.x.x.x;
filename=”pxelinux.0″;
range  x.x.x.x x.x.x.x;
option routers x.x.x.x;
}

host xxxxxxxx {
hardware ethernet xx:xx:xx:xx:xx:xx;
fixed-address x.x.x.x;
}

Para el servidor TFTP he elegido como apuntan en Ecualug, cambiar la forma en que trabaja y hacer que se arranque como un demonio más del sistema, pues, por defecto, funciona a través de inetd.

Para ésto: dpkg-reconfigure tftp-hpa y elegimos demonio.

Ahora tendremos que descargarnos las imágenes para arrancar vía PXE de las distribuciones que queramos. Yo me he descargado las de Lenny x86_64 y copiado las de Red Hat 4.7 y Red Hat 5.4.

Seguidamente tendremos que crear toda la estructura de directorios y ubicar en ellos dichas imágenes. Así es como me ha quedado el árbol de directorios:

El fichero default que hemos de generar a mano configurando las ubicaciones de los kernel y los initrd de cada uno de los sistemas que vayamos a arrancar:

En el arranque del Red hat 4.7 he incluído el fichero kickstart que crea la instalación de RedHat para que no me pregunte nada y lo haga de manera desatendida. He tenido que comentar algunas líneas que pretendían configurar alguna interfaz de red que éste servidor no tenía y cascaba la instalación y descomentar las líneas referentes al particionamiento para que efectivamente lo haga.  Desconozco si en Debian existe algo parecido.

El listado de lo que podemos lanzar para instalar:

Y para terminar,  en el propio servidor tenemos que copiar el contenido de los DVD’s de Red Hat. Yo los he puesto en /home/ftp/rhel47 y /home/ftp/rhel54 respectivamente y añadido los directorios correspondientes en el /etc/exports con permisos ro.

Para la instalación de Lenny no hace falta pues las imágenes son de tipo netinstall.

Indistintamente se puede lanzar la instalación de los Red Hat por NFS o FTP, pero para pasarle el fichero kickstart ha de ser NFS (aunque no he probado por FTP, la verdad)

Me hubiera gustado poner alguna captura donde se viera cargando el TFTP y el menú de los sistemas operativos pero por alguna extraña razón no puedo hacer capturas de la iLO …