Hello
Je souhaiterai savoir si quelqu'un parmi vous a déjà répondu à ce "besoin" et par quelle méthode. C'est un projet qui n'en est qu'à la phase théorique pour le moment.
Ça va être un peu long, merci d'avance pour ceux qui auront le temps de lire jusqu'au bout ;)
Je fais partie d'un GULL et nous organisons régulièrement des install party dans un local associatif loué. Ce local malheureusement est mal desservi au niveau internet et même au niveau routeur (la box du FAI est ancienne et assez peu efficace, elle ne supporte pas plus de 10 postes sur le LAN avant de ne plus répondre aux requêtes DNS)
Le débit étant aussi assez rapidement limitant, il nous faut trouver des solutions:
- Faire changer le FAI (ou la box) et refaire le réseau du local gérer par l'autre association est impossible, ils sont bornés.
- Installer un routeur supplémentaire pour le gérer nous même: c'est la solution que nous retenons pour le problème de DNS/DHCP
- Consommer moins de bande passante en rapatriant en local ce qui est le plus gourmand: les mises à jour et installations de distributions. (Faire cela par les CD/DVD n'est pas gérable ni amusant techniquement)
Voilà la partie technique:
Nous allons donc installer une machine qui fera routeur, relais DNS et serveur DHCP. Ainsi que miroir local avec un ou plusieurs très gros disques durs
Pour cela, nous lui ferons télécharger une copie des miroirs publics sur une connexion correcte (au boulot sur la fibre pour la première et à la maison pour les update-'delta')
Ce sera fait par rsync puisque c'est le protocole commun sur les serveurs des 3 distributions que nous installons: Debian Ubuntu Mageia (et en fait, les autres aussi, Fedora, etc ..)
Reste la "distribution" à proprement parler: les serveurs miroirs aujourd'hui sont des serveurs Web souvent, parfois FTP.
Le gros du problème vient du fait qu'il faudrait ne pas avoir besoin de changer la configuration des postes installés à chaque fois (les mettre puis remettre d'origine à la fin de la journée, avec le risque d'oublier), nous cherchons une solution qui se comporterait comme un proxy transparent. Vu que nous aurions la maîtrise totale du nouveau routeur cela semble faisable.
Malheureusement je n'ai rien trouvé qui aille dans ce sens: quand on cherche proxy transparent, miroirs distribution (en anglais aussi) il n'y a que des articles de proxy cache web (squid) qui sortent.
Si une machine télécharge des paquets seront-ils copiés localement par un proxy web transparent ? J'en doute
La solution avec apt-cache-ng ne conviendrait pas parfaitement parce qu'elle n'est dispo que sur les Debian-like (je n'ai vu aucun équivalent sur les Fedora-like), qu'elle nécessite également de modifier les repos sur chaque machine locale (pas de solution failover si le repo n'est pas disponible), et qu'elle oblige aussi à ce que le serveur de téléchargement soit le même partout sinon le cache n'est pas utilisé et tout sera re-téléchargé.
Il y aurait peut-être quelque chose à faire avec un serveur PXE ou une installation avec un fichier réponses (qui ne répondrait qu'aux questions sur le choix du dépôt) mais ça ne résout pas totalement le problème en fait.
Merci !
# Un script ou un script ?
Posté par Elytsie . Évalué à 1.
Yop,
J'ai déjà rencontré la même problématique mais sur CentOS + RedHat uniquement. J'ai trouvé un moyen de mettre en place un miroir "autogéré" par l’intermédiaire de deux outils :
Reposync
Reposync te permet de télécharger tout un repo via YUM, c'est très rapide tu n'as vraiment que les paquets, YUM se base toujours sur les Repodata donc tu as un avancement et tu sais où il en est.
Createrepo (man)
Createrepo te permettra de créer les fichiers Repodata localement en fonction des paquets présent sur ton serveur.
Évidemment il faut passer par un ou des scripts pour piloter le tout. Quelques astuces pour faire du multi-distro d'un seul coup.
$releaseveret$basearchen variable dans ton script, ça te permettra de piloter l'architecture et la version de la distro.L'avantage ici est que profite toujours des mirrorlist, tous les dépôts ont les mêmes URL.
Actuellement j'ai un seul script qui tourne (la nuit) et qui synchronise CentOS 5,6 (32 & 64 bits) et CentOS 7. YUM est utilisé pour RedHat (si tu as une licence) et Fedora je pense qu'il est assez simple d'ajouter ces repos.
A partir de la tu peux monter un kickstart facilement.
[^] # Re: Un script ou un script ?
Posté par Epy . Évalué à 2.
Merci pour les infos
Ce que tu sembles dire c'est qu'il faudrait que la machine hôte tourne sur la distribution dont j'ai besoin et il m'en faut plusieurs, parce qu'il faudrait utiliser Yum pour Fedora (et peut-être mageia ?), mais j'ai aussi besoin des dépots Ubuntu, donc apt parce que Yum ne les gèrera pas et vice-versa.
C'est pour ça que je voulais plutôt un script avec plusieurs rsync (un par distribution), ça serait "agnostique" de cette façon.
Le principal souci c'est pour distribuer ces repo
# dns menteur
Posté par jigso . Évalué à 3.
Une solution qui évite de toucher à la config des machines est de gruger au niveau du dns, et renvoyer l'adresse ip du serveur pour toutes les demandes de résolutions vers les miroirs des distribs. Ça nécessite peut-être de ne cibler qu'un sous-ensemble des miroirs, ceux en france par ex, pour simplifier l'administration. Du coup plus besoin de proxy, cache, etc.
[^] # Re: dns menteur
Posté par Epy . Évalué à 2.
J'ai réfléchi à ça mais ça ressemble à du man-in-the-middle non ? Je crains que les signatures ne soient pas acceptées en détournant le trafic sur un autre serveur.. (ça prouverait une grosse faiblesse dans le système des repo Linux)
On peut effectivement se limiter aux serveurs français, mais ça fait quand même une sacrée liste à tenir à jour.
(Liste dont je vais avoir besoin pour les mises à jour du repo local en fait..)
Plus j'y pense et je l'explique pour avoir des pistes, plus je me dis que c'est infaisable proprement.
Probablement que nous devrions faire des scripts, un par distribution, qui copierait le fichier de sources d'origine et en mettrait un autre à la place le temps des mises à jour et installations. Et un script inverse à penser à passer juste avant la fin de la journée (pour que chacun puisse continuer ses mises à jour et installations chez lui)
Pour les install je ne vois que l'install par PXE qui permet (je crois) de modifier le serveur d'installation, et une clé bootable pour l'installation par PXE pour les machines ne le supportant pas nativement.
Non ?
[^] # Re: dns menteur
Posté par NeoX . Évalué à 2.
ca me semble le mieux :
1°) pas besoin de clef usb/cd/dvd pour demarrer
2°) possibilité de preparer les medias d'installation pour ne cibler qu'un depot particulier
3°) prevoir un script sur le bureau qui remettre les depots d'origine de la distrib quand la personne quittera les locaux
[^] # Re: dns menteur
Posté par Epy . Évalué à 2.
A un détail près, on installe pas mal de vieilles machines (plus faciles à migrer, moins critiques pour les personnes qui ne sont pas décidées aussi) donc certaines ne supportent pas le PXE
Mais je viens d'aller faire un tour et il existe des images de CD et USB qui lancent un mini système capable de booter sur PXE (http://rom-o-matic.net/gpxe/gpxe-1.0.1/contrib/rom-o-matic/build.php par exemple)
Cela mérite des essais :)
Par rapport à ton autre réponse: apt-mirror n'existe pas chez la famille Red-Hat, et Reposync ne semble pas exister chez la famille Debian, il faudrait donc 2 OS pour les mises à jour ce n'est pas pratique:
J'espère parvenir à monter un petit boitier avec un bouton externe qui lancera automatiquement les scripts rsync après s'être connecté à un réseau performant. Cela me semble plus indépendant comme méthode (fonctionnel sur n'importe quel OS hôte qui sera choisi) et sans dual boot ;)
Merci pour les infos
[^] # Re: dns menteur
Posté par NeoX . Évalué à 2.
non, il te faut juste un OS principal, et un chroot de l'autre OS
[^] # Re: dns menteur
Posté par jigso . Évalué à 2.
Hum….
[^] # Re: dns menteur
Posté par jigso . Évalué à 3.
En ce qui concerne les signatures, ce sont les paquets qui sont signés, peu importe le serveur ou le support, donc ça ne posera pas de soucis.
En revanche si tu utilises des repo en https, là ça coincera, mais je ne crois pas que les repos classiques utilisent du https.
Honnêtement c'est ce qui me semble le moins intrusif, vu qu'il n'y a rien à changer sur la conf des clients.
En ce qui concerne la gestion des miroirs et du repo local, il te suffit d'en utiliser un par distrib comme source, la liste c'est juste pour le DNS.
KISS !
[^] # Re: dns menteur
Posté par Epy . Évalué à 2.
Ah ben si ça peut le faire comme ça je préfère encore cette solution à l'autre plus compliqué. Je vais essayer ça du coup.
Merci !
# apt-mirror pour les debianlike
Posté par NeoX . Évalué à 2.
apt-mirror pour les debian like,
reposync et d'autres outils pour les autres distribs,
si tu penses qu'il faut les lancés dans chacune des distribs, tu peux jouer avec des chroot contenant l'aborescence de chaque distrib.
une fois le mirroir fait, je suis d'accord avec ce que propose jigso, utiliser le dns local pour "tricher" et en faire un dns menteur pour envoyer vers ton serveur mirroir.
[^] # Re: apt-mirror pour les debianlike
Posté par feth . Évalué à 4.
Et s'il est tolérable de télécharger un paquet la première fois, je recommande apt-cacher, que nous utilisons avec profit dans mon entreprise. Il faut juste insérer temporairement un fichier /etc/apt/apt.conf.d/01proxy contenant
(recopié de https://help.ubuntu.com/community/Apt-Cacher-Server )
[^] # Re: apt-mirror pour les debianlike
Posté par Epy . Évalué à 2. Dernière modification le 03 mars 2015 à 10:30.
Comme je le disais c'est une solution très imparfaite:
Nous avons de nombreuses configurations différentes et avant que tous les paquets utilisés soient mis en cache nous aurons consommé pas mal de bande passante à mon avis
Il faut modifier un fichier de config et penser à le désactiver à la fin de la journée (bon, c'est un demi argument puisque c'était aussi le cas avec l'autre solution que j'étais en train d'envisager)
C'est problématique parce qu'en cas d'oubli l'utilisateur ne peut plus faire aucune mise à jour ni installation
Ça ne fonctionne pas pour les fresh install (à moins d'installer en minimal minimal, et de mettre le cache en place avant d'installer la suite par le gestionnaire de paquets, avec un script éventuel selon la config souhaitée)
Il faut faire attention que les machines interrogent toutes le même serveur, pour que le cache ne crée pas un nouveau répertoire et que tout soit retéléchargé (c'est le cas avec apt-cacher-ng par exemple)
Mais je garde l'idée de coté, on se tournera vers cette solution si nécessaire
Merci
[^] # Re: apt-mirror pour les debianlike
Posté par feth . Évalué à 3.
Précision: apt-cacher-ng, bien sûr !
Cela dit, vous pourriez préchauffer le cache en l'utilisant à l'avance.
# Mirrorbrain
Posté par Epy . Évalué à 2.
Si cela intéresse d'autres personnes, j'ai trouvé quelque chose qui pourrait être LA solution parfaite:
http://mirrorbrain.org/
Cela semble (si je ne me trompe pas) être comme un gestionnaire de CDN, il va intercepter les requêtes vers un repo et les rediriger vers le plus proche (en l'occurence il faudra que je force le mien)
Si ça fonctionne bien, il ne me reste qu'à faire fonctionner les scripts/chroot + scripts pour remplir mon repo
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.