Linux

A vueltas con los discos duros

A vueltas con los discos duros

Ampliar partición de sistema

Al instalar según que versión de Ubuntu (me consta que pasa con varias de ellas) puede ocurrir que, al dejar los ajustes por defecto para el particionado que proporciona el asistente de instalación, nos encontremos con que la partición de sistema no está utilizando la totalidad del disco duro. La última vez que me ocurrió tal cosa fue con una de las versiones de la distribución LTS 20.04, dejándome reducido un disco de 250Gb a la mitad, pero sé de gente que le ha ocurrido encontrarse con particiones de sistema ridículamente pequeñas en algunas versiones de la distribución 18.

Sea como fuere, es muy probable que deseemos aumentar el tamaño de nuestra partición al máximo disponible. Afortunadamente, el sistema LVM hace que esta tarea resulte sencilla, pudiéndose hacer al vuelo y sin siquiera tener que reiniciar la máquina.

Empezamos por redimensionar el volumen lógico para usar la totalidad del grupo, que coincidirá con el tamaño del disco. Esto se puede hacer de dos maneras. O entramos en la consola de LVM…

sudo lvm
lvm> lvextend -l +100%FREE /dev/ubuntu-vg/ubuntu-lv
lvm> exit

…0 bien tecleamos el comando directamente, que viene a ser lo mismo:

sudo lvm lvextend -l +100%FREE /dev/ubuntu-vg/ubuntu-lv

A continuación, redimensionamos la partición para que ocupe todo el volumen disponible:

sudo resize2fs /dev/ubuntu-vg/ubuntu-lv
resize2fs 1.45.5 (07-Jan-2020)
Filesystem at /dev/ubuntu-vg/ubuntu-lv is mounted on /; on-line resizing required
old_desc_blocks = 15, new_desc_blocks = 29
The filesystem on /dev/ubuntu-vg/ubuntu-lv is now 60655616 (4k) blocks long.

Y… ya está! Ya podemos comprobar el nuevo tamaño de nuestras particiones con

df -h

Comprobación de discos al inicio

Hay una herramienta que resulta muy útil para este propósito: tune2fs. Lo primero que podemos hacer es obtener información de los parámetros actualmente configurados. Para ello lo ejecutamos con la opción -l (list):

tune2fs -l /dev/sda1

Si sabemos con exactitud lo que estamos buscando podemos combinar la salida anterior con grep. En cualquier caso, los parámetros que nos ocupan ahora son Mount count y Maximum mount count. el primer nos proporciona la cuenta de las veces que el disco se ha montado desde la última comprobación, y el segundo el conteo máximo para el cual tendrá lugar la comprobación de discos.

Publicado por David en Herramientas, Linux, 0 comentarios
Acceso remoto mediante SSH. Generalidades

Acceso remoto mediante SSH. Generalidades

En ocasiones, si hemos cambiado el nombre o la dirección IP de la máquina a la que deseamos acceder, puede que al conectarnos nos aparezca el siguiente mensaje de aviso:

Warning: the ECDSA host key for 'pioneer' differs from the key for the IP address '192.168.1.x'
Offending key for IP in /home/david/.ssh/known_hosts:<n>
Are you sure you want to continue connecting (yes/no)?

Donde <n> es un número entero.

Se trata de un aviso estándar de seguridad que nos advierte de una posible brecha de seguridad. Obviamente, si estoy funcionando en mi red privada y soy consciente de que he estado haciendo cambios, este mensaje puede ignorarse con total tranquilidad. No obstante, si queremos deshacernos del mismo, hay dos maneras muy simples.

  1. Las máquinas a las cuales nos hemos conectado se guardan en el archivo mostrado en la ruta del mensaje (known_hosts). Si abrimos este archivo veremos que el formato no es muy amigable, pero tiene la ventaja de que cada host se guarda en una línea de archivo. Así que bastará con borrar la línea número <n> y ya estará.
  2. Lo anterior es sencillo si en dicho archivo tenemos una lista de tres o cuatro máquinas. Pero ¿qué pasa si, como me acaba de ocurrir, resulta que n = 61? Bien, siempre podemos editar el archivo de manera que nos muestre los números de línea, lo cual facilita mucho las cosas:
    nano ~/.ssh/known_host -l
  3. Y si no, siempre podemos usar el siguiente comando, que es de lo más molón:
    sed -i '61d' ~/.ssh/known_hosts
Publicado por David en Linux, SSH, 0 comentarios

Iniciar un servicio mediante systemd

En este caso se trata de una Raspberry Pi que controla unos paneles de leds que muestran, además de la fecha y la hora, algunos mensajes de información provenientes del controlador domótico mediante el protocolo MQTT, tales como la temperatura de distintas estancias, o la música que se está reproduciendo en ese momento (Y sí, os habéis fijado bien. La fecha viene en Esperanto. Qué le vamos a hacer…). El dispositivo cuenta además con un sensor de luz, el cual le permite, además de regular la luminosidad de los leds en función de la luz ambiente, proporcionar al sistema información sobre el nivel de luminosidad real de la estancia, permitiendo un control preciso de persianas y luces regulables.

Aspecto del reloj con matriz de leds en la parte superior de la librería de mi dormitorio, junto a algunos libros y colecciones de pelis en viejos archivadores de CD’s. Todo un compendio de mis pequeñas pasiones 😉

Para que el dispositivo funcione de manera autónoma, el programa deberá arrancar automáticamente cuando se encienda la placa, lo cual se puede lograr de varias maneras. Una de ellos, seguramente la más conocida, consiste en añadir la ruta al ejecutable en el archivo /etc/rc.local, aunque también es posible iniciar tareas utilizando el servicio crontab. En ambos casos tenemos un pequeño problema, y es que si el programa se cuelga o experimenta una salida inesperada debida a cualquier excepción no convenientemente capturada, todo el dispositivo se detiene dejando de funcionar.

Para salir al paso, una solución consiste en ejecutar el programa como un servicio. En el  caso que nos ocupa vamos a utilizar el sistema systemd, el cual presenta, entre otras, la gran ventaja de que si se produce un error y el progama se detiene, él mismo se reinicia automáticamente. Algo que a los manazas que vamos dejando rastros de programas mal depurados nos viene que ni de perlas. También es un sistema bastante robusto y que nos permite ajustar las condiciones adecuadas para la ejecución del probrama.

Lo primero que necesitamos es un archivo de script que contenga las instrucciones de inicio de nuestro programa. Si fuera necesario pasar parámetros para el inicio este archivo sería un lugar adecuado para especificarlos. En nuestro caso, es una simple llamada a la ejecución de un script Python:

nano /home/pi/mqtt-matrix/start.sh

#!/bin/bash
#
python3 /home/pi/mqtt-matrix/mqtt-matrix.py

Lo siguiente será la creación del archivo de unidad de servicio. Éste contendrá el nombre con el que queremos que systemd reconozca a nuestro servicio. Aunque sería improbable, no está de más comprobar que no vamos a darle un nombre que ya se encuentra en uso. Para ello, basta con echar un vistazo al contenido de la carpeta que suele contener los archivos de unidad de servicio:

cd /etc/systemd/system/
ls

También podemos probar este comando más específico y que resulta de lo más molón:

sudo systemctl list-unit-files --type=service

En mi caso, como el programa que pretendo ejecutar está en el archivo mqtt-matrix.py, he decicido que el servicio se llame mqtt-matrix.service y listos. Así que creamos el archivo en cuestión:

sudo nano /etc/systemd/system/mqtt-matrix.service

[Unit]
Description=mqtt-matrix
Wants=network.target
After=syslog.target network-online.target

[Service]
Type=simple
ExecStart=/home/pi/mqtt-matrix/start.sh
Restart=on-failure
RestartSec=10
KillMode=process

[Install]
WantedBy=multi-user.target

El archivo que hemos creado contiene las opciones más comunes, la mayoría de las cuales resultan bastante autoexplicativas. Además, podríamos especificar el usuario y el grupo bajo el cual se va a ejecutar nuestro servicio. Si no se especifica nada, por defecto se ejecutará con permisos de administrador, que es exactamente lo que deseamos, por ser uno de los requisitos del modo en el que accedemos a los pines de nuestra raspberry, así que lo dejamos tal cual.

Y ya está. A continuación enumeramos varios de los comandos más utilizados para manejar los servicios systemd

Recargar los archivos de servicio después de alguna modificación

sudo systemctl daemon-reload

Iniciar el servicio

sudo systemctl start mqtt-matrix.service

Detener el servicio

sudo systemctl stop mqtt-matrix.service

Reiniciar el servicio

sudo systemctl restart mqtt-matrix.service

Comprobar el estado del servicio

Además, nos proporciona información adicional, tal como:

  • Avisarnos si tenemos errores en la sintaxis del archivo, aunque el servicio no esté en ejecución
  • Indicarnos la ruta del ejecutable
  • Indicarnos la ubicación del archivo de servicio si no está donde esperábamos
sudo systemctl status mqtt-matrix.service

Y, lo más importante, teniendo en cuenta de qué va todo esto, indicarle al sistema que queremos que el servicio arranque automáticamente al inicio

sudo systemctl enable mqtt-matrix.service

O bien, deshabilitar el arranque al inicio

sudo systemctl disable mqtt-matrix.service
Publicado por David en Domótica, Linux, 0 comentarios
Funciones útiles con el Subsistema Linux en Windows 10 (WSL)

Funciones útiles con el Subsistema Linux en Windows 10 (WSL)

  • Acceder a una memoria USB desde WSL

En la estructura de archivos del subsistema de Linux vienen por defecto varios directorios con las típicas letras de unidad de disco de windows. En efecto, si miramos el contenido de la carpeta de montaje:

ls /mnt

c d e f

Sin embargo, cuando entramos en el directorio correspondiente a la letra de unidad donde tenemos insertada la memoria, resulta que está vacío. Al parecer, las unidades externas no se montan automáticamente, sino que hay que hacerlo explícitamente mediante el comando mount . En el siguiente ejemplo, vemos los parámetros con los que ejecutar este comando cuando montamos la unidad presente en E:

sudo mount -t drvfs E: /mnt/e

Y para desmontar, exactamente igual que en Linux…

sudo sudo umount /mnt/e
  • Acceder a los archivos del espacio WSL desde Windows

El espacio de archivos utilizado por WSL está disponible directamente desde el explorador de Windows 10 introduciendo esta ruta en la barra de direcciones del explorador de archivos: \\wsl$\Ubuntu

Nota: Si nos fijamos en la notación, veremos que Windows 10 maneja esta ruta como un sitio de red. Para que la ubicación de red esté montada, será necesario que en ese momento se esté ejecutando la sesión correspondiente en el WSL

Publicado por David en Blog, Linux, 0 comentarios
Acceso remoto SSH con clave pública y Google 2FA

Acceso remoto SSH con clave pública y Google 2FA

Las dos maneras más populares de asegurar una conexión SSH son el acceso mediante clave pública y la autenticación en dos pasos (2FA). La primera es la que más tradición tiene y la que llevo años utilizando en mis máquinas domésticas. La segunda es algo más reciente y nunca la había utilizado antes, así que me apeteció probarla para aumentar la seguridad. Hay decenas de tutoriales que explican el procedimiento, bastante sencillo, por cierto. Pero como el objeto de este blog es facilitarme las cosas a mí mismo y evitarme el ponerme a rebuscar, aquí dejo el enlace a la guía oficial de Ubuntu sobre el tema: Configure SSH to use 2FA

La verdad es que el acceso mediante 2FA es una chulada. Metes la contraseña y te pide un código del Google Authenticator. Sin embargo, una vez disipada la ilusión inicial pensé que no estaría de más sustituir el paso de introducir la contraseña por una autenticación mediante clave pública. Mucho más cómodo y, sobre todo, mucho más seguro. Así que configuré un par de claves RSA para entrar al servidor (proceso que aunque he realizado decenas de veces siempre se me olvida, así que también lo he dejado descrito por aquí).

La sorpresa vino cuando intenté la conexión. El hecho de haber configurado el acceso mediante clave hizo que la entrada al servidor fuera inmediata, sin solicitar el código de validación. Investigando un poco me entero de que, al parecer, el acceso mediante clave anula por defecto cualquier otro método de autenticación. Toda la configuración para el Google 2FA a hacer puñetas. Menudo chasco!

Así que vuelta a investigar la manera de poder mantener ambos modos de autenticación aunque, eso sí, sin necesidad de introducir la contraseña. De momento dos factores ya me parecen suficientes. Mejor dejar la autenticación multifactor (MFA) para más adelante.

Partimos de la configuración previa del archivo del servidor SSH, que coloco aquí mientras le busco un sitio mejor

sudo nano /etc/ssh/sshd_config
PasswordAuthentication no
ChallengeResponseAuthentication yes
PermitRootLogin prohibit-password

La cuestión es que si deseamos mantener ambos métodos de autenticación, de manera que ya no nos pida la contraseña (gracias a la clave RSA) pero nos continúe pidiendo el código de verificación, deberemos indicárselo explícitamente. Para ello, añadiremos una línea especificando dos posibles vías de autorización: O proporcionamos una clave pública y una contraseña, o bien una clave pública y un código de verificación.Las dos posibilidades están descritas en forma de dos listas de métodos. Las listas están separadas por un espacio. Y en cada lista, los métodos requeridos están separados por comas. Si los requisitos de una lista no se dan, entonces se pasa a la siguiente.
Como la configuración de este parámetro parece algo liosa, dejo aquí este enlace en el que lo explican todo muy bien y de manera muy detallada.

AuthenticationMethods publickey,password publickey,keyboard-interactive

Luego debemos modificar el archivo de configuración de PAM para que no nos pida la contraseña

sudo nano /etc/pam.d/sshd

Y comentamos la siguiente línea

#@include common-auth

Y ya está. Si os estáis preguntando por qué es necesario decirle a PAM que no pida contraseña en lugar de quitarla directamente de la lista de los métodos de autorización, os diré que yo me pregunto lo mismo. Lo único que sé es que hice la prueba y no funcionó, pero con el método descrito va como la seda.

Publicado por David en Blog, Seguridad, SSH, 0 comentarios