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 SIZE (MB):       25088
SHRINK SIZE (MB):       7359
VG DATA ONLY:           no

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.

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


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é…)


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:

name=Extra Packages for Enterprise Linux 5 – $basearch

name=Extra Packages for Enterprise Linux 5 – $basearch – Debug

name=Extra Packages for Enterprise Linux 5 – $basearch – Source

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’

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
+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.


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


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…