Posts Tagged ‘debian’

Instalación de OPSView en Alta Disponibilidad

|

OPSView es un sistema de monitorización libre. El siguiente tutorial cubre la instalación de dos servidores maestros de monitorización en alta disponibilidad. Está realizado sobre Debian Linux y aunque hay tutoriales y documentación en la página oficial, si queréis montar dos Debian maestros en HA no os recomiendo seguir la guia oficial al pie de la letra (yo ya lo hize).
La guía mostrada a continuación no es enteramente mía. Está basada en documentación oficial y en trozos de las páginas que menciono en el apartado referencias. Además no habría podido realizarla sin la ayuda de mis compañeros adolfop, 4lv3rn3, spanic y vege10n. Ahí vamos:

::Instalación SSOO::

Instalamos Debian en ambos nodos, solo el sistema base.
Para el particionado reservamos dos particiones para el HA sin montar, una para los metadatos(con 128 MB basta) la otra para var2.
Una vez instalado añadimos las siguientes lineas al fichero /etc/apt/sources.list

—-
deb http://ftp.es.debian.org/debian/ etch non-free
deb-src http://ftp.es.debian.org/debian/ etch non-free
deb http://www.backports.org/debian etch-backports main contrib non-free
deb http://apt.opsview.org/debian etch main
deb http://ftp.debian.org/debian etch non-free
—-

Después de esto al hacer “aptitude update” obtendremos errores de certificados, se solucionan importándolos con los siguienetes
comandos:

gpg –keyserver subkeys.pgp.net –recv-key XXXXXXXX
gpg –export –armor XXXXXXXX | apt-key add -

Donde XXXXXXXX son los últimos 8 dígitos numéricos del cedrtificado y se obtienen del error al hacer el “aptitude update”
COnfiguramos para que nodo1 y nodo2 tengan IP’s estáticas y completamos el fichero /etc/hosts para que resuelvan uno contra el otro.

:: Instalación Software ::

Instalamos el software necesario mediante aptitude:

aptitude install heartbeat
aptitude install drbd8-source
aptitude install drbd8-utils
aptitude install ssh
aptitude install opsview

Creamos el módulo para el drbd8:

module-assistant auto-install drbd8

:: Configuración de la HA ::

En ambas máquinas sustituimos el fichero /etc/drbd8.conf por este:

—-
global {
usage-count no;
}
common {
}
resource “r0″ { # r0 es el nombre del recurso
protocol C;
startup {
wfc-timeout 80;
degr-wfc-timeout 120;
}
disk {
on-io-error detach;
}
net {
}
syncer { rate 10M; }
on nodo1 { # nodo1
device /dev/drbd0; # dispositivo HA
disk /dev/sda6; # partición que compartirán los nodos en HA (var2)
address X.X.X.X:7780; # IP y puerto que se utilizará para balancear
meta-disk /dev/sda8[0]; # partición donde se guardan los metadatos
}
on nodo2 { # idéntico para el nodo2
device /dev/drbd0;
disk /dev/sda6;
address X.X.X.X:7780;
meta-disk /dev/sda8[0];
}
}
—-

Para ajustar los permisos ejecutamos los siguientes comandos:

chgrp haclient /sbin/drbdsetup
chmod o-x /sbin/drbdsetup
chmod u+s /sbin/drbdsetup

chgrp haclient /sbin/drbdmeta
chmod o-x /sbin/drbdmeta
chmod u+s /sbin/drbdmeta

En ambos nodos creamos el dispositivo para el recurso:

drbdadm create-md r0

Acto seguido iniciamos el servicio:

/etc/init.d/drbd8 start

Ahora en el nodo que inicialmente será el maestro (nodo1) ejecutamos:

drbdadm — –overwrite-data-of-peer primary r0
mkfs -t ext3 /dev/drbd0
mkdir /var2
mount /dev/drbd0 /var2

En el nodo2 creamos el directorio var2 (mkdir /var2).

Para iniciar la sincronización entre ambos nodos introducimos el siguiente comando en el nodo primario (nodo1):

drbdadm — connect all

En ambos nodos eliminamos el incio automático del software que será balanceado, ya que éste será iniciado mediante HA:

update-rc.d -f opsview remove
update-rc.d -f opsview-web remove
update-rc.d -f mysql remove
update-rc.d -f apache2 remove
update-rc.d -f opsview-agent remove

En ambos nodos reemplazados el fichero /etc/ha.d/ha.cf por el siguiente:

—-
debugfile /var/log/ha-debug
logfile /var/log/ha-log
keepalive 2
deadtime 30
warntime 10
initdead 120
auto_failback off
bcast eth0
# This is a ping test in our network to check which server can ping it
ping X.X.X.X # IP virtual a la que los clientes deberán dirigirse para utilizar los servicios ofrecidos en HA

node nodo1
node nodo2
respawn hacluster /usr/lib/heartbeat/ipfail
apiauth ipfail gid=haclient uid=hacluster
—-

Em ambos nodos reemplazamos el fichero /etc/ha.d/haresources por el siguiente(idéntico en los dos nodos):

—-
nodo1primario drbddisk::r0 Filesystem::/dev/drbd0::/var2::ext3 10.10.10.120 mysql opsview opsview-web apache2
# nodo que actua de primario, recurso, filesystem, punto de montaje, IP virtual, servicios en HA
—-

En ambos nodos reemplazamos el fichero /etc/ha.d/authkeys por el siguiente:

—-
auth 1
1 sha1 MySecret
—-

Modificamos los permisos del fichero /etc/ha.d/authkeys:

chmod 600 /etc/ha.d/authkeys

Una vez sincronizados deberemos preparar /var em ambos nodos para que los datos a compartir por los servidores estén en la partición en HA.
Para ello vamos a tomar el recurso compartido en el nodo2, realizaremos la preparación, acto seguido repetir los pasos, tomando el recurso
el nodo1 y haciendo la misma preparación:

En el nodo1 “soltamos” el recurso:

umount /var2
drbdadm secondary r0

En el nodo2 “cogemos” el recurso:

drbdadm primary r0
mount /dev/drbd0 /var2

A continuación vamos a preparar /var y /var2. La idea es que los recursos que se necesitan en HA estén realmente en /var2, aunque la máquina
a nivel local los trate como si estuvieran en /var.

cd /usr/local/
tar cvzf nagios.tar.gz nagios
mv nagios.tar.gz /var2
rm -r nagios
cd /var2
tar xvzf nagios.tar.gz /var2
ln -s /var2/nagios /usr/local/nagios
cd /usr/local/
tar cvzf opsview-web.tar.gz opsview-web
mv opsview-web.tar.gz /var2
rm -r opsview-web
cd /var2
tar xvzf opsview-web.tar.gz /var2
ln -s /var2/opsview-web /usr/local/opsview-web
cd /var/lib/mysql
tar cvzf mysql.tar.gz mysql
mv mysql.tar.gz /var2
rm -r mysql
cd /var2
tar xvzf mysql.tar.gz /var2
ln -s /var2/mysql/ /var/lib/mysql/mysql

Reemplazamos los agentes NRPE de Nagios:

apt-get install nagios-nrpe-server nagios-plugins-basic
rm /etc/nagios/nrpe.cfg
cp /var2/nagios/etc/nrpe.cfg /etc/nagios/nrpe.cfg

Editamos el fichero /etc/nagios/nrpe.cfg y lo modificamos para cambiar las rutas “/usr/local/nagios/libexec” por “/usr/lib/nagios/plugins
Reiniciamos el servicio:

/etc/init.d/nagios-nrpe-server restart

Tras realizar el último paso en el nodo1 podemos reiniciar las máquinas y dispondremos de OPSView en HA.
Para acceder al servicio los clientes deben dirigirse a la IP virtual, en este caso http://X.X.X.X:3000

:: NOTAS ::

Un error comun a la hora de sincronizar con drbd es el “Repair Split-Brain detected, dropping connection!

Para solucionarlo debemos seguir los siguientes pasos:
Paramos el heartbet en ambos nodos.
En el secundario ejecutamos el siguiente comando:

drbdadm — –discard-my-data connect r0

En el primario ejecutamos el siguiente comando:

drbdadm connect r0

Si aún con ello no levanta probamos el siguiente comando en el primario:

drbdadm primary r0

:: Referencias ::

http://docs.opsview.org/doku.php?id=opsview2.14:hamaster-debian-howto
http://wiki.centos.org/HowTos/Ha-Drbd
http://www.estrellateyarde.es/discover/drbd-en-linux
http://liyuangarcia.blogspot.com/2007/11/cluster-de-alta-disponibilidad-sobre.html
http://gobok.serveblog.net/system-admins/howto-repair-split-brain-detected-dropping-connection/

EL bug del Kernel: velocidad de reacción

|

Todos conocemos el gran revuelo armado por el bug descubierto en el núcleo de Linux. Desde el punto de vista técnico este fallo ha sido muy grave porque permitía una escalada local de privilegios muy sencilla al estar disponible un exploit( en realidad varias versiones ) que aprovechaban dicha vulnerabilidad.
La historia es conocida, dejo varias referencias:

http://open-eslack.org/php/news.php?readmore=60
http://www.kriptopolis.org/bug-kernel-linux
http://barrapunto.com/article.pl?sid=08/02/11/106213

El bug fue noticiado en SecurityFocus el 8 de Febrero a las 12 horas.
En la pagina oficial del Kernel de Linux la nueva release con el bug corregido vió la luz el 10 de Febrero a las 16:47.
Hoy no voy a hablar de lo buena que ha sido la reacción de los desarrolladores ni nada de eso, solo quiero establecer una comparativa de respuesta por parte de las distintas distribuciones, centrandome en las más populares y haciendo un breve análisis por familias.

Los datos de disponibilidad del paquete oficial corregido son los siguientes:

Slackware 12: 11 Febrero a las 17:46.
Zenwalk 5: a fecha de edición de este artículo no he encontrado el advisory.
Vector Linux 5.8: a fecha de edición de este artículo no he encontrado el advisory.
Debian 3.1: 11 Febrero sin especificar hora.
Mandriva 2008: 12 Febrero sin especificar hora.
Gentoo: a fecha de edición de este artículo no he encontrado el advisory.
Ubuntu: 12 Febrero sin especificar hora.
Fedora 8: 11 Febrero a las 15:39.
OpenSuse 10.3: 12 Febrero a las 14:00.
Arch Linux : UPDATED: 10 de Febrero sin especificar hora.

No voy a poner grafiquitos ni nada de eso( soy partidario de la filosofía KISS ) pero si me gustaría comentar algunas ideas:

En primer lugar lo extraño que me parece que Gentoo a fecha de este artículo no haya siquiera publicado el aviso, creo que no he sabido encontrarlo o que debe de haber alguna razón para ello, omito por tanto comentarios sobre esta distribución que me merece un gran respeto, nos in antes decir lo grave que me parecería esta situación.
En segundo lugar destacar que la referencia en la resolución de estas vulnerabilidades han sido las distribuciones más usadas, UPDATED: Destacando a Arch Linux que gana a las demás por un dia de diferencia, Fedora a la cabeza, Slackware y Debian. ¿He dicho las más usadas? Sinceramente no creo que Slackware sea de las más usadas, pero ahi está, la segunda más rapida en contestar.
Esto me hace pensar en uno de esos mitos sobre slack, aquel de que los paquetes son obsoletos, que en Slackware se usa software anticuado y en general todas esas cosas que se dicen desde la ignorancia y que con el conocimiento en la mano caen por su propio peso.

Si separamos los datos por familias vemos que si de RPM’s se trata Fedora ha ganado la partida, una distribución muy sería con una empresa preocupada por la seguridad( y por las ventas ). Por detrás vemos la reacción de Mandriva y OpenSuse. No me sorprende que estas ultimas no estén a la cabeza.
En la familia de los paquetes DEB comprobamos de nuevo lo que algunos intuíamos desde hace tiempo: Debian no ha muerto. Puede que no esté Murdock a la cabeza y que Ubuntu les haya quitado publicidad y usuarios, pero los debianitas pueden enorgullecerse de que a nivel de seguridad la respuesta de su equipo de seguridad reafirma que su distro está más comprometida con la seguridad.
Entre los amantes de los TGZ’s es un dia de luces y sombras, si bien se confirma que Slackware marca la pauta en todos los aspectos y en seguridad también( no olvidemos, la tercera distribución en reaccionar de las analizadas ) se puede apreciar también que entre las distribuciones derivadas no tienen esa misma preocupación. Zenwalk y Vector Linux no han sacado parche a dia de hoy o yo no he sabido encontrarlo. No sé porque pero tampoco esto me sorprende.

Como conclusión pienso que si estás interesado en la seguridad( o la necesitas ) deberías utilizar en tus sistemas Linux más críticos las distribuciones padres.
Las distribuciones derivadas suelen tener muy buena pinta, tener una web muy chula, mucha propaganda y su uso te convierte muchas veces en muy way, pero a la hora de la verdad vemos nuevamente cuales son la referencia.