Archivo de la categoría: Linux

A veces, compilar paquetes es mi pasion, llegando al punto de parecer un usuario gentoo … aqui algunas ideas y ejemplos

[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!

Historia de un script

Siempre me gusta tener un repositorio Debian en un disco portable, una conexión decente en dónde vivo (Guanare) es inexistente y de igual manera en el resto de ciudades, es mejor instalar Debian rápidamente que tener que esperar 2 horas de descargas.

Sin embargo, actualizarlo es otra cosa muy distinta, debo contar con una conexión “decente” (por encima de los 200kB/s) o podría pasar días enteros esperando a que “sincronize”, a veces, los archivos quedan “truncados” o no se descargan correctamente (uso rsync y si un archivo no se descarga correctamente, salta al siguiente y ese queda en falla).

Entonces escribí este script (https://github.com/phenobarbital/check_debian_repository), que, aunque está en sus inicios, aplica la filosofía del IDM (Internet Download Manager) y de los Download Accelerators, para descubrir qué archivos faltan en un mirror Debian y descargarlos en paralelo.

Por qué haría algo así? y por qué nadie había hecho algo parecido?, bueno, cuando tu velocidad promedio de descarga es:

>f+++++++++ pool/main/libr/libreoffice/libreoffice-help-zh-tw_4.2.6-1~bpo70+1_all.deb
1.93M 46% 162.71kB/s 0:00:13

162kB/s (y estaba rápida, son las 4 am) mientras amigos en países incluso consideradores “tercer mundo” con El Salvador o Guatemala poseen conexiones de 5MBps ó 10MBps, yo me tengo que conformar con “viajar” a Barquisimeto y conectarme al ABA de CANTV de la casa de mi mamá qué cuando funciona “de maravilla” (como ahora, a las 4am) reporta que es de 1.2MBps (aunque pago por 2MBps). La cosa no es que la conexión “sea cara” es que literalmente no existe.

Entonces, uno termina haciendo cosas que solo sirven para países en condiciones como las nuestras, espero que alguien más, con la necesidad de tener un mirror Debian multi-arch sincronizado y que tenga una conexión pobre, le sirva este script.

Saludos.

[ Motorola Android ] Rescatando al soldado Atrix 4G

El ladrillo …

Me encontraba probando varias ROM en mi Motorola Atrix 4G, cuando de repente sucedió lo imprevisto, la última ROM decidió no arrancar y cuando quité la pila y la volví a colocar, el teléfono inició indicando:

Failed to boot: 1

Oh Dios!, un soft-brick!, bueno, no importa!, eso se arregla con una ROM oficial Stock, en mi caso tenía en mi disco la:

1FF-olympus-user-2.3.4-4.5.91-110625-release-keys-signed-ATT-US-GAS_NA_OLPSGBATTSPE_P011.sbf

Uso el cargador RSD y … Oh Dios!, Failed to boot otra vez y esta vez ni siquiera el fastboot funciona! …

Bueno, vamos a entrar en modo RSD Protocol, para ello:

  • Sacamos la batería
  • Presionamos “Volume UP” y a su vez “Volume DOWN”
  • Metemos la batería
  • Encendemos el equipo

E intento aplicar usando el RSD protocol (protocolo para meter binarios en la NAND de equipos Motorola) el SBF:

1FF-olympus-user-2.3.6-4.5.141-111212-release-keys-signed-ATT-US-GAS_NA_OLPSGBATTSPE_P012.sbf

Y ahora el equipo ni siquiera entra en modo RSD! …

Panic Mode on!, un Hard-Brick? …
Lo bueno es que si uso el procedimiento “de emergencia” del protocolo RSD/Fastboot de Motorola:

  • Sacamos la batería
  • Presionamos “Volume UP”
  • Metemos la batería
  • Conectamos el cable micro-USB

El equipo se encenderá automáticamente y la pantalla indicará:

Failed to boot: 1
PwrReason: USB_CABLE
Starting fastboot protocol support

Sin embargo es un fastboot inútil, no puedes leer nada y no puedes flashear nada … entonces?

Para colmo, comienza a fallar la batería y aparece en la ventana del teléfono:

“Battery to low to flash”

Los teléfonos Motorola, si no tienen sistema operativo, no cargan las baterías así estén conectadas a una fuente de poder; para algunos esto es un “hard-brick” a menos que cuenten con alguna batería Motorola cargada adicional (que no es mi caso).

Qué hacer?, ya lo verán …

Cable USB-Activo

En este caso necesitas energizar de manera “independiente” la batería, mientras dejas el cable micro-USB solamente para comunicación, entonces.

  • Picas un cable viejo USB
  • Cortas y pelas los cables Rojo y Negro, dejando de lado el blanco y el verde, como se ve en la foto

2012-03-05_19-45-00_368

  • Pegas el cable ROJO en el símbolo (+) de la batería
  • Pegas el cable NEGRO en el símbolo (-) de la batería
  • Los sostienes con una mínima cantidad de cinta adhesiva
  • Conectas el cable USB a una fuente de poder (Cargador USB de 5V al menos 300mA) o en su defecto, a un puerto libre de la PC
  • Conectas el cable micro-USB

Y listo! … el teléfono encenderá y el cable permitirá energizar la batería mientras por el micro-USB accedemos al “extraño Fastboot Motorola”

Reparando el Fastboot

Aunque diga Fastboot, el equipo no es detectado por fastboot, pero si es detectado aún por las herramientas RSD (RSD Protocol), tal como “sbf_flash” para Linux.

Entonces, he descargado sbf_flash tal como expliqué en artículo anterior, y he ejecutado el flash de la ROM de stock (tranquilos, no la vamos a usar):

./sbf_flash 1FF-olympus-user-2.3.4-4.5.91-110625-release-keys-signed-ATT-US-GAS_NA_OLPSGBATTSPE_P011.sbf

Posteriormente, para recuperar “el verdadero” fastboot, cargamos el sbf_fix como indiqué en artículo anterior:

./sbf_flash 4547-fix-try2.sbf

En este momento, ya podemos acceder al fastboot.

Recuperando el Recovery

Ya con el sbf aplicado, podemos apagar el equipo (simplemente quitando cable USB y batería) y entrar en modo Fastboot de la siguiente manera:

  • Sacar la batería (recordemos que aún está energizada por el cable USB-activo)
  • Presionar “Volume DOWN”
  • Encender el equipo (o conectar el cable micro-USB)
  • El teléfono dirá “Failed to boot 1 Fastboot”
  • Presionar “Volume UP”
  • El dispositivo indicará “Starting Fastboot protocol support”

Ya podemos acceder desde ADB Fastboot.

Borramos el recovery (o lo que quedaba de él)

fastboot erase recovery

Aplicamos el recovery (el que me funciona para Atrix es el que indiqué en mi viejo post)

fastboot flash recovery recovery-dark-green-atrix5.img

Ahora podemos entrar al recovery

Aplicando la nueva radio y preparando para ROM nueva

Para acceder la Recovery:

  • Sacar la batería (recordemos que aún está energizada por el cable USB-activo)
  • Presionar “Volume DOWN”
  • Encender el equipo (o conectar el cable micro-USB)
  • El teléfono dirá “Failed to boot 1 Fastboot”
  • Presionar “Volume DOWN” varias veces hasta que donde decía “fastboot” diga “Android Recovery”
  • Presionar “Volume UP”
  • El dispositivo indicará “Starting Android Recovery”

Aprovechando que recuperé el equipo, he decidido aplicarle una nueva radio, diferente a la de stock, dicen que “se calienta menos” con una ROM Jelly Bean, además es la radio de la versión 145 que tantos dolores de cabeza le dió a varios.

Dicha radio la descargué de acá:

http://forum.xda-developers.com/showthread.php?t=2101841&page=46

Luego de ello, aplicarla es simplemente usar la opción “install zip from sd card” del Recovery.

Luego:

  • Wipe cache Partition
  • Advanced – Wipe Dalvik Cache
  • Mounts and Storage – Format /system
  • Mounts and Storage – Format /osh

Prepara el sistema para recibir una nueva ROM.

… Y listo para una nueva ROM

Como lo indican en xda-developers “Mientras el teléfono encienda, jamás será un hard-brick”, cada fabricante tiene métodos diferentes que hay que conocer para lograr “revivir de entre los muertos” a sus equipos, en el caso de Motorola, el protocolo RSD.

En mi caso, luego de probar la “SuperLite”, AtrICS y Atrix-MROM (ICS), me he decantado por la Epinter-10.1 con Kernel 3.1 a ver que tal me va.

UPDATE: Evitar el calentamiento de la batería

La ROM epinter es famosa por “poner caliente” la batería del teléfono, pero está documentado un proceso fácil para evitarlo:

entrar en modo ADB

adb shell

Ejecutar su – (pasar a root)

su -

Ejecutar el remontaje de /system como lectura-escritura:

mount -o remount rw /system

Borrar el siguiente archivo:

rm /system/app/FastDormancy.apk

Y reiniciar el equipo.

Y gracias a los experimentados de XDA-Developers por ayudarme a rescatar mi Atrix 4G de la muerte! …

[iptables] Descargando listas negras con Shorewall

Una de las características más importantes que debe realizar un firewall hoy día es reaccionar ante atacantes y/o conjuntos de atacantes, uno de ellos son los firewalls que protegen servidores de correo.

Las RBL (Realtime Blackhole List) son listas negras en tiempo real, generadas por muchísimas empresas e instituciones (spamhaus, por ejemplo) y que nos permiten obtener un listado bastante grande de IPs y subnets que son vigiladas por SPAM.

Hoy voy a probar hacer 2 listas negras, una desde Spamhaus y otra, de las subredes chinas más comunes utilizadas por los hackers.

Preparando a Shorewall para listas negras

Shorewall posee un archivo llamado /etc/shorewall/blacklist, de no poseer ese archivo, no hay problema, ya que crearemos un script que lo generará.

Pero primero, debemos indicar que la disposición de las IPs y subredes dentro del archivo BLACKLIST sea DROP.

Para ello ejecutamos:

sed -i "s/^BLACKLIST_DISPOSITION=.*$/BLACKLIST_DISPOSITION=DROP/" /etc/shorewall/shorewall.conf

Y refrescamos shorewall.

shorewall refresh

Script para descargar listas negras

Ahora debemos crear un script, que se ejecute mensualmente y que se dedique a “llenar” el archivo blacklist con listas dinámicas de varios sitios:

  • DShield Blacklist
  • Spamhaus DRBL
  • OKEAN Chinese and Korean Spammers
  • Wizcrafts (russian botnets)
  • RBN: Russian Bussiness Network
  • OpenBL

Con este conjunto de listas, creamos el script:

#!/bin/bash
cat <<EOF > /tmp/blacklist
#ADDRESS/SUBNET PROTOCOL PORT
# block all between ports 1 and 31
- tcp 1:31
# block unused ports
- udp 1024:1033,1434
- tcp 57,1433,1434,2401,2745,3127,3306,3410,4899,5554,6101,8081,9898
# block all from spamhaus, dshield and wizcrafts
EOF
echo "# dshield blocklist" >> /tmp/blacklist
wget -q -O - http://feeds.dshield.org/block.txt | awk 'NF && !/^[:space:]*#/' | sed '/Start/,+1 d' | awk '{ print $1 "/24"; }' >> /tmp/blacklist
echo "# spamhaus DRBL" >> /tmp/blacklist
wget -q -O - http://www.spamhaus.org/drop/drop.lasso | awk 'NF && !/^[:space:]*;/' | awk '{ print $1 }' >> /tmp/blacklist
echo "# chinese and korean spammers" >> /tmp/blacklist
wget -q -O - http://www.okean.com/sinokoreacidr.txt | awk 'NF && !/^[:space:]*#/' | awk '{ print $1 }' >> /tmp/blacklist
echo "# Wizcrafts Russian botnets, attackers and spammers" >> /tmp/blacklist
wget -q -O - http://www.wizcrafts.net/russian-iptables-blocklist.html | awk -F\> '/^pre>/{print $2}' RS=\< | awk 'NF && !/^[:space:]*#/' >> /tmp/blacklist
echo "# RBN Russian IPs" >> /tmp/blacklist
wget -q -O - http://doc.emergingthreats.net/pub/Main/RussianBusinessNetwork/RussianBusinessNetworkIPs.txt | awk 'NF && !/^[:space:]*#/' >> /tmp/blacklist
echo "# OpenBL.org 30 day List" >> /tmp/blacklist
wget -q -O - http://www.openbl.org/lists/base.txt | tr -d $'\r' | awk 'NF && !/^[:space:]*#/' >> /tmp/blacklist
echo "#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE" >> /tmp/blacklist
mv /tmp/blacklist /etc/shorewall/blacklist
shorewall refresh &>/dev/null

El script simplemente descarga todo en una lista temporal, que luego reemplaza el archivo blacklist y refresca la configuración del shorewall.

Luego, simplemente hacemos un enlace simbólico a /etc/cron.monthly

Para verificar, simplemente ejecutamos:

iptables -L -n --line

O en su defecto,

shorewall show blacklst

Que serían aproximadamente unas 28 mil IPs que quedarían permanentemente bloqueadas y que mensualmente se renovaría la lista.

Conclusiones

Atrás quedaron aquellas románticas (pero estúpidamente inútiles) épocas donde la gente escribía sus breves y concisos archivos de “reglas iptables” y los ponía en producción (aun queda *peligrosamente* gente así), en la actualidad es sumamente complicado mantener protegido un Firewall, con constantes botnets, malware, troyanos y un pare de contar de ataques y aprovechar estas listas, muchas actualizables incluso en tiempo real, nos ahorra mil dolores de cabeza y protege un poco más nuestros servidores.

¿imaginen qué pudieramos hacer si integraramos fwsnort al Firewall de nuestro equipo? …

 

[iptables]: Usar geoIP y Shorewall para bloquear paises

Y no, no es para hacer embargos! …

Preámbulo

Se estaba presentando el caso de un ataque de fuerza bruta contra un servidor públicamente visible, el ataque venía mayormente de China y Hong Kong y decidí, que sería interesante aprovechar las capacidades del módulo de xtables XT_GEOIP para ubicar una IP geográficamente con un porcentaje más o menos preciso.

Por ejemplo, GeoIPLookup (que hace uso de la base de datos de GeoIP), puede retornar la siguiente información:

geoiplookup 186.92.27.1
GeoIP Country Edition: VE, Venezuela

Lo cual resulta muy útil, ¿se podrá usar para bloquear tráfico desde países completos? …

Pre-requisitos

Los pre-requisitos son los siguientes:

  • Shorewall, versión 4.5 o superior
  • xtables-addons-common
  • libtext-csv-xs-perl (para procesar la base de datos de georeferencia).

Por ende, es simplemente instalar las dependencias y tener configurado Shorewall.

aptitude install xtables-addons-common libtext-csv-xs-perl

Creamos el directorio que requiere el módulo:

mkdir /usr/share/xt_geoip

Y montamos el módulo:

modprobe xt_geoip

Ahora, nos toca descargar la base de datos:

/usr/lib/xtables-addons/xt_geoip_dl

Veremos algo como:

root@proxy:/etc/shorewall# /usr/lib/xtables-addons/xt_geoip_dl
–2014-06-24 22:07:01– http://geolite.maxmind.com/download/geoip/database/GeoIPv6.csv.gz
Resolving geolite.maxmind.com (geolite.maxmind.com)… 108.168.255.243, 2607:f0d0:3:8::4
Connecting to geolite.maxmind.com (geolite.maxmind.com)|108.168.255.243|:80… connected.
HTTP request sent, awaiting response… 200 OK
Length: 823979 (805K) [application/octet-stream]
Saving to: ‘GeoIPv6.csv.gz’
100%[====================================================================>] 823,979 91.0KB/s in 9.3s
2014-06-24 22:07:11 (86.9 KB/s) – ‘GeoIPv6.csv.gz’ saved [823979/823979]

Y por último, convertimos este CSV en una forma binaria empaquetada que requiere el módulo xt_geoip:

/usr/lib/xtables-addons/xt_geoip_build -D /usr/share/xt_geoip *.csv
1 IPv6 ranges for VC Saint Vincent and the Grenadines
23 IPv4 ranges for VC Saint Vincent and the Grenadines
38 IPv6 ranges for VE Venezuela
230 IPv4 ranges for VE Venezuela
0 IPv6 ranges for VG Virgin Islands, British
48 IPv4 ranges for VG Virgin Islands, British
2 IPv6 ranges for VI Virgin Islands, U.S.
47 IPv4 ranges for VI Virgin Islands, U.S.
32 IPv6 ranges for VN Vietnam
257 IPv4 ranges for VN Vietnam
5 IPv6 ranges for VU Vanuatu
14 IPv4 ranges for VU Vanuatu

Y ya estamos listos para hacer uso de esta base de datos en Shorewall.

Configurando Shorewall

Desde Shorewall 4.5 existe soporte para GeoIP y su uso es extremadamente fácil, por ejemplo, podemos agregar al archivo /etc/shorewall/rules la siguiente regla:

DROP net:^[CN,TW,JP] fw - -

Y estaríamos bloqueando (DROP) desde mi zona “Internet” (net) a China (CN), Taiwan (TW) y Japón (JP), con destino a mi firewall (fw) de absolutamente todo tráfico UDP y TCP.  el formato del país es ISO-3661.

Podríamos por ejemplo, aceptar pero con información (LOG) todo tráfico WEB reportado como IP de Venezuela:

ACCEPT:info              net:^[VE]        fw          tcp          80,443

Podemos bloquear todo tráfico que sea explicitamente declarado como un proxy anónimo (según las reglas de GeoIP):

DROP        net:^[A1,A2]                  fw              -             -

Y listo!, verifiquen sus reglas y disfruten!.

Conclusiones

Los 2 comandos de arriba para descargar la base de datos de GeoIP podemos meterlos en un script, que se ejecute mensualmente, con esto, el sistema se actualizaría solo:

vim /etc/shorewall/scripts/updategeoip.sh

#!/bin/bash
# update geoip database (xt_geoip)
/usr/lib/xtables-addons/xt_geoip_dl > /dev/null 2>&1
/usr/lib/xtables-addons/xt_geoip_build -D /usr/share/xt_geoip *.csv > /dev/null 2>&1
# refresh configuration
shorewall refresh &>/dev/null

hacerlo ejecutable:

chmod 0770 /etc/shorewall/scripts/updategeoip.sh

Y colocar un enlace simbólico en cron.monthly:

ln -s /etc/shorewall/scripts/updategeoip.sh /etc/cron.monthly/updategeoip.sh

Y ya tendríamos un Firewall que bloquea (con una precisión del 74%) todo acceso desde el gigante asiático.

 

 

Del por qué un desarrollador NO ES un Database Administrator?

O del por qué podría ser, pero debería primero cambiarse la camisa …

Este POST no busca explicar postgreSQL, ni siquiera es un artículo acerca de trucos o buenas prácticas, es simplemente una reflexión acerca de cómo pequeñas cosas que muchos pasan desapercibidas causan impacto profundo en el diseño de una aplicación.

Preámbulo

Tomé un servidor físico GNU/Linux que únicamente ejecutaba una base de datos y lo mudé a una máquina virtual restringida (¡conchale!, hay que ahorrar recursos!, pensé), pensando que todo quedaría bien.

Sin embargo, los usuarios del sistema (en producción) comenzaron a quejarse de lentitud, además, los administradores de sistemas comenzaron a notar excesivos picos de uso de CPU (¿en un equipo que sólo tiene postgreSQL?) e incluso en varias oportunidades se iba a SWAP.

Antes de devolver la base de datos al equipo físico, decidí hacer una revisión (les dije, “no solo monto sistemas, también sé de programación y mucho de base de datos, lo olvidan?”) y estas son las impresiones de la muy breve (pero exitosa) revisión.

El análisis

Lo primero que siempre hago cuando voy a analizar un sistema conectado a postgreSQL, es activar el slow log, esto es, comenzar a medir aquellos queries que consumen más del tiempo que uno supone debería asumir cierto tipo de consulta; paralelamente es daba una clase rápida de postgreSQL, de la importancia de entender el ciclo de parsing/análisis de una consulta SQL y más aún, de la importancia de entender SQL; por ejemplo, dos casos reales extraídos de este caso:

“fecha_inscrito” es un campo VARCHAR, donde almacenan algo como “12/04/2012″; si desean sacar el año, hacen un SPLIT de la cadena con un SUBSTR y sacan el tercer valor luego del “/” … ¿les parece eso correcto?, pues veamos el resultado:

postgres=# SELECT substr(’12/04/2012′, 6);
substr
——–
/2012
(1 fila)
Duración: 61,300 ms

Versus:

postgres=# SELECT EXTRACT(year from ‘2012-04-12′::date);
date_part
———–
2012
(1 fila)
Duración: 0,468 ms

Y comenzaron las alarmas!, 60 milisegundos menos!, pero chamo, a mi no me gusta trabajar con formato ANSI!, y luego les recuerdo que existe la variable de conexión DATESTYLE:

postgres=# SET datestyle to sql;
SET
Duración: 0,124 ms
postgres=# SELECT ‘2012-04-12′::date;
date
————
12/04/2012
(1 fila)
Duración: 0,154 ms

INSOLITO! ¿cómo es posible que una simple función SET cause que todas las fechas salgan con el formato que yo desee?, esto pasa cuando se desconocen los detalles de la base de datos con la que se trabaja.

Igual sucede cuando la gente comprende la diferencia entre usar ON y USING cuando se construyen JOINS (diferencia claro está, a nivel de planificador).

El tercer caso de no-entendimiento de postgreSQL ocurría con un “pseudo-ORM hecho a mano” por los mismos programadores, que no solamente escapaba mal las cadenas:

Esto:

(‘Empresa’, ‘   MATURIN’, ’15/04/2014′, …

No es igual a esto:

(‘Empresa’, ‘MATURIN’, ’15/04/2014′, …

Ya que la cadena ”    MATURIN” no es igual a “MATURIN”, a menos que se haga un TRIM adicional, afectando el performance de la consulta, sino que además, hacen cosas como esta:

’21’, ’32’, ’16’, ‘8’, …

¿Esos son cadenas o números?, luego de ejecutar un DESCRIBE a la tabla, encontramos con que son campos numéricos, y aunque postgreSQL hace la conversión, lanza un WARNING indicando que esos valores son “not integers”, lo cual obviamente no es para nada óptimo.

Esto es lo que pasa cuando los programadores, pensando como programadores, intentan diseñar bases de datos.

El extraño caso del CPU consumido

Me he encontrado con una consulta muy repetida, con esta forma:

SELECT * FROM sol_solvencia WHERE cod_aport = $1 and estatus = $2;

La consulta se repetía muchísimo (sobre todo en temporada de mucho uso de la aplicación web hecha en PHP) y los logs del postgreSQL reportaban que su duración, promedio, era de 550 milisegundos … grité (como gritó Emmet Brown cuando le dijeron que debía alimentar el D’lorean con 1.1Gigawatts) ¡550 milisegundos!, yo en 550 milisegundos corría una nómina y ellos sólo ejecutan un query!.

Luego de usar EXPLAIN ANALYZE nos encontramos con la sorpresa de que la tabla no posee índices de ningún tipo (alegan que es un sistema legado y viene así de informix) y en la actualidad posee unos 98 mil registros; por ende, postgreSQL no le queda de otra para hacer el WHERE que ejecutar un SEQUENTIAL SCAN; o lo que es lo mismo, postgreSQL iteró de manera secuencial por los 98 mil registros para sacar ámbos criterios, ¿en conclusión?, allí se van los 550 milisegundos.

Si el query se ejecuta a un ritmo de hasta 50 veces en un minuto, se imaginan el uso de CPU de postgreSQL para poder mantener ese ritmo.

Indizar, y sino, indizar también …

Luego de construir un par de índices sencillos:

CREATE INDEX idx_sol_solvencia_cod_aport ON sol_solvencia USING btree (cod_aport NULLS FIRST);

Y

CREATE INDEX idx_sol_solvencia_estatus ON sol_solvencia USING btree (cod_estatus);

El EXPLAIN cambia considerablemente:

Aggregate  (cost=32.19..32.20 rows=1 width=4)
  ->  Index Scan using idx_solvencia_fecha on sol_solvencia  (cost=0.00..31.96 rows=94 width=4)
        Index Cond: (fecha_now = ’11-04-2014′::date)
        Filter: ((estado = 1) OR (estado = 15))

Al realizar un escaneo sobre índices y luego una función de agregado sobre ámbos índices, la consulta se ejecuta en 1.7 milisegundos …

¡toda una mejora!, ¿no les parece?

Prepáralo, ponlo para llevar

Luego, les expliqué el concepto del planificador, del GeQo de postgreSQL, y de cómo se analizaban las consultas, luego de ello, les dije “¿y se imaginan que ese tiempo pudiera bajarse más?” … te miran con cara de gallina comiendo sal y tú les muestras PREPARE.

PREPARE genera sentencias preparadas, toma una consulta común, la pasa por el planificador, construye el plan en base a criterios pre-definidos y compila este plan, presto a simplemente recibir los parámetros, ¿y qué ganamos con esto?, ¡ahorrarnos milisegundos valiosos de planificación!.

PREPARE pln_obtenersolvencia (int, varchar) AS
SELECT * FROM sol_solvencia WHERE cod_aport = $1 and estatus = $2;

Como ven, la sentencia preparada es simplemente un QUERY tradicional, al cual hemos pasado sus condiciones (que deben ser criterios, no metadatos) como parámetros, así, postgreSQL puede analizar, planificar y compilar la sentencia y esperar únicamente a que pasemos los parámetros:

EXECUTE pln_obtenersolvencia(682185, 1);

Total runtime: 0.473 ms
(1 filas)

De 1.7 a 0.4 ha sido una mejora interesante, ¿no?.

Conclusiones

No busco “echarme de enemigos” a los desarrolladores, yo también soy uno (de diseñado APIs, frameworks, y módulos en python y PHP), pero, cuando se trata de bases de datos, los desarrolladores deben quitarse los audífonos, la sudadera geek y ponerse en la camisa y anteojos nerd de los DBA; porque al final del día, la aplicación no se está diseñando para yo sentirme cómodo para trabajar con fechas o agregar y agregar campos sin mantener un diccionario de datos simplemente porque me pidieron en un lugar meter el RIF como J310210423 en otro como J-31021042-3 y en otro el tipo de contribuyente por un campo y el código del mismo por otro; no se trata de nuestra comodidad (o de nuestro limitado conocimiento como desarrolladores) sino de la eficiencia y la funcionalidad que deben garantizar que sea el USUARIO FINAL (y sólo él, porque al final, es el que usará todos los días la aplicación) quien disfrute el uso de nuestra aplicación.

Por cierto, como colofón, habrán notado que la tabla se llama “solvencia”, si, es un sistema que genera solvencias al público en general, ahora las consultas duran menos de un milisegundo (y no casi un segundo en cargar) por lo que la mejora impacta a miles de personas que solicitan la solvencia en ese sistema …

… Y ya el CPU no se agota en la máquina virtual! …

 

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!

 

 

 

Desbloquear un Motorola Atrix 4G o ¿que consigo de menos de 100US$?

Los Motorola Atrix, a pesar de ser horrendos teléfonos (estéticamente hablando, por algo los Razr usan Kevlar para sus diseños, parecen un policía mal vestido), pasan a ser unos equipos dignos de cualquier “Geek” que se aprecie, con una relación precio/valor digna de considerar.

motorola-atrix-4g-mb860

Preámbulo

En las postrimerías de las elecciones de diciembre fui asaltado y despojado de mi viejito HTC Desire, que acababa de recibir una actualización CyanogenMod a 4.2 (Jelly Bean); pensando en el teléfono idóneo para adquirir pasé días analizando reviews, comparando dispositivos (haciendo uso de la herramienta comparativa de GSM-Arena):

comparativa-atrix-motog

 

Por ejemplo, me sorprendió que el más moderno (y popular) Moto G no tenga slot para SD y solo tenga una memoria interna de 16GB (exactamente igual que el Motorola Atrix que es 2 años más viejo); pero, lo que más me impulsó a adquirir este equipo fueron las siguientes:

  • Extraordinario bajo precio: lo adquirí en una subasta en ebay por algo más de 60US$, lo que me evitaba el pago de nacionalización excesiva y el pago por compras mayores a 100US$
  • CPU ARMx9 NVIDIA dual-core, con los tunnings adecuados, puede llevarse a 1.2Ghz y su GPU brinda un rendimiento claramente mejor que un GPU Adreno.
  • NO HAY DOLARES!, este es el gran suplicio de los venezolanos, no podemos andar por allí con un fajo de billetes diciendo “aja!, dame un Razr Maxx HD de 32GB y un Iphone 5C de respuesto”.
  • Super-hackeable!: Todos los dispositivos de la serie atrix traen algo conocido como “Webtop”, que permite correr un “mini-linux” cuando se conecta a un dispositivo conocido como lapdock:

Motorola Lapdock

Por ahora, me he comprometido a meterle Android o Kali Linux al Webtop, pero eso es otro artículo.

Preparativos

El equipo que adquirí es un equipo no desbloqueado de AT&T, la versión de Android “oficial” es la 2.3.6 (gingerbread) y el número de compilación de la SBF (ROM binaria oficial Motorola) es la 4.5.145 (tomen nota de esto, encontrarán muchas confusiones acerca de esto).

Al teléfono entonces hay que realizarle un conjunto de cosas en este orden:

  1. SIM-Unlock: o desbloqueo de SIM, AT&T y otros operadores no bloquean las radios de los equipos, sino las SIM-card, no es posible meterle una SIM de otro operador
  2. Desbloquear el bootloader (con esto, podemos instalar un sistema de recuperación -recovery- y una nueva ROM)
  3. Instalar un Android Recovery
  4. Instalar una ROM nueva
  5. Instalar las Google Apps

Necesitamos:

Recovery: http://forum.xda-developers.com/showthread.php?t=1204500
Custom CWM-based Recovery 5.0.2.7-atrix

Advertencia: ESTE PROCEDIMIENTO ELIMINA EL SISTEMA ANDROID DE FABRICA (STOCK), si desean simplemente darle “root” al teléfono y dejarlo con la ROM stock, este no es tu artículo, ¡go away!.

Paso 0: Cargar el teléfono

Esto parece un paso obvio, pero no lo es, algunos teléfonos Motorola tienen la “característica” de requerir más de lo 500 mili-amperios que proporcionan los cargadores USB-genéricos convencionales, sobre todo para la primera full-charge es necesario que la carga sea usando el cargador que viene oficialmente con el teléfono (o algún cargador de pared compatible).

Entonces, encendemos el equipo.

Paso 1: SIM-Lock

He cancelado 14US$ a una empresa que vende códigos de desbloqueo por SIM, hay varias, pero nota, no busquen las más “barateras”, porque te hacen perder tiempo (bueno, puede ser que tengas “suerte”), tardan como 3 ó 4 días en decirte que “no consiguieron el IMEI” y te devuelven el dinero, yo al final del día me he ido por “http://unlockthatphone.com/” y en cuestión de día y medio (pagué una noche y al mediodía del siguiente ya tenía el código) recibí el correo electrónico con el código de desbloqueo de la SIM.

Es un conjunto de números, simplemente encienden el equipo con la SIM-card de la operadora de su elección (en mi caso, Digitel), cuando les pida el código de desbloqueo, lo escriben y listo!.

Un tutorial con video, acá: http://imei24.net/Blog/2013/08/19/como-desbloquear-un-motorola-atrix-2-mb865-de-att/

Al terminar, apagamos el teléfono.

Paso 2: Arrancar en modo RSD Fastboot

El modo RSD (Remote Software Download) permite al usuario “cargar” software al teléfono, se usa por ejemplo, para cargar absolutamente TODO el firmware:

Listado de Firmware oficial disponible para Motorola Atrix 4G: http://sbf.droid-developers.org/phone.php?device=33

Bien, al poner el teléfono en modo RSD podemos “cargar” binarios de tipo SBF al teléfono, con ello podemos por ejemplo reemplazar el firmware de la radio o cargar todo el sistema completamente a su versión “stock”:

Si deseas descargar el último Firmware oficial de Motorola para Atrix 4G: http://sbf.droid-developers.org/download.php?device=33&file=742

NUNCA carguen ROM oficiales completas vía SBF, RSD tiene lectura directa sobre el dispositivo, un fallo en la carga generaría un HARD BRICK (tu teléfono se volvería inservible, y a diferencia de un “soft-brick” no hay manera humana de regresarlo de un hard brick).

Para iniciar el modo RSD Fastboot deberán presionar el botón de Volumen arriba (Volume Up) y el botón POWER a la vez:

y lo dejan presionado hasta que aparezca en la pantalla:

RSD Protocol Support

En este momento, conectamos al equipo vía USB.

Paso 3: Aplicar el SBF

Para permitir desbloquear el bootloader, tenemos primero que descargar el sbf_flash y el pudding en una carpeta de nuestro equipo, que ya debe tener por cierto ADB (Android Debug Bridge), aunque solamente necesitaremos fastboot.

Al estar en modo RSD el teléfono, abrimos una consola de root en nuestro GNU/Linux y nos vamos a la carpeta donde descargamos el sb_flash y el pudding, ejecutamos:

chmod +x sbf_flash

Y luego ejecutamos el “flash” del archivo SBF que estaba dentro del archivo pudding.zip:

./sbf_flash 4547-fix-try2.sbf

Verán en la consola algo como esto:

moto-sb1

El teléfono se pondrá en negro varias veces y luego se apagará, de no apagarse, caerá en modo fastboot.

NOTA: En este momento, si desconectan y apagan el equipo, al encenderlo dará un error “boot 0x001″ y la gente entra en pánico (he visto hilos enteros en xda-developers), uno como linuxero, es normal, simplemente NO TIENES UN SISTEMA OPERATIVO, no hay nada que arranque, solo el fastboot!, si haces comentarios acerca de que tu teléfono “no arranca” luego de hacer este paso, estás advertido.

NOTA otra vez: ¡insisto!, el teléfono NO VA A ARRANCAR NADA SALVO FASTBOOT, ¡dejen el trauma!.

Si se llega a apagar y no logran encenderlo el truco es:

  • sacar la batería
  • esperar unos segundos
  • meter la batería nuevamente
  • Arrancar en modo fastboot (Volumen Abajo + botón de encendido) (Volume Down + Power Button)

Ahora, vamos a desbloquear el bootloader!

Paso 4: Desbloqueo del Bootloader

Si conectamos nuevamente el equipo vía USB a nuestro computador con ADB ya instalado, podrán ejecutar el comando “fastboot devices” y verán algo como esto:

./fastboot devices
TA207013NS fastboot

Ejecutamos entonces el comando para solicitar el desbloqueo del bootloader:

 ./fastboot oem unlock

Retornará lo siguiente:

...
(bootloader) Unlocking your device can permanently VOID your warranty.
(bootloader) This process cannot be reversed. If you wish to proceed,
(bootloader) reissue the unlock OEM command containing the unique ID
(bootloader) of your device: 027C108040A002D7
OKAY [ 0.001s]
finished. total time: 0.010s

Es importante hacer notar que el comando retorna un identificador único de equipo (acá en negrillas), con ese ID único repetimos el comando:

./fastboot oem unlock 027C108040A002D7

Y la respuesta será:

...
(bootloader) Device is now unlocked
OKAY [ 7.459s]
finished. total time: 7.459s

Y en la pantalla verán algo como esto:

Untitled-2

Y listo!, ya podemos instalar el recovery.

Paso 5: Instalar el CWM Recovery

He instalado una versión personalizada del CWM para el Atrix 4G, la he descargado (un archivo .img) y usando fastboot utilizo los comandos de borrar el recovery actual:

./fastboot erase recovery

Y luego cargar el recovery con:

./fastboot flash recovery “ruta y nombre del archivo .img”

En mi caso, quedó así:

./fastboot flash recovery /home/jesuslara/android/motorola/recovery-dark-green-atrix5.img
sending 'recovery' (4708 KB)...
OKAY [ 0.250s]
writing 'recovery'...
OKAY [ 0.462s]
finished. total time: 0.712s

Y ya tenemos CWM Recovery instalado.

Apagamos el equipo.

Paso 6: Inicio de instalación de ROM

Para arrancar en modo “Android Recovery”, presionan “volumen abajo” y botón de encendido (volume down+power button), encenderá con una frase “unlocked” abajo, esperen hasta que salga la palabra “fastboot”, cuando salga, podrán cambiar de “fastboot” a “android recovery” presionando varias veces volumen abajo hasta que salga la frase “android recovery”, en lo que esta frase salga, presionan volumen arriba “Volume Up” para confirmar e iniciar el Android Recovery.

Ya en el CWM, es sencillo, este recovery utiliza los botones de volumen para navegar arriba y abajo, el botón de búsqueda es ENTER (SELECT), atrás se logra con el atrás físico (BACK) y las teclas “Menú” y “Home” pueden usarse como arriba y abajo (si no se desea usar los botones de volumen).

Allí, ejecutan las siguientes tareas:

Advanced > Upgrade to ext4

* osh (webtop partition)
* /system
* /data

Luego, Advanced > Wipe Dalvik Cache

Y por último, instalamos la ROM:

Install Zip from SDCard > Choose Zip from SD Card, navegar y seleccionar la ROM (en mi caso, se llama “cm-10.1-20131211-UNOFFICIAL-epinter-olympus.zip”)

Al finalizar, le damos atrás 2 veces y presionamos sobre la opción “reboot now”, y habremos completado la instalación de la ROM.

Paso 7: pre-configuración de la ROM y Google Apps

Al iniciar por primera vez, si lo desean pueden crearse una cuenta CyanogenMod (prestan servicios como “buscar tu teléfono” y otras cosas que se encontraban con la aplicación “MotoBlur”), posteriormente, entran al menú de aplicaciones, buscan en “Configuración” > “Acerca del Dispositivo” y presionen varias veces y rápidamente en la opción “número de compilación”, eso activará un menú oculto conocido como “Rendimiento”, que permite modificar algunas cosas avanzadas de Android (lo veremos después).

Luego de finalizados estos pasos, es hora de instalar las Google Apps.

Simplemente, presionan el botón POWER unos segundos para que salga el menú, escogen “Apagar” y listo. Volvemos a iniciar en modo Android Recovery.

Igual, seleccionan “Install Zip from SDCard” > “Choose Zip from SDCard”, navegan por la SD hasta encontrar el archivo “gapps-jb-20131207-olympus.zip” y listo.

NOTA: esta versión de Google Apps para Motorola Atrix no posee ni Google Now ni Hangouts, deberán ser instalados a mano desde Google Play.

Al reiniciar el equipo (que tarda un poco más mientras se “asienta” la ROM) se iniciará el asistente para configurar la cuenta Google.

 

Conclusiones

Es un equipo modesto, de prestaciones decentes, con algunas características muy interesantes (como Webtop) que fue abandonada por Motorola, que me permitirá volver a la vida digital con un equipo del que estoy seguro, me dará más de una idea loca que publicaremos por acá.

Happy Hacking!

[Debian] Virtualizando con Xen XCP

En mi blog “Phenobarbital con Soda! 2 – El hereje” he incorporado el primero (de una serie) de artículos sobre virtualización utillizando Xen XCP, la plataforma de computación en la nube de Xen, ahora estable en Debian Wheezy y lista para entornos de producción.

Hago la nota acá pues tengo muchos más suscriptores por este blog y me gustaría recibir más comentarios que vayan retroalimentando y mejorando la entrada.

Próximamente habrá una versión “copy & paste” en el wiki de phenobarbital.info.

 

[apache] benchmark de diversas configuraciones de Apache+PHP

He estado configurando un load-balance de servidores Apache2; claro, usando nginx como proxy reverso, una de las dudas que me saltó durante las pruebas fue:
¿cómo lograr el máximo rendimiento en cada nodo?, y es que, cada nodo de apache2 se ejecuta en una máquina virtual con una ínfima cantidad de RAM, así que, manos a la obra, decidí tomar el control del asunto.

Apache y MPM

Los “módulos de multi-procesamiento” (“Multi-Processing Modules” ó MPM) es como llama apache a sus módulos que procesan las solicitudes.

mpm_prefork: el más antiguo y utilizado por usuarios de PHP, prefork genera procesos de apache con el interprete PHP imbuido (mod_php), es el más sencilo de configurar (apt-get install apache2-mpm-prefork libapache2-mod-php5); sin embargo, prefork tiene el inconveniente de tener que integrar un compilador de PHP en cada proceso, por consiguiente el consumo de recursos ante sitios con alta demanda, es excesivo.

mpm_worker: en worker no sólo se generan procesos, sino que cada proceso puede generar múltiples hilos, al procesar múltiples hilos de manera asincrónica a la vez, podemos consumir menos recursos que levantar un proceso de apache por cada solicitud

mpm_event: es una versión más reciente de worker, los procesos padre generan hilos “principales”, dichos hilos principales pueden “pasar” procesos a hilos hijos (creados por demanda) para asumir nuevas solicitudes, event tiene una característica de trabajo muy parecida al modo asíncrono multi-hilado de Nginx.

Las pruebas:

Hemos instalado el siguiente servidor (una máquina virtual) muy sencilla:

Servidor: Debian Wheezy 7.0
RAM: 512MB
Document Size: 70Kb
CPUs: 1

Usando apache benchmark, con una configuración muy simple:
ab -n 100 -c 50 http://web1.example.net/test.php

Donde test.php contiene un “loop” sencillo y un phpinfo().

He decidido probar las diferentes combinaciones tomando el mejor de 10 resultados.

Resultados (raw)

* apache mpm_prefork + mod_php:

la clásica combinación MPM_PREFORK+MOD_PHP.

Server API: Apache 2.0 Handler

Concurrency Level: 50
Time taken for tests: 37.756 seconds
Complete requests: 100
Failed requests: 14
 (Connect: 0, Receive: 0, Length: 14, Exceptions: 0)
Write errors: 0
Total transferred: 6701286 bytes
HTML transferred: 6674386 bytes
Requests per second: 2.65 [#/sec] (mean)
Time per request: 18877.780 [ms] (mean)
Time per request: 377.556 [ms] (mean, across all concurrent requests)
Transfer rate: 173.33 [Kbytes/sec] received

* apache mpm_worker + php5-fpm + fastcgi:

hemos combinado PHP5-FPM (vía socket, es unos 15% más rápido así que vía TCP, ya que te quitas unas cuantas capas del transporte TCP/IP) + fastcgi (el modo por defecto de configurar FPM, ya que fcgid no permite enviar solicitudes a procesos remotos).

Server API FPM/FastCGI

Concurrency Level: 50
Time taken for tests: 33.945 seconds
Complete requests: 100
Failed requests: 5
 (Connect: 0, Receive: 0, Length: 5, Exceptions: 0)
Write errors: 0
Total transferred: 7714795 bytes
HTML transferred: 7680695 bytes
Requests per second: 2.95 [#/sec] (mean)
Time per request: 16972.487 [ms] (mean)
Time per request: 339.450 [ms] (mean, across all concurrent requests)
Transfer rate: 221.95 [Kbytes/sec] received

Nota: el uso de RAM es muy eficiente usando php5-fpm, nunca consumiendo más de 140MB de RAM.

* apache mpm_worker + php5-cgi + mod_ fcgid:

combinamos mpm_worker con PHP5 en modo fastCGI pero usando fcgid

Server API CGI/FastCGI

Concurrency Level: 50
Time taken for tests: 32.200 seconds
Complete requests: 100
Failed requests: 8
 (Connect: 0, Receive: 0, Length: 8, Exceptions: 0)
Write errors: 0
Total transferred: 7641087 bytes
HTML transferred: 7606987 bytes
Requests per second: 3.11 [#/sec] (mean)
Time per request: 16099.806 [ms] (mean)
Time per request: 321.996 [ms] (mean, across all concurrent requests)
Transfer rate: 231.74 [Kbytes/sec] received

* apache mpm_event + php5-cgi + mod_fcgid:

realizamos la misma combinación, pero sustituyendo mpm_worker por mpm_event.

Server API CGI/FastCGI

Concurrency Level: 50
Time taken for tests: 46.755 seconds
Complete requests: 100
Failed requests: 8
 (Connect: 0, Receive: 0, Length: 8, Exceptions: 0)
Write errors: 0
Total transferred: 7641191 bytes
HTML transferred: 7607091 bytes
Requests per second: 2.14 [#/sec] (mean)
Time per request: 23377.675 [ms] (mean)
Time per request: 467.553 [ms] (mean, across all concurrent requests)
Transfer rate: 159.60 [Kbytes/sec] received

* apache mpm_event + fastcgi + php5-fpm:

La misma combinación de fastcgi + php5-fpm, pero usando mpm_event

Server API FPM/FastCGI

Concurrency Level: 50
Time taken for tests: 35.976 seconds
Complete requests: 100
Failed requests: 10
 (Connect: 0, Receive: 0, Length: 10, Exceptions: 0)
Write errors: 0
Total transferred: 7714787 bytes
HTML transferred: 7680687 bytes
Requests per second: 2.78 [#/sec] (mean)
Time per request: 17987.970 [ms] (mean)
Time per request: 359.759 [ms] (mean, across all concurrent requests)
Transfer rate: 209.42 [Kbytes/sec] received

Nota: se incrementó hasta 400 conexiones con 100 niveles de concurrencia, los valores de conexión y procesamiento se mantuvieron invariables.

 

Las gráficas

… y es que la gente le encanta un gráfico

conexion

El primero representa el tiempo que tarda Apache en recibir una conexión y procesarla, como vemos, aun con pocas solicitudes, prefork se va **adelante** (pues el servidor con solo 512MB de RAM estaba a punto de irse a la SWAP), mientras, mpm_event fue más diligente en conectarse y procesar rápidamente las solicitudes, sin tomar en cuenta cuanto más tardó en transmitirlas.

Ganador: Empate entre MPM-Event+PHP5-FPM y MPM-Event+PHP5-CGI+FCGID

tiempo-total

El tiempo total de la prueba, es lo que tardó Apache desde que se inició el apache-benchmark hasta que se completaron las 100 solicitudes, como vemos (y muy interesante el resultado) event-fcgid fue el peor en el resultado, tardando incluso más que mpm_prefork en conectar-procesar y transmitir resultados, de manera paradójica, la misma configuración pero usando mpm_worker fue la mejor de todas.

Ganador: MPM-Worker+PHP5-CGI+mod_fcgidsolicitud

En general, los resultados fueron parejos, sin embargo, worker-fcgid aparece nuevamente victorioso acá, además, en promedio terminó más solicitudes por segundo (unas 3.11 solicitudes/seg versus 2.9 de worker-fpm).

Ganador: MPM-Worker+PHP5-CGI+mod_fcgid
transfer-rate

 

La velocidad de respuesta, o rata de transferencia de los datos desde el servidor hacia el cliente, es también muy importante, como vemos, Worker-fcgid aparece con una velocidad más alta que el resto.

Ganador: MPM-Worker+PHP5-CGI+mod_fcgid

… ¿Y por qué no Nginx?

Con un conjunto de VPS, uso de .htaccess, facilidad de implementación de instalaciones adaptadas a apache2, en uso de apache2 es *casi* que una obligación en el proyecto que estoy realizando, sin embargo, es más que notable la diferencia de Nginx+PHP5-FPM versus el resto de configuraciones.

Pero para este caso en particular, necesitaba apache2.

Las conclusiones

Es precipitado adelantarse a dar ganadores sin explicar para qué se podría utilizar cada combinación, por ejemplo, mpm_prefork se muy sencillo de configurar y para sitios web con muy pocas visitas y si el recurso no es problema, con APC (o xcache) más mod_deflate+mod_expires puede superar a cualquiera de las configuraciones actuales.

Para sitios web con muchísimo tráfico y tiempos de respuesta cortos, es obvio que MPM-Worker+PHP5-CGI+mod_fcgid podría rendir mejor que cualquier otra combinación (MPM-Event+PHP5-FPM+FastCGI podría ser una segunda opción); sin embargo, hay que recordar que mod_fcgid no permite llamar procesos externos (como PHP5-FPM).

PHP5-FPM aparece como una buena opción (en conjunto con MPM-Worker, aunque mejores números, MPM-Event suele consumir más recursos como RAM y CPU que Worker) para pequeños servidores con bajos recursos, PHP5-FPM es bastante óptimo (durante las pruebas Apache+PHP-FPM+todo el sistema operativo no consumían más de 150MB de RAM), además la posibilidad de “compartir” el proceso PHP5-FPM con otras instancias (de apache o de nginx) tanto en el servidor como en otros servidores, nos brindan un ahorro notable de recursos.

La gran sorpresa de la noche fue mpm_event, tal vez me faltó algún detalle de configuración, sin embargo, ver que MPM_EVENT consume más recursos que mpm_worker y además, no rinde mejor que este … me hace dudar de implementarlo con PHP.

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: