Shakaran

Mis más fieles lectores y no tan fieles visitantes de google han podido advertir que mi blog ha estado offline más de 10 días, aunque esto no es del todo cierto, ya que se podía acceder mediante el subdominio shakaran.quijost.com que me proporciona el servidor de hospedaje Quijost.com, las imágenes y css estaban vinculados a shakaran.es con lo que no se veía nada bien y la gente no sabía que podía entrar por ahí.

Mi problema, no era debido al hospedaje, sino no a los registradores de dominios. En concreto a los que gestionan los dominios .es y terceros.

El día 3 de marzo, mi blog quedo totalmente offline intentando entrar por shakaran.es, anteriormente tenia este dominio registrado con el plan de JovenesEnRed que te regalaban un dominio .es gratuito por un año. Cuando expiró, ya que el dominio en realidad estaba con Acens hice una transferencia de dominio a Godaddy.com.

Ya que en Acens tienen un panel muy deficiente para cambiar los servidores DNS y otras gestiones, incluso fallaba y tenía que mandar un email para que me lo cambiara el soporte. Esto fue hace meses, pero en godaddy en su momento tardaron más de 17 días en hacer la tranferencia y no se hizo, porque faltaba por confirmar por parte de nic.es la solicitud y a pesar de que el soporte de nic.es decía que estaba activada y el de Godaddy no, pues el uno por el otro, la casa sin barrer y todo una chapuza.

Decidí (obligado como última situación y viendo que pasaba el tiempo sin ninguna solución de las partes implicadas), reclamar la autoridad del dominio .es en nic.es y lo dejé sin agente registrador gestionando yo los dns a traves de nic.es que por cierto tienen incluso aún un panel más deficiente que acens y godaddy, con poquísimo nivel y detalle (y eso que es una empresa dirigida por el Ministerio).

Trás unos meses sin problemas, llegamos al 3 de marzo, que es donde se produce toda la cadena de sucesos desafortunados.

Por un lado, no carga el shakaran.es, por lo que mando un email a nic.es para que ver pasa y me dicen que esta funcionando correctamente. Yo confundido, empece a mirar si eran las DNS de Quijost, que estaban perfectas. Por lo que procedí a enviar otro correo y me contestaron con un:

Le informamos que el problema se debe a un cambio que han hecho los root servers de las zonas com/edu/net el 1 de marzo.

Si tiene un dominio (.es o cualquier otro) que tiene como dns servidores de dominios com/edu/net, y no tiene el registro A del servidor dns declarado en su zona, le habrá dejado de funcionar el dominio.

Esto ocurre porque verisign ha dejado de publicar el glue record de esos dominios para respuestas no autoritativas. Ahora lo que da es un referral, y si el host no esta creado en su zona, finalmente no resuelve.

Puede encontrar toda la información en el enlace: https://www.verisign.com/domain-name-services/domain-information-center/dns-behavior/

Tras leer el enlace y ver que yo no podía hacer nada, ni como proveedor de hospedaje, ni como propietario del dominio, les llame a su teléfono de atención al cliente de nic.es y una señorita no hacía nada más que repertirme casi el mismo texto del email, y yo insistiendo en que no podía modificar nada y que me pasará a un técnico. Su solución fue que esperara y que no me prometía nada ya que no tenían técnicos para eso y que me pusiera en contacto con verisign.

Esto ya me sonaba a mucha incompentencia, por parte de una empresa del estado español, aún asi escribi un mensaje a Verisign y estos igual me decian que era o de mi proveedor de hospedaje o del registrador de dominios, pero que ellos no podian ayudarme y no sabían porque mi dominio tenía un timeout!

Así que de nuevo toda la historia se repetia, en España los registradores de dominios son muy incompetentes y el panel de nic.es no deja configurar registros de tipo A, AA o AAAA y menos NS o glue record como decían en su propio email.

Por tanto desistí y tengo abandonado el dominio shakaran.es y he registrado el nuevo como shakaran.net  esperando evitarme problemas de nuevo y además me evito pasar por el yugo de nic.es de nuevo. Pero al menos que quede constancia de la incompetencia actual y como en los días que estamos es complicadísimo llevar una gestión de un simple dominio, que en realidad es una entradita en un servidor de internet con tu nombre entre millones.

El dominio shakaran.es que tengo parece ser que no funciona desde el día 3 de Marzo (es una larga historia, ya la contaré). Por lo que he tenido que cambiar y comprar el shakaran.net

Por lo que ahora podeís acceder a mi blog desde:

El cambio de dominio me supone la perdida de mucho pagerank y bastantes visitas y páginas indexadas por google, pero al menos mis lectores del feed (que no os afecta el cambio ya que la url es de feedburner) podreís seguir leyéndome que tengo bastantes entradas en el tintero.

La gestión de servidores es un tema apasionante, pero exige mucho control sobre los sistemas a administrar. Personalmente en la empresa de hospedaje que administro llamada Quijost necesitamos un riguroso control de los servicios para detectar cualquier mal funcionamiento o sobrecarga y obtener una solución de forma casi inmediata.

Uno de los principales problemas es la gestión de recursos de memoria en servidores con Apache y que por lo general suelen usar Cpanel.

Cpanel es un buen sistema de panel de administración, pero es muy exigente en recursos y a veces consume demasiada memoria llegando a colapsar sus propios procesos e invocando a daemons encargados de reiniciarlo.

El problema viene cuando Cpanel además provoca un mal funcionamiento de Apache o bien tenemos un exceso de consumo en servidor por algún efecto Barrapunto, Menéame, Digg, etc.

En esos casos Apache atenderá todas las peticiones posibles dada la memoria de la que dispongamos. Normalmente y como referencia unas 200 peticiones por segundo con 1 GB de RAM (aunque tened presente que esta cifra puede variar bastante según configuraciones y hardware).

Cuando el servidor se quede sin memoria, las peticiones no se atenderán incluso otros servicios como emails (exim) pueden colapsar. Para evitar estas situaciones, he desarrollado un script que se encarga de comprobar periodicamente mediante una tarea cron, los recursos del sistema, la disponibilidad de Apache y la memoria disponible en el servidor, para actuar en consecuencia y reiniciar si es necesario, además de notificar a los administradores y mantener un log.

El script llamado Apache Checker está escrito en bash y tiene el siguiente aspecto:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79

# Apache Checker: a script for check resources on apache servers
# Author: Shakaran (http://www.shakaran.net)
# License: GPLv3
 
# For CentOs servers require bc and mutt:
# yum install bc
# yum install mutt
 
# Uses:
# Add this script to a cron's task with crontab -e
# For example: For run the checking every minute
# */1 * * * * /apache_check.sh &> /dev/null 
 
# Exit immediately if a simple command exits with a non-zero status
set -e
 
# Number of current apache2 processes.
N_CURRENT="$(ps aux | grep apache2 | wc -l)"
N_MIN="1"
DESTINY_EMAIL="your-server-admin-address@domain.com"
USER=`id -un` # For example: root
HOST=`hostname`
USERHOST=$USER@$HOST
 
THRESHOLD=90 # Max threshold for restart apache
TOTAL_MEMORY=$(free | grep "Mem:" | awk '{print $2}')
REMAINING_MEMORY=$(free | grep "Mem:" | awk '{print $4}')
CURRENT_MEMORY=$(echo "($REMAINING_MEMORY/$TOTAL_MEMORY)*100.0" | bc -l)
 
MAX_NPROCESS_APACHE=5
NPROCESS_APACHE=`ps fu $USERNAME  | awk '/processname/ { x++ } END{print x}'`
 
if [ "$N_CURRENT" -lt "$N_MIN" ]; then
    apachectl restart
    echo "$HOST: The Apache process is not working and it has been restarted."
    echo "$HOST: The Apache process is not working and it has been restarted." \
    >> /var/log/apache_restarter.log
    SUBJECT="Script Apache checker: start"
    echo "$HOST: The Apache process is not working and it has been restarted." | mutt -s "$SUBJECT" $DESTINY_EMAIL
fi 
 
ps -fea | grep "/usr/sbin/apache2"
if test ! $? -eq 0 then
    apachectl start
    echo "$HOST: Apache has stopped and it has been reactivated."
    echo "$HOST: Apache has stopped and it has been reactivated." \
    >> /var/log/apache_restarter.log
    SUBJECT="Script Apache checker: restart"
    echo "$HOST: Apache has stopped and it has been reactivated." | mutt $DESTINY_EMAIL
-s "$SUBJECT"
fi
 
if [ $CURRENT_MEMORY -gt $THRESHOLD ]; then
    apachectl restart
    echo "$HOST: Restarted apache on `date +'%Y-%m-%d %H:%M:%S'`. RAM utilization at
${CURRENT_MEMORY}%"
    echo "$HOST: Restarted apache on `date +'%Y-%m-%d %H:%M:%S'`. RAM utilization at
${CURRENT_MEMORY}%" \
    >> /var/log/apache_restarter.log
    echo "Restarted apache on `date +'%Y-%m-%d %H:%M:%S'`. RAM utilization at
${CURRENT_MEMORY}%" \
    >> /var/log/apache_restarter.log
    SUBJECT="Script Apache checker: restart"
    echo "$HOST: Restarted apache on `date +'%Y-%m-%d %H:%M:%S'`. RAM utilization at
${CURRENT_MEMORY}%" | mutt $DESTINY_EMAIL -s "$SUBJECT"
fi
 
if [ `ps fu $USERNAME  | awk '/processname/ { x++ } END{print x}'`>
$MAX_NPROCESS_APACHE] then
    echo "$HOST: max number of apache process = ${MAX_NPROCESS_APACHE} `date
+'%Y-%m-%d %H:%M:%S'`. RAM utilization at ${CURRENT_MEMORY}% "
    echo "$HOST: max number of apache process = ${MAX_NPROCESS_APACHE} `date
+'%Y-%m-%d %H:%M:%S'`. RAM utilization at ${CURRENT_MEMORY}% " \
    >> /var/log/apache_restarter.log
    SUBJECT="Script Apache checker: max number of apache process"
    echo "$HOST: max number of apache process = ${MAX_NPROCESS_APACHE} `date
+'%Y-%m-%d %H:%M:%S'`. RAM utilization at ${CURRENT_MEMORY}% " | mutt $DESTINY_EMAIL
-s "$SUBJECT"
fi

El script esta basado en bash y ha sido probado en servidores GNU/Linux CentOs 5.4, pero debería funcionar en cualquier distribución que soporte bash. Como únicos requisitos necesita tener instalados los programas mutt (para enviar correo) y bc (para calcular datos). En CentOs puedes instalarlos con:

1

# yum install bc mutt

Además para su instalación necesitas añadir una tarea cron que ejecute el script periodicamente, por ejemplo para cada minuto, abre tu editor de cron con:

1

# crontab -e

Y suponiendo que pones el script en / escribe:

1

*/1 * * * * /apache_check.sh &> /dev/null

Nota: se asume que el usuario que ejecuta el script tiene permisos de ejecución para Apache y programas bc y mutt que se utilizan (normalmente root), de lo contrario no funcionará correctamente.

¿como funciona?

El script necesita que configures una dirección de envío para los mails de notificación, que puedes cambiar en el valor de la variable DESTINY_EMAIL.

La primera comprobación que hace el script es para evitar ataques DDOS en los que se intentan que Apache haga muchos procesos hijos y sature el servidor (esto puede ser limitado en Apache) pero por si hubiese alguna manera de que el atacante lo incrementara o superase, el script reiniciará apache en caso de que haya muchos procesos y de esta manera se pueda liberar memoria. Para establecer el numero minimo y máximo, se pueden configurar las variables N_MIN y MAX_NPROCESS_APACHE respectivamente.

La segunda comprobación consiste en comprobar si apache esta funcionando, por si hubiese colapsado podamos volverlo a su ejecución normal.

La tercera comprobación establece un límite de consumo de memoria en el servidor, para que en tal caso (suponiendo que es Apache en que la consume) se reinicie apache y se liberen recursos. Por defecto este limite es el 90% de memoria del servidor y puede ser cambiado con la variable THRESHOLD.

De esta manera se puede conseguir tener un servidor un poco más optimizado al uso de memoria y tener constancia de cuando se producen picos debidos a Apache.

El script lo libero con licencia GPLv3 para todos aquellos que lo necesiten y quieran hacer uso de él.

Puedes descargarlo comprimido aquí: Apache Checker (14)

Todas la mejoras, sugerencias, fallos y críticas son bien recibidas.

A veces es necesario saber cuantos PPA (Personal Package Archive) tenemos activados en los repositorios para visualizarlos posibles conflictos o simplemente tener constancia de ello.

Listarlos es muy sencillo, basta con poner en el terminal:

1

grep -i ppa.launchpad.net /etc/apt/sources.list

Por ejemplo, un salida en mi portátil otorion (a magmus lo tengo más tranqulito):

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43

$ grep -i ppa.launchpad.net /etc/apt/sources.list
# deb http://ppa.launchpad.net/synce/ubuntu intrepid main #Synce
# deb-src http://ppa.launchpad.net/synce/ubuntu intrepid main #Synce SRC
# deb http://ppa.launchpad.net/blueman/ubuntu intrepid main #Blueman Bluetooth manager
# deb-src http://ppa.launchpad.net/blueman/ubuntu intrepid main #Blueman Bluetooth manager source
# deb http://ppa.launchpad.net/tualatrix/ubuntu intrepid main #Ubuntu Tweak
# deb-src http://ppa.launchpad.net/tualatrix/ubuntu intrepid main #Ubuntu Tweak src
# deb http://ppa.launchpad.net/deluge-team/ubuntu hardy universe
# deb http://ppa.launchpad.net/gscrot/ubuntu hardy main
# deb-src http://ppa.launchpad.net/gscrot/ubuntu hardy main
# deb http://ppa.launchpad.net/bortis/ubuntu hardy main
# deb-src http://ppa.launchpad.net/bortis/ubuntu hardy main
deb http://ppa.launchpad.net/transmissionbt/ppa/ubuntu jaunty main
deb-src http://ppa.launchpad.net/transmissionbt/ppa/ubuntu jaunty main
# deb http://ppa.launchpad.net/tualatrix/ubuntu hardy main
# deb-src http://ppa.launchpad.net/tualatrix/ubuntu hardy main
# deb http://ppa.launchpad.net/fta/ubuntu hardy main #Firefox
# deb http://ppa.launchpad.net/fta/ubuntu intrepid main #Firefox Intrepid
# deb http://ppa.launchpad.net/openoffice-pkgs/ubuntu intrepid main #OpenOffice 3.0 Intrepid
# deb-src http://ppa.launchpad.net/openoffice-pkgs/ubuntu intrepid main #OpenOffice 3.0 src Intrepid
deb http://ppa.launchpad.net/themuso/ppa/ubuntu jaunty main #PPA pulseaudio Luke Yelavich
deb http://ppa.launchpad.net/blueman/ppa/ubuntu jaunty main
deb http://ppa.launchpad.net/ubuntu-mozilla-daily/ppa/ubuntu lucid main
deb http://ppa.launchpad.net/bisigi/ppa/ubuntu jaunty main
deb http://ppa.launchpad.net/synce/ppa/ubuntu jaunty main
deb-src http://ppa.launchpad.net/synce/ppa/ubuntu jaunty main
deb http://ppa.launchpad.net/openoffice-pkgs/ppa/ubuntu jaunty main
deb-src http://ppa.launchpad.net/openoffice-pkgs/ppa/ubuntu jaunty main
###deb http://ppa.launchpad.net/kow/ppa/ubuntu jaunty main
# deb-src http://ppa.launchpad.net/kow/ppa/ubuntu jaunty main
# deb http://ppa.launchpad.net/xorg-edgers/radeon/ubuntu jaunty main
# deb-src http://ppa.launchpad.net/xorg-edgers/radeon/ubuntu jaunty main
deb http://ppa.launchpad.net/webkit-team/ppa/ubuntu jaunty main
deb-src http://ppa.launchpad.net/webkit-team/ppa/ubuntu jaunty main
deb http://ppa.launchpad.net/markuz/ppa/ubuntu jaunty main
deb-src http://ppa.launchpad.net/markuz/ppa/ubuntu jaunty main
deb http://ppa.launchpad.net/chromium-daily/ppa/ubuntu karmic main
deb-src http://ppa.launchpad.net/chromium-daily/ppa/ubuntu karmic main
deb http://ppa.launchpad.net/ubuntu-tweak-testing/ppa/ubuntu karmic main
deb-src http://ppa.launchpad.net/ubuntu-tweak-testing/ppa/ubuntu karmic main
# deb http://ppa.launchpad.net/pidgin-developers/ppa/ubuntu lucid main
deb http://ppa.launchpad.net/rvm/libs/ubuntu karmic main #MPlayer Core Libraries
deb http://ppa.launchpad.net/telepathy/ppa/ubuntu karmic main #Empathy

La compresión de archivos tar.xz es muy eficiente debido a que es un tipo de compresión sin perdida con un alto ratio de compresión y entre algunos proyectos se esta empezando a usar ampliamente debido al ahorro de ancho de banda que supone al liberar nuevos programas.

Por defecto en Ubuntu, el compresor/descompresor de archivos tar.gz (antes conocido como LZMA) no esta instalado. Luego necesitas instalar el paquete xz-utils (desarrollado por la distribución Slackware):

1

sudo apt-get install xz-utils

Despues puedes descomprimir cualquier archivo tar.gz con file-roller o bien mediante terminal:

1

tar -JXf archivo.tar.xz