🚀 go-pugleaf

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

El s�b, 24 mar 2001 11:59:03 +0100, linuxforever escribi�:
>A mi me aparece un problema...
>Resulta que en mi LAN tenemos algunos ordenadores con Red Hat 6.2. En  estos
>ordenadores instalo el paquete de NTP apropiado, y entonces elijo uno de estos
>ordenadores para que extraiga la hora de slug.ctv.es modificando el fichero
>/etc/ntp.conf con estas lineas:
>" server slug.ctv.es "
>" fudge slug.ctv.es "
   ^^^^^^^^^^^^^^^^^
Esa l�nea no es muy afortunada, fudge se refiere a los relojes asociados
al sistema que sirven para fijar la hora, en vez de a servidores externos
(para eso est� server o peer si cliente y servidor pueden intercambiar sus
papeles en caso de necesidad).
Ser�a mejor
server	127.127.1.0
fudge	127.127.1.0 stratum 10
para que se sincronice con slug.ctv.es y, cuando la conexi�n no se pueda
establecer, conf�e por defecto en su propio reloj interno. Lo de estrato 10
es para darle una prioridad muy baja al reloj interno (el protocolo siempre
tiende a buscar la ruta m�s corta hacia un servidor en estrato 1).

>Entonces en los ordenadores clientes escribo (no estando activo el demonio
>"ntpd") ntpdate direccion_ip_del_servidor_de_tiempo_de_mi_LAN , y aparece un
>mensaje "not suitable NTP server found...". Entonces espero unos minutos (de 5
>a 10), y ejecuto otra vez en los clientes el ntpdate y veo que se sincroniza la
>hora perfectamente. Incluso si los clientes tienen Red Hat 7.0 haciendo el
>ntpdate funciona.

Esos 5 o 10 minutos es lo que le cuesta sincronizarse al servidor local con
el externo. Ejecutando ntptrace (como usuario raso, no es necesario ning�n
privilegio) desde el servidor local saldr� la ruta de servidores NTP por
los que pasa hasta llegar a uno de estrato 1 (o en su defecto lo m�s alto
que pueda); en este caso supongo que s�lo habr� ruta hasta slug.ctv.es.

>El problema es que si ahora instalo el paquete NTP en un ordenador con Red Hat
>7.0, y le hago la misma modificaci�n en el /etc/ntp.conf
>" server slug.ctv.es "
>" fudge slug.ctv.es "
>
>Despues de esto intento hacer ntpdate con los clientes a ese ordenador y
>obtengo el mensaje "not suitable NTP server found...". Espero y espero...(he
>llegado a esperar m�s de una hora) y siempre obtengo "not suitable NTP server
>found..."
>

Supongo que el ordenador con RH7.0 (en la pr�ctica paquete NTPv4) no ha
conseguido sincronizarse con slug.ctv.es y, por lo tanto, tampoco atiende
a peticiones externas desde el momento en que sabe que su tiempo no es bueno.
De todos modos esto es f�cilmente comprobable con ntptrace.

Si sirve de consuelo, desde el trabajo nunca he conseguido sincronizarme
con slug.ctv.es. No s� si el problema est� en alg�n enrutador que filtra o
retarda excesivamente los paquetes UDP por los que viajan los mensajes NTP
o que otra cosa ocurre. Por contra, desde casa s� que accedo a �l (con
una RH7.0); pero en cambio no puedo acceder a los servidores que tengo
en el trabajo.

Lo que intentar�a ser�a buscar desde www.ntp.org una lista de servidores
NTP p�blicos en estrato 2 (para red peque�a con tener los equipos 
en estratos 3 � 4 sobra). A continuaci�n har�a pruebas con ntpdate y ntpd
hasta encontrar tres que funcionen (comparar si hay diferencia entre usar
n�meros IP y nombres DNS) y los meter�a como server en ntp.conf (as� si
falla uno, se buscan los otros). Eso para el servidor local. Una vez que
estuviese bien sincronizado, no deber�a de haber problema para que los
clientes se sincronicen a �l.

No hay que olvidar nunca enviar un correo al administrador de cualquier
servidor de tiempo del cual se vaya a hacer un uso habitual. Para las pruebas
no es necesario; pero una vez que se tiene el ntp.conf deseado y uno se puede
olvidar de todos estos rollos, conviene hacerlo.

M�s cosas si esto no funciona: 	- Si se pone el reloj local del servidor
como �ltimo recurso, todos los clientes se sincronizar�n con �l; con lo
cual la hora, aunque mala, ser� uniforme en toda la red.

				- Bajarse las fuentes del paquete ntpV4
(versi�n 4 del protocolo) y recompilarlo para todas las m�quinas (las RH7.0
ya lo utilizan, aunque ignoro si lo hacen con alg�n parche o configuraci�n
peculiar; mientras que las RH6.2 utilizan la versi�n 3). De todos modos,
en el trabajo tenemos una red heterog�nea en cuanto versiones (3 y 4
mezcladas) y nunca hemos tenido problemas para sincronizar internamente.
Si que los hay para acceder a seg�n que servidores externos (tanto en el
trabajo como en casa) y no s� muy bien el porqu�.

				- Hay una variable un tanto esot�rica
que puede causar problemas de compatibilidad entre versiones, debido a
la precisi�n distinta con la que trabaja cada una (o eso pone en las FAQ en
www.ntp.org); pero a m� nunca me los ha dado, dependiendo en �ltima
instancia de hora.rediris.es (trabajo en una universidad). A saber 
si los problemas con slug.ctv.es arrancan de all�.

				- Enviar un correo al ISP, solicit�ndole
que suministre este servicio para sus abonados (igual que dan correo, foros,
...). Seguro que si muchos lo solicitan, acabar�n poniendo servidores
de tiempo a disposici�n de sus clientes.
- ---
Juan Pablo Hierro �lvarez
hierro en escomposlinux punto org
Clave p�blica: 0xA8707ADF en pgp.rediris.es
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iEYEARECAAYFAjq/o2kACgkQd1aMoahwet9ZGgCeNkbD/5m1Pmq1161mrhFo5yT/
jeAAn3Jsdq2FFmbbnK4NsqGkIQ9ojHD2
=RX+W
-----END PGP SIGNATURE-----