Cacheado de paquetes con apt-cacher-ng

Repositorios

O sistema de xestion de paquetes de Ubuntu deriva do sistema usado na distribución Debian. Un paquete .deb contén todos os ficheiros, datos e instruccións para desarrollar unha funcionalidade concreta ou unha aplicación software. Os paquetes normalmente poden atoparse nos repositorios e en función da súa complexidade poden ter dependencias; é dicir, precisan de paquetes adicionais para poder funcionar correctamente. O ficheiro /etc/apt/sources.list contén a listaxe principal de repositorios:

main para software soportado oficialmente por Canonical.
restricted para software soportado pero que non ten unha licenza completamente libre.
universe para software mantido pola comunidade (non ten soporte oficial).
multiverse para software que non é libre.

...
deb http://archive.ubuntu.com/ubuntu/ jammy main restricted
# deb-src http://archive.ubuntu.com/ubuntu/ jammy main restricted
...

Tamén é posible atopar repositorios en calquera ficheiro de extensión .list dentro do directorio /etc/apt/sources.list.d/ e tambén engadir/eliminar repositorios e PPAs (Personal Package Archive) co comando add-apt-repository. No seguinte exemplo, podemos ver o repositorio de ondrej con versión mais actualizadas de PHP para Ubuntu:

$ ls -lhF /etc/apt/sources.list.d/
total 512
-rw-r--r-- 1 root root 140 may 20 18:16 ondrej-ubuntu-php-jammy.list
$ cat /etc/apt/sources.list.d/ondrej-ubuntu-php-jammy.list 
deb https://ppa.launchpadcontent.net/ondrej/php/ubuntu/ jammy main
# deb-src https://ppa.launchpadcontent.net/ondrej/php/ubuntu/ jammy main

Como pode verse nos exemplos anteriores os repositorios están en equipos situados en Internet, e polo tanto para actualizar a listaxe de paquetes dispoñibles nos repositorios, actualizar o sistema ou instalar paquetes, o noso equipo ten que acceder a Internet e proceder a descargar os arquivos correspondentes. Seguramente no desenvolvemento das prácticas na casa ou no IES atopámonos coas seguintes situacións:

• Temos que instalar o mesmo programa en 2, 3, 4, 5, 10, 30, ..., equipos Linux.
• Temos que actualizar 2, 3, 4, 5, 10, 30, ..., equipos Linux e a gran maioría das actualizacións consisten nos mesmos paquetes.

Cando facemos unha práctica na clase con Linux todo o alumnado ten que instalar/actualizar os mesmos paquetes.

Todo depende da conexión a Internet dispoñible, pero é posible que en todas as situacións anteriores a instalación sexa lenta ó saturar a saída a Internet da clase/IES para buscar nos repositorios a mesma información ou polo menos esta forma de traballar non é a máis óptima. Estamos na situación amosada na seguinte figura, onde todos os equipos saen a Internet e van buscar directamente a información ós repositorios:

Sin apt-cacher-ng

Fig. Acceso directo ós repositorios para buscar información/paquetes.

apt-cacher-ng

Aquí é onde entra en xogo apt-cacher-ng e o 'cacheado' de paquetes. A idea de apt-cacher-ng é a de todas as cachés:

• A primeira vez que un equipo pida un paquete, apt-cacher-ng irá ós repositorios correspondentes a buscalo, enviará o paquete ó cliente e ademais gardará unha copia do mesmo no seu disco duro.
• As seguintes veces que se pida ese paquete, apt-cacher-ng proporcionará a copia que gardou, aforrando ter que ir ós repositorios a buscalo e entregándoo á velocidade da rede local.

Con apt-cacher-ng as peticións dos equipos van pola rede interna da organización e únicamente sae ós repositorios de Internet a máquina onde corre o servizo apt-cacher-ng. Estariamos ante a seguinte situación:

Con apt-cacher-ng

Fig. Acceso ós repositorios para buscar información/paquetes usando apt-cacher-ng.

Cando temos que instalar en varios equipos os mesmos paquetes acadamos un aforro bestial de tempo e ancho de banda. A modo de exemplo, hai uns cantos anos a conexión a Internet nun centro proporcionaba uns 6 Megas e cando faciamos a instalación de software algo pesado, como Virtualbox ou Wireshark, a instalación demorábase moito debido á saturación da saída a Internet; sen embargo, configurando os equipos para usar un servidor apt-cacher-ng no centro, a instalación remataba en poucos minutos.

Apt-cacher-ng non está pensado para traballar só con servidores, cachea todo tipo de paquetes incluíndo os que están presentes nas distribucións de escritorio con contorno gráfico. Continuando co exemplo anterior, actualizar os 20 equipos Lubuntu dunha aula de informática de ESO/Bach. cuns 300 MBytes de paquetes a descargar (por cada equipo) sen apt-cacher-ng rozaba o infernal; e con apt-cacher-ng e os paquetes cacheados, o tema solucionase novamente en poucos minutos.

Outra punto a ter en conta é que apt-cacher-ng pode correr nunha máquina virtual sen grandes prestacións; e de feito, así é como estaba no meu antigo centro (máquina virtual Ubuntu 16.04 con 512MB de RAM en Virtualbox), dando servizo a varias aulas de informática e distintas versións de Ubuntu. Eu tamén teño apt-cacher-ng nun contedor no equipo da casa para acelerar algunhas probas para prácticas (p.e. algunhas do estilo das que imos facer neste tema onde creo contedores e automáticamente instalo sofware ou alguhas como as feitas en escenarios tipo os de alta dispoñibilidade).

Escenario Implantación dun sistema de cacheado de paquetes con apt-cacher-ng nunha organización

Este escenario consiste na implantación dun sistema de cacheado de paquetes con apt-cacher-ng nunha organización

Contempla a implantación dun servidor apt-cacher-ng e 5 equipos clientes, escolléndose este número de equipos para amosar como se comporta apt-cacher-ng cando hai varios equipos á vez facendo instalacións.

O escenario pode desenvolverse con menos (ou mais) equipos; por exemplo, un equipo para apt-cacher e un ou dous clientes.

Aproveitamos este escenario para amosar a ferramenta clusterssh que permite administrar múltiples equipos á vez por ssh; de ahí, que o equipo administrador sexa un equipo Ubuntu Linux con contorno gráfico.

Esta ferramenta está ben pero Ansible, que veremos máis adiante, é aínda máis poderosa.

Creación do escenario

A continuación veremos como crear o Escenario 8A:

Explicaremos como crear os servidores asir01, asir02, asir03, asir04 e asir05 e apt-cacher-ng de dúas posibles formas, habendo que escoller unha delas:

• Creación automática: explícase como crear e xestionar o escenario 8A usando contedores a través dun script.
• Creación manual con contedores Incus.

Explicaremos como instalar e configurar clusterssh para administrar á vez a todos os servidores asir01, asir02, asir03, asir04 e asir05.

Creación automática do escenario 8A

Como primeiro paso hai que levar o arquivo escenario_8A.zip ó equipo anfitrión dos contedores. Unha vez alí procedemos a descomprimilo:

$ unzip script_esc_8A.zip
$ cd script_esc_8A/
$ chmod 755 escenario_8A.sh
$ ls -lhF
total 16K
-rw-rw-r-- 1 asir asir  845 may 25  2024 config.yml_server.TEMPLATE
-rwxr-xr-x 1 asir asir 3,0K mar  1 11:30 escenario_8A.sh*
-rw-rw-r-- 1 asir asir  260 mar 27  2024 network_PLANTILLA.yml
-rw-rw-r-- 1 asir asir  190 may 25  2024 profile_WAN

A ter en conta antes de executar o script:

• No arquivo profile_WAN úsase:

• wan como parent
• O nome do storage pool é default --> No caso de usar outro nome, reemprazar default polo teu valor. Pódese ver o nome do pool executando:

incus storage list
+---------+-------------+--------+---------+---------+
| NOMBRE  | DESCRIPCIÓN | DRIVER | SOURCE  | USED BY |
+---------+-------------+--------+---------+---------+
| default |             | zfs    | default | 30      |
+---------+-------------+--------+---------+---------+

Script escenario_8A.sh: Permite crear o escenario, parar, arrincar os contedores e borrar o escenario. É posible modificar as direccións IP a usar no escenario editanto o script e cambiando os valores das variables APT, GW, ... Así podes adaptar a configuración de rede do contedor á túa rede. Por se alguén quere probablo, hai liñas comentadas que permiten traballar coa funcionalidade project de Incus, que permite crear proxectos para ter os contedores e perfís dun proxecto xuntos: Podemos listar todos os projects que temos con: incus project list (sempre aparecerá un default que ven sendo o por defecto, onde se crearán os contedores e perfís agás que indiquemos o contrario). Para poder traballar cos contedores dun project hai que entrar antes nel con incus project switch nome_do_project e unha vez dentro del, xa traballariamos coma sempre. A diferenza vai estar en que só veremos os contedores do project ó facer incus ls e o mesmo cos perfís, serán propios do project (esto pódese configurar doutro xeito para poder usar ós do projectdefault). É moi útil para poder centrarnos nos contedores dun escenario e ter todo organizado. O script crea contedores Ubuntu 22.04 pero pode personalizarse O script fai uso da ferramenta cloud-init a través de config.yml e network.yaml que permite facer as seguintes configuracións nos contedores no primeiro inicio: Actualizar os arquivos /etc/hostname e /etc/hosts co nome do contedor. A modo de exemplo, crea un usuario administrador chamado magasix con contrasinal magasix. No caso de querer cambiar o usuario e contrasinal hai que editar o arquivo config.yml_server.TEMPLATE. Poñer ó usuario por defecto ubuntu o contrasinal abc123. (rematado en punto). Configurar o servidor ssh para permitir autenticación por contrasinal e non facer resolucións dns inversas para acelerar os logins. Configurar a zona horaria. Configurar a rede.

Procedemos a lanzalo:

$ ./escenario_8A.sh
----- Escenario 8A -----
Seleccionar a operación:
1. Crear escenario
2. Parar equipos
3. Arrincar equipos
4. Borrar escenario
------
1
Crear escenario
Network wan created
Perfil WAN creado
------- apt-cacher-ng -------
 
Launching apt-cacher-ng
Launching asir01
Launching asir02
Launching asir03
Launching asir04
Launching asir05
+---------------+---------+-------------------+----------+-----------+----------------------+-----------+--------------+
|     NAME      |  STATE  |       IPV4        | PROFILES | SNAPSHOTS |     LAST USED AT     |   TYPE    | STORAGE POOL |
+---------------+---------+-------------------+----------+-----------+----------------------+-----------+--------------+
| apt-cacher-ng | RUNNING | 192.0.2.20 (eth0) | WAN      | 0         | 2026/03/01 11:38 CET | CONTAINER | default      |
+---------------+---------+-------------------+----------+-----------+----------------------+-----------+--------------+
| asir01        | RUNNING | 192.0.2.21 (eth0) | WAN      | 0         | 2026/03/01 11:38 CET | CONTAINER | default      |
+---------------+---------+-------------------+----------+-----------+----------------------+-----------+--------------+
| asir02        | RUNNING | 192.0.2.22 (eth0) | WAN      | 0         | 2026/03/01 11:38 CET | CONTAINER | default      |
+---------------+---------+-------------------+----------+-----------+----------------------+-----------+--------------+
| asir03        | RUNNING | 192.0.2.23 (eth0) | WAN      | 0         | 2026/03/01 11:38 CET | CONTAINER | default      |
+---------------+---------+-------------------+----------+-----------+----------------------+-----------+--------------+
| asir04        | RUNNING | 192.0.2.24 (eth0) | WAN      | 0         | 2026/03/01 11:38 CET | CONTAINER | default      |
+---------------+---------+-------------------+----------+-----------+----------------------+-----------+--------------+
| asir05        | RUNNING | 192.0.2.25 (eth0) | WAN      | 0         | 2026/03/01 11:38 CET | CONTAINER | default      |
+---------------+---------+-------------------+----------+-----------+----------------------+-----------+--------------+

Coma en escenarios anteriores, a configuración automática dos contedores tarda uns minutos e pode verse se rematou executando o comando cloud-init status:

$ incus exec asir05 -- cloud-init status
status: done

Se queredes probar os projects, durante a execución do script creouse o proxecto APT-CACHER, cambiouse do project default ó proxecto APT-CACHER e dentro del, creáronse o perfil Server e os contedores ós que se lles aplicou a configuración recollida no arquivo config.yml, que foi personalizado para cada un deles. Sobre cloud-init e config.yml afondaremos en próximos apartados do tema.

$ incus project list
+----------------------+--------+----------+-----------------+-----------------+----------+---------------+---------------------+---------+
|         NAME         | IMAGES | PROFILES | STORAGE VOLUMES | STORAGE BUCKETS | NETWORKS | NETWORK ZONES |     DESCRIPTION     | USED BY |
+----------------------+--------+----------+-----------------+-----------------+----------+---------------+---------------------+---------+
| APT-CACHER (current) | NO     | YES      | YES             | YES             | NO       | NO            |                     | 8       |
+----------------------+--------+----------+-----------------+-----------------+----------+---------------+---------------------+---------+
| default              | YES    | YES      | YES             | YES             | YES      | YES           |Default Incus project| 24      |
+----------------------+--------+----------+-----------------+-----------------+----------+---------------+---------------------+---------+

No caso de non estar dentro do proxecto APT-CACHER ou querer cambiar de proxecto simplemente hai que executar:

ncus project switch <Nome-do-proxecto>

O script permite parar e arrincar os contedores así como destruir todo o escenario, borrando contedores, o perfíl Server e o proxecto APT-CACHER.

Creación manual do escenario 8A con contedores LXC

O punto de partida é o equipo anfitrión dos contedores configurado cun bridge wan e un profile que teña unha tarxeta de rede co parent wan (ver apartado Redes en Incus do módulo incus/LXC).

Simplemente hai que crear un contedor aplicándolle o perfil e configurar a rede segundo os requisitos do escenario.

A modo de exemplo creo un server 22.04:

$ incus launch images:ubuntu/22.04/cloud apt-cacher-ng --profile Server
$ incus exec apt-cacher-ng bash
# nano /etc/netplan/50-cloud-init.yaml

    content: |
      network:
        version: 2
        renderer: networkd
        ethernets:
          eth0:
           addresses: [192.0.2.20/24]
           routes:
              - to: default
                via: 192.0.2.1
           nameservers:
              addresses: [8.8.8.8, 8.8.4.4]

Para poder acceder por ssh temos que indicar un contrasinal para o usuario por defecto ubuntu e autorizar o acceso mediante contrasinais en ssh:

#  passwd ubuntu
Enter new UNIX password: 
Retype new UNIX password: 
passwd: password updated successfully
root@apt-cacher-ng:~# nano /etc/ssh/sshd_config
...
PasswordAuthentication yes
...
# service ssh restart
ssh stop/waiting
ssh start/running, process 2787

Hai que repetir estes pasos para os servidores asir01, asir02, asir03, asir04 e asir05.

ClusterSSH

Nunha máquina Linux con contorno gráfico e que se poida comunicar cos servidores (pode ser o anfitrión dos contedores), procedemos a instalar clusterssh:

sudo apt update
sudo apt install clusterssh

Unha vez instalado o programa, podemos crear clusters de equipos editando o arquivo da nosa carpeta de usuario: .clusterssh/clusters. Neste arquivo podemos definir tantos clusters de equipos como precisemos. No caso de non existir a carpeta .clusterssh podemos executar o comando cssh e crearase automáticamente.

No seguinte exemplo pode verse un cluster chamado servers (constituido por dous equipos) e un cluster chamado ASIR formado polos 5 equipos asir da figura, ós que entrarei identificándome como usuario magasix (indicar o que corresponda no voso caso). De usar o script de xeración do escenario podemos usar o usuario magasix con contrasinal magasix ou tamén o usuario ubuntu con contrasinal abc123. (rematada en .). Lánzase clusterssh para crear a carpeta de configuración e asi poder crear o arquivo de clusters:

$ cssh
$ nano ~/.clusterssh/clusters

ASIR magasix@192.0.2.21 magasix@192.0.2.22 magasix@192.0.2.23 magasix@192.0.2.24 magasix@192.0.2.25

Unha vez creado o cluster, acceder a todas as máquinas á vez é tan sinxelo como facer cssh nome_do_cluster

$ cssh ASIR

Abriranse 5 terminais (unha por cada equipo membro do cluster) e un xanela para controlar o cluster. Nas seguintes imaxes vemos como pide aceptar a clave dos equipos ó ser a primeira conexión que se fai a eles e como tras introducir o contrasinal (magasix) terminamos cunha sesión ssh aberta en cada equipo do cluster. Todo o que escribamos na xanela de control do cluster escríbese en todas as terminais do cluster (o que se escribe non se ve na xanela pero si nas terminais):

Conexión por clusterssh ó cluster ASIR

Fig. Conectándose por primeira vez ós equipos do cluster ASIR a través de clusterssh

Conexión por clusterssh ó cluster ASIR

Fig. Liña de comandos nos servidores do cluster ASIR

Por exemplo, podemos comprobar o estado das conexións nos 5 servidores escribindo o comando ss -ltn na xanela de control do cluster:

Conexión por clusterssh ó cluster ASIR

Fig. Executanto ss -ltn en todos os equipos do cluster.

Esta ferramenta permite acceder a varios equipos á vez por ssh e traballar neles; é sinxela e útil, pero existen máis ferramentas se queremos facer cambios na configuración en múltiples equipos como veremos en apartados posteriores do tema.