ULTIMAS OCURRENCIAS DEL PROYECTO

Sincronización con NTP

Cuando nos enfrentamos ante una infraestructura amplia de servidores que deben trabajar con un mínimo de sincronización, es importante que todos ellos compartan la misma hora, y ajustar manualmente la hora de cada uno no solo es una tarea tediosa, sino que además es inútil ya que la precisión es muy baja, y la latencia del hardware de reloj de un servidor normal puede retrasarlo hasta 2 segundos a la semana. Insostenible a largo plazo.

Afortunadamente, existe un protocolo llamado Network Time Protocol (NTP, Protocolo de Tiempo de Red) que nos permite mediante un sistema jerárquico de clientes-servidores sincronizar a través de una red la hora de los servidores contra una o varias fuentes. Es decir, que los servidores pueden pedirse la hora unos a otros siguiendo un modelo escalonado, manteníendo todos la misma hora con un margen de diferencia mínimo.

Como comentamos, NTP tiene una estructura jerárquica dividida en ESTRATOS. El número de estrato de un servidor indica cuán lejos está de una fuente de hora original, siendo los servidores de estrato 1 los que constituyen una fuente de final de hora. Este tipo de servidores de estrato 1 son máquinas especiales equipadas con hardware específico capaz de obtener la hora en función de condiciones físicas externas, como por ejemplo los datos de un satelite de GPS o el eje de inclinación de la tierra. Este tipo de hardware es desorbitadamente caro, quepa decirlo. Ejemplos de este tipo de servidores de estrato 1 son los relojes atómicos de Greenwich (que miden el tiempo mediante las vibraciones del átomo de cesio) o los relojes astronómicos de la NASA.

En los siguientes estratos se van montando servidores que toman la hora de uno o varios estrato 1 y la sirven a estratos inferiores, con el objetivo de no saturar la carga de los servidores de más alto estrato y hacer más precisa su información. Los servidores de estrato 1 no suelen facilitar información a clientes, sólo a otros servidores. Técnicamente, no existe un limite en cuanto al número de estratos que puede haber en una jerarquía NTP, pero como convencíon podemos decir que 12 es el número máximo.

¿Como funciona NTP a nivel lógico? Sencillamente, cuando un cliente solicita información de hora a un servidor, este le devuelve su hora local, su huso horario y su estrato. Si no está configurado para ser fuente directa, en lugar de su hora local devuelve la hora del servidor o servidores con los que esté sincronizado. El cliente es el que se encarga de hacer los cálculos para decir que hora se queda.

Y ahora, ¿como se implementa? NTP es tremendamente sencillo. Veamos como se implementa en Windows y en Linux:

IMPLEMENTACIÓN DEL SERVIDOR

Windows:

Para implementar un servidor NTP en Windows, simplemente debemos descargar el servidor desde la web de Meinberg, que realiza el desarrollo para Windows. La licencia es libre.
Ejecutamos el fichero descargado y seguimos las instrucciones para instalación completa. Acto seguido, comenzamos a configurar el servidor:

En este menú, podemos dejar por defecto la ruta del fichero de configuración. A continuación marcamos la casilla “Crear configuración inicial”. Podemos elegir entre sincronizar contra fuentes estándar del pool de NTP.org en la primera pestaña, o especificar una lista de servidores personalizados en el cuadro de abajo. Puedes dejarlo vacío si quieres que la única fuente sea el reloj interno del servidor.

NOTA-YA-TE-LO-DIJE: No es buena idea utilizar el reloj interno del servidor como fuente de hora NTP por su imprecisión, salvo que este esté sincronizado a su vez con otra fuente por otro medio (como un controlador de dominio). Tampoco es conveniente tener muchas fuentes de hora: no te darán más precisión, si cabe menos. Es mejor tener dos o tres fuentes cerca de tu área geográfica que 14 de todo el mundo.

También se puede especificar si se va a usar la característica iburst. Más inforamción sobre esta característica en la web de Meinberg. En la siguiente casilla especificaremos que estrato tiene el servidor, útil si estás montando tu propia jerarquía.

Una vez instalado y configurado, dispones del siguiente menú en Inicio para controlar el servicio:

Haciendo click en la opción Start ya lo tendremos listo para aceptar peticiones.

Linux/Unix:

En los sistemas Linux/Unix es habitual que el demonio ntpd venga instalado de serie. Si no lo estuviese, es tán sencillo como instalarlo empleando los sistemas de paquetería habituales.

Los usuarios de Mandriva harán:

# su
# urpmi ntpd

Los usuarios de Debian harán:

# su
# apt-get install ntpd

Y si usas Solaris debes descargar el paquete desde Sun Freeware y ejecutar:

# su
# gunzip ntp-4.2.6-sol10-sparc-local.gz
# pkgadd -d ntp-4.2.6-sol10-sparc-local

A continuación procedemos a configuar el servicio. Si tienes un asistente gráfico, mejor que mejor, sino edita el ficero /etc/ntp.conf con tu editor de texto habitual. Veamos como es el fichero con su explicación:

# Esta línea permite que otros se sincronicen con nosotros,
# pero sin modificarnos.
restrict default kod nomodify notrap nopeer noquery

# Permitimos todas las conexiones por la interfaz de loopback,
# para sincronizarnos nosotros mismos
restrict 127.0.0.1
restrict -6 ::1

# En esta línea podemos dar permisos especiales a un determinado rango de red.
# Pon los rangos de red y la máscara de subred que se puedan conectar a tí.
# Más información sobre esto en ntpd.og.
#restrict 192.168.1.0 mask 255.255.255.0 nomodify notrap

# Aquí indicamos que si no hay ninguna fuente disponible, utilicemos
# nuestro reloj de hardware como fuente, indicando el estrato.
fudge 127.127.1.0 stratum 10

# Este fichero contiene la varianza entre la hora cedida y la cargada.
# No lo toques.
driftfile /var/lib/ntp/drift

# Fichero de claves para uso de criptografía cruzada.
# No lo toques-.
keys /etc/ntp/keys

# A continuación especificamos los servidores con los que nos vamos a sincronizar,
# así como las reglas que vamos a aplicar con cada uno de ellos.
# Si no hay nada se empleará la fuente local.
server 192.168.13.238
restrict 192.168.13.238 mask 255.255.255.255 nomodify notrap noquery

Para crear un servidor, únicamente debemos especificar los servidores a los que vamos a sincronizar o la línea fudge para ser nosotros fuente, y especificar el rango de red que podrá solicitar sincronización.

Después, arrancamos el servicio según nuestro sistema operativo.

IMPLEMENTACION DEL CLIENTE:

Al ser un servicio estándar, para configurar el cliente es irrelevante el SO del servidor. Todos funcionan con todos. Veamos lo sencillo que es configurar un cliente:

Windows:

En Windows la forma más sencilla de configurar NTP es hacer doble click sobre el reloj. En el cuadro que se despliega seleccionamos la pestaña Sincronización de Hora de Internet y dentro marcamos la casilla “Sincronizar automáticamente con un servidor de hora“. Indicamos en la pestaña el nombre del servidor y pinchamos en “Actualizar ahora“.Si todo va bien debería coger la hora sin problemas.

Linux/Unix:

Para sincronizar con Linux y Unix, igualmente debemos tener instalado el paquete ntpd. Lo instalamos si no lo tenemos como hemos explicado antes.

Desde una consola, ejecutamos el siguiente comando:

# ntpq -p host-ntp

Donde host-ntp es el nombre de host o IP del servidor NTP que hemos configurado. Con este comando testeamos si somos capaces de sincronizar con el servidor. Si funciona, nos devolverá una línea por cada fuente configurada del servidor. En este ejemplo el servidor sólo tiene configurada com ofuente su hora local:

# ntpq -p time.server.com
remote refid st t when poll reach delay offset jitter
==============================================================================
*LOCAL(0) .LOCL. 12 l 35 64 377 0.000 0.000 0.001

Una vez hemos comprobado que llegamos, simplemente editamos el fichero /etc/ntp.conf y añadimos las siguientes líneas al final por cada fuente:

server [host]
restrict [host] mask [subnet] nomodify notrap noquery

Arrancamos o reiniciamos el demonio ntpd y podremos comprobar como ahora servidor y cliente comparten al segundo la misma hora.

Named Pipes ¿Que son?

Sin duda una de las herramientas más útiles, características e indispensables de cualquier shell de sistemas tipo Unix (Linux incluido of course), son las llamadas tuberías o pipes. Las tuberías (representadas con el carácter ASCII |)se emplean para interconectar procesos, siendo su uso más habitual el pasar el resultado de la ejecución de un comando a la entrada de otro. Un ejemplo habitual sería:

ps -ef | grep wine.exe

En este comando estamo ejecutando ps con las opciones e y f, con lo que obtenemos un listado completo de procesos con nombre de usuario, PID, y el comando completo que ha lanzado el proceso, entre otras cosas. Toda esa información, en lugar de mostrarla por salida estándar, se la pasamos como entrada mediante una pipe a grep, al que le indicamos que tome dicha entrada, filtre aquellas líneas que contienen la cadena “wine.exe”, y nos las muestre por salida estándar. Con esto localizaríamos todos los procesos que contengan dicha cadena, lo cual a efectos de administración es algo muy cómodo.

En principio conocemos a los pipes como pipes o tuberías, pero sería mas correcto conocerlos como pipes anonimos, puesto que existe otro tipo de tuberías con similares características pero diferente finalidad y uso llamadas Named Pipes (Tuberías con Nombre).

Las Named Pipes son, basicamente, un fichero en disco. La diferencia consiste en que en lugar de ser un contenedor de datos, los Named Pipes actúan como torrentes de caracteres (stream), por lo que se puede indicar a otro o a otros procesos que lo lean y capturen al vuelo la información que contiene.

Ya tenemos las dos primeras diferencias entre una pipe y un Named Pipe: De un Named Pipe pueden leer varios procesos al mismo tiempo, cada uno de ellos puede extraer la información que necesita y procesarla sin tener que esperar turno. Otra característica importante es que los Named Pipes no almacenan datos, por lo que una vez terminado su uso simplemente vuelven a tamaño cero.

Pero, ¿para que podemos usar un Named Pipe? Supongamos que tenemos un script de Perl que lee de varios ficheros de log del sistema y genera un reporte. Dicho reporte es muy largo y el fichero generado es muy pesado, por lo que queremos comprimirlo en un tar.gz para enviarlo por email. Dado que tar y gzip no leen por entrada estándar, es necesario especificarles un fichero, por lo que el proceso normal consistiría en ejecutar el script de Perl, escribir el fichero, y después generar el tar.gz.

Sin embargo, si utilizamos una Named Pipe, podemos hacer que el script vuelque su salida en un Named Pipe y mientras tanto tar vaya leyendo el Named Pipe y comprimiendo. El resultado será únicamente el fichero comprimido, pues el tamaño de la tubería seguirá siendo 0. Útil si tienes el espacio en disco ajustado y quieres ahorrarte un tiempecito.

¿Como se usa una Named Pipe?

Lo primero es crearla, para ello utilizamos el comando mkfifo:

$ mkfifo /tubería

Acto seguido la tendremos disponible para realizar cualquier operación utilizando redirecciones:

ls -lrt > /tuberia

De cara a un script, sería más sencillo introducirla en una variable:

mituberia = /tuberia
mkfifo $mituberia
ls -lrt > $tuberia.

Las Named Pipes no son ni de lejos las más utilizadas en Bash Script. De hecho, no es habitual verlas puesto que en la mayoría de los casos es más sencillo utilizar tuberías anónimas. En cualquier caso, es muy interesante saber de su existencia porque en determinados contextos pueden sernos de gran utilidad.

Unix y el 2038: El otro "bug" del milenio

Para aquellos que sigan pensando que el año que viene se acaba el mundo porque lo dijeron los mayas, que sepan que están equivocados. No muy lejos queda el fin del mundo, pero no será hasta el 2038 que se irá todo a la porra.

¿Y porqué se irá a la porra? Porque la gran mayoría de nuestros sistemas informáticos no está diseñado para generar una fecha superior al 19 de Febrero de 2038.

Bueno, el mundo no se acabará (esperemos), pero el problema en si es real y se están buscando soluciones.

¿Y porqué se acaba el mundo? Sencillamente, por una limitación de diseño en los sistemas basados en POSIX, en los cuales el tiempo se va midiendo en forma de un número decimal, encarnado por el número de segundos transcurridos desde el 1 de Enero de 1970 hasta ahora.

El problema es que ese número decimál, de tipo Integer, es de 32 bits. Y las fechas superiores a la indicada arriba desbordan la capacidad de este tipo de números, con lo que los sistemas, que son muy cucos, convierten dicho número en negativo. En la práctica volvemos a 1970.

Si con esto no te enteras de ná, este gráfico de la Wikipedia es muy explícito:

En el se puede comprobar como efectivamente a partir de 19 de Enero de 2038 el número entero que define el tiempo transcurrido se vuelve negativo, se resetea a si mismo. Es algo parecido a lo que sucedió con el famoso Efecto 2000, salvo que en aquel caso el problema erá también de hardware. En este caso, el hardware no tiene problema.

¿Y como vamos a evitar que una cosa tan tonta no nos arruine? Pues sencillamente, desarrollando e implantando los sistemas de 64 bits. En realidad todos los que hayáis adquirido un PC en los útlimos 2 o 3 años no tendréis este problema mientras instaléis un Sistema Operativo de 64 bits. El verdadero problema está en las grandes infraestructuras bancarias, militares, científicas, corporativas, etc. cuya tecnología se remonta al amanecer de los tiempos y que no queda más que migrar, en casos mediante inversiones millonarias.

Y si no, ya vendrá John Titor a salvarnos.

Referencias:

• Pagina web del problema del año 2038.
• FAQ’s del Efecto 2038
• John Titor, el viajero que vino del futuro para solucionar el problema del Y2k38 en su tiempo.

Algunos cambios

En la línea de cambios que estoy llevando, y a modo informativo, os informo que he cambiado lo siguiente:

- autoestopistainformatico.proyectopqmc.com ya no existe. Para darle más coherencia, la página de siempre estará accesible a través de guia.proyectopqmc.com. Mas facilito de recordar, ¿eh?

- Al blog nuevo se accederá simplemente mediante blog.proyectopqmc.com.

- En breve se aplicará un proxy inverso para dejar las URL’s limpias y accesibles. A Google le va a encantar y a vosotros se que también.

Todos estos cambios desde ya. Si me tenéis enlazado, por favor cambiad los enlaces.

Por que Vim y no Vi

Pues sencillamente por esto:

Si uno tiene que manejar cadenas de comandos muy largas, comandos con muchísimas opciones, o es aficionado al &&, se puede encontrar con que un día, no puede editar un script porque se encuentra con una pantalla como la anterior. ¿Pero que significa esto? ¿Acaso el fichero de texto se ha corrompido? Y sobre todo, ¿por qué more me muestra la información del fichero correctamente?

La respuesta es que el viejo Vi sólo puede manejar líneas de fichero con una longitud máxima de 2048 caracteres (espacios incluidos). En el momento en que la línea sea màs larga os mostrará una pantalla como la que véis y un bonito mensaje como el que aparece en la última línea.

Por eso Vim y no Vi. Porque Vi como tal apenas ha sufrido cambias en sus ultimas versiones, mientras que Vim y otros clones han aumentado sus capacidades para ofrecer el manejo de líneas y ficheros más grandes, así como por ejemplo, sintaxis resaltada. Que es bien útil.

Que sea nuevo no significa que sea mejor. Que sea improved sí.

-Sobre Vim -> http://www.vim.org/

Oscuro estreno

Amigos míos, queridos lectores. Hoy estreno mi propio alter-blog: El Autoestopista Informático.

No les aburro con más perorata aquí. Sigan el enlace y descubrandlo por ustedes mismos.ç

Y siiii… Ya tengo twitter.

Si hace tus servidores seguros...

¿Por que no el resto de tu CPD?

Visto en el CPD de HyperMadHouse (aunque la foto no es de allí, sino de un Carrefour)

No es cachondeo. Los extintores Firefox también los tenemos en otra sede.