Xnoccio.com

Desde VIAVANSI, los redactores de Xnoccio os deseamos felices fiestas y que para el 2009 todo vaya bien o mejor. Gracias por vuestra fidelidad!

Hacía más de un año que sabía de la decisión que adoptó Airbus para incorporar Linux a sus super A380, pero no sabía que en los pequeñitos, como el A319 también lo podría encontrar.

Con esta y otras sorpresas volé hasta Bogotá; la verdad es que me hubiera gustado contarle a todo el mundo esta historia de otra manera, pero la realidad fue que en un viaje de 2 horas y 15 min. de duración el sistema se cayó en cuatro ocasiones, incluyendo reinicio general del sistema. Obviamente, en un vuelo tan corto no te da tiempo ni a ver una peli, pero si hubiera sido así….ejemm.

La solución adoptada (por lo que pude ver en la consola mientras se reiniciaba ) es una adaptación de RedHat.

Por cierto, también me llevé una grata sorpresa al comprobar que cada asiento dispone de una salida USB y, aunque no pude comprobarlo, supongo que estará como salida para cargar dispositivos como el iPod.

Bien por Airbus.

Gracias a OpenSearch podemos publicar un sistema de búsqueda de forma que sistemas externos puedan federarse y realizar búsquedas sobre nuestro sistema. Este mecanismo de integración puede ir más allá, e incluido en las cabeceras de nuestras web permite que Firefox e Internet Explorer ofrezcan la búsqueda directa sobre nuestra web. Para conseguir esto, los únicos pasos a realizar son declarar este servicio en el head de nuestra web y definir el servicio mediante un fichero OpenSearchDescripcion.

• Añadimos en el head de nuestro página web:

    <link rel="search" href="http://www.xnoccio.com/site_osd.xml" type="application/opensearchdescription+xml" title="Buscar información en Xnoccio">

• Creamos el fichero site_osd.xml al que hacemos referencia en el link:

<?xml version=”1.0″?>

<OpenSearchDescription xmlns=”http://a9.com/-/spec/opensearch/1.1/”>
<ShortName>Xnoccio (Buscador)</ShortName>
<Description>Busca en todos los artículos publicados en xnoccio</Description>
<Image height=”16″ width=”16″ type=”image/x-icon”>http://www.viavansi.com/opencms/opencms/viavansi/favicon.ico</Image>
<Url type=”text/html” method=”get”template=”http://xnoccio.com?s={searchTerms}”/>
<!–<Url type=”application/x-suggestions+json” method=”GET” template=”http://xnoccio.com?action=opensearch&search=searchTerms}”/>
</OpenSearchDescription>

Con esta mínima modificación conseguiremos que el navegador pueda ofrecer los servicios de búsqueda directamente al usuario de una forma muy sencilla.

He leído en la lista de Accesoweb de Sidar, que el El W3C acaba de publicar una nueva lista de recomendaciones en materia de accesibilidad. Es la WCAG 2.0 (Web Content Accesssibility Guidelines 2.0).

El W3C es la organización de mayor reconocimiento en materia de estándares web. Las especificaciones en esta materia de las administraciones públicas españolas, como la Junta de Andalucía o el Gobierno de España, hacen referencia siempre a las WCAG por lo que las pautas se convierten para nosotros en normas de facto.

Era evidente la necesidad de una revisión profunda de algunas de las pautas. Las indicaciones sobre uso de h1-h6 para identificar encabezados por ejemplo, con un uso más semántico que “topográfico”, es indicativo de esta nueva orientación.

Las nuevas recomendaciones se articulan sobre cuatro patas que debe tener cualquier contenido web:

• Perceptible (por ejemplo a través de alternativas textuales para imágenes, subtítulos para audio, presentación adaptada y contraste de colores);
• Operable (tratando el acceso del teclado, el contraste de colores, la coordinación de la entrada de datos, evitando el control automático y control de la navegación);
• Comprensible (teneniendo en cuenta la legibilidad y predicción del contenido, y la asistencia de introducción de datos); y
• Robusto (por ejemplo, manejando la compatibilidad con las tecnologías asistivas).

De todas maneras, mientras que la normativa con respecto a accesibilidad web no contemple un órgano regulador o una certificación oficial homologada, se seguirán poniendo alegremente en los portales las famosas “A”, “AA”, e incluso “AAA” (que se siguen manteniendo sin introducir la pintoresca A+) como quien tunea su buga con la pegatina de SuperTurbo, sin pasar siquiera los test automáticos, e incautos clientes que se verán deslumbrados con el dorado sello. De risa. O de pena :S

La nota de prensa:
http://www.w3.org/2008/12/wcag20-pressrelease.html

Y la recomendación en
http://www.w3.org/TR/WCAG20/

Este post no pretende ser más que una ayuda en castellano (encontrable vía Google) para aquellos que se encuentren con este problema en el futuro, ya que hemos encontrado bastantes referencias, pero pocas respuestas.

Los antecedentes

Nos encontrábamos en las instalaciones de un cliente, en un equipo Windows XP al cual le habíamos montado un kit de desarrollo completo: Eclipse (con diversos plugins), Maven, JDK, Tomcat’s de diversas versiones, etc., que tenía que integrarse con Hudson. En ese momento estábamos probando Maven sobre un sencillo proyecto de ejemplo; Maven debía descargar de un repositorio de librerías Artifactory recién descargado. Pero nos encontramos con efectos bastante raros:

• Al hacer un ‘mvn eclipse:eclipse’ en consola, observábamos que todos los JAR’s descargados daban un error de verificación de checksum.  Es decir, parecía ser que el contenido del JAR descargado no era exactamente el esperado. Y además no conseguíamos cargarnos la librería jline, una de las dependencias de las librerías de Plexus. Raro raro, porque nunca habíamos visto ese error. ¿Estaba pasando algo en algún repositorio público?
• Al hacer un’mvn clean’, algo mucho más raro todavía. Veíamos un log extrañísimo de repente saltaba un applet en pantalla que nos pedía confirmación de una operación. ¡Este plugin Maven nuevo!

Las pesquisas

Evidentemente aquí hay algo raro. En el log Maven aparecen mensajes que no habíamos visto hasta ahora:

Downloading: http://sanisidro:8080/artifactory/public/org/apache/maven/shared/ma
ven-shared-io/1.1/maven-shared-io-1.1.jar
116K downloaded
[WARNING] *** CHECKSUM FAILED - Checksum failed on download: local = 'e67415a960
00a3110c7834caa325d965022491f6'; remote = '02e1d57be05ecac7dbe56a3c73b113e98f222
40f' - RETRYING
Downloading: http://sanisidro:8080/artifactory/public/org/apache/maven/shared/ma
ven-shared-io/1.1/maven-shared-io-1.1.jar
116K downloaded
[WARNING] *** CHECKSUM FAILED - Checksum failed on download: local = 'e67415a960
00a3110c7834caa325d965022491f6'; remote = '02e1d57be05ecac7dbe56a3c73b113e98f222
40f' - IGNORING
[INFO] [clean:clean]
Current policy properties:
mmc.sess_pe_act.block_unsigned: false
window.num_max: 5
jscan.sess_applet_act.sig_trusted: pass
file.destructive.state: disabled
jscan.sess_applet_act.block_all: false
window.num_limited: true
jscan.sess_applet_act.unsigned: instrument
mmc.sess_pe_act.action: validate
jscan.session.daemon_protocol: http
file.read.state: disabled
mmc.sess_pe_act.block_invalid: true
mmc.sess_pe_act.block_blacklisted: false
net.bind_enable: false
jscan.session.policyname: TU1DIERlZmF1bHQgUG9saWN5
mmc.sess_cab_act.block_unsigned: false
file.nondestructive.state: disabled
jscan.session.origin_uri: http://repo1.maven.org/maven2/org/apache/maven
/shared/file-management/1.2/file-management-1.2.jar
mmc.sess_cab_act.action: validate
net.connect_other: false
jscan.session.user_ipaddr: 127.0.0.1
jscan.sess_applet_act.sig_invalid: block
mmc.sess_cab_act.block_invalid: true
thread.thread_num_max: 8
jscan.sess_applet_act.sig_blacklisted: block
net.connect_src: true
thread.thread_num_limited: true
jscan.sess_applet_act.stub_out_blocked_applet: true
mmc.sess_cab_act.block_blacklisted: true
jscan.session.user_name: 127.0.0.1
thread.threadgroup_create: false
file.write.state: disabled
-->> returning Frame NULL
BaseDialog: owner frame is a java.awt.Frame

Empezamos a pensar. Tras unos minutos de desconcierto, eso de jscan huele a antivirus. A ver si está haciendo algo, modificando los JAR’s al descargarlos, modificando alguna Java Policy, modificando la JDK, o incluso interactuando con las políticas de seguridad en runtime… efectivamente, buscando en Google nos lleva a comprobar que el culpable parece ser el antivirus de Trend Micro. Debe estar colocando el applet Java como medida de seguridad, interceptando el código original. El antivirus ha debido pensar que el JAR es un applet y, como hace operaciones de disco (un ‘mvn clean’ debe borrar ficheros), pide permiso. Pero, ¿qué y cómo lo está haciendo? Realizamos unas cuantas tareas:

• Paramos todos los servicios del antivirus. Probamos, sigue fallando. Este antivirus es un poco retorcido, ha debido modificar la JVM o alguna Java Policy.
• Restauramos la JVM, nos aseguramos de estar utilizando lo mismo. Sigue fallando, con el antivirus parado… ¿qué pasa aquí? ¿Dónde está la coleta de este Sansón de la seguridad?
• Probamos el applet de firma de Viafirma, que tampoco funciona. En la Java console observamos un error de un paquete com.trend (si al menos funcionara bien!)… El error era “Exception at com.trend.iwss.jscan.appscan.runtime …”. Nos bajamos el JAR de firma, lo descomprimimos y ¡voilá! Hay un buen conjunto de paquetes nuevos dentro de JAR. El antivirus modifica los JAR’s, lo cual explica todo: el misterioso applet del mvn clean, la rotura del applet de viafirma, los fallos de checksum… pero ¡el antivirus está apagado! ¿Cómo lo hace?

Las conclusiones

Si el antivirus en local no es culpable, debe haber un antivirus a nivel de red, junto al proxy. Efectivamente. El cliente, que por fortuna es técnico y de los que programan, no de los que sólo hablan, nos confirma que en muchas ocasiones ha tenido que utilizar otro proxy para descargarse JAR’s. El invento enemigo de los JAR’s no afecta sólo a Maven, obviamente, sino a cualquier JAR descargado por un proxy que disponga de este mecanismo de seguridad, y que realice determinadas operaciones. De hecho la librería JLine era parada por este producto llamado “Trend Micro InterScan Web Security Suite” que, de hecho, publicita este servicio tan majo y maligno a la vez.

Así que si en algún momento os encontráis este tipo de errores tan extraños, ya tenéis otra posibilidad latente.

El epílogo

Nos cambiamos de proxy y todo fue bien, previa limpieza del repositorio de librerías Maven.

Superada la cifra de 7 millones de DNI electrónicos en España, hemos sido testigos de cómo hemos alcanzado también el final de una etapa, la emisión del último DNI tradicional.

El último DNI sin “chip”, tal y como lo publica el país en este artículo, fue emitido a un afortunado ciudadano de un pueblo madrileño que podrá conservarlo como un buen objeto de coleccionistas.

Dos años han transcurrido desde la puesta en marcha del programa DNIe, y desde entonces hemos disfrutado de la incorporación paulatina de numerosos servicios basados en su uso, como la autenticación en algunos bancos.

Y más de un año desde que publicáramos este post donde anunciábamos la primera plataforma openSource con soporte para el DNIe, Viafirma.