# rm-rf.es | Administración de sistemas

Blog de un SysAdmin Unix, Gnu/Linux, Windows y lo que haga falta.

cvs commit: Up-to-date check failed for… (rancid)

Si usáis Rancid para tener un control de versiones de las configuraciones de vuestros dispositivos de red, puede llegar un momento en el que por X motivo se genere un problema en el repositorio y recibáis este error en los logs, que además provoca que no se actualice ningún fichero de configuración:

cvs diff: Diffing .
cvs diff: Diffing configs
cvs commit: Examining .
cvs commit: Examining configs
cvs commit: Up-to-date check failed for [...]
cvs commit: Up-to-date check failed for [...]
cvs commit: Up-to-date check failed for [...]
cvs [commit aborted]: correct above errors first!

Para solucionarlo, debemos hacer un update del repositorio con CVS (Concurrent Versions System) para resincronizarlo y que Rancid pueda volver a utilizarlo. Nos tenemos que colocar en la ruta en la que se encuentran los ficheros de configuración de los dispositivos que están dando el problema y ejecutar el update:

rancid@server:~$ cd /var/rancid/.../configs/
rancid@server:~$ cvs update

Si recibís un error de comando no encontrado verificar que el binario cvs se encuentra en el PATH, en caso contrario ejecutadlo con la ruta completa, por ejemplo:

rancid@server:~$ /usr/local/bin/cvs update

Y probamos a ejecutar rancid y verificar que se actualizan las configuraciones:

rancid@server:~$ /usr/local/rancid/bin/rancid-run

Monitorizar Oracle iPlanet Web Server con get-perfdump

Oracle SolarisLa utilidad de monitorización en servidores Web de Sun/Oracle ha mejorado mucho a partir de la versión 7.0. Si bien antes únicamente podíamos acceder a estos datos vía web, ahora podemos hacerlo a través de la shell/CLI wadm, permitiendo acceder a estadísticas a tiempo real de monitorización sin necesidad de hacerlo vía HTTP, con los problemas que conllevaba con el sistema cargado.

La nueva versión, disponible en Sun Java System Web Server, Oracle iPlanet Web Server 7.0 o como lo queráis llamar, añade la posibilidad de ver las Ips y peticiones que se están haciendo a cada instancia y así poder detectar con mayor facilidad el origen de un cuello de botella o sobrecarga del sistema.

Para acceder a wadm nos situamos en la ruta base del servidor web y ejecutamos el siguiente comando indicando usuario y clave de administración:

root@solaris:/opt/oracle/webserver7# ./bin/wadm --user=admin
Indique admin-user-password>
Conexión a localhost:8989
Oracle iPlanet Web Server 7.0.12 B07/01/2011 03:56
wadm>

Una vez dentro, elegimos la instancia y nodo del que queremos ver las estadísticas y tendremos el volcado de información:

wadm> get-perfdump --config solaris --node localhost

La información que recibimos es la siguiente. Tened en cuenta que es un webserver de prueba por lo que no hay apenas información:

wadm> get-perfdump --config solaris --node localhost

Oracle iPlanet Web Server 7.0.12 B07/01/2011 03:56 (SunOS DOMESTIC)

Server started Sat Feb 11 15:24:28 2012
Process 1133 started Sat Feb 11 15:24:29 2012

ConnectionQueue:
-----------------------------------------
Current/Peak/Limit Queue Length            0/4/16384
Total Connections Queued                   20
Average Queue Length (1, 5, 15 minutes)    0,00, 0,00, 0,00
Average Queueing Delay                     10,88 milliseconds

ListenSocket http-listener-1:
------------------------
Address                   https://0.0.0.0:443
Acceptor Threads          1
Default Virtual Server    solaris

ListenSocket http-listener-2:
------------------------
Address                   http://0.0.0.0:80
Acceptor Threads          1
Default Virtual Server    solaris

KeepAliveInfo:
--------------------
KeepAliveCount        6/32768
KeepAliveHits         8
KeepAliveFlushes      0
KeepAliveRefusals     0
KeepAliveTimeouts     6
KeepAliveTimeout      30 seconds

SessionCreationInfo:
------------------------
Active Sessions           0
Keep-Alive Sessions       6
Total Sessions Created    8/129

CacheInfo:
-----------------------
File Cache Enabled       yes
File Cache Entries       14/1024
File Cache Hit Ratio     76/108 ( 70,37%)
Maximum Age              30
Accelerator Entries      0/1024
Acceleratable Requests   18/45 ( 40,00%)
Acceleratable Responses  0/18 (  0,00%)
Accelerator Hit Ratio    0/0 (  0,00%)

Native pools:
----------------------------
NativePool:
Idle/Peak/Limit               1/1/128
Work Queue Length/Peak/Limit  0/0/0

DNSCacheInfo:
------------------
enabled             yes
CacheEntries        0/1024
HitRatio            0/0 (  0,00%)

Async DNS disabled

Performance Counters:
------------------------------------------------
                           Average         Total      Percent

Total number of requests:                     20
Request processing time:    0,0395        0,7899

default-bucket (Default bucket)
Number of Requests:                           20    (100,00%)
Number of Invocations:                       289    (100,00%)
Latency:                    0,0050        0,0999    ( 12,65%)
Function Processing Time:   0,0345        0,6899    ( 87,35%)
Total Response Time:        0,0395        0,7899    (100,00%)

Sessions:
-------------------------------------------------------
Process  Status  Client  Age  VS  Method  URI  Function

Resultan muy interesantes para detectar problemas y optimizar el rendimiento la sección “ConnectionQueue:” y “Sessions:“, en esta última es donde veremos las Ips de acceso, peticiones, URI, etc. Toda la información es bastante descriptiva y comprensible a primera vista. A partir de esta información se pueden generar scripts de recolección de datos, añadir a monitorización tipo Nagios o BigBrother, etc. Los que utilicéis servidores anteriores a la versión 7.0 habréis detectado un gran cambio de la cantidad de información del antiguo perfdump al nuevo.

Configurar un syslog remoto para centralizar logs

Syslogd permite ser configurado para escuchar y aceptar conexiones remotas, lo que implica poder recibir datos y almacenarlos de clientes externos (syslog de otros servidores). Esto es perfecto para crear un servidor syslog central y enviarle todos los logs de otros servidores, con la finalidad de tenerlos y gestionarlos todos en el mismo sitio.

La configuración es bastante sencilla. Vamos a ver los pasos a realizar en el servidor central syslogd y en los clientes.

Syslogd central

En el servidor syslogd que va a recibir todos los logs hay que revisar dos cosas. La primera que esté configurado para aceptar conexiones remotas. Para ello hay que añadir el parámetro “-r” a la línea de arranque. Ya sea en el script de /etc/init.d/syslog o si lo arrancamos a mano. En el script de init.d suele ser en la variable donde se especifican los parámetros:

SYSLOGD_OPTIONS="-r -m 0"

Y si lo arrancaramos a mano:

# syslogd -r -m 0

Una vez arrancado, debería estar escuchando en el puerto UDP 514. Aseguraos que está abierto en el firewall:

syslogd   13819      root    7u     IPv4  660344590      UDP *:syslog

Clientes syslogd

A la hora de configurar los clientes que van a enviar los logs al servidor central, únicamente tenemos que especificar qué logs van a ir al servidor central, lo haremos en el fichero de configuración /etc/syslog.conf.

Una línea estandar es esta por ejemplo, en la que mandamos a /var/log/messages los logs de cron, info, mail, etc:

*.info;mail.none;authpriv.none;cron.none		/var/log/messages

Para que estos logs se dejen de almacenar en el log local y pasen al remoto, únicamente indicamos con @servidor_syslogd el hostname/ip del servidor syslogd. Si por ejemplo el servidor syslogd tiene el hostname syslogd01:

*.info;mail.none;authpriv.none;cron.none	     @syslogd01

Reiniciamos syslogd y comenzaríamos a enviar los logs al servidor central:

# /etc/init.d/syslogd restart

Un ejemplo de como veríamos el log central con varias entradas de distintos servidores (servidor01, servidor02,…):

Aug 12 18:15:58 servidor01 snmpd[27557]: Connection from UDP: [xx.xx.xx.xx]:39892 
Aug 12 18:15:58 servidor01 snmpd[27557]: Received SNMP packet(s) from UDP: [xx.xx.xx.xx]:39892 
Aug 12 18:15:58 servidor02 snmpd[27557]: Connection from UDP: [xx.xx.xx.xx]:56751 
Aug 12 18:15:58 servidor02 snmpd[27557]: Received SNMP packet(s) from UDP: [xx.xx.xx.xx]:56751 
...
...

Comprobar el estado de los mirror de CentOS por país

Normalmente todos tenemos una lista de mirrors de CentOS preferida, ya sea por cercanía geográfica o por su velocidad. Si bien es fácil comprobar de forma manual si un mirror está online u offline, no deja de ser útil esta web en la que podemos ver el estado a tiempo real de los mirror de CentOS separados por países, con gráficas, histórico, reportes, etc.

La aplicación está hecha con el software mirmon. Pinchad en la imagen para acceder  al sitio web:

CentOS mirror status

Exim: monitorizar la cola de correo en Big Brother

Hoy vamos a ver la forma de integrar en el sistema de monitorización Big Brother la supervisión del estado de la cola de correos de exim. Todo ello gracias al script bb-exim.sh creado por Carl C. Inglis.

Es un script fácil de entender, modificar y personalizar a nuestros requerimientos. Lo más básico a conocer es que podemos realizar y monitorizar lo siguiente:

# Tests are:
#               RUN - Test if the daemon is running
#               QUEUE - Check the size of the queue (see below)
#               REJECT - Check to see if the reject log is > 0 bytes long
#               PANIC - Check to see if the panic log is > 0 bytes long
#               FROZEN - Check to see if there are any frozen messages
#                 IGNOREFROZENERRS - Ignore frozen messages with a sender
#                                    of "<>".  (i.e., error responses.)
TESTRUN="y"
TESTQUEUE="y"
TESTREJECT="n"
TESTPANIC="y"
TESTFROZEN="y"
IGNOREFROZENERRS="y"

Como veis, por defecto revisa que el demonio de exim está corriendo, así como el tamaño de la cola de correo, el tamaño de los logs panic y reject (no por defecto para el reject)así como el número de correo en estado frozen o sin destinatario válido. Después, hay dos variables para seleccionar el umbral de aviso para warning y panic con el número de correos en cola:

TESTQUEUEALERT="50"
TESTQUEUEPANIC="100"

Revisad también que la ruta al binario de exim es la correcta, a los logs, etc:

EXIMBINARY="/usr/sbin/exim"
EXIMREJECT="/var/log/exim/rejectlog"
EXIMPANIC="/var/log/exim/paniclog"

La instalación es igual que cualquier extensión de Big Brother, ubicáis el script en la carpeta ext/, le asignais permisos de ejecución para el usuario y después lo añadís en el fichero bb-bbext y reiniciamos Big Brother:

# vim /ruta_a_big_brother/ext/bb-exim.sh
# chmod 0750 /ruta_a_big_brother/ext/bb-exim.sh
# chown usuariobb. /ruta_a_big_brother/ext/bb-exim.sh
# vim /ruta_a_big_brother/etc/bb-bbexttab
localhost :  : bb-exim.sh

Personalmente he realizado unas cuantas modificaciones para adecuarlo a mis necesidades. Entre ellas la necesidad de usar sudo ya que el usuario Big Brother no tiene privilegios, otra de ellas la visualización de la cola de correo. En lugar de mostrar la lista de mensajes como se vería con un exim -bp, la parseo mediante exiqsumm -c para que sea agradable a la vista y más rápido de visualizar y claro:

# exim -bp
 2h  5.9K xx-0000ko-HA 
          xxx_70@xxx.com

 2h  6.0K xx-0000kt-OZ 
          xxx_70@xxx.com

76m  9.3K xx-0003Ee-OO 
          xxx@xxx.org

51m  7.8K xx-0005cQ-Te 
          xxx.xxx@xxx.org
# exim -bp | exiqsumm -c

Count Volume Oldest Newest Domain
----- ------ ------ ------ ------

279 23MB 63h 30m xxx.org
2 12KB 2h 2h xxx.com
2 272KB 14h 12h xxx.com

---------------------------------------------------------------
289 28MB 63h 20m TOTAL

El resultado final, podría ser algo así:

Exim Big Brother

Podéis descargar el script original aquí.

Cacti: arreglar gráficos con cortes intermitentes

Es posible que cuando en Cacti comencéis a tener una cantidad considerable de hosts monitorizandose de repente algunos de los gráficos no se generen de forma correcta y aparezcan cortes intermitentes en los que los datos a monitorizar no se han podido recolectar, ejemplo:

Cacti gráficos con cortes intermitentes

Probablemente el problema radique en que el “Poller” no tiene tiempo suficiente para recolectar los datos de todos los hosts, sobre todo si configuráis el cron cada poco tiempo. En mi caso, con un número considerable de hosts y cada 5 minutos no había manera. Usando el Poller en PHP (cmd.php), no Spine, simplemente aumentando el número de procesos concurrentes de 1 a 5 el problema ha quedado solucionado. En el caso de que uséis Spine simplemente se trata de tunear los parámetros correspondientes.

Para cmd.php, accedéis a Console > Settings > Poller y es la opción:

Maximum Concurrent Poller Processes
The number of concurrent processes to execute. Using a higher number when using cmd.php will improve performance. Performance improvements in spine are best resolved with the threads parameter

 

Gestión y monitorización de servicios con Monit

Creo que todos los administradores de sistemas coincidimos en que un buen sysadmin es aquel que es capaz de conseguir que los sistemas se autogestionen en la mayor parte de lo posible. Esto implica, además de disponer de un buen sistema de monitorización tipo Big Brother, Nagios o Cacti, disponer de herramientas para que cuando un servicio o aplicación falle y se pare, automáticamente intenten reiniciarla sin necesidad del administrador.

Monit es una herramienta muy sencilla de instalar y configurar que se encargará de hacer esta tarea por nosotros. Monit permite monitorizar y gestionar procesos, ficheros, directorios y sistemas de ficheros.

Su instalación es realmente sencilla, podéis utilizar gestores de descargas como YUM o APT o compilarlo desde el código fuente (no tiene ningún misterio). Descarga aquí.

En CentOS o RHEL por ejemplo:

# yum install monit

Una vez instalado, simplemente tenéis que personalizar la configuración, encontraréis el fichero en la ruta /etc/monit.conf. Cada sección o directiva está perfectamente explicada, no obstante las más importantes:

set daemon  60             # check services at 2-minute intervals
     with start delay 240  # optional: delay the first check by 4-minutes (by
#                          # default Monit check immediately after Monit start)

set daemon indica que levantemos monit como demonio, a continuación le especificamos el intervalo de tiempo para el chequeo de servicios, también indicamos un retardo de 4 minutos para que no los chequee nada más arrancar.

 set mailserver localhost               # primary mailserver
set alert xxx@xxx.com/pre>

Con set mailserver indicaremos el servidor de correo a utilizar para el envío de alertas. Set alert especificará la cuenta de correo a la que enviar los avisos.

Ya pasamos a la configuración de servicios y lo que vamos a monitorizar. En primera instancia podemos indicar que nos envíe correos cuando el sistema alcance una determinada carga o uso de CPU, memoria, etc. Descomentar y personalizar según requerimientos:

#  check system myhost.mydomain.tld
#    if loadavg (1min) > 4 then alert
#    if loadavg (5min) > 2 then alert
#    if memory usage > 75% then alert
#    if swap usage > 25% then alert
#    if cpu usage (user) > 70% then alert
#    if cpu usage (system) > 30% then alert
#    if cpu usage (wait) > 20% then alert

También podemos monitorizar cambios en ficheros, permisos, checksum, usuarios y grupos, etc

## Check if a file exists, checksum, permissions, uid and gid. In addition
## to alert recipients in the global section, customized alert can be sent to
## additional recipients by specifying a local alert handler. The service may
## be grouped using the GROUP option. More than one group can be specified by
## repeating the 'group name' statement.
#
#  check file apache_bin with path /usr/local/apache/bin/httpd
#    if failed checksum and
#       expect the sum 8f7f419955cefa0b33a2ba316cba3659 then unmonitor
#    if failed permission 755 then unmonitor
#    if failed uid root then unmonitor
#    if failed gid root then unmonitor
#    alert security@foo.bar on {
#           checksum, permission, uid, gid, unmonitor
#        } with the mail-format { subject: Alarm! }
#    group server

En la parte de servicios podemos configurar servicios como Apache, Exim, FTP, MySQL, etc para que cuando haya un problema y se paren Monit los levante automáticamente, a continuación os dejo el ejemplo para Apache (rutas y demás pueden diferir según la instalación):

  check process apache with pidfile /usr/local/apache/logs/httpd.pid
    start program = "/etc/init.d/httpd start" with timeout 60 seconds
    stop program  = "/etc/init.d/httpd stop"
    if cpu > 60% for 2 cycles then alert
    if cpu > 80% for 5 cycles then restart
    if totalmem > 200.0 MB for 5 cycles then restart
    if children > 250 then restart
    if loadavg(5min) greater than 10 for 8 cycles then stop
    if failed host rm-rf.es port 80 protocol http
       and request "/index.phpsy"
       then restart
    if failed port 443 type tcpssl protocol http
       with timeout 15 seconds
       then restart
    if 3 restarts within 5 cycles then timeout
    #depends on apachectl
    group server

Como véis monitoriza el PID de apache y si no lo encuentra lo reinicia. También monitoriza el uso de CPU y memoria y si es muy elevado en X ciclos de comprobación lo reinicia o avisa al administrador, lo mismo para el SSL, etc.

En la ayuda de Monit encontraréis información sobre como añadir más servicios, aunque simplemente es coger el de apache como base y modificar parámetros. Otro ejemplo para MySQL:

check process mysql with pidfile /var/lib/mysql/mysql.pid
   group database
   start program = "/etc/init.d/mysql start"
   stop program = "/etc/init.d/mysql stop"
   if failed host 127.0.0.1 port 3306 then restart
   if 5 restarts within 5 cycles then timeout

Una vez que tengamos todo configurado, solo queda iniciar el servicio y comprobar su funcionamiento, por ejemplo tirando uno de los servicios monitorizados.

# /etc/init.d/monit start
Starting monit: Starting monit daemon
Monit start delay set -- pause for 240s
                                                           [  OK  ]

Tener Monit instalado es un buen ejemplo de monitorización proactiva en vuestros servidores. Os sirva para evitar tener que levantaros alguna que otra madrugada a levantar un servicio.

Estadísticas de correo, spam y virus con Mailgraph

Mailgraph es un sistema de estadísticas que utiliza como frontend RRDtool y permite recolectar de forma gráfica el número de correos enviados y recibidos en gráficos diarios, semanales, mensuales y anuales. Básicamente tenemos un script en perl corriendo en el servidor, es el encargado de recolectar los datos (rrd), y por otra parte un script cgi a través del cual se generan y visualizan los gráficos vía web.

Instalación de Mailgraph

Mailgraph requiere tener instalado RRDtool y el módulo de Perl File::Tail. RRDTool se puede instalar tanto desde el gestor de paquetes como compilandolo a mano. Lo más rápido, desde YUM o APT:

# yum install rrdtool.i386

El módulo de perl lo podemos instalar desde cPan:

cpan> install File::Tail

Descargamos y descomprimimos la última versión desde el sitio web de mailgraph:

# wget http://mailgraph.schweikert.ch/pub/mailgraph-1.14.tar.gz
#  tar -xzvf mailgraph-1.14.tar.gz
# cd mailgraph-1.14

Ahora vamos a modificar el script base que nos ofrecen para el arranque del demonio en perl (mailgraph-init). Básicamente, tenemos que modificar las siguientes variables:

PATH=/bin:/usr/bin
MAILGRAPH_PL=/usr/local/bin/mailgraph.pl # RUTA DONDE VAMOS A COLOCAR EL SCRIPT
MAIL_LOG=/var/log/maillog # RUTA DE NUESTRO LOG DE CORREO
PID_FILE=/var/run/mailgraph.pid
RRD_DIR=/var/lib/mailgraph # RUTA DONDE ALMACENAR LOS RRD

Una vez realizado esto, movemos el script a init.d, le asignamos permisos de ejecución y lo arrancamos:

# cp mailgraph-init /etc/init.d/mailgraph
#chmod 0755 /etc/init.d/mailgraph
# /etc/init.d/mailgraph start

En este momento el demonio debería estar corriendo:

# ps aux | grep mailgraph
root     13023  1.1  0.2  14132  4128 ?        SNs  17:39   0:27 /usr/bin/perl -w /usr/local/bin/mailgraph.pl -l /var/log/maillog -d --daemon-pid=/var/run/mailgraph.pid --daemon-rrd=/var/lib/mailgraph

Ahora solo nos queda ejecutar el cgi para ver los gráficos generados mediante este script. Lo tendréis que ubicar en una ruta en la que podáis ejecutar CGI, debería tener en apache permitido lo siguiente:

<Directory /carpeta/web/script>
Options ExecCGI
</Directory>

Aseguraos también de que mod_perl está instalado para la ejecución del cgi, y que el handler está configurado en apache:

AddHandler cgi-script .cgi

Esto debería ser todo, ejecutamos el cgi desde el navegador y veremos algo tal que así, en este enlace tenéis una demo a tiempo real.

MailGraph
mailgraph