domingo, 24 de mayo de 2026

Google Drive con rclone al inicio del sistema en Fedora 44

Cómo montar Google Drive con rclone al inicio en Fedora 44: error user_allow_other

Si al intentar montar Google Drive con rclone al inicio del sistema en Fedora 44 usando un servicio systemd de usuario el servicio falla, es posible que el problema sea la opción --allow-other y la configuración de FUSE. En esta entrada explico qué lo causa y cómo resolverlo.

¿Qué es este error?

Configuras el servicio en ~/.config/systemd/user/rclone-gdrive.service con la opción --allow-other, lo habilitas y al revisar los logs con:

journalctl --user -u rclone-gdrive.service -f

Aparece el siguiente mensaje:

mount helper error: fusermount3: option allow_other only allowed
if 'user_allow_other' is set in /etc/fuse.conf

Fatal error: failed to mount FUSE fs: fusermount: exit status 1

La opción --allow-other le indica a FUSE que otros usuarios del sistema puedan acceder al punto de montaje. Sin embargo, por seguridad, FUSE exige que esta capacidad esté explícitamente habilitada en el archivo de configuración del sistema /etc/fuse.conf.

En Fedora 44 esa línea existe en el archivo pero viene comentada con un # y un espacio delante:

# user_allow_other

Un sed automático puede no funcionar si hay espacio entre el # y el texto, dejando la línea sin cambios.

La solución

Abre el archivo de configuración de FUSE con privilegios de administrador:

sudo nano /etc/fuse.conf

Busca la línea que contiene user_allow_other. Aparecerá comentada así:

# user_allow_other

Elimina el # y el espacio para que quede exactamente así:

user_allow_other

Guarda y cierra el archivo. En nano: Ctrl+O para guardar, Ctrl+X para salir.

Reinicia el servicio:

systemctl --user restart rclone-gdrive.service

Verifica que está funcionando:

systemctl --user status rclone-gdrive.service
ls ~/GoogleDrive

Deberías ver el estado active (running) y el contenido de tu Google Drive en el directorio ~/GoogleDrive.

Alternativa: prescindir de --allow-other

Si eres el único usuario del equipo y no necesitas que otros accedan al montaje, la solución más sencilla es eliminar la opción --allow-other del archivo del servicio, evitando tocar /etc/fuse.conf:

nano ~/.config/systemd/user/rclone-gdrive.service
# Elimina la línea --allow-other

systemctl --user daemon-reload
systemctl --user restart rclone-gdrive.service

Referencia: servicio systemd completo

Este es el archivo de servicio systemd de usuario recomendado para Fedora 44. Guárdalo en ~/.config/systemd/user/rclone-gdrive.service:

[Unit]
Description=rclone Google Drive mount
After=network-online.target
Wants=network-online.target

[Service]
Type=notify
ExecStart=/usr/bin/rclone mount gdrive: %h/GoogleDrive \
    --vfs-cache-mode full \
    --vfs-cache-max-age 168h \
    --cache-dir %h/.cache/rclone \
    --dir-cache-time 1h \
    --log-level INFO \
    --allow-other
ExecStop=/bin/fusermount -u %h/GoogleDrive
Restart=on-failure
RestartSec=5

[Install]
WantedBy=default.target

El especificador %h se expande automáticamente al directorio home del usuario, por lo que no es necesario escribir la ruta completa.

Habilitar el arranque automático en el boot

Para que el servicio arranque en el boot sin necesidad de iniciar sesión interactiva, habilita el lingering del usuario:

loginctl enable-linger $USER

Resumen de comandos

# Editar fuse.conf y descomentar user_allow_other
sudo nano /etc/fuse.conf

# Recargar y reiniciar el servicio
systemctl --user daemon-reload
systemctl --user restart rclone-gdrive.service

# Verificar estado
systemctl --user status rclone-gdrive.service

# Ver logs en tiempo real
journalctl --user -u rclone-gdrive.service -f

# Habilitar arranque automático sin login
loginctl enable-linger $USER

Cómo eliminar el error PXE-E05 en el arranque con una tarjeta Intel 82571EB

Cómo eliminar el error PXE-E05 en el arranque con una tarjeta Intel 82571EB

Si al encender el ordenador aparece el siguiente mensaje y el arranque tarda más de lo normal, este artículo explica cómo solucionarlo definitivamente.

Initializing Intel(R) Boot Agent GE v.1.2.36
PXE 2.1 Build 085 (WfM 2.0), RPL v1.28
PXE-E05: The LAN adapter's NVM configuration is corrupted
         or has not been initialized. The Boot Agent cannot continue.

¿Qué es este error?

Este mensaje lo genera el Intel Boot Agent, un firmware grabado en la ROM de la tarjeta de red que permite arrancar el equipo desde la red (PXE boot). Es especialmente común en tarjetas de gama profesional/servidor como la Intel 82571EB Gigabit, donde el PXE viene activado de fábrica.

El error PXE-E05 indica que la NVM (memoria no volátil) de la tarjeta está corrupta o sin inicializar. La red sigue funcionando con normalidad una vez cargado el sistema operativo, pero el proceso de arranque se alarga innecesariamente mientras el Boot Agent intenta iniciarse y falla.

Identificar la tarjeta y sus puertos

En Linux, podemos identificar el hardware con:

lspci | grep Ethernet

En nuestro caso la salida fue:

02:00.0 Ethernet controller: Intel Corporation 82571EB/82571GB Gigabit Ethernet Controller D0/D1 (copper applications) (rev 06)
02:00.1 Ethernet controller: Intel Corporation 82571EB/82571GB Gigabit Ethernet Controller D0/D1 (copper applications) (rev 06)

Para saber el driver en uso:

lspci -k -s 02:00.0

Salida esperada:

Kernel driver in use: e1000e
Kernel modules: e1000e

La solución: Intel BootUtil

Intel proporciona una utilidad llamada BootUtil que permite modificar la configuración del Boot Agent directamente en la NVM de la tarjeta, de forma permanente e independiente de la BIOS.

La herramienta se descarga desde la página oficial de Intel: Intel® Ethernet Connections Boot Utility, Preboot Images, and EFI Drivers . Para Linux hay que descargar el archivo Preboot.tar.gz.

Una vez descomprimido, el ejecutable para Linux de 64 bits es bootutil64e.

Primer intento: -BOOTENABLE=disable

El comando habitual para desactivar el PXE es:

sudo ./bootutil64e -NIC=2 -BOOTENABLE=disable

Pero en nuestro caso devolvió un error:

Found discrete ROM in the flash for NIC 2
The -BOOTENABLE command can only be used on flashed combo images
Bad parameter

El problema es que la tarjeta tiene una ROM discreta en lugar de una imagen combo, por lo que el parámetro -BOOTENABLE no es compatible. El listado de puertos mostraba la situación:

Port  Network Address    Location         Series   WOL  Flash Firmware          Version
====  =================  ===============  =======  ===  ======================  =======
   1  C860000A7864       00000:000:25.0   Gigabit  YES  FLASH Not Present
   2  001517851DD6       00000:002:00.0   Gigabit  YES  PXE                     1.2.36
   3  001517851DD7       00000:002:00.1   Gigabit  N/A  FLASH Disabled

El puerto 2 (NIC 2) tenía el Boot Agent PXE activo, mientras que el puerto 3 ya estaba desactivado.

Solución correcta: -FLASHDISABLE

El comando correcto para ROM discreta es -FLASHDISABLE:

sudo ./bootutil64e -NIC=2 -FLASHDISABLE

Salida:

Intel(R) Ethernet Flash Firmware Utility
BootUtil version 1.43.32.0
Copyright (C) 2003-2026 Intel Corporation
Disabling boot ROM on port 2...Success

Port  Network Address    Location         Series   WOL  Flash Firmware          Version
====  =================  ===============  =======  ===  ======================  =======
   1  C860000A7864       00000:000:25.0   Gigabit  YES  FLASH Not Present
   2  001517851DD6       00000:002:00.0   Gigabit  YES  FLASH Disabled
   3  001517851DD7       00000:002:00.1   Gigabit  N/A  FLASH Disabled

Ambos puertos con FLASH Disabled. El cambio es permanente: se graba en la NVM de la tarjeta y persiste aunque se cambie de equipo o de BIOS.

Resultado

Al reiniciar, el mensaje PXE-E05 desapareció por completo y el arranque se redujo notablemente al eliminarse la espera del Boot Agent. La tarjeta de red sigue funcionando con normalidad en el sistema operativo, ya que el driver e1000e es completamente independiente del firmware de arranque PXE.

Resumen de comandos

# Identificar la tarjeta
lspci | grep Ethernet
lspci -k -s 02:00.0

# Descargar BootUtil desde Intel y descomprimir
tar -xzf Preboot.tar.gz
cd APPS/BootUtil/Linux_x64/

# Listar puertos y estado
sudo ./bootutil64e

# Deshabilitar el Boot Agent en ROM discreta
sudo ./bootutil64e -NIC=2 -FLASHDISABLE

miércoles, 24 de septiembre de 2025

Configurar Intel AX200 como Access Point en OPNsense

Configurar Intel AX200 como Access Point en OPNsense

Configurar Intel AX200 como Access Point en OPNsense

En este tutorial se explica paso a paso cómo detectar y configurar una tarjeta Intel AX200 en OPNsense para usarla como punto de acceso inalámbrico (AP). Los pasos incluyen la instalación del firmware, creación de la interfaz y configuración de la red Wi-Fi.

1. Detectar la tarjeta Wi-Fi

Primero, se verifica que OPNsense detecta la tarjeta en el bus PCI:

pciconf -lv | grep -A1 -B3 network
iwlwifi0@pci0:1:0:0:
    vendor     = 'Intel Corporation'
    device     = 'Wi-Fi 6 AX200'
    class      = network
---

2. Instalar el firmware necesario

OPNsense requiere el firmware para que la tarjeta funcione correctamente. Con fwget se identifica el paquete:

fwget pci
Needed firmware packages: 'wifi-firmware-iwlwifi-kmod-22000'

Se instala con:

pkg install wifi-firmware-iwlwifi-kmod-22000

Luego se reinicia el sistema para que el firmware se cargue:

reboot
---

3. Comprobar detección del driver

Después del reinicio, verificamos que el módulo del driver esté cargado:

kldstat | grep iwn

Si el módulo if_iwn ya está presente, significa que el driver está cargado.

---

4. Crear la interfaz Wi-Fi

En FreeBSD/OPNsense, hay que crear la interfaz manualmente sobre el dispositivo detectado:

ifconfig wlan0 create wlandev iwlwifi0
ifconfig wlan0 up
ifconfig wlan0

Esto genera la interfaz wlan0 lista para usar.

Para que se cargue automáticamente al iniciar:

echo 'if_iwn_load="YES"' >> /boot/loader.conf.local
---

5. Configurar la interfaz en OPNsense

1. Acceder a la GUI de OPNsense y asignar la interfaz wlan0 como nueva interfaz llamada, por ejemplo, WiFiAP.

2. Habilitar la interfaz y asignar una IP estática, por ejemplo 192.168.X.1/24.

---

6. Configurar como Access Point

En la GUI de OPNsense:

  • Ir a Services → Wireless → Access Point.
  • Seleccionar la interfaz WiFiAP.
  • Configurar el SSID, modo Access Point, canal y seguridad WPA2 Personal.
  • Guardar y aplicar los cambios.
---

7. Configurar DHCP para clientes

1. Ir a Services → DHCP Server → WiFiAP.

2. Activar DHCP y asignar un rango de direcciones IP, por ejemplo 192.168.X.100-192.168.X.200.

---

8. Verificar funcionamiento

Clientes Wi-Fi deberían poder detectar el SSID y conectarse. Para verificar el estado desde la shell:

ifconfig wlan0
clog /var/log/system.log | grep wlan0

Con esto, la tarjeta Intel AX200 está funcionando como punto de acceso en OPNsense.

viernes, 12 de septiembre de 2025

OPNsense: ¿Nativo o Virtual? Una comparativa de rendimiento con interfaz de 2.5Gb

Parte 1 

Introducción

En este artículo, nos sumergiremos en una comparación de rendimiento entre dos configuraciones populares de OPNsense: instalado directamente en un hardware dedicado (barebone) y como una máquina virtual en Proxmox. Ambas opciones tienen sus ventajas, pero ¿cuál ofrece un mejor rendimiento?


Equipo Utilizado

Hardware: Placa base BKHN-NVR con procesador Intel Celeron N5105 y cuatro interfaces de red 2.5Gb/s, 32GB de memoria, NVME monando un SSD de 256GB y raspberry pi 4 como servidor iperf3 local.

Software: OPNsense y Proxmox.

Herramientas de prueba: iperf3, speedtest-cli, y medidor de consumo Shelly plug S

Configuración

OPNsense Nativo: Instalación estándar de OPNsense en el hardware dedicado.

OPNsense Virtual: Máquina virtual en Proxmox con asignación de los cuatro núcleos del procesador y la totalidad de la RAM disponible. Las interfaces de red están configuradas en modo bridge para un acceso directo al hardware.

Metodología de prueba

Para evaluar el rendimiento de ambas configuraciones, realizaremos una serie de pruebas de transferencia de datos utilizando con iperf3 y speedtest-cli. 

Como servidor iperf3 utilizaremos algunos de los disponibles en public-iperf3-servers

Cliente se conectara al servidor mediante el router local, un FRITZ!Box 6590 Cable, usando el puerto 5201. Estas pruebas medirán la velocidad de subida y bajada, así como la latencia. Adicionalmente, mediremos el consumo en ambos escenarios. 

El cliente es un ordenador Intel(R) Core(TM) i7-2600K CPU @ 3.40GHz con 16GiB de RAM, usando  Fedora 38: 6.8.9-100.fc38.x86_64. El cliente esta conectado a la red local en el puerto ethernet igc0  de 2.5Gb/s del ordenador N5105 donde se esta ejecutando OpenSense mediante un cable CAT5 aunque  el puerto del cliente es de 1 Gbit/s


Para realizar las pruebas de velocidad en local, hemos utilizado un raspberry pi4 conectada al mismo router FRITZ!Box.



Comandos Sugeridos:  iperf3 y speedtest-cli

Servidor: 

iperf3 -s

Cliente: 

iperf3 -c <IP del servidor> -P 4 -t 30 (4 hilos, 30 segundos)

speedtest-cli --server <ID del servidor> --threads 4 (4 hilos)


Preparación

Primer paso ha sido actualizar la raspeberry pi 4 con los siguientes comandos:

  1. sudo apt update.
  2. sudo apt full-upgrade.
  3. sudo reboot.
  4. sudo apt autoremove.
  5. sudo apt clean.
  6. sudo rpi-eeprom-update.
  7. sudo rpi-eeprom-update -a.
  8. sudo reboot.


A continuación, instalo en comando iperf3 en la raspberry pi 4 con:

sudo apt-get install iperf3

Ahora, para evitar fisgones, cambio el prompt.

Para mostrar el prompt actual usamos:

[\u@\h \W]\$ echo "$PS1"
[\u@\h \W]\$

Para cambiar el prompt, usamos:
PS1='[\D{%F %T}]\$'

Resultados y análisis

Resultados de las pruebas de velocidades máximas alcanzadas en configuracion standalone con iperf3

Repetimos la prueba con cuatro servidores diferentes:


con el segundo servidor:


con el tercer servidor:


Con el ultimo servidor:



Con el siguiente bash script hacemos que los resultados se muestren en una tabla html:

cat comparativa_iperf3.sh 

#!/bin/bash

# Lista de servidores
SERVIDORES=("spd-desrv.hostkey.com" "a205.speedtest.wobcom.de" "a209.speedtest.wobcom.de" "speedtest.novoserve.com")

# Función para ejecutar iperf3 y extraer los resultados
function ejecutar_iperf3 {
  servidor=$1
  modo=$2
  puerto=5201

  # Comando iperf3
  comando="iperf3 -c $servidor -p $puerto -t 10 $modo"

  # Ejecutar el comando y extraer las líneas sender y receiver
  resultado=$(eval $comando 2>&1)
  sender=$(echo "$resultado" | grep sender | tail -n 1)
  receiver=$(echo "$resultado" | grep receiver | tail -n 1)
  echo $servidor $sender
  echo $servidor $receiver

  # Extraer los valores de cada línea
  IFS=' ' read -ra AD_sender <<< "$sender"
  IFS=' ' read -ra AD_receiver <<< "$receiver"

  # Formatear los resultados para la tabla HTML
  echo "" >> resultados.html
  echo "  $servidor" >> resultados.html
  echo "  $modo" >> resultados.html
  echo "  ${AD_sender[4]}" >> resultados.html  # Tasa de bits sender
  echo "  ${AD_receiver[4]}" >> resultados.html  # Tasa de bits receiver
  echo "" >> resultados.html
}

# Crear el archivo HTML
echo "" > resultados.html
echo "" >> resultados.html
echo "" >> resultados.html
echo "" >> resultados.html
echo "" >> resultados.html
echo "" >> resultados.html
echo "

Resultados de las pruebas iperf3

" >> resultados.html echo "" >> resultados.html echo " " >> resultados.html echo " " >> resultados.html echo " " >> resultados.html echo " " >> resultados.html echo " " >> resultados.html echo " " >> resultados.html # Iterar sobre los servidores y modos for servidor in "${SERVIDORES[@]}"; do for modo in "" "-R"; do ejecutar_iperf3 "$servidor" "$modo" done done echo "
ServidorModoTasa de bits Sender (Mbits/s)Tasa de bits Receiver (Mbits/s)
" >> resultados.html echo "" >> resultados.html echo "" >> resultados.html echo "Resultados guardados en resultados.html"




Evaluacion del consumo electrico:


Consistencia: Evalúa la consistencia de los resultados a lo largo de múltiples pruebas.

Latencia: Compara la latencia de red en ambas configuraciones.

Sobrecarga del sistema: Observa si hay signos de sobrecarga del sistema en alguna de las configuraciones.

Conclusión

[Resume los hallazgos principales de tu prueba y ofrece una recomendación sobre cuál configuración es más adecuada para diferentes escenarios].


Factores a Considerar:


Requisitos específicos: Las necesidades de cada usuario pueden variar.

Complejidad de la configuración: OPNsense nativo puede ser más sencillo de configurar para usuarios menos experimentados.

Flexibilidad: Las máquinas virtuales ofrecen una mayor flexibilidad en términos de migración y escalabilidad.

En este artículo, hemos explorado las diferencias de rendimiento entre OPNsense instalado de forma nativa y como máquina virtual en Proxmox. Los resultados obtenidos [inserta tus conclusiones aquí] pueden servir como una guía para elegir la configuración más adecuada para tu entorno específico.


Preguntas para la Comunidad

¿Has realizado pruebas similares? ¿Cuáles fueron tus resultados?

¿Qué otras herramientas o metodologías recomendarías para evaluar el rendimiento de OPNsense?

¿Cuáles son tus experiencias con OPNsense en entornos virtuales y físicos?

¡Espero que este artículo te haya resultado útil!

OPNsense nativo en Zimaboard 832

Instalación y pruebas de rendimiento de OPNsense en ZimaBoard 832

Instalación y pruebas de rendimiento de OPNsense en ZimaBoard 832

En esta entrada detallo los pasos que seguí para instalar y configurar OPNsense en una ZimaBoard 832, así como las pruebas de rendimiento realizadas tanto en la red local como hacia servidores externos.

1. Instalación de OPNsense

Descargué la imagen de OPNsense, la copié a Ventoy y seguí el procedimiento de instalación mostrado en el vídeo aquí.

2. Configuración inicial y seguridad

  • Configuré la red local.
  • Activé HTTP Strict Transport Security (HSTS).
  • Configuré Google Authenticator como servidor MFA.
  • Habilité MFA para el usuario root.

3. Consola HDMI siempre activa

Se ajustó el archivo /boot/loader.conf para que la consola permanezca activa aunque no haya monitor conectado:

kern.vty=vt
hw.vga.textmode=0
kern.multicons=1

4. Creación de usuario con SSH

Se creó un usuario adicional para administración, añadido al grupo Admins, utilizando autenticación por claves SSH:

# Generación de claves SSH
ssh-keygen -t ed25519

# Copiar clave pública al servidor OPNsense
ssh-copy-id usuario@opnsense-ip

El usuario root permanece habilitado, pero la administración se realiza preferentemente con este nuevo usuario.

5. Pruebas de rendimiento LAN interna

Se instaló el plugin os-iperf en OPNsense y se realizaron pruebas TCP y UDP:

Prueba TCP interna

# En PC LAN como servidor
iperf3 -s

# En OPNsense como cliente
iperf3 -c 172.16.1.5 -l 64k

Resultado: ~943 Mbit/s promedio, 1.10 GB transferidos en 10 s, 150 retransmisiones.

Prueba UDP interna (1 Gbit/s)

# En OPNsense
iperf3 -c 172.16.1.5 -u -b 1G

Resultado: 955–956 Mbit/s, 1.11 GB transferidos, jitter 0.002–0.013 ms, sin pérdidas de paquetes.

6. Pruebas hacia servidores externos

Se realizaron pruebas TCP y UDP desde el PC LAN hacia distintos servidores externos:

Servidor Modo Tasa Sender (Mbit/s) Tasa Receiver (Mbit/s)
spd-desrv.hostkey.com 59.4 57.6
spd-desrv.hostkey.com -R 423 413
a205.speedtest.wobcom.de 60.2 58.9
a205.speedtest.wobcom.de -R 585 566
a209.speedtest.wobcom.de 61.4 59.4
a209.speedtest.wobcom.de -R 454 419
speedtest.novoserve.com - -
speedtest.novoserve.com -R - -

Conclusión

Las pruebas muestran que la red LAN interna del ZimaBoard 832 con OPNsense alcanza velocidades cercanas a 1 Gbit/s tanto en TCP como en UDP, mientras que las pruebas hacia Internet dependen del ancho de banda y la latencia de los servidores externos, mostrando variaciones entre 40 y 585 Mbit/s según el servidor y el modo de prueba.

jueves, 29 de mayo de 2025

Cómo instalar HP AMS en Proxmox sobre un Microservidor HP Gen8

 

Una de las funcionalidades más útiles del iLO en los servidores HP es la posibilidad de monitorizar el hardware, incluyendo los discos duros instalados en cada bahía. Para lograr esto en un entorno como Proxmox, es necesario instalar el Agentless Management Service (HP AMS), que se encarga de enviar esta información al iLO.

En esta entrada te cuento los pasos que seguí para instalar HP AMS en mi Microservidor HP Gen8 con Proxmox, basándome en la documentación oficial de HPE pero resolviendo manualmente algunos problemas en el camino.

Paso 1: Añadir los repositorios de HPE

Primero consulté la página oficial del proyecto MCP (Management Component Pack) de HPE:

👉 https://downloads.linux.hpe.com/SDR/project/mcp/

Allí indican cómo añadir el repositorio a tu sistema Debian (que es la base de Proxmox). Seguí las instrucciones añadiendo el repositorio y su clave GPG.

Paso 2: Intentar instalar el paquete

Tras configurar el repositorio, intenté instalar hp-ams con:

apt-get update
apt-get install hp-ams

Sin embargo, me encontré con un problema: el paquete no estaba disponible en el índice APT.

Paso 3: Descarga manual del paquete

Investigando un poco más, descubrí que los paquetes .deb también están disponibles directamente en este enlace:

👉 https://downloads.linux.hpe.com/SDR/repo/mcp/pool/non-free/

Desde ahí, localicé y descargué manualmente la última versión del paquete hp-ams compatible con Debian.

wget https://downloads.linux.hpe.com/SDR/repo/mcp/pool/non-free/hp-ams_<versión>.deb

Asegúrate de elegir la versión correcta para tu arquitectura (probablemente amd64).

Paso 4: Instalar gdebi para gestionar dependencias

Para instalar fácilmente el paquete .deb con todas sus dependencias, instalé gdebi:

apt-get install gdebi-core

Y luego:

gdebi hp-ams_<versión>.deb

Esto resolvió automáticamente las dependencias necesarias y completó la instalación correctamente.

Paso 5: Verificar que funciona

Después de reiniciar el servicio o el sistema, accedí a la interfaz web de iLO de mi Microservidor HP Gen8.

Fui a:

Information → System Information → Storage

¡Y por fin pude ver la información detallada de los discos instalados en cada bahía! Gracias a HP AMS, iLO es capaz ahora de obtener y mostrar esta información correctamente, incluso sin tener instalado un sistema operativo de HPE.

Conclusión

Aunque la instalación de HP AMS en Proxmox no es directa debido a la ausencia del paquete en el repositorio, con un poco de paciencia y una descarga manual, se puede lograr fácilmente. Esta pequeña mejora permite una mayor visibilidad del estado del hardware directamente desde iLO, lo cual es muy útil en entornos sin monitorización tradicional.

Si estás usando un HP Gen8 con Proxmox, te recomiendo realizar esta instalación para aprovechar al máximo las capacidades del servidor.

Addendum

También instalo la utilidad ssacli usando wget y gdebi. Sin embargo, cuando ejecuto:

ssacli ctrl all show

devuelve Error: no controllers detected.

Es posible que deba instalar el driver para el controlador SATA


sábado, 22 de febrero de 2025

Cómo forzar una instalación limpia de OpenJDK en Fedora

Forzar una instalación limpia de OpenJDK en Fedora

Cómo forzar una instalación limpia de OpenJDK en Fedora

Si necesitas asegurarte de que OpenJDK se instala sin conflictos o restos de versiones anteriores, puedes seguir estos pasos para realizar una instalación limpia en Fedora:

  1. Elimina los paquetes OpenJDK existentes:

    Abre una terminal y ejecuta el siguiente comando:

    sudo dnf remove java-*openjdk*

    Este comando eliminará todos los paquetes que comiencen con "java-" y contengan "openjdk". Esto debería eliminar todas las versiones instaladas de OpenJDK.

  2. Limpia las dependencias restantes:

    Ejecuta el siguiente comando para eliminar las dependencias que se instalaron con OpenJDK pero que ya no son necesarias:

    sudo dnf autoremove
  3. Purga los archivos en caché o no utilizados:

    Limpia la caché del administrador de paquetes DNF para asegurar un inicio limpio para la nueva instalación:

    sudo dnf clean all
  4. Instala la versión deseada de OpenJDK:

    Instala el kit de desarrollo de OpenJDK (JDK) para la versión deseada. Por ejemplo, para instalar la versión 17:

    sudo dnf install java-17-openjdk-devel

    Puedes reemplazar "17" con el número de versión deseado (por ejemplo, 11, 18, etc.). Si solo necesitas el Entorno de tiempo de ejecución de Java (JRE), puedes instalar java-17-openjdk en su lugar.

  5. Verifica la instalación:

    Asegúrate de que la instalación se realizó correctamente ejecutando el siguiente comando:

    java -version

    Este comando mostrará la versión de Java instalada, confirmando una instalación exitosa.

Notas adicionales

  • Si tienes varias versiones de Java instaladas, puedes usar el comando alternatives para administrarlas:
    sudo alternatives --config java
  • También puedes instalar OpenJDK usando la herramienta sdkman (Software Development Kit Manager), que proporciona una forma conveniente de administrar múltiples instalaciones de JDK.
  • Si encuentras algún problema, consulta la documentación de Fedora o los foros de la comunidad para obtener más ayuda.

miércoles, 14 de febrero de 2024

Solución al error en Autofirma al crear una cuenta directa en tesoro.es en Fedora 38

¡Hola a todos los usuarios de Fedora 38!

Hoy quiero compartir con ustedes una solución a un problema que puede surgir al intentar crear una cuenta directa en el portal tesoro.es utilizando Autofirma. Si te has encontrado con el mensaje de error "Error al recuperar los datos del servidor intermedio" seguido por un error de Java que dice "unable to find valid certification path to requested target", ¡no te preocupes! Aquí te explicaré paso a paso cómo solucionarlo.




Descargar los certificados intermedios

Para empezar, necesitamos descargar los certificados intermedios del servidor utilizando el siguiente comando en la terminal:

openssl s_client -showcerts -connect packagecloud.io:443

Este comando nos mostrará una lista de certificados. Debes copiar cada certificado comprendido entre "BEGIN CERTIFICATE" y "END CERTIFICATE" que se muestra en la terminal. En mi caso, obtuve cuatro certificados.

Guardar los certificados en archivos .crt

Pega cada certificado en un archivo de texto diferente y guárdalos con la extensión .crt. Por ejemplo, puedes nombrarlos como 1.crt, 2.crt, 3.crt y 4.crt.

Importar los certificados en el almacén de confianza de Java

Ahora, vamos a importar cada certificado uno por uno en el almacén de confianza de Java utilizando los siguientes comandos en la terminal:

sudo keytool -importcert -keystore /etc/pki/ca-trust/extracted/java/cacerts -storepass changeit -file 1.crt -alias "root_cert_1"
sudo keytool -importcert -keystore /etc/pki/ca-trust/extracted/java/cacerts -storepass changeit -file 2.crt -alias "root_cert_2"
sudo keytool -importcert -keystore /etc/pki/ca-trust/extracted/java/cacerts -storepass changeit -file 3.crt -alias "root_cert_3"
sudo keytool -importcert -keystore /etc/pki/ca-trust/extracted/java/cacerts -storepass changeit -file 4.crt -alias "root_cert_4"

Firmar la operación en Autofirma

Una vez que hayas importado los certificados, vuelve a intentar crear la cuenta directa en tesoro.es utilizando Autofirma. Esta vez, deberías poder firmar la operación sin errores.

¡Y eso es todo! Con estos pasos, deberías poder solucionar el error en Autofirma y completar la creación de tu cuenta directa en tesoro.es sin problemas.

En esta página puedes encontrar más información.

Espero que esta guía te haya sido útil. ¡Si tienes alguna pregunta o comentario, no dudes en dejarlo abajo!

viernes, 17 de noviembre de 2023

Instalación de Grafana, Prometheus y Pi-hole con Ansible

 

Instalación de Grafana, Prometheus y Pi-hole con Ansible en Raspberry Pi

Se describe el proceso para instalar estas aplicaciones en Raspberry Pi:

  uname -r

Devuelve el siguiente resultado sobre la version del SO:

  6.1.0-rpi6-rpi-v8

Para configurar tu red y monitorearla con Grafana, Prometheus y Pi-hole usando Ansible, sigue estos pasos:

  1. Instala ansible:
  2.   pipx install --include-deps ansible
      pipx upgrade --include-injected ansible
  3. Clona el repositorio:
  4.   git clone https://github.com/geerlingguy/internet-pi.git
      cd internet-pi/
      cp example.inventory.ini inventory.ini
      cp example.config.yml config.yml
      nano inventory.ini 
      nano config.yml 
      sudo ansible-playbook main.yml

    Yo he tenido problemas al ejecutar el playbook porque daba el siguiente error al instalar docker-compose:

    
    TASK [Install Docker Compose using Pip.] *************************************************************************
    fatal: [127.0.0.1]: FAILED! => {"changed": false, "cmd": ["/usr/local/bin/pip3", "install", "docker-compose"], "msg": "\n:stderr: error: externally-managed-environment\n\n× This environment is externally managed\n╰─> To install Python packages system-wide, try apt install\n    python3-xyz, where xyz is the package you are trying to\n    install.\n    \n    If you wish to install a non-Debian-packaged Python package,\n    create a virtual environment using python3 -m venv path/to/venv.\n    Then use path/to/venv/bin/python and path/to/venv/bin/pip. Make\n    sure you have python3-full installed.\n    \n    For more information visit http://rptl.io/venv\n\nnote: If you believe this is a mistake, please contact your Python installation or OS distribution provider. You can override this, at the risk of breaking your Python installation or OS, by passing --break-system-packages.\nhint: See PEP 668 for the detailed specification.\nDEPRECATION: Loading egg at /usr/local/lib/python3.11/dist-packages/vilib-0.2.0-py3.11.egg is deprecated. pip 24.3 will enforce this behaviour change. A possible replacement is to use pip for package installation.. Discussion can be found at https://github.com/pypa/pip/issues/12330\n"}
      

    Para solucionarlo he intentado instalar docker-compose manualmente, pero tambien da el siguiente error:

     pip install docker-compose

    error: externally-managed-environment
    
    × This environment is externally managed
    ╰─> To install Python packages system-wide, try apt install
        python3-xyz, where xyz is the package you are trying to
        install.
        
        If you wish to install a non-Debian-packaged Python package,
        create a virtual environment using python3 -m venv path/to/venv.
        Then use path/to/venv/bin/python and path/to/venv/bin/pip. Make
        sure you have python3-full installed.
        
        For more information visit http://rptl.io/venv
    
    note: If you believe this is a mistake, please contact your Python installation or OS distribution provider. You can override this, at the risk of breaking your Python installation or OS, by passing --break-system-packages.
    hint: See PEP 668 for the detailed specification.
      

    Tambien lo intento instalar con:

     pipx install docker-compose
    

    pero tambien da error:

    Fatal error from pip prevented installation. Full pip output in file:
        /.local/pipx/logs/cmd_2023-11-14_22.35.44_pip_errors.log
    
    pip seemed to fail to build package:
        PyYAML6,>=3.10
    
    Some possibly relevant errors from pip install:
        error: subprocess-exited-with-error
        AttributeError: cython_sources
    
    Error installing docker-compose.

    Entonces sigo las instrucciones descritas en este enlace para instalar docker-compose en un entorno virtual

  5. Para instalar Docker Compose manualmente:
  6.  python3 -m venv /ruta/a/tu/entorno_virtual
     source /ruta/a/tu/entorno_virtual/bin/activate
     pip install PyYAML==5.4.1
     pipx install docker-compose

Después de seguir estos pasos, deberías tener instalados Grafana, Prometheus, Pi-hole y Docker Compose para monitorear tu red.

Recuerda ajustar los comandos según tu entorno y las necesidades específicas de tu configuración.

Despues modifica el archivo docker.yml para actualizar el path al comando de instalacion a la nueva ubicacion en el entorno virtual

  nano tasks/docker.yml

El archivo docker.yml contiene pip3 como ejecutable, para que se ejecute pip3 en el entorno virtual, modifica el path del executable:

  - name: Install Docker Compose using Pip.
    ansible.builtin.pip:
    name: docker-compose
    state: present
    executable: /ruta/a/tu/entorno_virtual/bin/pip3

Ahora activamos el entorno virtual y ejecutamos el playbook:

  source ~/python-venv/bin/activate
  ansible-playbook ~/internet-pi/main.yml