A veces, uno tiene la sensación de ser el último en enterarse.
Así me ha sucedido con el peculiar uso, por parte de Mikrotik, del puerto 2000 (que IANA asignó al protocolo SCCP de Cisco en el ya lejano año 2003).
Ellos lo usan para una herramienta llamada bandwidth-server, cuya utilidad en este mundo es probar el ancho de banda de una red conectada a un Mikrotik. Y lo mejor de todo: Está disponible tanto por TCP, como por UDP.
¿Soy el último en pensar que esto es una mala idea, dicho con toda la diplomacia de que soy capaz?
En fin. A lo que voy:
/tool bandwidth-server set enabled=no
Y se acabó el problema. Problema que no debería existir, para empezar a hablar.
Así que voy a añadir esta línea a mi receta de Ansible para Mikrotiks, junto con deshabilitar la pila de servicios que vienen por defecto habilitados.
Mikrotik y el puerto 2000
Mac OS X no se deja actualizar
Sucede en las peores familias: Uno se apunta a las betas de Mac OS X en un momento de locura y desenfreno. Prueba antes que nadie, un tanto kamikazemente, cosas como APFS. Y un buen día, encuentra que no hay cosas aparentemente tan guays que justifiquen seguir corriendo betas. Así que saca el ordenador de las betas. Fácil, ¿no?.
Pues no.
Por algún motivo que no he llegado a comprender del todo, desde que saqué mi ordenador de las betas de Apple no actualiza bien. App Store avisa de que hay una actualización, la descarga, rearranca, hace como que la instala… Y al volver al escritorio, está la que estaba antes.
Mientras encuentro el tiempo (léase «ganas») de investigar el motivo último de este comportamiento, he encontrado una forma de instalar las actualizaciones a mano. Es poco trabajo, pero me ha costado un poco reunir la información, así que aquí queda.
Lo primero es hacernos con el «Combo update» en la página de descargas de Apple. Cuando acaba de salir una versión nueva, suele ser lo primero que sale.
Segundo, arrancar el Mac en modo recuperación (Cmd-R mientras hace clonnnng). Este es un modo mínimo que corre separadamente del sistema operativo principal, y por tanto no se ve afectado por las veleidades de éste.
Tercero, ya con el Mac arrancado en modo recuperación, tirar de la Utilidad de Discos y montar:
- Nuestro volumen principal. Sale en la barra lateral, no hay más que marcarlo y puchar el botón «Montar». Habrá que poner la clave si es encriptado.
- La imagen de disco de la actualización: Archivo, Abrir imagen de disco, buscarla y listo.
Armados con todo esto, ya podemos burguesamente abrir un terminal y, con la línea de comandos:
installer -pkg combo.pkg -target nuestrodisco
Por ejemplo:
installer -pkg /Volumes/macOS\ High\ Sierra\ 10.13.4\ Update/macOSUpdCombo10.13.4.pkg -target /Volumes/Macintosh\ HD
Y cuando diga que está listo:
reboot
Y el universo volverá a estar en equilibrio… Hasta la próxima.
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.
Los controladores virtuales en máquinas virtuales
«Modern OS should use virtio-scsi anyways«. Esta cita de Tom, de Proxmox, originalmente en su foro, suena a buena idea. Ya que hemos sustituído una controladora SCSI (SATA para nosotros, los humildes), con su correspondiente disco, por una mera simulación software de la misma y un trocito de un disco más grande, suena correcto que el controlador por el que el virtual pide sus operaciones sea virtual.
Hay varias razones para ello. La más sencilla es que una controladora virtual (una LSI, por ejemplo, que es una de las más populares) no deja de ser un software cuya tarea es interpretar lo que pide el sistema virtualizado, usando unos comandos que se diseñaron pensando en discos que giran y tienen cabezas magnéticas, y convertirlo a lo que el hipervisor ofrece. Esto último, cada vez más, son discos que se parecen mucho más a la memoria RAM que a lo que tenían en mente los que diseñaron el protocolo SCSI para discos. Entonces, podemos librarnos de un montón de trabajo en todos y cada uno de los accesos del virtual al disco si simplemente cogemos lo que el virtual quiere y directamente se lo damos al hipervisor en su lenguaje nativo. Menos uso de recursos, menos código y menos complejo, igual a menos errores. ¿Algún inconveniente?
Claro que sí. La cosa tiene sus inconvenientes. Los aficionados a la retroinformática («mi ERP requiere Windows Server 2003») descubrirán en seguida que los sistemas operativos diseñados hace quince años no llevan controladores para almacenamiento virtualizado. Oh, por supuesto hay solución: No hay más que bajarse la ISO con los últimos controladores, meterla en el CD virtual, e instalar. Si se trata de una máquina que ya existe, solo queda pegar el cambiazo. Ya de paso, podemos meter el controlador de red virtual. Este último mejorará un pelo el rendimiento y uso de recursos de la red, a cambio de… Su propio interface, por supuesto. Ah, ¿que estábamos hablando de una máquina virtual que ya existe? En ese caso, el ejercicio de malabarismo para cambiar uno por otro sin perder la conexión, lo dejo de manos del lector.
Feliz cumpleaños, Víctor.
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:
- Eliminar la máquina virtual del inventario, para evitar interferencias.
- Copiar el fichero de definición de la máquina virtual (.vmx y .vmxf al directorio destino) con un vulgar cp
- Clonar el/los disco(s) con vmkfstools -i /volumen/origen/disco.vmdk /volumen/destino/disco.vmdk -d thin.
- Añadir la máquina destino al inventario.
- 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.
Lo básico para un servidor HP con Linux
Hoy me he encontrado por el centro de datos alante un servidor HP de un cliente. El típico del que no se sabe gran cosa, porque lo gestiona el propio cliente y por tanto para nosotros es una caja con lucecitas.
El caso es que el cliente nos pidió que le pusiéramos la mano encima para resolver unos problemas que estaba teniendo. Y ya que estaba en ello, me miré un poco cómo dejarlo redondo.
En varias distros (al menos, en la Ubuntu en que lo probé) funciona hacer lo siguiente:
wget http://downloads.linux.hpe.com/SDR/add_repo.sh chmod +x add_repo.sh sudo ./add_repo.sh mcp
Esto añade el «repo» de software de HP adecuado según la distribución instalada. Y a partir de aquí, hay dos cosas que encuentro particularmente útiles.
Gestionar la iLO
apt-get install hponcfg
Este paquete instala la pequeña utilidad del mismo nombre. Permite hacer varias cosas con la iLO. Por ejemplo, muy útil, crear usuarios aunque no se sepa cuál es la clave que dejó puesta en el iLO el que montó el servidor:
alfredo@servidor:~$ sudo hponcfg -i
<RIBCL VERSION="2.0">
<LOGIN USER_LOGIN="Dontcare" PASSWORD="UsingAutologin">
<USER_INFO MODE="write">
<ADD_USER
USER_NAME="darthmaul"
USER_LOGIN="darthmaul"
PASSWORD="vaderpichafloja">
<ADMIN_PRIV value ="Yes"/>
<REMOTE_CONS_PRIV value ="Yes"/>
<RESET_SERVER_PRIV value ="Yes"/>
<VIRTUAL_MEDIA_PRIV value ="Yes"/>
<CONFIG_ILO_PRIV value="Yes"/>
</ADD_USER>
</USER_INFO>
</LOGIN>
</RIBCL>
^D
Otras recetas útiles: https://gist.github.com/drolfe/b91ea113714ab823f2df
Actualizar firmware de la iLO
Se baja un fichero scpexe de la web de HPE (con un poco de suerte, aquí). Es un script que corre bien en varias distribuciones. Tan sencillo como ejecutarlo. Verbigracia:
alfredo@servidor:~$ sudo ./CP032487.scexe /home/alfredo FLASH_iLO4 v1.17 for Linux (Sep 30 2015) (C) Copyright 2002, 2015 Hewlett-Packard Enterprise Development Company, L.P. Firmware image: ilo4_255.bin Current iLO 4 firmware version 2.10; Serial number ILOSERIALZ Component XML file: CP032487.xml CP032487.xml reports firmware version 2.55 This operation will update the firmware on the iLO 4 in this server with version 2.55. Continue (y/N)?y Current firmware is 2.10 (Jan 15 2015 00:00:00) Firmware image is 0x1001b1c(16784156) bytes Committing to flash part... ******** DO NOT INTERRUPT! ******** Flashing is underway... 100 percent programmed. \ Succeeded. ***** iLO 4 reboot in progress (may take more than 60 seconds.) ***** Please ignore console messages, if any. iLO 4 reboot completed.
Gestionar RAID
apt-get install hpssacli
Y ya podemos hacer lo que queramos con todos esos discos, incluso cargarnos todo y volver a empezar.
Referencias
http://ximunix.blogspot.com.es/2013/08/hp-toolsfirmware-for-proliantdebian.html
http://downloads.linux.hpe.com/SDR/repo/mcp/
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.
Debian 9 con RAID por software… Y que arranque, y todo
Con lo refinado que está el software libre en general, y el esmero con que está implantado en Debian en particular, es cada vez más raro encontrar, especialmente en una instalación limpia, una situación en que hay que hacer algo siquiera un pelín fuera de guión.
El caso de hoy ha sucedido al instalar en un servidor físico que arranca por BIOS, un RAID 1 por software.
Debian installer, en su versión actual, tiene previsto lo necesario para arrancar con un RAID 1 de discos grandes (y por tanto, GPT), y que además contiene el sistema. Para ello, se necesitan unas pequeñas particiones (1 MB es suficiente) que Debian llama BIOS boot area. Aquí es donde GRUB tiene un sitio para instalar el sector de arranque.
Pues bien, aunque Debian Installer lo ofrece, si estamos particionando manualmente (porque no creemos en la memoria virtual, porque nos gusta usar solo particiones primarias, o porque simplemente somos de la vieja escuela), entonces no acaba el trabajo. Para que el tinglado funcione, hay que hacer lo siguiente.
- En todos los discos que participen del RAID, crear al principio de los mismos sendas particiones de 1 MB.
- Marcarlas, todas ellas, como BIOS boot area.
- Crear el/los RAID oportunos en el resto del disco
- Instalar Debian
Si todo va bien hasta ahora, GRUB se ha podido instalar en el primer disco. Pero no hemos acabado:
- Rearrancar. Debian arranca con el sector de arranque del primer disco (o el que hayamos elegido en el instalador Y en la BIOS)
- Reconfigurar GRUB:
-
dpkg-reconfigure grub-pc
Y marcar todos los discos para que Grub, en lo sucesivo, mantenga en todos ellos actualizado el arranque.
Y esto es todo. ¿Qué hemos conseguido? Pequeños detalles: Que si el primer disco es (Ley de Murphy) el que se va al guano, el sistema pueda seguir arrancando. Típico problema que se queda agazapado hasta el momento más inoportuno.
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
Comentarios recientes