Jesus Aneiros Sosa wrote: >On Sun, 1 May 2005, Jens Hardings wrote: > > > >>Eso es una solución parche. ntpdate simplemente sincroniza en un >> >> > >Espero que ntpdate sea el equivalente del rdate de RH. > >
Más o menos... ntpdate sigue el protocolo ntp especificado en el RFC 1305, en el cual se elige el "mejor" servidor de entre los disponibles en base a varios criterios cuidadosamente estudiados, considera las demoras y el jitter en la red, etc. rdate sigue el protocolo definido en el RFC 868, que es bastante más primitivo. Ahora, si vas a usar solamente ntpdate y no el resto del servicio de un servidor ntp, bien puedes quedarte con rdate. Total, con la precisión que tienen los relojes dentro de los equipos, al par de días da lo mismo si la sincronización inicial tenía una diferencia de 10 o de 600 ms, la hora va a andar por la luna de todas formas. >>instante del tiempo, y luego cada servidor sigue manteniendo su propia >>hora independiente del resto. En cambio, ntpd mantiene un seguimiento, >> >> > >Aqui lo unico que olvidas mencionar es la necesidad de >configuracion/administracion de otro servicio. Creo que todo depende del >grado de exactitud que se quiera en el ajuste. > > Claro, pero en una máquina con un uptime de cientos de días, un esquema como setear la hora al booteo (que quizás sirve para otros servidores que se deben rebootear con cierta frecuencia) deja de tener sentido. Es peor que tener un reloj análogo detenido: al menos ese da la hora precisa exactamente dos veces al día ;-) Y un desajuste de 1 segundo ya implica bastante trabajo a la hora de revisar logs generados por distintas máquinas. Un buen administrador es un hombre flojo (o mujer floja, no seamos sexistas), por lo tanto va a hacer lo posible por evitar ese trabajo extra, manteniendo los servidores a la hora. Si hay posibilidad de mantener una diferencia de menos de 20 ms, por qué no aprovecharlo? La implementación ya está hecha y la configuración es relativamente sencilla. Y te ahorras toneladas de trabajo y errores en momentos críticos (revisar logs no es lo que uno hace en pleno relajo dominguero, por lo general hay mucha presión involucrada). Saludos, -- Jens.
