Command Line - Linux

Gestire Timezone e Sincronizzazione dell’ora su AlmaLinux

Nell’architettura di un’infrastruttura IT di classe enterprise, la gestione del ora non è un semplice dettaglio sistemistico, ma un pilastro della sicurezza e dell’integrità dei dati. La corretta sincronizzazione temporale e la configurazione dei fusi orari rappresentano requisiti imprescindibili per garantire la validità dei certificati, la coerenza delle transazioni nei database distribuiti e l’accuratezza della tracciabilità nei log di sistema. Vediamo le metodologie standard per governare questo aspetto attraverso timedatectl e il protocollo NTP, assicurando un ambiente server conforme agli standard.

La gestione del fuso orario (Timezone)

Per prima cosa controlliamo la configurazione attuale del sistema su cui stiamo operando. In questa guida si fa riferimento ad AlmaLinux ma gli stessi comandi sono validi anche per altre distribuzioni come RockyLinux, CentOS, …

Utilizzando il comando timedatectl, è possibile verifica l’ora corrente del sistema ed i parametri di configurazione

timedatectl status

L’output visualizza un report per identificare eventuali disallineamenti tra il fuso orario configurato e le reali necessità dell’infrastruttura.

               Local time: Sat 2026-01-31 11:37:06 CET
           Universal time: Sat 2026-01-31 10:37:06 UTC
                 RTC time: Sat 2026-01-31 10:37:06
                Time zone: Europe/Rome (CET, +0100)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

Qualora il sistema riporti RTC in local TZ: yes, si sta operando in una modalità non ottimale per gli ambienti server. Per garantire la massima stabilità e conformità agli standard POSIX, è consigliato forzare l’orologio hardware sull’ora universale:

sudo timedatectl set-local-rtc 0

Questa configurazione assicura che il kernel gestisca i fusi orari esclusivamente a livello software.

Vediamo ora come cambiare il fuso orario. Tramite il comando

timedatectl list-timezones

viene visualizzato l’elenco di tutti i fusi orari supportati (possiamo filtrare con grep)

[...]
Europe/Oslo
Europe/Paris
Europe/Podgorica
Europe/Prague
Europe/Riga
Europe/Rome
Europe/Samara
Europe/San_Marino
Europe/Sarajevo
Europe/Saratov
[...]

e una volta individuata la stringa corretta (es. Europe/Rome), utilizziamo il comando set-timezone con privilegi di root per applicare il fuso orario corretto

sudo timedatectl set-timezone Europe/Rome

Questa operazione aggiorna automaticamente il link simbolico in /etc/localtime che punta ai database in /usr/share/zoneinfo/

Sincronizzare l’ora con Chrony

In ambito enterprise (ma non solo), impostare manualmente l’ora è sconsigliato. È necessario configurare Chrony, l’implementazione predefinita di NTP (Network Time Protocol) su AlmaLinux. Per prima cosa dobbiamo installarlo qualora non fosse presente

sudo dnf install chrony

ed abilitare il servizio in modo che venga avviato al boot del sistema

sudo systemctl enable --now chronyd

Per monitorare lo stato dei server NTP esterni a cui il sistema è collegato possiamo utilizzare il comando

chronyc sources list

che restituisce in output

MS Name/IP address         Stratum Poll Reach LastRx Last sample
===============================================================================
^+ 81.56.230.156                 2   8   377     7   +427us[ +427us] +/-   36ms
^* time.cloudflare.com           3  10   377   325  -1899us[-2255us] +/-   25ms
^+ 172-232-209-103.ip.linod>     2  10   377   302  +2741us[+2741us] +/-   27ms
^+ kraken2.bilink.net            3  10   377   193  -1009us[-1009us] +/-   47ms

oppure

chronyc sources -v

pche ermette di avere oltre all’elenco dei server anche una legenda descrittiva delle varie colonne

  .-- Source mode  '^' = server, '=' = peer, '#' = local clock.
 / .- Source state '*' = current best, '+' = combined, '-' = not combined,
| /             'x' = may be in error, '~' = too variable, '?' = unusable.
||                                                 .- xxxx [ yyyy ] +/- zzzz
||      Reachability register (octal) -.           |  xxxx = adjusted offset,
||      Log2(Polling interval) --.      |          |  yyyy = measured offset,
||                                \     |          |  zzzz = estimated error.
||                                 |    |           \
MS Name/IP address         Stratum Poll Reach LastRx Last sample
===============================================================================
^+ 81.56.230.156                 2   8   377   258   +427us[ +427us] +/-   36ms
^* time.cloudflare.com           3  10   377   576  -1899us[-2255us] +/-   25ms
^+ 172-232-209-103.ip.linod>     2  10   377   553  +2741us[+2741us] +/-   27ms
^+ kraken2.bilink.net            3  10   377   444  -1009us[-1009us] +/-   47ms

molto utile per interpretarne i valori restituiti.

Per modificare i server NTP, è necessario intervenire direttamente sul file di configurazione di chrony. Questa operazione è fondamentale per puntare a sorgenti certificate o a server NTP interni. Il file di configurazione è /etc/chrony.conf e possiamo modificarlo con un editor di testo con privilegi di root:

sudo vi /etc/chrony.conf

Individuare le righe che iniziano con server o pool. La differenza tra i due è

  • pool: utilizza un cluster di server (consigliato per ridondanza)
pool 2.almalinux.pool.ntp.org iburst   # Default nelle installazioni Almalinux
pool pool.ntp.org iburst

  • server: utilizza un server specifico
server 192.168.1.100 iburst

Il parametro iburst permette di accelerare la sincronizzazione iniziale effettuando più tentativi ravvicinati al primo avvio

Dopo aver salvato il file, riavviare il demone per caricare la nuova configurazione

sudo systemctl restart chronyd

e con i comandi visti in precedenza possiamo verificare il corretto funzionamento delle modifiche applicate.

Perché è importante

Mantenere un sistema con il fuso orario e l’ora corretta è fondamentale. Una configurazione errata può causare

  • Errori di Autenticazione: molti protocolli falliscono se lo scostamento temporale è superiore a pochi minuti
  • Difficoltà nel Debug: log con timestamp sfasati rendono impossibile correlare eventi tra server diversi
  • Incongruenze nei dati: nelle applicazioni distribuite, l’ordine cronologico delle operazioni è essenziale per l’integrità dei dati