by Mariano Acciardi – 2024/08/09
D) Opciones más usuales de cada comando
B) Manejo de archivos de repositorios
Formato antiguo de los archivos de fuentes
C) Manejo de claves públicas para la firma digital de los paquetes
Problema de seguridad de usar apt-key
Metodología segura para instalar las claves sin usar apt-key
Ejemplo paso a paso usando bajando las claves con el comando gpg
Ejemplo paso a paso usando bajando las claves con wget/curl
D) Buenas prácticas para realizar un upgrade de release mayor (dist-upgrade o full-upgrade)
Problemas con los entornos de escritorio
Instalación/desinstalación de los paquetes de los entornos de escritorio
Opción 2: usando apt para instalar los conjuntos de tareas deseados 15
A) Principales Comandos
Los manejadores de paquetes de diferentes distribuciones tienen la función de permitir, facilitar y administrar la instalación de software o código fuente sobre el sistema. El modo de trabajar con repositorios en línea de debian es uno de los más antiguos en el mundo GNU/Linux y fue el precursor de muchos otros hoy existentes. Las utilidades más utilizadas que componen este ecosistema son:
- dpkg: Es el comando para instalar/desinstalar paquetes que hayan sido bajados previamente o se encuentren disponibles de modo local en el equipo. Al instalar este tipo de paquetes puede suceder que la instalación falle si el sistema no tiene instaladas previamente todas las dependencias necesarias.
- dpkg-reconfigure: permite reconfigurar un paquete instalado previamente, reproduciendo los pasos de configuración de la instalación.
- apt-get: (Advanced Package Tool) es el más antiguo manejador de paquetes en línea dentro de una distribución GNU/Linux. Data de 1998 Aún hoy su comodidad para la instalación/desinstalación segura de paquetes es indiscutible. Por más que sea antigua mantiene exactamente la misma sintaxis de siempre y es la utilidad más estándar para manejar paquetes. Apt-get busca un paquete por nombre en Internet e instala automáticamente todas las dependencias de ese paquete.
- apt-cache: permite buscar información en línea de los paquetes y manejar el cache local de paquetes.
- aptitude: es una evolución propuesta en el año 1999 como alternativa a apt-get. Tiene una sintaxis muy parecida a la original, con sutiles diferencias. Su novedad es que admite una interfase de texto basada en NCurses que permite navegar seleccionando paquetes. A esta interfase se accede simplemente tipeando aptitude en una consola. Al no ser una interfase gráfica estrictamente puede utilizarse sin problemas de modo remoto a través de una terminal ssh.
Ventajas:
-
- Un más evolucionado manejo de dependencias, con búsqueda de resolución de conflictos y sugerencias para superar conflictos de dependencias irresueltos.
- Con cada ejecución de “install” revisa paquetes que hayan sido instalados automáticamente por dependencias y ya no se utilicen, manteniendo así un sistema más limpio en donde solo quedan instalados los paquetes realmente necesarios.
- Introduce algunas funcionalidades de apt-cache en la misma interfase como la búsqueda de paquetes por patrones de caracteres (Ej. aptitude search codium)
- apt: Es la opción más actualizada de manejador de paquetes nativos en línea de que dispone debian. Fue introducida en el año 2014 como una herramienta que combina algunas capacidades de apt-get, apt-cache y aptitude en una sola. Tiene una sintaxis parecida a apt-get. Simplifica la experiencia de usuario mejorando los mensajes sobre las herramientas anteriores y dando información mejor formateada. Muestra además una barra de progreso de la instalación. Para algunas funciones específicas resulta insuficiente y es necesario recurrir a las anteriores, sin embargo dispone de todas las opciones más comunes utilizadas en la administración cotidiana de paquetes.
- apt-key: NO ES CONVENIENTE USAR ESTE COMANDO. Es el comando que históricamente se utilizaba para agregar claves públicas gpg para asegurar la integridad de los repositorios y de los paquetes instalados. El principal problema que trae aparejado es la posibilidad de firma de paquetes cruzada entre repositorios lo que introduce una brecha de seguridad. Ver siguiente apartado
D) Opciones más usuales de cada comando:
dpkg
- dpkg -i xxxx.deb zzzzz.deb (intenta instalar los paquetes xxxx.deb y zzzzz.deb
- dpkg -r <nombre de paquete> (desinstala un paquete instalado previamente pero no remueve sus archivos de configuración)
- dpkg –purge -r <nombre de paquete> (desisnstala el paquete pero además remueve los archivos de configuración del sistema. Importante, no remueve los archivos de configuración de usuario. Es decir solo los archivos de configuración que se hayan instalado en /etc pero no los que se instalen en el home del usuario (ej ~/.config)
dpkg-reconfigure
- dpkg-reconfigure <nombre de paquete> (reconfigura el paquete como si fuera la primera vez que se está instalando. Por ej para cambiar/agregar las locales de idioma del sistema: dpkg-reconfigure locales
apt-get
- apt-get update (actualiza los índices de los repositorios especificados (Ver más abajo). Es conveniente ejecutarlo previamente a toda instalación o al menos en el día en que se están realizando las instalaciones para mantener toda la información de los paquetes existentes en los repositorios en línea para evitar mensajes de “not found”. Es importante destacar que NO actualiza ningún paquete, solo el índice de paquetes online )
- apt-get install <nombre de paquete> <nombre de paquete 2> … (instala el/los paquetes especificados y las dependencias necesarias)
- apt-get remove <nombre de paquete> <nombre de paquete 2> … (desinstala el/los paquetes especificados y sus dependencias sin desinstalar los paquetes de configuración del sistema)
- apt-get purge <nombre de paquete> <nombre de paquete 2> … (desinstala el/los paquetes especificados y sus dependencias. Desinstala los paquetes de configuración del sistema pero no los del home del usuario. (mismo efecto de dpkg –purge -r <nombre de paquete>)
- apt-get upgrade (actualiza todos los paquetes del sistema, dentro de un mismo release (stable, testing o unstable)
- apt-get dist-upgrade (actualiza todos los paquetes del sistema, utiliza un algoritmo de dependencias más liviano y es utilizado unicamente cuando queremos cambiar de release mayor, ej, Debian 11 a 12. Por ejemplo pasar el sistema de bookworm a trixie. Esto puede ocasionar problemas de dependencias, sobre todo en paquetes de los grandes escritorios)
- apt-get -f install (sin especificar ningún paquete intenta buscar las dependencias que paquetes que hayan quedado a medio instalar, las instala y además instala todo los paquetes que quedaron a medias)
- apt-get autoremove (desinstala paquetes que hayan sido instalados automaticamente por dependencias y ya no se utilicen )
aptitude
- aptitude (sin ningun parámetro o comando adicional abre una pantalla Ncurses interactiva para instalar/desinstalar paquetes como si fuera una interface gráfica) .
- aptitude update (actualiza los índices de los repositorios especificados (Ver más abajo). Es conveniente ejecutarlo previamente a toda instalación o al menos en el día en que se están realizando las instalaciones para mantener toda la información de los paquetes existentes en los repositorios en línea para evitar mensajes de “not found”. Es importante destacar que NO actualiza ningún paquete, solo el índice de paquetes online )
- aptitude install <nombre de paquete> <nombre de paquete 2> … (instala el/los paquetes especificados y las dependencias necesarias. Si se le agrega la opcion “-r” toma las recomendaciones como dependencias y también las instala)
- aptitude remove <nombre de paquete> <nombre de paquete 2> … (desinstala el/los paquetes especificados y sus dependencias sin desinstalar los paquetes de configuración del sistema)
- aptitude purge <nombre de paquete> <nombre de paquete 2> … (desinstala el/los paquetes especificados y sus dependencias. Desinstala los paquetes de configuración del sistema pero no los del home del usuario. (mismo efecto de dpkg –purge -r <nombre de paquete>)
- aptitude safe-upgrade (actualiza todos los paquetes del sistema, dentro de un mismo release (stable, testing o unstable) utilizado un algoritmo de dependencias coservador para evitar romper paquetes).
- aptitude full-upgrade (actualiza todos los paquetes del sistema, utiliza un algoritmo de dependencias más liviano y es utilizado unicamente cuando queremos cambiar de release mayor, ej, Debian 11 a 12. Por ejemplo pasar el sistema de bookworm a trixie. Esto puede ocasionar problemas de dependencias, sobre todo en paquetes de los grandes escritorios)
- aptitude -f install (sin especificar ningún paquete intenta buscar las dependencias que paquetes que hayan quedado a medio instalar, las instala y además instala todo los paquetes que quedaron a medias)
apt
- apt update (actualiza los índices de los repositorios especificados (Ver más abajo). Es conveniente ejecutarlo previamente a toda instalación o al menos en el día en que se están realizando las instalaciones para mantener toda la información de los paquetes existentes en los repositorios en línea para evitar mensajes de “not found”. Es importante destacar que NO actualiza ningún paquete, solo el índice de paquetes online )
- apt install <nombre de paquete> <nombre de paquete 2> … (instala el/los paquetes especificados y las dependencias necesarias. Si se le agrega la opcion “-r” toma las recomendaciones como dependencias y también las instala)
- apt remove <nombre de paquete> <nombre de paquete 2> … (desinstala el/los paquetes especificados y sus dependencias sin desinstalar los paquetes de configuración del sistema)
- apt purge <nombre de paquete> <nombre de paquete 2> … (desinstala el/los paquetes especificados y sus dependencias. Desinstala los paquetes de configuración del sistema pero no los del home del usuario. (mismo efecto de dpkg –purge -r <nombre de paquete>)
- apt upgrade (actualiza todos los paquetes del sistema, dentro de un mismo release (stable, testing o unstable) utilizado un algoritmo de dependencias coservador para evitar romper paquetes).
- apt full-upgrade (actualiza todos los paquetes del sistema, utiliza un algoritmo de dependencias más liviano y es utilizado unicamente cuando queremos cambiar de release mayor, ej, Debian 11 a 12. Por ejemplo pasar el sistema de bookworm a trixie. Esto puede ocasionar problemas de dependencias, sobre todo en paquetes de los grandes escritorios)
- apt autoremove (desinstala paquetes que hayan sido instalados automaticamente por dependencias y ya no se utilicen )
B) Manejo de archivos de repositorios
Cualquiera de las aplicaciones “apt” basa su funcionamiento en un índice de paquetes que se guarda localmente y se actualiza cada vez que utilizamos apt… update. Este índice conviene actualizarlo frecuentemente. Si queremos instalar un paquete y recibimos un mensaje “not found” es muy probable que tengamos el índice desactualizado. Eso se soluciona simplemente ejecutando apt-get/apt/aptitude update.
El índice se crea a partir de los archivos de fuentes que se localiza en:
- /etc/apt/sources.list (práctica recomendada, usar este archivo unicamente para los repositorios oficiales de la distribución)
- /etc/apt/sources.list.d/ (archivos en general usados de manera individual para cada repositorio agregado. Los archivos de este directorio pueden ser “.list” para el viejo formato y “.source” para el nuevo formato)
Formato antiguo de los archivos de fuentes:
El formato antiguo utiliza una línea por cada repositorio, con varios campos separados por espacios.
IMPORTANTE:los archivos del viejo formato deben tener extensión .list
Ejemplo 1:
deb http://debian.unnoba.edu.ar/debian/ bookworm main contrib non-free non-free-firmware
deb-src http://debian.unnoba.edu.ar/debian/ bookworm main contrib non-free non-free-firmware
Ejemplo 2:
deb [arch=amd64 signed-by=/usr/share/keyrings/googlechrome.asc] https://dl.google.com/linux/chrome/deb/ stable main
Campos
- Define el tipo de repositorio, deb son paquetes con ejecutables compilados, deb-src indica un repositorio de paquetes fuentes de programas
- [] Entre corchetes se puede especificar como segundo campo que no es obligatorio, la arquitectura de los paquetes mediante arch=… (amd64, i386, arm, etc), y algunas opciones como signed-by=… para especificar la clave pública a utilizar para validar la autenticidad y la integridad de los paquetes.
- URL del repositorio,
- Versión de la distribución, en agosto 2024 la versión estable es bookworm. Podemos utilizar indistintamente bookworm o stable. Las mejores prácticas indican utilizar unicamente los nombres de la versión y no stable/testing/unstable debido a que estas denominaciones hacen referencia a diferentes versiones a lo largo del tiempo, y si colocamos stable, cuando trixie (testing) pase a ser estable vamos a estar actualizando paquetes de bookworm con paquetes de trixie
- Componentes, en debian “main” identifica a los repositorios “core” de la distribución, el mantenimiento lo realiza la comunidad debian. “contrib” son paquetes mantenidos o aportados por colaboradores de la distribución que no necesariamente son los desarrolladores debian, “non-free” incluye paquetes con aplicaciones que tienen alguna restricción de patente (Debe estar desactivado si se tiene una política estricta de licenciamiento de software legal). “ non-free-firmware” se introdujo a partir de bookworm para gestionar un conjunto específico de paquetes que no cumplen con los requisitos estrictos de software libre de Debian, pero que son necesarios para soportar hardware específico. Esto incluye en general drivers propietarios de hardware como nvidia, etc
Los mismos campos pero de una manera más clara se pueden cargar en formato nuevo tal como indica el próximo apartado
Formato nuevo deb822
La última línea del ejemplo anterior correspondiente al repositorio de google para instalar los paquetes de google-chrome puede expresarse en formato nuevo de esta manera
Ejemplo del contenido del archivo:
Types: deb
URI: http://dl.google.com/linux/chrome/deb/
Suites: stable
Components: main
Architectures: amd64
Signed-By: /usr/share/keyrings/googlechrome.asc
IMPORTANTE:los archivos del nuevo formato deben tener extensión .sources
También este archivo admite varios bloques si quiero expresar varios repositorios en un mismo archivo oficialreps.sources
Ejemplo de contenido del archivo con varios repositorios:
# Repositorio principal de Debian Types: deb Uri: http://deb.debian.org/debian/ Suite: bookworm Components: main contrib non-free # Repositorio de seguridad de Debian Types: deb Uri: http://security.debian.org/ Suite: bookworm-security Components: main # Repositorio de actualizaciones Types: deb Uri: http://deb.debian.org/debian/ Suite: bookworm-updates Components: main contrib non-free
En el caso del nuevo formato, el orden en que escribamos los campos no importa siempre y cuando se encuentren en el mismo bloque. El contenido se especifica con “etiquetas” (Type, Uri, Uris, etc) que no son sensibles a mayúsculas y minúsculas pero por convención se las escribe mediante capitalización pascal o de camello para facilitar la lectura humana.
C) Manejo de claves públicas para la firma digital de los paquetes
Los repositorios debian han sido históricamente muy seguros debido a que los paquete son validados en su autenticidad e integridad de la siguiente manera:
1. Autenticidad
- Definición: La autenticidad garantiza que el paquete proviene de una fuente confiable y que no ha sido modificado por un tercero no autorizado.
- Cómo se Logra: Los paquetes en los repositorios Debian se firman digitalmente usando claves GPG (GNU Privacy Guard). La firma es generada con la clave privada del mantenedor del repositorio o del desarrollador del paquete.
- Verificación: Cuando APT descarga un paquete, verifica la firma usando la clave pública correspondiente, que se encuentra en los keyrings de confianza de APT (/usr/share/keyrings/ o trusted.gpg.d/). Esto asegura que el paquete fue firmado por una entidad autorizada.
2. Integridad
- Definición: La integridad asegura que el paquete no ha sido alterado o corrompido desde el momento en que fue firmado hasta el momento en que se descarga e instala.
- Cómo se Logra: La firma digital incluye un hash criptográfico del contenido del paquete. Si el contenido del paquete cambia después de ser firmado, el hash no coincidirá con el hash incluido en la firma.
- Verificación: Al verificar la firma del paquete, APT compara el hash del contenido del paquete con el hash que fue firmado. Si los dos hashes coinciden, se confirma que el paquete no ha sido alterado desde que fue firmado.
Proceso de Firmado y Verificación
- Firmado del Paquete:
- El desarrollador del paquete firma el archivo .deb y sus metadatos con una clave privada.
- La firma se incluye en el paquete como un archivo adicional, típicamente en formato .changes o .dsc.
- Verificación del Paquete:
- Cuando APT descarga el paquete, verifica la firma usando la clave pública.
- APT también verifica el hash del paquete para asegurarse de que no ha sido modificado.
Esto es muy seguro en tanto y en cuanto confiemos en las claves públicas que instalamos en el sistema. Sin embargo hay una posible brecha de seguridad en el manejo de paquetes que posibilita validar paquetes de un repositorio con claves de otro. Esto es así porque históricamente debian no discriminaba las claves según repositorios, con lo cual cualquier clave pública instalada en el sistema puede usarse para validar cualquier paquete de cualquier repositorio.
Obviamente la brecha de seguridad no es demasiado alta si cada vez que hemos instalado una nueva clave pública en nuestro sistema confiamos en de donde proviene. Sin embargo en los últimos años se desarrolló una forma para evitar el problema de la firma cruzada de paquetes. Esta funcionalidad aún no ha sido implementada en la herramienta más usual hasta el momento de instalación de claves para los repositorios “apt-key”, motivo por el cual desaconsejamos completamente el uso de esta aplicación apt-key.
Problema de seguridad de usar apt-key
El comando apt-key sube las claves públicas en algunas de estas dos locaciones:
/etc/apt/trusted.gpg.d/
/etc/apt/trusted.gpg
Cualquier clave pública incluida en estas dos locaciones puede ser utilizada para validar cualquier paquete de cualquier repositorio. Lo que introduce una brecha de seguridad, ya que claves públicas de repositorios de terceros pueden utilizarse para firmar paquetes en cualquier mirror o repositorio, incluso potencialmente en un mirror oficial. Esto permitiría introducir un paquete alterado, firmarlo con una clave de un tercero y que eso sea tomado como un paquete oficial de la distribución.
Metodología segura para instalar las claves sin usar apt-key
Existe una metodología más segura, que básicamente lo que hace es poner las claves públicas en otra locación de manera que no sea tomada por defecto para firmar cualquier paquete, sino que solo pueda ser utilizada para validar paquetes de un repositorio determinado, lo que acota la brecha de seguridad a ese único repositorio.
Son muchas las maneras de realizar esto. Los pasos para realizarlo como siempre en GNU/Linux son variados. Los pasos generales son los siguientes:
- Localizar la clave pública existente en un repositorio oficial o confiable
- Bajar la clave pública, en formato binario o ascii (Con wget o gpg)
- Colocarla en un directorio que NO SEA /etc/apt/trusted.gpg.d . Se puede colocar en el directorio estandar de claves compartidas del sistema /usr/share/keyrings
- Especificar el archivo de fuentes en /etc/apt/sources.d con la opción signed-by=/usr/share/keyrings/miclave.asc
Ejemplo paso a paso usando bajando las claves con el comando gpg:
¿Cuándo nos damos cuenta que nos falta una clave pública? En general esto solo nos pasa con aplicaicones de terceros y no con aplicaciones propias de la distribución. Por ejemplo si quisiésemos instalar Spotify, esta es una aplicación que no es de la distribución, sin embargo tiene paquetes para debian. Estos paquetes están en un repositorio propio de Spotify, con lo cual deberemos agregar la referencia al repositorio de spotify en nuestros archivos de fuentes.
1) Agregar archivo de fuentes en en /etc/apt/sources.list.d con el siguiente contenido:
En formato antiguo (Podemos llamarlo spotify.list)
Ejemplo:
deb http://repository.spotify.com stable non-free
En formato deb822 (Podemos llamarlo spotify.sources):
Types: deb
URIs: http://repository.spotify.com
Suites: stable
Components: non-free
Cuando ejecutamos la actualización del índice encontramos:
aptitude update
Hit http://security.debian.org/debian-security trixie-security InRelease
Hit http://debian.unnoba.edu.ar/debian trixie InRelease
Hit http://debian.unnoba.edu.ar/debian trixie-updates InRelease
Des: 1 http://repository.spotify.com stable InRelease [3.316 B]
Err http://repository.spotify.com stable InRelease
Las firmas siguientes no se pudieron verificar porque su clave pública no está disponible: NO_PUBKEY 6224F9941A8AA6D1
Descargados 3.316 B en 1s (3.608 B/s)
W: Error de GPG: http://repository.spotify.com stable InRelease: Las firmas siguientes no se pudieron verificar porque su clave pública no está disponible: NO_PUBKEY 6224F9941A8AA6D1
E: El repositorio «http://repository.spotify.com stable InRelease» no está firmado.
E: Failed to download some files
W: Se produjo un fallo al descargar http://repository.spotify.com/dists/stable/InRelease:
Las firmas siguientes no se pudieron verificar porque su clave pública no está disponible: NO_PUBKEY 6224F9941A8AA6D1
E: Some index files failed to download. They have been ignored, or old ones used instead.
Se pueden bajar las claves públicas utilizando varios métodos. Se describen solo dos
2) Importar las claves usando gpg
1) Buscar la clave en un repositorio de claves confiable y conocido
Vamos a buscar la clave en primer lugar en un repositorio de claves públicas gpg confiable como el de ubuntu:
gpg --no-default-keyring --keyring /tmp/tempring.gpg --keyserver keyserver.ubuntu.com --recv-key 6224F9941A8AA6D1
Esto nos bajará a un archivo temporal (/tmp/tempring.gpg) la clave correspondiente si es que existe en el repositorio. Podemos ver una descripción, y que fue importada satisfactoriamente en la salida del comando:
gpg: caja de claves '/tmp/tempring.gpg' creada
gpg: clave 6224F9941A8AA6D1: clave pública "Spotify Public Repository Signing Key <tux@spotify.com>" importada
gpg: Cantidad total procesada: 1
gpg: importadas: 1
3) Exportar la clave a un archivo para luego referenciarla desde el archivo de fuentes:
gpg --no-default-keyring --keyring /tmp/tempring.gpg --armor --export 6224F9941A8AA6D1 |tee /usr/share/keyrings/spotify.asc
Esta línea exporta la clave recién importada en el archivo temporario /tmp/tempring.gpg en formato ascii armado (–armor) y mediante un pipe (|) le enviamos al comando tee la salida para que la grabe en el archivo que especificamos /usr/share/keyrings/spotify.asc (Recordemos que el comando tee es prácticamente lo mismo que usar “>” para redireccionar la salida estandar a un archivo, pero tenemos la ventaja que nos muestra por consola lo que mandó al archivo así nos evitamos tener que verificar si el archivo se creo correctamente).
4) Especificación de la firma con que se validará el repositorio
Estos dos simples pasos nos dejó disponible para su utilización un archivo que creamos en el directorio compartido de claves públicas. Ahora le deberemos decir al archivo fuente que esa es la firma mediante la cual están firmados los paquetes del repositorio de Spotify. La ventaja con este método es que la clave pública de desarrollador de Spotify solo será utilizada para validar paquetes de Spotify. Eso lo hacemos modificando los archivos .list o .sources según hayamos elegido utilizar formato viejo o deb822:
a) En formato antiguo (Podemos llamarlo spotify.list)
deb [signed-by=/usr/share/keyrings/spotify.asc] http://repository.spotify.com stable non-free
b) En formato deb822 (Podemos llamarlo spotify.sources):
Types: deb
URIs: http://repository.spotify.com
Suites: stable
Components: non-free
Signed-By: /usr/share/keyrings/spotify.asc
Alternativamente a la última opción b, en el formato deb822 podemos incluir la clave directamente dentro del archivo spotify.sources inmediatamente debajo de “Signed-By” quedando su contenido así:
Types: deb
URIs: http://repository.spotify.com
Suites: stable
Components: non-free
Signed-By:
Types: deb
URIs: http://repository.spotify.com
Suites: stable
Components: non-free
Signed-By:
-----BEGIN PGP PUBLIC KEY BLOCK-----
mQINBGVWABgBEACmyHqClhrPEupgMG5n14x1nKSSbqed9IDu5+m4vKve5gUlGLmg
GqmlKjaIWaxKNsd0NrZ5b4tDE9/o2DLyI95f77zLavfmUqBHun3ksGnQcOTcnHLy
bKuxxCMGOz4uPMdfZuilI9KoT5m/O49fCP23eYMlBiqtQ1zMgwM1dnwcrp8OLYDT
e92AzE8Ghf1PMtkpXwOugMa1HimxSZ4mfoxf7TgkWtpHd3MvehJYXdO4FNE841rI
zn/mSR57M9B22s6TEHFET7sajZsO3adtSZVeadYQAbHEQx+BxpWZ9Rd9ynQXvCbQ
GMSLB6kR7H3rOSQzHENaR2esDJVoMMaV3ny26aQZLi4GtSR58zu6Tlbv9cSnEa19
nXLJNfxB4u2ZlOpkHg1NjXXCcLLdkIUSvdXFEgBpAfUE1LSa+q6geQ/YJk18YRQz
Uq0eL+avBlcze+z/vabvWaHGP3NTelUaksk3BxyRpOupn5xJHOyNZBwB2lEnBEwP
xClJaVzN8seFh9Wq0zQmRFoYR8keVgKsC4KUT8ULHX+/rU8JptnM9X5SSGd1mv8i
nT3BMu3KFdXtZHNYb6i9gvpvK2jRyqrZ3RvBKHXlA8Lk4PzHe8bC5qGmsjpd6Xgb
kZKMoemHZe3vJ5dy5g3JQuzrKaks/wlWR65Vm8nDE/bd1dECqxxVprD74wARAQAB
tDdTcG90aWZ5IFB1YmxpYyBSZXBvc2l0b3J5IFNpZ25pbmcgS2V5IDx0dXhAc3Bv
dGlmeS5jb20+iQJUBBMBCgA+FiEEY8vuyQBmAgiPmxkyYiT5lBqKptEFAmVWABgC
GwMFCQJRQwAFCwkIBwIGFQoJCAsCBBYCAwECHgECF4AACgkQYiT5lBqKptGIsw//
cgeO0BVuOeAXyGdwoQaGnog8fyoNx/VkiX63BYB/J6HSIAnun0F4bImXa7kgScyX
bPjPusTn7y4PEenqWl4Olaos9+B6U3vs1f0RHOCbbxtQUJOtVAFdfsRMWoxCviic
0boW/5bFaDitBtuai8olbpb1YiA94uC+wGRXMWC3QOAwNPu9YWdon6IwJ4AFnEsS
NpU3Vlyqrz4ZEwYm6FhW8cvoBHfOwJo3WQ1nKSXFBMSod58o97Lhr308wvIuev7X
IgGeIZ1+zN39N7BLTaem9ynB8Fk0Mj9WGR+tztuQMcnZeL18rZNkMuzHx7UFY+ir
GgusbpenRPRaqXpUGES2zPwxpUWIMV3fzoI045ktVNDHVqxcQ67DfQX+bgiUPcY5
WaeEBSbpiqhqbqUjLtdTZtqyp1wMNHWxnQ4Bd9M2OipeKLThZ3sorFFZqVLmQ0Qs
CNJ9fgHpCW2LFs4U3fMxyNxbgfTZ0fog5PlEw67bTDloFh6EuFS8gmr6quSaYhor
1IjbJ8iex7lINqNUgZ4PDUYNnciLhYYgmvj8dKq1pZMPkZwTsGjtFnNJtlIE26qN
sbbV1qADvxhOCZ9QjeQfT20FjaUYeBryh4KqRu2kTg8FTYdOXSINlunLgLk3qW5F
IQkRR4+KWNraaGRySYGAGIIWc0Zzd8b6mIfJHcooAlc=
=F5Ek
-----END PGP PUBLIC KEY BLOCK-----
IMPORTANTE: Todo el bloque de la clave pública debe estar indentado al menos con un espacio. Para hacer eso podemos usar las facilidades de manejo de bloques de Vim. 1) [Ctrl][v] nos pone en modo visual de selección de bloque, seleccionamos todo el bloque que comienza en la línea —- BEGIN PGP hasta —-END PGP; 2) presionamos [Shift][i] para insertar en modo bloque; 3) tipeamos un [Space] ;4) presionamos [Esc]
5) Actualizar índice
Si ahora ejecutamos
aptitude update
obtenemos la salida esperada:
Hit http://debian.unnoba.edu.ar/debian trixie InRelease
Hit http://debian.unnoba.edu.ar/debian trixie-updates InRelease
Hit http://security.debian.org/debian-security trixie-security InRelease
Des: 1 http://repository.spotify.com stable InRelease [3.316 B]
Des: 2 http://repository.spotify.com stable/non-free amd64 Packages [1.670 B]
Descargados 4.986 B en 1s (3.585 B/s)
Ejemplo paso a paso usando bajando las claves con wget/curl
Raramente puede ocurrir que necesitemos usar un repositorio que no necesariamente está en un servidor de claves públicas GPG, y necesitamos bajarnos la clave con wget, ponerla en la carpeta /usr/share/keyrings y hacer los mismos pasos 4 y 5 que en el caso anterior usando gpg
1) Localizar con duckduckgo (yo no uso google) la clave
Lo hacemos a través de su huella única que nos tiró el error: 6224F9941A8AA6D1
encontramos un link en donde nos dice cual es la url de la clave:
IMPORTANTE: no nos tentemos de usar la opción “apt-key”, registremos la url de la clave, en este caso:
https://download.spotify.com/debian/pubkey_6224F9941A8AA6D1.gpg
2) Nos bajamos la clave que en este caso es una clave en formato ascii armado
wget https://download.spotify.com/debian/pubkey_6224F9941A8AA6D1.gpg -O /usr/share/keyrings/spotify.asc
Luego de este paso, como ya tenemos la clave en la carpeta de claves públicas compartidas podemos continuar con los pasos 4 y 5 de la opción anterior en que usábamos gpg para bajarnos las claves de un servidor de claves públicas.
IMPORTANTE: Si hacemos esto tenemos que tener mucha confianza en el repositorio que estamos usando
NOTA: Puede suceder que la clave se encuentre en formato binario. En ese caso podemos convertirla a ascii con el comando gpg de la siguiente manera. Las opciones –armor convierten de binario a ascii, –dearmor de ascii a binario:
curl -fsSL https://xxx.xxx.com/pubkey_xxxxxx.gpg | gpg --armor -o /etc/apt/keyrings/xxx.asc
o con wget de la siguiente manera:
wget -qO - https://xxx.xxx.com/pubkey_xxxxxx.gpg | gpg --armor -o /etc/apt/keyrings/xxx.asc
Luego todo lo anterior vale desde los pasos 4 y 5
D) Buenas prácticas para realizar un upgrade de release mayor (dist-upgrade o full-upgrade)
Para evitarnos problemas de dependencias nunca debemos dejar que nuestro sistema de desactualice demasiado. El dinamismo de desarrollo de debian es tan grande, que si estamos usando la distribución de testing (a la fecha trixie) por ejemplo, ya dos meses es una eternidad para las actualizaciones. Si estamos usando la versión stable (a la fecha bookworm) podemos tener un poco más de tiempo porque las actualizaciones son más lentas. Como recomendación es necesario hacer una actualización cada 2 meses en testing, cada 6 meses en stable.
El cambio de distribución o versión mayor, puede generar problemas de dependencia, sobre todo en los paquetes de los entornos gráficos. No es raro tener que desinstalar todo el entorno gráfico y reinstalarlo luego de un cambio de release mayor. La operación parece demasiado drástica, pero en realidad no lo es, porque en linux el desinstalador, aún con la opción “purge” no borra los datos de los usuarios, las configuraciones existentes en /home/fulano . Por ese motivo, luego de la reinstalación el usuario mantendrá todas sus configuraciones ateriores.
Para evitar al máximo posible la ocurrencia de problemas de dependencias, fundamentalmente debemos actualizar frecuentemente y podemos seguir los siguientes pasos:
Paso a paso dist-upgrade
- Actualizar índices SIEMPRE (apt update)
- Actualizar la versión actual con los últimos paquetes existentes (apt upgrade)
- Agregar en los repositorios el repositorio de la siguiente versión (Ej: además de bookworm agregar los repositorios de trixie). Sobre todo si estamos en testing puede ser conveniente dejar los paquetes de la versión estable anterior, ya que a veces ciertos paquetes tardan en pasar de stable a testing.
- Desactivar todos los repositorios externos que se encuentran en /etc/sources.list.d. Para eso se pueden renombrar los archivos a cualquier otra extensión que no sea .sources o .list y simplemente son ignorados por apt.
- Actualizar índices (apt update). Veremos que además del repositorio de la versión que teníamos apt se baja información de los nuevos repositorios agregados. Verificar que no falte ninguna firma. Si estamos usando solo los repositorios oficiales no debería faltar nunca una firma.
- Realizar la actualización de distribución (apt full-upgrade)
- Es posible que aparezcan problemas de dependencia, en esos casos trataremos de eliminar los paquetes problemáticos hasta tanto logremos un upgrade limpio, eliminamos paquetes y luego volvemos a ejecutar apt full-upgrade
- IMPORTANTE: No rebootear si se han producido errores en la instalación de la linux-image o con los archivos de inicialización init-ramfs (update-initramfs). Se deben arreglar los problemas al menos hasta que estos dos paquetes terminen correctamente. De lo contrario podría suceder que la máquina no vuelva a bootear. Como siempre se puede reparar luego pero es más complejo.
Problemas con los entornos de escritorio
Los grandes entornos de escritorio como gnome o kde son un conjunto de aplicaciones, librerías y configuraciones extremadamente complejos. Puede suceder que su complejidad, sobre todo si hacía mucho que no actualizábamos el sistema, impidan completamente el paso al nuevo release. En ese caso la forma más práctica para completar el upgrade es
- Desinstalar todos los entornos gráficos de escritorio
- Realizar un dist-upgrade/full-upgrade limpio, que culmine sin errores.
- Reinstalar los entornos que necesito luego del upgrade limpio.
Para realizar esta tarea que puede ser ardua para identificar a todos los paquetes que corresponden, en debian se pueden utilizar el comando tasksel o instalar los paquetes task-xxx-desktop.
Instalación/desinstalación de los paquetes de los entornos de escritorio
Opción 1: usando tasksel
tasksel
Nos muestra una interfase interactiva donde podemos seleccionar los entornos a instalar/desinstalar como así también algunos conjuntos de paquetes para tareas comunes como ser servidor web, etc.
Esta es la herramienta que utiliza el instalador la primera vez pero se puede usar todas las veces que necesitemos, si deseleccionamos las que tienen * se desistalan, seleccionandolas se instalan.
El único problema que presenta esta utilidad es que no nos muestra fácilmente lo que hace y si llega a fallar es más difícil entender que está pasando. La ventaja es que es de muy sencilla utilización.
Opción 2: usando apt para instalar los conjuntos de tareas deseados
Esta opción nos permite instalar como cualquier otro paquete los entornos de escritorios con solo saber el nombre que podemos buscarlos con:
aptitude search '~n^task-.*-desktop
Esta expresión regular en aptitude search nos traerá los nombres de todas las tareas, incluidas con variantes por idioma. Como siempre en GNU/Linux las aplicaciones son multilenguaje podemos instalar las estándar y luego configurar los idiomas que necesitemos. En este caso las “task” estándar para los principales entornos de escritorio son:
- task-gnome-desktop
- task-kde-desktop
- task-xfce-desktop
- task-lxde-desktop
- task-mate-desktop
- task-cinnamon-desktop
De esta manera nos es muy sencillo desinstalar o instalar el entorno completo, por ejemplo para desinstalar GNOME podemos utilizar:
aptitude remove task-gnome-desktop
o más drástico
aptitude purge task-gnome-desktop
y para volver a instalarlo luego de realizar el dist-upgrade limpio ejecutamos:
aptitude install task-gnome-desktop