In my previous post, we setup a Mastodon server using Docker and nginx-proxy. In this post, we use instead the web server Caddy. I’ve only discovered Caddy a week ago. The configuration of Mastodon is now even simpler and shorter. Caddy redirects traffic automatically from HTTP to HTTPS and configures HTTPS for all domains via Let’s Encryption. :rocket:

Our starting point is the docker-compose.yml shipped with the Mastodon code. Why is it not enough? It assumes you setup up proxy with HTTPS endpoints yourself. So let’s integrate this as well in Docker.

Setup

Few remarks to start with:

• my testing system: Ubuntu 20.04.3 LTS (GNU/Linux 5.4.0-97-generic x86_64)
• install first some software with apt install docker docker.io caddy jq git

• create an unprivileged user account, e.g. mastodon

  adduser --disabled-login mastodon
  adduser mastodon docker
  adduser mastodon sudo # optional, remove later
  su mastodon # switch to that user
  

• my docker compose: Docker Compose version v2.2.3 (based on go)

  install docker compose in 3 lines:

  mkdir -p ~/.docker/cli-plugins
  curl -sSL https://github.com/docker/compose/releases/download/v2.2.3/docker-compose-linux-x86_64 -o ~/.docker/cli-plugins/docker-compose
  chmod +x ~/.docker/cli-plugins/docker-compose
  

• my testing domain (for this example): social.host

• my dot-env file .env for docker compose:

  LETS_ENCRYPT_EMAIL=admin-mail@social.host
  MASTODON_DOMAIN=social.host
  FRONTEND_SUBNET="172.22.0.0/16"
  # check the latest version here: https://hub.docker.com/r/tootsuite/mastodon/tags
  MASTODON_VERSION=v3.4.6
  

• I have commented out build: ., because I prefer to rely on the official images from Docker Hub.

• With little effort, we enable as well full-text search with elasticsearch.

• The setup places all databases and uploaded files in the folder mastodon.

• We use a named volume mastodon-public to expose the static files from the mastodon-web container to the Caddy webserver. Caddy serves directy static files for improved speed. Awesome! :star2:

• The setup comes with the Mastodon Twitter Crossposter. You need to setup an extra subdomain for it. Remove it from the docker-compose.yml in case you have no use for it.

• Using extra_host, we expose with "host.docker.internal:host-gateway" the Docker host to the Mastodon Sidekiq container in case that you configure Mastodon to use a mail transfer agent (e.g. postfix) running on the host. In that case, use SMTP_SERVER=host.docker.internal.

• Consider to replace the git repository to build the crossposter with a local copy for more control over updates.

# file: 'docker-compose.yml'
version: "3.7"

services:
  caddy:
    image: caddy:2-alpine
    restart: unless-stopped
    container_name: caddy
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./caddy/etc-caddy:/etc/caddy
      - ./caddy/data:/data # Optional
      - ./caddy/config:/config # Optional
      - ./caddy/logs:/logs
      - mastodon-public:/srv/mastodon/public:ro
    env_file: .env
    # helps crossposter resolve the mastodon server internally
    hostname: "${MASTODON_DOMAIN}"
    networks:
       frontend:    
          aliases:
            - "${MASTODON_DOMAIN}"
    networks:
      - frontend
      - backend

  mastodon-db:
    restart: always
    image: postgres:14-alpine
    container_name: "mastodon-db"
    healthcheck:
      test: pg_isready -U postgres
    environment:
      POSTGRES_HOST_AUTH_METHOD: trust
    volumes:
      - "./mastodon/postgres:/var/lib/postgresql/data"
    networks:
      - backend

  mastodon-redis:
    restart: always
    image: redis:6.0-alpine
    container_name: "mastodon-redis"
    healthcheck:
      test: redis-cli ping
    volumes:
      - ./mastodon/redis:/data
    networks:
      - backend

  mastodon-elastic:
    restart: always
    image: docker.elastic.co/elasticsearch/elasticsearch-oss:7.10.2
    container_name: "mastodon-elastic"
    healthcheck:
      test: curl --silent --fail localhost:9200/_cluster/health || exit 1
    environment:
      ES_JAVA_OPTS: "-Xms512m -Xmx512m"
      cluster.name: es-mastodon
      discovery.type: single-node
      bootstrap.memory_lock: "true"
    volumes:
      - ./mastodon/elasticsearch:/usr/share/elasticsearch/data
    networks:
      - backend
    ulimits:
      memlock:
        soft: -1
        hard: -1

  mastodon-web:
    restart: always
    image: "tootsuite/mastodon:${MASTODON_VERSION}"
    container_name: "mastodon-web"
    healthcheck:
      test: wget -q --spider --proxy=off localhost:3000/health || exit 1
    env_file: mastodon.env.production
    environment:
      LOCAL_DOMAIN: "${MASTODON_DOMAIN}"
      SMTP_FROM_ADDRESS: "notifications@${MASTODON_DOMAIN}"
      ES_HOST: mastodon-elastic
      ES_ENABLED: true
    command: bash -c "rm -f /mastodon/tmp/pids/server.pid; bundle exec rails s -p 3000"
    expose:
      - "3000"
    depends_on:
      - mastodon-db
      - mastodon-redis
      - mastodon-elastic
    volumes:
      # https://www.digitalocean.com/community/tutorials/how-to-share-data-between-docker-containers
      - mastodon-public:/opt/mastodon/public # map static files in volume for caddy
      - ./mastodon/public/system:/opt/mastodon/public/system
    networks:
      - frontend
      - backend
    extra_hosts:
      - "host.docker.internal:host-gateway"

  mastodon-streaming:
    restart: always
    image: "tootsuite/mastodon:${MASTODON_VERSION}"
    container_name: "mastodon-streaming"
    healthcheck:
      test: wget -q --spider --proxy=off localhost:4000/api/v1/streaming/health || exit 1
        ]
    env_file: mastodon.env.production
    environment:
      LOCAL_DOMAIN: "${MASTODON_DOMAIN}"
      SMTP_FROM_ADDRESS: "notifications@${MASTODON_DOMAIN}"
      ES_HOST: mastodon-elastic
      ES_ENABLED: true
    command: node ./streaming
    expose:
      - "4000"
    depends_on:
      - mastodon-db
      - mastodon-redis
    networks:
      - frontend
      - backend

  mastodon-sidekiq:
    restart: always
    image: "tootsuite/mastodon:${MASTODON_VERSION}"
    container_name: "mastodon-sidekiq"
    healthcheck:
      test: ps aux | grep '[s]idekiq\ 6' || false
    env_file: mastodon.env.production
    environment:
      LOCAL_DOMAIN: "${MASTODON_DOMAIN}"
      SMTP_FROM_ADDRESS: "notifications@${MASTODON_DOMAIN}"
      ES_HOST: mastodon-elastic
      ES_ENABLED: true
    command: bundle exec sidekiq
    depends_on:
      - mastodon-db
      - mastodon-redis
    volumes:
      - ./mastodon/public/system:/mastodon/public/system
    networks:
      - frontend
      - backend
    extra_hosts:
      - "host.docker.internal:host-gateway"

  crossposter-db:
    restart: always
    image: postgres:14-alpine
    container_name: "crossposter-db"
    healthcheck:
      test: pg_isready -U postgres
    environment:
      POSTGRES_HOST_AUTH_METHOD: trust
    volumes:
      - ./crossposter/postgres:/var/lib/postgresql/data
    networks:
      - backend

  crossposter-redis:
    restart: always
    image: redis:6.0-alpine
    container_name: "crossposter-redis"
    healthcheck:
      test: redis-cli ping
    volumes:
      - ./crossposter/redis:/data
    networks:
      - backend

  crossposter-web:
    restart: always
    build: https://github.com/renatolond/mastodon-twitter-poster.git#main
    image: mastodon-twitter-poster
    container_name: "crossposter-web"
    env_file: crossposter.env.production
    environment:
      CROSSPOSTER_DOMAIN: "https://crossposter.${MASTODON_DOMAIN}"
    expose:
      - "3000"
    depends_on:
      - crossposter-db
    networks:
      - frontend
      - backend

  crossposter-sidekiq:
    restart: always
    build: https://github.com/renatolond/mastodon-twitter-poster.git#main
    image: mastodon-twitter-poster
    container_name: "crossposter-sidekiq"
    healthcheck:
      test: ps aux | grep '[s]idekiq\ 6' || false
    env_file: crossposter.env.production
    environment:
      ALLOWED_DOMAIN: "${MASTODON_DOMAIN}"
      CROSSPOSTER_DOMAIN: "https://crossposter.${MASTODON_DOMAIN}"
    command: bundle exec sidekiq -c 5 -q default
    depends_on:
      - crossposter-db
      - crossposter-redis
    networks:
      - frontend
      - backend

volumes:
  mastodon-public:

networks:
  frontend:
    name: "${COMPOSE_PROJECT_NAME}_frontend"
    ipam:
      config:
        - subnet: "${FRONTEND_SUBNET}"
  backend:
    name: "${COMPOSE_PROJECT_NAME}_backend"
    internal: true

The web server Caddy is configured using a Caddyfile stored in ./caddy/etc-caddy. I started with a config I found on Github.

# file: 'Caddyfile'
# kate: indent-width 8; space-indent on;

{
        # Global options block. Entirely optional, https is on by default
        # Optional email key for lets encrypt
        email {$LETS_ENCRYPT_EMAIL}
        # Optional staging lets encrypt for testing. Comment out for production.
        # acme_ca https://acme-staging-v02.api.letsencrypt.org/directory

        # admin off
}

{$MASTODON_DOMAIN} {
        log {
                # format single_field common_log
                output file /logs/access.log
        }

        root * /srv/mastodon/public

        encode gzip

        @static file

        handle @static {
                file_server
        }

        handle /api/v1/streaming* {
                reverse_proxy mastodon-streaming:4000
        }

        handle {
                reverse_proxy mastodon-web:3000
        }

        header {
                Strict-Transport-Security "max-age=31536000;"
        }

        header /sw.js  Cache-Control "public, max-age=0";
        header /emoji* Cache-Control "public, max-age=31536000, immutable"
        header /packs* Cache-Control "public, max-age=31536000, immutable"
        header /system/accounts/avatars* Cache-Control "public, max-age=31536000, immutable"
        header /system/media_attachments/files* Cache-Control "public, max-age=31536000, immutable"

        handle_errors {
                @5xx expression `{http.error.status_code} >= 500 && {http.error.status_code} < 600`
                rewrite @5xx /500.html
                file_server
        }
}

crossposter.{$MASTODON_DOMAIN} {
        log {
                # format single_field common_log
                output file /logs/access-crossposter.log
        }

        encode gzip

        handle {
                reverse_proxy crossposter-web:3000
        }

}

With these file in place, create a few more folders and launch the setup of the instance. If the instance has been setup before, a database setup may be enough.

# mastodon
touch mastodon.env.production
sudo chown 991:991 mastodon.env.production
mkdir -p mastodon/public
sudo chown -R 991:991 mastodon/public
mkdir -p mastodon/elasticsearch
sudo chmod g+rwx mastodon/elasticsearch
sudo chgrp 0 mastodon/elasticsearch

# first time: setup mastodon
# https://github.com/mastodon/mastodon/issues/16353 (on RUBYOPT)
docker compose run --rm -v $(pwd)/mastodon.env.production:/opt/mastodon/.env.production -e RUBYOPT=-W0 web bundle exec rake mastodon:setup

# subsequent times: skip generation of config and only setup database
docker compose run --rm -v $(pwd)/mastodon.env.production:/opt/mastodon/.env.production web bundle exec rake db:setup

# crossposter
mkdir crossposter
docker-compose run --rm crossposter-web bundle exec rake db:setup

# launch mastodon and crossposter
docker compose run -d

# look into the logs, -f for live logs
docker compose logs -f

Troubleshooting

1. I had much problems to let the mastodon container connect to a mail transport agent (MTA) of my host. Eventually, I solved it with an extra filewall rule: ufw allow proto tcp from any to 172.17.0.1 port 25.

2. The mail issue can be avoided by a) using a SaaS such as (mailgun/mailjet/sendinblue) or b) using another Docker container with postfix that is in the frontend network as well. Look at Peertube’s docker-compose file for some inspiration.

References

• https://caddyserver.com
• https://gist.github.com/yukimochi/bb7c90cbe628f216f821e835df1aeac1?permalink_comment_id=3607303#gistcomment-3607303 (Caddyfile for Mastodon on Github)

Tras Gran Canaria, Bilbao, A Corunya y Almería, es decir, por quinta vez en la historia de Akademy el encuentro anual de la Comunidad Internacional KDE se celebrará en España. De este modo me complace anunciar que Akademy 2022 se celebrará en Barcelona, concretamente del 1 al 7 de octubre en un evento que será híbrido: presencial y en línea, cumpliéndose los pronósticos que auguraban que tras el impacto de pandemía este tipo de encuentros se adaptarían a esta nueva realidad.

Akademy 2022 se celebrará en Barcelona

En palabras de los organizadores:

KDE anuncia que la Akademy de este año tendrá lugar tanto online como en persona en Barcelona en octubre.
Únase a nosotros en la vibrante ciudad de Gaudí, el Club de Fútbol Barça y la alta cocina mediterránea para reunirse en persona (o asistir online) y disfrutar de la mejor experiencia sea cual sea la opción que elija.
¡Reserva la fecha! El evento comienza el 1 de octubre y termina el 7 de octubre, con una fiesta de bienvenida prevista para la noche anterior al inicio de las charlas.

Akademy lleva realizándose anualmente bajo este nombre desde 2004, en la página web oficial o en la wikipedia podéis encontrar los nombres y fechas anteriores eventos.

Para que os hagáis una ligera idea de la magnitud del evento, os dejo una imagen de grupo de Akademy 2015 de A Corunya en la que tuve la suerte de participar.

Más información: Akademy 2022

¿Qué es Akademy?

Para los que no lo sepan, Akademy es el evento de la Comunidad KDE que aúna en una gran conferencia todo tipo de simpatizantes de KDE como desarrolladores, diseñadores, usuarios, traductores, promotores. Allí se reunirán a lo largo de una semana para compartir charlas, cenas, ponencias, talleres y, en definitiva, para trabajar juntos.
Es una gran semana que sirve para unir más fuerte los lazos que unen nuestra Comunidad, así como para crear nuevos.

dracut -a resume -f

add_dracutmodules+=" resume "

Seemingly a boring topic, Balázs Scheidler finds open source licensing fascinating. It allows him to work on syslog-ng even though Balabit was acquired. He writes:

“I mentioned in the previous post that I would like to focus on syslog-ng and put it more into the spotlight. I also mentioned that Balabit, the company I was a founder of and the commercial sponsor behind syslog-ng, was acquired by One Identity ~4 years ago. How does this add up? Who owns the Intellectual Property (IP) for syslog-ng? Who am I or this blog affiliated with?”

Read the rest of his blog at https://syslog-ng-future.blog/syslog-ng-future-blog-is-this-a-fork-or-what/

Deja que git hooks se ocupe de automatizar tareas, comprobar errores en commits, y mucho más de manera automática al trabajar con un repositorio en git

Los git hooks son una serie de scripts que se crean de manera automática al crear un repositorio git y que se «disparan» de manera automática ante ciertos eventos al trabajar con git. Por ejemplo al crear un commit, al recibir un push, etc.

Los podemos activar y personalizar a nuestras necesidades y utilizarlos para prevenir errores como enviar un commit a una rama equivocada, enviar una notificación antes de realizar un commit, etc.

Vamos a echar un vistazo a esos git hooks. Como siempre digo, no soy experto y por eso siempre remito a la documentación oficial. Aquí veremos algún ejemplo de uso de estos git hooks.

Te recomiendo abrir una terminal en tu equipo e ir siguiendo los pasos. Vamos a hacer una carpeta llamada prueba, entramos en ella y la inicializamos como repositorio git. Todo esto así:

mkdir prueba
cd prueba
git init

Cada vez que creas un nuevo repositorio de git en tu equipo como lo que hemos hecho en estos pasos, se creará una carpeta oculta llamada .git y dentro de esta otras carpetas y hay una llamada hooks y dentro de esa carpeta varios scripts listos para poder utilizarlos, veamos cómo.

Cabe recordar que esta carpeta .git no se subirá al repositorio git remoto. Por lo que estarán en tu equipo, pero no formarán del repositorio upstream.

Dentro de nuestra carpeta prueba, entramos en la carpeta .git/hooks y veremos que existen unos archivos similares a estos:

 applypatch-msg.sample
 commit-msg.sample
 fsmonitor-watchman.sample
 post-update.sample
 pre-applypatch.sample
 pre-commit.sample
 pre-merge-commit.sample
 pre-push.sample
 pre-rebase.sample
 pre-receive.sample
 prepare-commit-msg.sample
 push-to-checkout.sample
 update.sample

1. pre-commit → se ejecuta hantes de realizar un commit
2. prepare-commit-msg → se ejecuta antes de escribir un mensaje de commit
3. commit-msg → se ejecuta después de escribir un mensaje de commit
4. post-commit → se ejecuta después de realizar un commit
5. pre-rebase → antes de realizar un rebase
6. post-checkout → después de realizar un checkout
7. post-merge → después de realizar un merge
8. pre-receive → antes de recibir un push
9. post-receive → después de recibir un push
10. update → antes de recibir un push, se ejecuta una vez por rama

Pero hay alguno más. Estos scripts son unos ejemplos para utilizarlos como git hooks, sus nombres son bastante indicativos de cuando se ejecuta cada script. Puedes ver el contenido de código de uno de ellos.

Algunos están pensados para ser ejecutados desde el lado del cliente y otros son específicos para el lado del servidor donde esté ubicado el repositorio git.

Para utilizarlos, basta con eliminarles la extensión .sample y darle derechos de ejecución. Los códigos de los scripts son una guía que podemos utilizar. Pero podemos modificarlos a nuestras necesidades o utilizar otro lenguaje de programación como Python en vez de bash si lo preferimos, para adaptar los scripts a nuestras necesidades.

Vamos a habilitar el script commit-msg. Para ello, como he dicho, lo renombramos y le hacemos ejecutable:

mv commit-msg.sample commit-msg 
chmod +x commit-msg 

Editamos el archivo y podemos por ejemplo pegar este pequeño script en Bash:

#!/bin/sh

# Comprueba que el mensaje del commit es mayor de 4 caracteres y menor de 30
commit=$(head -n1 $1)

if [[ $(echo $commit | wc -c) -lt 5 || $(echo $commit | wc -c) -gt 30 ]];then
    echo -e "El texto del commit debe ser mayor de 5 caracteres y menor de 30.\nPor favor vuelve a escribir un nuevo commit"
    exit 1
fi

Con este script, «forzamos» a quien quiera crear un commit a que el comentario que introduzca sea mayor de 4 caracteres y menos de 30. De no cumplir eso, le mostrará el texto por pantalla y no se aceptará el commit.

Al igual que este script, también podemos crear otro, para comprobar que los commits cumplen unas normas, por ejemplo que empiecen de una manera determinada, o lo que necesitemos.

Otras tareas que podemos habilitar con otros scripts es enviar un correo de notificación a los responsables del repositorio de que se ha recibido un nuevo push.

O quizás al recibir un nuevo aporte a nuestro repositorio ejecutar un determinado script que refleje esos cambios en una página web, etc…

Aquí depende del uso que se les quiera dar para cada caso determinado. Por la red hay varios ejemplos de uso de diferentes casos para que les eches un vistazo, por si alguno se puede adaptar a tus necesidades.

Enlaces de interés

• https://git-scm.com/book/es/v2/Personalización-de-Git-Puntos-de-enganche-en-Git
• https://githooks.com/
• https://www.redhat.com/sysadmin/git-hooks

We learned in my previous sudo blog that cvtsudoers is not just for LDAP. Version 1.9.9 of sudo extends the querying possibilities of cvtsudoers further and adds a brand new feature: merging multiple sudoers files into one. Both are especially useful when you have complex configurations. Querying lets you to better understand what the various rules allow in your sudoers file. Merging helps you to combine multiple configurations into one, so you do not have to maintain a separate sudoers file on each of your hosts.

Read the rest of my blog on the sudo website at https://www.sudo.ws/posts/2022/02/cvtsudoers-merging-multiple-sudoers-files-into-one/

Han pasado ya los cuatro meses de rigor desde la última gran actualización del entorno de trabajo Plasma de la Comunidad KDE, la 5.23 edición 25 aniversario. Esto significa que los desarrolladores han estado trabajando en el siguiente paso y que se congratulan en anunciar que ha sido lanzado Plasma 5.24 LTS, que destaca por su búsqueda de mejorar la sensación general y la usabilidad del entorno.

Lanzado Plasma 5.24 LTS, armonía perfecta

El anuncio oficial dice así:

La Comunidad KDE ha publicado hoy Plasma 5.24, una versión con asistencia a largo plazo (LTS) que recibirá actualizaciones y correcciones de errores hasta el final de la versión Plasma 5, antes de la transición a Plasma 6.

Esta nueva versión de Plasma se centra en suavizar las asperezas, en la evolución del diseño y en la mejora de la sensación general y de la usabilidad del entorno.

Las novedades de Plasma 5.24 LTS

Hoy es un día de descarga y actualizaciones, y mientras espero que esté disponible para mi KDE Neon, os comento algunas de sus novedades:

• Mejoras en las funciones de KRunner con el asistente de ayuda.
• Desbloqueo de la pantalla y autentificación de las aplicaciones con tus huellas dactilares
• Nuevo y espectacular fondo de pantalla de Ken Vermette para Plasma 5.24 «Honeywave»

• Breeze amplía la función que permite elegir los colores de acento (introducida en Plasma 5.23) y ahora permite elegir cualquier color que desee, en caso de que los colores preseleccionados no sean de vuestro agrado.
• El tema por defecto Plasma Breeze ha recibido un refresco visual para que se ajuste más al estilo de Breeze de las aplicaciones, mejorando la coherencia visual entre ellas.

• Para que las notificaciones críticas de Plasma destaquen, ahora vienen con una franja naranja en el lateral para distinguirlas visualmente de los mensajes menos urgentes.
• Muchos widgets han recibido nuevas funciones y mejoras sutiles que mejoran su aspecto, la relevancia de su información y la facilidad para navegar por ellos.
• Los menús contextuales del Administrador de tareas se han aclarado y simplificado.
• Retorno de la la vista general para gestionar todos los escritorios y aplicaciones

• Se han añadido mejoras al Color Nocturno, a la hoja de pruebas de los altavoces en la página de Audio de los Ajustes del Sistema y a la función de límite de carga de la batería.
• Discover da la opción de reiniciar automáticamente después de que se haya completado una actualización., haciendo click en la casilla de verificación situada en la parte inferior de la página de Actualizaciones.
• Wayland continúa a buen ritmo con un gran número de mejoras, como la compatibilidad con colores de más de 8 bits, auriculares de RV con un rendimiento óptimo y tabletas de dibujo.

Más información: KDE

« Safer Internet Day », c’est aujourd’hui le 8 février, 2022, 2ème mardi de février. Mon coup de gueule ! En effet, une tablette ou smartphone n’est pas la nounou de votre enfant, voire la tétine pour garder l’enfant au calme ! De toutes les façons, je ne fais que vous recommander, vu mon jeune âge et mon expérience …

Journée mondiale pour un Internet plus sûrRead More »

The post Journée mondiale pour un Internet plus sûr appeared first on Cybersécurité, Linux et Open Source à leur plus haut niveau | Network Users Institute | Rouen - Normandie.

ΠΡΟΒΛΗΜΑ

ΕΓΚΑΤΑΣΤΑΣΗ autoyast

ΔΗΜΙΟΥΡΓΙΑ ΑΡΧΕΙΟΥ autoinst.xml

ΕΓΚΑΤΑΣΤΑΣΗ ΜΕ ΧΡΗΣΗ ΑΡΧΕΙΟΥ autoinst.xml

ΠΙΘΑΝΑ ΠΡΟΒΛΗΜΑΤΑ