¿Estás visitando desde Argentina?
Ingresá a Linware Argentina ⯈
Continuar en Linware Argentina ⯈
×
¿Qué estás buscando?
BUSCAR!
BLOG
Expedientes de un TSE: ¿Tendría tiempo?
Publicada el 13/10/2021
Esta es la primera parte de una serie que intenta mostrar el tipo de trabajo que realiza el soporte de SUSE y cómo ayudamos a los clientes a resolver problemas al ejecutar productos de SUSE. Los casos que se seleccionen se basarán en casos reales. Sin embargo, todos los detalles serán completamente anonimizados y despojados de marcas de identificación.
Este es un caso en el que el tiempo desde que lo llevé hasta que se resolvió fue de aproximadamente media hora. Ser media hora puede no significar mucho para algunas personas, pero los sistemas informáticos son mucho más sensibles al tiempo y necesitan que sea preciso y sincronizado. Por eso es fundamental contar con una sólida infraestructura NTP (Protocolo de tiempo de red). Este caso muestra lo importante que puede ser la atención a los detalles al solucionar problemas de un sistema.

Descripción del cliente:


Configuramos nuestro servidor en yast para usar solo el servidor ntp local como fuentes de tiempo. Parece que Yast escribió la configuración en /etc/chrony.conf:
piscina ntp01.customer.com iburst
piscina ntp02.customer.com iburst
 
Pero veo muchas caídas en el firewall mientras el servidor intenta llegar a fuentes ntp externas en Internet. 
 
¿Por qué? ¿Cómo puedo detener el servidor de sondeo fuera de los dos definidos en conf?
 
También hubo una salida de fuentes chronyc> del shell chrony que mostraban encuestas de algunas fuentes NTP. Contenía piscinas locales accesibles y algunas fuentes de Internet inalcanzables. Para obtener más información sobre la interpretación de la salida de: `ntp -q` y` chronyc sources -v`, consulte un TID que escribí sobre el tema.

Notas sobre la hora normal


Lo que el cliente quiere lograr aquí es una práctica excelente en el cronometraje. Es correcto que quieran utilizar fuentes de hora local. Esto tiene el potencial de mejorar la seguridad y es la única forma de dar tiempo a los servidores que no están conectados a Internet. No es una buena práctica tener 1 (sin redundancia, pero tampoco hay disputa del tiempo) o 3 servidores de tiempo configurados. Dos es probablemente el peor número de servidores de tiempo, ya que si indican una hora diferente, no habrá posibilidad de consenso. Es una de las razones por las que siempre queremos al menos 3 nodos en un clúster de alta disponibilidad y por qué 2 es el peor número de dispositivos de vigilancia de hardware.
Sin embargo, lo que el cliente ha configurado aquí son grupos  de servidores de tiempo. Un grupo es básicamente una lista de servidores, por lo que si uno de los servidores muestra una hora realmente inactiva o si es inalcanzable, NTP solo obtendrá la hora del siguiente servidor de la "lista". Entonces, lo que el cliente quiere aquí es muy razonable. Han configurado algunos servidores de tiempo locales, pero todas estas fuentes de tiempo de Internet inalcanzables contaminan su configuración. Sin embargo, no pueden averiguar de dónde vienen todos. De manera bastante razonable, escribieron en una pregunta específica: ¿Por qué el sistema está tratando de llegar a estas fuentes de tiempo de Internet? ¿Cómo lo soluciono?
Por ejemplo, estoy usando la configuración de mi escritorio, que ejecuta OpenSUSE Leap. Tiene la ventaja de que cada línea tiene un comentario, así que sé lo que hace sin siquiera mirar el manual. Para mis propósitos, en realidad * quiero * obtener tiempo de Internet. Quiero estar sincronizado a la hora adecuada y no tengo un grupo en mi red local. El cliente tenía una configuración similar, pero a diferencia de mí, quería evitar obtener su tiempo de Internet.

El problema y la solución


 
Lo que el cliente no notó es que tenía una directiva "incluir" en su configuración /etc/chrony.conf:
# También incluya cualquier directiva que se encuentre en los archivos de configuración en /etc/chrony.d nincluya /etc/chrony.d/*.conf
Y hay un archivo desplegable llamado '/etc/chrony.d/pool.conf' con contenidos como estos:
piscina 2.opensuse.pool.ntp.org iburst
Lo que estaba sucediendo es que Chrony analizó el archivo /etc/chrony.conf, presionó la directiva "incluir", la siguió e incluyó el grupo de Internet.
 
El origen probable es que el cliente dejó una casilla marcada con sincronizar con servidores de tiempo de Internet, al configurar el servicio NTP con YaST.
 
Ahora que sabemos cuál era el problema, ¿cómo lo solucionamos? Dado que esto es Linux, es sencillo y sin esfuerzo. Lo que sugerí fue comentar la línea 'incluir', lo que le diría a chrony que olvide cualquier cosa fuera de /etc/chrony.conf que esté bien si no hay otros archivos de inclusión que brinden una funcionalidad importante. La otra cosa que el cliente podría hacer es borrar el archivo '/etc/chrony.d/pool.conf' por completo o comentar su única línea.

Punto de práctica:


A menudo, escuchará del soporte de SUSE cuando estemos solucionando problemas, para "comentar" una o varias líneas de un archivo. ¿Qué significa esto y por qué lo hacemos?
 
Comentar una línea en una configuración significa poner un carácter de comentario al principio de una línea. Suele ser "#", pero no siempre. En configuraciones de samba ";" se prefiere para comentarios, por ejemplo.
 
cat / etc / fstabnn# Este texto puede considerarse inerte.n# Nada en esta línea se analizará como  parte de la configuración.nn# Esto puede resultar útil para documentar cambios y  desviaciones de las configuraciones estándar.nnUUID = f8626266-d78c-4c21-bc08-962bde178cdb / btrfs predeterminados 0 0 nUUID = 7facfae7-41e5-4699-9d78-555b032be5c8 swap swap defaults 0 0 0 n0ID = f8626266-d78c-bvc017821-b / var 0 0 nUUID = f8626266-d78c-4c21-bc08-962bde178cdb / usr / local btrfs subvol = / @ / usr / local 0 0 nUUID = f8626266-d78c-4c21-bc08-962bde178cdb / tmp btrfs subvol = / @ / tmp 0 0 nUUID = f8626266-d78c-4c21-bc08-962bde178cdb / srv btrfs subvol = / @ / srv 0 0 nUUID = f8626266-d78c-4c21-bc08-962bde178cdb / root btrfs subvol = / @ / root 0 0nUUID = f8626266-d78c-4c21-bc08-962bde178cdb / opt btrfs subvol = / @ / opt 0 0 nUUID = f8626266-d78c-4c21-bc08-962bde178cdb / home btrfs subvol = / @ / home 0 0 nUUID = d7826266 4c21-bc08-962bde178cdb / boot / grub2 / x86_64-efi btrfs subvol = / @ / boot / grub2 / x86_64-efi 0 0 nUUID = f8626266-d78c-4c21-bc08-962bde178cdb / boot / grub2 / btr i386-pc / @ / boot / grub2 / i386-pc 0 0n # UUID = 6CC5-4290 / boot / efi valores predeterminados de vfat 0 2
En el caso de que la línea del sistema de archivos / boot / efi esté "comentada", lo que significa que si, por ejemplo, ejecuto un comando mount -a, el sistema no intentará montarlo. Usamos esto para aislar el problema y ajustar rápidamente los elementos de configuración sin sobrescribirlos.

Conclusión


El cliente respondió en breve para confirmar que estaba satisfecho con la solución y cómo manejamos el caso.
 
A veces, la solución puede ser fácil, pero detectar el problema puede requerir atención a los detalles, una lectura detallada y una pizca de saber dónde buscar.
 
¿Alguna vez ha visto un problema en el que todo lo que se necesitaba para solucionarlo era cambiar un carácter o eliminar una línea? ¿Alguna vez  leyó un archivo de configuración una y otra vez, solo para que un colega señalara el problema a primera vista? ¿Fue usted ese colega que lo vio? Sé que he sido ambos. ¡No dude en compartir sus historias en los comentarios a continuación!
Ir al Blog