Archivo del sitio

[OpenLDAP] Bitácora de instalación

He decidido recuperar mi blog técnico, y para comenzar su uso, he incluído una completa guía de instalación, configuración y personalización del servicio de directorio OpenLDAP bajo Debian GNU/Linux.

Espero poder contar con sus visitas y comentarios en esta nueva etapa de documentación en mi blog.

Gracias y allá nos vemos!

Instalar openWRT a un TP-LINK WR-741ND

He tomado un viejo enrutador TP-LINK pre-N (150Mbps) que tenía por allí para actualizarle el firmware e instalar openWRT, mis razones de por qué openWRT y no DD-WRT?

tplink

  • Lo que no podés hacer por la interfaz, lo hacés por consola
  • El soporte a VLANs es exactamente igual al nativo en Linux, si aprendí en Linux, lo sé hacer en openWRT
  • Selección: Varios “optware” (módulos opcionales) y mod-hackings presentes para openWRT me son útiles (como soldarle un puerto USB y usarlo como servidor de impresión)

Entre otras cosas, DD-WRT es bastante óptimo en estos equipos para cosas como permitir gestionar la inalámbrica, múltiples SSID (es lo bueno del software libre: elección) pero en mi caso, usaré el equipo para más cosas y por ende openWRT es mi opción.

Actualización del Firmware oficial

Lo primero que debemos hacer es actualizar el firmware oficial de la página de TP-LINK, esto con el fin de evitar inconvenientes y tener un firmware “oficial” de respaldo ante cualquier inconveniente.

or seguridad, actualizar a la última versión de la versión 1 (V1.6 en mi caso).

Descargar cualquier versión v1 del ROM oficial acá:

http://www.tp-link.com/ve/support/download/?model=TL-WR741ND&version=V1

– Descargar y descomprimir:

wget -c http://www.tp-link.com/resources/software/201011814560814.zip

unzip 201011814560814.zip
cd 201011814560814

– Ir a System Tools > Firmware Upgrade y cargar el binario que descargamos (wr741nv1_en_3_12_4_up(100910).bin)

– Reiniciar el equipo y luego un “factory defaults”

downgrade

Listo, actualizado a la última versión “oficial”, pasamos a obtener OpenWRT.

Obtener openWRT

Para obtener openWRT podemos ir a la página oficial del enrutador:

Página oficial: http://wiki.openwrt.org/toh/tp-link/tl-wr741nd

Y aprovechar el WIKI en español que nos ofrecen:

Wiki de openWRT en español: http://wiki.openwrt.org/es/toh/tp-link/tl-wr741nd

Para descargar la última versión estable para el enrutador (Backfire) apuntamos a:

– Descargar la última versión backfire:
http://downloads.openwrt.org/backfire/10.03.1-rc3/ar71xx/openwrt-ar71xx-tl-wr741nd-v1-squashfs-factory.bin

– O con la última versión del trunk:
http://downloads.openwrt.org/snapshots/trunk/ar71xx/openwrt-ar71xx-generic-tl-wr741nd-v1-squashfs-factory.bin

También he descargado la última versión Beta (2014) (versión de actualización):

http://downloads.openwrt.org/attitude_adjustment/12.09/ar71xx/generic/openwrt-ar71xx-generic-tl-wr741nd-v1-squashfs-sysupgrade.bin

Con esto descargado, ahora si procedemos con el enrutador.

Desactivar opciones en el Router

Por seguridad deberíamos cumplir los siguientes criterios:

  • Estar conectados por la red alámbrica
  • Desactivar la red inalámbrica
  • Tener un firmware oficial descargado
  • Energía eléctrica estable (se los aseguro!, lean el último capítulo)

 

Preparando el TP-LINK para instalación

– Conectarse al equipo vía cable (parece obvio, pero hay que recordar que no se puede hacer este procedimiento vía wireless).
– Hacemos un respaldo del mismo (System tools > Backup & Restore > Backup)
– Reiniciamos el equipo a sus valores de fábrica (System Tools > Factory Defaults)
– Entramos al equipo con sus valores por defecto (IP: 192.168.1.1, user:admin, password:admin)
– Deshabilitamos el radio del equipo, para ello:
* vamos a la opción “wireless”
* desmarcan el checkbox “enable wireless radio”
* presionan el botón “SAVE”
* hagan click en el link “reboot” y luego en el botón “reboot”
* vayan a “status” y confirmen que Wireless está DISABLE.

wireless-disableAhora, ya podemos iniciar la instalación de openWRT.

Instalación vía Web

– Vamos a Firmware Upgrade (System Tools > Firmware Upgrade)

firmware-upgrade

Allí escogemos el archivo del firmware openWRT que seleccionamos y le damos “UPGRADE”.

Luego de unos minutos verán:

completed

Y el equipo se reiniciará en openWRT.

Accediendo al openWRT por primera vez

Al encender nuevamente el TP-LINK y conectarnos por red inalámbrica, nos dará una IP de la subred 192.168.1.0; nos conectamos al router a través de http://192.168.1.1/

Nos exigirá asegurar el equipo con una clave:

dd-wrt-first

Y luego de insertar la clave veremos que solicitará que aseguremos el acceso SSH:

no-password

 

Hacemos click en “Go to password configuration”:

Y configuramos la clave del usuario root:

openwrt-first

y el acceso SSH, luego presionan “SAVE & APPLY”:

save-apply

Y ya estamos listos para configurar, o para actualizar a la versión trunk “attitude adjustment”.

Actualizando a una nueva versión

descagar attitude_adjustment: http://downloads.openwrt.org/attitude_adjustment/12.09/ar71xx/generic/openwrt-ar71xx-generic-tl-wr741nd-v1-squashfs-sysupgrade.bin

Para actualizar se puede contar con varios modos, acá explicaré el modo SSH, el modo SCP (failsafe) y el modo Web

Modo Web

El modo web es muy sencillo, simplemente van a SYSTEM > FIRMWARE UPGRADE y cargan la versión de firmware que contenga la palabra “sysupgrade”:

system-flashing-openwrt

Vigilen los LEDs, cuando vean que el equipo esté completamente activado, verán que pierden el acceso Web, es porque hay un par de módulos que se deben activar “a mano” en esta versión de openWRT.

Acceso SSH:

  • Acceden por SSH al equipo 192.168.1.1 con el usuario “root” y la clave que le proporcionaron.

openwrt-ssh

Ejecutan los siguientes comandos:

opkg update
opkg install luci

/etc/init.d/uhttpd start
/etc/init.d/uhttpd enable

Y listo!, ya pueden acceder a la interfaz web.

Actualización via SSH

Podemos acceder vía SSH al TP-LINK y actualizarlo vía SSH

– Con acceso a Internet

Si es con acceso a Internet, simplemente, nos vamos al directorio TMP

root@OpenWrt:~# cd /tmp

Descargamos el FIRWMARE “sysupgrade” necesario:

root@OpenWrt:/tmp# wget -c http://downloads.openwrt.org/snapshots/trunk/ar71xx/openwrt-ar71xx-generic-tl-wr741nd-v1-squashfs-sysupgrade.bin
Connecting to downloads.openwrt.org (78.24.191.177:80)
openwrt-ar71xx-gener 100% |*****************************************************************************************************| 2880k 0:00:00 ETA

Ejecutar la actualización:

root@OpenWrt:/tmp# sysupgrade -v /tmp/openwrt-ar71xx-generic-tl-wr741nd-v1-squashfs-sysupgrade.bin

Upgrade completed
Rebooting system…

Al finalizar el reboot, hacer un “cold reset” (desconectar la energía, esperar 10 segundos y reconectar).

Volver a conectarse vía SSH y activar la interfaz web:

opkg update
opkg install luci
/etc/init.d/uhttpd start
/etc/init.d/uhttpd enable

– Sin acceso a Internet

Si no cuentan con Internet, pero el firmware lo han descargado a un equipo al que están conectados alámbricamente entonces usan SCP para copiarlo a /tmp en el TP-LINK

root@OpenWRT:/tmp# scp -P 22 root@192.168.1.2:/home/jesuslara/Descargas/openwrt/openwrt-ar71xx-tl-wr741nd-v1-squashfs-factory.bin .
Host ‘192.168.1.2’ is not in the trusted hosts file.
(ssh-rsa fingerprint md5 81:05:23:57:67:f5:bd:79:8a:08:2b:d9:eb:14:aa:00)
Do you want to continue connecting? (y/n) yes
root@192.168.1.2’s password:
openwrt-ar71xx-tl-wr741nd-v1-squashfs-factory.bin 100% 3840KB 768.0KB/s 00:05

Y actualizamos:

root@openWRT:/tmp# sysupgrade -v /tmp/openwrt-ar71xx-tl-wr741nd-v1-squashfs-factory.bin
Saving config files…
etc/sysctl.conf
etc/shells
etc/rc.local
etc/profile
etc/passwd
etc/inittab
etc/hosts
etc/group
etc/dropbear/dropbear_rsa_host_key
etc/dropbear/dropbear_dss_host_key
etc/config/system
etc/config/firewall
etc/config/dropbear
etc/config/dhcp
killall: watchdog: no process killed
Failed to connect to ubus
Switching to ramdisk…
Performing system upgrade…
Unlocking firmware …
Writing from <stdin> to firmware … [w]
Upgrade completed
Rebooting system…
Connection closed by foreign host.

Igual que los anteriores, actualizamos el opkg update y accedemos vía web.

Modo Failsafe

El modo “failsafe” es un modo busybox que es útil para recuperación, incluso en modos cuando ningún acceso es posible, en los TP-LINK el modo FAILSAFE se logra de la siguiente manera:

  • Desconectar cualquier cable de red que se tenga conectado
  • Desconectar de la corriente, esperar 10 segundos
  • Volver a conectar, observando los LEDs
  • Cuando el LED “SYS” comienza a parpadear y antes de quedar fijo, presionar varias veces el botón QSS
  • El LED “SYS” comenzará a parpadear muy rápidamente “Flash-blinking”, están en modo FAILSAFE

Para conectarse al modo FAILSAFE, deberán configurar manualmente su interfaz eth0 a la subred 192.168.1.0, yo en Debian ejecuté:

  • Desactivé el network-manager (service network-manager stop)
  • ifconfig eth0 up && ifconfig eth0 192.168.1.2 netmask 255.255.255.0

Y nos conectamos vía Telnet:

root@tafil:~# telnet 192.168.1.1
Trying 192.168.1.1…
Connected to 192.168.1.1.
Escape character is ‘^]’.

=== IMPORTANT ============================
 Use 'passwd' to set your login password
 this will disable telnet and enable SSH
 ------------------------------------------
BusyBox v1.19.4 (2014-04-23 10:39:15 UTC) built-in shell (ash)
Enter 'help' for a list of built-in commands.
_______ ________ __
 | |.-----.-----.-----.| | | |.----.| |_
 | - || _ | -__| || | | || _|| _|
 |_______|| __|_____|__|__||________||__| |____|
 |__| W I R E L E S S F R E E D O M
 -----------------------------------------------------
 BARRIER BREAKER (Bleeding Edge, r40555)
 -----------------------------------------------------
 * 1/2 oz Galliano Pour all ingredients into
 * 4 oz cold Coffee an irish coffee mug filled
 * 1 1/2 oz Dark Rum with crushed ice. Stir.
 * 2 tsp. Creme de Cacao
 -----------------------------------------------------

A partir de acá, la actualización procederá igual al modo SSH con o sin Internet.

Acceso Web a la versión trunk

Por seguridad, al actualizar, openWRT les exigirá reconfigurar la clave y el acceso SSH (con su nueva interfaz):

password-openwrt-2

y SSH:

ssh-openwrt-2

Luego, ya podemos configurar la inalámbrica:

configure-wifi

Y listo!, en próxima entrega otros experimentos! …

PD: ¿Y el modo recovery?

Cuando me encontraba experimentando con las diversas versiones y hacks de openWRT (Gargoyle, “attitude adjustment”, etc) durante un proceso de upgrade hubo un bajón de electricidad (bueno, técnicamente se fue la luz en mi casa) y el TP-LINK había quedado en un estado “BRICK” (un gran ladrillo), con el botón SYS completamente colgado. Es allí cuando el modo “recovery” entra en operación.

Para ello, accedemos vía telnet tal como expliqué, no sin antes borrar todo en la memoria existente:

Primero, ejecutamos “firstboot”

root@(none):/# firstboot

This will erase all settings and remove any installed packages. Are you sure? [N/y]
y
/dev/mtdblock3 is not mounted, erasing it
erasing 0 10000
erasing 10000 10000
erasing 20000 10000
erasing 30000 10000
erasing 40000 10000
erasing 50000 10000
erasing 60000 10000
erasing 70000 10000
erasing 80000 10000
erasing 90000 10000
erasing a0000 10000
erasing b0000 10000
erasing c0000 10000
erasing d0000 10000
erasing e0000 10000
erasing f0000 10000
root@(none):/#

Cambiamos al directorio TMP

root@(none):/# cd /tmp

Luego, usamos SCP para copiar un firmware COMPLETO (no un sysupgrade) a /TMP:

root@(none):/tmp# scp -P 22 root@192.168.1.2:/home/jesuslara/Descargas/openwrt/openwrt-ar71xx-tl-wr741nd-v1-squashfs-factory.bin .

/usr/bin/dbclient: Warning: failed creating /root/.ssh: Read-only file system

Host ‘192.168.1.2’ is not in the trusted hosts file.
(ssh-rsa fingerprint md5 81:05:23:57:67:f5:bd:79:8a:08:2b:d9:eb:14:aa:00)
Do you want to continue connecting? (y/n) yes
root@192.168.1.2’s password:
openwrt-ar71xx-tl-wr741nd-v1-squashfs-factory.bin 100% 3840KB 768.0KB/s 00:05

Y lo cargamos con sysupgrade:

root@(none):/tmp# sysupgrade -v /tmp/openwrt-ar71xx-tl-wr741nd-v1-squashfs-factory.bin
Saving config files…
etc/sysctl.conf
etc/shells
etc/rc.local
etc/profile
etc/passwd
etc/inittab
etc/hosts
etc/group
etc/dropbear/dropbear_rsa_host_key
etc/dropbear/dropbear_dss_host_key
etc/config/system
etc/config/firewall
etc/config/dropbear
etc/config/dhcp
killall: watchdog: no process killed
Failed to connect to ubus
Switching to ramdisk…
Performing system upgrade…
Unlocking firmware …

Writing from <stdin> to firmware … [w]

Upgrade completed
Rebooting system…
Connection closed by foreign host.

El equipo “volverá a la vida” después de eso, de no ser así, podrían montar un TFTP y cargar el firmaware, usar MTD o incluso podrían fabricarse un cable USB-to-SERIAL para conectarse al TP-LINK (requiere algo de experiencia y soldadura!).

Incluso, podríamos usar el modo FAILSAFE para devolver el equipo a un firmware STOCK.

¿Qué más?

OpenWRT es bastante completo, lástima que su interfaz no sea “tan elaborada” como la de DD-WRT, sin embargo, tiene mucho más desarrollo (la versión TRUNK de mi TP-LINK es de Marzo de este año), por lo que sirve para tener cosas tan avanzadas como un kernel 3.3 o soporte a openFlow y openVswitch, entre otras.

En próximo artículo, VLANS y múltiples SSID.

 

¿Y DD-WRT?, si, también lo instalé en el TP-LINK, la forma de instalación es muy semejante … comenta si deseas que haga un artículo.

Happy Hacking!

 

 

 

Triunfo y desastre: sobre dos migraciones a OpenOffice.org

Creo que hay que leer este artículo de José Alcántara, nos saltan muchas “inquietudes”, acerca de cómo se están haciendo las cosas en el mundo del software libre (y Venezuela es parte de esa regla), sobre todo, cuando se enfoca al *software libre* desde el ángulo incorrecto.

Maimónines y Séneca se enfrentan …

Maimónides es un sistema de gestión escolar diseñado por una empresa española para interconectarse con el actual  sistema de gestión SENECA (de la Junta de Andalucía), pero en vez de ser un proyecto “como cualquier otro en software libre”, la costa terminó siendo un juego del “gato y el ratón”, intentas hacer algo sin apoyo de la institución que “supuestamente” tratas de ayudar (es como hacer una API libre para interactuar con SENIAT y meses después, el SENIAT cambia su servicio, bueno, así), una empresa “Kodeko”, se dedica a llevar “el desarrollo” de una aplicación “con estándares libres” que busca algo “multi-plataforma” (claro, por aquello de la **interoperabilidad**, eso se lee “debe correr en Windows”), y como siempre, si la Junta de Andalucía no libera estándares ni especificaciones, sin la liberación de la API (para permitir a terceros desarrollar conectores, mejoras y nuevas versiones de Maimónides), la imposibilidad de “ponerse de acuerdo” (SENECA llegó a incorporar funcionalidades para evitar que MAIMONIDES funcionara correctamente) y un sinfín de trabas adicionales, han llevado a Kodeko a tomar la triste decisión, Maimónides deja de desarrollarse.

Del otro lado de la moneda está SENECA, este es un sistema para gestión escolar hecho para la Junta de Andalucía, se “suponía” que SÉNECA sería otro “desarrollo como cualquier software abierto ó libre”, es decir, una comunidad, gente desarrollando, estándares abiertos, etc; al final, la cosa se convirtió en una típica relación “Estado <> Empresa” (¿dónde han visto ustedes eso?) donde la Junta de Andalucía paga por un “software abierto”, dónde la culpa de “la lentitud” siempre el “consultor” se la echará a la base de datos (y terminan usando ORACLE sobre Solaris y Java 2EE sobre WebSphere) Y no importa qué tan “abierto” sea el código, termina siendo una relación “Junta de Andalucía <-> SADIEL-AYESA”, donde ámbos son los únicos que tocan el código e implementan mejoras al sistema, donde la empresa cobra Horas/Hombre, servicios de consultoría y es técnicamente, la única que puede “usarlo, meterle mejoras e implementarlo dentro de la junta de Andalucía”, ¿dónde está la libertad en eso? …

Al final, SADIEL-AYESA (la gran *mega-contratista*) se encargó (metiendo captchas, trampas, desconexiones) de evitar que Maimónides (y me imagino que cualquier otro software) se “interconectara” con SÉNECA y viniera a quitarles “el contrato” de cientos de horas/hombre de mantenimiento por caídas, desconexiones, mal servicio y soporte en general.

Que si para eso vamos, “supuestamente” el código de ORACLE 9i está en las bóvedas de PDVSA, así que “técnicamente” Oracle es software de código abierto, así yo no pueda tocarlo, usarlo o tan siquiera verlo, para PDVSA, *eso* es código abierto.

Dónde software libre, no es gratis

El artículo anterior me llevó de vuelta a la por demás paradójica historia de dos ciudades Alemanas, Freiburg y Munich, que intentaron migrar a “software libre” con resultados diametralmente opuestos.

La ciudad de Freiburg comenzó su migración a “OpenOffice.org”, pensando en que este sistema “le ahorraría costos en licencias” (con 2000 usuarios, serían unos 150 mil ó más dólares al año); al final, el principio por el que mucha gente lo adopta (-al software libre-) es precisamente ese, “es gratis y me ahorro las licencias”.

5 años y 600 mil dólares después, con toda una plataforma inestable y muchos usuarios infelices, la Alcaldía de Freiburg llamó a un consultor Microsoft acerca de las “posibilidades para arreglar el problema”, ¿la solución?, ¡Fácil!, echar para atrás todo, volver a Microsoft Office con una renovación en licencias que costó el primer año sólo 500 mil US$.

El problema derivó del primer enfoque, “ahorro de costos”, por aquello de la “interoperabilidad” y “el derecho a escoger”, mucha gente “por comodidad” se quedó en Microsoft Office, hubo que pagar migraciones de plantillas y macros a OpenOffice, la gente que usaba OpenOffice debía guardar sus archivos como “.doc” puesto que Microsoft Office “no lee” archivos de OpenOffice.org (¡y luego hablan de interoperabilidad los muy cínicos!) y un flujo mixto de documentos “Office-OpenOffice” maximizó las incompatibilidades y los errores, ¿de quien era la culpa?, ¡Por supuesto!, OpenOffice era el culpable de no poder “interoperar” correctamente con Microsoft Office; ¡caso cerrado!.

Del otro lado de la moneda tenemos a Munich, en ella la migración fue “completa” y no fue opcional, a la gente se les “retiraron” sus Microsoft Windows de sus equipos y se les instaló una combinación de LiMux (una distribución GNU/Linux desarrollada directamente por la propia Junta de Munich) y OpenOffice, hoy, la Junta de Munich informa que su migración a software libre les ha ahorrado 13 millones de euros, que tienen 15 mil usuarios completamente felices usando una distribución GNU/Linux y tienen una distribución GNU/Linux certificada con la norma ISO 9241.

La pregunta es ¿cómo lo hicieron?.

El enfoque de la ciudad de Munich fue totalmente distinto, ellos jamás pensaron en “el ahorro de costos”, sino en la primera y verdadera premisa del software libre, la libertad, Munich dedicó un gran esfuerzo e inversión en generar “comunidad”, muchos de sus IT-Administrators y SysAdmins eran miembros de la comunidad (o debían serlo), colocaron personas en lugares *clave* para la corrección de fallas, desarrollo de nuevas características o la construcción de comunidades (que se convertirían, en el largo plazo, en soporte y mantenedores de la misma); tal como Wollmux (el sistema de gestión de plantillas, conversor de templates y auto-texto sobre plantillas) fue un desarrollo netamente financiado por la Junta de Munich, incluso, la Junta donó dinero y apoyó la conversión de OpenOffice a LibreOffice cuando este fuera abandonado por Oracle.

¿Por qué no se podía pensar en *interoperabilidad*?, cada vez que alguien escuche esa palabra, téngalo por seguro que para alguien significa “no importa lo que vayan a montar, mi software por favor no me lo toquen”, en la primera evaluación (que llevó al desarrollo de Wollmux) la ciudad encontró que había nada más y nada menos que 13700 plantillas de documentos y hojas de cálculo con macros “casi una por cada empleado de la Alcaldía” (es como la historia de los 360 software de gestión internos dentro de Banco de Venezuela, para usar uno diario), por ende la migración no es solamente un “abaratamiento” de costos, es la oportunidad para salvar de un ecosistema heterogéneo a una plataforma de IT y casarla con estándares abiertos, que todos conocen y con los que realmente todos interactuan (o casi todos, no fue sino hasta el reciente MS Office 2013 que incorporaron soporte a ODF 1.2, el estándar de LibreOffice).

Y es extraño para muchos, si la premisa principal de migrar a software libre es porque “me ahorrará costos”, que la Junta de Munich haya invertido tanto parecerá ilógico (la Junta de Munich ha pagado, sólo a *freelancers comunitarios* 4 millones de euros para desarrollos particulares sobre Debian, Ubuntu y LibreOffice), incluso HP llegó a pagar un “estudio” donde aseguraba que la Junta de Munich mentía sobre sus cifras de ahorro, que *no estaban contando* los salarios de los cientos de empleados de IT requeridos para mantener el software libre (y la comunidad) y las constantes “actualizaciones” que le hacían a LiMux (que al ser “gratuito”, podías sacar versiones cada vez que la distribución Madre, Ubuntu, sacara nuevas versiones); sin embargo la Junta de Munich se defendió de ese artículo diciendo:

“Contrario a lo que HP clama, el uso de software libre si baja el costo del hardware -ya que exigimos la venta del mismo sin software pre-instalado-, además la empresa (HP) no pudo distinguir (en su informe) la diferencia entre una migración de software y el mantenimiento regular que se le hace al mismo”

Y las cifras que exponen en sus estudios son por demás alentadoras:

Gastos en Licencias, software base e inversión inicial (para 15 mil equipos):

Windows y MS Office:                   11.594.200 Euros

Windows con OpenOffice:              7.394.200 Euros

LiMux:                                                    273.132 Euros

Gastos relativos al mantenimiento de la plataforma (entrenamiento, soporte, actualizaciones, antivirus, Personal, etc):

Windows y MS Office (más servicios) para Munich:     34.143.880 Euros

Windows (con LibreOffice y herramientas libres):          29.943.880 Euros

LiMux:                                                                                     22.822.812 Euros

No por nada, la primera acción de la Municipalidad de Munich *antes* de migrar a Software Libre “no fue” ¡vamos a sacar la calculadora, a ver si las cuentas dan! (como típico gerente de institución pública), fue sacar dinero (12.8 millones de euros) para financiar la migración y emitir una DECLARACION DE INDEPENDENCIA a favor del software libre.

Por algo Florian Schiefel (líder comunitario del proyecto LiMux) expuso:

“Contrariamente a lo que podría creerse, la reducción de costos no fue la razón primordial del proyecto, la motivación fue la Independencia, durante todo el período del proyecto no esperabamos ahorrar dinero siquiera, pero queríamos ser capaces de decidir *por nosotros mismos* cómo queríamos gastar nuestro presupuesto de IT a largo plazo”

Incluso llegaron a sacar una lotería, para ayudar al financiamiento del proyecto …

No es cosa de técnica

Una migración no es un proceso técnico, no se puede tomar, quitar un software y poner otro, o decir con una ley “esto es así, porque yo digo”, es un proyecto de cambio, de abrir mentes, de hacer que las personas entiendan y esten a gusto y agradadas con el cambio (y esto es socialización, no politiquería); Oracle se puede migrar a postgreSQL, no porque la licencia de uno le cueste al Estado 100 mil US$ y la otra tenga costo cero, se puede migrar porque los cien mil los invertirás en fomentar el cambio, el ecosistema de soporte (en Munich el 80% del soporte viene de empresas medianas y pequeñas cooperativas y freelancers creados alrededor del propio proyecto), en pagar “todas esas mejoras que sueñas” y en demostrar que esos 100.000 US$ sirven *para algo más* que comprarle otro Yate a Larry Ellison (dueño de Oracle); podría describir todas las formas técnicas de clusterización y hardware en las que invertiría esos 100 mil US$ para que postgreSQL revolcara por el suelo a Oracle, pero no es la idea ni el fin, el cambio principal viene del hecho de estar libres de patentes, brechas (muchas de ellas, oscuras) en los sistemas, libres de impuestos y “royalties” y tener la libertad de decidir “qué vas a hacer con tu presupuesto”, y en el lado más general, asumir que la LIBERTAD es un VALOR y no UN COSTO.

[Linux] Instalación rápida de un DNS caché

Con el advenimiento de los problemas DNS o los fallos de resolución (el sábado pasado DNS1.CANTV.NET dejó de resolver por un par de horas), además como una buena práctica de gestión de tu plataforma, es importante contar con un servidor DNS caché.

En este caso, instalaremos dnsmasq, tanto para Debian como para Fedora/CentOS.

La razón de este artículo fue un compañero que me llamó presuroso, “tenemos problemas con el correo!, auxilio!, se está quedando represado y están fallando las resoluciones DNS”, rápidamente le envié mi guía de DNS caché y solventó su problema, ¿por qué no solventarle el problema a los demás?, aquí la publico.

DNSmasq es un servicio muy sencillo y fácil de configurar, con muchas guías disponibles, este simplemente es una más :)

Preámbulo

Un DNS caché es una herramienta que se encarga de hacer las consultas DNS contra servidores externos y almacenarlas el tiempo previsto por el REFRESH de la zona, así, nos ahorramos un montón de tráfico “hacia afuera” a preguntarle a DNS de Google o de CANTV (o el que sea tu ISP).

Para el trabajo utilizaremos una aplicación muy ligera, conocida como DNSmasq, acá las instrucciones para instalarlo.

Instalación

Para instalar en Debian GNU/Linux debemos ejecutar:

aptitude install dnsmasq

Para Fedora, debemos ejecutar:

yum install dnsmasq

Para CentOS, tenemos qué, previamente, añadir los repositorios EPEL para descargar de allí dnsmasq

rpm -Uvh http://download.fedoraproject.org/pub/epel/6/i386/epel-release-6-8.noarch.rpm

Y luego si ejecutamos la instalación

yum install dnsmasq

Luego de esto, aseguraremos la instalación, para ello, debemos crear un usuario y grupo (por defecto, dnsmasq se instala y correo como root ó como nobody):

groupadd -r dnsmasq
useradd -r -g dnsmasq dnsmasq

A partir de acá, pasamos a configurar el servicio.

Configuración de DNSmasq

Primero, guardamos el archivo de configuración “original” (por si acaso!):

cp /etc/dnsmasq.conf /etc/dnsmasq.conf.orig

Y creamos uno con el siguiente contenido:

archivo: /etc/dnsmasq.conf
#
# Configuration file for dnsmasq acting as a caching nameserver.
#
# Format is one option per line, legal options are the same
# as the long options legal on the command line. See
# "/usr/sbin/dnsmasq --help" or "man 8 dnsmasq" for details.
#
# Updated versions of this configuration file may be available at:
#
#   http://www.g-loaded.eu/2010/09/18/caching-nameserver-using-dnsmasq/
#
#
# Basic server configuration
#
listen-address=127.0.0.1
port=53
bind-interfaces
user=dnsmasq
group=dnsmasq
pid-file=/var/run/dnsmasq.pid
## Logging #
log-facility=/var/log/dnsmasq.log
log-queries
## Name resolution options #
domain-needed
bogus-priv
dns-forward-max=150
cache-size=1000
neg-ttl=3600
resolv-file=/etc/resolv.dnsmasq
no-poll

NOTA: si queremos evitar que dnsmasq lea las entradas del /etc/hosts simplemente agregamos “no-hosts” luego de “no-poll”.

Este archivo simplemente define un dnsmasq como “caching nameserver” con un tamaño de caché de 1000 entradas y un caché negativo (tiempo que se guarda una resolución NXDOMAIN como válida) de una hora.

Guardamos luego el archivo y le damos los privilegios necesarios:

chown dnsmasq.dnsmasq /etc/dnsmasq.conf
chmod 0640 /etc/dnsmasq.conf

Creando el resolv para DNSmasq

El archivo “/etc/resolv.conf” apunta al DNS que debería resolver nuestras direcciones, y este debe ser, obviamente, “127.0.0.1”, o sea, nuestro propio dnscaché.

archivo: /etc/resolv.conf
nameserver 127.0.0.1

Sin embargo, dnsmasq cuenta con su propio archivo, donde se definen los servidores DNS que consultará recursivamente por direcciones:

archivo: /etc/resolv.dnsmasq
nameserver 8.8.8.8 #DNS de GOOGLE, mi favorito
nameserver [Primer DNS de tu ISP]
nameserver [segundo DNS de tu ISP]

Gestionando el log

Hemos creado un log, para gestionar los mensajes de dnsmasq (y la opción “log-queries” creará una bitácora con todas las direcciones que nuestros “usuarios” consultan), pero este log no es el “oficial”, así que hay que incorporarlo al logrotate:

Creamos el archivo con el siguiente contenido:

archivo:  /etc/logrotate.d/dnsmasq

/var/log/dnsmasq.log {
monthly
missingok
notifempty
delaycompress
sharedscripts
postrotate
[ ! -f /var/run/dnsmasq.pid ] || kill -USR2 `cat /var/run/dnsmasq.pid`
endscript
create 0640 dnsmasq dnsmasq
}

Y aplicamos la regla de logrotate ejecutando:

/usr/sbin/logrotate  /etc/logrotate.conf -f

Ya con esto, sólo nos hace falta, iniciar el servicio.

Arranque y parada

Para poder iniciar al arranque del sistema, en Debian ejecutan:

update-rc.d dnsmasq defaults

Y en Fedora/centOS:

chkconfig dnsmasq on

Para luego, iniciar el servicio con:

service dnsmasq start

Con lo cual ya está en operación tu caché de DNS, ¿por qué no probarlo?

Pruebas

Lo más ideal, es realizar una serie de consultas, para determinar su velocidad, para ello utilizamos la herramienta “dig”

Por ejemplo, una consulta sobre un dominio .gob.ve a google (8.8.8.8) le toma:

$ dig @8.8.8.8 -t A localhost.saren.gob.ve
;; Query time: 198 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Fri Apr 26 03:06:12 2013
;; MSG SIZE rcvd: 56

Y a CANTV.NET

;; Query time: 105 msec
;; SERVER: 200.44.32.10#53(200.44.32.10)
;; WHEN: Fri Apr 26 03:39:59 2013
;; MSG SIZE rcvd: 56

Pero consultando 2 veces (una para que resuelva, la segunda ya responde desde caché) a nuestro servidor DNS:

$dig @127.0.0.1 -t A localhost.saren.gob.ve
;; Query time: 2 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Fri Apr 26 03:42:29 2013
;; MSG SIZE rcvd: 56

Lo cual no solo es una mejora significativa en velocidad, sino una además, un ahorro notable de ancho de banda de resoluciones DNS innecesarias.

[Linux-DNS] Vistas DNS e INCLUDE: dos increíbles aliados

Este artículo debería llamarse “El DNS para los pobres”, se trata de una situación que realmente es “bastante común”, como lo es, que un servidor “resolver recursivo” gestione varios DNS de una misma institución y que, además, resuelva direcciones “internas” y “externas” en un mismo ambiente.

Un amigo fué quien me hizo la consulta, me preguntó ¿cómo hago para que el servidor DNS, resuelva direcciones internas si está en mi red local, pero externas, si me consultan desde afuera? y además,  “solo tengo una máquina virtual y administro unas 5 cooperativas, ¿cómo hago para *facilitar* la administración de mi DNS?”, si tienes una situación similar con tus DNS, deberías leer el artículo.

La situación

Mi amigo tiene un servidor DNS en una máquina virtual, resuelve las direcciones “externas” (es autoritativo de su dominio) pero también las internas, además, debe gestionar los dominios de varias cooperativas, todas ellas comparten un único servidor Web, luego de explicarle me dijo “¿por qué no publicas esa ayuda?” y pues, aquí está.

Todas las cooperativas comparten servidor DNS y Servidor de correo y existen una serie de “hosts internos” (como el antivirus) comunes dentro del datacenter para servirle a las 5 cooperativas que comparten el edificio.

¿Cómo simplificar al máximo la administración?

Definir mis “amigos”

Lo primero que debemos hacer es crear en el archivo “named.conf” (si se encuentran usando Debian, es preferible hacerlo en “/etc/bind/named.conf.options”) una “ACL” (Access Control List) definiendo “quien” es mi red interna.

En este caso, he agregado lo siguiente:

archivo: /etc/named.conf.options
// definicion de mi red DMZ
acl internas {
 127.0.0.0/8;
 192.168.20.0/24;
 localnets;
};

Donde 192.168.20.0/24 constituye la sub-red de nuestra DMZ, además, en localnets (otra ACL) incorporé la lista de sub-nets dentro de la empresa:

// definicion de mi red interna
acl localnets {
 172.16.20.0/24;
 192.168.1.0/24;
};

De esta manera, cada vez que se incorpore una nueva sub-red, simplemente la agrego a “localnets” y recargo el servidor.

Interna y Externa

Las vistas son la manera de definir qué verá la red de internas y que verán los usuarios “externos”, para ello, incorporo al “named.conf” la definición de las vistas, la “interna” y la “externa”, de la siguiente manera:

view "interna" {
 match-clients { internal; };
 additional-from-auth yes; 
 additional-from-cache yes;
zone "." {
 type hint;
 file "/etc/bind/db.root";
};
zone "localhost" {
 type master;
 file "/etc/bind/db.local";
};
zone "127.in-addr.arpa" {
 type master;
 file "/etc/bind/db.127";
};
zone "0.in-addr.arpa" {
 type master;
 file "/etc/bind/db.0";
};
zone "255.in-addr.arpa" {
 type master;
 file "/etc/bind/db.255";
};
zone "coopera.net" {
 type master;
 file "/etc/bind/zonas/internas/coopera.net.zone";
 allow-query { internas; };
};
zone "servicioscoopera.net" {
 type master;
 file "/etc/bind/zonas/internas/servicioscoopera.net.zone";
 allow-query { internas; };
};
zone "20.16.172.in-addr.arpa" {
 type master;
 file "/etc/bind/zonas/internas/20.16.172.zone";
 allow-query { internas; };
};
};

La vista “interna”, incorpora la zona “punto”, mis zonas internas, además, se permite consultarlas únicamente a personas que hagan “match” con clientes que estén en las subredes especificadas en la acl “internas”, evitando así que cualquier cliente obtenga “por error” una IP interna.

Por el contrario, la vista “externa” permite que cualquiera (excepto redes “internas”) la consulte:

view "external" {
 match-clients { !internal; any; };
 recursion no;
 zone "servicioscoopera.net" {
   type master;
   file "/etc/bind/zonas/servicioscoopera.net.zone";
   allow-query { any; };
 };
 zone "coopera.net" {
   type master;
   file "/etc/bind/zones/coopera.net.zone";
   allow-query { any; };
 };
};

Las zonas internas serán definidas en la carpeta “/etc/bind/zonas/internas” y las externas en “/etc/bind/zonas”.

Definiendo y compartiendo Zonas

Para simplificar, debemos decidir cual dominio será el autoritativo para el resto (en nuestro caso, el falso dominio “coopera.net” será el autoritativo para el resto, y se realizarán los cambios en el NIC registrar para que “dns1.coopera.net” y “dns2.coopera.net” sean los autoritativos para el resto de las zonas.

Así, el resto de valores (MX, HINFO, puntero A @ y WWW, y NS) serán compartidos por el resto de las zonas.

La zona primaria de COOPERA.NET quedará de la siguiente manera:

;
; coopera.net
;
$ORIGIN coopera.net.
$TTL    86400
@       IN      SOA     dns1.coopera.net. hostmaster.coopera.net. (
                         2011051701     ; Serial
                         86400          ; Refresh
                          7200          ; Retry
                        2419200         ; Expire
                         60480 )       ; Negative Cache TTL
; definicion de Nameservers
       IN      NS      dns1.coopera.net.
       IN      NS      dns2.coopera.net.
; punteros A de los DNS
dns1.coopera.net. IN A 144.76.25.227
dns2.coopera.net. IN A 144.76.25.228
; puntero de la zona
@       IN      A       144.76.25.228
www     IN      A       144.76.25.228
; informacion de hardware de este DNS
        IN      HINFO   VM-XEN "Debian Wheezy 7.0"
; puntero de intercambio de correo
        IN      MX      5    correo.coopera.net.
correo IN A 144.76.25.229

En este caso, lo más básico de la zona fué definido, NS (nameservers), puntero MX (Mail Exchange) e incluso WWW, pero, ¿qué les parece si usamos “INCLUDE” para compartir la información común de esta zona?

Compartiendo información de Zona

Imaginen este caso, el día de mañana cambio de servidor de correo, o en su defecto, incorporo otro servidor adicional, o cambio de proveedor para cambiar los DNS, si tengo 5 zonas, tendría que cambiar 5 archivos para cambiar las IPs, agregar un segundo servidor web ó un nuevo servidor de correo, ¿cómo simplificarlo?, en nuestra ayuda viene “INCLUDE”.

Si utilizamos “INCLUDE” (parte de bind9) podemos separar el archivo en “partes” que incluiremos después, en este caso, utilizando INCLUDE, la zona queda así:

archivo: /etc/bind/zonas/coopera.net.zone
;;
;; coopera.net
;;
$ORIGIN coopera.net.
$TTL    86400
@       IN      SOA     dns1.coopera.net. hostmaster.coopera.net. (
                         2011051701     ; Serial YYYYMMDDXX
                         86400          ; Refresh
                          7200          ; Retry
                        2419200         ; Expire
                         60480 )       ; Negative Cache TTL
; definicion de Nameservers
$INCLUDE /etc/bind/zonas/ns.coopera
; puntero de la zona
$INCLUDE /etc/bind/zonas/www.coopera
; puntero de intercambio de correo
$INCLUDE /etc/bind/zonas/mx.coopera
; informacion del administrador del dominio
$INCLUDE /etc/bind/zonas/adm.coopera

Si nos damos cuenta, se ha “simplificado” bastante el archivo, creando 3 archivos “aparte” para NS, WWW y MX y uno adicional para RP (opcional)

archivo: /etc/bind/zonas/ns.coopera
       IN      NS      dns1.coopera.net.
       IN      NS      dns2.coopera.net.
; punteros A de los DNS
dns1 IN A 144.76.25.227
dns2 IN A 144.76.25.228
archivo: /etc/bind/zonas/www.coopera
@       IN      A       144.76.25.228
www     IN      A       144.76.25.228
; informacion de hardware de este DNS
IN      HINFO   VM-XEN "Debian Wheezy 7.0"
archivo: /etc/bind/zonas/mx.coopera
        IN      MX      5    correo
correo IN A 144.76.25.229
archivo: /etc/bind/zonas/adm.coopera
        IN      RP      jesuslara
jesuslara IN TXT        "Jesus Lara, (58) 555-5555"
Se preguntarán ¿y cómo funciona eso?, la declaración de $ORIGIN al inicio de la zona primaria, hace qué en todos los archivos INCLUIDOS, la zona sea utilizada para “reemplazar” el dominio, entonces, en el archivo “mx.coopera”, si en $ORIGIN dice “coopera.net” eso se traducirá en “correo.coopera.net”, si estás en la zona “servicioscoopera.net” entonces reemplazará por “correo.servicioscoopera.net” y así suscesivamente.
Como verán, si cambio las IPs de los NS en el archivo “ns.coopera”, se cambiará en absolutamente TODAS las zonas que incluyan este archivo.

Entonces, crear una nueva zona, será tan sencillo como, copiar el archivo de zona COOPERA.NET.ZONE y reemplazar el dominio “coopera.net” por el que corresponda, si usan VIM esto es tan fácil como abrir el archivo y escribir:

:%s/coopera.net/servicioscoopera.net/g

(NOTA: se lee “dos puntos”, luego %s (sustitución), /{lo que se quiere reemplazar}/{reemplazo}/g de manera “global”)

¿Y el serial de la zona?, si usan VIM, pueden “reemplazar” el serial de la zona “original” con:

:%s/\<\d\{10}/\=strftime("%Y%m%d00")/

Esto, tomará el primer grupo de 10 dígitos y los reemplazará con la fecha actual, seguida de “00” (puede cambiar ese número, por un incremental por cada zona).

Conclusiones

La zona interna serían los mismos archivos, pero obviamente, respondiendo a IPs de la zona interna (e incorporando, por ejemplo, una lista de hosts donde se declaren punteros A comunes, como “antivirus” o “directorio”), la administración se ha simplificado al máximo y por ejemplo, agregar un nuevo servidor MX a TODAS las zonas declaradas, pasa por simplemente editar UN SOLO ARCHIVO (mx.coopera) y se cambiarán TODAS las zonas, quedando únicamente el cambio del serial de todas ellas y como estamos en LINUX, esto es tan fácil como ejecutar “SED”:

sed -i 's/20[0-1][0-9]\{7\}/'`date +%Y%m%d%I`'/g' /etc/bind/zonas/*.zone

Esto, cambiará en todos los archivos “.zone” el serial existente, por la fecha actual, preservando el serial, solamente quedaría ejecutar:

rndc reload

Y todas las zonas se verán cambiadas, ¿fácil, no? …

Recordando el hecho de ver DNS “oficiales” tan mal configurados (por allí vi uno de una institución pública que tenía un puntero que resolvía como dirección “127.0.0.1” (there is no place like localhost!) y otras donde el hostname del SOA no correspondía a ningún servidor, creo que comenzar con artículos que ayudan a la mejor configuración de nuestros DNS es lo mejor para apoyar …

[Linux] Usando GNU “screen”

Me encontraba dándole una inducción remota de cómo instalar openLDAP y Samba a un compañero, cuando este se encontró con un problema, luego de múltiples *maromas y esoterismos* (el amigo estaba en una máquina Windows) que si Teamviewer, que si Skype compartiendo pantalla, le dije “mira, dame acceso por tu IP pública vía SSH”, y me dijo “pero yo quiero ver lo que haces” …

Dame un minuto, déjame enseñarte *screen*, y de allí surge este artículo.

GNU Screen

Screen es una herramienta extraordinariamente útil, nos permite ejecutar múltiples cónsolas que pueden ser minimizadas y re-adjuntadas a voluntad, compartidas, guardadas, divididas y un largo etcétera de opciones.

GNU Screen es una de mis herramientas favoritas para trabajo en servidores (sobre todo, cuando debo dejar haciendo trabajo en el servidor), sin embargo, he notado lo poco que algunos conocen esta herramienta.

Por la sugerencia del amigo, que debía hacer una guía de Screen en español, es que nace este artículo.

Entendiendo SCREEN

En *screen* se manejan 3 conceptos básicos, la “sesión“, es un área de trabajo, que se crea cuando ejecutas el comando screen.

Una ventana, es cónsola shell abierta dentro de una sesión de screen, una sesión de screen puede contener múltiples ventanas.

Una región, es una división, realizada a una ventana, que dentro contiene otra ventana, uno puede dividir una sesión de screen en 2 o más partes, horizontal o verticalmente y en cada split (porción de una región) desplegar una ventana.

Instalar SCREEN

En algunas distribuciones screen ya viene por defecto instalado, en aquellas donde no lo estuviera, con ejecutar:

apt-get install screen

ó

yum install screen

Será más que suficiente.

Crear una sesión de screen

Con simplemente escribir:

screen

se creará una sesión screen.

Crear una sesión de screen con nombre

screen -S [nombre]

Y entrarás en una sesión de screen con el nombre indicado (nota: si se tienen muchísimas sesiones de screen activas, es muy útil identificarlas por nombre).

Operaciones con screens

Todas las operaciones en SCREEN se activan con la secuencia CTRL+a seguida de alguna letra y/o combinación de letras (presionas tecla CONTROL y la letra a, luego sueltas y presionas la letra siguiente).

Ejemplo:

CTRL+a K : presionar CTRL+a y luego K, matará un programa dentro de una screen.

Screen también admite “comandos”, los comandos se escriben luego de escribir “:” (dos puntos), ejemplo:

CTRL+a “:multiuser off”, detiene el multi-usuario de una sesión.

Dettaching, attaching and re-attaching

Una de las cosas más útiles de SCREEN es la posibilidad de ejecutar un comando muy largo (ejemplo, un rsync) y dejarlo ejecutando dentro de una cónsola y luego minimizar la misma y re-conectarse luego.

* “Minimizar” (detach) una cónsola screen:

CTRL+a d nos permitirá minimizar una cónsola.

Para retornar a la cónsola escribimos:

screen -r

De existir más de una cónsola “minimizada”, veremos un listado como este:

# screen -r
There is a screen on:
4870.pts-4.lexotanil (Detached)
4638.pts-1.lexotanil (Detached)
19936.pts-1.lexotanil (18/02/13 12:46:38) (Attached)

Vemos 2 cónsolas minimizadas (Detached) y una abierta (Attached).

De existir una cónsola múlti-usuario, esta se verá:

19936.pts-1.lexotanil (18/02/13 12:46:38) (Multi, attached)

 Hablaremos de ellas más tarde.

Crear “ventanas” dentro de una screen

Cuando estén en una sesión de “screen” y desean crear una “ventana”, ejecuten:

CTRL+a y luego “c” (c:create), esto habilitará otra ventana.

Para cambiar entre ventanas:

CTRL+a entonces números del 0 al 9: cambiar a la ventana según su ordinal (posición)
CTRL+a entonces “n”: “next window”, próxima ventana
CTRL+a entonces ” (comillas dobles) (Mayúsculas-2): Una lista de todas las ventanas creadas

Esto retorna una lista muy parecida a esto:

Num Name Flags
0       bash      $
1       bash      $
2       bash      $

Esta lista se puede “navegar” (flechas arriba y abajo) y ENTER para seleccionar una ventana.

Renombrar ventanas:

Para darle nombre a una “ventana”:

CTRL+a entonces Mayúsculas+a: Aparece un mensaje debajo solicitando el nombre de la screen (en Debian, por defecto “bash”):

Set window’s title to: bash

Borren la palabra “bash” y pongan el nombre que deseen, con CTRL+a+SHIFT+2 verán:

Num Name Flags

0 prueba $
1 bash $
2 test

El nombre correspondiente de la ventana (muy útil para saber de qué se trata cada ventana).

Dividir en regiones

Se puede dividir una ventana en varias regiones, cada región puede tener el foco de una ventana de screen diferente.

CRTL+a SHIFT-s: permite dividir una screen en dos regiones (ver imagen)

screen-split

Luego, podemos cambiar el foco a la nueva región con:

CTRL+a y TAB (tabulación): moverá el foco a la región siguiente

Al estar en esta región podemos realizar las siguientes operaciones:

CTRL+a SHIFT-C: Crear una nueva ventana en la región
CTRL+a n: nos mueve a la ventana actual (la que está arriba), podemos igual cambiar a las diferentes ventanas ya  existentes (ver imagen)

screen-split2

Para cerrar una región, simplemente se ejecuta:

CTRL+a SHIFT-x : cierra la región actual
CTRL+a SHIFT+q : al contrario, cierra todas las regiones, salvo la actual

Pantallas multi-usuario

Una de las ventajas de usar screens, es que una cónsola pueda ser operada por varios usuarios a la vez, es una de las cosas que más uno realiza y de las qué pocos novatos se enteran.

Crear una sesión SCREEN multi-usuario

screen -S prueba

Al tener la sesión screen activa, activar la cónsola de comandos (CTRL+a y luego presionar dos puntos “:” para escribir comandos de screen)

* Activar el modo multi-usuario:

CTRL+a y escribir “:multiuser on”

En este momento, la sesión puede ser accedida por múltiples personas, pero primero, debemos autorizarlos.

* Conectarse a una cónsola multiusuario:

screen -x [nombre de la screen]

ó

screen -r [PID de la sesión]

* Autorización de usuarios

CTRL+a “:acladd [lista de usuarios]”

La lista de usuarios puede ser uno o varios nombres de usuario, separados por comas:

ejemplo:

CTRL+a ":acladd jesuslara,soporte"

El usuario que creó la sesión de screen, más los usuarios “jesuslara” y “soporte” tienen derecho a acceder a la sesión screen.

* Permisos en la cónsola screen multi-usuario:

La utilidad de las cónsolas multi-usuario es que permiten a algunos trabajar y otros “ver” lo que uno está realizando, los permisos son w:write, r:read y x:execution con los valores “+” (garantizar) y “-” (revocar), luego de los permisos viene el número de la ventana donde recibirá los permisos (el símbolo “#” indica “todas las ventanas”).

ejemplo:

CTRL+a :aclchg soporte -w “#”

El usuario soporte queda sin permisos de escritura en todas las cónsolas screen abiertas.
* Ver los usuarios conectados a una cónsola screen
CTRL+a SHIFT-“+” (CTRL+a “*”)

Retorna la lista de usuarios conectados en una cónsola screen..

Ejemplo de lista de usuarios conectados:

term-type size user interface window Perms
———- ——- ———- —————– ———- —–
xterm 85×25 root@/dev/pts/1 nb 0(prueba) rwx
 

Mensaje a todas las ventanas activas

Podemos enviar un mensaje a todas las ventanas activas de una sesión usando el comando “:wall”

CTRL+a “:wall [mensaje]”

Envía el mensaje a todas las ventanas de la sesión conectadas.

Conclusiones

SCREEN es una herramienta poderosa, que nos permite trabajar de manera cooperativa y colaborativa con cónsolas activas en servidores, sin tener que recurrir a “maromas” cómo pantallas compartidas de Skype, Teamviewer ú otras soluciones “resource-hungry”, algo tan sencillo como SSH y una cónsola SCREEN compartida, nos permite operar con confianza contra nuestros servidores Linux, macOSX/BSD; se puede incluso hacer trucos cómo que ssh-agent genere una screen automáticamente por cada sesión remota SSH que se genere en el servidor, o ejecutar:

CTRL+a y luego SHIFT+H: permite guardar el historial de comandos realizados por una ventana screen.

Espero que el pana @terracenter (quien pidió esta guía inicialmente) y el resto de mis lectores le saquen el provecho necesario, si no conocían screen, espero lo usen, y si ya lo conocían, espero haberles brindado algunos trucos útiles.

Happy Hacking! and screening! ;)

[Android] Actualizando HTC Desire a Android Jelly Bean (… y II)

Realmente he probado bastantes ROM, sin embargo, aquellas que funcionen realmente rápido son las que han llamado mi atención, entre ellas:

De todas ellas me ha parecido la más rápida VJ Cyanogenmod JB, además de ser la más moderna (Android Jellybean 4.1), es la que se ha comportado más rápida, estable y fluida en el teléfono.

Configuración previa

Debemos configurar la memoria SD para que sea nuestro almacén de datos, para ello debemos crear 3 particiones:

1.- Partición con el resto de los datos, en formato FAT32, llamada HTC
2.- una partición primaria en EXT4 de al menos 1GB, llamada sd-ext
3.- opcionalmente, una SWAP de 256MB

NOTA: utilizar una memoria SD de gran velocidad, por lo menos una SD class 4 (512k) y de un fabricante reconocido, en mi caso compré una microSDHC de 16GB Samsung Class 6, quedó formateada así:

  1. 14 GB – Datos
  2. 2 GB – sd-ext
  3. 256MB – SWAP

Descargamos desde la página del foro el ROM de la misma (no descarguen Gapps, ya no es necesario) y descargan superwipe.

Copian el archivo CM10_VJ_4.1.2_v3.0.zip y SuperWipe-Auto-Reboot.zip a la memoria SD (partición de datos que llamamos HTC) y apagan el equipo.

Instalación:

Debemos encenderlo en modo “recovery”, para ello, presionan VOLUMEN arriba+VOLUMEN abajo juntos y el botón POWER por 7 segundos.

Entraran a la pantalla principal de HBOOT, esperaran unos segundos, se moverán con las teclas de volumen hasta RECOVERY y presionarán POWER, entrarán en el modo de recuperación.

Nota: en el CWM Recovery, navegan con el trackball (botón central de navegación abajo) suavemente desplazando arriba y abajo, al presionarlo, seleccionan.

Limpieza previa

Para evitar cualquier “confusión” es ideal realizar una limpieza “general” del dispositivo, para ello:

* seleccionan la opción “Wipe Data/factory reset”

* en “advanced” seleccionan “Wipe dalvik cache”

* En “mounts and storage” seleccionan “format /system”

Instalación

Seleccionan “install zip from sdcard” y luego “select zip from sdcard”, allí, seleccionarán “SuperWipe-Auto-Reboot.zip” y este simplemente terminará de limpiar el teléfono y reiniciará el mismo hasta el recovery.

luego, instalaremos el otro ZIP, que es la ROM (CM10_VJ_4.1.2_v3.0.zip) esto es mucho más fácil, pues no requiere ninguna selección ni posee “Aroma Installer” como otras ROM, simplemente formatea, se copia y listo!.

Al finalizar, por favor, reinicien el equipo.

– Al encender:

Procederemos a definir el idioma (en mi caso, prefiero “Español – Estados Unidos”) y la configuración de la cuenta Google.

Por último, vamos a configurar algunas cosas.

Rendimiento

Nos vamos a Configuración > Rendimiento y luego a la opción “procesador”:

En la opción “Patrones CPU” seleccionen “smartAssv2″ y marcan la opción “establecer al iniciar”.

Luego, en planificador de E/S definen “BFQ” y también “establecer al iniciar”.

En Memoria: habilitamos KSM (Memoria compartida).

Y reiniciamos el equipo.

Por último, activamos A2SD.

A2SD

Permite mover las aplicaciones a la memoria SD

Buscamos en las aplicaciones a “Terminal emulator” y la ejecutamos: allí ejecutamos lo siguiente:

# su
# a2sd install
✔ Found block device: /dev/block/mmcblk0p2
✔ Removing flag a2sd
✔ Removing flag ad2sd
✔ Removing flag dc2sd
✔ Setting flag a2sd
Would you also like to move DALVIK-CACHE?
You can later undo this with ‘nocachesd’ (y|n) Y
Would you also like to move APPDATA (/data/data)?
You can later undo this with ‘nodatasd’? (y|n) N
✔ Your apps will be moved to /sd-ext on reboot
Your phone needs to be rebooted
Reboot now? (y|n) Y
✔ Exiting Success

Van a contestar “Y”, “N” y “Y”.

El teléfono se reinicia y este optimizará y moverá las aplicaciones a la memoria SD.

Al finalizar

Cargar Play Store y actualizar las aplicaciones, tiene las gapps lite, así que deberán instalar gmail, g+ y el resto de aplicaciones gmail, desactivar el modo “desarrollador” y comenzar a disfrutar de tu teléfono HTC mejorado con Android Jelly Bean.

Notas finales

* Debo probar INT2EXT+ que permite una mejor gestión de la memoria SD y del espacio del teléfono, al pasar muchas cosas a la SD (tener más espacio para instalar aplicaciones).
* Instalar un DSPManager con Beats Audio (a ver que tal suena mi teléfono así).

Happy Hacking!

[Android] Actualizando HTC Desire en Linux (I)

Desde hace algún tiempo tengo un equipo HTC Desire (bravo) original de Digitel:

HTC Desire Bravo

HTC Desire (bravo)

Preámbulo y otras yerbas

El equipo ha sido fiel hasta donde más, le he comprado una batería de polímero extra-grande que me permite llevarlo encendido full-operativo por más de 2 días y le tengo una memoria microSD class6 SDHC para almacenamiento, fue uno de los primeros teléfonos en poseer un CPU ARM snapdragon de 1Ghz y a pesar de lo que digan, todavía le queda mucho por ofrecer.

Inicialmente viene con Android 2.2 Froyo, en el “boom” de los smartphones que vino después de Froyo (Samsung Galaxy S1, Motorola Milestone y Xperia Sony) pues HTC lanzó una carrera de teléfonos (entre ellos el HTC Hero y el HTC one) dejando abandonado en el camino a este guerrero, que jamás recibió actualización alguna vía OTA (Over-The-Air) de Android.

Ya he actualizado mi tablet Lenovo K1 hasta el cansancio (no he hecho un post, porque aún no he conocido a alguien *que no sea mi esposa* que tenga una Lenovo K1 en Venezuela); nunca me había atrevido a instalar algo más que no fueran actualizaciones al teléfono, mucha gente optó por abandonarlo, pero yo no!.

Actualizando desde GNU/Linux

En la mayoría de los casos la gente olvida que Android es Linux y mucha gente entusiasta de la plataforma desarrolla herramientas para interactuar con él solo para Windows, lo que dificulta mucho el realizar operaciones sobre él, sin embargo, este no es el caso.

¿Qué vamos a actualizar?

Hay 4 cosas que debemos actualizar antes de pensar en montarle una nueva ROM (versión modificada de Android) estas son:

* Radio: software que gestiona la comunicación con el radio del teléfono, la última versión mejora notablemente el consumo de energía en comunicaciones de datos 3G, además, es esta opción la que “libera las bandas” desbloqueando el teléfono para cualquier operadora (SIM-Lock).

* S-Off: Permite escribir en la ROM del equipo, desactivando las protecciones en la misma

* HBOOT: el sistema de arranque del HTC Boot, incluye el recovery y el fastboot (algo así como los modos de recuperación del teléfono, si algo llega a pasar mal, deberán entrar en modo “fastboot”).

* Root: root significa realmente “ganar SU”, es decir, ganar privilegios de super-usuario (como cualquier linux) por lo que ganas el control total sobre el equipo.

NOTA: Recuerda activar la depuración de USB (Ajustes -> Aplicaciones -> Desarrollo -> Depuración USB) y conectar el telefono al computador mediante su cable micro-USB.

Requerimientos:

Android Debug Bridge (ADB)

Hay muchas guías de cómo instalar ADB en Linux, yo simplemente me descargue la SDK de Android y luego colocando la carpeta “platform-tools” en el PATH, para así poder llamar a los comandos “adb” y “fastboot”.

Advertencia!

Este proceso es altamente técnico, pueden dejar el teléfono inservible (bricked, volverlo un ladrillo) o en un estado inconsistente, además, perderán TODOS los datos en él (recomiendo una aplicación como Titanium Backup y SMS backup&Restore para respaldar todos sus datos).

OJO!, no nos hacemos responsables en este blog por el daño o pérdida de equipos por impericia o mal uso de las herramientas, para conocer más, es mejor pasear un rato y leer por los foros de xda-developers.

– Actualizando la Radio

Para actualizar la radio he obtenido información de acá:

Foro: http://forum.xda-developers.com/showthread.php?t=687464
Y de este post: http://www.mofirouz.com/wordpress/2011/03/htc-desire-radios/

He extraído la información para descargar la última radio para mi HTC Desire (5.17.05.23)

He descargado este .zip y la he descomprimido (un archivo, llamado radio.img está dentro del teléfono)

http://www.mofirouz.com/ahp/?file=htcdesire/radios/32.56.00.32U_5.17.05.23.zip

* Conectamos vía USB el teléfono y reiniciamos en el bootloader:

adb reboot bootloader
* daemon not running. starting it now on port 5037
** daemon started successfully *

Revisamos que fastboot detecta nuestro teléfono:

fastboot devices
SH12GPL05338 fastboot

El valor inicial es el serial (n° de serie) del teléfono, que lo pueden verificar en una etiqueta que está detrás de la batería.

* Ejecutamos el proceso de volcado de la nueva radio:

fastboot flash radio /home/jesuslara/android/htc/32.56.00.32U_5.17.05.23/radio.img
sending ‘radio’ (26112 KB)…
OKAY [ 3.800s]
writing ‘radio’…
OKAY [ 29.446s]
finished. total time: 33.246s

Luego de finalizado el proceso, seleccionamos “POWER DOWN” (botones de volumen para navegar y POWER para seleccionar), apagamos el equipo y entramos “de nuevo” en modo fastboot (tecla BACK + tecla POWER juntas por 7 segundos hasta que se ponga la ventana en blanco).

Verificamos la versión de la radio: RADIO-5.17.05.23

Procedemos a cambiar el modo S-ON a S-OFF (posibilidad de escribir en la ROM del teléfono) con “revolutionary”.

– Permitiendo escribir la ROM (S-OFF)

* Se conectan a la siguiente página web: http://revolutionary.io/

En esta página, descargan la versión para Linux, es necesario que la descarguen de allí, ya que un asistente les generará el beta-key (una llave) que les permitirá ejecutar revolutionary.

Luego de descargada y generada la clave, es muy fácil, le dan privilegios de ejecución a revolutionary:

chmod +x revolutionary

Y lo ejecutan con el teléfono encendido y conectado al USB (recuerden la nota USB-Debugging activo):

* Verifiquen qué el teléfono está conectado:

adb devices
List of devices attached
SH12GPL05338 device

Al ejecutar:

./revolutionary
=============================================
| Revolutionary S-OFF & Recovery Tool 0.4pre4 |
=============================================
Brought to you by AlphaRev & unrEVOked.

Este procederá a apagar el S-ON del teléfono, te preguntará la beta-key y luego si deseas instalar ClockworkMod Recovery a lo que indicarás que si (necesario para instalar muchas otras cosas):

Do you want to download (Internet connection required) and flash ClockworkMod Recovery? [Y/n] Y
Downloading recovery for your phone (bravo)…
Downloading recovery for your phone (bravo)…Done.
Rebooting to fastboot…
Flashing recovery over fastboot…SUCCESS!

* Al finalizar, el teléfono quedará en fastboot e indicará arriba que tiene revolutionary y S-OFF, vamos a actualizar el HBOOT.

HTC-Desire-A8181-S-OFF-and-custom-recovery-installed

– Actualizando HBOOT

Para actualizar el HBOOT de nuestro HTC podemos hacer uso del listado de HBOOT disponble en la página web de AlphaRev: http://alpharev.nl/

Cada HBOOT distribuye el espacio de acuerdo a ciertos factores como disponibilidad de espacio para /system, caché o no caché y cantidad de espacio que queda para /data (datos internos de usuario); por ahora vamos a lanzar la actualización de HBOOT stock:

http://alpharev.nl/bravo_alphaspl.img

NOTA: revisen la ROM que deseen, algunas versiones de HBOOT (como CWM7) son necesarias para funcionar.

* Encendemos directamente en fastboot (botón “BACK” + botón “POWER” ó Volumen Arriba-Volumen Abajo-POWER, esperan 7 segundos y en la opción “FASTBOOT” presionan “POWER”).

* Ya en fastboot; ejecutamos:

fastboot flash hboot /home/jesuslara/android/htc/bravo_alphaspl.img
sending ‘hboot’ (512 KB)…
OKAY [ 0.089s]
writing ‘hboot’…
OKAY [ 0.137s]
finished. total time: 0.226s

* Reiniciamos el fastboot:

fastboot reboot-bootloader
rebooting into bootloader…
OKAY [ 0.162s]
finished. total time: 0.162s

* limpiamos la cache:

fastboot erase cache

Listo!, ya tenemos el equipo con HBOOT, ClockworkMod Recovery, S-OFF y Radio actualizada, ¿qué nos falta?, root y una buena ROM!.

– Rooting con S-OFF

Al contar con S-OFF y acceso vía ClockWorkMod al ROM del teléfono, ya podemos instalar superuser (http://downloads.androidsu.com/superuser/Superuser-3.0.7-efgh-signed.zip) en el teléfono, para ello simplemente descargamos superuser, lo copiamos a una memoria SD del teléfono y entramos en modo recovery del teléfono:

* Encender en recovery (Volumen Arriba-Volumen Abajo + POWER) esperar 7 segundos y con los botones de volumen seleccionar la opción RECOVERY y luego presionar POWER, entramos en modo recovery (que gracias al CWM Recovery se ve cómo esta imagen):

HTC-Desire-A8181-Revolutionary-CWM-v4.0.1.4

* Seleccionar “install zip from sdcard” (se puede usar el trackball central para navegar por el menú y hacer click)
* Seleccionar “choose zip from sdcard”
* Seleccionamos el archivo zip “Superuser-3.0.7-efgh-signed.zip”

Esperamos a que el proceso termine, presionamos botón “BACK” y luego “reboot system now”.

Y listo!, tenemos el teléfono desbloqueado, actualizada la radio, con root y con un recovery para instalar lo que necesitamos, ¿y qué necesitamos?, una BUENA ROM!, pero eso es parte de un segundo artículo!.

Happy Hacking!

Musicbrainz Picard: La forma útil de ordenar tu colección musical

¿Eres melómano?, ¿fanático de la música o de un artista?, ¿tienes una increíble cantidad de canciones con nombre “unknown artist – track 1″ y no sabes ni cómo se llama? …

Bueno, ¡MusicBrainz Picard es tú solución!.

La aplicación

Musicbrainz picard es una aplicación muy sencilla, diseñada por la gente de la página web de Musicbrainz, que no es más que una herramienta que se conecta a las colecciones musicales cargadas por los miles de usuarios contribuyentes (me incluyo) y permite re-etiquetar y re-nombrar nuestros archivos de música (ogg, mp3, flac, wma, etc) para mantenerlos ordenados.

Es una aplicación diseñada en QT4 y es compatible con Linux, Windows y macOSX.

Para instalarla en Debian (y derivados) simplemente ejecuten:

aptitude install picard

Obtendrán una interfaz como esta:

 

Luego de instalado y ejecutado, realizaremos nuestra primera mejora a un disco.

Utilizando Musicbrainz Picard

Utilizar Musicbrainz es bastante sencillo, basta con presionar el botón de la barra de herramientas “agregar archivo” ó “agregar carpeta” para permitir buscar el conjunto de archivos que deseamos corregir:

 

Hemos cargado un disco como ven, de Astor Piazzolla y Gary Burton (Libertango).

Veremos 2 opciones, “analizar” y “Buscar”, la diferencia entre “Analizar” y “Buscar” es clara:

* Analizar: buscará a partir del identificador único de canción (PUID) registrado en MusicBrainz, para ver si la canción está originalmente extraída de alguno de los albumes oficiales.

* Buscar: Extrae los metadatos (nombre de canción, artista, album y otra serie de metadatos) y hace una búsqueda directa en MusicBrainz, útil si tus canciones no fueron generadas a partir de un disco oficial.

Al terminar de buscar, MusicBrainz cuadrará las canciones con sus respectivos albumes:

Si en algún caso, queda alguna canción en el album que no es, o simplemente queda desagrupada (sin clasificar), podemos “arrastrar” la canción hacia la canción coincidente en el album que corresponde.

Arrastrando la canción “Jugband Blues” del disco “Echoes” de Pink Floyd para hacerla coincidir en el disco

 

Cuando presionamos “GUARDAR” este registrará la metadata de cada canción correctamente, además guardará un archivo llamado “cover.jpg” con el arte gráfico del disco (portada).

 

Vemos que además, luego de guardar, nuestras canciones han sido renombradas y re-ordenadas en la carpeta del disco, colocando un archivo “cover.jpg” en la raíz del mismo:

 

Ordenando a Pink Floyd

A veces ocurre, que al ser los umbrales de “coincidencia” muy altos, podría encontrar las mismas canciones en diferentes discos (o diferentes versiones del mismo disco); ejemplo, de Pink Floyd hay diversas versiones de “The Wall”, lo que debemos hacer es verificar la versión “exacta” (disquera, año de emisión y versión de emisión -* UK, US, DE, versión internacional, etc -*) y quedarnos con “esa versión” y pasar manualmente (arrastrando cada una) el resto de las canciones.

 

En este caso, hacemos la selección manual del disco, presionamos botón derecho del ratón sobre el disco con más coincidencias (el primero, “The Wall (7/26)”) y seleccionamos manualmente el disco:

En mi caso, las canciones son extraídas de la versión CD de 1994 (versión del disco original de 1979 “The Wall”) en su versión inglesa (GB: 2 discos CD de 13 canciones cada una editado por Harvest EMI Records);  al seleccionar este disco y volver a presionar “buscar”, y luego de hacer coincidir las canciones faltantes manualmente, guardamos y listo!, tenemos el disco correctamente etiquetado y hasta con su carátula original.

Música: cosas de mi generación

He realizado una segunda carga, esta vez del disco “The Ultimate Collection” del grupo “The Who”, tenemos igualmente que escoger la versión del disco:

 

Mi disco es la versión 2002 americana (US) con 21+14 canciones en dos CDs, cuando los discos vienen en colecciones de múltiples discos (cd1, cd2, etc) debemos cargar un plugin de MusicBrainz para mantener esta “separación” en discos:

 

Esto permite entre otras cosas “quitar” la palabra “disco 1″ o “disc 1″ de los títulos de las canciones, moviéndolas a una etiqueta separada (disc number); asi la canción se llamará “My Generation” y no “My Generation (disc 1)”.

Lo bueno de seleccionar el disco correcto, es que si quedaron canciones “sin encontrar coincidencia”, es muy probable que al seleccionar esas canciones “sin coincidencia” y volvemos a presionar “Buscar”, Picard podrá mejorar la coincidencia al saber a qué disco van:

Al hacer una segunda búsqueda, la mayoría (salvo 9) canciones pudieron ser identificadas y etiquetadas correctamente, corregimos las 9 canciones manualmente, guardamos y listo!.

Organizando discos con MusicBrainz Picard

Con MusicBrainz Picard no solamente podemos etiquetar y renombrar a partir de la información contenida en MusicBrainz y en cada archivo, tambien podremos realizar tareas como organizar y renombrar a partir de los nombres de fichero: de la forma %artista%/%album%/%tracknumber% %titulo% (claro, que esta expresión es personalizable).

Veamos un ejemplo:

Así está nuestro disco “El alma al aire” del cantante español “Alejandro Sanz”, es el típico “artist – track 1″; está mal etiquetado, así no se llama el álbum, las canciones no tienen nombre; veamos cómo podemos, primero, renombrar los archivos según el artista y el nombre de la carpeta como álbum:

Cargamos la carpeta “ALMA AL AIRE” que no se encuentra etiquetada, veámos como no se encuentran etiquetados los archivos:

Al cargar, seleccionamos el menú “Herramientas > Etiquetar desde de nombres de ficheros” y al presionar “Previsualización” veremos que nos queda de esta manera:

Y presionamos “Guardar” para que guarde estos simples cambios.

Luego, hacemos una búsqueda en la página web de MusicBrainz, para hacer coincidir la mayor cantidad de metadatos (discID, disquera, etc) con nuestro disco:

Hacemos clic en el disco “El alma al aire CD 10 tracks” para ver toda su información:

Luego, seleccionamos todas las 10 canciones, presionamos botón derecho del ratón y en el menú, seleccionamos “Detalles”, le agregamos todos los metadatos coincidentes a nuestro disco:

Ventana de metadatos del disco

Al presionar “Guardar”, le modificamos los metadatos al disco, si volvemos a presionar “Buscar” luego de esto, veremos como rápidamente nuestro disco queda asociado al disco “El alma al aire” de Alejandro Sanz, y veremos como en nuestro disco duro, los archivos han sido “renombrados” y perfectamente etiquetados.

En otro ejemplo, pasamos de esto (un disco mal ordenado de “Los Amigos Invisibles”):

A esto:

El disco “The New Sound of the Venezuelan Gozadera” de 1998, perfectamente etiquetado y con su carátula, con sólo organizar correctamente las etiquetas y luego buscar el disco con Picard.

Conclusiones

MusicBrainz Picard es la herramienta que todo melómano, fan de la música y coleccionista debe tener, permite organizar en carpetas y mover los archivos para mejorar las colecciones, incorporar etiquetas a discos y carátulas, es una herramienta que hace muy bien la tarea para la que fué diseñada, permitirnos tener una colección musical perfectamente etiquetada y ordenada.

Disfruten de su música ordenada con MusicBrainz Picard, ¡Adios a Unknown artist – Track 1!

 

 

 

 

[Linux] De las comparativas (benchmarks) y otras justificaciones

Introducción

En un comentario anterior, el compañero Piccoro, hace una remembranza de unas pruebas de rendimiento que hiciera hace ya mucho Sun Microsystems  (antes que la comprara Oracle Corp.) sobre sus conocidos equipos SunFire, estas pruebas de rendimiento (conocidas como las “SPECjAppServer2004″) realizadas en 2007, ahora no están al alcance del público (aunque pueden aún ser encontradas en mi dropbox) pero demuestran el rendimiento de una misma aplicación, optimizada en estos equipos para Oracle, postgreSQL y MySQL.

¿Qué descubrimos con esta prueba?, veamos!.

La prueba Java (antes que fuera de Oracle)

MySQL 5 fué instalado en un equipo con las siguientes características:

  • Sun Fire X4100 (2×285,4x2GB,2X73GB) (2)
  • Sun StorEdge 3320, 12x73GB, 1 RAID CONT
  • Single-Port PCI Ultra320 SCSI HBA

Costo de la Licencia: 0$
Costo de implantación : 59.260 US$
MySQL: 720 JOPS

PostgreSQL 8.2 fué instalado con estas características:

  • Server HP Integrity rx2660 1.6Ghz 18GB 4-core (2)
  • 12GB DDR2 memory pair
  • SAN Array 1000

Costo de la Licencia: PostgreSQL 8.2 (0 US$)
Costo: 70.701 US$
Puntaje: 778 JOPS

Y Oracle 10g fué instalado con las siguientes características (semejantes a PostgreSQL)

  • Server HP Integrity rx2660 1.6Ghz 18GB 4-core (2)
  • 12GB DDR2 memory pair
  • SAN Array 1000

Costo de implementación: 70.701 US$
Licencias: Oracle 10g Enterprise + Oracle App Server + Oracle Partition Option
Costo en Licencias: 120.000 US$
Puntaje: 874 JOPS

Las pruebas, aunque en el mismo hardware físico gana Oracle (por al menos unos 70 puntos), demuestran que necesitas gastar 200US$ por unidad adicional para poder implementar Oracle, es decir, que con el costo *únicamente* de las licencias Oracle podrías incorporar 2 nodos más al cluster postgreSQL; qué, manteniendo la proporción de crecimiento, implementar un único servidor Oracle a 874 JOPS cuesta lo mismo que implementar un cluster de 3 nodos postgreSQL (ejecutandose a un rendimiento de 2334 JOPS).-

¿Cierto o falso?, queda a criterio del lector, la EULA de Oracle prohibe terminantemente la realización de pruebas y publicación de resultados sin su autorización, so-pena de recibir acciones legales, pero como yo no hice el benchmark! ;)

pero revisemos otro benchmark.

Cuándo VMWare decidió no publicar “malos benchmarks”

En una aclaratoria en su blog, la gente de VMWare explica que la clausula de la EULA (End-User License Aggrement) donde se prohíbe terminantemente la publicación de benchmarks de su producto versus otros productos de virtualización, no es porque “ellos estén en contra de las pruebas”, sino que le “sugieren amablemente” a las empresas encargadas de hacerlas, a que optimicen su producto y sólo utilicen el hardware que a “ellos” les es más conveniente, ¿interesante, no?.

Hace ya algún tiempo, la gente de specs.org publicaron una comparativa entre VMware ESX, la solución de virtualización para datacenters, y Linux KVM sobre Red Hat 6.1, resumiendo la conclusión:

KVM: SPECvirt_sc2010 1820 @ 114 VMs

VMWare: SPECvirt_sc2010 2721 @ 168 VMs

114 máquinas virtuales versus 168 es bastante, ¿no?, 900 puntos de diferencia en cuánto a rendimiento, también, ¿verdad?, pero, veamos a los detalles:

Primero, el equipo “sugerido” por VMWare para la prueba:

CPU: Intel(R) Xeon(R) X7560
Velocidad: (MHz) 2266
Núcleos: 32 cores, 4 chips, 8 cores/chip, 2 threads/core

Y el equipo con Red Hat:

CPU: Intel Xeon E7-2870
Velocidad: (MHz) 2400
Núcleos: Cores 20 cores, 2 chips, 10 cores/chip, 2 threads/core

El último es un simple HP Proliant Generación 7 (a un costo de 16800US$), el primero es un equipo ensamblado “especificamente” para VMWare, por su partner Bull Novascale, el “Novascale Bullion” fué catalogado como “el equipo para datacenter x86 más rápido del mundo” en 2011 y tiene un costo de 25 mil dólares la unidad.

Si a eso le sumamos la licencia de VMWare ESXi (9200 dólares por cada 2 núcleos), la cosa quedaría *más o menos* así:

KVM: Red Hat Licencias (Server=6500$ + Virtualización=6700) = 13200$
Servidor: 16800$
Total: 30000 US$
Costo: 263 dólares por VM (máquina virtual)

VMWare: Licencia=9200$ x 16 cores = 147200US$
Servidor: 25000 US$
Total: 172200 US$
Costo:  1025 US$ por VM (máquina virtual)

Entonces, ¿dónde está el rendimiento y el abaratamiento de precios?, además, hagamos algo bastante “jocoso”, reemplacemos Red Hat por Debian Linux (que el valor de siu licencia es “0$” – se lee cero!-) y te darás cuenta que por el mismo precio de la implementación de VMWare en tu empresa podrías pagar 11 servidores Proliant con GNU/Linux, ¡En vez de un equipo, tendrías un datacenter!  donde podrías en promedio (y según las cifras de Debian) virtualizar 990 máquinas virtuales.

A mí, me enseñaron que 990 VMs > (se lee, “es mayor qué”) 168 VMs, ¿no creen?.

Saquen ustedes sus propias conclusiones.

Seguir

Recibe cada nueva publicación en tu buzón de correo electrónico.

Únete a otros 3.227 seguidores

A %d blogueros les gusta esto: