Codigo Unix

OpenBSD: Enabling serial console for KVM/libvirt utilization

2012-01-01T15:38:00.000-08:00

Tengo un OpenBSD 5.0 con el que estoy realizando una serie de pruebas en una máquina virtual sobre KVM en CentOS 6. KVM en conjunto con libvirt, provee una serie de herramientas para administrar el host virtualizado, una de ella es virt-manager, una herramienta escrita utilizando GTK que obviamente necesita tener X ejecutándose. La otra es virsh, una CLI para administración de hosts virtuales.

Virsh tiene la interesante opción de poder attachear una consola virtual, la cual previamente debe estar configurada en el sistema operativo guest. Esto es importante para poder realizar con la VM todo el trabajo que no podemos hacer de manera remota utilizando SSH y así tener que evitar abrir virt-manager cada vez que tengamos que agregar algún parámetro al booteo, por ejemplo.

Cabe destacar que esta configuración no solo aplica a hosts virtuales, sino también a hosts físicos que tienen la posibilidad o se conectan mediante consola serie. Los pasos para realizar esto son bastante sencillos:

Vamos a dividir las consolas en dos partes:

La utilizada durante el booteo.
La utilizada durante el login.

Para poder ver los mensajes del booteo en la consola serie, podemos hacer esto de dos formas, la primera añadiendo el paramétro al momento del booteo, en el boot prompt, esta configuración será dinámica y se perderá la próxima vez que haga un reboot del equipo, para ello bajo x86 o x86_64 añadimos el parámetro set tty com0

boot> set tty com0

Siendo com0 nuestra consola serie. Si estamos bajo una arquitectura Sun/SPARC, y no hay un teclado conectado al equipo, se utilizará la consola serie por default. Caso contrario en el OK prompt añadimos:

ok setenv input-device ttya
ok setenv output-device ttya
ok reset

Ahora bien, esta configuración es dinámica, y como dije anteriormente, se perderá durante el booteo, caso que necesitemos hacerla permanente, con el equipo una vez booteado editamos o creamos el archivo /etc/boot.conf con la siguiente línea dentro:

set tty com0

Esto activará la consola serie al momento del booteo del equipo y todos los mensajes serán impresa utilizando el device com0. Pero para poder utilizar esto durante el login y la administración normal del sistema operativo tenemos que añadir una configuración adicional, editando el archivo /etc/ttys, reemplazamos la siguiente línea:

tty00 "/usr/libexec/getty std.9600" unknown off

Por esta, que nos iniciara /usr/libexec/getty en el dispositivo char tty00:

tty00 "/usr/libexec/getty std.9600" vt220 on secure

Ahora si, es importante tener un emulador de terminal como Minicom configurado en 9600 baudios 8 bits, sin paridad y 1 de Stop (9600 8N1). Ahora si hacemos un virsh console "OpenBSD-5.0-test", obtendremos la siguiente salida:

virsh # console OpenBSD-5.0-test
Connected to domain OpenBSD-5.0-test
Escape character is ^]
>> OpenBSD/i386 BOOT 3.17
boot>
booting hd0a:/bsd: 8192892+1088776 [61+367888+353319]=0x98a398
entry point at 0x200120
Copyright (c) 1995-2011 OpenBSD. All rights reserved. http://www.OpenBSD.org
OpenBSD 5.0 (GENERIC) #43: Wed Aug 17 10:10:52 MDT 2011
deraadt@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC

---- Output ommited ----

starting network daemons: sshd sendmail inetd.
starting local daemons: cron.
Sun Jan 1 20:33:02 ART 2012
OpenBSD/i386 (fwl-dmz.foobar.net) (tty00)
login: root
Password:
OpenBSD 5.0 (GENERIC) #43: Wed Aug 17 10:10:52 MDT 2011
Welcome to OpenBSD: The proactively secure Unix-like operating system.
You have mail.
fwl-dmz ~:#

PF: OS based redirection

2011-12-31T00:36:00.000-08:00

Supongamos que tenemos en nuestra red dos servidores web, a uno solo pueden entrar los clientes que corran Windows, a los otros los que usan GNU/Linux. ¿Es posible hacer esto de alguna manera sencilla?, la respuesta es si!. Utilizando PF, OS Fingerprints y una regla de redirección.

OS Fingerprints es un mecanismo que tiene PF para determinar el sistema operativo que esta utilizando un host en concreto que pasa por el firewall, lo hace mediante la examinación de algunos campos del header del paquete, como por ejemplo el TTL, y acorde a lo establecido en el archivo /etc/pf.os determina el sistema operativo al que corresponde el paquete.

Supongamos que el servidor web para Windows corre un IIS en el host 10.0.0.10, puerto 8080/TCP y el servidor Linux 2.6 un Apache en 10.0.0.20, puerto 8081/TCP.
Simplemente deberiamos utilizar estas:

$ext_if = "em0"
$webwin="10.0.0.10"
$weblinux="10.0.0.20"

pass in on $ext_if proto tcp from any os "Windows" to any port 80 modulate state flags S/SA rdr-to $webwin port 8081
pass in on $ext_if proto tcp from any os "Linux 2.6" to any port 80 modulate state flags S/SA rdr-to $weblinux port 8081

Esto se consigue mediante la clave OS, a la que debe indicarsele el sistema operativo a evaluar el fingerprint, y rdr-to que nos permite realizar una redirección a un host determinado acompañado de su número de puerto.

Unix: Stateful firewalls vs. Non-Stateful firewalls

2011-12-30T23:53:00.000-08:00

Hace unos días tuve una interesante discusión en Twitter sobre las ventajas de utilizar como firewall Packet Filter contra Netfilter (IPTables). Cabe destacar que tengo mas conocimientos de PF que de IPTables, por lo cual conozco más las ventajas prácticas del primero que del último.

En teoría de firewalls, encontramos los denominados stateful firewalls, son firewalls que actúan en layer 3 del modelo OSI/ISO (network) donde su punto fuerte es el poder de inspeccionar estados, y saber si los mismos corresponden a una conexión ya existente o no. Esto es posible lograrlo en Linux mediante connectrion tracking utilizando los módulos conntrack, y así mantener un record de los estados existentes en el sistema operativo.

Tanto Packet Filter como IP Filter utilizan una estructura denominada tabla de estados (o status table), para mantener dicha información. Si un paquete IP ingresa al firewall, se va a buscar mediante una previa inspección del header si el mismo forma parte de una conexión ya existente, y si esto es cierto no se van a inspeccionar reglas de filtrado, sino que el paquete va a pasar directamente. Si un paquete llega por primera vez al firewall, el mismo si matchea con alguna regla, entonces va a crear una entrada en la tabla de estados del firewall, y ya, mientras la conexión siga viva no va a pasar por dicha inspección de reglas.

Por su parte IPTables, trabaja distinto. Cada vez que un paquete llega (sea nuevo o no), va a pasar por las reglas de filtrado, si matchea con alguna regla se aplicará esta, en caso contrario se aplica la policy por default previamente definida. Pero como dije anteriormente, mediante la utilización de los módulos conntrack es posible logar esto. Como se muestra a continuación:

-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

En esta regla de filtrado todos los paquetes que ingresen al firewall con estado ESTABLISHED y RELATED van a ser aceptados, los cuales forman parte de una conexión ya existente posiblemente inicializada por un equipo de la red interna y de esta manera, por ejemplo es capaz mantener conexiones mediante NAT.

Esto puede ser realizado con una sintaxis más clara utilizando PF, y con la posibilidad de usar macros ;-)

wan_if='10.0.0.1'
lan_net='192.168.1.0/24'
pass in on $wan_if from any to $lan_net flags S/SA keep state

O mediante IP Filter:

pass in on em0 from any to 192.168.1.0/24 flags S/SA keep state

A modo resumen de lo visto hasta ahora podemos decir que todo firewall basado en estados se compone de dos elementos, ellos son: El conjunto de reglas de filtrado y la tabla de estados.

Esta tabla de estados en PF es una estructura en formato de árbol binario balanceado denominado AVL. Como sabemos la utilización de un árbol binario tiene un coste computacional un poco superior al de utilizar arboles hash, la decisión de utilizar un árbol binario en PF se basa en que fue concebido como parte del proyecto OpenBSD donde la principal preocupación al momento del diseño es la seguridad. Los hashes pueden provocar colisiones, esto es, dada distintas entradas obtener una misma salida, conociendo que a mayor cantidad de entradas en la tabla de estados, existe mayor posibilidad de colisiones, se opto por elegir un árbol binario como método de almacenar dichos estados.
Algoritmos de hashing como SHA1/SHA2 han demostrado tener casi nulas colisiones, pero el costo computacional de procesar búsquedas mediante estos algoritmos es bastante mas alto que el de utilizar algoritmos mas sencillos como MD4/MD5 que son fácilmente colisionables. Por lo cual, en la teoría, un atacante podría generar paquetes maliciosos para provocar colisiones en la tabla de estados y de esta manera realizar un ataque del tipo spoofing contra la red interna o DMZ y ganar acceso a equipos de acceso restringido.

Sabemos que el estado es una parte importante de los paquetes TCP, por cada paquete que matchee van a ser verificados varios campos por parte del firewall, esto es ISN (Initial Sequence Number), el origen (SRC), el destino (DST), puerto de origen (SRC PORT), y puerto de destino (DST PORT). PF computa el ISN añadiendo un valor aleatorio y de esta manera evitar ataques donde se altera el ISN y de esta manera evitar los ya conocidos SYN Flood que pueden provocar DoS/DDoS. IPTables no es capaz de realizar esta acción, aunque el costo computacional de no realizarlo es mucho menor del utilizado por PF.

Por su parte UDP, es conocido que es un protocolo sin estado por naturaleza, PF, también tiene la capacidad de manejar estados en conexiones UDP, ¿como lo consigue?. Las conexiones solo conocen dos pseudo estados, START y STOP, PF añade a esto un tiempo de expiración (acorde al nivel optimización seteado en el firewall), por lo cual mientras no haya expirado la conexión el paquete no va a tener que pasar por las reglas de filtrado, sino que simplemente se va a realizar una búsqueda en la tabla de estados.
Es importante conocer que para poder manejar esto, el tiempo de expiración se va a ir incrementando gradualmente a medida que lleguen paquetes que formen parte de la misma conexión hasta alcanzar su tope máximo. De esta manera se evitan que múltiples estados UDP sean creados y queden muertos a la espera de nuevos paquetes.

Los paquetes ICMP se dividen en dos categorías, ICMP-error e ICMP-querys (por ejemplo echo request/echo reply o más conocido como ping). Ambos tipos tienen la posibilidad de crear estados y ser manejados por el firewall, por ejemplo, si llega un ICMP-error al firewall, que es parte de una conexión existente, este matchea en la tabla de estados y puede pasar para notificar a la aplicación de que un error ocurrió. Lo mismo se aplica con los ICMP-querys.

Las posibles formas de mantener estados de PF, son las siguientes:

keep state: Trabaja con TCP, UDP e ICMP, es el default en las reglas de filtrado.
modulate state: Trabaja solo con TCP, recalcula el ISN.
synproxy state: Crea un proxy SYN para las conexiones TCP entrantes a fin de evitar conexiones spoofeadas. Combina las ventajas de modulate state y keep state.
non state: Funciona con TCP, UDP e ICMP. Ningún estado es creado.

El costo de evaluación de reglas de firewall puede ser calculado mediante O(n), donde n es el número total de reglas por las que debe pasar el paquete. Mientras que el costo de evaluación de la existencia de estados es O(log m), donde m es el número de estados. Mediante esto podemos concluir, que la evaluación de reglas tiene un coste parecido a la evaluación de estados.

Es interesante la posibilidad que tiene PF de crear TCP SYN Proxies (mediante synproxy state), de manera, si un cliente quiere contactar a un host remoto, le pasa un SYN al firewall, el firewall crea una entrada en la tabla de estados, y es el propio firewall el que inicializa el trheeway-handshake con el host remoto, pasandole la conexión una vez establecida al cliente. Con esto se busca evitar TCP Syn Floods que pueden terminar en DoS/DDoS.

Por su parte PF, también optimiza el conjunto de evaluación de reglas, mediante un algoritmo denominado skip-steps, el cual utiliza un puntero en cada parámetro de la regla apuntando a la siguiente regla a ser evaluada, que especifica un valor diferente para el parámetro; Si la regla no matchea con algún parámetro el puntero es utilizado para saltar a la siguiente regla que puede llegar a matchear. Esta optimización es totalmente transparente, debido a que no se modifica el ruleset, sino que se genera una estructura que simplemente mejora la performance del firewall, obviamente acorde a como esté escrito el ruleset cargado.

La performance de un firewall esta dada por varios factores, tanto de hardware como de software. Por parte del hardware, es determinante el tipo de NIC utilizada, el bus al que se conecta esta NIC (ISA/PCI/PCIe), la memoria. Pero paradojimanete, múltiples CPU's o cores no ayudan a PF, ya que únicamente trabaja con un solo procesador.

Por su lado, a nivel software, es factor determinante la complejidad con que fue configurado el ruleset, mientras mas complejo sea, más lento es. Por su parte, la utilización de la tabla de estados por parte de PF puede ser optimizado para actuar de diferentes formas; Esto puede ser establecido mediante el parámetro set, en el archivo /etc/pf.conf, como se muestra a continuación:

set ruleset-optimization aggresive

Las distintas optimizaciones posibles del ruleset pueden ser:

normal: Utilizable para la mayoría de las redes.
high-latency: Para redes de alta latencia, como conexiones satélitales.
aggresive: Expiración agresiva de conexiones de la tabla de estados, puede ayudar a reducir el uso de memoria en firewalls de alta carga, eliminando las conexiones inactivas.
conservative: Configuración extremadamente conservativa de recursos, puede aumentar la carga de la CPU debido al coste computacional utilizado para eliminar entradas de la tabla de estado.

El monitoreo de la tabla de estados, puede hacerse en tiempo real, de manera totalmente transparente, con herramientas disponibles tanto en packages como en ports, tales como pftop, o el propio pfctl ( pfctl -ss / pfctl -si), etc.

Los siguientes gráficos fueron extraidos del papper de Daniel Hartmeier "Design and Performance of the OpenBSD Stateful Packet Filter (pf)" y demuestran de manera clara y concisa lo expresado aquí. Las pruebas se basaron utilizando dos equipos 486, con dos NIC cada uno conectadas entre sí, un firewall utilizando PF, IPF e IPTables (de a uno por vez), y otro generando paquetes enviandolos a dicho Firewall. Como sistemas operativos se utilizaron OpenBSD 3.0 (Para PF tanto como para IPF), y Red Hat 7.2 con IPTables.

El primer test, se realiza el envío de paquetes de 256 bytes para un set de 100 reglas sin utilizar estados. La degradación de PF parece peor que la de IPTables y la de IPF.

En el segundo test se realiza la misma prueba con paquetes de 256 bytes, un set de 100 reglas y la utilización de estados. IPTables gana incrementalmente a mayor número de paquetes este test.

En el tercer test se intenta obtener el throughput máximo incrementando el número de reglas. El test es ganado por iptabales, debido a que tanto PF como IPF tienen un doble esfuerzo debido al filtrado de reglas inicial, y la búsqueda en la tabla de estados (y la creación de un estado si este aún no existe).

El cuarto test, es una comparativa de filtrado y utilización de estados entre PF e IPF, se puede notar que el throughput de PF decae mucho después que el de IPF a medida que se incrementa el número de paquetes.

En el quinto test, se comparan las latencias entre PF e IPF, puede observarse que IPF tiene una latencia un poco más alta que la de PF a medida que se incrementa el número de paquetes.

Luego de esto, se puede concluir que la evaluación de reglas es bastante mas cara que la evaluación de estados. Durante los tests iniciales se nota que PF es bastante más lento evaluando reglas que IPF e IPTables, pero hace un triple trabajo, que es gradualmente menos costoso que el que realiza IPTables. La baja performance en estas pruebas es debida a la forma que PF utiliza para evaluar las reglas, lo que realiza tres veces por cada paquete que pasa por la interface de red. Dos veces para buscar reglas de scrubbing, que determinan la normalización IP y TCP, (cosa que netfilter no realiza de la mejor manera) y una vez para las reglas pass o block. Por lo cual, podemos determinar que evaluar reglas de filtrado, es mas caro computacionalmente, que la búsqueda de estados.

Mi punto a favor de los firewalls basados en estados.

Material de referencia:
Les recomiendo el siguiente material de lectura para ampliar lo expresado en este post.

Linux: Determine if a program is using TCPWrappers

2011-12-25T14:06:00.000-08:00

TCP Wrappers es un sistema de ACL's basado en hosts y redes, multiplataforma; Que permite o deniega la acceso a un demonio en un sistema a ciertos hosts o redes, Su configuración se realiza editando los archivos /etc/hosts.allow y /etc/hosts.deny mediante el host o las redes que queremos permitir o denegar y las claves ALL, LOCAL, UNKNOW, KNOW y PARANOID.

Que un demonio utilice TCP Wrappers significa que el mismo fue compilado y linkeado contra libwrap.so y podemos determinarlo simplemente haciendo uso de ldd. Por ejemplo, podemos ver que SSH utiliza TCP Wrappers:

# ldd $(which sshd) | grep libwrap
libwrap.so.0 => /lib64/libwrap.so.0 (0x00002aae2628b000)

Y que Apache (httpd) no:

# ldd $(which httpd) | grep libwrap
#

A raíz de esto podemos determinar las reglas a escribir cuando queremos permitir o denegar el acceso a un servicio desde una porción de red o host determinado.

Por ejemplo si queremos denegar el acceso a SSH, excepto desde la red 192.168.10.0/24 podemos escribir en /etc/hosts.deny la siguiente regla:

sshd: ALL EXCEPT 192.168.10.0/255.255.255.0

FreeBSD: Enabling ALTQ support for PF queues

2011-12-23T23:19:00.000-08:00

Hace unos días, en DC Solutions migramos en un cliente un Firewall que utilizaba FreeBSD/IPFilter, a FreeBSD/Packet Filter a fin de poder soportar queues para permitiri una priorización del tráfico VoIP y además aliviar el bug descrito en este post IPF NAT entry causes kernel crash. No voy a describir las ventajas de utilizar una tecnología como PF sobre IPF, sino que solo voy a comentarles como darle soporte a las queues dentro del kernel de FreeBSD, el cual no se encuentra soportado dentro del kernel instalado con el sistema operativo.

Al intentar levantar las reglas de PF si no hay soporte a ALTQ en el kernel se puede encontrar el siguiente mensaje de error:

No ALTQ support in kernel
ALTQ related functions disabled

Como primer punto, debemos tener las fuentes del kernel instaladas en el equipo, para ello pueden utilizar sysinstall (como describo en la primera parte de este post), y así tenerlas instaladas bajo /usr/src.

Una vez instaladas procedemos a modificar el archivo de configuración del kernel, que debería encontrarse en /usr/src/sys/$(uname -m)/conf/GENERIC. Lo que debemos hacer es copiar dicho archivo con un nuevo nombre, por ejemplo FIREWALL:

# cp /usr/src/$(uname -m)/conf/GENERIC /usr/src/$(uname -m)/conf/FIREWALL

Y procedemos a parchear el archivo de configuración FILE, modificando la línea ident y añadiendo las siguientes líneas del tipo options, para dar soporte a los queues y sus diferentes tipos:

------ BEGIN ALTQ.patch ------
24c24
< ident GENERIC
---
> ident FIREWALL 78a79,87
> # Altq Support - added by FMDLC
> options ALTQ
> options ALTQ_CBQ
> options ALTQ_RED
> options ALTQ_RIO
> options ALTQ_HFSC
> options ALTQ_CDNR
> options ALTQ_PRIQ
>
------ EOF ALTQ.patch ------

# patch -p0 /usr/src/$(uname -m)/conf/FIREWALL < /tmp/ALTQ.patch

Luego procedemos a recompilar el kernel indicandole la ubicación de el nuevo archivo de configuración.

# cd /usr/src
# make buildkernel KERNCONF=FIREWALL

Una vez compilado procedemos a instalarlo y rebootear el equipo.

# make installkernel KERNCONF=FIREWALL && reboot

Una vez booteado el nuevo kernel podemos hacer el pfctl sin errores:

# kldload pf && pfctl -e -Fa -f /etc/pf.conf
rules cleared
nat cleared
2 tables deleted.
altq cleared
0 states cleared
source tracking entries cleared
pf: statistics cleared
pf: interface flags reset
pfctl: pf already enabled

HP-UX: Working with SAN LUN's and LVM

2011-11-30T12:31:00.001-08:00

Las redes de storage se integran cada día más como una de las tecnologías que mas fuertemente se utilizan en los datacenters. HP-UX si bien es un OS horrible (a gusto personal), sigue teniendo gran repercusión en entornos enterprise. Muchos de estos equipos trabajan con LUN's exportadas desde un storage, como puede ser un HP EVA y más de una vez se me ha hecho necesario trabajar con ellas. En este texto, voy a comentarles como reescanear las LUN's exportadas (partiendo desde el principio que el equipo tiene una HBA), y como crear Physical Volumes, Volumen Groups y Logical Volumes con estas en HP-UX 11.31.

Como consejo, si la LUN que queremos presentarle al server, es demasiado grande, y tenemos la intención de crear un solo LV con ella, es recomendable elegir un tamaño grande de LE, >= 8, o mas conveniente aún (para futuros resizes) >= 16, aunque esto puede impactar en la performance del filesystem creado en ella dependiendo el tipo de datos que contengamos. Si utilizamos tamaños chicos de LE (4 Mb.) y la LUN es demasiado grande, superaremos el límite establecido por el OS de LE máximos por LV y tendremos problemas (lo digo por experiencia :-P). Comenzemos:

Como primera medida, tenemos que tener las LUN creadas y presentadas en el storage (suponiendo que estamos utilizando FCoE o FC-SW). Una vez que esto es realizado, procedemos a reescanear las LUN's que ve el equipo con ioscan:

# ioscan -funC disk

Class I H/W Path Driver S/W State H/W Type Description
===============================================================================
disk 1 0/0/2/1.0.16 UsbScsiAdaptor CLAIMED DEVICE USB SCSI Stack Adaptor
/dev/deviceFileSystem/Usb/MassStorage/dsk/disk@hp-1008+294=A60020000001
/dev/deviceFileSystem/Usb/MassStorage/rdsk/disk@hp-1008+294=A60020000001
disk 2 0/1/1/0.0.0.0.0 sdisk CLAIMED DEVICE HP DG072BB975
/dev/dsk/c0t0d0 /dev/dsk/c0t0d0s2 /dev/rdsk/c0t0d0 /dev/rdsk/c0t0d0s2
/dev/dsk/c0t0d0s1 /dev/dsk/c0t0d0s3 /dev/rdsk/c0t0d0s1 /dev/rdsk/c0t0d0s3
disk 3 0/1/1/0.0.0.1.0 sdisk CLAIMED DEVICE HP DG072BB975
/dev/dsk/c0t1d0 /dev/dsk/c0t1d0s2 /dev/rdsk/c0t1d0 /dev/rdsk/c0t1d0s2
/dev/dsk/c0t1d0s1 /dev/dsk/c0t1d0s3 /dev/rdsk/c0t1d0s1 /dev/rdsk/c0t1d0s3
disk 37 0/2/1/0.2.0.0.0.0.1 sdisk CLAIMED DEVICE HP HSV200
/dev/dsk/c12t0d1 /dev/rdsk/c12t0d1
disk 39 0/2/1/0.2.0.0.0.0.3 sdisk CLAIMED DEVICE HP HSV200
/dev/dsk/c12t0d3 /dev/rdsk/c12t0d3
disk 40 0/2/1/0.2.0.0.0.0.5 sdisk CLAIMED DEVICE HP HSV200
/dev/dsk/c12t0d5 /dev/rdsk/c12t0d5
disk 33 0/2/1/0.2.4.0.0.0.1 sdisk CLAIMED DEVICE HP HSV200

Bien, ya tenemos todo reescaneado, notesé que por cuestiones de comodidad de lectura acorte la salida que es muchísimo más larga y así de desprolija. Ahora tenemos que crear las entradas correspondientes en /dev/disk/, de la siguiente forma:

# insf -e

Ahora es posible que necesitemos identificar, los discos exportados, por lo cual podemos hacer esto mediante su WWN o World Wide Name, de la siguiente manera:

# scsimgr -p get_attr all_lun -a device_file -a wwid -a state
/dev/rdisk/disk20:0x600508b40006d93d0000c000001c0000:ONLINE
/dev/rdisk/disk21:0x600508b40006d93d0000c00000170000:ONLINE
/dev/rdisk/disk22:0x600508b40006d93d0000c00000210000:ONLINE

En este caso vemos que disk20, disk21, y disk22 son las LUNs, y podemos revisar en el storage su WWN para identificar cual es cada una.

Si queremos escanear los adaptadores de Fiber Channel, hacemos:

# ioscan -fnC fc

En cambio si necesitamos consultar los WWN de las HBA's, podemos hacer:

# fcmsutil /dev/fcd0

Ahora procederemos a trabajar con LVM, para ello, podemos utilizar SAM (o SMH) o hacerlo directamente desde la línea de comandos, nosotros elegimos esta última. Lo primero es inicializar a los discos como PV, para ello utilizaremos pvcreate:

# pvcreate /dev/dsk/dsk{20,21,22}

Una vez creados los PV, vamos a crear el VolumenGroup que se va a llamar vgfoobar, para ello, tal como en Linux, vamos a utilizar vgcreate:

# vgcreate vgfoobar /dev/dsk/disk{20,21,22}

Si esto falla, probablemente necesitemos preparar el device file en /dev, de la siguiente forma

# mkdir /dev/vgfoobar/

# cd /dev/vgfoobar/

# mknod group c 64 0x010000

Ahora ya estamos en condiciones de crear los LV que hagan falta, una de las cosas que suckea de LVM en HP-UX es que tenemos que especificarle la capacidad de los LV en Mb o LE. Por lo cual por cuestiones de redondeo nosotros crearemos uno de 10.000 Mb.

# lvcreate -n lvexample -L 10000 vgfoobar

Y listo ya tenemos nuestro LV creado, podremos crear todos los que hagan falta. Ahora solo nos queda darle formato, en este caso bajo VxFS:

# newfs -F vxfs /dev/vgfoobar/lvexample

Nuestro LV debería montar en /mnt, en caso de elegir otro mountpoint debemos crearlo previamente (con mkdir), caso contrario, procedemos a montarlo directamente:

# mount /dev/vgfoobar/lvexample /mnt

Si queremos que persista a los reboots, debemos agregarlo al /etc/fstab como se muestra a continuación:

/dev/vgfoobar/lvexample /mnt vxfs delaylog 0 2

Linux: Enabling LVM devices from live CD.

2011-11-29T21:40:00.001-08:00

Hoy en mi trabajo tuve que resizear un volumen group donde se encontraba como LV el root filesystem (/) de un equipo con CentOS 5.4. Esta tarea no puede ser realizada en caliente, ya que consistía en reducir de 1.5 Tb. a 300 Gb. el volumen lógico del root filesystem (LVRoot) para después reducir el Volumen Group (VolGroup00).

Uno de los problemas con que es común encontrarse es que toda la metadata de LVM esta disponible, por ejemplo utilizando pvdisplay, vgdisplay y lvdisplay; Pero en /dev no tenemos las entradas correspondientes al device mapper creadas (/dev/mapper/VolGroup00 y /dev/VolGroup00).
Los pasos a seguir son los siguientes:

En primer lugar debemos bootear el equipo con algún LiveCD, para este caso yo usé el de ArchLinux.
Una vez booteado el equipo, procedemos a hacer el pvscan para identificar todos los physical devices:

#: pvscan
PV /dev/sda2 VG VolGroup00 lvm2 [1.55 TB / 0 free]
Total: 1 [1.55 TB] / in use: 1 [1.55 TB] / in no VG: 0 [0]

Y luego el vgscan:

#: vgscan
Reading all physical volumes. This may take a while...
Found volume group "VolGroup00" using metadata type lvm2

Una véz identificados tenemos que cambiar el estado del VolGroup00 a active, esto nos creara las entradas correspondientes en el /dev

#: vgchange -a y VolGroup00
/proc/misc: No entry for device-mapper found Is device-mapper driver missing from kernel?
Failure to communicate with kernel device-mapper driver.
0 logical volume(s) in volume group "VolGroup00" now active

Pero como vemos, esto falla, lo que está sucediendo es que no tenemos cargados los módulos de device-mapper, por lo cual debemos cargarlos manualmente.

#: modprobe -l | grep dm-
/lib/modules/2.6.18-238.5.1.el5/kernel/drivers/md/dm-crypt.ko
/lib/modules/2.6.18-238.5.1.el5/kernel/drivers/md/dm-mirror.ko
/lib/modules/2.6.18-238.5.1.el5/kernel/drivers/md/dm-mod.ko
/lib/modules/2.6.18-238.5.1.el5/kernel/drivers/md/dm-multipath.ko
/lib/modules/2.6.18-238.5.1.el5/kernel/drivers/md/dm-snapshot.ko
#: modprobe dm-mod
#: modprobe dm-snapshot

Y ahora si repetimos el vgchange esto va a funcionar, y las entradas correspondientes en /dev van a ser creadas, para así poder trabajar:

#: vgchange -a y VolGroup00
6 logical volume(s) in volume group "VolGroup00" now active

Linux: Connection tracking with FTP and IPTables

2011-11-10T21:27:00.001-08:00

Uno de los problemas más comunes con que se puede encontrar un admin utilizando IPTables es a la hora de levantar un servidor FTP (como por ejemplo vsftpd). El cliente puede conectar al servidor, pero no puede realizar ninguna operación en el (como listar, o transferir archivos). FTP por general utiliza dos puertos, el TCP/20 para datos y el TCP/21 para comandos; Aunque no siempre es de esa forma, sobre todo si se está detrás de un firewall.

El modo activo:

El cliente se conecta desde un puerto no privilegiado (N >1023) al puerto de control del servidor (21).
El cliente comienza a escuchar el puerto N + 1.
El servidor se conectará al puerto N + 1 desde su puerto de datos (TCP/20).
El cliente responderá con un ACK al servidor.

El modo pasivo:

El cliente abre dos puertos aleatorios ( N > 1023 y N + 1).
El primer puerto (utilizado para control) se conecta al puerto 21 del servidor y envía el comando PASV.
Luego el servidor abre un puerto no privilegiado ( P > 1023 ) y envía PORT P al cliente.
El cliente inicia una conexión desde el puerto N + 1 al puerto P del servidor para transferir datos.

Como notaran, hacer un seguimiento de los estados de las conexiones es una tarea complicada, si solamente queremos mantener abierto el puerto 21 para todas las conexiones entrantes, y no abrir rangos de puertos innecesarios podemos hacer uso del connection_tracking de Netfilter.

Bien sabemos que las conexiones pueden tener diferentes estados (podemos verlo en la salida de netstat):

NEW: Un cliente intentando establecer una nueva conexión.
ESTABLISHED: Una conexión ya establecida.
RELATED: Una conexión haciendo un nuevo request pero que ya es parte de otra conexión establecida.
INVALID: Si no es ninguno de los tres estados anteriores, la conexión es invalida.

Desde kernels 2.4 connection_tracking es la habilidad que tiene Netfilter de mantener los estados de la conexión en memoria y recordar los estados de las conexiones como ESTABLISHED & NEW, como así también direcciones de origen y destino, como puertos.

Primero que nada debemos añadir la regla de IPTables necesaria para esto:

-A INPUT -m state --state NEW,ESTABLISHED,RELATED --dport 21 -j ACCEPT

Para poder realizar el connection_tracking y evitar incluir múltiples reglas de firewall, podemos hacerlo utilizando dos módulos del kernel:

# modprobe ip_conntrack
# modprobe ip_conntrack_ftp

O podemos añadir esto de manera definitiva creando el archivo /etc/modprobe.d/conntrack.conf, con el siguiente contenido:

alias conntrack ip_conntrack_ftp
alias conntrack_ftp ip_conntrack_ftp

FreeBSD: Supporting DTrace

2011-11-10T17:05:00.001-08:00

Hace unos días en marco del BSDDay 2011 asistí a una charla de Fer Gleiser donde explicaba el uso de una herramienta increible como es DTracre. Así que partiendo de que tengo un FreeBSD instalado en mi notebook personal, decidí comenzar a aprender esta nueva herramienta.

Como primera medida, es necesario tener instaladas las fuentes del kernel, por lo que para hacer esto, es necesario ejecutar sysinstall

Luego ingresar en Configure, seleccionar Distributions:

Seleccionamos SRC:

Y finalmente sys, ya que base se encuentra instado por default:

Una vez hecho esto damos OK, y comenzara a descomprimir las fuentes del kernel en /etc/src/sys

Una vez que este proceso está terminado, procedemos a compilar el kernel, al cual debemos modificarle algunos parámetros.

En mi caso tengo instalado FreeBSD 8.2 sobre 64 bits, por lo cual debo editar su pertinente archivo de configuración que se encuentra en /usr/src/sys/amd64/conf/GENERIC seteando los siguientes parámetros:

options KDTRACE_HOOKS
options DDB_CTFmake
options DEBUG="-g"

makeoptions WITH_CTF=1

Guardamos el archivo de configuración bajo el nombre de DTRACE en el mismo directorio y procedemos a compilar el kernel.

# make buildkernel KERNCONF=DTRACE
# make installkernel KERNCONF=DTRACE
# shutdown -r NOW

Una vez listo esto, y rebooteado el sistema, procedemos a cargar y verificar que los módulos de DTrace se encuentren funcionando

# kldload dtraceall# kldstat | grep dtrace
0xffffffff81022000 396 dtraceall.ko
0xffffffff81028000 131460 dtrace.ko

Ahora necesitamos setear unos parámetros en el /etc/make.conf para que el nuevo software compilado no sea strippeado y ademas sea compilado con -f-no-omit-frame-pointer, para de esta manera mantener un registro de la posición del frame pointer, este es un registro de la CPU, que mantiene un record de la dirección de memoria donde se encuentra el último dato añadido al stack utilizando el método LIFO (Last In - Firt Out) (RSP en arquitecturas x86_64 y ESP en arquitecturas i386). Si make.conf no existe en /etc, copiamos un ejemplo de el:

# cp /usr/share/examples/etc/make.conf /etc/

Y añadimos las siguientes líneas al final:

STRIP=CFLAGS+=-fno-omit-frame-pointer

Ahora, como paso opcional, podemos hacer un make buildworld. Lo primero es instalar cvsup:

# make search name=cvsup
Port: cvsup-16.1h_4
Path: /usr/ports/net/cvsup
Info: File distribution system optimized for CVS
Maint: bzeeb+freebsdports@zabbadoz.net
B-deps:
R-deps:
WWW: http://www.cvsup.org/

# cd /usr/port/net/cvsup && make install clean

Una vez listo, si tenemos instalado el sistema base al hacer el cvsup es posible que fallé con el siguiente mensaje de error:

cd: can't cd to /usr/src/usr.bin/make
*** Error code 2

Stop in /usr/src.
*** Error code 1

Stop in /usr/src.

Esto es debido a que el parámetro *default host del archivo de configuración de cvsup no se encuentra seteado, por lo cual reemplazamos este con la URI del mirror de que queremos descargar las fuentes:

# cp /usr/share/examples/cvsup/standard-supfile /root/standard-supfile
# vi /root/standard-supfile

Y modificamos el parámetro por la URI de un mirror de FreeBSD:

*default host=cvsup4.us.FreeBSD.org

Guardamos los cambios y procedemos a hacer el cvsup de la siguiente forma:

# cvsup /root/standard-supfile

Una vez listo ya podemos hacer el make buildworld de la siguiente manera:

# make WITH_CTF=1 buildworld
# shutdown -r NOW

Booteamos en single-user y ahora procedemos a instalar:

# boot -s
# make installworld

Listo, ya tenemos nuestr kernel y nuestro entorno con soporte a DTrace, ahora solo resta instalar el userland de la siguiente manera:

# cd /usr/ports/sysutils/DTraceToolkit/ && make install clean

Ahora si, ya podemos hacer uso de DTrace en nuestro sistema.

PoC: Playing with the ZFS compression

2011-11-08T21:00:00.000-08:00

Como muchos sabrán, ZFS o ZettaByte filesystem es un sistema de 128 bits archivos diseñado por los ingenieros de Sun Microsystems para ser realmente grande, Jeff Bonwick, el arquitecto jefe de Sun para ZFS, dijo "Llenar un sistema de archivos de 128 bits excedería los límites cuánticos de almacenamiento de la Tierra. No puedes rellenarlo sin hervir los océanos". Una de las ventajas prácticas de ZFS es que integra el volume manager y el filesystem en un solo toolkit.

En este post, trataré de hacer una prueba de conceptos sobre uno de los features más interesantes que tiene ZFS, que es la compresión. Actualmente vivimos en una época en que el storage es un recurso barato, y el sentido de usar esta es mejorar de manera considerable el I/O del dataset, el dato al estar compreso ocupa menos, por lo cual se tienen que leer y escribir datos mas pequeños en el disco lo cual reduce la taza de I/O pero aumenta gradualmente la carga de las CPU's del equipo.

Para este ejemplo sobre FreeBSD 8.2 64 bits vamos a crear filedisks, iniciando un pool de discos con mdadm.
Vamos manos a la obra:

Como primera medida, vamos a darle soporte a ZFS en el sistema operativo (FreeBSD por default lo deshabilita), para ello tenemos que añadir el parámetro vfs.zfs.prefetch_disable=0 en el /boot/loader.conf y rebootear el equipo.

tokyo # echo "vfs.zfs.prefetch_disable=0" > /boot/loader.conf
tokyo # reboot

Una vez hecho esto, vamos a crear los filedisk propiamente dichos, en este caso lo haremos en /tmp, y seran en total 5 con una capacidad de 200M cada uno (1GB en total de storage), lo que utilizando bloques de 1K, suman un total de 204800 bloques. Para ello utilizaremos dd. Repetimos lo siguiente para cada uno de los discos:

tokyo # dd if=/dev/urandom of=/tmp/disk1 bs=1k count=204800
204800+0 records in
204800+0 records out
209715200 bytes transferred in 4.909060 secs (42720032 bytes/sec)

Una vez listos los cinco filedisks, vamos a crear el pool usando mdadm, el parámetro -a hace un add del device dentro del pool, el parámetro -t indica el tipo de device (vnode: en este caso el filedisk), el parámetro -f indica la localización en el filesystem del vnode, y el parámetro -u el número de device a crear en /dev/.

tokyo # mdconfig -a -t vnode -f /tmp/disk1 -u 1
tokyo # mdconfig -a -t vnode -f /tmp/disk2 -u 2
tokyo # mdconfig -a -t vnode -f /tmp/disk3 -u 3
tokyo # mdconfig -a -t vnode -f /tmp/disk4 -u 4
tokyo # mdconfig -a -t vnode -f /tmp/disk5 -u 5

Esto nos creara las correspondientes entradas de block devices bajo el nombre de /dev/mdX siendo X un número comprendido entre 1 y 5 correspondiente a los devices que inicializamos.

Actualmente ya contamos todos los elementos para comenzar. Lo primero que debemos hacer una vez que tenemos todo listo es crear un pool de ZFS, en este caso vamos a hacerlo utilizando RAIDZ 2; raidz es un esquema de redundancia integrada especial utilizado por ZFS, que es parecido a RAID 5 utilizando un stripe variable, esto es debido a que lo maneja el propio filesystem. RAIDZ 2 añade un bloque extra de paridad para dar aún mayor redundancia de datos. Creamos nuestro pool (llamado "foobar") indicándole los devices que estarán en el:

tokyo # zpool create foobar raidz2 /dev/md{1,2,3,4,5}

Podemos verificar que todo fue creado de manera correcta utilizando zpool status:

tokyo # zpool status
pool: foobar
state: ONLINE
scrub: none requested
config:
NAME STATE READ WRITE CKSUM
foobar ONLINE 0 0 0
raidz2 ONLINE 0 0 0
md1 ONLINE 0 0 0
md2 ONLINE 0 0 0
md3 ONLINE 0 0 0
md4 ONLINE 0 0 0
md5 ONLINE 0 0 0
errors: No known data errors

Bien, ahora procederemos a crear los filesystems utilizando los dos tipos de compresión soportados por ZFS: lzjb y gzip. En este ejemplo crearemos primero un filesystem sin compresión para poder diferenciar entre el uso de esta y el no uso. Para especificar la algoritmo de compresión a utilizar debemos pasarle con -o el parámetro compression=<lzjb|gzip-0-9|off>.

tokyo # zfs create -o compression=off foobar/filesystem1
tokyo # zfs create -o compression=lzjb foobar/filesystem2
tokyo # zfs create -o compression=gzip-9 foobar/filesystem3

En este caso, creamos los 3 filesystems. El primero (filesystem1) sin utilizar compresión alguna, el segundo (filesystem2) utilizando lzjb y el tercero (filesystem3) utilizando gzip un ratio de 9 (mayor compresión posible).

Estos ya se encuentran montados y dentro del directorio /foobar (el nombre del pool) y no necesitan ser añadidos al /etc/fstab (FreeBSD) o /etc/vfstab (en el caso de Solaris).

Podemos comprobar la correcta creación de los mismos haciendo un zfs list:

tokyo # zfs list
NAME USED AVAIL REFER MOUNTPOINT
foobar 281K 549M 42.9K /foobar
foobar/filesystem1 37.5K 549M 37.5K /foobar/filesystem1
foobar/filesystem2 37.5K 549M 37.5K /foobar/filesystem2
foobar/filesystem3 37.5K 549M 37.5K /foobar/filesystem3

En el directorio /tmp, cuento con un archivo llamado foobar.tar de unos 56Mb, vamos a copiar este a los tres filesystem que acabamos de crear para ver como se comportan:

tokyo # du -sh /tmp/foobar.tar
56M foobar.tar
tokyo # cp foobar.tar /foobar/filesystem1/
tokyo # cp foobar.tar /foobar/filesystem2/
tokyo # cp foobar.tar /foobar/filesystem3/

Una vez listo esto, podemos mirar cuanto pesa cada filesystem con el mismo archivo copiado en cada uno.

tokyo # du -sh /foobar/filesystem{1,2,3}
56M /foobar/filesystem1
18M /foobar/filesystem2
7.1M /foobar/filesystem3

En el primer caso, sin compresión el filesystem pesa exactamente el tamaño del archivo foobar.tar 56M, en el segundo caso utilizando lzjb, pesa 18M (38M menos), y en el tercer caso utilizando gzip con un ratio de compresión de 9, el mismo pesa solo 7.1M (48.9M menos).

Ahora saquen sus propias conclusiones sobre uno de los increibles features con los que cuenta ZFS!.

Linux: Recovering a corrupt superblock

2011-11-07T15:20:00.000-08:00

Una de las estructuras más básicas del filesystem son los bloques. Estos pueden ser utilizados para dos propósitos: El primero de ellos guardar datos, el segundo almacenar metadata que referencien a dichos datos.

En otras palabras, la metadata, describe la estructura del filesystem como así también sus atributos.
Existe un bloque muy importante en los filesystem denominado superblock, este bloque contiene toda la información referida a dicho sistema de archivos, y es en quien se fija el sistema a la hora de montarlo. Por ejemplo el contendrá la cantidad de inodos, los grupos de bloques, el tipo del filesystem, el estado, el tamaño, etc. Su ubicación varía dependiendo del tamaño de bloque usado, por default este tamaño es de 1024 bytes, pero esto varía entre 2048, o 4096.

Al momento de crearse el filesystem, se guardan varias copias de este superblock primario en distintos grupos de bloques, que pueden ser accedidas para su posterior recuperación en caso de que el mismo se corrompa. El comando dumpe2fs puede ayudarnos con esto, localizando donde se encuentran almacenados los distintos backups de el superblock:

# dumpe2fs /dev/sda1 | grep -i Backup
dumpe2fs 1.41.14 (22-Dec-2010)
Journal backup: inode blocks
Backup superblock at 32768, Group descriptors at 32769-32769
Backup superblock at 98304, Group descriptors at 98305-98305
Backup superblock at 163840, Group descriptors at 163841-163841
Backup superblock at 229376, Group descriptors at 229377-229377

En este caso vemos que existen backups de dicho superblock en los bloques 32768, 98304, 163840 y 229376, por lo cual, como dijimos si este superblock se corrompe podemos recuperarlo de manera relativamente sencilla.
Para ello, booteamos con singleuser (en el caso de que sea el root filesystem el que se corrompio), y con el filesystem desmontado hacemos fsck. elijiendo alguna copía de dicho superblock para restaurar:

# e2fsck -f -b 98304 /dev/sda1

Una vez que esto termine, podemos rebootear nuestro sistema y tendremos nuestro superblock recuperado.

Red Hat / CentOS: Running Apache with SELinux on a nonstandard port

2011-11-06T11:47:00.000-08:00

En el post anterior explique los fundamentos para hacer correr SELinux con enforcing en virtualhosts fuera del directorio /var/www.
Ahora supongamos que queremos ejecutar también utilizando SELinux en enforcing Apache en un puerto diferente al 80, por ejemplo el 1080. Sabemos que utilizando un puerto menor a 1023 debemos utilizar root para poder iniciar httpd.

Lo primero que debemos hacer es cambiar la configuración del puerto en el archivo /etc/httpd/conf/httpd.conf.

# sed -i 's/Listen\ 80/Listen\ 1080/g' /etc/httpd/conf/httpd.conf

Verificamos el modo de SELinux, y nos encontramos que estamos en Enforcing:

# getenforce
1

Ahora si queremos iniciar Apache, este va a fallar, ya que el puerto 1080 no esta permitido por SELinux para escuchar conexiones de httpd. Por lo cual con el paquete policycoreutils-python previamente instalado hacemos uso de semanage:

# semange port -a -t http_port_t -p tcp 1080

Con esto permitimos que httpd pueda escuchar en el puerto 1080. Ahora si verificamos con semanage port -l vemos que el puerto 1080 se lista:

# semanage port -l
http_cache_port_t tcp 8080, 8118, 8123, 10001-10010
http_cache_port_t udp 3130
http_port_t tcp 80, 443, 488, 8008, 8009, 8443, 1080
pegasus_http_port_t tcp 5988
pegasus_https_port_t tcp 5989

Si reiniciamos el servicio httpd vamos a ver que este levanta correctamente y ya podemos utilizar Apache en un puerto diferente.

Red Hat/CentOS: SELinux for Apache virtualhosts

2011-11-06T11:20:00.000-08:00

Sabemos que los virtualhost se utilizan para poder alojar en un mismo webserver, con una única IP, varios sitios webs. Muchos administradores de hosting que implementan esto sobre Red Hat o CentOS, al momento de la instalación desactivan SELinux para evitar conflictos de acceso a los distintos recursos del sistema.

SELinux por trabaja en dos modos, Enforcing, en el cual por default todo se deniega, y se permite acceso únicamente a lo que se explicitamente permitido, y Permissive, en lo cual por default todo se deniega, pero en vez de bloquear el acceso, simplemente notifica esto en los logs (/var/log/messages y /var/log/audit/audit.log) y debe ser utilizado solamente para testing.
Para verificar el estado de SELinux utilizamos el comando sestatus:

# sestatus
SELinux status: enabled
SELinuxfs mount: /selinux
Current mode: enforcing
Mode from config file: enforcing
Policy version: 26
Policy from config file: targeted

O mediante el comando getenforce:

# getenforce
Enforcing

Para cambiar de Enforcing a Permisive en tiempo real podemos utilizar setenforce:

# setenforce 0
# getenforce
Permissive
# setenforce 1
# getenforce
Enforcing

Si queremos saber como esta configurado en el sistema SELinux podemos revisar el archivo /etc/sysconfig/selinux que es un link simbólico hacia /etc/selinux/config:

# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
# enforcing - SELinux security policy is enforced.
# permissive - SELinux prints warnings instead of enforcing.
# disabled - SELinux is fully disabled.
SELINUX=enforcing
# SELINUXTYPE= type of policy in use. Possible values are:
# targeted - Only targeted network daemons are protected.
# strict - Full SELinux protection.
SELINUXTYPE=targeted

Cualquier modificación que hagamos en este archivo, requiere que reiniciemos el sistema para poder aplicar los cambios.

Un administrador, puede hacer uso de los directorios homes para contener los DocumentRoot de los usuarios, en un path que no es el originalmente permitido por SELinux (/var/www/), por lo cual debemos cambiar los permisos del mismo para poder acceder, veamos como hacer esto.

Una vez que httpd se encuentre instalado en el servidor, es importante definir los virtualhost en el archivo de configuración de Apache (Al final de /etc/httpd/conf/httpd.conf o añadirlos al directorio /etc/httpd/conf.d).
En este caso vamos a definir dos virutalhost, virtualhost-1 y virtualhost-2:

<VirtualHost ip.address.of.virtualhost-1>
ServerAdmin webmaster@virtualhost-1.com
DocumentRoot /home/user/www/virtualhost-1
ServerName virtualhost-1
ErrorLog logs/virtualhost-1-error_log
CustomLog logs/host.virtualhost-1-access_log common
</VirtuailHost>

<VirtualHost ip.address.of.virtualhost-2>
ServerAdmin webmaster@virtualhost-2.com
DocumentRoot /home/user/www/virtualhost-2
ServerName virtualhost-2
ErrorLog logs/virtualhost-2-error_log
CustomLog logs/host.virtualhost-2-access_log common
</VirtualHost>

Como vemos los DocumentRoot de ambos virtualhost no son los permitidos por SELinux (que intenta servir el contenido de /var/www o /srv), por lo cual al intentar acceder a los mismos vamos a obtener un error del tipo Forbidden, así que debemos permitirlos de manera explicita dentro de la policy de SELinux. Podemos verificar esto con semanage fcontext -l:

# semanage fcontext -l | grep httpd_
/var/www(/.*)? all files system_u:object_r:httpd_sys_content_t:s0
/var/www(/.*)?/logs(/.*)? all files system_u:object_r:httpd_log_t:s0
...

Por lo cual, lo que tenemos que hacer es cambiar el contexto de dichos directorios, y vamos a realizar esto de manera recursiva para que afecte a todos los archivos que se encuentran en su interior. Para esto vamos a utilizar el comando chcon.

# chcon -R -v -u system_u -r object_r -t httpd_sys_content_t /home/user/www/virtualhost-{1,2}

El parámetro -R hace esto recursivo, -v es verbose, con -u se especifica el usuario (system_u), con -r se especifica el rol, y con -t el tipo, que para que caso de httpd es httpd_sys_content_t.
Otra forma de lograr el mismo resultado es por referencia, esto es, pasandole como tal un directorio que tenga el contexto previamente configurado. Para esto utilizamos el parámetro --reference:

# chcon -R -v --reference=/var/www/html /home/user/www/virtualhost-{1,2}

Ahora, nuestra configuración persistirá a través de reboots, pero no soportaría un releabel (restorecon), por lo cual debemos commitear dichos cambios a la policy. Por lo cual, para esto, vamos a utilizar semange, dicho comando no se encuentra instalado por default en RHEL 6/CentOS 6, por lo cual debemos instalar el paquete policycoreutils-python mediante yum o rpm.

# semanage fcontext -a -t httpd_sys_content_t "/home/user/www/virtualhost-1(/.*)?"
# semanage fcontext -a -t httpd_sys_content_t "/home/user/www/virtualhost-2(/.*)?"

Ahora si hacemos un restorecon sobre los DocumentRoot de nuestros virtualhost vemos que soportan el relabel:

# restorecon -R -v /home/user/www/
# ls -Z /home/user/virtualhost-{1,2}
drwx------. root root system_u:object_r:httpd_sys_content_t:s0 virtualhost-1
drwx------. root root system_u:object_r:httpd_sys_content_t:s0 virtualhost-2

Pero esto todavía tiene una vuelta de tuerca más, para permitir el acceso de SELinux a la home, tenemos que modificar el valor de un booleano.

Para listar los booleanos, se pueden utilizar dos comandos, uno es getsebool y el otro, semanage, vamos a utilizar el segundo, ya que este nos provee además una breve descripción de lo que hace cada booleano:

# semanage boolean -l | grep httpd
httpd_can_network_relay -> off Allow httpd to act as a relay
httpd_can_network_connect_db -> off Allow HTTPD scripts and modules to connect to databases.
httpd_enable_homedirs -> off Allow httpd to read home directories
...

El booleano que nos interesa es httpd_enable_homedirs, como cualquier booleano, tiene dos posibles valores, true o false, en este caso vemos que esta seteado en off; Por lo cual, vamos a cambiarle su valor a on utilizando setsebool y el parámetro -P para que persista atravéz de los reboots del sistema:

# setsebool -P httpd_enable_homedirs 1

En caso de querer saber más acerca de la configuración de SELinux para cualquier deamon, es interesante ver las páginas de manual asociadas al mismo, para ello con man -k http | grep _selinux podemos listar estas:

# man -k httpd | grep _selinux

httpd_selinux (8) - Security Enhanced Linux Policy for the httpd daemon

Ahora si se reinicia el servicio httpd, se podrá acceder a los vitualhost creados, fuera del DocumentRoot que por default se habilita en SELinux.

Linux: Identifying a physical network interface card

2011-11-06T08:32:00.000-08:00

Hay momentos en los que es necesario identificar físicamente una interfaz de red, por ejemplo, cuando se debe cablear, o armar un bonding.

Esto suele ser una tarea bastante compleja cuando trabajamos con una cantidad grande de servidores y distintos modelos de ellos, ya que los dispositivos pueden ser nombrados de manera distinta, y donde en un servidor es eth0, puede ser eth1. Existe una herramienta muy útil en Linux, que se denomina ethtool.

Para identificar una NIC, podemos encender el LED de ella durante un determinado periodo de tiempo, y de esa manera identificarla fácilmente, para realizar esto la sintaxis es la siguiente:
ethtool -p <interface> <timeout>

Por ejemplo, si queremos encender el LED de la interáz eth1 durante 30 segundos hacemos:

#: ethtool -p eth1 30

Ahora si miramos la NIC, durante 30 segundos, tendra parpadeando su LED.
Otra manera de hacer esto, es enchufando la interfaz de red y determinar si tiene link o no.

#: ethtool eth1 | grep Link
Link detected: no

Cabe destacar que ethtool deja obsoleta a herramientas como mii-tool, que ya cumplieron su ciclo en GNU/Linux. Para más información sobre las múltiples features de ethtool, les recomiendo leer la manpage asociada al mismo.

The Sun OpenBoot architecture - Part I

2011-11-06T07:16:00.000-08:00

Todos los sistemas Sun tienen un firmware denominado PROM que le provee a los mismos las funciones básicas de testeo e inicialización del hardware del equipo. También desde el OpenBoot se puede identificar hardware de terceras partes y cargar drivers genéricos para hacer uso de estos dentro del sistema.
OpenBoot, se encuentra incluido en un chip denominado PROM, en el motherboard, y es la interfaz que se utiliza tanto para bootear un sistema, como para establecer parámetros sobre el funcionamiento del equipo, siendo especialmente útil durante el proceso de booteo, ya que el será el encargado de inicializar en SPARC, los distintos slides para inicializar el sistema.

Para conocer la versión del PROM que se encuentra instalada en el equipo, desde el sistema opeartivo (Solaris), ejecutamos lo siguiente:

#: prtconf -V
OBP 4.16.4 2004/12/18 05:21

Al inicializarse el sistema, se ingresa en una etapa denominada POST (Power On Self Test), en la cual se verifica y testea el hardware conectado al equipo, si todo se encuentra en parámetros normales de funcionamiento se continua con el proceso de booteo, en caso contrario, dependiendo de la severidad de la falla encontrada, o se muestra una alarma, o se interrumpe el booteo. Uno de los test que se realizan en el POST es verificar si se encuentra un teclado conectado (aunque puede ser también una consola serie), y si se envía una señal Stop - D (que puede ser un break en una consola serie).

Stop D: Si es se manda esta secuencia durante el booteo, este es interrumpido, y fuerza a OpenBoot a ingresar en modo de diagnostico.

Stop N: Setea los distintos parámetros alojados en la NVRAM a los valores por default.

Stop A: Aborta el sistema operativo.

A veces suele resultar útil deshabilitar la secuencia de escape Stop-A en el sistema operativo, y dejándola activa durante el booteo para realiar esto hacemos:

#: sed -i 's/KEYBOARD_ABORT\=disable/KEYBOARD_ABORT\=enable/g' /etc/default/kbd#: kbd -i

En el OK prompt, podemos identificar alguna información básica del sistema, es para ello que existe el comando banner, que nos mostrará el modelo del equipo, la versión del PROM, la cantidad de memoria física conectada al equipo, la dirección ethernet de la NIC que es utilizada en el PROM, y el ID del host.

ok bannerSun Ultra 5/10 UPA/PCI (UltraSPARC-IIi 360MHz), Keyboard PresentOpenBoot 3.31, 128 MB (50 ns) memory installed, Serial #11888271.Ethernet address 8:0:20:b5:66:8f, Host ID: 80b5668f.

Para bootear el sistema utilizamos el comando boot, si queremos bootear en single-user utilizamos el parámetro -s:

ok boot -s

Si queremos bootear desde un CD o DVD en single-user utilizamos los boot cdrom -s.:

ok boot cdrom -s

boot seguido del parámetro -a va a bootear el sistema de manera interactiva:

ok boot -a

Si queremos conocer los distintos parámetros alojados en la NVRAM, se utiliza printenv, por ejemplo:

ok printenv
Variable Name Value Default Value
tpe-link-test? true true
scsi-initiator-id 7 7
keyboard-click? false
...
ok printenv boot-device
boot-device = disk net

Si se necesita modificar alguno de estos valores, se utiliza setenv:

ok printenv auto-boot?
auto-boot? = true
ok
ok setenv auto-boot? false
auto-boot? = false

Con set-defaults, o set-defaults <parámetro> podemos resetear a su valor por defecto algún parámetro especifico alojado en la NVRAM.

Si lo que necesitamos es cambiar un parámetro desde el sistema operativo, utilizamos el comando eeprom, que ejecutandose solo listará todos los parámetros que podemos modificar. Cabe destacar que para poder hacer uso de este debemos ser root:

#: eeprom boot-deviceboot-device=disk
#: eeprom 'boot-device=disk2'

Para más información sobre el comando eeprom podemos consultar la manpage del mismo.
En siguientes post vamos a identificar el hardware de booteo, y crear alias de dispositivos.

Linux: The kernel SysRq and the SAK key.

2011-10-02T19:05:00.000-07:00

Muchos usuarios de Linux, no conocen la existencia de dos combinaciones de teclas que suelen resultar muy útiles a la hora de que un equipo no responda, o al momento de loguearse en uno.

SysRq key:
Cuando hablamos de kernel SysRq key, nos referimos a una combinación de teclas especial, la cual va a realizar que un equipo paniqueado, ocrasheado, sea capaz de responder, y poder rebootear de una manera un poco más suave que dandole el botonazo.

Para poder hacer uso y utilización de esta combinación de teclas, debemos previamente tener soporte a esta en la configuración del kernel, para ello buscamos, en el archivo config de este el siguiente string, que representa un valor booleano:

#: cat /boot/config-2.6.40.4-5.fc15.x86_64 | grep -i sysrq
CONFIG_MAGIC_SYSRQ=y

En este caso se encuentra soportado, en caso contrario, habría que recompilar el kernel, dandole soporte en dicha directiva de configuración.

En un sistema que soporte SysRq, debemos configurar si se permite realizar dicha sysrq mediante dos formas, una es mediante la sysctl kernel.sysrq, que tiene valor booleano, o la otra, pasandole "1" al archivo /proc/sys/kernel/sysrq.

#: cat /proc/sys/kernel/sysrq
0
#: echo 1 > /proc/sys/kernel/sysrq

En muchas distribuciones de Linux, viene en el archivo /etc/sysctl.conf la directiva comentada, o puesta 0, el motivo de por que se deshabilita es que supongamos un server, al cual le hemos realizado hardening físico, bloqueando el acceso al BIOS, la posibilidad de bootear de medios secundarios, el acceso a GRUB mediante password, etc. Cualquier individuo que tenga acceso físico al equipo, y pueda conectar un teclado, o un KVM al mismo, podrá ejecutar dicha SysRq, comprometiendo la seguridad física del mismo. Así que esto debe ser utilizado con cautela.

Ahora bien, estudiemos esta SysRq en profundidad: El archivo /proc/sys/kernel/sysrq va a soportar diferentes posibles valores, acorde a lo que necesitemos tener soportado, ellos son (según la propia documentación del kernel):

0 - disable sysrq completely
1 - enable all functions of sysrq
>1 - bitmask of allowed sysrq functions (see below for detailed function
description):
2 - enable control of console logging level
4 - enable control of keyboard (SAK, unraw)
8 - enable debugging dumps of processes etc.
16 - enable sync command
32 - enable remount read-only
64 - enable signalling of processes (term, kill, oom-kill)
128 - allow reboot/poweroff
256 - allow nicing of all RT tasks

Como podemos utilizar la petición al sistema?:

En arquitecturas x86 o x86_64, podemos realizar esto utilizando Alt + SysRq + <command-key>, SysRq suele estar localizado donde se encuentra la tecla "Print Screen" y en algunas laptops es necesario acceder a esta mediante function.

En SPARC, es necesario utilizar ALT + STOP + < command-key>

En consolas serial, se envia una señal de BREAK, y dentro de los cinco segundos, las posibles <command-key>

O una forma alternativa, que funciona en cualquiera de estas antes mencionadas, escribiendo sobre el archivo /proc/sysrq-trigger. Como en Unix todo es un stream, lo que la SysRq hace, es escribirse sobre este archivo del directorio /proc/. Por ejemplo

#: echo t > /proc/sysrq-trigger

Cuales son las command-key?:

Según la documentación del kernel, son las siguientes,

'b' - Will immediately reboot the system without syncing or unmounting
your disks.

'c' - Will perform a system crash by a NULL pointer dereference.
A crashdump will be taken if configured.

'd' - Shows all locks that are held.

'e' - Send a SIGTERM to all processes, except for init.

'f' - Will call oom_kill to kill a memory hog process.

'g' - Used by kgdb (kernel debugger)

'h' - Will display help (actually any other key than those listed
here will display help. but 'h' is easy to remember :-)

'i' - Send a SIGKILL to all processes, except for init.

'j' - Forcibly "Just thaw it" - filesystems frozen by the FIFREEZE ioctl.

'k' - Secure Access Key (SAK) Kills all programs on the current virtual
console. NOTE: See important comments below in SAK section.

'l' - Shows a stack backtrace for all active CPUs.

'm' - Will dump current memory info to your console.

'n' - Used to make RT tasks nice-able

'o' - Will shut your system off (if configured and supported).

'p' - Will dump the current registers and flags to your console.

'q' - Will dump per CPU lists of all armed hrtimers (but NOT regular

timer_list timers) and detailed information about all

clockevent devices.

'r' - Turns off keyboard raw mode and sets it to XLATE.

's' - Will attempt to sync all mounted filesystems.

't' - Will dump a list of current tasks and their information to your

console.

'u' - Will attempt to remount all mounted filesystems read-only.

'v' - Forcefully restores framebuffer console

'v' - Causes ETM buffer dump [ARM-specific]

'w' - Dumps tasks that are in uninterruptable (blocked) state.

'x' - Used by xmon interface on ppc/powerpc platforms.

'y' - Show global CPU Registers [SPARC-64 specific]

'z' - Dump the ftrace buffer

'0'-'9' - Sets the console log level, controlling which kernel messages

will be printed to your console. ('0', for example would make

it so that only emergency messages like PANICs or OOPSes would

make it to your console.)

Si bien es casi imposible recordar esto, tenemos una bastante interesante: SysRq + ALT + H, que nos va a mostrar una pequeña ayuda sobre como debemos realizar esto, H, es más fácil de recordar.

En caso de tratar de memorizar una combinación podemos usar REISUB donde R pone el teclado en modo XLATE, E va a mandar SIGTERM (-15) a todos los procesos y hacer que estos terminen bien, con la I vamos a enviar SIGKILL (-9) en caso de que no terminen con el SIGTERM enviado anteriormente, S va a intentar hacer sync a los discos, de los datos que están actualmente en memoría y estaban encolados esperando para escribirse, U, va a intentar remontar todos los filesystems como read-only (ro), y B va a rebootear el sistema inmediatamente, sin matar los procesos y lo aún mas peligroso sin hacer sync a disco. Cabe destacar que tenemos que ir presionando esto de a una vez, ya que vamos probando alternativas hasta llegar a la última, y mas grave de ellas.

En caso de no funcionar esto, debemos mapear el keycode de SysRq, que tiene el valor 99 en KEY_SYSRQ en el archivo includes/linux/input.h. Podemos usar showkeys -s, para saber el keycode de la tecla correcto y mapearlo.

The SAK key:

SAK, significa Secure Attention Key, en teoría de sistemas operativos, esto es una herramienta de seguridad, que nos va a proveer protección contra software capaz de capturar un password al momento del login, como puede ser el caso de un rootkit o un troyano. SAK es una manera de matar todos los programas que pueden estar enmascarados como aplicaciones de login, y así proveer un ingreso seguro de password en el sistema.

La regla dice, que el usuario debe proveer esta combinación de teclas antes de ingresar sus datos de login, asi matar cualquier proceso que este corriendo, haciendose pasar por dicho programa de login, y proveer de manera segura esta clave.

En teclados del tipo PC, esta combinación de teclas se consigue presionando ALT + SysRq + K. En el caso de que se este corriendo un servidor gráfico bajo el runlvel 5, al presionar dicha combinación de teclas, el mismo va a ser cerrado y vuelto a abrir, En caso de que se este ejecutando este desde otro runlevel, (por ejemplo el 3), deberemos cargarlo a mano nuevamente.

Como podemos hacer uso y mapear SAK?

La manera correcta es hacerlo mediante loadkeys, es por eso, que podemos incluir en /etc/rc.sysinit o /etc/rc.local, la siguiente línea:

#: echo "control alt keycode 101 = SAK" | /bin/loadkeys

En este caso, debido a que CTRL + ALT + DEL se usa para rebootear el sistema, CTRL + BACKSPACE para reiniciar el servidor X, se eligió utilizar CTRL + ALT + PAUSE, para de esta manera tener SAK de manera más sencilla de utilizar y no enredar los dedos al intentar tipearla :-P

Si quieren aprender más respecto a esto, pueden leer la documentación del kernel que pueden encontrarla en /usr/share/doc/kernel-doc-$(uname -r)/Documentation, si es que se encuentra instalada, sino en RHEL/CentOS/Fedora pueden hacer instalar el paquete kernel-doc.

BIND: Update zone serial for zone trasfers

2011-09-13T16:28:00.000-07:00

Supongamos que tenemos un BIND, configurado como master de una zona y hacemos cambios en el archivo de la zona del mismo. Como se entera el DNS slave, que dichos cambios fueron modificados?. Fácil, el servidor que actúa como master, envía un hash al slave, del archivo de la zona, el slave lo recibe y compara con la copia que tiene el. Si el valor del hash es distinto, entonces inicia la transferencia de la zona.
Supongamos que nuestra configuración es la siguiente:

En el master:

zone "fakezone.net" {
type master;
allow-transfer { 192.168.0.2; };
file "master/fakezone.net";
};

En el slave:

zone "fakezone.net" {
type slave;
file "slaves/fakezone.net";
masters { 192.168.0.100; };
allow-notify { 192.168.0.100; };
};

Y la zona en si misma, al que le añadimos un CNAME de mail a www.

; From: @(#)localhost.rev 5.1 (Berkeley) 6/30/90
; $Id: PROTO.localhost.rev,v 1.1.6.1 1998/02/27 21:32:55 jkh Exp $
;
; This file is automatically edited by the `make-localhost' script in
; the /etc/namedb directory.
;
@ IN SOA root.fakezone.net. root.fakezone.net. (
20110909 ; Serial
3600 ; Refresh
900 ; Retry
3600000 ; Expire
3600 ) ; Minimum
IN MX 0 mail.fakezone.net.
IN NS mail.fakezone.net.
IN A 192.168.0.145
www IN A 192.168.0.201
mail IN CNAME www
localhost IN A 127.0.0.1

Para que el servidor SLAVE, reciba dicho cambio, debe modificarse el campo referenciando al serial, en la sección correspondiente a los registros SOA, con la fecha actual, reemplazando 20110909 por 20110912 (fecha de hoy). De esta manera la transferencia de zona se realizara correctamente, y los equipos que hagan consultas DNS contra el DNS slave, podrán utilizar este nuevo CNAME.

Sept 12 23:33:53 ns1 named[5064]: zone fakezone.net/IN: transferred serial 20110912
Sept 12 23:33:53 ns1 named[5064]: transfer of 'fakezone.net/IN' from 192.168.0.100#53: end of transfer

CentOS/Red Hat: Examining and building the initial ramdisk

2011-09-13T15:28:00.000-07:00

Como muchos de ustedes seguramente sabrán, al bootear un equipo, es necesario tener cargados ciertos módulos como el de la controladora de disco (ATA/SATA/SCSI), filesystems, manejo de memoria, entre otros, para de esta forma poder realizar la secuencia normal de booteo e inicio del sistema.

Pero, aquí entramos en el clásico problema "The Chicken/Egg problem". ¿Como el OS monta la rootfs, si aún no tiene cargado los módulos?. Es que para ello existe, mis queridos amigos el initial RAM disk, o mejor conocido como initrd. Un filesystem temporal, utilizado por el kernel, que al momento del booteo es cargado en /dev/ram0. El kernel utilizará en un principio dicho RAM disk, como rootfs, hasta que el kernel monte el rootfs real, y lo posicione como tal mediante la syscall pivot_root.
Esto se realiza, escribiendo el número del real rootfs en el archivo /proc/sys/kernel/real-root-dev. Un ejemplo de ello podría ser:

# echo 0x301 >/proc/sys/kernel/real-root-dev

Ustedes sabrán que dentro del kernel, los módulos pueden ser compilados, built-in, osea construidos dentro de este o en forma de modulo, siendo cargados a medida que se necesitan.
Construir un kernel, con todos los drivers necesarios buil-in, daría lugar a un kernel pesado, y mas lento. Es por ello que estos drivers esenciales, que deben cargarse en algún momento del booteo del equipo, deben ser incluido en el initial RAM disk.

En el archivo de configuración de nuestro cargador de inicio (GRUB en la mayoría de los casos), encontramos estas líneas:

title CentOS (2.6.18-194.el5)
root (hd0,0)
kernel /vmlinuz-2.6.18-194.el5 ro root=/dev/VolGroup00/LogVol00 rhgb quiet
initrd /initrd-2.6.18-194.el5.img

Nos detenemos en la línea initrd, esta línea le dice al gestor de arranque, de donde debe obtener dicho RAM disk. Este es un archivo comprimido generalmente con cpio y a la vez compreso con gzip, que contiene además de los módulos algunas otras cosas, como scripts, algunas configuraciones, como la de LVM, en caso de ser usado, entre otros.

El el primer caso, podemos comprobar que el RAM disk se encuentra compreso con gzip:

# file /boot/initrd-2.6.18-194.el5.img
/boot/initrd-2.6.18-194.el5.img: gzip compressed data, from Unix, last modified: Mon Jan 3 08:12:32 2011, max compression

Y a su vez, comprobar que el mismo también se encuentra comprimido con cpio:

# zcat /boot/initrd-2.6.18-194.el5.img | file -
/dev/stdin: ASCII cpio archive (SVR4 with no CRC)

Si queremos examinar el contenido del mismo, para buscar si esta incluido dicho módulo, obviamente que podemos hacerlo:

# zcat /boot/initrd-2.6.18-194.el5.img | cpio -itv
drwx------ 2 root root 0 Jan 3 2011 proc
-rwx------ 1 root root 2784 Jan 3 2011 init
drwx------ 2 root root 0 Jan 3 2011 sys
drwx------ 3 root root 0 Jan 3 2011 etc
drwx------ 2 root root 0 Jan 3 2011 etc/lvm
-rw------- 1 root root 1287 Jan 3 2011 etc/lvm/lvm.conf
drwx------ 2 root root 0 Jan 3 2011 sysroot
drwx------ 3 root root 0 Jan 3 2011 lib
-rw------- 1 root root 51760 Jan 3 2011 lib/dm-region_hash.ko
-rw------- 1 root root 134232 Jan 3 2011 lib/dm-mod.ko
-rw------- 1 root root 117024 Jan 3 2011 lib/dm-raid45.ko

En caso de necesitar dar soporte a algún módulo en especial, cosa común cuando hacemos cambios en el hardware, por ejemplo la controladora de discos, o algún cambio importante en el filesystem, debemos reconstruir el initial RAM disk, para ello podemos hacerlo de distintas maneras:

La primera de ella es utilizando el modificador mkinitrd con el modificador --with

#: mkinitrd --with=qla2300 /boot/initrd-$(uname -r)-qla2300.img $(uname -r)

Y podemos verificar esto, fijándonos si construyo el nuevo initrd en el directorio /boot

# ls -l /boot/initrd-2.6.18-*
-rw------- 1 root root 3439778 Mar 15 15:53 /boot/initrd-2.6.18-194.32.1.el5.img
-rw------- 1 root root 3432496 Jan 3 2011 /boot/initrd-2.6.18-194.el5.img
-rw------- 1 root root 3487257 Apr 12 08:03 /boot/initrd-2.6.18-238.5.1.el5.img
-rw------- 1 root root 3498999 Sep 13 19:22 /boot/initrd-2.6.18-238.5.1.el5-qla2300.img

La segunda de ellas es localizando un script en el directorio /etc/sysconfig/mkinitrd/

#: echo "MODULES="$MODULES qla2300" > /etc/sysconfig/mkinitrd/qla2300
#: chmod +x /etc/sysconfig/mkinitrd/qla2300
#: mkinitrd /boot/initrd-$(uname -r)-qla2300.img $(uname -r)

Y la tercera de ellas es añadiendo dicho módulo, como alias en el archivo /etc/modprobe.conf, para ello:

#: echo "alias scsi_hostadapter qla2300" >> /etc/modprobe.conf
#: mkinitrd /boot/initrd-$(uname -r)-qla2300.img $(uname -r)

AIX: Create an installable image of the root volume group using mksysb

2011-09-12T04:15:00.000-07:00

Utilizando AIX, pude ser útil tener una imagen instalable del root VG, para evitar perder tiempo, en caso de algún incidente, haciendo la reinstalación completa de todo el OS (que suele ser bastante tediosa y demorar muchas horas), para evitar esto, es que existe mksysb.

Supongamos que tenemos un volumen group llamado, como no puede ser de otro caso, rootvg, si queremos crear una imagen del mismo y localizarla en /var/tmp/mksysb/ haríamos:

#: mksysb -i /var/tmp/mksysb/rootvg-$(date +%Y%m%d).img

En caso de querer respaldar esta imagen en una unidad de cinta que se encuentra en /dev/rmt0 deberíamos hacer:

#: mksysb -i /dev/rmt0

Y si lo que necesitamos en generar la imagen de todo el rootvg, pero queremos excluir por ejemplo, el directorio /home/foobar, haríamos:

#: echo "/home/foobar" >> /etc/exclude.rootvg
#: mksysb -e -i /dev/rmt0

De esta manera, todas las líneas que se encuentren en el directorio /etc/exclude.rootvg serán excluidas al momento de generar la imagen.

Linux: Connect to a remote domain0 using virsh and SSH

2011-09-12T03:58:00.000-07:00

Es bastante común tener VM's hosteadas en un host remoto, al cual podemos acceder mediante Internet, o conectándonos a la LAN local. Sin importar cual fuera el caso, en Linux principalmente existen dos plataformas medianamente "nativas" de virtualización (ambas proveen full virtualización), ellas son Xen, que no es otra cosa que un parche al kernel de Linux, y KVM, que esta integrada como módulo dentro del mismo y para conectarnos, disponemos siempre de un protocolo excelente como es SSH.
Existe una interfaz de administración por linea de comandos denominada virsh, a la cual le indicamos el hypervisor al que queremos conectar y el protocolo a utilizar.

Supongamos que nos encontramos en un host remoto, como primera medida copiamos nuestra clave pública SSH utilizando por ejemplo ssh-copy-id, o agregándola al ~/.authorized_keys del host remoto, una vez hecho esto, dependiendo que usemos haríamos:

Usando KVM:

virsh -c qemu+ssh://username@foo.bar/system

Usando XEN:

virsh -c xen+ssh://username@foo.bar/system

Y listo, ya estamos conectados al hypervisor remoto!.

Welcome to virsh, the virtualization interactive terminal.
Type: 'help' for help with commands
'quit' to quit

virsh # list

Id Name State
----------------------------------
1 CentOS5DS.py running
3 Centos5DS2 running

virsh #

FreeBSD IPF: NAT duplicate entry causes kernel crash

2011-09-11T23:26:00.000-07:00

Hace algún tiempo, fui a ver un servidor, que bajo FreeBSD 7.2 actuaba como firewall utilizando IPFilter y hacia NAT entre otros equipos de la LAN interna. El mismo había tenido unos reinicios inesperados, sin saber el verdadero origen de los mismos. Esto de por si representaba un problema, ya que incrementaba el downtime del mismo, y debiendo a que el las particiones del OS se encontraban bajo UFS, podía corromper los filesystems y forzar a la ejecución de fsck entre reboot y reboot.

Al acceder al equipo, encuentro en /var/log/messages.1 que el equipo, había booteado a las 9:42 AM del día 4 de Diciembre, por lo cual fijandome en logs anteriores encontré que el mismo había entrado en panic, y que había generado el coredump: vmcore.8.

En el directorio /var/crash encuentro varios coredumps de periodos de tiempos comprendidos entre el año 2008 y 2011.

Por lo cual comienzo a debuggear el coredump generado (vmcore.8), con kgdb. Al ejecutar esto, me muestra la siguiente información:

Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address = 0x4
fault code = supervisor read, page not present
instruction pointer = 0x20:0xc33ac8ab
stack pointer = 0x28:0xc2f909bc
frame pointer = 0x28:0xc2f90a38
code segment = base 0x0, limit 0xfffff, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags = interrupt enabled, resume, IOPL = 0
current process = 21 (irq17: xl1)
trap number = 12
panic: page fault
cpuid = 0
Uptime: 11h41m30s
Physical memory: 499 MB
Dumping 83 MB: 68 52 36 20 4

#0 doadump () at pcpu.h:196
196 __asm __volatile("movl %%fs:0,%0" : "=r" (td));

Se puede apreciar que se intenta cargar una página de memoria, que parece no estar presente, o incorrectamente mapeada, por lo cual, el kernel crashea con page fault, ejecutando el trap 12.
En la línea current process, se encuentra que es en el IRQ 17, en lo que es la interfaz xl1 conectada al equipo. Al hacer ifconfig xl1, encontramos lo siguiente:

xl1: flags=8843 metric 0 mtu 1500
options=9
ether 00:10:4b:c6:65:3b
inet 190.122.08.91 netmask 0xfffffff8 broadcast 190.122.08.124
media: Ethernet autoselect (100baseTX )
status: active

Dicha interfaz se encuentra activa, y con la dirección de IP Pública 190.122.08.91, en la cual se produce el NAT.

Dentro de kgdb, al hacer un backtrace encuentro lo siguiente:

(kgdb) bt
#0 doadump () at pcpu.h:196
#1 0xc07ec1f7 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418
#2 0xc07ec4c9 in panic (fmt=Variable "fmt" is not available.
) at /usr/src/sys/kern/kern_shutdown.c:574
#3 0xc0b18f2c in trap_fatal (frame=0xc2f9097c, eva=4) at /usr/src/sys/i386/i386/trap.c:939
#4 0xc0b191b0 in trap_pfault (frame=0xc2f9097c, usermode=0, eva=4) at /usr/src/sys/i386/i386/trap.c:852
#5 0xc0b19c2c in trap (frame=0xc2f9097c) at /usr/src/sys/i386/i386/trap.c:530
#6 0xc0afe20b in calltrap () at /usr/src/sys/i386/i386/exception.s:159
#7 0xc33ac8ab in nat_new () from /boot/kernel/ipl.ko
#8 0xc33b0574 in fr_checknatin () from /boot/kernel/ipl.ko
#9 0xc33c9723 in fr_check () from /boot/kernel/ipl.ko
#10 0xc33c170e in fr_check_wrapper () from /boot/kernel/ipl.ko
#11 0xc0897418 in pfil_run_hooks (ph=0xc0d03100, mp=0xc2f90be8, ifp=0xc3191400, dir=1, inp=0x0) at /usr/src/sys/net/pfil.c:78
#12 0xc08d76e2 in ip_input (m=0xc32eaa00) at /usr/src/sys/netinet/ip_input.c:416
#13 0xc0895bb5 in netisr_dispatch (num=2, m=0xc32eaa00) at /usr/src/sys/net/netisr.c:185
#14 0xc088bb51 in ether_demux (ifp=0xc3191400, m=0xc32eaa00) at /usr/src/sys/net/if_ethersubr.c:834
#15 0xc088bf43 in ether_input (ifp=0xc3191400, m=0xc32eaa00) at /usr/src/sys/net/if_ethersubr.c:692
#16 0xc09ec818 in xl_rxeof (sc=0xc3199000) at /usr/src/sys/pci/if_xl.c:2022
#17 0xc09eed24 in xl_intr (arg=0xc3199000) at /usr/src/sys/pci/if_xl.c:2257
#18 0xc07c9f5b in ithread_loop (arg=0xc3190300) at /usr/src/sys/kern/kern_intr.c:1088
#19 0xc07c6a59 in fork_exit (callout=0xc07c9da0 , arg=0xc3190300, frame=0xc2f90d38) at /usr/src/sys/kern/kern_fork.c:810
#20 0xc0afe2b0 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:264

(kgdb) p *0xc33ac8ab
$1 = 251937163

Si se realiza el seguimiento del backtrace, se encuentra, con lo que posiblemente sea un paquete intentando atravesar el modelo OSI/ISO (Físico, Enlace, Red, Transporte..) haciendo llamadas como por ejeplo a xl_intr, xl_rxeof, ether_input, ether_demux, netisr_dispatch, ip_input, hasta llegar a nat_new donde se produce la falla, y salta a la función calltrap(), la cual hace la llamada para producir el trap (trap y trap_pfault), el cual se convierte en trap_fatal (debido a que es un pagefault) y hace saltar a la funcion panic(), que finaliza escribiendo el coredump (volcado de memoria), y haciendo un reboot del equipo.

Lo que indica que el crash se produce al acceder a la función nat_new(), mapeado su segmento .text en la dirección 0xc33ac8ab, cuyo código de fuente se encuentra en /usr/src/sys/contrib/ipfilter/netinet/ip_nat.c, en el cual se realiza el encapsulado, fragmentación y traslado de direcciones, para aplicar NAT.

Dicha función se compone de tres secciones:

Crear una nueva estructura NAT para la regla MAP para las conexiones entrantes.
Crear una nueva estructura NAT para la regla RDR para las conexiones salientes.
Construir dicha estructuras y ponerla dentro de la tabla de NAT.

También función new_nat() recibe como parámetros:

np(I) -> Puntero a la regla de NAT
fin(I) -> Puntero a la información paquete, obtenido en las funciones anteriores.
flags(i) -> Que se encuentran en el último paquete.
direction(i) -> Dirección del paquete (IN/OUT) para luego la función new_nat() pueda aplicar MAP o RDR.

Por lo cual el pagefault lo puede estar dando al pasarle a la función, el argumento np(I). El cual apunte a una dirección de memoria inexistente o invalida, y al intentar leer de ella crashea.

Para reproducir el problema, se puede hacer lo siguiente:

Se debe crear un archivo llamado tcpfrag.nat, con el siguiente contenido:

[out,xl1]
4500 00a0 0000 0100 3f06 7555 0101 0101 0201 0101
0401 0019 0000 0000 0000 0000 5010 2000 86b7 0000
0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000 0000 0000

Luego ejecutando:

#: ipftest -F hex -N tcpfrag.nat -i tcpfrag.pkt

Esto es debido a que en el archivo /etc/ipnat.rules, se encuentran cargadas las siguientes reglas sobre la interfaz de red xl1.

bimap xl1 172.18.2.12/32 -> 190.122.08.91/32
bimap xl1 172.18.2.13/32 -> 190.122.08.91/32
bimap xl1 172.18.2.14/32 -> 190.122.08.91/32
bimap xl1 172.18.2.15/32 -> 190.122.08.91/32

Según busque entre los reportes de bugs de FreeBSD, el problema existe y el motivo del problema puede ser debido a que un fragmento TCP que matchee con una regla que es para otro cualquier protocolo, debido a que se duplica su entrada en la cache de NAT.

Dicha referencia puede ser encontrada en el siguiente link:

http://www.freebsd.org/cgi/query-pr.cgi?pr=137392

Dicho bug, se encuentra abierto al momento, y lleva reportado ya 2 años (Agosto del 2009), fue categorizado como "Medio". Debido a que es posible generar en un host remoto, paquetes con una payload ligeramente modificada y producir una denegación de servicio en el servidor, haciendo entrar en panic el kernel, y produciendo por lo tanto un reboot forzado del mismo.

Según encontré, aún no hay ningún parche oficial para solucionar dicho problema, y en esta empresa se necesita la utilización de las reglas bimap, por lo cual, la única solución accesible y razonable que encontré es migrar dichas reglas a Packet Filter. En el caso de Solaris, no tuve la oportunidad de testearlo, si alguién lo hace, por favor me avisa!.