En determinadas tareas y en ciertos campos de la Ciencia resulta absolutamente necesario conocer con precisión la hora exacta. Piénsese en la sismología, astrofísica, en la gestión de paquetes a traves de routers, etc... En otras muchas no se necesita tanta precisión, pero no negarán que eso de tener la hora exacta (bueno, con algunos milisegundos de variación) despierta al menos la curiosidad.
Existe un protocolo en internet llamado NTP (Network Time Protocol) que, como su nombre indica, sirve para sincronizar los relojes en una red. Todo esto está fundamentalmente desarrollado por el Profesor David Mills y sus colaboradores en la Universidad de Delaware.
Además del protocolo de comunicaciones entre ordenadores, lo que más llama la atención es la sencillez (y robustez) del algoritmo que se sigue para conseguir que todos los relojes de la red esten sincronizados y con la hora precisa. Pueden consultarse los detalles en este documento. De forma superficial y poco extensa comentaré un poco acerca de cómo funciona.
NTP está organizado en una jerarquía dinámica de servidores. El servidor de orden superior recibe la calificación de Stratum-0. Se trata de los propios relojes de precisión que tienen determinados sistemas. Los relojes Atómicos de Cesio y los Satélites GPS son dos buenos ejemplos. Ningún ordenador tiene esa categoría, porque ellos toman la hora de los stratum-0 que en la mayoría de las ocasiones tienen integrados como subsistemas. Así pues, los servidores que toman su hora de los stratum-0 son a su vez Stratum-1, es la máxima jerarquía que puede alcanzarse en la Internet. Cualquier ordenador que tome como referencia un Stratum-1 es un Stratum-2. De forma general un sistema que tome como referencia un Stratum-n es un Stratum-(n+1). El nivel más bajo que hay definido es un Stratum-16.
Así pues, en la Internet hay unos cientos (pocos) de Stratum-1 que son tomados como refencia por unos cuantos miles de Stratum-2 que a su vez dan la hora a muchos mas Stratum-3 etc...
La jerarquía es dinámica. Un mismo sistema puede ser en un momento stratum-3 y en otro Stratum-2, incluso Stratum-16 cuando pierde la sincronización, dependerá en cada momento de qué servidor tome como referencia.
Al mismo tiempo, si el sistema ya ha corrido ntpd durante un tiempo suficiente en una sesión anterior, lee la última corrección que hay que hacer a la frecuencia interna del reloj para mantener la hora correcta en un márgen adecuado. Cada ordenador calcula su hora contando los ciclos que completa determinados osciladores. A éstos se les supone una frecuencia que puede que no sea la correcta. Pues bien, NTP es capaz de estimar su error e imponer al Kernel que tenga en cuenta esa corrección.
Al inicio de la sesión, el ordenador se supone no sincronizado. Comienza a leer información horaria de sus peers a un ritmo primero rápido de unos 64 segundos (concretamente 2^minpoll) después cada 128, más tarde 256 y así hasta un ritmo de 2^maxpoll segundos (por defecto maxpoll = 10).
Cada vez que recibe una nueva referencia de alguno de sus peers el demonio ntpd recalcula los parámetros de ese peer, esto es, su desfase respecto del reloj local, el retardo en la red y la dispersión de sus datos. A continuación elige como referencia el mejor y solamente el mejor de los peers con los que contacta, una vez que hayan superado unos mínimos umbrales de calidad.
Cuando se alcanzan las condiciones mínimas de estabilidad entonces nuestro ordenador se declara sincronizado y adquiere el estatus de Stratum-(n+1) siempre que el peer elegido sea Stratum-n.
Conforme el tiempo avanza, las correcciones que ntpd hace son más fiables, el sistema es mas estable y el intervalo transcurrido entre dos consultas a los peers va aumentando. El error máximo que se le permite al reloj del sistema es de 128 milisegundos por defecto. Si se supera este límite, el sistema se declara de nuevo no sincronizado y todo comienza como desde el arranque. No suele ocurrir eso, por ejemplo mi servidor a las dos horas tiene un error del orden de 2 milisegundos y suele ser bastante estable.
Respecto a los osciladores de los sistemas, se permite como máximo una corección de 500 partes por millón. Nótese que una corrección de 12 ppm equivale a una variación de 1 segundo por día. Mientras escribo estas líneas, ntpd corrige 118 ppm la frecuencia del oscilador de mi PC, en otro la corrección es de 39 ppm. Hay que tener en cuenta que estas correcciones pueden variar con el tiempo, sobre todo con la temperatura.
Bien, creo que ya esta bien de introduccíon. Vamos a entrar en materia. Se trata de instalar NTP en nuestro sistema ¿No?
Una vez que se ha instalado el software en nuestro sistema, todavia no se puede utilizar. Hay que configurarlo según nuestras necesidades, que es lo que trata el siguiente punto.
Como ya se ha visto mas arriba, cuando arranca el demonio ntpd en nuestro sistema, él mismo se convierte al cabo de unos minutos en servidor. Al menos puede utilizarse como servidor, todo depende de qué configuración queramos dar. Llegado a este punto, es importante decidir qué queremos:
##
## Ejemplo de fichero de configuración ntp '/etc/ntp.conf' utilizando pool.ntp.org
## (c) Guillermo Ballester Valor, 2003
##
## Reloj local no sincronizado. Esto es un falso driver a un reloj local, como backup
## cuando no hay accesible ninguna referencia remota.
##
server 127.127.1.0 # reloj local (LCL)
fudge 127.127.1.0 stratum 10 # LCL está desincronizado, ya le asignamos stratum-10
##
## En el listado de servidores utilizamos el sitio pool.ntp.org. Allí se recomienda poner
## al menos tres servidores. En principio es suficiente, pero es preferible poner cinco.
## Puede invocarse concretamente el pais, el continente o todo el mundo. En este ejemplo se
## utilizan cuatro servidores de españa 'es' y otros dos de europa 'europe'.
##
## A fecha 23 de Octubre de 2004 las areas son
##
## 137 | europe
## 73 | north-america
## 64 | us
## 24 | uk
## 23 | nl
## 20 | de
## 14 | es
## 12 | south-america
## 11 | oceania
## 11 | ch
## 10 | fr
## 9 | br
## 8 | nz
## 8 | ca
## 6 | pl
## 5 | asia
## 5 | fi
## 4 | it
## 4 | at
## 3 | se
## 3 | au
## 3 | dk
## 3 | no
## 2 | pt
## 2 | ie
## 2 | mx
## 1 | sg
## 1 | tr
## 1 | jp
## 1 | si
## 1 | be
## 1 | in
## 1 | cl
## 1 | my
## 1 | ph
## 1 | gt
##
## Como puede verse, a fecha 11 de noviembre de 2004 ya son 14 los servidores es.pool.ntp.org
## Desde julio de 2004 se han desdoblado los dominios y subdominios de pool.ntp.org en {0,1,2},
## es decir que pueden ponerse por ejemplo {0,1,2}.es.pool.ntp.org (ver más abajo)
## Los sevidores DNS nos asignan al azar alguno de ellos de entre los del área, aunque se repita
## el nombre
##
## maxpoll = 12 indica que cada 2^12=4096 segundos como máximo se hara una consulta
## al servidor. El valor por defecto es 10
## Si no queremos mucha precisión o cargar demasiado a los servidores, 12 es
## una buena opción.
server 0.es.pool.ntp.org maxpoll 12 # area del país
server 1.es.pool.ntp.org maxpoll 12 #
server 2.es.pool.ntp.org maxpoll 12 #
server 0.es.pool.ntp.org maxpoll 12 # area del país
server 0.europe.pool.ntp.org maxpoll 12 # area del continente
server 1.europe.pool.ntp.org maxpoll 12 #
|
El anterior fichero es válido para España. Obviamente se debe cambiar de área en caso de otras naciones o continentes. En caso de duda, la repetición de pool.ntp.org no debe causar problemas, aunque se nos asigne un servidor que esté en las antípodas. Es mejor, no obstante, elegir áreas suficientemente próximas.
Podemos copiar el fichero y cambiar las áreas si procede. Ya estaremos en condiciones de poner en marcha el servidor. Continuar leyendo aquí
## ## Miscelánea ## ## El fichero ntp.drift es el que contiene la corrección que hay que hacer a ## la frecuencia de nuestro reloj local para que funcione lo más exacto posible ## viene expresada en partes por millón (ppm). El máximo por defecto es 500 ppm ## Una corrección de 12 ppm equivale a un segundo por día. ## ## Aquí se indica dónde se escribe esa corrección. Normalmente se escribe un valor cada ## hora driftfile /var/lib/ntp/ntp.drift ## ## Si queremos que ntp escriba un log tenemos que descomentar las líneas adecuadas ## logfile /var/log/ntp # fichero de log # logconfig =syncstatus + sysevents logconfig =all ## ## Tareas de monitorización ## ## En esta línea se indica de qué se quiere tener estadísticas ## statistics loopstats peerstats clockstats ## ## Directorio donde se escriben los ficheros de estadística ## statsdir /var/lib/ntp/stat/ ## ## Tipo de ficheros generados. Ver documentación detallada ## filegen peerstats file peerstats type day enable filegen loopstats file loopstats type day enable filegen clockstats file clockstats type day enable |
A continuación, como ejemplo, un caso real de configuración, el de mi servidor hora.oxixares.com
## ## Ejemplo de fichero de configuración ntp '/etc/ntp.conf' ## (c) Guillermo Ballester Valor, 2003 ## ## Reloj local no sincronizado. Esto es un falso driver a un reloj local, como backup ## cuando no hay accesible ninguna referencia remota. ## server 127.127.1.0 # reloj local (LCL) fudge 127.127.1.0 stratum 10 # LCL está desincronizado, ya le asignamos stratum-10 ## ## Para los servidores algunos stratum-1 de acceso libre publicados en la lista ## Si hay duda de que el servidor vaya a cambiar de IP, es mejor utilizar su nombre ## dejando que DNS resuelva su IP ## server 131.188.3.221 maxpoll 10 # ntp1.fau.de Nuremberg server 131.188.3.222 maxpoll 10 # ntp2.fau.de Nuremberg server 130.149.17.21 maxpoll 10 # ntps1-0.cs.tu-berlin.de Berlin server 192.93.2.20 maxpoll 10 # canon.inria.fr Paris server 193.204.114.233 maxpoll 10 # time.ien.it Torino, Italy server 129.132.2.21 maxpoll 10 # swisstime.ethz.ch, suiza server 193.67.79.202 maxpoll 10 # ntp0.nl.net server ntp2.gbg.netnod.se maxpoll 10 ## ## Algunas restricciones para evitar abusos de clientes hostiles o mal ## configurados ## ## discard pone por defecto los limites del flag 'limited'. Por defecto ## se rechazan paquetes que llegan con un promedio superior a 1 paquete cada ## 5 segundos o puntualmente 1 paquete cada 2 segundos discard ## ## Y ahora las restricciones: ## La general, con el flag 'limited' para todos los hosts restrict default limited ## Ahora la lista de hosts que NO queremos que sea afectada por lo anterior ## Como ejemplo están puestas las clases A y B locales. Si no se pone ningún flag ## se supone que el acceso no está restringido de ninguna forma restrict 127.0.0.0 mask 255.0.0.0 restrict 192.168.0.0 mask 255.255.0.0 ## ## Miscelánea ## ## El fichero ntp.drift es el que contiene la corrección que hay que hacer a ## la frecuencia de nuestro reloj local para que funcione lo más exacto posible ## viene expresada en partes por millón (ppm). El máximo por defecto es 500 ppm ## Una corrección de 12 ppm equivale a un segundo por día. ## ## Aquí se indica dónde se escribe esa corrección. Normalmente se escribe un valor ## cada hora driftfile /var/lib/ntp/ntp.drift ## ## Si queremos que ntp escriba un log tenemos que descomentar las líneas adecuadas ## logfile /var/log/ntp # fichero de log # logconfig =syncstatus + sysevents logconfig =all ## ## Tareas de monitorización ## ## En esta línea se indica de qué se quiere tener estadísticas ## statistics loopstats peerstats clockstats ## ## Directorio donde se escriben los ficheros de estadística ## statsdir /var/lib/ntp/stat/ ## ## Tipo de ficheros generados. Ver documentación detallada ## filegen peerstats file peerstats type day enable filegen loopstats file loopstats type day enable filegen clockstats file clockstats type day enable |
Si nuestro servidor funciona de forma ininterrumpida con conexión a la Internet y una IP fija, si estamos dispuestos a hacer unas mímimas labores de mantenimiento, podemos solicitar añadir nuestro servidor a pool.ntp.org. En las páginas de ese sitio nos explícan qué hacer y cómo hacerlo. En cuanto al ancho de banda que ocupan las posibles conexiones de los clientes es muy pequeña. Unos 100 clientes solicitando simultaneamente servicio a nuestro servidor pueden ocupar unos 50 Bytes por segundo. La única desventaja si el ancho de banda disponible es limitado consiste en que los paquetes se pueden retrasar demasiado cuando esta ocupada totalmente en otras transacciones.
En el ejemplo anterior vienen unos pequeños filtros para evitar que algún cliente hostil o mal configurado pueda abusar o colapsar nuestro servidor. Explicar con detalle las restricciones desbordaría este pequeño tutorial. La orden discard establece los límites del flag limited que puede añadirse en los filtros restrict. A continuación se establece una restricción general para todos los host, con el flag limited, de forma que a priori nungún host puede superar los límites impuestos en la orden discard. Como eso puede ser un incoveniente para ciertos servidores locales, a continuación se añaden restrict sin flags, y por tanto sin niguna restricción, para las clases A y B locales. Cada servidor NTP debería adaptar estas direcciones libres de restricciones según sus necesidades
El puerto por defecto por el que circulan los paquetes de ntp es UDP #123. Si queremos acceder a un servidor o que alguien acceda al nuestro, debemos abrir dicho puerto.
Es conveniente tener en cuenta que algunas de las distribuciones Linux/GNU más
populares (SuSE, Red
Hat, Mandrake ...) incorporan firewalls
personales que pueden bloquear los paquetes NTP. Si esto es así puede utilizarse
iptables con la siguiente regla:
#iptables -I INPUT 1 -m udp -p udp -s 0/0 --sport 123 -d 0/0 --dport 123
-j ACCEPT
que desbloquea el paso al puerto NTP estandar #123.
Una vez que se ha instalado el software, hay que activar el servidor. Se trata del demonio xntpd. Lo habitual es que en los paquetes precompilados ya se incluya el script de inicio y control de tal forma que se pueda configurar como servicio al arrancar el sistema.
En el caso de SuSE, con el sistema de inicio tipo system V, este script se halla en el directorio
/etc/init.d y también se llama xntpd. Tras la instalación del rpm, se activa el servicio con
#rcxntpd start
rcxntpd es simplemente un enlace blando que se halla en /usr/sbin
Lo más cómodo desde luego es dejar que el demonio xntp se active al arrancar el ordenador, de forma que ya no nos debemos preocupar más del asunto. De nuevo, la forma de hacerlo depende de cada distribución. En caso de SuSE 8.x lo mejor es recurrir a Yast2
yast2 -> Runlevel editor -> RunLevel properties -> Activar xntpd en niveles 3 y 5Tras activar el servicio o al arrancar el ordenador, durante los primeros minutos, el reloj estará desincronizado. Una llamada a ntptrace como root puede dar como resultado lo siguiente
mozart:~ # ntptrace localhost: stratum 16, offset 0.000073, synch distance 0.00000 0.0.0.0: *Not Synchronized* |
mozart:~ # ntptrace localhost: stratum 3, offset 0.000064, synch distance 0.50545 hora.oxixares.com: stratum 2, offset 0.001512, synch distance 0.07550 ntp2-rz.rrze.uni-erlangen.de: stratum 1, offset -0.010752, synch distance 0.00021, refid 'GPS' |
Del anterior listado se deduce que en ese momento nuestro ordenador (localhost) está sincronizado con el stratum-2 hora.oxixares.com y por tanto es un stratum-3. A su vez, hora.oxixares.com tiene como peer el stratum-1 ntp2-rz.rrze.uni-erlangen.de .
Una salida como la del ejemplo nos indica que nuestro ordenador ya esta sincronizado y que a su vez puede ser servidor de otros, mision cumplida :)
Con ntpq podemos ver el estado de todos los peers de hora.oxixares.com
gauss:~ # ntpq -p hora.oxixares.com
remote refid st t when poll reach delay offset jitter
==============================================================================
LOCAL(0) LOCAL(0) 10 l 2 64 377 0.000 0.000 0.008
-ntp1-rz.rrze.un .DCFp. 1 u 446 512 377 110.762 -9.304 3.525
-ntp2-rz.rrze.un .GPS. 1 u 242 512 377 112.863 -9.615 0.526
-hora.cs.tu-berl .PPS. 1 u 456 512 377 123.149 -2.476 0.479
*canon.inria.fr .GPS. 1 u 444 512 377 100.236 1.824 0.455
-ntp2.ien.it .IEN. 1 u 313 512 377 141.008 -3.922 0.386
-swisstime.ee.et .DCFa. 1 u 445 512 377 105.025 -5.507 4.360
+ntp0.NL.net .GPS. 1 u 495 512 377 267.048 3.765 0.254
+ntp2.gbg.netnod .PPS. 1 u 314 512 377 145.764 4.568 1.417
|
En este caso, en el momento de hacer la llamada a ntpq el servidor elegido era canon.inria.fr lo que se indica con un * al principio de la línea. Los que comienzan con + también son candidatos. Si comienzan con - se considera que el error es demasiado alto. Si comienza con un blanco entonces no esta sincronizado o no es accesible.
También se indica en el listado el stratus de cada peer, si está activo (t), cuántos segundos hace que se llamó (when), cuantos segundos deben pasar entre cada llamada (poll), la máscara de llamadas con exito (en octal, cada bit corresponde a una llamada, el bit 0 es la última y el bit 7 la de hace 7 llamadas, un '1' corresponde a éxito). delay se refiere al tiempo estimado, en milisegundos, que tarda el paquete desde el servidor hasta nuestro host. offset es la diferencia estimada entre lo que marca nuestro reloj y el de referencia. jiter se refiere a la dispersion de los valores de referencia obtenidos con ese peer, es una medida de la calidad de la referencia
Por último, algunas recetas para monitorizar qué servidores, cuantos y con qué frecuencia
están utilizando nuestro servidor. De ello se encarga ntpdc. Si se quiere una lista
detallada
#ntpdc -c monlist
Puede tardar un poco porque DNS tiene que resolver todas las entradas. Si queremos una respuesta
rápida pero sin los nombre de lugar
#ntpdc -n -c monlist
Podemos encadenar esto para saber cuántos clientes/servidores hemos contactado.
#ntpdc -nc monlist | wc -l
Lo que se cuenta en este artículo no es más que una ínfima parte de lo que se debe saber si queremos ser unos buenos timekeepers, que yo me permito traducir aquí como serenos (los cuales daban la hora durante la noche en las ciudades de España a principios del siglo XX).
En español este documento en formato doc ilustra con profusión de detalles el protocolo NTP. Hay que leerlo si se quiere profundizar en el tema.
En Inglés, el mejor sitio para acceder a documentación es, desde luego, éste. Para comenzar, este magnifico FAQ sería de lectura obligada. Si se domina el inglés, no debe haber problemas en convertirse pronto en un experto en ntp. Yo no lo soy (todavía), pero he escrito estas líneas para que otros se sirvan de mi corta experiencia trabajando con ntp. Mi deseo es que les haya sido útil esta lectura abriendo el mundo NTP a toda la comunidad hispana.