ZFS será incluido de forma predeterminada en Ubuntu 16.04

Ubuntu 16.04 integrará ZFS. Una gran noticia, que nos apunta nuestro colega Alejo, que posiblemente hará que otros muchos sigan su camino. Un gran sistema de ficheros que se merece su integración en todo tipo de distros.

Noticia disponible aquí.

Bitácora de PSI.: Una de cuotas

En el capítulo anterior hemos hablado, entre otras cosas, de los sistemas de ficheros. Hoy trataremos de poner algunas barreras al campo en la forma de cuotas.

Es necesario definir cuotas en nuestros sistemas de ficheros, tanto locales como en red, especialmente en entornos multiusuario. Bueno, si tu máquina únicamente te tiene a ti por usuario, no será tan crítica esta tarea, aunque ...

Nuestro espacio de almacenamiento no suele ser infinito, por lo que será necesario limitar su uso. No es bueno dejar llenar nuestros discos duros. Como mínimo poner cuotas al número de bloques e inodes por usuario y, o, grupo. De forma resumida para vuestras máquinas de laboratorio podéis utilizar este mini-howto "Debian Disk Quota Management". Para asignar cuotas podrás utilizar el quotatool o el edquota. Normalmente se definen varias cuotas tipo a usuarios que se utilizan para asignar a otros usuarios:

$ sudo edquota -p ...

# for i in `cat /etc/passwd [pipe] cut -f1 -d:`; do edquota -p $i; done

Este último comando asignará cuota a todo usuario del /etc/passwd, incluido root, admin, etc. Si quieres asignárselo a un grupo determinado, según el caso, puedes utilizar algún pequeño "script" o comando para seleccionar los usuarios afectados.

En este punto, utilizamos unas viejas conocidas en el mundo de los procesos, las llamadas "fork bombs", que sirve para ilustrar la necesidad de configurar otro tipo de cuotas, como las de procesos. Es bastante habitual encontrarnos en la actualidad máquinas multiusuario con cuotas de disco, pero no de procesos. Tal vez la más conocida, publicada y comentada de las "fork bombs" sea :(){ :[pipe]:& };:

De forma resumida, abre un terminal como usuario y ejecuta dicha cadena. En el caso de que el sistema no tenga cuotas de proceso, se comerá el procesador de la máquina y la dejará tirada. Esta cadena es una función llamada : que se auto-llama de forma recursiva dos veces y que se vuelven a llamar, como diría el inminente Buzz Light Year, "hasta el infinito y más allá". Esta función se puede reescribir de la siguiente forma para una mejor comprensión:

mifuncion(){ mifuncion[pipe]mifuncion& };mifuncion

Para microsoft en un cmd si se ejecutas un fichero por lotes mifuncion.bat cuyo contenido sea %0[pipe]%0 el efecto será el mismo. Existen otras muchas fork bombs, pero que no tienen ningún interés más que el de ilustrar la necesidad de definir cuotas en los distintos subsistemas gestionados por nuestros sistemas operativos. Aunque aquí veremos cuotas para el sistema de ficheros y procesos, recuerda que también tenemos otros recursos que pueden requerir de cuotas, como por ejemplo nuestros interfaces de red (por IP, servicios, etc.), para evitar posibles abusos (traffic shapping y QoS).

En el caso de cuotas de proceso, en los equipos del laboratorio (debian) tienes el fichero de configuración de linux-pam /etc/security/limits.conf. En el que podrás definir cuotas para distintos elementos, por ejemplo.:

@colegas hard nproc 100
@enemigos hard nproc 10

La primera línea definiría un límite "hard" de número de procesos a los usuarios del grupo colegas de 60 y, en la segunda, de 10 para los enemigos.

* hard nproc 60

Esta línea establecerá un límite de procesos de 60 para todo bicho que pulule en el equipo, a excepción del root. No olvides que un proceso puede generar un gran número de procesos. Analizar el perfil de los procesos de tus usuarios y sus necesidades te permitirá definir la política de asignación de cuotas. Bajo ningún concepto debemos considerar la típica coña de "usuario bueno, usuario muerto". Nosotros trabajamos para ellos y, sin ellos, nuestro trabajo no tendría sentido.

Y, es suficiente con las cuotas que hemos visto?. En el caso del fichero /etc/security/limits.conf podrás definir, al igual que se hace con nproc, límites para otros parámetros (fuente fichero de configuración de las debian de laboratorio).:

core limits the core file size (KB)
data max data size (KB)
fsize maximum filesize (KB)
memlock max locked-in-memory address space (KB)
nofile max number of open files
rss max resident set size (KB)
stack max stack size (KB)
cpu max CPU time (MIN)
as address space limit
maxlogins max number of logins for this user
maxsyslogins max number of logins on the system
priority the priority to run user process with
locks max number of file locks the user can hold
sigpending max number of pending signals
msgqueue max memory used by POSIX message queues (bytes)
nice max nice priority allowed to raise to
rtprio max realtime priority

Otros muchos parámetros configurables del sistema los encontrarás en /etc/login.defs y /etc/pam.d/common-password

password required pam_unix.so nullok obscure min=4 max=8 md5

¿Qué opinas de la línea anteriore que puedes localizar en los ficheros common-password de las máquinas de laboratorio?. ¿Qué opinas del uso de password md5 de longitud mínimo 4?. ¿Debemos enviar al md5 a hacerle compañía al crypt?. De momento no, pero requiere unos ciertos cuidados, que recuerdan a los últimos días del crypt.

Para que puedas dedicar un poco de tiempo a probar alguna herramienta, señalar dos dedicadas a la reproducción de ataques por fuerza bruta sobre una gran cantidad de servicios, Medusa y THC Hydra. Sin entrar en IDSs de propósito general, existen herramientas para su detección y filtrado, como fail2ban, denyhosts, blocksshd o sshdfilter. Su funcionamiento se centra en la identificación en los ficheros de "log" de ataques por fuerza bruta desde determinadas IPs para su filtrado normalmente mediante iptables. Será necesario incluir excepciones, para no filtrar lo que no se debe, y tener en cuenta la posibilidad de paquetes IP spoofing que nos puedan producir el filtrado de equipos confiables.

Y la pregunta que está en el aire, ¿no vas a dar más niveles RAID?. Hemos llegado hasta aquí hablando de sistemas de ficheros y RAIDs, y no hemos terminado nuestra aventura. Es hora de cerrarla, y descubrir al asesino.

Se analiza el funcionamiento de los RAID3 y 4, de los que no incluyo en esta entrada nada, al no ser de gran interés para nosotros. El RAID5, uno de nuestros clásicos, ilustra la utilización de información de paridad distribuida entre un grupo de discos para garantizar la recuperación ante el "casque" de un disco duro. El RAID5 incrementa el rendimiento respecto al 3 y 4, evitando el cuello de botella de tener toda la paridad en un único disco duro.

Desde un punto de vista operativo, la mayoría de los RAID que montamos son 0, 1 y 5. Existen otros muchos RAID, pero no son de este mundo -:). Recuerda que los discos duros se pueden llenar (el próximo día de clase hablaremos de LVM), se pueden estropear, te los pueden robar. RAID puede proporcionar un cierto nivel de seguridad, pero no funciona ante un borrado accidental de ficheros, no sustituye al backup, no protege de incendios, inundaciones, etc. También puedes plantear hacer RAID sobre discos remotos, por ejemplo con Fibre Channel.

En algunas ocasiones los RAID se van de fiesta y se montan RAID10 (grupos de "mirrors" "stripeados") o RAID01 (grupos de "stripeados" "mirroreados") [estos últimos términos son el resultado de un proceso de fusión, mis disculpas a la RAE].

Aunque los RAID pueden incrementar el rendimiento también puedes plantear el uso de distintos planificadores de entrada salida a disco o ajustar algunos de sus parámetros. Sin duda alguna, el "tunning" es un deporte maravillo que, por desgracia, se practica poco.

Recuerda que la partición de swap puede darle mucho trabajo a tu disco. No te olvides dimensionar al swap adecuadamente, y meterlo en un disco rápido. También puedes crear varias particiones de swap y distribuirlas entre varios discos, asignándoles prioridades. De esta forma, tu swap podrá irse de vacaciones a varios discos, y utilizar eso que se llama acceso concurrente.

Otra instalación que puede sernos de interés es hacer "mirroring" del sistema operativo. Y finalmente, para que puedas crear, monitorizar y hacer todo tipo de pruebas con los RAID en los equipos del laboratorio, el mdadm.

Bitácora de PSI.: Vida salvaje (la redundancia)

Seguridad y redundancia, dos términos íntimamente ligados. Al igual que la "hydra" de la fotografía, la redundancia a distintos niveles nos podrá proporcionar, entre otros, sistemas tolerantes a fallos, alta disponibilidad, computación distribuida y balanceo de carga. En este punto deberemos tener presente la organización "hardware" de nuestros sistemas que, en muchas ocasiones, pasará por la instalación de "clusters" y "blades" (los tipos de enlaces de ambos son autoexplicativos, y recuerda que en algunas ocasiones puede ser aconsejable "casarte" con alguna empresa y cubrirte la espalda con algún tipo de soporte). Tampoco debemos olvidarnos del mundo de la computación GRID. Además, la virtualización y paravirtualización de nuestros sistemas proporciona, entreo otras muchas ventajas, una gran flexibilidad, sin entrar en los posibles problemas de seguridad añadidos a este tipo de aproximaciones y a sus hypervisores.

Todo en la naturaleza utiliza la redundancia como mecanismo de protección-supervivencia. Muchas especies tienen docenas, cientos o incluso miles de crías. Como es lógico, este parámetro está relacionado con su índice de supervivencia. En resumen, se busca perpetuar la especie garantizando la supervivencia de un determinado número de individuos, al igual que nosotros buscamos garantizar la supervivencia de nuestros sistemas y servicios. Si tomamos un único individuo, la redundancia está presente en nuestro sistema de visión y auditivo, más que nada para poder disfrutar del estéreo de los sentidos, dos pulmones, dos riñones, ..., y un corazón (en este último caso más bien por un problema de consumo, de energía). Siempre hay elementos que saldría demasiado caro redundarlos.

La genética y la evolución siempre está presente en nuestros sistemas. La capacidad de adaptarnos a situaciones cambiantes es un cualidad muy deseable. Si estás interesado en estos temas te recomiendo alguno de los proyectos fin de carrera que propuse y dirigí cuando era joven, y que sobre los distintos subsistemas gestionados por nuestros sistemas operativos, se desarrolló todo un conjunto de algoritmos genéticos para proporcionar un sistema automático de ajustre de nuestros sistemas, facilitando su adaptación a distintos entornos, tanto "hard" como de aplicativo. Un ejemplar de cada uno de ellos está disponible en la biblioteca de la FI de la UDC. La monitorización y ajuste de nuestros sistemas es una tarea compleja. Por lo tanto, todo sistema automático que mejore el rendimientos de nuestos operativos, constituira un primer paso para hacer a nuestros sistemas operativos un poco más listos.

Si pensamos en nuestra infraestructura, encontramos redundancia a todos los niveles.

- Tal vez nuestras redes de comunicaciones constituyen el elemento más importante a la hora de pensar en redundancia. Si las redes fallan, todo falla. Debemos tener en cuenta tanto líneas redundantes como activos redundantes. Los caminos que nos unen son múltiples, variados y multitecnología. Hay bits que vuelan, otros navegan y, los que más me gustan a mí, hacen espeleología. Y recuerda, tal y como hemos visto en aventuras anteriores, que existen otros muchos mundos, otras muchas redes.: de suministro eléctrico, de alimentación ininterrumpida, de agua, de gases, de puesta a tierra, etc.

- CPDs redundantes o, como mínimo, la parte más importante, el almacenamiento. Un servidor se puede sustituir (es cuestión de €s), la pérdida total de los datos y de todo soporte disponible puede no serlo. ¿Qué hubiese pasado si nuestra empresa y todos sus sistemas hubiese estado en las torres gemelas o en la torre windsor? (bueno, sin contar con disponer de "backups" de todo en la caja innifuga de la windsor). Además, este nivel de redundancia nos permitirá jugar con distintos esquemas de alta disponibilidad y balanceo de carga, etc., sobre infraestructura en distintos edificios. Recuerda que muchas de estas tareas podrás delegarlas en equipamiento "hardware" especializada, como puedan ser los balanceadores de carga, aceleradores SSL, etc. Aunque en clase referencié algunos de estos dispositivos, no los incluyo aquí por no hacer publicidad. Si algún proveedor de este tipo de sistemas llega a esta entrada y está interesado en presentar alguno de sus "cacharros" a un grupo de unos 60 futuros profesionales, que no dude en contactar. Por favor, abstenerse comerciales.

Observación para los alumnos.: Es habitual encontrar comerciales que siempre tienen una respuesta afirmativa a cualquier cuestión técnica del tipo si se puede hacer tal o cual cosa que, a posteriori, se vuelve prácticamente inviable. Cuando te entrevistes con comerciales, procura documentarte bien sobre el tema a tratar y, de ser posible, ponle algún examen sobre cuestiones que tengas claras y sean poco viables para ver su grado de fiabilidad. Y recuerda que no encontrarás un buen comercial que antes no haya sido buen técnico. Esto mismo se puede aplicar a los directivos y gestores de personal. Vivimos en un mundo en el que con cierta frecuencia se trata de "vender la moto", aunque "menos mal que nos queda Portugal".

- Backups redundantes. Son demasiadas las veces que asistimos a situaciones en las que en el momento de necesitar un "backup", no está en las condiciones que debería, o con la política adecuada a nuestras necesidades. Una buena política de "backups" nos dejará dormir más tranquilos por la noche. Tampoco es aceptable entrar en un CPD y encontrar DLTs de "backup" zapateados por las mesas.

Sobre "backups", haciendo memoria de los tiempos en los que ejercía la segunda profesión más antigua del mundo, al inicio de los noventa utilizaba el tar sobre cintas de 150 Mb. Todo estaba planificado y organizado pero, la primera vez que necesité recuperar algo, mi dispositivo me recibió con un checksum error. Que hijo de puta, con perdón, pensé yo. En esas fechas descubrí que habría ciertas tareas que se debían hacer en single user, o buscar una utilidad un poco más evolucionada e inteligente que un simple tar. Pero bueno, con un poco de imaginación al final se pudo hacer la recuperación. Pasaron unos años y las unidades de cinta de 4mm. llegaron a poblar nuestras mesas (ellas nunca lo harían, no las dejes abandonados encima de la mesa). Ahora pensábamos en Gb, en lugar de Mb., y la compresión de la información entró en nuestras vidas. Era habitual encontrar "backups" sobre cpio, dump-restore, afio, etc. También empezamos a exportar disco en red y a hacer "backups" a disco, mucho más rápido. Finalmente, antes de dejar de ejercer esta gratificante profesión, se instaló un sistema de "backup" en red, un IBM server con el software de "backup" TSM, Tivoli para los amigos, con un primer nivel de "backup" a disco, en el que predominaba como mecanismo de seguridad el RAID5, y un segundo nivel de transferencia a un dispositivo de LTOs. Sin duda alguna las posibilidades de planificación de "backups" en este tipo de sistemas permiten una flexibilidad más que suficiente para atender las peculiaridades de todo tipo de entornos, sistemas y usuarios.

- No quiero dejar fuera de esta sección otro elemento importante a redundar, al menos parcialmente, se trata del personal. Es habitual encontrarnos profesionales que utilizan todo tipo de estrategias para garantizar, muchas veces en un proceso oscurantista, que todo está bajo su único control. No es un delito, pero toda organización deberá tratar de redundar, en la medida de lo posible, total o parcialmente según sea el entorno de trabajo, las atribuciones más críticas del personal técnico. Como decía y dice Rosendo, "esto es la fauna, chaval". Pero también puedes encontrarte el típico centro con buenos profesionales, que planifican todo el trabajo, las migraciones, etc., etc. En estos casos los servicios proporcionados y el trabajo desarrollado pueden llegar a pasar desapercibido para los usuarios y, o, directivos. En algunas situaciones se puede llegar a pensar que sobra personal o que parte del mismo se puede derivar a otras tareas. En el lado opuesto esta el entorno de trabajo que no planifica o hace mal los desarrollos. Se puede llegar a dar la situación que cada cierto tiempo el usuario se percata de problemas en el servicio, así como los directivos, y de la gran labor que desarrolla ese personal técnico y la enorme necesidad de contratar nuevo personal para que todo funcione bien. En estos casos siempre suele aparecer el "técnico" salvador que, después de generar grandes problemas, los soluciona para aplauso de todos los que asisten al circo. Obviamente, contratar nuevo personal no suele solucionar el problema. Pero bueno, siempre queda la opción de coger a los mejores técnicos y aplicar la redundancia por medio de la clonación. Esto último no es posible, pero identificar el trabajo bien hecho debe ser una de las principales tareas de cualquier directivo. Obviamente, será difícil, por no decir imposible, que un directivo pueda llegar a desarrollar bien su trabajo, si antes no ha sido un buen técnico, o al menos aceptable. Como consejo, no tengas prisa por llegar a la cima de la montaña, disfruta de la ascensión. Y recuerda que la cima no es el paraíso.

Finalizamos la clase con un clásico de la redundancia en almacenamiento, los sisetmas RAID (Redundant Array of Inexpensive Disks). En este punto se incluyen conceptos como "hot swap", cabinas de disco, SCSI (Small Computer System Interface), SATA, "Fibre Channel", SAN (Storage Area Networks), "fabric director", etc.

Se analizan los niveles RAID básicos.:

- Lineal (muy bonito en la teoría, pero no sirve para nada)

- 0 "stipping" (utiliza n discos con almacenamiento en paralelo sobre los mismos). Un fichero se almacena en varios discos duros. Este nivel busca un incremento en el rendimiento de la I-O a disco, sin aportar redundancia-seguridad en el almacenamiento. Habitual encontrarlo en sistemas de edición de vídeo (el "rendering" suele comer todo rendimiento a disco que le podamos proporcionar), cálculo científico intensivo (modelos climáticos, biología molecular, etc.) y, en general, en todo entorno que mueva grandes cantidades de datos con nuestros discos. A nivel operativo, señalar que podemos hacer RAIDs de particiones o particiones de RAIDs. Es habitual que, con el tiempo, se tengan que adquirir nuevos discos duros y, por lo tanto, convivan distintos tipos de discos. Una buena organización mejorará los rendimientos o, al menos, no los empeorará. ¿qué pasaría si en un RAID 0 o 1 algunos discos duros fuesen más lentos que otros?

- 1 (mirror). En este nivel existe una redundancia total del almacenamiento, garantizando la disponibilidad del sistema ante casques de dispositivos. Obviamente, todo tiene un coste, y este caso requerirá una doble inversión. Recuerda que si únicamente dispones de una controladora de discos, podrás estar protegido ante la "muerte" de discos, pero no de controladora. Redundar las controladoras y organizar los discos adecuadamente te proporcionará otro nivel de seguridad.

En este punto, antes de continuar con los RAID, se analiza el proceso de "bautizo" de un disco duro. Un disco duro no se puede montar según te llega de fábrica, hay que bautizarlo (particionarlo y generar el sistema de ficheros). Aunque los discos duros virtuales de nuestro laboratorio no se puedan tocar, al ser ficheros, requieren seguir el mismo proceso. No puedo tratar de montar un disco duro que no ha sido particionado, ni generado su sistema de ficheros. El fdisk y el mkfs te podrán solucionar dicha tarea. El fichero /etc/fstab será el encargado de definir la información de montado. En clase se analiza el formato del /etc/fstab y las opciones que podemos encontrarnos. No incluyo en esta entrada nada al respecto, al estar ampliamente publicado en diversas fuentes. También analizamos el conjunto de ficheros y directorios que nos podemos encontrar en el, como dice la literatura, "pseudo" sistema de ficheros /proc.

Concluimos la clase con una cuestión, ¿qué sistemas de ficheros utilizaremos?. La respuesta no es cualquiera, o el reiserfs o ext3 que es el que suelo encontrarme. Si dentro del comando fdisk selecionas la opción l verás varias decenas de sistemas de ficheros distintos. Entonces, para que tantos?. Pues bien, los sistemas de ficheros son como el vino, los hay buenos y malos, unos aconsejables para ciertas comidas y otros para otras. A nadie se le ocurre tratar de meter un fichero de 4 GB en un disco FAT. Por lo tanto, deberemos tener en cuenta factores como los discos duros y buses disponibles, tamaño de los ficheros y directorios, números de lecturas y escrituras, patrón de los accesos a disco y carga de trabajo, algoritmos o planificadores disponibles, gestión de bloqueos, estrategias de reconstrucción ante "casques", etc. Dejamos el tema aquí exponiendo dos posibles configuraciones de un mismo servicio, el de correo electrónico que, según utilicemos "mbox format" o "maildir format" las implicaciones en cuanto al sistema de ficheros serán radicalmente opuestas.

Para terminar, hablando de rendimimiento y seguridad en el almacenamiento, un curioso video de rendimiento con SSDs (fuente Tomás, gracias). Además, no debemos olvidarnos que el cifrado de los sistemas de ficheros tienen su implicación en el rendimiento.

next gen discs

De los muchos emails que me llegan con noticias de nuestro mundillo, algunas de las cuales están relacionadas con los temas tratados en clase, son varias las que merecen nuestra atención, aunque no me queda otra que hacer una selección. Adjunto contenido email remitido por F.A.R.M.
-------------
Encontré un artículo que es relevante de acuerdo al tema que diste en clases pasadas sobre almacenamiento y respaldo de información. Unos investigadores han logrado crear una especie de disco compacto capaz de almacenar el equivalente a 2,000 DVD’s utilizando una tecnología de 5 dimensiones (3 espaciales y dos extras: espectral y polaridad). Esperan que una aplicación comercial llegue en 5-10 años, y podría marcar una nueva manera de guardar respaldos de nuestra información. Enlace de la noticia aquí.
----------------
Sobre el tema, los interesados en otros trabajos relacionados con dispositivos de almacenamiento de alta capacidad, señalar por ejemplo los diferentes desarrollos en sistemas holográficos. Para más información Holography System Development Forum (HSDF).

Pdt.: Sin duda alguna los futuros y cada vez más cercanos procesadores de varias decenas de núcleos requerirán de nuevos planteamientos jerárquicos de almacenamiento, empezando por las caches y terminando por los discos.

Ensuring Data Security During Hardware Disposal

Noticia disponible en http://www.darknet.org.uk/2009/05/ensuring-data-security-during-hardware-disposal/

Hemos hablado de seguridad a nivel físico, de la necesidad de aplicar mecanismos de protección a nivel físico, del hardware. Todo "hardware" tiene un ciclo de vida y, tras la vida, nuestros equipos se pueden reencarnar en nuevas vidas. Lo que para unos es chatarra, para otros es un tesoro. Pero, ¿qué pasa con nuestros equipos que dejan de dar servicio?. Entre otras muchas cuestiones, sus discos duros, los dispositivos de backups, etc., siguen soportando información durante muchos años que, incluso después de un mal-borrado, se podría llegar a recuperar. Como ejemplo, la noticia que encabeza esta entrada.

A nivel funcional, señalar la existencia de herramientas para hacer un borrado de nuestros dispositivos de almacenamiento magnético, de tal forma que ningún análisis forense pueda recuperar la información (DBAN y Eraser). Si manejas información crítica, sin duda alguna deberás definir un método de reciclaje al nivel de las circunstancias, evitando que los equipos puedan darte un susto en su segunda vida o, en caso de duda, siempre puedes pulsar el botón de autodestrucción. Aunque a todos nos gusta probar técnicas y herramientas como metodología de aprendizaje, no pruebes estas herramientas en tus discos duros. Y de hacerlo, un backup completo previo o imagen te vendrá muy bien. -:)

Puedes complementar el tema con "La recuperación de datos, un arma de doble filo"

Para borrado seguro de ficheros destacar, entre otros, srm, wipe o shred. Como todo en este mundo, toda herramienta proporciona un "arma" muy valiosa tanto para el lado oscuro, como para el de la luz, unos por protección de la información y, los otros, para eliminación segura de cualquier posible rastro.

smartmontools: control the health of your hard disk

La práctica 3 de PSI está pensada para analizar y probar distintos aspectos relacionados con la protección y seguridad en los dispositivos de almacenamiento. En esta entrada se presenta una noticia relacionada con una herramienta para el análisis de la "salud" de nuestros discos duros, esos pequeños aparatitos que traen nuestros computadores, y que de vez en cuando nos dan algún susto. Es muy posible que en futuras versiones de la práctica 3 incluyamos algún apartado relacionado con esta herramienta.

Modern SCSI disks have it too if they’re SCSI 3 or newer. It happens that inside the disk chipset there are routines to check parameters of disk health: spin-up time, number of read failures, temperature, life elapsed… And all of those parameters are not only registered by the disk chipset, but they have designated security limits and both parameters and limits can be checked by software who access the disk using the appropriate I/O instructions.
And that software is smartctl, a piece of the smartmontools deb package.

[Fuente noticia completa.: http://debaday.debian.net/2008/10/12/smartmontools-control-the-health-of-your-hard-disk/]