Chuletillas (y XXXXVIII) – Cambiar el formato de tablas de MySQL o MariaDB de Antelope a Barracuda (para instalar o actualizar Moodle)

chuletaLas últimas versiones de moodle exigen que las tablas usen InnoDB con formato Barracuda en lugar de Antelope. De hecho, en algunos casos puede que la actualización falle sólo por el hecho de no cumplir este requisito y sin que medie ningún comentario informativo acerca de cual es el origen del problema.

Para evitar este problema tenemos que añadir las siguientes líneas en el archivo my.cnf de configuración de mysql o mariadb:

innodb_large_prefix=ON
innodb_file_format=Barracuda
innodb_file_per_table=ON
innodb_file_format_check=ON
innodb_file_format_max=Barracuda

No soy un gran experto en bases de datos, mi lector habitual ya lo sabe, pero tengo entendido que la principal ventaja que aporta Barracuda es la compresión de datos. Quién quiera hablar sobre ello con propiedad puede echarle un vistazo a este texto. En cualquier caso, si quieres seguir usando moodle no tienes mas remedio que pasar por el aro. Son lentejas, ya sabes 😉

Script desatendido para eliminar ficheros antiguos de un servidor ftp

Hace ya un tiempo que dejamos por aquí el “esqueleto” de un script para realizar una conexión y transferencia desatendida a un servidor ftp. La finalidad del mismo era automatizar los backups en nuestro hosting cuando lo que nos proporcionan para ello es este medio. Auxiliar a este tenía uno que eliminaba los backups antiguos, pero nunca llegué a estar demasiado satisfecho de él. Hace poco buscando mejorarlo vi una solución maravillosamente elegante en stackoverflow. El script original es este:

#!/bin/bash
# get a list of files and dates from ftp and remove files older than ndays
ftpsite="ftp.yourserver.com"
ftpuser="loginusername"
ftppass="password"
putdir="/public_ftp/admin/logs"

ndays=7

# work out our cutoff date
MM=`date --date="$ndays days ago" +%b`
DD=`date --date="$ndays days ago" +%d`

echo removing files older than $MM $DD

# get directory listing from remote source
listing=`ftp -i -n $ftpsite <<EOMYF 
user $ftpuser $ftppass
binary
cd $putdir
ls
quit
EOMYF
`
lista=( $listing )

# loop over our files
for ((FNO=0; FNO<${#lista[@]}; FNO+=9));do
  # month (element 5), day (element 6) and filename (element 8)
  #echo Date ${lista[`expr $FNO+5`]} ${lista[`expr $FNO+6`]}          File: ${lista[`expr $FNO+8`]}

  # check the date stamp
  if [ ${lista[`expr $FNO+5`]}=$MM ];
  then
    if [[ ${lista[`expr $FNO+6`]} -lt $DD ]];
    then
      # Remove this file
      echo "Removing ${lista[`expr $FNO+8`]}"
      ftp -i -n $ftpsite <<EOMYF2 
      user $ftpuser $ftppass
      binary
      cd $putdir
      delete ${lista[`expr $FNO+8`]}
      quit
EOMYF2

    fi
  fi
done

Por comentarlo un poco y “ganarnos el pan”, el script tiene tres bloques: el primero de definición de variables que tendrás que personalizar con tus datos (hasta la línea 8 incluida), el segundo en el que se realiza una conexión con el servidor y se obtiene un listado de todos los ficheros que están en el directorio que indicamos (hasta la línea 25) y por último un tercer bloque en el que se realiza el borrado propiamente dicho.

En el primer bloque la variable ndays en la línea 8 define la máxima antigüedad de los ficheros que no se eliminaran (7 días en este caso) y la variable putdir en la 6 el directorio del servidor ftp donde dejamos los archivos. Si, como yo, dejas los backups directamente en el raiz del servidor ftp puedes eliminar (o comentar) las líneas 6, 20 y 42

En el segundo bloque, la línea 14 indica la fecha límite de los ficheros que se conservaran. Todos los anteriores a esta se eliminarán. Si no quieres que aparezca en la salida puedes eliminarla o comentarla.

En el tercer bloque, si quieres hacer pruebas de que el script funciona antes de lanzarlo en modo real, puedes comentar la línea 43. Esto te mostrará en la consola los ficheros que se eliminarían pero no te los borrará realmente con lo cual podrás comprobar que el script hace lo que realmente necesitas. La línea 38 es la que te muestra el fichero que va a borrarse. Puedes eliminarla o comentarla también cuando ya no te interese. Por último, la línea 30 que aparece comentada muestra un listado de todos los ficheros del servidor ftp antes de realizar el borrado. Puedes descomentarla también para evaluar si está trabajando de forma correcta.

Problemas de postgrey y las listas grises con los servidores de correo de outlook y hotmail de Microsoft

correo Hace ya años que contamos por aquí en que consisten las listas grises a la hora de validar como bueno un correo y combatir contra el spam y enseñamos a configurarlas en un servidor con Debian y postfix. Recientemente he tenido muchos problemas con los correos que vienen de servidores de Microsoft (¡como no!) que provocaban retrasos de hasta algunos días o pérdida de correos en algunas ocasiones. Vamos a contar que es lo que ocurre y como solucionarlo.

El problema que tenemos con los servidores de correo de Microsoft es que el reintento de envío del correo que exige el sistema de listas grises no se realiza desde el mismo servidor que realiza el envío original con lo que nuestro sevidor toma el reintento como un correo diferente al original y no lo valida como correcto. La solución es fácil y seguramente estará “parcheada” en un futuro en nuestras Debian, pero por el momento tienes que solucionarla por ti mismo. Vamos a verlo.

En el directorio /etc/postgrey tenemos dos ficheros: whitelist_clients y whitelist_recipients. En ellos podemos incluir manualmente los servidores y direcciones de correo (respectivamente) que queremos validar automáticamente sin pasar por el sistema de listas grises. No obstante, hacerlo es una mala idea: en estos ficheros (sobre todo en el primero) es donde los mantenedores de Debian incluyen los servidores de correo que ya saben que dan problemas con el sistema de listas grises pero son servidores válidos. Posiblemente nuestro problema se resolverá en un futuro próximo cuando la gente de Debian incluya los servidores de Microsoft en este fichero pero mientras tanto tenemos que buscarnos una solución. Postgrey admite incluir en este mismo directorio dos nuevos ficheros con la misma funcionalidad pero donde podamos incluir nuestros propios servidores y direcciones de correo sin miedo a perder actualizaciones: whitelist_clients.local y whitelist_recipients.local.

Ahora ya sólo nos hace falta saber cuales son las direcciones de los servidores de correo de Microsoft. Afortunadamente están casi todas publicadas aquí. En algún foro he leído que es interesante añadir un par de líneas adicionales para validar los servidores de los servidores de Office 365. Al final, mi fichero whitelist_clients.local ha quedado así:

23.103.132.0/22
23.103.136.0/21
23.103.144.0/20
23.103.156.0/22
23.103.191.0/24
23.103.198.0/23
23.103.198.0/24
23.103.199.0/24
23.103.200.0/22
23.103.212.0/22
40.92.0.0/14
40.107.0.0/17
40.107.128.0/18
52.100.0.0/14
65.55.88.0/24
65.55.169.0/24
94.245.120.64/26
104.47.0.0/17
104.212.58.0/23
134.170.132.0/24
134.170.140.0/24
157.55.234.0/24
157.56.110.0/23
157.56.112.0/24
207.46.51.64/26
207.46.100.0/24
207.46.163.0/24
213.199.154.0/24
213.199.180.128/26
216.32.180.0/23
2a01:111:f400:7c00::/54
2a01:111:f403::/48
104.47.0.0/17
40.107.0.0/16
/.*outbound.protection.outlook.com$/
/outlook/

Ahora sólo queda reiniciar los daemons de postgrey y postfix para que los cambios tomen efecto y listo

Chuletillas (y XXXXVII) – Instalar un programa de debian Stretch mientras que usas debian stable (Jessie)

chuletaSi quieres instalar un determinado programa (y sus dependencias obligatorias) incluido en la próxima versión de Debian (Stretch) mientras continuas usando la versión stable (Jessie) puedes hacerlo de la siguiente forma:

En primer lugar edita tu fichero sources.list (en el directorio /etc/apt) e incluye al final las direcciones de los repositorios de Stretch pero sin eliminar ni modificar los que ya usas de Jessie. Por ejemplo así:

# Repositorios de Jessie
deb http://http.debian.net/debian/ jessie main contrib non-free
deb-src http://http.debian.net/debian/ jessie main contrib non-free
deb http://security.debian.org/ jessie/updates main contrib non-free
deb-src http://security.debian.org/ jessie/updates main contrib non-free

# Updates de Jessie, antes conocidos como 'volatile'
deb http://http.debian.net/debian/ jessie-updates main contrib non-free
deb-src http://http.debian.net/debian/ jessie-updates main contrib non-free

# Backports de Jessie
deb http://http.debian.net/debian jessie-backports main contrib non-free

#Repositorios de Stretch
deb http://http.debian.net/debian/ stretch main contrib non-free
deb-src http://http.debian.net/debian/ stretch main contrib non-free
deb http://security.debian.org/ stretch/updates main contrib non-free
deb-src http://security.debian.org/ stretch/updates main contrib non-free

# Updates de Stretch
deb http://http.debian.net/debian/ stretch-updates main contrib non-free
deb-src http://http.debian.net/debian/ stretch-updates main contrib non-free

A continuación creamos un fichero llamado stretch en el directorio /etc/apt/preferences.d y escribimos en el lo siguiente:

Package: *
Pin: release n=jessie
Pin-Priority: 900

Package: *
Pin: release n=stretch
Pin-Priority: 100

Con esto estamos modificando la prioridad con la que Debian actualizará nuestros paquetes. Por defecto instala siempre la versión más moderna de todas las que tenga disponibles en sus repositorios. Con este fichero le dará preferencia a cualquier paquete de jessie frente a uno de stretch aunque tenga una versión menor. Es decir, mantendremos nuestro sistema con las versiones de jessie salvo que un paquete no exista en esta y si en stretch… O se lo indiquemos manualmente durante la instalación que es lo que vamos a ver a continuación. Si quieres maś información sobre la forma de establecer preferencia para apt puedes echarle un vistazo a esta página.

Y ya lo tenemos todo listo. Ahora, tenemos que actualizar nuestros repositorios (apt update) y cuando queramos instalar un paquete directamente de stretch lo especificamos manualmente en el comando apt. Por ejemplo, si quisiéramos instalar la versión de apache de stretch lo haríamos así:

apt-get install -t stretch apache2

Nueva página: Herramientas web de testing y monitorización

herramientas En muchos de los articulos que publico por aquí referencio herramientas web encaminadas a ayudar con la configuración, pruebas o análisis de diversos elementos de nuestra infraestructura informática. Servidores Web, certificados SSL, Disponibilidad, Correo Electrónico, Seguridad, etc. El enlace a la página está en el índice lateral y aquí:

Herramientas web de Testing y Monitorización

El propósito de esta nueva página es recogerlas en un único lugar para mantener una referencia completa, cómoda y perfectamente autorizada. Todas las herramientas relacionadas en ella son gratuitas al menos en un modo básico aunque podrían tener un modo de pago más completo. Y si conoces alguna otra que no aparece y crees que puede ser útil no dejes de enviármela a través de un comentario por favor. Gracias.

Chuletillas (y XXXXVI) – Solventar el error de wordpress que lo deja bloqueado en modo de mantenimiento

chuleta Si trabajas habitualmente con wordpress te habrá pasado montones de veces. Tras actualizar un plugin, un tema o el propio wordpress la instancia web se queda “eternamente” mostrando un mensaje como el que sigue a pesar de que debería (y lo ha hecho) haber concluido ya la actualización en cuestión.

Briefly unavailable for scheduled maintenance. Check back in a minute.

En esos casos recurres a buscar en google un blog (como este) donde te cuentan la solución o le pides a algún amigo (que hará o habrá hecho lo mismo en alguna ocasión) que te lo solucione. En el peor de los casos le pagas a alguien para que te solucione el problema o recurres a la empresa que te lleva el mantenimiento.

La solución es muy sencilla. wordpress “detecta” que debe de mostrar el mensaje de mantenimiento porque en el directorio raiz de la instancia web existe un archivo llamado .maintenance En algunas ocasiones el borrado de ese fichero falla una vez concluida la actualización y wordpress se queda ahí encallado. Para solucionarlo basta con borrar manualmente ese fichero desde el panel web que usemos para acceder a nuestro servidor (si somos novatos) o desde la consola si nos manejamos un poco mejor. Fácil, eh?

Configurar compresión gzip en nginx

nginx La compresión de lo que el servidor web envía al cliente es una de las técnicas más sencillas para mejorar la respuesta de nuestras webs. En nginx lo habilitamos facilmente a través de las directivas adecuadas del archivo nginx.conf en el directorio /etc/nginx. Por defecto suelen aparecer pero comentadas. Una configuración típica podría ser esta:

 ##
# Gzip Settings
##

gzip on;
gzip_disable "msie6";

gzip_vary on;
gzip_proxied any;
gzip_comp_level 6;
gzip_buffers 16 8k;
gzip_http_version 1.1;
gzip_min_length 256;
gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript application/vnd.ms-fontobject application/x-font-ttf font/opentype image/svg+xml image/x-icon;

La información de que hace cada línea la tienes aquí. Y no olvides que una vez hechos los cambios debes reiniciar el servidor web para que tomen efecto.

Status Cake,una alternativa gratuita a pingdom

herramientas Seguro que conoces Pingdom, la popular herramienta web de monitorización que dispone de 14 días de prueba gratis, pero lo mas probable es que no conozcas Status Cake, una alternativa totalmente gratuita en su opción básica (perfectamente funcional) con una alternativa comercial más avanzada.

panel principal de status cake

Status Cake dispone de monitores http, dns, smtp, ssh, ping y tcp genéricos. En su opción gratuita realiza tests de entre 5 minutos y 24 horas y elige aleatoriamente el servidor desde el que se realiza la prueba (aunque puedes indicarle si quieres confirmación del estado desde diferentes lugares) y te alerta por correo de cualquier incidencia. En la opción de pago admite que elijas manualmente desde donde se harán las pruebas, granularidad de hasta 1 minuto en los tests y alertas por SMS.

Además, disponemos de completos paneles informativos de las incidencias y tiempos de respuesta de los diferentes monitores como puedes ver en los siguientes pantallazos:

status cake key details

status cake status periods and downtime root causes

status cake latest tests

Y informes más “ejecutivos” que pueden enviarse directamente por email para informar al jefe de nuestro buen trabajo 🙂

status cake email reports

Otra alternativa más también gratuita es Uptime Robot pero después de evaluarlas ambas me quedo con Status Cake. Ahí te dejo también el enlace por si quieres echarle un vistazo 😉

Centralizando los datos de munin de varios servidores

herramientas Hemos hablado bastante por aquí en los últimos años acerca de munin. No en vano se trata de una de mis herramientas de monitorización favorita. Vamos a completarlas con alguna cosa más.

Cuando queremos monitorizar varios servidores diferentes, lo más cómodo es verlos todos en la misma página del navegador. Para ello hacemos lo siguiente:

En primer lugar, recordad que munin tiene dos módulos diferentes: munin y munin-node. En el artículo inicial de esta “saga” instalábamos tres paquetes: munin, munin-node y munin-plugins-extra. Ahora instalaremos los tres sólo en la máquina que centralizará los datos de la monitorización. Esta máquina se configurará igual que vimos ya en su día y debe de contar con un servidor web, intérprete de php y todo lo que ya hablamos en su momento. En las máquinas que solamente queremos monitorizar sólo instalaremos los dos paquetes finales (munin-node y munin-plugins-extra).

En todas las máquinas (salvo la que centralizará la comunicación) tendremos que editar el fichero /etc/munin/munin-node.conf. En este fichero nos aseguraremos de que aparecen dos líneas como estas:

host_name nombre2.midominio.net
allow 33.44.55.66

Donde 33.44.55.66 es la IP de la máquina que centralizará la monitorización de munin y nombre2.midominio.net será el nombre con el que queremos que aparezca esta máquina en nuestro panel de monitorización. Una vez hecho esto reiniciamos el daemon de munin-node: systemctl restart munin-node

En la máquina donde queremos ver las gráficas editamos el fichero /etc/munin/munin.conf y escribimos algo como esto:

[nombre1.midominio.net]
    address 127.0.0.1
    use_node_name yes

[nombre2.midominio.net]
    address 11.22.33.44
    use_node_name yes

[nombre3.midominio.net]
    address 55.66.77.88
    use_node_name yes

El primer bloque (nombre1.midominio.net) corresponde a la máquina en la que estamos editando el fichero y por eso usamos 127.0.0.1 como dirección. Cada uno de los otros corresponde con una de las máquinas cuya información queremos recoger y centralizar en esta.

Por defecto las máquinas aparecerán en el panel de monitorización en orden alfabético. Si queremos alterar dicho orden debemos de introducir una nueva directiva:

[midominio.net;]
        node_order nombre2.midominio.net nombre1.midominio.net nombre3.midominio.net

Ojo al punto y coma final de la directiva que es importante para que funcione. Luego reiniciamos el daemon munin (systemctl restart munin).

Ahora, cuando entremos en nuestra página de monitorización veremos en la sección overview una línea llamada midominio.net y luego otra por cada una de las máquinas monitorizadas:

Página de Overview de munin con varios servidores

Y si pulsamos en la línea correspondiente a midominio.net veremos los datos de todos los servidores ordenados en columnas:

Página de monitorización de munin con varios servidores

Y ya. La próxima entrada que hagamos sobre esto irá sobre la posibilidad de que munin realice notificaciones en caso de error o de exceder de ciertos límites. Si, si, yo tampoco lo sabía, pero se puede 😉

Probando el Aruba Cloud Server Smart de 1€

hosting Por fin he tenido tiempo de hacer una primera prueba medianamente seria con mis nuevos VPS de Aruba y, para matar dos pájaros de un tiro, he instalado una instancia de Chamilo LMS para evaluar si me sirve como aula virtual para el curso de este año. He usado el VPS más pequeño de la familia: el de 1Gb de RAM y 1 core de CPU por 1€ al mes. Además, si funcionan bien el hecho de que ofrezcan dos meses gratis me permitirá usarlo con mis alumnos para algunas prácticas sin necesidad de que realicen desembolso alguno. Si, los que tenemos poco tiempo disponible tenemos que aprovechar al máximo el que tenemos 🙂

No voy a describir todo el proceso en detalle y con pantallazos porque es bastante fácil e intuitivo (casi siempre) y si ya has trabajado con algún otro VPS no tendrás problemas. Lo primero que tienes que elegir una vez has hecho login es el datacenter dentro del cual quieres crear tu máquina. Yo escogí uno de los dos italianos porque es un Tier IV y eso mola y porque tiene un 100% de uptime desde su creación en 2011. Posiblemente el francés me daría mejores respuestas desde nuestro país, pero ya tendré tiempo de probarlo. Luego eliges el tamaño de VPS y el sistema operativo a instalar y a esperar. Aquí me he encontrado los dos primeros “inconvenientes”. Por un lado, dentro la lista de sistemas operativos a elegir sólo hay tres opciones de 32 bits (os recuerdo que instalar un sistema operativo de 64 bits en una máquina con menos de 4 gigas de RAM es bastante ineficiente): debian 7, CentOS 6 y Ubuntu 12.04, todas ellas obsoletas… Así que como mi idea era trabajar con Debian 8 instalé la versión de Debian 7 32 bits con idea de usar luego el procedimiento estándar de upgrade. En una máquina nueva y sin dependencias ni software actualizado no debería de dar problemas y, efectivamente, no lo hizo.

El segundo inconveniente fue que la creación de la máquina virtual tardó más de lo que me esperaba. Alrededor de una hora o tal vez algo mas. Ya sabeis como es la impaciencia en estas cosas. Nos pasamos meses pensando en cambiar de hosting y en elegir el adecuado y luego queremos una instalación en segundos 🙂 Pero una vez instalada todo fue como la seda. Hice un login en mi Debian 7, seguí el procedimiento que he enlazado antes y todo listo. Y este es el aspecto que presenta el panel de control web de la VPS (Como siempre, pulsa sobre las imágenes para verlas con mayor calidad):

Panel de control de Aruba Cloud

Como se aprecia, la solapa de “Edit/Upgrade” aparece deshabilitada. Esto es debido a que sólo se puede actualizar la máquina cuando está apagada y, según pone en las FAQs, hacia un modelo mayor.

La primera comparación inevitable con mi anterior hosting es la relativa a los componente virtualizados. Para evaluar esto de forma gráfica instalé phpsysinfo. Estos son los resultados obtenidos:

phpsysinfo en el Aruba Cloud Smart de 1Gb

Y estos los de mi hosting de Gigas (con dos cores y 4 Gigas de RAM). Como se ve, la CPU virtualizada en Aruba Cloud es superior a la que nos proporciona Gigas. Ya veremos si esto se mantiene (o mejora) cuando probemos un VPS de dos cores.

phpsysinfo en el VPS de Gigas

Para monitorizar los recursos he instalado munin y por el momento todo parece muy estable. Lógicamente la máquina apenas ha tenido uso estos días, así que no hay sorpresas con esto. Ya os contaré que tal va cuando se enfrente a una carga moderada:

munin en el Aruba Cloud Smart de 1Gb

Y poco mas. Lo siguiente será trasladar este blog a un VPS más robusto o, incluso, haciendo una separación en dos capas. Ya veré. Y queda pendiente también que os cuente mis primeras impresiones con Chamilo y la configuración necesaria para que funcione con nginx, que no es trivial. Para la próxima. Salud y bienvenidos de vuelta al curso 😉