tail -f | sysadmin » Apache

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é.

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.

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.

mod_python + Python 2.6 en CentOS

elbarto — Sat, 14 Mar 2009 21:03:06 +0000

mod_python

Hace algún tiempo escribí un pequeño artículo sobre cómo instalar mod_python en Apache 2.2. El tema es que, lógicamente, cada tanto uno quiere actualizar Python para tener las últimas correcciones de bugs y los últimos features. En mi caso quería instalar Python 2.6.1 en un CentOS. El tema es que con yum no veía ninguna actualización, pero tenía Python 2.4.x instalado y yo quería lo último. Me bajé el código, lo compilé, lo instalé y al rato me di cuenta que al hacer eso había roto el yum (que está escrito en Python). Así fue que llegué a darme cuenta de cómo instalar Python 2.6.1 por separado, y recompilar mod_python para que trabaje con esa versión, y esto es lo que quería compartir con ustedes.

Primero: Instalar Python 2.6 en una ubicación alternativa

Lo primero que vamos a hacer es descargar, compilar e instalar Python 2.6 en una ruta alternativa, es decir, sin pisar la instalación actual de Python 2.4 que viene con CentOS.

# cd /usr/src
# wget http://www.python.org/ftp/python/2.6.1/Python-2.6.1.tgz
# tar zxvf Python-2.6.1.tgz
# cd Python-2.6.1/
# ./configure --prefix=/usr
# make
# make altinstall

La clave está justamente en el último paso. En vez de hacer “make install”, hacemos “make altinstall” para que se instale sin sobreescribir la versión actual de Python. Básicamente lo que hace es instalar todas las libs en /usr/lib/python2.6 (esto lo hace de todas formas), y luego crear el binario /usr/bin/python2.6 pero sin sobreescribir /usr/bin/python.

Editado el 10/03/2010: En algunos casos puede ser necesario agregar al configure de Python la opción –enable-shared. Gracias Orcen!

Segundo: Recompilar mod_python

Ahora queda recompilar mod_python contra la nueva versión de python.

# cd /usr/src
# wget http://www.apache.org/dist/httpd/modpython/mod_python-3.3.1.tgz
# tar -zxvf mod_python-3.3.1.tgz
# cd mod_python-3.3.1
# ./configure --with-python=/usr/bin/python2.6
# make
# make install

La clave aquí está en el configure al que le pasamos el parámetro de qué binario de Python debe usar.

Tercero: Reiniciar Apache y probar

Por último queda reiniciar Apache y repetir la prueba explicada en el artículo anterior.

# service httpd restart

Instalar mod_evasive en Apache para dificultar ataques DoS

elbarto — Sat, 07 Feb 2009 17:46:09 +0000

Apache Web Server

Describiremos a continuación los pasos para la instalación y configuración de mod_evasive, un módulo para Apache desarrollado por Nuclear Elephant para prevenir ataques DoS. Antes que nada es preciso advertir que no se trata de una solución definitiva y que, incluso, bajo ataques importantes, no sirve de mucho. Pero es una buena forma de evitar ataques pequeños y mantener la salud de nuestro servidor.

¿Cómo funciona?

Básicamente lo que hace es mantener una tabla dinámica con las URIs accedidas por las distintas IPs de los clientes del Apache, y permite ejecutar algunas acciones cuando una misma IP solicita un mismo recurso (una misma URI o elementos de un mismo sitio) más de n veces en m segundos. La acción por default que ejecuta el mod_evasive es, una vez superado el máximo de requests por segundo permitidos, bloquear durante una cantidad de segundos al cliente (la IP) devolviendo un error 403 (Forbidden) a la petición HTTP. Pero lo interesante es que también permite ejecutar un comando de sistema al registrarse un intento de ataque, con lo cual se puede agregar una regla al iptables para bloquear la IP del cliente.

Instalación

La instalación es muy sencilla. Basta con descargar el tar, descomprimirlo, compilarlo con apxs y habilitarlo en el httpd.conf.

# cd /usr/src
# wget http://www.zdziarski.com/projects/mod_evasive/mod_evasive_1.10.1.tar.gz
# tar zxvf mod_evasive_1.10.1.tar.gz
# cd mod_evasive
# apxs -cia mod_evasive20.c # para Apache 1.3 el comando sería apxs -cia mod_evasive.c
# vi /etc/httpd/conf/httpd.conf # editamos la configuracion
# service httpd restart # reiniciamos el Apache

En el httpd.conf habría que agregar las siguientes líneas.


DOSHashTableSize 3097
DOSPageCount 2
DOSSiteCount 50
DOSPageInterval 1
DOSSiteInterval 1
DOSBlockingPeriod 300

Opciones de configuración

A continuación transcribo la descripción de las distintas opciones de configuración tomada de esta excelente guía de Xombra Team.

DOSHashTableSize – Establece el número de nodos a almacenar para cada proceso de peticiones de la tabla hash (contenedor asociativo de recuperación de peticiones por medio de claves que agiliza las respuestas del servidor). Si aplicamos un número alto a este parámetro obtendremos un rendimiento mayor, ya que las iteraciones necesarias para obtener un registro de la tabla son menores. Por contra, y de forma evidente, aumenta el consumo de memoria necesario para el almacenamiento de una tabla mayor. Se hace necesario incrementar este parámetro si el servidor atiende un número abultado de peticiones, aunque puede no servir de nada si la memoria de la máquina es escasa.
DOSPageCount – Indica el valor del umbral para el número de peticiones de una misma página (o URI) dentro del intervalo definido en DOSPageInterval. Cuando el valor del parámetro es excedido, la IP del cliente se añade a la lista de bloqueos.
DOSSiteCount – Cuenta cuántas peticiones de cualquier tipo puede hacer un cliente dentro del intervalo definido en DOSSiteInterval. Si se excede dicho valor, el cliente queda añadido a la lista de bloqueos.
DOSPageInterval – El intervalo, en segundos, para el umbral de petición de páginas.
DOSSiteInterval – El intervalo, en segundos, para el umbral de petición de objetos de cualquier tipo.
DOSBlockingPeriod – Establece el tiempo, en segundos, que un cliente queda bloqueado una vez que ha sido añadido a la lista de bloqueos. Como ya se indicó unas líneas atrás, todo cliente bloqueado recibirá una respuesta del tipo 403 (Forbidden) a cualquier petición que realice durante este periodo.
DOSEmailNotify – Un e-mail será enviado a la dirección especificada cuando una dirección IP quede bloqueada. La configuración del proceso de envío se establece en el fichero mod_evasive.c de la forma /bin/mail -t %s, siendo %s el parámetro que queda configurado en este parámetro. Será necesario cambiar el proceso si usamos un método diferente de envío de e-mails y volver a compilar el módulo con apxs (por ejemplo, la opción t ha quedado obsoleta en las últimas versiones del comando).
DOSSystemCommand
– El comando reflejado se ejecutará cuando una dirección IP quede bloqueada. Se hace muy útil en llamadas a herramientas de filtrado o firewalls. Usaremos %s para especificar la dirección IP implicada. Por ejemplo, podemos establecer su uso con iptables de la forma siguiente:
```
DOSSystemCommand “/sbin/iptables –I INPUT –p tcp –dport 80 –s %s –j DROP”
```
DOSLogDir – Establece una ruta para el directorio temporal. Por defecto, dicha ruta queda establecida en /tmp, lo cual puede originar algunos agujeros de seguridad si el sistema resulta violado.
DOSWhitelist
– La dirección IP indicada como valor del parámetro no será tenida en cuenta por el módulo en ningún caso. Para cada dirección IP a excluir ha de añadirse una nueva línea con el parámetro. Por ejemplo, dejaremos fuera del chequeo del módulo a un posible bot que use los siguientes rangos de direcciones:
```
DOSWhitelist 66.249.65.*
DOSWhitelist 66.249.66.*
```

Probarlo

¿Y cómo sé si está funcionando? mod_evasive viene con un pequeño script en perl para probar el funcionamiento del módulo. Para eso vamos al directorio de mod_evasive y ejecutamos el script test.pl:

# cd /usr/src/mod_evasive
# perl test.pl
HTTP/1.1 200 OK
HTTP/1.1 200 OK
HTTP/1.1 200 OK
HTTP/1.1 200 OK
HTTP/1.1 200 OK
HTTP/1.1 200 OK
HTTP/1.1 200 OK
HTTP/1.1 200 OK
HTTP/1.1 200 OK
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden

Y si pusimos la directiva para bloquear la IP por iptables podemos verlo con:

# iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
DROP tcp --  anywhere tcp dpt:http

Referencias

Apache: solucionar “(28) No space left on device”

elbarto — Tue, 13 Jan 2009 17:09:20 +0000

Apache Web Server

Recién me topé con un error medio raro, que jamás me había sucedido y afortunadamente encontré rápido la solución en internet. Por eso me pareció bueno compartirlo, para que si se encuentran con este error sepan cómo corregirlo y para que quede la solución online por si a otra persona le sucede.

De repente me avisan que está caído el Apache de uno de los servers y que al reiniciarlo no levanta. Entro al servidor y veo que efectivamente falla al iniciar. Reviso el error log y veo lo siguiente:

[Tue Jan 13 14:34:03 2009] [notice] mod_python: Creating 8 session mutexes based on 450 max processes and 0 max threads.
[Tue Jan 13 14:34:03 2009] [notice] mod_python: using mutex_directory /tmp
[Tue Jan 13 14:34:03 2009] [error] (28)No space left on device: mod_python: Failed to create global mutex 0 of 8 (/tmp/mpmtx297990).
Configuration Failed

No me parecía que pudiera haber un error con mod_python porque siempre funcionó. De todas formas, lo deshabilité, probé de nuevo y me daba el mismo error en otra parte:

[Tue Jan 13 14:31:05 2009] [emerg] (28)No space left on device: Couldn't create accept lock (/var/logs/accept.lock.29427) (5)

Evidentemente el problema iba por otro lado, y lo primero que pensé era que me estaba quedando sin espacio en el disco. Revisé eso y tampoco. El consumo del disco era muy bajo (25%). Entonces recurrí a Google y encontré la solución en eHow.

Al parecer es un problema común, que se solucione revisando los arrays de semáforos que está usando el Apache y removiéndolos.

# Revisar los semáforos de Apache
ipcs -s | grep apache
# Remover todos los semáforos
for i in `ipcs -s | grep apache | awk '{print $2}'` ; do ipcrm -s $i; done
# Iniciar Apache
service httpd start

Fuente: http://www.ehow.com/how_4397601_error-no-space-left-device.html