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!