Logrotate, rotado automático de logs en Linux

Una de las tareas más importantes de un administrador de sistemas es la correcta gestión de los logs que se generan. Almacenar información que nos permita descubrir un error es importante, pero esa información no debe terminar por saturar nuestros sistemas.

Y una de las herramientas que nos van a permitir cumplir ese objetivo es logrotate, esta utilidad en linux nos permite rotar, comprimir y renovar los ficheros de log de forma automatizada. En este post voy a exponer algunos ejemplos que yo utilizo para este cometido, pero desde “man logrotate” tenéis información adicional para adaptar la configuración a vuestras necesidades.

El fichero principal de configuración está accesible por defecto en /etc/logrotate.conf

$ cat /etc/logrotate.conf
weekly
rotate 4
create
include /etc/logrotate.d
/var/log/mail {
    daily
    size 1M
    create 0664 root utmp
    rotate 1
}

El directorio /etc/logrotate.d/ contiene ficheros de configuración de otras aplicaciones instaladas en el sistema, como Apache (httpd) por ejemplo. Y allí podéis crear vuestro propio fichero para ejecutar la rotación de logs.

Así la configuración básica, incluye una ruta, seguida de llaves, donde se incluye la configuración que se quiere para el rotado de logs en esa ruta.

A través de las opciones daily, weekly, monthly, yearly se le indica cada cuanto tiempo se debe ejecutar el rotado. Así si elegimos weekly, una vez a la semana se hará el rotado del fichero indicado.

Rotar cuando se alcanza un determinado tamaño de fichero

/var/log/mail.log {
        size 1M
        rotate 4
}

Con la opción size se le indica a partir de que tamaño deber rotar, si el fichero no ha alcanzado el tamaño, en nuestro ejemplo 1 mega, el fichero no será rotado.

Entre las opciones más destacadas encontramos rotate, seguido de un número entero, le indica cuantos ficheros debemos conservar. Una vez alcanzado ese número se borrará el más antiguo.

Otra opción interesante es copytruncate, que realiza una copia del fichero original y luego vacia el fichero para que los procesos que estaban trabajando con ese fichero puedan seguir haciéndolo a pesar de la rotación.

Y la otra opción, que casi diría que es fija para la mayoría de administradores, es poder comprimir los logs una vez realizada la rotación para reducir espacio. Esta opción se indica con compress. Una última opción que puede ser de mucha utilidad es missingok, que evita retornar un error en caso de que se produzca.

Así una configuración básica que rotase todos los logs dentro del directorio /var/log/ cuando alcancen el mega de tamaño, manteniendo 5 rotados y comprimiendo los antiguos, quedaría así:

/var/log/*.log {
        size 1M
        copytruncate
        rotate 5
        compress
        missingok
}

Mostrar colores en command line (Console – Symfony2)

Desde hace algún tiempo que utilizo el component Console de Symfony2 para crear mis propios comandos en las aplicaciones Symfony2 o en solitario para otros proyectos. Una de las ventajas, es su formato colorado en pantalla, que permite distinguir de un vistazo cuando ha fallado algo o si todo ha sido correcto.

Este coloreado resulta de aplicar unos estilos predeterminados (podemos generar los nuestros propios si lo necesitamos), pero para que esto funciones es necesario tener instalados algunos paquetes. En Linux haremos uso de php-process, mientras que en Mac debemos utilizar php-posfix.

Paquetes para probar PHP 7 en Fedora y RHEL

Para los que queráis ir probando las novedades que trae PHP 7 sin necesidad de compilar desde los fuentes, el repositorio de Remi ya tiene disponible el paquete php70 en remi-test, para sistemas RHEL y Fedora.

Si no tienes los repos de Remi, puedes descargarlos desde su página, seleccionando el sistema operativo que corresponda. Puedes hacer la instalación del repo manualmente o bajarte el paquete rpm de auto-configuración del repositorio.

El paquete está disponible para Fedora 20, 21, 22 y para Enterprise Linux 6 y 7 (RHEL, CentOs, …) como una instalación separada, por lo que puedes hacerla vivir fácilmente con otros paquetes de PHP que tengas ya instalados. Para realizar la instalación:

yum --enablerepo=remi,remi-test install php70 
[salva@localhost ~]# php70 -v
PHP 7.0.0-dev (cli) (built: Apr  3 2015 08:04:28) 
Copyright (c) 1997-2015 The PHP Group
Zend Engine v3.0.0-dev, Copyright (c) 
1998-2015 Zend Technologies

La instalación se realiza bajo /opt/remi, sólo está disponible bajo arquitectura x86_64 y, por el momento, sólo instala la versión 7.0.0-dev. En el blog de Remi podéis encontrar más información.

Utilidades para trabajar con expresiones regulares

El otro día un compañero (gracias, Óscar) me envío un listado de URL’s con utilidades e información relacionada con expresiones regulares que siempre es útil tener a mano:

Yum: resolver el error “rpmdb open failed”

Tras intentar hacer alguna operación con yum en consola nos encontramos con el error “rpmdb open failed”.

Este error indica que las bases de datos que se encuentran bajo el directorio /var/lib/rpm( están dañadas. Su formato de nombre de fichero es del tipo “_db*”, así que para deshacernos de este problema nada más sencillo que borrarlas y volver a crearlas.

Como root ejecutamos el borrado de las bases de datos, las regeneramos, limpiamos la cache y la volvemos a crear.

$
$ rm -f /var/lib/rpm/_db*
$ rpm -vv --rebuilddb 
$ yum clean all
$ yum makecache 
$

Instalar Google Chrome en Linux a través de YUM

Google Chrome es ya uno de los navegadores de referencia en todas las plataformas y además cuenta con el beneplácito de los usuarios que ven en él un modo fácil y rápido de escapar a Internet Explorer, además de aportar muchas herramientas adicionales.

No es mi propósito hablar de las ventajas del navegador del buscador más popular de la red, para eso hay muchos artículos por la red, el interés de este post es hablar de cómo instalarlo en sistemas Red Hat y derivados a través del popular YUM.

Podemos optar por dos modos, el primero descargando directamente el RPM desde la página de Google y la segundo agregando el repositorio de YUM. El segundo método tiene evidentes ventajas sobre el primero, sobre todo a la hora de mantener actualizado el sistema.

Para instalarlo con el RPM en local, procedemos a descargarlo desde la web de Google, nos situamos en el directorio e instalamos con:

yum localinstall --nogpgcheck google-chrome-stable_current_x86_64.rpm

Para usar el segundo método, tendremos que crear el repositorio, para ello generamos el fichero /etc/yum.repo.d/google.repo y ponemos lo siguiente:


[google-chrome-32]
name=Google Chrome - 32-bit
baseurl=http://dl.google.com/linux/chrome/rpm/stable/i386
enabled=1
gpgcheck=1
gpgkey=https://dl-ssl.google.com/linux/linux_signing_key.pub

[google-chrome-64]
name=Google Chrome - 64-bit
baseurl=http://dl.google.com/linux/chrome/rpm/stable/x86_64
enabled=1
gpgcheck=1
gpgkey=https://dl-ssl.google.com/linux/linux_signing_key.pub

Podemos optar por montar uno sólo de los repositorios eligiendo el que corresponda a la arquitectura de nuestro procesador.

Después de esto sólo queda un paso para tener instalado Google Chrome:

#### Version Estable ###########
yum install google-chrome-stable
#### Version Beta ###########
yum install google-chrome-beta

Y … listo a disfrutar del navegador de Google en Linux.

Nota para desarrolladores web: Google Chrome tiene la misma base que Safari, por lo que si vuestra web está dando problemas en Mac y no tenéis uno a mano, podéis comprobar los errores con este navegador (muy útil con problemas en javascript)

Pasando de sysvinit a systemd en Fedora

En las Notas de lanzamiento de la documentación de Fedora 16 nos encontramos con lo siguiente:

3.2.4. Scripts de SysVinit portados a systemd

Fedora 15 vió la introducción de systemd, un administrador de sistema y de servicios nuevo para Linux. La integración de systemd continúa en Verne, con muchos más scripts de inicio de SysV convertidos a archivos de servicios nativo de systemd. El resultado es un proceso de arranque más rápido, eficiente y una administración de servicios más simple.

Ahora bien, si entrar a valorar si el cambio ofrece mejoras, que seguro que si y pronto lo veremos también en Red Hat Enterprise, CentOS y el resto de la familia, pero el abandono de sysvinit trae consigo la necesidad de adaptarse al nuevo sistema.

Por el momento se puede hacer uso de service y chkconfig, aunque creo que poco durarán en futuras versiones, así que toca ponerse al día para poder administrar los servicios con systemd, ahí van algunos comandos y sus correspondencias con sysvinit:

SYSVINIT SYSTEMD Función
service httpd start systemctl start httpd.service Utilizado para arrancar el servicio (no resiste reinicio)
service httpd stop systemctl stop httpd.service Utilizado para detener el servicio (no resiste a reinicio)
service httpd restart systemctl restart httpd.service Utilizado para detener y arrancar el servicio.
service httpd reload systemctl reload httpd.service Cuando se soporta, recarga el archivo de configuración sin interrumpir las operaciones pendientes.
service httpd condrestart systemctl condrestart httpd.service Rearranca el servicio sólo si ya está ejecutándose.
service httpd status systemctl status httpd.service Indica si el servicio está en ejecución o no.
ls /etc/rc.d/init.d/ ls /lib/systemd/system/*.service /etc/systemd/system/*.service Utilizado para listar los servicios que pueden ser iniciados o detenidos
ls /etc/rc.d/init.d/ systemctl list-units –all Utilizado para listar todos los servicios y otros units
chkconfig httpd on systemctl enable httpd.service Pone el servicio en “on”, para que se inicie cuando se inicie la máquina u otro disparador como cambio de nivel de ejecución.
chkconfig httpd off systemctl disable httpd.service Pone el servicio en “off” para que al iniciar el sistema, no se inicie el servicio o se detenga por ejemplo al momento de cambio de nivel de ejecución.
chkconfig httpd systemctl is-enabled httpd.service Utilizado para verificar si un servicio está configurado para ser iniciado en el entorno actual.
chkconfig httpd –list ls /etc/systemd/system/*.wants/httpd.service Utilizado para listar qué niveles de ejecución el servicio está en “on” o “off”.
chkconfig httpd –add systemctl daemon-reload Utilizado para cuando se desea crear un nuevo archivo de servicio o modificar su configuración.

Más info en: https://fedoraproject.org/wiki/SysVinit_to_Systemd_Cheatsheet/es