pornoHARDWARE.com

Unifica el estilo del código de un proyecto con Editorconfig

BhEaN — Sat, 27 Feb 2021 03:54:02 +0100

Dicen que en la variedad está el gusto. Y efectivamente, siempre es mejor tener muchas opciones para poder elegir entre ellas la que más nos guste. Pero cuando por variedad no nos referimos a los sabores de un helado sino a que en un mismo proyecto tenemos gente que usa un editor de código que finaliza los archivos con una nueva linea mientras que otros usan otro editor que no, unos indentan los archivos con espacios y otros con tabuladores, unos tienen el tamaño máximo de cada línea de 80 carácteres y otros de 120... al final acabamos con un popurrí de estilos que en el mejor de los casos hará que las revisiones de código sean un infierno y que haya cambios en el código cuya aprobación dependerá subjetivamente de la persona que esté revisándolos en ese momento. La variedad ahora ya no está tan bien, ¿verdad?

Alta disponibilidad en etcd: Desplegando un cluster paso a paso

BhEaN — Sun, 06 May 2018 00:14:02 +0100

Si estas intentando montar un cluster de Kubernetes en alta disponibilidad, o bien tienes alguna experiencia en esto porque lo has visto anteriormente o porque ya has trabajado con ello antes, o bien has llegado a este artículo buscando ayuda en Internet después de haber pasado un buen rato intentando seguir sin éxito los pasos de la incorrecta documentación oficial de multi-master en Kubernetes que hay publicada al respecto.

Bien por este motivo o bien porque quieres tener un servicio de etcd tolerante a fallos para tu proyecto, espero que con este artículo no te quede ninguna duda sobre cómo montar un cluster para conseguir alta disponibilidad y comunicaciones totalmente cifradas con SSL en el servicio de etcd.

Así que basta ya de hablar y vamos al turrón...

High availability in etcd: Deploying a cluster step by step

BhEaN — Sun, 06 May 2018 00:14:02 +0100

Así que basta ya de hablar y vamos al turrón...

Para intentar organizarlo un poco, voy a dividir el artículo en varias partes:

¿Qué es etcd?
Consideraciones iniciales de nuestro cluster
Creación de los certificados SSL
Instalación y configuración del cluster
Administración básica
Referencias

¿Qué es etcd?

Etcd es un servidor de almacenamiento de datos de tipo clave-valor (similar a Redis, aunque con bastantes diferencias) diseñado para funcionar de forma distribuida, rápida y estable.

Forma parte del sistema CoreOS, y es un proyecto de código abierto escrito en Go y liberado bajo licencia Apache 2.0.

Etcd es un proyecto maduro y que lleva muchos años en desarrollo constante por lo que muchos grandes proyectos lo utilizan para almacenar sus configuraciones debido a su gran estabilidad y rapidez, pero últimamente su desarrollo se ha visto potenciado aún más sobre todo por el auge que está teniendo Kubernetes, que es uno de estos grandes proyectos que utilizan etcd.

Toda la comunicación con etcd se realiza a través de una API que puede ser explotada mediante JSON a través de HTTP/HTTPS o a través del cliente etcdctl para linea de comandos.

A principios de año (enero de 2018), CoreOS (y por lo tanto etcd) fué comprado por Redhat.

Consideraciones iniciales de nuestro cluster

Como recomendación general, para montar un cluster en alta disponibilidad debemos utilizar el mayor número posible de nodos.

En cualquier caso, debemos utilizar al menos 3 nodos para el cluster ya que aunque teóricamente bastaría con 2 nodos para tener tolerancia a fallos, en un cluster de etcd siempre debe haber un nodo principal (llamado leader) que es el que tendrá el control de determinadas funciones del cluster, y si ese nodo leader quedara fuera de servicio por algún motivo, los demás nodos del cluster utilizarían un quórum para designar quién sería el nuevo leader. El algoritmo que se utiliza para obtener dicho quórum es Raft, usado no solo para este proyecto sino para muchísimos otros, por lo tanto debe haber al menos 3 nodos para que si se pierde el nodo leader los otros 2 puedan designar un sustituto.

Así que en este artículo vamos a crear un cluster con 3 nodos que tendrán estas características:

#	Nombre	IP	RAM
1	etcd01	192.168.1.83	2 Gb
2	etcd02	192.168.1.84	2 Gb
3	etcd03	192.168.1.85	2 Gb

Todas estas máquinas parten de una instalación limpia de mi sistema operativo favorito (Debian, concretamente la versión stable 9.4) pero debería funcionar prácticamente igual (con ligeros cambios en algunos paths o en el nombre de algún paquete) en cualquier otra distribución de Linux.

Antes de empezar, asegúrate de que todos estos servidores tienen conectividad entre ellos, y que resuelven los nombres de los demás. Lo mejor sería que tuvieras tu propio servidor DNS (bind o similar) configurado en tu red para resolver todos los nombres de tus servidores, pero sino, puedes añadir las 3 direcciones IP con sus respectivos nombres al archivo /etc/hosts de cada uno de ellos:

/etc/hostsdownload

127.0.0.1       localhost
192.168.1.83    etcd01
192.168.1.84    etcd02
192.168.1.85    etcd03

# The following lines are desirable for IPv6 capable hosts
::1     localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters

Ni qué decir tiene que es recomendable asegurarse siempre de que partimos de un sistema actualizado:

$ sudo apt-get update
$ sudo apt-get dist-upgrade

En mi caso, las últimas versiones disponibles en el momento de escribir este artículo son (no te preocupes si alguno no te suena, los iremos viendo a medida que los vayamos necesitando):

Etcd: 3.3.4
cfssl: 1.2
cfssljson: 1.2

Creación de los certificados SSL

Como acabo de comentar, toda la comunicación tanto entre el cliente y el servidor de etcd como entre los propios servidores de etcd de un cluster puede realizarse por SSL, cifrando de esa forma todas las comunicaciones y aportando otra capa de seguridad al sistema.

Aunque podríamos montar el cluster utilizando únicamente HTTP, es muy sencillo generar unos certificados y configurar etcd para que los use, por lo que vamos a hacerlo de esta forma.

Lo primero que debemos hacer será generar los certificados que vamos a necesitar, que son:

Cliente: Este certificado es el que usaremos nosotros (o la aplicación que se vaya a conectar a etcd, como por ejemplo Kubernetes) para conectarnos al cluster.
Servidor: Este certificado es el que usará cada uno de los nodos de nuestro cluster para cifrar las comunicaciones.
Peer (no se muy bien como traducirlo): Este certificado es el que usará cada nodo para conectarse a los demás nodos del cluster (muy similar al certificado de cliente, pero generaremos ambos para diferenciar unas conexiones de otras).

La explicación sobre el intercambio de certificados en una comunicación SSL, los tipos de certificados, su firma, etc. es algo que queda fuera del ámbito de este artículo por lo que no voy a explicarlo con demasiado detalle. Si alguno de estos conceptos no te queda claro, te recomiendo que investigues un poco acerca del funcionamiento de estos certificados (intentaré escribir otro artículo sobre SSL algún dia).

Para generar los certificados vamos a utilizar cfssl, que es una herramienta de código-abierto desarrollada por CloudFlare muy fácil de utilizar y que nos permite generar y firmar certificados desde la linea de comandos.

En lugar de ir nodo por nodo, vamos a instalar la herramienta en nuestra máquina local para generar los certificados, y una vez generados los copiaremos a los 3 nodos.

Como dije antes, en el momento de escribir este artículo la última versión de cfssl era la 1.2, por lo que os recomiendo que antes de instalarla comprobéis en su página (https://pkg.cfssl.org/) que no haya ninguna versión más reciente, y en caso de haberla, cambiad las siguientes URLs según corresponda para poder instalar la aplicación actualizada:

$ sudo curl -o /usr/local/bin/cfssl https://pkg.cfssl.org/R1.2/cfssl_linux-amd64
$ sudo curl -o /usr/local/bin/cfssljson https://pkg.cfssl.org/R1.2/cfssljson_linux-amd64
$ sudo chmod +x /usr/local/bin/cfssl*

Creamos un directorio en cualquier parte de nuestro disco duro (y nos situamos en él) para ir guardando los certificados de forma temporal hasta que los hayamos copiado a los nodos de nuestro cluster:

$ mkdir $HOME/etcd-certs
$ cd $HOME/etcd-certs

Y ahora vamos creando los certificados necesarios:

Certificado de la Autoridad de Certificación (CA)

Primero, crearemos un archivo JSON llamado ca-config.json con la configuración de la Autoridad de Certificación (CA) que va a firmar los certificados que vamos a generar.

En él definiremos la expiración de los certificados, el uso que les vamos a dar (autenticación, firma, ...), etc:

ca-config.jsondownload

{
  "signing": {
    "default": {
      "expiry":"43800h"
    },
    "profiles": {
      "server": {
        "expiry":"43800h",
        "usages": [
          "signing",
          "key encipherment",
          "server auth",
          "client auth"
        ]
      },
      "client": {
        "expiry":"43800h",
        "usages": [
          "signing",
          "key encipherment",
          "client auth"
        ]
      },
      "peer": {
        "expiry":"43800h",
        "usages": [
          "signing",
          "key encipherment",
          "server auth",
          "client auth"
        ]
      }
    }
  }
}

Después crearemos otro archivo llamado ca-csr.json donde irá la configuración de la solicitud de certificación (CSR), donde indicaremos el algoritmo de cifrado que queremos utilizar, la longitud de la clave, los datos del certificado, etc:

ca-csr.jsondownload

{
  "CN":"etcd",
  "key": {
    "algo":"rsa",
    "size":2048
  },
  "names": [
    {
      "C":"ES",
      "L":"Madrid",
      "O":"PornoHardware S.L.U.",
      "OU":"Tech department",
      "ST":"Spain"
    }
  ]
}

Generamos los certificados de nuestra Autoridad de Certificación:

$ cfssl gencert -initca ca-csr.json | cfssljson -bare ca -

Una vez ejecutado el comando habremos obtenido 3 nuevos archivos:

ca.csr: La petición de generación de certificado.
ca.pem: El certificado raíz.
ca-key.pem: La clave del certificado raíz.

Ya tenemos nuestro certificado raíz, vamos a seguir con los demas...

Certificado de cliente

Este certificado es el que usaremos nosotros mismos para conectarnos al cluster y lanzar los comandos que queramos ejecutar de forma segura.

Creamos el archivo client.json:

client.jsondownload

{
  "CN": "client",
  "key": {
    "algo": "ecdsa",
    "size": 256
  }
}

Y utilizando el recién creado certificado raíz y la configuración que habíamos definido al principio, generamos el certificado de cliente:

$ cfssl gencert -ca=ca.pem -ca-key=ca-key.pem -config=ca-config.json -profile=client client.json | cfssljson -bare client

Una vez ejecutado el comando habremos obtenido 3 nuevos archivos:

client.csr: La petición de generación de certificado.
client.pem: El certificado de cliente.
client-key.pem: La clave del certificado de cliente.

Certificados peer y de servidor

Cada uno de los nodos necesita también un certificado para cifrar las conexiones que los demás nodos se hagan entre si (peer). Este certificado necesita generarse para un nombre de host y una IP en concreto (la de cada servidor), por lo tanto necesitamos generar 3 certificados diferentes (uno para cada nodo de nuestro cluster).

Creamos un archivo de configuración por cada nodo, donde indicaremos el nombre del servidor y su IP, entre otras cosas:

Para el nodo 1:

config-etcd01.jsondownload

{
  "CN": "etcd01",
  "hosts": [
    "etcd01",
    "etcd01.local",
    "192.168.1.83"
  ],
  "key": {
    "algo": "ecdsa",
    "size": 256
  },
  "names": [
    {
      "C": "ES",
      "L": "Madrid",
      "ST": "Spain"
    }
  ]
}

Para el nodo 2:

config-etcd02.jsondownload

{
  "CN": "etcd02",
  "hosts": [
    "etcd02",
    "etcd02.local",
    "192.168.1.84"
  ],
  "key": {
    "algo": "ecdsa",
    "size": 256
  },
  "names": [
    {
      "C": "ES",
      "L": "Madrid",
      "ST": "Spain"
    }
  ]
}

Para el nodo 3:

config-etcd03.jsondownload

{
  "CN": "etcd03",
  "hosts": [
    "etcd03",
    "etcd03.local",
    "192.168.1.85"
  ],
  "key": {
    "algo": "ecdsa",
    "size": 256
  },
  "names": [
    {
      "C": "ES",
      "L": "Madrid",
      "ST": "Spain"
    }
  ]
}

Como todos los certificados que vamos a generar tendrán el mismo nombre (server.pem, server-key.pem, ...) independientemente del nodo al que correspondan, vamos a crear un subdirectorio por cada nodo y a generar los certificados de cada uno de ellos en su respectivo directorio.

Creamos el subdirectorio, entramos en él, generamos los certificados (tanto los de servidor como los peer) y continuamos con el siguiente sucesivamente hasta que hayamos generado los certificados de los 3 servidores:

$ mkdir $HOME/etcd-certs/etcd01
$ cd $HOME/etcd-certs/etcd01
$ cfssl gencert -ca=../ca.pem -ca-key=../ca-key.pem -config=../ca-config.json -profile=server ../config-etcd01.json | cfssljson -bare server
$ cfssl gencert -ca=../ca.pem -ca-key=../ca-key.pem -config=../ca-config.json -profile=peer ../config-etcd01.json | cfssljson -bare peer
$ mkdir $HOME/etcd-certs/etcd02
$ cd $HOME/etcd-certs/etcd02
$ cfssl gencert -ca=../ca.pem -ca-key=../ca-key.pem -config=../ca-config.json -profile=server ../config-etcd02.json | cfssljson -bare server
$ cfssl gencert -ca=../ca.pem -ca-key=../ca-key.pem -config=../ca-config.json -profile=peer ../config-etcd02.json | cfssljson -bare peer
$ mkdir $HOME/etcd-certs/etcd03
$ cd $HOME/etcd-certs/etcd03
$ cfssl gencert -ca=../ca.pem -ca-key=../ca-key.pem -config=../ca-config.json -profile=server ../config-etcd03.json | cfssljson -bare server
$ cfssl gencert -ca=../ca.pem -ca-key=../ca-key.pem -config=../ca-config.json -profile=peer ../config-etcd03.json | cfssljson -bare peer

Una vez ejecutados todos los comandos habremos obtenido 6 nuevos archivos en cada subdirectorio:

peer.csr: La petición de generación de certificado.
peer.pem: El certificado peer.
peer-key.pem: La clave del certificado peer.
server.csr: La petición de generación de certificado.
server.pem: El certificado de servidor.
server-key.pem: La clave del certificado de servidor.

Si todo ha ido bien, ahora deberíamos tener todos los certificados necesarios para nuestro cluster generados en $HOME/etcd-certs/, por lo que deberíamos tener algo parecido a ésto:

├─ $HOME/etcd-certs/
│  ├─ ca.csr
│  ├─ ca.pem
│  ├─ ca-config.json
│  ├─ ca-csr.json
│  ├─ ca-key.pem
│  ├─ client.csr
│  ├─ client.json
│  ├─ client.pem
│  ├─ client-key.pem
│  ├─ config-etcd01.json
│  ├─ config-etcd02.json
│  ├─ config-etcd02.json
│  ├─ etcd01/
│  │  ├─ peer.csr
│  │  ├─ peer.pem
│  │  ├─ peer-key.pem
│  │  ├─ server.csr
│  │  ├─ server.pem
│  │  └─ server-key.pem
│  ├─ etcd02/
│  │  ├─ peer.csr
│  │  ├─ peer.pem
│  │  ├─ peer-key.pem
│  │  ├─ server.csr
│  │  ├─ server.pem
│  │  └─ server-key.pem
│  └─ etcd03/
│     ├─ peer.csr
│     ├─ peer.pem
│     ├─ peer-key.pem
│     ├─ server.csr
│     ├─ server.pem
│     └─ server-key.pem

Ya tenemos todos los archivos que necesitamos para poder configurar nuestro cluster de etcd utilizando SSL, por lo que ya solo nos queda copiarlos a cada uno de los nodos.

No hace falta que copiemos todos los archivos a cada nodo, únicamente vamos a necesitar estos:

ca.pem
client.pem
client-key.pem

Y para cada uno de los nodos únicamente los de su respectivo subdirectorio:

etcdXX/server.pem
etcdXX/server-key.pem
etcdXX/peer.pem
etcdXX/peer-key.pem

Como ya comenté antes, en mi caso estoy montando este cluster de etcd para su uso con Kubernetes por lo que voy a copiar los certificados al directorio /etc/kubernetes/pki/etcd de cada nodo, pero vosotros podéis copiarlos al directorio que queráis (/etc/etcd/certs, por ejemplo).

Una vez copiados estos 7 archivos a cada nodo ya podemos empezar con la configuración del cluster.

Importante: Aunque no todos los archivos generados hacen falta os recomiendo que los guardéis igualmente (sobre todo los archivos de configuración) por si en un futuro necesitáis volver a generar los certificados de alguno de los servidores o generar nuevos certificados para un nuevo nodo con el que ampliar el cluster.

Instalación y configuración del cluster

Antes de nada, si los nodos que vas a utilizar para el cluster tienen algún firewall configurado, debemos abrir los puertos necesarios para poder conectarnos.

Etcd utiliza estos puertos por defecto:

2379: Para las conexiones de los clientes
2380: Para las conexiones entre los demás nodos del cluster

Por lo tanto debemos asegurarnoss de que podemos conectarnos al puerto 2380 de cualquier nodo desde cualquier nodo y al puerto 2379 de cualquier nodo desde donde vayamos a hacer peticiones al cluster.

Es importante comprobar que no tengamos en nuestros nodos ninguna versión de etcd ya instalada. Si es así, hay que desinstalarla primero.

Antes de instalar una nueva versión de etcd tenemos que saber cuál es esa última versión, por lo que vamos a la zona de releases de su página de Github (https://github.com/coreos/etcd/releases) y lo comprobamos.

En este momento la última versión es la 3.3.4, por lo que descargamos e instalamos dicha versión en cada uno de los nodos de nuestro cluster:

$ export VERSION=v3.3.4
$ curl -sSL https://github.com/coreos/etcd/releases/download/$VERSION/etcd-$VERSION-linux-amd64.tar.gz | sudo tar -xzv --strip-components=1 -C /usr/local/bin/

Ahora que ya tenemos etcd instalado en los 3 nodos, vamos a configurarlo.

Creamos un archivo /etc/etdc.env en cada uno de los nodos con el nombre e IP de cada servidor:

Para el nodo 1:

/etc/etcd.envdownload

PEER_NAME=etcd01
PRIVATE_IP=192.168.1.83

Para el nodo 2:

/etc/etcd.envdownload

PEER_NAME=etcd02
PRIVATE_IP=192.168.1.84

Para el nodo 3:

/etc/etcd.envdownload

PEER_NAME=etcd03
PRIVATE_IP=192.168.1.85

Ahora vamos a crear los archivos de configuración de systemd para que podamos arrancar, reiniciar y parar el servicio de etcd como haríamos con cualquier otro servicio.

Para eso, creamos un archivo /etc/systemd/system/etcd.service en cada uno de los nodos, indicando los argumentos que se le pasarán al programa etcd cuando arranque, y que son básicamente el nombre e IP del servidor, el nombre e IP de los demás nodos del cluster, la ruta a los certificados que generamos en el paso anterior, etc.

El archivo quedaría más o menos así para el nodo 1:

/etc/systemd/system/etcd.servicedownload

[Unit]
Description=etcd
Documentation=https://github.com/coreos/etcd
Conflicts=etcd.service
Conflicts=etcd2.service

[Service]
EnvironmentFile=/etc/etcd.env
Type=notify
Restart=always
RestartSec=5s
LimitNOFILE=40000
TimeoutStartSec=0

ExecStart=/usr/local/bin/etcd \
  --name etcd01 \
  --data-dir /var/lib/etcd \
  --initial-advertise-peer-urls https://192.168.1.83:2380 \
  --listen-peer-urls https://192.168.1.83:2380 \
  --listen-client-urls https://192.168.1.83:2379,https://127.0.0.1:2379 \
  --advertise-client-urls https://192.168.1.83:2379 \
  --initial-cluster-token etcd-cluster-1 \
  --initial-cluster etcd01=https://192.168.1.83:2380,etcd02=https://192.168.1.84:2380,etcd03=https://192.168.1.85:2380 \
  --initial-cluster-state new \
  --cert-file=/etc/kubernetes/pki/etcd/server.pem \
  --key-file=/etc/kubernetes/pki/etcd/server-key.pem \
  --client-cert-auth \
  --trusted-ca-file=/etc/kubernetes/pki/etcd/ca.pem \
  --peer-cert-file=/etc/kubernetes/pki/etcd/peer.pem \
  --peer-key-file=/etc/kubernetes/pki/etcd/peer-key.pem \
  --peer-client-cert-auth \
  --peer-trusted-ca-file=/etc/kubernetes/pki/etcd/ca.pem

[Install]
WantedBy=multi-user.target

Para el nodo 2:

/etc/systemd/system/etcd.servicedownload

[Unit]
Description=etcd
Documentation=https://github.com/coreos/etcd
Conflicts=etcd.service
Conflicts=etcd2.service

[Service]
EnvironmentFile=/etc/etcd.env
Type=notify
Restart=always
RestartSec=5s
LimitNOFILE=40000
TimeoutStartSec=0

ExecStart=/usr/local/bin/etcd \
  --name etcd02 \
  --data-dir /var/lib/etcd \
  --initial-advertise-peer-urls https://192.168.1.84:2380 \
  --listen-peer-urls https://192.168.1.84:2380 \
  --listen-client-urls https://192.168.1.84:2379,https://127.0.0.1:2379 \
  --advertise-client-urls https://192.168.1.84:2379 \
  --initial-cluster-token etcd-cluster-1 \
  --initial-cluster etcd01=https://192.168.1.83:2380,etcd02=https://192.168.1.84:2380,etcd03=https://192.168.1.85:2380 \
  --initial-cluster-state new \
  --cert-file=/etc/kubernetes/pki/etcd/server.pem \
  --key-file=/etc/kubernetes/pki/etcd/server-key.pem \
  --client-cert-auth \
  --trusted-ca-file=/etc/kubernetes/pki/etcd/ca.pem \
  --peer-cert-file=/etc/kubernetes/pki/etcd/peer.pem \
  --peer-key-file=/etc/kubernetes/pki/etcd/peer-key.pem \
  --peer-client-cert-auth \
  --peer-trusted-ca-file=/etc/kubernetes/pki/etcd/ca.pem

[Install]
WantedBy=multi-user.target

Para el nodo 3:

/etc/systemd/system/etcd.servicedownload

[Unit]
Description=etcd
Documentation=https://github.com/coreos/etcd
Conflicts=etcd.service
Conflicts=etcd2.service

[Service]
EnvironmentFile=/etc/etcd.env
Type=notify
Restart=always
RestartSec=5s
LimitNOFILE=40000
TimeoutStartSec=0

ExecStart=/usr/local/bin/etcd \
  --name etcd03 \
  --data-dir /var/lib/etcd \
  --initial-advertise-peer-urls https://192.168.1.85:2380 \
  --listen-peer-urls https://192.168.1.85:2380 \
  --listen-client-urls https://192.168.1.85:2379,https://127.0.0.1:2379 \
  --advertise-client-urls https://192.168.1.85:2379 \
  --initial-cluster-token etcd-cluster-1 \
  --initial-cluster etcd01=https://192.168.1.83:2380,etcd02=https://192.168.1.84:2380,etcd03=https://192.168.1.85:2380 \
  --initial-cluster-state new \
  --cert-file=/etc/kubernetes/pki/etcd/server.pem \
  --key-file=/etc/kubernetes/pki/etcd/server-key.pem \
  --client-cert-auth \
  --trusted-ca-file=/etc/kubernetes/pki/etcd/ca.pem \
  --peer-cert-file=/etc/kubernetes/pki/etcd/peer.pem \
  --peer-key-file=/etc/kubernetes/pki/etcd/peer-key.pem \
  --peer-client-cert-auth \
  --peer-trusted-ca-file=/etc/kubernetes/pki/etcd/ca.pem

[Install]
WantedBy=multi-user.target

Ya solo nos queda reiniciar el demonio de systemd de cada nodo para que lea el archivo que acabamos de crear:

$ sudo systemctl daemon-reload

Y ahora ya podemos gestionar el demonio de etcd con el comando systemctl o con service, por lo que vamos a levantar el proceso y a configurarlo para que se inicie automáticamente al arrancar el servidor:

$ sudo systemctl enable etcd
$ sudo systemctl start etcd

Si todo ha ido bien, ahora mismo ya tendremos el servicio de etcd levantado, por lo que hacemos lo mismo en los otros 2 nodos.

Si es la primera vez que estas levantando el servicio, hay veces en las que al invocar a systemctl se queda el proceso esperando eternamente (hasta que salta el más-que-generoso-timeout(TM), me refiero). La mayoría de las veces se debe a que el proceso se demonio de etcd se inicia correctamente, pero se queda intentando conectarse con los otros 2 nodos del cluster, por lo que si aún no los hemos levantado, el proceso lo reintenta indefinidamente y parece que se queda congelado...

En estos casos, puesto que el proceso se levanta correctamente, o bien sales con CTRL + C, o bien levantas los demonios en los otros 2 nodos.

Puedes comprobar si el servicio se ha levantado correctamente con:

$ sudo systemctl status etcd
- etcd.service - etcd
   Loaded: loaded (/etc/systemd/system/etcd.service; enabled; vendor preset: enabled)
   Active: active (running) since Tue 2018-05-06 00:21:53 CEST; 11s ago
     Docs: https://github.com/coreos/etcd
 Main PID: 9426 (etcd)
    Tasks: 18 (limit: 4915)
   Memory: 10.1M
      CPU: 145ms
   CGroup: /system.slice/etcd.service
           └─9426 /usr/local/bin/etcd --name etcd01 --data-dir /var/lib/etcd --initial-advertise-peer-urls https://192.168.1.83:2380 --listen-peer-urls https://192.168.1.83:2380 --listen-client-urls https://192.168.1.83:2379,https://127.0.0.1:2379 --advertise-client-urls

May 06 00:21:53 etcd01 etcd[20483]: established a TCP streaming connection with peer c37956d0928a73d9 (stream Message reader)
May 06 00:21:53 etcd01 etcd[20483]: established a TCP streaming connection with peer c37956d0928a73d9 (stream MsgApp v2 reader)
May 06 00:21:53 etcd01 etcd[20483]: raft.node: 1e9f81657a2688f9 elected leader b5a3b7906f500074 at term 1291
May 06 00:21:53 etcd01 etcd[20483]: 1e9f81657a2688f9 initialzed peer connection; fast-forwarding 8 ticks (election ticks 10) with 2 active peer(s)
May 06 00:21:53 etcd01 etcd[20483]: published {Name:etcd01 ClientURLs:["https://192.168.1.83:2379"]} to cluster e47a206dc7abb150
May 06 00:21:53 etcd01 etcd[20483]: ready to serve client requests
May 06 00:21:53 etcd01 etcd[20483]: ready to serve client requests
May 06 00:21:53 etcd01 systemd[1]: Started etcd.
May 06 00:21:53 etcd01 etcd[20483]: serving client requests on 127.0.0.1:2379
May 06 00:21:53 etcd01 etcd[20483]: serving client requests on 192.168.1.83:2379

Esto significa que ya tenemos nuestro cluster funcionando y aceptando conexiones por el puerto 2379!

Administración básica

Ahora que ya tenemos el cluster funcionando, vamos a ver algunos comandos que nos serán de utilidad a la hora de administrar el cluster, comprobar su estado, añadir un nuevo nodo, etc.

Recuerda que hemos configurado nuestro cluster para usar SSL en cualquier conexión, por lo que necesitaremos el certificado de cliente en cualquier sitio desde el que nos queramos conectar al cluster.

Al servidor etcd se accede utilizando la API, como ya expliqué al principio del artículo, pero existe una utilidad llamada etcdctl que nos permite acceder a dicha API desde la linea de comandos. Vamos a ver sus opciones, pero antes tenemos que establecer la variable de sesión ETCDCTL_API=3 ya que de lo contrario la utilidad nos mostrará opciones obsoletas (luego explicaré el tema de las variables de sesión):

$ export ETCDCTL_API=3
$ etcdctl --help
NAME:
    etcdctl - A simple command line client for etcd3.

USAGE:
    etcdctl

VERSION:
    3.3.4

API VERSION:
    3.3


COMMANDS:
    get         Gets the key or a range of keys
    put         Puts the given key into the store
    del         Removes the specified key or range of keys [key, range_end)
    txn         Txn processes all the requests in one transaction
    compaction      Compacts the event history in etcd
    alarm disarm        Disarms all alarms
    alarm list      Lists all alarms
    defrag          Defragments the storage of the etcd members with given endpoints
    endpoint health     Checks the healthiness of endpoints specified in `--endpoints` flag
    endpoint status     Prints out the status of endpoints specified in `--endpoints` flag
    endpoint hashkv     Prints the KV history hash for each endpoint in --endpoints
    move-leader     Transfers leadership to another etcd cluster member.
    watch           Watches events stream on keys or prefixes
    version         Prints the version of etcdctl
    lease grant     Creates leases
    lease revoke        Revokes leases
    lease timetolive    Get lease information
    lease list      List all active leases
    lease keep-alive    Keeps leases alive (renew)
    member add      Adds a member into the cluster
    member remove       Removes a member from the cluster
    member update       Updates a member in the cluster
    member list     Lists all members in the cluster
    snapshot save       Stores an etcd node backend snapshot to a given file
    snapshot restore    Restores an etcd member snapshot to an etcd directory
    snapshot status     Gets backend snapshot status of a given file
    make-mirror     Makes a mirror at the destination etcd cluster
    migrate         Migrates keys in a v2 store to a mvcc store
    lock            Acquires a named lock
    elect           Observes and participates in leader election
    auth enable     Enables authentication
    auth disable        Disables authentication
    user add        Adds a new user
    user delete     Deletes a user
    user get        Gets detailed information of a user
    user list       Lists all users
    user passwd     Changes password of user
    user grant-role     Grants a role to a user
    user revoke-role    Revokes a role from a user
    role add        Adds a new role
    role delete     Deletes a role
    role get        Gets detailed information of a role
    role list       Lists all roles
    role grant-permission   Grants a key to a role
    role revoke-permission  Revokes a key from a role
    check perf      Check the performance of the etcd cluster
    help            Help about any command

OPTIONS:
      --cacert=""               verify certificates of TLS-enabled secure servers using this CA bundle
      --cert=""                 identify secure client using this TLS certificate file
      --command-timeout=5s          timeout for short running command (excluding dial timeout)
      --debug[=false]               enable client-side debug logging
      --dial-timeout=2s             dial timeout for client connections
  -d, --discovery-srv=""            domain name to query for SRV records describing cluster endpoints
      --endpoints=[127.0.0.1:2379]      gRPC endpoints
      --hex[=false]             print byte strings as hex encoded strings
      --insecure-discovery[=true]       accept insecure SRV records describing cluster endpoints
      --insecure-skip-tls-verify[=false]    skip server certificate verification
      --insecure-transport[=true]       disable transport security for client connections
      --keepalive-time=2s           keepalive time for client connections
      --keepalive-timeout=6s            keepalive timeout for client connections
      --key=""                  identify secure client using this TLS key file
      --user=""                 username[:password] for authentication (prompt if password is not supplied)
  -w, --write-out="simple"          set the output format (fields, json, protobuf, simple, table)

Como puedes ver este comando tiene bastantes parámetros, por lo que vamos a echar un ojo a los más importantes:

--endpoints: Aqui debemos especificar todos los nodos de nuestro cluster (host y puerto) separados por comas, de forma que si uno de ellos estuviera caído nuestra consulta sería enviada de forma automática a otro de los nodos. Por ejemplo, en nuestro caso sería: https://etcd01:2379,https://etcd02:2379,https://etcd03:2379.
--cert: La ruta del certificado de cliente que vamos a utilizar para conectarnos. En nuestro caso sería: /etc/kubernetes/pki/etcd/client.pem.
--key: La ruta de la clave del certificado de cliente. En nuestro caso sería: /etc/kubernetes/pki/etcd/client-key.pem.
--cacert: La ruta hacia la entidad certificadora con la que hemos generado los certificados. En nuestro caso sería: /etc/kubernetes/pki/etcd/ca.pem.
--write-out: Aqui indicamos cómo queremos que nos devuelva al respuesta del comando que vamos a lanzar al cluster. Puede ser simple, json, table, etc.
--debug: Con esta opción podemos ver las llamadas HTTP/HTTPS que se estan lanzando a la API del cluster para ejecutar el comando que vayamos a ejecutar. Muy util para depurar el proceso si tenemos algún problema con los datos que estamos obteniendo.

Por comodidad, tener que estar introduciendo las rutas de todos los certificados y la lista de endpoints cada vez que lancemos un comando puede resultar una auténtica tortura. Por suerte, podemos definir una serie de variables de entorno que una vez definidas permitirán a etcdctl conocer el valor de todos estos parámetros sin que tengamos que estar tecleándolos constantemente. Estas variables son:

ETCDCTL_CERT: La ruta que pondríamos en el parámetro --cert-file.
ETCDCTL_KEY: La ruta que pondríamos en el parámetro --key-file.
ETCDCTL_CACERT: La ruta que pondríamos en el parámetro --ca-file.
ETCDCTL_ENDPOINTS: La lista (separada por comas) de endpoints (host y puerto) de nuestro cluster.
ETCDCTL_API: Versión de la API que queramos utilizar. Puede ser 2 o 3.

Una vez que hemos visto los parámetros, vamos con algunos de los comandos disponibles:

get: Devuelve el valor de una clave.
put: Establece el valor de una clave.
endpoint health: Muestra el estado de los nodos del cluster.
check perf: Realiza un informe de rendimiento del cluster.
Etc... (esta vez me refiero a etcétera, no al nombre del programa del que estamos hablando xDDD)

Vamos a probar alguno de ellos...

Nos conectamos a cualquiera de los nodos (por ejemplo al primero: etcd01) y definimos las variables de sesión con los valores necesarios para no tener que preocuparnos de ellos en cada ejecución del comando etcdctl:

$ export ETCDCTL_CERT=/etc/kubernetes/pki/etcd/client.pem
$ export ETCDCTL_KEY=/etc/kubernetes/pki/etcd/client-key.pem
$ export ETCDCTL_CACERT=/etc/kubernetes/pki/etcd/ca.pem
$ export ETCDCTL_ENDPOINTS=https://etcd01:2379,https://etcd02:2379,https://etcd03:2379
$ export ETCDCTL_API=3

Ahora vamos a lanzar el comando endpoint health para ver la salud de nuestro recién creado cluster:

$ etcdctl endpoint health
https://etcd02:2379 is healthy: successfully committed proposal: took = 2.397419ms
https://etcd01:2379 is healthy: successfully committed proposal: took = 1.535434ms
https://etcd03:2379 is healthy: successfully committed proposal: took = 2.331939ms

Que indica que los 3 nodos estan funcionando correctamente (...is healthy).

Si en lugar del resultado os muestra algún error relacionado con los certificados significa que no habeis puesto bien las rutas de las variables de sesión, o que vuestro usuario no tiene permiso para leer dichos archivos.

Ahora vamos a introducir una clave de prueba y su valor. Por ejemplo:

$ etcdctl put clavePrueba "Esto es una prueba"

Leemos el valor de la clave clavePrueba:

$ etcdctl get clavePrueba
Esto es una prueba

Vamos ahora con algo más delicado: gestionar nuevos nodos. Supongamos que queremos añadir un nuevo nodo a nuestro cluster. Por comodidad y para matar dos pájaros de un tiro vamos primero a quitar uno de los nodos del cluster y luego lo volveremos a meter.

Con el comando member list vemos la lista de nodos que componen nuestro cluster, y el ID de cada uno de ellos:

$ etcdctl member list
b5a3b7906f500074, started, etcd01, https://192.168.1.83:2380, https://192.168.1.83:2379
c37956d0928a73d9, started, etcd02, https://192.168.1.84:2380, https://192.168.1.84:2379
1e9f81657a2688f9, started, etcd03, https://192.168.1.85:2380, https://192.168.1.85:2379

Para eliminar uno de ellos, por ejemplo el nodo 3 (etcd03), ejecutamos el comando member remove indicando el ID del nodo que queremos eliminar de nuestro cluster:

$ etcdctl member remove 1e9f81657a2688f9
Member 1e9f81657a2688f9 removed from cluster e47a206dc7abb150

Si volvemos a obtener la lista de nodos del cluster veremos que ya solo tenemos 2:

$ etcdctl member list
b5a3b7906f500074, started, etcd01, https://192.168.1.83:2380, https://192.168.1.83:2379
c37956d0928a73d9, started, etcd02, https://192.168.1.84:2380, https://192.168.1.84:2379

El procedimiento para añadir un nodo es tambien muy sencillo, pero si el nodo que queremos añadir ya ha formado parte de un cluster etcd anteriormente (como es nuestro caso ya que lo acabamos de eliminar ahora mismo) hay que hacer un par de cosas antes:

Detener el servicio de etcd en el nuevo nodo que queremos añadir: $ sudo systemctl stop etcd.
Eliminar el directorio donde se guardan los datos de etcd para que al añadirlo al cluster se sincronice de nuevo con el resto de nodos: $ sudo rm -rf /var/lib/etcd/member.

Una vez hecho esto, ya podemos continuar con el proceso para añadirlo a nuestro cluster.

Ejecutamos el comando member add junto con el nombre y el endpoint de peer del nuevo nodo que queremos añadir:

$ etcdctl member add etcd03 --peer-urls="https://192.168.1.85:2380"
Member c398e05912695024 added to cluster e47a206dc7abb150
ETCD_NAME="etcd03"
ETCD_INITIAL_CLUSTER="etcd01=https://192.168.1.83:2380,etcd02=https://192.168.1.84:2380,etcd03=https://192.168.1.85:2380"
ETCD_INITIAL_ADVERTISE_PEER_URLS="https://192.168.1.85:2380"
ETCD_INITIAL_CLUSTER_STATE="existing"

El comando muestra los datos del nuevo nodo que hemos añadido (nombre, endpoints, etc) así como su estado actual, que es existing. Esto significa que aunque el nodo se ha añadido al cluster, aún no está operativo. Podemos verlo si de nuevo volvemos a pedir el listado de nodos:

$ etcdctl member list
b5a3b7906f500074, started, etcd01, https://192.168.1.83:2380, https://192.168.1.83:2379
c37956d0928a73d9, started, etcd02, https://192.168.1.84:2380, https://192.168.1.84:2379
c398e05912695024, unstarted, , https://192.168.1.85:2380,

Como ves, el nuevo nodo está unstarted, por lo que aún no está funcionando (como es lógico).

Para iniciarlo, nos conectamos a dicho nodo y editamos el archivo de configuración de systemctl del etcd (el archivo /etc/systemd/system/etcd.service que creamos cuando estábamos configurando el cluster). Tenemos que sustituir la linea --initial-cluster-state new por --initial-cluster-state existing, por lo que el archivo quedaría así:

/etc/systemd/system/etcd.servicedownload

[Unit]
Description=etcd
Documentation=https://github.com/coreos/etcd
Conflicts=etcd.service
Conflicts=etcd2.service

[Service]
EnvironmentFile=/etc/etcd.env
Type=notify
Restart=always
RestartSec=5s
LimitNOFILE=40000
TimeoutStartSec=0

ExecStart=/usr/local/bin/etcd \
  --name etcd03 \
  --data-dir /var/lib/etcd \
  --initial-advertise-peer-urls https://192.168.1.85:2380 \
  --listen-peer-urls https://192.168.1.85:2380 \
  --listen-client-urls https://192.168.1.85:2379,https://127.0.0.1:2379 \
  --advertise-client-urls https://192.168.1.85:2379 \
  --initial-cluster-token etcd-cluster-1 \
  --initial-cluster etcd01=https://192.168.1.83:2380,etcd02=https://192.168.1.84:2380,etcd03=https://192.168.1.85:2380 \
  --initial-cluster-state existing \
  --cert-file=/etc/kubernetes/pki/etcd/server.pem \
  --key-file=/etc/kubernetes/pki/etcd/server-key.pem \
  --client-cert-auth \
  --trusted-ca-file=/etc/kubernetes/pki/etcd/ca.pem \
  --peer-cert-file=/etc/kubernetes/pki/etcd/peer.pem \
  --peer-key-file=/etc/kubernetes/pki/etcd/peer-key.pem \
  --peer-client-cert-auth \
  --peer-trusted-ca-file=/etc/kubernetes/pki/etcd/ca.pem

[Install]
WantedBy=multi-user.target

Recargamos la configuración de systemctl e iniciamos el servicio de etcd:

$ sudo systemctl daemon-reload
$ sudo systemctl start etcd

Al cabo de unos pocos segundos (dependiendo del tamaño de la base de datos de etcd que tengamos en nuestro cluster), el nuevo nodo se habrá sincronizado y si pedimos de nuevo la lista de nodos tendríamos que ver que el nuevo nodo ya está funcionando como los demás:

$ etcdctl member list
b5a3b7906f500074, started, etcd01, https://192.168.1.83:2380, https://192.168.1.83:2379
c37956d0928a73d9, started, etcd02, https://192.168.1.84:2380, https://192.168.1.84:2379
736e5742db963896, started, etcd03, https://192.168.1.85:2380, https://192.168.1.85:2379

Por coherencia con el resto de nodos, yo recomiendo que una vez se ha añadido el nuevo nodo al cluster y todo está funcionando, editemos de nuevo el archivo /etc/systemd/system/etcd.service y volvamos a cambiar el --initial-cluster-state existing por --initial-cluster-state new para dejarlo como estaba (igual que en el resto de nodos) pero realmente daría igual ya que una vez iniciado el servicio por primera vez, ese parámetro ya no se vuelve a tener en cuenta.

Bueno, pues ya tenemos el cluster otra vez completo, ¿pero cómo sabemos que realmente esta funcionando en alta disponibilidad, y va a seguir haciéndolo aunque alguno de sus nodos se quede fuera de servicio? Vamos a comprobarlo:

Detenemos el servicio de etcd en el nodo 1 (etcd01):

$ sudo systemctl stop etcd

Y volvemos a preguntar por el valor de la clave que guardamos antes:

$ etcdctl get clavePrueba
Esto es una prueba

Como ves, obtenemos el valor de la clave sin problemas aún con el nodo 1 fuera de servicio.

Ahora, levantamos de nuevo el servicio etcd en el nodo 1, lo detenemos el nodo 2 y volvemos a preguntar por la clave (es importante que ANTES de detener el nodo 2 vuelvas a iniciar el nodo 1, ya que un cluster de 3 nodos puede sobrevivir si falla 1 nodo, pero no si fallan 2):

$ etcdctl get clavePrueba
Esto es una prueba

De nuevo sigue funcionando... así que vamos con la última prueba: levantamos de nuevo el servicio etcd en el nodo 2, lo detenemos en el nodo 3 y volvemos a preguntar por la clave:

$ etcdctl get clavePrueba
Esto es una prueba

Como ves, el cluster sigue funcionando aunque cualquiera de sus nodos deje de hacerlo.

Ya tienes tu cluster montado y funcionado, así que ya puedes empezar a utilizarlo sin problemas!

Como siempre, espero que el artículo os haya resultado de utilidad! Y por supuesto, no dudéis en distribuirlo y compartirlo con todo el mundo (pero por favor, citad siempre la fuente original de éste artículo).

Alaaaaaaaaaaaaaaaaaaaaaaa!

Referencias

Implementa tests en tus roles de Ansible con Molecule

BhEaN — Mon, 12 Mar 2018 16:12:40 +0100

Hoy en dia nadie concibe (o nadie debería concebir, mejor dicho) empezar un proyecto de programación sin sus correspondientes tests. Tranquilidad en el desarrollo, código más robusto, anticiparnos a los errores, etc. son algunas de las maravillas que nos ofrece el mundo del testing, así que si tiene tantas ventajas... ¿porqué no íbamos a aplicarlo también a otros ámbitos que no sean exclusivamente los de la programación?

Ansible es una de esas herramientas indispensables para cualquiera que administre servidores, automatizando la instalación de nuevos servicios, el despliegue de aplicaciones, configuraciones, etc. permitiendo que llevemos a cabo todas esas tareas de forma sencilla, rápida y automatizada ya sea en un servidor, en diez o en miles de ellos mediante la creación de roles.

En este artículo voy a explicar cómo implementar el framework Molecule en dichos roles para poder testear su sintaxis, su idempotencia (me encanta esta palabra) y su ejecución en diferentes instancias con diferentes sistemas operativos y configuraciones.

Correcta instalación de Java en Debian mediante paquetes DEB

BhEaN — Sun, 12 Nov 2017 15:58:52 +0100

Hay muchas formas de instalar diferentes versiones de Java en nuestros sistemas: en la propia web de Oracle (que como todos sabéis, es el propietario de Java desde hace varios años) podemos descargar diferentes versiones (9, 8, 7, ...), en diferentes formatos (comprimido con tar.gz, paquetes para CentOS/RedHat, ejecutables binarios, ...) y para diferentes sistemas operativos (Linux, MacOS, Windows y SPARC).

Incluso hay repositorios no-oficiales que ponen a disposición de todo el mundo los paquetes de instalación de Java en otros formatos, por lo que a simple vista cualquiera diría que existiendo tanta variedad incluso nosotros (fieles y exigentes defensores de Debian y de la mantenibilidad de los sistemas) estaríamos contentos, verdad?

Pues va a ser que no...

Firmando emails con OpenDKIM

BhEaN — Fri, 10 Nov 2017 23:50:06 +0100

El SPAM es una de las mayores lacras que inundan Internet desde el principio de su creación. Genera cien veces más pérdidas a la sociedad que beneficio a sus creadores y supone el 84% de los emails que recibimos. Y este mal existe, entre otras cosas, porque el sistema de correo electrónico de Internet se diseñó dando por hecho que toda la gente que lo iba a utilizar lo haría de buena fe: craso error.

Pensar que nadie iba a utilizar el correo electrónico para hacer cosas malas hizo que se diseñara, entre otras muchas cosas, sin ningún sistema que garantice a quien los recibe que dichos mensajes no han sido manipulados por el camino o escritos por remitentes falsos.

Por estos motivos, Internet lleva años desarrollando herramientas y sistemas que ayuden a paliar los problemas de diseño que el correo electrónico tiene de base.

DKIM es uno de estos mecanismos, y permite a los destinatarios de un mensaje de correo electrónico saber si un email ha sido realmente enviado por el remitente y no por alguien haciéndose pasar por él (esta práctica se denomina mail spoofing).

Integración Continua en Pelican usando Gitlab-CI

BhEaN — Mon, 24 Apr 2017 22:08:25 +0100

A estas alturas no creo que haya nadie (o casi nadie) en este mundillo que todavía no sepa qué es la integración continua, sin embargo la inmensa mayoría no lo utiliza aún en sus proyectos.

Hay muchas excusas para justificar este hecho, como por ejemplo que "es un proyecto pequeño", o que "es un proyecto personal en el que solo trabajo yo", o que "el proyecto tiene unos plazos muy ajustados y no hay tiempo para más ~~tonterías~~ desarrollos", o incluso que "no merece la pena el esfuerzo extra que hay que dedicarle"... pero ninguna de ellas es válida, así que si alguna vez en tu vida has usado alguna de estas excusas para no utilizar un sistema de integración continua, eres un merluzo, compañero... pero no temas, que eso va a cambiar hoy...

Adios Octopress, hola Pelican!

BhEaN — Thu, 23 Mar 2017 23:24:54 +0100

Efectivamente, ha llegado la hora de enterrar a nuestro antiguo Octopress y dar la bienvenida al nuevo Pelican. Y no solo porque este último esté hecho en Python (que me gusta mil veces más que Ruby, todo sea dicho) sino porque estoy más que harto de esperar la maldita versión 3 de Octopress desde hace literalmente más de 2 años, y no solo no ha salido aún (de hecho, ha pasado más de 1 año desde el último commit que hicieron en cualquiera de las ramas de su repositorio de Github) sino que además sus desarrolladores han anunciado que ésta nueva versión NO es compatible con las anteriores, por lo que ni siquiera puedo migrar el blog. Tendría que hacerlo de nuevo desde cero (incluyendo los plugins que he hecho, el theme, etc).

Así que como se suele decir: Con Octopress, va a ser que no...

Accede a tu biblioteca multimedia (audio y video) desde cualquier parte con Ampache

BhEaN — Mon, 28 Dec 2015 17:13:04 +0100

Según la definición que aparece en Wikipedia, Ampache es un administrador de archivos y servidor de streaming multimedia que se ejecuta sobre un servidor web. Es decir, un software que os permitirá mantener organizada vuestra biblioteca multimedia (generalmente música y películas) y que os permitirá reproducir dicha biblioteca desde un navegador, un smartphone, una tablet, etc.

Empresas como Spotify, Deezer, Jamendo, los asquerosos de Google Play Music o la recién llegada Apple Music (entre muchas otras) ofrecen casi toda la música del mundo a solo un par de clicks de distancia, y como cada vez hay más competencia en este tipo de servicios de audio en streaming, todas ellas se esfuerzan en mejorar la calidad de sus servicios, aumentar su catálogo y mejorar sus cada vez más atractivos precios de suscripción.

¿Porqué montar entonces un servicio propio de streaming? Intentaré explicarlo para que incluso tu, insignificante humano, lo entiendas...

Creación de un bot de Telegram en PHP

BhEaN — Wed, 12 Aug 2015 19:48:53 +0200

Siempre defiendo que Telegram es la mejor app de mensajería que existe a día de hoy, no solo porque de verdad se preocupen por la seguridad y privacidad de las comunicaciones de sus usuarios (no como otros), ni por la calidad de sus apps frente a las de sus competidores, sino porque entre muchas otras cosas, mantienen un ritmo muy alto de actualizaciones que hacen que cada poco tiempo tengamos disponibles nuevas versiones con nuevas y mejores funcionalidades.

En este artículo hablaré de una de sus últimas funcionalidades, concretamente de la API que la gente de Telegram ha liberado para su uso público, y que permite a cualquier programador crear bots para interactuar con otros usuarios a través de conversaciones de Telegram.

Y no solo a programadores, sino que gracias a algunas herramientas (como por ejemplo paquebot.io) cualquier persona con un mínimo de interés y ganas de trastear un poco puede hacerlo.

Pero esto es un blog técnico, no una web de noticias para lusers, así que déjate de asistentes, GUIs y demás mariconadas y vamos a programar...

LCARS: el sistema operativo de la Flota Estelar

BhEaN — Thu, 02 Jul 2015 23:03:45 +0200

Hace tiempo que quería escribir este artículo, sobre todo porque se dice que hay gente por ahí que no saben qué es LCARS (si, lo se... es alucinante.. yo tampoco me lo creía) y como a mi siempre me ha parecido un tema curioso, a partir de ahora cuando hable de este tema con alguien que no lo conozca me resultará mucho más fácil enviarle el enlace a éste artículo que tener que explicar una y otra vez de qué va ésto.

Antes de seguir, y sobre todo si eres una de esas personas (por llamarte de alguna forma) que no ha oido nunca hablar de LCARS, quiero dejar claro que éste artículo no trata de tecnología real, ni de un nuevo sistema operativo, ni de ninguna nueva plataforma de desarrollo asombrosa para que la implementes en tus proyectos.

LCARS NO EXISTE, es pura fantasía, y solo un pequeño e inocente niño pensaría que realmente existe más allá de la imaginación de algunos (al igual que los Reyes Magos, el Ratoncito Pérez o la política de empleo de Mariano Rajoy.

Teclados mecánicos: ¿a qué esperas para comprarte uno?

BhEaN — Sun, 15 Mar 2015 00:58:48 +0100

La inmensa mayoría de las personas que utilizan un ordenador a diario utilizan teclados de membrana, y la inmensa mayoría de ellos ni siquiera saben de la existencia de otros tipos de teclados.

En éste artículo explicaré las características más representativas de los teclados mecánicos, los diferentes tipos de mecanismos de teclas que existen para éstos teclados y en definitiva, todas las sensaciones que aporta el uso de uno de éstos teclados.

Y es que al contrario de lo que piensa la mayoría, estos teclados no solo para gamers, sino para cualquier persona o político que utilice un ordenador habitualmente..

Solo existen 2 tipos de personas en el mundo: los que adoran los teclados mecánicos, y los que aún no los han probado.

Instalación y configuración de un servidor de correo completo en Linux

BhEaN — Thu, 01 Jan 2015 11:03:39 +0200

Uno de los servicios más importantes de Internet es sin duda el correo electrónico, y al igual que con muchos otros servicios, no hay nada que gestione mejor el correo que GNU/Linux.

Hay muchos proyectos conocidísimos y de gran importancia en el mundo de GNU/Linux, como por ejemplo el servidor web Apache, las bases de datos MySQL y PostgreSQL, el servidor de nombres Bind y muchísimos más... pero hay 2 de estos grandísimos proyectos que no suelen ser tan conocidos para el ciudadano de a pié, y sin embargo son una parte fundamental de Internet. Me estoy refiriendo a Postfix y a Courier, la pareja perfecta para hacerse cargo de algo tan importante hoy en dìa como es el correo electrónico.

Y es que la combinación de estos 2 sistemas no solo funciona, sino que además lo hace increíblemente bien.

Inicio automático de máquinas virtuales con XenServer

BhEaN — Wed, 24 Dec 2014 12:04:34 +0200

Cuando se habla de virtualización a nivel usuario, la mayoría de la gente piensa en Virtualbox (que es una genial aplicación), y cuando se habla de virtualización a nivel empresarial, el software en el que casi todo el mundo piensa es VMWare.

Ambos son grandísimos productos, maduros y estables... pero desde que probé XenServer, éste genial sistema de virtualización de la empresa Citrix es el que más me gusta.

XenServer es (al igual que el resto de productos de Citrix) un software cerrado y de pago, pero también existe una version gratuita que se puede usar libremente en entornos de producción empresarial. Ésta versión gratuita únicamente tiene algunas limitaciones con respecto a la versión de pago, y una de ellas es precisamente la de configurar las máquinas virtuales para que se inicien automáticamente cuando se inicia el servidor.

Promoción de Navidad de Leroy Merlin: Un buen ejemplo de como NO hacer las cosas

BhEaN — Thu, 11 Dec 2014 20:57:54 +0100

Dice mi mujer que cada vez tengo peor carácter, y que al final me acabaré convirtiendo en el típico viejo amargado que protesta por todo... y quizás tenga razón, pero no puedo evitarlo: no soporto la chulería ni los malos modales de la gente, y menos aún cuando no solo NO tienen razón sino que además se supone que deberían ser amables con sus propios clientes.

Pero empecemos desde el principio: os voy a contar la breve historia de lo que me sucedió la semana pasada con ésta conocida cadena de herramientas y bricolaje, y de cómo conseguí lo que me correspondía usando nuestra Querida Tecnología(TM).

Modificar el espacio reservado en particiones con sistemas de archivos ext3 o ext4

BhEaN — Mon, 08 Dec 2014 00:23:20 +0100

Si llevais algun tiempo usando GNU/Linux y sois mínimamente observadores, habreis notado que siempre que montais un nuevo disco y lo formateais utilizando ext3 o ext4 como sistema de archivos, nunca se obtiene el 100% de la capacidad del disco.

Ésto se debe a que éstos sistemas de archivos reservan por defecto un 5% de la capacidad total del disco para uso del usuario root (para que en caso de llenar por completo el disco, todavía podamos acceder y realizar tareas de administración) y para prevenir problemas derivados de la fragmentación de archivos.

Y hace años, cuando el tamaño de los discos duros era ínfimo (comparado con el tamaño actual, quiero decir) éste valor podía tener sentido... pero hoy en dia, teniendo discos SATA de hasta 6 TB, reservar un 5% es una salvajada que solo serviría para perder 300 GB!

Telegram: aún hay esperanza para las apps de mensajería

BhEaN — Tue, 18 Nov 2014 20:57:44 +0100

Por si implementar un robusto protocolo de encriptación, tener una app para casi todos los sistemas operativos móviles mayoritarios que existen, haber publicado su código fuente, disponer de una API pública para que cualquier desarrollador pueda integrar Telegram en sus programas o haber garantizado desde el primer momento que su sistema será gratis y libre de publicidad para siempre no fueran argumentos suficientes como para erigir a Telegram como la mejor aplicación de mensajería instantánea que existe hoy en día, ahora van y sacan aplicaciones de escritorio para Linux y Mac!! (vaaaaale, para Windows también... pero a quién le importa ésto último?)

Y nada de webapps (aunque si quieres, también las tiene) sino que se trata de aplicaciones nativas para cada sistema operativo (cuyo código fuente, además, también han publicado).

POODLE: En qué consiste esta vulnerabilidad del protocolo SSL y qué hacer para evitarla

BhEaN — Mon, 20 Oct 2014 10:34:19 +0200

Ha sido un duro golpe el que ha recibido nuestro querido SSL (concretamente su versión 3.0) con el descubrimiento de ésta vulnerabilidad, ya que no existe una solución de verdad al problema salvo la de no utilizar esa versión en concreto.

Ésta vulnerabilidad no provoca una denegación de servicio (DoS), ni otorga acceso de administración a los servidores vulnerables, ni se puede utilizar para eliminar archivos, sino que permite a un atacante (mediante ataques man in the middle) acceder a la información que se transmite en una conexión que hasta ese momento se pensaba que era segura y privada, sin que los interlocutores de dicha comunicación lo sepan.

jekyll-vimeo-lazyloading: Un nuevo plugin para mostrar videos de Vimeo en Octopress

BhEaN — Sat, 27 Sep 2014 02:13:36 +0200

Lo prometido es deuda... y tal y como comenté en mi artículo sobre plugins para Octopress, finalmente he desarrollado un nuevo plugin para mostrar los videos del genial Vimeo en aquellos blogs basados en Jekyll y Octopress de forma que el reproductor embebido no se cargue hasta que el usuario no haga click en dicho video.

De ésta forma evitamos la carga innecesaria del iframe de Vimeo en aquellas páginas en las que el usuario no está interesado en reproducir los videos que hay en ella.

¿Nunca os ha pasado que al entrar en una página, varios videos (sobre todo del asqueroso Youtube) comienzan a reproducirse automaticamente (con audio incluido), molestandoos no solo a vosotros sino a todos los que os rodean (en caso de tener el volumen activado)?

Diagramas, mapas de red y demás gráficas estructuradas con Graphviz

BhEaN — Thu, 18 Sep 2014 09:53:36 +0200

Hoy voy a hablar de Graphviz, un proyecto que tiene ya unos cuantos años, y que si has ido a la universidad seguramente ya conozcas (al parecer se usa en muchas de ellas).

Para los que no, es algo que os puede resultar muy util a la hora de hacer gráficas relacionales, mapas de red, diagramas de flujo y cualquier otro tipo de representación gráfica similar. Libre, gratuito, facil de usar, potente y se maneja desde la linea de comandos de Linux... es decir, que es uno de esos programas a los que solo les falta tener tetas para ser perfecto...

Graphviz permite generar imágenes (PNG, SVG, GIF, etc) a partir de los datos que definamos mediante texto plano en un archivo, y el resultado no tiene nada que envidiar a algunos de los mejores servicios online de diseño de gráficas de éste tipo (como por ejemplo el genial Gliffy, que esta muy bien y es gratuito para un par de gráficas... pero cuando necesitas hacer más o usar opciones avanzadas, hay que pagar, y no es NADA barato).

Instalación de Raspbian en la Raspberry Pi B+

BhEaN — Fri, 01 Aug 2014 23:35:44 +0200

Si tuviera que decir uno de los inventos que más posibilidades tiene de los últimos años, o el que más horas de diversión puede proporcionar a un coste verdaderamente asequible, sin duda uno de los primeros que se me pasaría por la cabeza sería la genial Raspberry Pi.

Supongo que la mayoría de vosotros, consumidores habituales del pornohardware más variado, obviamente conoceréis este increíble proyecto... pero para aquellos que hayan pasado los últimos años aislados en una cueva sin poder salir o en una isla desierta alimentándose únicamente de cocos y ostras y sin el más mínimo contacto con la civilización, os comentaré a modo de resumen rápido que Raspberry Pi es un ordenador del tamaño de un paquete de tabaco, y que cuesta aproximadamente 35 € (dependiendo del sitio donde la compréis). Esta descripción debería ser suficiente como para que aquellos que no la conocíais sintáis en éste momento la necesidad de tocaros...

A dia de hoy (salen nuevos modelos más potentes y con nuevas funcionalidades cada cierto tiempo) funciona con un procesador ARM a 700MHz (aunque se puede hacer overclocking hasta los 1000MHz), por lo que se puede instalar cualquier distribución de Linux que soporte dicha arquitectura. En nuestro caso, y como no podía ser de otra manera, utilizaremos Raspbian: una Debian adaptada a la Raspberry Pi.

Feliz dia del Administrador de Sistemas!

BhEaN — Fri, 25 Jul 2014 10:49:55 +0200

"Las organizaciones gastan millones de dólares en firewalls y dispositivos de seguridad, pero tiran el dinero porque ninguna de estas medidas cubren el eslabón más débil de la cadena de seguridad: la gente que usa y administra los ordenadores."

Kevin Mitnick. Hacker, cracker, phreaker, leyenda.

Y si no sabes de qué va éste post, échale un ojo a http://sysadminday.com (o a su versión en español).

Búsquedas por similitud de trigramas en PostgreSQL con pg_trgm

BhEaN — Wed, 23 Jul 2014 20:54:53 +0200

Oracle es la leche, eso no creo que haya nadie que pueda negarlo. Sin duda es una de las mejores (si no la mejor) bases de datos del mundo... pero por desgracia para el común de vosotros los humanos, su código es privativo y su precio prohibitivo (y juro que el pareado ha sido espontáneo!).

Pero no desesperéis... no hace falta que recurráis a soluciones inferiores ni nada parecido. Gracias a los Dioses tenemos PostgreSQL, aunque en éste artículo no vamos a hablar de éste genial motor de base de datos, sino de uno de los módulos adicionales que incorpora para realizar búsquedas basandose en la similitud entre los trigramas de una cadena: pg_trgm.

Selección de plugins para Octopress

BhEaN — Sat, 12 Jul 2014 02:29:36 +0200

Ya sea a modo de chuleta para mi mismo sobre los que utilizo en el blog, o bien por si a alguien le resulta útil, voy a escribir en éste artículo la lista de los mejores y más interesantes plugins para Octopress que he encontrado...

Un paseo por el datacenter en el que vivo

BhEaN — Wed, 09 Jul 2014 20:38:17 +0200

Y no, no estoy hablando en sentido metafórico... hoy voy a enseñaros el pequeño datacenter que tengo montado en mi casa, donde ~~mis servidores~~ mis niñas funcionan sin interrupción para dar servicio tanto a mis frikadas como a algunas otras cosas un poco más serias.

Y cuando digo datacenter no me refiero a un par de ordenadores viejos sin monitor en una esquina del dormitorio, como teneis algunos (y vosotros os llamais frikis? debería daros vergüenza!), sino a varios racks con decenas de servidores, SAI's, cabinas de discos duros en RAID, switches redundantes y mil cosas más (como tenemos los frikis de verdad... así que tomar nota!!) xDD

Ha sido un proceso muy largo, y mentiría si dijera que ya ha terminado y que no voy a seguir ampliando la infraestructura de mi datacenter... pero a dia de hoy (mediados de 2014) puedo decir que (por suerte para mi y por desgracia para mi mujer) una de las habitaciones de mi casa tiene ésta pinta:

Markdown, el lenguaje de marcado para texto plano

BhEaN — Wed, 02 Jul 2014 21:23:07 +0200

Cuando vosotros (los humanos) necesitais formatear un texto de forma rápida y sencilla, y además teneis que hacerlo en texto plano, la mayoría intentará hacerlo con HTML (si va a ser interpretado por un navegador web) o incluso con BBCode (si se trata de un post en un foro)... y ambas opciones no estan mal, pero existe otra opción especialmente diseñada para ese fin, que muy pocos conocen y aún menos utilizan: el lenguaje de marcado web Markdown.

Mejorando un poco el SEO de Octopress (o de cualquier web en general)

BhEaN — Thu, 26 Jun 2014 22:22:01 +0200

Se entiende por SEO (Search Engine Optimization) el proceso de mejora de la visibilidad de un sitio web en los resultados de un buscador. Es decir, aquellos mecanismos que utilizamos para que nuestra web aparezca mejor posicionada que las demás en las páginas de resultados de los buscadores.

Hay todo un mundo detrás del SEO, donde la mayoría de las pautas son generales para todos los buscadores, pero donde también se pueden encontrar comportamientos y formas de hacer las cosas únicamente para favorecer los resultados en un buscador en concreto. En cualquier caso, en éste artículo solo nos vamos a centrar en 3 cosas muy concretas que nuestro querido Octopress no hace del todo bien, pero que bastan unos sencillos cambios para solucionarlo.

Replicación de bases de datos PostgreSQL con Slony en CentOS

BhEaN — Tue, 24 Jun 2014 23:02:38 +0200

Slony1 es un software para la replicación de datos entre servidores PostgreSQL, creando clusters formados por un nodo maestro y uno o varios nodos esclavos.

Aunque soy Debianita a muerte, muchas veces me veo obligado a usar otras distribuciones de Linux (sobre todo en el curro), como por ejemplo CentOS. Y puesto que éste artículo lo escribí hace ya varios años como chuleta personal precisamente para el curro, está hecho sobre esa distribución... pero como casi siempre en éstos casos, debería ser perfectamente válido para cualquier otro Linux.

Partimos de la base de que ya tenemos instalados y configurados los servidores de base de datos PostgreSQL en los nodos que vamos a usar.

Es de vital importancia que todos los nodos que van a formar el cluster tengan la misma codificación. Es decir, si vamos a usar UTF8, TODOS los servidores y bases de datos deben estar en UTF8, y si vamos a usar LATIN1, TODOS deben estar en LATIN1. De lo contrario, al inicializar la replicación por primera vez, se comenzaran a copiar algunas tablas, y de repente el proceso parará y empezará de nuevo a copiar la primera tabla, y así sucesivamente en un bucle sin fin, sin que ningun log muestre ninguna pista al respecto, así que hay que tenerlo muy presente antes de empezar.

Instalación y configuración de Octopress en Linux

BhEaN — Fri, 20 Jun 2014 20:33:02 +0200

Voy a intentar explicar de la forma más clara posible cómo instalar y configurar Octopress, un framework Open Source para construir blogs basados en el proyecto Jekyll.

Es un software muy potente que permite crear blogs totalmente estáticos, es decir, una vez configurado, basta con ejecutar un comando para que se nos genere en un directorio toda la escructura de archivos y directorios en texto plano (archivos HTML, JS y CSS) que necesitaremos para nuestro blog.

Estos archivos estáticos estarían listos para servir a través de un servidor web cualquiera, sin necesidad de bases de datos, scripts o lenguajes de programación en el lado del servidor, lo que permite ahorrar muchos recursos, tiempo y por supuesto hardware. De hecho, una vez configurado, bastaría con ejecutar otro comando para que Octopress subiera éstos archivos a nuestro servidor de forma totalmente automática (deploy).

Instalación de Sphinx en Debian y su librería de acceso desde PHP

BhEaN — Mon, 09 Apr 2012 00:59:35 +0200

Sphinx Search es un genial motor de búsqueda Open Source especialmente útil cuando tenemos muchos datos a los que tenemos que acceder de forma rápida.

Su principal virtud es la de crear unos índices conteniendo la información que nosotros le hayamos configurado, que pueden ser accedidos desde nuestros programas (C, PHP, etc) para recuperar la información mucho más rápido que si lo hiciéramos directamente a una base de datos (normalmente se usa como complemento de éstas, cuando la cantidad de información que tenemos en dicha base de datos es demasiado grande y sus propios índices no son todo lo efectivos que nos gustaría).

~~A dia de hoy no existen paquetes precompilados para nuestra querida Debian, por lo que vamos a generarlos nosotros a partir de su código fuente.~~ Ya existen paquetes precompilados para las distribuciones de Linux más importantes, los cuales se pueden descargar desde: http://sphinxsearch.com/downloads/release/

Instalacion y configuración de QNOTIFIER en Debian y CentOS

BhEaN — Thu, 11 Jun 2009 11:39:06 +0200

QNotifier es una aplicación desarrollada en Ruby para monitorizar servidores desde un iPhone / iPad (con avisos push).

Este manual explica la instalacion del servicio qnotifier en cada servidor que queramos monitorizar, por lo que partimos de la base de que ya tenemos la aplicación qnotifier instalada en el iPhone / Pad que vamos a utilizar (aplicación disponible en la App Store).