Mautic: la revolución Open Source en Email Marketing

Uno de los campos en los que decididamente la presencia de soluciones Open Source era casi inexistente es el de la automatización del marketing. En un sector dominado por gigantes como Marketo, Pardot (de SalesForce), Eloqua (de Oracle) y que HubSpot vino a revolucionar allá por 2006, cuando prácticamente introdujo el concepto de Inbound Marketing, se echaba decididamente en falta una alternativa Open Source.

Y no sólo por los costes. Es cierto que soluciones como las arriba citadas son extremadamente caras, dificultando así su adopción por pequeñas y medianas empresas y organizaciones sociales. Pero lo peor es que estas plataformas de marketing automatizado obligaban a las empresas a adaptar sus procesos internos al propio funcionamiento de las herramientas.

Fundador

David Hurley supo ver esto con claridad cuando fundó Mautic en 2013.  Como él mismo dice, “como empresario y emprendedor me quedé profundamente impactado al comprobar que no existían herramientas Open Source de relevancia en los campos del marketing y de la automatización del marketing”. Esta impresión fue la que le movió a fundar una comunidad Open Source en torno al concepto de la automatización del marketing que hoy es, sin duda, la base de toda una revolución en el sector.

Mautic es una plataforma de código abierto que sorprende por su madurez y completitud. Hasta ahora, en el mercado existían herramientas que destacaban por ser intuitivas y fáciles de usar, pero con funcionalidad limitada. Otras herramientas ofrecían una funcionalidad avanzada, pero con la desventaja de ser extremadamente difíciles de implementar. Mautic ha venido a revolucionar este panorama.

Moderna arquitectura

Está desarrollada con una moderna arquitectura, con APIs abiertas que permiten su facilísima integración con cualquier otro tipo de herramientas (CRMs, gestores de contenido, etc). La combinación de facilidad de uso con la más sofisticada tecnología es lo que lo diferencia. Y, al ser Open Source, permite que cada organización pueda adaptarlo y/o extenderlo exactamente de acuerdo a sus necesidades.

Funcionalidades

Resumiendo mucho, algunas de las funcionalidades de Mautic son:

  1. Captación de oportunidades (leads)
  2. Creación y gestión de campañas
  3. Creación, gestión y seguimiento de correos electrónicos
  4.  Formularios
  5.  Cualificación de oportunidades (Lead Scoring)
  6.  Landig pages
  7.  Integraciones. Con todo tipo de herramientas: Facebook, Twitter, Word Press, MS Dynamics, Salesforce… La lista completa está aquí: https://www.mautic.org/integrations/
  8.  Informes

Instalación en Ubuntu 16.04

Quien quiera usar Mautic como servicio, puede hacerlo en https://mautic.com/, que es gratuita hasta cierta cantidad de oportunidades y usuarios. Si queremos instalarla en nuestro propio servidor, teniendo por tanto pleno control de la plataforma, podemos hacerlo de la siguiente forma (instrucciones para Ubuntu Server 16.04):

    1. Descargamos la última versión de Mautic (a día de hoy, la 2.9.2). En nuestro ejemplo la descargaremos en el directorio /var/www:
      cd /var/www
      wget --level=0 https://www.mautic.org/download/latest
    2. Descomprimimos el fichero y, para nuestro ejemplo, creamos un directorio llamado “mautic”:
      unzip latest -d mautic
    3. Cambiamos los permisos de la carpeta recién creada y de su contenido:
      sudo chown -R www-data:www-data /var/www/mautic
    4. Creamos una base de datos para Mautic (en nuestro ejemplo se llama “mautic”)
      mysql -u root -p
      CREATE DATABASE mautic DEFAULT CHARACTER SET utf8 COLLATE utf8_unicode_ci;
      GRANT ALL ON mautic.* TO ‘mauticuser’@’localhost’ IDENTIFIED BY ‘password’;
      FLUSH PRIVILEGES;
      EXIT
    5. Creamos un Virtual Host (en nuestro caso, en Apache):
      sudo gedit /etc/apache2/sites-available/mautic.conf
    6. Ponemos el siguiente contenido en el fichero creado (cambiando rutas y parámetros por los nuestros propios):
      <VirtualHost *:80>
      ServerAdmin mi@correo.com
      ServerName mi.sitio.mautic
      DocumentRoot /var/www/mautic
      <Directory />
      Options FollowSymLinks
      AllowOverride All
      </Directory>
      <Directory /var/www/mautic>
      Options FollowSymLinks MultiViews
      AllowOverride All
      Order allow,deny
      allow from all
      </Directory>
      php_value date.timezone “America/Mexico_City”
      </VirtualHost>
    7. Lo habilitamos:
      sudo a2ensite mautic.conf
    8. Instalamos php5-intl
      sudo apt-get install php5-intl
    9. Reiniciamos Apache:
      sudo systemctl restart apache2.service
    10. Configuramos las tareas programadas necesarias (Cron Jobs):
      crontab -e

      De las siguientes líneas, la 1, 2 y 3 son necesarias. La 4 sólo si quieres programar el envío de emails. La 5 si quieres procesar los emails rebotados. La 6 se necesita si quieres enviar webhooks en lotes y la 7 es para automatizar la descarga de la base de datos de geolocalizacón:

      * * * * * /ruta/al/ejecutable/php /var/www/mautic/app/console mautic:segments:update >/dev/null 2>&1
      * * * * * /ruta/al/ejecutable/php /var/www/mautic/app/console mautic:campaigns:update >/dev/null 2>&1
      * * * * * /ruta/al/ejecutable/php /var/www/mautic/app/console mautic:campaigns:trigger >/dev/null 2>&1
      * * * * * /ruta/al/ejecutable/php /var/www/mautic/app/console mautic:email:process  >/dev/null 2>&1
      * * * * * /ruta/al/ejecutable/php /var/www/mautic/app/console mautic:fetch:email >/dev/null 2>&1
      * * * * * /path/to/php-binary/php /var/www/mautic/app/console mautic:webhooks:process >/dev/null 2>&1
      * 2 10 * * /ruta/al/ejecutable/php /var/www/mautic/app/console mautic:iplookup:download >/dev/null 2>&1
    11. Ya lo único que nos queda es acceder a nuestra instancia de Mautic (en la url definida en el Virtual Host, en el ejemplo “mi.sitio.mautic”) a través de cualquier navegador y completar el proceso de instalación guiado.

Mosaico: Editor de plantillas responsive para Email Marketing

Hoy en día no es nada complicado encontrar buenas herramientas para crear magníficas plantillas de email marketing que funcionan sin problema en cualquier cliente de correo electrónico. A mi particularmente me gusta mucho Litmus (de pago), y casi todas las grandes plataformas de email marketing, como MailChimp o Mailjet, tienen herramientas de creación de emails bastante potentes e intuitivas. Si buscamos alternativas Open Source, Odoo ofrece, entre sus múltiples aplicaciones, una de composición y envío de emails, con un completo sistema de gestión de campañas.

Pero, por el motivo que sea, igual no estamos interesados en utilizar ningún servicio “freemium” o de pago, ni mucho menos instalarnos todo un ERP sólo para una tarea tan concreta como la creación de una plantilla de email responsive. Si este es el caso, Mosaico es una magnífica alternativa, totalmente Open Source y con características de lo más interesantes.

Edición intuitiva

Desarrollado por Stefano Bagnara, uno de los cofundadores de la plataforma italiana de email marketing VOXmail, Mosaico es una librería JavaScript que permite de forma visual e intuitiva la edición de plantillas de correo electrónico. Lo bueno es que Mosaico, el programa en sí mismo, no define lo que se puede editar o qué estilos se pueden cambiar: esto lo controla directamente la plantilla, lo que hace que Mosaico tenga una enorme flexibilidad.

Instalación en Ubuntu

En su página web, https://mosaico.io, se puede ver en ejecución. Si queremos instalarlo en nuestro propio equipo, los pasos son (en Ubuntu 16.04):

  1. Es necesario tener instalada una versión de NodeJS igual o superior a la V6.0. No nos sirve por tanto la de los repositorios de Ubuntu, que actualmente van por la versión 4.6. Lo instalaremos via package manager:
    curl -sL https://deb.nodesource.com/setup_8.x | sudo -E bash --
    sudo apt-get install -y nodejs
  2. Instalamos ImageMagick:
    sudo apt-get install imagemagick
  3. Instalamos grunt-cli:
    npm install -g grunt-cli
  4. Instalamos git:
    sudo apt-get install git
  5. Descargamos el código de Mosaico y lo instalamos en la carpeta deseada (en nuestro caso, /var/www/mosaico):
    wget https://github.com/voidlabs/mosaico/archive/master.zip -P /var/www/mosaico
  6. Nos movemos a la carpeta elegida para la instalación de Mosaico
    cd /var/www/mosaico
  7. Descomprimimos el fichero:
    unzip master.zip
  8. Instalamos Mosaico:
    npm install
  9. Compilamos y ejecutamos el servidor local:
    grunt

Y esto es todo. Como lo hemos instalado localmente, se accederá a Mosaico intruduciendo http://127.0.0.1:9006 en el navegador.

Odoo: cómo hacer que un vendedor sólo pueda ver sus propios clientes


Ya vimos anteriormente cómo instalar Odoo 10 en Ubuntu 16.04. Pero, como dijimos, la labor de configuración posterior a la instalación es aún más importante. Nos podemos encontrar con muchísimas particularidades de nuestra empresa que queremos implementar en el ERP. En nuestro caso, una de las necesidades era que cada uno de los miembros del equipo de venta sólo pudiera visualizar sus propios clientes dentro del sistema.

Paso a paso

En el vídeo anterior se puede ver paso a paso el proceso que seguimos para conseguirlo. De forma resumida, son los siguientes:

  1. En Configuración, activar el “Modo Desarrollador”
  2. Crear un nuevo grupo de vendedores, o modificar alguno de los existentes. En nuestro caso, modificamos el grupo “Ventas / Usuario: Solo mostrar documentos propios”
  3. En la pestaña “Reglas”, hacer clic en “Añadir un elemento” y una vez aquí, hacer clic en el botón “Crear”.
  4. Ponerle un nombre a la nueva regla. Como objeto, buscar y seleccionar “res.partner”
  5. En el campo “Definición de regla (filtro de dominio)”, pegar el siguiente código:
    [‘|’,(‘user_id’,’=’,user.id),(‘user_id’,’=’,False)]
  6. Guardar

Con estos pasos, ya podemos comprobar cómo cada uno de los miembros de los equipos de venta sólo puede ver exclusivamente los clientes que se le han asignado.

Instalar Odoo en Ubuntu 16.04

Toda empresa necesita apoyarse en herramientas que den cobertura a sus necesidades de negocio. Existen en el mercado multitud de sistemas de información que cubren esta necesidad. Los llamados ERP ayudan a la gestión de las actividades de ventas, entregas, pagos, producción, administración de inventarios, contabilidad, recursos humanos , etc.

En nuestro caso, necesitábamos una herramienta para gestionar ventas, selección, contabilidad y facturación. Entre las muchas opciones existentes, nos decantamos por Odoo (aquí su página oficial), que es quizá el software para negocios más instalado en el mundo, con más de 2 millones de usuarios. Nació en el 2004 como Tiny ERP, posteriormente OpenERP y desde 2013 se presenta con su actual nombre.

Odoo tiene tres versiones distintas: Enterprise, Online SaaS y Community version. Esta última es la que nos resulta especialmente interesante, se trata de una aplicación plenamente OpenSource. Es una suite que consta de 34 aplicaciones principales creadas por Odoo, pero que además tiene más de 5,500 aplicaciones desarrolladas por su muy activa comunidad y que dan cobertura a la mayor parte de las necesidades de cualquier negocio. Y con la ventaja de que, al ser modular, puedes instalarte sólo aquello que necesites.

A continuación detallo los pasos que seguimos para su instalación en un servidor con Ubuntu 16.04.

Prerrequisitos

Antes de instalar Odoo realizamos los siguientes pasos:

  1. Actualizar el sistema
    sudo apt update && sudo apt upgrade
  2. Si no tenemos instalado ninguno, instalaremos un servidor web. En nuestro caso, Apache:
    sudo apt-get install apache2
  3. Hay que configurar el firewall para dejar abierto, tanto para acceso ssh como tcp, el puerto utilizado por defecto por Odoo (8069). Este puerto puede personalizarse (aunque no es recomendable configurarlo en el puerto 80, el utilizado por Apache), pero en nuestro caso será el que utilicemos. Lo habilitamos en UFW:
    sudo ufw allow ssh
    sudo ufw allow 8069/tcp
    sudo ufw enable
  4. Odoo está desarrollado en Python. Instalamos sus dependencias:
    sudo apt-get install python-dateutil python-docutils python-feedparser python-jinja2 python-ldap python-libxslt1 python-lxml python-mako python-mock python-openid python-psycopg2 python-psutil python-pybabel python-pychart python-pydot python-pyparsing python-reportlab python-simplejson python-tz python-unittest2 python-vatnumber python-vobject python-webdav python-werkzeug python-xlwt python-yaml python-zsi poppler-utils python-pip python-pypdf python-passlib python-decorator gcc python-dev mc bzr python-setuptools python-markupsafe python-reportlab-accel python-zsi python-yaml python-argparse python-openssl python-egenix-mxdatetime python-usb python-serial lptools make python-pydot python-psutil python-paramiko poppler-utils python-pdftools antiword python-requests python-xlsxwriter python-suds python-psycogreen python-ofxparse python-gevent
  5. La base de datos que utiliza Odoo es PostgreSql. La instalamos y creamos un usuario (en nuestro ejemplo, ‘odoo’):
    sudo apt-get install postgresql
    su -- postgres
    createuser odoo
  6. Ahora creamos el directorio donde vamos a instalar Odoo (en nuestro caso, /opt/odoo):
    sudo mkdir /opt/odoo
  7. Creamos el usuario y grupo ‘odoo’ en nuestro sistema:
    sudo adduser --system --home=/opt/odoo --group odoo

Instalación de Odoo

  1. Clonamos los ficheros de Odoo en la ubicación elegida (en nuestro caso, /opt/odoo/):
    sudo git clone https://www.github.com/odoo/odoo --depth 1 --branch 10.0 --single-branch /opt/odoo
  2. Instalamos las dependencias necesarias para las App de Odoo. Wkhtmltopdf, necesario para la generación de informes en PDF, así como NPM y su paquete less:
    wget http://download.gna.org/wkhtmltopdf/0.12/0.12.1/wkhtmltox-0.12.1_linux-trusty-amd64.deb
    sudo dpkg -i wkhtmltox-0.12.1_linux-trusty-amd64.deb
    sudo cp /usr/local/bin/wkhtmltopdf /usr/bin
    sudo cp /usr/local/bin/wkhtmltoimage /usr/bin
    sudo apt-get -yq install npm
    sudo ln -s /usr/bin/nodejs /usr/bin/node
    sudo npm install -g less less-plugin-clean-css
  3. Instalar las dependencias de Python (si la ruta donde instalaste Odoo es diferente, tienes que cambiar /opt/odoo/odoo-10.0 por tu ruta personalizada):
    sudo pip install -r /opt/odoo/odoo-10.0/doc/requirements.txt
    sudo pip install -r /opt/odoo/odoo-10.0/requirements.txt

Configuración

  1. Copiar el fichero de configuración que viene de ejemplo a una ubicación más conveniente. Si utilizaste una ruta personalizada, tienes que sustituir ‘/opt/odoo/odoo-10.0’ por la tuya propia:
    sudo cp /opt/odoo/odoo-10.0/debian/odoo.conf /etc/odoo.conf
  2. Modificar el fichero de configuración con tus propios datos:
    [options]
    admin_passwd = tupasswordpersonalizadoyfuerte
    db_host = False
    db_port = False
    db_user = odoo
    db_password = False
    addons_path = /opt/odoo/odoo-10.0/addons (modificar si instalaste en otra ruta)
    xmlrpc_port = 8069
    logfile = /var/log/odoo/odoo.log
    log_level = error
    SECURITY_EMAIL_SENDER = ‘tu@mail.com’

Configurar Odoo como servicio

  1. Creamos un fichero llamado odoo.service en /etc/systemd/system, con un contenido como este (de nuevo, si utilizaste rutas diferentes en la instalación, tendrás que personalizarlas aquí):
    [Unit]
    Description=Odoo
    Documentation=http://www.odoo.com/
    [Service]
    # Ubuntu/Debian convention:
    Type=simple
    User=odoo
    ExecStart=/opt/odoo/odoo-10.0/odoo-bin -c /etc/odoo.conf[Install]
    WantedBy=default.target
  2. Cambia propietario y permisos del fichero de configuración para que lo lance el usuario que hemos creado (‘odoo’) :
    sudo chown odoo: /etc/odoo.conf
    sudo chmod 640 /etc/odoo.conf
  3. Arrancamos el servicio:
    sudo systemctl start odoo.service
  4. Comprobamos que funciona:
    sudo systemctl status odoo.service
  5. Si todo está bien, habilitamos el servicio, con lo que se iniciará cada vez que arranque el sistema:
    sudo systemctl enable odoo.service

Configuración de Apache

  1. Para poder acceder a Odoo desde tu propio dominio y sin necesidad de añadir el puerto 8069 en la URL, configuramos un Proxy Reverso en Apache. Primero, habilitamos los siguientes módulos:
    sudo a2enmod proxy
    sudo a2enmod proxy_http
  2. Creamos un archivo de configuración para tu dominio:
    sudo gedit /etc/apache2/sites-available/tu-dominio.com.conf
  3. Añadimos el siguiente contenido:
    <VirtualHost *:80>
    ServerName tu-dominio.com
    ServerAlias www.tu-dominio.com
    ProxyRequests Off
    <Proxy *>
    Order deny,allow
    Allow from all
    </Proxy>
    ProxyPass / http://tu-dominio.com:8069/
    ProxyPassReverse / http://tu-dominio.com:8069/
    <Location />
    Order allow,deny
    Allow from all
    </Location>
    </VirtualHost>
  4. Una vez guardado el contenido del fichero de configuración, lo habilitamos:
    sudo a2ensite tu-dominio.com.conf
  5. Reiniciamos Apache:
    sudo service apache2 restart

Iniciando Odoo

  1. Si todo ha ido bien hasta ahora, ya podemos acceder a Odoo simplemente introduciendo en un navegador la direccón de nuestro dominio:
    http://tu-dominio.com
  2. Debe aparecer una pantalla como la siguiente:
  3. Sólo debemos proporcionar el nombre de la base de datos que creamos en un paso anterior, nuestro e-mail y el password. Con esto ya está Odoo completamente instalado y funcional… ahora sólo queda (pero eso ya no es objeto de este post) instalar los módulos deseados, así como configurar e implementar los procesos de nuestra empresa.

Cómo instalar Plexpy en Ubuntu

Una eficaz y potente herramienta para monitorizar la actividad de tu Plex Media Server

PlexPy
Cuando tu servidor Plex alcanza una cantidad de contenido multimedia considerable y cuando, además, compartes tus contenidos con decenas de usuarios, es una buena idea tener algún tipo de sistema de monitorización. Puede que te interese saber quién está viendo, y cuándo, tu biblioteca multimedia, saber cuáles son los contenidos más demandados, desde qué dispositivos se consumen, etcétera.
Para ello, y de entre las varias opciones que existen, PlexPy es posiblemente una de las más completas y potentes. Se trata de un sistema de monitorización escrito en python y que ha sido diseñado específicamente para Plex. Incluye una increíble cantidad de características que permiten monitorizar la actividad en tiempo real del servidor Plex, acceder a registros históricos, configurar todo tipo de alertas personalizadas, estadísticas, actividad por usuario, y muchas más.

Instalación de Plexpy

El proceso de instalación en Ubuntu es bien simple, lo resumo a continuación:

  1. Si no tenemos aún instalado git, lo instalamos:
    sudo apt-get install git-core
  2. Instalamos PlexPy:
    cd /opt
    sudo git clone https://github.com/drzoidberg33/plexpy.git
    cd plexpy
    sudo python PlexPy.py
  3. Para salir de la pantalla que se nos muestra a continuación, tecleamos:
    :q
  4. En un navegador, introducimos la IP del servidor donde hayamos instalado PlexPy seguido del puerto 8181. Por ejemplo, 192.168.0.1:8181
  5. Esto nos muestra la pantalla de configuración de PlexPy. Introducimos nuestro usuario y contraseña de Plex y ya está. Sólo tenemos que configurarlo a nuestro gusto.
  6. Finalmente, para arrancar automáticamente Plexpy como servicio, tecleamos lo siguiente:
    sudo adduser –system –no-create-home plexpy
    sudo chown plexpy:nogroup -R /opt/plexpy
    sudo ln -s /opt/plexpy/init-scripts/init.ubuntu /etc/init.d/plexpy
    sudo update-rc.d plexpy defaults
  7. Ya hemos terminado. Para arrancar el servicio:
    sudo service plexpy start

La página del proyecto en GitHub, donde se puede obtener el código fuente (y donde se pueden consultar instrucciones para su instalación en otros sistemas operativos), es la siguiente: https://github.com/drzoidberg33/plexpy

HTTPS con LetsEncrypt

Y algunos ajustes adicionales para sitios construidos con WordPress

LetsEncrypt

Cuando nació, allá por la década de los 60 del siglo pasado, Internet servía casi exclusivamente para el envío y recepción de mensajes, y el modelo se parecía mucho al del correo tradicional: el emisor envía algo a un receptor, pero siempre origen, destino y contenido eran conocidos previamente.
Este modelo del Internet primitivo cambió para siempre en 1989. Tim Berners-Lee ideó el lenguaje HTML con el objetivo de organizar los documentos del CERN.

Poco después, en 1991, este sistema se extendió para el envío de todo tipo de documentos a través de Internet, dando origen a la World Wide Web, que es lo mismo que decir Internet tal y como lo conocemos hoy día. Y todo estaba fundamentado en el protocolo de transferencia para hipertextos (HTTP). Exactamente igual que hoy.

HTTP es el protocolo que utiliza cualquier navegador para comunicarse con los servidores web, y que permiten que puedas ver, por ejemplo, esta página. Funciona bien, pero hay que tener en cuenta que con él todos los datos se transmite en texto plano, sin cifrar.

Cualquier persona dentro de tu red o que pueda interponerse entre tu computadora y el servidor será capaz de ver tus contraseñas, datos bancarios, etc. Por eso desde hace años prácticamente todas las webs transaccionales (aquellas en las que puedes realizar operaciones de cualquier índole, pero especialmente compras, transferencias, etc) utilizan HTTPS.

HTTPS

Hyper Text Transfer Protocol Secure (HTTPS) es la versión segura de HTTP. Todas las comunicaciones entre tu navegador y el servidor son encriptadas utilizando SSL/TLS (Secure Sockets Layer/Transmission Layer Security), que son dos protocolos para enviar paquetes cifrados a través de Internet. Su uso como dijimos, está ampliamente difundido entre comercios electrónicos y banca online, aunque desde hace unos años crece la presión para generalizar su uso en detrimento de HTTP. Google, por ejemplo, concede mayor relevancia en sus resultados a los sitios con HTTPS, lo que hace que cualquier experto en posicionamiento se decante por su uso.

El problema, hasta hace poco, es que los certificados que se usan para el cifrado HTTPS eran de pago. Pero todo eso cambió desde el finales del año pasado, cuando la Electronic Frontier Foundation se propuso la puesta en marcha de una “autoridad certificadora” con la intención de ayudar a cifrar el tráfico de toda la web.

LetsEncrypt

Con el nacimiento de LetsEncrypt, cualquiera puede asegurar su sitio web con HTTPS en cuestión de minutos y de forma absolutamente gratuita. Veamos cómo hacerlo en un servidor con Ubuntu Server y Apache:

  1. Comprobar que todos los paquetes del sistema están actualizados, e instalar git:
    apt-get update
    apt-get upgrade
    apt-get install git
  2. Instalar Let’s Encrypt:
    git clone https://github.com/letsencrypt/letsencrypt /opt/letsencrypt
  3. Generar los certificados de Let’s Encrypt:
    cd /opt/letsencrypt
    ./letsencrypt-auto --apache -d ejemplo.com

    También puedes utilizar un único certificado para múltiples dominios o subdominios, para lo que tienes que añadir algunos parámetros al comando:
    ./letsencrypt-auto --apache -d ejemplo.com -d www.ejemplo.com

Con esto ya tenemos el certificado para nuestro sitio web, podemos asegurar razonablemente (https no es invulnerable) que la comunicación entre nuestro servidor y los navegadores de los visitantes del mismo ha sido cifrada y es inviolable. Cuando visiten nuestro sitio, verán algo así:

Candado verde https

Un candado verde, seguido de “https”, que indica que la conexión es segura.

Aspectos adicionales

Ya casi todo el trabajo está hecho. Pero veamos algunos aspectos a revisar.

  1. Para evitar que se pueda acceder a tu sitio web por http, y obligar a que la conexión sea siempre segura, https y por el puerto 443, teclea lo siguiente en la terminal:
    cd /etc/apache2/sites-available
    gedit tusitio.com.conf
  2. Sustituye el contenido del fichero de configuración por lo siguiente:
    RewriteEngine on
    RewriteCond %{SERVER_NAME} =tusitio.com
    RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,QSA,R=permanent]

    Guarda el fichero y reinicia apache
    sudo service apache2 reload

    Con esto, cualquier visitante a tu sitio web será redireccionado a la versión segura.
  3. Si tu sitio está construido con WordPress, tendrás que cambiar la configuración para evitar que el navegador te alerte de que estás ofreciendo contenido inseguro (el candado se verá tachado y/o de color naranja, según el navegador). Ve a la administración de WordPress y en “Ajustes”, cambia la URL del sitio añadiendo “https”.
  4. En función del “Theme” que estés utilizando, es posible que te salga el mismo mensaje de alerta. Revisa que todas las imágenes y URL’s introducidas en las opciones de personalización del Theme comienzan por “https”.
  5. Como apunta Manuti en su comentario, aún pueden quedar elementos que realicen llamadas hacia fuera sin usar https (puede ser el caso de algunos plugins). Estas llamadas se realizan o bien desde el código fuente del sitio web, bien desde su base de datos. Para solucionar los enlaces incorrectos en el código fuente hacemos lo siguiente:
    cd /var/www/tusitio.com
    grep -lir “http://tusitio.com”

    Este comando nos listará los ficheros que contengan un enlace con HTTP. Modificamos estos enlaces por HTTPS.
    Para corregir los enlaces incorrectos que puedan quedar en la base de datos, hacemos lo siguiente:
    mysql -u root -p nombre_de_tu_base_de_datos

    UPDATE wp_options SET option_value = replace(option_value, ‘http://tusitio.com’, ‘https://tusitio.com’) WHERE option_name = ‘home’ OR option_name = ‘siteurl’;

    UPDATE wp_posts SET guid = replace(guid, ‘http://tusitio.com’,’https://tusitio.com’);

    UPDATE wp_posts SET post_content = replace(post_content, ‘http://tusitio.com’, ‘https://tusitio.com’);

    UPDATE wp_postmeta SET meta_value = replace(meta_value,’http://tusitio.com’,’https://tusitio.com’);

Y esto es todo. Ya tienes tu sitio web securizado con HTTPS.

Nunca olvides el factor humano

Cómo aprendí de primera mano que no siempre la solución a los problemas de un sistema está en los logs

Limpiando la computadora
Cuando hice la migración de MartinServer ya era consciente de que no había sido todo lo “limpia” que hubiera sido de desear, y me esperaba algunos problemas.
Efectivamente, en los días siguientes vi cómo se producían desconexiones intermitentes. Creí haberlo solucionado, primero, con un script para actualizar FreeDNS, y más tarde, ya de forma más definitiva, solucionando un problema con la interfaz de red.

Problemas menores

En verdad el sistema quedó mucho más estable, ya apenas se producían caídas. Pero persistían algunos problemillas que me traían de cabeza, y me puse a estudiar como loco los logs del sistema para ver de qué coño se trataba. En primer lugar, cada vez que reiniciaba el sistema, se demoraba una eternidad. No era normal. Yo estoy acostumbrado a trabajar con Ubuntu desde hace años y nunca me había pasado nada igual. Por mucho que un servidor HP ProLiant Gen8 sea diferente, no se justificaba.
El otro problema, poco importante pero desconcertante, es que todos los días se desconectaba unos minutos a las 7:00 AM. Yo monitorizo algunos de los sitios web que alojo en MartinServer con una funcionalidad del plugin JetPack para WordPress. Este plugin te avisa si se ha producido una caída en el servicio y durante bastantes días, como digo, puntualmente me llegaba un mensaje a las 7:00 AM. Sólo duraba unos minutos, pero jodía.

Swap

En cuanto al primer problema, lo que me llamó la atención fue este error:

The disk drive for /dev/mapper/ubuntu--vg-swap_1 is not ready yet or not present.

Esto quería decir que el espacio de intercambio o “swap” no era reconocido en el arranque. Con casi toda seguridad era esto lo que estaba enlenteciendo el arranque.
Me llamó la atención la ruta “/dev/mapper/”, es la que se suele utilizar para las particiones encriptadas. Y yo no recordaba haber encriptado mi partición swap. Así que, tecleando blkid en una terminal, comprobé la UUID de la partición swap, y efectivamente no era la que daba el error. Edité fstab:
sudo nano /etc/fstab

Cambié la ruta de la partición swap por la UUID que me había proporcionado el comando blkid. Guardé y reinicié. Problema resuelto, el arranque ya era normal. Y además (y esto ya no sé explicarme por qué), el segundo problema, el de las desconexiones todos los días a las 7:00AM, también desapareció.

Factor humano

Aún quedaba otro problema más pequeño aún, pero me obsesioné con resolverlo. Todos los miércoles por la mañana, el equipo se apagaba. No era una desconexión de red, sino apagado. Mis sitios webs, el accesso SSH y todos los servicios en general eran inaccesibles, pero sí podía acceder a través del interfaz HP iLO, donde veía que el equipo estaba apagado.

Tampoco podía deberse a un corte de electricidad, porque el equipo se reiniciaría solo. No. La única alternativa que me quedaba era, como digo, volver a encender el equipo a través del interfaz HP iLO. Y después todo volvía a funcionar con normalidad, hasta el siguiente miércoles, cuando volvía a pasar lo mismo.

Me quemé las cejas revisando los logs del servidor, para no encontrar finalmente nada. Estas misteriosas caídas del servidor hubieran quedado para siempre sin resolver si no hubiera recordado que lo único que diferencia los miércoles al resto de los días de la semana es que… ¡una chica viene a limpiar la casa por las mañanas!

La llamé. Le pregunté si había tocado el equipo, y me dijo que sí, que por supuesto, que había visto que yo me lo había dejado encendido y que ella lo apagaba. “Por favor, no lo vuelvas a apagar nunca más -le rogué-“. Misterio resuelto. Maldito factor humano 🙂 .

 

 

Problemas con la interfaz de red

Configurar la interfaz de red para que la reconozca como “em1”

Eth0Cada dos o tres días al principio, cada pocas horas al final, MartinServer estuvo sufriendo una serie de caídas que me impedían acceder al servidor. No tenia acceso a mis páginas web, pero es que tampoco podía acceder remotamente a una terminal vía SSH. El servidor estaba muerto  (o, más exactamente, desconectado). Para salir del paso, apagaba y volvía a encender el equipo, bien directamente o en remoto a través del HP iLO. Pero aquí había un problema que solucionar 🙂 .

Revisando el log del sistema en /var/log/syslog, me encontré con que el error era el siguiente:

Error getting hardware address for “eth0”: No such device

“Eth0” es el nombre que habitualmente se le da en los sistemas Linux a la tarjeta de red, es decir, al adaptador donde se conecta el cable ethernet que nos permite conectarnos a nuestra red LAN y a internet. Lo que estaba pasando, sencillamente, es que mi servidor no encontraba este adaptador de red.
Para averiguar qué estaba pasando, abro el terminal y tecleo:
ifconfig -a

Y me devuelve algo así:
em1       Link encap:Ethernet  direcciónHW b3:5f:dc:87:da:c0
Direc. inet:192.168.1.100  Difus.:191.161.1.255  Másc:255.255.255.0
Dirección inet6: fd80::b25c:dbcc:fd87:dac0/64 Alcance:Enlace
ACTIVO DIFUSIÓN FUNCIONANDO MULTICAST  MTU:1500  Métrica:1
Paquetes RX:14145493 errores:0 perdidos:0 overruns:0 frame:0
Paquetes TX:17842179 errores:0 perdidos:0 overruns:0 carrier:0
colisiones:0 long.colaTX:1000
Bytes RX:6871585837 (6.8 GB)  TX bytes:17386533946 (17.3 GB)
Interrupción:16
em2       Link encap:Ethernet  direcciónHW b3:5f:dc:87:da:c1
ACTIVO DIFUSIÓN MULTICAST  MTU:1500  Métrica:1
Paquetes RX:0 errores:0 perdidos:0 overruns:0 frame:0
Paquetes TX:0 errores:0 perdidos:0 overruns:0 carrier:0
colisiones:0 long.colaTX:1000
Bytes RX:0 (0.0 B)  TX bytes:0 (0.0 B)
Interrupción:17

No me extraña que mi servidor no encontrase el adaptador de red. En mi equipo (es algo que pasó tras la actualización a Ubuntu Server 16.04) se está nombrando el adaptador de red como “em1” en vez de como “eth0”. Busqué la posible razón, y por lo visto es para conseguir mayor consistencia en la nomenclatura de las tarjetas de red. No profundicé mucho en la razón, simplemente procedí a solucionar el problema 🙂 .
La mayor parte de los afectados lo que hicieron fue forzar, modificando el Grub, que la tarjeta de red volviese a llamarse “eth0”. En mi caso fui más cómodo (espero que no me dé más problemas en adelante), y lo único que hice fue renombrar el interfaz de red:
sudo nano /etc/network/interfaces

Y aquí dejé el fichero de configuración de red tal que así:
source /etc/network/interfaces.d/*
# The loopback network interface
auto lo
iface lo inet loopback
# The primary network interface
auto em1
iface em1 inet dhcp

Listo. A partir de ahora, mi sistema “sabe” que la interfaz del red se llama “em1”. No he vuelto a tener esos problemas de conexión.

Problemas con la actualización de FreeDNS

Y de cómo le hallé solución

FreeDNSComo ya conté aquí hace algún tiempo, tanto mis páginas webs como la de algunos amigos las alojo en un servidor casero, al que llamo MartinServer :-). Realmente, para el tráfico que tienen está bastante bien. Cuento con 200Mb simétricos, tanto de subida como de bajada, y he podido comprobar tanto desde aquí en México como desde España que su rendimiento es bastante razonable.

El único problema es el de los DNS. Yo no he contratado una IP estática con mi proveedor, luego la IP de MartinServer cambia cada cierto tiempo. Por tanto, no me queda más remedio que contratar o utilizar algún servicio gratuito que se encargue de renovar los DNS  de mis páginas webs cada vez que a mi proveedor le dé por cambiar la IP de mi servidor.

Para el dominio martinalia.com contraté DynDNS. Es un servicio de pago, pero supercómodo. Tan sólo tengo que configurar los parámetros de mi cuenta en mi router (un Linksys WRT1900 AC), y ya está. Puedo estar seguro de que cada vez que cambie la IP de MartinServer, el propio router lo comunicará a DynDNS y de ahí se propagará, garantizando que martinalia.com siempre esté online.

Para el resto de los websites, en cambio, opté por un servicio gratuito: FreeDns. En mi router no se puede configurar (al menos no de forma sencilla) este servicio, por lo que tuve que recurrir a instalar en el servidor un servicio que se encargase de esta tarea.

ddclient

De entre todos los disponibles, me decanté por ddclient. Se instala así:

sudo apt-get install ddclient

Una vez instalado, hay que editar la configuración, de la siguiente manera:
sudo nano /etc/ddclient/ddclient.conf

Y dejamos la configuración con algo como esto:
# /etc/ddclient/ddclient.conf
#
daemon=3600 # Aquí le decimos la frecuencia con que se actualizará. En el ejemplo, cada 3600 segundos
protocol=freedns
use=if, if=eth0
ssl=yes # Aquí le indicamos si se utilizará o no SSL
use=web, web=http://ip.dnsexit.com/ # Aquí podemos poner cualquier servicio que nos devuelva la IP que estamos utilizando
server=freedns.afraid.org
login=nombre_de_usuario
password=’contraseña’
midominio.ejemplo.com #Aquí listamos nuestro dominio o dominios a actualizar

Y ya está. Con esto debería funcionar, y de hecho me funcionó en el momento en el que lo instalé. Sin embargo, hace unos días mi proveedor cambió la IP con la que MartinServer sale a internet. Mi web martinalia.com seguía funcionando, porque está configurada con DynDNS en el router, pero el resto de las webs dejaron de funcionar.

Le di un vistazo al log del sistema en /var/log/syslog y lo que me indicaba es que la conexión de ddclient con el servicio de FreeDNS no se podría realizar. Estuve un buen rato trasteando con la configuración para ver si lo solucionaba, pero como todo intento fue infructuoso, corté por lo sano. Me monté yo mismo una tarea programada (cron) para actualizar el servicio.

La solución

La idea me la dio No soy vago, soy eficiente. Creé un archivo llamado “freeDNS.sh”, le di permiso de ejecución. Lo edité y quedó tal que así:

#! /bin/bash
DOMINIO=”midominio.ejemplo.com”
UPDATE_URL=”http://freedns.afraid.org/dynamic/update.php?xxxxxxxxxxxx” #donde pone xxxxxxxxxxxx va la cadena que te genera para tu dominio FreeDNS
UPDATE_COMMAND=”/usr/bin/curl -s $UPDATE_URL”
logger “Actualizando FreeDNS”
CURRENTIP=`curl -s ip.dnsexit.com | sed ‘s/[^0-9.]//g’`
echo “IP actual: ${CURRENTIP}”
CURRENTIPDOMINIO=`dig -x -add +short $DOMINIO`
echo “IP de $DOMINIO: ${CURRENTIPDOMINIO}”
if [ “${CURRENTIP}” != “${CURRENTIPDOMINIO}” ] ; then
echo “Encontrada diferencia, actualizando”
logger “Actualizando a ${CURRENTIP}”
if ${UPDATE_COMMAND}; then
echo “IP actualizada”
else
echo “Error actualizando FreeDNS”
fi
else
echo “No hay cambios, no se hace nada”
fi

Una vez listo, hacemos un “crontab -e”, y añadimos la línea:
*/5 * * * * /home/ruta_a/freeDNS.sh

Con esto le decimos que actualice la información sobre nuestra IP en FreeDNS cada 5 minutos. Y listo. Funcionando.

Migrando MartinServer a un HP ProLiant MicroServer Gen8

Venturas y desventuras del cambio de servidor

hp proliant

Hewlett Packard Enterprise ProLiant MicroServer Gen8 E3-1220v2 4GB-U B120i LFF 2x1TB Server/S-Buy – Servidor

Hace menos de un año que puse mi propio servidor, MartinServer, en marcha. Desde entonces alojo todas mis páginas webs en casa, sin recurrir a ningún proveedor de hosting. El PC que utilizaba como servidor era bastante mediocre, un HP dc7800p Convertible Minitower, pero la verdad es que para lo que me costó ha venido funcionando bastante bien.

Pero el uso verdaderamente intensivo de MartinServer ha venido de parte del Servidor Plex que instalé. Actualmente alojo unas 1.500 películas y unas cincuenta series, que no sólo disfruto yo, sino que comparto con 15 amigos en 3 países diferentes.

Obviamente, con este escenario el rendimiento ya se resiente, y cuando tres o más usuarios están transcodificando vídeo simultáneamente, el servidor se desestabiliza peligrosamente. Ya se ha caído en alguna ocasión.

Llevo bastante tiempo pensando en cambiar el equipo, de forma que obtenga un rendimiento razonable. La mayor parte de los usuarios de Plex utilizan un NAS como servidor. Yo de hecho tengo dos Western Digital, uno de 3 TB y otro de 6 TB, donde almaceno mi contenido multimedia, aunque Plex está instado en el HP dc7800p.

Pero no es una solución que me convenza: MartinServer no sólo lo utilizo como servidor de Plex, es además mi servidor web, mi servidor FTP, mi almacenamiento en la nube particular… lo que necesito es un pequeño servidor doméstico.

ProLiant

La verdad es que no entiendo nada de hardware, por lo que me he tomado mucho tiempo pensando las opciones. Tras mucho comparar, fijé mi atención en el  HP ProLiant MicroServer Gen8, un servidor de diseño compacto y elegante que, además, tenía buenas referencias entre usuarios de Plex. Sólo advertían de la poca potencia del procesador, que no permitía demasiadas transcodificaciones simultáneas. En cualquier caso, el modelo que se me había antojado venía con un procesador Intel Xeon E3-1220L, que debería ser más que suficiente para soportar la carga de MartinServer.

Así que finalmente me decidí, y hace apenas unos días llegó a mi casa. Ahora quedaba el reto de migrar el servidor de equipo sin romper nada por el camino 🙂 .

Preparativos

La mayor parte de los propietarios de un  HP ProLiant MicroServer Gen8, por lo que vi, instalan el sistema operativo en un SDD (unidad de estado sólido) que obviamente se compra por separado y se conecta a través de la bahía para la unidad de disco óptico que viene dentro del equipo (hay que desmontarlo para su instalación). La ventaja de esta opción es mantener separado el sistema operativo de las unidades de almacenamiento (el HP Proliant viene con cuatro bahías para discos duros).

Yo ignoré esta opción. Mi equipo venía con dos discos duros de 1 TB, y yo le añadí otros dos discos duros de 6 TB cada uno. 14 TB en total. Decidí usar el primero de los discos de 1 TB para el sistema operativo y para la carpeta /home, el segundo para copias de seguridad y los dos discos de 6 TB para almacenar contenidos multimedia.

Otra opción que ignoré fue la de configurar los discos duros en RAID (Redundant Array of Independent Disks, es decir, “conjunto redundante de discos independientes”). Se suele utilizar para montar un espejo entre discos duros y, de esta forma, replicar la información en dos discos duros idénticos. Yo, imprudentemente, he ignorado esta posibilidad, he priorizado la capacidad total de almacenamiento sobre la seguridad.

Ubuntu Server

Así que pude proceder a instalar Ubuntu sin mayor demora. Lo único a tener en cuenta antes de instalar este sistema operativo es modificar la opción “Smart Array B120i RAID controller enabled” que viene por defecto en la BIOS (y que no está soportada por Ubuntu) por la opción “SATA AHCI Support”. Es fácil de hacer: Presionamos la tecla F9 y nos vamos a “System Options -> SATA Controller Options -> Embedded SATA Configuration”. Ahí seleccionamos “Enable SATA AHCI Support”. Presionamos la tecla ESC hasta que aparezca la opción para guardar, y listo.

Hecho esto, introducimos un USB de arranque con Ubuntu Server. Antes de instalar, abrimos Gparted y formateamos y montamos los discos duros. Reiniciamos, arrancamos nuevamente desde el USB, seguimos los pasos para la instalación y nada más. Ya está el HP Proliant funcionando con Ubuntu Server.

Clonando el servidor

Conecto el HP Proliant a mi red doméstica. Para clonar MartinServer utilizo el comando dd, que es una herramienta simple y muy potente. Con este comando puedo clonar todo el disco físico incluyendo el MBR (arranque de sistema), todas las particiones, UUIDs (la identificación única de cada partición) y los datos.
En el terminal escribí el siguiente comando para copiar el MBR:

su -c ‘dd if=/dev/sda of=/ruta/al/respaldo/sdabk.mbr count=1 bs=512’

Donde “/ruta/al/respaldo/” es donde guardé la copia de seguridad, un disco externo accesible tanto por el servidor viejo como por el nuevo.

Para realizar la copia de seguridad del sistema en sí, tecleé lo siguiente:

su -c ‘tar -cvpzf /ruta/al/respaldo/linuxbackup.tgz --exclude=/ruta/al/respaldo/ --exclude=/lost+found --exclude=/dev --exclude=/proc --exclude=/sys /’

Donde “/ruta/al/respaldo/”, nuevamente, es la ruta de acceso al disco duro externo. Con esto creé el archivo “linuxbackup.tgz” en el disco duro externo, que es una copia de seguridad completa del sistema. Es muy importante la opción “–exclude”, con ella le decimos qué debe quedar fuera de la copia de seguridad, como los discos duros externos o los directorios que están dinámicamente llenos por el sistema durante el arranque.

Migración

Ahora en el nuevo servidor, en el HP Proliant, escribí el siguiente comando para restaurar el MBR:

dd if=/ruta/al/respaldo/sdabk.mbr of=/dev/sda

Y para restaurar el sistema:
su -c ‘tar -xvpzf /ruta/al/respaldo/linuxbackup.tgz -C /’

Finalmente:
su -c ‘mkdir /proc && mkdir /lost+found && mkdir /dev && mkdir /sys && init 6’

Con esto se vuelven a crear los directorios excluidos y se reinicia el sistema. Teóricamente, el nuevo servidor debería ser idéntico al original.

Problemas

Pero algo debí hacer mal, porque el nuevo servidor no arrancaba. Me daba el error:

error: no such device: …
press any key to continue …

Seguramente no respaldé o restauré correctamente el MBR, con lo que la UUIDs de las particiones no coincidían. Es decir, en el archivo /etc/fstab del nuevo servidor se estaba apuntando a particiones que no existían. En el Grub seguramente habría la misma incongruencia.
Para solucionar esto, reinicié de nuevo el equipo con el USB de instalación. Desde una terminal tecleé:
blkid

Este comando me listó las UUIDs correctas del nuevo servidor. Con esta información siempre a la vista, abro otra ventana del terminal y tecleo:
gksudo gedit /boot/grub/grub.cfg

Me abre el fichero de configuración del Grub, el gestor de arranque. Cambio las antiguas UUIDs por las nuevas.
A continuación, lo mismo para fstab:
gksudo gedit /etc/fstab

Nuevamente cambio las antiguas UUIDs por las nuevas. Guardo y reinicio el sistema. Y… voilà! MartinServer ya está funcionando en el flamante HP Proliant Server.
El único detalle final es desconectar el servidor antiguo de la red y configurar en el router, para el nuevo servidor, la misma IP que utilizaba el servidor antiguo. Con esto, listo y funcionando.