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.

 

The 0517 led of Death and the blessed alt_disk_copy

Yesterday I upgraded an AIX 5.3 to AIX 6.1 TL07. But it failed the first time.

First of all I did the rootvg copy to another disk, create the fbo adapter in the VIO and map the AIX6.1 DVD1 to the partition. Then I rebooted the client and booted from the dvd. After some minutes, my system was on AIX6.1 TL04, everuthing went ok.

It’s time to apply patches to get the system on TL07. The .bff’s are on another machine so I exported that filesystem with NFS and mounted on my client. And I started the upgrade!

Apparently, everything went ok too, but… it wasn’t. Next reboot, the HMC shows the led code 0517 in the partition… and hangs… for a loooong time….. So, what was the problem? I did this way several times before in other systems…

I checked my led_code.pdf file …

0517: Explanation: Mounting client remote file system during network IPL.

I did not understand … “remote filesystem” ??? why ???

I tried to boot in service mode and tried to mount rootvg’s filesystems or checked them… but I was impossible… each time system tried to access rootvg, it hanged.

So the only thing left to do was to start it over.

I rebooted, started from the “altisnt_rootvg”, I deleted the “old_rootvg” and made another alt_disk_copy. And started the migration + upgrade one more time.

This time everything went ok (in fact just like before…) but this time, after the upgrade, it booted correctly.

Why hanged the first time? Well, the only thing was that in the middle of the upgrade, my vpn was disconnected from the customer… I don’t know if this can affect the whole process. Other times my connection has got disconnected, then I connected another time and nothing happen.

The only thing I know is that backup is and always will be a MUST ;)

Sometimes the system lies…

Recently I had to install sddpcm drivers on customer’s VIO servers. The environment is formed by 2 P520 machines with redundant VIO servers each of them.So, my work was to install the drivers on 4 machines.

Before doing this installation, we “moved” one partition from machine 2 to machine 1. The rootvg disks of this micropartition were located on local LV mapped from the VIO servers, so I had to clone the rootvg on a LUN disk. Then, I created a new micropartition on machine 1, attach this LUN to it and boot. Later I imported the data vg’s on this new micropartition and everything booted correctly on machine 1.

Now that I had machine 2 without running partitions it was time to install the drivers on the VIOs.

Everything was ok: I broke VIOs mirror and make a clone of rootvg, installed drivers and rebooted.

When I tried to relocate that micropartition I moved from machine 2 to machine 1 so I could have machine 1 without running micropartitions, I booted the micropartition and all the vg’s could not be activated. Why?!The system told me the PVs were corrupted… That wasn’t true. If I booted the micropartition on machine 1, everything went ok, so what was the problem?

I tried to export the vg and reimport it, delete the disk, discover it again… nothing worked… The vg’s could only be activated in micropartition located in machine 1 not on machine 2.

– Yes, reserve policy of disks was set to ‘no_reserve’ –

I decided to go ahead and leave the micropartitions stopped until I finished the driver installation.So I proceed the same way on machine 1 as in machine 2.

Time to activate vg’s on micropartition on machine 2.

I thought: ok, let’s start again from the beginning.

1. I created a new LUN on the storage

2. map to one vio on machine 1

3. map to one vio con machine 2

4. map to the micropartition on machine 1, everything ok.

5. shutdown micropartition

6. map the same LUN to the micropartition on machine 2

7. boot micropartition and oh!!! everything is activated!!

So, I think there was some type of block at storage level or vscsi level because the very firsts mappings of that micropartition were made without sddpcm driver installed on the VIO servers. I cannot find any other explanation.

When I install a VIO server, I install sddpcm driver. Always. (if storage permits, obviously) But I did not install these VIO servers…

Anyway, everything is up & running. The only thing left is to rebuild the mirrors of the rootvg VIOs.

Cloning AIX machine (the alt_disk_mksysb way)

I usually run alt_disk_copy to clone machines to another disk but recently I had to use alt_disk_mksysb. I have always created mksysb bootable images so you can burn to a cd/dvd and boot and install your system, but this time I was provided with the mksysb FILE. I thought this image was an ISO image so in my VIO server I ran:

mkvopt -name mymksysbimage -file mksysb.FILE -ro

Then I maped this image to my client partition:

loadvopt -disk mymksysbimage -vtd vtopt0

I tried to boot my client but it failed. Then I realised that this was not an iso image and I must to use alt_disk_mksysb

After digging some time I realised of this:

# lsmksysb -lf mksysb.FILE
VOLUME GROUP:           rootvg
BACKUP DATE/TIME:       Mon May 10 00:29:07 CEST 2010
UNAME INFO:             AIX XXXXX 3 5 00C995E44C00
BACKUP OSLEVEL:         5.3.11.0
MAINTENANCE LEVEL:      5300-11
BACKUP SIZE (MB):       25088
SHRINK SIZE (MB):       7359
VG DATA ONLY:           no

rootvg:
LV NAME             TYPE       LPs     PPs     PVs  LV STATE      MOUNT POINT
hd5                 boot       1       2       2    closed/syncd  N/A
hd6                 paging     2       4       2    open/syncd    N/A
sistemas_lv         jfs        2       4       2    open/syncd    /sistemas
hd8                 jfs2log    1       2       2    open/syncd    N/A
hd4                 jfs2       1       2       2    open/syncd    /
hd2                 jfs2       15      30      2    open/syncd    /usr
hd9var              jfs2       1       2       2    open/syncd    /var
hd3                 jfs2       4       8       2    open/syncd    /tmp
hd1                 jfs2       1       2       2    open/syncd    /home
hd10opt             jfs2       4       8       2    open/syncd    /opt
fslv01              jfs2       16      32      2    open/syncd    /software
loglv14             jfslog     1       2       2    open/syncd    N/A

The problem were this “PP”, you know, this is “Physical Partitions”…. This mksysb image was made from a mirrored rootvg so if you want to create a system from this mksysb, you must provide alt_disk_mksysb with 2 disks. Then, my command runs this way:

# alt_disk_mksysb -B -O -m /home/padmin/mksysb/mksysb.FILE -d “hdisk35 hdisk36″

This is run inside my VIO server. It is actually running. After it finishes, I’ll map one of the disks to a client partition and I’ll try to boot.

Happy new year!

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.

RHCE

A la 2ª va la vencida, ya soy RHCE.

Imagen

Lo malo de empezar con las certificaciones es que nunca tienes suficiente.

La próxima: RHCDS, que son 3 exámenes, ya hay faena para el año que viene…

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.