En homelab gestiono la virtualización con XCP-NG y Xen-Orchestra (XO). La realidad es que funciona muy bien, es muy estable y ¡son soluciones europeas! ¡Ole ahí esa soberanía tecnológica buena!

Recientemente he instalado y configurado Pocket-ID para intentar centralizar la identidad a lo largo de todos los servicios que tengo desplegados. Que, si bien no son muchísimos, es preferible no tener una contraseña diferente para cada servicio.

Creación cliente OIDC en Pocket-ID

Desde el panel de administración de Pocket-ID, buscamos la opción para crear un nuevo cliente:

En esta nueva pantalla, rellenaremos los datos necesarios:

• Name: ``Xen-Orchestra` (o lo que decidamos)
• Client Launch URL: La URL desde la que nuestra instancia de XO es accesible.
• Callback URLs: host-xo/signin/oidc/callback (siendo host-xo la URL de nuestra instancia, diferenciando entre HTTP y HTTPS).
• El resto de datos podemos editarlos al gusto: imagen, client id, etc.

Al guardar la configuración se mostrarán los detalles:

Depende de cómo tengamos configurado el entorno, puede ser necesario añadir grupos o usuarios autorizados para usar esta aplicación.

Configuración Xen-Orchestra

PREVIO: Usuario admin local

En este momento se asume que ya hay un usuario local como administrador en el entorno de Xen-Orchestra. En mi caso, y creo que es una buena práctica, voy a mantener el usuario local, para seguir teniendo acceso al sistema si fallara la autenticación centralizada.

Opcional: creación de usuarios OIDC

Los usuarios que no existan en el sistema de XO, pero que se hayan podido autenticar con Pocket-ID (o el sistema OIDC en uso), se crearán en XO. Por seguridad, se crearán sin permisos.

Si conocemos los usernames de los usuarios a generar en el sistema, podemos crearlos y asignar los permisos y pertenencia a grupos adecuados. Al hacerlo, al iniciar sesión con el SSO, ya podrán disfrutar de los permisos adecuados.

Configuración y activación plugin auth-oidc

La funcionalidad de iniciar sesión SSO con OIDC en XO es provista por el plugin auth-oidc. Lo encontraremos en Settings > Plugins.

Antes de activarlo, hemos de configurarlo, con los datos datos mostrados en Pocket-ID y las características de nuestro entorno (en mi caso, tomo el campo preferred_username de Pocket-ID como username en XO).

Tras guardar la configuración, hemos de activar el plugin.

Probar el SSO

Una vez guardados los cambios en XO, si abrimos una ventana privada (para que nuestras cookies de inicio de sesión no interfieran) veremos dos formas de iniciar sesión:

• Sign in with OpenID Connect (nuevo)
• Inicio de sesión con usuario y contraseña (como hasta ahora)

Al hacer clic en la primera opción, nos aparecerá la pantalla de Pocket-ID para iniciar sesión:

Si todo ha funcionado correctamente, se iniciará sesión en XO. Si el usuario es nuevo, se creará en XO (sin permisos). Al no tener permisos, no podrá realizar ninguna acción:

Asignar permisos a los nuevos usuarios

Como se ha comentado anteriormente, se pueden crear los usuarios de forma previa al primer inicio de sesión y asignarles los permisos adecuados.

Si no, siempre se puede, una vez creado el usuario (automáticamente con el primer inicio de sesión vía OIDC), actuando como un usuario que sea administrador, buscar el usuario en Settings > Users y asignarle los permisos adecuados:

¡Hemos terminado!

En este momento hemos terminado de configurar el inicio de sesión único en Xen-Orchestra contra Pocket-ID, y hemos comprobado que funciona correctamente.

¿Alguna duda?

No dudes en ponerte en contacto conmigo para cualquier duda, sugerencia, queja o aclaración que creas necesaria. ¡Será un placer hablar contigo!

Cualquier persona que me conozca sabe que me gustan, entre muchas otras, dos cosas:

• Quejarme, de forma constructiva, de muchas cosas.
• Quejarme del procedimiento de gestión de quejas.

¡Y aquí estamos, otra vez, con la misma cantinela!

A través de la App Madrid Móvil la ciudadanía puede, entre otras cuestiones, plantear avisos. Es la evolución del teléfono 010^[1].

Entre estos avisos, se pueden plantear avisos relativos a desperfectos en las calzadas y aceras, como pueden ser alcantarillas sueltas.

Sin embargo, el Ayuntamiento no tiene competencia para intervenir en aquellos registros (alcantarillas) que gestiona el Canal de Isabel II^[2].

Estos son algunos ejemplos de alcantarillas que gestiona el Canal de Isabel II (en adelante, CYII):

Si bien en la imagen de la izquierda se puede ver claramente la identificación del CYII, no ocurre lo mismo con la imagen de la alcantarilla circular, en la que pone claramente «Ayuntamiento de Madrid».

Cualquiera podría pensar, como yo inicialmente pensé, que si hay algún problema con este elemento, habría que notificarlo al Ayuntamiento; aunque finalmente no sea así.

Pero, ¿qué pasa si se reporta el aviso al Ayuntamiento para una alcantarilla que no es competencia suya?

El Ayuntamiento, amablemente, responde al aviso indicando lo siguiente:

Sinceramente, creo que es buen aviso: te explica el motivo de la cancelación y te facilita la vía de contacto para comunicarlo al CYII a través del teléfono y a través de la Oficina Virtual del Canal de Isabel II.

Pero, ¿y si pudiera mejorarse el proceso? Aunque no tengo cifras oficiales para sustentar mi opinión, estoy bastante seguro de que para este tipo de avisos (desperfectos en calzada o acera/alcantarilla), muchos se acaban cancelando por ser responsabilidad de CYII.

Quizá se podría añadir una casilla para que la ciudadanía autorizase al Ayuntamiento, en el caso de que no sea el responsable de la reparación, a comunicarla en su nombre a la entidad responsable de su gestión. Es una casilla para el usuario, y estoy seguro de que la comunicación Ayto-CYII no sería complicada.

En mi opinión, redundaría en menor frustración y fricción y en un mejor servicio público. Más cuando el propio Ayuntamiento de Madrid recoge en su Plan de Calidad Institucional 2023-2027 este objetivo^[1].

P.D.: Como las quejas, además de en el bar, hay que plantearlas donde corresponde, ya está planteada la sugerencia 502/2026/013648 ante el Ayuntamiento para su toma en consideración.

Cuando una aplicación necesita elevación de privilegios (permisos de Administrador) para ejecutarse, suele aparecer una pantalla similar a la siguiente:

El objetivo deseado es que se solicite no solo la confirmación, sino también la autenticación del usuario cada vez, para aumentar la seguridad (siempre teniendo en cuenta que es recomendable no trabajar con un usuario con permisos de Administrador sobre el equipo). Tal que así:

Proceso

1-Evitar que se muestren las cuentas durante la elevación

Hemos de usar el editor de directivas de grupo local (Win+R, gpedit.msc), y editar la clave Enumerar las cuentas de administración al realizar una elevación, en la ruta: Configuración del equipo > Plantillas Administrativas > Componentes de Windows > Interfaz de usuario de credenciales.

Se ha de marcar la opción deshabilitada. De esta forma, los usuarios siempre deberán escribir un nombre de usuario y una contraseña para realizar la elevación.

2-Requerir usuario y contraseña durante la elevación

Además de no mostrar el nombre de usuario, al activar esta opción hacemos que sea necesaria la autenticación completa:

Hemos de abrir el Editor de Registro (Win+R > regedit) y buscar la clave SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\ConsentPromptBehaviorAdmin. Esta entrada permite definir 6 valores distintos.

En nuestro caso, se establecerá el valor 1: This option prompts the Consent Admin to enter his or her user name and password (or another valid admin) when an operation requires elevation of privilege. This operation occurs on the secure desktop.

¿Alguna duda?

No dudes en ponerte en contacto conmigo para cualquier duda, sugerencia, queja o aclaración que creas necesaria. ¡Será un placer hablar contigo!

Nota: para realizar las capturas de pantalla de la ventana de credenciales UAC ha sido necesario definir el valor de la clave ConsentPromptBehaviorAdmin en 3, para evitar que esta abriera en el Escritorio Seguro.

Recently, I faced a puzzling issue: a VPN client could reach my Linux server (packets arrived at the interface), but no responses were sent back. Services running in Docker were unreachable, even though ports appeared open in nmap.

Root Cause

A newly deployed Docker stack automatically created a network using the range 192.168.0.0/20. This overlapped with my VPN subnet (192.168.3.0/24). As a result:

• Incoming packets from the VPN were routed correctly to the server.
• The server’s response packets were routed through the Docker bridge (because of the overlapping range), causing asymmetric routing.
• Linux’s rp_filter and firewall dropped these responses silently.

Symptoms

• tcpdump showed ICMP requests arriving, but no replies leaving.
• ip route get VPN-client-IP revealed the wrong egress interface (br-xxxx instead of the VPN interface).

Solution

Update Docker network to avoid conflicts. In the docker-compose.yml:

services:
  service_name:
  [...]
    networks:
      - custom_net
[...]
networks:
  custom_net:
    driver: bridge
    ipam:
      config:
        - subnet: 172.30.1.0/24
          gateway: 172.30.1.1

And then restart the compose stack.

Lesson Learned

Always define custom IP ranges for Docker networks or configure default-address-pools to avoid automatic allocation in common ranges like 192.168.x.x. Overlapping subnets can silently break routing and connectivity.

Any doubts?

Do not hesitate to contact me with any questions, suggestions, complaints, or clarifications you may have; I'll be happy to talk to you!

Recientemente he llegado a esta nota de prensa del Ministerio para la Transformación Digital y de la Función Pública:

La entrada en la web dice así:

El ministro para la Transformación Digital y de la Función Pública, Óscar López, acompañado por la secretaria de Estado de Función Pública, Clara Mapelli, ha presentado ‘Consenso por una Administración Abierta’, la estrategia de transformación de la Administración con la que se pretende dar el salto hacia una Administración de altas capacidades.
[...]
El proyecto de transformación se inició en marzo de 2024 con la publicación del documento marco ‘Consenso por una Administración Abierta’; posteriormente, se ha ido desarrollando en los laboratorios de la Administración y se ha construido gracias a un proceso participativo en el que se han implicado más de 400 personas de la sociedad civil, sindicatos, empresarios, universidades y resto de administraciones. Ese trabajo de consenso da como resultado una estrategia de transformación que se asienta sobre cuatro ejes y que engloba 18 proyectos, algunos de los cuales ya están en marcha.

Por tanto, el documento marco, Consenso por una Administración Abierta, parece la piedra angular de la publicación, ¿cierto? Pero… ¿Cómo se accede al mismo? Debería haber algún enlace por algún lado…

¡Pero no! Al final de la publicación en la web se puede leer lo siguiente:

Si el lector/a quiere acceder al documento, debe:

1. Navegar hasta el final de la página.
2. Hacer clic en el enlace Nota de prensa.
3. Desplazarse, en el PDF de la nota de prensa, hasta la página 6 del documento (última).
4. Sacar el móvil
5. Abrir la cámara
6. Apuntar al QR y leerlo
7. Y ya, si quiere leerlo en el ordenador, compartir el enlace por cualquier otra vía.

¿Existen vías alternativas? Bueno, pues siempre se puede poner un enlace. Sí, como el anterior, que lleva a la página del Mº que trata sobre la estrategia/documento Consenso por una Administración Abierta.

En fin, hablemos de IA... 😭😭

Inspired by this post by Anarcat, I've developed a Python script to parse Caddy (a web server and reverse proxy) logs to get information about the top IP and ASN visiting the sites behind Caddy.

Traffic meter per ASN without logs

anarcat

anarcat

This tool analyzes Caddy web server logs to:

1. Extract client IP addresses (handling both direct connections and Cloudflare-proxied requests)
2. Count request frequency per IP address
3. Look up ASN (Autonomous System Number) information for each IP
4. Generate summaries and statistics about traffic patterns
5. Export data to JSON for further analysis
6. Load previously saved data for review without reprocessing logs

Python script code

The key difference with other similar tools is that it allows you to see the real visitor IP behind Cloudflare (using X-Forwarded-For header) when present, instead of the base client_ip present on Caddy Logs

The Python script is published on Github, below I detail the features:

GitHub - gonzaleztroyano/asn-counters-caddy: A powerful Python utility for analyzing Caddy web server logs to summarize IP addresses and ASN information from requests.

A powerful Python utility for analyzing Caddy web server logs to summarize IP addresses and ASN information from requests. - gonzaleztroyano/asn-counters-caddy

GitHubgonzaleztroyano

Features

• IP Detection Logic:

  • Extracts original client IPs from Cloudflare X-Forwarded-For headers
  • Uses remote_ip for direct connections
  • Handles both IPv4 and IPv6 addresses

• ASN Lookup:

  • Identifies the network/organization behind each IP address
  • Uses MaxMind MMDB format databases (compatible with GeoIP2, IPinfo, DB-IP)
  • Shows ASN numbers and organization names

• Multiple Input Options:

  • Process individual log files
  • Process multiple log files at once
  • Use glob patterns to match logs (e.g., logs/caddy-2025-*.log)
  • Read from stdin for piped input
  • Support for compressed (.gz) log files

• Data Management:

  • Save results to JSON files for later analysis
  • Load previously saved data without reprocessing logs
  • Append new data to existing analysis
  • Overwrite existing files with new results

• Analysis Output:

  • Shows top N IPs by request count (customizable)
  • Shows top N ASNs by request count
  • Provides percentage statistics for ASNs
  • Formatted tables for easy reading

Any doubts?

Do not hesitate to contact me with any questions, suggestions, complaints or clarifications you may have, I'll be happy to talk to you!

When your favorite grammar checker decides to ghost your favorite LaTeX editor 📝

TL;DR

LanguageTool started blocking Overleaf with a "temporarily disabled" message. We reverse-engineered the extension, found the culprit, and created a client-side patch that bypasses the restriction entirely. Here's how we did it and how you can fix it too.

The problem: When extensions go rogue

If you're a LaTeX user who relies on LanguageTool for grammar checking, you've probably hit this frustrating wall:

Lo sentimos, LanguageTool ha deshabilitado temporalmente el soporte 
para este sitio web. Estamos trabajando en una solución. 
Debería ser cuestión de días.

Translation: "Sorry, LanguageTool has temporarily disabled support for this website. We're working on a solution. It should be a matter of days."

The Investigation: Going Down the Rabbit Hole

Step 0: Asking for support

As a LanguageTool user and suscriber I have access to the support team. I reached them with some screenshoots and, after some interactions, they replied me that they were aware of the issue and the haven't had and ETA.
The offered me a reimbursement, but I'd like to keep using Language Tool, as I found it really useful!

Step 1: Finding the Smoking Gun

First, I dug into the extension's localization files to trace where this message comes from. In _locales/es/messages.json, there it was:

{
  "siteTemporarilyUnsupported": {
    "message": "Lo sentimos, LanguageTool ha deshabilitado temporalmente..."
  }
}

The message key siteTemporarilyUnsupported was our first clue.

Step 2: Following the Breadcrumbs

Using grep to search through the minified JavaScript files, I found this logic in popup.js:

ff.isDomainSupported(Z_) ? 
  ff.isDomainExcludedByGroupPolicy(Z_) && (d.supported=!1, d.unsupportedMessage=In.getMessage("siteDisabledPerGroupPolicy")) : 
  (d.supported=!1, d.unsupportedMessage=In.getMessage("siteTemporarilyUnsupported"))

Bingo! When isDomainSupported() returns false, it triggers our dreaded error message.

Step 3: The Remote Config Revelation

Digging deeper, I discovered that LanguageTool uses a remote configuration system. The extension fetches domain blacklists from:

https://languagetool.org/webextension_config.json

The isDomainSupported function checks against this dynamically updated list:

isDomainSupported(e) {
  return !this._configuration || 
         !this._configuration.unsupportedDomains.includes("*") && 
         !Hr._isListContainsDomain(this._configuration.unsupportedDomains, e)
}

The thing here is that overleaf.com was not on this list! Only "seleniumbase.io" appears at the moment of writing.

Step 4: The Domain Matching Logic

The _isListContainsDomain function is particularly clever—it supports wildcard subdomain matching:

function Mt(e,t) {
  const r = Ut(t);  // Normalize domain
  return (e||[]).some(e => {
    const t = Ut(e);
    return t === r || r.endsWith("." + t)  // Exact OR subdomain match
  });
}

This means if overleaf.com is blocked, so are www.overleaf.com, v2.overleaf.com, etc.

The Solution: Client-Side Liberation

The Strategy

Instead of trying to fight the remote configuration (which we can't control), we implement a client-side override. The beauty of browser extensions is that once you have the code, you can modify it.

The Implementation

The fix is elegantly simple. We modify the isDomainSupported function to always return true for Overleaf domains, regardless of what the remote config says:

isDomainSupported(e) {
    // Always allow overleaf.com and its subdomains
    if(e && (e.includes('overleaf.com') || e.endsWith('overleaf.com'))) {
        return true;
    }
    // Original logic continues...
    return !this._configuration || 
           !this._configuration.unsupportedDomains.includes("*") && 
           !Hr._isListContainsDomain(this._configuration.unsupportedDomains, e)
}

Files That Need Patching

LanguageTool's architecture spreads this function across multiple contexts:

• background.js - Main extension logic
• content.js - Injected page scripts
• popup.js - Extension popup interface
• validator/validator.js - Grammar validation engine
• toolbox/toolbox.js - Writing tools interface
• options/options.js - Settings management
• And several others...

Each file contains its own minified version of the domain checking logic, so they all need the same patch.

Happy LaTeX writing, everyone! 🎉

BOSCO es el programa informático (software) que decidía sobre si una persona era, o no, beneficiaria del bono social.

Tras recibir las quejas de muchas personas, la Fundación Ciudadana Civio (unas personas maravillosas a las que recomiendo seguir y, si puedes permitírtelo, hacerte socio) comprobó que este programa estaba denegando el bono social a personas que sí que tenían derecho a recibirlo.

Al detectar este problema, Civio solicitó, amparándose en la Ley de Transparencia, el acceso al código fuente del programa para poder comprobar su funcionamiento, su lógica y, en definitiva, entender el funcionamiento de esta pieza de software (desarrollada con dinero público) para poder arreglarlo.

Este proceso comenzó en 2018 y es ahora, 7 años después, cuando el Tribunal Supremo ha fallado en favor de Civio, obligando al Ministerio para la Transición Ecológica a dar acceso a Civio al código fuente del programa BOSCO.

No ha sido un camino fácil, la Transparencia ^[1] nunca suele serlo lamentablemente: desde su sulicitud hasta el actual resultado favorable han tenido que pasar silencios administrativos, reclamaciones al Consejo de Transparencia y Buen Gobierno, y 3 sentencias judiciales de por medio (Juzgado Central de lo Contencioso-Administrativo n.º 8, Audiencia Nacional y Tribunal Supremo).

Esta sentencia crea jurisprudencia y establece que conocer las tripas de los programas y algoritmos que usan las administraciones públicas es un derecho democrático.
Estima que los riesgos de publicar un software (y en general aplicable a cualquier tipo de solicitud de Transparencia) han de ser ponderados cada caso (como ya ha estimado en otras ocasiones).

La transparencia algorítmica y la Transparencia de las AAPP en este sentido es importante, y una obligación, como afirma la sentencia, pues permiten “explicar de forma comprensible el funcionamiento de los algoritmos que se emplean en la toma de decisiones que afectan a los ciudadanos para permitirles conocer, fiscalizar y participar en la gestión pública”.

La propiedad intelectual ni la seguridad no pueden suponer una opción de carta blanca para permitir a las AAPP denegar acceso a información pública, en definitiva.

Desde aquí no puedo más que felicitar a Civio por su trabajo, por su insistencia y por creer, y luchar por, un mundo mejor.

Puedes acceder a su web, donde lo explican infinitamente mejor que yo a través del siguiente enlace:

https://civio.es/novedades/2025/09/17/civio-abre-camino-en-la-transparencia-algoritmica-el-supremo-condena-al-gobierno-a-entregar-el-codigo-fuente-de-bosco/

Y, de nuevo, te invito a apoyarles de la mejor forma que puedas. 🤓🙃

Preparando informes con los datos publicados como parte del informe ISPA 2024, me he topado con un valor curioso:

La siguiente tabla está ordenada por la columna percibido_periodo2, que es el sueldo del alcalde/alcaldesa a partir de las elecciones municipales de 2023.

Obviamente, para cualquier persona que (1) sepa un poco de análisis de datos y (2) conozca nuestro país, sabe que es altamente improbable que un municipio como Dos Aguas, con una población de 338 personas, según el INE, pague a su alcalde tal cantidad de dinero.

Se trata de un error presente en los datos que el Mº de Transformación Digital y de la Función Pública ha publicado, tal y como se puede ver en la siguiente captura del PDF:

Este error nos recuerda la importancia de validar la introducción de datos y aplicar restricciones en este tipo de inputs.

Por supuesto, este error ya ha sido notificado a través del buzón de sugerencias y mejoras del Espacio ISPA.

¡Datos corregidos!

Tras ponerlo en conocimiento de la unidad competente, la información publicada ya ha sido corregida. ¡¡Bien!!

We can think about the Pi-hole as a local NTP cache. Or, more RFC2030-compliant, a lower stratum NTP server. In our home scenario, the added delay (much lower than a second) is almost negligible.

On the other hand, thinking about the common good of the Internet (and also on the NTP server admin team & service), having a NTP cache is a really efficient, as the stratum 1 server only receive request from one device (Pi-hole server) instead of all the devices that you have (can be tens of them).

On the following diagram can be seen graphically:

Activating Pi-hole's NTP server

On the Pi-hole admin panel, we've to activate Expert settings, clicking on the toggle on the top right corner of the Settings > System page.

After doing so, a new option appears on the Settings submenu (marked as 5 on the capture below):

Setting upstream NTP server

As I've stated before, here in Spain the official time is distributed by the Army Royal Observatory (ROA, Real Observatorio de la Armada), so to configure Pi-hole to query this Stratum 1 server, we must set the following option/variable [6 on the following image]:

Configure clients:

It's recommended to set the DHCP options, if available, as it's practical. The problem is that most of the clients ignore this option to choose the one hardcoded or default (time.windows.com on Windows, for example).

So to set the Pi-hole as NTP server for local clients, just follow the instructions on Windows or Linux.

Any doubts?

Do not hesitate to contact me with any questions, suggestions, complaints or clarifications you may have, I'll be happy to talk to you!

As a Caddy Server user, I faced a strange error today^[1].

I'm on my way to change my browser (previously Chrome and Edge) to Firefox and when trying to access some of my sites (the ones not proxied by Cloudflare) the following error appeared on Firefox:

Problem

Of course, if not DNS, it's certificate chain trust ;(.

If tried to connect to the server/page/domain with the echo "" | openssl s_client -showcerts -servername *****.glez.cloud -connect *****..glez.cloud:443 command, I receive the following errors:

verify error:num=20:unable to get local issuer certificate [...]
verify error:num=21:unable to verify the first certificate [...]
Verification error: unable to verify the first certificate [...]
Secure Renegotiation IS NOT supported [...]
Verify return code: 21 (unable to verify the first certificate) [...]

Solution

Although I would be the only user facing this error, these kinds of things are the ones that have to be solved when encountered. If not, the debt could be worse next time.

So, to solve this problem, we have to identify it first: the server is not sending the full certificate chain, only the leaf certificate.

To make Caddy send the full certificate, the certificate file path on the tls directive of the CaddyFile has to point not to the leaf certificate, but to the fullchain file. In case you are using Let's Encrypt, the paths will be:

Change tls /etc/letsencrypt/live/*domain*/cert.pem to tls /etc/letsencrypt/live/*domain*/fullchain.pem

Any doubts?

Do not hesitate to contact me with any questions, suggestions, complaints or clarifications you may have, I'll be happy to talk to you!

A la hora de configurar NTP en Linux (& Co.) parece a primera vista que la única opción es usar ntpd.

En mis equipos me gusta indicar los servidores NTP a usar para la sincronización de hora. Pero como la mayoría de los tuturiales están enfocados a ntpd, si este daemon no está instalado, al ir a editar el archivo /etc/ntp.conf, recibirás un error de archivo inexistente. ;(

Sin embargo, en muchos sistemas, por su mayor simplicidad y reducido tamaño es chrony el daemon instalado por defecto. La configuración es realmente sencilla, y se gestiona a través del archivo /etc/chrony.conf

Para configurar servidores de tiempo (NTP) para España (en mi caso, uso los del ROA y RedIRIS), basta con editar el archivo añadiendo lo siguiente, y eliminando las otras referencias existentes a otros servidores:

pool ntp.roa.es
pool hora.rediris.es

Quedando de la siguiente manera el archivo:

Una vez editado el archivo, basta con reiniciar el servicio:

service chronyd restart

Y para ver el estado de sincronización podemos usar:

chronyc sources

En la docmentación de chronyc podemos ver qué significa cada valor de salida del comando.

Igualmente, con chronyc tracking podemos ver el detalle de la sincronización del reloj:

Si bien hay ciertas recomendaciones de usar pool.ntp.org y sus variantes locales, en mi caso me gusta usar:

• El NTP del Real Observatorio de la Armada (ROA), ntp.roa.es, o sus direcciones:

  • 150.214.94.5 (en FQDN, hora.roa.es)
  • 150.214.94.10 (en FQDN, minuto.roa.es)
  • Sin IPv6 😫

  El ROA es la institución encargada de proporcionar el tiempo oficial dentro de España. Véase Real Decreto 1308/1992 y Ley 32/2014

• El NTP de RedIRIS (Red Académica y de Investigación española), que toma como referencia el anterior, hora.rediris.es, o sus direcciones:

  • 130.206.3.166
  • 2001:720:418:cafa::166

(Actualización) Otros servidores

Los servidores arriba indicados son, quizá, demasiado opinionated^[1], así que por aquí comparto otros más comunes:

• time.windows.com, es el predeterminado de Windows.
• time.google.com, ofrecido por Google.
• time.cloudflare.com, ofrecido por Cloudflare
• es.pool.ntp.org., dirección de los servidores NTP para España dados de alta en el proyecto NTPpool.org.

Implicaciones de privacidad y geopolítica aparte, se pueden usar cualquiera; ¡y combinarlos, claro!

Configurar NTP en Windows

Por defecto, windows usa ``time.windows.net``, que si bien funciona puede no ser lo más deseable.

Para cambiarlo a los indicados anteriormente, es necesario abrir una consola de Powershell (con privilegios de administración) y ejecutar:

w32tm /config /manualpeerlist:"ntp.roa.es hora.rediris.es" /syncfromflags:manual /update

💡 Es posible indicar un servidor con prioridad sobre otro, modificando levemente el comando anterior. En el siguiente ejemplo, el servidor predeterminado es ``hora.roa.es`` y se utiliza ``time.cloudflare.com`` como servidor de respaldo:

w32tm /config /syncfromflags:manual /manualpeerlist:"hora.roa.es,0x8 time.cloudflare.com,0x2" /update

Para reiniciar el servicio:

Stop-Service w32time
Start-Service w32time

Comandos útiles

Comprobar aplicación

Podemos comprobar si los cambios se han guardado correctamente ejecutando el comando:

w32tm /dumpreg /subkey:parameters

Dará como resultado:

Forzar sincronización

w32tm /resync

Fuente: Documentación oficial de Microsft

Configurar NTP en Linux con Chrony

https://blog.gonzaleztroyano.es/tech-notes/configurar-ntp-con-chrony-conf/