Pero ¿por que temen?

"Nunca positivo"
Esa garantía no es suficiente para la coalición que, en una carta al procurador general adjunto y titular de la División Antimonopolios del departamento de Justicia, Thomas Barnet, argumentó que el trato le daría a Google casi el 90% del mercado de búsquedas publicitarias y fortalecería su influencia sobre el acceso de los usuarios a la información en internet.
"Enfrentamos un posible futuro en el que no se podría tener acceso a ningún contenido sin el permiso de Google", indica la carta.
Según Flowers, los efectos de tales asociaciones entre empresas grandes nunca es positivo ya que "condensa la competencia, aumenta los precios y limita nuevas oportunidades en la internet".

Ante la mejor defensa que tengo es: ¿tiene idea de lo que está diciendo? El internet no le pertenece a nadie! ¿No tener acceso a contenidos sin permiso de google? Es totalmente ilógico e incoherente. Además, ni idea de cuáles precios habla que van a aumentar, Google no cobra por la mayoría de sus servicios, cobra por una minoría de ellos que presta a empresas. ¿Limita nuevas oportunidades? ¿Acaso se va a acabar el espacio en el que se pueda experimentar en el internet? ¡NO! ¡Porque es virtual!

A estos grupos de usuarios y derechos civiles preocupados por el monopolio sólo tengo por decirles una cosa: ¡Sólo son un montón de socialistas!

La semana pasada tuve la oportunidad de facilitar el Taller de Empaquetado y Distribución de Software bajo el Sistema APT, en las instalaciones de CENDITEL en Mérida. En la actividad participaron desarrolladores de los proyectos SAID y SAFET, así como desarrolladores de la DSLv2 de EDELCA y algunos futuros colaboradores de Debian.

Hace mucho tiempo había realizado mini-talleres sobre empaquetado (IVIC, EDELCA) en el marco de otras actividades, y algunas charlas por IRC en castellano. En esta ocasión, sin embargo, tuve la oportunidad de estructurar el contenido de forma de abordar de manera apropiada la problemática de distribución de software libre, explicar como el sistema APT se enfrenta a esta problemática y describir los detalles operativos del empaquetado y la distribución de software libre.

El taller se inició con una breve descripción del ecosistema de software libre y cuales son los niveles de responsabilidad de los actores en el desarrollo, para luego identificar los problemas en la distribución de software libre, como por ejemplo ubicación, configuración, facilidad de administración, mecanismos de actualización, entre otros.

Se presentaron algunos modelos que abordan estos problemas: los sistemas de paquetes mixtos (APT, RPM), los sistemas de paquetes fuentes (Portage) y los sistemas de paquetes binarios (Klik) incluyendo una breve pasada sobre sistemas distribuidos como Conary. Haciendo énfasis en el objetivo del taller, se definieron los paquetes binarios y fuentes de APT, y las interrelaciones entre los mismos.

En torno a algunas de las guías disponibles para distribuidores de software en APT (como la Guía del Nuevo Mantenedor de Debian) se inició la parte operativa del taller, trabajando en la creación de paquetes fuentes utilizando debhelper. También se abordó CDBS como un mecanismo de reutilización de instrucciones para la construcción de paquetes, y dpatch como sistema de gestión de parches al paquete fuente, utilizando la documentación de Ubuntu.

Una gran parte del taller se centró en los mecanismos centralizados de configuración de paquetes, en particular debconf, uno de los sistemas disponibles y compatibles con la Debian Policy. En este sentido trabajamos en la creación de plantillas, priorización, orden y necesidad de las preguntas, así como el uso de las respuestas y la localización de las plantillas.

Como una extensión al tema de debconf se trabajó brevemente con dbconfig-common, un conjunto de hooks adicionales a debconf que permiten que una aplicación (por ejemplo, la típica aplicación Web) cree y cargue una base de datos MySQL o PostgreSQL.

El taller tuvo como característica que la parte operativa se desarrolló alrededor de casos de uso tanto dentro de Debian (debianizar un paquete, modificar un paquete, recompilar un paquete) como fuera del Proyecto (distribuir entornos de Wine con aplicaciones Windows, hacer cambios locales en paquetes fuentes y reconstruir)

Finalmente, en el taller trabajamos en la modificación de paquetes binarios y fuentes (el primer caso tiene mucha utilidad en entornos organizacionales con implementaciones localizadas de Debian, Ubuntu, et. al.) y la interacción e integración del trabajo con el Proyecto Debian, desde adoptar un paquete haciendo uso de WNPP hasta manejar reportes de errores a través del BTS, incluyendo algunos mecanismos de control de calidad como Lintian, pbuilder y piuparts para garantizar la integridad del software que se distribuye.

Agradezco el interés de todos los participantes en este tema, en particular de CENDITEL como organizador, y espero que esto los motive a liberar el software que desarrollan utilizando sistemas de paquetes ampliamente difundidos y con muchas facilidades para distribuir su aplicación de forma efectiva, incluso en Debian :-)

Mañana 26 de Abril en las instalaciones de la Universidad José Gregorio Hernández se estará llevando a cabo el FLISOL.

Según se desprende del Wiki Oficial, El FLISOL (Festival Latinoamericano de Instalación de Software Libre) es el evento de difusión de Software Libre más grande en Latinoamérica. Se realiza desde el año 2005 y su principal objetivo es promover el uso del software libre, dando a conocer su filosofía, sus alcances, avances y desarrollo al público en general. Para tal fin, las diversas comunidades locales de software libre, organizan simultáneamente eventos en los cuales se instala de manera gratuita y totalmente legal, software libre en las computadoras que llevan los asistentes. Además, en forma paralela, se ofrecen charlas, ponencias y talleres, sobre temáticas locales, nacionales y latinoamericanas en torno al Software Libre, en toda su gama de expresiones: artística, académica, empresarial y social.

Para encontrar la información detallada del evento que se va a llevar a cabo en Maracaibo visiten:

http://flisol.net/FLISOL2008/Venezuela/Maracaibo

Debajo les dejo el afiche del evento.

Saludos cordiales,

El Grupo de Usuarios Linux de Mérida (GULMER), el Grupo de Usuarios de Software Libre de la Universidad de Los Andes (gUsLA), Activista por el Software Libre y el Grupo de usuarios Linux de Venezuela (VELUG), cumpliendo con su meta de promover y difundir el uso de Software Libre en nuestra región, se complace en invitarle a la tercera edición del Festival Latinoamericano de Instalación de Software Libre (FLISOL) en nuestra hermosa ciudad de Mérida, la cita es para el día sábado 26 de abril a partir de las 9:00 a.m. hasta las 5:00 p.m en las instalaciones de CORPONADES, la cual está ubicada en la Avenida Los Próceres, entrada al Parque La Isla. Edificio Sede. La entrada es totalmente libre y gratuita.

En el transcurso del día se tiene contemplado dar unas series de charlas introductorias y de demostraciones acerca de temas diversos, entre ellas cabe destacar:

• ¿Qué es el Software Libre?

• Demostración de entornos de escritorio en Debian GNU/Linux.

• Tecnologías Libres.

• Sistema administrativo integrado descentralizado – SAID.

• Demostración de Juegos en Software Libre.

• ULAnix Scientia una distribución para el estudiante de Ingeniería y Ciencias.

Además, toda persona interesada en instalar Software Libre en sus ordenadores, pueden llevarlo al evento, recordando respaldar la información relevante que mantenga y desfragmentar su disco duro, de esa manera contribuye en agilizar el proceso de instalación.

Ninguno de los Grupos de Usuarios de Software Libre mencionados previamente no se harán responsables por ninguna pérdida en sus datos, aunque esto no suele pasar, no se preocupe, animase en llevar tu maquina para instalarle Software Libre.

ACERCA DEL FLISOL

El FLISOL (Festival Latinoamericano de Instalación de Software Libre) es el evento de difusión de Software Libre más grande en Latinoamérica. Se realiza desde el año 2005 y su principal objetivo es promover el uso del software libre, dando a conocer al público en general su filosofía, alcances, avances y desarrollo.

Para tal fin, las diversas comunidades locales de software libre (en cada país, en cada ciudad/localidad), organizan simultáneamente eventos en los que se instala de manera gratuita y totalmente legal, software libre en las computadoras que llevan los asistentes.

Además, en forma paralela, se ofrecen charlas, ponencias y talleres, sobre temáticas locales, nacionales y latinoamericanas en torno al Software Libre, en toda su gama de expresiones: artística, académica, empresarial y social.

¿A quién está dirigido el evento?

El evento está dirigido a todo tipo de público: estudiantes, académicos, empresarios, trabajadores, funcionarios públicos, entusiastas y aun personas que no poseen mucho conocimiento informático.

Si posees o no conocimientos e intereses en informática, licencias, derecho de autor/copyright y demás áreas de la ciencia y la tecnología, déjate tentar, asiste y participa del evento. Nuestro objetivo es compartir conocimientos y ansias de libertad.

¿Cuánto cuesta el evento?

La asistencia al evento es totalmente libre y gratuita. Para mayor información acerca del Festival Latinoamericano de Instalación de Software Libre, le recomendamos revisar los siguientes enlaces:

http://www.installfest.info/

http://installfest.info/DescubreElSoftwareLibre

http://installfest.info/FLISOL2008/Venezuela/Merida

http://www.gulmer.org.ve/

http://www.ula.ve/gusla

http://activistasxsl.org.ve/

http://www.velug.org.ve/

P.D.: Se les agradece difundir este mensaje entre amigos, compañeros, entre otros.

Escrito con el Navegador Flock

Tags: Eventos, SoftwareLibre, FLISOL, Mérida, 2008

En un sistema de correo corporativo geográficamente distribuido, los buzones de correo se suelen servir desde el MDA más cercano al usuario. Como resultado, suelen haber dos o más servidores IMAP (o POP3) por región sirviendo correos a usuarios finales. Si el usuario se desplaza a otra región, debe configurar el cliente de correo electrónico de forma apropiada para revisar su buzón, o utilizar un cliente de correo Web (como IMP de Horde) que permita hacer login en todos los servidores.

Sin embargo, cuando se requiere que el usuario acceda a su buzón remotamente (sin considerar VPN en este momento) con un dispositivo lector de correos (como un Blackberry) se presentan dos problemas; el primero es presentar el servicio en la capa de aplicación (para evitar usar NAT, por ejemplo) y el segundo es el de dirigir la consulta al MDA que corresponda. Lo primero es fácil de resolver con cosas como imapproxy o Courier. Lo segundo es el tema en cuestión de este post.

nginx, un ligero servidor Web diseñado originalmente para ser un proxy HTTP, tiene la capacidad de servir como proxy IMAP (POP, SMTP también). nginx sabe IMAP y puede transformar una solicitud de inicio de sesión (0 login USER PASS) en una consulta HTTP para un servicio de autenticación:

GET ... HTTP/1.0 Host: localhost Auth-Method: plain Auth-User: USER Auth-Pass: PASS Auth-Protocol: imap Auth-Login-Attempt: 1 Client-IP: 127.0.0.1

Por lo tanto, es posible hacer un script (en cualquier lenguaje, FWIW) servido por HTTP que lea las cabeceras de esta petición y responda con información útil para continuar con la sesión IMAP utilizando una respuesta HTTP de este tipo (por supuesto, Auth-Status también puede ser Invalid):

HTTP/1.0 200 OK Auth-Status: OK Auth-Server: 10.10.10.10 Auth-Port: 143

La parte divertida es cuando se usa Perl para el asunto, porque nginx embebe Perl bajo la clase nginx y es posible escribir un mecanismo de autenticación directamente como una subclase de nginx. La clase tiene acceso a todas las cabeceras de la petición y puede inyectar cabeceras y contenido a la respuesta, por lo que podemos cambiar la cabecera Auth-Server, por ejemplo, dependiendo de la lógica de nuestro script. En el caso que nos ocupa, escribiríamos una cabecera correspondiente al MDA donde está el buzón del usuario consultando un campo en LDAP.

Algo muy básico podría ser esto:

package Auth; use nginx; use Net::LDAP; our $ip={}; $ip->{'serverA'} = "10.10.10.10"; $ip->{'serverB'} = "10.20.10.10"; sub handler { my $r = shift; my $ldap = Net::LDAP->new( 'ldap-server' ); my $mesg = $ldap->bind; $mesg = $ldap->search ( base => 'dc=tu,dc=base', filter => '(&(uid=' . $r->header_in("Auth-User") . '))' ); my $goto = $mesg->entry(0)->get_value('atributoLDAPconDireccion'); $r->header_out( "Auth-Status", "OK" ) ; $r->header_out( "Auth-Server", $mail_server_ip->{$goto} ); $r->header_out( "Auth-Port", "143"); $r->send_http_header("text/html"); return OK; } 1;

nginx también debe ser configurado apropiadamente para utilizar la clase de autenticación y activar el proxy IMAP. El servidor web debe ser configurado con las opciones –with-mail y –with-http_perl_module. Aun estoy buscando la mejor forma de hacer distribuible esta configuración en el paquete que mantengo para Debian y Ubuntu (ya que nginx es muy pwd centered)

Con un servidor nginx correctamente compilado, y con la clase de autenticación lista, basta agregar en /etc/nginx/nginx.conf algo como:

http { ... perl_modules /etc/nginx/perl/lib; perl_require Auth.pm; server { location /auth { perl Auth::handler; } } } mail { auth_http 127.0.0.1:80/auth; imap_capabilities "IMAP4rev1" "UIDPLUS"; server { listen 143; protocol imap; proxy on; } }

Es increíble, en nuestra universidad para poder entrar a algo de la red nos hacen usar nuestros usuarios y contraseñas para poder usar el proxy y además enviárselas en texto plano las contraseñas que usamos para inscribirnos y manejar nuestros procesos académicos.

Resulta que además tienen una cuenta para entrar a la red inalámbrica (supongo que para la red cableada funcionará también, aún no lo he probado) que es tan simple como user: eventos password: eventos, ya lo tienen desde hace días y puedo acceder desde cualquier AP de la universidad.

Vaya, esos administradores de red de la Universidad del Táchira ¡sí que son buenos!

¿Lo peor? Las cuentas de los estudiantes están limitadas por horarios, la de eventos no. Al menos tendré internet a toda hora :)

¡Y para no perder la costumbre!

Ya hay nuevos paquetes de XScreenSaver disponibles en mi repo, es la misma versión sólo con un parche aplicado para los sistemas con doble pantalla y para que ahora venga compilado con proc-interrupts.

Technorati Tags: xscreensaver debian

Bueno, ya saben que ayer migré mi blog de PostgreSQL a MySQL y a falta de una herramienta buena que me hiciera el trabajo me tocó hacerlo de manera manual sacando tablas específicas como CSV y luego importándolas al MySQL, básicamente consistio en ir al psql y hacer por cada tabla algo como:

~$ psql -U usuario -W drupalbd
\o node_revisions.txt
COPY node_revision TO STDOUT WITH DELIMITER '|';
\o

Eso me dejaba un archivo ./node_revisions.txt con el contenido separado por barras. Luego voy al mysql y hago:

~$ mysql -u usuario -p drupalbd
SET character_set_database=utf8;
LOAD DATA LOCAL INFILE 'node_revisions.txt'
INTO TABLE node_revisions
FIELDS TERMINATED BY '|'
LINES TERMINATED BY '\n'
(campos, según, el, orden);
SET character_set_database=default;

Hay veces que ya no existe una columna en la nueva BD por ser una nueva versión y haber cambiado algunas cosas entonces al pasar el LOAD DATA va a mostrar un error. Leyendo un poco y preguntando conseguí que puedo enviar esa columna a una variable colocándole una @ antes, algo así como @basura entonces no pasa los datos de esa columna a la nueva tabla.

Y hacer eso por cada tabla que sea significativa :D Para mi lo fueron: node, node_revisions, term_*, comments

Hoy por cosas que suceden en la vida actualicé a Drupal6, me tiré la BD y preferí hacer una desde cero, esta vez MySQL, últimamente Drupal con PostgreSQL me había estado dando muchos problemas.

En fin, ya está arriba de nuevo, me faltan aún algunos detallitos pero el lunes los corregiré, mañana tengo competencia de natación :)

Entre las cosas que me faltan es que cada nodo esté agregado a la categoría que pertenece, no he conseguido aún cuál es la tabla que hace exactamente eso, quizás sea un poco más de leer y más nada...

La excusa de Flickr para limitar los vídeos a 90 segundos es para evitar que los usuarios suban material con copyright que no sea de su propiedad, pero, los únicos que pueden subir vídeos son los usuarios pro. Tomando en cuenta que para ser pro tuviste que pagar una cuenta con tú tarjeta de crédito quiere decir que conocen tus datos personales y tienen a quien acusar en caso de problemas legales así que no debería ser un problema para Flickr sino para el usuario.

¿Es suficiente esta excusa? No lo creo, problemas legales no tendrían...

No es que sea el mejor, pero me siento orgulloso de lo que hice :) Más que tengo que entregarlo mañana en la universidad! Jajaja

Se supone que es hecho de manera recursiva aunque aún tengo mis dudas al respecto. En fin, quienes lo quieran ver y criticarme está aquí, es un código en C++.

El programa no falla con 7 o menos caracteres, a partir de 8 caracteres da un fallo de segmento que no logro identificar aún pero espero próximamente arreglar.

Feel free to kill me with your comments!

Flickr siempre ha sido la alternativa para publicar fotos con gran calidad, en su mayoría para profesionales y personas que ven la fotografía como un hobby.

Hoy le agregaron el esperado Flickr Vídeo, del cuál personalmente esperaba más. Según aseguran los de TechCrunch tiene una capacidad máxima el vídeo de 90 segundos y 150MB. Esto, obviamente, hace que no sea una alternativa para profesionales y amateurs del vídeo que quieran publicar sus vídeos en la red, además de que sólo los PRO lo pueden hacer. Debido a esto, incluso DailyMotion se ve como una mejor alternativa en vídeo que Flickr.

Quizás esa limitante la colocaron para evitar que montaran series y contenido con copyright, sin embargo, sucedería lo mismo con imágenes grandes de gran calidad, pero los que compran la cuenta pro lo hacen para colocar sus propias fotografías con gran calidad y capacidad de almacenamiento.

De verdad, Flickr, me decepcionas, esperaba mucho más de Flickr vídeo.

IPMI es un protocolo para el control de dispositivos inteligentes dentro de equipos informáticos especializados. El alcance del protocolo es bastante amplio, pero en la práctica le permite a una organización implementar lights-out management utilizando medios secundarios de acceso a un equipo cuando todo lo demás falla. En tal sentido es argumentable que esta tecnología redunda en reducción de costos, en particular cuando se deben administrar centros de datos geográficamente distribuidos.

En servidores IBM, como el System x3200, existe un dispositivo inteligente llamado BMC (Baseboard Management Controller) que funciona como el punto neurálgico de IPMI. Como ya es común, existen drivers en Linux para tener acceso a las funciones del mismo. Otros vendedores incorporan tecnologías similares (iLO de HP, DRAC de Dell, Xserver de Apple y ALOM de Sun) con mayor o menor soporte para la especificación IPMI, pero en algunos casos completamente fuera de control.

Módulos y paquetes

Muchas distribuciones traen núcleos con soporte IPMI (mi plataforma de trabajo, Debian, los trae) pero en algunos casos será necesario compilar el soporte dentro del núcleo. A tales efectos considero apropiado leer la documentación de IPMI en el kernel. Algo como find /lib/modules -type f -name ‘ipmi*’ puede ayudar a saber si es necesario o no.

También se necesitan los paquetes openipmi y ipmitool, disponibles en Debian, Ubuntu y muchas otras distribuciones. Luego de instalar esto, se deben cargar los módulos necesarios para el soporte IPMI: ipmi_watchdog, ipmi_devintf, ipmi_si, ipmi_poweroff y el más importante, ipmi_msghandler.

Una vez que se carguen estos módulos el núcleo debería reportar la disponibilidad de hardware con capacidad para IPMI, con mensajes como:

ipmi: Found new BMC (man_id: 0x000002, prod_id: 0x0026, dev_id: 0x20) IPMI poweroff: Found a chassis style poweroff function

Luego, mediante ipmitool se pueden empezar a consultar los valores monitorizados por el BMC (open sel list y sensor también son comandos muy útiles):

dewey:~# ipmitool -I open chassis status System Power : on Power Overload : false Power Interlock : inactive Main Power Fault : false Power Control Fault : false Power Restore Policy : unknown Last Power Event : command Chassis Intrusion : inactive Front-Panel Lockout : inactive Drive Fault : false Cooling/Fan Fault : false Front Panel Control : none

IPMI sobre LAN

Lo siguiente que podemos querer es tener acceso a IPMI sobre la tarjeta Ethernet (una Broadcom NetXtreme) para hacer verdaderamente LOM. Lo primero que hay que identificar es el canal de la tarjeta de red.

En mi servidor, el canal de la LAN es el número 1, pero en otros productos de IBM y en otros proveedores probablemente eso cambie. La mejor forma de averiguarlo es iterar sobre el comando ipmitool -I open lan print $i hasta que se arrojen valores sobre la tarjeta de red (los System X de IBM vienen con direcciones en el rango 10/8)

Una vez identificado el canal, es posible utilizar el script bmclanconf (en Debian está en /usr/share/ipmitool, pero la ubicación definitivamente puede cambiar entre distribuciones) invocándolo de la siguiente manera (es importante colocarle el password, BTW): bash /usr/share/ipmitool/bmclanconf -c CHAN -p PASS -i IFACE -v IP -w MASK

Probando

Con estos elementos puestos en su lugar es posible hacer algunas pruebas interesantes. Desde un equipo remoto con ipmitool puede ejecutar un comando como IPMI_PASSWORD=PASS ipmitool -I lan -H IP -E COMANDO, donde COMANDO puede ser por ejemplo sensor.

Para algo más interesante, apague el equipo por el procedimiento que mejor le parezca y una vez que el equipo esté apagado, repita el comando. Mejor aún, con el equipo apagado pruebe a ejecutar remotamente este comando:

bureado@dirac:~$ IPMI_PASSWORD=PASS ipmitool -I lan -H IP -E chassis power on Chassis Power Control: Up/On

Posibilidades

Resulta muy útil configurar IPMI para trabajar con el demonio watchdog de Linux. Básicamente hay que cargar el módulo ipmi_watchdog, asegurarse de que /dev/watchdog haya sido creado (quizás sea necesario crearlo con mknod, o agregar un alias char-major-10-130 ipmi_watchdog en /etc/modprobe.d/aliases) e instalar el paquete watchdog.

En /etc/watchdog.conf hay que descomentar la línea watchdog-device, configurar funcionalidades adicionales (si las necesita) e iniciar el servicio watchdog. De forma predeterminada, cuando watchdog detecte que la tabla de procesos está llena, que no queda memoria libre o que la carga de trabajo en la máquina sea demasiado alta, enviará un comando IPMI para reiniciar la máquina de forma limpia.

Dependiendo de las capacidades del hardware, puede configurar Serial Over LAN, para poder tener acceso sobre LAN a las capacidades visuales del servidor (desde el arranque hasta el trabajo en la línea de comandos, como una consola serial tradicional) y en este sentido puedo apuntar al documento IPMI HOWTO en Debian, ya que el x3200 no tiene esta capacidad: hay que usar las herramientas propietarias que IBM pone a disposición en la página de especificaciones del servidor.

Happy IPMI’ng.

Today we had the opportunity to be part of a very important event: Venezuela’s final meeting on DIS 29500 fast-tracking. Even though we’re working on this matter since 2007, and we weren’t approved official participation as a community, we managed to be there today. There was a strong discussion; and we had our chance to participate. I believe we were welcomed by the NB and hopefully we, as a community, can be part of future discussions in a very constructive way. Thanks again to all the committee members and our NB who made it possible for us to participate today.

From: "FONDONORMA" <...@fondonorma.org.ve> To: <brannon@...>, <takahashi@...>, <gaillen@...>, <...@fondonorma.org.ve> Subject: Modification to the vote on DIS 29500 - Venezuela (FONDONORMA) Date: Fri, 28 Mar 2008 14:04:26 -0430 (snip) Venezuela wishes to modify its position on DIS 29500 (snip) (snip) from Approval with comments to Disapproval with comments.

Finalmente hoy he podido colocar en línea mi blog. Cosas que han pasado:

1) Pude trancisionar de G77 a Gfortran 3 de los paquetes que mantengo: blacs-pvm, blacs-mpi y scalapack gracias a la ayuda de Kumar y Colin.

2) Estoy en la cola para el proceso de NM, la mala nueva de esto es que no me han asignado un AM pero se que el proceso es poco a poco.

3) He empaquetado MakeHuman, pero hay ciertos problemas con algunas licencias. Ya he contactado a los upstream para hacer los cambios pertinentes, es cuestión ahora de solo esperar un nuevo release por parte de ellos para poder subirlo a Debian.

Todavía tengo cosas por hacer:

1) Subir una nueva revisión de aMSN para corregir unos lintian warnings.

2) Terminar de subir de una vez por todas Make Human y los otros programas que tengo pendientes.

Estos días de “descanso”[1] me dediqué a finiquitar algunas cosas que tengo pendientes en mi vida, el balance me indica que aproveché muy el tiempo.

Así, una de los items me indica el tema del OCR

El OCR es un tema bastante complejo y que ha consumido muchos años de trabajo a una gran cantidad de estudiosos. Cierto que hacer OCR sobre un texto perfectamente prístino es relativamente fácil, pero se empieza a complejizar cuando:

a) El documento sobre el cual se aplica la digitalización no está en excelente estado: por ejemplo, documentos de registros civiles; cierto que acá no es problema del OCR directamente ya que la labor del OCR es reconocer el texto escrito, pero si indirecto ya que el CR debe ser capaz de detectar con tasas “aceptables” de error, el ruido presente en el documento.

b) Caracteres mos acentuados: buena parte del software  OCR existente en el mundo del SL no permite trabajar con caracteres acentuados en virtud de haber sido desarrollado en países donde el tema de los acentos no existe, por lo cual falan estrepitosamente cuando se aplican en textos de nuestro idioma, por ejemplo.

c) El santo grial: documentos manuscritos, los cuales en su mayoría deben ser transcritos ya que hasta la fecha el grado de exactitud de los OCR en este tema es bastante  precario.

Más allá, es menester también que hagamos mención a los escritos en los cuales se utilizan ideogramas los cuales, hasta el momento sólo han dado resultados aceptables en condiciones más que óptimas en diferentes estudios realizados por estudiosos de la materia [2] [3] [4]

Después de realizar una búsqueda exhaustiva encontramos el software tesseract [5], proyecto desarrollado por  Ray Smith y que ha demostrado sernos de ayuda invaluable para la labor que lo requeríamos.

Su funcionamiento es trivial y está empaquetado para Debian [6] aunque preferimos compilarlo nosotros mismos y crearnos nuestro propio paquete debian [7]

En una próxima entrega hablaremos del proceso de construcción y uso.

[1] Defino descanso como el intervalo de tiempo en el cual no estoy en la oficina _haciendo_el_trabajo_de_oficina_ ya que en la oficina muy bien se puede estar conversando, o probando, adaptando, modificando software que no tiene nada que ver con el trabajo.-

[2]  http://www.springerlink.com/content/30k4j26legkfw09w/

[3]  http://ieeexplore.ieee.org/Xplore/login.jsp?url=/iel5/8926/28251/01263261.pdf?temp=x

[4]  http://ecet.ecs.ru.acad.bg/cst06/Docs/cp/sV/V.4.pdf

[5]  http://code.google.com/p/tesseract-ocr/

[6]  http://packages.debian.org/etch/tesseract-ocr

[7] En la labor de pruebas de calidad del paquete nos ayudó bureado quien me indicó algunos tips para que estuviese acorde con las políticas de empaquetado de Debian.

Para no perder la costumbre!!

Hay nuevo paquete de xscreensaver! Ya va por la versión 5.05 y trae nuevos hacks: lcdscrub, cubicgrid e hypnowheel (pueden conseguirlos en los paquetes extra de los hacks gl a los 2 últimos y en data-extra a lcdscrub).

Pueden descargarse los debs para i386 o descargarse las fuentes para construir el paquete :)
http://debian.ghostbar.ath.cx/xscreensaver/5.05-1/

Enjoy!

Ya hay una nueva versión de xscreensaver además de la que había acabado de subir a Debian...

Trabajaré esta noche en esta versión a ver si para el fin de semana les doy diversión a unos cuantos geeks mientras yo me echo una pea de esas geniales :D

Serie de documentos ¿Cómo hacer?

Aplicaciones Web seguras con Apache, OpenSSL, GPG y PHP

T.S.U. Leonardo Caballero

Grupo de Usuarios Linux de Mérida - GULMER
Web Site: http://www.gulmer.org.ve/
Linux User # 369081 / IRC Nick: macagua
E-mail: leonardocaballero@gmail.com
Web Site: http://lcaballero.8k.com/

Palabras clave

HowTo, Servidor Web Seguro, Apache, OpenSSL, PKI, Certificado Digital, PGP, GPG, Triatlon de Software Libre, Mérida.

Resumen

El presente HowTo describe los servicios y aplicaciones necesarias para mi “proyecto de software libre” que defendí en el “I Triatlon Regional de Software Libre Mérida” para lograr esto estuve 4 horas investigando en Internet y conseguí varios manuales, pero estaban desactualizados con respecto a mi distribución Debian GNU/Linux, o simplemente daban por entendido muchas cosas que yo no sabía, por lo que para resolver mi problema tuve que utilizar como mínimo 3 manuales que son diferentes en cuanto su distribución, versión de paquetes, entre otras, logre adaptarlo a mi solución. Esta dificultad en la documentación me da base para realizar este HowTo bajo las características de requerimientos que se citan el en mismo apartados.

El mismo aborda los siguientes temas: Introducción al tema, definiciones a cerca de HTTPS, RSA, Triple DES, X.509, OpenSSL, Mod_ssl, PGP, PGP y GPG. Luego se citan los requerimientos de software para que todo funcione. Seguidamente se explican los procedimientos de instalación y configuración de los servicios del proyecto. Además el desarrollo de la aplicación demostrativa con códigos fuentes se ofrecen recursos en la red.

Introducción

Este HowTo es sobre ¿Cómo hacer aplicaciones Web seguras con conexiones cifradas con SSL?. Así, quien quiera empezar a montarse en casa un pequeño “laboratorio de pruebas” ya tiene por donde empezar; el mismo describe los servicios y aplicaciones necesarias para mi “proyecto de software libre el cual defendí en el “I Triatlon Regional de Software Libre Mérida”; para lograr esto estuve 4 horas investigando en Internet y conseguí varios manuales pero estaban desactualizados con respecto a mi distribución Debian GNU/Linux, o simplemente daban por entendido muchas cosas que yo no sabía, por lo que para resolver mi problema tuve que utilizar como mínimo 3 manuales que son diferentes en cuanto su distribución, versión de paquetes, entre otras, logre adaptarlo a mi solución. A continuación les dejo algunas definiciones básicas que debe manejar para poder realizar el proceso con éxito

HTTPS.

Es la versión segura del protocolo HTTP, inventada en 1996 por Netscape Communications Corporation. No es un protocolo separado de HTTP. Se trata de una combinación de este último con un mecanismo de transporte SSL o TLS, garantizando una protección razonable durante la comunicación cliente-servidor. Es ampliamente utilizado en la red mundial (WWW o World Wide Web) para comunicaciones, como transacciones bancarias y pago de bienes y servicios.

El servicio utiliza el puerto 443 por TCP para realizar las comunicaciones (la comunicación normal para HTTP utiliza el 80 por TCP). El esquema URI (Uniform Resource Identifier o Identificador Uniforme de Recursos) es, comparando sintaxis, idéntico al de HTTP (http:), utilizándose como «https:» seguido del subconjunto denominado URL (Uniform Resource Locator o Localizador Uniforme de Recursos). Ejemplo: https://www.dominio.org/. [CEM-bot 2007].

RSA.

Es un algoritmo para el ciframiento de claves públicas el cual fue publicado en 1977, patentado en EE.UU. en 1983 por el el Instituto Tecnológico de Michigan (MIT). RSA es utilizado ampliamente en todo el mundo para los protocolos destinados al comercio electrónico. Sus siglas son acrónimo de los apellidos de sus autores, Ron Rivest, Adi Shamir y Len Adleman. [LordT 2007].

Triple DES.

También conocido como TDES, es un algoritmo que realiza un triple cifrado DES, desarrollado por IBM en 1978. Su origen tuvo como finalidad el agrandar la longitud de una clave sin necesidad de cambiar el algoritmo de ciframiento, lo cual lo hace más seguro que el algoritmo DES, obligando a un atacante el tener que triplicar el número de operaciones para poder hacer daño. A pesar de que actualmente está siendo reemplazado por el algoritmo AES (Advanced Encryption Standard, también conocido como Rijndael), sigue siendo estándar para las tarjetas de crédito y operaciones de comercio electrónico. [TXiKiBoT 2007].

X.509.

Es un estándar ITU-T (Estandarización de Telecomunicaciones de la International Telecommunication Union) para infraestructura de claves públicas (PKI, o Public Key Infrastructure). Entre otras cosas, establece los estándares para certificados de claves públicas y un algoritmo para validación de ruta de certificación. Este último se encarga de verificar que la ruta de un certificado sea válida bajo una infraestructura de clave pública determinada. Es decir, desde el certificado inicial, pasando por certificados intermedios, hasta el certificado de confianza emitido por una Autoridad Certificadora (CA, o Certification Authority). [Ignacioerrico 2007].

OpenSSL.

Es una implementación libre y código abierto, de los protocolos SSL (Secure Sockets Layer o Nivel de Zócalo Seguro) y TLS (Transport Layer Security, o Seguridad para Nivel de Transporte). Está basado sobre el extinto proyecto SSLeay, iniciado por Eric Young y Tim Hudson, hasta que éstos comenzaron a trabajar para la división de seguridad de EMC Corporation. [OpenSSL 2007].

Servidor HTTP Apache.

Es un software (libre) servidor HTTP de código abierto para plataformas Unix (BSD, GNU/Linux, etc.), Windows, Macintosh y otras, que implementa el protocolo HTTP/1.1 y la noción de sitio virtual. [VolkovBot 2007].

Mod_ssl.

Es un módulo para el servidor HTTP Apache, el cual provee soporte para SSL versiones 2 y 3 y TLS versión 1. Es una contribución de Ralf S. Engeschall, derivado del trabajo de Ben Laurie.

PGP.

Es un programa desarrollado por Phil Zimmermann y cuya finalidad es proteger la información distribuida a través de Internet, mediante el uso de criptografía de clave pública, así como facilitar la autenticación de documentos gracias a firmas digitales. Sus siglas significa Pretty Good Privacy (privacidad bastante buena). [Nolaiz 2007].

GPG.

GPG o Gnu Privacy Guard es una herramienta para cifrado y firmas digitales, que viene a ser un reemplazo del PGP (Pretty Good Privacy), pero con la principal diferencia que es software libre licenciado bajo la GPL y se puede ejecutar en Linux y en MS Windows. [RobotQuistnix 2007].

PHP

Es un lenguaje de programación usado normalmente para la creación de páginas web dinámicas. PHP es un acrónimo recursivo, que significa “PHP Hypertext Pre-processor” (inicialmente PHP Tools, o, Personal Home Page Tools), y se trata de un lenguaje interpretado. Últimamente también puede ser utilizado para la creación de otro tipo de programas incluyendo aplicaciones con interfaz gráfica, usando las bibliotecas Qt o GTK+. [Jarisleif 2007].

HTML

Es el acrónimo inglés de HyperText Markup Language, que se traduce al español como Lenguaje de Etiquetas de Hipertexto. Es un lenguaje de marcado diseñado para estructurar textos y presentarlos en forma de hipertexto, que es el formato estándar de las páginas web. Gracias a Internet y a los navegadores como Internet Explorer, Opera, Firefox, Netscape o Safari, el HTML se ha convertido en uno de los formatos más populares y fáciles de aprender que existen para la elaboración de documentos para la web. [CienciaAlPoder 2007].

Hojas de estilo en cascada

Las hojas de estilo en cascada (Cascading Style Sheets, CSS) son un lenguaje formal usado para definir la presentación de un documento estructurado escrito en HTML o XML (y por extensión en XHTML). [CienciaAlPoder 2007].

Cliente de correo electrónico.

Un cliente de correo electrónico, o también llamado en inglés mailer o Mail User Agent (MUA), es un programa de ordenador usado para leer y enviar e-mails. Originalmente, los clientes de correo electrónico fueron pensados para ser programas simples para leer los mensajes del correo de usuario, enviados por el agente de reparto de correo (MDA) conjuntamente con el agente de transferencia de correo (MTA), a un buzón local. [AlleborgoBot 2007].

Novell Evolution.

Evolution o Novell Evolution es un gestor libre de información personal y de trabajo en grupo para GNOME, desarrollado originalmente por Ximian ahora es parte oficial del escritorio de GNOME. Combina administración de correo electrónico, calendario, agenda y lista de tareas. Forma parte del conjunto GNOME Office. Su interfaz gráfica y funcionalidad imita bastante a la aplicación Microsoft Outlook. Evolution puede opcionalmente conectarse a servidores Microsoft Exchange, usando su interfaz web y un añadido conocido como Connector. [Estirabot 2007].

Requerimientos

No creo que hoy en día sea difícil instalar ambas cosas en cualquier distribución o plataforma estos son los únicos requisitos previos. Tampoco pienso que sea muy diferente en Windows. Los pasos que se detallan a continuación han sido realizados en los siguientes paquetes para GNU/Linux:

• Sistema Operativo Debian GNU/Linux 4.0

• Servidor HTTP Apache 2 v2.2.3-4

• OpenSSL v0.9.8c-4.

• GPGV v1.4.6-2

• PHP5 v5.2.0-8+etch3

Es necesario disponer de una dirección IP pública (aunque para esta demostración no es necesario funciona con una IP privada) para cada sitio de red virtual que se quiera configurar con soporte SSL/TLS. Debido a la naturaleza de los protocolos SSL y TLS, no es posible utilizar múltiples sitios de red virtuales con soporte SSL/TLS utilizando una misma dirección IP. Cada certificado utilizado requerirá una dirección IP independiente en el sitio de red virtual.

El paquete mod_ssl (modulo de SSL para Apache 2) instala el fichero /etc/apache2/mods-enabled/ssl.conf, mismo que no es necesario modificar, puesto que se utilizarán ficheros de inclusión, con extensión *.conf, dentro del directorio /etc/apache2/mods-enabled/, a fin de respetar la configuración predeterminada y poder contar con la misma, que es funcional, brindando un punto de retorno en el caso de que algo saliera mal.

Instalación y configuración de los Servidor HTTP Apache, OpenSSL, GPGV y PHP.

Aunque supongo es igual que con distribuciones basadas en Debian, como siempre.

• Instalar Apache2: Se debe instalar en su sistema de pruebas el paquete Apache2, por comodidad se usará las herramientas de gestión de paquetes de Debian como Aptitude y lo puede realizar con el siguiente comando:

# aptitude install apache2

• Habilitar el módulo ssl: Luego de instalar el servidor Apache 2 se debe habilitar el modulo de SSL y lo puede realizar con el siguiente comando:

# a2enmod ssl

• Instalar OpenSSL: Se debe instalar en su sistema de pruebas el paquete OpenSSL, por comodidad se usará las herramientas de gestión de paquetes de Debian como Aptitude y lo puede realizar con el siguiente comando:

# aptitude install openssl

• Generar clave privada RSA: Se llamara al servidor por ej. triatlon (sustituye “triatlon” por el nombre-url suyo). Para generar una clave privada RSA protegida por contraseña lo puede realizar con el siguiente comando:

$ openssl genrsa -des3 > triatlon.key

La protección de la clave por contraseña (para lo que puede utilizar también AES) presenta el inconveniente de que tendrás que teclear esta contraseña cada vez que arranques el servidor y que si la olvida se acabó.

Por eso, si prefieres la comodidad a la máxima seguridad (por ejemplo, se trata de su servidor de pruebas) y está “seguro” de que la clave no va a caer en malas manos (o no importa), puedes optar por no proteger con contraseña y lo puede realizar con el siguiente comando:

$ openssl genrsa > triatlon.key

• Generar CSR (Certificate Signing Request): Ahora se generó una petición para enviar a una Autoridad de Certificación, solicitar que firme nuestra clave y nos devuelva un certificado; este paso lo puede realizar con el siguiente comando:

$ openssl req -new -key triatlon.key > triatlon.csr

Responde a las preguntas sobre país, provincia. ciudad, empresa, nombre y e-mail.

El fichero generado podrías enviarlo a una autoridad de certificación (como Verisign, de pago, o CACert, gratuita aunque no del agrado de Microsoft) para que lo firmaran y te enviaran su certificado, pero haremos algo aún mejor: ¡crearemos nuestra propia autoridad de certificación!.

• Crear nuestra propia Autoridad de Certificación (CA):

Precaución: (el path a CA.pl puede ser distinto en su distribución) para localizarlo ejecute el siguiente comando:

$ locate CA.pl

Para generar la CA ejecute el siguiente comando:

$ /usr/lib/ssl/misc/CA.pl -newca

Presiona Enter y proporciona la que será contraseña de acceso a la clave privada de esta nueva autoridad. Proporciona país, provincia, ciudad, etc. para esta autoridad.

Enhorabuena. Ya eres el feliz propietario de una flamante “Autoridad de Certificación”, contenida en el nuevo directorio demoCA. El fichero cacert.pem contiene su clave pública, mientras que en el directorio private/cakey.pem dispones de la clave privada que te permitirá crear certificados para sus “clientes”.

• Crear certificados: Como ejemplo, empecemos por firmar el CSR que genero en el paso llamado “Generar CSR (Certificate Signing Request)” y lo puede realizar con el siguiente comando:

$ openssl ca -policy policy_anything -out triatlon.crt -infiles triatlon.csr

Introduce la contraseña de su autoridad cuando se te pida. Pulsa ‘Y’ cuando se te pregunte si deseas firmar ‘Y’, también para ejecutar (commit) el cambio en su base de datos.

Vamos a generar también un certificado autofirmado para su propia autoridad certificadora (en el apartado 6 verás para qué). Acceda al directorio de su autoridad (demoCA) y escriba el siguiente comando:

$ openssl x509 -req -days 365 -in careq.pem -out cacert.crt -signkey ./private/cakey.pem

• Añadir certificado al servidor web: Es necesario añadir al servidor Apache los certificados generados por la CA y lo puede realizar con los siguientes comandos:

# cp triatlon.key /etc/apache2/

# cp triatlon.crt /etc/apache2/

Editar /etc/apache2/mods-enabled/ssl.conf para añadir el nombre, email del administrador y puerto de nuestro servidor y editar las líneas de clave y certificado para que digan así:

SSLCertificateFile /etc/apache2/triatlon.crt

SSLCertificateKeyFile /etc/apache2/triatlon.key

• Copiar la configuración de sitios habilitados: No es necesario hacer un respaldo de el archivo en el directorio “sites-enabled” pero siempre es recomendado por si algo falla puede comparar con la configuración original. También nota que existe un enlace simbólico desde /etc/apache2/sites-enabled/000-default hasta /etc/apache2/sites-available/default. Intenta, respaldarlo en el directorio sites-available el archivo o en otra locación y los puede realizar con los siguientes comandos:

# cd /etc/apache2/sites-available

# cp /etc/apache2/sites-available/default default_original

• Establecer un enlace simbólico necesario: El primer comando copia el archivo de la configuración por defecto para el puerto 80, para usar esta copia del archivo de configuración para el puerto 443. El segundo comando establece un enlace simbólico desde el fichero ’ssl’ en el directorio ’sites-available’ al fichero ’ssl’ en el directorio ’sites-enabled’. Esta metodología de enlazar con “enlaces simbólicos” entre dos directorios (como el mods-available y mods-enabled), es un explicado en fichero /etc/apache2/README. La idea general es que habilitemos ficheros de salida como enlaces simbólicos creados sus partes disponibles y lo puede realizar con los siguientes comandos:

# cp /etc/apache2/sites-available/default /etc/apache2/sites-available/ssl

# ln -s /etc/apache2/sites-available/ssl /etc/apache2/sites-enabled/ssl

• Definiendo el “document roots”: Es la localización por defecto para las paginas HTML con la instalación inicial de Debian /var/www y allí existen en sitios no separados los archivos SSL. Yo prefiero separar para servir para paginas HTML básicas /var/www/html y páginas SSL en /var/www-ssl/htm. Como usted quiera trabajarlo no importa, pero para este paso creo los directorios y lo puede realizar con los siguientes comandos:

# cd /var/www
# mkdir html
# cd /var
# mkdir www-ssl
# cd www-ssl
# mkdir html

• Configurar los “virtual hosts”: Aquí usted necesita definir en el archivo de configuración del Apache la IP de su servidor, nombre DNS (si existe) y el “document roots” (directorio raíz) que se creo en el anterior paso. Para configurar el puerto 80 del HTTP, ejecute el siguiente comando:

# vim /etc/apache2/sites-available/default

Nota: Observe lo siguiente que debes cambiar o agregar en la configuración de los “Virtual Host”.

NameVirtualHost *:80

<VirtualHost *:80>
ServerName localhost
DocumentRoot /var/www/html

Nota: Use su IP asignada o el nombre DNS seguido con “:80″. Si usted tiene una para el Nombre del Servidor.

El procedimiento es similar para HTTPS en el puerto 443, edite el /etc/apache2/sites-available/ssl con el siguiente comando:

# vim /etc/apache2/sites-available/ssl

Nota: Observe lo siguiente que debes cambiar o agregar en la configuración de los “Virtual Host”.

NameVirtualHost *:443
<VirtualHost *:443>
ServerName localhost
DocumentRoot /var/www-ssl/html

Nota: Use su IP asignada o el nombre DNS seguido con “:443″ .Si usted tiene una para el Nombre del Servidor.

• Indicar al Apache para escuchar al puerto 443: Usted debe editar el archivo /etc/apache2/ports.conf con el siguiente comando:

# vim /etc/apache2/ports.conf

y añadir la siguiente linea:

Listen 443

• Modificar el fichero /etc/hosts (si es necesario): Cuando arranque y detenga el servidor Apache, allí tal ves exista una advertencia como “Could not determine the server’s fully qualified domain name, using 127.0.1.1 for ServerName”. Debe tomar en cuenta esto si no tiene un nombre DNS para su servidor y esta usando una IP dinámico. Si este es su caso diríjase dentro del archivo /etc/hosts y realice los cambios siguientes: Básicamente usted debe agregar “localhost.localdomain” a la IP de 127.0.0.1 y cualquier nombre de su sistema que seleccionó cuando instaló su distribución (que asume usted no lo ha cambiado). La línea final abajo debe estar allí si tienes un IP estático y el correspondiente nombre del DNS registrado para esto. Si éste es el caso, en el paso anterior llamado “Configurar los virtual hosts” donde se colocó el ServerName, allí debe tener un valor que corresponda con el nombre del DNS, también indicado aquí y lo puede realizar con el siguiente comando:

# vim /etc/hosts

127.0.0.1 localhost localhost.localdomain {su nombre de su pc}
127.0.1.1 {su nombre de su pc}
{IP estática, si usted tienes uno} {Completo nombre del host DNS, si usted tiene uno}

• Instalar GPGV: Se necesita instalar el verificador de firmas GPG que permitirá a la aplicación a desarrollar que pueda firmar y enviar los datos, usted lo puede realizar con el siguiente comando:

# aptitude install gpgv

• Iniciar sesión con usuario Apache: Si usted ha seguido los pasos previos debería estar iniciado como usuario “root”, si es así debe iniciar sesión desde la consola como el usuario “www-data” que es el usuario que usa el servidor Apache para la ejecución de solicitudes de los diferentes clientes hacia el servidor, usted lo puede realizar con el siguiente comando:

# su www-data

• Generar llave(s) PGP: Se deben generar un nuevo par de llaves como un usuario sin privilegios de “root”, para que posteriormente pueda leer las claves del cliente de correo de su preferencia, usted lo puede realizar con el siguiente comando:

$ gpg –gen-key

Nota: Observa que el User Id o UID que colocas al generar la firma PGP lo debe cambiar o agregar en el archivo “mail.php” que verás en la sección “Mi solución al problema” en la variable llamada $desde, para que el interprete de PHP puede ejecutar el comando para firmar el mensaje que se envía cifrado con la firma que en este paso se esta generando.

• Listar de llave(s) pública(s) PGP: Lista todas las llaves desde el anillo de claves públicas, o justo las obtenidas en la linea de comando, lo puede realizar con el siguiente comando:

$ gpg –list-keys

• Listar de llave(s) privada(s) PGP: Lista todas las llaves desde el anillo de claves privadas, o justo las obtenidas en la linea de comando, y usted lo puede realizar con el siguiente comando:

$ gpg –list-secret-keys

• Exportar llave(s) pública(s) PGP: Con la opción –export se exporta todas las llaves desde todos los anillos de llaves. El nuevo anillo de llaves es escrito en la salida estándar o en un archivo dando la opción –output. Use junto con la opción –armor para los email de esas llaves y usted lo puede realizar con el siguiente comando:

$ gpg –armor –output /tmp/tsl_publicas.asc –export nombre@proveedor

Nota: Observa que el e-mail nombre@proveedor es el mismo que coloco al generar la llaves PGP que realizó anteriormente en el paso llamado “Generar llaves PGP”.

• Exportar llave(s) privada(s) GPG: La opción –export-secret-key es casi igual como la opción –export, pero exporta las llaves secretas, usted lo puede realizar con el siguiente comando:

$ gpg –armor –output /tmp/tsl_privadas.asc –export-secret-key nombre@proveedor

Nota: Observa que el e-mail nombre@proveedor es el mismo que coloco al generar la llaves PGP que realizo anteriormente en el paso llamado “Generar llaves PGP”.

• Cerrar sesión del usuario “www-data”: Se debe cerrar la sesión del usuario “www-data” y usted lo puede realizar con el siguiente comando:

$ exit

• Instalar PHP5: Se necesita instalar el intérprete de PHP5 con el respectivo módulo para el servidor Apache 2 y usted lo puede realizar con el siguiente comando:

# aptitude install php5 libapache2-mod-php5

• Reiniciar Apache: Se necesita reiniciar el servicio del servidor Apache2 para que vuelve a leer sus archivos de configuración y reabre algún archivos de registros o logs y usted lo puede realizar con el siguiente comando:

# /etc/init.d/apache2 restart

• Escribir una aplicación de prueba: Cree un archivo llamado info.php en el directorio /var/www-ssl/html para comprobar la instalación del módulo de PHP en Apache y usted lo puede realizar con el siguiente comando:

# vim /var/www-ssl/html/info.php

A continuación escriba el siguiente código:

<?php

phpinfo();

?>

Ejecute su navegador preferido para probar nuestros servicios con la siguiente URL: https://localhost/info.php si muestra la información de la configuración de PHP5, podemos pasar al desarrollo de la aplicación para el proyecto. Si descarga el fichero info.php es que no esta configurado correctamente el modulo PHP5 con el servidor Apache 2, verifique que allá realizado exitosamente el paso llamado “Instalar PHP5”.

Desarrollo de la aplicación demostrativa

El enunciado propuesto para el “Proyecto de Software Libre” del “I Triatlon Regional de Software Libre Mérida” es el siguiente:

1. Realizar una aplicación web segura que envié por un formulario los siguientes datos:

   1. Nombre

   2. Cédula

   3. Dirección

   4. Teléfono.

La misma debe enviar los datos firmados mediante GPG al correo nux@ula.ve puede usar cualquiera de los recursos a continuación: PKI, GPG, Web service, CGI, entre otros.

Mi solución al problema

Bueno aquí va mi solución al problema la cual solvente usando el siguiente modelo:

Cuadro 1: Ilustración del proceso de flujo de trabajo de la aplicación

Obtener los fuentes del proyecto

Usted puede obtenerlo desde el siguiente vinculo: www-ssl.tar.gz

También en la secciones llamadas “Fichero index.html” y “Fichero mail.php” se encuentran detallados los código de la aplicación.

Fichero index.html

El fichero llamado “index.html” que posee el formulario de datos, donde los mismo son enviados a la aplicación llamada “mail.php”.

<?xml version=”1.0″ encoding=”utf-8″?>

<!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Strict//EN” “http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd”>

<html xmlns=“http://www.w3.org/1999/xhtml”>

<head>

<title>Prototipo de Triatlon de Software Libre</title>

<meta name=“GENERATOR” content=“Quanta Plus” />

<meta http-equiv=“Content-Type” content=“text/html; charset=utf-8″ />

<meta name=“KEYWORDS” content=“triatlon de software libre, software libre, ofimática, programación. administración gnu linux” />

<link rel=“stylesheet” type=“text/css” href=“styles/.css” />

</head>

<body style=“background-color : #c08300;”>

<h1 style=“color : #ffffff;”>Formulario de contacto</h1>

<form action=“mail.php” method=“post” enctype=“multipart/form-data”>

<fieldset title=“Ingrese sus datos en el siguiente formulario de contacto” style=“background-color : #c0b53c; width : 20%px;”>

<legend accesskey=“Prueba” style=”color : #ffffff;”> <strong><em>Formulario de contacto</em></strong> </legend><br />

<strong>Nombre completo:</strong> <input type=“text” name=“nombre” size=“50″ maxlength=“25″ alt=“Ingrese por favor su nombre completo” tabindex=“1″ /><br /><br />

<strong>Cédula de identidad:</strong> <input type=“text” name=“cedula” size=“10″ maxlength=“12″ alt=“Ingrese por favor su número de cédula de identidad” tabindex=“2″ /><br /> <br />

<strong>Dirección:</strong> <input type=“text” name=“direccion” size=“60″ maxlength=“100″ alt=“Ingrese por favor su dirección de domicilio completa” tabindex=“3″ /><br /><br />

<strong>Teléfono:</strong> <input type=“text” name=“telefono” size=“25″ maxlength=“25″ alt=“Ingrese por favor su teléfono” tabindex=“4″ /><br /><br />

<input type=“submit” name=“enviar” value=“Enviar” alt=”Haga clic aquí para enviar los datos” />

<input type=“reset” name=“limpiar” value=“Limpiar formulario” alt=”Haga clic aquí limpiar los datos del formulario” />

</fieldset><br /><br />

</form>

</body>

</html>

Fichero mail.php

Este fichero recibe los datos, se construye el mensaje y se firma con GPG del emisario antes de enviarlo al destinatario.

<?php

$nombre = $_POST['nombre'];

$cedula = $_POST['cedula'];

$direccion = $_POST['direccion'];

$telefono = $_POST['telefono'];

 

// ruta del GPG

$gpg = ‘/usr/bin/gpg’;

// Datos de origen

// Es el nombre del usuario que envía el correo

// pero también debe ser el mismo user id o UID

// del que firma el mensaje con su clave gpg

 

$desde = ‘Leonardo’;

 

// Datos de destinatario

// E-mail del destinatario

 

// $para = ‘nux@ula.ve’;

$para = ‘leonardo@localhost’;

 

// asunto

$asunto = ‘Correo del Mini Proyecto de Leonardo Caballero’;

 

// mensaje

$mensaje = “

<?xml version=“1.0“ encoding=“utf-8“?>

<!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Strict//EN“ “http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd“>

<html xmlns=“http://www.w3.org/1999/xhtml“>

 

<head>

<title>$asunto</title>

<meta name=“GENERATOR“ content=“Quanta Plus“ />

<meta name=“AUTHOR“ content=“Leonardo Caballero“ />

<meta http-equiv=“Content-Type“ content=“text/html; charset=utf-8“ />

<meta name=“KEYWORDS“ content=“triatlon de software libre“ />

</head>

<body>

 

<table width=“100%“ cellspacing=“2“ border=“1“ cellpadding=“2“>

<caption>Datos enviados por un usuario</caption>

<thead>

<tr align=“center“>

<th>Nombre</th>

<th>Cédula</th>

<th>Dirección</th>

<th>Teléfono</th>

</tr>

</thead>

<tfoot>

<tr>

<td colspan=“4“ align=“center“>Espero su respuesta</td>

</tr>

</tfoot>

<tbody align=“justify“ valign=“middle“>

<tr>

<td>$nombre</td>

<td>$cedula</td>

<td>$direccion</td>

<td>$telefono</td>

</tr>

</tbody>

</table>

 

</body>

</html>

“;

// Para enviar correo HTML, la cabecera Content-type debe definirse

$cabeceras = ‘MIME-Version: 1.0′ . “rn“;

$cabeceras .= ‘Content-type: text/html; charset=utf-8′ . “rn“;

// Este es un comando de Shell que imprime la variable $mensaje y

// se las envía al programa “gpg” que firmara el mensaje con el

// parámetro “-e” encripta la data, con el parámetro “–always-trust”

// es idéntica a la “–trust-model always” evita la validación de

// clave y asume que la clave usada es siempre muy confiable y con el

// parámetro “-r” encripta por el nombre del user id o uid.

$comando = “echo “$mensaje” | $gpg -e –always-trust -r $desde“;

 

// Enviarlo

$mensaje_encriptado = base64_encode(shell_exec($comando));

 

$correo = mail($para, $asunto, $mensaje_encriptado, $cabeceras);

 

if ($correo) {

echo “n<h1>El correo fue enviado exitosamente.</h1>n“;

echo $mensaje;

$mensajejs = “<script>n“;

$mensajejs.= ” alert(’El correo fue enviado exitosamente’);n“;

$mensajejs.= ” location.href=’index.html’;n“;

$mensajejs.= “</script>n“;

echo $mensajejs;

} else {

echo “n<br /><h1>No ha podido enviar el correo.</h1><br />n“;

}

?>

Despliegue la aplicación

El código fuente de la aplicación se debe desplegar en el siguiente directorio: /var/www-ssl/htmls/, usted lo puede realizar con los siguientes comandos:

# cp /RUTA-ABSOLUTA/index.html /var/www/www-ssl/

# cp /RUTA-ABSOLUTA/*.php /var/www/www-ssl/

Donde:

RUTA-ABSOLUTA: Es la ruta absoluta del directorio donde se encuentran los ficheros de la aplicación.

Ejecutar la aplicación

Ejecute su navegador preferido para probar los servicios con la siguiente URL: https://127.0.0.1:443/index.html, le deberá mostrar el “Formulario de contacto”, donde debe agregar los datos y presionar el botón de “Enviar” para que proceda a enviar los datos.

• Verificar la recepción y decodificación del mensaje enviado

• Instalar llave(s) privada(s) PGP en el usuario destino: Se debe iniciar la sesión del usuario destino, luego importar la(s) llave(s) privada(s) PGP y lo puede realizar con el siguiente comando:

# su USER

Donde:

USER: Es el nombre del usuario del destinatario.

$ gpg –import /RUTA-ABSOLUTA/tsl_privadas.asc

Donde:

RUTA-ABSOLUTA: Es la ruta absoluta del directorio donde se encuentra la clave privada exportada previamente, para que el usuario del destinatario pueda descifrar el correo.

• Configurar el cliente de correo: Para este caso lo demostrare usando el cliente de correo Evolution de GNOME, las razones las cito a continuación:

• Ya esta instalado por defecto en el sistema de ventana GNOME.

• La configuración de la cuenta de correo con respecto a la UID de la llave PGP es casi transparente.

Simplemente configure una cuenta de correo del destinatario que se definió en la variable $para. La idea es poder descifrar desde el cliente de Evolution el e-mail enviado desde la aplicación realizada.

Al abrir el e-mail enviado desde la aplicación, el cliente Evolution comparara el ID del e-mail con lo(s) UID de la(s) llave(s) local(es) previamente instalada(s), si existe coincidencia y le pedirá que ingrese la clave de la llave privada PGP, así de esa forma descifrar el e-mail que se envió cifrado.

Conclusiones

Espero que les sirva este HowTo para instalar, configurar y desplegar los servicios esta aplicación básica que implementa este tipo de funcionalidad.

Para mi fue muy interesante lograr este proyecto, lastima que al momento de presentarlo fallé en la configuración del cliente de correo (tenía tiempo que no lo hacía) y además las llaves PGP no las importe adecuadamente en el usuario donde se ejecutaba el cliente Evolution, por consiguiente no pude descifrarlo desde el cliente, pero si demostré por consola que se estaba enviado el e-mail cifrado

Obtener una copia de este documento

Usted puede obtenerlo desde el siguiente vinculo: servidor-web-seguro-apache-openssl-gpg-php5.pdf

Agradecimientos

A Dios por la sabiduría dada, al CPTM por la oportunidad de participar en el evento, a Dueñas J. por su trabajo llamado “Cómo configurar Apache con soporte SSL/TLS” de Linux para todos el cual me sirvió de mucho ;), también a todo el personal de Fundacite Mérida especialmente a Hector Lira, Hector Colina e Igor Muñoz que me apoyaron y supieron responder de forma oportuna a las dudas que les formule, a Syra Lacruz por su colaboración, sobre todo durante esos días me apoyo mucho

Licenciamiento

Copyright © 2007, 2008 Leonardo Caballero.

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled “GNU Free Documentation License”.

GNU Free Documentation License

Puede obtener una copia de la licencia “GNU Free Documentation License” en los siguientes sitios en Internet:

• http://www.gnu.org/copyleft/fdl.html

• http://www.fsf.org/licensing/licenses/fdl.html

Referencia

[Dueñas 2007] Dueñas J. (2007): Cómo configurar Apache con soporte SSL/TLS. Linux para todos. En linea: http://www.linuxparatodos.net/portal/staticpages/index.php?page=como-apache-ssl. último acceso: 13/09/2007.

[CEM-bot 2007] CEM-bot, (2007): HTTPS. Wikipedia Español. En linea: http://es.wikipedia.org/wiki/HTTPS. último acceso: 03/01/2008.

[Netscape 2007] Netscape, (2007): SSL 3. Netscape. En linea: http://wp.netscape.com/eng/ssl3/draft302.txt. último acceso: 13/09/2007.

[LordT 2007] LordT, (2007): RSA. Wikipedia Español. En linea: http://es.wikipedia.org/wiki/RSA. último acceso: 03/01/2008.

[TXiKiBoT 2007] TXiKiBoT, (2007): Triple DES. Wikipedia Español. En linea: http://es.wikipedia.org/wiki/Triple_DES. último acceso: 03/01/2008.

[Ignacioerrico 2007] Ignacioerrico, (2007): X.509. Wikipedia Español. En linea: http://es.wikipedia.org/wiki/X.509. último acceso: 03/01/2008.

[OpenSSL 2007] OpenSSL, (2007): OpenSSL. OpenSSL. En linea: http://www.openssl.org/. último acceso: 13/09/2007.

[Apache 2007] Apache F., (2007): Apache Mod SSL. Apache Foundation. En linea: http://httpd.apache.org/docs/2.2/mod/mod_ssl.html. último acceso: 13/09/2007.

[Nolaiz 2007] Nolaiz, (2007): PGP. Wikipedia Español. En linea: http://es.wikipedia.org/wiki/PGP. último acceso: 03/01/2008.

[RobotQuistnix 2007] RobotQuistnix, (2007): Gpg. Wikipedia Español. En linea: http://es.wikipedia.org/wiki/Gpg. último acceso: 03/01/2008.

[VolkovBot 2007] VolkovBot, (2007): Servidor HTTP Apache. Wikipedia Español. En linea: http://es.wikipedia.org/wiki/Servidor_HTTP_Apache. último acceso: 03/01/2008.

[Jarisleif 2007] Jarisleif, (2007): PHP. Wikipedia Español. En linea: http://es.wikipedia.org/wiki/PHP. último acceso: 03/01/2008.

[CienciaAlPoder 2007] CienciaAlPoder, (2007): HTML. Wikipedia Español. En linea: http://es.wikipedia.org/wiki/HTML. último acceso: 03/01/2008.

[CienciaAlPoder 2007] CienciaAlPoder, (2007): CSS. Wikipedia Español. En linea: http://es.wikipedia.org/wiki/Hojas_de_estilo_en_cascada. último acceso: 03/01/2008.

[AlleborgoBot 2007] AlleborgoBot, (2007): Cliente de correo electrónico. Wikipedia Español. En linea: http://es.wikipedia.org/wiki/Cliente_de_correo_electrónico. último acceso: 03/01/2008.

[Estirabot 2007] Estirabot, (2007): Novell Evolution. Wikipedia Español. En linea: http://es.ikipedia.org/wiki/Novell_Evolution. último acceso: 03/01/2008.

Si usted es de esas personas que cuenta con una tarjeta inalámbrica Intel Corporation PRO/Wireless 3945, seguramente sabrá que existen al menos dos proyectos que le dan soporte. El primero de ellos es ipw3945 y se encuentra obsoleto, el desarrollo pasó al proyecto iwlwifi.

Aprovechando que recientemente ha ingresado a la versión inestable de Debian la serie del kernel 2.6.24, este contiene el nuevo modulo iwl3945 que reemplaza al viejo ipw3945. Una de las ventajas de este cambio es que ya no hay necesidad de tener activo el demonio ipw3945d. Sin embargo, aun se necesita del firmware que se encuentra en la sección non-free del repositorio de Debian.

Hasta donde he leído el plan será remover los paquetes ipw3945-modules-* e ipw3945d de los repositorios de Debian (al menos en testing y en unstable) una vez que la serie 2.6.24 del kernel llegue a la versión de pruebas (testing). Aquellos que se encuentren hoy día en la versión inestable (unstable) de Debian deberán cambiar el driver desde ipw3945 a iwl3945. Para aquellos que trabajan en etch también es posible usar el driver iwl3945 si actualiza su versión del kernel por medio del repositorio etch-backports (el nuevo stack mac80211 que usa iwlwifi se encuentra a partir de la versión del kernel 2.6.22).

Las instrucciones que verá a continuación se han aplicado en Debian inestable, si usted desea instalar iwlwifi en etch puede seguir estas instrucciones.

Obteniendo algunos datos de interés antes de proceder con la actualización.

Versión del kernel:

$ uname -r 2.6.22-3-686

Verifique que en realidad tiene una tarjeta Intel Corporation PRO/Wireless 3945

$ lspci -nn | grep Wireless 03:00.0 Network controller [0280]: Intel Corporation PRO/Wireless 3945ABG Network Connection [8086:4227] (rev 02) Paquetes necesarios

Ahora bien, es necesario instalar el nuevo kernel y el firmware necesario para hacer funcionar a iwlwifi

# aptitude install linux-image-2.6-686 \\ linux-image-2.6.24-1-686 \\ firmware-iwlwifi Evitando problemas

Verifique que no existe alguna entrada que haga referencia al modulo ipw3945 en el fichero /etc/modules. Para ello recurrimos a Perl que nos facilita la vida.

# perl -i -ne 'print unless /^ipw3945/' /etc/modules

Debido a algunos problemas que se presentan en el paquete network-manager si anteriormente ha venido usando el modulo ipw3945 se recomienda eliminar la entrada que genera udev para dicho modulo en el fichero /etc/udev/rules.d/z25_persistent-net.rules, la entrada es similar a la siguiente:

# PCI device 0x8086:0x4227 (ipw3945) SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="00:13:02:4c:12:12", NAME="eth2" Fichero /etc/network/interfaces

Este paso es opcional, agregamos la nueva interfaz wlan0 al fichero /etc/network/interfaces y procedemos a configurarla de acuerdo a nuestras necesidades.

auto lo iface lo inet loopback auto wlan0 iface wlan0 inet dhcp wpa-driver wext wpa-ssid foo wpa-psk baz wpa-key-mgmt WPA-PSK wpa-pairwise TKIP CCMP wpa-group TKIP CCMP wpa-proto WPA RSN

En este caso particular se está indicando que nos vamos a conectar a un Access Point cuyo ssid es foo con tipo de cifrado WPA-PSK/WPA2-PSK, haciendo uso del driver wext que funciona como backend para wpa_supplicant. Es de hacer notar que el driver wext es utilizado por todos los adaptadores Intel Pro Wireless, eso incluye ipw2100, ipw2200 e ipw3945.

Para hacer funcionar WPA recuerde que debe haber instalado previamente el paquete wpasupplicant.

# aptitude install wpasupplicant

De igual manera se le recuerda adaptar todos aquellos parámetros como wpa-ssid y wpa-psk a aquellos adecuados en su caso. En particular el campo wpa-psk lo puede generar con el siguiente comando:

$ wpa_passphrase su_ssid su_passphrase

Aunque mi recomendación es usar el comando wpa_passphrase de la siguiente manera.

$ wpa_passphrase su_ssid

Posteriormente deberá introducir su_passphrase desde la entrada estándar, esto evitará que su_passphrase quede en el historial de comandos.

Para mayor detalle de los campos expuestos en la configuración del fichero /etc/network/interfaces se le recomienda leer la documentación expuesta en /usr/share/doc/wpasupplicant/README.modes.gz.

Una vez concluidos estos pasos reiniciamos el sistema y seleccionamos en nuestro Gestor de Arranque (ej. GRUB) la versión del kernel recien instalada. Al momento de iniciar su sesión verifique que su tarjeta inalámbrica esté funcionando, de lo contrario haga las revisiones que se indican en la siguiente sección.

En caso de persistir los problemas

Remueva y reinserte el modulo iwl3945

# modprobe -r iwl3945 # modprobe iwl3945

De manera adicional compruebe que udev haya generado una nueva entrada para iwl3945.

$ cat /etc/udev/rules.d/z25_persistent-net.rules ... # PCI device 0x8086:0x4227 (iwl3945) SUBSYSTEM=="net", DRIVERS=="?*", ATTR{address}=="00:13:02:4c:12:12", ATTR{type}=="1", NAME="wlan0“

Finalmente, reestablecemos la interfaz de red.

# ifdown wlan0 # ifup wlan0 Elimine ipw3945

Una vez verificado el correcto funcionamiento del módulo iwl3945 puede eliminar con seguridad todo aquello relacionado con el modulos ipw3945.

# aptitude --purge remove firmware-ipw3945 \\ ipw3945-modules-$(uname -r) \\ ipw3945-source ipw3945d

Estas instrucciones también aplican para el modulo iwl4965. Mayor información en Debian Wiki § iwlwifi.