viernes, 18 de diciembre de 2009

El falso proxy

A primera vista, un proxy falso (o mal configurado), lo único que puede provocar es que no naveguemos en absoluto por la red. Sin embargo, bien configurado, puede ser un sustituto casero para permitir el acceso a determinados sitios, y restringir el resto. Efectivamente, sería mejor montar una solución con Squid, pero ya he dicho que es un remedio casero, siempre y cuando, la lista de sitios permitidos no sea muy grande.

Un ejemplo válido sería un ordenador de consulta público, en modo quiosco, en el que sólo queremos que se pueda visitar la web de nuestra empresa.

El truco radica, básicamente, en configurar un proxy inexistente en el navegador web y poner como excepciones de ese proxy, la lista de sitios a los que se quiere dar acceso exclusivo. La gracia del truco está en que esta configuración no pueda ser cambiada por el usuario que tiene acceso al navegador.

A continuación, vamos a configurar adecuadamente el navegador Firefox para que sirva a nuestros propósitos. Los parámetros a configurar son:

  • network.proxy.type: Deberá tener valor 1 para hacer la configuración manual del proxy.

  • network.proxy.http: Este es el lugar donde indicaremos el nombre del falso proxy.

  • network.proxy.http_port: Indica el puerto de escucha del proxy. Como en nuestro caso no existe, pondremos un valor comprendido entre 1024 y 65535.

  • network.proxy.share_proxy_settings: Al poner a true esta clave, la configuración para el protocolo HTTP valdrá también para el resto de protocolos (SSL, FTP, ...).

  • network.proxy.no_proxies_on: Como valor, separados por comas, pondremos la lista de sitios a los que sí se quiere tener acceso.


Ahora, lo que interesa es poner en el sitio adecuado los parámetros anteriores. Deberán estar en la configuración global del navegador (para que afecte a todos los usuarios de la máquina) y estarán bloqueados para que nadie los pueda modificar en su configuración local.

¿Cómo bloquear las preferencias? Para ello utilizaremos la directiva lockPref. El código resultante sería el siguiente:

// Opciones bloquedas
lockPref("network.proxy.type", 1);
lockPref("network.proxy.http", "falso.proxy.miempresa.com");
lockPref("network.proxy.http_port", 8888);
lockPref("network.proxy.share_proxy_settings", true);
lockPref("network.proxy.no_proxies_on", "miempresa.com,otrapagina.com");
lockPref("browser.startup.homepage", "http://miempresa.com");

Además, hemos incluido la opción browser.startup.homepage, para que la página de inicio del navegador sea una de la lista permitida (la principal). Aunque siempre es posible bloquear más opciones de configuración.

Para el final, hemos dejado la parte difícil: elegir el sitio donde poner el código. Como ya hemos dicho, no interesa poner esta configuración en el perfil del usuario de consulta, sino que es mejor que esté a nivel global y con permisos restringidos.

Llamaremos al archivo de configuración con los bloqueos lock.js. Este fichero lo tendremos que colocar dentro del directorio de instalación de Firefox. Para Windows sería %ProgramFiles%\Mozilla Firefox\ y para entornos Linux, algo parecido a esta ruta: /usr/lib/firefox/.

Por último, para que Firefox tenga en cuenta estos nuevos parámetros, habrá que añadir o modificar los siguientes parámetros:
  • pref("general.config.filename", "lock.js"); Así se indica un fichero adicional de configuración. No debe indicarse la ruta, sólo el nombre.

  • pref("general.config.obscure_value", 0); El valor 0 permite que el contenido del fichero lock.js vaya en texto claro. Por defecto, suele tener el valor 13, y eso significaría que el archivo debe estar codificado.


Dichos parámetros se encuentran dentro de los ficheros de configuración globales de la aplicación, y es en este punto donde hay alguna variación de la ruta, dependiendo de la versión de Firefox. Algunos ejemplos:
  • Para la versión 3.0 de Firefox para Windows, el fichero a modificar sería %ProgramFiles%\Mozilla Firefox\greprefs\all.js.

  • Para Fedora 12 y Firefox 3.5, el fichero sería /usr/lib/firefox-3.5.5/defaults/preferences/firefox.js.


Pero es conveniente avisar que, dependiendo de la distribución de Linux utilizada, estos parámetros pueden encontrarse en algún otro fichero que haya en ese directorio.

lunes, 12 de enero de 2009

Pidgin y el protocolo MSN

Hoy, como todos los días, he llegado a casa y he puesto en marcha mi cliente de mensajería instantánea multiplataforma, Pidgin. Pero hoy, una de las cuentas, la de MSN para más señas, no ha conectado al iniciar el programa. El mensaje que mostraba Pidgin era el siguiente:

Unable to retrieve MSN Address Book


Lo primero que he hecho, ha sido intentar entrar con mi cuenta passport en el sitio de Windows Live para verificar si estaba o no activa.

Como sí lo estaba, he empezado a buscar por Internet. Allí, he encontrado una noticia que señalaba que hoy (precisamente hoy), Microsoft había hecho un cambio en el protocolo y que era necesario instalar un nuevo plugin en Pidgin para solucionar el problema. O eso, o utilizar otro programa de mensajería.

De hecho, al probar con Kopete (el cliente por defecto del escritorio KDE), he entrado sin inconvenientes a la cuenta y he podido acceder a mis contactos. Otro programa que recomendaba la noticia era Empathy Instant Messenger. Aunque el programa es bastante más simple que Pidgin, también ha funcionado a la primera.

Pero el asunto es que quería solucionar el problema para Pidgin. Existe ya, desde hace unos meses, un paquete específico con el plugin para los usuarios de Ubuntu, que se puede descargar desde la web oficial del proyecto (msn-pecan, Alternative MSN protocol plugin for libpurple) y que también reside en los repositorios de la distribución.

En cambio, para Fedora, sólo parecían existir 2 opciones:
  • Compilar el fuente.
  • Esperar a que Pidgin (que ya comentan en su web el problema y que ya están trabajando en ello), sacara una actualización para el sistema.


Pero he encontrado una tercera opción. Edouard Bourguignon, ha compilado el código fuente y ha hecho un paquete específico para Fedora Core 10 y lo ha colgado en su página web. Gracias a él (otro héroe anónimo del software libre), el imprevisto con el protocolo MSN ha estado resuelto en menos de un día, preparado para miles de usuarios.

El último paso para volver a conectar con la red MSN en Pidgin, tras instalar el paquete, es reiniciarlo y cambiar el tipo de cuenta de MSN a WLM.

¿Qué sistema de pago hubiera hecho lo mismo, de forma gratuita, para sus clientes, en tan poco tiempo?

lunes, 5 de enero de 2009

Actualización de Fedora 7 a la versión 10

Un año y medio en informática es muchísimo tiempo y, más si cabe, si hablamos de la evolución de escritorio de las distribuciones Linux. Desde mediados del año 2007, en el que me instalé Fedora Core 7, tan sólo había renovado el sistema con las actualizaciones de seguridad de la versión. Por fin, estas navidades, aprovechando el tiempo libre, me decidí a hacer un upgrade de la distribución.

Primera desilusión

Fedora, que está basada en Red Hat, tiene yum como gestor de paquetes. Podríamos decir que yum es a Fedora como apt es a Debian: la herramienta que permite instalar lo que necesitas sin preocuparte por las (odiosas, en algunos casos) dependencias.

Una de las opciones que tiene yum, es actualizar el sistema entero a través del modificador upgrade. Al menos, eso era lo que creía. Siempre que ejecutaba el comando en cuestión, llegaba al mismo problema irresoluble de dependencias conflictivas. ¿No se suponía que esta herramienta era, precisamente, la indicada para no tratar nunca más con semejantes problemas? Pues no hubo manera, aún cuando, en un intento desesperado, le cambié las direcciones de los repositorios para apuntar a las versiones más modernas (e inestables) de dichos repositorios.

El único camino posible

La única alternativa viable era iniciar una instalación/actualización desde un CD de la nueva versión. Para ello, aprovechando la magnífica banda ancha de la que disponemos en España, me descargué la ISO más pequeña, que instala todos los componentes desde los repositorios de Internet.

Para que este método funcione, por precaución, siempre es conveniente seguir estas 2 normas:

  1. Tener los datos de los usuarios (/home) en una partición diferente a la del sistema. (Actualmente, casi todas las distribuciones Linux respetan esta norma y no hay que preocuparse por ello.)
  2. Hacer una copia de seguridad de los datos, en otro disco duro independiente al del sistema (o en un DVD, si cabe).


Primer arranque tras la instalación

Antes de comenzar con los problemillas que encontré tras la actualización de Fedora, un comentario sobre el proceso de instalación: el asistente de instalación a través de red es verdaderamente simple, pero casi demasiado escueto en información sobre el proceso (cada vez se parece más a la filosofía de Windows, ocultando el máximo de información...).

Ahora, empecemos con lo bueno. El proceso de arranque de esta versión 10 es muchísimo más simplista que el de la 7 (está visto que hay que parecerse al sistema de ventanas como sea...). Mi anterior sistema estaba preparado para entrar en modo gráfico tras el arranque, pero tras el upgrade... este último paso, falló. Al menos tenía acceso al sistema desde la consola de texto. También tenía acceso a Internet para buscar soluciones, pero... sin modo gráfico... ¿cómo continuar?

Había una alternativa de primeros auxilios, y otra un poco más... ¿cómo decirlo?, de chico con recursos. La primera consistía en instalar (en modo texto) un navegador en modo texto, como lynx o links. La segunda, por la que opté, era utilizar otro ordenador para conectarme a Internet en busca de información. Para ello, me agencié un Acer Aspire One con Linux preinstalado (una distro llamada Linpus que está basada en Fedora) y procedí a solventar mi contratiempo.

En uno de los foros donde recalé, indicaban que buscara más detalles sobre el problema en el fichero /var/log/Xorg.0.log. Editándolo, pude ver al final del mismo, estas líneas:

(EE) No devices detected
Fatal server error:
No screens found


Increible, pero cierto. Hasta hace unos minutos había tenido mi servidor X funcionando a la perfección, pero el proceso de actualización había sido incapaz de reconocer mi tarjeta gráfica (pese a que todo el procedimiento se había llevado a a cabo en modo gráfico).

Por suerte, existía una solución: ejecutar en modo root el siguiente comando (habiendo realizado antes una copia del fichero /etc/X11/xorg.conf, por si acaso):

# system-config-display


Tras reiniciar el equipo, la secuencia de arranque se completó hasta el final correctamente, pero... siguieron las sorpresas.

Nueva versión de KDE

Una especie de déjà vu recorrió mi mente la primera vez que vi arrancar el escritorio KDE. Parecía que estaba viendo el escritorio de XP: limpio como una patena, sin ningún icono ni documento a la vista. ¿Quién se había llevado mis lanzadores de aplicaciones y archivos?

Hasta entonces, KDE (versión 3.5), siempre me había parecido un entorno muy amigable (aunque tal vez, demasiado parecido al de Windows), pero la desaparición de iconos del escritorio (en esta versión 4.1) ya me parecía un toque de mimetismo demasiado... cruel. Así pues empecé a investigar por el nuevo sistema, por si era una opción de configuración (como en su alter ego). Después de un rato de no encontrar nada, pasé la búsqueda al ámbito de Internet. Tan sólo extraje como conclusiones que KDE reinventaba el escritorio y que la documentación oficial sobre Plasma (que así se llama ahora la aplicación que lo controla) está un poco verde todavía.

Lo que parecía claro, es que el directorio /home/mi_usuario/Escritorio no era lo que estaba viendo en pantalla y que, ahora, no se creaban lanzadores, sino applets (incluso se pueden utilizar los de Mac OS X), widgets y plasmoids.

¿Dónde estaba el explorador de archivos?

Eso es lo que me pregunté cuando intenté ver el contenido del disco duro. Ni rastro de Konqueror, ni de su sustituto en esta versión: Dolphin. Tampoco encontré el programa de terminal de KDE: Konsole. Ni siquiera estaba el editor de textos sencillo, el programa KWrite.

Una vez más, eché mano de Internet a través de mi flamante nueva versión de Firefox (¡por fin podía disfrutar de la versión 3!). Llegué a una página donde podía buscar programas de Fedora, y me devolvía información sobre el desarrollo (código fuente) de la herramienta. De esta forma, pude encontrar la clave de la cuestión: todos los programas que echaba en falta, estaban dentro de un paquete llamado kdebase. Cuando busqué ese paquete en mi sistema (rpm -qa | grep kdebase), comprobé que, efectivamente, no estaba... el de la versión 4. Sí que seguía estando el correspodiente paquete para la versión 3. Entonces, ¿por qué no se había actualizado?

La herramienta yum, cuando actualiza paquetes, se fija en el nombre de los mismos. El formato de los nombres de los paquetes es como sigue:

nombre-versión-release.arquitectura.rpm


Resumiendo, que si el nombre no coincide, yum no actualiza. Eso es lo que había pasado en mi caso. El paquete, para KDE 3.5, se llamaba kdebase3, y, para la versión 4, el nombre había cambiado a, simplemente, kdebase.

Instalando manualmente el paquete (yum install kdebase), tuve de nuevo todos mis programas.

Inconvenientes con las codificaciones de archivos

Ni la nueva versión de Konqueror, ni el nuevo Dolphin, entendían algunos de los nombres de mis antiguos archivos: aquellos que estaban en una codificación distinta a UTF-8. Ni siquiera me dejaban, ninguno de los 2 exploradores de archivos, renombrar los ficheros de la discordia. Solución: hacerlo manualmente desde la línea de comando.

Esto, en cuanto a nombres se refiere. Pero el contenido de mis archivos de texto (abiertos con KWrite), en codificación ISO-8859-1, tampoco se salvaba de la quema. Como ya he dicho, ahora todos los programas en Linux, trabajan con UTF-8 por defecto, y cada vez va siendo más complicado cambiar este comportamiento. En KWrite, versión para KDE 3.5, existía un menú de la aplicación, donde se podía cambiar fácilmente el modo de la codificación, pero en la nueva versión, está algo más escondido. Más exáctamente, está en: Settings, Configure editor..., Open/save, General, opción Encoding autodetection. Es necesario poner el valor western european para ver correctamente el contenido de los archivos generados en ISO Latin 1.

Los nombres de las opciones de la aplicación los pongo en inglés, porque el instalador no me puso el paquete de español para KDE. Tal vez pase algo parecido que en el caso del paquete kdebase, pero la verdad es que el cambio de idioma no me afecta tanto como el perder programas.

Conclusiones

Seguro que me dejo de comentar más pequeñas pegas pero, por el momento, tan sólo comentaré una más: el directorio /sbin ya no está en el PATH del usuario root. Aunque solucionarlo es sencillo (añadirlo en el archivo .bash_profile del usuario, por ejemplo), no dejó de resultarme curioso que antes estuviera y ahora no.

La pregunta que me hago es si los problemillas que me han surgido en la actualización, también hubieran ocurrido en una instalación limpia. Por lo demás, con la nueva versión, el ordenador ha mejorado en rendimiento y la respuesta al usuario de los programas es más ligera que antes. Así que, pese a todo, el cambio ha sido para mejor.

En todo cambio, mudanza, innovación... hay pérdidas. Unas veces reales y tangibles, otras veces en comodidad. Pero si hay una cosa que he aprendido en este año que termina es que si no te atreves a cambiar, no hay posibilidad de mejorar y de aprender cosas nuevas.

Actualización (2009-01-14):
Como me temía, que KDE 4 estuviera en inglés en lugar de en español, era debido al cambio de nombre del paquete de internacionalización. En la versión 3.5 se llama kde-i18n-Spanish y, en la versión 4.1, pasa a ser kde-l10n-Spanish. Instalando el nuevo paquete y configurando el idioma en las preferencias del sistema (Systems Settings, Country & Language), el tema queda solucionado.