Journal Un outil fort pratique : apt-cacher-ng

Posté par  (Mastodon) . Licence CC By‑SA.
Étiquettes :
24
28
déc.
2016

Bonjour,

Vous êtes sûrement l'administrateur de votre réseau local domestique, il y a pas mal de choses sympa à faire qui faciliteront la vie à vos utilisateurs comme à vous même.

Aujourd'hui : la mise en place d'un serveur de cache apt-cacher-ng.

Mais qu'est-ce donc-t-il donc ?

Ce serveur de cache va simplement cacher les paquets apt qui sont téléchargés, pour les resservir à la demande. Ainsi, si un des ordinateurs du réseau local se met à jour, les paquets téléchargés restent dans le cache, et l'ordinateur suivant demandant le même paquet le récupérera depuis le réseau local (1Gb/s chez moi) au lieu de le re-télécharger (450kb/s chez moi).

De plus, depuis la version 0.7.11 me semble-t-il, un seul serveur sait gérer plusieurs distributions, comme des versions différentes de Debian et de Ubuntu.

Installation côté serveur

Rien de plus facile, le paquet est en standard chez Debian et Ubuntu :

apt-get install apt-cacher-ng

Ensuite on peut éditer le fichier de configuration /etc/apt-cacher-ng/acng.conf pour notamment paramétrer l'endroit où les paquets seront stockés (/var/cache par défaut), ou le port du serveur cache (3142 par défaut).

A l'installation une procédure cron assure l'entretien périodique du dépot : les paquets obsolètes (ceux dont une nouvelle version a été téléchargée) sont purgés quotidiennement.

Installation côté client

Il faut indiquer au client d'utiliser ce "proxy" pour les téléchargements. La procédure est la même que le client soit sous Debian ou Ubuntu : dans le fichier /etc/apt/apt.conf.d/70debconf on ajoute simplement la ligne Acquire::http { Proxy "http://<ip du serveur>:<port>"; };

… et c'est tout !

Exemple concret

Je l'ai mis en place hier donc. Mes 2 enfants ont chacun un ordi avec Ubuntu 14.04 LTS . Je ne fais quasiment jamais de mise à jour (et c'est pas bien !), disons que la dernière date de plusieurs mois. Je lance la mise à jour chez ma fille : environ 1Go, 1h. Puis je lance la mise à jour chez mon fils : environ 1Go, une bonne 20aine de secondes :)

Conclusion

Quand on a de l'espace de stockage disponible 24/7 sur le réseau local (NAS sous Debian dans mon cas), c'est un confort de plus, non négligeable dès que les versions de Ubuntu ou de Debian s'accumulent à la maison (ordis de bureau, ordis portables, RPi… je dois en avoir une dizaine en tout, tous sous packages apt). Évidemment, c'est avec une connexion Internet limitée en débit qu'on en profitera le plus.

Je n'ai pas regardé si l'équivalent existe chez les autres distributions (Fedora, Arch…) et je laisse les commentaires pointer vers l'outil adéquat.

Quelques liens qui m'ont aidé :
- https://wiki.debian-fr.xyz/Apt-cacher-ng
- https://doc.ubuntu-fr.org/apt-cacher

  • # Pour Gentoo: http-replicator

    Posté par  . Évalué à 2.

    Sous Gentoo, la commande emerge doit télécharger les sources des logiciels.
    Le logiciel http-replicator peut faire office de cache.

    C'est très simple et très léger.

    Pour le(s) client(s), il suffit d'ajouter une ligne dans le fichier make.conf:

    http_proxy="http://<ip ou fqdn du serveur>:<port>"

    La seule limitation: ne fonctionne uniquement qu'en http et pas en ftp.

  • # et pour les fans de docker

    Posté par  (site web personnel) . Évalué à -1.

    https://docs.docker.com/engine/examples/apt-cacher-ng/

    ウィズコロナ

    • [^] # Re: et pour les fans de docker

      Posté par  . Évalué à 6.

      Tu sorts l'artillerie Docker alors que le paquet/service apt-cacher-ng s'installe tranquilou via APT???

      • [^] # Re: et pour les fans de docker

        Posté par  . Évalué à 4.

        Tu sorts l'artillerie Docker[…]

        L'« artillerie » peut déjà être sortie (si tu as déjà des services géré par docker par exemple), tu peut t'en servir sur une autres distribution par exemple,…

        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

  • # prise en charge de apt-transport-tor

    Posté par  . Évalué à 3.

    Lors de mes derniers essais, il ne prenait pas en charge les transports autre que http.
    Est ce toujours le cas ?

  • # HTTPS

    Posté par  (site web personnel, Mastodon) . Évalué à 6.

    À noter que, avec la conf par défaut, apt-cacher-ng ne gère pas du tout les dépôts servis uniquement via HTTPS.

    Dans ce cas, la solution la plus simple est d'indiquer dans la conf l'URL dont il ne faut pas cacher les paquets (option PassThroughPattern).

    Si on veut absolument cacher les paquets servis via HTTPS, il fait aller un peu plus loin dans la conf. Voir cette doc par exemple : https://blog.packagecloud.io/eng/2015/05/05/using-apt-cacher-ng-with-ssl-tls/

  • # Et en nomade ?

    Posté par  (site web personnel) . Évalué à 8.

    Comment gères tu le proxy sur un ordinateur portable qui peut rester longtemps loin du NAS ?

    Pour ma part j'ai un script /etc/NetworkManager/dispatcher.d/99SetAptProxy avec le contenu suivant :

    #!/bin/sh

SERVER=<hostname du nas>
PORT=3142
PROXY_FILE="/etc/apt/apt.conf.d/99Proxy"

if nc -w 1 $SERVER $PORT
then
    printf 'Acquire::http::proxy "http://%s:%s";' $SERVER $PORT \
        > $PROXY_FILE
else
    rm -f $PROXY_FILE
fi

    En gros ça teste si le NAS est dispo, auquel cas ça active le proxy, sinon ça le désactive.

    • [^] # Re: Et en nomade ?

      Posté par  (Mastodon) . Évalué à 3.

      Ah merde !

      Judicieuse remarque… ayant essayé uniquement depuis hier, j'ai pas encore eu ce cas. Es-tu sûr déjà que ça ne marche pas quand le proxy n'est pas dispo ? C'est vraiment une erreur fatale ou "juste" un timeout ?

      En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

      • [^] # Re: Et en nomade ?

        Posté par  . Évalué à 4.

        erreur fatale ou "juste" un timeout ?

        De base il me semble que si apt est configuré pour utiliser un proxy il ne va pas de lui même passer en direct vers internet si le proxy est inaccessible.

        Donc tu n’aurais pas une erreur "fatale" (mais un code retour différent de 0 quand même), et ça ne fera pas les mises à jour.

        D’où son script qui change dynamiquement la configuration de apt selon la disponibilité du proxy.

        Peut-être que apt a déjà une option pour reproduire ce comportement, je n’en sais rien.

    • [^] # Re: Et en nomade ?

      Posté par  (site web personnel) . Évalué à 8.

      Salute,

      J'ai expliqué ma façon de faire dans un article.

      Tcho !

  • # Archlinux

    Posté par  (site web personnel) . Évalué à 4.

    Un équivalent est pacserve. J'avais profité de ce cahier des charges minimes pour en faire une version en Go, paclan (non maintenu car non utilisé)

  • # squid-deb-proxy

    Posté par  (site web personnel) . Évalué à 6.

    Après avoir essayé ainsi que d'autres comme approx, je suis allé du côté de squid-deb-proxy que je trouve supérieur : basé sur squid donc gestion plus complète et robuste du HTTP, par exemple le keep-alive qui accélére beaucoup apt, intégration avahi pour découverte automatique et gestion de cas nomade.

  • # Excellent

    Posté par  . Évalué à 1.

    C'est génial ce truc !
    Merci pour la découverte =)

  • # Proxy transparent ?

    Posté par  . Évalué à 2.

    Personne n'a essayé de faire des règles iptables pour avoir un proxy transparent ? Ce qui est intéressant, c'est que le client n'ait rien du tout à configurer, au prix d'une configuration plus importante sur le serveur / routeur.

  • # Question de béotien: l'intérêt face à un miroir ?

    Posté par  . Évalué à 3.

    Désolé de ma question de débutant, mais n'est-il pas plus simple d'installer directement au sein de son réseau local un miroir de la distribution utilisée??

    Le miroir se met à jour et télécharge les paquets nécessaires et les ordinateurs personnels téléchargent vers le miroir les paquets qu'ils ont besoin.
    Comme le miroir est le proche de chez eux, il n'y a pas besoin de configurer les ordinateurs personnels et quand on quitte le réseau local, les ordinateurs personnels téléchargeront à partir un d'un autre miroir plus proche de chez eux.

    • [^] # Re: Question de béotien: l'intérêt face à un miroir ?

      Posté par  (Mastodon) . Évalué à 7. Dernière modification le 30 décembre 2016 à 09:37.

      C'est différent, même si on parle de quelque chose de comparable en effet.

      Inconvénient du miroir : il va répliquer l'intégralité des repos Debian, y compris ce dont on ne se servira jamais (espace de stockage sans commune mesure avec un cache !)
      Avantage du miroir : il va répliquer en avance (par exemple) la nuit, et donc tout est disponible "instantanément" quand on en a besoin.

      Par contre, je pense qu'il faut bien mettre dans ton sources.list l'adresse de ton miroir.

      En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

    • [^] # Re: Question de béotien: l'intérêt face à un miroir ?

      Posté par  . Évalué à 8.

      Ça marche bien si tu as la même distribution pour tout. Si tu as un raspbian, une debian stable et une ubuntu ça va te demander beaucoup de place pour rien.

      Au niveau de la consommation de la bande passante de ton réseau, c'est pas sur que tu y gagne.

      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

    • [^] # Et face à apt-p2p??

      Posté par  . Évalué à 2.

      Merci de vos réponses.

      Et face à apt-p2p ?? (Toujours dans le but d'éviter une configuration à faire sur le poste client)

      Sauf erreur, un paquet est télécharger par un des ordinateurs, grâce au p2p, ce paquet sera alors disponible aux autres qui ne téléchargeront plus sur le miroir.

  • # Sous Mageia

    Posté par  . Évalué à 3.

    Sous Mageia, c'est urpmi-proxy.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.