tail -f | sysadmin » servicios

Sencillo parser para Apache mod_status en Python

elbarto — Sun, 31 Jul 2011 01:01:46 +0000

Cuánto hace que no actualizo este blog!! Hoy estuve jugando un poco con Python y me puse a hacer un pequeño script que supongo que a otros les podrá servir como base para hacer algo más interesante. Precisamente, tengo planes para hacer algo más interesante, pero como recién están en veremos, les voy pasando esta pequeña base a ver si alguien me gana de mano

Como muchos sabrán, Apache (y otros web servers) tiene un módulo llamado mod_status que nos permite ver en tiempo real el estado del servidor (los requests que se están procesando, el uso del CPU, el estado de las conexiones, etc.). Esta información puede ser muy útil para hacer diagnósticos cuando está habiendo algún tipo de problema, para hacer monitoreo, etc. El módulo nos muestra una página web con la información y tiene dos interfaces: una está pensada para ser vista por seres humanos y otra para ser consultada por scripts (para ver esta segunda sólo hace falta pasarle el parámetro “?auto” en la URL). El problema es que esta segunda interfaz no nos muestra a qué dominios (virtual hosts) están dirigidos los requests que se están procesando (o si hay forma de que lo muestre yo no la encontré). Entonces me puse a hacer un sencillo script en Python para parsear la página “para seres humanos”.

Por suerte Python nos ofrece muchas herramientas muy útiles para este tipo de cosas, así que no me tuve que esforzar demasiado. En este caso utilicé urllib2 para acceder a la página de mod_status y BeautifulSoup para parsear el HTML. Por si no lo conocen, BeautifulSoup es un muy poderoso parser para XML/HTML hecho en Python. No viene con el código fuente sino que hay que instalarlo, pero hacerlo es muy fácil:

En Debian/Ubuntu:

apt-get install python-beautifulsoup

En CentOS/RedHat:

yum install python-BeautifulSoup

Con easy_install:

easy_install BeautifulSoup

El código tiene una clase Status que es la que hace la magia y una función main() que utiliza la clase para parsear una URL e imprimir algunos datos a modo de ejemplo.

import sys
import urllib2
from operator import itemgetter
from BeautifulSoup import BeautifulSoup

class Status (object):
_url = None

def __init__ (self, url):
self._url = url

def fetch (self):
return urllib2.urlopen(self._url).read()

def parse (self):
html = self.fetch()
soup = BeautifulSoup(html)
status = {}
status[‘server_info’] = [i.string.strip() for i in soup.findAll(‘dt’)]
status[‘requests’] = []
requests = soup.find(‘table’).findAll(‘tr’)
keys = [i.string for i in requests.pop(0)]
for tr in requests:
req = {}
for n, td in enumerate(tr):
req[keys[n]] = td.string
status[‘requests’].append(req)
return status

def main (argv):
if len(argv) < 2:
print "Usage %s "%argv[0]
return 1

status = Status(argv[1])
data = status.parse()
print "SERVER INFORMATION"
print "=================="
for v in data[‘server_info’]:
print v

print "REQUESTS BY VHOST"
print "================="
entries = [i[‘VHost’] for i in data[‘requests’]]
requests = sorted([(entries.count(i), i) for i in list(set(entries))], reverse=True)
print "\n".join(["%d: %s"%(a,b) for a,b in requests])

if __name__ == "__main__":
sys.exit(main(sys.argv))

La forma de uso es:

python status.py "http://localhost/server-status"

Y en este caso la salida del script es algo así:

SERVER INFORMATION
==================
Server Version: Apache/2.2.19 (Unix) mod_ssl/2.2.19 OpenSSL/0.9.8e-fips-rhel5 DAV/2
Server Built: May 26 2011 15:14:47
Current Time: Sunday, 31-Jul-2011 00:53:59 ART
Restart Time: Saturday, 30-Jul-2011 12:07:12 ART
Parent Server Generation: 0
Server uptime:  12 hours 46 minutes 47 seconds
Total accesses: 407813 - Total Traffic: 3.7 GB
CPU Usage: u2.05 s3.23 cu52 cs0 - .125% CPU load
8.86 requests/sec - 85.0 kB/second - 9.6 kB/request
10 requests currently being processed, 8 idle workers
REQUESTS BY VHOST
=================
9: www.tail-f.com.ar
5: www.otro-dominio.com.ar
4: www.not-a-domain.com.ar
3: www.algunlado.com.ar
2: subdominio.dominio.com.ar
1: www.pepe.com.ar
1: www.no-votes-a-macri.com.ar
1: www.asd.com.ar
1: localhost

Obviamente esto no es una aplicación funcional, sino un ejemplo que espero que les sirva para hacer algo más copado. Yo seguiré jugando y si hago algo un poco más interesante, ya se los mostraré.

Nginx como Proxy Reverso en servidor Directadmin

elbarto — Sat, 18 Sep 2010 04:04:05 +0000

Apache

En esta oportunidad voy a explicar cómo instalar Nginx como proxy reverso en un servidor de hosting con Directadmin.

¿Qué es un proxy reverso?

Un proxy reverso en este caso es, básicamente, un servidor web que se interpone como una capa entre el cliente y un backend, de manera de optimizar la conexión. Típicamente el proxy es un servidor muy liviano que funciona de frontend, atiende las peticiones de los clientes HTTP y deriva el procesamiento en un backend que podría ser un servidor Apache. Según la configuración que apliquemos, un proxy nos permite introducir mayor seguridad en nuestra red, hacer balanceo de carga, hacer cache, etc.

También optimiza el manejo de memoria. Pensemos que Apache lanza un thread o proceso por cada nuevo cliente, el cual se cierra recién cuando termina la transferencia de datos. Si el cliente tiene una conexión lenta, por más que Apache funcione rápido, el proceso queda corriendo hasta que se terminen de enviar los datos. Un frontend liviano como Nginx nos permite que el proceso que espere al cliente sea mucho más liviano que uno de Apache.

Por último, como indican en sysadmin.es, un proxy Nginx nos sirve para prevenir ataques de denegación de servicio utilizando slowloris.

Un proxy reverso en un servidor de hosting

Nginx

Los proxies se suelen utilizar en arquitecturas para servir sitios de alta demanda. En esos casos es común, por ejemplo, hacer que Apache sirva el contenido dinámico y un servidor más liviano (lighttpd o nginx) sirva contenido estático. Pero en un servidor de hosting esto no es tan sencillo, pues al alojarse varios sitios en un mismo equipo nuestra configuración debe ser lo más genérica posible para que sirva a la mayor parte de nuestros clientes. Como veremos, podemos definir algún tipo de cache, pero también tiene que ser bastante genérico para no causar problemas. Además tenemos que pensar en la integración con el panel de control que estemos usando. Yo uso Directadmin y este panel no tiene (aún) una integración nativa con otro web server que no sea Apache.

Nginx + Apache + Directadmin

La opción que les presento es para utilizar Nginx como proxy reverso, manejando las conexiones de los clientes y haciendo un muy básico cache del contenido estático. La guía está pensada para CentOS, pero en otros sistemas operativos no debería ser muy distinto.

Primero instalamos Nginx. El proceso es muy sencillo.

# cd /usr/src
# wget http://nginx.org/download/nginx-0.7.67.tar.gz
# tar zxvf nginx-0.7.67.tar.gz
# cd nginx-0.7.67
# ./configure --prefix=/usr \
              --conf-path=/etc/nginx/nginx.conf \
              --error-log-path=/var/log/nginx/error.log \
              --http-log-path=/var/log/nginx/access.log \
              --pid-path=/var/run/nginx/nginx.pid \
              --lock-path=/var/run/nginx/nginx.lock \
              --with-http_stub_status_module \
              --with-openssl=/usr/lib/openssl
# make && make install

Creamos el directorio para guardar el cache de contenido estático:

# mkdir -p /var/tmp/nginx
# chown apache:apache /var/tmp/nginx

Lo más importante es configurar Nginx. Para ello modificaremos /etc/nginx/nginx.conf para que quede algo similar a esto:

Importante: reemplazar __SERVER_IP__ por la IP del servidor y __SERVER_HOSTNAME__ por el nombre del servidor.

user  apache;
worker_processes  1;

events {
    worker_connections  8192;
}

http {
    server_tokens off;

    include       mime.types;
    default_type  application/octet-stream;

    log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                      '$status $body_bytes_sent "$http_referer" '
                      '"$http_user_agent" "$http_x_forwarded_for"';

    #access_log  /var/log/nginx/access.log  main;

    sendfile        on;
    tcp_nopush     on;

    keepalive_timeout  75 20;

    gzip  on;

    server_names_hash_bucket_size 64;
    reset_timedout_connection on;

    client_max_body_size 100m;

    # Main cache data
    proxy_cache_path  /var/tmp/nginx/cache  levels=1:2   keys_zone=staticfilecache:180m  max_size=500m;
    proxy_temp_path /var/tmp/nginx/proxy;
    proxy_connect_timeout 30;
    proxy_read_timeout 120;
    proxy_send_timeout 120;
    proxy_cache_key "$scheme$host$request_uri";

    server {
        listen       __SERVER_IP__:81;
        server_name  __SERVER_HOSTNAME__ _;

        #charset koi8-r;
        charset off;

        access_log off;
        #access_log  /var/log/nginx/access.log  main;

        # Main reverse proxy for most requests
        location / {
                    proxy_set_header Host $host;
                    proxy_set_header X-Real-IP $remote_addr;
                    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

                    proxy_pass              http://__SERVER_IP__;    # apache here

                    client_max_body_size       16m;
                    client_body_buffer_size    128k;

                    #proxy_buffering     off;
                    proxy_buffering     on;  

                    proxy_connect_timeout      90;
                    proxy_send_timeout         90;
                    proxy_read_timeout         120;
                    proxy_buffer_size          8k;
                    proxy_buffers              32 32k;
                    proxy_busy_buffers_size    64k;
                    proxy_temp_file_write_size 64k;

                    error_page              502 503 /50x.html;
        }

        # Proxy cache for static files
        location ~* \.(jpg|png|gif|jpeg|css|js|mp3|wav|swf|mov|doc|pdf|xls|ppt|docx|pptx|xlsx)$ {
                    proxy_set_header Host $host;
                    proxy_set_header X-Real-IP $remote_addr;
                    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

                    proxy_pass              http://__SERVER_IP__;    # apache here

                    client_max_body_size       16m;
                    client_body_buffer_size    128k;

                    #proxy_buffering     off;
                    proxy_buffering     on;  

                    proxy_connect_timeout      90;
                    proxy_send_timeout         90;
                    proxy_read_timeout         120;
                    proxy_buffer_size          8k;
                    proxy_buffers              32 32k;
                    proxy_busy_buffers_size    64k;
                    proxy_temp_file_write_size 64k;

                    # Proxy cache data
                    proxy_cache_valid 200 120m;
                    expires 864000;
                    proxy_cache staticfilecache;

                    error_page              502 503 /50x.html;
        }

        #error_page  404              /404.html;

        # redirect server error pages to the static page /50x.html
        #
        error_page   500 502 503 504  /50x.html;
        location = /50x.html {
            root   /var/www/html;
        }

    }

}

Por supuesto esta es una configuración básica que debería adaptarse al caso específico. Es importante notar lo siguiente:

Nginx escucha en el puerto 81 y Apache en el 80. Esto es importante para no tener que hacer cambios en la configuración de Directadmin.
Se definen 3 Locations. Las primeras dos son proxies que le pasan requests al Apache esuchando en el puerto 80. La segunda aplica solamente a los requests de archivos estáticos y hace un cache en /var/tmp/nginx. Este cache es manejado siguiendo los headers HTTP correspondientes.

Ahora necesitamos instalar un módulo de Apache, mod_rpaf, para poder usar el header X-Real-IP.

# cd /usr/src
# wget http://stderr.net/apache/rpaf/download/mod_rpaf-0.6.tar.gz
# tar zxvf mod_rpaf-0.6.tar.gz
# cd mod_rpaf-0.6
# apxs -i -c -n mod_rpaf-2.0.so mod_rpaf-2.0.c

Y luego agregamos esto al httpd.conf

LoadModule rpaf_module /usr/lib/apache/mod_rpaf-2.0.so
RPAFenable On
RPAFsethostname On
RPAFproxy_ips 127.0.0.1 __SERVER_IP__
RPAFheader X-Forwarded-For

Reemplazando __SERVER_IP__ por la IP del servidor.

También vamos a necesitar un script para el init del Nginx. Como no encontré uno hecho, hice este:

#!/bin/bash
#
# Name: NginX, tsj5j
#
# Function:     Start up NginX
#
# chkconfig: - 85 15
# description: NginX starter

# Source function library.
. /etc/rc.d/init.d/functions

# Source networking configuration.
. /etc/sysconfig/network

prog="nginx"
nginx=/usr/sbin/nginx

start () {
        echo -n $"Starting $prog: "
        $nginx
        RETVAL=$?
        return $RETVAL
}

stop () {
        echo -n $"Stopping $prog: "
        killproc $nginx
        RETVAL=$?
        return $RETVAL
}

reload () {
        echo -n $"Reloading $prog: "
        killproc $nginx -HUP
        RETVAL=$?
        return $RETVAL
}

case "$1" in
  start)
        start
        ;;
  stop)
        stop
        ;;
  restart)
        stop
        sleep 1
        start
        ;;
  reload)
        reload
        ;;
  graceful)
        reload
        ;;
esac

exit $RETVAL;

Una vez ubicado ese contenido en un archivo /etc/init.d/nginx lo habilitamos

# chkconfig --add nginx
# chkconfig nginx on
# service nginx start

Y nos falta una única cosa. Tenemos Apache corriendo en el puerto 80 y Nginx en el 81. ¿Cómo hacemos que Nginx atienda las peticiones de nuestros clientes? Creamos una ruta en iptables para que redirija el tráfico del puerto 81 al 80:

# iptables -t nat -A PREROUTING -p tcp -s ! __SERVER_IP__ --dport 80 -j REDIRECT --to-ports 81
# service iptables save

Reemplazando __SERVER_IP__ por la IP del servidor.

Y listo, ahora nuestro Nginx va a recibir todo el tráfico HTTP y negociar con el Apache para devolverlo a los clientes.

Verificar que atienda Nginx

Comprobar que Nginx esté atendiendo las peticiones en el puerto 80 es muy sencillo de hacer con curl. Por ejemplo, probándolo contra la URL de este blog.

# curl -I http://www.tail-f.com.ar
HTTP/1.1 200 OK
Server: nginx
Date: Sat, 18 Sep 2010 04:09:23 GMT
Content-Type: text/html; charset=UTF-8
Connection: keep-alive
Keep-Alive: timeout=20
Vary: Cookie,Accept-Encoding,User-Agent
X-Pingback: http://www.tail-f.com.ar/xmlrpc.php
Cache-Control: private, no-cache, no-store, proxy-revalidate, no-transform
Pragma: no-cache

Como vemos el servidor que atiende es Nginx.

Referencias:

Instalar Monit: monitoreo de servicios para servidores Unix

elbarto — Sun, 04 Apr 2010 14:40:47 +0000

Hoy voy a explicar cómo instalar Monit, un software muy completo para monitoreo de servicios (locales y remotos) de cualquier sistema Unix. Con él podremos estar atentos ante posibles problemas en alguno de nuestros servidores y realizar algunas tareas automaticamente.

¿Qué es Monit?

De acuerdo con su propia definición, Monit es una utilidad gratuita y Open Source para administrar y monitorear procesos, archivos, directorios y filesystems en un sistema Unix. Realiza tareas automáticas de mantenimiento y reparación y puede ejecutar acciones significativas durante situaciones de error.

Está desarrollado en C (pueden ver el código fuente en Google Code) y su demonio corre de manera casi imperceptible para el sistema, en tanto consume muy pocos recursos.

Para más información, se puede consultar el sitio oficial de Monit y su manual online (ambos en inglés).

Instalación

La instalación de Monit es muy sencilla.

# cd /usr/src
# wget http://mmonit.com/monit/dist/monit-5.1.1.tar.gz
# tar zxvf monit-5.1.1.tar.gz
# cd monit-5.1.1
# ./configure --prefix=/usr
# make && make install

Luego, si estamos instalando en CentOS o algún Linux similar, vamos a querer copiar el archivo rc.

# cp contrib/rc.monit /etc/init.d/monit
# chown root:root /etc/init.d/monit
# chmod 755 /etc/init.d/monit
# chkconfig --add monit
# chkconfig monit on

Configuración

Una vez instalado podemos pasar a la configuración, que será lo más importante del proceso. Para ello yo suelo crear un archivo inicial /etc/monitrc que tiene la configuración general del Monit, y luego dentro de una carpeta /etc/monit creo un archivo por cada servicio que quiero monitorear.

Les dejo aquí mi configuración.

Archivo: /etc/monitrc

set daemon  120
set logfile syslog facility log_daemon
set mailserver localhost

set alert administrator@domain.com                      # receive all alert
set alert anotheradmin@domain2.com

set httpd port 2812 and
   use address localhost  # only accept connection from localhost
    allow localhost        # allow localhost to connect to the server and
#    allow admin:monit      # require user 'admin' with password 'monit'
#
#
###############################################################################
## Services
###############################################################################
##
## Check general system resources such as load average, cpu and memory
## usage. Each test specifies a resource, conditions and the action to be
## performed should a test fail.
#
  check system fqdn.domain.com
    if loadavg (1min) > 5 then alert
    if loadavg (5min) > 10 then alert
    if loadavg (1min) > 20 then exec "/bin/bash /root/handle_high_load.sh"
    if memory usage > 75% then alert
    if cpu usage (user) > 70% for 3 cycles then alert
    if cpu usage (system) > 30% for 3 cycles then alert
    if cpu usage (wait) > 20% for 3 cycles then alert

include /etc/monit/*.monitrc

Algunas cosas para anotar de esta primera parte. El daemon va a revisar cada 120 segundos los servicios, va a loguear en Syslog y va enviar mails usando el mailserver local. Cuando haya alguna alerta, la enviará a administrador@domain.com y anotheradmin@domain2.com. Luego habilito el servicio web que ofrece monit para que escuche en la IP local (esto es para poder utilizar todas las opciones del comando `monit`). Por último defino las reglas para el chequeo del sistema, cuyo FQDN es fqdn.domain.com (acá iría el hostname de su servidor). Las reglas son bastante sencillas. En algunos casos lo que hago es enviar una alerta y si el loadavg es más de 20 ejecuto un script para controlarlo.

La última línea incluye todos los archivos *.monit del directorio /etc/monit. Que es lo que vamos a ver ahora.

Archivo: /etc/monit/httpd.monitrc

#
# Monitor Apache (httpd)
#
check process httpd with pidfile /var/run/httpd.pid
    start program = "/sbin/service httpd start"
    stop program  = "/sbin/service httpd stop"
    if cpu > 80% for 3 cycles then alert
    if totalmem > 1500.0 MB for 5 cycles then alert
    if children > 250 then alert
    if children > 255 for 5 cycles then stop
    if cpu usage > 95% for 3 cycles then restart
    if failed port 80 protocol http then restart

check file httpd.conf with path /etc/httpd/conf/httpd.conf
    if changed checksum then alert

Aquí defino un proceso de nombre “httpd” con un pidfile en /var/run/httpd.pid. Luego defino los comandos para iniciar y detener el proceso. Y luego las acciones a realizar según el evento. En algunos casos será “alert” (enviar aviso por mail), en otros “restart” (reinicar el proceso). Hay otras opciones que podrán ver en la documentación. Por último agrego una verificación del archivo httpd.conf. Si se modifica me notificará por mail.

De la misma forma, en el directorio /etc/monit tengo archivos similares para MySQL, SMTP, POP3, IMAP, SSH, etc. Y además tengo archivos para controlar algunos servicios externos. Esto es por una cuestión básica: hasta ahora estamos haciendo todos chequeos locales, si el servidor se cae o por alguna razón no puede enviarme las alertas, podría nunca enterarme de qué pasa. Entonces voy a agregar este otro archivo para controlar un servidor externo que me diga si los servicios están accesibles.

Archivo: server1.monitrc

# server1.domain.com check
check host server1.domain.com with address 1.2.3.4
      if failed icmp type echo count 10 with timeout 15 seconds
         then alert
      if failed port 21 proto ftp then alert
      if failed port 25 proto smtp then alert
      if failed port 80 proto http then alert
      if failed port 110 proto pop then alert

Aquí estoy monitreando el servidor server1.domain.com con IP 1.2.3.4 (este archivo debería estar en otro servidor con Monit, por ejemplo, servidor2.domain.com). Lo primero que intento es hacer un Echo ICMP. Lamentablemente Monit no soporta hacer ping, pero un echo ICMP es lo más cercano que nos permite. Si falla 10 veces seguidas, le pido que me avise (la cantidad de veces tan alta es para asegurarme de no recibir una alerta por un paquete perdido y llenar mi mail de alertas inútiles que no me permitan ver las importantes). Luego agrego que testee los principales puertos a través de los protocolos correspondientes y que si falla me avise.

Iniciando Monit

Una vez que tenemos la configuración, ya podemos probarlo. Para ello iniciaremos el servicio, veremos si se inicia correctamente en el log y veremos el status.

Iniciamos:

# service monit start

Luego vemos en syslog:

Apr  4 11:35:23 fqdn monit[24820]: Starting monit daemon with http interface at [localhost:2812]
Apr  4 11:35:23 fqdn monit[24822]: Starting monit HTTP server at [localhost:2812]
Apr  4 11:35:23 fqdn monit[24822]: monit HTTP server started
Apr  4 11:35:23 fqdn monit[24822]: 'fqdn.domain.com' Monit started

Monit inició y tiene su servidor HTTP escuchando en localhost:2812. Ahora veamos el resumen del status de los servicios.

# monit status
The Monit daemon 5.0.3 uptime: 1m 

System 'fqdn.domain.com' running
Process 'sshd'                      running
File 'sshd_config'                  accessible
Process 'exim'                      running
File 'exim.conf'                    accessible
Process 'mysqld'                    running
File 'my.cnf'                       accessible
Process 'httpd'                     running
File 'httpd.conf'                   accessible
Remote Host 'fqdn.domain.com' online with all services

Para ver los comandos disponibles:

# monit -h

Al mismo tipo de información podremos acceder por vía web si accedemos a http://localhost:2812. También, si queremos acceder desde afuera, podemos configurar Monit para que escuche en otra IP (por ejemplo, 0.0.0.0) y definir un método de autenticación (para que no pueda acceder cualquiera).

Python: Ver dominios de Apache que más transferencia consumen

elbarto — Thu, 11 Mar 2010 01:47:12 +0000

Hace un rato publiqué un post con un script para ver qué dominios de Apache consumen mayor transferencia. El script en BASH toma unos 7 segundos en procesar 750 archivos de uno de mis servidores. Ahora hice una versión en Python, para la que me dieron algunos consejos los chicos de PyAr, y toma aproximadamente 4 segundos en procesar los mismos archivos. Aquí les dejo el código:

#!/usr/bin/env python
""" Access Log Parser

Parses all the files in a directory
treating them as access_log files
and outputs the list of files sorted
by transfered megabytes. Useful for
identifying heavy users.

Usage:
./access_log_parser.py
base_dir = directory where the access_log files are
"""
import sys
import os
import time
from operator import itemgetter

def main (args):
"""Main

Main function of the script.
This is where the magic happens.
It takes the script arguments
and returns an exit code.
"""

# Parameter checking
if len(args) < 2:
print "Usage: %s " % args[0]
return 1

if os.path.isdir(args[1]):
base_dir = args[1]
else:
print "%s is not a directory" % args[1]
return 2

# Init vars
t1 = time.time()
mbyte = 1048576.0
domains = []

# Start processing files
for item in os.listdir(args[1]):
path = os.path.join(base_dir, item)
if os.path.isfile(path) and \
os.path.getsize(path) > 0:

bytes = 0
init_date = None
data = None

# Process file lines
for line in open(path, ‘r’):
data = line.split(" ")
if init_date is None:
init_date = data[3][1:]
try:
bytes += long(data[9])
except ValueError:
pass
domains.append({‘domain’: item, \
‘mbytes’: bytes / mbyte, \
‘init_date’: init_date, \
‘end_date’: data[3][1:] })

# Print out sorted information
for domain in sorted(domains, key=itemgetter(‘mbytes’)):
print "%.2f MB | From: %s | To: %s | %s" % \
(domain[‘mbytes’], \
domain[‘init_date’], \
domain[‘end_date’], \
domain[‘domain’])

print "Generated in %d seconds" % (time.time() – t1)
return 0

if __name__ == "__main__":
sys.exit(main(sys.argv))

Para ejecutarlo:

./access_log_parser.py /tmp/domain_logs
...
544.30 MB | From: 10/Mar/2010:02:48:33 | To: 10/Mar/2010:18:13:25 | dominio1.com.ar.log
602.34 MB | From: 10/Mar/2010:00:23:09 | To: 10/Mar/2010:23:39:45 | dominio2.com.ar.log
944.03 MB | From: 10/Mar/2010:00:49:35 | To: 10/Mar/2010:23:39:57 | dominio3.com.ar.log
Generated in 3 seconds

Ver dominios de Apache que más transferencia consumen

elbarto — Wed, 10 Mar 2010 19:07:44 +0000

Frecuentemente me encuentro ante la necesidad de saber qué dominios de los que tengo alojados en mis servidores consumen más tráfico HTTP. Como éste es el tipo de tráfico más importante y que más incide en el desempeño general de mis servidores, saber qué dominios transfieren más datos por HTTP me orienta en la búsqueda de heavy users. Para ello hice un script hace algún tiempo, y ahora lo estuve revisando, retocando y simplificando, y decidí compartirlo.

En el entorno de Directadmin, los logs de Apache se encuentran en /var/log/httpd. Allí hay una carpeta “domains” que guarda los logs de cada dominio. Por cada dominio hay tres logs: dominio.com.log, dominio.com.error.log y dominio.com.bytes. El primero es el access_log, el segundo el error_log y el tercero solamente guarda la cantidad de bytes de cada request. La opción más sencilla es trabajar con este último tipo de logs, pero el problema que tienen es que no indican la fecha. Si bien se supone que los logs de Directadmin rotan una vez por día, alguna vez me ha pasado que por razones que nunca pude descubrir, algunos logs no rotaban y generaban ciertas confusiones. Por lo tanto, el script que dejo usa los access_logs. Además esta opción es reutilizable en otras implementaciones de Apache que no tengan archivos de bytes.

El código:

# Access Log Parser
#
# Parses all the files in a directory
# treating them as access_log files
# and outputs the list of files sorted
# by transfered megabytes. Useful for
# identifying heavy users.
#
# Usage:
# ./access_log_parser.sh
# base_dir = directory where the access_log files are

if [ -z $1 ]; then
echo "Usage: $0 "
exit 1
fi

BASE_DIR=$1
T1=`date +%s`
for file in $BASE_DIR/*;
do
size=`stat -c %s $file`
if [ $size -gt 0 ]; then
from=`head -1 $file | awk ‘{print($4)}’ |sed ‘s/^\[//’`
to=`tail -1 $file | awk ‘{print($4)}’ |sed ‘s/^\[//’`
bytes=`cat $file | awk ‘{a+=$10}END{print a}’`
mbytes=`echo $bytes | awk ‘{print $1 / 1048576}’`
echo "$mbytes MB ($bytes bytes) | From: $from | To: $to | ${file:${#BASE_DIR}+1}"
fi
done \
| sort -nb
T=`date +%s`

Un detalle importante: el script levanta todos los archivos de un directorio que se especifica por parámetro. Esto es así porque yo lo invoco desde otro script:

#!/bin/bash
LOG_DIR=/var/log/httpd/domains/
TMP=/tmp/domain_logs
if [ ! -d $TMP ]; then
mkdir -p $TMP
fi

rm -f $TMP/*

cd $LOG_DIR
for i in `ls *.log |grep -v error`; do
ln $i $TMP/$i
done
/root/access_log_parser.sh $TMP

Este último script lo que hace es crear un directorio temporal (si no existe). Vaciar su contenido. Y luego generar hardlinks a todos los access_logs de /var/log/httpd/domains. De esta forma, no me tengo que preocupar por si los logs son modificados mientras yo estoy ejecutando el script. Por último, ejecuta mi primer script (access_log_parser.sh) y le pasa como parámetro el directorio temporal donde están los access_logs.

Por último, la salida del script sería algo así:

...
186.995 MB (196078184 bytes) | From: 10/Mar/2010:00:27:47 | To: 10/Mar/2010:16:51:09 | dominio1.com.ar.log
187.096 MB (196184596 bytes) | From: 10/Mar/2010:03:24:55 | To: 10/Mar/2010:16:51:24 | dominio2.com.ar.log
245.692 MB (257626221 bytes) | From: 10/Mar/2010:02:53:50 | To: 10/Mar/2010:16:39:54 | dominio3.com.log
273.46 MB (286743390 bytes) | From: 10/Mar/2010:02:48:33 | To: 10/Mar/2010:14:59:29 | dominio4.com.ar.log
306.344 MB (321224473 bytes) | From: 10/Mar/2010:00:23:09 | To: 10/Mar/2010:16:51:20 | dominio5.com.ar.log
444.097 MB (465669066 bytes) | From: 10/Mar/2010:00:49:35 | To: 10/Mar/2010:16:51:20 | dominio6.com.ar.log
Generated in 6 seconds

Les dejo, de yapa, la opción del script utilizando los logs de bytes. Como dije, esta opción es un poco más sencilla y veloz, pero no nos dice las fechas de los logs.

#!/bin/bash

if [ -z $1 ]; then
echo "Usage: $0 "
exit 1
fi

BASE_DIR=$1
T1=`date +%s`
for file in $BASE_DIR/*.bytes;
do
size=`stat -c %s $file`
if [ $size -gt 0 ]; then
bytes=`cat $file | awk ‘{a+=$1}END{print a}’`
mbytes=`echo $bytes | awk ‘{print $1 / 1048576}’`
echo "$mbytes MB ($bytes bytes) ${file:${#BASE_DIR}+1}"
fi
done \
| sort -nb
T=`date +%s`
echo "Generated in $(($T-$T1)) seconds"

Y la salida sería así:

# ./parser.sh /var/log/httpd/domains
...
181.716 MB (190543470 bytes) dominio1.com.bytes
187.115 MB (196203973 bytes) dominio2.com.ar.bytes
189.093 MB (198278283 bytes) dominio3.com.ar.bytes
245.692 MB (257626221 bytes) dominio4.com.bytes
273.472 MB (286756234 bytes) dominio5.com.ar.bytes
314.32 MB (329588717 bytes) dominio6.com.ar.bytes
444.516 MB (466108759 bytes) dominio7.com.ar.bytes
Generated in 2 seconds

Grave exploit para Apache descubierto

elbarto — Mon, 08 Mar 2010 21:31:30 +0000

Leo en Slashdot que se descubrió un grave exploit para Apache. De acuerdo con la nota de ZDNet, la compañía de seguridad “Sense of Security” descubrió un serio bug en el servidor web Apache que podría permitir a un atacante remoto obtener control sobre una base de datos. Una vulnerabilidad existente en el módulo “mod_isapi” del core de Apache podría permitirle a un atacante obtener privilegios de administrador, comprometiendo seriamente la seguridad de la información.

La nota de ZDNet no da muchos detalles del bug, pero indica que comprometería especialmente a los servidores Windows. Por otra parte, el reporte de Sense of Security es más detallado e incluye una “prueba de concepto” acerca de cómo explotar el bug.

Se recomienda actualizar a la versión 2.2.15 de Apache que corrige el bug.

Directadmin ya ha hecho los cambios correspondientes, así que con Custombuild podemos actualizar rápida y fácilmente a la nueva versión siguiendo el procedimiento que explique recientemente.

httping: herramienta para medir la latencia de un servidor web

elbarto — Mon, 08 Mar 2010 19:40:58 +0000

El otro día, Pablo Morales me pasó el dato de httping. Se trata de una herramienta similar al ping, pero que en vez de enviar paquetes por ICMP a una IP, envía peticiones HTTP a un servidor web. De esta forma podemos medir la latencia del servicio.

Instalación

En Debian/Ubuntu podemos instalar el paquete httping:

# sudo apt-get install httping

Para otras distribuciones, accediendo a la página de httping encontrarán RPMs y el tar.gz con los fuentes. Descargando los fuentes solamente hace falta descomprimirlo y darle “make && make install”.

Ejemplo de uso

Usarlo es muy sencillo. Por ejemplo, para pingear un servidor local:

elbarto@tarantino:~$ httping -c 5 -g http://localhost
PING localhost:80 (http://localhost):
connected to localhost:80, seq=0 time=1.56 ms
connected to localhost:80, seq=1 time=1.30 ms
connected to localhost:80, seq=2 time=1.30 ms
connected to localhost:80, seq=3 time=1.27 ms
connected to localhost:80, seq=4 time=1.19 ms
--- http://localhost ping statistics ---
5 connects, 5 ok, 0.00% failed
round-trip min/avg/max = 1.2/1.3/1.6 ms

El parámetro “-c 5″ define la cantidad de pings a realizar. Esto es igual que el ping de Linux.

También puedo pingear esta web.

httping -c 5 -g http://www.tail-f.com.ar
PING www.tail-f.com.ar:80 (http://www.tail-f.com.ar):
connected to www.tail-f.com.ar:80, seq=0 time=55.48 ms
connected to www.tail-f.com.ar:80, seq=1 time=45.74 ms
connected to www.tail-f.com.ar:80, seq=2 time=34.24 ms
connected to www.tail-f.com.ar:80, seq=3 time=41.79 ms
connected to www.tail-f.com.ar:80, seq=4 time=40.31 ms
--- http://www.tail-f.com.ar ping statistics ---
5 connects, 5 ok, 0.00% failed
round-trip min/avg/max = 34.2/43.5/55.5 ms

En este caso los tiempos son mayores, y tenemos que tener en cuenta dos cosas. En primer lugar, hay una diferencia por la conexión (no es lo mismo conectarme a localhost que a un servidor externo). En segundo lugar, este blog es un sitio dinámico hecho en PHP que realiza una serie de operaciones antes de mostrar el resultado. Pero, ¿cómo sabemos qué toma más tiempo, si la conexión o el procesamiento del sitio?. Para ello podemos separar ambos tiempos con el parámetro -S.

httping -c 5 -Sg http://www.tail-f.com.ar
PING www.tail-f.com.ar:80 (http://www.tail-f.com.ar):
connected to www.tail-f.com.ar:80, seq=0 time=25.96+22.93=48.89 ms
connected to www.tail-f.com.ar:80, seq=1 time=22.74+17.37=40.11 ms
connected to www.tail-f.com.ar:80, seq=2 time=21.90+20.39=42.29 ms
connected to www.tail-f.com.ar:80, seq=3 time=25.36+18.01=43.37 ms
connected to www.tail-f.com.ar:80, seq=4 time=27.81+15.85=43.66 ms
--- http://www.tail-f.com.ar ping statistics ---
5 connects, 5 ok, 0.00% failed
round-trip min/avg/max = 40.1/43.7/48.9 ms

Aquí vemos primero el tiempo de conexión, luego el de procesamiento y por último el total. En este caso, por lo general toma un poco más la conexión que el procesamiento, aunque es bastante parejo.

Otra cosa a tener en cuenta es que en este tipo de pruebas que venimos haciendo, el httping envía una petición HEAD al servidor. Para enviar un GET (que obtenga todo el contenido de la página), debemos agregar el parámetro “-G”. Por ejemplo:

elbarto@tarantino:~$ httping -c 5 -Gg http://www.tail-f.com.ar
PING www.tail-f.com.ar:80 (http://www.tail-f.com.ar):
connected to www.tail-f.com.ar:80, seq=0 time=210.41 ms
connected to www.tail-f.com.ar:80, seq=1 time=211.78 ms
connected to www.tail-f.com.ar:80, seq=2 time=194.49 ms
connected to www.tail-f.com.ar:80, seq=3 time=184.41 ms
connected to www.tail-f.com.ar:80, seq=4 time=210.62 ms
--- http://www.tail-f.com.ar ping statistics ---
5 connects, 5 ok, 0.00% failed
round-trip min/avg/max = 184.4/202.3/211.8 ms

Aquí los tiempos se incrementan, lógicamente, porque el tamaño de los paquetes traficados es mucho mayor.

Por último, podemos usar httping para hacer pruebas de stressing, con la opción “flood connect” (-f) que envía peticiones sin esperar respuesta.

elbarto@tarantino:~$ httping -fg http://www.tail-f.com.ar
PING www.tail-f.com.ar:80 (http://www.tail-f.com.ar):
connected to www.tail-f.com.ar:80, seq=0 time=51.54 ms
connected to www.tail-f.com.ar:80, seq=1 time=48.47 ms
connected to www.tail-f.com.ar:80, seq=2 time=56.07 ms
connected to www.tail-f.com.ar:80, seq=3 time=55.58 ms
connected to www.tail-f.com.ar:80, seq=4 time=55.99 ms
connected to www.tail-f.com.ar:80, seq=5 time=52.46 ms
connected to www.tail-f.com.ar:80, seq=6 time=56.06 ms
connected to www.tail-f.com.ar:80, seq=7 time=52.99 ms
connected to www.tail-f.com.ar:80, seq=8 time=52.54 ms
connected to www.tail-f.com.ar:80, seq=9 time=76.56 ms
connected to www.tail-f.com.ar:80, seq=10 time=63.04 ms
connected to www.tail-f.com.ar:80, seq=11 time=53.01 ms
connected to www.tail-f.com.ar:80, seq=12 time=36.00 ms
connected to www.tail-f.com.ar:80, seq=13 time=48.93 ms
connected to www.tail-f.com.ar:80, seq=14 time=42.78 ms
connected to www.tail-f.com.ar:80, seq=15 time=44.82 ms
connected to www.tail-f.com.ar:80, seq=16 time=52.41 ms
connected to www.tail-f.com.ar:80, seq=17 time=56.62 ms
connected to www.tail-f.com.ar:80, seq=18 time=48.44 ms
connected to www.tail-f.com.ar:80, seq=19 time=53.05 ms
connected to www.tail-f.com.ar:80, seq=20 time=54.13 ms
^Cconnected to www.tail-f.com.ar:80, seq=21 time=60.53 ms
--- http://www.tail-f.com.ar ping statistics ---
22 connects, 22 ok, 0.00% failed
round-trip min/avg/max = 36.0/53.3/76.6 ms

Luego tiene muchas otras opciones interesantes, como configuración de la salida para integrarse con Nagios y la posibilidad de definir un User-Agent y un Referer específicos en los requests. Les recomiendo instalarlo y hacer “man httping” para ver todas las opciones.

Tips Apache: ver configuración desde la línea de comandos

elbarto — Mon, 01 Mar 2010 16:19:28 +0000

Apache Web Server

A veces queremos saber algunas cosas de la configuración de Apache, pero no queremos revisar el httpd.conf ni seguir sus includes. El binario httpd acepta algunos parámetros que nos pueden servir, proveyéndonos esa información. Dejo un par de ejemplos.

Verificar sintaxis de los archivos de configuración

Muy facilmente podemos pedirle al Apache que verifique la sintaxis de los archivos de configuración. Esto es útil por si hicimos una modificación de la que no estamos seguros y queremos verificarla antes de reiniciar el servicio (y dejar a los clientes sin servicio hasta que lo resolvamos).

Comando:

httpd -t

Salida:

Syntax OK

Obtener versión de Apache

La más sencilla y obvia, para ver la versión de Apache sólo basta con:

httpd -v

Y la salida es algo así:

Server version: Apache/2.2.14 (Unix)
Server built:   Jan 28 2010 12:43:06

Ver información de compilación

Eventualmente podemos querer tener algunos datos sobre cómo fue compilado Apache.
Esta es una versión más completa de lo que ofrece httpd -v.
Entre otros datos, nos sirve para saber qué módulo de MPM está usando Apache.

Comando:

httpd -V

Salida:

Server version: Apache/2.2.14 (Unix)
Server built:   Jan 28 2010 12:43:06
Server's Module Magic Number: 20051115:23
Server loaded:  APR 1.3.9, APR-Util 1.3.9
Compiled using: APR 1.3.9, APR-Util 1.3.9
Architecture:   32-bit
Server MPM:     Prefork
  threaded:     no
    forked:     yes (variable process count)
Server compiled with....
 -D APACHE_MPM_DIR="server/mpm/prefork"
 -D APR_HAS_SENDFILE
 -D APR_HAS_MMAP
 -D APR_HAVE_IPV6 (IPv4-mapped addresses enabled)
 -D APR_USE_SYSVSEM_SERIALIZE
 -D APR_USE_PTHREAD_SERIALIZE
 -D SINGLE_LISTEN_UNSERIALIZED_ACCEPT
 -D APR_HAS_OTHER_CHILD
 -D AP_HAVE_RELIABLE_PIPED_LOGS
 -D DYNAMIC_MODULE_LIMIT=128
 -D HTTPD_ROOT="/etc/httpd"
 -D SUEXEC_BIN="/usr/sbin/suexec"
 -D DEFAULT_PIDLOG="/var/logs/httpd.pid"
 -D DEFAULT_SCOREBOARD="logs/apache_runtime_status"
 -D DEFAULT_LOCKFILE="/var/logs/accept.lock"
 -D DEFAULT_ERRORLOG="logs/error_log"
 -D AP_TYPES_CONFIG_FILE="conf/mime.types"
 -D SERVER_CONFIG_FILE="conf/httpd.conf"

Ver módulos

Hay dos alternativas diferentes para ver los módulos. Por un lado podemos ver todos los módulos que están compilados con Apache. Por otro lado, podemos ver todos los módulos que carga Apache (esto incluye módulos compilados aparte).

Módulos compilados

httpd -l

Esto no muestra el listado de módulos compilados en el binario de Apache:

Compiled in modules:
  core.c
  mod_authn_file.c
  mod_authn_default.c
  mod_authz_host.c
  mod_authz_groupfile.c
  mod_authz_user.c
  mod_authz_default.c
  mod_auth_basic.c
  mod_include.c
  mod_filter.c
  mod_deflate.c
  mod_log_config.c
  mod_logio.c
  mod_env.c
  mod_headers.c
  mod_unique_id.c
  mod_setenvif.c
  mod_version.c
  mod_proxy.c
  mod_proxy_connect.c
  mod_proxy_ftp.c
  mod_proxy_http.c
  mod_proxy_scgi.c
  mod_proxy_ajp.c
  mod_proxy_balancer.c
  mod_ssl.c
  prefork.c
  http_core.c
  mod_mime.c
  mod_dav.c
  mod_status.c
  mod_autoindex.c
  mod_asis.c
  mod_suexec.c
  mod_cgi.c
  mod_dav_fs.c
  mod_dav_lock.c
  mod_negotiation.c
  mod_dir.c
  mod_actions.c
  mod_userdir.c
  mod_alias.c
  mod_rewrite.c
  mod_so.c

Módulos cargados:

httpd -M

Así veremos todos los módulos que carga Apache:

Loaded Modules:
 core_module (static)
 authn_file_module (static)
 authn_default_module (static)
 authz_host_module (static)
 authz_groupfile_module (static)
 authz_user_module (static)
 authz_default_module (static)
 auth_basic_module (static)
 include_module (static)
 filter_module (static)
 deflate_module (static)
 log_config_module (static)
 logio_module (static)
 env_module (static)
 headers_module (static)
 unique_id_module (static)
 setenvif_module (static)
 version_module (static)
 proxy_module (static)
 proxy_connect_module (static)
 proxy_ftp_module (static)
 proxy_http_module (static)
 proxy_scgi_module (static)
 proxy_ajp_module (static)
 proxy_balancer_module (static)
 ssl_module (static)
 mpm_prefork_module (static)
 http_module (static)
 mime_module (static)
 dav_module (static)
 status_module (static)
 autoindex_module (static)
 asis_module (static)
 suexec_module (static)
 cgi_module (static)
 dav_fs_module (static)
 dav_lock_module (static)
 negotiation_module (static)
 dir_module (static)
 actions_module (static)
 userdir_module (static)
 alias_module (static)
 rewrite_module (static)
 so_module (static)
 python_module (shared)
 evasive20_module (shared)
 qos_module (shared)
 php5_module (shared)
Syntax OK

Aquí se puede notar la diferencia entre los módulos compilados con el Apache (linkeados como ‘static’) y los compilados como objetos compartidos que se cargan en tiempo de ejecución (‘shared’).

Ver virtual hosts

También podemos ver todos los virtual hosts que están configurados en el Apache.

httpd -S

Esto nos va a mostrar una lista como esta:

VirtualHost configuration:
1.1.1.1:80       is a NameVirtualHost
         default server localhost (/etc/httpd/conf/extra/httpd-vhosts.conf:29)
         port 80 namevhost localhost (/etc/httpd/conf/extra/httpd-vhosts.conf:29)
         port 80 namevhost www.midominio.com (/usr/local/directadmin/data/users/usuario/httpd.conf:11)
1.1.1.1:443      is a NameVirtualHost
         default server localhost (/etc/httpd/conf/extra/httpd-vhosts.conf:38)
         port 443 namevhost localhost (/etc/httpd/conf/extra/httpd-vhosts.conf:38)
         port 443 namevhost www.midominio.com (/usr/local/directadmin/data/users/usuario/httpd.conf:48)

En el ejemplo vemos un hipotético servidor (usando Directadmin) con IP 1.1.1.1, y los virtual hosts para el puerto 80 y el 443, tanto los default como los que corresponden al dominio “www.midominio.com” del usuario llamado “usuario”.

Nota sobre diferentes distribuciones

El artículo lo escribí pensando en CentOS y otras distros donde el binario de Apache se llama httpd. En Debian y sus derivados, el binario es apache o apache2. Todos los comandos que comenté acá se pueden correr invocando esos binarios o apachectl (que en algunos casos puede ser apache2ctl).

Apache: 15 años

elbarto — Tue, 23 Feb 2010 18:19:48 +0000

Un 23 de Febrero, pero del año 1995, nacía Apache, el servidor HTTP multiplataforma y de código abierto más usado en el mundo.

En sus inicios, Apache consistía solamente en un conjunto de parches a aplicar al servidor de NCSA, pero luego su código fue reescrito por completo.

Dicen que su nombre se debe a que querían que tuviese la connotación de algo que es firme y enérgico pero no agresivo, y la tribu Apache fue la última en rendirse al que pronto se convertiría en gobierno de EEUU, y en esos momentos la preocupación de su grupo era que llegasen las empresas y “civilizasen” el paisaje que habían creado los primeros ingenieros de internet.

En el blog de la Fundación Apache, comentan hoy el aniversario y relatan un poco su historia.

Tomado de Ubuntips.

mod_wsgi + Python 2.6 en CentOS

elbarto — Sun, 14 Feb 2010 22:08:19 +0000

Python

Hace algún tiempo publiqué un artículo donde explicaba cómo instalar mod_python con Python 2.6 en CentOS, por el problemita que tiene yum que no funciona con la última versión de Python. Pues bien, últimamente por lo que he venido leyendo, una alternativa mejor a mod_python es mod_wsgi, pues aparentemente funciona bastante mejor, más rápido y es la opción recomendada para usar con Apache y Django.

Por lo tanto, dejo esta guía muy sencilla de cómo instalar mod_wsgi con Python 2.6 en CentOS.

Descargar mod_wsgi, descomprimir y configurar

# cd /usr/src
# wget http://modwsgi.googlecode.com/files/mod_wsgi-3.1.tar.gz
# tar zxvf mod_wsgi-3.1.tar.gz
# cd mod_wsgi-3.1
# ./configure --with-python=/usr/bin/python2.6

Esa última línea es la clave para que utilice la instalación correcta de Python (ver el artículo anterior para saber cómo instalar Python 2.6 sin pisar la versión actual).

Luego compilamos e instalamos

# make && make install

Agregamos la línea para cargar el módulo en el httpd.conf

LoadModule wsgi_module        lib/apache/mod_wsgi.so

Y reiniciamos el Apache

service httpd restart

Luego para configurar un virtual host para que utilice mod_wsgi no es tan sencillo, pero tampoco es demasiado complicado. Básicamente hay que generar un archivo .wsgi, que no es más que un archivo Python que va a ser el que se integre con mod_wsgi y luego configurarlo en el httpd.conf. Lo que hay que tener en cuenta es que mod_wsgi no sirve contenido estático, por lo cual uno debe configurar por un lado el handling del código python y por otro los archivos estáticos. Si bien es algo distinto a lo que solemos hacer con mod_php, es algo bastante lógico y es una buena práctica pensar en servir por separado el contenido dinámico y el estático.

Como es un poco complejo, lo mejor es leer la guía correspondiente. En el sitio de mod_wsgi van a ver que hay mucha documentación. Particularmente, la guía de integración con Django es muy útil.