Autor: Luis Mita

  • SSDs baratos – El Inicio

    Necesitaba unidades SSD para un experimento en mi minidatacenter. Podría ir a la Uyustus a comprarlos, o podía arriesgarme a comprarlas de Internet al precio más bajo…


    Introducción

    Recientemente (2019+) estuve trabajando en Raspberry Pi como servidores. Esto no es estrictamente una novedad: a la gente que le interesaría tener servicios interesantes 24×7 alojados en su casa y no en Internet, les sería mejor tener algo pequeño y que consuma menos energía en comparación a una máquina x86 vieja (que es lo que la mayoría de hackers suele hacer).

    Necesitaba hacer pruebas con una placa con almacenamiento propio, y luego de pensarlo varias veces me decidí por un SSD ya que solo le vi ventajas: menos temperatura, menor consumo eléctrico, etc. Claro que tendría una menor capacidad de almacenamiento disponible, pero no era algo importante por ahora.

    Yo había tenido experiencias ya con SSDs: hace varios meses compré varios para mi laptop y las máquinas de mi casa. Ver cómo funcionan los SSDs, conocer las características internas de su funcionamiento es algo que me produce mucha curiosidad y luego de ver el video de Linus Tech Tips sobre el tema pues decidí ir a AliExpress y buscar la unidad más barata.

    Como comparación, las SSD de 120 GB en las tiendas de la ciudad costaban en esa época cerca de 30 dólares.

    Lo compré en mediados de enero de este año, y lo recibí hace unos días, en Mayo.

    Cómo llegó

    No tengo las fotos del paquete (deseché todo el envoltorio externo por precaución contra el coronavirus), pero la unidad SSD tenía muy poca protección. Un trozo pequeño del clásico relleno de burbuja rodeaba a la unidad SSD, que estaba dentro de una bolsa antiestática oscura sellada al vacío.

    Ya abierta esta, podemos ver la unidad:

    Decido desarmarla, sería genial ver qué hay adentro. La unidad no tiene ni siquiera tornillos: el plástico en la base tiene algunas piezas que hacen de gancho, con un destornillador plano se puede separarlas con facilidad.

    Hay una mejor foto de los componentes, y descubrí algunas cosas interesantes que les comento luego.

    Y ahí dejo una foto de la parte trasera de la placa, como se ve no hay nada interesante.

    Pruebas

    Luego de formatear la unidad a ext4 + hacerle TRIM, la primera prueba fue sencilla: usé un script para medir la velocidad. Suelo usar iozone pero usé esto esta vez, que hace una prueba de escritura y lectura simultánea.

    25MB/s de escrituras aleatorias van muy bien para mi propósito 🙂

    Luego le hice un test extendido de SMART (tardó 15 minutos y dio todo OK). No guardé la captura de los datos SMART, pero me acuerdo que tenía marcada 1 hora en Power_on_Hours, y el valor en Total_LBAs_Written y Total_LBAs_Read iba por los 2000. Me imagino datos que reflejan que se le hizo una prueba al SSD antes de ser vendido.

    Ya pasados unos días, les dejo la información de SMART del disco:

    smartctl 7.1 2019-12-30 r5022 [aarch64-linux-5.4.0-1011-raspi] (local build)
    Copyright (C) 2002-19, Bruce Allen, Christian Franke, www.smartmontools.org
    
    === START OF INFORMATION SECTION ===
    Device Model:     SSD 120GB
    Serial Number:    SCRW19121901B0016
    Firmware Version: S1120A0
    User Capacity:    120,034,123,776 bytes [120 GB]
    Sector Size:      512 bytes logical/physical
    Rotation Rate:    Solid State Device
    Form Factor:      2.5 inches
    Device is:        Not in smartctl database [for details use: -P showall]
    ATA Version is:   ACS-3 T13/2161-D revision 4
    SATA Version is:  SATA 3.2, 6.0 Gb/s (current: 6.0 Gb/s)
    Local Time is:    Tue May 26 07:15:07 2020 -04
    SMART support is: Available - device has SMART capability.
    SMART support is: Enabled
    
    === START OF READ SMART DATA SECTION ===
    SMART overall-health self-assessment test result: PASSED
    
    General SMART Values:
    Offline data collection status:  (0x00) Offline data collection activity
                                            was never started.
                                            Auto Offline Data Collection: Disabled.
    Self-test execution status:      (   0) The previous self-test routine completed
                                            without error or no self-test has ever 
                                            been run.
    Total time to complete Offline 
    data collection:                (  120) seconds.
    Offline data collection
    capabilities:                    (0x11) SMART execute Offline immediate.
                                            No Auto Offline data collection support.
                                            Suspend Offline collection upon new
                                            command.
                                            No Offline surface scan supported.
                                            Self-test supported.
                                            No Conveyance Self-test supported.
                                            No Selective Self-test supported.
    SMART capabilities:            (0x0002) Does not save SMART data before
                                            entering power-saving mode.
                                            Supports SMART auto save timer.
    Error logging capability:        (0x01) Error logging supported.
                                            General Purpose Logging supported.
    Short self-test routine 
    recommended polling time:        (   2) minutes.
    Extended self-test routine
    recommended polling time:        (  10) minutes.
    
    SMART Attributes Data Structure revision number: 1
    Vendor Specific SMART Attributes with Thresholds:
    ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
      1 Raw_Read_Error_Rate     0x0032   100   100   050    Old_age   Always       -       0
      5 Reallocated_Sector_Ct   0x0032   100   100   050    Old_age   Always       -       0
      9 Power_On_Hours          0x0032   100   100   050    Old_age   Always       -       71
     12 Power_Cycle_Count       0x0032   100   100   050    Old_age   Always       -       25
    160 Unknown_Attribute       0x0032   100   100   050    Old_age   Always       -       0
    161 Unknown_Attribute       0x0033   100   100   050    Pre-fail  Always       -       100
    163 Unknown_Attribute       0x0032   100   100   050    Old_age   Always       -       152
    164 Unknown_Attribute       0x0032   100   100   050    Old_age   Always       -       1350
    165 Unknown_Attribute       0x0032   100   100   050    Old_age   Always       -       13
    166 Unknown_Attribute       0x0032   100   100   050    Old_age   Always       -       1
    167 Unknown_Attribute       0x0032   100   100   050    Old_age   Always       -       3
    168 Unknown_Attribute       0x0032   100   100   050    Old_age   Always       -       1500
    169 Unknown_Attribute       0x0032   100   100   050    Old_age   Always       -       100
    175 Program_Fail_Count_Chip 0x0032   100   100   050    Old_age   Always       -       0
    176 Erase_Fail_Count_Chip   0x0032   100   100   050    Old_age   Always       -       0
    177 Wear_Leveling_Count     0x0032   100   100   050    Old_age   Always       -       0
    178 Used_Rsvd_Blk_Cnt_Chip  0x0032   100   100   050    Old_age   Always       -       0
    181 Program_Fail_Cnt_Total  0x0032   100   100   050    Old_age   Always       -       0
    182 Erase_Fail_Count_Total  0x0032   100   100   050    Old_age   Always       -       0
    192 Power-Off_Retract_Count 0x0032   100   100   050    Old_age   Always       -       18
    194 Temperature_Celsius     0x0022   100   100   050    Old_age   Always       -       40
    195 Hardware_ECC_Recovered  0x0032   100   100   050    Old_age   Always       -       602
    196 Reallocated_Event_Count 0x0032   100   100   050    Old_age   Always       -       0
    197 Current_Pending_Sector  0x0032   100   100   050    Old_age   Always       -       0
    198 Offline_Uncorrectable   0x0032   100   100   050    Old_age   Always       -       0
    199 UDMA_CRC_Error_Count    0x0032   100   100   050    Old_age   Always       -       0
    232 Available_Reservd_Space 0x0032   100   100   050    Old_age   Always       -       100
    241 Total_LBAs_Written      0x0030   100   100   050    Old_age   Offline      -       4460
    242 Total_LBAs_Read         0x0030   100   100   050    Old_age   Offline      -       4674
    245 Unknown_Attribute       0x0032   100   100   050    Old_age   Always       -       3240
    
    SMART Error Log Version: 1
    No Errors Logged
    
    SMART Self-test log structure revision number 1
    Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error
    # 1  Extended offline    Completed without error       00%         1         -
    
    Selective Self-tests/Logging not supported

    Algo curioso: Temperature_Celsius está siempre a 40 grados. Nunca sube, nunca baja.

    Detalles interesantes

    Tal como se vio en los videos que tratan el tema (…), algunas fuentes sugieren el por qué de los precios tan bajos de estas unidades:

    1. La placa está reciclada y el controlador reseteado.
    2. Componentes robados
    3. Componentes que no pasaron el control de calidad.

    El controlador es un SiliconMotion SM2259XT y las memorias son Intel/Micron 29F04T2ANCQJ1. Sobre esta última hay bastante información conflictiva, pero personalmente me inclino a creer que las memorias son 3D QLC de 128 GB cada uno. Sumando las dos que vimos en la placa, serían 256 GB.

    En ese caso podría inclinarme por la tercera opción, quizás estas memorias son demasiado malas para guardar 256 GB de datos asi que le dijeron al controlador que solo guarde 120 GB y esperar lo mejor del algoritmo de corrección de errores (ECC).

    Lo que ahora viene

    La mayoría de reviews en sitios como Aliexpress y Ebay no ayudan mucho: leyendo con atención, la mayoría solo comenta si le llegó el paquete y si la SSD funciona, además de la ocasional prueba de velocidad. Muy raras veces hay comentarios sobre cómo fue la vida de estas unidades: cuántos meses duraron, cuántos datos se escribieron y leyeron en la unidad, etc.

    Las pruebas de velocidad también no son un indicador fiable: una unidad SSD QLC puede llegar hasta ~100MB/s de rendimiento de escritura secuencial (es más lento que un HDD común de 7200 rpm), pero en las pruebas donde se llega hasta 400MB/s muy probablemente el controlador esté usando una caché SLC dentro de las memorias NAND.

    Para mis propósitos va muy bien, crear máquinas virtuales y contenedores en una Raspberry Pi 4 almacenadas en esta SSD. Uso ZFS como sistema de archivos, y como este me permite hacer copias incrementales en otra parte, si configuro un cron para que haga copias de vez en cuando pues no importa si el SSD decide morirse un día 🙂

    Si hay novedades respecto a este SSD las comento en otra entrada en el blog.

  • Cómo instalé Ubuntu Server 20.04 sin ISOs y con muy poca RAM

    Ayer, jueves 23 de abril de 2020 se ha lanzado la nueva versión de Ubuntu 20.04 LTS. Yo estaba esperando esta versión por varias cosas:

    • Soporte de 5 años (el soporte de versiones anteriores es de 3)
    • Módulo Wireguard integrado en el kernel 5.4 y también con soporte oficial
    • Livepatch para todo lo anterior

    Se ve muy bien para instalar en una máquina virtual donde el uptime sea importante, y había agendado instalar esa versión en un VPS importante. Como su tarea básicamente es enrutar paquetes, lo compré con un buen ancho de banda asignado y con poca RAM (512 MB) para ahorrar dinero. Luego de hacer una copia de seguridad a las cosas importantes y montar la ISO de Ubuntu Server, llegué a este kernel panic:

    Analizando el mensaje de error, podemos ver que el init no pudo ejecutarse (error code 2 = ENOENT = no existe el archivo). Los mensajes arriba muestran que el initramfs (mini sistema de archivos comprimido que se descomprime en la RAM para luego ser ejecutado) no pudo descomprimirse. El error más común es grabar mal un disco (devolvería algo como I/O error), pero como estoy usando un ISO con sha256sum verificado, me hace estar más atento al error final: «Write error».

    La instalación de Ubuntu Server ahora es más «live»: se ha dejado de utilizar por completo debian-installer para dar paso a Subiquiti, su nuevo instalador. Quizás el problema sea en la memoria RAM, y resultó que sí.

    Asi que nos toca instalar el sistema operativo de otra manera.

    Revisando el entorno

    Usé btrfs como el sistema de archivos de la raíz para aprovechar la compresión transparente con compress=zstd. Esto nos ayudará: btrfs soporta subvolúmenes y con eso podemos trabajar sin necesidad de particionar.

    El entorno original es Ubuntu 18.04: ya que no necesitaremos particionar, podemos usar el mismo entorno Linux para levantar otro.

    Instalando

    Necesitamos una «partición»

    Sin preveer nada, yo instalé el viejo Ubuntu en la raíz de la partición btrfs. Necesitaré un nuevo subvolumen:

    sudo btrfs sub create /ubuntu2004

    Esta operación crea el subvolumen ubuntu2004 al inicio del montaje actual (/) y podré usarlo como si fuera una partición independiente, ahorrándome muchas horas en particionar o hacer copias. Cabe aclarar que yo usé el instalador oficial antiguo, y eso me da certeza que mi / no está ya en un subvolumen (si eso sucede no es malo de por sí, solo que no quedaría bien organizado).

    Ahora montaré mi subvolumen en una carpeta cualquiera:

    sudo mount -o compress=zstd,subvol=ubuntu2004 /dev/vda3 /mnt2

    Instalamos Ubuntu

    La utilidad debootstrap nos permite desplegar una distribución GNU/Linux basada en Debian usando solo los paquetes de los repositorios: una solución segura y elegante.

    sudo debootstrap --arch amd64 focal /mnt2 http://us.archive.ubuntu.com/ubuntu

    Luego de que haya terminado, ingresaré a esa nueva instalación.

    sudo mount --bind /dev /mnt2/dev
    sudo mount --bind /proc /mnt2/proc
    sudo mount --bind /sys /mnt2/sys
    sudo chroot /mnt2

    Tenemos ya acceso a una instalación funcional, pero a un estilo contenedor. Necesitamos más paquetes para que esta instalación pueda funcionar por sí sola:

    apt install linux-image-generic grub-pc ssh nano

    Ahora configuramos la red:

    nano /etc/netplan/10-internet.yaml
    
    network:
      version: 2
      renderer: networkd
      ethernets:
        ens3:
          dhcp4: no
          addresses:
            - x.x.x.x/24
            - "y:y:y:y::y/60"
          gateway4: x.x.x.x
          gateway6: "x:x:x::x"
          nameservers:
            addresses: [x.x.x.x, y.y.y.y]

    El nombre del host ya debería estar en /etc/hostname. Puedes cambiarlo si quieres.

    Luego, agregué el hostname en /etc/hosts para mantener al comando sudo al tanto:

    echo "127.0.1.1 $(hostname)" > /etc/hosts

    Adapto la configuración regional para activar es_BO.UTF-8 y mi zona horaria:

    dpkg-reconfigure locales
    timedatectl set-timezone America/La_Paz

    Necesito que la instalación se acuerde de su partición raíz:

    nano /etc/fstab
    
    UUID=6b02ed42-d91f-48a5-85af-d3d5cba35be7       /       btrfs   rw,compress=zstd,subvol=ubuntu2004      0     2

    Y, finalmente, necesito agregar un usuario y adicionarlo a grupos relevantes. El grupo sudo me da poderes de superusuario y systemd-journal me da acceso al registro completo de sucesos del sistema.

    adduser elusuario
    adduser elusuario sudo
    adduser elusuario systemd-journal

    Antes de reiniciar, me aseguro de que el sistema es arrancable:

    update-grub
    grub-install --recheck /dev/vda

    Y eso es todo. Ya tengo una instalación rápida y limpia de Ubuntu 20.04 sin utilizar la ISO, ni reparticionar, ni nada.

    Algunos comentarios

    Yo había utilizado dos particiones: una ext4 para /boot y otra btrfs para el /: la versión de grub que venía en Ubuntu 18.04 no soportaba compresión zstd, y el sistema quedaba sin poder arrancar, a menos que ponga el kernel y otras cosas importantes en ext4. Ahora Ubuntu 20.04 viene con grub 2.04, que sí tiene soporte y me permite tener todo en un solo subvolumen.

    Ah, sí, ahora update-grub (o bueno, grub-mkconfig y os-prober) ya reconoce instalaciones distintas de GNU/Linux separadas en subvolúmenes, lo cual nos ahorra mucho trabajo en configurarlo.

  • Transmission Rate Podcast 03 – Otoño 2020

    Tal como estaba prometido en el anterior episodio, tenemos nuevo episodio del Podcast para este cambio de estación 😀

    Veremos qué tenemos:

    • «8 Hours, Still No Rain» es un track que llevo esperando desde mediados de 2019, y en Febrero fue lanzado siendo parte de una compilación. Es uno de mis tracks favoritos y ayuda a acomodar el ambiente para los demás.
    • Varios tracks aquí ya tienen cierto tiempo dando vueltas: el rework de «Strong», «Lauderdale», «If It All Stops» y «Song For Alan Turing» entre otros. Pero como son geniales, no los hemos olvidado.
    • «The Sound of Magnolia» es un track con orígenes improvisados. Es una mezcla entre Magnolia y Song of Silence, la composición musical de la segunda no me gustó, y para hacerle justicia a las vocales las conseguí y terminé mezclando ambos en directo en un evento. Preparé una mejor versión, y meses después la muestro en este episodio.
    • Mención honorífica al remix de «Supersonics»: este track parte del último álbum «Chronologic» de Caravan Palace ha sido remezclado por Outsider, y a través del podcast está haciendo su primera aparición en público. ¡Un gran honor!
    • Nueva sección en el podcast: Guest Mixes. Sam (parte del grupo de estudio Núcleo GNU/Linux y un gran amigo) aceptó la invitación y nos compartió una selección de la música que más le ha llamado la atención. Desde música orquestal hasta llegar a rock alternativo, los artistas que componen la lista merecen que les des un vistazo (yo ya lo hice, y aprovechando la cuarentena iré explorando más géneros).

    Un saludo, ¡y nos vemos en un próximo episodio!

  • Transmission Rate 002 – Podcast Verano 2019/2020

    Luego de la última versión del podcast (en 2017), en este fin de año he vuelto con un nuevo episodio para terminar el 2019. Esta vez me he animado a continuar de forma más regular: una mezcla por cada cambio de estación. Son 4 en un año, ahora es Verano, así que la próxima mezcla sería para Marzo (Otoño).

    En esta edición del podcast, además de poner las pistas que me han llamado la atención estos meses, estoy agregando algún material mío:

    • el remix de un poema de Lucy Loud. Escribí los acordes apenas unas semanas después del estreno del episodio «Head Poet’s Anxiety» en 2018, pero dejé de ser un fan de la serie y no le presté más atención hasta ahora. Aún así, me gusta el remix y probablemente lo siga utilizando.
    • el edit de «Geeks», track del álbum «Nordland» de Binärpilot. Apenas @donkeysharp nos mostró su canción sugerida para el video de invitación al Hackmeeting 2019 no resistí y la edité. Una parte muy corta de la canción editada fue para el video, pero seguí trabajando y armé una versión un poco más larga para mezclar en vivo. Ya pasado el evento, antes de archivar la canción para siempre, la puse aquí.
    • Un edit de «Free Software Song» de Thor.

    Para el que ha llegado hasta aquí: planeo para el FLISoL 2020 armar un mixtape con canciones libres y/o relacionadas a Software Libre, ya que he visto mucho material desordenado y, creo yo, sería divertido unificarlo en una mezcla con la duración máxima de un CD. El edit de «Free Software Song» que puse, estará en el mixtape, además de mucho material exclusivo mío y de la comunidad.

    Tracklist

    • 00:00 ID – ID
    • 01:40 Kidnap – Grow (Looper Lane Edit)
    • 05:18 Forty Cats – Human Race
    • 07:57 Cubicolor – Still Linger In My Dreams
    • 12:41 Ben Bohmer & Wood – Voyager 1
    • 18:07 Lucy Loud – Funny Faces (Looper Lane Deep Remix)
    • 20:15 Lane 8 – Every Night
    • 24:44 David Hohme – Fear Less (Hraach Remix)
    • 30:49 Blanche – City Lights (Gorje Hewek & Izhevski Remix)
    • 35:43 OCULA – Immunity
    • 39:56 Binaerpilot – Geeks (Looper Lane Hackmeeting 2019 Edit)
    • 41:43 Nox Vahn – Brainwasher
    • 45:40 Khrigar – Raining Stars
    • 47:27 R3d Cloud – El Fin del Camino
    • 49:50 ID – ID
    • 53:17 Andrew Bayer ft. Ane Brun – Love You More
    • 57:55 Thor – Free Software Song (Looper Lane Edit)
  • RIPE Atlas, o el cómo monitorear todos los rincones de Internet

    En uno de los grupos de Telegram en los que estoy, estaban buscando voluntarios para «RIPE Atlas». Fui, me dieron un aparato para que lo conecte a mi red, y estuve revisando el proyecto para ver de qué trataba. Aquí escribo lo que entendí.

    RIPE Atlas es un proyecto de RIPE NCC que busca ser una de las plataformas de monitoreo y medición de parámetros de red e Internet a nivel mundial.

    Cómo y para qué funciona

    RIPE Atlas se conforma principalmente de pequeños aparatos llamados sondas («probes» en inglés), y los voluntarios las instalan en su red.


    Esta foto la tomaron los responsables de RIPE Atlas Bolivia cuando el primer envío llegó y empezaron a buscar voluntarios. Casualmente esa sonda me la llevé yo.

    Su propósito es llegar a entender las diferentes redes de las que Internet se conforma, y poder hacer mediciones desde ellas. Las sondas a nivel mundial exponen al panel de control central de RIPE Atlas las siguientes mediciones: ping, traceroute, DNS, NTP, HTTP/HTTPS. Así, investigadores de todo el mundo pueden obtener estas medidas, entre otras cosas:

    • Revisión del routing entre redes e identificacion de problemas. Por ejemplo: descubrimos que en Bolivia, la red de la Univ. Mayor de San Andrés, filtra paquetes locales al exterior del país.
    • Detección regional de firewalls L7 o bloqueos por censura.
    • Revisión del efecto en Internet de las peleas entre ISPs (peering u otra cosa).
    • Comprobación de la eficiencia de un CDN
    • Registro fiable de caídas regionales del servicio de Internet


    Una sonda de RIPE Atlas consume muy poco ancho de banda.

    Cabe aclarar que las mediciones de RIPE Atlas no involucran calidad de servicio y/o velocidad de conexión [1].

    Solicitar una sonda

    Es posible apoyar al proyecto solicitando gratuitamente una sonda Atlas directamente a RIPE NCC, o comunicarse a una organización local que las haya pedido (RIPE Atlas Bolivia, por ejemplo). RIPE NCC espera algunas cosas de los que se ofrezcan a mantener una sonda:

    • Se asume que la sonda se va a colocar de forma fija en la casa (probablemente al lado del router) y que se quedará funcionando por tiempo indefinido.
      • Si uno ya no puede seguir manteniendo la sonda, es posible transferirla a otro interesado.
    • La sonda debe tener una conexión permanente a Internet. Como consume muy poco datos, no importa si es ilimitada o no.
    • La sonda sigue siendo propiedad de RIPE NCC (es decir, no es un regalo).
    • La sonda será monitoreada continuamente desde el exterior, y dependiendo de cómo se la instale, los datos de tu red (como tu IP externa) serán públicos.
    • La sonda tendrá actividad remota DNS y HTTP/HTTPS dentro de tu red, y puede que tu ISP relacione esa actividad contigo. De todas maneras, RIPE Atlas supervisa las pruebas que se transmiten a las sondas a nivel mundial.
    • La sonda viene con un firmware especial cerrado, que se administra mediante un servicio web online. La red a la que se debe conectar debe soportar obligatoriamente DHCP.
    • Un envío de una sonda consiste en: 1) una sonda Atlas V3 (un router TP-LINK TL-MR3020 con firmware especial), 2) un cable de red y uno USB para energía. La alimentacion eléctrica, como adaptadores y etc., es responsabilidad del usuario (es decir, hay que tener cuidado para no quemar el aparato usando adaptadores de energía USB de baja calidad)
  • LEDE 17.01 en un Ubiquiti UniFi AC AP Lite

    Desde que Ubiquiti ha cerrado la posibilidad de usar firmware alternativo en los aparatos que distribuye (incluso teóricamente violando la GPL al distribuir un U-Boot modificado sin su código fuente), se ha vuelto más difícil intentar instalar OpenWrt o LEDE. Pero, gracias a la experiencia obtenida en algunas tareas, he podido armar esta guía para hacerlo (mas una explicación al final). Quizás haya contenido que no necesariamente aplica a tu aparato. De todas maneras, si arruinas el proceso, los routers Ubiquiti te permiten cargar firmware (oficial) por TFTP y así poder volver a empezar. Igualmente, sería bueno que hagas copias de los bloques /dev/mtdblock* en el firmware original y los saques a tu máquina con scp, para estar más protegido, por si acaso.

    Cómo instalar LEDE en el UniFi AC AP Lite

    Necesitamos los siguientes archivos:

    Ahora podemos empezar a trabajar.

    Fase 0: Desbloqueando el firmware

    Por defecto los APs con los que trabajé venían con la versión 3.4.14 del firmware oficial. Como éste ya implementa verificación de las firmas digitales para el firmware de Ubiquiti, tenemos que hacer un downgrade (desactualizar) a la versión 3.4.7, que no implementa ésta restricción.

    1. Enciende el AP y conéctate. Si está ya configurado, debes resetearlo. De preferencia, el router no debe tener acceso a Internet ahora mismo.
    2. Conéctate al servicio ssh de la IP por defecto 192.168.1.20, con las credenciales ubnt/ubnt.
    3. Copia el fichero BZ.qca956x.v3.4.7.3284.150911.1650.bin a la carpeta /tmp del aparato, usando el nuevo nombre fwupdate.bin. Puedes hacerlo con un miniservidor http (python3 -m http.server 8080) o con scp.
    4. Luego de tener ya el archivo /tmp/fwupdate.bin, ejecuta syswrapper.sh upgrade2.
    5. Espera unos minutos a que el router se reinicie.

    Fase 1: Instalando el firmware intermedio

    Ubiquiti usa un formato un poco extraño para el firmware de sus APs, y gracias a éso, no podremos instalar OpenWrt/LEDE así nada más, ya que tratará de ejecutar el firmware desde una partición no esperada. Usaremos un firmware intermedio para corregir éso.

    1. Conéctate al AP por ssh. La vieja IP (192.168.1.20) y las credenciales ubnt/ubnt aún deberían servir.
    2. Copia el archivo lede-r3435-ubnt-unifiac-lite-enmaskarado-phase1.bin a la carpeta /tmp del AP.
    3. Ejecuta:
      1. mtd write /tmp/lede-r3435-ubnt-unifiac-lite-enmaskarado-phase1.bin kernel0
      2. mtd -r write /tmp/lede-r3435-ubnt-unifiac-lite-enmaskarado-phase1.bin kernel1
    4. El aparato se reiniciará, y luego de unos minutos, el firmware de primera fase estará funcionando. Deberías tener acceso por ssh a la IP 192.168.1.1, sin credenciales.
    5. Ejecuta:
      1. insmod mtd-rw i_want_a_brick=1
    6. Ahora todas las particiones se han desbloqueado y habilitado como lectura/escritura. Revisa la estructura del chip SPI, para identificar a la partición bs (que en nuestro caso, está en mtd7). root@n16p1:~# cat /proc/mtd
      dev: size erasesize name
      mtd0: 00060000 00010000 «u-boot»
      mtd1: 00010000 00010000 «u-boot-env»
      mtd2: 00790000 00010000 «firmware»
      mtd3: 00140000 00010000 «kernel»
      mtd4: 00650000 00010000 «rootfs»
      mtd5: 002a0000 00010000 «rootfs_data»
      mtd6: 00790000 00010000 «ubnt-airos»
      mtd7: 00020000 00010000 «bs»
      mtd8: 00040000 00010000 «cfg»
      mtd9: 00010000 00010000 «EEPROM»
    7. Descarga al router el archivo UnifiAcApLite_mtd7_bs_kernel0.bin, en la carpeta /tmp.
    8. Vamos a sobreescribir esta partición bs, quizás quieras tener backups. Ahora ejecuta:
      1. mtd write /tmp/UnifiAcApLite_mtd7_bs_kernel0.bin bs

    Fase 2: Instala el firmware final que desees

    1. No reinicies. Ahora sí, descarga el firmware LEDE que quieras usar (versión sysupgrade), y ejecuta:
      1. sysupgrade -n /tmp/lede-17.01.3-ar71xx-generic-ubnt-unifiac-lite-squashfs-sysupgrade.bin
    2. Si el aparato te pregunta reiniciar, dile que sí. Luego de ésto, ya tendrás LEDE en el AP.
    3. Fin.

    Explicando los pasos

    Ubiquiti maneja una estructura de la memoria en sus APs un poco rara, pero que cada vez es más común en entornos profesionales y alguno doméstico: dos particiones para el firmware. Así, estos aparatos se pueden actualizar automáticamente y de forma masiva, sin riesgos. Si una actualización falla, el antiguo firmware puede ejecutarse de nuevo y minimizar el tiempo de no-actividad del AP. LEDE se conforma bien con tomar la primera partición, pero el proceso de instalación de Ubiquiti no le garantiza que sea así:

    • Por defecto los APs vienen con su firmware en kernel0.
    • Al desactualizar el aparato a la versión 3.4.7, éste firmware se carga en kernel1, y el bootloader de Ubiquiti se configura para bootear éste kernel1, modificando un byte en la partición bs.
    • LEDE espera estar en kernel0.
    • Por eso necesitamos instalar el firmware de fase 1 en ambas particiones:
      • si se copia sólo en kernel0, LEDE nunca se ejecutará.
      • Si se copia en sólo kernel1, LEDE arrancará bien su kernel, pero intentará montar los sistemas de archivos (la base squashfs y el jffs2) desde kernel0, donde obviamente no están: ésto genera un kernel panic, y por consiguiente, un soft brick.
    • Si copiamos nuestro firmware final a ambas particiones, puede funcionar, pero será un caos terrible intentar actualizarlo, etc. Es mejor corregir ésto.
    • Para arreglar éste desastre, copiamos el firmware de fase 1 a ambos bloques y corregimos la partición arrancable del bootloader, flasheando con mtd-rw una partición bs modificada.
    • Así el bootloader arrancará kernel0 y LEDE estará contento. Tareas como el sysupgrade volverán a funcionar.

    Partición bs

    • ¿Qué significa bs? Quizás boot-selector, o algo así.
    • Ésta partición prácticamente no tiene datos propios del AP: en varios AP de un mismo batch, he verificado que no hay diferencias entre particiones bs, y que un sólo bs modificado sirve para todos.
    • El primer byte hexadecimal de la partición bs determina la partición a arrancar: un 0 significa kernel0, y un 8 significa kernel1.
    • Aquí tengo un bs que bootea kernel0 y otro bs que bootea kernel1, por si quieres ver las diferencias de ambos con hexdump.
    • Si estás seguro de que tu AP (sea un AC AP Lite o no) bootea su firmware oficial desde kernel0, puedes copiar su partición bs al principio, y luego restaurarla cuando necesites corregir el orden, teniendo LEDE ya.
  • Restringir canales Wi-Fi para el selector automático (ACS) en LEDE

    Tengo un pequeño aparato Wi-Fi móvil (mi nodo móvil de LaOtraRed, Mochila Hacker). Lo llevo a todas partes, y a veces el canal Wi-Fi en el que está configurado no es el mejor (tiene más interferencia de otros routers, por ejemplo). Usando la función Automatic Channel Selection que hostapd expone, podemos hacer que OpenWrt o LEDE revisen velozmente la banda 2.4GHz y elijan el canal más limpio.

    Como nota adicional, el único controlador inalámbrico que he visto que funciona más o menos bien con ACS es ath9k (con alguno que otro bug, especialmente si usas 2+ interfaces virtuales en LEDE 17.01.2), ya que éste sí tiene cosas como el detector de ruido ambiental en el canal Wi-Fi (noise floor). Los chips Ralink de los aparatos que tengo, no soportan esto y ACS no funciona.

    El problema que me ocasiona es que ésta función tiende a ocupar el canal 13, que casi siempre está vacío, pero no todos los clientes Wi-Fi lo soportan, gracias a clientes y APs mal configurados alrededor (es una historia larga acerca de 802.11d y 802.11h). Gracias a ésto, la gran mayoría de clientes Wi-Fi usa las regulaciones US (de Estados Unidos), y por lo tanto, son sordos a los canales 12 y 13. Podría configurar mi router móvil con las regulaciones en US y así evitar esos dos canales, pero eso significaría contribuir más al desastre de 802.11d en mi ciudad. Configurando la opción country_ie se evitaría, pero sigo creyendo que no es la mejor solución.

    Solucionando el problema

    Resulta que hay una opción no documentada en OpenWrt (desde r47427 de trunk, en noviembre de 2015) y LEDE para poder restringir los canales de los que el ACS puede disponer, llamado el array channels:

    config wifi-device 'radio0'
    #(…)
    option channel 'auto'
    list channels '1'
    list channels '6'
    list channels '11'

    Funciona: puedes probar especificando algunos pocos canales y el router escogerá alguno de ellos.

  • (2017) Trivia Sysadmin I – Alta carga

    Aquí tenemos una captura de un servidor que se ha vuelto loco, ¡con un load average que llega a 136! (demasiado para un servidor con 2c/4t de CPU).

    El reto consiste en analizar esa captura de pantalla y descubrir qué está haciendo el servidor para haber llegado a tal extremo.


    Contexto

    Quiero dar de baja este servidor porque necesito ahorrar dinero. Venía con un disco de 2 TB (si, un solo disco, sin RAID ni nada) que usaba para los backups de mis backups.

    Pistas e indicaciones

    • El load average de 1m/5m/15m debería darte una idea del tiempo que el servidor lleva trabajando así.
    • Los Intel Atom CPU D525 tienen 2 cores y 4 threads, pero aún así, el rendimiento es terrible comparado a otros CPUs de Intel.
    • Uno de los comandos que se ven ejecutándose es vital para entender el problema, pero estrictamente no está generando carga al CPU.
    • Hace unas semanas en el FLISoL dieron una charla de seguridad informática básica muy buena: es sorprendente cómo la gente da por ciertas muchas cosas.
    • La carga del sistema es alta, pero htop dice que los 4 threads de CPU están con poco trabajo.



    Solución

    Estoy sobreescribiendo mi disco duro con ceros, con el comando:

    ~# pv < /dev/zero > /dev/sda.

    El comando pv me da la opción de ver cuánto del disco se ha sobreescrito con ceros y cuánto le falta para completar.
    El proveedor del servidor me ha configurado el disco con ext4 (sistema de archivos que no da la opción de cifrado nativo), no configuré LUKS/dm-crypt y sé que un futuro arrendatario del servidor podría ejecutar utilidades como testdisk o photorec para recuperar contenido que yo hubiera creído ya eliminado.

    El formateo a bajo nivel (llenar de ceros el disco en este caso) es una forma bruta de proteger datos, pero funciona, y los archivos son suficientemente irrecuperables para mi gusto (otras personas recomiendan múltiples pasos para contenido sensible).

    En la orden ~# pv < /dev/zero > /dev/sda el proceso que escribe a /dev/sda depende directamente de la velocidad del disco duro (lento): como no puede igualar los ~1.2GB/s de /dev/zero, el caché de escritura en RAM se llena y se genera mucho I/O Wait (pausas del CPU esperando a que los datos terminen de escribirse en el disco). Además, formatear 2TB a 120MB/s da el tiempo suficiente para disparar el Load Average y llegar a cantidades absurdas.

    Como bonus: htop no muestra el IOWait por defecto. Se puede activar manualmente yendo a sus opciones, o se puede usar top, que sí muestra al menos un porcentaje.

  • LEDE 17.01.1 en una Mikrotik RB750GL, sin brickear nada en el intento

    Hola! Algunos de uds. saben que estoy ayudando a montar una red de Internet en la carrera donde estudio (Informática-UMSA). Entre las compras, venía un RouterBOARD 750GL con instrucciones de instalar OpenWrt para nuestro propósito. Instalar OpenWrt es sencillo (initramfs + wget2nand), pero ésto se ha vuelto más complicado con LEDE, y no sale a la primera. Pero tengo una guía para lograrlo a la primera (necesitarás un sistema GNU/Linux cualquiera, medianamente actualizado).

    Primeros pasos

    • Vamos a tocar el sistema de archivos completo, así que es hora de hacer una copia de tu licencia RouterOS, si quieres volver a ése firmware sin romper nada. Abre WinBox -> System -> License -> Export Key.
    • No debes fiarte de una sola fuente de información, y debes considerar que puedes equivocarte. Para poder ver el panorama con más claridad, debes leer la documentación. TEN MUCHO CUIDADO: aquí es muy fácil romper cosas. Ésta edición de RouterBOOT no habilita los pines serial TX-RX de la placa (y para colmo, la memoria es NAND), así que un hard-brick será muy difícil de solucionar.
    • Igual, debes saber que las RB750GL suelen tener cambios importantes de hardware sin ser mencionados (como el tamaño de la NAND). ¡Mucho ojo con brickear algo!

      Para instalar LEDE, vamos a aprovechar una feature de RouterBOOT y utilizaremos una imagen initramfs que se cargará en la memoria RAM. Para ello, necesitamos configurar al router para que 1) bootee de la red una vez, y 2) que luego bootee de la NAND. Sí o sí necesitaremos WinBox para eso. Volvé a Windows, conecta tu máquina a un puerto LAN cualquiera del router, y abre WinBox.

    1. System → Routerboard → Settings → Boot device: Try ethernet once then NAND
    2. System → Routerboard → Settings → Boot protocol: DHCP
    3. System → Routerboard → Settings → Force Backup Booter: Activar (¡importante!)

    Guarda («save»), y luego, apaga el router. No lo enciendas ahora.  

    Instalando LEDE 1/2

    Ahora, inicia tu sistema GNU/Linux, andá a tu $HOME, creá una carpeta «mtikgl» y una carpeta «mtikglcc» En la carpeta mtikgl descarga éstos archivos:

      En la carpeta mtikglcc descarga éstos archivos:

    Ahora, asigna a tu máquina la dirección 192.168.0.100/24 con iproute2 o con NetworkManager. Luego conecta tu máquina al router, al puerto 1 (WAN): NO LO ENCIENDAS AÚN.  

    Quizás, al encender el router luego, la interfaz se levante demasiado rápido y no te alcance a activar un comando. Tal vez haya flips, y las siguientes instrucciones no funcionen. Para estar seguros, conecta al medio de tu máquina y el router, un switch ethernet barato.

      Ahora abre un terminal en la carpeta mtikgl y ejecuta:

    sudo killall dnsmasq
    sudo dnsmasq --no-daemon --port=0 --dhcp-range="192.168.0.50,192.168.0.150,12h" --enable-tftp \
    --bootp-dynamic --dhcp-boot="lede-17.01.1-ar71xx-mikrotik-vmlinux-initramfs.elf" \
    --tftp-root="$HOME/mtikgl"

    Ahora, toma un palillo y presiona el botón de RESET, con el router apagado. Mientras mantienes presionado RESET, ahora sí enciende el router. Espera al menos 15 segundos, y luego quita el palillo. Podrás ver ahora en las lucecitas del switch bastante actividad, y en la ventana del terminal donde está dnsmasq, que alguien pidió una IP y descargó el initramfs.   Bien! Ahora LEDE está cargándose en la memoria RAM, y puedes cerrar el dnsmasq con un Ctrl-C. Conéctate al router usando cualquier puerto LAN (del 2 al 5) y asígnate la IP 192.168.1.100/24. Ahora nos conectamos al router e instalaremos LEDE.

    # Copiamos ahora mismo el firmware. Aquí uso el firmware para NANDs >=128, ojo.
    scp lede-17.01.1-ar71xx-mikrotik-nand-large-squashfs-sysupgrade.bin 192.168.1.1:/tmp

    ssh -l root 192.168.1.1
    # ahora estamos dentro del router
    cd /tmp
    sysupgrade lede-17.01.1-ar71xx-mikrotik-nand-large-squashfs-sysupgrade.bin

      Si todo va bien, el router aceptará el archivo y la sesión SSH se apagará de inmediato. Déjalo así unos 30 segundos.

    Instalando LEDE 2/2

    La instalación debería ser así de fácil, pero no funciona: el router no podrá bootear LEDE y entrará en un bootloop. Al parecer, LEDE ahora guarda el kernel y el rootfs en la partición UBI de datos en mtd3, pero algunas ediciones de RouterBOOT sólo pueden bootear kernels en la partición mtd2, formateada con yaffs. Hasta donde sé, LEDE no soporta ya yaffs.   Gracias a nuestra configuración de RouterOS, el bootloop activa el booteo por DHCP y podremos arrancar otro initramfs. Vamos a la carpeta mtikglcc y ejecutamos ésto:

    sudo killall dnsmasq
    sudo dnsmasq --no-daemon --port=0 --dhcp-range="192.168.0.50,192.168.0.150,12h" --enable-tftp \
    --bootp-dynamic --dhcp-boot="openwrt-ar71xx-mikrotik-vmlinux-initramfs.elf" \
    --tftp-root="$HOME/mtikglcc"

    Nos conectamos con la IP 192.168.0.100/24 al router encendido (que está en bootloop ahora mismo) al puerto 1 (WAN). No suele ser necesario reiniciar, el router debería pedirte un initramfs desde ya.   Ahora, conéctate al router usando cualquier puerto LAN (del 2 al 5) y asígnate la IP 192.168.1.100/24

    # Copiamos el kernel que falta
    scp ../mtikgl/lede-17.01.1-ar71xx-mikrotik-vmlinux-lzma.elf 192.168.1.1:/tmp/

    telnet 192.168.1.1
    # ahora estamos dentro del router
    cd /tmp
    cat /proc/mtd
    # debería aparecer la partición kernel como mtd1

    mtd erase kernel
    mount /dev/mtdblock1 /mnt
    mv /tmp/lede-17.01.1-ar71xx-mikrotik-vmlinux-lzma.elf /mnt/kernel
    chmod a+x /mnt/kernel
    umount /mnt

    Ahora sí puedes reiniciar, y al bootear de nuevo, LEDE debería estar funcionando.  

    Créditos

    He tomado información de los siguentes enlaces:

    • https://wiki.openwrt.org/toh/mikrotik/common
    • https://www.mail-archive.com/lede-dev@lists.infradead.org/msg06759.html
    • http://lists.infradead.org/pipermail/lede-dev/2017-April/007005.html
  • Error state: check-failed utilizando canonical-livepatch

    Yo utilizo la versión gratuita de canonical-livepatch para unos pocos servidores dedicados (yo virtualizo, y es incómodo perder uptime en las máquinas virtuales).

    Al activar el servicio en una máquina (utilizando una plantilla Ubuntu 16.04 de OVH) canonical-livepatch funciona momentáneamente, pero al cabo de unas horas aparece un error en el journal: Bad server status code: 403. URL: https://livepatch.canonical.com/api/machine/<id> {"error": "Invalid Machine Token"}.

    Además aparece otro error de tipo check-failed, que impide seguir bajando actualizaciones del servicio.
    sudo canonical-livepatch status --verbose
    (...)
    status: - kernel: 4.4.0-45.66-generic
    running: true
    livepatch: checkState: check-failed (...)

    Resolviendo el error

    La plantilla Ubuntu 16.04 de OVH, a pesar de ser la misma para los clientes, tiene que asegurarse que ciertos datos no sean los mismos. Esta debe generar, por ejemplo, los pares de claves para SSH por máquina. La plantilla viene con un parámetro de systemd llamado machine-id que en teoría debe ser única por máquina y se genera aleatoriamente al momento de la instalación.

    Canonical-livepatch utiliza éste campo para crear una pareja única machine-id<=>token, creando así el machine-token para la máquina. Si alguien activa su servicio con tu machine-id, tu machine-token será revocado de inmediato, y como la plantilla de OVH no tomó en cuenta eso, entonces así llegamos a la falla.

    Necesitamos obtener nuestro machine-id original para ver que tenemos este fallo: cat /etc/machine-id
    5b4291032856154f1caf5ffb5694cdc3

    Luego lo cambiamos por otra cadena aleatoria: head /dev/urandom | md5sum | cut -d " " -f 1 | sudo tee /etc/machine-id El manual de systemd tiene una utilidad para generar otro machine-id, pero necesita un rootfs no booteado. Por ese motivo, nos aseguraremos de reiniciar la máquina ahora mismo, para evitar fallas raras.