Nuestro funcionamiento es muy sencillo, creamos una máquina virtual, generalmente ubuntu, esta maquina se arranca y se le ofrece conexión remota al profesor. Una vez que está todo listo, se replica la imagen a los demas equipos para que los alumnos lo tengan todo listo.

Con esto nos ahorramos mucho tiempo de configuración, puesto que no tenemos que ir equipo por equipo, ni hacemos venir al profesor (sobretodo si son cursos europeos o similares)

Bueno, pues hasta la semana pasada todo iba correcto, trabajamos con el Player version 2, las imagenes hacian NAT sobre el cliente base (tambien conocido como Dom0) y al estar esto por NAT la ip era auto asignada. Recordemos que haciendo Bridge necesitarmos tener una ip diferente para el dom0 y para la imagen.

El caso… por algun tipo de movimiento de la gente de Vmware han decidido que la utilidad vmnetcfg no esté disponible así como así.

Pues bien, por circustancias de la vida, y en concreto una imagen de CentOS que usamos para un curso de Schrödinger nos fue necesario actualizar a  la versión 3… y oh sorpresa… nos quedamos sin esta utilidad.

Pues bien… parece que la cosa tiene solución, en concreto 2 posibles, por un lado utilizar los paquetes de la version 2.5 (aunque si actualizasteis como yo, adios paquetes)… o la más comoda, que es extraer el contenido del paquete de instlación del player3.

En concreto lo que yo hice fue lo siguiente:

ejecutar cmd (INICIO -> EJECUTAR -> Teclear(CMD))

Teclear(vmware-player-version.exe /e Directorio_temporal)

Con esto hemos desempaquetado (extraido) el contenido del instalable en Directorio_temporal.

Ahora nos desplazamos hasta ese lugar, una vez dentro podemos ver un fichero estilo network.cab, pues bien, lo descomprimimos (yo he usado winrar).

Una vez descomprimido, hoh sorpresa ficherito vmnetcfg.exe (ademas con icono nuevo)

Ahora solo falta moverlo al directorio de nuestra instalación del Player y ya lo tendremos.

No entiendo muy bien este moviemiento de VMware, de si disponer de dicha aplicación pero que no sea disponible en la instalación… pero bueno, mientras sea asi de “sencillo” disponer de ella.

Como podeis ver, la idea es muy sencilla, VACAS!

Pues, eso, HP ha presentado esta solución, montar un CPD, o un Data Center, al lado de una campinha repleta de vacas, aprovechando el biocombustible (lease mierda, ya tratada) para generar energia, que por un lado sirve para el propio CPD y por otro lado sirve para para las operaciones diarias de gestión, tanto las de extraccion de la leche, como las del propio CPD.

Tambien se aprovecharia el calor residual del cpd, para procesar el biogas, haciendo util el residuo principal de un CPD.

Como podeis ver, es simplemente cerrar el circulo, conseguir ademas ser autosuficientes, aunque a la larga se presentan nuevos gastos de manutención del cpd, como veterinarios… jeje

la idea, como mínimo curiosa.

Se trataba de explicar como algunas aplicaciones influyen en la forma de gestión y en la vida laboral de una persona, en este caso de un tecnico de sistemas HPC.

Pero esto presenta un pequeño problema, sobretodo si hacemos una instalacion mínima y luego queremos meter más paquetes. Existen varias soluciones, la primera seria activar NAT entre los nodos y el frontal, pero esto a mi forma de ver, supondria un posible fallo de seguridad a la hora de tener esa conectividad que desde un principio no quisimos.

Por otro lado, podemos crearnos un repositorio local, y que cada nodo acceda a el, pero… esto da demasiado trabajo para unos nodos que una vez actualizados o configurados, no vamos a querer seguir actualizando (por lo menos creo que lo recomendable no es seguir actualizando o haciendo upgrade de los mismos (como del kernel) ) Recordar que en caso de haber realizado esto, es recomendable que tengais el rollback activado para poder volver atrás y no perder mas de un dia de trabajo.

Hoy os voy a hablar de la forma más sencilla que conozco de tener siempre disponibles paquetes para instalar, y que no sea por RPM a mano (por lo tedioso que puede ser hacer rpm -Uvih y seguir dependencias de paquetes). La solucion es que yum busque en nuestro sistema local, en concreto en una imagen del DVD que nosotros le indiquemos (que será la misma imagen de la version instalada)

Lo primero es tener una imagen, con una iso nos llega, en concreto yo tengo una img del dvd de centos. Para facilitar y ahorrar espacio, lo que tengo es dicha imagen en una carpeta compartida por todo el cluster, generalmente /opt o incluso /home

Lo primero, necesitamos que nuestros nodos tengan el paquete createrepo, este paquete nos permite, como su nombre indica, crear un repositorio. Por suerte este paquete no tiene dependencias por lo que podemos descargarlo de un ftp e instalarlo a mano, aunque yo os recomiendo los siguientes pasos

Lo primero es tener instalado el paquete createrepo en cada uno de nuestros clientes, lo podeis hacer siguiendo el tutorial de como descargar paquetes con yum

Ya con este paquete y con el dvd con la imagen, los pasos serian muy sencillos.

Paso 1. Montar la iso y crear la estructura
mkdir -p /mnt/iso/{1,2,3}
mount -o loop /path/de/la/imagen/centos.iso /mnt/iso/1

Paso 2. Crear el repositorio
cd /mnt/iso
createrepo .
yum clean all

Paso 3. Crear fichero de configuracion
vi /etc/yum.repos.d/iso.repo

[FicheroISORepositorio]
name=Centos 5.4
baseurl=file:///mnt/iso
enabled=1

Con estos simples pasos tendriamos ya yum funcionando en local y permitiendo instalar desde dvd.

nota: a veces aparecen mensajes como “bad id repo:” o algo asi, por lo general es por haber puesto simbolos raros, espacios en lugares extraños… una vez solucionado intentad hacer un yum update (luego decis que no a instalar paquetes) tendria que solucionarse.

Este post, es una guia rapida para poder hacer un download y así poder mover dicho paquete (y sus dependencias) a otro cliente donde lo  vamos a instalar (es recomendable por supuesto que el cliente final tenga la misma version o el paquete sea compatible)

La verdad esque es muy sencillo, lo primero instalar el propio pluggin

# yum install yum-downloadonly

Con esto ya tendremos las opciones necesarias para hacer un download de nuestro paquete sin necesidad de instalarlo. Ahora solo tendriamos que darle las ordenes correctas a nuestro yum, de la siguiente forma

# yum install nombre_paquete -y –downloadonly –downloaddir=/bag

Como veis, con esta orden, directamente nos descargamos el paquete “nombre_paquete” y lo guardamos en el directorio /bag, en caso de no poner –downloaddir el paquete se guarda en /var/cache/yum

Consecuencias… zas… servidor al carajo, el kernel que tenias optimizado para correr lustre esta KO, los paquetes dejan de funcionar por haber pasado de php4 a php5, y las aplicaciones que estan compiladas dinamicamente… bueno de esas ya ni hablamos… gaussian ha pasado a mejor vida…

Entonces estas personas… dueños y rooteros por bolsillo (si pagan tienen todo el derecho del mundo) recurren al principio basico de la vida, pagar de nuevo por un servicio…

Es aquí donde entramos en juego… tenemos dos opciones… reinstalar todo el cluster… (porque los rooteros lo intentaron en todo el cluster… por si acaso!) o haber pensado que esto podia pasar, y tener activado el rollback para yum.Por si no lo sabeis, la version CentOS 5 y por supuesto RedHat 5, Scientific Linux, y todos los derivados de RHEL tienen la opcion de activar rollback, con esto, simplemente, en caso de catastrofe (incluida catastrofe del yum, por actualizacion de python), podriamos indicarle a rpm que ponga todo como estaba en el ultimo momento bueno.

los pasos son muy sencillos y solo hay que editar 2 ficheros

echo tsflags=repackage >> /etc/yum.conf

echo “%_repackage_all_erasures 1 ” >> /etc/rpm/macros

desde este momento estas a salvo, de poder realizar un roll back.

Es importante decir, que si has metido la pata en la actualizacion… no va a servir de nada que actives el rollback, ya la cagaste…

Pero bueno… y para hacer este especie de time machine linuxero… pues facil, solo tienes que indicarle a rpm que quieres hacer, imaginemos que queremos recuperar el estado del 23 de febero

rpm -Uvh –rollback ‘february 23′

Por lo que he visto, tambien se le podria pasar valores como “yesterday” o incluso horas “23:40″ o en e formato “24 hours ago”

Lo que no tengo claro, es como funciona si has realizado una instalacion en Castellano… que por cierto… habria que matarte… un servidor en ingles SIEMPRE!

En nuestro caso, donde trabajo, tenmos 3 librerias de cintas lt0, cada cinta con una capacidad superior al Terabyte… lo que hace que tengamos muuuuchos datos guardados y muuuchos y muy diferente indole.

Conociendo esto, tenemos que ver que estos datos generan unos ficheros, que data protector llama, internal database filenames y que se guardan a nivel local donde reside el servidor.

Por defecto este fichero tiene un límite de 2G, en concreto de fnames.dat tiene un valor de 2097152 kB.

Pero… que ocurre cuando estamos haciendo un backup y tenemos el siguiente mensaje:

[12:1168] There is no more space in the Internal Database for filenames.

Claramente el principal problema es que directamente nos quedamos sin logs… dios… os imaginais un itAdmin o SysAdmin sin logs a los que recurrir… un kaos…

Pues la solucion es muy sencilla, se trata simplemente de aumentar o añadir tamaño extra a nuestro fnames.dat.

Este fichero se encuentra por defecto en la ruta /var/opt/omni/server/db40/datafiles/cdb

Es importante primero revisar si efectivamente nos quedamos sin espacio, para ello usaremos el comando “/opt/omni/sbin/omnidbutil -extendinfo” que nos muestra la informacion.

Os pongo un ejemplo de mi caso:

Base file “fnames.dat”:
Device               = /var/opt/omni/server/db40/datafiles/cdb
Number of extensions = 3
Maximum size         = 2097152 [kB]
Current size         = 2097152 [kB]
Extension file “fnames.dat1″:
Device       = /var/opt/omni/server/db40/datafiles/cdb
Maximum size = 2096128 [kB]
Current size = 2096128 [kB]
Extension file “fnames.dat2″:
Device       = /var/opt/omni/server/db40/datafiles/cdb
Maximum size = 2096128 [kB]
Current size = 2096128 [kB]
Extension file “fnames.dat3″:
Device       = /var/opt/omni/server/db40/datafiles/cdb
Maximum size = 2096128 [kB]
Current size = 2096128 [kB]
Maximum size with extensions = 8385536 [kB]
Current size with extensions = 8385536 [kB]

Como podeis ver, en mi caso el fichero ya habia sido aumentado hasta en 3 ocasiones, y siempre de 2 en 2 gigas

Pues ahora, unicamente necesitamos indicarle que genere otros 2 gb para poder seguir almacenando datos.

omnidbutil -extendfnames /var/opt/omni/db40/datafiles/cdb -maxsize 2048

Acordaros de poner la ruta si no disponeis del comando en el path.

Con este comando, generais un fnames.datX donde X es el numero incremental en relacion al ultimo, en nuestro caso, X corresponderá a 4

Realizando el comando anterior, “/opt/omni/sbin/omnidbutil -extendinfo”,

Base file “fnames.dat”:
Device               = /var/opt/omni/server/db40/datafiles/cdb
Number of extensions = 4
Maximum size         = 2097152 [kB]
Current size         = 2097152 [kB]
Extension file “fnames.dat1″:
Device       = /var/opt/omni/server/db40/datafiles/cdb
Maximum size = 2096128 [kB]
Current size = 2096128 [kB]
Extension file “fnames.dat2″:
Device       = /var/opt/omni/server/db40/datafiles/cdb
Maximum size = 2096128 [kB]
Current size = 2096128 [kB]
Extension file “fnames.dat3″:
Device       = /var/opt/omni/server/db40/datafiles/cdb
Maximum size = 2096128 [kB]
Current size = 2096128 [kB]
Extension file “fnames.dat4″:
Device       = /var/opt/omni/server/db40/datafiles/cdb
Maximum size = 2096128 [kB]
Current size = 0 [kB]
Maximum size with extensions = 10481664 [kB]
Current size with extensions = 8385536 [kB]

Si os fijais, ahora tenemos un fichero nuevo, y el valor de Maximun size es diferente al de Current size.

Quiero aprovechar este post, para que todos los que en algun momento perseguimos usuarios, podamos tener unos puntos básicos de partida.

Empezaré por los comandos más evidentes e ire avanzando un poco, como ya os dije, son comandos muy basicos pero que a veces se nos pasan de largo.

• ps -feaux : Este comando es el primero que cualquier administrador de sistemas tendrá a mano, rapidamente nos sale una lista en forma de arbol de todos los procesos que estan corriendo en la máquina local, este ejemplo nos sirve para saber si hay algun proceso huerfano, si existen procesos zombies consumiendo, etc…
• top : Otro tambien básico, un comando a pantalla completa, que se actualiza constantemente como si fuera filtrado por un watch, y donde nos muestra, entre otros, la carga del sistema (load, cpu, idle…). Con este comando claramente podemos saber la carga del sistema, podemos conocer la memoria que consume un proceso y tambien, por supuesto, la cpu.
• vmstat : Otra utilidad a la que solemos recurrir, nos muestra informacion de memoria e incluso centrada en bloques IO, paginas,… quizá mas tecnica.
• w : Es san básico que casi se me pasa, comando para saber quien (who) está conectado, sirve para saber si un usuario anda haciendo ssh a lugares donde solo se puede computar. En nuestro caso, los nodos de calculo no permiten ssh (algun dia os contaré entonces como va el asunto)
• tail : No es un comando tan tecnico como los anteriores, quizá sea mas generalista. Este comando nos muestra el final del fichero, en concreto las 10 ultimas lineas, aunque con opciones como -n 100 (100 ultimas lineas), o con la mejor -f (se queda esperando que alguien o algo escriba en el fichero) muy util si por ejemplo queremos ejecutar algo en una terminal y mirar si escribe en el fichero
• free : Memoria libre, asi de sencillo :) versiones actuales permiten la opcion -h (modo humano…) con lo que podemos verlo en Gigas o sino… siempre nos queda la opcion -k
• iptraf : Quizá la mas tecnica, esta la usamos para saber quien esta, por ejemplo haciendo uso extensivo e intensivo de la red, y por lo general saturando el nfs y afectando al resto de usuarios. Iptraf es un generador de estadisticas (que NO snifer) donde se nos muestra la suma total de paquetes o bytes que se estan moviendo por un interface de red.
• strace : O como ver las tripas de un proceso corriendo, se puede lanzar seguido de -p y un pid o con el comando a ejecutar. No os asusteis del cascoporro de cosas que sueltan, porque al final se termina entendiendo cuando crea y cierra ficheros y si esta haciendo output o no
• kill : Bueno… como su nombre indica, nos sirve para matar procesos, pero no solo eso, tambien nos sirve para parar, reencolar, y muchas mas opciones. Muy interesante

Como veis, son ideas generales, como siempre, utilizar el man o -help antes de cualquier comando que no tengais claro, porque la podeis liar parda… como hacer un kill -9 al pid 1

Os dejo tambien este enlace para informacion mas detallada.

http://www.cyberciti.biz/tips/top-linux-monitoring-tools.html

Bueno este post, es algo general para que tengais en cuenta a la hora de instalar “material de una asignatura”

En mi caso he tenido que optar por virtualizar todo, pero si tienes windows te aconsejo que hagas lo mismo, sobretodo porque cuando acabes el semestre (o cuando saques bd 2) solo tendras que eliminar la maquina y no desinstalar todo el informix y lo que te haya metido.

Pues bien, lo primero, trivial… vmware o simil, un windows (xp, en mi caso una iso que anda por ahí parcheada) y un keygen o lo que es lo mismo un serial de estos de gran volumen, como los de empresas o universidades.Para quien no sepa lo que es un serial, es el numerito que acompaña a la caja que te compras en la fnac o en pccity que pone “original” y que trae un numerito del estilo B77QF-DP27W-4H68R-72B48-78RPD

Pues nada, en mi caso la instalacion es automatica por lo que puedes aprovechar para leerte el temario de la UOC y tener a mano en tu delicious la url de la documentacion de IBM (http://publib.boulder.ibm.com/infocenter/idshelp/v115/index.jsp)

Efectivamente estamos usando la version 10 de Informix y la documentacion es la v11 pero tranquilos no cambia tanto :) por lo menos para el semestre y para esta asignatura, igual si le pillamos el gusto y queremos seguir con informix necesitaremos buscar o comprar una version mas actual de IDS

Una vez teneis ya windows, el proceso es muy sencillo, solamente hay que seguir las instrucciones que se os indican en el pdf que trae adjunto, pero vamos a tener una serie de consideraciones principales que es importante apunteis:

1. Nombre del equipo:
   • es importante que el nombre del equipo sea sencillo, en mi caso utilice PCTEST
2. Nombre de la Base de datos
   • nos va hacer falta en 2 configuraciones, segun los pdf od_PCTEST, para mi utilice IDSTEST
3. Podeis acceder directamente a los servicios en “inicio / Ejecutar ” y escribiendo services.msc, a mi me resulta mas cómodo.
4. Si al ejecutar el SQL Editor os da un fallo que hace referencia a dll es porque teneis que reiniciar! (si, windows es así)
5. Si haceis como yo, y en la primera vez que ejecutais marcais “Save for Future Sessions” no os asusteis, podeis cambiarlo en la aplicacion Informix Setnet32 en la pestaña “Host Information” que ya configurasteis con anterioridad.

Como veis la instalacion no tiene mucha chicha, pero si teneis cualquier duda y ni el pdf ni el consultor os dan la solucion, preguntad por aqui a ver si entre todos sacamos la duda.

Lo que suelo tener yo es todo a partir de /nagios/ así trato de tener toda la configuracion centralizada, y no depender de otros paths como seria con una configuración por defecto.

La idea principal es que Nagios realiza chequeos automáticos cada tiempo que tu le digas y en caso de que haya algun tipo de fallo, lo notifica tanto por e.mail como por beeper. Actualmente existen tambien plugins o addons para notificar por correo electrónico o incluso por jabber (alias gtalk)

Algo que he aprendido de este tiempo usando nagios, sobretodo teniendo en cuenta que controlamos mas de 2700 servicios en algo mas de 300 hosts,  es la necesidad de tener una estructura definida dentro de los ficheros de configuracion, en mi caso /nagios/etc/objetos.

Lo que suelo hacer y que os recomiendo es que creeis ficheros de configuracion para cada host por separado y para cada servicio, esto os facilitará luego hacer modificaciones.

Bueno, a grandes rasgos, Nagios es esto, un sistema de monitoreo web, facil de instalar, facil de gestionar, que soporta muchisimos addons y que tiene una comunidad de developers muy grande.

En proximos dias trataré de entrar mas a fondo sobre su configuracion, utilidad y addons como pnp4nagios o nagvis (este ultimo actualmente no lo uso, pero me acuerdo que en mi anterior trabajo quedaba muy mono jejeje)