El wakeonlan, los cables de red y el sistema sudo

Son ya dos las máquinas que en casa están casi siempre en modo ahorro de energía y cuya finalidad es recibir copias de seguridad. O hacer, según me dé, aunque lo veo más complicado.

En una de ellas a la que he llamado silo haciendo referencia su función principal de almacenar reservas, he descubierto algunas cosas interesantes sobre el funcionamiento de la gestión de energía. La primera es que existen varias maneras para llevar la máquina a este modo de funcionamiento, pero con la llegada tiempo atrás de systemd y su prima la mejor forma es emplearlo: $ sudo systemctl suspend.

También he aprendido que si el cable de red está piojoso o en algún estado similar tras permanecer años en una caja el sistema no funciona. Sí, el modo de ahorro se activa pero luego no es posible despertarlo. Toca cambiar el cable o ir ajustándolo con pequeños vaivenes hasta que recibe la señal WOL. La susodicha señal es un acrónimo para Wake On Lan y consiste en enviar un paquete UDP -especialmente construido- a su interfaz de red empleando la dirección MAC del mismo. Y si el cable está más para allá que para acá pues lo dicho: no va.

Una vez que la máquina está despierta tarda muy poco, uno o dos segundos, en estar disponible para el uso. Esto es importante porque si vas a emplearlo como almacén de datos es necesario asegurarse antes de que está despierto. Se trabaja con él normalmente y al terminar se le vuelve otra vez al sueño. Si no es posible hacerlo durante ese trabajo porque es una conexión directa de datos (por ejemplo con borg) lo mejor es conectar más tarde con SSH y ponerlo a dormir.

Teniendo un usuario para estas operaciones como osr (que es el que siempre uso) basta con añadir una regla para él en el sistema sudo (un archivo de nombre arbitrario en /etc/sudoers.d) y lanzarlo directamente.

# suspend sudoers.d config file
# ------------------------------------
#
# Please consider a look at /etc/sudoers.d/README howto enable this file.
#

# Keep apt-dater's MAINTAINER environment variable
Defaults        env_keep += MAINTAINER

# Allow members of group adm to execute the apt-get command
osr     ALL=NOPASSWD: /usr/bin/systemctl suspend

Como se puede ver se ha limitado mucho lo que es posible llamar. Para que funcione debe hacerse de la siguiente forma:

$ ssh osr@silo sudo /usr/bin/systemctl suspend

Asumiendo, claro, que la conexión vía SSH esté establecida y no necesite contraseña y demás.

¿Y para despertar a la bestia? Pues para eso se pueden emplear varios programas (demasiados tal vez) que le envían la trama a su dirección MAC. Obtengamos primero dicha dirección o no hacemos nada.

Una vez con ella enviamos le paquete para despertarlo de esta forma:

# la dirección es un ejemplo
$ wakonlan c8:1f:66:08:fa:29

Y si el maldito cable está bien, como he dicho, pues funciona. Si no te toca conectar un monitor, darle energía e incluso conectar un teclado para saber qué coño está pasando en la máquina.

Sé listo: comprueba el puto cable.

Ampliando un servidor de impresión

O cómo, cuando sólo tienes una impresora física y mucho tiempo, se te ocurren todo tipo de ideas.

CUPS es uno de los sistemas más chulos con los que he tenido que trabajar. Lo que hay al final, las impresoras físicas, son un maldito asco. Pero la parte intermedia mola un montón. Es un sistema de colas de trabajo que permite que interpongas código y funcionalidad y/ó que cambies por completo su forma de ver los contenidos con los que trabaja.

Primeros pasos con el servidor casero

Ya están añadidos los nuevos discos, reorganizado el contenido de siempre, conectado a la red y con una IP fija. ¿ Y ahora ?

Pues ahora vamos con los primeros pasos para que todos los otros servicios puedan apoyarse en él. Comienzo por instalar el servidor openLDAP y algunos paquetes extra para ayudar en las tareas.

Lo dije tiempo atrás: LDAP sigue sin hacerme gracia, pero en Linux, ahora mismo, es lo más parecido a un directorio global de usuarios. Estuve mirando aplicaciones web ya instaladas en el par de sistemas que mantengo fuera y todas ellas acceden al directorio interno para validar accesos y obtener información simple sobre los usuarios (nombre completo, correo, …).

Una vez que se consigue cambiar la contraseña de acceso de un usuario se aplica a todos los servicios del dominio y no hay más que hacer. Otra cosa es que ese cambio sea sencillo de implementar. Las mejores soluciones que había -que tampoco eran para pegar alaridos de placer- están fuera de Debian por problemas varios o tan atrasadas que no te atreves a instalarlas por si estás debilitando el sistema.

Pero dado que estoy hablando de la red de casa nos ponemos a ello con ilusión y ánimo. Es verdad que existen varios programas-ecosistemas que ya hacen más o menos lo que se pretende. Si opto por este camino no es porque me quiera mal (que tal vez), es que tengo pruebas de que así ha funcionado muy bien y no quiero entregarme a otra suite megachuli de esas porque me entusiasmo demasiado. Al final encuentro las limitaciones que siempre hay en estos programas (como las versiones de pago) o el abandono por otra cosa más brillante por parte de los desarrolladores y me quedo en bragas. Y estoy harto. No pido tanto. Sólo tener validación de credenciales y cuatro datos normalizados más sobre los usuarios y los grupos.

¿ Y cómo se consigue que los usuarios estén centralizados en LDAP ? Pues es más sencillo de lo que parece.

  • Se elige un servidor y se instala en él el directorio LDAP.
  • Se le añade soporte (esquemas) para almacenar cuentas y grupos de usuarios.
  • Se crea una cuenta con capacidad de administración para cambiar contraseñas, crear y borrar usuarios y demás desde otras máquinas.
  • Se aseguran accesos seguros: certificados para conexiones TLS y limitación de accesos inseguros.
  • Se añaden cuentas y grupos según se necesite. Bien empleando una herramienta intermedia (como cpu), bien a pelo con ldapmodify.
  • En los clientes se instalan un par de paquetes que puentean y conectan los servicios de autentificación (PAM) y de consulta de servicios (NSS) apuntando al directorio del servidor.
  • Si el servidor va a emplear también las cuentas de usuario hacer lo mismo que en el paso anterior.

Y, vale, lo admito. No es tan simple como he dicho. Pero se hace una vez. Cuando se pone en marcha, salvo problemas de conectividad con el servidor, un sistema se comporta como un Linux normal.

Eh, no, eso tampoco. Más que nada porque hay que asegurarse de que los identificadores numéricos de las cuentas locales y las cuentas LDAP no se solapen. Debian lo tiene bastante resuelto pero no es difícil, por ejemplo, crear una cuenta local con el mismo nombre que una global. Es divertido cuando lo resuelves. Antes no.

Y como alcanzado este punto estoy casi hiperventilando voy a parar un poco y a seguir pasito a pasito. Queda mucho confinamiento y esto es viejo. Muchos planos y esquemas dibujados desde hace tiempo y hacer que funcione no quiero que me quiebre.