[postgreSQL] Una instalación de postgreSQL básica (¡pero mejor!)

PostgreSQL: Introducción

PostgreSQL es una de las grandes maravillas del software libre, robusto, potente, altamente funcional, distribuido en miles de formas posibles (greenplum=clusterizador masivo, postgres Plus=”imitador” de Oracle,deepgreen=granjas de datawarehousing con postgreSQL, etc) puede ser optimizado (como todo lo que es software libre) de maneras inimaginables para cada necesidad específica. Entonces, ¿por qué hay gente que denigra de él? …

El primer error que comete la gente, es pretender que un sistema tan necesario como la base de datos, sea utilizado “directamente” luego de su instalación; un detalle de distribuciones Linux como Debian, es no optimizar para ningún aspecto (ya que son meta-distribuciones genéricas sin una orientación específica).

Mientras Oracle saca libros de 900 páginas de cómo optimizar al máximo hardware, sistema de archivos, sistema operativo y la base de datos como tal, mucha gente piensa “migrar” a postgreSQL ejecutando un “aptitude install postgresql” y dejándolo así … nada más perdido y lejos de la realidad.

Acá, ejecutaremos una instalación que debería ser “básica”, la más básica, para un entorno pequeño de datos, para que sus sistemas “rindan”.

Preámbulo

Uno de los aspectos más importantes es que postgreSQL “no debería” compartir acceso a disco con el sistema operativo, esto es, si es posible que postgreSQL esté en una partición distinta a “root” (incluso un disco separado, de ser recomendable); por lo que la opción “instalar y usar” no debería ser para instalaciones en producción de postgreSQL 9.1.

Hay que tomar en cuenta que postgreSQL (como cualquier otra base de datos) debería ser optimizada posteriormente a su instalación de manera correcta, una de las optimizaciones más necesarias (pero que casi nadie sigue) es gestionar los espacios de datos y separarlos del tablespace pg_default (que gestiona la DB “postgres”, la DB de “information_schema” y demás información, por lo general en “/var/lib/postgresql/9.1/main”); además, ambos deberían estar separados de la partición raíz donde está el sistema operativo.

Las optimizaciones acá realizadas son de las más sencillas a nombrar para postgreSQL, se tomó una máquina virtual en Xen 4.1 en una portátil y se optimizó de lo más básico, para demostrar, que hasta en los cambios más sencillos, pueden afectar el “performance” de aplicaciones diseñadas con postgreSQL.

Preparación primaria

Si estamos instalando un servidor de datos, lo primero que debemos pensar es en separar el montaje de /var del resto del sistema, de hecho, si podemos incluso separar /var/log sería muy apropiado; también es bueno separar /tmp (más 1Gb es innecesario) ya que si no separamos /tmp, Debian GNU/Linux utilizará un tmpfs montado en RAM para gestionar /tmp (restándonos un poco de RAM para trabajar, además que postgreSQL no utiliza la partición /tmp).

Un esquema básico podría ser:

  • / (raiz) (Debian GNU/Linux no ocupa más de 5Gb en este modo)
  • /tmp (1Gb como máximo)
  • swap (Lo necesario, aunque no mayor a 2GB en sistemas con más de 4Gb de RAM)
  • /var (2~4GB ya que será un servidor en producción)

Y de resto, un volumen lógico (LVM) que podemos modificar de tamaño de acuerdo a nuestra necesidad.

Luego de instalado el sistema, procedemos a instalar PostgreSQL.

Instalación

La instalación de postgreSQL 9.1 en Debian GNU/Linux es bastante sencilla:

  • Instalamos postgreSQL 9.1 (pero así no se debería quedar):
    apt-get install postgresql-9.1

PostgreSQL por defecto, creará una carpeta de configuración en: /etc/postgresql/9.1/main/

Y creará un espacio de datos en: /var/lib/postgresql/9.1/main/

Que no utilizaremos para nuestra base de datos, ya que crearemos un espacio propio.

Configuración inicial

Siempre es recomendable dejar el usuario “postgres” (el super-usuario de PostgreSQL) como un usuario “para accesos de emergencia”, ya que este usuario tiene garantizado el acceso a todas partes(si eres root en el sistema), es recomendable que NINGUNA base de datos tenga como “owner” el usuario postgres (y evitar en lo posible utilizarlo como usuario de acceso desde sistemas, aunque esto, obviamente lo he visto más de una vez ocurrir hasta en sistemas web).

  • Creamos un super-usuario para nuestras necesidades, primero cambiamos al usuario postgres:
    su postgres
  • Creamos un usuario, que será nuestro “super-usuario” para “nuestros” accesos, evitando así el usuario postgres:
    createuser -sPl jesuslara
    
    -- ingresamos nuestra contraseña
    Enter password for new role: 
    Enter it again:
  • Ejecutamos la consola SQL de postgreSQL:
    psql
  • Garantizamos al usuario que creaste acceso irrestricto sobre el la DB postgres:
    psql (9.1.3)
    Type "help" for help.
    
    postgres=# grant all on database postgres to jesuslara;
    GRANT

Y salimos de la consola:

postgres=#\quit

Configuración de postgreSQL

  • Accedemos al directorio /etc/postgresql/9.1/main
    cd /etc/postgresql/9.1/main
  • Si vamos a acceder de manera remota a nuestro postgreSQL, agregamos la siguiente línea al archivo pg_hba.conf:
    # la forma es:
    # host -> database (all: todas las db) -> usuario (all: todos los usuarios) -> subnet (de nuestra red) -> modo de clave
    host    all     jesuslara       192.168.100.0/24        md5
  • Habilitamos el acceso remoto en nuestro postgreSQL:

archivo /etc/postgresql/9.1/main/postgresql.conf

listen_addresses = '*'

Optimización del archivo postgresql.conf

  • Y cambiamos algunas opciones básicas del archivo postgresql.conf:
    shared_buffers = 256MB

‘shared_buffers': Es la memoria de trabajo compartida para todo el servidor postgreSQL, fíjese que por defecto en Debian GNU/Linux la opción es 24MB (y el valor por defecto si comentamos es 32MB), sin embargo, como esta es la memoria utilizada para trabajo de postgreSQL, es recomendable “al menos” el 25% de la RAM disponible (y jamás > 40%).

temp_buffers = 16MB

‘temp_buffers': La memoria temporal utilizada por cada sesión para las tablas temporarias y para apertura de tablas en cada sesión de cada base de datos, tome en cuenta que este valor dependerá obviamente de la cantidad de datos que carga cada sesión y dependerá muchísimo del sistema que se utiliza.

work_mem = 16MB

‘work_mem': uno de los valores más importantes y más despreciados, “work_mem” se refiere a la memoria temporal utilizada por cada sesión, para las operaciones de ordenamiento (ORDER BY) para las sesiones de diferenciación (GROUP … HAVING y DISTINCT) y para la gestión de hash (uniones HASH, indices HASH, hash_aggregations), si en nuestro sistema realizamos muchísimas consultas ordenadas, agrupadas, diferenciadas por cadenas, etc se crearán mucho de estos buffers de manera paralela, mientras más memoria asignemos, menos probabilidades hay que los ordenamientos y otras operaciones se hagan con archivos temporales en disco (más lentos que la memoria RAM).

max_stack_depth = 8MB

‘max_stack_depth': define el tamaño del espacio utilizado para cómputo de operaciones complejas, su valor está asociado al límite máximo que un usuario (en este caso, “postgres”) tiene derecho a reservar un stack, el valor soportado por nuestra distribución se determina con “ulimit -s”.

shared_preload_libraries = '$libdir/plpython2.so'

‘shared_preload_libraries': Permite cargar una librería específica cuando arranca el sistema, si utilizamos muchos procedimientos almacenados en un lenguaje específico (ej: python, perl, tcl, java, etc), es bueno pre-cargarla para que esté disponible cuando se utilice por primera vez. Nota: esta opción ralentiza un poco el reinicio del sistema.

bgwriter_delay = 500ms

‘bgwriter_delay': El background-writer es un proceso del servidor que se encarga de escribir a disco todos los “shared_buffers” modificados, este proceso conlleva una carga de I/O sobre el disco, su modificación permite o reducir el valor para evitar en lo más posible pérdidas de datos en equipos que pueden fallar, o su incremento permite reducir el I/O al disco duro en sistemas perfectamente protegidos.

Modificados estos parámetros básicos, vamos a modificar nuestro sistema operativo.

Optimización de Linux para postgreSQL

Una de las cosas que olvidamos “optimizar” (tunning) es nuestro sistema operativo GNU/Linux, con grupo de valores en el sysctl ya podemos ayudar “mucho” a nuestro postgreSQL.

  • Agregamos al archivo sysctl.conf

archivo: /etc/sysctl.conf

kernel.sem = 100 32000 100 128
kernel.shmall = 3279547
kernel.shmmax = 289128448
kernel.shmmni = 8192
fs.file-max = 287573
vm.dirty_bytes = 67108864
vm.dirty_background_bytes = 134217728

Nota: observe el valor de shmmax, la cantidad de “memoria máxima reservada para un shared_buffer” que puede crear una aplicación debe ser igual o mayor al valor del shared_buffer de postgreSQL, este valor está en bytes y es ~ 275MB.

La cantidad máxima de archivos que pueden abrirse en un sistema, dependerá obviamente del nivel de trabajo de la DB, durante una operación regular, la gente puede ejecutar “lsof | wc” para obtener la cantidad de archivos abiertos.

  • Y luego, las aplicamos:
    sysctl -p
    
    --
    kernel.sem = 100 32000 100 128
    kernel.shmall = 3279547
    kernel.shmmax = 289128448
    kernel.shmmni = 8192
    fs.file-max = 287573
    vm.dirty_bytes = 67108864
    vm.dirty_background_bytes = 134217728

Ya, con estos sencillos cambios, podemos reiniciar el postresql:

/etc/init.d/postgresql restart
Restarting PostgreSQL 9.1 database server: main.

Y estamos listos para crear una partición y tablespace para nuestra DB.

Creación del espacio de tablas

Creamos una partición del tamaño necesario para contener “al menos” nuestra base de datos (esta es una guía básica, no hablaremos de particiones adicionales para metadatos, para índices y demás).

Nota: en nuestro caso, la partición es /dev/xvdb1 y mide 10GB.

El “journal”, para quien no lo conoce, es la razón por la cual no existe software de “desfragmentación” en Linux, todos los sistemas operativos que lo soportan (ext3, ext4, jfs, reiserfs, xfs, zfs, etc) tienen servicios que se encargan de ordenar, desfragmentar y gestionar tanto la data como los metadatos (información acerca de los archivos y carpetas en sí), pero además, los journal cumplen otras funciones, entre ellas, recuperar desde sus logs la data que pudiera “haberse perdido” luego de un fallo de energía y/o de sistema.

En sistemas de base de datos, la data es contenida en uno o más (y diversos) tablespaces, espacios de tablas donde la data, metadata e índices es contenida, como es la base de datos la encargada de gestionar la posición de los datos en ellos, el Sistema Operativo no requiere la presencia de un journal, o al menos, de un journal más relajado y menos estricto.

Formateando la partición

  • Se formatea la partición (disco):
    mkfs.ext4 -E stride=32 -m 0 -O extents,uninit_bg,dir_index,filetype,has_journal,sparse_super /dev/xvdb1

Utilizamos ext4, porque en modo “writeback” tiene un mayor performance que XFS para almacenar los tablespaces y tiene menor propensión a fallos.

  • Habilita el journal en modo writeback:
    tune2fs -o journal_data_writeback /dev/xvdb1
  • Si simplemente desea eliminar el journal, ejecute:
    tune2fs -O ^has_journal /dev/xvdb1
  • Nota: utilice esta opción a su propio riesgo, recuerde que no tener un journal afecta de 2 modos:
  • La data no es colocada en orden en el disco, fragmentando el mismo
  • Ante un fallo de energía, el FS no podrá recuperar desde el journal las últimas actividades para recuperar esos datos.
  • Se ejecuta un chequeo de archivo básico:
    e2fsck -f /dev/xvdb1
  • Creamos la carpeta de postgresql:
    mkdir /srv/postgresql
  • Y luego se monta con las opciones que describiremos más abajo:
    mount -t ext4 /dev/xvdb1 /srv/postgresql -o  noatime,nouser_xattr,noacl,discard,nodelalloc,data=writeback,barrier=0,commit=300,nobh,i_version,inode_readahead_blks=64,errors=remount-ro

Las opciones son:

Opciones de FS Linux:

noatime

No guardar la información del timestamp del último acceso a los archivos, esta información no es necesaria ya que postgreSQL gestiona apropiadamente el acceso a los tablespaces.

nouser_xattr

Deshabilita el uso de atributos extendidos de usuario, esto es seguro en postgreSQL ya que la carpeta donde se guardan los tablespaces no requiere ninguno de esos atributos.

noacl

No utilizar atributos extendidos ni ACLs POSIX, no son necesarias ya que solamente postgreSQL tendrá acceso a los archivos en esta partición.

Opciones específicas de ext4:

nobh

ext4 asocia buffers de datos con las páginas de datos, esos bloques de cache proveen garantía de ordenamiento de los datos; “nobh” evita el uso de estos buffers de ordenamiento de datos (sólo activable con “data=writeback”).

data=writeback

No se preserva el ordenamiento de los datos, la data será escrita en el sistema de archivos solo después que la metadata ha sido guardada en el journal. Aunque hay personas que recomiendan desactivar el “journaling” del disco, esto no es recomendable pues, aunque postgreSQL gestiona correctamente los datos, los metadatos (información de los archivos y carpetas en el FS) es responsabilidad de mantenerla consistente el FS.

commit=seconds

Los datos y metadatos son escritos a disco cada “n” cantidad de segundos, el valor por defecto son 5 segundos (commit=0 es igual a dejar el valor por defecto), un valor más bajo puede mejorar la seguridad de los datos, un valor muy alto mejora el performance pero ante un fallo podría perderse datos.

barrier=0

Deshabilita el uso de barreras de escritura, las barreras de escritura fuerzan el uso de ordenamiento on-disk de los commits al journal, haciendo las caché de disco seguras de usar, pero un daño en el performance del disco.

inode_readahead_blks=n

Cantidad de inodes que el sistema de pre-lectura de ext4 lee al buffer caché, el valor por defecto de n es 32, pero un valor de 64 es normal para optimizar las lecturas.

discard

Permite decidir que realiza con los bloques que son liberados, por lo general ext4 ejecuta una operación de trim (limpieza), con esta opción, ellos simplemente son marcados como descartados, evitando la escritura innecesaria de bloques.

i_version

Permite indicar que los inodes serán de 64-bits, solo disponible si se está en un sistema a 64 bits.

  • Luego de montada de esta manera, lo fijamos en el /etc/fstab
# particion para postgresql
/dev/xvdb1 /srv/postgresql ext4 rw,noatime,errors=remount-ro,nouser_xattr,noacl,commit=300,barrier=0,i_version,nodelalloc,data=writeback,inode_readahead_blks=64,discard 0 0
  • Comprobamos:
    mount -a

Y ya estamos listos para crear el espacio de datos para nuestra DB!.

El espacio de tablas (tablespace)

Crearemos un simple espacio de tablas en nuestro optimizado sistema de archivos ext4 para contener nuestra base de datos:

  • cambiamos el propietario a la carpeta /srv/postgresql
    chown postgres.postgres /srv/postgresql
  • cambiamos al usuario “postgres” y abrimos la consola ‘psql':
    su postgres
    psql
  • En la consola, ejecutamos el comando para crear un espacio de tablas:
    postgres=# CREATE TABLESPACE db_sistema OWNER jesuslara LOCATION '/srv/postgresql';

Y listo!, ya tenemos un espacio de tablas disponible para crear bases de datos y optimizado!

Usando el espacio de datos optimizado

Para crear una DB que no esté asociada al espacio “por defecto” (pg_default) ejecutamos:

  • Crear una DB:
CREATE DATABASE sistema WITH ENCODING='UTF8' OWNER=jesuslara TEMPLATE=template0 TABLESPACE=db_sistema;

Y como verán, le pasamos el tablespace “db_sistema” que hemos creado anteriormente.

¿Alguna prueba de la eficiencia?

La configuración siguiente no se hizo en un sistema dedicado para tal, se realizó en una portátil, corriendo Xen 4.1 y en una VM con 1GB de RAM se instaló el postgreSQL con las opciones nombradas, sin embargo, es posible notar una mejora en el performance general de las consultas (y eso que son solamente optimizaciones básicas).

Para ello, creamos una DB adicional, de un sistema administrativo (migrado desde Oracle hasta postgreSQL) que un amigo amablemente me facilitó para esta prueba.

Para ello, se movieron algunas funciones de código “Visual Basic” a código PL/Python y PL/pgSQL y se creó una consulta semi-compleja, de unas 26 líneas de extensión, que unifica unas 6 tablas del sistema para calcular una simple pre-nómina (ivss, paro forzoso, caja de ahorros, faov, isrl, etc); hay que notar que en la versión “cliente-servidor” de la aplicación, la nómina de 13 mil empleados dura varias minutos hasta horas con múltiples conceptos; para nuestra versión “simplificada” (5 asignaciones y 3 deducciones y cálculo de salario integral); la consulta se ejecutó en: 33068ms Para 13674 registros.

Pero, lo mejor ocurre si lo ejecutas por segunda vez!, ya que los buffers de trabajo mantienen en cache las operaciones de hash_aggregate (necesarias para algunos de los cómputos de agregado realizados), la segunda ejecución fué: 3107 milisegundos (3 segundos)

¿13 mil cómputos de empleados en 3 segundos?, ¡Nada mal para ser una portátil!

Conclusiones

Estas optimizaciones no son ni la décima parte de las que podemos optimizar de postgreSQL, pero es un comienzo, esta guía surge de la necesidad de orientar a las personas, que creen que pueden poner un sistema en producción de un postgreSQL recién instalado, estas optimizaciones mínimas, que cualquiera puede seguir, son un ejemplo y un comienzo.

No se dejen engañar con esas personas que dicen que “postgreSQL no rinde como Oracle” y un largo etcétera de excusas baratas, si alguien en su sano juicio instala Oracle cambiando parámetros en el sysctl, modificando los valores de tunning del sistema operativo o del sistema de archivos, clusterizar al máximo e incluso hace cosas más “malandras” como generar índices “al vuelo” por aquellos DBA vagos que jamás piensan bien sus bases de datos; ¿por qué la gente no hace lo mismo con postgreSQL?, tal vez porque ser un DBA “certificado postgreSQL” es más difícil y hacer entender a la gente, cuando crean un sistema conectado a datos, que su principal preocupación no debería ser “si usar PHP o Python” sino ver de qué formas optimizarás el S.O, el sistema de archivos, las consultas, el planificador, el acceso a disco y la gestión de índices para lograr que te sea “inocuo” si la gente utiliza perl o Visual Basic como Front-End.

Al final, postgreSQL debe tener el mando de los datos de la aplicación, y aprender a “verdaderamente” instalarlo, es el primer paso!.

¡Happy Hacking!

Las 12 razones por las que un Administrador de Sistemas perezoso es un buen administrador

Hace muchísimo tiempo me enviaron este texto (lo encontré por acá) y es mi compendio de axiomas de trabajo en la administración de Sistemas, he decidido hacer una traducción libre de este artículo para que mis lectores disfruten un rato y comiencen a ser un poco más perezosos.

Si ves un administrador de sistemas, un técnico de soporte o un administrador de servidores, que siempre anda dando vueltas, como tratando de sofocar fuegos, que constantemente se ocupa de cuestiones relativas a detalles en la producción de sistemas y/o servidores; usted podría pensar que él está trabajando muy duro, ¡siempre tan dedicado!, esa es la concepción para la mayoría de las personas (de hecho, es una concepción de contratar esas personas “bomberos”), pero en realidad él no está haciendo bien su trabajo.

Si vemos a este administrador de sistemas (Unix/Linux, administrador de servidores, DBA o administrador de red) que parece estar todo el día “jugando”, que no parece estar haciendo mucho en la oficina, siempre relajado y casi nunca aparece ningún trabajo duro visible, puede estar seguro de que él está haciendo realmente bien su trabajo.

Estas son las 12 razones por las que un administrador de sistemas (sysadmin) perezoso, es el mejor administrador de sistemas.

Razón 1 ¿Quién es el jefe?: La razón principal por la que los Administradores de sistemas perezosos son los mejores es a causa de su actitud. Ellos ven las máquinas un poco diferente a la forma como las ven en otros departamentos de TI. Hay una diferencia notable entre los administradores de sistemas perezosos y otros admininistradores (ejemplo: los desarrolladores). Los desarrolladores piensan que están para servir a las máquinas mediante el desarrollo de código. No hay nada de malo en este enfoque, ya que los desarrolladores tienen mucha diversión allí; Sin embargo, los administradores de sistemas hacen todo lo contrario; ellos piensan que las máquinas están allí simplemente para servirles. Todo lo que tienes que hacer es alimentar la máquina y mantenerla feliz, dejando que la máquina haga todo el trabajo pesado, mientras pueda relajarse y simplemente dedicar su tiempo a ser perezoso. El primer paso para ser un administrador de sistemas perezoso es un ligero cambio en la actitud, y dejar que la máquina sepa que usted es quien manda.

Razón 2 Automatiza hasta el café: Ser un sysadmin perezoso no significa ser holgazán, debe esforzarse inicialmente para que todo fluya con soltura, debe escribir guiones de programación para trabajos repetitivos; en este aspecto ser perezoso es ser inteligente. Un administrador de sistemas inteligentes es un maestro en todos los lenguajes de scripting (bash, awk, sed, egrep, etc.) y cada vez que se vea obligado a hacer algún trabajo, y si hay una remota posibilidad de que ese mismo trabajo se repita en el futuro, entonces escribe un guión que repita este trabajo. De esta manera, en el futuro cuando se le pida hacer el mismo trabajo, no tiene que pensar, sino que simplemente tiene que ejecutar el script, y volver a ser perezoso.

Razón 3 evitar las pérdidas: Copia de seguridad de todo. Siendo sysadmins perezosos, siempre deben tener una copia de seguridad. Un administrador de sistemas perezoso sabe que debe realizar un poco de trabajo en la creación de procesos de copia de seguridad y escribir secuencias de comandos de copia de seguridad para todos los sistemas y aplicaciones críticas. Cuando el espacio en disco no es un problema, él programa la tarea de respaldo para cada aplicación, incluso para aquellas aplicaciones que no son críticos; de esta manera, cuando algo va mal, él no tiene ponerse a correr a recuperar cosas y sólo hay que restaurar desde la copia de seguridad, y volver a la lectura de comics que estaba haciendo antes.
Esta es también la regla #1 en las tres reglas del administrador de sistemas que JAMÁS se debe romper.

Razón 4 Crea un plan de recuperación ante desastres: A un Administrador de sistemas no le debería gustar correr cuando las cosas van mal (y ciertamente no debería habituarse a ello). Cuando las cosas están funcionando sin problemas, se debe tomar algo de tiempo para crear un DRP (Disaster-Recovery Plan); así, cuando las cosas vayan demasiado mal, pueden seguir el plan de recuperación rápida y que las cosas vuelvan a la normalidad, y volver a ser perezoso de nuevo!.

Razón 5 si no te puedes clonar, clona tus sistemas: La regla de los sistemas altamente redundantes. un sysadmin competente (y perezoso) no le gusta recibir llamadas en el medio de la noche a causa de algún problema de hardware que falló por una tontería; por ende, los sysadmins perezosos se aseguran que todos los componentes de su plataforma sean altamente redundantes. Esto incluye tanto hardware como software. Desde configurar tarjetas de red en modo bonding, RAID en discos, siempre al menos dos servidores o máquinas virtuales para cada cosa, siempre hay que tener al menos dos de todo. Por ende, cuando un componente falla, el sistema todavía sigue funcionando y el administrador del sistema perezoso puede dormir esa noche tranquilo y podrá trabajar en la reparación del componente roto mucho después de regresar temprano en la mañana.

Razón 6 Siempre debe haber espacio para crecer: Un sysadmin perezoso nunca permite que sus sistemas funcionen a plena capacidad. Siempre hay que disponer de espacio suficiente para el crecimiento inesperado; debe asegurarse que los sistemas tiene un montón de CPU, RAM y disco duro disponible; así, cuando su empresa decide volcar toneladas de información o genera inesperadamente muchos archivos, así no sufrirá insomnio pensando si la plataforma colapsará al quedarse sin recursos.

Razón 7 Sea proactivo: Ser un sysadmin perezoso no quiere decir que sólo se sientan y no hacen nada todo el tiempo. Siendo perezosos, se dedican a adelantarse a los hechos y ser proactivo. Los sysadmins perezosos odian ser reactivos. Se anticipan a los problemas y al crecimiento (razones 5 y 6). Cuando tienen algún tiempo libre, se dedican a investigar cómo evitar nuevos problemas, escribir nuevos scripts y modificar la plataforma para durante los problemas seguir siendo perezoso.

Razón 8 Ama tu teclado: combinaciones de teclado, un sysadmin perezoso conoce todos los atajos de teclado para todas sus aplicaciones favoritas. Si va a pasar mucho tiempo todos los días en una aplicación, lo primero que hace es dominar las comnbinaciones de teclas para esa aplicación. por eso los sysadmins perezosos aprenden a usar editores proactivos como emacs o vim, ya que a él le gusta gastar menos tiempo en la solicitud de la información a su máquina, para volver a ser perezoso.

Razón 9: Maestro de la línea de comandos: Cada sysadmin perezoso que conozco es un maestro de la línea de comandos. A veces la gente se sorprende de ver tanto tiempo al sysadmin en una “pantalla negra”; Esto no solo se aplica a sistemas Linux/BSD sino también a DBA’s, administradores de red, etc. Aunque exista una aplicación con interfaz gráfica para una tarea, usted verá al sysadmin lanzando una línea de comandos, En una interfaz de instalación de programas, por ejemplo, tendrás que cargar la aplicación, esperar que cargue, buscar el programa, darle a “seleccionar” y luego a “instalar”, en una cónsola escribes “migestor install miprograma” y listo, sabes exactamente que hacer en cada momento. Hay dos razones básicas por qué los sysadmins perezosos les encanta una línea de comandos. Por un lado, se pueden hacer las cosas más rápidamente en la línea de comandos (si se sabe hacerlo, claro está). Por otra parte, le hace sentir que él es el jefe y no la máquina. Cuando se utiliza la línea de comandos, usted está en control del sistema, usted sabe exactamente lo que quiere hacer y sabe lo que va a obtener. Cuando se utiliza una interfaz gráfica de usuario, usted está a merced del flujo de trabajo gráfico y no tiene el control total.

Razón 10 Aprende de los errores: a un sysadmin perezoso no le gusta cometer el mismo error dos veces. Él odia trabajar en problemas inesperados; pero, cuando surge algún problema inesperado, trabaja en su corrección y piensa acerca de por qué ocurrió, y de inmediato pone las cosas necesarias en su lugar para que el mismo problema no vuelva a ocurrir. Trabajar sobre el mismo problema dos veces es un pecado para un sysadmin perezoso. A un sysadmin perezoso le gusta trabajar en el problema una sola vez, hacer las cosas para evitar el mismo error que ocurra en el futuro, y volver a ser perezoso.

Razón 11 Nunca quedarse atrás: Aprende nuevas tecnologías. No hay nada malo en aprender una nueva tecnología para conseguir un trabajo mejor o simplemente para mantenerse al día con el crecimiento de la tecnología. Pero, nuestro sysadmin perezoso no aprende las nuevas tecnologías por este motivo; en cambio, se entera de las nuevas tecnologías, porque a él le gusta estar en control de los sistemas todo el tiempo. Él sabe que él es el jefe (Razón 1). Así que, cuando una nueva tecnología aparece, este se toma el tiempo para estudiarla. Ahora tiene nuevas herramientas que le permiten mantener el sistema activo, mientras que él sigue siendo un perezoso. Se documenta y aprende una nueva tecnología solo para mantener su egoísta pereza.

Razón 12 Nunca confiar en la mente, Documente todo: No todos los sysadmins perezosos lo hacen; sólo los mejores administradores de sistemas perezosos hace esto. Nunca a un sysadmin perezoso le gusta que le molesten cuando está en la playa disfrutando de sus vacaciones. Entonces, ¿qué hace? documenta todo, deja bitácoras y resoluciones para todo, así que cuando él no está cerca, otro técnico de soporte puede hacer el trabajo de rutina y hacer avanzar las cosas simplemente leyendo la documentación sin molestar las vacaciones del sysadmin. Hay también otra razón más íntima para que el administrador del sistema perezoso documente todo, porque pueden olvidarse las cosas. Puesto que él es perezoso, quizás tiende a olvidar lo que hizo hace un mes. Dado que nunca le gusta pensar el mismo tema dos veces (Corolario de la Razón 10), se documenta todo y cuando tiene que hacer lo mismo en el futuro, pues busca en su documentación para comprender como se hace.

Ahora, usted considerará que ser un sysadmin perezoso no es cosa fácil, es muchísimo trabajo duro, si usted no es un administrador de sistemas, puede que ahora aprecie al administrador vago que ve sentado en su computadora viendo Facebook mientras todo funciona perfectamente, recuerde que no funciona así solo. Si usted es un administrador de sistemas y siempre está dando vueltas apagando fuegos como bombero, usted ya sabe lo que tiene que hacer para ser perezoso.

¡A trabajar hoy, para descansar mañana!

[Trac] Instalando SCM Trac en Debian Wheezy y derivados (Ubuntu, Mint, Canaima)

Preámbulo

Un amigo me solicitó la bitácora de instalación de Trac en Debian Wheezy, había tenido algunos detalles utilizando Trac y postgreSQL 9, por lo que decidí publicarla para que más personas pudieran aprovecharla, sin embargo, como el Wiki de GNU de Venezuela no está operativo (donde estaba la versión Squeeze) entonces publicaré toda la guía por acá.

Instalación de Trac

Trac funciona en el modo “instancia”, cada instancia requiere de su propia base de datos y de su propia carpeta (instancia), pero comparten un único punto en el servidor web, aunque Trac utiliza por defecto sqlite para la base de datos, utilizaremos postgreSQL.

La instalación se realiza en una distribución Debian-based pero puede ser realizada en cualquier distribución GNU/Linux que posea python-setuptools y el comando easy_install (o pip).

Instalación de dependencias

  • Instalar las dependencias en Debian Wheezy (o distribución compatible con aptitude | apt-get):
aptitude install apache2 python2.7-setuptools python-genshi python-pybabel python-psycopg2 python2.7-psycopg2 libapache2-mod-wsgi python-babel babel-1.4.0 postgresql-8.4 subversion git mercurial bzr

Nota: si utiliza postgresql-9.1 con Trac < 0.12.2 tendrá que realizar una correción en el código fuente de Trac para poder crear instancias en schemas de postgreSQL 9.

Nota: Si se instala babel posterior a la instalación de Trac, deberá reinstalar trac y actualizar sus instancias.

  • Opcionalmente, podemos actualizar setuptools (requiere conexión a Internet)
easy_install -U setuptools

Instalación de Trac

  • Vía apt-get:
    apt-get install trac trac-bzr trac-git trac-graphviz trac-mercurial trac-odtexport trac-wikiprint
  • ó via easy_install:
easy_install Babel==0.9.5 Genshi==0.6
easy_install Trac
  • También podemos descargar el fuente e instalarlo manualmente:
    wget -c http://ftp.edgewall.com/pub/trac/Trac-0.12.2.tar.gz
    tar xvf Trac-0.12.2.tar.gz
    cd Trac-0.12.2
    python ./setup.py install

Nota: si deseamos instalar (o descargar) la versión de pruebas ejecutamos:

  • Usando easy_install:
easy_install Trac==dev
  • Descargando:
    svn co http://svn.edgewall.org/repos/trac/trunk trac
    cd trac
    python ./setup.py install

Por ultimo, luego de instalado, verificamos que tenemos la última versión:

trac-admin --version

Luego de instalado Trac, procedemos a configurar una instancia.

Configuración de una instancia

Preparación de la DB de postgreSQL

Agregar las siguientes líneas al archivo pg_hba.conf:

archivo: /etc/postgresql/{version}/main/pg_hba.conf

local tracdb tracuser password
host tracdb tracuser 127.0.0.1/32 md5
host tracdb tracuser [subnet]/24 md5
#para poder iniciar sesion en red:
host all all [subnet]/24 md5

Donde [subnet] se reemplaza por la subnet de la red local; ejemplo:

local tracdb tracuser password
host tracdb tracuser 127.0.0.1/32 md5
host tracdb tracuser 192.168.1.0/24 md5
#para poder iniciar sesion en red:
host all all 192.168.1.0/24 md5

Y en postgresql.conf modificamos:

listen_addresses = '*'

Nota: solo necesario si el postgreSQL y el Trac estarán en diferentes equipos.

  • Iniciar una consola y ejecutar:
su postgres
  • E iniciar una consola de postgreSQL:
    >psql
  • En la consola de postgreSQL, crear la DB:
  • Para crear una DB en > 8.4 ejecutar:
    CREATE DATABASE tracdb
      WITH ENCODING='UTF8'
           TEMPLATE=template0
           LC_COLLATE='C'
           LC_CTYPE='C'
           CONNECTION LIMIT=-1;
  • para 8.3 o inferior:
    CREATE DATABASE tracdb 
    WITH ENCODING='UTF8' 
    TEMPLATE=template0 
    LC_COLLATE 'C' 
    LC_CTYPE 'C';
  • Crear el usuario necesario para gestionar la DB:
create user tracuser password 'clavesecreta';
  • Y garantizar los permisos necesarios sobre la DB de trac:
    grant all on database tracdb to tracuser;
  • Salimos del postgresql:
postgres=# \q

Y reiniciamos el postgreSQL:

/etc/init.d/postgresql restart

Ya estamos listos para crear una instancia de Trac.

(Opcional) Preparación de Trac con postgreSQL 9.1

Nota: cambios iniciales para Trac 0.12 y postgreSQL 9.1

Si se intenta crear una instancia de Trac en postgreSQL 9.1 utilizando un schema personalizado (no “public”), Trac devolverá un error por un detalle en el uso de psycopg (la librería python para conectarse a Trac), dicho error se ve así:

Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/trac/admin/console.py", line 422, in do_initenv
    options=options)
  File "/usr/lib/python2.7/dist-packages/trac/env.py", line 213, in __init__
    self.create(options)
  File "/usr/lib/python2.7/dist-packages/trac/env.py", line 401, in create
    DatabaseManager(self).init_db()
  File "/usr/lib/python2.7/dist-packages/trac/db/api.py", line 146, in init_db
    connector.init_db(**args)
  File "/usr/lib/python2.7/dist-packages/trac/db/postgres_backend.py", line 98, in init_db
    params)
  File "/usr/lib/python2.7/dist-packages/trac/db/postgres_backend.py", line 87, in get_connection
    params)
  File "/usr/lib/python2.7/dist-packages/trac/db/postgres_backend.py", line 212, in __init__
    cnx.cursor().execute('SET search_path TO %s', (self.schema,))
DataError: invalid value for parameter "search_path": "weyu"
DETAIL:  schema "weyu" does not exist

Es un error en el archivo /usr/lib/python2.7/dist-packages/trac/db/postgres_backend.py, dicho error ya está corregido en versiones posteriores de Trac y existe un patch para dicho archivo:

  • Parche que está en la incidencia #10406 de Trac:

 http://trac.edgewall.org/attachment/ticket/10406/10406-search-path-r10830.patch

Si desean hacer los cambios ustedes mismos, las líneas a cambiar son:

Línea 34:

34	 	    from psycopg2 import ProgrammingError as PGSchemaError <- eliminar esta
 	34	    from psycopg2 import DataError, ProgrammingError <- agregar esta

Línea 214:

214	 	        except PGSchemaError: <- eliminar esta
 	214	        except (DataError, ProgrammingError): <- agregar esta

Con esta correción podrán crear instancias en postgreSQL 9.1.

Creando un ambiente base (environment Trac)

  • Creamos el árbol de proyectos:
mkdir /srv/{repositorios,trac,proyectos} -p
  • Nos dirigimos a la carpeta de proyectos:
cd /srv/proyectos
  • Inicializamos la primera instancia de trac (se llamará documentacion)
trac-admin /srv/proyectos/documentacion initenv
  • Se inicia un script que realliza una serie de preguntas:
Project Name [My Project]> Documentacion GNU/Linux
  • Conexión a la DB:
Database connection string [sqlite:db/trac.db]>
  • forma del database connection string
    ''{database}://{usuario}:{contraseña}@{host}:{port}/{database}?schema={schema}''

Ejemplo:

postgres://tracuser:clavesecreta@localhost:5432/tracdb?schema=documentacion

Nota: de usar el schema “public”, simplemente no pasar la opcion schema: ejemplo:

postgres://tracuser:clavesecreta@localhost/tracdb
  • Si deseamos usar unix-sockets:

postgres://user:pass@/dbname?host=/path/to/unix/socket/dir&schema=schemaname

Ejemplo:

postgres://tracuser:clavesecreta@/tracdb?host=/var/run/postgresql/.s.PGSQL.5432/dir&schema=documentacion

— Al terminar la configuración de trac, podemos iniciar las pruebas:

  • ejecutamos:

tracd –port 8000 /srv/proyectos/documentacion

Y apuntamos nuestro navegador a:

 http://host:8000/documentacion

Luego de chequeado, procedemos a configurar nuestra instancia de Trac.

Configuración de Apache y Trac

Debemos crear un ambiente web (www) con WSGI del Trac para apache, para ello desplegamos en la carpeta web (/srv/trac/www’) el sitio web:

trac-admin /srv/proyectos/weyu deploy /srv/trac/www/

Creamos el virtualHost para multiples proyectos de trac, creamos un archivo en:

/etc/apache2/sites-availables/trac.site

<VirtualHost *:80>
# administrador del servidor
ServerAdmin jesuslara@DOMINIO
# nombre del vhost
ServerName proyectos.DOMINIO
# alias del servidor
ServerAlias trac.DOMINIO
DocumentRoot /srv/trac/www/htdocs/

        <Directory />
                Options FollowSymLinks
                AllowOverride None
        </Directory>

WSGIScriptAlias / /srv/trac/www/cgi-bin/trac.wsgi

    <Directory /srv/trac/www>
        WSGIApplicationGroup %{GLOBAL}
        SetEnv trac.env_parent_dir /srv/proyectos
        Order deny,allow
        Allow from all
    </Directory>

    ErrorLog /srv/trac/www/log/apache-error.log
    CustomLog /srv/trac/www/log/access.log combined

</VirtualHost>
  • Creamos el directorio para los logs de apache:
mkdir /srv/trac/www/log && chown www-data.www-data /srv/trac/www/ -R
  • Modificamos el archivo trac.wsgi /srv/trac/www/cgi-bin/trac.wsgi:

Este queda:

#!/usr/bin/python
# -*- coding: utf-8 -*-

import sys
sys.stdout = sys.stderr

import os
import trac.db.postgres_backend
trac.db.postgres_backend.PostgreSQLConnection.poolable = False

os.environ['TRAC_ENV_PARENT_DIR'] = '/srv/proyectos/'

def application(environ, start_request):
    if not 'trac.env_parent_dir' in environ:
        environ.setdefault('trac.env_path', '/srv/proyectos/documentacion')
    if 'PYTHON_EGG_CACHE' in environ:
        os.environ['PYTHON_EGG_CACHE'] = environ['PYTHON_EGG_CACHE']
    elif 'trac.env_path' in environ:
        os.environ['PYTHON_EGG_CACHE'] = \
            os.path.join(environ['trac.env_path'], '.egg-cache')
    elif 'trac.env_parent_dir' in environ:
        os.environ['PYTHON_EGG_CACHE'] = \
            os.path.join(environ['trac.env_parent_dir'], '.egg-cache')
    from trac.web.main import dispatch_request
    return dispatch_request(environ, start_request)

Apache debe acceder al directorio de proyectos:

chown www-data.www-data /srv/proyectos -R
  • Y al directorio trac/htdocs:
chown www-data.www-data /srv/trac -R
  • Reiniciamos apache:
/etc/init.d/apache2 restart
  • Y ya podemos acceder a nuestra instancia vía la ruta del  virtualhost:

 http://host/documentacion

Quedando el directorio así:

.
|-- proyectos
|   `-- documentacion
|       |-- attachments
|       |-- conf
|       |-- htdocs
|       |-- log
|       |-- plugins
|       `-- templates
|-- repositorio
|   `-- documentacion
`-- trac
    `-- www
        |-- cgi-bin
        |-- htdocs
        |   |-- common
        |   |   |-- css
        |   |   |-- guide
        |   |   `-- js
        |   `-- site
        `-- log

(opcional) Configuración de múltiples ambientes (instancias)

Aunque se puede crear una base de datos para cada instancia, utilizaremos una única base de datos postgreSQL y schemas por cada instancia de Trac.

  • Inicializamos una nueva instancia:
trac-admin /srv/proyectos/lyx-book/ initenv
  • Configuramos la instancia:
Project Name [My Project]> Lyx Book

Database connection string [sqlite:db/trac.db]> postgres://tracuser:clavesecreta@localhost:5432/tracdb?schema=lyx
  • Propietario www-data a la carpeta del proyecto:
chown www-data.www-data /srv/proyectos -R
  • reiniciamos apache:
/etc/init.d/apache2 restart
  • Y ya podemos ver la nueva instancia en la lista de instancias:
  • al acceder al vhost, veremos la lista de instancias:

 http://host/

– Lista de instancias:

—————————————-

Available Projects

—————————————-

Autenticación inicial del Trac

La autenticación inicial se realizará vía htpasswd (en próximo artículo, agregaré la autenticación openldap).

  • Agregamos un usuario de sistema, para administrar el trac
useradd administrador
  • Creamos el archivo inicial para autenticar los usuarios con Trac
htpasswd -c /srv/trac/www/.htpasswd administrador
  • nota: inicialmente autenticamos con el usuario administrador, con la contraseña que le asignemos.
  • Y agregamos la entrada de autenticación al vhost del trac:
        <Location />
                AuthType Basic
                AuthName "Trac"
                AuthUserFile /srv/trac/www/.htpasswd
                Require valid-user
        </Location>
  • Luego, agregamos la info de autenticación via HTPASSWD al archivo de configuración de la instancia:
  • nota: el archivo de configuración de la instancia está en /srv/proyectos/{instancia}/conf/trac.ini, ejemplo:

archivo: /srv/proyectos/documentacion/conf/trac.ini

  • Agregamos la autenticación vía htpasswd:
[account-manager]
account_changes_notify_addresses =
password_file = /srv/trac/www/.htpasswd
password_format = htpasswd
password_store = HtPasswdStore
  • Le damos privilegios de TRAC_ADMIN al usuario administrador:
trac-admin /srv/proyectos/documentacion
  • Aparece la consola de la instancia de Trac:
-
Welcome to trac-admin 0.12.2
Interactive Trac administration console.
Copyright (C) 2003-2011 Edgewall Software

Type:  '?' or 'help' for help on commands.

Trac [/srv/proyectos/documentacion]>
  • Y en la consola ejecutamos el siguiente comando:
permission add administrador TRAC_ADMIN
  • Salimos de la consola:
>exit
  • Ejecutamos el upgrade de la instancia:
trac-admin /srv/proyectos/weyu upgrade
  • Y reiniciamos apache:
/etc/init.d/apache2 restart

Y ya podemos entrar al trac como el usuario administrador:

 http://host/documentacion/admin/

Ahora podemos personalizar ciertas opciones como incorporar plugins o agregar temas.

Incorporar un Tema a Trac

Para incorporar un tema a Trac, se debe primeramente incorporar el  http://trac-hacks.org/wiki/ThemeEnginePlugin Theme Engine Plugin

Instalación del Theme Engine Plugin

  • Descargamos el gestor de temas:
svn co http://trac-hacks.org/svn/themeengineplugin/0.11/ theme-engine
  • compilamos e instalamos:
cd theme-engine
python setup.py install
  • Habilitamos el theme engine plugin en el archivo conf/trac.ini
[components]
themeengine.* = enabled
  • Y reiniciamos el apache:
    /etc/init.d/apache2 restart

Ya podemos instalar un nuevo tema.

Instalar un Tema

  • Descargamos el tema que necesitamos:
svn co http://trac-hacks.org/svn/pydotorgtheme/0.11/ pydotorgtheme
  • Habilitamos el tema como plugin en el archivo conf/trac.ini
  • Se agregan a la sección ![components] del archivo trac.ini:
    pydotorgtheme.* = enabled
  • Habilitamos el tema en la sección ![theme] del archivo conf/trac.ini
[theme]
theme = PyDotOrg
  • Reiniciamos apache:
/etc/init.d/apache2 restart

Y ya contamos con un nuevo tema instalado.

Instalando un plugin de Trac

Para instalar un plugin de trac por la vía de la descarga, primero, ubicamos y descargamos la fuente;

  • Descargamos, el plugin de Mercurial
svn co http://svn.edgewall.com/repos/trac/plugins/0.12/mercurial-plugin
  • Nos movemos a la carpeta:
    cd mercurial-plugin
  • Ejecutamos la instalación del plugin:
python setup.py install
  • Y luego incorporamos dicho plugin al ‘conf/trac.ini’
[components]
tracext.hg.backend.*
  • Nota: podremos saber el nombre del componente a agregar en el archivo “setup.py > packages”.

Algunos plugins solicitarán actualizar (upgrade) de la instancia, para ello:

  • Ejecutamos en una cónsola:
trac-admin /srv/proyectos/documentacion upgrade
  • Y reiniciamos apache:
    /etc/init.d/apache2 restart

Configuración de repositorios

La configuración de repositorios (directorios donde se almacena código fuente versionado gracias a un VCS) depende de cada software de VCS utilizado, por defecto Trac gestiona Subversion, pero puede habilitarse para otros VCS.

Subversion

  • Instalamos subversion
aptitude install subversion libapache2-svn
  • Creamos la carpeta para el proyecto que deseamos versionar:
mkdir /srv/repositorio/proyecto-svn
  • Creamos el ambiente del proyecto SVN:
svnadmin create /srv/repositorio/proyecto-svn
  • Y le damos privilegio a apache para leerlo:
chown www-data.www-data /srv/repositorio -R
  • Entramos en el environment del trac:
trac-admin /srv/proyectos/documentacion
  • Agregamos el repositorio:
repository add proyecto-svn /srv/repositorio/proyecto-svn svn
  • nota: la sintaxis es: repository add {nombre} {ruta} {tipo}
  • Y ejecutamos la sincronización:
Trac> repository resync proyecto-svn 

Resyncing repository history for proyecto-svn ... 
0 revisions cached. 
Done.
  • Podemos ejecutar la resincronización de todos los repositorios existentes ejecutando:
repository resync '*'

Mercurial (Hg)

  • Instalamos el soporte a mercurial en nuestra distribución:
aptitude install mercurial
  • Descargamos el plugin
svn co http://svn.edgewall.com/repos/trac/plugins/0.12/mercurial-plugin
  • E instalamos el plugin de mercurial:
    cd mercurial-plugin
    python setup.py install
  • Configuramos el plugin de mercurial (hg) en el trac.ini
[components]
tracext.hg.backend.*
  • agregamos la configuración del plugin mercurial
    [hg]
    # -- Show revision number in addition to the changeset hash (defaults to yes)
    show_rev = yes
    # -- Changeset hash format
    node_format = short
  • Reiniciamos el environment de trac y apache:
trac-admin /srv/proyectos/documentacion upgrade && /etc/init.d/apache2 restart

Y ya tenemos configurado el soporte para Mercurial en Trac, ahora procedemos a agregar un repositorio:

  • Para agregar un repositorio Hg (Mercurial) creamos:
mkdir /srv/repositorio/hg/gnu
  • Nos movemos al directorio:
cd /srv/repositorio/hg/gnu/
  • Iniciamos Mercurial en la carpeta
    hg init
  • Y actualizamos:
    hg update
    0 files updated, 0 files merged, 0 files removed, 0 files unresolved
  • Entramos en el environment del trac:
trac-admin /srv/proyectos/documentacion
  • Agregamos el repositorio:
>repository add gnu-hg /srv/repositorio/hg/gnu hg
  • Y ejecutamos la re-sincronización:
    Trac [/srv/proyectos/documentacion]> repository resync gnu-hg
    Resyncing repository history for gnu... 
    0 revisions cached.
    Done.

GIT

Configurando Git

  • Instalamos lo necesario para git:
    aptitude install git git-core git-daemon-run
  • instalamos el plugin de GIT
    easy_install http://github.com/hvr/trac-git-plugin/tarball/master
  • Reiniciamos apache:
    /etc/init.d/apache2 restart
  • Agregamos la sección GIT al trac.ini
    [git]
    cached_repository = false
    persistent_cache = false
    shortrev_len = 7
    wiki_shortrev_len = 7
    git_bin = /usr/bin/git
    trac_user_rlookup = true
    use_committer_id = false
    use_committer_time = false
  • Y habilitamos el plugin (trac.ini)
    [components]
    tracext.git.* = enabled
  • Tambien agregamos la posibilidad de tener GIT post-commit hooks:
    [components]
    tracopt.ticket.commit_updater.committicketreferencemacro = enabled
    tracopt.ticket.commit_updater.committicketupdater = enabled
  • Y cambiamos esto (en el trac.ini):
    repository_sync_per_request = (default)

    — por esto:

    repository_sync_per_request =

Ya configurado GIT, creamos un repositorio.

Creación de un repositorio GIT

  • Creamos la carpeta:
mkdir /srv/repositorios/lyx-book
  • La convertimos en un repositorio git vacio:
    git --bare init
  • Nota: el directorio debe ser de tipo “bare”, ya que Trac debe tener acceso a los archivos de control (HEAD y config) de GIT y no solo el directorio .git/
  • Incorporamos los archivos necesarios, ejecutamos su adhesión al GIT:
    git add .
  • Ejecutamos el primer commit del repositorio:
    git commit -a -m 'first commit'
  • Verificamos su estado:
    git status
    # On branch master
    nothing to commit (working directory clean)
  • Cargamos la consola de la instancia:
    trac-admin /srv/proyectos/documentacion
    
    Welcome to trac-admin 0.12.2
    Interactive Trac administration console.
    Copyright (C) 2003-2011 Edgewall Software
    
    Type:  '?' or 'help' for help on commands.
    
    Trac [/srv/proyectos/documentacion]>
  • Incorporamos el repositorio:
repository add lyx-book /srv/repositorio/lyx-book git
  • Ejecutamos la sincronización:
    repository resync lyx-book

Conclusiones

Trac es una excelente herramienta  de SCM (Source Code Management) ya que combina Wiki, Gestión de incidencias (ticket, bug-tracking), gestión de código VCS y se le pueden incorporar plugins de terceros que incluyen desde un foro hasta un blog.

[PostgreSQL] Crear triggers dinámicos con postgreSQL

¿Qué es un trigger dinámico?, es aquel trigger que la metadata de en cual tabla/campo va a operar es pasado de manera dinámica (parámetros) a la función de trigger (trigger function).

¿Y para qué sirve?, bueno, imaginen un sistema dónde cada operación debe ser por ejemplo, agregada a una tabla auditoría, o por ejemplo, que una operación en una tabla, causa una operación en otra tabla, que aunque el código sea *casi* el mismo, depende de la tabla que dispara el trigger, qué tabla va a operar.

La utilidad de esto es simplemente poder re-utilizar una única funcion trigger para diversas acciones a ser tomadas de acuerdo a los parámetros recibidos.

El ejemplo

Este ejemplo se construyó durante un taller de postgreSQL que estaba dictando, el criterio era el siguiente:

  • El trigger toma el valor insertado en una tabla
  • Busca dicho valor en otra tabla, usando otro campo como criterio
  • Si el valor no existe, retorna NULL
  • Si el valor existe, retorna el objeto NEW del disparador, con lo cual la inserción sí ocurre

Los campos TG_*

En los disparadores de postgreSQL se cuenta con un conjunto de variables muy útiles, como son:

  • TG_OP: define la operación realizada en la tabla (INSERT, UPDATE o DELETE)
  • TG_TABLE_SCHEMA: define el schema al que pertenece la tabla (ej: “public”)
  • TG_TABLE_NAME: define el nombre de la tabla que disparó este trigger
  • TG_ARGV: es un arreglo (array []) que contiene los parámetros enviados a una función de trigger.

Con esto podemos hacer cualquier tipo de condicional en la función de trigger, reduciendo el código a sólo una función que se usará, de acuerdo a los parámetros que se le pasen.

La Función

CREATE OR REPLACE FUNCTION permitir_insert() RETURNS trigger AS

Comenzamos con la definición, la llamaremos “permitir_insert()” y obviamente, retorna un trigger.

luego, en la sección de declaración, definimos las únicas variables que vamos a necesitar para este ejemplo:

 vrecord integer;
campo text;
tabla text;
id int;
rc int;

BEGIN

En el cuerpo de la función, preguntamos qué tabla y campo voy a consultar para verificar si permito o no el insert, esto se hace consultando a TG_ARGV:

 tabla := TG_ARGV[0];
campo := TG_ARGV[1];

Como ven, ya que podamos recibir cualquier cantidad de parámetros en el trigger, las opciones son infinitas.

Ahora, necesito saber que hay en el campo trigger (NEW.campo), en este caso, debo reemplazar “campo” con el nombre del campo de la tabla que disparó el trigger (y que voy a consultar en otra tabla), como en mi caso el valor de el “campo” en todas las “tablas” que usarán esta función de trigger es entero, he declarado “vrecord” integer, si su tipo será distinto, sería conveniente declararlo “anyelement”.

EXECUTE 'SELECT ($1).' || quote_ident(campo) || '::text' INTO vrecord USING NEW;

Lo que hace ese código, es ejecutar un $1.”campo”::text (dónde campo es una variable) y mete su valor en la variable “vrecord”, se usa el objeto NEW para la sustitución del $1.

Ejemplo, si el campo se llama “piezas“, ese “EXECUTE” quedaría “NEW.piezas” y entonces metería el valor de NEW.piezas en la variable “vrecord”.

¿sencillo, no?.

La consulta

Ahora, debo verificar que en el campo “campo”::text de la tabla tabla::text (variable) existe un valor con lo que está contenido en “vrecord”, de lo contrario retorno NULL y el trigger no se ejecuta (la operación de inserción no ocurre).

Sería algo como un “constraint” pero sin usar reglas de constraint, ¿entendido?.

IF TG_OP = 'INSERT' THEN

EXECUTE format('SELECT '||quote_ident(campo)||' FROM '||quote_ident(tabla)||' WHERE '||quote_ident(campo)||' =$1') USING vrecord INTO id;

En este caso, he ejecutado un SELECT (SELECT “campo”::text FROM “tabla”::text WHERE campo::text = vrecord), claro que haciendo las conversiones y los reemplazos respectivos.

El valor de esa ejecución lo agrego a la variable id.

Si adicionalmente se desea averiguar si esa consulta anterior retornó filas, colocamos seguidamente al EXECUTE:

GET DIAGNOSTICS rc = ROW_COUNT;

Si “rc” es igual a cero, entonces no existe el valor “vrecord” en el campo “campo” de la tabla “tabla”, caso contrario, se retorna NEW.

 IF rc = 0 THEN
    RAISE EXCEPTION 'no existe el valor % en el campo % de la tabla %', vrecord, campo, tabla;
    RETURN NULL;
END IF;
RETURN NEW;

Y listo!, definimos el cierre y que esta es una función VOLATILE:

END;
LANGUAGE plpgsql VOLATILE

Y ya podemos usarla.

Usando la función dinámica

Para usar la función dinámica, simplemente creamos un trigger en cada tabla que necesite convocarla, pasando como parámetros de la función trigger la tabla referencia y el campo que debe evaluar, ejemplo:

CREATE TRIGGER trg_insert_detalle_reportes
BEFORE INSERT
ON reportes
FOR EACH ROW
EXECUTE PROCEDURE permitir_insert('reportes', 'id_reporte');

Se insertará un detalle de reporte, solamente si el valor de “id_reporte” aparece en la tabla “reportes”.

Conclusiones

Sé que parece muy “rebuscado” un ejemplo que bien podría salir con una clave foránea, pero sirve para el hecho de demostrar la posibilidad de obtener e iterar sobre el objeto NEW, consultar metadata al “information_schema” o realizar cualquier operación de manera dinámica, pasando parámetros y consultando las variables mágicas TG_* de postgreSQL.

¿Se les ocurre alguna idea para estos triggers dinámicos? …

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.

 

 

Haciendo bien tu trabajo …

Nadie puede negar la voluntad de trabajo de muchísimos venezolanos, el problema es que muchísimas veces (me incluyo) no lo sabemos hacer correctamente, lo cual explica la gran mayoría de los problemas que como país nos acontecen, desde el productivo y competitivo hasta el político-ideológico.

La necesidad es mala consejera, sobre todo cuando se trata de hacer algún trabajo “por la chamba y por los dineritos que me entrarán al hacerlo”, si en la fórmula no se incluye la mística necesaria para no solamente hacer bien nuestro trabajo, sino disfrutarlo, estaremos no solamente perdiendo nuestro tiempo, sino que, si seguimos pensando de manera egoísta, de dejar de hacer perder el tiempo (y un sinfín de cosas más, incluso la vida) a los demás.

Llegando bien a tu destino

Una de las cosas que más cuesta explicar es la labor de taxista en Venezuela, por cosas como la crisis, no solamente veras profesionales tras el volante (y hasta el ex-dueño de una constructora de casas a la que el gobierno jamás le pagó y se declaró en bancarrota), sino que verás gente haciendo la labor únicamente por la necesidad y sin la mística y dedicación necesaria para realizar el trabajo.

Siempre tengo anécdotas encontradas y divergentes acerca de los taxistas, desde el señor mayor que, con un carrito destartalado me llevó desde el Aeropuerto de Barcelona a mi destino y de paso, me esperó a que cenara en una arepera (donde también le brindé la cena y hablamos de su vida, de su anciana esposa muy enferma, lo que lo había llevado a dedicarse a ser taxista, del cómo los “taxistas oficiales” de la línea del aeropuerto no “le daban chance de trabajar” lo ninguneaban y lo relegaban a un rincón bastante alejado del andén principal, etc); pasando por el “taxi pirata” enfrente del C.C. Sambil que me dijo con actitud retrechera “son 150 Bolívares, si quieres no te montas, yo no llevo a nadie de gratis”, al señor de la línea del terminal de la Bandera en Caracas que me pidió permiso para meterse por “unos caminos verdes” para llegar más rápido, valorando así mi tiempo, hasta aquel que te hace perder el tiempo en una cola porque no se quiere desviar, las cosas son tan variopintas y anecdóticas como pudiera imaginarse.

Recordé todo esto hace unos días, tomé un taxi en el centro de Barquisimeto y el hombre, al ver que yo iba hacia el oeste, en vez de tomar la Ribereña, o bueno, tal vez no “desviarse” tanto, tomar la 14 ó la 16; el hombre como si nada permanece inmóvil (y con una cara de obstinación y stress que no se le puede poner peor) en una grandísima cola en la carrera 18 (para el que no lo sabe, el Barquisimeto es poco asiduo de “desviarse” de su ruta, y todos aprendieron a bajar y a subir la ciudad por las mismas calles y carreras), en cada calle que pasábamos le recordaba la “existencia” de la 16, le dije “mire, si nos desviamos acá, salimos a la Escuela Costa Rica, pasamos detrás del ambulatorio y agarramos la carrera 13 frente al San Juan”, el hombre simplemente dijo “ujum”, y siguió aferrado a su volante y mirando la cola, al llegar a la 38 fue igual, “mire, si doblamos acá, podemos agarrar la 14 allá abajo y salimos al parque ayacucho”, el hombre me miró con cara de “¡no me fastidies!” y siguió con actitud de Juan Peña en “El Diente roto” de Pedro Emilio Coll, así fue en cada calle hasta la calle 48, donde dobló, me dejó en mi destino (luego de una hora y cuarto de cola) y al pagarle ni las gracias me dió, es decir, hace más de media hora que me hubiera dejado en mi destino e incluso hubiera tomado ya otra carrera; pero capaz llegará a su casa, cansado y obstinado, peleando con su mujer diciendo “¡coño!, ¡no agarré casi carreras y me mamé unas colas terribles y varios clientes intensos y fastidiosos!” y tratará de preguntarse (sin respuesta obviamente) por qué le va mal en su trabajo …

Tal como el taxista que me llevó de Maiquetía a un hotel en La Guaira y aunque viendo que estaba lloviendo y yo llegaba con más de 90 kilogramos en maletas desde Guatemala; el hombre, a pesar de haberme cobrado *casi* como un pasaje Caracas-Barquisimeto, fue incapaz de estacionarse dentro del Hotel, ayudar a bajar las maletas o siquiera prestarme un paraguas; ¿para qué se dedica a ser taxista si no desea tener la empatía, la mística y el buen trato hacia sus clientes y sólo nos ve como máquinas que le damos dinero para que él mueva un volante y pise un freno y un acelerador? …

Ubicando bien tu negocio

Me encontraba muy temprano en la mañana en el andén del Terminal de pasajeros de Guanare, me pega el hambre y llamo a una señora, que cava en mano, carga pastelitos y empanadas y pasea por todos los andenes del mismo; mientras echo la mirada al horizonte, veo en la cerca perimetral, que queda colindante a un barrio, una joven, con una mesa, una cava con empanadas, una sombrilla, sentada mirando su celular, me pregunté ¿qué diferencia hay entre esa joven y esta señora?, ambas venden empanadas, ambas deben pararse muy temprano a hacer las empanadas y ambas tienen una cava, la diferencia notable es que la joven se sienta enfrente de su casa (no hay muro que evite que ella pueda entrar al terminal de pasajeros) y la señora toma su cavita y pasea por todo el anden, es probable que la señora termine antes que la joven, también es probable que la joven finalice el día más descansada que la señora, ¿quien lo está haciendo bien? …

Como aquella persona que se dedica a vender aceites y lubricantes para motor simplemente poniendo una mesa y un letrero en la puerta de su casa (como si viviera en un lugar extremadamente concurrido lleno de talleres mecánicos y vehículos) , puede que te levantes muy temprano a trabajar, pero no te estás ubicando correctamente, no es lo mismo vender café en la emergencia de un hospital que vender café a la salida de un jardín de niños y escuela primaria (si, he visto ese caso); también es el caso de que se ha fomentado, con exacerbado ahínco, que una persona con una silla, una mesa, una sombrilla, un par de celulares y una cestita llena de caramelos de menta para dar cambio, es un empleado formal muy bien organizado.

Transito informal

Siempre he dicho (con el perdón de los funcionarios), que el trabajo peor ejecutado en Venezuela, es el de los fiscales de tránsito, tal vez son pocos los que “se portan mal”, pero como acá en Venezuela, las cosas que ocurren mal hacen más ruido que las buenas, pues es lo que más se ve y escucha.

Imaginen el caso, Avenida Lara esquina Avenida Bracamonte de Barquisimeto, corredor vial, esquina (y con semáforo), rayado de acera en rojo, zona bancaria (bancos Del Tesoro y Venezuela) y aún así, jamás verás allí un par de fiscales dirigiendo el tráfico y peor aún, verás muchos vehículos estacionados incluso frente a la zona bancaria, incluso si desearan “portarse mal” y *matraquear* a malos conductores, ¡ese sería un paraíso!, sin embargo, lo más que verás será en cualquier otra esquina, un par de conos y ellos parando taxistas pidiendo papeles y “pidiendo para el refresco”.

¿se imaginan cómo serían de transitables nuestras avenidas y calles si cada fiscal “hiciera su trabajo” y ya le hubieran revocado la licencia a más de un multi-infractor loco que anda por las calles?, ¿se imaginan lo práctica que sería Caracas si no cualquiera que tuviera plata, pudiera tener carro y tener licencia con sólo pagar 500 mil sin tener siquiera que hacer examen?, ¿cuanta informalidad más cabrá dentro del rol de fiscal de tránsito, hasta que nos demos cuenta que es gracias a ellos (y culpa de ellos) que sigan en las calles gente que le tranca el paso a una ambulancia, hace doble (y triple) fila en un cruce, se atraviese en la encrucijada luego de comerse el semáforo, o crean que las avenidas son para detenerse y echar cuentos con el motorizado de al lado?.

Política informalizada

En estos últimos quince años, al igual que los taxistas, hemos tenido la más variopinta clase de funcionarios detrás de los organismos, desde veterinarios como Ministros de Salud, hasta filósofos en carteras de economía, acá todo el que quiera “echarle bolas” en un cargo lo hace así no tenga ninguna experiencia en el mismo, ¿las consecuencias?, pues las estamos viviendo ahora.

No estoy en contra de una persona no graduada en algo para poder ejercerlo, pero una cosa sin ecuanón es que debe, “al menos” ser docto, mi amigo Hector Colina podrá ser historiador, pero es un experto del software libre mucho más erúdito que muchos ingenieros graduados de conozco; pero hay graduados en una carrera, que ni en su propia área la pueden ejercer bien.

No hay mejor ejemplo que CONAVI, la Comisión Nacional de la Vivienda, durante 15 meses el arquitecto “y poeta productor de cine” Farruco Sesto, fue su presidente, fue tan funesto su paso por allí que el presidente Hugo Chávez deshizo el organismo luego que su titular admitiera en cadena de radio y televisión que cuando llegó al mismo “no tenía idea alguna de lo que era hacer casas populares” y finalizó su paso en 2009 sin una sola urbanización inaugurada por este organismo, llevando a la “emergencia” que hoy es “La Gran Misión Vivienda Venezuela”.

Es que precisamente la mayoría de las misiones y grandes misiones salieron, de la incapacidad de los organismos titulares de hacer las cosas bien, de hacer su trabajo como es debido.

¿Acaso se necesitaría Misión Saber y Trabajo si los ministerios de comercio e Industria se dedicaran al fomento y creación de empresas con el fin de emplear a toda esa mano de obra desempleada?, ¿necesitaríamos una Misión “En amor mayor”, si el IVSS no fuera una maraña inexpugnable de burocracia e ineptitud?.

Es que la creación de una Misión (estructura informal, adscrita directamente a la presidencia de la república, con presupuesto propio y accionar directo desde el consejo de ministros) es una demostración tácita de que el organismo (y los funcionarios que lo rigen) no están haciendo el trabajo como es debido (o ni siquiera lo están haciendo bien) y es una llamada de alerta para la re-estructuración; pero, con 33 ministerios, varias decenas de vice-ministerios y más de 30 misiones, está más que demostrado que hay mucho político allí que no está haciendo bien su trabajo …

La libertad de no hacerlo

Hay 2 cosas por las que hago mi trabajo, la libertad plena de desenvolverme y por la posibilidad de disfrutarlo; si, como todo el mundo tengo mis carencias y mis necesidades, pero eso no significa que voy a salir a la calle a vender SAINT (no solamente porque sea un software propietario sino porque simplemente no entiendo nada de administración y contabilidad); respeto a los demás, así que tengo la libertad de decir “no” cuando el momento impone hacer algo que o no me gusta o no se hacer; en Venezuela existe la tradición de “tirar flechas”, decir que “se sabe algo” sin saber y luego comienzas a lanzar ideas y teclas como flechas, a ver si pegas alguna.

Por algo, por mucha necesidad que tenga, no me verán instalando servidores Windows 2008, eso se llama “convicción”, y mi abuela me enseñó que las convicciones son los cimientos de la moral  …

 

¿alguna vez se han puesto a pensar cómo sería nuestro país si cada uno hiciera bien su trabajo?

 

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!

 

 

 

Linux Disks: Rescatando data de un disco de portátil VIT de las garras de la muerte

Mil disculpas por tener abandonado el blog!, ciertamente el no tener portátil y trabajar con portátil prestada, me limita en las cosas que podría y/o debería hacer en el equipo, además el trabajo, múltiples ocupaciones hacen imposible dedicarle mucho tiempo a escribir …

Pero sucedió algo … ;-)

Me encontraba usando una portátil VIT (modelo 2400), en vista que mi anterior portátil Thinkpad fue robada en diciembre pasado, con el equipo todo iba bien salvo algunas cosas:

  • Ligeros congelamientos en el mousepad
  • Keycodes disparados (visibles en el dmesg) sin haber presionado ninguna tecla especial
  • Algunos problemas con la red
  • Incompatibilidad con Debian Jessie e imposibilidad de usar un kernel liquorix con la tarjeta inalámbrica que trae.

Bueno, todo iba bien con el equipo, hasta que un día, de improviso y sin siquiera avisarlo el smartctl, el disco duro se congeló!, el equipo literalmente se congeló por completo, una larga espera y tuve que apagarlo forzado.

Al encender, veo que insólitamente el BIOS ni siquiera ve el disco!, es decir, el disco duro se ha “esfumado”, tratando de “dilucidar” tan extraño comportamiento de la BIOS (imaginándola tal vez desactualizada y jamás dudando de un disco duro SATA3 de menos de un mes de uso), decido probar suerte y meto un Live-USB de Debian Installer.

Pero, por si acaso, presiono “TAB” para editar la entrada del “Advanced Options > Rescue Mode” y escribo:

idebus=66 pci=routeirq

La primera opción, hace que el disco funcione como un IDE-66 (PATA-compatible) y la segunda opción cuestiona la decisión de asignación de IRQ de la tarjeta madre y decide que el kernel la haga por si mismo (esto me permite en algunas tarjetas madre “buggy”, como la que usan en VIT, detectar hardware con problemas).

Insólito!, el disco aparece en el dmesg!

[ 2377.833672] end_request: I/O error, dev sdb, sector 4007
[ 2377.833689] sd 9:0:0:0: [sdb] Unhandled error code
[ 2377.833695] sd 9:0:0:0: [sdb] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
[ 2377.833708] sd 9:0:0:0: [sdb] CDB: Read(10): 28 00 00 00 0f a7 00 00 08 00
[ 2377.833745] end_request: I/O error, dev sdb, sector 4007
[ 2377.833767] sd 9:0:0:0: [sdb] Unhandled error code
[ 2377.833774] sd 9:0:0:0: [sdb] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
[ 2377.833784] sd 9:0:0:0: [sdb] CDB: Read(10): 28 00 00 00 0f a7 00 00 08 00
[ 2377.833820] end_request: I/O error, dev sdb, sector 4007
[ 2414.775081] sd 9:0:0:0: [sdb] Unhandled error code
[ 2414.775083] sd 9:0:0:0: [sdb] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
[ 2414.775086] sd 9:0:0:0: [sdb] CDB: Read(10): 28 00 00 00 00 41 00 00 02 00

Ahora bien,eso realmente no significa mucho, el disco da problemas de montaje, sin embargo, el DRIVER_OK me causa sospechas, ¿y si el disco está bueno, pero la lógica de comunicación de la tarjeta madre está operando mal?, entonces apago el equipo y reinicio el sistema de rescate, pero esta vez con dos opciones más:

libata.force=noncq libata.atapi_passthru16=0 idebus=66

Con la primera opción, fuerzo la desactivación del NCQ, es un sistema de cola de comandos de 32bits que utilizan los discos SATA y SSD más modernos para comunicarse con la tarjeta madre, un error en la lectura de comandos por parte de la controladora ATA puede “simular” un fallo de hardware y desactivar el disco; por ende, desactivar el NCQ puede ayudar a la controladora SATA a entender al disco duro.

La segunda opción, me permite tratar al disco como si fuera un viejo IDE, desactivando el soporte a comandos de 16 bits.

Con estas dos opciones, mágicamente el disco duro ahora es perfectamente detectado, he montado un disco externo, rescaté los datos a dicho disco externo y listo!, datos del disco duro “dado por muerto” rescatados.

¿y qué pasará con la portátil?

Aunque pudiera desactivar el modo AHCI en el BIOS y funcionar en modo IDE y pudiera luego pasar estas opciones en el GRUB, ciertamente estas opciones hacen que el disco vaya a muchísima menos velocidad que en condiciones normales, cómo la única posible solución documentada es una actualización del BIOS que le permita actualizar la tabla APCI y corregir el bug NCQ de la controladora ATA; será mejor devolver el equipo ya que al ser un equipo VIT ensamblado en Venezuela con piezas chinas, es poco probable que el proveedor de piezas de VIT haya sacado alguna “actualización de seguridad” del BIOS VIT.

Si a alguno le quedó el disco como “desaparecido del BIOS” en una VIT y necesitan con urgencia sacar unos datos, les indico que esta es la solución de resurrección más idónea.

Si alguien sabe como “actualizar” el BIOS de una VIT, me avisa …

Actualización

Luego de “despertar” al disco con “idebus=66 libata.force=noncq” y apagar inmediatamente el equipo, EL EQUIPO ENCENDIÓ!, normalmente, salvo que al llegar al GRUB, por precaución agregué ámbas opciones (idebus=66, libata.force=noncq) y pude llegar al GNOME para sacar sin apuro y con más vigilancia (y con un entorno gráfico) algunas cosas que no había respaldado.

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!

Seguir

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

Únete a otros 3.063 seguidores

%d personas les gusta esto: