“Flasheando” la ROM de un móvil chino: UMI X2

Josemaría | 17 de diciembre de 2013 | 19 comentarios

móviles UMI X2 personalizado con Yandex ShellY si. Al final yo también he “caído” y me he comprado un móvil chino. En china, quiero decir, porque todos los que estáis leyendo esto y tenéis móvil también tenéis un móvil chino ;-)

Las motivaciones han sido varias pero la fundamental es que quería un móvil decentito para poder trastear con él y lo quería a un buen precio y totalmente libre: sin ataduras a ningún proveedor y con privilegios de root. Me niego a hacer el “paripé” de comprarlo bloqueado y luego rootearlo. No me entra en la cabeza que nadie me venda un pequeño ordenador de bolsillo y me limite lo que puedo hacer con él, la verdad.

Después de mirar mucho por ahí mis dos finalistas fueron el UMI X2 y el Jiayu G4. El primero un clónico de los Galaxy de Samsung, el segundo una imitación de los iPhone de Apple. En esas estaba cuando mi amigo Guillermo escribió en su blog que se había comprado un UMI, que estaba satisfecho y daba las pistas necesarias para que quién le tuviera miedo a la puesta a punto inicial no se lo pensara demasiado. Cuatro semanas y poquito más de 200€ después lo tenía en casa. Si dudas sobre donde comprarlo puedes empezar por mirar en Antelife (casi siempre con los mejores precios) o en Pandawill, AliExpress, Banggood, FocalPrice, etc.

Yo voy a seguir por aquí donde lo dejó Guillermo. ¿Que hacemos si queremos instalarle una ROM personalizada? Necesitaremos una Tarjeta SD y elegir la ROM adecuada. La mejor base de datos está en needrom. Como podemos ver, todas derivan de la versión 4.2.1 de Android que es la que lleva la última oficial del fabricante. Es decir, que realmente se tratan de personalizaciones más o menos atrevidas de la versión oficial. De entre todas ellas, una de las más descargadas la cocinan en perfecto castellano y cuenta con un estupendo soporte desde este hilo de los foros de htcmania. Tiene detrás ocho versiones ya y parecía estable y muy depurada, así que es una buena elección para empezar.

ACTUALIZACIÓN: Si preferís probar con una ROM basada en CyanogenMod tenéis dispobible esta otra, también con soporte y desarrollo en español. Está basada en Android 4.2.2 y en CyanogenMod 11 y también va fenomenalmente bien. Parece que este terminal ha dado fuerte en territorio patrio ¿no?

Menú principal de Mobileuncle Tools Lo primero que necesitamos es cambiarle a nuestro teléfono el ClockWorkMod Recovery (en adelante CWM que es como se lo suele llamar), un pequeño programita (casi un mini sistema operativo) que traen todos los Android como arranque de emergencia y que suele invocarse cuando encendemos el móvil pulsando simultáneamente durante unos segundos la tecla de encendido y la de subir el volumen. Un usuario ha recogido en este enlace de Mega algunos de los CWM que van bien con el UMI X2 y todo el mundo parece estar de acuerdo en que la versión 6.0.3.0 de Bruno Martins es la mejor. Para reemplazar el CWM existen diferentes herramientas. Yo he usado Mobileuncle Tools. Una vez instalada y con el archivo img de la CWM en la tarjeta SD entramos en la aplicación y desde su menú principal elegimos la opción de “Cambiar Recovery”. Elegimos el archivo y listo. Si tenemos también el zip con la nueva ROM en la SD y estamos convencidos de realizar el cambio sólo tenemos que pulsar en la opción de “Modo Recovery”. Nuestro móvil reiniciará y, si todo ha ido bien, entrará en el menú del CWM.

En la siguiente fotografía tenéis una muestra de lo que deberíais de encontraros. Un menú en el que os desplazáis arriba y abajo con las teclas de volumen y elegís una opción con la tecla de encendido.

CWM 6.0.3.0 de Bruno Martins

Las opciones que tenéis que utilizar antes de flashear la nueva ROM son tres:

Hasta aquí aún no habéis hecho nada “irremediable” en vuestro móvil. Si os entra el pánico y reiniciais (opción “reboot system now”) el móvil arrancará perfectamente pero, eso si, tal y como si lo hubiérais sacado de la caja, perdiendo todas las instalaciones y configuraciones que le hayáis hecho. Si decidís seguir adelante aseguraos de que la batería no esta agotándose (mejor si tenéis el móvil conectado a corriente durante el proceso) y adelante. ¡Vamos, valientes! Lo único que os resta es elegir la opción de “Install zip from sdcard” y seleccionar el archivo donde está la ROM que queréis instalar. Si habéis elegido la que os he recomendado por ahí arriba os saltará un instalador gráfico que usa la interfaz táctil del móvil (si, si, habéis oído bien: Aroma Installer es una virguería que alguien se ha currado muy bien y que permite instalar una ROM en tu android de esta forma), que os hará unas preguntas mínimas sobre lo que queréis hacer y que, al terminar, reiniciará con vuestra nueva y flamante ROM.

Un par de cosas para terminar. Si os aficionáis a esto de probar diferentes ROMs (¡es adictivo!) os daréis cuenta que el verdadero coñazo viene después a la hora de volver a instalar las aplicaciones que usas, configurar las cuentas, etc. Una aplicación que te permita hacer backups previos de datos y programas (Titanium Backup es la que yo uso) te evitará pasar por esto si haces una copia previa antes de instalar una nueva ROM. Y dos: recuerda que en ningún momento hemos hecho una copia de seguridad de tu ROM antigua. Si te interesa puedes hacerlo a través del propio CWM que tiene las opciones para hacer backup y restore. También puedes buscarte una ROM original de UMI para tenerla en caso de emergencia. Pero recuerda que este tipo de móviles no tienen soporte técnico en nuestro país, así que si te equivocas o algo sale mal en el proceso deberías de estar seguro de poder resolverlo por ti mismo. Si eres cuidadoso y sigues al pié de la letra lo que hemos visto aquí es bastante improbable, pero puede pasar.

NOTA FINAL: Los expertos de estas cosas recomiendan que hay que recalibrar la batería del móvil después de instalar una nueva ROM para asegurarnos de que el nivel de batería que se nos indica es correcto. Para ello hay que instalar una de las muchas aplicaciones que existen (yo uso Battery Calibration), dejar que se agote completamente la batería, volver a cargarla al 100% y luego calibrar desde la aplicación que hayamos elegido.
Compártelo:
    emailPDFPrintBitacoras.comIdenti.caTwitterdel.icio.usDiigoFacebookMeneameBarraPuntoNetvibes
Categorías: android, howto´s
Etiquetas: , , , , ,

Backups y recuperación de datos en PYMEs

Josemaría | 16 de diciembre de 2013 | Comentar
Una buena ración de estadísticas para preocuparse un poco…
especiales Según un reciente estudio realizado entre SMBs (“Small and Medium Business”, el nombre que reciben nuestras PYMES en el mundo anglosajón) de Estados Unidos, Francia, Alemania y Reino Unido por una importante empresa del sector de la virtualización, el 85% de los interrogados tenían problemas con el coste de sus soluciones de backup, el 83% con la capacidad o el espacio de almacenamiento requerido por las mismas y el 80% con la complejidad técnica necesaria para su uso.

El estudio no tiene desperdicio y hay muchas otras cifras interesantes en él. A veces, cuentan, recuperar un simple correo electrónico borrado puede llevar hasta 12 horas, el 17% de las recuperaciones de datos que se realizan presentan algún tipo de problema o error y hasta el 55% de las empresas está considerando cambiar sus métodos de backup para el año que entra.

No conozco ningún estudio similar en nuestro país, pero lo que he visto en las PYMEs (y también en alguna gran empresa) en las que he tenido algo que ver en los últimos años es similar a lo que se cuenta aquí. O, incluso, peor. Lo que me sigue sorprendiendo es la desidia a implementar soluciones robustas en este terreno cuando todos sabemos que los discos duros fallan (¡y mucho!), pero sobre todo que las personas cometemos errores y, más a menudo de lo que nos gustaría, borramos archivos por error. O de forma malintencionada. Mirad, si no, lo que ha ocurrido en la UGT hace bien poco ;-)

De lo segundo es bastante difícil conseguir datos fiables, pero de lo primero hay suficientes números como para echarse a temblar. El tiempo de vida medio de un disco duro en un entorno empresarial se estima en entre tres y cinco años. Los estudios realizados por Google dicen que a partir del segundo año la probabilidad anualizada de error en un disco se dispara al 8% y se mantiene entre este valor y el 10% en los tres años siguientes. Los estudios de ExtremeTech indican un porcentaje menor de errores en el segundo año pero los disparan a cerca del 12% a partir del tercero. Y ¿son más fiables los nuevos discos SSD? Es difícil comparar una tecnología con poco más de cinco años con otra de más de 50, pero los pocos estudios que se han hecho por el momento indican que el incremento en la fiabilidad de esta tecnología es escaso o inexistente.

Las técnicas de backup y de recuperación de datos son, hoy en día, inexcusables en un entorno informático y, si me apuran, en el personal. Cualquier empresa que se precie debería de tomarse ambas cosas muy en serio y asegurarse de que usa mecanismos acordes a lo que trata de proteger. Porque luego lamentarse es gratis, pero no sirve ya de nada.

Referencias:

Compártelo:
    emailPDFPrintBitacoras.comIdenti.caTwitterdel.icio.usDiigoFacebookMeneameBarraPuntoNetvibes

Pollo con níscalos

Josemaría | 30 de noviembre de 2013 | Comentar

icono distintivo de los textos de recetas de cocina Hacía tiempo que no veía los níscalos tan baratos como este otoño, así que anotad y, si aún llegáis a tiempo, aquí tenéis una receta de esas facilonas pero que quedan deliciosas.

Pollo con Níscalos
Se salpimenta el pollo (en no más de ocho o 10 trozos y sin piel) y se sofríe en la cazuela con aceite de oliva. Cuando esta doradito se saca, se reserva y en el mismo aceite y grasa que ha soltado pochamos los dientes de ajo, la cebolla y el pimiento verde bien picaditos. Añadimos el tomate triturado y después de unos minutos echamos los níscalos (extremadamente bien limpios y troceados con las manos), el pollo, las hojas de laurel y un vaso (unos 25 cc.) de cava. Dejamos cocer 20 o 25 minutos a fuego lento y listo para comer.

Compártelo:
    emailPDFPrintBitacoras.comIdenti.caTwitterdel.icio.usDiigoFacebookMeneameBarraPuntoNetvibes

7 enlaces 7 (y LIV)

Josemaría | 7 de noviembre de 2013 | Comentar

enlaces rápidos

Compártelo:
    emailPDFPrintBitacoras.comIdenti.caTwitterdel.icio.usDiigoFacebookMeneameBarraPuntoNetvibes
Categorías: enlaces rápidos
Etiquetas:

RAID por software en Debian 7 con mdadm

Josemaría | 23 de octubre de 2013 | 2 comentarios

hard disk Para el que no lo sepa, un RAID en informática no es una carrera de aventuras sino un disco duro lógico creado a partir de la union de dos o más discos duros físicos con objeto (por lo general aunque no siempre) de proporcionar tolerancia a fallos. Las siglas vienen de Redundant Array of Inexpensive Disks y hace referencia a que, en su día, constituían una alternativa para proporcionar un almacenamiento seguro usando discos baratos en lugar de unos mucho más caros (por lo general SCSI). Ahí está la wikipedia para quién quiera aprender un poquito más ;-)

El método más seguro de usar esta tecnología es mediante hardware dedicado. Eso que quede claro. Pero cuando no queremos o no podemos gastarnos el dinero que esto requiere tenemos la alternativa de implementarlo mediante software. En Linux tenemos para ello mdadm, una herramienta en línea de comando muy sencilla de usar si entendemos los conceptos básicos de lo que estamos haciendo.

La instalación en una Debian es así de sencilla:

apt-get install mdadm

El script de configuración posterior a la instalación sólo nos planteará dos cuestiones. Leelas atentamente (como siempre… ;-) ). En la primera se nos pregunta si el sistema de ficheros raíz de nuestro Linux estará en un RAID con objeto de iniciarlo antes de la secuencia de arranque. En este ejemplo le diremos que no puesto que sólo usaremos RAID para los discos de datos, así que responderemos con none como se nos indica en el mensaje siguiente:

Instalación de mdadm en Debian Linux
En la segunda pregunta se nos interroga acerca de si queremos que los discos RAID que vamos a crear se inicialicen de forma automática durante cada inicio de la máquina o si preferimos hacerlo nosotros manualmente. Contestaremos que queremos que lo haga de forma automática.

Instalación de mdadm en Debian Linux
Una vez instalado mdadm ya podemos crear nuestro RAID. En el ejemplo que vamos a ver crearemos un RAID5 con tres discos de 500GB. El comando lsblk es muy cómodo para ver que asignación de nombres le ha hecho nuestro sistema a estos dispositivos:

Comprobando la asignación de nombres de dispositivos a nuestros discos duros con lsblk
El comando básico para crear un RAID es este:

mdadm --create dispositivo-md --level=x --raid-devices=z dispositivos-sd

O en formato abreviado:

mdadm --create dispositivo-md -l x -n z dispositivos-sd

Donde x es el nivel de RAID (admite los básicos 0, 1, 4, 5, 6, 10 y alguno más) y z el número de discos que formarán el array. El dispositivo-md será el nombre de dispositivo que recibirá el nuevo disco lógico (y que debería de estar en el directorio /dev y, por convención, llamarse md seguido de un número, por ejemplo /dev/md0) y los dispositivos-sd serían los discos físicos que forman el array separados por espacios (por ejemplo /dev/sdb /dev/sdc). Podemos añadir también la opción --verbose para obtener información más detallada del proceso de creación y los posibles fallos. Veamos un par de ejemplos:

Para crear un RAID0 con los tres discos indicados:

mdadm --create --verbose /dev/md0 --level=0 --raid-devices=3 /dev/sda /dev/sdb /dev/sdc

Para crear un mirror (RAID1) con los discos indicados:

mdadm --create /dev/md0 -l 1 -n 2 /dev/sdb /dev/sdc

La creación admite, aparte de estas, otras opciones avanzadas que puedes consultar en el manual que se ha instalado con él (man mdadm). Y vamos ya a seguir con nuestro ejemplo. Para crear el RAID5 que necesitamos ejecutamos lo siguiente:

mdadm --create --verbose /dev/md0 --level=5 -n 3 /dev/sdb /dev/sdc /dev/sdd

Si todo ha salido bien se nos mostrarán algunos mensajes informativos y el comando finalizará indicando que el disco md0 ha sido inicializado y arrancado. Podemos comprobar el estado de nuevo con lsblk o con more /proc/mdstat
Comprobando el estado de un RAID5 recién creado con mdadm

Para poder utilizar nuestro disco debemos aún formatearlo y montarlo en nuestro sistema de ficheros. Vamos a formatearlo como ext4 y a montarlo en un directorio que se llame datos dentro del subdirectorio /mnt:

mke2fs -t ext4 /dev/md0
mkdir /mnt/datos
mount /dev/md0 /mnt/datos

Si usamos ahora, por ejemplo, el comando df (df -k /mnt/datos) para ver el espacio de la partición y el porcentaje de uso veremos que, efectivamente, disponemos de cerca de 1TB correspondiente al tamaño del RAID5 con tres discos de 500GB que hemos montado.

Nos falta aún algo más. Durante la instalación le hemos dicho a mdadm que inicie de forma automática todos los arrays, pero eso no significa que los monte en el sistema de ficheros. Si queremos que lo haga automáticamente en cada arranque y en el mismo directorio donde lo acabamos de hacer de forma manual, tendremos que añadir una línea como la siguiente al fichero /etc/fstab:

/dev/md0  /mnt/datos  ext4  defaults  0  1

Vamos a echarle ahora un vistazo a diversos comandos de gestión y monitorización. Si queremos detener el volumen usamos el argumento --stop. No olvides desmontarlo antes para evitar que haya pérdida de datos:

umount /dev/md0
mdadm --stop /dev/md0

Luego, para volver a arrancarlo de forma manual:

mdadm --assemble /dev/md0 /dev/sdb /dev/sdc /dev/sdd

Y si habíamos incluido la línea que indicamos antes en el fichero fstab para volver a montar el disco en nuestro sistema de ficheros basta con hacer esto:

mount /dev/m0 /mnt/datos

Para ver información de todos los arrays que tenemos en funcionamiento en la máquina usamos el argumento --detail:

mdadm --detail --verbose --scan

Información de los RAID en una máquina con mdadm

Sólo tenemos uno, claro. Para ver información en detalle del mismo:

mdadm --detail --verbose /dev/md0

Información en detalle de un RAID con mdadm

O también podemos usar el argumento --examine para ver información y el estado de cualquier a de los discos que forman nuestro array:
Información en detalle de uno de los discos de un RAID con mdadm

Vamos a simular ahora la rotura de uno de los discos. Para ello apagamos la máquina bruscamente y desconectamos uno de los tres discos del RAID. Podemos hacer fácilmente esta prueba tanto en una máquina real (¡que no esté en producción!) como en una virtual. Tras arrancar de nuevo nuestro RAID habrá perdido la tolerancia a fallos. No obstante, si hemos creado o copiado datos en el directorio /mnt/datos veremos que estos siguen siendo perfectamente accesibles.

OJO: Si el RAID no estaba aún totalmente inicializado (hemos usado discos muy grandes y no ha pasado suficiente tiempo desde su creación o desde la última vez que se recuperó de un fallo) el volumen no arrancará correctamente. Es por tanto muy importante no comenzar a usarlo hasta que no se ha inicializado completamente y extremar las precauciones después del fallo de algún disco hasta que volvemos a recuperar la tolerancia a fallos. Si miramos el pantallazo de aquí arriba en el que aparece la salida de ejecutar more /proc/mdstat vemos que allí aparece una barra de progreso donde se indica el estado de creación o reconstrucción del RAID. Mientras que esa barra no llegue al 100% y desaparezca mejor que no tengas ningún problema ;-)

Para recuperar la tolerancia a fallos debemos de añadir un disco nuevo. Lo hacemos y una vez arrancada de nuevo la máquina ejecutamos lo siguiente para añadir el disco /dev/sdc a nuestro RAID en sustitución del que hemos simulado que se ha roto:

mdadm /dev/md0 --add /dev/sdc

El RAID se reconstruirá sólo de forma automática pero dependiendo del tamaño y del volumen de datos podrá tardar más o menos tiempo. Observa de vez en cuando la salida de more /proc/mdstat para estar al tanto.

OJO: Después de perder un disco los nombres de los dispositivos pueden haber ??bailado?. Es muy importante que comprobemos antes (con lsblk, por ejemplo) cuales son los que siguen formando parte del array y cual el nuevo que queremos añadir.

Si lo que queremos es añadir al RAID un nuevo disco para que sea usado como hot spare basta con sumarlo a un RAID ya creado y funcional con el mismo comando que usamos antes para añadir un disco a un RAID estropeado:

mdadm /dev/md0 --add /dev/sde

Si lo que queremos es añadir el disco para agrandar el tamaño del RAID y no para que sea usado como hot spare tendríamos que usar los siguientes comandos:

mdadm /dev/md0 --add /dev/sde
mdadm --grow /dev/md0 ??raid-devices=4

En el fichero /proc/mdstat podemos ver el proceso como siempre:
Haciendo crecer nuestro RAID añadiendo un nuevo disco

Lo que no nos va a resolvernos mdadm es hacer que la partición que habíamos creado en el disco y sobre la que estábamos trabajando crezca. Eso es tarea nuestra:

umount /dev/md0
e2fsck -f /dev/md0
resize2fs /dev/md0
mount /dev/md0 /mnt/datos

Y el resultado:
Extendiendo la partición de un RAID al que hemos añadido un nuevo disco

NOTA: Como se puede observar, durante este último proceso de crecimiento del RAID hemos trabajado con cuatro discos (tres originalmente) de 1GB cada uno en lugar de los de 500GB que hemos usado en el resto del tutorial. Quería que se apreciara el cambio de tamaño del volumen y la resincronización de discos tan grandes habría supuesto tener que esperar muchas horas para poder visualizar el proceso completo.

Si lo que queremos es eliminar uno de los discos del RAID (para reemplazarlo por otro, por ejemplo) tenemos antes que marcarlo como fail. Luego lo eliminamos:

mdadm /dev/md0 --fail /dev/sdd
mdadm /dev/md0 --remove /dev/sdd

Y si quisiéramos eliminar el RAID usamos este comando:

mdadm --remove /dev/md0

mdadm tiene también un argumento llamado --monitor que le permite generar alertas cuando ocurre alguna incidencia en el RAID. Por defecto en una Debian el monitor se arranca como un daemon que graba las incidencias en el fichero de logs de la máquina (/var/log/syslog) de esta forma:

mdadm --monitor --pid-file /run/mdadm/monitor.pid --daemonise --scan --syslog

Si, además, quisiéramos que nos enviara dichas incidencias a nuestra cuenta de correo deberíamos de añadir la opción --mail:

mdadm --monitor --pid-file /run/mdadm/monitor.pid --daemonise --scan --syslog --mail josemaria@uponday.net
Compártelo:
    emailPDFPrintBitacoras.comIdenti.caTwitterdel.icio.usDiigoFacebookMeneameBarraPuntoNetvibes

En bici por Madrid (y II): la nueva M-10

Josemaría | 14 de octubre de 2013 | Comentar

Hace casi exactamente siete años que, después de traerme mi bici a Madrid, escribí estas tristes líneas. La entrada se ha convertido en una de las 5 más vistas del blog con una media de cerca de 1.000 visitantes distintos mensuales. Esto demuestra dos cosas: que Google es bastante más malo de lo que nos pensamos y que en Madrid existe un gran interés ciudadano por poder usar la bici en el día a día.

En estos siete años las cosas han cambiado poco. Madrid sigue siendo una ciudad incómoda para usar la bicicleta como medio de transporte. El tráfico es demasiado agresivo y no existe cultura de bici ni apoyo institucional para que las cosas cambien. Aún así, algo (aunque poco) hemos avanzado. Por ejemplo, el propio ayuntamiento tiene un servicio GIS basado en Google Maps donde podemos ver los carriles bici que existen en la ciudad: en verde el anillo ciclista, en rojo los demás.

GIS Municipal con información de carriles bici en Madrid

Como se aprecia claramente, el anillo ciclista (ya casi totalmente construido) vale como circuito deportivo pero, salvo casualidades, no para servir de vía de desplazamiento al trabajo. El resto de carriles bici son francamente escasos y no están bien estructurados. La normativa de la red de Metro tampoco ayuda a planificar un desplazamiento mixto: salvo que tengas una plegable, los días laborables sólo puedes acceder al metro con tu bici entre las 10 y las 12.30 y a partir de las 21.00 hasta cierre del servicio. O sea, olvídate de ir al trabajo. Además, la práctica totalidad de los carriles bicis se ha construido robando espacio al peatón y no al tráfico rodado cosa que, según muchos estudios, es contraproducente e incluso aumenta el riesgo de accidentes.

En los próximos meses tenemos un par de elementos que pueden hacer cambiar un poco este panorama: el ayuntamiento de Madrid ha decidido, por fin, cumplir un par de promesas electorales que ya nadie esperaba: la llamada M-10 (un anillo ciclista alrededor del centro de la ciudad) y un servicio municipal de alquiler de bicis al estilo del que existe desde hace años en Sevilla y otras ciudades.

La M-10 será un anillo que circunvalará el centro de Madrid y que se construirá reservando un carril de la calzada para uso preferente de los ciclistas. Los automóviles podrán circular también por este carril pero siempre a una velocidad inferior a 30 kmh. La construcción comenzará inmediatamente y está previsto que concluya antes de finalizar el año puesto que la inversión es mínima y apenas consistirá en la señalización horizontal y vertical necesaria. Durante el año que viene está prevista la construcción de otros 60 kms de carriles bicis en el centro de Madrid para complementar esta medida.

Plano del proyecto de la M10 en Madrid

Además, MyBici, el servicio municipal de alquiler de bicis de Madrid debería de empezar a funcionar el 1 de mayo de 2014 y contará inicialmente con más de 1.500 bicicletas repartidas entre 120 aparcamientos, todos ellos en en el centro de Madrid. El servicio será muy similar al que ya existe con gran éxito en muchas capitales europeas y españolas salvo en un punto muy polémico: además del coste anual de abono de 25? habrá que pagar desde el primer minuto de utilización. El coste de la primera media hora será de 0,5? mientras que en la mayoría de las ciudades estos primeros 30 minutos son gratuitos.

Veremos, pues, como evoluciona todo esto. Y si quieres seguir informado de estos temas con mucho más rigor y asiduidad que en este blog o ponerte en contacto con el “universo ciclista” de Madrid te recomiendo las siguientes fuentes:

ACTUALIZACI?N: Se me olvidó incluir el calendario ciclista de Madrid que mantienen actualizado gracias a sus lectores desde las páginas de enbicipormadrid.es
Compártelo:
    emailPDFPrintBitacoras.comIdenti.caTwitterdel.icio.usDiigoFacebookMeneameBarraPuntoNetvibes
Categorías: estilos de vida
Etiquetas: , , ,

Bacalao con salsa de pimientos

Josemaría | 11 de octubre de 2013 | 1 comentario

Bacalao con salsa de pimientosicono distintivo de los textos de recetas de cocina De vuelta a los fogones. Anotad, que esta es sencillita:

Espolvoreamos ligeramente el bacalao con pimienta negra y lo reservamos. Picamos la cebolla, los ajos y los pimientos y lo sofreímos todo. Cuando está bien pochado (pero cuidando que no se queme en absoluto) lo trituramos con una picadora junto con la rebanada de pan frito, lo mezclamos bien con el tomate y añadimos medio vaso de vino blanco y otro medio de agua. Lo devolvemos a la cacerola, añadimos las hojas de laurel y, esperamos a que empiece a hervir. Colocamos los lomitos de bacalao, espolvoreamos generosamente con perejil fresco bien picado y lo dejamos cocer, cubierto y a fuego lento, durante unos 15 minutos por cada lado.

Mi intención original era hacer bacalao a la vizcaína pero parece ser otra de esas recetas con miles de variantes y una lucha encarnizada por defender la verdad única. Y no, ya no me meto en más de esas que estoy mayor… ;-)
Compártelo:
    emailPDFPrintBitacoras.comIdenti.caTwitterdel.icio.usDiigoFacebookMeneameBarraPuntoNetvibes
Categorías: recetas de cocina
Etiquetas:

Greylisting en Postfix y Debian 7

Josemaría | 27 de septiembre de 2013 | 2 comentarios

correoNadie se acuerda de Santa Bárbara hasta que truena, que dice el refrán. Yo tenía pendiente configurar un sistema de Greylisting (listas grises) en mi servidor de correo pero no lo he visto como urgente e inmediato hasta el aumento inusitado de actividad de los bots de spam de los últimos días.

El Greylisting es, hoy por hoy, uno de los métodos más efectivos a la hora de controlar el spam y su funcionamiento es sencillo y fácil de entender. Cuando un servidor de correo recibe un mensaje anota en una lista tres datos que lo identifican (la IP desde donde viene, el correo del remitente y el del receptor) y a continuación lo rechaza indicando al emisor que lo intente de nuevo más tarde. Esto se hace con un código 45x:

-> MAIL FROM: <sender@somedomain.com>
<- 250 2.1.0 Sender ok
-> RCPT TO: <recipient@otherdomain.com>
<- 451 4.7.1 Please try again later

Si el mensaje ha sido enviado por un servidor SMTP legítimo reconocerá el mensaje de rechazo y en un tiempo predefinido (típicamente de 300 segundos) reenviará de nuevo el correo que, en este caso, será aceptado por el servidor del destinatario. Un bot preparado para enviar spam no realizará el segundo envío. De esta forma, si el correo no es spam llegará al destinatario con 5 minutos de retraso. Salvo este detalle el emisor no se enterará de nada (todo el trabajo se hace entre los servidores de correo sin que los clientes intervengan). Si el receptor abre la cabecera del mensaje recibido verá una línea parecida a esta:

X-Greylist: delayed 300 seconds by postgrey-1.34 at invernalia; Thu, 19 Sep 2013 16:30:33 CEST

El sistema de control del spam mediante Greylisting fue originalmente ideado por Evan Harris en este whitepaper de 2003. El señor Harris mantiene, además, una lista de implementaciones de su método para diversos servidores de correo. Si quieres más información conceptual sobre esta técnica, esta página y la entrada correspondiente de la wikipedia también tienen información interesante.

Si ya tienes una Debian con un servidor de correo postfix funcionando la implementación en perl del Greylisting es muy, muy fácil de poner en marcha. Basta con instalar el paquete postgrey y añadir check_policy_service inet:127.0.0.1:10023 en la lista de restricciones del fichero main.cf de configuración de postfix en el directorio /etc/postfix:

smtpd_recipient_restrictions = reject_unknown_sender_domain, reject_unknown_recipient_domain, reject_unauth_pipelining, permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination, check_policy_service inet:127.0.0.1:10023

Por supuesto, una vez hechas ambas cosas debemos de reiniciar el servicio postfix. La instalación nos ha creado un nuevo servicio llamado postgrey que arranca como daemon y escucha en el puerto 10023 y que responde a los argumentos habituales: start, stop, restart, reload, force-reload y status. En el directorio /etc/postgrey tenemos dos ficheros denominados whitelist_clients y whitelist_recipients donde, respectivamente, se pueden especificar las direcciones de ciertos servidores smtp o direcciones de correo que no se someteran al procedimiento de rechazo temporal de los mensajes y que se aceptaran al primer intento. Tenemos, además, un fichero donde se encuentra la configuración principal del servicio llamado /etc/default/postgrey que veremos más adelante.

Si observamos ahora el log de nuestro postfix (/var/log/mail.log) podemos estudiar el funcionamiento y si este es correcto. Cuando recibimos cualquier correo (salvo uno ya identificado como válido en las whitelist) será inmediatamente registrado y rechazado:

Al cabo de cinco minutos si el correo es legítimo el servidor remitente volverá a intentarlo y ahora el correo si será aceptado:

Puede que el servidor emisor se impaciente y antes de que transcurran esos cinco minutos vuelva a intentarlo. En ese caso el correo volverá a ser rechazado:

Como puedes observar en los mensajes del log, aparte de la razón del rechazo el servidor enviará una dirección web personalizada donde se informa detalladamente de lo que está ocurriendo:

mensaje de información de postgrey en castellano

Postgrey crea, además, una base de datos en el directorio /var/lib/postgrey donde guarda información acerca de los mensajes recibidos. Después de aceptar cinco mensajes de un servidor, este será automáticamente incluido en una whitelist de tal forma que, a partir de este momento, ya no se le volverá a exigir el trámite de los reintentos. Podemos consultar en cualquier momento los servidores de esta lista ejecutando el siguiente script:

perl /usr/share/doc/postgrey/postgrey_clients_dump

Y una ejecución de ejemplo:

Servidores incluidos en la whitelist de greylist

Tenemos aún pendiente ver el fichero de configuración principal: /etc/default/postgrey. En el podemos modificar, por ejemplo, el texto que aparecerá en el mensaje de rechazo:

POSTGREY_TEXT="Si tu sevidor funciona como debiera debería de intentar enviarme de nuevo el mensaje en 5 minutillos de nada"

También podemos enviar al demonio cualquiera de los argumentos que tenemos disponibles para modificar su funcionamiento (ver man postgrey) mediante el parámetro POSTGREY_OPTS. Por ejemplo, en la siguiente línea se dice al demonio que escuche en el puerto 60000, subimos el retraso para aceptar el mensaje a 600 segundos y le indicamos que incluya las direcciones de los clientes en la whitelist después de aceptarles 3 envíos:

POSTGREY_OPTS="--inet=60000 --delay=600 --auto-whitelist-clients=3"

Para terminar, si quieres comprobar la configuración de tu servidor de correo electrónico para ver si es vulnerable de alguna forma y puede ser usado como un Open Relay, si el correo saliente que envía puede verse bloqueado de alguna forma, etc. existen muchas herramientas en línea pero las más cómodas y completas, a mi juicio, son las de mxtoolbox y el test de allaboutspam.

Compártelo:
    emailPDFPrintBitacoras.comIdenti.caTwitterdel.icio.usDiigoFacebookMeneameBarraPuntoNetvibes

Analizando el arranque de tu Linux con bootchart

Josemaría | 17 de septiembre de 2013 | 3 comentarios

herramientas ¿Qué es lo que hace tu Linux durante el arranque?¿Hay alguna forma de ver exactamente que se ejecuta, cuales son los procesos dependientes que genera y cuanto tiempo se invierte en cada uno de ellos de forma que podamos, si es necesario, saber donde tenemos que tocar para conseguir un arranque más rápido?

Bootchart es una herramienta que obtiene y procesa fácilmente esta información y genera como resultado un gráfico fácilmente interpretable. Como muestra, aquí tenéis la gráfica resultado en un servidor VPS con Debian 7 (ya sabes, pulsa sobre la gráfica para verla con mejor resolución):

Gráfica de bootchart 0.9 en un servidor VPS con Debian 7

La instalación básica en una Debian estable requiere dos paquetes (y sus dependencias): bootchart y pybootchartgui. El primero es el que recopila los datos y el segundo el que genera el gráfico a partir de ellos. bootchard se instalará por defecto en el directorio /sbin y su archivo de configuración se llama bootchard.conf y se encuentra en el directorio /etc. pybootchartgui se encuentra en el directorio /usr/bin/. Aunque tenemos muchas opciones interesantes para explorar, vamos a limitarnos a ver el funcionamiento tal y como queda recién instalado y sin tocar nada.

Una vez instalados ambos, tenemos que hacer que el kernel de nuestro Linux ejecute el proceso que realiza la recogida de datos lo antes posible y esto lo hacemos introduciendo dicha llamada directamente en GRUB. Si estamos en un equipo desde el que tenemos acceso directo a teclado y monitor lo más fácil es introducir a mano la opción necesaria en el momento del arranque. Para ello, una vez que nos aparece el menú de GRUB pulsamos la letra “e” (de editar) e introducimos la opción init=/sbin/bootchartd. De esta forma el proceso sólo se llamará en este arranque puesto que la opción no queda salvada:

Editando la entrada de Grub para invocar a bootchar

Si no tenemos acceso al teclado de la máquina en el momento del arranque (en un Hosting VPS, por ejemplo) el método pasa por introducir esta opción en los archivos de configuración de GRUB. El método es diferente según que usemos GRUB o GRUB2. En GRUB basta con editar el archivo /boot/grub/menu.lst, buscar el bloque correspondiente al kernel con el que qeremos realizar el arranque e introducir la misma opción que hemos visto antes. Por ejemplo, así:

title           Debian GNU/Linux, kernel 3.2.0-4-amd64
root            (hd0,0)
kernel          /boot/vmlinuz-3.2.0-4-amd64 root=/dev/vda1 ro quiet no-kvmclock init=/sbin/bootchartd
initrd          /boot/initrd.img-3.2.0-4-amd64

En GRUB2 tenemos que editar el fichero /etc/default/grub, buscar la línea etiquetada como GRUB_CMDLINE_LINUX_DEFAULT e incluir al final de lo que allí aparezca la opción de carga de bootchartd. Así, por ejemplo:

GRUB_CMDLINE_LINUX_DEFAULT="resume=/dev/disk/by-uuid/35a07870-ac1a-489f-a19b-629
6dca46903 init=/sbin/bootchartd"

En este segundo caso, una vez editado el fichero tendremos que ejecutar el programa update-grub para que los cambios tomen efecto.

Un cuarto método, disponible si estamos usando un equipo de escritorio con un gestor de ventanas instalado, es usar uno de los muchos programas existentes para configurar grub de forma gráfica. Por ejemplo, grub-customizer:

Configurando el arranque de bootchartd con grub-customizer

Sea cual sea el método que hayamos usado, en el próximo arranque se ejecutará bootchartd, pero no olvides que, salvo en el primer caso, cuando ya no quieras usarlo tendrás que deshacer los cambios efectuados.

Bien. Tras reiniciar la máquina se invocará al proceso llamado bootchartd que recogerá la información necesaria y la guardará en un archivo llamado bootchart.tgz en el directorio /var/log. Para crear el gráfico basta con invocar a pybootchartgui:

Generando el gráfico de bootchart con pybootchartgui

Nota que se toma por defecto la ubicación y nombre del archivo original y que, por tratarse este de un nombre genérico, cada vez que reiniciemos y/o generemos un nuevo gráfico machararemos los datos del anterior a menos que los renombremos manualmente o le echemos un vistazo a la forma de modificarlos mediante los parámetros en línea y/o opciones de configuración adecuadas. Y listo. A continuación tenéis otro ejemplo correspondiente a un servidor más modesto que el anterior montado sobre VirtualBox:

Gráfica de bootchart 0.9 en una máquina de virtualbox con Debian 7

En la paquetería de Manjaro Linux (e, imagino, que ocurre igual con Arch) se usa otro programa similar también llamado bootchart pero que, en realidad, integra en un sólo servicio la recolección de datos y la generación del gráfico final. El gráfico resultante presenta, además, algunos aspectos diferenciadores. Podéis ver una muestra en la siguiente imagen que corresponde con el arranque de un PC de escritorio:

Gráfica de bootchart 1,2 en un PC de escritorio con Manjaro Linux

Para usarlo basta instalar el paquete llamado bootchart. El programa que tendremos que invocar se llamará igualmente bootchartd pero en este caso reside en el directorio /usr/bin. Podemos usar cualquiera de los métodos anteriormente vistos para invocarlo pero el parámetro a incluir en las opciones de carga del kernel será init=/usr/bin/bootchard. El archivo de configuración también es sensiblemente diferente y está en el directorio /etc/systemd. Cuando reiniciamos la máquina, el archivo que bootchart genera es ya directamente un gráfico en formato svg. El directorio destino del mismo es, igualmente, /var/log pero en este caso el nombre incluye una marca de tiempo (por ejemplo bootchart-20130916-0800.svg) de forma que si realizamos sucesivos reinicios tendremos disponible una colección de gráficos para su posterior estudio sin necesidad de ninguna intervención manual.

Existe aún, al menos, otro tercer sistema similar a estos denominado bootchart2 y que, por el momento, no he tenido ocasión de probar. Ahí queda el enlace por si alguien se anima…

NOTA: Desde hace ya unos meses estoy usando Manjaro Linux (con Openbox como window manager) como distribución de escritorio, tanto en mi ordenador de sobremesa como en mi portatil. Manjaro es una distribución rolling release, muy, muy ligera basada en Arch Linux que me está gustanado bastante, así que previsiblemente hablaremos bastante de ellas en lo sucesivo.
Compártelo:
    emailPDFPrintBitacoras.comIdenti.caTwitterdel.icio.usDiigoFacebookMeneameBarraPuntoNetvibes

Plugins de memcached y bind9 para munin

Josemaría | 5 de septiembre de 2013 | Comentar

herramientasEl otro día dejamos munin instalado y funcionando con los plugins más comunes que vienen de serie y se configuran de forma automática sin (casi) necesidad de manipulación extra alguna. El principal problema que vamos a encontrar con esta herramienta de monitorización es que cuando tratemos de instalar alguno de los centenares de plugins adicionales de que dispone nos encontraremos, según el caso, una información bastante irregular en cuanto a la forma en que tenemos que hacerlo: dependencias, configuración, etc. Hoy vamos a instalar un par de estos plugins adicionales de forma manual y así conoceremos un poco mejor sus tripas y veréis claramente a lo que me refiero.

La primera herramienta que debemos de conocer a la hora de añadir plugins adicionales es munin-node-configure, un script que nos ayuda a identificar que plugins nos pueden resultar útiles y ayudarnos a instalarlos. Como ya vimos, la instalación base de munin identifica muchos de los elementos que pueden resultarnos útiles y los configura e instala, pero si existe algún requisito o dependencia adicional para que funcionen no es capaz de resolverlo aunque si deja un mensaje informándonos de ello si usamos el parámetro --suggest. No suelen ser muy descriptivos y suele hacer falta hacer uso de Google para encontrar la solución (por ejemplo, si te falta la librería libcache-cache-perl para que funcione el plugin de MySQL el mensaje que aparece es “Missing dependency Cache::Cache”), pero bueno, algo es algo.

Para configurar el plugin de bind9 no necesitamos instalar nada adicional, pero si hacer algunos cambios en la configuración de nuestro servidor DNS. En el archivo named.conf.options (típicamente en el directorio /etc/bind) tenemos que introducir la siguiente línea dentro del bloque de options:

statistics-file "/var/cache/bind/named.stats";

Y añadir al final del fichero el siguiente bloque:

logging {
        channel b_query {
                file "/var/log/bind9/query.log" versions 2 size 1m;
                print-time yes;
                severity info;
        };
        category queries { b_query; };
};

A continuación creamos el directorio /var/log/bind9, le damos permisos de escritura al usuario bind, reiniciamos el demonio de nuestro servidor DNS y ejecutamos el comando rndc stats. Con esto el servicio dejará los logs detallados de estadísticas de consultas en ese directorio. A continuación tenemos que configurar el plugin de munin para que las lea y nos las muestre de forma gráfica. Para ello editamos el fichero /etc/munin/plugin-conf.d/munin-node y añadimos los siguientes bloques:

[bind9]
user root
env.logfile   /var/log/bind9/query.log

[bind9_rndc]
user root
env.querystats /var/cache/bind/named.stats

Por último, creamos un enlace a los plugins en el directorio de configuración como explicábamos el otro día:

ln -s /usr/share/munin/plugins/bind9 /etc/munin/plugins/bind9
ln -s /usr/share/munin/plugins/bind9_rndc /etc/munin/plugins/bind9_rndc 

Y ya sólo nos queda reiniciar el demonio munin-node. Casi inmediatamente tendremos una nueva categoría de gráficos dedicada a la monitorización de nuestro servicio de nombres:

Plugin de bind9 para munin

La configuración del plugin para memcached es bastante más sencilla. Lo primero que debemos de hacer es instalar el paquete libcache-memcached-perl (en una debian o derivada). A continuación añadimos el siguiente bloque en el archivo /etc/munin/plugin-conf.d/munin-node:

[memcached_*]  
env.host 127.0.0.1  
env.port 11211  
env.timescale 3

Creamos los enlaces:

ln -s /usr/share/munin/plugins/memcached_bytes /etc/munin/plugins/memcached_bytes
ln -s /usr/share/munin/plugins/memcached_counters /etc/munin/plugins/memcached_counters
ln -s /usr/share/munin/plugins/memcached_rates /etc/munin/plugins/memcached_rates

Reinciamos munin-node y ya:

Plugin de memcached para munin

NOTA: Tienes información bastante detallada acerca del fichero de configuración munin-node, las opciones que admite y su significado en este enlace.
Compártelo:
    emailPDFPrintBitacoras.comIdenti.caTwitterdel.icio.usDiigoFacebookMeneameBarraPuntoNetvibes