Eloy Mier Pérez Site

Hola a todos de nuevo

De vez en cuando, normalmente debido a entradas anteriores, el sistema acaba teniendo algunos nombre de ficheros extraños o peculiares. De forma habitual son fácilmente eliminables del sistema, pero ¿que pasaría si nos encontramos con un fichero cuyo nombre comienza por – (por ejemplo -file o incluso -f)?, el comando:

rm -file

no funcionará. rm entenderá que se le están pasando cuatro opciones -f, -i, -l y por ultimo -e, y finalizará en la opción -l, por que no es una opción válida.

Podrías intentar usando un carácter de escape en el shell de la siguiente forma:

rm \-file

No obstante, si piensas un poco en lo que esta sentencia hace te darás cuenta de que así tampoco funcionará. El shell verá el código de escape, lo eliminará y pasará completo -file al comando rm; por lo tanto nos encontraremos con el mismo problema. Lo que necesitamos es escapar el comando rm, no el shell.

Existen varias formas de solucionar esto. La primera es usando --. Esta opción la usan muchos comandos para indicar el fin de las opciones. Si quisieses crear un directorio con nombre -test y posteriormente quisieses borrar ese directorio y todo su contenido el siguiente comando debiera funcionar:

rm -rf -- -test

-rf establece las opciones iniciales; el -- señala el final de las opciones, y que el resto después de esa señal debe ser pasado tal cual al comando. En el caso que nos ocupa, es el nombre del directorio a borrar.

Puedes probar con los siguientes comandos:

mkdir -- -test
ls -l -- -test
rm -rf -- -test

La otra opción posible es especificar el directorio del fichero. Para borrar el fichero -file en el directorio actual, debemos usar:

rm ./-file

Esta solución debería funcionar con otros comandos también. Para probar puedes ejecutar:

touch ./-file
ls -l ./-file
rm ./-file

Desde este momento, cuando te encuentres con este tipo de problemas en los nombres de fichero en tus directorios, ya no creo que tengas problema para dar buena cuenta de ellos ¿verdad?

Un saludo a tod@s y hasta la próxima.

Espero que hayas visto esto también — un mail tal como el de la captura siguiente.

En algunas ocasiones te puedes imaginar lo que significa “ basándote en el contexto. En este caso “ es una comilla doble a la izquierda y ’ es un apostrofe. Pero en general ¿quien es el guapo que quiere leer mensajes como estos? ¿que es lo que que causa este comportamiento?

El articulo de hoy va a versar sobre la codificación de caracteres, como funciona en el correo electrónico y en los navegadores web y en como asegurarnos de que nuestros mensajes no sufran los problemas que acabamos de ver.

ASCII

En los inicios de todo este mundo (aparte de Adan y Eva) solo existía ASCII: un simple conjunto de 127 caracteres (7 bits). En tu máquina linux puedes ver la tabla ASCII ejecutando el comando man ascii.

ASCII estaba bien para el idioma Inglés y para la mayor parte de los lenguajes de programación. Lamentablemente pronto los usuarios Españoles, Franceses y Alemanes comenzaron a quejarse: Écoutez! ¡Oye! Paß auf!

127 caracteres no eran suficientes para todos los caracteres que esos lenguajes necesitaban. Los vendedores de Sistemas Operativos decidieron comenzar a usar el 8º bit. Esto solucionó el problema,….mas o menos durante un mes (xD), hasta que los Griegos, Rusos, Chinos, etc. comenzaron también a demandar nuevas soluciones para poder usar del mismo modo sus propios lenguajes.

ISO-8859

En breve existían docenas de codificaciones distintas para todos los lenguajes y sistemas operativos. ISO-8859 fué un intento de estandarizar todos ellos, e incluia ISO-8859-1 o “Latin 1″ para lenguajes Europeos Occidentales, ISO-8859-2 para lenguajes Centro Europeos, y así de forma sucesiva.

Algunos programas se modificaron para que comenzasen a usar el  nuevo estandart ISO-8859, pero en cambio otros se aferraban a las antiguas codificaciones, tales como Windows 1252 (lenguajes Europeos Occidentales) y cp1251 (Microsoft Windows 3.1 Cyrillic). Mientras tanto, se encontraban nuevos problemas:: multitud de lenguajes Asiáticos usaban mas de 256 caracteres.

Unicode y UTF

Unicode era la solución: una tabla que incluía todos los caracteres de todos los lenguajes del mundo. Inicialmente se intento que cupiese en 2 bytes — pero 65,536 (216) “code points*” no eran suficientes. En la actualidad Unicode tiene 1,114,112 code points.

La representación de 1,114,112 caracteres requiere 21 bits, sin embargo, nadie quiere usar para cada carácter 3 bytes de longitud. Por lo tanto se desarrollaron los formatos de transformación Unicode. UTF-16 puede representar la mayor parte de los caracteres Unicode en 2 bytes, y crece algún byte mas para representar los caracteres poco usuales o los raramente usados. UTF-8 usa un solo byte cuando es posible hacerlo — para mensajes Ingleses que contienen los 127 caracteres ASCII originales,, UTF-8 es exactamente igual que ASCII.

Conjunto de caracteres en los correos electrónicos

Por lo tanto y visto lo visto, ¿por que vemos esos graciosos caracteres en los mensajes de mail?

Todos los mensajes llegan con una codificación concreta. Puedes usar la funcionalidad de “Encabezado completo” en tu cliente de correo y buscar en el encabezado (en Content-Type) la parte charset= .

Como se puede apreciar en este caso, el encabezado indica que el mensaje ha sido enviado con codificación iso-8859-1; y por lo tanto así lo visualiza mi cliente de correo. Pero tal y como podemos ver el mensaje contiene unas series de tres caracteres con esta pinta ’ que obviamente no era lo que el autor quería. ¿Que es lo que ha pasado?

Comillas inteligentes ¿idiotas?

La mayor parte de las ocasiones, esto se produce por que alguien ha pegado texto desde algún otro programa dentro del mail antes del envío. Esto es especialmente grave cuando se componen textos en un procesador de textos, como por ejemplo MS Word (probablemente el culpable en este caso) o OpenOffice, debido a la funcionalidad llamada “etiquetas inteligentes” o “smart quotes”.

Mis comillas dobles en la sentencia anterior son las clásicas dobles comillas ASCII. Por el contrario si escribo esa frase en OpenOffice, él intenta dárselas de ingenioso y asume que quiero decir algo mas: “smart quotes” Nótese que ahora las comillas son cruzadas y por lo tanto aparecen con direcciones opuestas.

La verdad es que se ven bastante mejor ¿verdad? El problema es que ahora esas comillas ya no son caracteres ASCII. Por poner un ejemplo, la doble-comilla cruzada izquierda en Unicode se corresponde con U+201C. En UTF-8, son tres bytes: en hexadecimal, son e2 80 9c.

Esto no es un problema mientras el programa que lo visualice sepa que se corresponde con UTF-8 y decodifique e2 80 9c correctamente. El problema es si pegas esos tres bytes dentro de un cliente de correo que piensa que la codificación es ISO-8859-1, el cliente de correo decodifica de forma incorrecta — y lo que se muestra es “.

Solucionando el problema en el mail

La buena noticia es que muchos clientes de correo proporcionan herramientas para solucionar estos inconvenientes. En nuestro cliente de correo debemos buscar un menú llamado “Codificación de caracteres” o algo similar.

En el caso de que estés viendo secuencias de 2 o 3 bytes puedes probar a cambiar a UTF-8 a ver si eso mejora algo. Por supuesto que también puedes probar otras codificaciones a ver cual de ellas es la que mejor “lee” el mensaje.

¿Y que es lo que pasa con los mensajes que nosotros enviamos?

Lo primero que debemos hacer es verificar que la codificación que tenemos establecida en nuestro cliente de correo tiene un valor sensato. La mayor parte de los clientes de mail tienen alguna opción para configurarla. Si no estás seguro de la codificación que quieres, te recomiendo que uses UTF-8 o ISO-8859-15, que se corresponde con Latin-1 con unos cuantos caracteres adicionales como el carácter de Euro.

Lo segundo es que intentemos no pegar texto en el cliente de mail. Como esto es prácticamente imposible dado que vivimos en la sociedad del copy+paste, deberíamos considerar deshabilitar las comillas inteligentes del procesador de texto y además verificar que tanto el procesador de textos como el cliente de mail usan la misma codificación de caracteres.

Páginas Web

Existe otro caso problemático: la operación de pegado usando como fuente una página web. Las páginas Web, al igual que los mensajes de mail, tienen una codificación. Si copias texto de una página Windows 1252 y lo envías como ISO-8859-15, puede ser que incluso recibas un mensaje de error debido al conjunto de caracteres usado.

Lamentablemente las páginas web no tienen la posibilidad de mostrar las cabeceras al contrario que los mails. En vez de eso, por ejemplo, en Firefox, click derecho sobre la página y seleccionamos “Ver información de página”.

Alguna veces el servidor no especifica la codificación y el navegador tiene que intentar averiguarlo. En algunas ocasiones, la adivinación no funciona correctamente. En el caso de que veas caracteres raros en una página web intenta usar la funcionalidad de selección de codificación de caracteres a usar de forma manual de esta manera obligas al navegador a leer la página de otra forma. Un caso claro de este problema, es esta misma página. Intenet Explorer no detecta bien la codificación de la misma, mostrando caracteres extraños.

Bueno pues esto es todo lo que necesitábamos saber de codificación de caracteres.

Hasta la próxima y un saludo a todos.

Hola a todos

En este articulo vamos a ver como configurar una máquina para aceptar conexiones XDMCP. Este articulo es una nueva versión debido a la gran diferencia con respecto a la configuración de xdmcp entre versiones anteriores de Ubuntu y la versión 9.10.

Configurar XDMCP en Ubuntu 9.10 es mas sencillo que en versiones anteriores. No se si recordáis, pero en anteriores versiones había que editar el fichero /etc/gdm/gdm.conf, buscar ciertos elementos y modificarlos oportunamente, en cambio en esta, simplemente tenemos que crear un fichero de configuración personal en /etc/gdm/. El fichero se debe llamar custom.conf.

El contenido del fichero debe ser este:

# GDM configuration storage

[xdmcp]
Enable=true
DisplaysPerHost=10  #esta línea es para solucionar un problema con múltiples conexiones….de momento la tengo puesta

[chooser]

[security]

[debug]

Y ya está, para poder ver el servidor XDMCP activo tenemos 2 posibilidades

• O bien reinicias la máquina
• O bien reinicias gdm con service gdm restart (/etc/init.d/gdm restart)

Saludos a todos.

Para un próximo articulo veremos a ver si en la Beta de Ubuntu 10.04 se configura de la misma forma XDMCP.

Hola a todos de nuevo

Hoy que ando un poco aburridete me he puesto a probar un poco la nueva versión de Ubuntu 10.04 Beta 1. Vamos a hacer un recorrido por la instalación del producto sobre todo para acercar a los nuevos usuarios la nueva interfaz del sistema:

Comenzamos la instalación…seleccionamos el idioma y en mi caso lo voy a instalar, para eso he montado una nueva máquina virtual en el servidor:

Selecciono el uso horario:

Para la instalación he creado un disco virtual en el servidor de 40G, espacio mas que suficiente para probar esta versión beta a la espera de la definitiva.

Le damos a siguiente y comienza el proceso de instalación, como siempre, creo que hasta el momento se mantiene en la linea de sus predecesores. Personalmente pienso que esa política es buena, sobre todo para facilitar las cosas a las personas menos acostumbradas a las instalaciones complejas.

Continua con la instalación….El fondo del escritorio tiene buena pinta, de todas formas yo no soy muy pijotero con esas cosas, casi siempre me gusta lo que la gente de Ubuntu realiza a nivel gráfico en las distribuciones. Posiblemente el que se volverá loco sera mi cuñao…¿verdad Guiller?

Continua con la instalación, supongo que en breve me hará alguna pregunta de configuración…

Con respecto a la instalación, cuando comienza con la instalación de los paquetes de idiomas, está muy bien el detalle del relog de la cuenta atrás, asi tenemos una idea del tiempo que queda para concluir el proceso…

La instalación pide reiniciar….

Como comentario, al finalizar la instalación la versión 10 se ha dado cuenta de que el host tenia bloqueada la unidad de CD y me ha aconsejado desbloquearla desde el host para terminar la instalación y proceder al arranque….

En las siguientes capturas podemos ver el sistema corriendo. Me ha sorprendido muy gratamente la velocidad de arranque en la máquina virtual de esta versión. Desde que se le da la orden de reinicio en gnome hasta que se ve la ventana de loggin de nuevo tarda 20sg.

Un saludo a todos y hasta el próximo articulo…

Dentro de unos días a ver si puedo publicar unos comentarios sobre esta nueva versión…..me pondré a toquetear con ella y de paso a ver si puedo reportar algún problema…

Hola a todos de nuevo, buenos días

En este articulo vamos a echar un vistazo a munin (http://munin-monitoring.org/). Para aquellos que no lo conozcan munin es una aplicación que permite monitorizar máquinas en la red. Para ello munin se compone de 2 componentes completamente diferenciados, que son el nodo munin y el server. Para que una máquina pueda ser monitorizada por el server se requiere en esa máquina la instalación del software de nodo y además se requiere que el servidor la tenga agregada al fichero de configuración y que por supuesto el server pueda conectar con el nodo en el puerto definido (instalación por defecto 4949).

Como una imagen vale mas que mil palabras aquí tenéis un par de pantallazos para el server munin corriendo:

En esta imagen podéis apreciar la página de nivel superior generada por el servidor a partir de la información recopilada de los nodos:

Como podéis apreciar en la imagen superior, en mi red, y dentro de la plataforma de monitorización se encuentran 4 máquinas:

• acerX3900 es un servidor vmware y antiguo servidor munin (64b)
• odisea es la máquina de mi mujer un simple ordenador de escritorio (32b)
• princesa es mi máquina personal, ordenador de escritorio (64b)
• ubuntueeebox es el nuevo servidor munin (32b).

Si selecciono ubuntueeebox para ver los gráficos que obtiene el server podremos apreciar algo similar a:

Y si pincho en un gráfico para ver el detalle, lo que obtengo es el gráfico de días + semanas + meses + año:

Para obtener la información que se ha mostrado en los gráficos anteriores, munin-node, hace uso de una serie de scripts en el nodo. Si esos scripts (pluggins) están habilitados y son capaces de obtener la información que se supone que deben obtener entonces el server recibe dicha información y la pinta. Si por el contrario desactivamos el pluggin, el server simplemente no pinta el gráfico asociados. En el caso de que el pluggin este habilitado y no sea capaz de obtener la información necesaria, el servidor simplemente pinta el gráfico vacío. Un caso típico por ejemplo de esta última casuística es el siguiente: en el nodo tenemos habilitado el pluggin de monitorización de HD pero no tenemos instaladas las herramientas de bajo nivel necesarias (smartmoontools) y por lo tanto el nodo munin no es capaz de enviar al servidor información de monitorización de los discos.

Hoy vamos a tratar un tema cuanto menos curioso, que es la migración de un servidor munin de arquitectura 64b a arquitectura 32b. Inicialmente cuanto me plantee el cambio de servidor para munin, la verdad, es que no pensaba que requeriría ningún proceso especial para realizarla. Una vez montado munin server en la nueva máquina, con el servicio corriendo y los ficheros de datos(rrd) instalados resulta que viendo que no actualiza dichos ficheros me paso por el log (/var/log/munin) del server y veo un mensaje similar a:

El fichero no ha podido ser actualizado por que procede de otra arquitectura distinta a la actual. El mensaje exacto es

This RRD was created on another architecture

Bien, parece ser que los ficheros rrd que usa el servidor munin son dependientes de la arquitectura de la máquina, no tenia ni idea. Así que me puse a investigar un poco sobre cómo poder portar los ficheros existentes, mas que nada por no perder la información histórica de las máquinas.

Finalmente di con la solución, el proceso que debemos seguir es:

1. Exportación en el servidor 64b de los ficheros rrd a xml usando la herramienta rrdtool dump.
2. Copia de los ficheros exportados (xml) a la máquina con la nueva arquitectura, en mi caso ubuntueeebox, que es el nuevo servidor munin.
3. Importación de los ficheros xml a ficheros rrd pero en arquitectura 32b. Uso de la herramienta rrdtool restore.
4. Copia de los nuevos ficheros rrd en el directorio de datos munin (en mi caso /var/lib/munin/casamier)
5. Ahora ya podemos arrancar de nuevo el servidor de munin, no deberíamos recibir mas errores de arquitectura.

Bien, puesto que en el servidor tengo bastantes ficheros rrd y la herramienta rrdtool no acepta un comodín, pues no queda mas remedio que hacer un par de scripts para la exportación e importación. Los scripts que he escrito son muuuuy simples, no reciben parámetros y deben ser ejecutados desde el directorio que contiene los rrd y los xml.

Script para el paso numero 1 (exportacion a xml) en el servidor origen:

eloy@ubuntueeebox:~/casamier$ cat exportarRRD
#!/bin/bash
for file in $( ls *.rrd ); #recorremos solo los ficheros rrd
do
orig=$file
dest=$(echo $file | sed -e “s/.rrd/.xml/”)
rrdtool dump $orig $dest
done
exit 0

Script para el paso número 3 (importación a rrd) en el servidor destino:

eloy@ubuntueeebox:~/casamier$ cat importarRRD
#!/bin/bash
for file in $( ls *.xml ); #recorremos solo los ficheros xml
do
orig=$file
dest=$(echo $file | sed -e “s/.xml/.rrd/”)
rrdtool restore -r -f $orig $dest
done
exit 0

Bueno, pues hasta aquí la historieta de hoy. Para un proximo articulo, a ver si puedo mostraros la configuración del server y de los nodos.  Espero que tengáis buen día todos. Saludos y hasta la próxima.