I’ve been thinking about my home server today and I think I need some more RAM for it …

I was wondering when did I installed it and I’ve found it was born on 2008 !!

It’s a Intel(R) Core(TM)2 Duo CPU E8400  @ 3.00GHz with 4GB RAM.

I remember I was looking for a machine with VT support and some amount of RAM to get some virtualized machines.

I bought it everything separated: motherboard, ram, disks… And installed the operating system.

For the installation I had an old disk, a 40GB IDE disk that worked perfectly and nowadays it does, for Debian Etch (at that moment it was the stable version), and 2 1TB disks for RAID1 managed by the Linux mdadm.

I have upgraded the operating system without problems from v4, v5, v6 and finally v7 and added some more disks. Nowadays I have the same 40GB disk for the operation system and 4 more disks: 3 1TB for RAID5 and 1 500GB disk for backups.

 

Implantación de Puppet Linux

Puede llegar un momanto en nuestro trabajo donde se con empiece a complicar el administrar nuestros servidores debido no ya a la complejidad del propio sistema sino al número de máquinas que debemos tener controladas.

Debido a la creciente tendencia de virtualizar todo lo que tengamos en plataforma Intel, el número de servidores RHEL a administrar está rozando ya las 80 máquinas. Cuando tenemos que tener configurados correctamente o hacer algún cambio en los DNS, SNMP, NTP, etc se hace inviable y tedioso entrar en cada una de ellas, hacer los cambios pertinentes y reiniciar el servicio. Para poder tener todo ésto controlado desde una consola central utilizamos Puppet Linux.

Lo tenemos disponible para RHEL, Debian y cualquier distribución. La aplicación consta de un servidor principal que se llama Puppetmaster (y no Master of Puppets, aunque no estaría mal) y un pequeño agente que instalamos en cada una de las máquinas a administrar. Para Debian está en los repositorios oficiales pero para RHEL hay que echar mano de los repos de EPEL, que aunque estén mantenidos por Fedora son perfectamente compatibles con RHEL.

Configuración del puppetmaster:

El servidor lo tengo en una máquina bastante potente que, entre otras cosas, ahora también hace de servidor Puppet. Ésta máquina corre Debian Squeeze. Evidenetemente también podemos instalar el puppetmaster en una máquina con RHEL, pero en el entorno donde estoy, me venía especialmente bien ya que ésta máquina tiene bastante tarjetas de red y la puedo configurar para que tenga conexión a las distintas subredes de todos los entornos que tenemos y no andar abriendo puertos en el firewall.

Instalación sencilla: apt-get install puppetmaster

Con Puppet podemos hacer muchas cosas. Yo de momento únicamente lo uso para mantener ficheros de configuración actualizados y monitorizar servicios. Pero también se puede instalar software, por ejemplo.

Toda la configuración de Pupput la entrontramos en /etc/puppet

El primer fichero que debems configurar es /etc/puppet/fileserver.conf

Aquí es donde pondremos la ruta local donde estarán los ficheros que queremos pasarle a los clientes y quién puede y quién no, acceder a ellos.

[files]
path /etc/puppet/files
allow *

En mi caso, podrá acceder todo el mundo previa firma del certificado. Más adelante veremos cómo se hace ésto.

El siguiente fichero es: /etc/puppet/puppet.conf

[main]
logdir=/var/log/puppet
vardir=/var/lib/puppet
ssldir=/var/lib/puppet/ssl
rundir=/var/run/puppet
factpath=$vardir/lib/facter
templatedir=$confdir/templates
certname=puppetmaster
autosign=false
reports=rrdgraph

Lo que está en negrita es lo que yo he añadido: certname -> nombre del servidor (debe coincidir con el hostname, sino seguramente dará problemas de certificado); autosign -> false, para que cualquier cliente deba ser validado desde el servidor para poder acceder a él. Prefiero dejarlo así para controlar mejor los clientes. Podríamos ponerlo a true para ahorrarnos éste paso; reports -> ésto es para que nos genere gráficas con rrd de la actividad de los clientes (no muy buenas por cierto, tengo que mirar de hacerlo de otra forma).

El funcionamiento de Puppet es a base de declaraciones de clases con una sintaxis propia del aplicativo. Todas éstas declaracione (o manifiestos) se encuentran en /etc/puppet/manifests

Yo utilizo una clase principal llamada /etc/puppet/manifests/site.pp dentro de la cual llamo a las diferentes clases que previamente he creado. Por ejemplo, he creado una clase por cada servicio que quiero monitorizar, una por cada fichero que quiero mantener, etc, pero se podrían agrupar (seguramente más adelante lo haré…)

site.pp:

import “classes/*.pp”

# Defaults para todos los nodos
node default {
include f_resolv_conf
include f_ntp_conf
include f_snmp_conf
include f_sshd_config
include s_snmp
include s_ntp
include s_sshd
}

Todos los include hacen referencia a ficheros dentro de classes/ con la extensión .pp Por adptar una nomenclatura los que empiezan con f_ hacen referencia a ficheros de configuración y los que empiezan con s_ a la monitorización de servicios. Pongo un ejemplo de cada uno, todos son iguales.

puppetmaster:/etc/puppet/manifests# cat classes/f_resolv_conf.pp
class f_resolv_conf {
file {“/etc/resolv.conf”:
ensure => present,
mode => 644,
owner => root,
group => root,
source => “puppet://puppetmaster/files/resolv.conf”
}
}

Las variables son autoexplicativas, verdad?

Comentar únicamente, que el servir el fichero se hace a través de un pequeño servidor web que se instala con el puppetmaster y escucha en el puerto 8140/tcp aunque también tiene el 8443/tcp abierto y a la escucha para las peticiones de certificados.

puppetmaster:/etc/puppet/manifests# cat classes/s_ntp.pp
class s_ntp {
service { “ntpd”:
pattern => “ntp”,
ensure => “running”,
start => “service ntpd start”,
stop => “service ntpd stop”,
hasstatus => “true”,
hasrestart => “true”,
}
}

Nos podemos encontrar un problema en las variables start y stop. No todas las distribuciones Linux arrancan y paran servicios de la misma manera. Para solventar éste problema, Puppet Linux nos permite, dentro de la clase, hacer distinciones de distros y aplicar unos comandos u otros según corresponda. Para ésto se utiliza la herramienta facter, que se instala junto con el cliente puppet y que le permite, entre otras cosas, averiguar con quién está hablando. En mi entorno no he tenido que hacer ésta distinción, al menos todavía ya que todos los servidores corren RHEL. El hasstatus quiere decir que si los demonios de arranque/parada tienen la opción ‘status’ pues que la use para averiguar el estado del servicio, y el hasrestart para que si tienen la opción ‘restart’ se use en vez de hacer un stop/start a la hora de refrescar el servicio.

Y por la parte servidor poco más, pasamos ahora a la parte cliente.

Como he dicho, en los repos oficiales de RHEL no se encuentra Puppet, pero podemos echar mano de EPEL para la instalación.

En nuestro servidor cliente crearemos un /etc/yum.repos.d/epel.repo nuevo con los siguiente:

[epel]
name=Extra Packages for Enterprise Linux 5 – $basearch
#baseurl=http://download.fedoraproject.org/pub/epel/5/$basearch
mirrorlist=http://mirrors.fedoraproject.org/mirrorlist?repo=epel-5&arch=$basearch
failovermethod=priority
enabled=1
gpgcheck=0
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL

[epel-debuginfo]
name=Extra Packages for Enterprise Linux 5 – $basearch – Debug
#baseurl=http://download.fedoraproject.org/pub/epel/5/$basearch/debug
mirrorlist=http://mirrors.fedoraproject.org/mirrorlist?repo=epel-debug-5&arch=$basearch
failovermethod=priority
enabled=0
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL
gpgcheck=0

[epel-source]
name=Extra Packages for Enterprise Linux 5 – $basearch – Source
#baseurl=http://download.fedoraproject.org/pub/epel/5/SRPMS
mirrorlist=http://mirrors.fedoraproject.org/mirrorlist?repo=epel-source-5&arch=$basearch
failovermethod=priority
enabled=0
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL
gpgcheck=0

Y nada más, ahora basta un yum -y install puppet. No es necesario tener registrada la máquina en la RHN, a no ser que el paquete contenga algunas dependencias que tienen que ser descargadas de los repos de RH, entonces nos fallará la instalación. Tendremos que registrar la máquina previamente.

Una vez instalado sólamente tenemos que configurar 2 ficheros:

1: /etc/puppet/puppet.conf -> añadimos una línea nueva en la sección [main] con ‘server = puppetmaster’ (nombre del servidor)

2: /etc/sysconfig/puppet -> añadimos PUPPET_EXTRA_OPTS=–report (para que genere reports de actividad)

Una vez tenemos todo configudado, vamos a validarnos en nuestro servidor con el certificado:

[root@bddesa1 ~]# puppetd -t
warning: peer certificate won’t be verified in this SSL session
info: Caching certificate for ca
warning: peer certificate won’t be verified in this SSL session
warning: peer certificate won’t be verified in this SSL session
info: Creating a new SSL certificate request for bddesa1.ha.gva.es
info: Certificate Request fingerprint (md5): 53:83:53:7E:50:49:85:B5:40:99:27:8A:03:4D:D3:92
warning: peer certificate won’t be verified in this SSL session
warning: peer certificate won’t be verified in this SSL session
warning: peer certificate won’t be verified in this SSL session
Exiting; no certificate found and waitforcert is disabled
[root@bddesa1 ~]#

Ahora tenemos que firmar el certificado en nuestro servidor. Nos vamos al puppetmaster:

puppetmaster:/# puppetca –list
bddesa1 (53:83:53:7E:50:49:85:B5:40:99:27:8A:03:4D:D3:92)

puppetmaster:/# puppetca –sign bddesa1
notice: Signed certificate request for bddesa1
notice: Removing file Puppet::SSL::CertificateRequest bddesa1 at ‘/var/lib/puppet/ssl/ca/requests/bddesa1.pem’
puppetmaster:/#

Ahora que ya hemos firmado el certificado, volvermos a ejecutar puppetd -t en el cliente y vemos que conecta correctamente al servidor y empieza a actualizar los ficheros, chequear servicios y todo lo que le hayamos configurado.

Por ejemplo, los cambios del DNS:

— /etc/resolv.conf    2011-10-18 16:55:19.000000000 +0200
+++ /tmp/puppet-file.11280.0    2011-12-23 10:15:10.000000000 +0100
@@ -1,3 +1,6 @@
search domain.org
nameserver 1.2.3.4
nameserver 5.6.7.8
+options timeout:1 attempts:1
info: FileBucket adding {md5}e5b242192d3a5a4017158eb34c932925
info: /Stage[main]/F_resolv_conf/File[/etc/resolv.conf]: Filebucketed /etc/resolv.conf to puppet with sum e5b242192d3a5a4017158eb34c932925
notice: /Stage[main]/F_resolv_conf/File[/etc/resolv.conf]/content: content changed ‘{md5}e5b242192d3a5a4017158eb34c932925’ to ‘{md5}1b603ae49bc8c2e33e018085c9e2bf1a’

Arrancamos el servicio en el cliente: service puppet start

Y lo añadimos al arranque: chkconfig –level 35 puppet on

De ésta forma cuando haya que cambiar algo masivamente en todas las máquinas, entraremos al puppetmaster, cambiamos el fichero que conrresponda y añadimos alguno nuevo, y se replicará de forma automática entre todos los clientes.

Si tocamos algo de la configuración del puppetmaster no hace falta reiniciar el servicio ya que él sólo se autorecarga. Si queremos forzar la actualización de los clientes hay que entrar en cada uno de ellos y ejecutar ‘puppetd -t’, si no tocamos nada, cada 30 minutos los clientes hacen una nueva consulta al servidor.

He leído en algunos foros que el mini-servidor web que lleva el puppetmaster puede llegar a saturarse por muchas peticiones de los clientes. En éste caso, hay gente que lo ha sussituído por un Apache o cualquier otro. De momento, yo no me he encontrado con ningún problema y llego añadidas unos 30 servidores.

Salut! y espero que aproveche.

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.

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.

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 …