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