Como Hackerspace, queremos ser independiente. En organización pero también en infraestructura digital para nuestra comunidad y presencia en línea. Por eso utilizamos una arquitectura post-cloud, donde tomamos tecnologías que nacieron para la nube, pero utilizando la localmente. Garantizando nuestra independencia.

Obviamente utilizamos software libre. Pero tener acceso al código es solo un desde. Al otro extremo debemos ser practicos, es más importante tener un servicio que funcione bien y que uno que cumple prefectamente con nuestos pensamientos. Sin embargo, si dependemos de otros, ellos no deben tener mayor control sobre nosotros y facil de reemplazar por otro servicio igual.

Los servicios

En esta fase de nuestro Hackerspace somos pocos y necesitamos solo unos pocos servicios. Necesitamos una página web, un lugar para conversar internamente y gestionar los accesos de miembros a los servicios.

Todo se gestiona con containedores Docker corriendo en un RaspberryPi como un usuario normal que se despliegue con un simple docker compose up. La configuración de los servicios se guarda en un repositorio de código Git infra.

Todos los servicios web son https (obviamente) gestionados por una instancia de Caddy. La configuración de Caddy para servicios es simple. Pero lo más agradable es que viene con soporte para generar certificados Let’s Encrypt válidos sin ninguna configuración adicional para todos los virtual hosts registrados en Caddy.

Sitio web público

Queremos que nuestro sitio web sea ligero ambos para el usuario y el servidor. Libre de seguimiento comercial. Fácil de agregar contenido, sin obligar a nadie utiliza una interfaz específica para la creación de contenido. La solución obvio es utilizar un generador de sitios. El input son Archivos MarkDown en un repositorio de código. El output es un sitio web estático. Sin application servers, ni base de datos. Hay muchos proyectos que hacen esto. En este momento utilizamos Hugo. Tenemos un script deploy.sh que genera el sitio y sube los archivos del sitio al servidor. Tenemos dos sitios, hackina.cl y next. Next contiene la proxima versión del sitio público. En el repositorio de git esto se maneja como dos branches main y next.

El servidor web es el mismo Caddy. Y dado que es un sitio de páginas estáticas, no hay más necesidad que apuntar al directorio con los archivos del sitio. El resultado es un sitio que carga extremadamente rápido.

Una mejora que podemos hacer en el futuro es cambiar el script de actualización por los repo-actiones para crear el CI/CD completamente automatico. Por el momento, el script se ejecuta manualmente.

Servicio para conversaciones

Para el chat utilizamos XMPP. Miembros de Hackinta pueden crear una cuenta personal en el XMPP del Hackerspace. El servidor que utilizamos es el de prosody, dado que es más ligeros y apto para grupos pequeños como lo nuestro. Tenemos canales internos de Hackinta para miembros y miembros pueden crear canales para proyectos. El XMPP es federado y permite conversaciones con usuarios y grupos de otros servicios XMPP. Los clientes móviles como Conversations y Gajim para computadores de escritorio funcionan bien con el servicio.

Una mejora que hemos estado conversando es agregar una interfaz de Chat al sitio de hackinta, mediante algo como Converse.js.

Antes de XMPP, hicimos experimentos con el servicio Matrix, que en papel es federado y ademos más moderno. Sin embargo los pocos clientes viables que haya, están muy enfocados en empujar los servicios de matrix.org. Dejando self-hosting como opción claramente de segunda categoria. Constantemente hay que indicar que no quieres usar el servicio de matrix.org. Ademas ofrecen servicios como buscar de personas, siempre cuando integras con servicios centrales sin preguntar ni solicitar permisos.

Kanidm, acceso centralizado

Aparte de XMPP tendrémos varios sistemas que dan acceso para miembros. Para eso, necesitan una lista de usuarios y sus credenciales. Mantener una lista de usuarios por cada uno es una mala idea. Ya que da acceso es un drama para miembros nuevos. Inventar contraseñas para cada uno es un dolor tal que todo el mundo termina utilizando la misma en todas los sistemas, donde después es mucho trabajo rotarlas para otra. Y lo peor es off-boarding, cuando alguien ya no debe tener acceso, siempre queda algún acceso olvidado. Hay que resistir la tentación y la solución es usar un servicio de autenticación centralizado, que es mucho más fácil cuando empiezas con uno y no intentes a agregarlo después, con varios proyectos de migración complicados.

Kanidm es un servicio de authenticatión centralizado. Para nosotros eso vive en https://auth.hackina.cl. Todos los miembros deben tener una cuenta en este servicio y eso da acceso a todos los demás servicios. Mantiene las credenciales web como OAuth y Passkey. Y también está disponible como un LDAP de solo lectura para integración con otros servicios. Técnicamente, es otro servicio ligero que es un Docker de la infraestructura. Los demás servicios online apunten a Kanidm como su fuente de autenticación.

El equipo y la red

  architecture-beta
    group ZGH(cloud)[ZGH]
    group VPS(server)[Eslabon] in ZGH
    service wireguard_s[Wireguard] in VPS

    group Hackinta(cloud)[Hackinta]
    group Atanor(server)[Atanor] in Hackinta
    service wireguard_c[Wireguard] in Atanor
    service Caddy[Caddy] in Atanor
    service XMPP[XMPP] in Atanor
    service Kanidm[Kanidm] in Atanor

    wireguard_s:B -["VPN: Wireguard"]- T:wireguard_c
    Caddy:R -- L:XMPP
    Caddy:L -- R:Kanidm

Atanor

Nuestros servicios principales vive en Atanor. Es un Raspberry Pi 4B con 8GB de RAM y 128GB de almacenamiento. Usa menos energia que un luz LED de tu living y la carga (load) tipico del servidor es “0.00”. Atanor conectado por cobre con la red internet fibra de la cazona donde está el space y mantiene una connection wireguard con Eslabon.

Eslabon

Eslabon existe solo porque queremos un IPv4 and IPv6 fija. Es el VPS más pequeño de ZGH. Lo único que hace es redirigir los puertos de interés via wireguard para nuestros servicios a Atanor

Respaldos

Respaldemos todos los servicios con Borg backup a un servidor offsite. Borg cifra sus respaldos antes de enviarlos. El offsite server solo sabe que hay respaldos, pero no puede obtener el contenido. Para simplificar la configuration de Borg utilizemos borgmatic.

Cada servicio puede tener un script backup.sh que es llamado antes de crear el espaldo, con lo cual los servicios pueden exportar sus datos antes de que Borg los respalde para tener datos limpios. Ambos Kanidm y Prosody utilizan esto método para generar respaldos limpios de sus datos.

Donde dependemos de otros

No podemos hacer estos servicios solo, dependemos de terceros. Sin embargo, estos son fácil de reemplazar por otro igual y manejen nuestros de datos directos.

  • Internet - Entel fibra al edificio donde está el space. Nada especial, podría ser reemplazado por otro ISP.
  • VPS - ZGH con un servidor virtual en Chile para los IPs fijas. Se puede reemplazar por otro VPS con nada de problema.
  • DNS - Estamos en Cloudflare, por flojos. Claudflare hace nada más que manejo de Zona DNS para nosotros. Podría ser cualquier otro servidor con DNS.
  • Repositorios Git - Codeberg.org tiene nuestros repositorios de código y artefactos. Si se pone malo lo migramos a una solución self-hosted.
  • Email - Estamos utilizando forwardmail para recibir y envirar emails del dominio @hackinta.cl. Lamentablemente, Google y Microsoft han terminado tan dominante el servicio de email que basicamente deciden quien puede levantar un servidor de email propio. En un futuro, podemos intentar hacerlo self-hosted, pero para ser exitoso require más dedicación de lo que tienemos disponible en este momento.
  • Offsite Backups - Hetzner en Alemania recibe los respaldos. Barato, tonto y fácil de reemplazar por otro servicio.