bureado

DebConf 11 will be held in Banja Luka, Bosnia and Herzegovina. Munich, Germany arrived on a close second and our bid, Quito, Ecuador, arrived last, allegedly because some points flipped over since DC 11 was meant to happen in Europe. So, after having three DebConfs hosted in America in the last four years, DebConf 11 will travel to Europe in 2011! Good news for all our fellow DDs and contributors over there.

The Banja Luka team managed to get an important support from their Government. They even met with the Prime Minister and got him to sign an offer of full support. I think this becomes dangerous for a DebConf, given that I’ve worked and have had mishaps while funding conferences with at least three governments (Ecuador, Venezuela and Brazil) with stronger levels of support (Law-like level) for free software and I know that at least other two governments in the World have unfortunately done this in the past. So we need backup plans and lots of follow-up activities with the stakeholders.

However, this agreement sets an important milestone in government support for free and open source software as well as Debian. I’ll use it in my Debian slides, and congratulations!

IMO, Munich would have made a great host for DC11 in terms of air travel connectivity, at a bigger hit on local costs, but nothing that would differ that much from DC7, though! I don’t think I’ll be able to make it at this moment to Bosnia (struggling for NYC) and at this point it’s premature to think on supporting Quito’s again for DC12. People and sponsors get gradually tired, even with spiritual commitment.

The DC10 decision meeting was long and lots of things needed to be improved. At that moment I thought the Project learnt useful lessons for future meetings, but we’re repeating ourselves now on the DC11 decision meeting. And now, I’m just hoping for the best, for the sake of the time and sanity of all us here. Ditch the priority list altogether, increase the stakeholders on the global team, filter bids early in the process and use more technology to improve the information flow before the decision!

I’ve been recently fiddling with Jasig’s CAS, an outstanding product which allows organizations to seamlessly centralize their login procedures and deploy single sign-on for the web. I call this Kerberos for the Internet, since the authorization is ticket-based (just as in Kerberos) but you don’t need to expose your KDC to the Internet or make assumptions on your user’s operating system setup.

Let’s assume you have several existing applications running in an Apache webserver. Let them be Tomcat-contained applications using mod_jk, Ruby, Python or Perl applications using either FastCGI, the mod_* preprocessors or the plethora of app-executing environments available for other programming languages. You don’t need to modify (or, as we call it, CASify) your applications to deploy centralized, controlled, single-sign-on authentication.

Since CAS only provides authentication (and not authorization, that is, it won’t grant users roles or permissions, and that makes sense since CAS is not aware of application capabilities) you only need to trust in the Web server’s REMOTE_USER HTTP variable. Of course, there’s a mod_auth_cas around for Apache which allows you to protect any part of your application with CAS. Or better yet, CAS-enable any part of your application. Talk about powerful.

Of course, you can always CASify your application by using libraries for your specific programming language which gets the ticket granting ticket and requests other tickets to CAS. In some cases, I even assume that’s the only available scenario, since inferior Web servers such as IIS might not have feasible solutions for the enterprise user.

Authentication is handled using authentication backends. Right, you weren’t expecting CAS to handle users and passwords in-memory. I’m using LDAP with OpenLDAP (of course) but RADIUS, JDBC (that is, any SQL database), X.509 client certs (fully passwordless solution, if you want to) and even SPNEGO for Kerberos are available and distributed among CAS. You’ll still need to build then using Maven but that’s not a problem (though Maven seems like an awkward build manager) and configuration is handled in detail on the Wiki.

Specially when compared with Shibboleth, which is the other big open source single sign-on player, CAS provides an enterprise-grade, robust, straightforward and easy to deploy solution to single sign-on for Web applications on the Internet. Go get it!

Ayer leía en los logs de Glenn Hauser que la Voz de América (el servicio de radiodifusión del Gobierno Federal de los Estados Unidos de América) había empezado una coproducción con Radio Martí (a la sazón, la voz de la disidencia cubana fuera de Cuba) llamada “A Fondo”, que se estaría emitiendo diariamente por SW en las frecuencias 7340, 9415 y 11625 KHz entre las 0100 y 0200 UTC. Al momento del QSL, no había demasiada información disponible sobre el programa.

Tanto Hauser como Kim Elliott argumentaban sobre el objeto del programa. El experimentado diexista Hauser hace notar que Radio Martí está siendo objeto de presión por parte del Congreso para salir del aire, y que podría tratarse de una estrategia del Gobierno para salir de esta incómoda emisora (que ellos mismos crearon) — y que el programa estaría siendo ahora dirigido a Venezuela, con el objeto de difundir mensajes de oposición al gobierno venezolano.

Hauser cita algunos pasajes de la primera transmisión (que fue ayer) como por ejemplo las protestas que se han estado desarrollando en los últimos días en Venezuela, citas de El Nuevo Herald, RCTV y otros medios ¿Será esto suficiente para calificar a VOA como una emisora de propaganda en contra de Venezuela?

Decidí sintonizar el programa hoy alrededor de las 0150 UTC (2050 EST) y lo conseguí en 11625, mucho mejor en 9415. La claridad de la voz y la intensidad de la señal eran sobresalientes, como casi todas las emisiones de Radio Martí que he escuchado tanto en Venezuela como en Ecuador. Ciertamente el programa está dirigido a una temática venezolana: en las entrevistas finales pude escuchar como hablaban de la Alcaldía de Caracas, junto a una entrevista a Milos Alcalay.

¿Mi opinión personal? El programa, al menos hasta ahora, transmite contenido de forma ecuánime. Sospechoso por supuesto el hecho de que el contenido se detalle con tanta densidad al respecto de Venezuela, siendo una emisora extranjera. Resulta curioso que ni siquiera la transmisión diaria del Canal Internacional de Radio Nacional de Venezuela, que tengo que oír por Internet porque la transmisión es un desastre¹, toca la actualidad con tanta profundidad. De hecho, la última transmisión que escuché se limitaron a leer Las Líneas de Chávez, y 2-3 noticias adicionales. Amanecerá y veremos.

¹ RNV utiliza repetidoras, como muchos servicios de radiodifusión por onda corta, en este caso de Cuba, pero la calidad de la transmisión es pésima. No dedico demasiado tiempo a hacer DX, pero nunca he podido escuchar bien a Radio Nacional de Venezuela, y he sintonizado emisoras en Argentina, Perú, Brasil, Colombia, Estados Unidos, Francia, España, Rusia, China…

Desde tiempos inmemorables, un grupo de profesionales venezolanos se ha responsabilizado por mantener el ccTLD de Venezuela, .ve. Desde hace ya varios años, esta actividad ha sido responsabilidad de NIC.ve, ahora parte de CONATEL.

A la fecha, un total de cinco servidores de nombres poseen copias y operan de forma autoritativa el ccTLD de Venezuela. Dos de ellos están fuera de Venezuela (Estados Unidos de América y Chile, específicamente), uno es hospedado por la ULA en Mérida y los dos restantes son operados por NIC.ve en Caracas. Adicionalmente, NIC.ve desarrolló y mantiene el portal, el sistema de registros, la lógica para registro y replicación (SRS, colectivamente) y el servicio WHOIS. Y de los 5 NS, 3 ofrecen servicio en IPv6 (el de EUA y los dos de Caracas) — wunderbar.

En este punto, permítanme subrayar la relevancia y necesidad de operar de forma óptima un ccTLD. En un mundo de direcciones IP, las empresas privadas, el Estado y los/as ciudadanos/as esperan poder comunicarse en Internet de una forma simplificada, usando marcas, identificadores y espacios de nombres coherentes. Hace diez años, nadie pensaba en establecer una imagen de espacios de nombres bajo el ccTLD de Venezuela. Con el pasar del tiempo los costos se hicieron razonable y NIC.ve se mantuvo siempre muy responsivo.

Calculo que NIC.ve debe estar hospedando hoy más de 150 mil dominios. Sin embargo, el hardware que están usando en sus dos NS de Caracas, está obsoleto. Más aun, ¿qué pasaría si se remueven las copias que están fuera de Venezuela? No es necesario que suponga una falla muy complicada; ns1.nic.ve y ns2.nic.ve están en el mismo sitio físico, en el mismo rango de direcciones, y en el mismo enrutador. Con 4 de 5 afuera, dependeríamos del NS (y la conectividad, seguridad física) de la ULA, no habría SRS y definitivamente el servicio se estaría viendo severamente afectado.

¿Afectado? ¿En qué le afecta a usted esto? Pongo un escenario, dirigido por ejemplo a Gobierno: imagine que toda la estrategia comunicacional del Estado en línea desaparece, incluyendo: Radio Nacional de Venezuela, YVKE Mundial, Agencia Bolivariana de Noticias… añada los sistemas del SENIAT, en fechas de declaración del ISLR. Ni hablar de CADIVI y el costo político, de la banca pública (BIV al menos) y sus sistemas al público, las alcaldías y gobernaciones con sus sistemas de consulta para la ciudadanía, Policía Nacional y sus sitios de denuncias…

Estos sistemas no funcionarían, no importa cuántas medidas de protección física y lógica, plantas eléctricas y demás medidas tomen las instituciones, y podría tomarse muchas horas y personal muy especializado y sobre todo muy comprometido (que, lamentablemente, no nos está sobrando) en paliar la situación y varios días en que cesaran los efectos colaterales. Millones de bolívares en pérdidas, muchas al bolsillo del ciudadano. Y una completa desconexión de la comunidad internacional en términos de ser los garantes y protectores de nuestro ccTLD.

Esta situación es innecesaria. ¿Cómo podemos ayudar? NIC.ve necesita nuevos equipos y una red de asociados individuales e institucionales para garantizar la sustentabilidad de la infraestructura de la red pública en nuestro país. Así mismo, necesita que abramos en conjunto los espacios para un consenso y mejoras en lo técnico (¡recuperemos el liderazgo en América Latina!) y en lo social (una idea: dominios .ve para la acción social)

Algunas preguntas: ¿por qué no hay un NS raíz para el ccTLD en CANTV? ¿en CONATEL, propiamente? ¿en ninguna de las universidades? ¿en PDVSA? ¿en CORPOELEC? ¿en los ISPs más grandes? No solamente se va a hacer más robusta la infraestructura, sino que, con la planificación adecuada, los ISPs y usuarios/as de cada una de estas instituciones se verán beneficiados/as directamentes. ¿Por qué no se ha aprovechado el aporte de las comunidades de desarrolladores para el SRS? ¿Se puede hacer? ¿Cómo nos preparamos para el agotamiento de las direcciones IP de IPv4? ¿Es sustentable nuestro soporte IPv6? ¿Cómo mejorarlo?

Canalicemos nuestras opiniones directamente al equipo de NIC.ve, por el correo electrónico nicve arroba conatel.gob.ve, pidamos que adquieran nuevos equipos y se distribuyan de forma resiliente en distintas redes públicas y privadas, propongamos organizar un Foro de NIC.ve en CONATEL, ayudemos a difundir los logros que el NIC tiene a nivel regional. A todos y todas nos interesa. Disfrutamos del servicio ahora y, si no hacemos nada, vamos a ser dolientes de lo inexistente mañana. ¡Ayudemos a NIC.ve!

Microblogging: #NICve

After my last post about timestamping according to RFC 3161, I’ve setup a Perl/OpenTSA-based Open Timestamping Authority which is open to the public -no warranties, read the disclaimer and also no provisions for handling non-trivial traffic- for tests.

Just visit tsa.g33k.com.ve and follow the instructions. I’d appreciate your feedback through either my blog, my Identi.ca/Twitter accounts (bureado) and/or tsa at g33k.com.ve