Políticas de contraseñas y control de acceso en Debian

Josemaría | 8 de febrero de 2014 | 8 comentarios

seguridad Existe un falso tópico por ahí que viene a decir, de una u otra forma, que Linux es más seguro que Windows. Para nada. Es cierto que, normalmente, el usuario medio de Linux está más comprometido con la seguridad, abundan más los usuarios expertos y menos los usuarios domésticos y que existe una mayor variedad de posibilidades y herramientas para hacer seguros nuestros sistemas. También que al existir un volumen menor de equipos con Linux no es objetivo prioritario de los creadores de virus. Pero “recién salido de la caja” y en manos de un usuario torpe y/o despreocupado, un Linux es, por regla general, tan poco seguro como cualquier Windows. De veras.

Veamoslo, por ejemplo, desde el punto de vista de la política de usuarios y contraseñas, uno de los aspectos que mas se critica en los Windows de escritorio. Una Debian 7.3 (la última en el momento de escribir esto) te permite poner cualquier contraseña para el root y la cuenta inicial que se crean de forma obligatoria durante la instalación. Y cuando digo cualquiera, digo cualquiera y sin ningún tipo de advertencia. ¡Hasta una de un sólo carácter o el maldito 123456 (que hace años que ya ni siquiera en Hotmail está permitida aunque sigue siendo una de las passwords más usadas)! Además, el único tipo de protección ante ataques de diccionario y/o fuerza bruta es un retraso de tres segundos entre cada intento de login fallido. No, no parece un planteamiento muy seguro a priori ¿Verdad? Bueno, por lo menos no nos permite dejar las cuentas sin contraseña. Algo es algo…

NOTA: Si durante la instalación dejamos la password del usuario root en blanco nos lo permitirá pero en ese caso, afortunadamente, lo que hará sera deshabilitar la cuenta de root y conceder privilegios a través de sudo a la cuenta del primer usuario que… igualmente, podremos inicializar con cualquier contraseña sin ningún tipo de advertencia. ¡Ay!

La parte positiva del asunto es que con un poquito de trabajo por nuestra parte este esquema puede mejorar sustancialmente. Para ello, lo primero es conocer como funciona la autenticación de usuarios en Linux. Vamos a ello.

Antes que nada vamos a ubicar algunos de los ficheros importantes en este asunto. En el directorio /etc se encuentran los ficheros passwd y shadow que guardan, respectivamente, las cuentas de usuario y los “hashes” de las contraseñas. Además, repartido entre ellos, existe mucha información relacionada con el proceso de autenticación: si el usuario puede hacer login interactivo o no, el bash que usará, información de caducidad de la cuenta, etc. Veamos una línea típica de cada uno de estos ficheros y hagamos una disección de su contenido.

Empezamos por el fichero passwd. Cada línea se corresponde con un usuario y consta de siete campos en los que el separador es el signo “:”. Por ejemplo así:

josemaria:x:1001:1001:Jose Maria Morales,,,:/home/josemaria:/bin/bash

El significado de cada uno de los campos es este:

1Nombre que el usuario utilizará en el login
2Tradicionalmente aquí se encontraba la hash del password. Ahora, una x simboliza que la hash de la password se encuentra en el fichero shadow. Un * o un ! indican que la cuenta está desactivada. Por el contrario, si eliminamos la x (o cualquier otra cosa) de este campo, el sistema nos dejará entrar sin necesidad de contraseña pero sólo a través de una conexión "in situ" frente a la máquina mientras que las conexiones remotas no se permitiran.
3UID del usuario
4GID del grupo primario del usuario
5Infomación personal del usuario. Los diferentes campos están separados por comas.
6Directorio home del usuario
7Path absoluto al shell por defecto que usará cuando realice una conexión interactiva. Se suele poner /bin/false cuando no queremos permitir una conexión interactiva.

Aquí ya podemos hacer la primera “personalización” relativa a la seguridad. Si queremos que un usuario no pueda hacer una conexión interactiva con el sistema basta con que pongamos un * o un ! en el campo 2 o un shell inexistente en el campo 7 (por convención suele ponerse /bin/false). La diferencia entre usar uno u otro método es que el segundo permitirá que, aún así, esa cuenta de usuario pueda seguir usándose para otro tipo de servicios (correo, por ejemplo) mientras que si usamos el primero la cuenta quedará totalmente inutilizable para ningún servicio.

Vayamos ahora con el fichero shadow. Primero un ejemplo. Como podemos ver, en este caso tenemos 8 campos:

josemaria:$6$F3PRa1Vu$fXK1ZYXex67wi5XdbnTokhWle416I87oAtgs0ynFdhn.c6IBqrvGhmnCUC.Ue2AbLJtn9C9ZH.3pgNfSeneTF0:15675:0:99999:7:::
1Nombre que el usuario utilizará en el login
2Se trata de un campo compuesto que contiene información del algoritmo que usará el sistema para calcular el hash, la salt que aplicaremos a la password antes de calcular este y el hash resultante. Cada uno de estos tres subcampos se separan por el símbolo $. En el ejemplo de aquí arriba el 6 del primer campo indica que usaremos SHA512 (la opción por defecto en las Debian actuales), la salt es F3PRa1Vu y el resto después del último símbolo $ es la hash ya calculada al resultado de concatenar la salt con el password. Un 5 en el primer campo indica que usaremos SHA256, un 4 SHA1, un 3 NT Hash, un 2 blowfish y un 1 MD5. Un * o un ! en este campo también indican que la cuenta está deshabilitada.
3Fecha del último día en que se cambió la password indicada, como es habitual, mediante el número de días transcurridos desde el 1 de Enero de 1970
4Número mínimo de días requeridos entre cambios de contraseñas. Un 0 indica que se puede cambiar tan a menudo como se quiera.
5Número máximo de días para obligar a un cambio de contraseña. Por defecto 99999. O sea, casi 274 años. O sea, nunca.
6Número de días antes de que el password expire en que se mostrará un aviso al usuario indicando que debe de cambiarla. Por defecto 7 días
7Número de días del periodo de gracia después de que el password expire transcurridos los cuales la cuenta será deshabilitada. En blanco por defecto (no habrá periodo de gracia).
8Fecha (indicada también mediante el número de días transcurridos desde el 1 de enero de 1970) en que la cuenta será deshabilitada. En blanco por defecto (la cuenta nunca expira).

La expiración de passwords y de cuentas de los parámetros que hemos visto se puede manejar de dos formas: editando directamente la información del fichero shadow o con el comando chage. Por ejemplo, el siguiente comando fija en 30 días la validez máxima de una contraseña para el usuario josemaria y en 2 el mínimo número de días que deben de transcurrir entre cambios:

chage -M 30 -m 2 josemaria

Otros parámetros interesantes son -d y -E para establecer la fecha del último cambio de contraseña y la de caducidad de la misma respectivamente (en formato YYYY-MM-DD), -I para establecer los días de gracia antes de desactivar la cuenta, o -W para establecer el número de días antes de la fecha de caducidad para emitir una advertencia.

También podemos cambiar todos estos datos de forma interactiva:

comando chage en forma interactiva

O listar los valores establecidos para una cuenta usando el argumento -l:

chage -l josemaria

Pero ¿Dónde se establecen estos valores por defecto para que se tengan en cuenta a la hora de crear nuevos usuarios y no tener que modificarlos uno a uno? En el fichero /etc/login.defs podemos editar los siguientes parámetros que sirven, respectivamente, para ajustar el número máximo y mínimo de días de validez de una password y la antelación a que caduque con que recibiremos una advertencia:

PASS_MAX_DAYS   60
PASS_MIN_DAYS   2
PASS_WARN_AGE   5

En el fichero /etc/default/useradd ajustamos los días de gracia en que las cuentas permarecerán activas después de caducar las contraseñas y la fecha global de expiración de las mismas:

INACTIVE=2
EXPIRE=

Un -1 en el primer campo indica que la cuenta se deshabilitará tan pronto como caduque la contraseña. Si el segundo campo está en blanco indica que la cuenta no tendrá una fecha predeterminada de expiración.

Pero la verdadera potencia en el sistema de identificación de Linux reside en la gran variedad y flexibilidad que tenemos a la hora de usar métodos que refuerzan el sistema clásico de autenticación o nos proporcionan alternativas al mismo mediante módulos adicionales. Estos módulos residen en el directorio /lib/i386-linux-gnu/security/ y se configuran a través de los ficheros que tenemos en /etc/pam.d. En este enlace podemos ver todos los disponibles en una Debian 7 estable, aun los no instalados por defecto. Empecemos por ver dos de los que vienen instalados “de serie”. pam_faildelay y pam_tally nos permiten, a través del fichero /etc/pam.d/login, controlar el retraso entre varios intentos de login fallidos y la configuración de bloqueo de cuentas después de sucesivos intentos erroneos con los siguientes parámetros:

auth optional pam_faildelay.so delay=5000000
auth required pam_tally.so deny=5 unlock_time=7200

En la primera línea el retraso entre logins fallidos se especifica en microsegundos (5000000, o sea, 5 segundos). En la segunda línea decimos que tras cinco intentos de login fallido la cuenta se bloqueará durante 7200 segundos (2 horas). En una instalación limpia y por defecto la primera línea aparece configurada a 3 segundos y la segunda no aparece, es decir, la cuenta no se bloquea nunca.

El control manual de las cuentas bloqueadas o intentos fallidos de login puede llevarse mediante dos utilidades: pam_tally o faillog.

pam_tally y faillog para control de cuentas bloqueadas e intentos fallidos de login

Podemos, además, consultar los datos relativos a una única cuenta de usuario con cualquiera de estos dos comandos:

pam_tally --user josemaria
faillog -u josemaria

Desbloquear manualmente una cuenta o hacer un reset a los intentos fallidos de la misma así:

pam_tally --user josemaria --reset=0
faillog -r -u josemaria 

O modificar el número máximo de intentos fallidos así:

faillog -m 3
NOTA: Los bloqueos tras sucesivos intentos fallidos se pueden controlar también con utilidades externas como denyhost (de la que hablamos aquí hace años) o fail2ban que añaden muchas otras funcionalidades.

El tipo de contraseñas permitidas y alguna otra característica asociada a las mismas se configura en el fichero /etc/pam.d/common-password. La configuración por defecto usa el módulo pam_unix y se define mediante esta línea:

password [success=1 default=ignore] pam_unix.so obscure sha512

El argumento obscure realiza una mínima comprobación de la complejidad de la contraseña: si esta es demasiado simple o una modificación fácilmente reproducible a partir de la anterior, mientras que sha512 define el algoritmo que se usará para guardar el hash en el fichero shadow. Otros argumentos interesantes que podemos añadir son remember, que dicta el número de contraseñas que son memorizadas por el sistema para que el usuario no las repita o minlen que fija la longitud mínima de la contraseña. Por ejemplo, para recordar las 12 contraseñas anteriores y fijar una longitud mínima de 10 caracteres modificaríamos la línea anterior así:

password [success=1 default=ignore] pam_unix.so obscure remember=12 minlen=10 sha512

El módulo pam_cracklib, que no viene instalado por defecto, nos permite una configuración mucho más flexible. Lo instalamos así:

apt-get install libpam-cracklib

Y, tras hacerlo, se nos añadirá automáticamente la siguiente línea en el fichero /etc/pam.d/common-password justo encima de la que define la forma de funcionar del módulo pam_unix:

password requisite pam_cracklib.so retry=3 minlen=8 difok=3

pam_cracklib es mucho más restrictivo que pam_unix a la hora de permitir contraseñas puesto que, además de las comprobaciones de complejidad, contrasta la password elegida por el usuario con las de un diccionario que instala en el directorio /var/cache/cracklib. Además, en su configuración por defecto que acabamos de ver exige una longitud mínima de 8 caracteres de los cuales, al menos, tres no debería de estar presentes en la password anterior (argumento difok). Otros argumentos interesantes son reject_username (rechaza contraseñas que contengan de alguna forma el nombre de usuario escrito normal o invertido) o maxrepeat=n (rechaza contraseñas con más de n caracteres iguales seguidos).

Particularmente flexible es el método que nos permite definir el tipo de caracteres que exigiremos a la contraseña. pam_cracklib considera que existen cuatro grupos de caracteres: letras mayúsculas, letras minúsculas, cifras y signos de puntuación. La forma más sencilla es definir el mínimo número de estos tipos que deberían de estar presentes en cada contraseña con el argumento minclass=n, donde n es un número entre 1 y 4.

Contamos, además, con los argumentos lcredit, ucredit, dcredit y ocredit que representan, respectivamente, a las letras minúsculas, las mayúsculas, los dígitos y los signos de puntuación, los cuatro grupos de caracteres a considerar. Cuando aparecen con valores negativos indican el mínimo número de caracteres de ese grupo con que debería de contar nuestra password. Por ejemplo, minlen= 8 ucredit=-1 lcredit=-1 dcredit=-1 indica que la contraseña debería de tener al menos una mayúscula, una minúscula y un dígito y contar con 8 caractéres mínimos de longitud. Cuando se utilizan con valores positivos, sin embargo, validan nuestra contraseña según un sistema de créditos donde minlen indicaría el número de “puntos” mínimo que validaría una contraseña como correcta. La contraseña sumaría un punto por cada carácter de longitud y los puntos correspondientes a las clases de caracteres que incluya. Pongamos, por ejemplo, que hemos establecido los argumentos minlen= 13 ucredit=1 ocredit=2 dcredit=2. La contraseña tristr4s suma diez puntos (ocho por longitud y dos más por contener un dígito) y no sería valida, mientras que Tristr4s! sumaría 14 (nueve por longitud, una por tener mayúsculas, dos por tener un dígito y otros dos por tener un signo de puntuación) y si sería permitida.

En las páginas del manual de cada uno de estos módulos puedes encontrar algunos otros argumentos interesantes.

IMPORTANTE: La mayor parte de estas restricciones se tendrán en cuenta sólo en el caso de que sea el propio usuario quien realice su cambio de contraseña. Si es el usuario root quien la establece inicialmente o la cambia se le permitirá saltarse a la torera la gran mayoría de estas normas, a veces sin siquiera una advertencia.
ACTUALIZACI?N: En Security by Default publican esta semana esta entrada con información mucho más técnica sobre los módulos de autenticación PAM donde, además, los analizan como posible punto para comprometer a un sistema.
Compártelo:
    emailPDFPrintBitacoras.comIdenti.caTwitterdel.icio.usDiigoFacebookMeneameBarraPuntoNetvibes

7 enlaces 7 (y LV)

Josemaría | 7 de enero de 2014 | Comentar

enlaces rápidos

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

Lo más visto por aquí en 2013

Josemaría | 2 de enero de 2014 | Comentar

icono de calendario En estos días todas las estrellas de esto de la blogocosa se dedica a publicar listas de “lo más” de su año: los libros que más les han gustado, las canciones que más han escuchado, lo que más han comido (de esto no tengo pruebas pero seguro que alguién lo ha escrito por ahí…) Yo, que hace años que tengo pretensiones y amenazo con mantenerme por aquí hasta que, por fin, sea el año de la muerte de los blogs y tras desaparecer todos menos el mío me convierta en (espero) uno de los más leídos del mundo mundial, voy a empezar por dejar aquí una lista con los 11 posts más leídos de este blog durante el 2013, por si acaso a alguno de mis siete lectores se le ha escapado alguno de ellos. Y si, se que es injusto usar sólo el criterio de número de lectores sin ningún tipo de proporcionalidad pero ¿aún alguien se cree que esta vida es justa? Pues así os va…

ACTUALIZACI?N: ¿Qué os decía? :-D
Compártelo:
    emailPDFPrintBitacoras.comIdenti.caTwitterdel.icio.usDiigoFacebookMeneameBarraPuntoNetvibes

“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: