Consejo sobre Unix: Comandos NTP
ITworld.com – ¡Envíe sus preguntas sobre Unix hoy mismo!
Vea más consejos y trucos sobre Unix
La columna de la semana pasada introdujo el NTP, el Protocolo de Tiempo de Red y el concepto de mantenimiento de la hora altamente preciso. Aunque existen numerosos comandos para ayudar a los administradores de sistemas a mantener una hora bastante precisa en los sistemas que gestionan, los más obvios son muy limitados. Como resultado, la mayoría de las redes sufren de grandes discrepancias en la hora del sistema. Diferencias de tiempo como las que se muestran a continuación (tomadas de una red real) no son infrecuentes:
host01: Thu Oct 14 10:50:23 EDT 2004
host02: Thu Oct 14 10:43:53 EDT 2004
host03: Thu Oct 14 10:41:52 EDT 2004
host04: Thu Oct 14 10:50:13 EDT 2004
host05: Thu Oct 14 10:33:59 EDT 2004
host06: Thu Oct 14 14:48:17 GMT 2004
host07: Thu Oct 14 10:52:04 EDT 2004 *
host08: Thu Oct 14 10:52:33 EDT 2004
host09: Thu Oct 14 10:49:55 EDT 2004
host10: Thu Oct 14 10:33:20 EDT 2004 *
host11: Thu Oct 14 10:51:22 EDT 2004
Sólo dentro de estos once sistemas encuestados secuencialmente, podemos ver una considerable variabilidad en el tiempo reportado. Aunque los sondeos tuvieron lugar en un lapso de unos pocos segundos, las diferencias de tiempo son considerablemente mayores que unos pocos segundos. De hecho, hay una diferencia de 18 minutos y 44 segundos entre la primera y la última hora comunicada. Si hubiéramos sondeado toda la red, la diferencia entre las horas más tempranas y las más tardías habría sido aún mayor.
Para forzar a sistemas como estos a una mayor proximidad horaria, el administrador de sistemas puede utilizar cualquiera de una serie de comandos con diversos grados de éxito.
El comando de fecha
El comando de fecha que permite al administrador del sistema establecer la fecha y la hora es el comando más obvio para corregir la hora de un sistema, pero depende de que el administrador del sistema tenga una referencia horaria bastante precisa. Este comando también se ejecuta un sistema a la vez. Usando el comando de fecha para sincronizar dos sistemas, es poco probable que el administrador del sistema consiga que las horas del sistema se acerquen más que unos pocos segundos entre sí. El comando date claramente no es el comando a elegir cuando la sincronización es importante. Y, en una red con varios cientos de sistemas, este enfoque puede ser tedioso e inexacto.
Si un administrador de sistemas emitiera un comando de fecha en un bucle como el que se muestra a continuación, las horas del sistema estarían más cerca que las mostradas anteriormente, pero seguirían variando tantos segundos como el bucle tardara en completarse. Y, por supuesto, esta variación de tiempo será cada vez más significativa si hay que introducir una contraseña para cada comando ssh.
for host in `cat host_list`do ssh $host "date 10141045"done
El comando date es claramente sólo mínimamente útil para sincronizar sistemas. Los relojes de los sistemas que tienden a ganar o perder tiempo, aunque sea del orden de un par de segundos cada día, volverán a ampliar rápidamente las diferencias horarias. Además, los sistemas configurados para otras zonas horarias – como el sistema que reporta la hora como GMT en la lista mostrada arriba, tendrían sus relojes desviados por horas si usamos el comando de fecha como se muestra.
El comando rdate
El comando rdate, una opción mucho mejor para sincronizar los relojes en una red, requiere que un administrador de sistemas seleccione un sistema accesible a su red, presumiblemente uno que mantenga una hora bastante precisa para usarlo como referencia horaria para el resto.
El siguiente bucle daría resultados mucho mejores que el mostrado anteriormente. Después de todo, el tiempo necesario para que este bucle se complete no tendrá ningún efecto perjudicial, ya que cada comando rdate se sincronizará con la hora del servidor de referencia cuando se ejecute ese comando.
for host in `cat host_list`do ssh $host "rdate timekeeper"done
Además, el comando rdate no anula la zona horaria del sistema de destino. En lugar de establecer la hora literalmente a un valor que se proporciona en la línea de comandos, rdate solicita datos de tiempo que son independientes de la zona horaria. En otras palabras, si se ejecuta «rdate » en un sistema que utiliza GMT, la hora del sistema GMT se ajustará correctamente.
El comando rdate se ejecuta generalmente al inicio del sistema o a través de cron una vez al día o una vez por hora para alinear los relojes de los sistemas en una LAN. En comparación con los relojes indisciplinados del sistema mostrados anteriormente, esto es una gran mejora. Sin embargo, desde el punto de vista de cada sistema cuyo reloj se reajusta con rdate, pueden ocurrir algunas cosas muy inusuales. Los relojes pueden saltar hacia adelante o hacia atrás en el tiempo cada vez que se ejecuta el comando rdate. Este comportamiento puede llevar a algunas interpretaciones muy extrañas de eventos sensibles al tiempo.
Comandos NTP
NTP tiene claramente ventajas considerables sobre los comandos date y rdate. Por un lado, NTP proporciona una forma de sincronizar los relojes del sistema con una precisión inusual y de realizar los ajustes necesarios de forma suave, evitando los saltos en el tiempo que comandos como rdate suelen provocar. Echemos un vistazo más de cerca.
NTP proporciona dos comandos para el ajuste de la hora: el comando ntpdate — que establece la hora del sistema de manera similar a como lo hace el comando rdate (es decir, haciendo referencia a un sistema remoto para obtener la hora actual) y el demonio NTP — ntpd o xntpd — que proporciona un mecanismo mucho más elaborado para llegar a la hora adecuada y sincronizarla.
El comando ntpdate
El comando ntpdate — generalmente utilizado, como el comando rdate, al inicio del sistema, bajo demanda o periódicamente a través de cron — sincroniza la hora sobre una base «ad hoc» de manera similar a rdate. Sin embargo, el comando ntpdate tiene dos ventajas muy importantes sobre rdate.
Por un lado, ntpdate hace referencia a un servidor NTP, no sólo a un cronómetro fiable accesible a su red. Dado que los servidores NTP suelen estar vinculados a la jerarquía NTP (y, en última instancia, a un reloj atómico de gran precisión), está casi garantizado que sean más precisos que cualquier servidor que simplemente tenga un buen chip de reloj.
Por otra parte, ntpdate puede recoger una serie de muestras de tiempo de una serie de fuentes de tiempo (es decir, múltiples servidores NTP) y luego seleccionar la hora que parece más precisa. Así, el comando ntpdate no sólo hace referencia a una fuente de tiempo que es más probable que sea precisa que las seleccionadas para su uso con rdate, sino que hace referencia a una serie de tales sistemas y aplica un sofisticado proceso de selección.
Un comando ntpdate podría tener este aspecto:
# ntpdate 129.6.15.28
14 Oct 10:52:41 ntpdate: adjust time server 129.6.15.28 offset -0.003350 sec
De hecho, si el comando ntpdate está instalado en su sistema (/usr/sbin/ntpdate en la mayoría de los sistemas Solaris), podría probar ese mismo comando ntpdate ahora mismo. El servidor de referencia en este ejemplo es un servidor NTP en el NIST en Gaithersburg, Maryland.
Alternativamente, puede intentar un comando ntpdate como este:
# ntpdate 129.6.15.28 216.200.93.8 208.184.49.9
14 Oct 14:57:41 ntpdate: adjust time server 216.200.93.8 offset 0.015733 sec
En este caso, se consultan múltiples servidores NTP.
El demonio NTP
Aunque el comando ntpdate proporciona un nivel de control de tiempo que es un orden de magnitud mejor que rdate, el demonio NTP va un paso gigante más allá de ntpdate con sus sofisticados algoritmos para maximizar la precisión y la fiabilidad. Utilizado correctamente, el demonio NTP también utiliza una cantidad mínima de recursos de red — examinaremos este tema la próxima semana.
El demonio NTP proporciona sofisticados algoritmos que sincronizan suavemente los relojes del sistema a través de un proceso de aproximación sucesiva. Cuanto más tiempo se ejecute el demonio, más se acercará la hora del sistema a la de su fuente. Realiza grandes ajustes rápidamente y luego ajustes más pequeños a lo largo del tiempo para evitar sobrepasar la hora adecuada.
El NTP puede tardar minutos u horas en acercarse a un nivel fino de precisión pero, una vez que lo hace, la fiabilidad de la hora en el sistema puede ser asombrosamente precisa. Dicho esto, la exactitud del tiempo de NTP es, sin embargo, en última instancia, ligada a la exactitud de las fuentes de tiempo que hace referencia. Cada servidor NTP intenta sincronizar a UTC (es decir, Tiempo Universal Coordinado) utilizando la mejor fuente de tiempo y ruta de transmisión disponible. Si el conjunto de servidores referenciados transmite tiempos que no están muy cerca unos de otros, NTP considerará que uno o más de estos servidores de tiempo están rotos y los descartará. Por lo tanto, para obtener una hora precisa utilizando NTP, su elección de los servidores de tiempo debe ser precisa.
Los recién llegados a NTP deben tener en cuenta que la ejecución del proceso del demonio NTP NO hace necesariamente que un sistema sea un servidor NTP. El hecho de que un sistema habilitado para NTP desempeñe el papel de cliente o de servidor viene determinado por los archivos de configuración del demonio en ese sistema, algo que examinaremos en la columna de la próxima semana.
Esta noticia, «Consejo sobre Unix: Comandos NTP» fue publicado originalmente por ITworld.