Aumentar espacio de tu Raspberry Pi usando un dispositivo de almacenamiento USB

Una de las bondades de los sistemas GNU/Linux es la posibilidad de montar una unidad USB y  formatearla convenientemente. La cual puede ser montada a voluntad o meterla en la fstab (File Systems TABle) para que se monte con el arranque del sistema si lo deseamos. Para estas cosas GNU/Linux es la caña y es super flexible!! 😉

Un opción que podría ejemplificar fácilmente el uso de este procedimiento, puede ser una Raspberry Pi a la que queráis darle más espacio que el que tenéis disponible en la microSD donde tenéis montado el sistema operativo. Actualmente las memorias USB han bajado mucho su precio y han aumentado los tamaños máximos de las mismas, encontrándonos a precios razonables memorias de 128GB o256GB.

Empecemos con lo básico que es conectar la memoria USB a la Rapsberry Pi (obvio pero por si acaso lo digo 😉 ). Con la memoria USB conectada ejecutamos el siguiente comando:

ls -l /dev/disk/by-uuid/

El comando nos responde identificado las unidades disponibles. Las unidades “mmcblk0p1” y “mmcblk0p2” corresponden a la partición de boot del la Rapsberry Pi y a la de ficheros de Raspbian (Sistema Operativo) respectivamente. La que nos insteresa es la “sda1“. Anota el identificador (UUID) que tiene, en mi ejemplo el mio es “51a4dc12-f769-4286-bdb6-58f40f6a7ce2“.

Ahora vamos a preparar el punto de montaje de la unidad. Para ello ejecuta el siguiente comando para crear la ruta “media/usb” donde montaremos la unidad:

sudo mkdir /media/usb

Puedes usar otra ruta si lo deseas, pero intenta que sea corta, ya que tendrás que escribirla tantas veces como quieras acceder a la unidad.

Ahora hay que asegurarnos que el usuario “pi” es propietario de la nueva carpeta donde montaremos la unidad. Para ello ejecuta:

sudo chown -R pi:pi /media/usb

Para montar la unidad lo haremos con el siguiente comando:

sudo mount /dev/sda1 /media/usb

Si ejecutamos el comando:

df -h -T

Veremos que aparece la unidad en el punto de montaje “media/usb” indicado, así como el tipo de sistema de ficheros. Si has usado otro punto de montaje, aparecerá que el que hayas puesto.

Como usar la memoria USB con el formato FAT32 (aparece como vfat) no es lo más óptimo, formatearemos la unidad a EXT4 mucho más óptimo para nuestro sistema Raspbian. Puedes formatear fácilmente la unidad con el siguiente comando tras desmontar la unidad con:

sudo umount /media/usb
sudo mkfs.ext4 /dev/sda

⚠️ Ten en cuenta que si ejecutas los comandos para formatear la memoria USB, perderás los datos que hubiese dentro. ⚠️ Si estamos conformes con el formateo decimos que sí.

Si quisiéramos que la unidad se montase automáticamente, tendremos que incluir la nueva unidad en fstab. Para ello abriremos primero el fichero de configuración de fstab:

sudo nano /etc/fstab

Y añadiremos tras la última línea esta otra:

UUID=51a4dc12-f769-4286-bdb6-58f40f6a7ce2 /media/usb ext4 auto,nofail,noatime,users,rw 0 0

El parámetro más importante es el “UUID” que anotamos al principio del artículo. Si finalmente optaste por formatear la memoria USB a EXT4, te recomiendo que vuelvas a ejecutar el comando porque el valor habrá cambiado.

Para concer específicamente el significado de cada parámetro te dejo la siguiente referencia:

Si finalmente decidiste NO formatear la memoria USB, la línea cambia un poco y se sustituye “ext4” por “vfat“:

UUID=51a4dc12-f769-4286-bdb6-58f40f6a7ce2 /media/usb ext4 auto,nofail,noatime,users,rw 0 0

Ahora solo nos resta comprobar si efectivamente la unidad se monta sola y para ello ejecutaremos un reinicio:

reboot

Si lo hemos hecho bien deberíamos poder ver la memoria USB en “/media/usb“. Ya tenemos más espacio en nuestra Raspberry Pi!! 😉

Feliz Navidad y Próspero Año 2018

Las vacaciones Navideñas y el fin de año ya están a la vuelta de la esquina y toca cerrar otro año en el que en lo personal y profesional no me puedo quejar.

Mascando Bits ha mejorado su número de visitantes y la recurrencia de los mismos. ¡Gracias a todos los que leéis y compartís! 😉 Este blog lo puse en marcha como sistema de información personal de dominio público, sin ninguna pretensión más allá de la de devolver algo de conocimiento y pasión de lo que es mi hobby y mi profesión.

Este año tengo cambios profesionales y espero seguir manteniendo mi actividad de publicación y el desarrollo de mis proyectos en GitHub.

Con mis mejores deseos ¡Felices Fiestas! (para los agnósticos y atéos), ¡Feliz Navidad! (para los creyentes) y ¡Feliz Año 2018! (para TODOS 😉 ). ¡Nos vemos a la vuelta!

 

 

Neurtura – O cómo sobrevivir en el mundo de la Monitorización Industrial

Ha costado que llegue el segundo invitado a Mascando Bits, pero nunca es tarde si la dicha es buena, y en este caso lo es. Hoy Xabier, compañero de fatigas en el trabajo, nos trae una retrospectiva con aplicación práctica de ingeniería de hardware y software al estilo open source que tanto ha marcado los inicios de Ingran Engineering, empresa de la que me siento orgulloso de pertenecer. Xabier ha sido y será siempre un MacGyver de la electrónica y la mecánica. Esperemos que esta sea la primera de otras muchas entradas.


Actualmente vivimos en un mundo complicado, luchando entre el software y hardware abierto y sistemas propietarios. En la confrontación entre la solución basada en ArduinoESP8266 de 5€ y el Siemens S7 de 500€. En el dilema de dar servicio a un precio adecuado y cumplir las directivas y el marcaje CE. Puede que aquí encontréis algo intermedio, o no. Pero por lo menos, fue nuestra solución durante un tiempo.

 

Introducción

La verdad que empecé a escribir esta entrada hace bastante tiempo, puede que hace más de uno año. Pero por fin lo he completado. A falta de que todavía monte un blog, quisiera agradecer a Rubén que me deje espacio en su blog para publicar.

Este va a ser la primera de varias entradas, comentando la funcionalidad de un sistema que en su día desarrollamos en Ingran Engineering, que actualmente ha quedado en desuso, al migrar a sistemas de adquisición de datos basados en Modbus-TCP, y también porque el módulo central del sistema, el Industruino que usamos en sus primeras versiones, nos dio bastantes problemas para los niveles de calidad y servicio que buscábamos. No obstante el fabricante ha sacado una revisión del Industruino que soluciona los problemas del primero y que además añade nuevas capacidades al dispositivo.

El las siguientes fotos os muestro la versión básica del Neurtura (nombre comercial del dispositivo de monitorización), en la primera podéis ver el aspecto exterior con los conectores:

 

En esta podéis ver los componentes internos:

Podéis observar de izquierda a derecha: Un magnetotérmico, un analizador de energía eléctrica, el Industruino D21G IND I/O (la versión más reciente) con su módulo ethernet al lado, una fuente de alimentación de 24 Voltios y un router Teltonika RUT230.

El la parte exterior tenemos conectores Harting, para la alimentación, para la conexión de las pinzas amperimétricas, para el analizador de energía, y para las conexiones de los sensores, actuadores y Modbus-485.

Si alguien no tiene demasiadas ganas de leer, que vaya al final, al apartado “Compilando“.

 

Contexto

¿Cómo narices se puede monitorizar un proceso industrial, en este caso concreto, una bomba de agua para regadío, de manera efectiva, eficaz y barata? Esa pregunta nos la hicimos en Ingran Engineering hace bastante tiempo, con la certeza de que tenía que haber una solución que tuviese las tres Bs (Bueno, Bonito y Barato). Esto era lo que necesitábamos:

  • Medida de parámetros eléctricos de una bomba: Potencia, Voltaje, Factor de Potencia…
  • Medidas de parámetros del acuífero: Conductividad eléctrica (salinidad), Nivel del agua bajo tierra…
  • Medida de parámetros del agua extraída: Caudal, Presión…
  • Registro de datos cada 10 segundos, y mostrarlos vía Web y en el móvil

Además, por si no fuera poco, teníamos las siguientes restricciones:

  • Necesidad de utilizar GSM/GPRS/3G para la comunicación.
  • Necesitaba tener marcaje CE y cumplirlo.
  • Tenía que ser compatible con lo que había ya montado: diversos tipos de caudalímtros/contadores, medidores de nivel de acuífero…

Aqualogy tenía una solución llamada IdroSmartWell que hacía todo eso, y más, a un precio que casi nos dio un infarto al escucharlo. La solución de software vino de la mano del proyecto EmonCMS de Open Energy Monitor y la de hardware tuvimos que apañárnosla.

 

Especificaciones técnicas

Las especificaciones técnicas de Neurtura que habéis visto en las fotos anteriores son las siguientes:

  • Analizador de energía eléctrica trifásica: Conexión a pinzas amperimétricas externas de 5A o 1A. Medida de V, I, P, PF, THD y más cosas…
  • 4 Entradas analógicas de 0-20mA o 0-10 Voltios: Resolución máxima de 18 bits.
  • 2 Salidas analógicas de 0-20mA o 0-10 Voltios: Resolución máxima de 12 bits.
  • 8 Entradas/Salidas digitales: Opción de usarlas como contadores de pulsos.
  • Conexión de Modbus-485 para conectar mas dispositivos.
  • Opción de postear (enviar) a EmonCMS directamente.
  • Guardado de datos en la SD local.
  • Guardado de parámetros de configuración en la EEPROM.
  • Guardado de datos de contadores y demás datos cambiantes en la FRAM propia.
  • RTC local.
  • Actualización del firmware remota: Utilizando el RUT230.

 

Compilando y cargando el firmware

El Industruino se programa utilizando el IDE de Arduino por USB, aunque también se puede programar por Ethernet utilizando TFTP, cosa que ya comentaré explicaré mas adelante en otra entrada.

En la Organización de Ingran Engineering de Github podéis encontrar el firmware y las librerías necesarias:

Para compilarlo y subirlo al Industruino, seguid estos pasos:

  1. Decargar el IDE portable de Arduino, versión 1.8.5
  2. Extraer arduino-1.8.5-windows.zip
  3. Dentro de la carpeta de arduino-1.8.5 crear una carpeta llamada “portable
  4. Abrir el programa arduino.exe
  5. Instalar la placa del industruino -> clicando Tools -> Boards Manager y buscando “industruino” -> Insalar “Industruino SAMD Boards 1.01
  6. Cerrar el entorno de programación de Arduino
  7. Descargar el proyecto Ikusi-Makusi de GitHub y extraerlo en donde se quiera
  8. Descargar el proyecto Ikusi-Makusi-libraries de GitHub y copiar las librerías en la carpeta arduino-1.8.5\libraries
  9. Abrir el programa arduino.exe de nuevo, en Herramienta->Placa seleccionar Industruino D21G y en Herramientas->Puerto el puerto de series correspondiente.
  10. Abrir el archivo Industruino_ethernet.ino del proyecto Ikusi-Makusi con el IDE de Arduino.
  11. Compilarlo y subirlo al Industruino.
  12. Conectad el Industruino a una red con DHCP y encenderlo.
  13. Con los botones navegar hasta la pantalla RED y mirad la IP asignada.
  14. Meter la IP en cualquier navegador web y empezar a experimentar.

Continuará…

 

Configurar servidor DNS caché con tu Raspberry Pi para mejorar la velocidad del Tráfico de tu Red Local

Un de las piezas claves hoy en día de nuestro Internet que permite que funcione, son las Domain Name System o mayormente conocido como DNS. Este sistema de servidores DNS es el encargado de traducir los nombres de dominio que manejamos habitualmente, como mascandobits.es, en la dirección IP del ordenador donde está alojado ese dominio, que en el momento de escribir esta entrada es 31.220.20.199 .

 

Contextualización


Cada ordenador en Internet tiene una dirección IP que es única para ese ordenador (por lo menos en la red que pertenece). La IP está formada por cuatro números enteros de 0 a 255, separados por puntos. 127.0.0.1 es un ejemplo de dirección IP que además es especial porque hace referencia a nuestra propia máquina. Cada vez que te conectas a Internet, a tu ordenador se le asigna una dirección IP, puede ser siempre la misma o puede variar, lo normal es que cada vez que reinicies el router o al cabo de un tiempo obtengas una IP diferente.

Esta IP que tiene tu equipo, y que te proporciona tu router, es privada y solo funciona en el rango de tu red local (dispositivos conectados a tu router). Existe un conjunto de rangos de IP que son usados como IPs privadas:

  • 192.168.0.0 – 192.168.255.255 (65,536 direcciones IP)
  • 172.16.0.0 – 172.31.255.255 (1,048,576 direcciones IP)
  • 10.0.0.0 – 10.255.255.255 (16,777,216 direcciones IP)

El primer grupo de IPs lo puedes ver en la red local de tu casa o empresa (si es pequeña), el segundo grupo en empresas algo más grandes y el último grupo es común verlo para equipos conectados mediante VPN.

A su vez existe una segunda IP denominada pública que es la que tu ISP o proveedor de servicios te asigna al router y que sirve para poder acceder a Internet. Esta IP pública suele ser dinámica en la mayor parte de los casos y tu ISP se la asigna a tu router, normalmente reiniciando el router puede cambiar esta IP.

La conversión de una IP privada a una pública y viceversa se hace gracias a la Network Address Translation o NAT del router. Esto permite hacer peticiones a IPs publicas de servicios de Internet y devolver el tráfico de respuesta a la IP privada de la máquina que hizo las peticiones.

Un vez aclarado esta parte que es básica avancemos….

Los ordenadores donde están alojadas las páginas web o servicios tienen siempre la misma dirección IP, esto permite acceder dichos recursos siempre igual con la misma IP (a no ser que se cambie…). Sin embargo, cuando buscas una determinada página o servicios, en tu navegador no introduces la IP del ordenador donde está alojada, sino algo más sencillo de recordar, introduces un nombre de dominio, como mascandobits.es. Adicionalmente he dicho que normalmente no se cambia la IP de la web o servicio, pero puede darse el caso por ejemplo de que se quiera mover la web o servicio a otra máquina que muy seguramente tenga otra IP pública.  Gracias a las DNS este problema queda cubierto, ya que simplemente basta con asociar el dominio con la nueva IP pública.

Cuando escribes en tu navegador el nombre de una web o servicio, lo que hace tu ordenador es preguntar a tu servidor local DNS (el que te indica tu router por DCHP) por la dirección IP del ordenador donde está alojada esa página o servicio. El servidor DNS es una gran base de datos con infinidad de traducciones de nombres de dominio a dirección IP. Esa base de datos es distribuida y compartida con otros proveedores y sus respectivos servidores DNS. Si el nombre de dominio que estás buscando no está en tu DNS local, éste realizará una petición a otros DNS de la red hasta encontrar la traducción adecuada. Estas bases de datos guardan en caché durante unos días esas traducciones de nombre de dominio a IP, por eso a veces sucede que si una web o servicio cambia de servidor, puede que desde algunos lugares del planeta se acceda a la web o servicio y desde otros no, porque hay ordenadores que cuando preguntan por la página, el servidor DNS los envía a la antigua dirección IP y no a la nueva.

Además de los servidores DNS, nuestro ordenador también guarda un caché de las DNS, y si hemos visitado recientemente una página web, nuestro ordenador ya no preguntará al servidor cuál es la dirección IP de la página, sino que se dirigirá a la que ya tiene almacenada. Esta caché puede borrarse.

Para borrarla desde Windows:

ipconfig /flushdns

Para borrarla desde GNU-Linux:

sudo /etc/init.d/nscd restart  //si usas nscd dns cache
sudo /etc/init.d/dnsmasq restart  //si usas dnsmasq dns cache
sudo /etc/init.d/named restart  //si usas bind dns cache
sudo /etc/init.d/bind9 restart  //(alternativa) si usas bind dns cache

 

Configurar servidor DNS caché


Las DNS constituyen la columna vertebral del funcionamiento de Internet y dado su función constituye un riesgo una mala gestión de los DNS globales que son gestionados por la ICANN, una asociación sin ánimo de lucro. Existen 7 llaves que dan acceso físico a los DNS y que se reparten entre 14 personas, 7 titulares y 7 suplentes. Son los garantes de que los DNS no sean atacadoso o modifcados de manera no deseada:

Como puedes deducir el acceso a la resolución de DNS es algo que puede ser muy crítico. La ICANN sólo constituye el registro de una parte de Internet, aunque habitualmente se suelen usar sus DNS como referencia, ya que a su vez las operadoras que dan acceso a Internet (ISP) tienen sus propio DNS que van configurados en nuestro router y los cuales podemos cambiar por otros que sean de nuestro agrado.

Controlar las DNS y cómo se resuelven es algo que puede ser ventajoso, sobre todo si tenemos dentro de nuestra red local el servidor DNS y la resolución de dominios tiene una menor latencia. Para crear nuestro DNS caché lo podemos hacer con una Raspberry Pi conectada a nuestra red local de casa. Una Raspberry Pi consume como un móvil cargando y puede servirnos perfectamente para este cometido de acelerar las peticiones de resolución de DNS.

Accedemos a nuestra Raspberry Pi por SSH e introducimos el siguiente comando:

sudo apt-get install bind9 dnsutils

Con esto instalamos bind y además instalamos la herramienta dig (con el paquete dnsutil) que más adelante ya veréis para qué sirve.

Un vez instalado vamos a /etc/bind/named.conf.options, puedes configurarlo con el siguiente comando:

sudo nano /etc/bind/named.conf.options

Lo puedes configurar con la siguiente información:

    forwarders {
         208.67.222.222;
         208.67.220.220;
    };

Es posible que tengas que quitar la // para que tenga efecto. Todo lo que va precedido con // se trata como un comentario. Yo he usado como forwarders las DNS de OpenDNS, pero puedes usar las que quieras o añadir otras.

Ahora recargamos las configuraciones con el siguiente comando:

rndc reload

Ya tenemos funcionando nuestro servidor DNS cacche. Para comprobar la diferencia de tiempos de resolución vamos a hacer la siguiente prueba. Vamos a resolver las peticiones contra las DNS de Google (8.8.8.8) (se asume que son de lo mejorcito 😉 ) y contra nuestro nuevo servidor DNS caché en la Raspberry Pi.

Introducimos el siguiente comando para comprobar el tiempo de respuesta para la resolución del dominio mascandobits.es con las DNS de Google:

dig mascandobits.es  @8.8.8.8

; <<>> DiG 9.9.5-9+deb8u13-Raspbian <<>> mascandobits.es @8.8.8.8
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 28184
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;mascandobits.es.               IN      A

;; ANSWER SECTION:
mascandobits.es.        2684    IN      A       31.220.20.199

;; Query time: 42 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Thu Oct 26 19:11:51 CEST 2017
;; MSG SIZE  rcvd: 60

Nos devuelve 42 msec, que no está anda mal, pero vamos a ejecutar lo mismo usando nuestro DNS de la Raspberry Pi. Lo haremos dos veces, ya que la primera vez le costará un tiempo similar, o algo mayor, ya que deberá ir a buscar la resolución del dominio a los forwarders que configuramos la primera vez, en mi caso a los DNS de OPenDNS. Para la segunda ejecución os debería salir algo así:

dig mascandobits.es  @127.0.0.1

; <<>> DiG 9.9.5-9+deb8u13-Raspbian <<>> mascandobits.es @127.0.0.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59435
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 7, ADDITIONAL: 14

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;mascandobits.es.               IN      A

;; ANSWER SECTION:
mascandobits.es.        2575    IN      A       31.220.20.199

;; AUTHORITY SECTION:
es.                     146250  IN      NS      a.nic.es.
es.                     146250  IN      NS      ns-ext.nic.cl.
es.                     146250  IN      NS      ns1.cesca.es.
es.                     146250  IN      NS      f.nic.es.
es.                     146250  IN      NS      ns3.nic.fr.
es.                     146250  IN      NS      sns-pb.isc.org.
es.                     146250  IN      NS      g.nic.es.

;; ADDITIONAL SECTION:
a.nic.es.               146250  IN      A       194.69.254.1
a.nic.es.               146250  IN      AAAA    2001:67c:21cc:2000::64:41
f.nic.es.               146250  IN      A       130.206.1.7
f.nic.es.               146250  IN      AAAA    2001:720:418:caf1::7
g.nic.es.               146250  IN      A       204.61.217.1
g.nic.es.               146250  IN      AAAA    2001:500:14:7001:ad::1
ns1.cesca.es.           146250  IN      A       84.88.0.3
ns1.cesca.es.           146250  IN      AAAA    2001:40b0:1:1122:ce5c:a000:0:3
ns3.nic.fr.             146250  IN      A       192.134.0.49
ns3.nic.fr.             146250  IN      AAAA    2001:660:3006:1::1:1
ns-ext.nic.cl.          146250  IN      A       200.1.123.14
sns-pb.isc.org.         146250  IN      A       192.5.4.1
sns-pb.isc.org.         146250  IN      AAAA    2001:500:2e::1

;; Query time: 1 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Oct 26 19:11:40 CEST 2017
;; MSG SIZE  rcvd: 495

Hemos bajado a 1 msec, que es bastante mejor que el tiempo de las DNS de Google. Además esto nos demuestra que se consigue bastante velocidad, en mi caso 42 veces más rápido para un dominio cacheado previamente por el servidor DNS de la Raspberry Pi.

Ahora para que todos los dispositivos de tu red usen estas nuevas DNS, lo más fácil es configurarlo en el router. Yo tengo un router de TP-Link, pero la configuración suele ser similar en todos los routers. Lo que nos interesa suele estar en la sección “DCHP”:

En el DNS Server he añadido la IP de la Raspberry Pi donde está el servidor DNS, es recomendable para ello que asignes IP estática a la Raspberry Pi. Hoy en día lo puedes hacer fácil desde el propio router asociando una IP privada a la MAC de la Raspberry Pi. El Secondary DNS Server lo he dejado con 0.0.0.0 para que lo resuelva contra el modem-router de proveedor de servicio a Internet (ISP). Esto hace que si la Raspberry Pi deja de funcionar, la red puede seguir resolviendo los dominios contra las DNS que me proporciona el router de mi ISP. Hay que cubrirse siempre 😉 !.

Con esto ya estaría listo, pero para dejarlo todo bien atado vamos a volver a la consola SSH de la Raspberry Pi para comprobar si bind arrancará al inicio si la apagas y enciendes. Para ello vamos a introducir el siguiente comando:

service bind9 status
● bind9.service - BIND Domain Name Server
   Loaded: loaded (/lib/systemd/system/bind9.service; enabled)
  Drop-In: /run/systemd/generator/bind9.service.d
           └─50-insserv.conf-$named.conf
   Active: active (running) since jue 2017-10-26 10:25:49 CEST; 5h 18min ago
     Docs: man:named(8)
 Main PID: 17478 (named)
   CGroup: /system.slice/bind9.service
           └─17478 /usr/sbin/named -f -u bind

Si en la línea de “Loaded” vemos al final “enabled”es que está activado como servicio al arranque. Si no fuera así bastaría con ejecutar el siguiente comando:

sudo systemctl enable bind9

Si quieres ver de manera general todos los servicios que tienes corriendo puedes ejecutar:

service --status-all

Podremos ver los servicios que existen y si están arrancados o no.

Con esto ya queda tu red perfectamente configurada para usar tu propio servidor DNS caché alojado en tu Rapsberry Pi para toda tu red local y mejorar los tiempos de respuesta de la resolución de dominios.