Han cambiado un tanto las cosas y, encima, tiene peor integración entre estos elementos a pesar de su fama.
Antes de nada comentar que el proceso de ejecución de programas en el arranque y parada de sesión está automatizado: se llama al programa Autostart (Autoarranque en español) y se puede gestionar casi todo:
![](https://esferas.org/msqlu/wp-content/uploads/sites/12/2020/03/imagen-2.png)
Pero como siempre que puedo prefiero comprender qué ocurre, he rebuscado en la documentación de auto arranque -y algún foro más- y he encontrado cosas útiles, sobre todo de aspectos que han cambiado desde mi último uso de KDE allá por la temprana publicación de la versión 4.
En la documentación del proceso de arranque hay un párrafo especial. Si sigues lo que dice está chupado y no hace falta leer más.
To migrate your personal autostart setting from KDE Workspaces 4: Copy desktop files from$HOME/.kde/Autostart
to$HOME/.config/autostart
Copy pre startup script files from$HOME/.kde/Autostart
to$HOME/.config/plasma-workspace/env
Copy shutdown script files from$HOME/.kde/Autostart
to$HOME/.config/plasma-workspace/shutdown
En Debian la documentación es más escasa y me he visto obligado a echarle un vistazo al fuente del programa startkde.
Allí he aprendido lo siguiente:
- KDE busca programas de inicio (y de parada) en dos lugares: uno de usuario y otro de sistema.
- La configuración de usuario se toma de la variable de entorno $XDG_CONFIG_HOME (de la normativa XDG) o emplea $HOME/.config si no existe.
- Para la configuración global o de sistema usa algo parecido. o la variable de entorno $XDG_CONFIG_DIRS o el directorio /etc/xdg directamente.
- Sea cual sea su origen el entorno de escritorio Plasma utiliza el subdirectorio plasma-workspace para sus preferencias.
- Existen como tres fases en las que situar un programa: antes de tener el entorno gráfico, tras levantarlo y antes de pararlo.
- Antes de tener entorno gráfico es el momento de ejecutar programas que alteren el entorno como los citados agentes de usuario del título. ¿ Por qué ? Pues porque el script de arranque es justamente eso, un script, y la forma de ejecutar estos programas es en el mismo contexto; cualquier cambio en las variables de entorno se queda allí para todos los demás programas ya que son hijos suyos.
- En este caso los scripts deben estar en el directorio env (es decir, en $config/plasma-workspace/env) ser legibles (test -r) y tener la extensión .sh.
- Luego, si es necesario hacer algo al cerrar el entorno gráfico, se debe emplear el subdirectorio shutdown ($config/plasma-workspace/shutdown) de la misma forma. Aviso de que no he encontrado nada al final de startkde que valide ésto; se menciona en la documentación pero creo que es cosa ya del entorno gráfico realizar esta tarea.
ssh-agent
No voy a mencionar nada de este tema en profundidad porque ya hay material de sobra en la red. Aquí prefiero dejar sólo los detalles técnicos.
El script que añado al entorno KDE para activar y cargar el agente SSH es el siguiente:
#!/bin/sh
# Antes de lanzar el agente comprobamos que no esté funcionando uno
if [ -n "$SSH_AGENT_PID" ] &&
[ -z $(ps -o pid -h $SSH_AGENT_PID) ]; then
echo "Arrancando instancia de agente SSH ..."
eval $(ssh-agent)
fi
# Añadimos las claves predeterminadas y otras específicas
ssh-add
ssh-add ~/.ssh/empresa
El archivo se sitúa, como he dicho, en ~/.config/plasma-workspace/env/ssh-agent.sh y lo que hace es añadir las claves habituales al agente en la primera invocación de ssh-add y luego una específica para conectar con la empresa en la segunda. Para ésta, además, conviene tener instalado el programa ssh-askpass y así pedirá una contraseña en el entorno gráfico. Hay varias alternativas dependiendo del entorno gráfico y en Debian parece que está cubierto cuando instalas KDE pero por si acaso mejor tenerlo.
Si se necesita añadir una clave y probar la integración con esta herramienta es necesario redirigir la entrada estándar para que la use:
$ ssh-add ~/.ssh/empresa </dev/null
Una de las cosas que me ha sorprendido (no sé si gratamente) es que en Debian Buster (e imagino que quizás antes) el paquete openssh-client ya incluye un servicio definido para systemd. Esto es, que ya se arranca un agente de este tipo cuando se inicia la sesión. De ahí que en el script anterior compruebe si existe para no lanzar uno por mi cuenta. He comprado que los agentes ssh pueden coexistir sin problemas en el sistema en un número absurdo (en pruebas he llegado a contabilizar una docena) por lo que es mejor ir añadiendo claves en lugar de iniciar nada.
Luego está el asunto de las contraseñas y el llavero de KDE kdewallet del que añadiré notas más abajo.
gpg-agent
Bueno, pues ahora el otro agente que me hace falta y para el que existe soporte también en el sistema. De nuevo systemd se ha adelantado y lanza un agente GPG conectado con dbus por lo que según comenzamos la sesión ya está preparado para ello.
Una vez que dicho agente está activo usar gpg para cifrar algo pondrá en marcha la comunicación con dicho agente para que proporcione la clave necesaria. Si no la tiene debe cargarla directamente del anillo personal y solicitar una contraseña para acceder a ella.
Y sí, en este caso no he tenido que hacer nada más. La pide una vez y la conserva hasta que expire el tiempo establecido con los valores default-cache-ttl y max-cache-ttl.
Ah, otra cosa más antes de que se me olvide: gpg-agent incluye un emulador de agente para ssh también. Así que si se instala con la configuración predeterminada se dispone de los dos.
kdewallet
El almacén de contraseñas de KDE. No tiene tanta integración como el de Gnome pero hasta ahora no estoy teniendo demasiados problemas con él.
Si se instala el paquete ksshaskpass basta con emplear ssh-add para que la contraseña de la clave quede registrada en el llavero y pueda ser reutilizada tranquilamente. Hay varias técnicas para desactivar este comportamiento pero creo que no merece la pena si no hay ajustes muy especiales que hacer. Así funciona bien.
![](https://esferas.org/msqlu/wp-content/uploads/sites/12/2020/03/imagen-5.png)
Y aquí me encuentro el problema de siempre con KDE. La información sobre cómo funciona internamente está dispersa y a veces demasiado entremezclada con el desarrollo. Si quieres saber cómo funcionan las aplicaciones para un usuario bien, si necesitas conocer algo más interno vas dado.
Y lo dejo aquí porque llevo ya demasiado tiempo así y ésto ya funciona.
Referencias
Enlaces a artículos, foros y otras fuentes con información relacionada: