Archivos de Categoría: Juguetes

Los ventiladores de los Mikrotik CCR1036

El sol lucía a mediados de Agosto en la calle cuando, en el CPD, un CCR dijo que uno de sus ventiladores había dejado de girar.

El ventilador en cuestión pertenecía a un Mikrotik CCR 1036 (si, uno de esos a los que ya a estas alturas he hecho mil perrerías, como meterles doble fuente o cambiar condensadores de estabilización de los chips Ethernet).

Algo fastidiado, porque este tipo de equipos generalmente es un tanto complicado desmontarlos estando en producción, me puse a investigar.

Por un lado, encontré un documento PDF titulado «TroubleShooting for CCR1036/CCR1016«. No estoy seguro de su autoría; los metadatos dicen que fue creado con la aplicación Draw de OpenOffice 3.4.1 el 6 de Diciembre de 2013, pero no tienen nada en el campo de autor. En él, se dice que si el ventilador no va, se verifique el transistor Q133. Q133 es un transistor SMD minúsculo, por lo que empecé a rezar a Santa Tecla para que lo roto fuera el ventilador, y no Q133.

Total, que cogí un ejemplar del taller y me miré los ventiladores. Los fabrica Chiefly Choice, su modelo CC 4028B12M. En el momento de escribir este artículo, aquí está su hoja de características. En resumen, es un ventilador de rodamientos de bolas, de 40x40x28 mm; a cambio de 190 mA a 12V, gira a 7000 rpm, moviendo casi 13 CFM (368 l/m), emitiendo un ruido de 33 dBA. O eso dice el fabricante.

En Digi-Key encontré casi 100 posibles sustitutos, muchos de ellos con ventaja. Y ya tenía el dedo en la lista de la compra, cuando el router dijo que el otro ventilador se había parado.

Dos ventiladores de los dos que tiene el chisme parados dan para acojonar al más pintado, porque ya sabemos lo que sigue a continuación: La temperatura empieza a subir rápidamente, y el trasto empieza a rearrancar, lo cual lo enfría un poco, pero en seguida se vuelve a calentar y así se queda, en un bucle sin fin de autodestrucción.

Pero sucedía algo extraño. La temperatura no subía. El trasto seguía clavado en sus 50 grados en placa (60 en el procesador) y diciendo que tenía todos sus ventiladores parados.

Más moscas que las que hay en un laboratorio de teleportación, nos acercamos al centro de datos a meter una brida por la parte trasera del chisme, y… ¡Ñiooooook! Aquello estaba girando, como siempre desde que se enchufó la última vez y se empezó a calentar.

Parece improbable que los dos sensores hayan fallado a la vez, por lo que me inclino a pensar en un fallo de RouterOS. Que he buscado, pero no encontrado; así que lo actualizaremos y ya veremos lo que nos depara el futuro.

Para la posteridad, aquí queda este testimonio de que (a) los CCR1036, al menos una vez, indicaron que estaban sin ventilación no siendo cierto; y (b) las características y referencia de los ventiladores, y posibles sustitutos.

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:

  1. 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.
  2. 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.

 

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.

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/

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.

  1. En todos los discos que participen del RAID, crear al principio de los mismos sendas particiones de 1 MB.
  2. Marcarlas, todas ellas, como BIOS boot area.
  3. Crear el/los RAID oportunos en el resto del disco
  4. Instalar Debian

Si todo va bien hasta ahora, GRUB se ha podido instalar en el primer disco. Pero no hemos acabado:

  1. Rearrancar. Debian arranca con el sector de arranque del primer disco (o el que hayamos elegido en el instalador Y en la BIOS)
  2. Reconfigurar GRUB:
  3. 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.

Más difícil todavía: Partido y con las teclas en blanco

Desde la primera vez que noté que me dolían las muñecas, he estado buscando el teclado ideal.

Antaño, gustaba del tacto de aquellos IBM, ahora Unicomp. Durante años no pude usar otra cosa que Key Tronic. Pasé fugazmente por Logitech y, aunque nunca quedé totalmente convencido, Logitech fue mi primer teclado partido.

Hoy, tengo un teclado que tiene casi todo lo mejor de todos ellos: Un Ergodox-EZ.

Ergodox es un diseño de teclado abierto, tanto hardware como software. La electrónica se basa en Teensy, y las teclas en el caso del Ergodox-EZ son Cherry MX (la historia de la empresa Cherry es interesante, pero es otra historia y debe ser contada en otra ocasión).

Ergodox-EZ cogió el diseño Ergodox y, financiación de moda mediante, lo vende listo para funcionar. Perfecto para los que, como yo, tienen cierta tendencia a meterse en berenjenales y acabarlos al cabo de varios años.

El teclado parte de una filosofía de diseño, heredada de su antecesor Key64: No poner más teclas que las que se usan. Esto parece de perogrullo, pero cualquiera que tenga la costumbre de comer sandwiches de mermelada a la vez que usa el ordenador sabe que hay teclas que se usan, teclas que apenas se usan, y teclas que se usan poco pero no se puede pasar sin ellas. Ergodox tiene suficientes teclas para cubrir las que se usan y las que no se puede pasar sin ellas. Total, 76 teclas. Pero mediante el truco de disponer diferentes capas, se pueden tener disponibles hasta las que casi nunca se usan.

Ergodox EZ tiene un configurador por web con el que fácilmente se puede decidir la distribución de teclado,  y escupe un .bin que se larga al teclado con el cargador de Teensy. Facilito. Lo único que no es facilito, y es una pequeña desgracia dado el precio del juguete, es que el configurador solamente está disponible con el juego de teclas US. Así pues, ¿cómo se configura en castellano, que es lo que uso yo? Se coge un teclado US, se mira a qué símbolo corresponde la misma tecla en el teclado ES, y se pone la del teclado US en el configurador. Durante el proceso, recordar varias veces el árbol genealógico del que hizo la distribución de teclado ES. Y eso es todo. Esta es mi distribución en el momento de empezar a escribir este artículo:  ergodox_ez_firmware_kvpdlm_alfredo.hex. En esta distribución, está todo lo necesario para escribir en castellano y creo que también en gallego y euskera, pero le faltan algunas cosas para escribir en catalán.

Inspirado un tanto onanísticamente por mi propio artículo, me he hecho otra distribución que simplemente tiene accesible una capa con teclas de función y un teclado numérico bastante útil para picar direcciones IP, con el 5 centrado en la J, o sea, en la tecla que tiene el resalte, al igual que en un teclado numérico clásico: ergodox_ez_firmware_qgrdnj_alfredo.hex

Me ha llevado en torno a un par de semanas habituarme lo bastante como para encontrarlo razonablemente cómodo y empezar a pensar en exprimir algo más de él. Los primeros días fueron horrorosos. Al cabo de una semana, empieza a doler menos, y al cabo de dos, ya lo uso con cierta soltura.

Por la pasta que ha costado, espero que me dure muchos años… Y que no me duelan las muñecas mucho más.

Las iDRAC molan. A veces. Salvo que te las cargues actualizando

Las iDRAC antiguas, en particular las iDRAC 6 y anteriores, tienen sus manías. Más manías cuanto más antiguo es el firmware, hasta el punto de ser poco menos que intratables: Solo funcionan con versiones prehistóricas de ie, les petan las actualizaciones, no les funciona https… En fin, esas cosillas.

A veces, es posible que una de estas iDRAC antiguas petardee al actualizar, y las cosas se van rápidamente a la alcantarilla. El peor caso que he conocido necesitó comprar un recambio. ¿Qué recambio? Ahí está lo gracioso: Dell parece hacer como si no existiera.

En los fiables (aunque ya venerables) r610, el acceso fuera de banda al servidor está compuesto de dos piezas separadas: La placa que contiene el puerto Ethernet (y que habitualmente se llama iDRAC a secas) y otra placa que se llama iDRAC express, y que no es otra cosa que una BMC glorificada. Para confundir las cosas, el firmware no va en la iDRAC, sino en la iDRAC express. Y la iDRAC express, va de serie en los r610, y no se vende como recambio normalmente. De hecho, en el esquema del servidor donde se dice dónde van hasta cosas tan raras como la licencia de iSCSI (que es una especie de llave física), no se hace ni mención a la iDRAC express, pero sí a la iDRAC, que es opcional.

Pues bien, cuando la actualización de firmware de iDRAC se va al desagüe… ¿A que no adivinas qué placa es la que se ha quedado gagá? Claro, como no podía ser de otra forma: La que «no existe».

¿La solución? Bueno, tal vez sea posible recuperarla por el método descrito aquí, usando el puerto serie virtual para acceder a la consola de recuperación. Pero si no, no hay problema: Nos vamos a eBay, y preguntamos por una iDRAC 6 express. Las he llegado a ver por un euro (mas 18 de envío). Os aseguro que es más barato que el tiempo que se puede llegar a perder peleando con una iDRAC 6 express mal flasheada (y disculpad el barbarismo). Creedme, aunque os costara 50 euros, seguiría siendo barato.

 

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.

 

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

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.