Integradores OpenSource

En la actualidad, el software libre representa una gran oportunidad de negocio para muchas empresas y profesionales de las TIC: nos permite ahorrarnos el coste de la licencia de uso, que suele ser la cantidad más importante del coste del software, pero ello no se traduce en software gratis. El uso de software libre tiene unos costes de servicios de instalación y configuración, que debido a la gran especialización, suelen ser más caros que en el caso del software propietario, pero por ello como clientes debemos exigirles más.
Los servicios de integración y consultoría de software libre, deben aportar valor, no basta con saber descomprimir un TGZ y ejecutar "make, make install"... los profesionales del software libre deben conocer las herramientas, implantarlas y configurarlas de acuerdo con las necesidades del cliente, y llegado el caso, adaptarlas modificando el código fuente si fuera necesario; de no ser así, nos estarán vendiendo software gratis como software propietario, con la escusa de que es libre. Los implantadores deben encargarse de ejercer nuestros derechos sobre el software por nosotros.
Os dejo como ejemplo la implantanción de un portal cautivo que me han pedido.

Además de implantar lo que propiamente es el portal cautivo, con este aspecto inicial
He trabajado en los siguientes puntos:

1. Traducción completa al castellano de la interfaz de usuario (la enviaré al proyecto).
2. Varias correcciones en el código PHP que he descubierto.
3. Los scripts de IpTables tienen bugs importantes, que he encontrado reportados sin solución en los foros, y en el Bugtracker del proyecto. Yo los he solucionado para mi cliente.
4. Personalización de la interfaz del usuario, de acuerdo con las guías de estilo del cliente
5. Integración con Squid y listas negras con SquidGuard. Modificación de este para tener listas blancas.
6. Personalización de los mensajes de error de Squid y Apache.
7. Varias modificaciones en la base de datos, para guardar un registro de todo lo que hacen los usuarios.
8. Configuración de los puntos de acceso Wifi.
   

El aspecto final es el siguiente.

Nuestra misión como integradores y consultores dedicados a implantar soluciones OpenSource, es garantizar a nuestro cliente que pueda ejercer sus derechos sobre el software a través de nosotros: No nos pagan por descomprimir tgz... eso lo hacen scripts.

Guía de supervivencia de MDADM

Aprovecho mi reciente experiencia con un par de servidores Fujitsu Primergy RX100, para dejar testimonio de supervivencia sobre RAID software conLinux, porque lo que es la controladora SATA esta que traen estos equipos, no engaña ni a Windows... al final si queremos configurar un RAID1 con los dos discos e instalar Linux, tendremos que hacerlo por software deshabilitando en la BIOS la controladora SATA.

• Conocer el estado del RAID,

  cat /proc/mdstat

• Reinsertar en el RAID un disco, porque arrancamos el equipo con el raid degradado, y una vez lo hemos devuelto a su lugar, debemos recuperar el estado del Raid

  mdadm --manage /dev/md0 --add /dev/sdb1
  mdadm --manage /dev/md1 --add /dev/sdb5

  Hemos supuesto que tenemos dos particiones (sdb1 y sdb5) en Raid (dm0 y dm1).
• Nos falla completamente un disco. Lo cambiamos en caliente y reemplazamos el que está averiado, por un igual. Así tendremos que clonar un nuevo disco en el RAID1. Lo primero será recuperar la configuración del RAID,

  mdadm --examine  --scan --config=partitions > /tmp/mdadm.conf
  mdadm --assemble --scan --config=/tmp/mdadm.conf

  Luego tendremos que recrear las mismas particiones del disco bueno, en el nuevo...

  unset LANG
  sfdisk -d /dev/sda | sfdisk --Linux /dev/sdb
  partprobe
  fdisk -l
  cat /proc/mdstat

  Por último reinsertar estas nuevas particiones en el RAID, para que empiece la complicación...

  mdadm --manage /dev/md0 --add /dev/sdb1
  mdadm --manage /dev/md1 --add /dev/sdb5
  cat /proc/mdstat 

  Cuando se haya completado la sincronización, instalaremos grub en los dos discos...

  grub-install /dev/sda
  grub-install /dev/sdb

Si aún así, necesitamos saber un pocó más os recomiendo consultar el howto Replacing A Failed Hard Drive In A Software RAID1 Array. Gracias Juanjo por la ayuda que me has dado en esto.
La imagen la he sacado de la galería de brandon shigeta en flick.

World of Goo

Hacía tiempo ya que no jugaba a ningún juego de ordenador, quizás desde que mis sobrinos me retan al Ghost'n Goblins, Puzzle Booble y el Pang en la máquina recreativa que les preparé en casa. Worl Of Goo es un juego de puzzles que me recuerda irremediablemente a los Lemmings. Partimos de unas pequeñas bolitas pegajosas y resbaladizas llamadas goos, que debemos ir apilando y enlazando para crear un camino que conduzca al resto de goos a la tubería de escape. Podremos usar varios tipos de goos:

• negros, que son los más básicos,
• verdes, que podemos quitar y poner en diferentes posiciones,
• rojos, que podemos quemar como si fueran una mecha
• abejas voladoras, que permiten deshacer la última acción
• calaveras, que son inmunes a los pinchos, y alguno más que aún no he visto

Este juego es un vicio: Con una estética que me recuerda a Worms, es muy entretenido y divertido. Podemos ver un video en YouTube, y bajarnos una demo para probarlo... pero lo mejor del juego no es esto, lo mejor es que puedes comprarlo en la Web por unos 15€, y ver que puedes descargarlo Linux (en versión RPM, DEB y TGZ por si eres muy friki)... eso sí que no tiene precio: sin duda es lo mejor, el respeto con el que nos han tratado a los usuarios de Linux. Todo un lujo.

Además pienso que el modelo de negocio para este tipo de juegos que no van respaldados por una superproducción es muy acertado. Podemos comprar juegos para el móvil y melodías chorras a partir de 3€. Un juego actual puede costarnos 50€ ... ¿por qué no descargarlo directamente por poco más que un politono con cubata y ahorrarnos un 70% en la compra del juego?

Deshabilitar ipv6 en ubuntu 9.10

El otro día al configurar un equipo con Ubuntu 9.10, comprobé que cada vez es más difícil deshabilitar ipv6 en nuestros equipos Linux ¡¿?! ... Comprobé que después de haber añadido a /etc/modprobe.d/00local las siguientes líneas:

alias net-pf-10 off
alias ipv6 off 

... añadir a /etc/modprobe.d/blacklist.conf la línea

blacklist ipv6

y reiniciar el equipo, seguía teniendo ipv6 configurado. Parece que en Ubuntu debemos deshabilitarlo desde grub2. Para ello tenemos que editar el fichero /etc/default/grub y configurar la línea GRUB_CMDLINE_LINUX, para que tenga:

GRUB_CMDLINE_LINUX="ipv6.disable=1"

Cuando terminemos de editar el fichero, podremos aplicar los cambios ejecutando

sudo update-grub2

Todo esto me hizo intentar recordar, por qué sistemáticamente deshabilito ipv6 cuando termino de instalar un servidor en una red con sólo servicios ipv4:

• El hecho de tener configurado el protocolo nos consume tiempo de CPU y espacio en RAM.
• Además al tener configurado Ipv6 estamos expuestos a los agujeros de seguridad del protocolo.
• A parte de estos inconvenientes que encontramos en cualquier otro protocolo de red, resulta que cuando tenemos configurado nuestro equipo en IPv6, todas las consultas que hacemos al DNS se hacen en ipv6 y en ipv4: esto inyecta tráfico que no sirve para nada a nuestra red, y ralentiza las comunicaciones de nuestro equipo, porque no se da por resuelta la consulta DNS hasta que no se han obtenido las respuestas ipv6 e ipv4, o han expirado los timeouts.

La imagen la he sacado de la galería de iandavid en flick

Usar Ubuntu Server frente RedHat Enterprise Linux

En los últimos meses he empezado a desplegar equipos Ubuntu Server 9.10 en varios clientes, en detrimento de RedHat. Hasta hoy los motivos han sido la posibilidad de usar EXT4 ya en la instalación de una forma más estable si se compara con Debian 5.0, el hecho de que los paquetes importantes estén muy actualizados (OpenLDAP 2.4.18, samba 3.4 + samba4, apache 2.2.12) y por supuesto el soporte gratuito a actualizaciones: Esta gente de ubuntu cada vez más me parece más atrevida, más profesional y más dinámica, aunque aún quedaría evaluar el soporte de pago.

RedHat para algunas cosas me parece un petrolero gigantesco cruzando un océano a gran velocidad, pero que para cambiar de rumbo necesita mucho espacio y tiempo, creo que ha perdido frescura frente a Canonical: es como pensar en el monstruo IBM intentando vender de todo y compitiendo con Apple vendiendo iPods o iPhones. En RedHat5 aún seguimos con samba 3.0.33 u OpenLdap 2.3, y otros paquetes que ya tienen más de dos años de antigüedad, y esto, para algunos clientes que no tienen contratado el soporte con RedHat es un problema, porque algunos bugs ya no se pueden reportar al upstream del proyecto base ya que están marcados como obsoletos. Si encuentro un bug en el paquete Samba de mi RHEL5 último Update, estoy obligado a reportarlo a RedHat, previo pago, no puedo enviarlo a la lista de desarrollo de samba porque está obsoleto, ellos tienen marcada como en mantenimiento (sólo arreglan bugs de seguridad) la versión 3.2, y en estable la 3.4.4 (sólo podemos reportar bugs para esta), mientras que Samba4, en contínuo desarrollo, ya incluye compatibilidad total con el Directorio Activo de Windows 2003... ¿cuánto tiempo tendrá que pasar para que dispongamos de estas versiones en RedHat Enterprise Linux?. Los implantadores debemos influir en la decisión de qué distribución usar, depediendo de las necesidades funcionales del cliente y del soporte que tenga contratado con el distribuidor.

Tampoco creo que la frescura de Fedora sea recomendable para el despliegue de servidores, creo que sus políticas de inclusión de software es demasiado inestable para algunos paquetes importantes: No hace mucho quitaron completamente el soporte a XEN en el Hypervisor después de haberlo incluído en versiones previas. En los últimos tiempos es cierto que Fedora ha mejorado mucho la experiencia del usuario de escritorio, pero me parece demasiado atrevido usarla en servidores de producción.

Con todo ello no quiero decir que una sea mejor que otra, lo único que digo es lo que ya le comenté un día a Alfonso Vera hablando de estas cosas: Al final el soporte Linux, lo das tú, nadie llama a RedHat cuando aparece un problema, te llaman a tí, y si tú no sabes llamas a RedHat. Las matrices de compatibilidad están muy bien pero en ellas no siempre pone como resolver los problemas de tu cliente cuando aparecen, eso lo hacemos los implantadores: Cuando te manden luchar, deja que por lo menos te permitan elegir las armas con las que tienes que defenderte.

La imagen la he sacado de la galería de afsilva

Xinetd e Identd

El otro día me pidieron que revisara la configuración de un sistema RHEL5 que tenía configurado un servidor CVS autenticado vía LDAP contra NDS-Novell. Al parecer cuando se accedía al servicio vía VPN desde una VLAN aislada, las conexiones con el CVS iban excesivamente lentas, mientras que en la Intranet iban a la velocidad habitual.

Analizando el patrón del tráfico desde el servidor CVS con tcpdump, pude comprobar que por cada conexión que se realizaba al servidor, había una petición desde este hacia el cliente por el puerto TCP/113. Este puerto es el que usa el servicio Identd, para identificar usuarios en conexiones TCP/IP. Después de un rato buscando al final descubrí que el origen de estas conexiones estaba en la opción USERID que había configurada en las líneas log_on_success y log_on_failure de varios de los servicios que tenía configurados en /etc/xinetd.d/*, y en concreto en el fichero de CVS. Esta opción hacía que cada conexión exitosa o fallida hacia el servicio lanzara una conexión IdentD para identificar el usuario. Cuando la conexión venía desde la VPN, el firewall truncaba este flujo y la conexión desde el servidor CVS no obtenía respuesta, por lo que tenía que esperar a que expirara el timeout.

La solución a este problema es tan simple como eliminar las apariciones de la opción USERID de todos los ficheros /etc/xinetd.d/*, y luego reiniciar el servicio /etc/init.d/xinetd restart.

La imagen la he sacado de la galería de Zorraquino.

En la cabeza de Steve Jobs

Anoche, justo una semana después que se presentara el iPad, acabé el libro que me regalé por San Antón, cuando me convencí de que los reyes mágicos ya no me traerían nada este año. En la cabeza de Steve Jobs: La mente detrás de Apple, es un libro entretenido de lectura fácil y rápida que nos relata la vida, obra y milagros del genio que hay detrás de Apple.

El texto está organizado en capítulos cortos, en los que en cada uno se enfatiza uno de los rasgos de la personalidad de Steve que más han podido influir en el éxito de Apple: Focalización, despotismo, perfeccionismo, elitismo, pasión, creatividad y obsesión por el control. Para desarrollarlos, el autor nos cuenta un montón de historias y anécdotas que a veces no parecen tener relación y que no paran de mezclarse en el tiempo: Los comienzos de Apple en los setenta, la época oscura cuando le pusieron en la calle, el discreto éxito de Next, el nacimiento de Pixar, el retorno a Apple, el éxito del iPod y del iPhone. Al estar todo entremezclado, pienso que obliga al lector a conocer previamente parte de la historia de Jobs, y a participar de la cultura de Apple profundizando aún más en ese elitismo y culto a la manzana.

Aparte del estilo de la redacción, el libro presenta las grandes contradicciones del comportamiento de Jobs: Por un lado su elitismo frente a su obsesión de simplificarlo todo, por otro lado sus problemas en las relaciones personales con todos frente a grandes amistades como la de Lasseter o Wozniak, su antimaterialismo frente a la venta masiva de artilugios fabricados en Asia.

Aunque el libro vanagloria en exceso la figura Steve sin profundizar en la parte más oscura de su personalidad, a pesar de que se deja ver porque no se puede disimular, no se le puede negar que este señor es todo un ejemplo de constancia, esfuerzo, dedicación, innovación y talento para este negocio de la informática. Es un gran visionario digno de admiración y del respeto de todos los que nos dedicamos a la Informática. Leyendo el libro (atención spoiler) te puedes enterar de cosas como que ... cuando introdujo el ratón en el mercado, quitó las teclas de función del teclado para obligar a los usuarios a realizar ciertas funciones con el ratón, y a los fabricantes de software a reprogramar sus aplicaciones para contemplar este cambio. El libro está plagado de historias de estas.