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.

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

La situación es la siguiente, imaginemos que tenemos una red interna del estilo host.domain.age y queremos enviar correos, logwach correos de root o de crontab a nuestro correo corporativo que es del estilo user@subdomain.domainII.es y OH CASUALIDAD este correo es virtual, no se puede hacer ping internamente (ni externamente a subdomain.domainII.es) porque no lo conoce ni el tato.

Pues este HOWTO o guia  explica como conseguir que estos correos funcionen usando sendmail, y claro está que salgan para un servidor exchange (windows 2003) que ya se encargará de mirar a que corresponde lo de subdomain.domainII.es

Lo primero es hacer un pequeño truco, y hacer un forzado para que todos los correos que tengan que ir a subdomain.domainII.es pasen a narices por el servidor exchange, que mira tu por donde esta en el domain.age de nuestra red corporativa.

# cat /etc/hosts
127.0.0.1 localhost localhost.localdomain
10.1.140.x host host.domain.age
10.1.140.y exchange.domain.age subdomain.domainII.es

Podemos ver el “apaño” para que la ip 10.1.140.y sea la que corresponde a subdmain.domainII.es

Ahora nuestro sendmail.mc

#cat /etc/mail/sendmail.mc
divert(-1)dnl
include(`/usr/share/sendmail-cf/m4/cf.m4?)dnl
VERSIONID(`setup for linux’)dnl
OSTYPE(`linux’)dnl
define(`SMART_HOST’, `10.1.140.y‘)dnl
define(`confDEF_USER_ID’, “8:12”)dnl
define(`confTO_CONNECT’, `1m’)dnl
define(`confTRY_NULL_MX_LIST’, `True’)dnl
define(`confDONT_PROBE_INTERFACES’, `True’)dnl
define(`PROCMAIL_MAILER_PATH’, `/usr/bin/procmail’)dnl
define(`ALIAS_FILE’, `/etc/aliases’)dnl
define(`STATUS_FILE’, `/var/log/mail/statistics’)dnl
define(`UUCP_MAILER_MAX’, `2000000?)dnl
define(`confUSERDB_SPEC’, `/etc/mail/userdb.db’)dnl
define(`confPRIVACY_FLAGS’, `authwarnings,novrfy,noexpn,restrictqrun’)dnl
define(`confAUTH_OPTIONS’, `A’)dnl
define(`confTO_IDENT’, `0?)dnl
FEATURE(`no_default_msa’, `dnl’)dnl
FEATURE(`smrsh’, `/usr/sbin/smrsh’)dnl
FEATURE(`mailertable’, `hash -o /etc/mail/mailertable.db’)dnl
FEATURE(`virtusertable’, `hash -o /etc/mail/virtusertable.db’)dnl
FEATURE(redirect)dnl
FEATURE(always_add_domain)dnl
FEATURE(use_cw_file)dnl
FEATURE(use_ct_file)dnl
FEATURE(local_procmail, `’, `procmail -t -Y -a $h -d $u’)dnl
FEATURE(`access_db’, `hash -T<TMPF> -o /etc/mail/access.db’)dnl
FEATURE(`blacklist_recipients’)dnl
EXPOSED_USER(`root’)dnl
DAEMON_OPTIONS(`Port=smtp, Name=MTA’)dnl
FEATURE(`accept_unresolvable_domains’)dnl
LOCAL_DOMAIN(`host.domain.age‘)dnl
FEATURE(masquerade_envelope)dnl
FEATURE(masquerade_entire_domain)dnl
FEATURE(`mailertable’,`hash -o /etc/mail/mailertable.db’)dnl
MAILER(smtp)dnl
dnl MAILER(procmail)dnl
Cw10.1.140.y

En este apartado entre las muchas opciones que tenemos ( man sendmail.mc ) lo principal es definir un smart que será a donde enviemos nuestras cosillas y un Cw que es más de lo mismo. También le indicamos como es el nombre del dominio para que nos llegue al correo con ese nombre.

Aqui también podemos hacer un MASQUERADE para simular que los correos llegan de algún dominio en concreto.

Configuramos nuestra tabla de correos, esto es, a donde se mandará si se desconoce la dirección, esto por supuesto se hace para ejercer más presión a la hora de llegada de correos.

#cat /etc/mail/mailertable
subdomain.domainII.es smtp:[10.1.140.y]

Añadimos en nuestro fichero de acceso que hacer en caso de un correo para ese sitio.

#echo “10.1.140.y RELAY” >>/etc/mail/access
#echo “subdomain.domainII.es RELAY”>>/etc/mail/access
#echo “exchange.domain.age RELAY”>>/etc/mail/access

Por ultimo solo tenemos que reiniciar el servicio de sendmail para poder mandar correos

#service sendmail restart

Con estos escasos cambios tendriamos configurado nuestro servidor de correo para enviar a nuestra cuenta corporativa a traves del servidor exchange (que es el que conoce a que corresponde el dominio virtual)

Como los DNS de nuestra máquina desconocen que es subdomain.domainII.es tardará del orden de 4 minutos en llegar un correo, esto es muuuuucho tiempo, asi que mejor que configurar para que no use los DNS.

#cat /etc/mail/service.switch
hosts files
aliases files

#echo “O ServiceSwitchFile=/etc/mail/service.switch” >>/etc/mail/sendmail.cf

LISTO

Es importante tener en cuenta que los echo añadden al final de los ficheros, mucho cuidado de sobreescribir algún dato o borrar algo. Es muy recomendable tener una copia de seguridad.

Esta guia fue redactada usando CentOS y RedHat Enterprise 5, en distribuciones como Debian o Suse puede variar la configuración asi como los comandos a usar.

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!

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

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)

Pues os comento, el hosting que tenia decidio que no pagaba lo suficiente para tener copias en cinta, o algo asi… y claro los backup que ya existian estaban en el home… y mi home se perdio en algun rincon del mundo este que tenemos de 1 y 0…

Así que toca empezar de cero, pero bueno, he aprovechado y he puesto un diseño nuevo, a falta de poner de nuevo el nombre de druidacelta.net en la cabecera, y algunos pequeños retoques, ya puedo decir que estoy online

Para quien no me conozca me presentaré de nuevo (ya que el título es “empezamos” ). Me llamo Alejandro y soy tecnico de sistemas, trabajo mayoritariamente con sistemas HPC (high-performance computer) bajo linux, la verdad es que disfruto cada dia de mi trabajo, y a pesar de lo duro que resultan algunos, me motiva a seguir adelante.

Pero lo que de verdad me gustan son las motos, no por la velocidad (que tambien) sino por la sesación de ser libre en esos momento y poder disfrutar de cada curva. Puesto que actualmente es lo que mas me gusta, creo que la foto de mi moto en el hotel de Penitentes veteranos del 2009 es la mejor foto para poder empezar con todo esto.

Tambien me encantan las redes sociales, no solo por los botones y los diseños, sino por poder conocer gente que tiene las mismas inqueitudes que uno, y no hablo solo de redes como Facebook, sino de otras tan buenas (o mejores) como minube.com, twitter, linkedin,… seguro que vosotros ya me entendeis.

Pero bueno… a donde se va con todo esto… todo en la vida tiene un fin o una meta no? pues la mia está mas o menos clara, seguir aprendiendo y formandome para poder terminar en google Zurich, y quien sabe igual luego en Palo alto :)

Espero que en mayor o menor medida, este blog os aporte algo igual que me lo tratará de aportar a mi.