Archivos de Categoría: almacenamiento

ix0: Unsupported SFP+ module detected!

Ya el año pasado, me tocó lidiar con la estúpida decisión de Intel de que sus chips de 10G no funcionan con los SFP que no entran en la corta lista de los que tienen probados.

La historia se repite, y esta vez ha sido un venerable FreeNAS 11.1 en un nuevo armario y con nuevos y flamantes cables AOC el que lleva el controlador de Intel que ha decidido, vaya hombre, que los AOC no son lo bastante flamantes; que si eso, que compre otros.

Uno no tiene tiempo ni ganas de dejarse llevar por las veleidades de una empresa que tiene gente trabajando en puestos que llevan a la vez la palabra technical y la palabra marketing (pobrecicos).

Usando la clásica técnica de poner en un buscador el mensaje de error que sale en dmesg y que da título a este artículo, en seguida se llega a algún ticket del redmine de IXsystems / FreeNAS; no en vano es uno de los mayores distribuidores de FreeBSD del momento.

El caso es que, como suele suceder, las cosas no pueden ser tan fáciles.

¿Es cierto que añadir a /boot/loader.conf las palabras mágicas:

hw.ix.unsupported_sfp=1

resuelve el problema? Si.

Pero no es menos cierto que en la versión 11.1, no. Vamos, lo ignora completamente en la versión que va en el kernel de la 11.1.

Así que, usando la clásica y probada por la experiencia técnica de la huida hacia delante, me bajé la ISO de la última estable de FreeNAS y le hice una actualización in situ. Las actualizaciones de FreeNAS son una gozada, si bien hacerlas sobre uno de esos KVM viejos de Supermicro no son la mejor experiencia del mundo. Pero en una máquina virtual Windows bien añeja (de Windows 7 para atrás) funcionan, así que no me voy a quejar demasiado. Total, hace años que por estas cosillas dejé de comprar Supermicro y pasé a comprar Dell.

Una vez hecha la actualización, arrancado el sistema nuevo, ya todo…

…Una mierda. Resulta que la actualización instala su propio /boot/loader.conf. Bueno, no pasa nada: Otra vez KVM basado en Java y volver a añadir hw.ix.unsupported_sfp=1 al final del ficherito.

Y esta vez sí, por fin, quejándose como un abuelo hablando de política en el bar del pueblo, por fin levantó los puertos de 10G. Y el resto, como se suele decir… Es historia.

Cuando zfs se hace el pool un lío porque hemos hecho demasiados experimentos

Instalar una Debian 9 con zfs en la raíz es, si no rápido, al menos relativamente indoloro gracias a la guía que mantiene zfsonlinux en Github.

Aunque esa guía es enormemente concienzuda en cosas como limpiar bien los discos antes de usarlos, no puede protegernos de nuestra propia impaciencia y de que nos encontremos con restos de una instalación anterior. Si esto sucede, puede darse el caso de que al arrancar el kernel, se queje de que no puede importar un pool que está en un estado calamitoso, y zpool import nos sacará dos pools donde esperábamos uno: El bueno, y el malo, resto de un intento anterior, que además tiene una pinta bastante fea. Claro: hemos escrito otro encima… Pero no en las mismas particiones.

Carallo, ¿y qué hacemos? Nos hemos tirado horas preparando el servidor, luego haciendo la instalación (que finalmente sale bien a la tercera, claro)… Y no queremos empezar desde cero.

Como hay un dios para los informáticos y ayer estaba de guardia, sucedió que el pool bueno es un mirror, y el pool malo está en una partición de uno de los miembros del mirror, según nos ha informado diligentemente el mencionado zpool import. Y para algo tienen que servir los mirror, ¿no es cierto?

Pues hala, nos cargamos el principio del disco que tiene el zpool chungo, donde están el MBR, la tabla de particiones y las etiquetas de los vdevs de zfs:

dd if=/dev/zero of=/dev/sda bs=512 count=2000

Miramos cómo de largo es:

cat /sys/bus/scsi/devices/0\:0\:0\:0/block/sda/size
11721045168

(el angelito en cuestión es un WD Red de 6 TB)

Y nos cargamos también el final, donde hay guardadas las copias de las etiquetas de los vdevs de zfs:

dd if=/dev/zero of=/dev/sda bs=512 count=2000 skip=11721043168

rearrancamos, y genial: El servidor arranca desde el siguiente disco (porque hemos tenido la precaución de pedir a grub que escriba el MBR en todos ellos), el pool malo ha desaparecido, el bueno se monta solito (informando de que se encuentra un poco mal, y de que hagamos algo al respecto) y el sistema arranca. Nos hemos ganado el salario de hoy.

Configurar un RAID de HP que corre ESXi

Supongamos que tenemos un servidor HP corriendo ESXi felizmente, accediendo a almacenamiento por red. Y supongamos que se nos ocurre la feliz idea de recopilar unos cuantos de esos discos SAS que tenemos por ahí cogiendo polvo desde que los sustituímos por unos humildes SATA que, siendo mucho menos pijos pero de estado sólido, les han dado una paliza horrorosa en consumo y rendimiento. A la vez.

Quizá el servidor en cuestión está ocupado haciendo lo que hacen los servidores con ESXi normalmente en un entorno de alojamiento en centro de datos, es decir, servir webs con WordPress y rechazar spam. Y nos da cosita interrumpir este feliz quehacer cotidiano solo porque hemos tenido una ocurrencia más.

HP ofrece, al igual que Dell y otros fabricantes, una herramienta para configurar sus controladoras mientras corren lo que sea que están corriendo. En el caso de HP, se puede encontrar fácilmente buscando por HPE Smart Storage Administrator (HPE SSA) CLI for VMware en la web del servicio técnico de HPE. Esto nos ofrecerá un vib, que podemos burguesamente scp al servidor en cuestión y seguidamente

esxcli software vib install -v ssacli-2.65.7.0-5.5.0.vib

(por ejemplo).

La documentación de esta herramienta es todo lo completa y farragosa que acostumbran los grandes fabricantes. Pero, por resumir una larga y diagonal lectura:

A ver, ¿qué hay aquí?

/opt/smartstorageadmin/ssacli/bin/ssacli controller all show config

A ver, quiero un RAID

# /opt/smartstorageadmin/ssacli/bin/ssacli controller slot=0 create type=ld drives=allunassigned raid=10

Y así se teje. Seguidamente, nos vamos a nuestro cliente de vmware obsoleto favorito, creamos un vmfs, y a correr.

Copiar un disco en vmware, lo más rápida e indoloramente posible

Cuando las cosas se van al guano, o sea, pocas veces pero más que las que uno quiere, a veces se acaba necesitando sacar máquinas virtuales de un almacenamiento, a mano, con las mayores garantías de integridad pero sobre todo tardando lo menos posible, para que los usuarios de las mismas no sufran más que lo mínimo y esa noche, a ser posible, se pueda dormir un ratito.

Hay más de una forma de pelar un gato, y cuando se trata de mover máquinas virtuales a mano en entornos vmware, hay muchas: scp, el explorador de archivos del cliente de vCenter, cp o mv sobre los directorios en que están montados los almacenamientos, rsync (que no va de serie, pero un binario estático va de maravilla) y algunas más.

Pues bien, para mover rápido y con garantías, lo más conveniente es una herramienta que:

  • Tire de la librería de discos del hipervisor
  • Conozca y respete los discos «thin provisioned»
  • A ser posible, venga ya de serie.

Esta maravilla existe: se llama vmkfstools. Así en plural.

El procedimiento no es directo pero tampoco es ciencia aeroespacial:

  1. Eliminar la máquina virtual del inventario, para evitar interferencias.
  2. Copiar el fichero de definición de la máquina virtual (.vmx y .vmxf al directorio destino) con un vulgar cp
  3. Clonar el/los disco(s) con vmkfstools -i /volumen/origen/disco.vmdk /volumen/destino/disco.vmdk -d thin.
  4. Añadir la máquina destino al inventario.
  5. Limpieza y acabado.

Et voilá. Esta estrategia es la más rápida y, al usar disklib, nos garantiza el trato más correcto al fichero del disco de la máquina virtual, así como la mayor velocidad de copia.

Los Samsung Evo 850: Una maravilla en todo, salvo cuando llegan

Cuando uno se compra un disco para, digamos, el ordenador de jugar, casi le hace ilusión que el embalaje sea incluso un poquillo complicado de abrir. Es el momento del descubrimiento; hace un poquillo de ilusión.

Cuando uno compra los discos por docenas, no le hace a uno maldita la gracia que el embalaje sea un coñazo de abrir, que haya que invertir varios minutos para acceder al chisme, y varios más en clasificar los residuos. Multiplicado por docenas, claro.

Todo esto viene a cuento de mis discos de estado sólido favoritos, los Samsung Evo 850. Son unos trastos estupendos, muy fiables y de un precio no barato pero relativamente contenido. Los hay desde 256 GB hasta 4 TB (estos últimos de un precio astronómico, pero démosles tiempo). Y hasta estéticamente tienen su gracia.

¿Inconveniente? El embalaje.

En primer plano, siete Evo 850 de 1 TB; detrás, todo el embalaje con el que vienen

Los discos en cuestión, según me han explicado en varias ocasiones, no se suministran en bulk, o sea, en una caja que contiene una o dos docenas de discos. Solo se suministran en caja bonita. Lo cual está muy bien cuando uno pide, digamos, a PC Componentes una unidad para su ordenador de jugar. Pero no cuando uno tiene sobre la mesa tres docenas de discos, y a cada uno de ellos tiene que:

  • Romper el sello para abrir la caja (lo cual requiere una cuchilla, porque no viene trepado ni nada parecido).
  • Sacar el disco de la caja, que viene en una bandeja de polipropileno.
  • Montarlo en su bandeja.
  • Separar la bandeja de polipropileno del sobre que contiene el manual, que está adherido con un pegamento del juicio final. Samsung: aunque venga sin pegar, tampoco se va a perder.
  • Separar del sobre que contiene el manual el CD (¡sí, en 2017!) en que vienen cosas que se pueden descargar de la web de Samsung en el improbable caso de que hagan alguna falta.
  • Separar por un lado el CD y la bandeja del disco, por otro la caja y los manuales
  • Tirar todo a su cubo correspondiente

No solamente es un desperdicio de material. También lo es de tiempo. De verdad, Samsung, ¿no podéis vender estos discos en bruto? Ni siquiera estoy discutiendo el precio. Solo quiero no perder tiempo y que no me duela tirar todo ese material inútil.

Las LSI 9211-8i y el modo IT

La madre de las tarjetas interesantes fabricadas por LSI que son útiles para algo como FreeNAS o (probablemente) BlueStore, es la 9211-8i: Dos conectores SFF-8087 y, algo de magia negra mediante, ningún software RAID entre los discos y el sistema operativo principal. Es básicamente la misma tarjeta que la Dell H310 o la IBM M1015.

Sin embargo, para convertir estas tarjetas a modo IT, he tenido que hacer algo distinto. En algunas placas base, los sas2flsh.exe de DOS no funcionan. Ni idea del motivo; da un error diciendo algo de PAL, que me suena a tele analógica en color. Así que he tenido que recurrir al shell UEFI.

Como no todo podía ser bonito, el shell UEFI de la Supermicro X9SCM-F tiene dificultades para ver un sistema de ficheros que no sea el de un disco SATA (tampoco ni idea de por qué: tenía que flasear las malditas tarjetas, así que simplemente fui aceptando los hechos tal como me los iba encontrando). Adiós al brillante plan de cascar los ficheros en un pincho USB y terminar.

Total, que con un FreeDOS instalado en el disco C:, me bajé el paquete Installer_P20_for_UEFI de Broadcom (ex Avago, ex LSI), creé un directorio 9211 y le copié:

  • sas2flsh.efi
  • MPTSAS2.ROM
  • 2118IT.BIN

Si se intenta meter el firmware IT sin más, el chisme se niega, indicando (un tanto estúpidamente) que nada de flasear un firmware IT sobre uno IR. Así que, igual que con toda la familia, lo primero que hay que hacer es

sas2flas.efi -o -e 6

Al carallo, ya no hay firmware. Ahora ya nada nos lo impedirá:

sas2flas.efi -o -f 2118IT.BIN -b MPTSAS2.ROM

La BIOS no creo que sea necesaria, pero ya estaba un poco cansado y decidí que ya experimentaría con quitarla de en medio en otro momento, si eso.

Como cosa curiosa, al borrarles la flash a estas tarjetas, no han perdido su dirección SAS.

Como cosa más curiosa aún, el proceso de pasarlas a IT ha sido el más sencillo de la familia.

Referencias y créditos:

  • http://brycv.com/blog/2012/flashing-it-firmware-to-lsi-sas9211-8i/
  • https://linustechtips.com/main/topic/104425-flashing-an-lsi-9211-8i-raid-card-to-it-mode-for-zfssoftware-raid-tutorial/
  • Añadido con posterioridad a la redacción: https://www.broadcom.com/support/knowledgebase/1211161501344/flashing-firmware-and-bios-on-lsi-sas-hbas
  • La referencia definitiva para hacerlo rápido y fácil:
    https://fohdeesha.com/docs/perc.html

Un disco de estado sólido para usar con FreeNAS, rápido y barato

Hay dos buenos motivos para tener en un servidor con FreeNAS, al menos un disco lo más rápido posible. Uno es poder usarlo para L2ARC, y el otro es usarlo para SLOG/ZIL.

No voy a entrar en los detalles de una y otra cosa, porque para eso se ha molestado jgreco en escribir el artículo antes referido en los foros. En lugar de esto, voy simplemente a compartir lo que he hecho.

Un disco rápido, en los tiempos que corren, quiere decir SSD. Pero dentro de los SSD, también hay clases. No me refiero a los discos «Enterprise» o «Pro», sino a algo más básico y es que hay discos SSD con puerto SATA, SAS, mSATA y M.2. Para acabar de confundir el asunto, este último formato puede llevar, según le parezca al fabricante, presentado en su conector un puerto SATA 3.0, un PCI Express 3.0, y/o un USB 3.0. De estos tres buses, el más rápido con diferencia es el PCI Express, así que el siguiente paso es elegir un disco M.2 con bus PCI Express y un adaptador para poder pincharlo en la placa base del servidor en cuestión.

Siendo uno de natural perfeccionista y rata a la vez, he acabado con esta solución de lo más afinado en ambos: Un disco Samsung 960 Evo, un poco más caro que los tradicionales 850 Evo SATA pero no una barbaridad en capacidades modestas, y un adaptador que Amazon está encantado de vender por la principesca suma de 7 euros y 99 céntimos, porte incluído:

Este adaptador funciona, no hay mucha ciencia en ello, pues se trata básicamente de llevar las líneas adecuadas del conector PCI Express al conector M.2. Viene con chapita para ranuras de altura completa, y la que se ve en la foto es una adaptación hecha en mi taller de una que agarré en la pila de los trastos.

Tal cual, no hay más que pincharla y contarle a FreeNAS para qué la queremos usar.

Usando una tarjeta Dell H310 con FreeNAS

Es vox populi que FreeNAS, o cualquier cosa que use ZFS como la versión 5 de Proxmox VE, quiere acceso directo a los discos para que el ZFS los gestione directamente. Es decir, no queremos una tarjeta RAID presentando un único volumen gordo con todos los discos que tiene detrás; solamente queremos que el sistema operativo vea todos y cada uno de los discos.

Para hacer esto, la opción más sencilla es tener una placa base con todos los conectores necesarios. Pero a veces tenemos una cierta cantidad de discos, por ejemplo 12 o 24, conectados a un backplane que, típicamente, cuenta con un par de conectores SFF a partir de los cuales conecta todos los discos.

La Dell H310 es una de bastantes versiones remarcadas de la LSI 9211-8i. Es una tarjeta RAID, pero LSI, en su infinita sabiduría, suministra un firmware que la convierte en una sencilla HBA. Es decir, una tarjeta que se limita a conectar discos y presentarlos de manera visible al sistema operativos. O sea, lo que queremos.

Otra encarnación de la LSI 9211-8i es la popular IBM M1015.

¿Por qué comprar la H310? Por lo de siempre: Por dinero. Van más baratas que las LSI. Además, no hay tantas copias chinas como de las M1015.

Dije que LSI suministra un firmware para convertirla en HBA. Ahora bien, aquí acaban las buenas noticias: El proceso que hay que seguir es algo engorroso pero sobre todo plagado de puñetitas. Así que, ya que me he puesto, he decidido documentarlo.

Hay que decir que la tarjeta tiene un firmware y una BIOS, que son dos piezas separadas. En mi caso, decidí dejarla sin BIOS. Esto no es ningún sacrilegio (la tarjeta vive perfectamente sin ella) y ahorra tiempo en el arranque porque, al no tener BIOS, ya no tiene que echar su meadita en cada arranque del sistema.

Siendo uno de natural paranoico, por otra parte, decidí que solamente iba a descargar el software necesario de sitios de los que me fiara. Tuve que hacer un pequeño salto de fe con fdos.org, más que nada porque es la manera más práctica de generar una ISO de arranque con FreeDOS.

En fin. Vamos a por los ingredientes:

  • Una Debian o cosa similar con xorriso (apt-get install xorriso, sin más)
  • FDOEMCD.builder.zip de fdos.org. Unzip eso, suelta un directorio con el DOSero nombre de FDOEMCD
  • megarec.exe. El único sitio fiable que encontré fue, de una FAQ de Supermicroel FTP de Supermicro. Unzip eso dentro de FDOEMCD/CDROOT. Ya de paso, nos suministra megacli.
  • El firmware IT para la H310. Que, por supuesto, no puede estar en una página de descargas de Dell llamada H310. No, está en la página de los R410, que son uno de los modelos que la montaban. Y ni siquiera se llama H310, sino «6Gbps SAS HBA Firmware Package». En fin, que está aquí y que espero que los de Dell tengan que encontrar su camino por Mongolia con un mapa de carreteras de Libia de 1978. Unzip (es uno de esos exe autoextraíbles que unzip también entiende) dentro de FDOEM/CDROOT también.
  • empty.bin, que es un firmware vacío. Es un fichero de 256 bytes que contiene:
    • 0000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      *
      0000090 00 00 00 00 00 00 00 00 ff ff ff ff ff ff ff ff
      00000a0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
      *0000100
    • Si te encuentras especialmente paranoico, créalo con un editor hexadecimal.
    • Y si no eres muy paranoico: empty.bin
    • En cualquier caso, también a FDOEM/CDROOT

Ya tenemos todo.

Ahora cogemos y desde FDOEM, y con fe: xorrisofs -o miiso.iso -p "Yo Claudio" -publisher "blog.tecnocratica.net" -b isolinux/isolinux.bin -no-emul-boot -boot-load-size 4 -boot-info-table -N -J -r -c boot.catalog -hide boot.catalog -hide-joliet boot.catalog CDROOT

No todas las opciones son estrictamente necesarias, pero así queda más mono. Eso genera miiso.iso.

Bueno, pues arrancamos nuestro servidor con eso (si ese día le toca funcionar al KVM del servidor basado en una versión fosilizada de Java, claro) y ejecutamos:

  • En el directorio de Supermicro, tools:
    • megacli.exe -AdpAllInfo -aAll -page 20
    • Tomar nota de la dirección SAS, para ponérsela más tarde, porque nos la vamos a calzar.
    • megarec.exe -writesbr 0 \empty.bin
    • megarec.exe -cleanflash 0

En este punto, hay que rearrancar. No me preguntes por qué, pero si no, no funciona el invento. Venga, rearranca. Yo espero.

Sigamos:

  • Ahora nos vamos al directorio del firmware de Dell:
    • sas2flsh.exe -o -f 6GBPSAS.fw
    • sas2flsh.exe -o -sasadd <la dirección SAS>

Ya hemos acabado. Llegados a este punto, o tenemos una HBA, o algo con que sujetar la puerta. De nada.

Créditos y enlaces de interés:

  • https://tylermade.net/2017/06/27/how-to-crossflash-perc-h310-to-it-mode-lsi-9211-8i-firmware-hba-for-freenas-unraid/
  • https://forums.freenas.org/index.php?threads/ibm-serveraid-m1015-and-no-lsi-sas-adapters-found.27445/
  • http://www.cgsecurity.org/wiki/Create_a_TestDisk_FreeDos_LiveCD
  • http://blog.asiantuntijakaveri.fi/2013/09/turning-dell-perc-h310-to-dumb-biosless.html
  • https://techmattr.wordpress.com/2016/04/11/updated-sas-hba-crossflashing-or-flashing-to-it-mode-dell-perc-h200-and-h310/
  • https://ciamician.wordpress.com/2015/03/06/flashing-your-dell-perc-h310-to-it-firmware-uefi/

Powershell y VMWare: Mola bastante

Voy a ser sincero: Considerando cuándo lo echaron al mundo, Powershell me parece, como dicen los abogados, manifiestamente mejorable. Pero es el lenguaje de scripting (en español: pequeñas ñapillas rápidas) de vmware, y si se necesita hacer algo programado, sin florituras pero que ande, es lo que hay que usar.

Cansado de vaciar a mano los almacenamientos para instalarles parches, decidí ponerme profilaxis, echar mano de Notepad++, y tras las típicas tribulaciones de los que aprendimos a programar hace muchos años y raramente lo hacemos ya (sustitúyase «programar» por «montar en bicicleta» para un ejemplo gráfico), acabé con lo siguiente, que es una ñapa de lo más funcional.

Que ustedes lo disfruten.

<#
.SYNOPSIS
 Vaciar un almacenamiento
.DESCRIPTION
 Mueve todas las máquinas virtuales del almacenamiento origen al destino
.INPUTS
 None
.OUTPUTS Log File
 Por ahora, no deja ni rastro
.NOTES
 Version: 0.1
 Author: alfredo
 Creation Date: 20160421
 Purpose/Change: Version inicial
.EXAMPLE
 $almacenOrigen = "Origen"
 $almacenDestino = "Destino"
#>


# Horas de operacion
$horaInicio = "1"
$horaFin = "6"

$almacenOrigen = "Origen"
$almacenDestino = "Destino"

# Usuario y vCenter
$vcServidor = '172.16.0.0'
$vcUsuario = 'usuario'
$vcClave = 'clave'

# Velocidad a la que consideramos que movemos las maquinas en GB/min
$velocidad = 1.5

$historico = "C:\Users\alfredo\$(Get-Date -uformat "%Y%m%d-%H%M%S").sucesos"
Start-Transcript -Path $historico

Connect-VIServer $vcServidor -User $vcUsuario -Password $vcClave
$MVs = get-datastore -name $almacenOrigen | get-vm | sort UsedSpaceGB

Foreach($MV in $MVs) {

 # Ver si estamos en hora y si acabariamos en hora
 do {
 $h=Get-Date
 sleep 100
 } while ( ($h.Hour -lt $horaInicio) -or ($h.Hour -gt $horaFin) )
 $mogollon=[math]::round((get-vm $MV).UsedSpaceGB , 2)
 $finEstimado=$h.AddMinutes($mogollon/$velocidad)
 if ( $finEstimado.Hour -lt $horaFin) {
 Write-Host ([string](Get-Date) + " Empezando a mover '" + $MV.Name + "'")
 Move-VM -VM (Get-VM -Name $MV) -Datastore $almacenDestino -DiskStorageFormat thin
 Write-Host ([string](Get-Date) + " Movido '" + $MV.Name + "'")
 } else {
 # Estamos fuera de hora, asi que esperamos
 # Deberiamos calcular mejor cuanto tenemos que esperar, para otra version
 sleep 1000
 }
}

RTS: Mola mucho

Los chicos de RisingTideSystems me han facilitado una versión previa de lo nuevo de su fábrica de pequeños milagros cotidianos iSCSI y aledaños, a saber, LIO y su herramienta de administración rtsadmin. En pocas palabras, se han superado.
Lo he montado en dos almacenamientos con diferentes tarjetas RAID. En realidad, empiezo a pensar que las tarjetas RAID son totalmente prescindibles, pero ya que las tenía no las iba a tirar.
Ahora, rtsadmin tiene un interface de línea de comandos de lo más pocholo, con colorines y completado de comandos con el tabulador. Sin leer ni una triste guía rápida, en dos ratitos tenía el primero levantado y conectado a los ESXi.
Aunque no he hecho pruebas formales de rendimiento, la impresión es que va muy bien. Y tan libre de problemas como el anterior.
Me fastidia moderadamente que hayan cambiado la Debian que utilizaban anteriormente como base por una SuSE. No entiendo por qué lo han hecho, aunque pare gustos, los colores. Lo que importa al final es que el iSCSI va fiable y mangao.
Tal como viene, además de rtsadmin y por supuesto LIO, trae un módulo para Nagios (nrpe), arcconf (gestión de tarjetas RAID de Adaptec), OpenIPMI, DR:BD, parted y cosas de esperar como Samba, rsync, etc.
RisingTideSystems empieza a ofrecer su software, mediante suscripción anual a un precio que me parece bastante lógico (comparado con Open-E y similares), a ciertos clientes. Les auguro un éxito total.