A vueltas con las claves SSH

SSH es un protocolo estupendo, y OpenSSH es una implementación digna de estudio por su usabilidad y pulcro mantenimiento, lo que le ha llevado a una casi ubicuidad.

Con los años, los cifrados han ido cambiando, aconsejándose unos y otros según avanza la ciencia de la criptografía. Los siguientes son los más habituales, y los primeros tres los que más he usado:

  • RSA, el clásico. Aunque desaconsejado por haber sido superado por lo último, sigue siendo la única forma de tener autenticación con clave pública en, sin ir más lejos, los también ubicuos switches Cisco Catalyst, que no conocen otra cosa. No es aconsejable usarlo para nuevas claves salvo en casos como el mencionado si hay otros más modernos.
  • DSA, el que pudo ser. Hace bastantes años, DSA prometía mejorar RSA. Sin embargo, los avances en criptografía lo acabaron poniendo en un riesgo mayor que RSA. En los OpenSSH actuales, se desaconseja usar DSA. Incluso Mac OS Sierra lo trae desactivado de serie.
  • ECDSA, una nueva esperanza. DSA con curvas elípticas. Teóricamente, un DSA sin los problemas de DSA. En la práctica, también tiene sus «problemillas»: Su seguridad depende de lo bueno que sea el generador local de números aleatorios. Ni mencionar a alguien siquiera medio paranoico.
  • Ed25519, el salvador (al menos por ahora). Un algoritmo matemáticamente fuerte, implementable con buen rendimiento, que depende menos del generador local de números aleatorios y, en fin, al que no se le conocen por ahora grietas. En resumen, el que hay que usar si se ha de elegir uno para empezar.

Por cierto. .ssh/authorized_keys2 lleva años desaconsejado, pero aún se ve en servidores por el mundo alante. Trabajando con versiones siquiera medio actuales de SSH, es recomendable mv .ssh/authorized_keys2 .ssh/authorized_keys.

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
 }
}

El flujo de aire en los equipos de red

Es una vieja pelea, de esas que acaban por diluírse en el tiempo, poco a poco, con cambios que se van sucediendo y que acaban por hacer el problema irrelevante.

Los servidores, por una herencia que se remonta al diseño de los PCs originales, absorben aire frío por la parte delantera (donde están normalmente los botones, los dispositivos de almacenamiento, y las lucecitas) y los echan caliente por la trasera (donde están generalmente los conectores, enchufe y cerca de donde se sitúan las fuentes de alimentación).

Los switches de red, por su parte, empezaron por ventilarse de un lado al otro. ¿Por qué? Fácil: Es por donde había hueco. 48 puertos RJ-45 ocupan prácticamente todo el frontal de 1U en un armario de 19″. ¿Y los routers? Pues como Cisco decidió en su día: Pusieron en el frontal los conectores de red, en la trasera el de alimentación… Y empezaron a bufar hacia el lado contrario que los servidores.

Cuando la densidad fue creciendo en los centros de datos, la cosa empezó a ser un problema. Todo el mundo copió a los fabricantes pioneros como Cisco, y el resultado es que a 2016, los equipos de Mikrotik hacen lo que hacía Cisco en los 90: Coger aire del frontal, donde está su pantallita, sus luces y sus conectores, y echarlo hacia «atrás», que es donde está la fuente y el conector de alimentación.

Y con ello, los routers, definitivamente, quedan sólidamente establecidos con flujos de aire exactamente al revés que los servidores: Del lado donde están los conectores, al otro. Mientras que los servidores, fieles a su larga tradición, siguen enviando el aire del «otro» lado, al de los conectores.

En un centro de datos clásico, donde lo que hay es aire frío a cascoporro, cada equipo está montado como cayó, y los flujos de aire no están definidos, eso no es un problema. Pero, ¿qué ocurre en un centro de datos moderno, con separación de pasillo frío y caliente? Pues muy sencillo. Como de lo que más hay es servidores, se puede elegir entre tres alternativas para los equipos de red:

  1. Ponerlos con los conectores al mismo lado que los servidores, y que se frían por estar «respirando» aire caliente;
  2. Ponerlos con un flujo de aire correcto y pasar el resto de la vida moviendo cables de un lado a otro del armario;
  3. Arreglar el bendito problema de una vez, invirtiendo el flujo de aire para hacerlo igual que el de los servidores.

Así que, sin discurrir mucho más, vamos a examinar la alternativa 3.

Empezaremos por hacer notar que algunos fabricantes como Cisco o Juniper, en su infinita sabiduría, hace poco empezaron a fabricar switches (algunos, no todos) que se pueden pedir con los flujos de aire en un sentido o en otro, o incluso dar la vuelta a voluntad. Esto es perfecto para un entorno de centro de datos, sobre todo si hablamos de switches con 48 puertos y por tanto 48 cables que no hay que pasar de un lado al otro del armario y, lo que es más engorroso, mantenerlos.

Sin embargo, si vamos a ver los populares routers de Mikrotik, veremos que, ocupados en detalles sin importancia como crear equipos de una relación precio/potencia de otro mundo, siguen haciendo lo que Cisco en los años 90: Mover el aire al revés que los servidores.

Arreglemos, pues, ese problema.

En los CCR1036, la cosa es fácil. Solo tienen dos ventiladores, exactamente delante del disipador del procesador. Dos tornillos por cada uno, se les da la vuelta y problema resuelto.IMG_8714

En los CCR1072, la cosa es ligeramente más complicada. Llevan seis ventiladores: Cuatro delante del disipador del procesador (que se invierten de manera análoga a como se hace en los 1036) y uno en cada una de las dos fuentes de alimentación. En su infinita sabiduría, Mikrotik ha decidido que los tornillos de la carcasa de la fuente de alimentación sean T-5 (o por ahí), es decir, tirando a rarillos. Nada que no pueda resolver un juego de destornilladores «de precisión», que el chino de la esquina suministrará sin problema ninguno. Hay que desmontar completamente la fuente, sacando la PCB fuera, para acceder todos los tornillos. Pero hecho esto, y rutado el cable del ventilador por un lateral, se acabaron los problemas.

Por cierto, que todos los tornillos dentro de la fuente son los habituales Phillips del número 2. Y nos quejamos cuando Apple hizo aquella jugadita del «pentatorx»…IMG_8716

En el momento de escribir esto, he efectuado la operación en varios 1036 y un par de 1072. Como estos son los más grandes, parecen más interesantes. Pues bien, con el flujo de aire corregido, y cursando 1 Gbps de tráfico, la CPU se mantiene en unos tranquilizadores 50C y 54C; y eso, teniendo justo debajo un par de Catalyst con el flujo de aire al revés.

 

FreeNAS, cada vez mejor

Lo mejor que puede ocurrir con un almacenamiento es que pase desapercibido.
Lo segundo mejor es que sea potente, escalable y demás características deseables.
Un almacenamiento pasa desapercibido cuando no genera problemas, corre lo suficiente y, en general, va como un reloj. FreeNAS lleva haciendo esto ya años.
Para extraer lo máximo de FreeNAS, no solamente en rendimiento sino también, y más importante, en resistencia a fallos, es necesario aprender unas cuantas cosas sobre ZFS. Cómo se organizan los discos en volúmenes. Cuáles son las mejores formas de mejorar el rendimiento y la fiabilidad, dependiendo del hardware de que se disponga; o qué hardware comprar, dependiendo de lo que se quiera hacer.
A fecha de este artículo, estamos convirtiendo todos nuestros almacenamientos basados en sistemas libres de RAID 10 a pilas de RAIDZ-2 de un máximo de 6 discos. Esto da un máximo de almacenamiento exportado (un 15% largo más que RAID10 con solo 6 discos) con un máximo de rendimiento.
Expandir la capacidad de una cabina cambiando los discos por otros de mayor tamaño es relativamente rápido y sencillo, siempre y cuando uno tome la precaución de leer la sección del manual que describe cómo cambiar discos. En algún caso he tenido que ir a la línea de comandos a hacer un zpool replace; nada que quede fuera del alcance de un administrador de sistemas con algunas noches en su haber. Desapercibido.
La flexibilidad, por el hecho de no usar discos con firmware propio, resulta mucho mayor que la de las cabinas «de marca» que mantenemos. Y, aunque estas últimas facilitan algunas operaciones, como el cambio de discos, no se justifica de ninguna de las maneras que cuesten a partir de tres veces más.
Con FreeNAS 9.10, estamos pasando (por recomendación suya) a instalar el sistema en un disco SSD, en lugar de un pincho USB o memoria interna SD. Uno pequeño, de 50 o 100 gigas, es ampliamente suficiente. Como no son muy caros, suelo usar los Samsung 850 Evo de 120. Más espacio libre es más espacio sobre el que repartir las escrituras y por tanto más fiabilidad.
A día de hoy, atesoramos varios años de funcionamiento con FreeNAS. Su fiabilidad ha resultado a la misma altura de las Dell, EMC y compañía. Han pasado igual de desapercibidas. Y han costado de la tercera parte para abajo por bit exportado.

Añadiendo una segunda fuente a un Mikrotik CCR 1036

Publicado originalmente en inglés en el foro de Mikrotik.
Tres de las fuentes originales petaron en solo dos semanas, todas ellas con una chepa en C10:
C10 reventado

Por ello, tuve que invertir algún tiempo en el asunto. Los resultados han sido como sigue.

La primera decisión fue fácil. Dado que las fuentes conmutadas de los 69W necesarios (según las especificaciones en http://www.cloudcorerouter.com/) no son muy caras, decidimos cambiarla por una mejor. La elegida fue la experimentada Traco Power TOP 100, aunque probablemente echaré una mirada a su nueva, y más compacta, TPI 100-124A-J más adelante. Ambas suministran 100W.

Una de las cosas más dolorosamente ausentes en los CCR 1036 es fuentes dobles. El problema es que hay poco espacio dentro de la caja, por lo que se precisa una fuente minúscula. Me decidí por la Mean Well EPS-65S. Aunque un pelín por debajo de lo requerido, permite extraer picos de 71,6W durante 10 segundos, lo cual debe ser suficiente: nunguno de nuestros CCR 1036 en producción se lleva más de 55W contínuamente. Y lo importante es que su perfil es bajo, con una altura de solo 24mm desde la base de la placa hasta la parte superior.

Para instalar esta fuente, diseñé e imprimí en 3D una base que se atornilla a la parte izquierda de la placa base del router con los tornillos originales:

second ps support

Este es el archivo original de la base en OpenSCAD.

La fuente se atornilla a esta base con tornillos, arandelas y tuercas M3.

Los conectores de las fuentes están especificados en sus respectivas hojas de características. Desgraciadamente, una usa Molex y la otra JST; ambos son baratos y fáciles de montar.

Cuando empecé a probar, me encontré con que cuando cortaba la alimentación a la Mean Well, el router rearrancaba. Creo que tira un pico de carga y este pico tira la Traco Power, porque estas fuentes no fueron diseñadas para la redundancia. Esto se resuelve insertando un diodo 1N4004 entre la salida +V de la Mean Well y la placa base. En la próxima conversión, añadiré otro diodo a la otra fuente, por si acaso.

Arreglado eso, las pruebas fueron bien. Cualquiera de las dos fuentes puede arrancar el router y mantenerlo andando durante tanto tiempo como he probado hasta ahora. El router no se entera de un corte a una sola de las fuentes.

La Traco Power se calienta un poco, pero no mucho. La Mean Well, probablemente porque su diodo mantiene su voltaje ligeramente por debajo de la otra y por tanto no recibe carga, se mantiene fría.

Un poco más de prueba en el banco, luego algo de pruebas en el centro de datos, y si no sale nada, verán luz verde para producción.

IMG_8702

Lo más original que me han pedido desde un servicio técnico

Hoy, he ido a un centro de datos a montar un par de balanceadores, Barracuda 340 para ser exactos. Son unos trastos sencillitos, tripa Linux, pero que vienen listos para plantar y funcionar complicándose uno poco la vida.

Desafortunadamente, uno de ellos no pitufó. Se enciende, y a los diez segundos se apaga, sin que se vea nada en el monitor. Algo en la fuente, o la fuente misma parándose para protegerse por exceso de consumo. Sucede en las mejores familias. Abriendo caso con Barracuda.

Total. Les mando el número de serie, una descripción del problema, quién soy, mi talla de calzoncillos… Lo habitual. Y cuando por fin me ponen con un, cito textualmente, «Technical Solutions Engineer», me pide:

– Una foto del monitor en el que no se ve nada.
– Una foto del frontal del equipo.

Yo le ofrecí al fulano hacer un vídeo jurando sobre la biblia que no aparece nada en el monitor, y que el frontal del equipo es el frontal del equipo. Pero nada. Debe profesar otra religión, como la de las Amebas de los Últimos Días. Que le mande una foto de un monitor en negro, y una foto de un frontal igual al de los otros cientos de frontales de equipos del mismo modelo que han hecho.

La del monitor fue fácil, el primero apagado que pillé en la oficina fue suficiente. Ahora, desde cuando se tomaron las miles de fotos del frontal del trasto que hay por la web alante hasta ahora, han cambiado el modelo del frontal. Me cago en su departamento de márquetin. A ver qué invento. Por si acaso, he pedido una foto de verdad. Del que funciona, claro, que el otro ya está metidito en su caja.

guifi.net

La iniciativa guifi.net podría llamarse la Internet por el aire, o la InfoVía de nuestros días, pero hecha para la gente y sin las ridículas pretensiones que caracterizaron al engendro de Telefónica.
Consiste el asunto en hacer una red empleando enlaces inalámbricos para usarla en lo que hubiere menester. Cada uno se paga el cacho de infraestructura que pone en su casa (o en su azotea), y poco a poco se va construyendo red.
¿Menesteres? Cualquier cosa que sea útil a los que están enganchados: Compartir acceso a Internet es lo más inmediato, pero a poco que se pone a trabajar el ingenio, salen más ideas: Copias de seguridad remota, compartir archivos, conectar redes… Vamos, para lo que sirve una red.
En guifi.net los enlaces se hacen sin encriptación. No se hacen ilusiones sobre la robustez de las encriptaciones inalámbricas; en su lugar, sugieren que los participantes se busquen la vida para asegurar su tráfico.
Este que escribe, se ha comprado su equipo (una antena de la firma Ubiquity que tiene un coste muy comedido para su calidad y prestaciones) y se ha conectado. A ver qué se puede hacer. Por ahora, buscarle un mástil mejor. Posiblemente, compartir acceso a Internet. Ya veremos. La cosa tiene un aroma 1.0 que mola.

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.

qdb

Hay webs inmortales. En tiempos muy remotos, el navegador Netscape venía configurado con sendos botones titulados «What’s new» y «What’s cool». Era una época en que se podían hacer estas cosas.

Sin embargo, con todo el tiempo pasado, siguen existiendo algunos sitios que, de seguir existiendo el segundo de los botones, allí seguirían, año tras año.

Hoy, en uno de esos lugares inmortales, pasé uno de esos ratos riéndome solo (y tomado, por tanto, por loco). Y de todo lo que leí, me resulta muy difícil quedarme con algo, pero si algo mola mucho, es esto: http://www.qdb.us/305607

Mas sobre iTerm2

Dado que he tenido poco tiempo para sentarme tranquilamente y escribir aqui tambien, he dejado esta pequeña pero gratificante labor a el amiguete que ha ido dándole bastante vida a este, nuestro pequeño blog. Hoy después de una release que ha durado 3 días han mejorado algo que utilizo para muchos servidores identicos y que ayuda a acelerar el trabajo; El enviar los mismos comandos a todas la pestañas.

El parte del changelog de hoy reza:
– Improve «send input to all sessions», adding new modes: 1) send to all panes in current tab, 2) to all sessions in current window, and 3) to an arbitrary collection of panes (toggled with context menu).

Lo que cada día hace que este terminal me de mas gusto tanto de haberlo encontrado como de usarlo. Ya es la hora de «jubilar» al viejo pero que nos a ayudado mucho iTerm.