¿Cuáles son los pros y los contras entre estas dos formas de sincronizar su servidor?
Me parece que su servidor probablemente no se desplazará más de 1 segundo todos los días, por lo que ntpdate en un crontab estaría bien. Pero escuché que podría usar servidores NTP redundantes aquí
http://www.pool.ntp.org/en/use.html
para mantener el tiempo sincronizado en caso de falla.
¿Tienes alguna sugerencia?
Respuestas:
El algoritmo NTP incluye información que le permite calcular y corregir la deriva en el reloj de su servidor. NTPD incluye la capacidad de usar esto para mantener su reloj sincronizado y funcionará con más precisión que un reloj en una computadora que no ejecuta NTPD. NTPD también usará varios servidores para mejorar la precisión.
ntpdate no mantiene ningún estado para realizar este servicio por usted, por lo que no proporcionará el mismo tipo de precisión. Le permitirá proporcionarle una lista de servidores que utilizará para intentar proporcionarle un mejor resultado, pero esto no sustituye a los sofisticados algoritmos proporcionados en NTPD que rastrean su deriva de cada uno de los servidores a lo largo del tiempo.
NTPDATE corrige la hora del sistema instantáneamente, lo que puede causar problemas con algún software (por ejemplo, destruir una sesión que ahora parece vieja). NTPD corrige intencionalmente el tiempo del sistema lentamente, evitando ese problema. Puede agregar el modificador -g al iniciar NTPD para permitir que NTPD realice la actualización por primera vez, que es más o menos equivalente a ejecutar ntpdate una vez antes de iniciar NTPD, lo que en algún momento fue una práctica recomendada.
En cuanto a las cuestiones de seguridad, los servidores ntp no se vuelven a conectar en conexiones no iniciadas, lo que significa que su firewall debería poder decirle que inició la solicitud ntp y permitir el tráfico de retorno. No debería haber necesidad de dejar los puertos abiertos para conexiones arbitrarias para que NTPD funcione.
Desde la página del comando man ntpdate (8):
ntpdate se puede ejecutar manualmente según sea necesario para configurar el reloj del host, o se puede ejecutar desde el script de inicio del host para configurar el reloj en el momento del arranque. Esto es útil en algunos casos para configurar el reloj inicialmente antes de iniciar el demonio NTP ntpd. También es posible ejecutar ntpdate desde un script cron. Sin embargo, es importante tener en cuenta que ntpdate con scripts cron ideados no sustituye al demonio NTP, que utiliza algoritmos sofisticados para maximizar la precisión y la fiabilidad al tiempo que minimiza el uso de recursos. Finalmente, dado que ntpdate no disciplina la frecuencia del reloj del host como lo hace ntpd, la precisión con ntpdate es limitada.
Se prefiere ntpd sobre ntpdate porque obtienes una corrección de tiempo suave en lugar de saltos en tu reloj. ¿Qué sentido tiene de sus registros cuando hay un salto hacia atrás en el tiempo? ntpdate también cambiará de forma transparente entre servidores según sea necesario.
En cuanto a requerir puertos abiertos (como lo menciona Kyle), las versiones más nuevas de ntpd (por ejemplo, 4.2.4 en mi servidor Debian) se pueden configurar para transmitir / multidifusión a la LAN, con autenticación criptográfica.
Editar: ver también esta pregunta .
En general, recomiendo que ejecute NTPD y sincronice sus servidores con un servidor horario designado dentro de su organización. Ese servidor interno generalmente se sincronizará con uno de los servidores NTP públicos (como se vinculó).
He usado el método ntpdate sin ningún problema, pero parece más hackear que ejecutar un verdadero demonio ntpd.
He oído hablar de problemas con el sesgo del reloj en máquinas virtuales que ejecutan ntpd. También he oído hablar de personas que corrigen este problema ejecutando trabajos cron regulares que llaman a ntpdate contra varios de los servidores del grupo. No he tenido estos problemas, pero he oído hablar de ellos varias veces.
Como se mencionó en otra parte, NTP proporciona una corrección de tiempo suave. Si a las aplicaciones en su servidor no le importa que falten segundos enteros, o que repita los mismos segundos nuevamente, entonces ntpd no le gana mucho más que ntpdate.
Si, por otro lado, tiene aplicaciones sensibles al tiempo que son sensibles a segundos, o peor aún, sensibles a segundos parciales, entonces ntpd es, con mucho, la mejor opción. Actualizaciones de marcas de tiempo de Novell eDirectory para el manejo de la colisión de actualizaciones, lo que se vuelve crítico si las actualizaciones llegan muy rápido (como durante el inicio de sesión de la mañana). Un servidor syslog debe tener un tiempo preciso de al menos medio segundo para mantener registros sanos.
Para mi caja de MythTV en casa, me doy cuenta cuando es incluso unos segundos menos de lo que mi proveedor de cable considera tiempo, así que uso NTP en eso. Para el servidor de monitoreo UPS en el trabajo, uso crontabbed ntpdate por las mismas razones que Kyle Hodgson señaló, ya que es un host de bastión, no quiero que ese puerto esté abierto, incluso si he bloqueado la aplicación; para esa aplicación ser un segundo apagado de verdad no es grave.
En cuanto a la redundancia, mantenemos al menos dos hosts de tiempo en nuestra red y señalamos todos nuestros hosts internos a esos dos. Estos dos rastrean diferentes hosts NTP de internet. Además, están configurados en un acuerdo entre pares para que puedan mantener el tiempo entre ellos de manera consensuada si nuestro enlace de Internet se cae. El NTP robusto es definitivamente posible de diseñar.
En un servidor donde el acceso y el endurecimiento son críticos, utilicé el razonamiento de que xntpd, la versión de ntpd en la que confiaba, requería un puerto UDP abierto 123. Como prefería tener abiertos tcp 22 y 80, usé ntpdate en un crontab en su lugar. Nunca escuché una buena razón de por qué necesitaba eso, o no una que yo recuerde.
Una de las desventajas de usar una llamada crontab'ed ntpdate es que no puede manejar la corrección de deriva con elegancia. ntpdate, iirc, actualiza el reloj tan pronto como puede indicar que está desactualizado: los demonios ntp generalmente corrigen la deriva suavemente. Esto tiene el beneficio de que sus registros se mantienen cuerdos: se puede imaginar, en un servidor web ocupado, por ejemplo, que si el RTC se hubiera desviado unos minutos, leer los registros web al día siguiente podría inferir que las personas pudieron llegar a un lugar seguro URL antes de iniciar sesión, ya que los accesos web estarían fuera de servicio.
No necesita usar crontab, para eso es ntpd.
Inicialmente, cuando se acaba el tiempo, una forma es simplemente detener ntpd, luego ejecutar ntpdate ntp.server.compara volver a sincronizarlo, luego iniciar ntp nuevamente.
Sin embargo, si tiene una red grande, probablemente configure un par de servidores ntp locales y haga que todos los hosts los usen.
Vea esta discusión para comprender por qué "ntpdate" todavía se desea y está en uso.
Para resumir: ntpd es lento en comparación cuando se realiza un ajuste de tiempo masivo, incluso con la opción -g.
Para uso en el hogar, ntpdate no es gran cosa realmente ... Hay una razón por la que es "más lento". Cualquiera que use un cron con ntpdate en un entorno de PRODUCTION ENTERPRISE es simplemente un idiota.