# Ebuilds herunterladen

## Keruskerfuerst

Es es auch möglich per rsync die Ebuilds herunterzuladen?

Aktuell wird (so weiß ich), nur ftp und http Transfer unterstützt.

----------

## schmutzfinger

Häh? Was glaubst du macht "emerge --sync"?

----------

## Keruskerfuerst

emerge --sync gleicht den Dateibaum unter /usr/portage ab.

Ich meinte den Dateitransfer für den Sourcecode der Ebuilds.

----------

## Beforegod

Ich glaube es gibt einfach zu wenige Filehoster die per rsync Daten übertragen (also meines wissens nach)... von daher kaum nutzvoll. Gabs nicht auch mal Delta Patches?

----------

## Keruskerfuerst

Der Dateitransfer per Rsync wäre besser, da dieses Protokoll auch noch Prüfsummen mitüberträgt.

----------

## think4urs11

Sofern ich das Problem richtig verstehe ...such dir hier einen aus der rsync unterstützt.

In D z.B. den hier: rsync://linux.rz.ruhr-uni-bochum.de/gentoo/

----------

## Keruskerfuerst

Ich habe folgendes in /etc/make.conf eingetragen:

GENTOO_MIRRORS="rsync://linux.rz.ruhr-uni-bochum.de/gentoo/ rsync://ftp.join.uni-muenster.de/gentoo/ rsync://mirrors.sec.informatik.tu-darmstadt.de/gentoo/ rsync://ftp-stud.fht-esslingen.de/gentoo/"

Nur erscheint dann bei emerge -f <Paket>:

Downloading 'rsync://linux.rz.ruhr-uni-bochum.de/gentoo/distfiles/kdelibs-3.5-patchset-05.tar.bz2'

rsync://linux.rz.ruhr-uni-bochum.de/gentoo/distfiles/kdelibs-3.5-patchset-05.tar.bz2: Unsupported scheme.

----------

## schmutzfinger

 *Keruskerfuerst wrote:*   

> Der Dateitransfer per Rsync wäre besser, da dieses Protokoll auch noch Prüfsummen mitüberträgt.

 

Und wozu braucht man das wenn im portage tree sowieso Prüfsummen drinne sind?

----------

## think4urs11

logisch; emerge benutzt im Hintergrund standardmäßig wget zum Download der Files und das kann nunmal nicht mit rsync-Servern.

Theoretisch sollte es durch geeignetes Anpassen in /etc/make.conf von FETCHCOMMAND / RESUMECOMMAND auf etwas adaptierbar sein das auch rsync kann; wie aber genau und mit welchem Client muß ich passen.

----------

## Keruskerfuerst

 *schmutzfinger wrote:*   

>  *Keruskerfuerst wrote:*   Der Dateitransfer per Rsync wäre besser, da dieses Protokoll auch noch Prüfsummen mitüberträgt. 
> 
> Und wozu braucht man das wenn im portage tree sowieso Prüfsummen drinne sind?

 

Weil Rsync die Dateien in Blöcken - die mit einer Prüfsumme versehen ist - überträgt. Deshalb wäre dies besser.

Außerdem treten aufgrund der Bitfehlerrate (der Übertragungsstrecke) beim Dateitransfer immer Fehler auf.

----------

## Finswimmer

 *Keruskerfuerst wrote:*   

>  *schmutzfinger wrote:*    *Keruskerfuerst wrote:*   Der Dateitransfer per Rsync wäre besser, da dieses Protokoll auch noch Prüfsummen mitüberträgt. 
> 
> Und wozu braucht man das wenn im portage tree sowieso Prüfsummen drinne sind? 
> 
> Weil Rsync die Dateien in Blöcken - die mit einer Prüfsumme versehen ist - überträgt. Deshalb wäre dies besser.
> ...

 

Ob du am Ende die große Datei vergleichst, oder x Teilpakete, ändert nichts an der Sicherheit.

Tobi

----------

## Keruskerfuerst

 *Finswimmer wrote:*   

>  *Keruskerfuerst wrote:*    *schmutzfinger wrote:*    *Keruskerfuerst wrote:*   Der Dateitransfer per Rsync wäre besser, da dieses Protokoll auch noch Prüfsummen mitüberträgt. 
> 
> Und wozu braucht man das wenn im portage tree sowieso Prüfsummen drinne sind? 
> 
> Weil Rsync die Dateien in Blöcken - die mit einer Prüfsumme versehen ist - überträgt. Deshalb wäre dies besser.
> ...

 

Falsch.

Wohl noch nie eine Vorlesung über Nachrichtentechnik gehabt. Ich habe schon oft große Dateien (Isoimages von Betriebssytemen) heruntergeladen. Oft gab es bei der Installation Fehler. Wenn ich diese Images per Bittorrent heruntergeladen habe, dann funktionierten diese einwandfrei.

----------

## Finswimmer

Na dann erklär mal.

Die Datei ist 100Mb groß. Ich habe eine MD5 Summe. Die garantiert mir, dass die Datei identisch zur Quell Datei ist.

Zerlege ich die Datei nun in 200*0,5Mb, versehe die wieder mit je einer MD5 Summe, setze es dann zusammen, hab ich doch das Gleiche.

Ergo ändert sich nichts an der Datei selbst.

Nur: Je nachdem wie groß die zu überprüfenden Blöcke sind, desto mehr muss neu geladen werden, wenn die Summe nicht stimmt.

Tobi

----------

## schmutzfinger

Wenn ich die Datei aber in 200 Teile teile, dann kann zwischendurch die 200 Teile checken. Wenn einer davon fehlerhaft ist, muss ich nur den neu übertragen, und nicht die ganze Datei. Bei einem Fehler würde das bei deinem Bsp bedeuten:

1. Fall du ziehst 100MB, die sind kaputt und du ziehst sie nochmal -> 200MB

2. du ziehst 100MB ein Teil kaputt, den nochmal ziehen -> 100.5MB

Ist aber imho trotzdem Schwachsinn, TCP hat auch schon Prüfsummen intigriert. Und das sichert http und ftp ordentlich ab. Das letzte mal das bei portage ne Prüfsumme nicht gestimmt hat, lag bei mir an nem Fehler im tree. Übertragungsfehler hatte ich noch nie, oder kann mich jedenfalls nicht erinnern.

----------

## Finswimmer

@schmutzfinger: Mir ging es ja nur um die Sicherheit, dass man mehr runterladen muss ist klar. Hatte ich ja auch erwähnt gehabt.

Und da jedes TCP/IP Paket gecheckt wird, ist das auch kein Problem...

Tobi

----------

## Keruskerfuerst

Um rsync beim Herunterladen zu verwenden muß folgendes in /etc/make.conf eingetragen werden:

FETCHCOMMAND="/usr/bin/rsync --verbose --progress \${URI} /\${DISTDIR}/\${FILE}"

RESUMECOMMAND="/usr/bin/rsync --verbose --progress \${URI} /\${DISTDIR}/\${FILE}"

Es müssen natürlich auch die Einträge in GENTOO_MIRRORS geändert werden.

Wegen der Datenübertragung:

Ich habe schon oft große Dateien (Isoimages von Betriebssytemen) heruntergeladen. Danach die MD5 Summe verglichen und diese stimmte dann auch. Trotzdem gab es bei der Installation oft Fehler. Wenn ich diese Images per Bittorrent heruntergeladen habe, dann funktionierten diese einwandfrei.

----------

## schmutzfinger

Ich würde mal eher auf Probleme beim Brennen oder Lesen der CDs tippen. Ich weiß nicht wie hoch die Wahrscheinlichkeit ist, dass Übertragungsfehler die selbe md5-Summer erzeugen. Ich würde es für annähernd unmöglich halten.

----------

## think4urs11

 *schmutzfinger wrote:*   

> Ich weiß nicht wie hoch die Wahrscheinlichkeit ist, dass Übertragungsfehler die selbe md5-Summer erzeugen. Ich würde es für annähernd unmöglich halten.

 

OT: Logisch betrachtet erhöht sich die Wahrscheinlichkeit für identische MD5 analog der übertragenen Dateigröße. Schließlich und endlich ist eine MD5/SHA1 ja nur eine stark verkürzte Darstellung der Ursprungsdaten (grob gesagt) und daher gibt es bei größeren 'ver-md5-ten' Datenhappen mehr Möglichkeiten für -trotz auf Bitebene unterschiedlicher- Rohdaten eine identische MD5 zu erhalten.

Von daher ist die Logik 'viele kleine Häppchen mit Prüfsumme ist besser als ein großer Brocken' schon richtig.

Wie wahrscheinlich es allerdings ist steht auf einem anderen Blatt da stimme ich dir zu; in jedem Fall größer 0.

----------

## Keruskerfuerst

Wegen der Theorie von Übertragungsstrecken: leider kenne ich keine Möglichkeit mathmatische Formeln hier im Forum zu posten; ansonsten könnte ich mal über die Theorie von Übertragungsstrecken hier etwas wiedergeben.

Und hier noch meine Liste der

GENTOO_MIRRORS="rsync://linux.rz.ruhr-uni-bochum.de/gentoo rsync://ftp.join.uni-muenster.de/gentoo rsync://mirrors.sec.informatik.tu-darmstadt.de/gentoo/ rsync://ftp-stud.fht-esslingen.de/gentoo/ rsync://gentoo.intergenia.de/gentoo-linux rsync://ftp.belnet.be/gentoo/ rsync://ftp.snt.utwente.nl/gentoo/ rsync://gd.tuwien.ac.at/opsys/linux/gentoo/ rsync://trumpetti.atm.tut.fi/gentoo/"

----------

