Después del cambio de rumbo de Redhat, orientándose al mercado empresarial y el fin de las versiones redhat con actualizaciones gratuitas; ésta empresa sigue siendo líder en el mercado de distribuciones Linux orientadas a empresas.
En esta sección listamos diversos artículos escritos y probados por nosotros relacionados con RedHat Enterprise y clones de éste.
El otro día un cliente mío tenía un problema en una máquina que le instalé hace unos dos años si mal no recuerdo. Ésta es la parte buena de linux, sencillamente la máquina funcionó haciendo su labor de servidor de mensajería por dos años. Pero algo ocurrió con el spamassassin (versión 2.54 creo que tenía) que llenó el disco.
Entré y ví lo viejo del software y le propuse actualizarle con un clon de RedHat para que tuviera algunos años más de actualizaciones, me dijo que ok.
Ahora, me daba pereza ir hasta donde él. Podía ir, pero tenía otras cosas que hacer, así que me dediqué a probar una forma de actualizar el RH9 a centos 3.6 pero vía internet, sin tener que estar donde el cliente ni insertar Cds
Éste método es válido para actualizar ya sea la versión 3.6 o las subsiguientes versiones de centos que puedan salir (3.7, 3.8, etc), solamente es de bajar los 2 rpm que sugerimos para 3.6 pero para las siguientes versiones que hayan.
Pasos previos
Lo primero a realizar es una pequeña revisión de seguridad, para determinar que no tengamos ningún troyano ni rootkits ni nada malicioso instalado en la máquina. Esto es importante porque normalmente los rootkits alteran el filesystem, ponen muchos archivos imborrables, que aunque podemos borrarlos a la larga, esto es un impedimento grave para continuar, porque si tenemos una máquina comprometida, a la final la actualización que hagamos muy probablemente termine contaminada por el caballo de troya o rootkit que teníamos previamente.
Si al acabar la revisión de seguridad nos indican que hay troyanos o algún malicioso por ahí metido, sugiero que no se proceda con la actualización y se instale desde cero el centos, así nos quitamos ese problema.
Sugerimos que use uno o los dos de estas variantes:
ó
chkrootkit -q
rkhunter --update
rkhunter -c
Y verificamos que no haya problemas en nuestro sistema.
De no haberlos, procedemos al siguiente paso que es preparar los paquetes del sistema actual para ser actualizados con yum.
Eliminación de paquetes del sistema actual
Bien, ahora hay que eliminar todo el contenido innecesario para evitar una actualización larga y demorada. Yo por lo menos elimino todo lo que tenga que ver con estos paquetes, que contenga estos nombres:
XFree86
gnome
mozilla
devel
font
gcc
cpp
java
fam
fbset
gstreamer
esto se hace por ejemplo con la cadena de comandos:
rpm -qa|grep gnome|xargs rpm -e
Posiblemente dará algunos errores de dependencia, hay que primero eliminar esas dependencias:
rpm -e paquete1 paquete2 ... paqueteX
después repetir:
rpm qa|grep gnome|xargs rpm -e
Si sigue diciendo de dependencias volver a eliminar esas primero y así hasta eliminar todo gnome
Proceder igual con XFree (rpm -qa|grep Xfree|xargs rpm -e), con mozilla, con los *devel*, cvs, r* (rsh, rlogin, etc) y con los *font*, yo también borro los gcc, cpp y demás utilerías para compilar como yacc, bison, flex, la idea es lograr una actualización rápida, después se pueden instalar nuevamente estos paquetes con calma.
Igual si consideras que algún otro paquete está de más, bórralo, recuerda que la actualización será online y que mientras más tenga que actualizar, más demorará en realizarse, por lo que repetimos e insistimos que debes eliminar los paquetes que estén de más en el sistema.
Esto quitará los paquetes del ambiente gráfico pues no lo uso para los servidores, puedes intentar actualizar con estos paquetes encima (XFree, gnome, kde, fam, etc) pero no te podré ayudar si algo falta. Prefiero quitarlos pues no hacen falta en un servidor. Además ya habremos quitado todas las herramientas de desarrollo que consumen un buen espacio y nos demoraría la actualización.
reconstruir la BD de rpm:
rpm --rebuilddb
Ahora que hemos eliminado paquetes innecesarios, podemos proceder a instalar el yum y a actualizar el sistema
Instalando yum y otras opciones necesarias para comenzar
Bueno, ya hemos hecho la mayor parte, y les aseguro que sí, en las dos páginas anteriores hemos resumido el 95% del trabajo de actualización.
Habrán personas que querrán venir directamente a ésta sección y comenzar la actualización sin oir, leer y analizar lo que hemos puesto en las anteriores, pero les repito a esas personas que apliquen lo que se pide en las dos secciones anteriores si no quieren fracasar miserablemente actualizando el sistema.
Ahora procedamos a hacer unos pasitos muy sencillos:
* Instalemos la clave GPG del centos, esto nos permitirá posteriormente que el yum pueda certificar que los paquetes que bajemos están correctamente firmados por sus autores:
rpm --import http://mirror.trouble-free.net/centos/RPM-GPG-KEY-CentOS-3
Si este mirror no funciona, usen otro mirror que tenga las claves GPG de centos, todos las tienen (www.centos.org para más información sobre mirrors)
* Bajar los rpm del centos-release y del yum, son los dos unicos paquetes que tendremos que instalar manualmente antes de proceder a la actualización.
wget http://mirror.trouble-free.net/centos/3.6/os/i386/RedHat/RPMS/centos-release-3-6.1.i386.rpm
wget http://mirror.trouble-free.net/centos/3.6/os/i386/RedHat/RPMS/yum-2.0.8-1.centos.7.noarch.rpm
Proceder a instalar ambos paquetes:
[root@mail root]# rpm -Uvh centos-release*.rpm yum*.rpm
Preparing... ########################################### [100%]
1:yum ########################################### [ 50%]
2:centos-release ########################################### [100%]
Listo, ahora procedamos a verificar las actualizacionesy a instalarlas de aceptarlas:
yum update
Los siguientes pasos se nos demorarán un poco, en dependencia del canal que tengan, este cliente tiene 64kbs y demoró unas 20 horas en total.
Hay que esperar un buen rato en lo que baja los encabezados de todos los paquetes de centos, al acabar verificará qué paquetes tenemos instalado y con cuáles los actualizará, y nos dará una lista de dependencias a instalar para que aprobemos (con y)
Si algo falla durante la ejecución del yum hay que ver quién y por qué falla y arreglar el problema, normalmente lo que hago es quitar el paquete que está fallando y si posteriormente lo requiriera, lo instalaría después de actualizado el sistema.
En ésta actualización que hice, no falló nada pues al eliminar decenas de paquetes (ver secciones anteriores de este documento) disminuí la posibilidad de interferencias o fallos entre ellos.
Bien, cuando acabe de bajar los encabezados, dirá algo así:
imlib-devel-1-1.9.13-13.4 100% |=========================| 4.0 kB 00:00
elinks-0-0.4.2-7.i386.hdr 100% |=========================| 3.8 kB 00:00
.
.
freetype-devel-0-2.1.4-4. 100% |=========================| 7.7 kB 00:02
dejagnu-1-1.4.2-10.noarch 100% |=========================| 8.7 kB 00:05
Resolving dependencies
.Dependencies resolved
I will do the following:
[update: lockdev 1.0.1-1.2.i386]
[update: openssh-clients 3.6.1p2-33.30.4.i386]
.
.
.
[update: pam 0.75-62.i386]
[update: slang 1.4.5-18.i386]
[update: ash 0.3.8-16.i386]
[update: diffutils 2.8.1-8.i386]
[update: sendmail-cf 8.12.11-4.RHEL3.1.i386]
[update: php-imap 4.3.2-23.ent.i386]
[update: openssl 0.9.7a-33.15.i386]
[update: freetype 2.1.4-4.0.i386]
I will install/upgrade these to satisfy the dependencies:
[deps: rpm-libs 4.2.3-10.i386]
[deps: beecrypt 3.0.1-0.20030630.i386]
[deps: ethtool 1.8-3.3.i386]
[deps: bind-libs 20:9.2.4-7_EL3.i386]
[deps: laus-libs 0.1-66RHEL3.i386]
[deps: tzdata 2004e-1.EL.noarch]
Is this ok [y/N]: y
Será una lista bien larga, pues actualizará TODOS los rpm que encuentre en el sistema. Nos está indicando que procederá a instalar esta cantidad de paquetes, que si estamos de acuerdo, si no están de acuerdo (¿y si no estás de acuerdo por qué llegastes hasta aquí?) presionan n y listo, no actualizan nada, sin embargo, no hemos venido tan lejos para estar en desacuerdo, ahora presionamos y y procedemos a bajar los paquetes.
Hasta este momento no ha pasado nada que no se pueda arreglar en el sistema, sencillamente ha bajado los encabezados del yum para tener una lista de paquetes a instalar, más nada. Y es más, ahora es que comienza la demora real, demorará VARIAS horas en dependencia del tipo de red que tengamos hasta bajar todos los paquetes los cuales una vez bajados serán instalados entonces.
El yum comenzará ahora a bajar cada paquete y darte tiempos estimados para que acabe de bajarlo, una vez bajado no es instalado, sino cuando todos los que tocan instalar estén abajo:
Downloading Packages
Getting lockdev-1.0.1-1.2.i386.rpm
lockdev-1.0.1-1.2.i386.rp 100% |=========================| 12 kB 00:02
Getting openssh-clients-3.6.1p2-33.30.4.i386.rpm
openssh-clients-3.6.1p2-3 2% | | 8.0 kB 01:04 ETA
.
.
.
A la final de las varias horas, veremos un resumen de que pudo instalar todo. Si algo fallara, proceder a resolver el conflicto, yo lo solucionaría temporalmente eliminando el paquete o paquetes conflictivos hasta lograr actualizar, una vez actualizado ahi los podría instalar de nuevo (los paquetes que puedan dar conflictos).
Al finalizar la labor de actualización dejará todito actualizado excepto el kernel, por alguna razón lo tenemos que instalar manualmente:
yum -y install kernel
Revisemos /etc/grub.conf y verifiquemos que el sistema arranca con el default kernel del centos (veremos al menos dos kernels instalados, el nuevo de Centos y el viejo de redhat 9). Grub cuenta desde 0, es decir, si el primer kernel que aparece en la lista es el de centos debemos asegurarnos que default esté en 0, para que así arranque el kernel de centos.
Ahi podemos proceder a reiniciar y esperemos que todo les vaya bien.
Yo reinicié remotamente el sistema y me trabajó muy bien, es más, antes de reiniciar me aseguré que los servicios fundamentales corrieran: service squid restart; service httpd restart; service sendmail restart; etc, etc
Si desea que le ayudemos a actualizar remotamente un sistema por favor contáctenos para ayudarle. Es una labor bien pesada que algunas personas requieren pero no tienen la experiencia ni el tiempo para hacerlo, nosotros le podemos ayudar a actualizar su sistema.
Conclusiones:
1. Es factible, totalmente fácil de actualizar de redhat 9 a un clon de redhat enterprise linux (Centos 3 en este caso).
2. Toma un tiempo el planificar la actualización, eliminar paquetes innecesarios y aunque parezca una pérdida de tiempo es el corazón de la actualización.
3. Deben analizarse cuestiones bien importantes si usted tiene paquetes adicionales a redhat como es oracle, informix, tomcat, algún panel de control como cpanel, ensim, etc, pues estos pueden requerir de trabajo adicional para realizar la actualización. Todos deben trabajar para Centos, pero los binarios seguro han variado, por lo que sugiero más bien desinstalar cualquier aplicación que no sea nativa de redhat y posterior a la actualización proceder a reinstalarla para redhat enterprise (centos es un clon y todo lo de redhat enterprise trabaja en él).
En este artículo veremos cómo actualizar los clones de redhat enterprise linux sin costo. Estos clones son Whitebox Enterprise Linux y CentOS ya sea en la versión 3 ó 4 de ambos.
Ambas versiones vienen con una forma muy simple de administrador de paquetes que se llama yum. El yum nos permite realizar actualizaciones diarias automáticas o manuales.
Actualización manual
Para realizar la actualización manual, la cual sugerimos que se haga al menos la primera vez y de ser posible una vez cada 15 o 30 días. Debemos poner el comando:
yum -y update
-y asumir que sí a todas las potenciales preguntas. Es bueno ponerlo porque sino se quedará esperando a que digamos Y a sus preguntas.
Update ejecuta el yum en modo de actualización.
La primera vez que ejecutemos el yum, este demorará un buen rato, en dependencia del tipo de conexión que mantengamos. En este tiempo bajará todos los encabezados de los paquetes que hayan para nuestro enterprise linux desde que el CD fué creado por el autor. A veces bajará unos 15 paquetes si es un respin o versión mejorada de nuestro enterprise linux. Si es una versión que quemamos o tenemos de hace unos meses o años, demorará mucho más tiempo pues tiene que bajar toditos los encabezados (headers).
La idea es que a la final, sea una versión que haya sido creada hace un día o varios años. Nuestro sistema tendrá exactamente todos los paquetes que debe actualizar y una vez bajados los encabezados, comenzará a bajar los paquetes a actualizar. Igual demorará un rato en dependencia de las actualizaciones que tiene que bajar y al final instalará estas actualizaciones.
Repetimos, la primera vez sugerimos hacerlo de esta forma manual para verificar que todo fue bien. Una vez actualziado el sistema con este yum, este quedará como nuevo, tendrá los últimos paquetes para nuestro sistema.
Un detalle, si por casualidad el kernel se actualizó durante esta corrida, debemos reiniciar la máquina para que arranque con el nuevo kernel. Cuando se actualizan los kernels es la única vez que debemos reiniciar la máquina. Si la actualización no incluyó al kernel entonces ya todo está trabajando con la última versión.
Actualización automáticas
mandar a ejecutar el servicio del yum:
chkconfig --level 2345 yum on
service yum start
Con estos dos comandos el yum ejecutará desde el cron una vez al día, si hay alguna actualización por instalar, la bajará e instalará automáticamente.
Increíblemente con estas actualizaciones podremos mantener nuestros clones de redhat enterprise linux actualizados y preparados para trabajar en ambientes de internet en los que se requiere al menos tener las máquinas actualizadas para evitar o al menos mitigra el impacto de un ataque.
Comentan que es factible actualizar también servidores de redhat enterprise linux con estos binarios de los clones. Pero nosotros no lo hemos probado.
Con esto un servidor de redhat con el contrato de actualización y soporte técnico vencido podrá seguir siendo actualizable.
Para más información sobre los clones por favor ver nuestro este artículo.
Diagnosticando problemas en el hardware
Seguro alguna vez nos ha pasado, la máquina tiene un problema de hardware. Los momentos más angustiosos que se pueden pasar administrando un servidor es cuando este tiene problemas en el hardware.
Sin embargo, debemos en efecto establecer que un problema muchas veces no depende de que un dispositivo (pieza o chip) no funcione correctamente por fallas de diseño, sino que muchas veces existen conflictos entre dispositivos de la máquina (colisiones con las mismas interrupciones, etc).
Uno de los síntomas más comunes de este tipo de problema son:
1. La máquina se apaga inesperadamente
2. La PC se queda colgada (congelada) sin responder al teclado o demás
3. Los discos duros comienzan a parpadear interminablemente, o al contrario, no se mueven en largos periodos de tiempo
4. El sistema comienza a dar pánicos
5. El sistema no obedece a comandos desde el shell
Planteamiento del problema
Expondremos un caso real de un servidor que es un clon de redhat enterprise (www.centos.org) que repentinamente deja de funcionar sin previo aviso. El servidor aloja aproximadamente 120 sitios web con sus usuarios (es un servidor de hosting) el cual tiene un disco duro de 80GB, una tarjeta de red realtek 8139 (rtl8139), 1GB de memoria RAM y el procesador Intel(R) Pentium(R) 4 CPU 2.80GHz.
La situación real, al momento de ocurrir el problema es que
* el servidor deja de responder a peticiones de casi cualquier tipo, sean http, smtp, pop3, imap, ftp o ssh.
* Cualquier tipo de conexión que se intente abrir al servidor termina dando timeout.
* El servidor no rechaza las conexiones inmediatamente, sino que hace como si intenta abrir, pero al poco tiempo da timeout la conexión.
* Si se hace un telnet al puerto 25 del servidor, por ejemplo, no obtenemos la tradicional bienvenida que nos da el smtp; en vez del tradicional:
telnet srv3.misitio.com 25
Trying zzzz.www.yyy.xxx...
Connected to srv3.misitio.com (zzzz.www.yyy.xxx).
Escape character is '^]'.
220 srv3.misitio.com ESMTP Sendmail 8.12.11/8.12.11; Fri, 1 Apr 2005 15:42:18 -0500
Obtenemos sólo el inicio (es decir, el demonio responde, pero no acaba abriendo la conexión), así:
telnet srv3.misitio.com 25
Trying zzzz.www.yyy.xxx...
Connected to srv3.misitio.com (zzzz.www.yyy.xxx).
Escape character is '^]'.
Es decir, no está abriendo la sesión correcta ni completamente.
Estimación de las causas del problema:
Lo primero que hay que hacer es un estimado de qué está causando este tipo de problemas en el servidor. Es decir, que es lo que nos parece que está dejando de funcionar.
Muchas personas tienden a confundir causas con consecuencias. Por ejemplo, el que se llene la memoria ram de una máquina no significa que solucionemos el problema agregándole más ram. Pues no hemos determinado la causa que puede ser en efecto que requiramos de más memoria, pero sin embargo puede ser un script usando memoria descontroladamente y el incrementar la RAM no la solucione. Sólo nos fijamos en que la memoria se llenaba sin ver más atrás.
Así que procedamos. Por el tipo de síntomas que estamos viendo en el sistema. Al parecer existen algunas causas, muchas con tremenda validez, y otras un poco dudosas:
1- La tarjeta de red no está funcionando 100% efectivamente por la cantidad de colisiones que se dan en la red.
2- La memoria RAM del servidor se llena, pues uno de los síntomas típicos de ram llena es que el servidor no logra abrir las sesiones completamente. Sin embargo cuando es problema de ram, salen algunas indicaciones sobre procesos que no se pueden abrir en los logs. No aparece nada en los logs.
3- El disco duro o la controladora han dejado de funcionar temporal o permanentemente, pues uno de los síntomas típicos de problemas con los dispositivos de almacenamiento es que no se logran abrir las sesiones y que no se logra listar directorios o ejecutar ningún comando estando en el shell. También cuando es problema de I/O, no se pueden guardar los logs.
Estas son las conclusiones preliminares de por qué el servidor está dejando de funcionar correctamente. Todavía no es momento de atacar cualquiera de los problemas sino de estudiar un poco.
Comencemos con el punto 1
1- La tarjeta de red no funciona correctamente
Este es un problema visible, que logramos determinar al ver las estadísticas en el comando “ifconfig”
Aqui un ejemplo real de la tarjeta (hemos cambiado la IP solamente)
ifconfig
eth0 Link encap:Ethernet HWaddr 00:0C:6E:C1:3A:8A
inet addr:zzzz.xxxx.yyyy.wwww Bcast: zzzz.xxxx.wwww.223 Mask:255.255.255.224
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:1875602 errors:0 dropped:0 overruns:0 frame:0
TX packets:2232760 errors:208 dropped:0 overruns:0 carrier:465
collisions:30 txqueuelen:1000
RX bytes:258344392 (246.3 Mb) TX bytes:2444720372 (2331.4 Mb)
Interrupt:10 Base address:0xf000
De toda esa información, lo más preocupante son dos errores:
carrier:465 errores. Esto normalmente significa que la portadora en el cable que conecta al equipo con el switch, está fallando y está dando errores. Puede deberse normalmente la causa a:
* el cable está dañado,
* el cable está viejo,
* la conexión de los puntos del cable tiene falsos contactos o
* el puerto del switch o de nuestra tarjeta de red están malos
collissions: 30. En un ambiente de red donde se maneje todo a base de switches (lo 100% comun en este momento en las redes) el servidor no debe tener ninguna colisión, por lo tanto hay que aclarar con el datacenter para que no nos pongan en un hub, sino en un switch decente que no genere colisiones.
Sin embargo, no es nuestra opinión que este es el problema por el que el servidor no responde, aunque puede ser un elemento que agudice la crisis, al tenerse que repetir paquetes, descartar paquetes, en fin trabajar con una red poco amiga. En todo caso, pedimos al proveedor que:
1. cambie el cable de red, y verifique que no tenga falsos contactos, y que tenga las medidas mínimas o máximas permitidas para cables 10baseT
2. De no funcionar el cable, que por favor, verifique que el server esté conectado a un switch y no a un hub y que el puerto del switch esté bueno. En todo caso que nos cambien de puerto para verificar
De no trabajar ninguno de estos dos arreglos, les solicitamos que manteniendo los dos cambios anteriores, procedan a cambiar la tarjeta.
3. Para poner las cosas peores, el proveedor no obedece a lo que le decimos (estamos en un ambiente de administración remota, el servidor en norteamérica nosotros en Ecuador) sino que procede a directamente cambiar la tarjeta de red por una 3com que supuestamente es mucho mejor.
El resultado del cambio fue que los paquetes con errores por causa de portadora (carrier) llegaban a ser casi los mismos que el total de paquetes procesados, lo que empeoró el asunto y nos demostró (?) indirectamente que parece que la tarjeta anterior no era la problemática sino que hay algo en el cable o el puerto. Posteriormente vuelven a poner la tarjeta realteck, realizan estos cambios a la vez (punto 1 y 2) y el problema de errores por carrier y colisiones se va.
Resumen para este punto: no se deben permitir colisiones en las tarjetas de red, ni errores de carrier. Cualquier otro error puede ser normal y deberse a condiciones propias de la red, y es más los otros errores a veces ocurren en ambientes de servidores congestionados o con muchos días activos (15, 30 o más días). Pero los errores por carrier siempre deben estar en 0 o muy cerca de cero si la máquina lleva varias semanas en funcionamiento (a veces pasa que falla la luz por un microcorte y sí falla el carrier pero uno o dos errores). Lo que no es normal es que una máquina con 10 o 30 minutos de funcionamiento ya tenga errores de carrier.
2- La memoria RAM del servidor se llena
Pues uno de los síntomas típicos de ram llena es que el servidor no logra abrir las sesiones completamente
Normalmente la memoria no se llena de repente, sino que se va notando que el servidor se va llenando.
Podemos monitorear la memoria RAM mediante el comando “free”, por ejemplo:
free -m
total used free shared buffers cached
Mem: 995 970 24 0 63 721
-/+ buffers/cache: 185 809
Swap: 1999 101 1898
¿Qué nos está indicando este comando? Para empezar, por mi parte no considero que tengo problemas con la memoria, veo que a simple vista está todo bien. Pero veamos los detalles:
El servidor tiene 1GB de Ram (reporta 995 pero está bien). De los cuales está usando 970 MB de memoria y tiene 24 libres (no es para asustarse, esperen!).
Estos 970 se pueden desglosar aproximadamente en:
* 63 MB buffers - son memorias de intercambio, que no son permanentes ni obligatorias tenerlas siempre
* 721MB cacheados - son páginas tomadas en algún momento del disco para ser servidas y que por su nivel de acceso el servidor ha decidido guardarlas en memoria para tener más rápido acceso, definitivamente es mejor acceder a la memoria RAM que no a disco; estas páginas pueden ser descartadas, desechadas en cualquier momento, no indican que la memoria está llena sino que el servidor como tiene memoria libre, ha ido viendo las páginas más solicitadas y las ha mantenido en memoria. Eso es buen síntoma.
* 185 de memoria core: Digámosle así, porque no tengo un nombre exacto. (eso de -/+ buffers/cache no me gusta). Esto indica cuál es la memoria que realmente el sistema está usando, tanto para el kernel como para los procesos que están corriendo e indica que es una memoria bloqueada que no puede ser descartada (como sí puede ser el buffer y el caché). Es decir, si esta memoria se acerta al total (995 en mi caso) preocupémonos!!! pues significa que el servidor en cualquier momento se queda sin memoria para asignarle a los procesos.
De swap, tengo 2 GIGAS (normalmente pongo la misma swap que ram, pero en este caso de prueba puse el doble). Y estamos usando 101 megas, no es nada de alarmarse sobre todo que es un momento bien popular para el servidor y hace que tenga algunos procesos que pueda swapear para tener un poco más de memoria core y para cache y demás.
En definitiva. No estamos usando más que 185 megas en RAM de 1GB que tenemos y 101 megas en swap de 2GB, no creemos que el problema sea por memoria llena.
Además hemos implementado un script que chequea cada un minuto la memoria y lo guarda a un archivo, así que cuando el servidor se cae y lo levantamos, verificamos el uso de memoria al momento de la caída, y definitivamente es super normal en ese momento.
Aquí el script:
#!/bin/bashecho "`date "+%d-%H:%M.%S"`" >> /var/log/memoria .log/usr/bin/top -bn1 >> /var/log/memoria .loguptime >> /var/log/memoria .logcat /proc/meminfo >> /var/log/memoria .logps fuaxww >> /var/log/memoria.lognetstat -na >> /var/log/memoria.log
Lo que hace es bien simple, lo ponemos en el crontab cada unos 2 minutos (o un minuto o 3, como deseen) y el scriptcito guardará en /var/log/memoria.log una serie de detalles como procesos corriendo, memoria en uso, tiempo al aire y procesos de red.
Este script no nos indica (en la última lectura antes de la caída) ni una cantidad inusual de conexiones de red ni tampoco un uso exagerado de memoria ni de procesador. Por lo que al implementarlo, pudimos descartar la teoría número dos que era que la ram se llenaba.
También hemos logrado descubrir que en los logs no se guarda nada en el periodo que el servidor deja de funcionar, como que no nos parece que sea un problema de red pues aunque no haya red sí se guardan los logs...
nos parece más bien la opción 3
3- El disco duro o la controladora han dejado de funcionar temporal o permanentemente
Es la tercera opción que nos queda, y además la resforzamos con la teoría planteada anteriormente de que el servidor no está guardando los logs a partir de que falla. Por lo tanto hacemos una prueba y es guardar los logs en un servidor remoto.
¿Qué logramos con esto? Bueno, si el problema es que el disco no está escribiendo en esos momentos, entonces los logs no se guardarán y no nos podremos enterar de lo que el kernel nos quiere indicar. Cómo lo resolvemos? Simple, no escribamos los logs a disco, sino que los podemos mandar a una máquina remota.
Atención, la conexión entre la máquina remota y la máquina con problemas debe ser estable y buena, de lo contrario, se perderán los logs. De ser posible que sea una conexión local, aunque en nuestro ejemplo lo hicimos con una máquina a miles de millas de distancia pero ambas con un excelente canal a internet (para eso revisamos la tarjeta de red no?!) Además, sugerimos que al acabar las pruebas que pueden durar algunas horas o días, quitemos el logueo remoto y pongamos nuevamente a guardar los logs localmente.
En la máquina que va a servir de servidor de logs (la máquina buena, la que sencillamente sabemos que el disco funciona) editamos:
vi /etc/sysconfig/syslog
Veamos la primera linea descomentada:
SYSLOGD_OPTIONS="-m 0"
Sencillamente agreguémosle: -r, esto sirve para que la máquina acepte conexiones UDP por el puerto 514 que es el de syslog. Recueden en caso de haber un firewall, abrir este puerto en UDP para la IP de la máquina con problemas.
así quedaría:
SYSLOGD_OPTIONS="-m 0 -r"
Ahora reiniciemos el syslog:
service syslog restart
con esto basta, nuestra máquina amablemente aceptará que logueen en ella remotamente. Ahora indiquemosle a la problemática (el servidor que nos está fallando) que mande los logs para allá. Editemos:
vi /etc/syslog.conf
*.info;mail.none;authpriv.none;cron.none[tab]/var/log/messages
authpriv.* /var/log/secure
mail.* /var/log/maillog
cron.* /var/log/cron
*.emerg *
uucp,news.crit /var/log/spooler
local7.* /var/log/boot.log
Muy bien, básicamente estamos diciendo aqui hacia dónde van nuestros logs, todos están yendo a algún lugar dentro de /var/log, esto es, al disco, y no es lo que queremos, queremos evitar escribir a disco pues tenemos la duda de que esté fallando. Cambiémos TODO y pongamos a loguear al servidor remoto (1.2.3.4 le llamaremos, es el que anteriormente configuramos para que aceptara conexiones remotas -r)
kern.* @1.2.3.4
#*.info;mail.none;authpriv.none;cron.none /var/log/messages
*.info;mail.none;authpriv.none;cron.none @1.2.3.4
#authpriv.* /var/log/secure
authpriv.* @1.2.3.4
#mail.* /var/log/maillog
mail.* @1.2.3.4
#cron.* /var/log/cron
cron.* @1.2.3.4
#*.emerg *
*.emerg @1.2.3.4
#uucp,news.crit /var/log/spooler
uucp,news.crit @1.2.3.4
#local7.* /var/log/boot.log
local7.* @1.2.3.4
service syslog restart
y listo, nuestra máquina no va a guardar los logs del syslog en el disco de ella, sino en otra (1.2.3.4 en el ejemplo, insisto porque conozco la mente del ser humano y no dudo que ya pronto me preguntarán por qué no funciona 1.2.3.4).
Miren en la máquina remota (1.2.3.4) y verán que ya comienza a recibir los logs de nuestra máquina problemática. Y ese es el objetivo.
Ahora vigilamos a que falle nuevamente el servidor nuestro y listo, nos pasó, falló, sólo repondía a los ping y a más nada.. así que vamos al servidor remoto y velos los logs (/var/log/messages en nuestro caso) encontrando un error sobre IRQ:
Apr 1 09:11:04 srv3 kernel: hda: lost interrupt
Apr 1 09:11:04 srv3 kernel: hda: lost interrupt
Apr 1 09:11:44 srv3 last message repeated 4 times
Apr 1 09:11:44 srv3 last message repeated 4 times
Apr 1 09:12:54 srv3 last message repeated 7 times
Apr 1 09:12:54 srv3 last message repeated 7 times
Eso sí NO nos gusta. Hay algo raro con las interrupciones. El disco no parece estar físicamente dañado pues no emite errores al syslog de daño, sino algo de interrupciones, colisiones con interrupciones. Normalmente esto se debe a una controladora de disco bien maluca o más fácilmente, que algún otro dispositivo está usando la misma interrupción que el disco.
Veamos las interrupcciones que hay en el sistema y quién las ocupa:
lspci -v
En mi caso sale mucha información, pero sobre todo veo un conflicto entre la controladora de disco y el audio:
00:1f.5 Multimedia audio controller: Intel Corp. 82801DB/DBL/DBM (ICH4/ICH4-L/IC
H4-M) AC'97 Audio Controller (rev 02)
Subsystem: Giga-byte Technology GA-8PE667 Ultra
Flags: bus master, medium devsel, latency 0, IRQ 10
I/O ports at e000 [size=256]
I/O ports at e400 [size=64]
Memory at e8181000 (32-bit, non-prefetchable) [size=512]
Memory at e8182000 (32-bit, non-prefetchable) [size=256]
Capabilities: [50] Power Management version 2
00:1f.1 IDE interface: Intel Corp. 82801DB (ICH4) IDE Controller (rev 02) (prog-
if 8a [Master SecP PriP])
Subsystem: Giga-byte Technology GA-8PE667 Ultra
Flags: bus master, medium devsel, latency 0, IRQ 10
I/O ports at
I/O ports at
I/O ports at
I/O ports at
I/O ports at f000 [size=16]
Memory at 20000000 (32-bit, non-prefetchable) [size=1K]
Ambos usan la misma interrupción, y eso sí que no es agradable. Si hay algo que no debe compartir interrupciones son el DISCO y la tarjeta de RED. Por lo tanto procedamos con las medidas, que deben ser:
1.
Eliminar desde el BIOS o físicamente cuanto dispositivo no estemos usando, estos pueden ser pero no se limitan a: unidad de floppy, puertos USB, tarjeta de sonido, modem, pci para VGA. Estos dispositivos normalmente no se usan cuando damos un servicio de hosting así que al quitarlos hacemos que no hayan conflictos de interrupciones.
2.
Verificar (viendo en /proc/dma) que no hayan situaciones con los DMA, en nuestro caso no las hay.
3.
Desactivar apm y/o acpi y/o apci en el grub. Esto se hace editando /etc/grub.conf y agregando lo siguiente en la linea que comienza con “kernel”
nousb apm=off acpi=off noapic
quedaría algo así (es un ejemplo, tomar la linea correcta del kernel de ustedes):
kernel /vmlinuz-2.4.21-27.0.2.EL ro root=LABEL=/ nousb apm=off acpi=off noapic
Conclusiones
No estamos indicando que estos pasos a seguir son la solución para todos los problemas en un hardware, sino que sencillamente estos fueron los pasos lógicos que seguimos, la determinación del problema y la causa de este.
Después de estas medidas, hemos logrado controlar las caídas del servidor y ya no son misteriosas.
Recomendaciones:
Bueno, increíblemente algunas empresas existen por ahi que compran la licencia de Oracle pero no se sienten con la motivación para adquirir actualizaciones de RHEL o de United Linux.
Aquí describimos de forma muy breve una variante que está probada que trabaja. Y te permite gastar en Oracle y ahorrar en actualizaciones de redhat. Oracle al momento no dá soporte para instalaciones hechas en clones de RedHat, así que haga este procedimiento a su propio riesgo.
El Sábado pasado me sucedió: un cliente quería que le instalara WBEL pero con oracle. No me molesté en preguntarle. Sólo tomé nota de los dos pasos que tuve que tener en mente:
1- Hacerle creer a oracle que está en un RHEL: ln -s /etc/whitebox-release /etc/redhat-release
2- Leer completamente el manualito de instalación de Oracle y seguir paso a paso TODAS las indicaciones que nos dá el manual.
Respecto al centos, ya viene con el directorio /etc/redhat-release, sólo hay que ponerle el texto exacto que viene en cualquier máquina de RHEL para que oracle se piense que está en un RHEL.
Ahora describiremos el procedimiento que seguimos para actualizar algunos redhat linux con un clon no comercial del Enterprise Linux Por todos es sabido que la empresa RedHat Linux decidió desde el año pasado descontinuar las versiones de Redhat Linux, estas eran bien populares por su facilidad de actualización y varios detalles más que están de más en discutir.
Redhat ofrece al momento dos alternativas:
1- Distribución de RHEL mediante la cual por un costo anual un poco alto, se pueden obtener actualizaciones
2- Distribución de Fedora que es altamente experimental y no ofrecen actualizaciones una vez que salga la siguiente versión (core) de fedora, y se comprometen a sacar una nueva versión cada 10 a 12 meses.
En internet, vivir sin actualizaciones es la muerte. Entonces las empresas tienen algunas opciones que deben valorar además de estas:
1- Pagar por las actualizaciones de RHEL que oscilan entre 300 y 2500usd o algo parecido.
2- Usar fedora en todos sus servidores y cada vez que salga un core nuevo, correr a actualizar estas máquinas con el nuevo core (muy improbable)
3- Dejar las cosas como están (100% posibilidad de que tengan un intruso en poco tiempo)
4- Usar fedoralegacy.org para poner actualizaciones a sus viejos redhat
5- Instalar alguna otra distribución, lo que implicaría un costo relativamente alto de aprendizaje, posibles downtimes, etc.
6- Instalar CentOS o mejor aún actualizar el viejo redhat a esta versión
Oh sí, otro detalle, CentOS es actualizado con la misma velocidad conque RedHat actualiza sus versiones enterprise, pues es sólo tomar los fuentes de redhat y recompilarlos. Bueno las actualizaciones no ocurren exactamente al momento que redhat libera las suyas, toma un tiempo más pues hay que bajar los fuentes compilarlos, probarlos, etc. Pero básicamente están casi al mismo tiempo las actualizaciones. Y lo mejor es que redhat liberará actualizaciones hasta Octubre del 2008 de su versión RHEL 3 que como ya dijimos es lo mismo que el CentOS.
Listo, vayamos al grano, la idea es tratar de actualizar el viejo redhat con el CentoS para tener una versión de redhat moderna y segura. ¿Cómo hacemos esto?
Existen dos variantes:
1- Copiar la configuración del viejo redhat y los directorios de usuario y sus mails a otra máquina y reinstalar desde cero el CentOS.
2- Actualizar el redhat con la versión de CentOS de una sin reinstalar ni tener que reponer los datos.
Yo acostumbraba a hacer el paso 1 pues es más seguro, sólo que entonces tenía que reponer los usuarios, sus claves, etc, /var/spool/mail y mil cosas más. Era un poco tedioso y lento y sobre todo hacía perder tiempo a los usuarios que tenían que esperar un buen rato para tener el sistema actualizado.
Hasta que el otro día me puse a leer en google cómo actualizar RH9 a RHEL y todos mencionan que no es soportada la actualización por parte de la empresa redhat pues ellos no quieren tener tantas llamadas de soporte de usuarios que actualizarían y se tropezarían con errores. Pero que existe una opción oculta que sí lo permite hacer.
Antes de que dé la opción indico en qué máquinas probé y qué pasos previos seguí:
Guardé por si acaso toda la información de /etc /var/spool/mail y /home en otra máquina, por si acaso.
He actualizado varios RH versión 9, y también de 7.2 y 7.3, pero estas (7.x) requieren de que se hagan ajustes a la configuración de ciertos servicios que han cambiado (por ejemplo httpd ha cambiado de 1.3 a 2 y posiblemente algunos más) pero no es muy problemático el ajuste lo he hecho y realmente es bien simple.
Los servidores que he actualizado varían desde servidores de firewall, hasta servidores de mensajería (sendmail, antivirus,e tc) y un servidor de hosting de un ISP con varias páginas web.
El procedimiento es el siguiente:
1- Insertar el primer CD de CentOS-3 (SOLO EL 3!!) y escribir: linux upgradeany Esta es la opción que se ocupará de actualizar CUALQUIER redhat que encuentre en el disco duro de la máquina instalado.
2- Revisar la integridad de los 3 CDs de CentOS, no quiero ni pensar qué pasaría si un CD está falloso y se queda la actualización a la mitad. Es más seguro hacer la revisión aunque demore al inicio.
3- Proceder a escoger el teclado, mouse e idioma
4- CentOS revisará las particiones que hay en el sistema y detectará una partición con redhat instalado que indicará que es desconocida. No importa, escojamos ésta. Le llama desconocida para indicar que hay riesgo de que falle algo, no importa, no fallará.
5- Indicará si deseamos actualizar el GRUB, digamos que sí (dejémosle en el valor conque aparece por defecto que es actualizar)
6- CentOS emitirá una advertencia de que actualizar desde un RHEL 2.1 es factible pero que otro tipo de versión no dan garantías.. no importa apretemos el botón de Yes (continuar)
7- CentOS revisará los paquetes que están instalados actualmente y comenzará a automáticamente actualizarlos con los paquetes de él, este proceso demora entre 5 y 30 minutos en dependencia del lector de CD que tengamos.. no pregunta nada.. no dice más nada
8- Al final, CentOS indicará que todos los paquetes fueron actualizados y que procedamos a reiniciar, sacamos el CD y reiniciamos.
Aquí la máquina deberá arrancar con el nuevo sistema, nuevo kernel y sus paquetes actualizados, sin problema alguno.
De existir problemas, debemos leer para resolverlos, la mayoría de los que puedan existir serán con RH 7.x y cambios en los archivos de configuración pero con RH 9 no he tenido que ponerle los dedos al sistema para nada, sencillamente comienza a funcionar de una, sin mayor complicación, increíblemente bien.
Como regla general, cuando se pregunte algo durante el proceso de actualización dejémoslo por defecto, así lo he hecho y así ha trabajado con varios RH9.
Si alguien desea, me puede contactar al (09)9246504 o al (02)3412402 para enviarle los CDs de CentOS para que lo use. Igual, si alguien quiere un poquito más de seguridad me puede contactar para ver cómo le puedo ayudar a actualizar el sistema. Pero repito, hasta el momento no me ha dado el más mínimo problema en actualizar.
Saludos y espero les ayude, seguro que sí, así no se tienen que preocupar por actualizaciones hasta el 2008, parece lejano, verdad?.
1. White Box Enterprise Linux (WBEL)
White Box Enterprise Linux fue la primera distribución en estar construída a partir de las fuentes de RHEL. El proyecto es patrocinado por la Biblioteca Pública Beauregard Parish de Louisiana, EE.UU., porque, como aclaran en su sitio, quedaron librados a su propia suerte cuando Red Hat cambió su modelo de negocios, con varios servidores y más de 50 estaciones de trabajo con Red Hat Linux.
El objetivo de White Box Enterprise Linux es proveer una distribución lo suficientemente compatible con RHEL 3.0 como para permitir fáciles actualizaciones con las correcciones oficiales que Red Hat se comprometió a liberar para ese producto hasta el año 2008.
Los creadores del WBEL no agregan paquetes adicionales que puedan diferenciarlo del RHEL, no hacen nada por actualizar paquetes fuera de los que redhat actualiza para su RHEL, es decir, son idénticos al RHEL.
Con su versión 3.0 Liberation de 3 .ISOs lanzada en Diciembre del 2003, el proyecto White Box tiene también su propia y muy activa lista de correo, además de una completa documentación de su proceso de construcción. Al momento tienen lo que llaman un respin, el respin2 liberado en marzo del 2005 con actualizaciones hasta esa fecha.
WBEL también liberó su versión 4, que es un clon de RHEL 4.
Con un patrocinador estatal y con la ventaja de haber arrancado primero, White Box tenía quizá el futuro más promisorio de los clones. Sin embargo, este clon ha tenido y tiene dificultades para actualizar de una forma ágil desde los fuentes de redhat. A veces demoran varios días, hasta semanas en liberar una actualización, por lo que muchos administradores y usuarios habituales, con necesidades de actualizaciones rápidas han preferido no usarles y cambiarse al CentOS. A propósito, el cambio entre clones de redhat es sumamente fácil. En el sitio de centos hay un howto sobre cómo actualizar de wbel a centos en pocos momentos. Tomar en cuenta que este howto habla de la migración a centos 3.3, tomar un paquete más actualizado para un centos más nuevo.
Sitio web: http://www.whiteboxlinux.org
2. CentOS
CentOS, mantenido por la comunidad cAos, está construído a partir de las fuentes de RHEL y creado para mantenerse tan compatible con él como sea legalmente posible. Esto último, también para asegurar su compatibilidad con las correcciones y actualizaciones que libere oficialmente Red Hat.
CentOS no mejorará ni extenderá por su cuenta lo proveído en los paquetes fuentes oficiales de RHEL, prometiendo entregar sólo un clon compatible a nivel binario.
A pesar de esto último, CentOS mantiene un repositorio de paquetes extras y ajenos a RHEL, accesible a través de repositorios yum, de una manera similar al proyecto Fedora. La arquitectura x86 tampoco será la única soportada, IA64, x86_64 (AMD64) también están en la lista así como Alpha que es una arquitectura creada sólo por colaboradores de CentOS.
CentOS-2, una versión de CentOS basada en RHEL 2.1 también está disponible. Mirrors con las ISOs de CentOS-2, CentOS-3 y CentOS-4 pueden encontrarse listados en su sitio.
CentOS-4 es una recompilación de los fuentes de RHEL4 y se ofrece para diferentes arquitecturas igualmente.
CentOS ofrece sus CDs con el mismo estilo que redhat hace, es decir, los CDs los recrean cada cierto tiempo para incluir sus últimas y evitar la tarea de actualizar un sistema desde el mismo inicio. En vez de llamarles respin como WBEL, usan una filosofía similar a la de RHEL, le agregan un número adicional, por ejemplo Octubre del 2005 el último juego de CDs es el CentOS-3.6 y para el caso de la versión 4 es el CentOS 4.2 que contiene todo el CentOS pero con todas las actualizaciones hasta Octubre del 2005. Evitándonos de esta forma bajar paquetes que están actualizados desde hace tiempo. CentOS también se ofrece en DVD y en una versión corta llamara Server, que contiene sólo los paquetes necesarios para instalar un servidor y cabe en un sólo CD.
Las actualizaciones y CDs de CentOS están distribuídas entre varios servidores ofrecidos la mayoría de forma voluntaria por muchos administradores interesados en que se mantenga viva la idea. También aceptan donaciones 12USD para el que quiera ayudar a mantener el proyecto.
Esta es la distribución que estamos usando al momento nosotros. También muchos proveedores de servidores ofrecen instalar CentOS en los servidores que se arriendan y muchos paneles de control también se ofrecen ya para servidores CentOS. En artículo aparte pondremos nuestra experiencia con el bluequartz que es un panel de control gratuito.
Lineox Enterprise Linux es el producto de una empresa finlandesa del mismo nombre, y al contrario de CentOS, se enorgullecen de haber modificado las fuentes de RHEL 3.0 para producir su distribución. Como resultado, en ella se incluyen paquetes de RHEL Advanced Server (AS), Entry/Mid Server (ES), Workstation (WS), Red Hat Cluster Suite, Red Hat Developer Suite, y otros como OpenOffice 1.1.
Pero por supuesto, si sumamos todo lo anterior, tenemos una distribución que se distribuye como 5 imágenes .ISO de DVD-ROM (!). Afortunadamente, en su sitio se explica cómo hacer una instalación de red de Lineox Enterprise Linux, usando un mínimo CD-ROM de arranque. Sin embargo, aún hay que bajar los 5 DVD-ROMs...
Lineox ofrece un sistema de actualización de paquetes para su Enterprise Linux, con los lanzamientos oficiales de correcciones y actualizaciones de Red Hat para RHEL 3.0, basado en un sistema de activación, como el servicio de actutalización de Red Hat Network de Red Hat 7.x. Por el momento es gratuito, pero la empresa espera cobrar una cuota anual próximamente.
De igual manera, un servicio de actualización automático de paquetes para Red Hat Linux 7.x, basado en los paquetes de RHEL 2.1 también está disponible gratuitamente. Pero otra vez, pronto se implementará una cuota anual para este mismo servicio.
Al implementar un costo anual y modificar los fuentes de redhat, ya no se me parece tanto a RHEL, repito, no quiero una distribución diferente sino un RHEL gratis, algo que sea idéntico, muy idéntico. No la uso tampoco por eso.
Sitio Web: http://www.lineox.com/
4. Tao Linux
Tao Linux es, ahora por lo menos, un proyecto unipersonal basado en los paquetes fuentes de RHEL 3.0, que su mismo autor aconseja no instalar en servidores críticos. La iniciativa para Tao Linux nació de pura necesidad personal, pero sus frutos ya pueden descargarse como sendos .ISOs, listos para fomentar una comunidad de usuarios a su alrededor.
El autor de Tao Linux promete construir los binarios de las actualizaciones oficiales de RHEL y ponerlas a disposición vía yum, pero quienes no quieran confiarse sólo en éso pueden encontrar en su sitio todas las instrucciones para hacer ésto mismo por propia cuenta.
Sitio web: http://www.taolinux.org/
Conclusiones
Todas estas distribuciones hacen grandes esfuerzos por aclarar su total independencia de Red Hat Inc., y su apego a las bondades de la licencia GNU/GPL.
Todas son producto de su correcta aplicación, y demuestran una vez más la adaptabilidad de la comunidad del Software Libre para asegurar el soporte de sus propios usuarios.
Su mera existencia prueba que no será difícil encontrarnos más adelante con aún más alternativas, y que los actuales usuarios de Red Hat Linux no deben desesperar ni apresurarse a Fedora.
Quizás sea demasiado temprano para aventurar la suerte de cualquiera de las distribuciones mencionadas, o hasta sugerir una sobre otra para ocupar el difícil lugar de un viejo y confiable Red Hat Linux.
Si necesitáramos de actualizar un servidor redhat viejo.. y mantenerlo actualizado mucho más allá de Fedora, sugeriríamos en este orden: CentOS, WBEL