Re: Choix d'un proxy/cache APT
Jean-Yves F. Barbier a écrit :
> Pascal Hambourg <pascal.mail@plouf.fr.eu.org> a écrit :
>
>> Si j'étais vraiment obligé d'augmenter
>> l'espace disque je préfèrerai ajouter un (ou remplacer le) disque
>> interne, d'autant plus que la machine n'a que des ports USB 1.1.
>
> au pis aller ça passe très bien; parce que ce ne sont pas les transferts
> qui prennent du temps.
Certes l'USB 1.1 reste 10 fois plus rapide que la connexion ADSL, et à
peu près aussi rapide que la connexion ethernet côté LAN (flemme de
remplacer la carte ethernet par une fast ethernet, pas très utile
jusqu'ici). Mais 10 fois moins rapide qu'un disque interne sur cette
machine (pas d'UDMA), par exemple ça ne doit pas être de la tarte pour
rsync qui doit y lire les fichiers à synchroniser afin de les comparer à
ceux de la source.
> et dès fois tu n'as pas le choix (quand un gros HD bloque le BIOS, par
> exemple)
C'est fort probablement le cas vu l'âge de l'engin, mais il y a des
contournements. Pour un disque secondaire, le déclarer absent dans le
BIOS ne l'empêche pas d'être détecté et utilisé par Linux. Pour le
disque de boot, définir manuellement une géométrie CHS fictive.
>> rsync est efficace sur les fichiers .deb ? Intuitivement j'aurais plutôt
>> tendance à penser qu'un fichier de type archive compressée ne s'y prête
>> pas bien, mais je peux me tromper.
>
> Oui, rsync demande d'abord un md5sum au svr afin de décider s'il met à jour
> ou non, donc quelque soit le type de ficher, ça marche :)
On ne s'est pas bien compris, je crois. rsync ne télécharge que les
fichiers modifiés, d'accord. Mais ma question portait sur les fichiers
modifiés : rsync essaie de ne télécharger que les parties qui diffèrent,
en tenant compte d'éventuels décalages. Pour du texte voire de
l'exécutable ça peut être efficace, mais l'est-ce aussi pour une archive
compressée comme un .deb ? Sinon je ne vois pas trop l'intérêt de rsync
si c'est juste pour détecter les paquets qui ont changé, les
méta-données d'APT suffisent.
>> De toute façon 45 Go c'est trop, il faudrait des jours pour la
>> synchronisation initiale du miroir alors qu'une infime partie serait
>> utilisée. C'est pourquoi je privilégie plutôt un proxy/cache.
Au fait, le total des CD ou DVD binaires pour i386 fait environ 20 Go, à
quoi correspondent les 45 Go ? Si cela inclut les paquets sources, je
n'en ai pas besoin.
> cétoakivoa, disons que l'avantage de mirroirs complets c'est que la BP
> n'est phagocytée qu'une seule fois par nuit et jamais plus par les machines
> du LAN.
>
> évidemment, l'intérêt est directement proportionnel au nombre de machines à
> mettre à jour simultanément.
Une poignée seulement. Pas assez pour justifier un miroir. C'est surtout
que la mise à jour de chaque machine télécharge les mêmes paquets à
chaque fois, ce que je voudrais éviter.
Reply to: