Desarrollo Linux y software libre

Si tras instalar Eventum no se tiene acceso con el login por defecto (admin@example.com / admin), lo más probable es que el usuario de acceso a la base de datos de Eventum no tenga acceso a la misma, y por tanto no pueda constantar si el usuario introducido existe en la BD.

Para ello es preciso darle permisos:

pilar002:/var/www/eventum/config# mysql -u root -h localhost -p
Enter password:

mysql> GRANT ALL on eventumDB.* TO usuarioEventum@locahost;

una solución más directa es dar permisos a todas las bases de datos, sabiendo lo que se hace en cuestiones de seguridad:
mysql> GRANT SELECT ON *.* TO usuarioEventum

Esta herramienta para manejar y hacer seguimiento de incidencias en cualquier tipo de proyecto de ingeniería actualmente viene en Inglés. En la versión actual (2.1.1) no incorpora el Español, por lo cual si se desea traducir es necesario incorporar los diccionarios españoles.

Para ello se consultará el SVN del proyecto, se copiarán de él las traducciones y se le especificará a Eventum que utilice por defecto este idioma. Para ello:

1º) Bajarse del SVN todo el proyecto:
mkdir svn.eventum
cd svn.eventum
svn checkout svn://eventum.mysql.org/eventum-gpl/

2º) Localizamos los diccionarios
cd /home/carlos/temp/svn.eventum/eventum-gpl/trunk/eventum/misc/localization

y los copiamos en el directorio de Eventum:
cp -R es /var/www/eventum/misc/localization
cp es.po /var/www/eventum/misc/localization

3º) Activar el idioma Español en Eventum: hay dos formas
a) Copiando el class.language.php del SVN a nuestro Eventum:
cp /home/carlos/temp/eventumSVN/eventum-gpl/trunk/eventum/include/class.language.php /var/www/eventum/includes/class.language.php

b) Descomentando en /var/www/eventum/includes/class.language.php el idioma Español.
No obstante es más fiable el primer método.

4º) Indicar a Eventum el idioma predeterminado: viene en Inglés norteamericano, cambiarlo por es_ES.

nano /var/www/eventum/config/config.php
(...)
//define('APP_DEFAULT_LOCALE', 'en_US');
define('APP_DEFAULT_LOCALE', 'es_ES');
(...)

Y probar a conectarse, ya está traducido. En algún caso se puede necesitar reiniciar Apache:
sudo /etc/init.d/apache2 restart

Además, en el caso de que el hosting sea GNU/Linux, las locales deben estar configuradas en el mismo idioma en el que se desee Eventum:

# dpkg-reconfigure locales

aunque también se puede optar por una solución rápida: reemplazar el valor «en_US» de los siguientes ficheros por «es_ES«:

# nano eventum-2.2\config\config.php
# nano eventum-2.2\init.php

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

Hay veces que tenemos que entrar sucesivamente a una máquina por ssh, y se pierde mucho tiempo en el login. Para ello hay una utilidad de SSH que permite el logueo automático sin que ello signifique decremento de seguridad. Para ello se genera una clave pública y se exporta a la otra máquina, asumiendo el demonio de ssh a partir de entonces el acceso desde esa máquina, con ese usuario y con esa clave, como permitido:

carlos@host1:~$ ssh-keygen -t dsa
carlos@host1:~$ ssh-copy-id -i .ssh/id_dsa.pub pepito@host2

De esta manera el usuario carlos puede entrar en host2 como usuario «pepito» sin tener que teclear siempre la contraseña. Es una solución util para interacciones automática entre sistemas sin tener que almacenar la contraseña del usuario en texto plano, cron o demás.

A parte, es conveniente en sistemas compartidos modificar los permisos de acceso a los ficheros de claves generados para evitar malos usos:
carlos@WhenIGrewUp:~$ chmod 700 .ssh
carlos@WhenIGrewUp:~$ chmod 600 .ssh/authorized_keys
carlos@WhenIGrewUp:~$ chmod 600 .ssh/id_dsa
carlos@WhenIGrewUp:~$ chmod 744 .ssh/id_dsa.pub

En determinadas ocasiones no funciona esta solución. Para ello es conveniente unificar la versión de servidor ssh existente en los nodos. Se puede averiguar facilmente con la utilidad scanssh:

carlos@WhenIGrewUp:~$ sudo scanssh 172.26.9
172.26.0.9:22 SSH-2.0-OpenSSH_4.6p1 Debian-5ubuntu0.6
Effective host scan rate: 3.91 hosts/s

carlos@WhenIGrewUp:~$ sudo scanssh 172.26.5
172.26.0.5:22 SSH-2.0-OpenSSH_5.1p1 Debian-3ubuntu1
Effective host scan rate: 1.52 hosts/s

carlos@shirley:~$ sudo scanssh 172.26.0.4
172.26.0.4:22 SSH-2.0-OpenSSH_4.7p1 Debian-8ubuntu1.2
Effective host scan rate: 3.33 hosts/s

Para facilitar al Gran Hermano su labor podemos importar en nuestras cuentas de Gmail ese fichero de correo de cientos, a veces gigas, de correo que ya es inamovible de nuestro ordenador (y por tanto inaccesible desde otras localizaciones).

Para ello existe GML (GoogleMail Loader), un script en Python para procesar ficheros de correo en formato Mbox (Netscape, Mozilla Thunderbird), MailDIR (Qmail), MMDF (Mutt), NH (NHM) o Babyl (Emacs Rmail). El formato PST de Outlook se puede transformar facilmente con la herramienta «readPST» a formato Mbox.

GML se puede descargar desde aquí, donde también hay versión para Windows. Tras descomprimirlo, se ejecuta mediante el intérprete de Phyton:

carlos@WhenIGrewUp:~/gmlw$ python gmlw.py

La ejecución es muy sencilla, se muestra un GUI en el que hay que elegir la dirección de correo, el fichero almacén y el login en el SMTP correspondiente. Posteriormente el proceso comenzará incorporándose los correos en Gmail con la fecha y destinatarios originales. Lo único que cambiará será el remitente si utilizas el smtp de Gmail, que incluirá tu dirección de Gmail pero mantendrá el nombre del remitente verdadero para facilitar el seguimiento (límites de la seguridad frente al spam en los SMTP’s habituales). Es un proceso automático y lento.

En esta portabilidad de correos siempre es recomendable que antes de empezar que cambies tu contraseña de Gmail. Ésta ya es visible en la GUI y en la consola. Si utilizas como SMTP el de Gmail, viajará encriptada. Posteriormente puedes volver a establecer tu contraseña anterior.

Posibles problemas:

a) Al iniciar una importación, se produce el siguiente problema:
mBox (Netscape, Mozilla, Thunderbird) at location /home/carlos/tmp/Inbox Opened Successfully.
Done. Stats: 0 success 0 error 0 skipped.

El fichero no es un Mbox, pese a que el aviso indique que si.

b) El fichero está corrupto o no lo reconoce.
Se puede aplicar un programa de limpieza del fichero descargable aquí.

carlos@WhenIGrewUp:~/tmp$ python cleanmbox.py varios
Reading messages from 'varios'
Processing 55 messages... done.
Wrote to 'varios.cleaned'
Cleaned 1 mailbox(es).

c) Al ejecutarlo se produce el siguiente error:
carlos@WhenIGrewUp:~/gmlw$ python gmlw.py
Traceback (most recent call last):
File "gmlw.py", line 42, in
import os, sys, mailbox, smtplib, time, Pmw, webbrowser, tkFileDialog, re
ImportError: No module named Pmw

en caso de obtener ese error, se necesitará instalar la librería correspondiente:
carlos@WhenIGrewUp:~/gmlw$ apt-cache search pmw
python-pmw - Pmw -- Python MegaWidgets
python-pmw-doc - Pmw -- Python MegaWidgets
carlos@WhenIGrewUp:~/gmlw$ sudo apt-get install python-pmw

Al estar descontinuado GML, han surgido forks o modificaciones de este programa. A parte, hay otra opción como Gexodus.

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.