Je souhaiterais faire un miroir (partiel) du dépôt
http://ftp.fr.debian.org/debian/ (et éventuellement d'autres
petits dépôts ici où là) et j'ai quelques questions à ce sujet.
1) Déjà, quelle méthode utiliser ?
Sur cette page http://www.debian.org/mirror/ftpmirror.fr.html#how,
il est clairement indiqué d'utiliser le script "ftpsync" (un lien
vers un tar.gz est donné). Je suis en train d'essayer ce script et
ça semble bien marcher.
Personnellement, j'aime bien la solution "apt-mirror" qui est
d'une simplicité déconcertante à utiliser mais cette solution
utilise wget pour créer le miroir, or ceci est clairement déconseillé
dans le lien que j'ai donné ci-dessus.
Ça fait quand même drôle parce que apt-mirror est packagé, alors que
la solution ftpsync, elle, ne l'est même pas et c'est pourtant elle
qui est recommandée.
De plus, ftpsync se base sur rsync mais certains dépôts ne « parlent »
pas le rsync, comme par exemple http://hwraid.le-vert.net/debian/ et
du coup, pour ce genre de dépôt, si je veux m'en faire un miroir je suis
bien obligé de laisser ftpsync de côté et d'utiliser apt-mirror a priori,
non ?
2) Avec ftpsync, j'arrive sans problème à exclure des architectures
dont je n'ai que faire (en ce qui me concerne seules les sources et
l'architecture amd64 m'intéressent). En revanche en lisant le peu
de doc qui accompagne ftpsync, je n'ai pas trouvé comment exclure
des distributions. En effet, par exemple je me moque de jessie (pour
l'instant en tout cas) et ne souhaite récupérer que ce qui concerne
squeeze et wheezy.
Savez-vous comment faire cela ?
Pour le coup, avec apt-mirror, c'est vraiment très simple à faire
alors qu'avec ftpsync ça semble moins évident (mais j'ai peut-être
loupé un truc).
3) Peut-on et doit-on faire un miroir (à usage privé bien sûr pas un
miroir officiel) de security.debian.org ?
De ce que j'ai lu ici ou là, il n'est pas recommandé d'utiliser
un miroir officiel de security.debian.org et pour cause il n'en
existe pas. En revanche, je n'ai rien trouvé qui déconseille
l'utilisation d'un miroir « perso » de security.debian.org.
Par contre, j'ai du mal à réaliser la chose avec ftpsync car
security.debian.org ne propose pas de module "debian" en partage
(qui est le module par défaut que va chercher ftpsync) :
Sur quel module faut-il que je fasse la synchronisation ?
En revanche avec apt-mirror (qui lui utilise wget), c'est très
facile de faire un miroir de security.debian.org (en ne gardant
que distributions qui m'intéressent).
4) Admettons que j'ai un miroir perso complet de
http://ftp.fr.debian.org/debian/ dans le sens où j'ai pu faire
ma première et longue synchro. Supposons que de nouvelle mises
à jour arrivent sur http://ftp.fr.debian.org/debian/. Je dois faire
une nouvelle synchro de mon miroir perso, synchro qui elle ne sera
pas trop longue (car j'ai juste un delta à récupérer). Durant la période
où je fais cette nouvelle synchro, est-ce que mon miroir perso est
opérationnel ? Je veux dire par là est-ce que le miroir perso se
trouve dans un état « inconsistant » durant cette phase là le rendant
non utilisable pour les clients ? Ça me semblerait logique que ce
soit le cas tant que la synchro n'est pas terminée. Faut-il, par
prudence, couper service http sur le miroir perso à ce moment là ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Nicolas George
Francois Lafont , dans le message <526bb884$0$2141$, a écrit :
Personnellement, j'aime bien la solution "apt-mirror" qui est d'une simplicité déconcertante à utiliser mais cette solution utilise wget pour créer le miroir, or ceci est clairement déconseillé dans le lien que j'ai donné ci-dessus.
Je pense que tu as mal compris la recommandation. Tel que je la comprends, il est déconseillé d'utiliser wget directement, simplement avec ses options de miroir par exploration récursive des liens. Mais si wget est piloté par un script qui fait correctement les choses, alors c'est juste un bon client HTTP.
Francois Lafont , dans le message
<526bb884$0$2141$426a74cc@news.free.fr>, a écrit :
Personnellement, j'aime bien la solution "apt-mirror" qui est
d'une simplicité déconcertante à utiliser mais cette solution
utilise wget pour créer le miroir, or ceci est clairement déconseillé
dans le lien que j'ai donné ci-dessus.
Je pense que tu as mal compris la recommandation. Tel que je la comprends,
il est déconseillé d'utiliser wget directement, simplement avec ses options
de miroir par exploration récursive des liens. Mais si wget est piloté par
un script qui fait correctement les choses, alors c'est juste un bon client
HTTP.
Francois Lafont , dans le message <526bb884$0$2141$, a écrit :
Personnellement, j'aime bien la solution "apt-mirror" qui est d'une simplicité déconcertante à utiliser mais cette solution utilise wget pour créer le miroir, or ceci est clairement déconseillé dans le lien que j'ai donné ci-dessus.
Je pense que tu as mal compris la recommandation. Tel que je la comprends, il est déconseillé d'utiliser wget directement, simplement avec ses options de miroir par exploration récursive des liens. Mais si wget est piloté par un script qui fait correctement les choses, alors c'est juste un bon client HTTP.
Francois Lafont
Le 26/10/2013 14:49, Nicolas George a écrit :
Je pense que tu as mal compris la recommandation. Tel que je la comprends, il est déconseillé d'utiliser wget directement, simplement avec ses options de miroir par exploration récursive des liens. Mais si wget est piloté par un script qui fait correctement les choses, alors c'est juste un bon client HTTP.
Ah ok, tu as sans doute raison.
J'aime vraiment bien la simplicité d'utilisation de apt-mirror après je tombe parfois sur des sortes de blocages, par exemple avec ce fichier de conf /etc/apt/mirror.list :
#---------------------------------------------- set base_path /apt-mirror set mirror_path $base_path/mirror set skel_path $base_path/skel set var_path $base_path/var set cleanscript $var_path/clean.sh set defaultarch amd64 set postmirror_script $var_path/postmirror.sh set run_postmirror 0 set _tilde 0 set nthreads 20
deb http://ftp.fr.debian.org/debian squeeze main contrib non-free deb-src http://ftp.fr.debian.org/debian squeeze main contrib non-free
deb http://ftp.fr.debian.org/debian wheezy main contrib non-free deb-src http://ftp.fr.debian.org/debian wheezy main contrib non-free
deb http://security.debian.org squeeze/updates main contrib non-free deb-src http://security.debian.org squeeze/updates main contrib non-free
deb http://security.debian.org wheezy/updates main contrib non-free deb-src http://security.debian.org wheezy/updates main contrib non-free
La synchronisation se fait toujours en 2 temps. D'abord, le téléchargement de fichiers d'index (en général cette phase est assez rapide) puis ensuite le téléchargement des paquets etc. (en général cette phase là est très longue... la toute première fois). Et bien avec le fichier de conf ci-dessus, la première phase n'en finit pas, ce qui me semble bien étrange. J'ai ça :
~$ apt-mirror Downloading 160 index files using 20 threads... Begin time: Sat Oct 26 17:43:26 2013 [20]... [19]... [18]... [17]... [16]... [15]... [14]... [13]... [12]... [11]... [10]... [9]... [8]... [7]... [6]... [5]... [4]... [3]... [2]... [1]...
Et ça reste bloqué sur le [1]..., même après environ 30 Go de fichiers *déjà* téléchargés dans /apt-mirror (testé avec un du -sh /apt-mirror sachant que le répertoire était vide au départ) le soit-disant download des 160 fichiers d'index n'est toujours pas terminé. C'est vraiment curieux car quand je prends seulement un dépôt dans la conf (une ligne deb et deb-src et les autres sont commentées), ça se passe bien et la phase de téléchargement des index est assez rapide (5 minutes à tout casser). Pris tous ensembles, on dirait qu'un truc bloque. Je n'atteins jamais la phase 2 (jusqu'à présent et j'ai été patient je crois).
Perso, j'utilisais déjà apt-mirror pour chez moi mais avec une liste restreinte de dépôts (squeeze uniquement). Mais là, avec une liste un peu plus fournie comme ci-dessus, je constate des « blocages ».
Quelqu'un a-t-il déjà eu ce genre de souci ?
-- François Lafont
Le 26/10/2013 14:49, Nicolas George a écrit :
Je pense que tu as mal compris la recommandation. Tel que je la comprends,
il est déconseillé d'utiliser wget directement, simplement avec ses options
de miroir par exploration récursive des liens. Mais si wget est piloté par
un script qui fait correctement les choses, alors c'est juste un bon client
HTTP.
Ah ok, tu as sans doute raison.
J'aime vraiment bien la simplicité d'utilisation de apt-mirror après je tombe
parfois sur des sortes de blocages, par exemple avec ce fichier de conf
/etc/apt/mirror.list :
#----------------------------------------------
set base_path /apt-mirror
set mirror_path $base_path/mirror
set skel_path $base_path/skel
set var_path $base_path/var
set cleanscript $var_path/clean.sh
set defaultarch amd64
set postmirror_script $var_path/postmirror.sh
set run_postmirror 0
set _tilde 0
set nthreads 20
deb http://ftp.fr.debian.org/debian squeeze main contrib non-free
deb-src http://ftp.fr.debian.org/debian squeeze main contrib non-free
deb http://ftp.fr.debian.org/debian wheezy main contrib non-free
deb-src http://ftp.fr.debian.org/debian wheezy main contrib non-free
deb http://security.debian.org squeeze/updates main contrib non-free
deb-src http://security.debian.org squeeze/updates main contrib non-free
deb http://security.debian.org wheezy/updates main contrib non-free
deb-src http://security.debian.org wheezy/updates main contrib non-free
La synchronisation se fait toujours en 2 temps. D'abord, le téléchargement
de fichiers d'index (en général cette phase est assez rapide) puis ensuite
le téléchargement des paquets etc. (en général cette phase là est très
longue... la toute première fois). Et bien avec le fichier de conf ci-dessus,
la première phase n'en finit pas, ce qui me semble bien étrange. J'ai ça :
~$ apt-mirror
Downloading 160 index files using 20 threads...
Begin time: Sat Oct 26 17:43:26 2013
[20]... [19]... [18]... [17]... [16]... [15]... [14]... [13]... [12]...
[11]... [10]... [9]... [8]... [7]... [6]... [5]... [4]... [3]... [2]...
[1]...
Et ça reste bloqué sur le [1]..., même après environ 30 Go de fichiers
*déjà* téléchargés dans /apt-mirror (testé avec un du -sh /apt-mirror sachant
que le répertoire était vide au départ) le soit-disant download des 160
fichiers d'index n'est toujours pas terminé. C'est vraiment curieux car
quand je prends seulement un dépôt dans la conf (une ligne deb et deb-src
et les autres sont commentées), ça se passe bien et la phase de téléchargement
des index est assez rapide (5 minutes à tout casser). Pris tous ensembles,
on dirait qu'un truc bloque. Je n'atteins jamais la phase 2 (jusqu'à présent
et j'ai été patient je crois).
Perso, j'utilisais déjà apt-mirror pour chez moi mais avec une liste
restreinte de dépôts (squeeze uniquement). Mais là, avec une liste
un peu plus fournie comme ci-dessus, je constate des « blocages ».
Je pense que tu as mal compris la recommandation. Tel que je la comprends, il est déconseillé d'utiliser wget directement, simplement avec ses options de miroir par exploration récursive des liens. Mais si wget est piloté par un script qui fait correctement les choses, alors c'est juste un bon client HTTP.
Ah ok, tu as sans doute raison.
J'aime vraiment bien la simplicité d'utilisation de apt-mirror après je tombe parfois sur des sortes de blocages, par exemple avec ce fichier de conf /etc/apt/mirror.list :
#---------------------------------------------- set base_path /apt-mirror set mirror_path $base_path/mirror set skel_path $base_path/skel set var_path $base_path/var set cleanscript $var_path/clean.sh set defaultarch amd64 set postmirror_script $var_path/postmirror.sh set run_postmirror 0 set _tilde 0 set nthreads 20
deb http://ftp.fr.debian.org/debian squeeze main contrib non-free deb-src http://ftp.fr.debian.org/debian squeeze main contrib non-free
deb http://ftp.fr.debian.org/debian wheezy main contrib non-free deb-src http://ftp.fr.debian.org/debian wheezy main contrib non-free
deb http://security.debian.org squeeze/updates main contrib non-free deb-src http://security.debian.org squeeze/updates main contrib non-free
deb http://security.debian.org wheezy/updates main contrib non-free deb-src http://security.debian.org wheezy/updates main contrib non-free
La synchronisation se fait toujours en 2 temps. D'abord, le téléchargement de fichiers d'index (en général cette phase est assez rapide) puis ensuite le téléchargement des paquets etc. (en général cette phase là est très longue... la toute première fois). Et bien avec le fichier de conf ci-dessus, la première phase n'en finit pas, ce qui me semble bien étrange. J'ai ça :
~$ apt-mirror Downloading 160 index files using 20 threads... Begin time: Sat Oct 26 17:43:26 2013 [20]... [19]... [18]... [17]... [16]... [15]... [14]... [13]... [12]... [11]... [10]... [9]... [8]... [7]... [6]... [5]... [4]... [3]... [2]... [1]...
Et ça reste bloqué sur le [1]..., même après environ 30 Go de fichiers *déjà* téléchargés dans /apt-mirror (testé avec un du -sh /apt-mirror sachant que le répertoire était vide au départ) le soit-disant download des 160 fichiers d'index n'est toujours pas terminé. C'est vraiment curieux car quand je prends seulement un dépôt dans la conf (une ligne deb et deb-src et les autres sont commentées), ça se passe bien et la phase de téléchargement des index est assez rapide (5 minutes à tout casser). Pris tous ensembles, on dirait qu'un truc bloque. Je n'atteins jamais la phase 2 (jusqu'à présent et j'ai été patient je crois).
Perso, j'utilisais déjà apt-mirror pour chez moi mais avec une liste restreinte de dépôts (squeeze uniquement). Mais là, avec une liste un peu plus fournie comme ci-dessus, je constate des « blocages ».
Quelqu'un a-t-il déjà eu ce genre de souci ?
-- François Lafont
Francois Lafont
Le 26/10/2013 18:20, Francois Lafont a écrit :
je tombe parfois sur des sortes de blocages, par exemple avec ce fichier de conf /etc/apt/mirror.list :
[...]
Ce point là est résolu... c'est ma faute. Dans le fichier de conf, j'indiquais la taille approximative correspondant à un dépôt comme ceci :
deb http://ftp.fr.debian.org/debian wheezy main contrib non-free # 44 Go
en me disant qu'avec le caractère #, il n'y avait pas de souci, ça passait comme un simple commentaire. Erreur... j'ai pu voir dans les fichiers que le # se retrouvait dans les urls cibles utilisées par les wget et ça engendrait un download de tout une arborescence. Bref, il ne faut pas mettre de commentaires en fin d'une ligne du type « deb ... » etc.
Du coup, je vais définitivement m'orienter vers apt-mirror je pense. Je suis toujours intéressé par la question 4 de mon premier message (lors d'une phase de synchro le miroir perso est-il toujours opérationnel ou bien est-il dans un état inconsistant qui nécessite l'arrêt du service http ?).
-- François Lafont
Le 26/10/2013 18:20, Francois Lafont a écrit :
je tombe
parfois sur des sortes de blocages, par exemple avec ce fichier de conf
/etc/apt/mirror.list :
[...]
Ce point là est résolu... c'est ma faute. Dans le fichier de conf,
j'indiquais la taille approximative correspondant à un dépôt comme
ceci :
deb http://ftp.fr.debian.org/debian wheezy main contrib non-free # 44 Go
en me disant qu'avec le caractère #, il n'y avait pas de souci, ça
passait comme un simple commentaire. Erreur... j'ai pu voir dans les
fichiers que le # se retrouvait dans les urls cibles utilisées par les
wget et ça engendrait un download de tout une arborescence. Bref, il
ne faut pas mettre de commentaires en fin d'une ligne du type
« deb ... » etc.
Du coup, je vais définitivement m'orienter vers apt-mirror je pense.
Je suis toujours intéressé par la question 4 de mon premier message
(lors d'une phase de synchro le miroir perso est-il toujours
opérationnel ou bien est-il dans un état inconsistant qui nécessite
l'arrêt du service http ?).
je tombe parfois sur des sortes de blocages, par exemple avec ce fichier de conf /etc/apt/mirror.list :
[...]
Ce point là est résolu... c'est ma faute. Dans le fichier de conf, j'indiquais la taille approximative correspondant à un dépôt comme ceci :
deb http://ftp.fr.debian.org/debian wheezy main contrib non-free # 44 Go
en me disant qu'avec le caractère #, il n'y avait pas de souci, ça passait comme un simple commentaire. Erreur... j'ai pu voir dans les fichiers que le # se retrouvait dans les urls cibles utilisées par les wget et ça engendrait un download de tout une arborescence. Bref, il ne faut pas mettre de commentaires en fin d'une ligne du type « deb ... » etc.
Du coup, je vais définitivement m'orienter vers apt-mirror je pense. Je suis toujours intéressé par la question 4 de mon premier message (lors d'une phase de synchro le miroir perso est-il toujours opérationnel ou bien est-il dans un état inconsistant qui nécessite l'arrêt du service http ?).
