Built for Rock'n'Roll (i was)

Son obviedades, mas a mí me viene bien tenerlo por escrito. Estas son las diferentes formas de tener un servidor NextCloud en RaspBerry Pi:

Una vez instalado Open Media Vault 5 en el servidor, se le pueden añadir capacidades mediante plugins.

Algunos plugins oficiales de Open Media Vault son:

miniDLNA: servidor DLNA, permite proporcionar multimedia en streaming a otras máquinas. Probado [x]. Funciona correctamente.
MYSQL: Este plugin nos permitirá crear nuestra propia báse de datos.
Transmissionbt (!): Cliente torrent que, entre otras cosas, nos permite descargar con él desde otras máquinas. No existe -¿aún?- para OMV 5. En su lugar existe otro plugin:
Openmediavault-Downloader.
CUPS: servidor de impresión
dnsMasq
LVM2: volúmenes y particiones lógicos

Es posible desarrollar plugins a medida, particulares, los nuestros propios.

Hasta hace bien poco para correr el servidor de Open Media Vault (OMV) en RaspBerry Pi había que seguir el método tradicional que se aplicaba a los sistemas operativos de esta máquina: quemar una imagen del software en una microsd o un pendrive usb y arrancarlo en RaspBerry Pi. Se trataba de un sistema operativo "dedicado", basado en ArmBian, que corría todo lo necesario para que el servidor OMV funcionara.

Actualmente ese método ancestral ya no está "activo", e incluso la imagen .ISO ya no se encuentra en el "repositorio" habitual de SourceForge.

Hoy se instala Open Media Vault en RaspBerry Pi sobre un sistema operativo ya existente -RaspBian Lite es lo "recomendado- como si fuera un servicio convencional, incorporando elementos mediante apt.
Esto se puede hacer de dos formas: paso a paso, o bien automatizado a través de un script.

He intentado instalar Open Media Vault (y todas sus "dependencias") en RaspBian Buster completo (no en RaspBian Buster Lite, como se especifica oficialmente).

Ambos métodos han dado como resultado una instalación fallida debido, fundamentalmente, a que en el sistema ya existía una instalación mía de apache2, mariadb, php, etcétera...

He experimentado e investigado 3 cosas:



1) ¿Cómo se pueden subsanar los problemas que acontecen en RaspBian "completo" para que la instalación de OMV sea exitosa?
→ Desde cero. Sin instalar previamente servidores web, php, mysql etcétera. A partir de Raspbian limpio y actualizado se puede instalar OMV sin errores.



2) Si el fallo está en emplear como base RaspBian "completo" y no RaspBian Lite. Probar ambos métodos en RaspBian Lite.
Por ejemplo: Existe la posibilidad de que el hecho de emplear RaspBerry Pi 4 y no los anteriores modelos influya en los errores antes mencionados. O también que la versión de RaspBian empleada sea Buster y no Stretch. O también que la instalación de NextCloud + apache2 + mariadb + php7.2 que tenía ya consolidada interfiera.
→ El modelo de RaspBerry Pi no afecta en absoluto. OMV 5 funciona correctamente en RaspBerry Pi 4b.
SÍ es cierto que los problemas de instalación de OMV 5 eran debidos a las interferencias de la instalación de NextCloud + apache2 + mariadb + php7.2 que tenía ya consolidada.


3) Si, en caso de que OMV fuera exitosamente instalado en RaspBian Lite, ¿existirían incompatibilidades con...?:
3.1 la incorporación de un entorno gráfico
3.2 la incorporación mediante apt de servicios extras como NextCloud, PiHole, OpenVpn, etcétera.... algunos de los cuales he leído que OMV acepta incorporarlos como plugins o como Docker.
→ No he constatado incompatibilidades con el añadido a posteriori de un escritorio gráfico al sistema y mucho menos si el entorno gráfico es anterior a la instalación de OMV 5. Se logra instalar sin incidencias OMV 5 en RaspBian completo.
→ PiHole no interfiere, al menos si se instala después de instalar OMV y se le cambia el puerto a uno diferente del 80 (que es el que emplea PiHole) desde el interface web (de OMV).



4) Si el antiguo sistema para poner en funcionamiento un servidor OMV a partir de una imagen de disco (.ISO) funcionaría en RaspBerry Pi 4. Intuyo que no, mas he de comprobarlo empíricamente.
→ en curso.....

Este blog se está transportando a un sitio "más libre".
Puede consultarse este artículo en su nueva ubicación:
>>>>>>>>>>>>>>>>>>>>>>

Para poner o quitar el modo mantenimiento en NextCloud basta con editar el fichero /var/www/html/nextcloud/config/config.php y modificar el valor de 'maintenance' a true o false, según convenga.

sudo nano /var/www/html/nextcloud/config/config.php

  'maintenance' => false,

La partición boot y la partición rootfs deben estar en sincronía.
Podemos tener la partición boot en la tarjeta microsd y la partición de datos -rootfs- en un dispositivo de almacenamiento usb -algo muy común en RaspBerry Pi 4, que no arranca de forma "nativa" desde USB, o en el resto de modelos de RaspBerry Pi cuando utilizamos discos duros mecánicos que tienen excesiva latencia al arrancar-, mas ambas particiones deben estar sincronizadas: si se actualiza el sistema ambas particiones se ven afectadas. La partición de datos -rootfs- muy probablemente no funcionará correctamente si arrancamos desde una microsd con una partición de arranque -boot- que no ha sido actualizada simultáneamente.

Obtendremos, por ejemplo, el siguiente error nada más arrancar:

[Failed] Failed to start Load Kernel Modules.
See 'systemctl status systemd-modules-load.service' for details.

Generalmente viene aderezado con el problemón de que ningún dispositivo usb funcionará, ni las tarjetas de red, etcétera...

La solución rápida es recurrir a una copia de seguridad de ambas que haya sido realizada simultáneamente: partición de arranque y partición de datos.

Por consiguiente: cuando hagamos copia de seguridad del sistema, hagámoslo de ambas particiones.

El parámetro a continuación de -n es el tiempo en segundos que pasará entre comprobación y comprobación.
En este ejemplo se especifica que haga la comprobación cada 1 segundo.

watch -n 1 "vcgencmd measure_clock arm; vcgencmd measure_temp"

Establecer CONF_SWAPSIZE=256

/opt/vc/bin/tvservice -off

«««««««««««««««««««««««««««««««««««««««««««
Usage: tvservice [OPTION]...
  -p, --preferred                   Power on HDMI with preferred settings
  -e, --explicit="GROUP MODE DRIVE" Power on HDMI with explicit GROUP (CEA, DMT, CEA_3D_SBS, CEA_3D_TB, CEA_3D_FP, CEA_3D_FS), MODE (see --modes) and DRIVE (HDMI, DVI)
  -t, --ntsc                        Use NTSC frequency for HDMI mode (e.g. 59.94Hz rather than 60Hz)
  -c, --sdtvon="MODE ASPECT [P]"    Power on SDTV with MODE (PAL or NTSC) and ASPECT (4:3 14:9 or 16:9) Add P for progressive
  -o, --off                         Power off the display
  -m, --modes=GROUP                 Get supported modes for GROUP (CEA, DMT)
  -M, --monitor                     Monitor HDMI events
  -s, --status                      Get HDMI status
  -a, --audio                       Get supported audio information
  -d, --dumpedid <filename>         Dump EDID information to file
  -j, --json                        Use JSON format for --modes output
  -n, --name                        Print the device ID from EDID
  -l, --list                        List all attached devices
  -v, --device                      Specify the device to use (see --list)

  -h, --help                        Print this information

Cuando se sospecha que existe un problema con la fuente de alimentación de Raspberry Pi (por ejemplo, vemos que el led rojo parpadea o vemos que la la frecuencia baja) es una buena idea chequear el voltaje actual de la placa.
Existen 2 puntos de test etiquetados TP1 y TP2 en la placa base para facilitar las mediciones de voltaje. Con un polímetro configurado en el rango de 20 voltios DC (o 20 V =) si todo estuviera bien deberíamos obtener un voltaje entre 4'75 y 5'25 voltios.

PWR (rojo)
Indica que la placa está alimentada. En los modelos A+ y posteriores parpadeará si el voltaje cae por debajo de 4,63V


ACT (verde)
Indica actividad en la tarjeta SD (¿o en el almacenamiento usb?): parpadea cuando se lee o se escribe en ella.
Suele parpadear intensamente durante el arranque.

Adicionalmente el led ACT puede parpadear siguiendo un patrón específico para indicar problemas en el arranque:

1 parpadeo: Tarjeta SD incompatible
2 parpadeos: La tarjeta SD no puede ser leída
3 parpadeos: loader.bin no encontrado
4 parpadeos: loader.bin no lanzado
5 parpadeos: start.elf no encontrado
6 parpadeos: start.elf no lanzado
7 parpadeos: kernel.img no encontrado

Este blog se está transportando a un sitio "más libre".
Puede consultarse este artículo en su nueva ubicación:
>>>>>>>>>>>>>>>>>>>>>>

sudo apt update
sudo apt upgrade
sudo rpi-update

sudo apt install transmission-daemon

sudo /etc/init.d/transmission-daemon stop

sudo usermod -aG debian-transmission miusuario

mkdir /carpetadecompletados
mkdir /carpetadeincompletos

sudo cp /etc/transmission-daemon/settings.json /etc/transmission-daemon/settings.json.backup
sudo nano /etc/transmission-daemon/settings.json
"download-dir":"/carpetadecompletados"
"incomplete-dir":"/carpetadeincompletos
"
"incomplete-dir-enabled":true
"rpc-authentication-required":true
"rpc-bind-address":"0.0.0.0"
"rpc-whitelist-enabled":false
"rpc-enabled":true
"rpc-username": "TUUSUARIO",
"rpc-password":"TUPASSWORD"

(*) La contraseña, aunque podamos pensar que al guardar el archivo de configuración se mostrará en texto plano, creo que no se mostrará.
De alguna forma, al guardar el fichero de configuración, la contraseña se mostrará encriptada. Desconozco el algoritmo y el grado de seguridad de éste, mas la contraseña no se verá en texto plano.
En principio, el usuario por defecto -a no ser que lo cambiemos- es transmission


sudo chown -R debian-transmission:debian-transmission /carpetadecompletados
sudo find /carpetadecompletados -type d -print -exec chmod 775 {} \;
sudo find /carpetadecompletados -type f -print -exec chmod 664 {} \;

sudo chown -R debian-transmission:debian-transmission /carpetadeincompletos
sudo find /carpetadeincompletos -type d -print -exec chmod 775 {} \;
sudo find /carpetadeincompletos -type f -print -exec chmod 664 {} \;

sudo /etc/init.d/transmission-daemon start


Controlaremos remotamente Transmission desde el navegador, introduciendo: http://ipdelordenadorconTransmission:9091

Podemos agregar descargas, cancelarlas, etcétera.

Este blog se está transportando a un sitio "más libre".
Puede consultarse este artículo en su nueva ubicación:
>>>>>>>>>>>>>>>>>>>>>>

https://hijosdeinit.gitlab.io/howto_monitorizacion_raspberrypi_2/

Este blog se está transportando a un sitio "más libre".
Puede consultarse este artículo en su nueva ubicación:
>>>>>>>>>>>>>>>>>>>>>>

Hay discos duros externos a los que los 0'6A que entregan los puertos USB de Raspberry Pi no les basta para alimentarse y funcionar con normalidad.
Este problema, unido a la latencia inherente a la mayoría de controladoras IDE y SATA y/o los discos duros mecánicos, añade cierta complejidad al arranque de Raspberry Pi desde un disco duro.
Esto podría simplificarse si aumentamos el amperaje de los puertos USB de Raspberry Pi. Se hace editando el archivo /bios/config.txt, que es una especie de BIOS de Raspberry Pi.

sudo nano /boot/config.txt

añadimos la linea

max_usb_current=1

Existen muchas soluciones de cortafuegos disponibles para Linux, y la mayoría usan el proyecto IpTables para proveer filtrado de paquetes. Ese proyecto es la base del sistema de filtrado de red de Linux.
Iptables viene instalado por defecto en Raspbian, pero no está configurado.
Configurarlo puede ser una tarea complicada. Por eso existe un proyecto que provee de un entorno más simple para hacerlo. Se trata de ufw (Uncomplicated FireWall).
Es la herramienta de cortafuegos por defecto en Ubuntu y puede ser fácilmente instalada en Raspbian u otros sistemas operativos para Raspberry Pi.

sudo apt install ufw

sudo nano /etc/ssh/sshd_config

modificamos -y/o descomentamos- la línea que contiene “Port 22” de forma que ponga “port númerodepuertodeseado"

sudo systemctl restart ssh.service

ssh nombreusuariomaquinaremota@ipmáquinaremota -p númerodepuerto