Desarrollo Linux y software libre

Este monitorizador de tareas permite enviar alertas en función de eventos o condiciones. En la versión 4.10 no permite definir que el login de SMTP sea SSL (Como la mayoría de los actuales), y utilizar un localhost suele ser inútil al rechazar los relays de correo a servidores no autenticados como medida contra el spam.

Por tanto es necesario utilizar un smtp público, como Gmail, que no utilice SSL o, en el caso de que lo utilice, actualizar a la beta 5 de Monit que ya soporta autenticación en SMTP por SSL.

En este último caso, tras descargarla es necesario instalar bison. También es conveniente, aunque no necesario, hacer una copia del monitrc:
$sudo cp /etc/monit/monitrc /root
Pero en principio ni se modifica ni se incluye uno nuevo. La instalación se compone de:

(según la configuración del sistema es probable necesitar hacerlo con permisos de superusuario).

$ ./configure --without-ssl
(...)
monit has been configured with the following options:
Architecture: LINUX
SSL support: disabled
resource monitoring: enabled
resource code: sysdep_LINUX.c
large files support: enabled
Compiler flags: -g -O2 -Wall -D _REENTRANT
Linker flags: -lpthread -lcrypt -lresolv -lnsl
pid file location: /var/run
$ make
$ make install

Instalado, definir los datos del envío de correo (es probable que algunas variables no figuren en el fichero de ejemplo):

$ sudo nano /etc/monit/monitrc
(...)
set mailserver smtp.gmail.com PORT 587 # primary mailserver
USERNAME "micuenta@gmail.com" PASSWORD "micontraseña" using TLSV1
(...)

Reiniciar monit
$ sudo /etc/init.d/monit restart
y comprobar, provocando algún evento, que se reciben correos de alerta. Además se pueden ver configuraciones de ejemplo para definir alertas aquí.

Actualización (octubre de 2026): el script mostrado en 2008 es una referencia histórica, no una solución lista para usar en producción. Incluye borrados automáticos y rutas específicas de su entorno original.

Comprobaciones imprescindibles

Antes de utilizar un script de copias, pruébalo con datos no críticos: comprueba el resultado de cada transferencia antes de borrar los temporales, valida la integridad, protege el destino, define una política de retención y realiza periódicamente una prueba real de restauración. Considera set -euo pipefail en scripts Bash nuevos, gestionando expresamente los comandos cuyo error es esperado. No bases la recuperación en una única copia.

Relacionado: acceso SSH con claves públicas y dividir ficheros grandes en Linux.

Generalmente en entornos de producción es necesario hacer copias de seguridad. Para ello se puede utilizar software como Bacula o hacernos nuestro pequeño script si las necesidades no son muchas.

En este caso muestro un ejemplo de script que corre en el cron de un servidor, el cual se conecta a dos máquinas por SSH, comprime ciertos directorios de algunas máquinas y los envía por scp al servidor. Posteriormente borra las copias con 2 días de antigüedad.

Para que las copias de seguridad sean automáticas, sin intervención del usuario, es necesario configurar el acceso SSH sin password.

El script de ejemplo es el siguiente:

#!/bin/bash
#Definir el servidor donde se almacenan las backups.
LOCALHOST="172.26.0.5"
DEST="/home/carlos/disco.sda1/backups"

#Equipo #1 del que hacer copias.
ORIG1="/home/prod/software"
FICH1=prod-$(date +%Y%m%d).tgz
HOST1=172.26.0.4

ORIG2="/home/tibco"
FICH2=tibco-$(date +%Y%m%d).tgz
HOST2=172.26.0.9

#ATENCIÓN: Añadir la clave pública de ssh para que no se pida clave durante el proceso.

#Backup1
#Crear el fichero, enviarlo y borrarlo del host remoto
ssh $HOST1 "tar cvfz /tmp/$FICH1 --exclude="/home/prod/soft/temp" --exclude="/home/prod/soft/logs" /home/prod/soft/"
ssh $HOST1 "scp /tmp/$FICH1 carlos@$LOCALHOST:$DEST"
ssh $HOST1 "rm /tmp/$FICH1"
FICH_ANTERIOR=prod-$(date +%Y%m%d --date '2 days ago').tgz
if [ -f /home/carlos/disco.sda1/backups/$FICH1 ]; then
rm /home/carlos/disco.sda1/backups/$FICH_ANTERIOR
fi

#Backup2
ssh tibco@$HOST2 "tar cvfz /tmp/$FICH2 /home/tibco/"
ssh tibco@$HOST2 "scp /tmp/$FICH2 carlos@$LOCALHOST:$DEST"
ssh tibco@$HOST2 "rm /tmp/$FICH2"
FICH_ANTERIOR=tibco-$(date +%Y%m%d --date '2 days ago').tgz
if [ -f /home/carlos/disco.sda1/backups/$FICH2 ]; then
rm /home/carlos/disco.sda1/backups/$FICH_ANTERIOR
fi

Y es necesario programar en el cron la ejecución de este script:
carlos@shirley:~$ crontab -e
# m h dom mon dow command
00 21 * * * /home/carlos/backups/misBackups.sh

así como darle permiso de ejecución al script:
carlos@shirley:~$ chmod 700 backups/misBackups.sh

Otros artículos relacionados: Configurar claves SSH · Dividir archivos grandes

Actualización (octubre de 2026): el ejemplo de Monit de 2008 es histórico: las rutas de configuración, los comandos de arranque y los nombres de servicios pueden haber cambiado. Comprueba tu versión instalada y valida la configuración antes de reiniciar servicios.

Seguridad: el ejemplo original incluye una credencial demostrativa admin:monit. No la utilices en un equipo real. Si habilitas la interfaz web de Monit, restringe su acceso y usa una contraseña robusta y exclusiva. No expongas el puerto de administración sin controles adecuados.

Relacionado: monitorización de máquinas VirtualBox con Monit.

Frecuentemente es necesario tener servicios y procesos monitorizados y levantados las 24h. Para ello existen utilidades que monitorizan y rearracan en caso de caída o condiciones críticas del sistema, a la vez que envían alertas al administrador. Y lo hacen no sólo en base al estado del proceso si no también, si se desea, en función del entorno (RAM en uso, espacio libre en disco, etc), así como permite crear tareas de mantenimiento para evitar entrar en situaciones críticas.

En GNU/Linux uno de los más utilizados es Monit. De una manera sencilla permite controlar procesos, servicios, ficheros, memoria, CPU, puertos ó comunicaciones. En Debian ó Ubuntu se instala de manera sencilla:

$sudo apt-get install monit

Y crea el servicio que se arrancará en todos los reinicios. A contiinuación, es necesario activarlo configurando los parámetros generales de la aplicación:

$sudo nano /etc/default/monit
# You must set this variable to for monit to start
startup=1
# To change the intervals which monit should run uncomment
# and change this variable.
CHECK_INTERVALS=180

y posteriormente indicar los parámetros personalizados (condiciones a monitorizar). El fichero viene totalmente comentado por un ejemplo de cada tipología de evento monitorizable (fichero que cambia, procesos que mueren, consumo de memoria o de CPU, puerto inalcanzable…), de modo que es bastante fácil de configurar y de adaptar a situaciones persanlizadas. En mi caso pongo de ejemplo una condición para mantener demonio de aMule (amuled) arrancado si cae:

# sudo nano /etc/monit/monitrc
set daemon  60
set logfile syslog facility log_daemon
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'
(...)
#--------------- AMULE DAEMON
check process aMule with pidfile /home/carlos/.aMule/muleLock
start program = "/etc/init.d/amule-daemon start"
stop program  = "/etc/init.d/amule-daemon stop"
if failed host localhost port 4712 then restart
(...)

Comentar que el  «set httpd port 2812» configura un interfaz web cómodo para acceder a las estadísticas de Monit vía web. A parte, las estadísticas se pueden ver en el syslog o en el fichero que se especifique en la configuración.

Otros artículos relacionados: Automatizar copias de seguridad con Bash y SSH

Advertencia (octubre de 2026): el comando original usa kill -9 sobre un conjunto de PID obtenido mediante filtros de texto. No lo ejecutes a ciegas: puede terminar procesos no deseados y causar pérdida de datos.

Para localizar procesos de un usuario, comienza por ps -u usuario -o pid,comm,args; para buscar una aplicación propia, utiliza pgrep -a -u usuario nombre. Comprueba los PID antes de enviar señales y, si es posible, intenta una finalización normal (SIGTERM) antes de recurrir a SIGKILL.

Relacionado: diagnóstico de procesos y archivos abiertos.

Como matar todos los procesos de un usuario o que cumplan una condición:

kill -9 `ps auxww | grep [nombre] | egrep -v grep | awk ‘{print $2}’`

Revisión técnica (octubre de 2026): un sistema de archivos que requiere intervención manual puede tener errores graves. No fuerces reparaciones automáticas ni ejecutes fsck sobre un sistema de archivos montado en modo escritura. Identifica primero el dispositivo, el tipo de sistema de archivos y el mensaje exacto. Si los datos son importantes, conserva una imagen o copia recuperable antes de reparar.

Los parámetros y rutas del ejemplo de 2007 son históricos. En sistemas modernos, comprueba las opciones de recuperación de tu distribución y el estado del almacenamiento: un fallo recurrente también puede indicar problemas físicos.

Relacionado: errores de fstab que impiden arrancar.

En muchos sistemas administrados remotamente es frecuente que al reiniciarlos presenten alguna inconsistencia en el sistema de archivos. Esto hace que se ejecute una recuperación con fsck pero generalmente, ante una duda, suele pedir la intervención del usuario:


/dev/hdc1 contains a file system with errors, check forced.
/dev/hdc1:
Inode 4642102 has illegal block(s).

/dev/hdc1: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
(i.e., without -a or -p options)
fsck died with exit status 4

give root pasword for maintenance.
(or type control-D for normal startup)

Al no tener acceso via ssh (el demonio no se ha cargado aun), la solución para este problema de fsck es:

1º) Editar el fichero de configuración:
sudo nano /etc/default/rcS

2º) Cambiar la variable FSCKFIX a «yes»
FSCKFIX=yes

Teniendo esta inconveniencia salvada.

La versión 6.10 de Kubuntu (Edgy), muestra una pantalla en negro en diversos ordenadores (mayoritariamente los más nuevos) al pasar al modo gráfico después del arranque liveCD. Según he investigado en foros, parece deberse a algún error de drivers de nvidia, aunque también ocurre en ATI.

Solución: instalar en modo texto la versión «alternate» AMD64 de Kubuntu. Después de instalarla, se accede a la consola (CTRL+ALT+F1), se hace login (si hiciste una instalación OEM, el usuario es «oem») y toca:

#sudo nano /etc/apt/sources.list

modificándolo para que quede de la siguiente manera:
deb http://archive.ubuntu.com/ubuntu/ edgy main restricted universe multiverse
deb http://archive.ubuntu.com/ubuntu/ edgy-updates main restricted universe multiverse
deb http://archive.ubuntu.com/ubuntu/ edgy-backports main restricted universe multiverse
deb http://security.ubuntu.com/ubuntu edgy-security main restricted universe multiverse
#sudo apt-get update

#sudo apt-get upgrade

#shutdown -h now

que actualiza xserver-xorg. Después se edita el fichero de configuración gráfica:

#nano /etc/X11/xorg.conf

y se eliminan de todas las entradas las resoluciones altas (tipo 1280×1000).

Se reinicia y el problema estará solucionado. En ordenadores con placa base nvidia con tarjeta de video y sonido integradas es básico utilizar la versión de K/Ubuntu de 64 bits para que funcione todo.

En algunas distribuciones (como Ubuntu) el fichero lts.conf no vienne por defecto, simplemente porque se presupone que se va a utilizar una configuración por defecto. Por tanto, si se desea modificar la configuración por defecto, es necesario copiar el fichero de ejemplo a la localización indicada y editarlo.

cp /opt/ltsp/i386/usr/share/doc/ltsp-client/examples/lts.conf /opt/ltsp/i386/etc/lts.conf

(nótese que el fichero de configuración es lts.conf, y no ltsp.conf)
En mi caso fué necesario además incluir unas líneas más de las que venían en este ejemplo de Novell para poder cambiar la frecuencia del monitor, de modo que se viese correctamente en una televisión.

Probando a instalar LTSP en Ubuntu Edgy me he atrevido a hacer un apt-get de los paquetesque, a partir de esta versión de Ubuntu, se incorporan al repositorio para facilitar la vida en este tipo de instalaciones.

En principio parece que es una pre-release, que aun queda por desarrollar, pero hay capturas muy interesantes de herramientas gráficas para gestionar estos entornos.

Una de ellas es ltsp-manager:

ltsp-manager - Ubuntu LTSP server management GUI

que se instala bien, cumpliendo sus dependencias, pero que a la hora de ejecutarlo (ya sea como usuario, sudo o root directamente) produce este bonito error:

carlos@aldi:~$ sudo ltsp-manager
Password:
(ltsp-manager:5230): libglade-WARNING **: could not find glade file './ltsp-manager.glade'
Traceback (most recent call last):
File "/usr/bin/ltsp-manager", line 409, in ?
base = LTSPManager()
File "/usr/bin/ltsp-manager", line 18, in __init__
self.wTree=gtk.glade.XML ("./ltsp-manager.glade")
RuntimeError: could not create GladeXML object

Uno empieza a hacer apt-get’s de diversos paquetes que sospecha puedan faltar, relacionados la mayoría con GTK, Pyhon o Glade. Incluso, al estarse realizando las pruebas sobre una Ubuntu Edgy Server (que viene por tanto sin escritorio pero a la que le he instalé KDE), piensa en instalar Gnome (más dependencias y librerías no podrá instalarte nadie 😉 ). Y bueno, estamos de pruebas, así que podemos permitírnoslo. Total, que 500 megas descargados después, reinicio y entrada en Gnome (argh), sigue dándose el mismo error. Tiene pinta de que símplemente parece que se han olvidado del fichero «./ltsp-manager.glade» al empaquetar, pero me niego a asumirlo…

Total, que investigando un poco más sobre ese fichero, lo localizo en:

/usr/share/ltsp-manager

observo sus permisos y símplemente con un bruto:
chmod -R 777 /usr/share/ltsp-manager/

se arregla la historia.

Actualización: el problema no son los permisos. Símplemente para ejecutarlo se debe hacer desde /usr/share/ltsp-manager/