El problema

En aquel artículo, casi al final de todo, comentaba que hacía falta aplicar una solución para que el tráfico XMPP del resto de puertos (5000, 5222,… todos los que no son el 80 ó el 443) fuese reenviado desde el VPS a mi servidor en casa.

Probé algunas cosas con la configuración de NGINX y su módulo streams, pero no funcionó, así que voy a describir aquí cómo acabé usando las capacidades de filtrado de paquetes de Linux (el núcleo mismo) a través de iptables (en inglés).

Mi solución está basada y adaptada a partir de lo explicado en este artículo (en inglés) de Ryan Welch.

Al final del artículo, en cualquier caso, dejaré las configuraciones que intenté aplicar en NGINX para procesar tráfico TCP y UDP en general. Quizá lo necesitemos más adelante, o a lo mejor decides probarlo y comentarme qué es lo que hice mal.

Solución

Como comentaba antes, Linux (NO GNU/Linux, sino “Linux” sin más, el núcleo) tiene funcionalidades de filtrado de paquetes de red incluidas, que podemos configurar para nuestros propios fines.

Para configurar la redirección de tráfico en el VPS, entramos por SSH y habilitaremos IP forwarding en el núcleo:

sudo sysctl -w net.ipv4.ip_forward=1

Esto puede que se aplique entre arranques, o no, dependiendo de tu distribución. Para asegurarte, edita el fichero /etc/sysctl.conf y descomenta la línea net.ipv4.ip_forward=1.

Tras ello, ya podrás redirigir puertos y rangos de puertos con instrucciones como la siguiente:

iptables -A PREROUTING -t nat -p tcp -i eth0 --dport 5222 -j DNAT --to-destination <IP Destino>:5222
iptables -A POSTROUTING -t nat -p tcp -d <IP Destino> --dport 5222 -j MASQUERADE

Y, para rangos de puertos:

iptables -A PREROUTING -t nat -p udp -i eth0 -m multiport --dports 49152:65535 -j DNAT --to-destination <IP Destino>:49152-65535
iptables -A POSTROUTING -t nat -p udp -d <IP Destini> -m multiport --dports 49152:65535 -j MASQUERADE

Vas a tener que cambiar los puertos del ejemplo por los tuyos propios, así como poner tu propia dirección IP de destino en lugar del texto <IP Destino>.

Para el caso de XMPP hay que añadir todas las reglas de renvío correspondientes a sus puertos, cambiando el texto <IP Destino> por la dirección IP del servidor de casa, patata en el artículo previo de la serie, y teniendo en cuenta que la dirección que tenemos que configurar es la de patata en Tailscale.

iptables -A PREROUTING -t nat -p tcp -i eth0 --dport 5222 -j DNAT --to-destination <IP Destino>:5222
iptables -A POSTROUTING -t nat -p tcp -d <IP Destino> --dport 5222 -j MASQUERADE
iptables -A PREROUTING -t nat -p tcp -i eth0 --dport 5269 -j DNAT --to-destination <IP Destino>:5269
iptables -A POSTROUTING -t nat -p tcp -d <IP Destino> --dport 5269 -j MASQUERADE
iptables -A PREROUTING -t nat -p tcp -i eth0 --dport 5000 -j DNAT --to-destination <IP Destino>:5000
iptables -A POSTROUTING -t nat -p tcp -d <IP Destino> --dport 5000 -j MASQUERADE
iptables -A PREROUTING -t nat -p tcp -i eth0 --dport 3478 -j DNAT --to-destination <IP Destino>:3478
iptables -A POSTROUTING -t nat -p tcp -d <IP Destino> --dport 3478 -j MASQUERADE
iptables -A PREROUTING -t nat -p tcp -i eth0 --dport 3479 -j DNAT --to-destination <IP Destino>:3479
iptables -A POSTROUTING -t nat -p tcp -d <IP Destino> --dport 3479 -j MASQUERADE
iptables -A PREROUTING -t nat -p udp -i eth0 --dport 3478 -j DNAT --to-destination <IP Destino>:3478
iptables -A POSTROUTING -t nat -p udp -d <IP Destino> --dport 3478 -j MASQUERADE
iptables -A PREROUTING -t nat -p udp -i eth0 --dport 3479 -j DNAT --to-destination <IP Destino>:3479
iptables -A POSTROUTING -t nat -p udp -d <IP Destino> --dport 3479 -j MASQUERADE
iptables -A PREROUTING -t nat -p tcp -i eth0 --dport 5349 -j DNAT --to-destination <IP Destino>:5349
iptables -A POSTROUTING -t nat -p tcp -d <IP Destino> --dport 5349 -j MASQUERADE
iptables -A PREROUTING -t nat -p tcp -i eth0 --dport 5350 -j DNAT --to-destination <IP Destino>:5350
iptables -A POSTROUTING -t nat -p tcp -d <IP Destino> --dport 5350 -j MASQUERADE
iptables -A PREROUTING -t nat -p udp -i eth0 --dport 5349 -j DNAT --to-destination <IP Destino>:5349
iptables -A POSTROUTING -t nat -p udp -d <IP Destino> --dport 5349 -j MASQUERADE
iptables -A PREROUTING -t nat -p udp -i eth0 --dport 5350 -j DNAT --to-destination <IP Destino>:5350
iptables -A POSTROUTING -t nat -p udp -d <IP Destino> --dport 5350 -j MASQUERADE
iptables -A PREROUTING -t nat -p udp -i eth0 -m multiport --dports 49152:65535 -j DNAT --to-destination <IP Destino>:49152-65535
iptables -A POSTROUTING -t nat -p udp -d <IP Destino> -m multiport --dports 49152:65535 -j MASQUERADE

Prueba que todo funciona y graba las reglas de iptables con sudo iptables-save > /etc/iptables/rules.v4, de tal forma que se apliquen cada vez que reinicies el VPS.

En su artículo, Ryan comentaba otras configuraciones adicionales para temas tales como control de congestión. Consulta ese artículo para saber más, y aplica todo aquello que te sea de utilidad.

NGINX con tráfico TCP y UDP genérico

Esta parte del artículo no está del todo probada, porque no me acabó de funcionar para la instalación del servidor XMPP Snikket. Sin embargo, de acuerdo a su documentación, ésta es la forma en la que se configura NGINX para tráfico que no es Web.

Instala libnginx-mod-stream para habilitar el soporte a proxies inversos TCP y UDP.

Modifica /etc/nginx/nginx.conf para añadir un bloque stream:

stream {
        include /etc/nginx/streams-enabled/*;
}

Tras ello, crea los directorios correspondientes siguiendo el mismo esquema existente para las webs: sudo mkdir -p /etc/nginx/streams-available /etc/nginx/streams-enabled

Crea un fichero /etc/nginx/streams-available/tcpudpservice.example.com.conf con reglas como las siguientes:

# Puerto TCP (tráfico no HTTP):
server {
        listen 5222;
        proxy_pass <IP Destino>:5222;
}

# ...

# Puerto UDP:
server {
        listen 3478 udp;
        proxy_pass <IP Destino>:3478;
}

# ...

# Se aceptan rangos, también. En este caso, fíjate
# en el uso de $server_port en la sentencia proxy_pass.

server {
        listen 49152-65535 udp;
        proxy_pass <IP Destino>:$server_port;
}

En caso de definir rangos de puertos muy grande, como los que propone Snikket para conversaciones de audio y vídeo por XMPP en instalaciones con muchos usuarios, NGINX devolverá un error al tener demasiados ficheros abiertos. La configuración de Snikket espera poder tener hasta 16384 conexiones UDP abiertas al mismo tiempo.

Si queremos resolver esto en lugar de reducir el rango de puertos UDP, hay que aumentar el parámetro LimitNOFILE de NGINX. Para eso, ejecuta sudo systemctl edit nginx.service; esto abrirá un fichero de extensión de la definición del servicio

Escribe lo siguiente y graba los cambios:

[Service]
LimitNOFILE=65535

Tras ello, en el preámbulo de /etc/nginx/nginx.conf (fuera de cualquier bloque http, events o stream), añade la línea worker_rlimit_nofile con un valor menor a 65535 (30000 funciona para Snikket), e incrementa el valor de worker_connections dentro de events:

...
include /etc/nginx/modules-enabled/*.conf;

worker_rlimit_nofile 30000;

events {
        # worker_connections 768;
        # 3 veces 8192 será suficiente
        worker_connections 24576;
        # multi_accept on;
}

...

Como dije antes, esta configuración no me sirvió para XMPP, pero puede ser útil para otros casos de uso.

Este texto detalla los pasos a seguir para conectar un proxy inverso (NGINX) instalado en un servidor A, y dar acceso a servicios web instalados en otra máquina diferente, un servidor B. Si la máquinas están en ubicaciones o redes diferentes, la conectividad la podremos resolver mediante varias alternativas, como una VPN.

En mi caso concreto, esto sirve para instalar NGINX en un VPS, y usarlo para exponer mis servicios alojados en un servidor que tengo en casa, “barcas”. Para conectar las dos máquinas y que NGINX pueda redirigir el tráfico a esos servicios, he usado Tailscale.

Este artículo continúa la serie que empezó con “Cambios en mi red de la mano de XMPP”. Si te preguntas por qué querríamos hacer esto, o qué valor tiene esta configuración, visita ese enlace.

Solución

Para llevar a cabo esta solución necesitarás:

1. Un servidor VPS contratado con tu servicio de alojamiento de confianza, al que poder acceder por SSH.
2. Un servidor en tu casa, con al menos un servicio aceptando conexiones HTTP. Por ejemplo, en el puerto 5000 (0.0.0.0:5000). A este servidor lo llamaremos patata en el resto del artículo, por claridad.
3. Una cuenta gratuita en Tailscale. En general, valdría con cualquier otro proveedor de VPN, pero es preferible que esté basada en WireGuard, porque ofrece un mejor rendimiento que OpenVPN.
4. Opcionalmente, o para que esto tenga sentido, un dominio con sus registros de DNS apuntando al VPS que mencionamos en el punto 1.

En las instrucciones de este artículo supondré que ambos servidores (el VPS y patata) tienen instalada una Ubuntu LTS Server (por ejemplo, la 24.04).

Si no hay problemas, en 20 minutos deberías tenerlo todo listo.

Servidor en casa

Nos conectaremos a patata, donde está nuestro servicio web esperando peticiones en el puerto 5000.

Instalamos Tailscale y autenticamos a patata en nuestra cuenta. Esto asociará una dirección IP dentro de la VPN a patata:

# Las órdenes para instalar tailscale no las reproduzco 
# porque podrían cambiar en cualquier momento.

sudo tailscale up
# Seguimos las instrucciones por pantalla

# Habilitamos Tailscale como servicio de sistema permanentemente
sudo systemctl enable tailscaled --now

# Obtenemos la IP de esta máquina en la tailnet y la anotamos.
tailscale ip -4
100.85.67.22

En el panel de control de Tailscale podremos ver su nombre local, además de la IP devuelta por la última orden.

También podremos configurar la máquina para que no haya que re-introducirla en la red, desactivando la expiración de la clave usada para autenticar la máquina en Tailscale.

Opcionalmente, podemos activar el “MagicDNS” para podernos referir a ambas máquinas mediante un nombre, en lugar de mediante una dirección IP, sin tener que configurar nada localmente en las máquinas.

Una vez la máquina está en Tailscale, debemos abrir el puerto 5000 en el cortafuegos de patata, si es que no lo habíamos hecho ya, para que pueda recibir peticiones desde el VPS por dicho puerto.

sudo iptables -A INPUT -p tcp -m tcp --dport 5000 -j ACCEPT

A este respecto:

1. Si no tienes iptables-persistent instalado, es el momento de instalarlo para poder grabar las reglas de cortafuegos de tal forma que se apliquen con cada reinicio de la máquina.

sudo apt install iptables-persistent 
sudo iptables-save > /etc/iptables/rules.v4

2. Personalmente, abro los puertos en todos los interfaces y no sólo en el de Tailscale.
   • Al no tener que abrir ese puerto en el router, no estoy haciendo nada que me deje demasiado expuesto.
   • Al hacerlo así, no necesito acceder por Tailscale a patata cuando, estando en casa, necesito hacer alguna prueba.
   • Cada caso es distinto: decide qué hacer tú mismo con tu cortafuegos dependiendo de lo crítico que sea el servicio que estás configurando, y lo sensibles que sean los datos que gestiona.

VPS

En segundo lugar, nos conectamos al VPS por medio de SSH e instalamos un proxy inverso. Aunque no vayamos a tener más de un servicio escuchando en los puertos 80 y 443, configurar y entender un proxy inverso es más fácil que configurar y entender reglas de reenvío de tráfico y DNAT en un cortafuegos como iptables.

En mi caso, suelo usar NGINX.

sudo apt update && sudo apt install nginx

Instalamos Tailscale y repetimos los mismos pasos al respecto que en el caso de patata. Anotamos la dirección IP de el VPS en “la tailnet”, por ejemplo 100.85.77.36.

Obtenemos un certificado de Let’s Encrypt para nuestro dominio, con CertBot. Para esto:

• Debemos configur previamente los registros DNS de nuestro dominio, ejemplo.com, para que apunten a la IP pública (no a su IP en Tailscale) del VPS en el que estamos trabajando.
• Es posible tengamos que parar NGINX para esto (sudo systemctl stop nginx), dependiendo de nuestros proveedores de dominio y los plugins de CertBot disponibles para interactuar con él.

sudo certbot certonly --standalone -d ejemplo.com
...
...
Successfully received certificate.
Certificate saved at: /etc/letsencrypt/live/ejemplo.com/fullchain.pem;
Key is saved at:      /etc/letsencrypt/live/ejemplo.com/privkey.pem;
...
...

Configuramos el servicio en el proxy inverso, poniendo en la sentencia proxy_pass la IP de nuestro servidor patata en Tailscale. Para ello, en /etc/nginx/sites-available/ creamos un fichero de configuración, por ejemplo ejemplo.com.conf para una web https://ejemplo.com.

upstream ejemploweb {
        # Sustituye [IP o nombre de máquina] por el valor de tu 'patata'
        # **en Tailscale**.
        # 100.85.67.22 en el texto del artículo.
        server [IP o nombre de máquina]:5000;
        keepalive 64;
}

server {
        server_name ejemplo.com;
        listen 80;

        location / {
                return 301 https://$host$request_uri;
        }
}

server {
        server_name ejemplo.com;
        listen 443 ssl http2;

        # Other SSL stuff goes here
        ssl_protocols TLSv1.2 TLSv1.3;
        ssl_ciphers HIGH:!MEDIUM:!LOW:!aNULL:!NULL:!SHA;
        ssl_prefer_server_ciphers on;
        ssl_session_cache shared:SSL:10m;
        ssl_session_tickets off;

        ssl_certificate     /etc/letsencrypt/live/ejemplo.com/fullchain.pem;
        ssl_certificate_key /etc/letsencrypt/live/ejemplo.com/privkey.pem;

        location / {
                # The final `/` is important.
                proxy_pass http://ejemploweb/;
                add_header X-Frame-Options SAMEORIGIN;
                add_header X-XSS-Protection "1; mode=block";
                proxy_redirect off;
                proxy_buffering off;
                proxy_set_header Host $host;
                proxy_set_header X-Real-IP $remote_addr;
                proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
                proxy_set_header X-Forwarded-Proto $scheme;
                proxy_set_header X-Forwarded-Port $server_port;
                proxy_read_timeout 90;
        }
}

Creamos un enlace simbólico a este fichero en /etc/nginx/sites-enabled, probamos la configuración de NGINX y, si todo va bien, la recargamos.

cd /etc/nginx/sites-enabled/
sudo ln -s ../sites-available/ejemplo.com.conf
sudo nginx -t
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
# Si hemos detenido el servicio de NGINX para obtener el certificado, 
# lo arrancamos; si no:
sudo systemctl reload nginx

En este punto, deberíamos poder interactuar con nuestro servicio en patata desde https://ejemplo.com.

Posibles errores que te puedes encontrar

• El navegador no muestra nada, el servicio no contesta. Si hay actividad en los logs de NGINX en el VPS (sudo tail -f /var/log/nginx/access.log), y la petición se abandona tras un tiempo (timeout), hay varias posibles causas que me he encontrado con mi limitada experiencia. En patata:
  • El servicio al que quieremos acceder a través de NGINX no está funcionando, y tenemos que arrancarlo,
  • o el servicio está expuesto en el puerto 5000 de un interfaz de red específico, en lugar de 0.0.0.0 (que significa todos los interfaces de red de patata), y que no es el de Tailscale; por ejemplo, en 127.0.0.1,
  • o hemos hecho algo mal con el cortafuegos y la petición se está rechazando de esta forma.
• La configuración de NGINX es correcta (sudo nginx -t dice que 👍), pero NGINX no arranca o se muere al recargar la configuración. La causa más frecuente es que NGINX no se puede comunicar con patata, al que estaríamos apuntando con la sentencia proxy_pass, porque no lo encuentra.
  • O bien hemos cometido un error al configurar el proxy_pass,
  • o bien NGINX ha intentado establecer contacto con patata antes de que Tailscale estableciese el túnel, por ejemplo si esto ocurre tras reiniciar el VPS,
  • o bien el servicio de Tailscale se ha parado en alguna de las dos máquinas.
  • Esta causa se confirma con el mensaje host not found in upstream en la salida de sudo systemctl status nginx:

nginx.service - A high performance web server and a reverse proxy server
     Loaded: loaded (/usr/lib/systemd/system/nginx.service; enabled; preset: enabled)
    Drop-In: /etc/systemd/system/nginx.service.d
             └─override.conf
     Active: active (running) since Fri 2025-08-29 11:05:51 UTC; 3 days ago
       Docs: man:nginx(8)
    Process: 1154 ExecStartPre=/usr/sbin/nginx -t -q -g daemon on; master_process on; (code=exited, status=0/SUCCESS)
    Process: 1156 ExecStart=/usr/sbin/nginx -g daemon on; master_process on; (code=exited, status=0/SUCCESS)
    Process: 58676 ExecReload=/usr/sbin/nginx -g daemon on; master_process on; -s reload (code=exited, status=1/FAILURE)
   Main PID: 1157 (nginx)
      Tasks: 3 (limit: 1110)
     Memory: 46.9M (peak: 200.2M)
        CPU: 29min 57.349s
     CGroup: /system.slice/nginx.service
             ├─1157 "nginx: master process /usr/sbin/nginx -g daemon on; master_process on;"
             ├─1158 "nginx: worker process"
             └─1159 "nginx: cache manager process"

...
Sep 02 05:32:49 vps-hostingprovider nginx[58676]: 2025/09/02 05:32:49 [emerg] 58676#58676: host not found in upstream "100.85.77.22" in /etc/nginx/sites-enabled/ejemlo.com.conf>
Sep 02 05:32:49 vps-hostingprovider systemd[1]: nginx.service: Control process exited, code=exited, status=1/FAILURE
Sep 02 05:32:49 vps-hostingprovider systemd[1]: Reload failed for nginx.service - A high performance web server and a reverse proxy server.
lines 1-28/28 (END)

• Recibimos un código de estado HTTP 502. Esto quiere decir que, si bien NGINX está funcionando correctamente, el servicio al que nos conectamos (expuesto en el puerto 5000 de patata), está devolviendo errores.
  • Si haces una prueba local en patata y el servicio funciona, casi seguro que se trata de un tema de proxies de confianza. Describir el problema en detalle excede los objetivos de este artículo, pero en resumen se trata de que tienes que especificar en la configuración de ese servicio, en patata, que NGINX está instalado en una máquina diferente, el VPS, y configurar la dirección del VPS en Tailscale como proxy de confianza. Consulta los logs del servicio para confirmar esta hipótesis.
  • Esto no es un problema, es una característica de seguridad bastante interesante.
  • Por ejemplo, esto me pasó con mis instancias de Mastodon y de Nextcloud. En ambos casos, la documentación contenía las soluciones: Mastodon – trusted proxies, Nextcloud – trusted proxies
  • Depende de cómo esté implementado el servicio que estamos intentando arreglar, puede ser que acepte un proxy de confianza tanto como nombre de máquina o como direccion IP, o sólo como IP. Ármate de paciencia y si no te funciona con el nombre de la máquina no te desesperes.

En éste os voy a contar cuáles son esos problemas, por qué surgen, por qué los quiero resolver y cómo los he resuelto, pero desde un punto de vista de diseño por el momento. No vas a encontrar instrucciones de terminal para resolver todo esto, sino el contexto necesario para saber qué estoy intentando resolver; las instrucciones detalladas vendrán en los siguientes artículos.

Hasta ahora, todos mis servicios alojados bajo mi impresora eran servicios Web, es decir, basados en comunicaciones a través de los puertos 80 y 443 (HTTP y HTTPs). Estos puertos eran suficientes para comunicar todos mis servicios con mis dispositivos o con mi navegador, o con otros servidores en el caso de mi instancia de Mastodon. Para poder atender a tantos servicios tras los mismos puertos, uso NGINX como proxy inverso:

A diferencia de mis otros servicios, XMPP usa más puertos TCP y UDP que el 80 y el 443: 5000, 5222, 5269,… En el caso de Snikket como, supongo, toda otra serie de alternativas, los puertos 80 y 443 también se usan para proporcionar un panel de control Web y poder administrar usuarios y salas de chat.

Sobre el papel, la configuración para instalar Snikket sería la siguiente:

• Configurar los puertos 80 y 443 en NGINX para poder usar el panel de control de usuarios y conversaciones de Snikket.
• Configurar acceso directo a todo el resto de los puertos de Snikket: 5222, 5269,… ésta es la lista completa (en inglés). Como no son puertos compartidos entre varios servicios, no hace falta configurarlos en un proxy inverso.
• Configurar las DNS de mi servicio de XMPP en mi proveedor de dominios, que es Cloudflare.

Esta configuración, que a priori tendría buena pinta, se resume en esta figura:

Sin embargo, esto tiene un problema que no es evidente, y la configuración de arriba no funciona sin más. Las características de seguridad de Cloudflare que están disponibles para las cuentas gratuitas en forma de “el proxy de Cloudflare” sólo soportan los puertos 80 y 443. Con el proxy de Cloudflare activado, todo el tráfico que no es web (80 y 443) se descartaba, por lo que ninguno de los puertos que entran en juego en las conversaciones de XMPP llegaba a mi servidor.

Desactivando el proxy de Cloudflare para la configuración de los subdominios de Snikket todo funciona, pero queda así:

Desactivar el proxy de Cloudflare no es ideal, porque expone la IP del servidor al resto de internet. Mi servidor está en casa, por lo que un ataque de denegación de servicio que, por puro azar, incluyese la dirección IP que mi operador de acceso a internet me asigna, tiraría por tierra toda mi red doméstica. Eso nos impediría trabajar o estudiar desde casa y, probablemente, me traería problemas con mi proveedor de servicio.

Una alternativa a esto es contratar un servidor barato en cualquier proveedor de alojamiento en la nube (un VPS) y mover toda mi configuración de NGINX a él, conectando este servidor en la nube con el servidor de mi casa mediante una VPN (la cuenta gratuita de Tailscale funciona muy bien y es más que suficiente).

• El proveedor de alojamiento en la nube protegería mi servidor porque la IP expuesta sería la suya, no la de mi casa, y este tipo de empresas protegen su infraestructura ante ataques, por lo menos a un nivel de red. Tras los puertos XMPP no hay contenido, sino un servicio de mensajería que además cifra el tráfico, así que no hay problema por perder la capa de seguridad y anti-bots que proporciona Cloudflare para estos puertos.
• Conectar el VPS a mi servidor a través de una VPN es perfecto para este caso, porque oculta la dirección IP de mi red doméstica ahorrándome configurarla en el panel de control de DNS, y también el tener que abrir puertos en mi router. Además, para todo el tráfico que iría entre la VPS y mi servidor, se aplicaría una capa de cifrado que lo protegería en caso de que, de por sí, no estuviese ya cifrado.

¿Por qué mover sólo la configuración de NGINX y no todos los servicios? Por una cuestión de recursos y precio: para ejecutar NGINX y una serie de reglas de cortafuegos, los requisitos que necesitamos son mínimos. Con un servidor que tenga 1 GB de RAM y con una CPU es más que suficiente, y eso cuesta entre 3 y 6€ al mes. Si muevo todo² necesitaría entre 8 y 16 GB de RAM, mucho más almacenamiento potencia de CPU, una solución de copias de seguridad,… Con todo ello me estaría moviendo en un rango de unos 40€, o más, al mes. Teniendo un servidor en casa donde ejecutar los servicios, moverlo todo a la VPS acarrea un coste innecesario en mi caso.

Así pues, parece que contratar una VPS sencilla para tener NGINX configurado allí, y conectarla al servidor de casa mediante Tailscale, resolvería mis problemas a un coste muy bajo (3 a 6€ al mes).

La única complicación adicional de este método es que tenemos que tener algún mecanismo para redirigir el tráfico de los puertos de XMPP (varios puertos como el 5222, 5269,… en TCP y UDP) desde el VPS hacia nuestro servidor (en casa o donde fuere). Al final lo he resuelto configurando el VPS para que haga IP forwarding y luego he configurado una serie de reglas DNAT³ en su cortafuegos.

En próximos artículos veremos más en detalle la configuración de todos los elementos.

En ocasiones, algo pasa y la opción correspondiente para grabar el escritorio del ordenador desaparece. No sé si OBS está traducido al Español, o si lo está, si está bien traducido; en Inglés la opción que desaparece es “Screen Capture (PipeWire)”:

En mi caso este problema se debió a que los recursos correspondientes a la funcionalidad de Wayland para compartir pantalla se quedaron bloqueados en algún estado inconsistente.

Tras mucho trastear, acabé por recuperar la funcionalidad perdida borrando el contenido de los directorios ~/.cache y ~/.local/state/:

rm -rf ~/.cache/*
rm -rf ~/.local/state/*

No creo que esta solución sirva a todo el mundo, porque Wayland está aún en fase de desarrollo y pueden estar fallando muchas más cosas. Las pistas que me sirvieron para probar estas cosas fueron las siguientes:

• Esta característica funcionaba, no mucho tiempo atrás.
• Creando un usuario nuevo, ese usuario tiene la opción disponible.

Esto quiere decir que OBS y Wayland están bien instalados y funcionan en el ordenador, por lo que todo apuntaba a ficheros temporales.

Para poder colocar la respuesta automáticamente por encima del texto al que respondes, deberás editar las plantillas por defecto del editor. Para eso, en Settings → Composer → *Standard Templates, *o sus equivalentes en español, deberás cambiar todas las plantillas de respuesta para que el comando %CURSOR aparezca por encima del comando %QUOTE.

Por ejemplo, la plantilla de responder a todos pasaría de ésto:

%REM="Default reply all template"%-
On %ODATE %OTIMELONG %OFROMNAME wrote:
%QUOTE
%CURSOR

A ésto:

%REM="Default reply all template"%-
%CURSOR

On %ODATE %OTIMELONG %OFROMNAME wrote:
%QUOTE

Deberás cambiarlas todas. Y para más inri, si usas KMail como un plugin de Kontact, probablemente debas cambiar estas plantillas en ambas aplicaciones; por alguna razón no hablan entre ellas muy bien. En cualquier caso, ese cambio funciona una vez ambos escenarios reconocen el cambio.

Siendo esta aplicación parte de KDE, entorno de escritorio famoso por la ingente cantidad de opciones que ofrece, que falte algo tan básico es casi un síntoma de la falta de diseñadores de producto colaborando con proyectos de software libre que, por otro lado y desde cualquier punto de vista, son fantásticos.

Aún así, no hace falta buscar muy a fondo en internet para encontrar respuestas como la que sigue:

No tiene nada de malo que la comunidad de KDE eduque a usuarios como tú en conceptos avanzados de los clientes de correo electrónico [como las plantillas]. … … entender cómo funcionan las plantillas de texto no es mucho pedir para un usuario de KDE/Plasma. Siempre puedes instalar Thunderbird si piensas diferente.

Y así es como el software libre pierde usuarios: con respuestas pedantes que piensan que forzarte a perder el tiempo con algo tan de nicho como un lenguaje de marcado específico de un editor de plantillas de mensajes correo electrónico es más razonable que mejorar un producto con una opción en forma de una casilla de verificación. Una triste casilla de verificación.

El pasado viernes 29 de noviembre estuve instalando Linux en arranque dual con Windows 11, en través de twitch. Y me ha gustado el resultado, tanto que es muy posible que haga muchos más vídeos de ahora en adelante, tanto en directo como “producidos”.

El resultado está disponible en PeerTube, en mi cuenta de veedeo.org, próximamente en YouTube, y lo puedes ver aquí mismo:

También he creado, por fin, una cuenta de Patreon para que, quien quiera, pueda apoyar este blog, el podcast y los vídeos que iré creando a medida que el tiempo y el material disponible me lo permitan.

Sin embargo, el fichero de copia de seguridad del certificado (formato PKCS #12, de extensión .p12) que generan las herramientas oficiales usa una versión de los algoritmos de cifrado que está considerada obsoleta. Esto genera un fichero aparentemente inservible, imposible de usar en la mayoría de navegadores modernos, como Firefox en mi caso.

Esto te puede estar afectando ya mismo aunque no uses Linux, y aunque no hayas renovado nada.

• El problema se debe a un cambio en los estándares de seguridad de los navegadores, que busca elevar el nivel de seguridad de este tipo de cosas. Si tienes esta copia de seguridad almacenada en tus archivos y quieres importarla en un navegador moderno, meses o años después de haberla generado, probablemente tengas este problema.
• Al ser algo relacionado con la seguridad de forma general, el problema no debería estar limitado a Firefox ni a Linux, y puede estar pasando ahora o en un futuro cercano con Safari, Chrome o Edge en Windows o en macOS.

Los siguientes comandos en GNU/Linux producen un fichero certificado.p12 que podrás importar en tu navegador. Antes de empezar, algunas notas:

• VISO_CARRERA_GABRIEL___[NIF].p12 es el archivo de certificado con problemas, así que tendrás que usar el nombre de tu propio fichero.

• Los ficheros .p12 están protegidos con contraseña. Necesitarás introducir una contraseña para operar con el fichero .p12 con problemas, y fijar una nueva contraseña en el fichero .p12 resultado del proceso. Esto no está representado en los comandos siguientes.

  openssl pkcs12 -legacy -in VISO_CARRERA_GABRIEL___[NIF].p12 -clcerts -nokeys -out certificado.crt openssl pkcs12 -legacy -in VISO_CARRERA_GABRIEL___[NIF].p12 -nocerts -out cifrado.key openssl rsa -in cifrado.key -out privado.key openssl pkcs12 -export -in certificado.crt -inkey privado.key -out certificado.p12

Un comando por línea.

Una vez hecho esto, certificado.p12 podrá ser importado en tus navegadores, sin problema alguno.

Este proceso no me lo he inventado yo, ni lo he descubierto por mi mismo; lo he encontrado en esta respuesta en el foro de la comunidad de Fedora.

Si usas GNU/Linux en tu día a día pero tienes Windows en una máquina virtual por si las moscas, esto también es un problema aunque no uses Windows más que una o dos veces al año. Por ejemplo, si usas Windows para entrar en la típica página de la administración porque no has sido capaz de configurar un navegador de forma que funcione correctamente, vas a tener que tener un sistema compatible pero actualizado. No quieres usar un sistema desactualizado, sin parches, etc., para cosas tan sensibles como tu declaración de la renta o gestionar cosas con la Seguridad Social. Aunque creas que te da igual, no te da igual, y no quieres hacerlo.

Para poder llevar a cabo este proceso tu ordenador físico tiene que cumplir con los requisitos de hardware de Windows 11 en términos de microprocesador, módulo de seguridad TPM, y demás. La virtualización es un proceso que comparte dispositivos reales de la máquina física entre distintos sistemas operativos: uno anfitrión, que es el que está instalado sobre la máquina física, y los distintos sistemas operativos huéspedes, instalados en las máquinas virtuales.

Aunque pudiese haber productos que, además de virtualización, tuviesen capadidades de emulación para exponer un chip TPM realizado por software, o para que Windows 11 percibiese un microprocesador de una serie más moderna que el tuyo, VirtualBox no es uno de ellos.

Por lo tanto, utilizar VirtualBox no te va a servir para instalar Windows 11 en un PC que no esté soportado.

Al igual que actualizar un ordenador a Windows 11, actualizar una máquina virtual tiene sus curvas, sus terraplenes y sus trucos: si cambiamos el hardware virtual de nuestra máquina virtual, nuestra licencia de Windows 10 no será válida, y tendremos que comprar una licencia de Windows 11. No podemos crear otra máquina virtual, instalar Windows 11 y usarlo, porque no tendremos licencia de Windows para ese hardware. Incluso si creamos la máquina virtual con los mismos identificadores de hardware, sospecho que al no haber cambiado de Windows 10 a Windows 11 de forma controlada podríamos tener algún problema de licencia porque la licencia vinculada a esos identificadores de hardware es de Windows 10.

Por si fuera poco, VirtualBox no se caracteriza por ofrecer una experiencia de virtualización de Windows 11 adecuada, ni por facilitar la actualización desde Windows 10:

1. Hasta hace relativamente pocos telediarios, las máquinas virtuales de VirtualBox tenían una definición equivalente a un PC de hace 20 años, y no exagero: BIOS, esquema de particiones MBR, nada que se parezca a un chip TPM es ofrecido a la máquina virtual, el arranque seguro es ciencia-ficción y la EFI “sólo es válida para sistemas operativos especiales”.
2. Por las razones arriba expuestas, estas máquinas no soportan Windows 11. Para usar Windows 11 en estas máquinas debías usar el proceso existente para decirle a Windows que no comprobase sus requisitos de hardware. Esto cae en un terreno gris donde Microsoft no termina de posicionarse, pero siempre ha barajado no permitir que dichos PC recibiesen actualizaciones.
3. En VirtualBox 7, como quien dice, anteayer, Oracle por fin implementó todas las características que requiere Windows 11 de forma nativa y ya permite definir una máquina virtual con EFI, arranque seguro, TPM 2.0 y todas esas otras características.
4. En una máquina virtual existente, activar esas características permitiría, en teoría, ejecutar el proceso de actualización a Windows 11 sin perder la licencia ni tener que hacer arcanos de terminal ni editar ficheros a mano.
5. Sin embargo, activar la EFI, TPM y arranque seguro en nuestra máquina virtual existente la dejará aparentemente inservible, porque no arrancará.

No es un problema tan descabellado, tiene su sentido, la causa del problema es trivial y, por suerte, tiene fácil solución. El problema es que la máquina no encuentra el sistema operativo: el disco donde está Windows 10 es un disco formateado con un esquema de particiones MBR, típico de la época de los PC con BIOS, mientras que los PC con EFI espera discos formateados con esquema de particiones GPT.

Así pues, para poder activar la EFI hay que convertir la tabla de particiones de un disco desde MBR a GPT. Para ello y como se discute en el enlace anterior, Microsoft proporciona un programa llamado mbr2gpt.exe. Afortunadamente, todas las instalaciones de Windows 10 que conserven su partición de recuperación lo tienen disponible, y las instalaciones hechas en VirtualBox no son una excepción. Además, y por si las moscas, ese programa está incluido en todas las imágenes de DVD o de memoria USB que usaríamos para reparar, actualizar o restaurar el sistema.

Esto es lo que hay que hacer específicamente en Virtual Box:

• Actualiza tu instalación de Windows 10 hasta la última actualización disponible.

• Realiza una copia de seguridad de tus ficheros, por si la conversión desde MBR a GPT fallase por alguna razón y debieras reinstalar Windows 10.

• Recuerda: tu licencia está vinculada a Windows 10. Hasta que no tengas un sistema actualizado a Windows 11 y con Windows 11 activado, creo que no puedes formatear e instalar Windows 11 desde cero.

• Descarga el programa de creación de medios de instalación de Microsoft para crear dos medios de instalación en formato ISO: Windows 10.iso y Windows 11.iso.

• Reinicia tu sistema operativo en modo recuperación pulsando la tecla de mayúsculas mientras pinchas en el botón Reiniciar de Windows 10

• Alternativamente, utiliza cualquiera de las ISO que acabas de descargar para reparar el sistema.

La ISO de Windows 11 ofrece opciones para reparar el sistema, igual que la partición de recuperación de Windows 10.

• En este entorno, abre un intérprete de comandos (Troubleshoot > Advanced Options > Command Prompt o algo como Solución de Problemas > Opciones Avanzadas > Intérprete de Comandos) y ejecuta los comandos siguientes:

  mbr32gpt /validate

Comando para validar tu unidad de disco. Si todo va bien, la salida del programa terminará con MBR2GPT: Validation completed successfully.

mbr2gpt /convert

Comando para convertir tu unidad de disco desde MBR a GPT. Si todo va bien, la salida del programa terminará con MBR2GPT: Conversion completed successfullyMBR2GPT: Update WinRE config fileMBR2GPT: Before the new system can boot properly you need to switch the firmware to boot to UEFI mode!

Diferentes pantallas del proceso explicado en los puntos anteriores, donde podemos ver el aspecto del proceso de recuperación y la salida de los comandos.

• Apaga la máquina virtual de forma ordenada y, en VirtualBox, cambia la configuración para que EFI, Arranque Seguro (Secure Boot), el chip TMP 2.0 y la aceleración de gráficos en 3D estén activadas en el siguiente arranque.

Activando las opciones EFI y Secure Boot.Activando la aceleración 3D, y dotando a la máquina de suficiente memoria de vídeo (256 MB, que es el máximo)

• Arranca la máquina virtual. El sistema debería arrancar perfectamente y funcionar como si nada.
• Actualiza Windows 10 una vez más.

Windows seguirá diciendo que tu sistema no es compatible con Windows 11, y sólo obtendrás actualizaciones de Windows 10. Esto no es cierto gracias a los cambios que hemos llevado a cabo en la máquina: mi sospecha es que el programa de compatibilidad que Microsoft ha escrito tiene una base de datos de fabricantes reconocidos que no está preparado para máquinas virtuales. Pero esto no es un problema, porque tenemos una ISO de Windows 11 y podremos iniciar el proceso pese a todo.

• Monta la ISO de Windows 11 en la unidad de DVD que tiene tu máquina virtual.
• Ábrela con el Explorador de Ficheros y ejecuta el programa setup.exe.

Programa de instalación de Windows 11, en el Explorador de Ficheros de Windows 10

• Selecciona las opciones adecuadas para conservar tus ficheros y aplicaciones (o no), y actualizar el sistema.

Si todo te ha ido igual de bien que a mí, deberías tener una máquina virtual con Windows 11 donde todos los requisitos están cumplidos, la activación del sistema es correcta y está vinculada a tu cuenta de Microsoft. Detalle de la máquina virtual Windows 11 mostrando los detalles del chip TPM que le es ofrecido. Es hora de actualizarla una última vez para recibir actualizaciones específicas de Windows 11, crear una copia de seguridad de acuerdo a tu propia estrategia, y dedicarte a cosas más productivas.

Era genial.

Entonces, llegó Spotify, primero como inversor, y luego comprando Anchor. Al poco tiempo, todas las características sociales y el funcionamiento que comentaba arriba, como la emisora, desaparecieron del producto y nos quedamos con una plataforma de podcasting solvente, y nada más.

No voy a dar cuenta en detalle del proceso de enmierdificación de Spotify en este artículo, sino que me voy a limitar a decir que no estoy cómodo en esa plataforma desde hace tiempo, y he decidido autoalojar en casa mi propio podcast. El soporte a mi podcast me lo da ahora Castopod, una plataforma de podcasting libre y de código abierto que, además, ofrece integración con el fediverso mediante Activity Pub y soporte a múltiples características del podcasting 2.0, como la posibilidad de dejar comentarios desde tu propia aplicación de escucha de podcasts entre otras cosas.

Vamos a ver cómo se migra un podcast a Castopod. En este artículo se trata de Spotify, pero el proceso va a ser muy similar en cualquier otro caso.

Obtén Castopod

Castopod está disponible para instalar en tu propio servidor, que puede ser una VPS o una máquina sencilla conectada a internet, o puedes contratarlo en varios proveedores especializados. En castopod.org tienes acceso a información acerca de todas las opciones. Yo lo he instalado en un mini PC, en mi casa, usando Docker y NGINX como proxy inverso. Publicaré algo al respecto en lo sucesivo, pero hoy me voy a centrar en el proceso de salida de Spotify.

Opcional: obtén tu propio dominio y, si es posible, una CDN

Si lo vas a instalar en tu casa, vas a necesitar un dominio. Si lo usas ofrecido por alguno de los proveedores, probablemente puedas usar un subdominio proporcionado por ellos.

En cualquier caso, como un podcast sirve archivos de cierto peso, es buena idea contratar un servicio que te ofrezca una red de distribución de contenidos (CDN) con presencia en múltiples geografías: actuará de caché, relajando los requisitos de ancho de banda de tu proveedor, y además acelerará el acceso a tu podcast desde geografías lejanas. Personalmente, uso la cuenta gratuita de Cloudflare para los dos asuntos: dominio y CDN.

Importa tu Podcast en Castopod

Una vez Castopod está funcionando en tu servidor, es hora de importar tu podcast en Castopod. Esto se hace indicando la dirección del feed RSS a Castopod en su panel de control, así como el nombre de usuario en el fediverso, la categoría y el idioma del contenido.

![)Formulario de importación de un podcast en Castopod Es importante tener en cuenta que Castopod va a reinterpretar todo el feed y a validarlo. Uno de los problemas que tuve derivados de este aspecto es que, si a alguno de tus episodios le faltan las notas (el contenido del campo <description />), el proceso va a fallar, tendrás que corregir el episodio en concreto, esperar a que Spotify republique tu feed, y reanudar el proceso donde se interrumpió. En mi caso, llevó unos cuantos intentos:

Opcional: activa las estadísticas OP3

Las estadísticas que ofrece Castopod por defecto son bastante buenas, pero si te interesa la iniciativa Open Podcast Prefix Project, OP3, es un buen momento para unirte a ella activando las estadísticas con un sólo click en el formulario de edición de tu podcast.

Redirige tu antiguo feed al nuevo, permanentemente

Éste es el paso más sencillo, y más crítico. En Spotify para Podcasters, en el panel de edición de tu podcast, encontrarás un campo de texto para introducir un nuevo feed al que redirigir el antiguo. Esta redirección se implementa mediante un código de estado del protocolo HTTP, 301, que indica a los clientes, índices, buscadores y directorios de podcasting que el feed se ha mudado y nunca volverá a Spotify. En el cuerpo de la respuesta que acompaña a ese estado de redirección permanente 301 está la dirección del nuevo feed. El comportamiento esperado para clientes HTTP (cualquier aplicación o servicio que quiera acceder al feed) cuando reciben una respuesta con estado 301 es actualizar sus registros a la nueva dirección y no volver a intentar acceder a la antigua nunca más.

A partir de este momento, y en un tiempo indeterminado, todos tus suscriptores empezarán a recibir contenido por el feed nuevo, y si tienes la misma experiencia que yo, de una forma totalmente transparente.

⚠️ Cuando esto pase, perderás el control de tu podcast en Spotify para Podcasters

Esto es algo de lo que Spotify no te avisa claramente, pero cuando Spotify perciba que el podcast ya no está bajo su control, perderás acceso a funciones de edición del mismo, e incluso a la posibilidad de borrar los datos del mismo en Spotify.

Aún cuando veas que esto está pasando, no borres aún tu cuenta de Spotify para Podcasters: si algún rezagado no ha recibido la instrucción de redirección y borras tu cuenta, se borra la redirección, con lo cual podrías perder oyentes. Personalmente, yo voy a borrarla pasado un mes.

⚠️ Escoge cuidadosamente el momento de hacer esto si alojas tu nuevo podcast en tu casa.

En el momento en el que actives la redirección en Spotify, servicios de directorio que probablemente no sepas que estaban indexando tu feed recibirán las coordenadas del feed nuevo. Estos servicios de directorio usan procesos tipo arañas (mala traducción de web crawlers) para recorrer el feed y reindexarlo todo.

El cambio desde Spotify para Podcasters a Castopod es muy profundo. En términos de la propia estructura del feed, de dónde están alojados los ficheros, y del nombre de los mismos, el efecto es que todos estos procesos perciben tu podcast como una reedición completa. Como decimos en España, a este feed no lo reconoce ni su padre. Esto hace que todos estos actores invaliden todos los datos previos y lo recorran todo de nuevo, descargando todos y cada uno de tus episodios, metadatos, imágenes… todo. Y en este momento, aunque tengas CDN, su caché todavía está vacía, por lo que todas las peticiones van a ir directas a tu casa.

Estos servicios tienen una capacidad de cómputo y de red inmensamente mayor que la de tu casa, por lo que todos* ataquen tu feed a la vez*, tu conexión a internet va a experimentar un pico de tráfico de subida muy significativo, que puede afectar a tu conectividad, especialmente si hay alguien trabajando desde casa.

Por eso, mejor hazlo por la noche. No seas como yo 😅

Solicita el traspaso de tu Podcast a tu propiedad en los distintos directorios (que te interesen)

Esto es importante.

Me voy a centrar en Apple Podcasts, pero es fácil entender que esto deberías hacerlo allá en donde te interese tener presencia, en tu caso particular.

Acabas de redirigir tu feed a Castopod, tu conexión a internet en casa las ha pasado canutas, y has tenido que dar explicaciones a tu mujer e hijos de por qué internet iba como una patata, pero todo ha vuelto a su cauce normal, todo funciona y los primeros oyentes que sabían que ibas a cambiar esto te felicitan, te dicen que las descargas van más lentas…

Sin embargo, los directorios de podcasting como Apple Podcasts no te tienen registrado como el autor o el responsable del mismo a la hora de enviarte alertas y avisos con respecto a tu podcast. Situaciones en las que te podrías ver involucrado y que te interesaría resolver con Apple, como una potencial violación de los Términos y Condiciones de su servicios de directorio, no te serán notificadas.

Por otro lado, tampoco tienes control sobre tu podcast en Spotify para Podcasters, que es a donde Apple enviaría este tipo de mensajes en caso de conflicto. Spotify te ha dado la patada en cuanto la redirección se ha vuelto efectiva.

Estás en tierra de nadie.

Es hora de ponerse en contacto con Apple Podcasts Connect y solicitar que te den control sobre tu podcast.

Para eso, ármate con tu fluidez en el idioma de Shakespeare, porque creo que el formulario no se ofrece en Español, y haz lo siguiente (efectivo en Mayo de 2024):

1. Entra en Apple Podcasts Connect, o regístrate si no tienes cuenta.

2. Abajo de todo, selecciona “Contact Us”

3. En el formulario que aparece, rellena tus datos y selecciona como tema de consulta “Missing Podcast(s)” dentro de “Content Management”. Tendrás que introducir los siguientes datos:

4. El título del podcast ("Podamigos del cocido")

5. El id del podcast. Entiendo que se trata de los números al final en la URL del podcast en Apple Podcasts: “id817487481”.

6. La URL completa a la página del podcast en Apple Podcasts.

7. La URL del nuevo feed.

8. En el cuerpo del mensaje, indica que has migrado tu podcast desde Spotify a otro hosting, indica también la del anterior por si acaso el operador que te atienda todavía tiene el antiguo feed en sus cachés, y pide instrucciones como te gustaría que te las pidiesen a ti.

Este fue el mensaje enviado, nada fuera de lo común:

Good afternoon.

I am writing as the author of the show “sobre la marcha”, which was previously hosted on Spotify for Podcasters. I recently re-hosted the show on my own hosting server, and I would like to claim ownership and be able to manage it under my Apple Podcasts Connect dashboard. I hope this is the right method / channel to request so.

Looking forward to hearing from you,

~Gabriel Viso Carrera

PS – before today, the show’s feed was “https://anchor.fm/s/dd4f78/podcast/rss". As part of the migration, it has been placed a 301 permanent redirection to the feed I filled in this form; please take it into consideration of you see that the redirection hasn’t been followed in your systems yet. Please note that no further episodes will be appearing in such feed.

Te enviarán un correo en un plazo de un par de días, pidiéndote más datos (como el ID de tu cuenta en Apple Podcasts Connect), y dándote un código numérico que deberás introducir en algún campo del feed. Por ejemplo, mí me dieron como opciones el campo de <copyright />, <keyword /> o <verification />.

En negrita los aspectos clave que nos piden en esta respuesta de ejemplo, que es lo que me contestaron a mí con algunas cosas cambiadas.

Hello Gabriel,

Thanks for reaching out to us. I hope you’re doing well.

To get access to the show in Apple Podcasts Connect, we can transfer the ownership of it to your account.

To transfer ownership, enter the six-digit authorization code “381234” in the verification, keyword, or copyright fields of your RSS feed.

You can update the six-digit authorization code on your hosting provider’s platform or edit the metadata tags in your RSS feed. If you need assistance with this update, contact your hosting provider. We’ll review your request after we receive your reply.

When you reply, tell us where you entered the authorization code so we can find it and include the Account ID of your Apple Podcasts Connect account.

You can locate the Account ID on the Details pane in the Account section in Apple Podcasts Connect.

Example Account ID: 12a345bc6-d7ef-8901-2ghi-j3k4lm56n7o8

If you have additional questions related to this request, please reference case number 384791872432.

Best regards,

Mary Jane Apple Inc.

El feed que genera Castopod no tiene campo <verification />, pero como añadir campos a medida es sencillísimo, es la solución ideal porque nadie recibirá ese cambio de forma visible. Ve al panel de control de edición de tu podcast, y abajo de todo encontrarás un campo donde poder poner el campo extra:

Salva los cambios en tu podcast, verifica que en unos segundos, el feed tiene el mencionado campo dentro del objeto <channel />, y contesta a Apple con los datos que te han solicitado, que incluyen dónde pueden encontrar el valor en cuestión.

Good morning, Mary Jane.

Thanks for your prompt reply. As requested:My Podcasts Connect Account ID is 12a345bc6-d7ef-8901-2ghi-j3k4lm56n7o8.I’ve just included the code you provided in the tag of my feed, inside the <channel /> element:

<rss version=“2.0”> <channel> … ** <verification>381234</verification>** … </channel> </rss>

Thank you for your help and kind regards, ~Gabriel

Cuando recibas la confirmación y al cabo de un tiempo prudencial que te indicarán, deberías poder controlar tu relación con el directorio de Apple Podcasts tú mismo.

No tengas prisa en borrar cosas

En realidad ya está, pero es importante que no corras a Spotify y a tu feed a borrar cosas y deshacer cambios, porque puedes revertir el proceso sin querer.

1. Como comentaba en el apartado de la redirección permamente, no tengas demasiada prisa en borrar tu cuenta de Spotify, porque podrías perder oyentes.
2. Aún cuando ya tengas tu podcast en Apple Podcasts Connect, no corras a editar tu podcast en Castopod para retirar el campo de verificación. Ten en cuenta que el directorio de podcasts de Apple tienen páginas en todo el mundo, y no nos interesa que, por alguna razón, alguna versión antigua del feed se haya quedado en algún sitio y reasignen tu podcast a Spotify. Deja ese campo de verificación en tu feed el tiempo que te parezca oportuno.

Pues ya estaría

Hasta aquí mi experiencia. Espero que te resulte útil e interesante.

Pika Backup es una solución de copias de seguridad para GNU/Linux que, sin dejar de ser extremadamente sencilla de utilizar, proporciona características muy interesantes y es muy eficiente. Está basado en Borg Backup, un sistema que crea copias de seguridad comprimidas, cifradas, y que además detecta y elimina duplicados en la copia de seguridad.

Las características de Pika Backup que me han convencido han sido las siguientes:

• Permite realizar copias de seguridad a discos USB y a cualquier directorio remoto, y soporta Borg en el lado del servidor:

• Directorio “tonto”: cualquier directorio en donde tengas acceso local (por ejemplo, servicios tipo Drop Box o One Drive), y a localizaciones remotas “tradicionales” como servidores de ficheros FTP, o carpetas compartidas en red.

• En sí, esto ya es muy potente y versátil.

• Servicio remoto con soporte para Borg Backup, si quieres mejor rendimiento. Esto no es más que un servidor donde el ejecutable borg esté instalado, y al que tengas acceso por ssh. Una Raspberry Pi con el paquete borgbackup instalado y un disco duro enchufado por USB es suficiente para tener copias de seguridad en red en casa, con rendimiento mejorado.

• No hay por qué saber usar Borg; Pika Backup lo hace todo por ti, tanto en tu ordenador de trabajo como en tu servidor de copia de seguridad.

• Más adelante os cuento por qué esto es tan ventajoso.

• Permite tener más de una tarea de copia de seguridad configuradas sobre el mismo conjunto de datos, para poder tener tu copia de seguridad en varios lugares. Por ejemplo, en un servidor en red, donde ejecutas la copia de seguridad de forma programada, y en un disco externo por USB, donde ejecutas la copia manualmente, cuando te parece bien.

• Esto permite desarrollar una **estrategia 3:2:1 **sin salir de Pika Backup.

💡 Una estrategia 3:2:1 significa que deberíamos tener 3 réplicas de los datos, 2 de las cuales serían las copias de seguridad, ubicadas en sistemas almacenamiento diferentes, para 1 conjunto de datos en particular.

De esa forma, siempre nos protegemos en caso de daño físico tanto a nuestra estación de trabajo como a discos de las copias, siendo extremadamente difícil que fallen las tres réplicas a la vez.

• Es amigable para portátiles, porque detecta si el ordenador está conectado a la corriente, y si no lo está, ni siquiera intenta realizar la tarea de copia de seguridad programada.
• Proporciona filtros predefinidos para excluir de la copia de seguridad máquinas virtuales, contenedores, cachés y aplicaciones flatpak instaladas en el directorio de usuario. Esto simplifica bastante la configuración, aunque si no es suficiente, se pueden añador desde ficheros y carpetas individuales, hasta filtros basados en nombres de fichero y en expresiones regulares.
• Las copias de seguridad se pueden programar (hay reglas horarias, diarias, semanales, mensuales o anuales), y permite especificar el día y la hora 🎉. Esto parece baladí, pero si sabes que, por ejemplo, los domingos por la tarde el portátil va a estar en el escritorio con tareas de mantenimiento como actualizar el sistema, con sólo dejarlo enchufado la copia de seguridad se va a realizar automáticamente.

De por sí, las funcionalidades que proporciona Pika Backup en su interfaz gráfico son ya suficientes para convencerme; sobre todo el hecho de poder tener todas las copias de seguridad de mi estrategia 3:2:1 en la misma aplicación. Pero donde lo remata es en el aspecto de ser un cliente de Borg, y por lo tanto soportar servidores con Borg, para acelerar todas las operaciones de copia y restauración, y en especial la verificación de las copias de seguridad.

En general, hay que verificar las copias de seguridad, al menos cada cierto tiempo. Con ello nos aseguramos de que los archivos se han generado y almacenado correctamente, y que no hay nada corrupto. Y esto es un proceso que, si se hace en red, es muy costoso: Pika debería descargarse un trozo de la copia de seguridad desde el servidor de red, verificar su integridad, buscar el siguiente trozo, y así… hasta 130 GB en mi caso. He presenciado verificaciones de integridad hechas así que tardaron 20 horas. Y así es como se hace cuando Pika Backup deposita las copias de seguridad en un directorio de red, “tonto”, es decir, sin Borg.

Con Borg, la cosa cambia. El hecho de que Pika Backup esté basado en Borg Backup y, a todos los efectos, que sea un cliente de Borg, acelera el proceso de una forma drástica. Según la documentación de Borg, el proceso del lado del servidor realiza las operaciones de gestión de almacenamiento completas cuando se hace la copia de seguridad, y la verificación en sí. Esto incrementa el rendimiento sensiblemente, porque elimina el trasiego de datos por la red, y reduce el tiempo de verificación de una copia tan masiva como 130 GB de 20 horas a unos 35 minutos.

En general estoy muy contento con el cambio, ya que me permite realizar las cosas más eficientemente, utilizar mejor los recursos, y sobre todo, sobre todísimo, poder realizar todas las copias de seguridad de mi estrategia con la misma aplicación y de forma sencilla.

Extremadamente recomendable.

¿Cómo se compara Pika Backup con Déjà Dup?

Déjà Dup es una solución basada en duplicity que se ofrece, tradicionalmente, como parte del entorno de escritorio Gnome. Realiza copias de seguridad cifradas, incrementales, y las almacena en un formato de archivo comprimido que, independientemente de dónde almacenes estos archivos, preserva los permisos de los ficheros en tu máquina.

• Soporta discos externos y todo tipo de almacenamiento remoto –la lista completa se puede consultar en la documentación de duplicity, pero sólo soporta una única configuración para tu copia de seguridad. La copia de seguridad que configures, es única y a un sólo destino. Esto dificulta el realizar una estrategia de copias de seguridad robusta, 3:2:1, con la misma herramienta.
• Por otro lado, el sistema de copias de seguridad no tiene parte servidora, como la tiene Borg (y la aprovecha Pika Backup al ser éste un cliente gráfico y versátil de Borg); esto quiere decir que la verificación y el almacenamiento sea mucho más lento.
• No está bien pensado para portátiles, si es que han pensado en portátiles en absoluto.
• No permite escoger el día o la hora de las copias de seguridad programada. Si cuando configuras Déjà Dup las copias semanales caen en miércoles por el artículo 33, moverlas al domingo no es nada intuitivo, si es que el posible. Y, si cuando entra la copia de seguridad, te tienes que ir con tu portátil, el proceso se va a quedar por ahí medio enganchado.
• Las copias de seguridad programadas siempre se intentan realizar, estés funcionando en batería, sin red, o lo que sea. Esto consume energía y genera errores de forma innecesaria.

Todo este tipo de cosas hacen que Déjà Dup se vaya quedando atrás. Si bien es igual de sencillo de usar que Pika Backup, el ritmo al que añaden el tipo de funcionalidades que me afectan más es bastante bajo, casi diría que cae en la apatía, y estas cosas van desluciendo al producto poco a poco.

Comentarios previos

Antonio, el 8 de mayo de 2024 , comentó:

Gabriel, estupendo artículo muy interesante para los que tenemos que hacer respaldos de los archivos regularmente. Recomiendas alguno para macOS?. Gracias

Gabriel Viso Carrera, el 8 de mayo de 2024, respondió:

Para macOS solo tengo experiencia con Time Machine y Super Duper. Los dos hacen bien su tarea.

No descarto probar Vorta, que está basado en Borg Backup, igual que Pika Backup. Si quieres echarle un vistazo ve a https://vorta.borgbase.com