Mi nuevo portátil HP dv5-1132es


Hace unas semanas me compré un nuevo portátil en MediaMark aprovechando la ayuda de 200€ que nos dá nuestro gobierno regional. El portátil es como el que ahora mismo tienen en oferta por 699€ con el anuncio del avión, pero con ligeras diferencias, por aquello de que yo sí soy tonto: Me costó 799€ y es un modelo HP Pavilion dv5-1132es, que en resumen tiene un poco más de procesador que el de la oferta, 1GB más de RAM, algo más de disco duro, y un modelo superior de tarjeta gráfica.

Aunque aún no he terminado de ponerlo a punto (como siempre Fedora tiene la culpa de mis desgracias), le he instalado perfectamente Ubuntu 8.10 en 32bits (todo funciona perfectamente), Fedora Core 10 en 64bits (tengo problemas con el sonido y con la WIFI), Windows Vista (que viene de serie) y he probado a instalar Hackintosh 10.5.4 (funciona todo excepto la suspensión) y que al apagar no termina de apagarse completamente). Este post lo estoy escribiendo con ECTO sobre leopard acostado en el sofá y conectado con la Wifi.

No habría podido instalarlo correctamente si no es por la inestimable ayuda de Jesús Gómez, que se estuvo peleando con esto durante varios días. Conseguí que funcionara todo de la siguiente forma:

  1. Instalar leopard 10.5.2 desde la imagen Kaliway.

  2. Actualizar a leopard 10.5.4 desde la imagen de iATKOS 4i sin formatear siguiendo http://forum.insanelymac.com/index.php?showtopic=127885&pid=904505&mode=threaded&start=#entry904505. La idea es seguir los pasos del foro y seleccionar el driver para VGA – Nvinjet de 256Mb, y en System todo excepto ext2fs y ntfs-3g. En red eligir realtek 8139 y broadcom 440x.
  3. Al hacerlo tendremos un problema de permisos, por lo que habrá que subsanarlo siguiendo http://docs.info.apple.com/article.html?artnum=306876-es.
  4. Para instalar la Wifi Broadcom 4310, podemos seguir http://forum.insanelymac.com/index.php?showtopic=51725. En el hilo de mensajes del foro descargaremos el Script v0.5.1. Lo descomprimiremos y desde un terminal ejecutaremos:
    sudo ./bcm43xx_enabler.sh
    Luego reiniciaremos el equipo. Luego vamos a Preferencias-Red y eliminamos Red Airport.
  5. Para el sonido seguimos http://forum.insanelymac.com/index.php?showtopic=132495&pid=942841&mode=threaded&start=#entry942841: Descargar HDAEnabler.kext, eliminar los ficheros /System/Library/Extension/AppleHDA.kext y /System/Library/Extension/HDAEnabler.kext (si lo tenemos). Copiar AppleHDA.kext y DAApple.kext en la carpeta /System/Library/Extension y eliminar /System/library/Extension.mkext. Ejecutar los siguientes comandos para actualizar los permisos, y luego reiniciar
    chown -R root:wheel /System/Library/Extensions
    chmod -R 755 /System/Library/Extensions/AppleHDA.kext
    chmod -R 755 /System/Library/Extensions/HDAapple.kext

Tomcat y enlaces simbólicos

Esta semana pusimos una aplicación Java bajo Tomcat 5.0 en alta disponibilidad. Para ello, la aplicación necesita usar un sistema de archivos compartido, que configuramos mediante NFS remoto. Los directorios donde se guardan los ficheros compartidos caen dentro del contexto de la aplicación, por lo que decidimos sacarlos al directorio NFS, y en su lugar dejar enlaces simbólicos. El problema que sucede entonces es que a Tomcat (igual que Apache) tenemos que decirle que siga los enlaces simbólicos.

Esto se le puede decir con el atributo allowLinking="true" en la etiqueta <context>, que encontraremos de forma aislada en el fichero XML del contexto de nuestra aplicación, dentro de los subdirectorios conf/Catalina/localhost/ o conf/Standalone/localhost (según hayamos definido el Engine en server.xml), o bien el en el propio conf/server.xml, dentro de <Server><Service><Engine><Host>

<context path="/mi-aplicacion" 
docBase="DIRECTORIO_de_mi_aplicacion"
allowLinking="true"/>

Evento Citrix en Murcia

Hace unas semanas estuve en un evento que Citrix celebró en Murcia. Estuvo organizado por el grupo inforges y resultó muy interesante porque pudimos descubrir cómo Citrix ha re-bautizado sus productos tras la adquisición de XenSource y Ardence, y encontrar las analogías con lo que conocemos del mundo VMware.

  1. XenServer se correspondería con VMware ESX Server. Dispone de hasta cuatro versiones de licenciamiento. XenServer Express Edition es gratuito hasta 4 máquinas virtuales corriendo en un único servidor. En la Enterprise Edition hay disponible un XenMotion (equivalente a VMotion).
  2. XenCenter se correspondería con VMware VirtualCenter.
  3. XenConvert se correspondería con VMware Converter. Este producto permite virtualizar equipos, generando una imagen .XNA que luego podemos importar desde XenCenter.
  4. Citrix Provisioning Server, es lo que llaman Streaming de Sistema Operativo, y al final consiste en una herramienta para poder desplegar el sistema orativo como hace Altiris Rapid Deployment Pack vía PXE entre otros.
  5. XenApp es la suite clásica de productos Citrix (ICA) que ya conocíamos (Metaframe, SecureGateway, etc) que han provisto además de posibilidades para el streaming de aplicaciones (lo que hace SoftGrid de Microsoft) o virtualización de aplicaciones. Resultó interesante ver un vídeo que demostraba como el protocolo RDP6 de Micrsoft aún tiene mucho que mejorar para hacer sombra a ICA, sobre todo bajo conexiones lentas
De pasada me quedé con las herramientas libres de inventario que están pegando duro: GLPI que están poniendo en marcha en la Consejería de Hacienda, y OCS Inventory que estamos poniendo en marcha en la Consejería de Educación.
En lo que se refiere a la virtualización del escritorio XenDesktop (se apoya en ActiveDirectory, igual que hace VDI de VMware, y sólo podemos usarlo bajo Windows 2003) presentaron los cuatro formatos en las que lo encontramos (Express, Platinum, Standard, Enterprise): La edición Express permite 10 hasta usuarios de forma gratuita. La Enterprise incorpora licencias de XenApp (lo que sería el Presentation Server) de forma que nos permite degustar los dos sabores, para pode determinar qué es mejor: si virtualización de escritorios o de aplicaciones. XenDesktop se fundamenta en portICA que es un protocolo distinto a ICA, que está en pleno desarrollo y que sólo permite virtualizar escritorios Windows XP, Vista y 2008.

VMware VMotion entre CPUs diferentes

Hace una unas semanas configuramos en un cliente VMware VirtualCenter 1.3 sobre los dos servidores ESX que tenía instalados. Estos servidores eran un IBM xSeries 346 y un 345, prácticamente con el mismo hardware pero diferían en el modelo de CPU: Uno llevaba un intel xeon 3.2GHz y el otro iba con un intel xeon 2GHz.

Cuando lanzábamos el live-migration de vmotion en caliente nos encontrábamos que no podíamos hacerlo, y nos daba un el error:

Error: Cannot migrate between hosts with different CPUs. Supported extended features differ. (Source: 0x00000000, Destination: 0x0000001d)


En los foros de VMware existen diferentes soluciones, pero probablemente ninguna se ajuste a lo que necesitamos. El documento que mejor explica este problema lo encontramos en VMotion CPU Compatibility - Migrations Prevented Due to CPU Mismatch - How to Override Masks, donde comenta que todo se debe a un problema máscaras de bits, por lo que las soluciones que a otras personas les funcionaron, no tienen por qué servirnos.

Lo que tendremos que hacer, es ejecutar el comando cat /proc/vmware/cupinfo y observar la salida, y buscar el campo al que hace mención el error (Supported extended features differ), que en nuestro era extFeat: Para un nodo valía 0x0000441d, y para el otro 0x00004400, que al hacer un OR-Lógico nos devolvía el error que estábamos obteniendo: 0x0000001d. En ese momento calculamos la máscara que tendríamos que aplicar para que al hacer el XOR-Logico el resultado fuera 0x00000000. En nuestro caso, la máscara que probamos nos funcionaba fue: 0xE5FF.

Una vez tenemos la máscara, debemos crear el fichero C:\Documents and Settings\All Users\Datos de programa\VMware\VMware VirtualCenter\config.ini con el siguiente contenido:
migrate.ignore.extfeature.bits = 0xE5FF
migrate.ignore.feature.bits = 0x20000
, reiniciar el servicio VirtualCenter y volver a probar el live-migration.

Comandos dmidecode y wmic

Siguiendo las entradas compartidas de Reader de Rubio, me he encontrado que podemos averiguar el modelo de nuestro equipo, número de serie, etc con el comando dmidecode del paquete con el mismo nombre:

dmidecode -s system-product-name
dmidecode -s chassis-serial-number
En el barebone de casa no ha funcionado, pero de rebote he encontrado el comando wmic en Windows, que permite lanzar consultas WMI desde una consola de Windows, algo así como el WMIExplorer del que ya he hablado alguna vez, pero para consola.
Para saber nuestro numero de serie y modelo de BIOS vía WMI, podemos ejecutar en una consola de Windows:
wmic bios get serialnumber
wmic bios get

El Kernel-PAE en RHEL5

Al parecer, lo que pasa si tenemos un equipo con más de 3GB de RAM y le instalamos RHEL5/Centos5, sólo veremos que el sistema tiene 3GB. Esta tarde me ha pasado, y me he preocupado bastante, porque estaba trabajando con blades de IBM con 6GB de RAM, y he pensado que me habían llenado los slots con DIM de Spare ¿?. Menudo susto, luego resulta que es una tontería, y todo se soluciona instalando el kernel-PAE, siempre que las CPUs incluyan "Physical Address Extensions".

yum install kernel-PAE kernel-PAE-devel
Editar la configuración de grub, para asegurarnos de que en el siguiente reinicio arrancamos con este kernel y reiniciar.
Con RHEL4 en el mismo tipo de Blades HS21 y sin kernel hugemem, me reconocía perfectamente los 6GB. Esto son los misterios de la informática que nos invitan a reflexionar si se fundamenta verdaderamente sobre ciencias exactas o aproximadas.

Conceptos VMware e IBM

El miércoles pasado, estuve en una charla que organizó el Grupo Inforges en el hotal Amistad, sobre VMware y soluciones Blade de IBM. Para ello tuve que descartar asistir al TechNet que se organizaba en Murcia. Las cosillas que me enteré de forma resumida fueron:

  • En VMware, DRS es el VMotion dinámico.
  • La solución de VMware para optimizar el consumo eléctrico de nuestra granja ESX es DPM, que lo que hace es mover máquinas virtuales y apagar servidores ESX, para minimizar el consumo.
  • VMware HA, se encarga desde el VirtualCenter de detectar que un ESX ha muerto, y entonces levanta las máquinas virtuales en otro ESX, pero claro, esto tiene una parada, no es como el VMotion.
  • Modelos de licenciamiento en el ESX:
    • ESXi, es la gratuita, para empezar a trabajar con la infraestructura virtual
    • ESX fundation, es como el ESXi, mas el Backup Consolidation, Update Manager (algo así como el SUS para VMware), el agente de Virtual Center.
    • Standard, que lleva lo mismo que el anterior, pero con VMware-HA.
    • Enterprise, el que incluye todo: DRS, Vmotion, etc
  • Modelos de licenciamiento del VirtualCenter:
    • Fundation, que permite controlar hasta 3 ESX
    • Full, sin límite de ESX que poder controlar.
  • Al hablar de Disaster Recovery encontramos,
    • RTO, cantidad de tiempo que tardamos en ser operativos
    • RPO, Hasta el punto que debemos retroceder en una caída.
    • En VMware encontramos Site Recovery Manager, que permite automatizar la parada y recuperación desde el segundo CPD, con ayuda de herramientas del almacenamiento como MirrorView o SRD de EMC, o ERM de IBM
  • También hablamos de VDI, y los elementos que se necesitan para trabajar con él: La infraestructura ESX 3i, el VirtualCenter y VDM que es un broker de conexiones que requiere del directorio Activo, y que haría las veces de CSG+Presentation Server (si lo comparamos con la infraestructura Citrix. Más tarde en el aperitivo, tuve ocasión de hablar con los técnicos que ya están trabajando en estas soluciones y les pregunté sobre VDI vs XenDesktop: Se mojaron, y me comentaron que la solución de Citrix resulta más atractiva porque por el mismo precio te ofrecen virtualización de escritorio y de aplicaciones, que según para qué cosas puede interesar una cosa u otra.
  • Ya sobre hardware VMware vimos el BladeCenter S, que está bastante, bastante bien para PYMES, que no tienen porqué racks: En uno de estos Chasis nos dejan casi el CPD entero... está muy, muy bien. Permite meterle todo (blades, array de discos, circuitería de red, KVM), etc y todo en 11Us, sin necesidad de RACK.
  • Además de este tipo de BladeCenter está el E y el H, donde la diferencia estriba en el número máximo de conexiones que permite sacar (switches que podemos meterle), y que es importante de cara a los Blades que luego deberemos comprar, por aquello de que no todos los Blades les podemos pinchar tarjetas de red o de fibra, de 8 puertos, etc.
  • Las familias de blades son: HXXX (micro intel), LXXX (micro AMD), JXXX (micro Power6) y QXXX (micro cell), y que todos los blades pueden pincharse en el mismo chasis. Según la gente de IBM, uno de los valores diferenciales de su BladeCenter es que todas las especificaciones son libres (como ya hicieran con el PC), y otros fabricantes empiezan a fabricar Blades compatibles con este BladeCenter.
  • En cuanto a filosofía de cabinas, parece que la hermana menor es DS3000 que puede llegar a DS5000 (no sé donde quedan las FasT), y que en productos ERM es equivalente a MirrorView de EMC, y FlashCopy a SnapShot de EMC.


Consultas WMI desde Linux

Ya llevo tiempo trabajando con la herramienta Nagios WSC que me permite monitorizar en Nagios los equipos Windows, sin desarrollar los incómodos scripts en Windows e invocarlos del port NRPE que existe para ellos, gracias a WMI. En los servidores Nagios, desarrollo unos pequeños scripts, que invocan las URLs del Web Service de Nagios-WSC que publico en IIS en un servidor Windows (habitualmente llamo a estos equipos Wagios), y transforman la salida del servicio web para al final tener una respuesta válida interpretable por Nagios.

Esta mañana me he planteado solucionar la monitorización de los clusters Microsoft a través de WMI. Para investigar que consulta realizar y qué clases consultar, siempre utilizo WMI Explorer, una pequeña utilidad Windows, que sin necesidad de instalar mucha cosa, me permite navegar por las clases. Para ello, lo primero que hay que hacer es tener claro el namespace que tenemos que consultar, y NameSpaces hay varios: root\aspnet, root\CIMV2, root\Cli, root\DEFAULT, root\directory, root\Microsoft, root\MicrosoftActiveDirectory, root\MicrosoftIISv2, root\MicrosoftNLB, root\MSCluster, root\perfmon, root\Policy, root\RSOP, root\SECURITY, root\subscription, root\WMI. Si no se tiene ni idea de WMI, como yo, se tarda un rato en descubrirlo :).

El NameSpace que aparece siempre seleccionado por defecto, y en que el que se basan la mayoría de ejemplos es root\cimv2, pero el que a mí interesaba era root\MSCluster. He realizado varias consultas y al final he comprobado que la clase que tenía los datos que me interesaban consultar era MSCluster_NodeToActiveGroup. Cuando he ido a Nagios WSC para cambiar el namespace, me he encontrado que no era posible, o yo no he sabido encontrar la forma de poder cambiarlo.

He empezado a buscar clientes para Linux (con idea de usarlos desde el propio servidor Nagios, en vez de usar el equipo intermediario Windows, wagios), y me he encontrado que tog-pegassus incorpora el comando wbemexec, pero después de leerme el manual tampoco he sabido construir un fichero XML con una petición que me funcionara, lo más cerca que he estado ha sido tener un fichero peticion.xml con este contenido,

<?xml version="1.0" ?>
<CIM CIMVERSION="2.0" DTDVERSION="2.0">
<MESSAGE ID="51000" PROTOCOLVERSION="1.0">
<SIMPLEREQ>
<IMETHODCALL NAME="EnumerateInstances">
<LOCALNAMESPACEPATH>
<NAMESPACE NAME="root"/>
<NAMESPACE NAME="MSCluster"/>
</LOCALNAMESPACEPATH>
<IPARAMVALUE NAME="PartComponent">
<CLASSNAME NAME="MSCluster_NodeToActiveGroup"/>
</IPARAMVALUE>
</IMETHODCALL>
</SIMPLEREQ>
</MESSAGE>
</CIM>
y luego ejecutar:
wbemexec -h vip-cluster -p 5989 -u 'DOM\\user' -w contraseña peticion.xml
wbemexec: Unable to use requested input file: file does not exist
pero no me ha funcionado :(. Al final he encontrado este otro cliente WMI, SBLIM (pronunciado "sublime"), que me permite ejecutar:
wbemcli ein -nl -noverify 'https://DOM\user:contraseña@vip-cluster:5989/root/MSCluster:MSCluster_NodeToActiveGroup'
y que sí funciona al pelo.

Gnokii: ¿qué significa un "+CMS:500"?

Cuando trabajamos con Gnokii, a menudo obtenemos códigos de error +CMS:500, +CMS:38, etc. Podemos encontrar un relación detallada de los códigos de error en el blog: http://blog.nowsms.com/2008/07/gsm-modem-cms-error-code-list.html, y el listado todos en http://www.activexperts.com/activsms/sms/gsmerrorcodes/.

De Apache FOP 0.20.5 a 0.94 (parte I)

Esta tarde he estado probando Apache FOP 0.94 con mis documentos XML, FO, XSL, etc, que hasta ahora no había tenido mucho tiempo. Las impresiones que puedo sacar con un primer vistazo son las siguientes:

  1. Con el nuevo FOP tendré que retocar los márgenes y distancias. Me consta que han mejorado el soporte para tablas, borders y dimensiones, y han implementado algunos atributos de XSL:FO que aún no estaban soportados en las versiones 0.20.X, por lo que me va a tocar revisar mis plantillas, para quitar todos los inventos que tenía que hacer para colocar el texto donde quería, mediante tablas.
  2. Las tablas ya no permiten elementos <fo:table-cell></fo:table-cell>, por lo que toca sustituirlas por <fo:table-cell><fo:block/></fo:table-cell>.
  3. Las imágenes no se redimensionan automáticamente para ajustar en la página, cuando no se tenemos valor para los atributos width y/o height. Para conseguirlo, debemos indicar width="100%" content-width="scale-to-fit" content-height="100%". Hay ejemplos en images.fo dentro del directorio examples/fo/basic/ de la distribución.

Seguiremos probando. Lo siguiente que quiero hacer es incluir mis propios tipos de fuentes, y rediseñar los formatos de las páginas.

Repositorios YUM personalizados en RHEL4 ( y RHEL5 y RHEL3)

Para tener yum en RHEL4, lo primero que necesitas es instalar los siguientes paquetes: python-elementtree, python-sqlite, python-urlgrabber, sqlite y yum

... y los podrás encontrar en la página:
http://rpmfind.net/linux/RPM/Dag_Apt_Repository_for_Red_Hat_Enterprise_Linux_4.html

... hay que tener paciencia a que termine de cargar que es muy grande. Las versiones que yo estoy usando en RHEL4, en todos los Updates hasta en el 6, y de momento no me ha dado ningún problema, que yo sepa, son:

   python-elementtree-1.2.6-7.el4.rf.i386.rpm
python-sqlite-0.5.0-1.2.el4.rf.i386.rpm
python-urlgrabber-2.9.7-1.2.el4.rf.noarch.rpm
sqlite-2.8.17-1.el4.rf.i386.rpm
yum-2.4.2-0.4.el4.rf.noarch.rpm
Las dependencias de estos paquetes (si tuvieran) las instalo desde la distribución oficial de RHEL4 que esté usando, poniendo el contenido de los CDs accesible vía NFS. Instalando todo esto tendremos el comando "yum" en nuestro equipo RHEL4 donde ya podremos configurar los repositorios que nos interese, igual que si estuviéramos en RHEL5: /etc/yum.conf y/o /etc/yum.repos.d/. A efectos practicos, llamaremos a todas estas máquinas hostclient.

Para publicar nuestro repositorio de paquetes, además necesitaremos el comando "createrepo", en al menos una máquina RHEL4 con el que poder crear la estructura del repositorio, por lo que habrá que descargar también el paquete: createrepo (yo uso: createrepo-0.4.4-1.noarch.rpm). A efectos prácticos, llamaremos a esta máquina configurator.

Luego tendremos que disponer de una máquina con el servidor Web o FTP configurado y con espacio suficiente, como para ir dejando ahí todos los paquetes que conformarán nuestros diferentes repositorios. Si este equipo es diferente de la máquina configurator, necesitaremos tambien que esta pueda montar por NFS los directorios donde tengamos los repositorios de paquetes, y así poder ejecutar el comando createrepo. A efectos prácticos, llamaremos a este equipo reposerver.

Imaginar que en el reposerver queremos publicar varias distribuciones:
- RHEL4U6, en el directorio /opt/repos/RHEL4U6
- RHEL4U5, en el directorio /opt/repos/RHEL4U5
- RHEL4U1, en el directorio /opt/repos/RHEL4U1

Crear estos directorios en reposerver y copiar el contenido de todos los CDs o DVDs (sobreescribiendo si hubiera conflictos) en ellos, de manera que los directorios con los RPMS de RHEL4U1 (por ejemplo) quedarán en /opt/repos/RHEL4U1/RedHat/RPMS. El hacerlo así, es porque también podremos usar scripts personalizados de anaconda para instalar las distribuciones, dejando los paquetes vía http.

En reposerver, debemos exportar por NFS el directorio /opt/repos para que configurator pueda escribir. Una vez en configurator, montaremos el directorio NFS (mount -t nfs reposerver:/opt/repos /mnt/reposerver) y ejecutaremos:
 cd /mnt/reposerver
for i in RHEL4*
do
cd /mnt/reposerver/$i/RedHat/RPMS
createrepo .
done
sync
cd
umount /mnt/reposerver
Con esto, deberíamos tener directorios repodata dentro de cada /opt/repos/RHEL*/RedHat/RPMS/.
De nuevo sobre la máquina reposerver, crearemos el siguiente enlace simbólico:
ln -s  /opt/repos/RHEL4U6  /opt/repos/RHEL4-ultima
Configurar Apache para que podamos navegar por los subdirectorios de /opt/repos desde nuestra red sin problemas, y que se sigan los enlaces simbólicos, de manera que si desde nuestro navegador accedemos a http://reposerver/repos/RHEL4-ultima/ ... veamos los mismos archivos que si lo hacemos en la URL http://reposerver/repos/RHEL4U6/


Una vez hecho esto, ya podemos acceder a cualquiera de las máquinas "hostclient". Supongamos que lo hacemos a una máquina RHEL4U1. Editaremos /etc/yum.conf (o crear un fichero /etc/yum.repos.d/) y añadiremos el siguiente contenido:

[base]
name=RedHat 4 Update 1
baseurl=http://reposerver/repos/RHEL4U1/RedHat/RPMS/

#[updates-released]
#name=RedHat 4 Updates
#baseurl=http://reposerver/repos/RHEL4-ultima/RedHat/RPMS/

Para una máquina RHEL4U5, escribiremos...

[base]
name=RedHat 4 Update 5
baseurl=http://reposerver/repos/RHEL4U5/RedHat/RPMS/

#[updates-released]
#name=RedHat 4 Updates
#baseurl=http://reposerver/repos/RHEL4-ultima/RedHat/RPMS/

... y un hostclient con RHEL4U6:

[base]
name=RedHat 4 Update 6
baseurl=http://reposerver/repos/RHEL4U6/RedHat/RPMS/

#[updates-released]
#name=RedHat 4 Updates
#baseurl=http://reposerver/repos/RHEL4-ultima/RedHat/RPMS/

Una vez hemos editado el fichero de los repositorios, guardaremos los cambios, y ejecutaremos "yum update", para que se refresquen la lista de nuestros repositorios. En teoría, no debería pedirnos actualizar nada, porque solo hemos dejado visible el repositorio de paquetes el repositorio de paquetes de nuestra distribución. Esto nos permite, que cuando tenemos que instalar cualquier paquete de la distribución, en vez de andar como locos poniendo y quitando CDs, y de vueltas con el comando "rpm -ivh, rpm -Uvh", lo hagamos directoramente con "yum install", lo cual ya es una comidad, porque yum resolverá las dependencias e instalará los paquetes que le digamos.

En un momento dado, nos puede interesar actualizar los hostclient a la última distribución que tengamos publicada (RHEL4-ultima), por lo que en ese momento, tendremos que editar el fichero de yum.conf y descomentar la sección:

[updates-released]
name=RedHat 4 Updates
baseurl=http://reposerver/repos/RHEL4-ultima/RedHat/RPMS/

y luego ejecutar "yum -y update", lo cual provocará que nuestra distribución quede completamente actualizada.

Esto muchas veces no es posible hacerlo, porque generaría conflicto con el aplicativo que tengamos en el servidor ( Oracle, SAP, BEA, etc) y romperíamos la matriz de certificación. Para estos casos, tendremos dos alternativas:

1. Usar el parametro "exclude=" en /etc/yum.conf, y evitar que se actualicen los paquetes conflictivos, que nos romperían la matriz de compatibilidad:

[updates-released]
name=RedHat 4 Updates
baseurl=http://reposerver/repos/RHEL4-ultima/RedHat/RPMS/
exclude=kernel,glibc

2. Tener un directorio especial en reposerver, donde vamos colocando los paquetes que sólo queremos actualizar, por ejemplo /opt/repos/RHEL4-especial. Cada vez que copiemos ahí un archivo tendremos que ejecutar createrepo desde el configurator, y luego en los hostclients tendremos que tener un repositorio, con esta pinta más o menos:

[updates-especial]
name=RedHat 4 Updates Especial
baseurl=http://reposerver/repos/RHEL4-especial/


Este último mecanismo, podríamos usarlo para tener una máquina registrada en RHN configurada, para desacargarse todas las actualizaciones que publiquen en RedHat-Network, y copiarlas desde /var/spool/up2date/ a este directorio. Esto sería una forma de mantener completamente actualizados nuestros equipos, habiendo registrado sólo uno, aunque debo reconocer que nunca lo he probado y no se si funcionará.

Lo que últimamente sí estoy probando es a disponer en un repositorio de yum todos los scripts, personalizaciones, y scripts de administración que desarrollo de manera personaliza para mis clientes: Por ejemplo, los scripts de monitorización de Nagios, o los scripts de backup del sistema. Todos estos scripts, ficheros, etc, los desarrollo bajo un control de versiones basado en Subversion y les preparo con ant, reglas para construir un RPM, que tras construirlo coloco directamente en ese directorio especial. Luego a cada servidor, le programo un "yum -y update" nocturno/semanal y mantengo completamente actualizada la infraestructura, sin necesidad de ir servidor por servidor.

Esto tiene otra ventaja. Ultimamente los servicios de informática para los que trabajo, están en proceso de certificación en alguna norma de calidad: ISO27000, ISO9000, ITIL, etc. En la mayoría de los sitios, tienen definido de manera bastante nítida, el proceso de desarrollo de aplicaciones, o correcciones de las aplicaciones que tienen en producción, y como trabajar con diferentes entornos productivos, lo que habitualmente se conoce como Desarrollo, Pruebas y Producción y el paso y maduración del código en estas plataformas. Trabajar con repositorios yum y control de versiones como he contado, permite convertir los trabajos del departamento de sistemas, como retocar una configuración, desarrollar un script, etc, en casi el trabajo de un programador-analista del departamento de desarrollo, y con ello no tener que definir procesos específicos para la administración de sistemas, lo cual me ayuda a vender mejor mis ideas ;).


Además, el tener los repositorios organizados de esta manera, me permite instalar de forma remota (vía http) los servidores, con ayuda de anaconda. La idea, es instalar un servidor RHEL4 con CDs, de manera atendida de manera que al terminar la instalación nos deje un fichero anaconda-ks.cfg, con todas las opciones que elegimos para la instalación. Luego lo editaremos y nos aseguraremos de incluir las siguientes opciones:
 
url --url http://reposerver/repos/RHEL4U6/
network --device eth0 --bootproto dhcp --hostname unattended-rh4u6

Este fichero anaconda-ks.cfg editado, lo renombro a rh4u6.cfg y lo coloco en un servidor Web (puede valer el mismo reposerver), en un subdirectorio HTTP llamado ks, (/opt/repos/ks/) de forma que podamos acceder con el navegador a http://reposerver/ks/rh4u6.cfg y veamos el fichero que hemos editado.

Luego, para instalar meto el primer de la distribución y cuando estamos ante el prompt de lilo, tecleo:
linux text ks=http://IP_de_reposerver/ks/rhel4u6.cfg

Suelo evitar la resolucion DNS en este punto de la instalación, para ganar velocidad y evitarme problemas. Esta linea esta indicando que queremos instalar en modo texto, y que la secuencia de repuestas para anaconda la encontrará en esa URL.
Este mecanismo de instalación, tiene sus problemas en con RHEL5, porque anaconda usa yum en la instalacion, por lo que cuando hacemos la copia de los CDs a /opt/repos/RHEL5UXX debemos conservar los directorios repodata que vienen con los paquetes en CD, y habilitar el FTP. En el script de instalación de anaconda pondremos:

url --url ftp://reposerver/repos/RHEL5U2/
network --device eth0 --bootproto dhcp --hostname unattended-rh5u2

Para publicar repositorios yum, tendremos la precaución de ejecutar en configurator el comando createrepo sin sobreescribir el directorio repodata que teníamos del CD:

cd /mnt/reposerver
for i in RHEL5*
do
for k in `find /mnt/reposerver/$i -type d -maxdepth 1 `
do
if [ -d $k/RedHat/RPMS ]
then
cd $k/RedHat/RPMS
mv repodata repodata.cd
createrepo .
mv repodata repodata.web
mv repodata.cd repodata
fi
done
done
sync
cd
umount /mnt/reposerver


Luego en Apache, tendremos crear diferentes alias para que la URL
http://reposerver/repos/RHEL5UX/YYYYY/RedHat/RPMS/repodata
apunte a /opt/repos/RHEL5UX/YYYYY/RedHat/RPMS/repodata.web
... donde UX será el Update de nuestra distribución RHEL5, e YYYYY, será el directorio de paquetes: Cluster, cluster-Storage, Server, etc...


Como este planteamiento nos obliga a tener varias máquinas configurator para crear los repositorios de diferentes distribuciones, lo que se puede hacer es usar el reposerver como DOM-0 con XEN, que ejecuta el mismo, el resto de máquinas configurator, las cuales son máquinas virtuales XEN ejecutadas como ya he dicho en el propio reposerver.


Si queremos usar todo esto en RHEL3, es posible, siguiendo las instrucciones de RHEL4, sólo que en los clientes necesitaremos instalar los paquetes: python-urlgrabber y yum, que podremos encontrar en
http://rpmfind.net/linux/RPM/Dag_Apt_Repository_for_Red_Hat_Enterprise_Linux_3.html

Yo uso las versiones: python-urlgrabber-2.9.7-1.1.el3.rf.noarch.rpm y yum-2.0.8-0.1.el3.rf.noarch.rpm, y tampoco me han dado problemas que yo sepa. Las dependencias como siempre, de los paquetes oficiales de la propia RHEL3.
Luego se hace todo de la misma forma que antes, pero en vez de usar el comando "createrepo ." se usará "yum-arch .", y no creará directorios "repodata" sino "headers".

¿Cuántos Watios consume mi CPD?

Ayer tuve quehacer una estimación de consumo eléctrico para un CPD pequeño, donde tenían gran variedad de equipamientos: Dos Racks de servidores, no completos, un clariion, un centera, la electrónica del edificio y la centralita. Este es
el resultado del análisis y por supuesto puede ser totalmente erróneo.

Me he basado en las especificaciones técnicas
de los equipos, porque la cuenta de Wattios=Voltios * Amperios,
disparaba los números, y he decidido ir al fabricante de cada
componente para ver cuánto dice él que consumen sus cacharros.


https://www-304.ibm.com/systems/support/supportsite.wss/docdisplay?lndocid=MIGR-4VUGY7&brandind=5000008
* (1U) 1 x IBM xSeries 330 => 200W
* (3U) 7 x IBM xSeries 340 (8656-6RY) => 270W



https://www-304.ibm.com/systems/support/supportsite.wss/docdisplay?lndocid=MIGR-44204&brandind=5000008
* (1U) 4 x IBM xSeries 335 (8676-L1X) => 411W (¿por fuente?)




https://www-304.ibm.com/systems/support/supportsite.wss/docdisplay?lndocid=MIGR-43694&brandind=5000008
* (2U) 8 x IBM xSeries 345 (8670-Varios) => 514W (¿por fuente?)

https://www-304.ibm.com/systems/support/supportsite.wss/docdisplay?lndocid=MIGR-56806&brandind=5000008
* (2U) 9 x IBM xSeries 346 (8840-Varios) => 625W (¿por fuente?)


https://www-304.ibm.com/systems/support/supportsite.wss/docdisplay?lndocid=MIGR-50053&brandind=5000020
* (6U) 1 x IBM BladeCenter (Type 8677) => 5500W


http://www.emc.com/products/detail/hardware/clariion-cx3-model-20.htm
* 1 Clariion CX3-20:
(3U) 2 x 230W (controladoras) => 460W
(3U) Por cada cajon de discos => 425W (maximo nº cajones= 10)




http://h18004.www1.hp.com/products/quickspecs/12028_na/12028_na.HTML
* (2U) 7 x HP Proliant DL380G4 => 575W (¿por fuente?)


Del centera no encuentro nada oficial: artículos y referencias. Parece que ...
2 x 250W (CUA=>1U c/u) => 500W
2 x 250W (Centera=>1U c/u) => 500W
(2U) Supongo cajones igual que clariion=> 425W (maximo nº cajones=15)


Aires acondicionados: La relacion entre Watios y Frigorias es:
* 1 frigoría o caloría = 1.16W
* 1 Watio = 0,86 Figrorías o calorías
* Cada aparato de 3000 Frigorías consume => 3480W
En el CPD de arriba tenemos 4 máquinas de aire no sé de cuanto cada una.



http://www.brocade.com/products/switches/silkworm_200E/index.jsp
* (2U) 2 Switches de fibra (60W c/u) => 120W



http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps5023/product_data_sheet0900aecd80371991.html
* (1U) Switches Cisco Catalyst 3750 => 200W (cada uno) como media van desde 190W -> 590W
Tenemos 5 de estos



http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps6545/product_data_sheet0900aecd80322aeb.html
* (1U) Switches Cisco Catalyst 500 => 110W
Tenemos 1 de estos.



http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps5528/product_data_sheet09186a00801f3d7d.html
* (1U) Switch Cisco Catalyst 3560G => 160W
Tenemos 1 de estos



No encuentro nada oficial para los Cajun P334T (aprox.200W)
* (3U) Cajun P334T => 200W
Tenemos 4 de estos



No encuentro el consumo de la centralita que tenemos que creo es Alcatel NextiraOne, pongamos que consume 1000W.



--- ESTIMACIONES TOTALES --------------


En un CPD como este, donde hay diferentes modelos de
servidores, con fuentes redundantes y sin redundancia, con fuentes que
consumen más, etc... tenemos que hacer medias (suponiendo todas las
fuentes redundantes):


* Servidores de 1U (antiguos) => consumo medio 500W


* Servidores de 2U => consumo medio 1100W ( consumo medio por 1U=>560W)


* Servidores de 3U (muy antiguos) => consumo medio 540W ( consumo medio por 1U=>180W)


* Servidores Blade => consumo medio 5500W ( consumo medio por 1U=>920W)
  +--> Pero suponen un ahorro, porque en 1U no metemos un servidor si no 14.
  * 14 servidores de una 1U modernos pueden consumir 500W * 14 = 7000 y 14U de espacio
  * 14 blades consumen 5500W (390W por equipo, sin contar que incluye al menos un par de switches interno) y solo 6U de espacio.


* La media de consumo por 1U podría estar en torno a los 540W por 1U
de un RACK y los Rack de servidores tienen 42U, por lo que un Rack
lleno de servidores, estaría en torno 22500W de consumo (22,5Kw)


* La media de consumo de un switch de entre 24 y 48 bocas, puede
estar en 160W, y para tener todo cableado se necesitan al menos 10
switches... lo supondría entorno a 1,6Kw para electrónica. Esto es
electrónica sin PoE (Power over Ethernet, que consume casi tres veces
más, y es recomendable para VoIP).


* El almacenamiento en Clariion estaría estando lleno en torno a los 4800W (4,8Kw)


* El almacenamiento en el Centera estaría, estando lleno, en torno a 7000W (7Kw)


* Ahora mismo en todo el CPD hay cuatro máquinas (supongamos de 3000frigorias) para enfriar en total:
= 1600W (electronica) + 2160W (clariion) + 1425W (centera) + 29700W (55Us de servidores) +
+ 1000W (centralita) + 13920W (aire acondionado) = 50000W aproximadamente ...


... por lo tanto 13920/50000= 0,27W aprox. ... esto quiere decir que
por cada Watio de consumo del CPD, necesitamos consumir 0,27W en aire
acondicionado, lo que se traduce en que por cada U de un Rack
necesitamos 145W (125 frigrorias)... por tanto:


TOTALES:
   2 RACKS Llenos de servidores    => 45000W
   1 CLARIION lleno de discos        =>   4800W
   1 CENTERA lleno de discos        =>   7000W
 10 Switches (electronica edificio)   =>   1600W (sin VoIP)
   1 CENTRALITA                          =>   1000W
   X AIRES ACONDICIONADOS      => 16000W
====================================================
                                                         75500W (75'5Kw)



Estas son las cuentas que he visto, me puedo haber equivocao, porque
no estoy muy ducho en esto, por eso lo he detallado, para que vosotros
veais en qué me he basado para hacer todo este razonamiento.

Compartir en Google Reader



Hace tiempo que Puche me lo estaba diciendo: "Comparte tus noticias en Google-Reader", y luego a mí me aparece lo que tú filtras y a tí lo que yo, y así con todos tus contactos. Es una forma de poder estar al día de más cosas, porque lo a mí me interesa puede interesarte y no lo sabes por que no solemos leer los mismos feeds", y como siempre Puche tenía razón.
Hasta ahora no había caído en hacer click en el enlace "Compartir" que aparece en la parte inferior de cada noticia, y desde esta semana lo estaba haciendo, pero claro, seguía sin ver lo que mis contactos compartían. Esta mañana acabo de verlo: El problema es que parece que esto sólo está disponible para la versión en inglés.

Windows XP y TS Gateway (windows 2008)

Desde hace tiempo vengo observando TSGateway de Windows 2008 Server. Está bastante bien, aunque aún le queda bastante para conseguir la velocidad de Citrix CSG, con más bien poca carga de usuarios. Hasta ahora el gran problema está en los clientes: Windows 2008, Vista y XP SP3, dado que necesitan la versión 6.1 del protocolo de escritorio remoto (RDP). Para probarlo desde Windows XP (y no hacerlo desde Windows Vista, por aquello de no mezclar las pruebas y las evaluaciones :)), bastaba con actualizarse a Service Pack 3. El otro día lo hice en un equipo, pero aún así seguía sin funcionar ¿?. La solución la daba Leandro en su blog.

  1. Para versiones XP SP2 parece que existe algún parche: Buscar la actuialización KB952230 en Microsoft.
  2. Si tenemos SP3, y aún así no nos aparece entre los complementos, será porque tenemos que borrar las siguientes entradas del registro, como era mi caso.
    HKCU\Software\Microsoft\Windows\CurrentVersion\Ext\Settings\{7390f3d8-0439-4c05-91e3-cf5cb290c3d0}
    HKCU\Software\Microsoft\Windows\CurrentVersion\Ext\Settings\{4eb89ff4-7f78-4a0f-8b8d-2bf02e94e4b2}

Por qué no funciona system-config-cluster en RHEL4U6

Porque el script Python está mal: Tips and tricks: Why does system-config-cluster fail to run in Red Hat Cluster Suite 4 update 6?. Lo que me mosquea es que al buscar en google el error que me aparece, sólo aparece esta referencia, en vez de aparecer el Bugzilla donde se reporte y se corrija. No me parece bien, y creo que esa no es la dirección... muy mal.

# system-config-cluster
Traceback (most recent call last):
File "/usr/sbin/system-config-cluster", line 52, in ?
from ConfigTab import ConfigTab
File "/usr/share/system-config-cluster/ConfigTab.py", line 27, in ?
from ConfigTabController import ConfigTabController
File "/usr/share/system-config-cluster/ConfigTabController.py", line 35, in ?
from FaildomController import FaildomController
File "/usr/share/system-config-cluster/FaildomController.py", line 213
if val == "Yes" or val == "yes" or val="1":
^
SyntaxError: invalid syntax

Un día de clusters con RHEL4U5


Hoy he perdido un día más de vida. El responsable ha sido un maldito cluster RHCS sobre RHEL4U5, que no quería funcionar como yo quería que funcionara.
Un cluster sencillo con 2 nodos y 2 recursos: un script java que se encarga de leer un tabla, y enviar correos, y otro script que monta un volumen NFS y luego un demonio que lee de ese volumen para envar FAX con ayuda de efax. Por separado todo funcionaba perfecto, de hecho el primero de los scripts lo tenía un par de meses él solito en el cluster, funcionando bien. Hoy le añado el segundo script y me funciona todo perfecto en el NODO1. Ejecuto clusvcadm -r RECURSO -m NODO2 , y el recurso se ejecuta en el NODO2 como era de esperar. Vuelvo a ejecutar clusvcadm -r RECURSO -m NODO1, y veo como se para en NODO2 (sin que aparezca nada en los logs de NODO1), y en unos segundos vuelve a estar arriba en NODO2... buf!!! vaya pesadilla!!! ¿que era? el exclusive="1" que tenían definidos los recursos del cluster, de manera que hacían que cada nodo ejecutara un solo servicio, y cuando intentaba moverlos de forma manual, se comportaban como si tuvieran un repelente de insectos...

Y qué he aprendido con todo esto:
  1. No usar el exclusive="1", a no ser que mi vida dependa de ello.
  2. Para aumentar el nivel de Log del cluster podemos usar log_facility="local4" log_level="7", en en la apertura del tag <rm>. Por defecto viene predeterminado a log_level="4". Luego debemos comprobar que en /etc/syslog.conf los mensajes local4.* tienen algún destino a fichero, y sino fijarlo y reiniciar syslog.
  3. Cuando tenemos scripts en cluster deberías usar LSB, tal y como se dice en la FAQ de RedHat, aunque ello sólo funciona de forma parcial:
    • DAEMON start => Siempre salir con exit 0
    • DAEMON stop => Siempre salir con exit 0 (aunque no sea LSB)
    • DAEMON status => Salir con exit 0 si está arrancado, con exit 3 si está parado.

Hacer un telnet en Windows 2008

Pues no funciona :P ... hay que instalarlo:
servermanagercmd -install telnet-client
se están volviendo locos por allá. Si además queremos saber, todo los que podemos instalar:
servermanagercmd -query
... la verdad, es que con un poco menos de esfuerzo podían haberle dejado al comando apt-, o yum, no por no tener que aprender, sino porque era más corto, aunque valoro muy positivamente el esfuerzo que han tenido que hacer para proporcionarnos una herramienta con la que poder instalar componentes de Windows desde la consola: Creo que están en el camino correcto, aunque una vez que ya están sobre él, deberían procurar acelerar y meter alguna marcha larga, a veces me parece que ese coche no anda.

Pero bueno, no quiero ensuciar la buena imagen que últimamente me están dando. Enhorabuena, y adelante.

RHEL4: Dhclient actualice mi servidor DNS W2k3

En un cliente me he encontrado que tienen servidor DNS y DHCP en Windows 2003. Cuando configuro los clientes RedHat Enterprise Linux 4 para que configuren su IP a través del DHCP me encuentro que no se registran automáticamente en el DNS, a pesar de tenerlo permitido:

  1. En el servidor DNS encontramos:
  2. En el servidor DHCP encontramos:
Los equipos RHEL5Update2 se registran perfectamente, sin embargo con RHEL4 no se realizan las actualizaciones. Para ello debemos configurar el fichero /etc/dhclient-ethXX.conf (sustituyendo XX por la interfaz que configuramos con DHCP) para que tenga el siguiente contenido:
send fqdn.fqdn "NOMBRE_DOMINIO.";
send fqdn.encoded off;
send fqdn.server-update off;
Sustituir NOMBRE_DOMINIO por el nombre del servidor incluyendo el dominio y dejando el punto del final, por ejemplo, "poke.tecnoquia.com.", "border.casa.tecnoquia.com.". Además comprobaremos que el fichero /etc/sysconfig/network-scripts/ifcfg-ethXX contiene algo similar a lo siguiente:
DEVICE=ethXX
ONBOOT=yes
TYPE=Ethernet
###HWADDR=09:1A:64:89:79:5C

#- Con IP estatica
#BOOTPROTO=static
#IPADDR=192.168.NNN.MMM
#NETMASK=255.255.255.0

#- Con IP dinamica
BOOTPROTO=dhcp
####DHCP_HOSTNAME="NOMBRE_DOMINIO" ###DESCOMENTAR_EN_RHEL5

check_link_down(){
return 1;
}
Aún no he descubierto cómo actualizar de esta forma el registro PTR (en RHEL5 sí se actualiza), si no es haciéndolo yo manualmente con el comando nsupdate.

Oracle:¿qué versión/parche estoy usando?

Esta mañana se lo he preguntado a Jose Juan Buendía,

select comp_name,version from dba_registry
siendo system, y nos dirá los componentes y versiones de estos que tenemos instalados. También me ha comentado que no está demás instalar NCOMP tal y como recomienda Jeff Hunter en su artículo de OTN de cómo instalar 10gRAC sobre iSCSI.

RHEL4U6: nss_ldap + sendmail = PROBLEMAS

Desde hace varias semanas he notado que los sendmails de los servidores RHEL4U6 autenticados contra el LDAP del Diretorio Activo en Windows2003, no son capaces de entregar el correo local. Hoy por fín he sacado un poco de tiempo para depurarlo. El comportamiento es el siguiente.
  1. El equipo está autenticado contra el directorio LDAP del AD. Esto quiere decir que en /etc/nsswitch.conf tendremos algo similar a lo siguiente:
    passwd:     files ldap
    shadow: files
    group: files ldap
  2. Somos capaces de ejecutar los comandos getent passwd y getent group y obtener el listado de usuarios y grupos autorizados del dominio
  3. Arrancamos NSCD y parece que todo funciona, pero cuando ejecutamos service nscd status nos dice que no está ejecutándose.
  4. Cuando ejecutamos mail root, para enviar un correo en /var/log/maillog obtenemos:
    Jul 29 22:43:47 vmtyo-subversion-pro sendmail[20289]: m6TKhlFo020289: from=root, size=61, class=0, nrcpts=1, msgid=<200807292043.m6TKhlFo020289@vmtyo-subversion-pro.tyo.carm.es>, relay=root@localhost
    Jul 29 22:43:47 vmtyo-subversion-pro sendmail[20292]: m6TKhlxl020292: from=<root@vmtyo-subversion-pro.tyo.carm.es>, size=411, class=0, nrcpts=1, msgid=<200807292043.m6TKhlFo020289@vmtyo-subversion-pro.tyo.carm.es>, proto=ESMTP, daemon=MTA, relay=localhost.localdomain [127.0.0.1]
    Jul 29 22:43:47 vmtyo-subversion-pro sendmail[20289]: m6TKhlFo020289: to=root, ctladdr=root (0/0), delay=00:00:00, xdelay=00:00:00, mailer=relay, pri=30061, relay=[127.0.0.1] [127.0.0.1], dsn=2.0.0, stat=Sent (m6TKhlxl020292 Message accepted for delivery)
    ... y el correo nunca llega. Al ejecutar mailq vemos que está en la cola.
  5. Si ahora editamos /etc/nsswitch.conf y dejamos lo siguiente,
    passwd:     files ldap
    shadow: files
    group: files
    después de reinciar sendmail, vemos como finalmente el correo llegará a la cuenta de root.
Después de depurar durante varias horas el proceso, depurando el comportamiento con distintas opciones de configuración y con ayuda de strace, en diferentes sistemas RHEL4UXX, he llegado a la conclusión de que tenía que ser un bug de nss_ldap-226-20 (la versión de RHEL4U6). He realizado una búsqueda en Internet y así parece ser que es.

He actualizado el sistema para usar nss_ldap-226-18 (la versión de RHEL4U5) y el envío de correos funciona a la perfección.

Error "sql_select option missing" al reiniciar sendmail en RHEL4

Habitualmente suelo configurar los agentes MTA locales de los servidores Linux, con el fín de que al menos el correo local en la máquina se entregue apropiadamente, y me lleguen los reportes de logwatch,cron, etc.
En las instalaciones de RHEL4, me estaba encontrando en /var/log/messages que cada vez que reiniciaba el demonio, aparecían entradas como esta.
Jul 29 18:58:10 vmtyo-subversion-pro sendmail[6340]: sql_select option missing
Jul 29 18:58:10 vmtyo-subversion-pro sendmail[6340]: auxpropfunc error no mechanism available
Jul 29 18:58:10 vmtyo-subversion-pro sendmail: sendmail startup succeeded
Jul 29 18:58:11 vmtyo-subversion-pro sendmail: sm-client startup succeeded
Al parecer esto se debe a que tenemos instalado el paquete cyrus-sasl-sql, y no lo hemos configurado, que tampoco es mi caso, por lo que para que desaparezcan estos mensajes bastará con desinstalarlo:
rpm -e cyrus-sasl-sql-2.1.19-14
/etc/init.d/sendmail restart

Vmware Server 2.0 en Ubuntu 8.04

Esta mañana he instalado y configurado al fín VMware Server 2.0, en el equipo con Mythbuntu que tengo conectado a la tele. He seguido las instrucciones de http://ubuntuforums.org/showthread.php?t=779934, y luego en las respuestas he aceptado todas las sugerencias que me hacía, como antiguamente decíamos: Siguiente->Siguiente->...

sudo apt-get install build-essential linux-headers-`uname -r` xinetd
cd /opt/
tar xzvf /opt/software/VMware-server-2.0.0-101586.i386.tar.gz
cd vmware-server-distrib/
./vmware-install.pl
Lo que me resulta más interesante es la posibilidad de crear máquinas virtuales con RHEL5 en 32 y 64 bits, además del nuevo interface Web y el soporte a USB2.0.

Claves GPG en Ubuntu/Debian

A menudo las claves GPG de los distintos repositorios nos caducan y necesitamos actualizarlas, porque de otra forma apt-get nos fallará y nos avisará del problema con las claves GPG. Así, necesitaremos...
wget -q URL-DEL-FICHERO.gpg -O- | sudo apt-key add -
o bien, si ya la tenemos descargada
sudo apt-key add FICHERO.gpg
Una vez hayamos cargado las nuevas claves, ya podremos ejecutar
sudo apt-get update
para refrescar el repositorio de paquetes, que nos estaba fallando.

Investigando el contenido de un initrd

Tratando de solucionar mis problemas de sonido
[   36.093438] ACPI: PCI Interrupt 0000:00:11.5[C] -> Link [LNKC] -> GSI 11 (level, low) -> IRQ 11
[ 36.093748] PCI: Setting latency timer of device 0000:00:11.5 to 64
[ 36.595513] ACPI: PCI interrupt for device 0000:00:11.5 disabled
[ 36.595623] VIA 82xx Audio: probe of 0000:00:11.5 failed with error -13
con el PVR-Mythbuntu sobre Shuttle SK41G que estoy tratando de configurar en casa, tengo la curiosidad de mirar el fichero initrd que preparan en Ubuntu, para ver si por casualidad ahí estuviera la clave del problema.
Al intentarlo me encuentro con que el formato del initrd, no es con el que yo estaba familiarizado (imagen ext2 comprimida, que siempre montaba con mount -o loop), sino que se trata de un cpio comprimido. Para descomprimirlo...
mkdir /tmp/prueba
cd /tmp/prueba
cp /boot/initrd.img-2.6.24-19-generic initrd.gz
gunzip initrd.gz
cpio -imdF initrd
luego realizamos los cambios que consideremos oportunos, y para dejarlo cargable por grub ejecutaremos...
cd /tmp/prueba
rm -f initrd
find ./ | cpio -H newc -o > ../mi-initrd.cpio
gzip ../mi-initrd.cpio
mv ../mi-initrd.cpio.gz /boot/initrd.img-2.6.24-19-generic-mia
También deberíamos editar /boot/grub/menu.lst para que el sistema arranque con esta nueva imagen.

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.

IP dinámica en casa y DynDNS

Hace tiempo que tengo un script para comprobar la dirección IP dinámica que me reparte mi proveedor de internet y actualizar el registro dyndns, con el fin de poder acceder al servidor de casa, cuando estoy fuera. Hace unas semanas estaba notando ya que no siempre está disponible showmyip, y ayer me decidí a cambiar el script y reescribirlo para quitarle toda la parte XML, dejándolo puramente en Bash.
Este es el resultado:
#!/bin/bash
#
# Este script permite renovar la direccion IP de mi servidor en
# dyndns, lanzando una consulta HHTP a servicios web para
# comprobar la IP que tenemos.
#

# ---------------------------------------------------------

# Configuracion de DynDns
DynDns_User=LOGIN_DE_USUARIO_DYNDNS
DynDns_Pwd=PASSWD_DE_USUARIO_DYNDNS
DynDns_Domain=NOMBRE_DOMINIO
DynDns_MX=REGISTRO_MX

# ---------------------------------------------------------

# Definir el directorio donde iremos dejando logs, IPs, etc
BaseDir=/var/log/dynIP
if [ ! -w $BaseDir ]
then
echo "No puedo escribir en [$BaseDir]. Asegurese de que existe y que tiene permisos de escritura" >&2
exit 1
fi

# Ficheros temporales
tmpFile=/tmp/renuevaIP-$$-$RANDOM

# Fichero de Log con las renovaciones
logFile=$BaseDir/renovaciones.log

# Fichero con la ultima IP conocida
ipFile=$BaseDir/lastIP

# Direccion IP inicial
MyIP=""

# Asegurarnos de que cualquiera podrá escribir en los ficheros...
chmod a+w $logFile $ipFile 2>/dev/null >&2

# --- FUNCIONES -------------------------------------------
download () {
/usr/bin/wget \
-O $tmpFile.dwn \
-U "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) \
Gecko/20030430 Debian/1.3-5" \
"http://$1" >/dev/null 2>&1
return $?
}


# --- MAIN ------------------------------------------------

# Buscar la IP de Internet
if download 'www.whatismyip.com/automation/n09230945.asp'
then
MyIP=$(cat $tmpFile.dwn)
elif download 'checkip.dyndns.org'
then
MyIP=$(cat $tmpFile.dwn \
| perl -ne 'print $1 if ($_=~ m/Current IP Address:\s([\d|\.]+)/);')
elif download 'www.formyip.com'
then
MyIP=$(grep 'Your IP' $tmpFile.dwn \
| head -1 \
| perl -ne 'print $1 if ($_=~ m/Your IP is\s([\d|\.]+)/);')
elif download 'whatsmyip.org'
then
MyIP=$(grep 'Your IP' $tmpFile.dwn \
| head -1 \
| perl -ne 'print $1 if ($_=~ m/Your IP is\s([\d|\.]+)/);')
else
exit 0
fi

# Obtener la ultima IP
OldIP=`cat $ipFile 2>/dev/null`

if [ "$MyIP" != "$OldIP" ] && [ "$MyIP" != "" ]
then
if download "$DynDns_User:$DynDns_Pwd@members.dyndns.org/nic/update?system=dyndns&hostname=$DynDns_Domain&myip=$MyIP&wildcard=ON&mx=$DynDns_MX&backmx=NO&offline=NO"
then
echo "[`date "+%d/%h/%y %H:%M:%S"`] Resultado: `cat $tmpFile.dwn` " >> $logFile
echo -n "$MyIP" > $ipFile
fi
fi

# Borrar todos los ficheros temporales creados
rm -f $tmpFile.*
Este script podemos guardarlo en /usr/local/TECNOQUIA/bin/renuevaIP y darle permisos de ejecución. Luego deberíamos crear el directorio /var/log/dynIP con permisos 777 y añadir al crontab del root lo siguiente:
# Renovacion de IP en DYNDNS, cada 15 minutos, si procede.
*/15 * * * * /usr/local/TECNOQUIA/bin/renuevaIP >/dev/null 2>&1
. Del script sólo deberíamos personalizar las variables: DynDns_User, DynDns_Pwd, DynDns_Domain, DynDns_MX con los datos de nuestra cuenta en dyndns.

Swappiness

Hace tiempo Longinos, me comentó el problema que existía con el servidor TSM y que todas las noches escribiera a SWAP aún a pesar de tener RAM disponible. Esto se debía a en la rama 2.6, el kernel de linux tiene este valor a un 60%, mientras en 2.4 no existía: cat /proc/sys/vm/swappiness, lo que significa que se hará bastante uso swap. Esto es útil en equipos con poca RAM y mucha carga. Conviene realizar pruebas con nuestro servidor, antes de pasarlo a producción:
sudo sysctl -w vm.swappiness=10
Para consolidar los cambios bastará con editar el fichero /etc/sysctl.conf, añadir al final vm.swappiness=10 y reiniciar el equipo.

Gvim en Ubuntu e iluminación de sintaxis

Esta tarde, al intentar trabajar con Ubuntu 7.10 y Gvim, me he propuesto no tener que configurar contínuamente la iluminación de la sintaxis, cuando edito cualquier tipo de documento. Esto se consigue editando la línea 20 del fichero /etc/vim/vimrc y quitando la doble comilla por la que empieza, que indica que se trata de un comentario. Así, que basta con dejar:

syntax on
... et voilá, a funcionar.

Deepest Sender y el problema con las fechas en blogger

He estado buscando más usuarios con el mismo problema que yo con Deepest Sender + blogger + fechas, y finalmente he encontrado este post que explicaba cómo solucionarlo. Parece que en la siguiente versión, aparecerá ya solucionado. La idea:
  1. Descargar a disco la extensión "deepest sender-0.8.0-firefox+sm.xpi".
  2. Descomprimir con file-roller el fichero a un directorio temporal.
  3. Descomprimir el fichero jar con el código (he tenido que abrir una terminal, aún no se hacerlo desde GNOME) y ejecutar lo siguiente:
    cd ~/prueba/chrome
    mkdir jar
    cd jar
    /opt/jdk1.5.0/bin/jar xvf ../deepestsender.jar
  4. Editar el fichero ~/prueba/chrome/jar/content/protocols/atom.js y en la línea 63 cambiar this.date.toISO8601String(4); por this.date.toISO8601String(5);.
  5. Lo siguiente es rehacer lo que acaba de deshacer:
    cd ~/prueba/chrome/jar
    rm -f ../deepestsender.jar
    /opt/jdk1.5.0/bin/jar cvf ../deepestsender.jar *
    cd ..
    rm -fr jar
  6. Luego con file-roller he vuelto a crear un fichero ZIP con el contenido de la carpeta ~/prueba/, y después le he cambiado la extensión para renombrarlo a deepest_sender-0.8.0-firefox+sm-modificado.xpi.

Esta entrada ya está publicada directamente con Deepest Sender que he modificado, y lo he dejado en mi cuenta de freedrive.

Deepest Sender como editor de blogs

Anoche me quedé desilusionado cuando descubrí que BloGTK está por mejorar y esta mañana he empezado a mirar, para ver las alternativas que tenemos en Linux para la edición de blogs. Me he encontrado con la extensión Deepest Sender para Firefox, que es con la herramienta que estoy escribiendo esta entrada.

La impresión general es bastante buena:

  1. Soporta edición WYSIWYG
  2. Está totalmente en castellano. El hecho de que no esté en castellano, lo asocio a un problema de inmadurez del software.
  3. Los botones para la edición son los que deben ser, aunque probablemente le falte la edición del formato de texto, y no tener que recurrir a la pestaña Fuente para editar en HTML. Tener que editar código en HTML directamente lo asocio a un problema de accesibilidad del software.
  4. El deshacer no funciona todo lo bien que debiera, cuando cambiamos de pestañas.
  5. Permite editar el titulo del post.
  6. Tampoco envía las imágenes, por lo que al final tengo que modificar las entradas a mano y subir las imágenes.
  7. No me permite publicar por que me muestra un error con la ¿fecha (= WTF!?)?
  8. Lo mejor de todo es que entre las opciones de configuración podemos configurar si queremos que nos detecte los títulos de las ¿ canciones (=WTF!?)?
Sentencia: No puedo usarlo, aunque está más maduro que BloGTK, a pesar de que no puedo publicar nada.

Posteando con BloGTK

Leyendo Microsiervos y aprendiendo de los maestros, he leído que ellos usan ecto para editar sus posts en MacOsX, aunque también existe una versión para Windows. Entonces me he preguntado: ¿existirá algo parecido para Gnome?. La respuesta que primero he encontrado es BloGTK, y he creado esta nueva entrada usándolo a él como editor, y no haciéndolo en la incómoda interfaz web.


Como estoy en mi semana Fedora, me he instalado la versión de Fedora Core7 que me sugiere el propio administrador de paquetes de FedoraCore8 (actualizada hace una hora), en plan usuario windows sin abrir una consola ni nada de eso: todo con el ratón. Me ha instalado la versión 1.1-8.fc7

No es muy allá o aún no la controlo lo suficiente, porque he detectado los siguientes problemillas:

  1. No tiene botones para la inserción de listas ordenadas e itemizadas (lo que viene siendo <ol> y <ul>)

  2. No me permite cambiar el título de los post que envío

  3. No se encarga de subirme las imágenes el programa: A la hora de insertar imágenes, me pide la URL ¿y las dimensiones? ...error: Debería pedirme el fichero donde las tengo, y que él se encargara del resto

  4. Los botones no funcionan bien en la pestaña de previsualización

  5. En la pestaña "Edit Post" puedo modificar los Tags HTMLs alegremente sin que se compruebe que es HTML válido

  6. No está en castellano

  7. No sé para qué sirve la pestaña Advanced
En resumen ... que no está muy usable... resulta casi tan incómodo como la web.

Mi primer paquete SRC.RPM y RPM

Desde hace ya tiempo, me estaba planteando aprender a crear paquetes RPMs con los scripts y proyectos que voy haciendo en mis diferentes clientes, porque no siempre tenemos a mano el CVS donde lo desarrollé. La idea sería...

  1. Saber construir el paquete perfectamente (./configure, make, make install, etc) desde los fuentes.
  2. Hacer un fichero SPEC
  3. Crear el SRC.RPM
  4. Construir el RPM para RHEL3, RHEL4, RHEL5, etc
  5. Publicar los RPMs en repositorios YUM marcados como updates.
  6. Configurar los equipos, para que periódicamente actualicen estos repositorios.
Hoy me he decidido por fín a empezar con esto. Ya había leído mucha información sobre cómo poder hacerlo:
Al final lo más fácil es lo siguiente. Primero copiamos el fuente a /usr/src/redhat/SOURCES/.
cp nagios-plugins-1.4.3.tar.gz /usr/src/redhat/SOURCES/

Luego nos creamos un fichero SPECs (nagios-plugins.spec).
Name: nagios-plugins
Version: 1.4.3
Release: 1
Summary: Conjunto de plugins para los clientes Nagios

Group: Applications/System
License: GPL
URL: http://nagiosplug.sourceforge.net/
Source0: http://dl.sf.net/sourceforge/nagiosplug/%{name}-%{version}.tar.gz
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)

Packager: IBM78M
Vendor: Nagios Plugins - Consejeria Turismo
Provides: nagios-plugins


%description
Nagios monitors hosts and services on your network. Actual host
and service checks are performed by separate plugins which return
the host or service status to Nagios. This site is devoted to
making the plugins as useful and reliable as possible.


%prep
%setup -q


%build
./configure --prefix=/usr/local/nagios
make %{?_smp_mflags}


%install
rm -Rf $RPM_BUILD_ROOT
make DESTDIR=${RPM_BUILD_ROOT} install



%clean
rm -Rf $RPM_BUILD_ROOT


%files
%defattr(-,root,root)
/usr/local/nagios/libexec/*
/usr/local/nagios/share/locale/*/LC_MESSAGES/nagios-plugins.mo


%changelog
* Wed Mar 26 2008 Ignacio Barrancos
- Initial build.

Ahora creamos el SRC.RPM mediante:
rpmbuild -bs nagios-plugins.spec

Una vez lo hemos creado (nos lo dejará en /usr/src/redhat/SRPMS/nagios-plugins-1.4.3-1.src.rpm), ya podremos crear el paquete binario:
rpmbuild -bb  SPECS/nagios-plugins.spec

Extraer ficheros de un paquete RPM sin instalarlo

Esta mañana he necesitado extraer ficheros de un paquete RPM que estaba en RH3 para RH4 ... ¿cómo se hace esto? ... pues está bien explicado en http://www.cyberciti.biz/tips/how-to-extract-an-rpm-package-without-installing-it.html. Es suficiente con ejecutar el siguiente comando:

rpm2cpio PAQUETE | cpio -idmv
Y nos deshará el paquete en el directorio actual.

Como cambiar la zona horaria a un Linux

Al actualizar el ESX a 2.5.3-Path14 me he encontrado con la hora del sistema que estaba mal. La he ajustado con nuestro servidor NTP interno, y tampoco, claro que ha sido entonces cuando me he dado cuenta de la zona horaria que estaba usando no era la de Paris/Madrid: ¿Cómo cambiar la zona horaria de nuestro servidor Linux?, pues siguiendo esta secuencia de pasos, que me he molestado en traducir.

  1. Primero, sacamos una copia del fichero actual, por si hubiera que volver atrás:
    mv /etc/localtime  /etc/localtime.old

  2. Crear un enlace simbólico a la zona que queremos que tenga nuestro servidor:
    ln -s  /usr/share/zoneinfo/Europe/Madrid  /etc/localtime

  3. Ajustar la hora con nuestro servidor...
     ntpdate ntp.carm.es

  4. ... y por último ajustar el reloj hardware, para que cuando reiniciemos el equipo, no hayan muchas diferencias de hora:
     hwclock --systohc

  5. Crear el directorio para el ajuste horario
     mkdir /var/lib/ntp/drift -p
    chown -R ntp.ntp /var/lib/ntp

  6. Actualizar el fichero de configuración para NTP, esto está en /etc/ntp.conf
    ## Indica que solo el localhost puede usar el servicio.
    ## Es la forma de indicar que no se quieren escuchar peticiones
    ## UDP, lo que nos convertiria en servidores tambien
    restrict default nomodify notrap noquery
    restrict 127.0.0.1

    ##
    ## Quien sera nuestra referencia horaria
    server ntp.carm.es # El NTP Corporativo
    server 127.127.1.0 # Nuestro reloj interno

    ## Nuestro reloj interno lo metemos en un stratum alto
    ## por si es que no estuviera disponible el Coporativo
    fudge 127.127.1.0 stratum 10

    ## Aqui se indica donde se escribe esa correccion.
    ## Normalmente se escribe un valor cada hora.
    ## OJO CON LOS PERMISOS DEL FICHERO.
    driftfile /var/lib/ntp/drift

    ## Sin autenticacion
    authenticate no
  7. Actualizar el fichero /etc/ntp/step-tickers, ejecutando:
     echo 'ntp.carm.es' > /etc/ntp/step-tickers
  8. Iniciar el servicio y configurar para que arranque con el sistema:
     /etc/init.d/ntpd start
    chkconfig --level 35 ntpd on
Luego, para saber si estamos si tenemos nuestro reloj ajustado o no, podemos ejecutar "ntpq -p".

Actualización de servidores VMware ESX 2.5.X

En mi nuevo lugar de trabajo, me he encontrado con un servidor VMware ESX Server 2.5.3 build-24171. He estado mirando en Internet y parece que se corresponde con la versión 2.5.3-Patch1. No es necesario explicar la necesidad de mantener estos sistemas actualizados. Para comprobar si existen actualizaciones pendientes de este producto, debemos acceder a http://www.vmware.com/download/esx/esx2_patches.html, y buscar nuestra versión. En nuestro caso, comprobé que existía hasta el parche 14. Lo descargué, leí atentamente las instrucciones que se indicaban y realicé la siguiente secuencia de pasos.

  1. Parar todas las máquinas virtuales que tuviéramos arrancadas en el servidor.
  2. Copiar el parche que me había descargado al directorio /tmp de nuestro servidor ESX.
  3. Como no tenemos una instalación del ESX desde la SAN, reinicio la máquina con la opción "linux" en LILO para evitar que arranque con el kernel de VMware (vmkernel).
    /sbin/lilo -R linux
    reboot
  4. Una vez haya arrancado la máquina, descomprimir el parche y lanzar la actualización
    cd  /tmp
    tar -xzvf esx-2.5.3-56529-upgrade.tar.gz
    cd esx-2.5.3-56529-upgrade
    ./upgrade.pl
Una vez ha terminado la actualización nos preguntará, si queremos reiniciar el servidor. Responderemos que sí, y la actualización ya estará terminada. El siguiente paso, debería ser el de reinstalar VMware Tools en las máquinas virtuales que teníamos instaladas en el equipo. Sería bueno que antes de instalar nuevos sistemas, comprobáramos las notas de instalación y configuración que nos indican en la web de soporte de VMware, dependiendo del tipo de sistema que vayamos a instalar.

Trabajo sobre IDSes Wireless

Hace unas semanas que estuve investigando sobre IDSes Wireless y redes ad-hoc, para el trabajo de una de las asignaturas que estoy cursando en el Máster de la Universidad de Murcia, este año. Lo he subido a mi cuenta de GoogleDocs, porque parece que la publicación cruzada a mi Blog no me terminó de convencer y las entradas en el Blog quedan demasiado grandes a mi juicio, además de que los cambios que hago en el documento después de haber publicado en el blog no se refrescan automáticamente: Parece más práctico, publicar el documento y luego linkarlo desde una entrada en blogger.

Bueno el trabajo versa sobre la Detección de intrusiones en redes wireless y espero que les introduzca en la problemática, que considero muy interesante.

Overlay en OpenLDAP 2.2.13

El otro día Tomás me planteó estudiar la posibilidad de separar toda la rama LDAP donde almacenamos las CRLs de la FNMT en otro árbol separado con su máster y dos réplicas, y configurarles la alta disponibilidad a la lectura mediante nuestros balanceadores hardware de MZ. Para ello me sugirió usar el mecanismo de referral y overlay chain de OpenLDAP, basándose en una primera lectura del http://www.zytrax.com/books/ldap/ch7/referrals.html .

Con esto, pretendíamos sacar de los directorios de desarollo, pruebas y producción las CRLs (que ocupan bastante), ahorrando espacio y ganando flexibilidad y alta disponibilidad: Cuando tenemos algún problema de sincronización con la fábrica, nos resulta complicado parar el master de producción para resincronizar, porque no tenemos alta disponibilidad de escritura: si lo hacemos sin parada, debemos borrar todas las CRLs primero y hay un momento donde no existe ninguna CRL y cualquier certificado sería válido. Un follón. La posibilidad de tener las CRLs nos evitan esto, porque la escritura sólo se realiza dos veces al día, y podríamos parar en cualquier momento.

Investigué todo esto y me encontré que la documentación que me pasó Tomás era para versiones nuevas (2.3 y 2.4) de OpenLDAP. Desgraciadamente aún estamos en 2.2.13 que es la que viene con RHEL4 update2, pero afortunadamente podemos usar overlay chain con la documentación del producto. Encontré las siguientes cosillas sobre overlays y esta versión de openldap, como que podemos saber los overlays que disponemos mirando las páginas man de los módulos que tenemos instalados:


rpm -ql openldap-servers | grep man | grep slapd-
En concreto, toda la documentación del "overlay chain" está disponible en slapd-ldap (man slapd-ldap). Para configurarlo, lo primero que tendremos que hacer será preparar un nuevo árbol con toda la estructura y datos que queremos sacar para darle mayor disponibilidad. Este árbol lo colocaremos en 192.168.1.170 por ejemplo. Luego en el árbol que queremos que tenga la referencia al nuevo (que llamaremos árbol B), deberemos añadir una entrada como la que se muestra a continuación:

dn: o=FNMT,c=ES,dc=RegionMurcia,dc=es
objectClass: referral
objectClass: extensibleObject
o: FNMT
ref: ldap://192.168.1.170/o=FNMT,c=ES

Esta entrada crea un objeto referral o:FNMT en la rama c=ES,dc=RegionMurcia,dc=es, de manera que los objetos que deberían colgar de esta rama, en realidad no están ahí sino en la rama equivalente del árbol 192.168.1.170. Probé a usar otra rama en el árbol 192.168.1.170 (llamaremos árbol A), por ejemplo “o=FNMT,c=ES,dc=CARM,c=es”, pero luego me obligaba a usar el overlay de rewrite (mirar man slapd-meta) para ir reescribiendo todos los DNs en los varios contextos de operaciones LDAP, y finalmente no me atreví por temor a que mis reglas rewrite se olvidaran de contemplar algún caso que en el futuro me generara problemas: Si no queremos complicarnos, lo mejor es dejar la misma estructura que teníamos en B en el nuevo árbol A.

Luego en la configuración del árbol B (/etc/openldap/slapd.conf), justo antes de la sección donde declaramos las réplicas, añadiremos:
# Referral sobre LDAP A
overlay chain
uri ldap://192.168.1.170
binddn "cn=admin,dc=RegionMurcia,dc=es”
bindpw secret
Tenemos todas las opciones configurables en la página man slapd-ldap. Reiniciamos el servicio en árbol B. Debemos asegurarnos de haber añadido en /etc/openldap/ldap.conf (que guarda la configuración del cliente OpenLDAP del equipo):
DEREF always
Después de esto, ya podremos lanzar la prueba:
ldapsearch –x –h IP_de_B
-D “cn=admin,dc=RegionMurcia,dc=es”
-w secret
-b “o=FNMT,c=ES,dc=RegionMurcia,dc=es”
Observaremos como se trae la información desde el directorio A. Luego lo probamos con las aplicaciones clientes en Java y PHP y no nos funcionó. ¿Por qué? … Asumimos que en ambos casos se debe a que por defecto, los clientes, no establecen el “DEREF always”, y hay que establecerlo de forma manual.
Solicité el código Java que hacía el bind al OpenLDAP y descubrí que usaban el objeto LDAPConection . La conexión real se hacía en la llamada al método bind() con tres parametros: IP_Servidor, Login, Passwd. Si miramos la documentación, comprobaremos que existe otro método bind que en vez de 3 espera 4 parámetros. El cuarto argumento es un LDAPConstraints. La API indica que tiene un método llamado setReferralFollowing que por defecto es false, y que hace que los objetos referrall se sigan como si fueran enlaces simbólicos, como bien se explica en la documentación de la API.

Esta mañana (28/Feb/2008) hemos vuelto a intentarlo y lo hemos conseguido usando la conexión a través de JNDI y usando como url ldap://servidor:puerto/????deref=always en la inicialización del parámetro URL de la conexión. Me he inspirado en el código de http://iubio.bio.indiana.edu/biogrid/directories/ldapsearch.java .