Problemas con Crontab y el encoding

A veces me ha sucedido que el mismo comando que desde la consola funciona correctamente cuando se ejecuta mediante cron tiene problemas con el encoding en los ficheros que genera o envíos de email.

Esto es debido normalmente a que los atributos locales del usuario que ejecuta desde consola no son los mismos que toma crond.

Para solucionar esto puedes colocar delante de los comandos del crontab una línea como esta:


LANG=en_US.UTF-8

O bien, si los comandos que ejecutas con cron son shell scripts puedes hacerlo en cada uno de ellos. Recuerda que si esos scripts llaman a otros quizás te convenga utilizar export:


export LANG=en_US.UTF-8

“date: cannot set date: Operation not permitted” en entornos Xen como root

Cuando uno está como root no está acostumbrado a que le digan “operation not permitted” y menos en un comando tan simple como date.

El caso es que en entornos Xen puede no estar permitido establecer la hora del sistema porque se asume que se comparte la hora de la máquina física que contiene la instancia virtual Xen.

Si queremos tener una hora independiente de la máquina física podemos hacer lo siguiente:

echo 1 > /proc/sys/xen/independent_wallclock

Y si queremos que el cambio sea permanente editamos el fichero /etc/sysctl.conf y añadimos la siguiente línea:

xen.independent_wallclock = 1

Recordamos que la mejor alternativa al comando date es establecer la fecha, hora y zona horaria del sistema sincronizando con un servidor NTP.

Efecto 2010 en el SpamAssassin

Me resultó sospechoso que varios correos “no-spam” habían sido marcados esta mañana como spam. Indagué en las cabeceras y vi una regla que puntuaba un 3,2 y que no la había visto nunca aparecer: FH_DATE_PAST_20XX – The date is grossly in the future.

Por el nombrecito de la regla enseguida pensé en un “efecto 2010″ y miré el resto de emails de hoy no marcados como spam y efectivamente aparecían puntuados con esta regla. También los de ayer y hasta el día 1. Los del día 31 no.

La solución es darle un cero a esta regla en el fichero de definición de reglas: /etc/mail/spamassassin/local.cf de esta forma:

score FH_DATE_PAST_20XX 0

y luego reiniciar el spamassassin:

service spamassassin stop
service spamassassin start

Luego buscando información en Google he visto otras formas de solucionarlo.

Ajustar fecha y hora en CentOS

El comando date nos permite saber la fecha y hora del sistema así como la zona horaria. Mediante date también podemos ajusta la fecha y hora de forma manual pero, siempre que tu máquina esté conectada a Internet, la mejor forma es sincronizar con un servidor NTP (Network Time Protocol). Vamos allá:

Comenzamos haciendo backup de la timezone actual:

mv /etc/localtime /etc/localtime-old

Cambiamos al timezone adecuado, en este caso el de España Penínsular (aka Madrid):

ln -sf /usr/share/zoneinfo/Europe/Madrid /etc/localtime

Sincronizamos la hora con nuestro servidor NTP preferido (en mi caso hora.rediris.es):

/usr/sbin/ntpdate -u hora.rediris.es

Si no disponéis del comando ntpdate:

yum install ntp

Editando el fichero /etc/sysconfig/clock nos aseguramos que la entrada ZONE tiene el valor correcto. En nuestro caso el contenido del fichero debería ser el siguiente:

ZONE="Europe/Madrid"
UTC=true
ARC=false

El sistema ya tiene la hora correcta… ahora se la pasamos al reloj hardware:

/sbin/hwclock --systohc

Consejo gratis: Estos relojes, aunque no son de cuerda, también se atrasan. Es muy recomendable realizar un cron que puede ser diario que tenga las dos líneas siguientes:

/usr/sbin/ntpdate -u hora.rediris.es
/sbin/hwclock --systohc

De esta manera diariamente sincronizaréis la hora del sistema y del reloj hardware con el servidor NTP que mantiene la hora oficial de España.

crontab: command not found

Si te has encontrado con este problema en un sistema CentOs/RedHat/Fedora y no sabes que paquete instalar:

yum install vixie-cron