Rotar archivos de log con Logrotate

Logrotate es el proceso encargado de rotar, comprimir y enviar por mail los logs de sistema en Linux.

Cuando un paquete individual (como httpd, bacula, vsftpd, yum, etc.) se instala, éste añade en el directorio /etc/logrotate.d/ su fichero de configuración logrotate encargado de la gestión de los logs. Así por ejemplo, Apache añade un fichero similar al siguiente:

[root@server logrotate.d]# cat /etc/logrotate.d/httpd
/var/log/httpd/*log {
missingok
notifempty
sharedscripts
postrotate
/sbin/service httpd reload > /dev/null 2>/dev/null || true
endscript
}

Si se quieren añadir políticas de rotación de logs para logs que no estén definidos o que no estén en las rutas por defecto, se podrá tocar el fichero de configuración /etc/logrotate.conf

En este fichero (/etc/logrotate.conf), además, se configuran las políticas de rotación de logs comunes a todos los logs. En cada fichero de configuración dentro de /etc/logrotate.d, se pueden sobreescribir las políticas comunes, de forma local, redefiniendo el valor para la variable de configuración deseada. Así por ejemplo, se podría crear un fichero para rotar los logs del tipo /var/log/miapp.log que deja una aplicación concreta, tal y como sigue:

[root@server logrotate.d]# cat /etc/logrotate.d/miapp
/var/log/miapp.log {
weekly
copytruncate
rotate 4
compress
missingok
}

Con la definición anterior, estaríamos inficando:

  • weekly: los logs se rotarán semanalmente.
  • copytruncate: crea una copia del fichero de logs original y después trunca el fichero original a cero bytes, de esta manera “miapp” siempre apuntará al mismo fichero y evitaremos problemas.
  • rotate 4: mantendrá los últimos 5 ficheros (rotará 4 veces).
  • compress: comprime el fichero de log, una vez rotado.
  • missingok: si el fichero de log no existe, no devuelve error.

Logrotate no es un demonio que corre en la máquina. Así pues, tras realizar cualquier cambio en el fichero de configuración, no será necesario realizar ningún restart de ningún servicio. Símplemente, Logrotate usará la nueva configuración en la siguiente ejecución. Si se desea testear Logrotate tras algún cambio en su configuración, se puede ejecutar el comando siguiente:

logrotate -vf /etc/logrotate.conf

PD: Es posible que tras la ejecución del comando anterior, tarde unos segundos en empezar a escribir en el nuevo fichero de logs.

Útil y muy necesario para mantener controlado el espacio usado por los logs.

Fuentes:
http://www.thegeekstuff.com/2010/07/logrotate-examples/
http://www.linuxcommand.org/man_pages/logrotate8.html
http://www.linuxquestions.org/questions/linux-newbie-8/

Copias de seguridad con Bacula

BaculaBacula es probablemente, la solución OpenSource más conocida para la realización de copias de seguridad a nivel empresarial. Bacula se compone de varios elementos:

  • Director: dice cuando hacer backups/restores a los clientes de bacula (FD). Los backups que realizan los clientes de bacula se envían directamente al storage, sin pasar por el director.
  • Storage: recibe los datos de los clientes de bacula y los envía al lugar donde se almacenarán (disco, cinta, etc.). El demonio bacula-sd se configurará en un servidor que tenga montados los recursos de almacenamiento (se suele usar el propio servidor de bácula).
  • Catalog: base de datos (MySQL, PostgreSQL o SQLlite) con la información de los jobs. Además, guarda los nombres de todos los archivos de los backups realizados, lo cual servirá para hacer restores selectivos.
  • Cliente bácula (FD): agente que corre en las máquinas clientes que se quieren backupear.
  • Bconsole: programa que interactua con el director, por línea de comandos y permite administrar bacula. Por ejemplo, permite lanzar backups a mano, ver el estado de los jobs o listar los dispositivos de almacenamiento configurados.

Continuar leyendo “Copias de seguridad con Bacula”

Añadir disco extra en Red Hat

Red HatEn entornos tanto físicos como virtuales, es común encontrarse con la necesidad de añadir un disco duro extra a un servidor tipo Red Hat. Éste proceso se puede hacer de diversas maneras, pero con cualquiera de ellas, se convierte en una tarea crítica, puesto que cualquier fallo nos puede provocar muchos problemas.

A continuación describo el proceso que a mi me funciona:

Identificar los discos, con

fdisk -l

Crear una partición primaria para el nuevo disco, en el ejemplo /dev/sda:

[root@USAFront2 dev]# fdisk /dev/sda
Orden (m para obtener ayuda): n
Acción de la orden
e Partición extendida
p Partición primaria (1-4)
p
Número de partición (1-4): 1
Primer cilindro (1-4865, valor predeterminado 1):
Se está utilizando el valor predeterminado 1
Last cilindro, +cilindros or +size{K,M,G} (1-4865, valor predeterminado 4865):
Se está utilizando el valor predeterminado 4865

Orden (m para obtener ayuda): w
¡Se ha modificado la tabla de particiones!

NOTA:
n Añade una nueva partición
w Escribe la tabla en el disco y sale

Continuar leyendo “Añadir disco extra en Red Hat”

Modificar .profile en Linux

En las distribuciones tipo Red Hat, cada usuario de sistema puede modificar su fichero $HOME/.bash_profile, para por ejemplo, definir nuevos comandos, programas a ejecutar en el momento de acceder al sistema, o cambiar los valores de las variables de entorno como $PATH.

Cuando un usuario (excepto “root”) se loguea, primero se ejecuta el fichero /etc/profile, que contiene las definiciones comunes para todos los usuarios, y posterioremente, se ejecutará el fichero .bash_profile correspondiente al usuario.

“When bash is invoked as an interactive login shell, or as a non-interactive shell with the –login option, it first reads and executes commands from the file /etc/profile, if that file exists. After reading that file, it looks for ~/.bash_profile, ~/.bash_login, and ~/.profile, in that order, and reads and executes commands from the first one that exists and is readable.”

Fuente: “man bash”

Si se quisiera realizar un cambio en una variable de entorno para todos los usuarios, se recomienda crear un fichero .sh en /etc/profile.d/ con el código correspondiente, en lugar de modificar directamente el fichero /etc/profile.

“It’s NOT a good idea to change this file unless you know what you are doing. It’s much better to create a custom.sh shell script in /etc/profile.d/ to make custom changes to your environment, as this will prevent the need for merging in future updates.”

Fuente: “head /etc/profile”

Fuente: http://www.troubleshooters.com/linux/prepostpath.htm