Instalar NextCloud usando NGINX, PHP-FPM, APCu, Redis y GlusterFS

Aprovechando que he montado un nuevo volumen Raid1 con dos discos duros Hitachi HGST_HTS721010A9E630 en mi servidor personal en Madrid he decidido migrar algunos contenedores desde el viejo volumen en Western Digital, especialmente porque el throughput del nuevo volumen de discos Hitachi es muy superior al volumen con discos Western Digital.

En algunos casos he optado por hacer instalaciones limpias, en lugar de mover el contenedor de volumen; como por ejemplo el contenedor que corre el nodo de NexctCloud en Madrid. Así que he aprovechado la ocasión para documentar el proceso en forma de post.

Algunas Consideraciones previas:

  1. El servicio de NextCloud está clústerizado en los nodos Madrid/Sevilla. Aunque debido a que la línea de Madrid es mucho mejor (300MB/300MB frente a 30MB/3MB), no se hace balanceo; por defecto todo el tráfico es enrutado hacia el nodo de Madrid, por lo que a efectos prácticos el servicio no dispone de alta disponibilidad (se precisa intervención humana para cambiar la DNS).
  2. Las comunicaciones entre los nodos de Madrid y Sevilla tiene lugar a través de un túnel VPN montado con OpenVPN.
  3. La base de datos es un clúster multimaster de MariaDB 10.1 con un nodo en Madrid y otro en Sevilla además de un Árbitro en Madrid para evitar situaciones de split-brain. Lo idóneo sería contar con una tercera ubicación donde colocar el Árbitro, aunque de momento con este sistema no he tenido problemas en 2 años a pesar de tener numerosas caídas, especialmente del nodo de Sevilla.
  4. El clúster multimaster de MariaDB esta alojado en otro contenedor, por lo que solo es necesario permitir el login desde la IP del nuevo contenedor de NextCloud; es decir, este punto no se toca en está entrada.
  5. La replicación a nivel de archivos se consigue a través de GlusterFS, con un brick en Madrid y otro en Sevilla.
  6. Los nodos del GlusterFS corren dentro del propio contenedor de NextCloud. Para evitar la caída del servicio se añadirá un nuevo nodo al clúster de GlusterFS, y una vez el nuevo servidor este configurado, sincronizado y operativo se eliminará el viejo nodo.
  7. Redis se usa como cache local para gestionar los bloqueos transaccionales, es decir, no existe un clúster de Redis por los motivos expuestos en el punto 1.

Convertir certificados en formato PPK (Putty) a certificados en formato OpenSSH

El cliente SSH por excelencia para Windows es PuTTy, el cual usa certificados en formato PPK, esto no es un problema en si mismo pero si un poco engorroso cuando los usuarios solicitan acceso a un servidor y te adjuntan su llave pública ¡en formato PPK!

Es cierto que puedes usar PuTTYGen para pasar de un formato a otro, pero a mi me resulta muy engorroso. Personalmente veo más fácil y rápido usar ssh-keygen desde consola para transformar certificado PPK a certificado OpenSSH.

El uso es bastante sencillo: ssh-keygen [-i|-e] -f file, donde:

  • -i: lee un certificado, público o privado, no cifrado e imprime el equivalente en formato OpenSSH.
  • -e: lee un certificado, público o privado, cifrado e imprime el equivalente en formato OpenSSH.
  • -f: indica el archivo a leer

Ejemplo:

Crear clúster MariaDB

Esta entrada es una guía para desplegar un clúster de MariaDB en CentOS 7, aunque es aplicable para cualquier otra distribución (Debian, Ubuntu, Suse…).

Añadir el repositorio de MariaDB

El primer paso es agregar el repositorio de la versión de MariaDB y para la distribución donde se hará el despliegue, en este caso de MariaDB 10.1 para CentOS 7.

1
2
3
4
5
6
7
8
9
cat << EOF >> /etc/yum.repos.d/MariaDB.repo
# MariaDB 10.1 CentOS repository list
# http://downloads.mariadb.org/mariadb/repositories/
[mariadb]
name = MariaDB
baseurl = http://yum.mariadb.org/10.1/centos7-amd64
gpgkey=https://yum.mariadb.org/RPM-GPG-KEY-MariaDB
gpgcheck=1
EOF

Git: Trabajar con servidores que usan certificados autofirmados

La mayoría de desarrolladores, ¡e incluso algunos DEVOPS!, tienen la horrible costumbre de desactivar la verificación de certificados mediante git config http.sslVerify "false" para trabajar con servidores que usan certificados autofirmados y de esta forma evitar los errores del tipo:

1
2
3
4
C:\Users\antonio.guillen\Projects
λ git clone https://git.my-company.com/antonio.guillen/pymagit.git
Cloning into 'pymagit'...
fatal: unable to access 'https://git.my-company.com/antonio.guillen/pymagit.git/': Peer's certificate issuer has been marked as not trusted by the user.

Este post no tiene por objetivo enumerar los posibles problemas que puede traer desactivar las comprobación de certificados, saludos man-in-the-middle, sino indicar la forma correcta de trabajar en estas circunstancias. Y no, ejecutar git config http.sslVerify "false", no es la forma correcta de trabajar.

Diagnosticar problemas con conexiones SSL/TLS en Java

Java usa un almacén de Autoridades Certificadoras (CA), Java trustStore, que es mantenido por la Java Development Kit (JDK). Cuando una aplicación Java se conecta a un servicio SSL/TLS, lo primero que hace es comprobar si el certificado está firmado por alguna de las CA albergadas en la trustStore. En caso de que el certificado no pueda ser validado por la trustStore en los logs se registrará un error similar a PKIX path building failed... unable to find valid certification path to requested target.

Para comprobar si, efectivamente, los problemas de conexión se deben a la falta de una CA en la trustStore, se puede usar la clase de Java SSLPoke en dos sencillos pasos:

  1. Descargar SSLPoke.class
  2. Ejecutar java SSLPoke host port

A continuación un ejemplo, usando SSLPoke para validar una trustStore que aun no contiene la correspondiente CA.:

Recuperar la contraseña de sa de SQL Server

El método oficial para recuperar el acceso como administrador de SQL Server es:

  1. Logar con la cuenta de administrador local.
  2. Detener la instancia de SQL Server.
  3. Iniciar la instancia en modo de usuario único.
  4. Cambiar la contraseña de sa o agregar al rol de sysadmin cuentas de usuarios del dominio o locales.

Mediante consola

Si el servidor donde está instalado el SQL Server carece de interfaz gráfica, o simplemente prefieres la consola:

  1. net stop MSSQLSERVER$InstanceName, para detener la instancia InstanceName.
  2. net start MSSQLSERVER$InstanceName /m, para iniciar la instancia InstanceName en modo de usuario único.
  3. SQLCMD -S ServerName\InstanceName, para conectar a la instancia InstanceName del servidor ServerName. El binario de SQLCMD.EXE se suele localizar en C:\Program Files\Microsoft SQL Server\MSSQL11.MSSQLSERVER\MSSQL\Binn.
  4. Cambiar la contraseña de sa o crear un nuevo usuario sysadmin:
    • ALTER LOGIN sa WITH PASSWORD = 'NewPassword';, para cambiar la contraseña del usuario sa por NewPassword.
    • Crear un usuario y añadirlo al rol de sysadmin del SQL Server:
      • CREATE LOGIN [MyCompany\username] FROM WINDOWS;, para crear el login para el usuario username del dominio MyCompany.
      • ALTER SERVER ROLE sysadmin ADD MEMBER [MyCompany\username];: otorgar el rol de sysadmin al usuario username del dominio MyCompany.
  5. net stop MSSQLSERVER$InstanceName y net start MSSQLSERVER$InstanceName, para detener y volver a iniciar la instancia en modo multiusuario.

MySQL: Consultar el charset y collation

Conceptos

El charset es un conjunto de símbolos y codificaciones, es decir, la forma en que la base de datos guarda internamente los datos. Mientras que el collation es el conjunto de reglas que se aplican para comparar caracteres en un charset, es decir, indica a la base de datos como debe comparar los datos.

A continuación hago una traducción libre de un extracto de la documentación de MySQL Character Sets and Collations in General:

Suponga que tenemos un alfabeto de cuatro letras: A, B, a, b. Asignamos a cada letra un número: A = 0, B = 1, a = 2, b = 3. La letra A es el símbolo, el número 0 es el código para A y la combinación de las cuatro letras y sus códigos es el juego de caracteres (charset).

Suponga que queremos comparar dos cadenas de valores, A y B. La forma más sencilla de hacerlo es mirar sus códigos: 0 para A y 1 para B. Como 0 es menor que 1, diremos que A es menor que B. Lo que acabamos de hacer, es aplicar un collation a nuestro charset. El collation es un juego de reglas (en este caso solo una): “campara los códigos”. Llamamos a este collation, el más simple de todos los collation posible, collation binario (binary collation).

Pero, ¿qué ocurre si queremos decir que las minúsculas y las mayúsculas son equivalente? Entonces nosotros tenemos al menos dos reglas: (1) tratar la letras minúsculas a y b como equivalente de A y B; (2) compara los códigos. Llamamos a este collation insensible a mayúsculas y minúsculas (case insensitive) y es un poco más complejo que un binary collation.

Localizar los controladores de dominio del Directorio Activo

El servicio de Directorio Activo es un servicio distribuido que precisa que los clientes deben ser capaces de descubrir de forma dinámica los DC (Domain Controller). Este proceso de localización de los DC se puede realizar mediante dos tipos de protocolos:

  • Protocolos que hacen uso de broadcast, como NetBIOS y mailslot. Nota: Es normal que la difusión de los broadcast esté limitada en grandes redes.
  • Protocolos que no hacen uso de broadcast, como DNS y LDAP.

En ambos casos, el proceso de descubrimiento es similar y se divide en dos fases:

  1. Los DC publican información sobre ellos mismos mediante DNS o NetBIOS.
  2. Los clientes buscan esta información para determinar los posibles DC y envían mensajes, LDAP ping o mailslot ping, para determinar la disponibilidad de los mismos.

Gestión de usuarios en gitlab desde la consola rails

Esta semana tuve que dar soporte a un viejo servidor GitLab 6.0 y nadie tenía la contraseña del usuario admin. Así que me vi en la necesidad de usar la consola de rails para crear un usuario local y asignarle permisos de administrador en GitLab. Desde la rails console es posible realizar multitud de gestiones aunque en esta entrada tan solo nos centraremos en la creación de usuarios, reseteo de contraseña y asignación de permisos de administrador en GitLab.

Dependiendo de la versión de GitLab algunos parámetros no son permitidos, siendo necesario hacer algunas acciones en dos pasos.

Lanzar la consola rails

Dependiendo del GitLab, la consola puede ser invocada con el usuario root desde cualquier directorio usando el comando gitlab-rails console production o debe ser invocada con el usuario git en el directorio gitlab usando el comando bundle exec rails console production. A continuación ambos ejemplos:

  • A través de gitlab-rails:

    1
    2
    3
    [root@git ~]# gitlab-rails console production
    Loading production environment (Rails 4.2.8)
    irb(main):001:0>
  • A través de bundle exec:

    1
    2
    3
    git@gitlab-prod:~/gitlab[6-0-stable]$ bundle exec rails console production
    Loading production environment (Rails 3.2.13)
    1.9.1 :001 >

UniFi Video: Unable to Load Stream

Al configurar Nginx como proxy SSL/TLS OffLoading de un Tomcat ejecutando la aplicación UniFi Video, no es posible reproducir los streaming de videos a través de HTTPS. El streaming de video funciona correctamente a través de HTTP, pero no a través de HTTPS. En el interfaz web de UniFi Video se muestra un tooltip con el siguiente mensaje de error: Unable to load stream. Please make sure port 7446 is open on your NVR.

A continuación una captura de pantalla del error en la interfaz web de UniFi Video: