Extraer un fichero de un paquete RPM

Podemos saber qué ficheros tiene un determinado paquete, mediante:

rpm -qlp  PAQUETE.rpm 

Luego, una vez sabemos el listado de paquetes, podemos extraer uno en concreto mediante:

rpm2cpio PAQUETE.rpm  |  cpio -ivd FICHERO_A_EXTRAER

y a funcionar... Un ejemplo ilustrado sería el siguiente:

# rpm -qlp nagios-plugins-disk_smb-1.4.5-1.fc4.i386.rpm
/usr/lib/nagios/plugins/check_disk_smb

Para obtener el único fichero que contiene, ejecutaremos:

rpm2cpio nagios-plugins-disk_smb-1.4.5-1.fc4.i386.rpm \
 | cpio -ivd  ./usr/lib/nagios/plugins/check_disk_smb

Atención a ./, del principio de la ruta del fichero que queremos extraer.

ArpTables en Debian

Estos dos últimas días he estado configurando servicios Linux balanceados con Piranha (la "interpretación de lvs" de RedHat). La topología de Red y el personal de comunicaciones me han obligado a usar Direct-Routing, y como todos sabrán, para ello es importante usar ArpTables. Era la primera vez que lo usaba, porque siempre había usado el módulo no-arp, tal y como recomiendan en el proyecto ultramonkey, pero consideré que era un buen momento para evaluar este tipo de soluciones.

En RedHat todo está bastante documentado y encontraremos una muy buena explicación de las posibles configuraciones, en el capítulo 3 de Linux Virtual Server (LVS) for Red Hat Enterprise Linux 5.1. Todo lo haremos con arptables_jf

arptables -A IN -d virtual_ip -j DROP
arptables -A OUT -d virtual_ip -j mangle --mangle-ip-s real_ip

Cuando he tenido que llevar esto a Debian Etch, me he encontrado que no me funcionaba :(, desesperado, he intentado volver a compilar el módulo no-arp, que ya no he podido hacerlo funcionar para el kernel 2.6.18-6-686. Finalmente he dado con la tontería, de por qué no funcionan estas reglas en Debian, y es porque cambian los chain para las reglas, así que para Debian queda como:

apt-get install arptables
arptables -A INPUT -d virtual_ip -j DROP
arptables -A OUTPUT -d virtual_ip -j mangle --mangle-ip-s real_ip

Vaya, tontería que me ha hecho perder 4 horas casi.

Instalación de licencias de PowerPath

Una vez se instala PowerPath y se instalan las licencias, debemos ejecutar:

powermt check_registration
powermt set policy=co dev=all
powermt display dev=all
powermt save

Tenemos ayuda en man powermt. La política es para que sea el clariion quien decida por dónde debemos ir.

Instalaciones remotas de RHEL en BladeCenter

Esta mañana he tenido que instalar una RHEL5 sobre un Blade HS21 de IBM. Uno de los principales inconvenientes que le encuentro a este tipo de infraestructura es que la consola de gestión remota, el Virtual Media, y demás es bloqueante, y sólo un blade puede usar los recursos, al contrario que sucedía con los equipos de HP, donde las interfaces de administración remota no son compartidas.

Además el VirtualMedia de la disquetera crea un dispositivo USB (/dev/sdc), por lo que lo típico de lanzar la instalación de un Linux mediante:

linux text ks=floppy

... no funciona. Así que he tenido que investigar un poco y al final he descubierto esta interesante página en Linux Para todos donde explican bastante bien cómo trabajar con anaconda. No he tenido éxito al instentar decirle a Anaconda que el KS estaba en sdc1://ks.cfg, usb://ks.cfg, y demás alternativas y combinaciones. Lo que sí me ha funcionado ha sido hacerlo por Web:

linux text ks=http://LA_IP_DE_UNO_DE_MIS_SERVIDORES/ks/rhel5u0.ks

Crear parches

En un cliente estoy trabajando en la integración de Active Directory y Linux RHEL4, y me he encontrado con numerosos problemas. La idea es que los usuarios no se conecten por SSH a los servidores como Root, sino con su login y passwd del dominio Windows 2003, y además se les mapee como home su unidad de trabajo personal (la U:).

Me he encontrado  varios defectos importantes, en esto.

1. RHEL4U0 hasta RHEL4U5 tienen mal soporte al módulo CIFS en el kernel. No nos permite montar rutas UNC de la forma \\SERVER\LO_QUE_SEA$\LOGIN, sólo se queda en \\SERVER\LO_QUE_SEA$. En RHEL4U6 funciona perfectamente, mientras en RHEL4U5 se escibe un mensaje en /var/log/messages:
   kernel: CIFS: Unknown mount option prefixpath
   
2. No hay una versión buena de pam_mount que funcione en RHEL4 decentemente sin instalar media Fedora, por lo que finalmente me he tenido que ir a la versión 0.9.25. 
3. La versión del cliente samba que viene hasta RHEL4U5 no monta correctamente mis volúmenes CIFS, por lo que he tenido que actualizar los RHEL4 a samba*3.0.25b-0.4E.6.
4. Como simultaneo usuarios linux (/etc/passwd) con usuarios ActiveDirectory (LDAP) cuando se conectan los usuarios locales aparece un molesto mensaje:

   pam_mount: error trying to retrieve authtok from auth code
   pam_mount: error trying to read password

   que por otro lado es normal.
5. Por las particularidades de la configuración del cliente, he tenido que crearme un script miMount, que es el que llama pam_mount, dado que había usuarios que tenían diferente UNC de conexión a la red, por temas de cuotas. En el script se detecta esto y se arregla.
   

Viendo todo esto, creo que es un verdadero milagro que funcione pam_mount en la red del cliente y en RHEL4 previas a U6. Al final he ido solucionando todo a excepción del mensajito que aparece cuando se conectan los usuarios linux, que no he podido solucionar mediante la configuración de  pam. He creado un parche para pam_mount y he recompilado el paquete, que es lo que he distribuido por los servidores linux RHEL4. Para generar el parche:

1. Cambiarse a al directorio donde están los fuentes del paquete:

   cd /usr/src/redhat/SOURCES/

2. Descomprimir y dejar dos copias: una original (orig) y otra para aplicar el parche (patched)

   tar -xzvf pam_mount-0.9.25.tar.gz
   mv pam_mount-0.9.25 pam_mount-0.9.25.orig
   cp -R pam_mount-0.9.25.orig pam_mount-0.9.25.patched

3. Realizar los cambios en el árbol de fuentes patched.
4. Extraer las diferencias con diff y crear el parche.

   diff -uNr pam_mount-0.9.25.orig pam_mount-0.9.25.patched > Mensajes.patch

5. Modificar el SPECS/pam_mount para tener que en la compilación se aplique nuestro parche. Esto es añadir al principio
   

   Patch0: Mensajes.patch

   y luego tras la sección %setup -q,

   %patch0 -p1
   

6. Por supuesto deberemos cambiar también la revisión.
   

   Release: 2

Luego sólo quedaría reconstruir nuestro paquete y volver a instalarlo.

Paquete screen en Linux

El paquete screen es una de esas utilerías simples que descubrí un día, gracias a Angel Prieto, y que luego uso bastante. Aprovechando que tengo que copiar unas máquinas virtuales para el trabajo de mañana, edito esta entrada; Screen es un programita que al ejecutarse lanza una shell en segundo plano, que después podemos dejar ejecutándose y desconectarnos; si después necesitamos ver como va el proceso, podemos volver a recuperar la consola... lo cual marca la principal diferencia con el comando nohup. Esto es muy útil cuando tenemos que lanzar un apt-get upgrade por ejemplo.

La idea es:

1. Ejecutar el comando screen
2. Lanzar lo que queramos, lanzar
3. Salir de la consola pulsando CONTROL+A, lo que sería [detached]. Si pulsamos CONTROL+D saldremos y mataremos el proceso [screen is terminating].
   
4. Una vez que hemos pulsado CONTROL+A, podremos ejecutar los siguientes comandos básicamente:
   • screen -ls, para listar los procesos screen que tenemos activos
   • screen -r PID, para recuperar la consola

Aunque la página man es más completa, lo básico para sobrevivir sería esto.

Mi Google Code: DynIP

Por fín me he decidido a probar el servicio Google Code, para en principio ir dejando cosillas que deseo otras personas puedan usar cuando quieran. Ya lo intenté con SourceForge, pero la creación de proyectos es moderada, osea, hay alguien que decide si acepta tu proyecto o no, por la descripción que haces de él, lo que pretendes, etc, en fín una forma de asegurar la calidad de los contenidos, que me parece justa, aunque lo único que yo siempre pretendí fue alojamiento de mis cosillas y disponibilidad de acceso independientemente de donde estuviera.

Parece que google code me permite esto que yo quiero... fácil y rápido, como todo lo que hacen: en 10 minutos tenía subido el código a mi nueva cuenta, http://tecnoquia-scripts.googlecode.com/svn/trunk/dynIP/. Este proyecto DynIP  incluye el script de renovación de IP de mi anterior entrada, y además un demonio que me permite saber si se me ha caído la conexión a internet o no. Lo he desarrollado, porque últimamente , el poco tiempo que estoy en casa, me paso más tiempo esperando estar conectado que realmente conectado.