Názory k článku
Vlastní mirror repositářů pro Debian a Ubuntu

nejlepsi cache co sem kdy pouzival bylo tohle: http://lftpfs.sourceforge.net/
napsal sem si k tomu bashovej mount.lftps wrapper, takze to slo mountovat i z fstabu. dokaze to cachovat vzdaleny data pomoci ruznejch protokolu se spoustou nastaveni a neomezuje se to na debiani balicky. v zasade se to chova jako filesystem, kterej se pokusi ze zadanyho zdroje (cokoliv co ma podporu v lftp) stahnout kazdej soubor ke kterymu se nekdo pokusi pristoupit a pak ho nacachuje na prednastavenou dobu. pokud to hodite treba do rootu nejakyho ftp/webserveru, tak mate vlastne cachujici reverzni proxy pro statickej obsah...

Ak mam server zapojeny medzi pocitacmi a internetom a mam ho nastaveny cez Firehol aby preposielal udaje z eth0 na eth1 a zaroven mi na tom serveri bezi Appache, bude to fungovat?

Bude, není v tom problém.

Existuje něco podobného i pro Arch?

Resi se to stejne jako kdyz si pustite lokalni instalaci toho sameho 2x.. DISTFILES nese zamky sebou (v adresari /mnt/distfiles/­.locks/ ) a instalator je dostatecne chytry aby pockal na dotazeni balicku.

V pripade vetsi instalace se balicky jiz nejakou dobu stahuji dokonce na pozadi instalace - cize soucasny pristup k datum je vyresen vyborne.

Co se tyce synchronizace PORTAGE - delate ji bud pravidelne v noci, nebo predtim nez neco potrebujete nutne aktualizovat. Vy si snad pustite synchronizaci a update/instalaci zaraz? Prinejhorsim se neco nepovede nainstalovat, zkusite podruhe a uz to jde. Standardni Gentoo zivot :) (taky je o hodne pravdepodobnejsi ze neco nepujde zkompilovat, nez ze se pri synchronizaci zrovna trefite do patchovani jen s polovinou patchu, nebo vypoctu zavislosti ktere by si spolu opravdu nesedli).

>> DISTFILES nese zamky sebou

Díky, to mě právě zajímalo.

>> se balicky jiz nejakou dobu stahuji dokonce na pozadi instalace

To je pěkné!

>> Vy si snad pustite synchronizaci a update/instalaci zaraz?

Nepustím, protože Gentoo nepoužívám ;) Spíš my šlo třeba o to, že si člověk nemusí uvědomit, že když spustí před spaním kompilace nějakýho molocha (OpenOffice nebo tak něco), že se mu do toho přes noc připlete synchronizace portage v cronu... Čili ptal jsem se (podobně jako v předchozí otázce), jestli je to ošetřeno, nebo to musí hlídat admin.

>> Prinejhorsim se neco nepovede nainstalovat, zkusite podruhe a uz to jde. Standardni Gentoo zivot :)

Tak to mě teda moc neláká, bez urážky :)

Omlouvám se za chyby - holt, ty příspěvky si člověk po sobě má přečíst :)

>> Čili ptal jsem se (podobně jako v předchozí otázce), jestli je to ošetřeno, nebo to musí hlídat admin.

Zavislosti se generuji pred zacatkem stahovani/kompilace prvniho balicku, tedy synch portage behem probihajici kompilace nema zadnej vliv.

Nejde jenom o zavislosti, ne?

samozrejme pak jsou potreba jeste fyzicky ebuildy (ulozeny v portage tree); tady je teoreticky mozny, ze by update portage mohl nektery ebuild odstranit a nahradit jinym (vetsinou novejsim), nicmene v situaci, kdy budu updatovat pravidelne nightly se to imo nestane (starsi baliky se nemazou hned a velke mnozstvi baliku ma vic stable/testing verzi).

Pro absolutni klid admina na dusi by pro tento pripad stacilo napr lokalne pres rsync (prvni co me napadlo) pred emerge synchronizovat portage tree a nepouzivat sdileny uloziste (samozrejme cache balicku by dal zustala sdilena). Pripadne pouzit neco jako skript update-world, kterej se po nezdarene kompilaci pokousi o dalsi (jen by se musel upravit pro znovugenerovani listu balicku).

Sync behem kompilace ma vliv - mensi patche jsou soucasti portage (adresar files), ale ne kazdy balicek je vyuziva. Tyto se aplikuji behem kompilace takze pokud je sync odstrani tak zamyslena verze k instalaci jiz nepujde skompilovat.

Ano - o to mi šlo. Jestliže si dokážu představit situaci, kdy běží kompilace a uprostřed ní se spustí sync portage, pak si dokážu představit i situaci, kdy tento sync překlad pokazí (pakliže neexistuje nějaký zámek, který synchronizaci uprostřed kompilace nedovolí).

Článek jsi vůbec nečetl, nebo jen nepochopil?

Cetl a pochopil moc dobre :) A mit prehled je prece plus.

Ono je to videt i v diskuzi, jak to nekterym nefunguje, ze zcela zahadneho duvodu. Neni prece jednodussi, kdyz primo balickovaci system je navrzen inteligentne, oproti stavu "staci jednoduse a zbytek se nejak pozdeji dodela".. to pak vznikaji tyto problematicke doplnky.

To je super, niečo také som potreboval! Ako je to ale s prenášaním? Napr. ak by som si to nastavil na notebooku doma a potom by som chcel niečo inštalovať mimo moju sieť, bude to fungovať?

No je celkem jasné, že to fungovat nebude... Ten váš server, na kterém ta cache jede, nejspíš nebude dostupný (zvlášť když to bude něco typu 192.168.*.*)...

A je asi celkem jedno, jestli se použije to nastavení v článku - cache server bude nastavený jako proxy - nebo to zadáte jako nový repozitář.

Asi by se to dalo vyřešit tak, že by měl člověk dva konfigurační soubory pro APT (jeden s proxy, druhý bez) a nějakým skriptem mezi nimi přepínal...

Dobré vedeieť... Tak mi napadlo, že by mohlo byť dobré urobiť akúsi P2P sieť pre ľudí, ktorí nemajú domáci server... Ale písať sa mi to nechce :) Asi skúsim to s 2 konfigurákmi...

K tomu presne mam na notebooku tenhle skript v /etc/network/if-up.d/apt-proxy : http://so.piskvor.org/3503/apt-proxy - podle broadcast adresy z DHCP nastavi tu spravnou proxy pro APT (nebo prime spojeni, pokud neni na zname siti).

Zdravím,

tohle je přesně to, co potřebuju. Podle popisu vše proběhlo jak má, při pokusu o aktualizaci ale dojde k chybě:
W: Chyba při získávání http://cz.archive.ubuntu.com/ubuntu/pool/main/b/base-files/base-files_5.0.0ubuntu20.10.04.3_i386.deb
Nemohu se připojit k 192.168.1.20:3128 (192.168.1.20). - connect (111: Connection refused)

Jak mám prosím říct zdroji, aby spojení neodmítal? ;-)

Díky...

To by som tipoval na ohnivú stenu, zlú IP alebo nebežiaci démon...

No, ohnivá stěna není, IP je dobře.
Ale na toho démona se podívám, i když si myslím, že běží asi rovnou, ne? Bez nějakýho speciálního souštění...
Díky za tip.

OT: To je protipozarni, nikoliv ohniva stena. Nelze pouzivat doslovny preklad.

"Firewall (construction), a barrier inside a building or vehicle, designed to limit the spread of fire, heat and structural collapse"

To záleží na tom, jestli jsi hrál Diablo :).

neni to nespravne nastavenym portem? apt-cacher i apt-cacher-ng defaultne bezi na portu 3142, u Vas vidim 3128...

Je. Tedy bylo. Díky moc za tip - většina mých problémů se zakládá na podobných chybách...
Nicméně, v "V adresáři /etc/apt/apt.con­f.d/ stačí vytvořit soubor 01proxy" - jak píše autor jsem skutečně zapsal hodnotu podle článku.
V Synapticu jsem ale při konfigurování proxy udělal překlep. Možná jsem to úplně nepochopil - stačí tedy udělat jen jeden krok? Anebo jsou zapotřebí konfigurovat obě místa?

Jak říkám, díky za popostrčení :D

Možná by nebylo špatné zmínit, jestli existuje něco podobného taky pro RedHat, Fedoru nebo jiné systémy založené na rpm.

Pro Fedoru jsem nasel https://fedorahosted.org/intelligentmirror/wiki/IntelligentMirror

Bohuzel pro openSUSE jsem funkcni projekt nenalezl. V anarchistickych diskusnich krouzcich se hovori o zypp-proxy ;) Nicmene bohuzel pro zypper se mi jevi jako jedina neidealni varianta - http proxy. Squid je ale strasna vec, ktera snad v kazde verzi kompletne zmeni syntax konfiguracnich souboru.

Jestli se smím zeptat - což takhle podobná vychytávka pro uživatele Mandrivy? Má někdo k tomu pozitivní zkušenost? Díky!

http://www.mandrivalinux.cz/jak-si-vytvorit-lokalni-repozitar-pro-mandriva-linux/

+ http://www.mandrivalinux.cz/hromadna-sprava-softwaru-v-mandriva-linuxu-pro-pocitace-v-siti/

OK, děkuji za info, vyzkouším... :-)

mohu nastavit CacheDir: /var/cache/ap­t/archives ?

Ne, APT cache je jeden adresář bez Release souborů, APT server (mirror) je množství různých hierarchicky uspořádaných adresářů.

snazim zprovoznit mirror uz asi 2 hodky, ale zkoncil jsem na tom ze mi to netaha.
Pri importu mi to pisne hlasku:
"Maintenance task (File Import), apt-cacher-ng version: 0.5.13 (Cancel)
Importing from /var/cache/apt-cacher-ng/_import/_import directory, scanning...
No index files detected. Unable to continue, cannot map files to internal locations.
Return to main page"

v configu mam cestu /var/cache/apt-cacher-ng/_import/ ne chapu kde to bere _import

Odpovím si sám, kdyby to náhodou někoho zajímalo. Jde to skrze Squid http://lauri.vosandi.eu/blog/?p=173

Zdar, netušíte, zda to pozná balíčky ze zdrojů různé platformy označené jako "all" a nacacheuje? A co když jeden počítač to tahá z originálních repozitářu a druhý z českých?

Všechny balíčky jsou v jednom společném poolu, akorát seznamy balíčků se potom rozdělují podle architektury. Tedy balíčky all mají jenom jednu URL a tak se nacachují jenom jednou.

S více mirrory apt-cacher-ng nemá problém, jeho balíček obsahuje seznam mirrorů (i když tam můj oblíbený chyběl) a ty on poté mapuje dohromady jako jeden zdroj (uburep, debrep ap.). Neumí to ale pracovat se systémem getdeb, to jsem musel obcházet pomocí jména balíku.

Dobry clanek!

Pouzival jsem podobnou vec, modul pro IPCop; Update Accelerator
http://update-accelerator.advproxy.net/

• Modul pro transparetni proxy; klienti o proxy nevi, neni treba nastavovat
• Obecnejsi. Podporuje DEB, RPM i aktualizce pro Windows; malou zmenou skriptu lze rozsirit, treba o DRPM anebo XY balicky
• Graficke GUI (HTML). Prehled o vyuziti akceleratoru (statistiky, kolik se usporilo, kolikrat byl kazdy soubor pozadovan, atd)

• Reseni omezene na IPcop/SmoothWall

Zaujalo me, ze v provozu se nejvice dat usetrilo pro stanice s Windows, prestoze jich bylo v siti minimum. Stanice s Windows stale stahovaly nejake update pro antiviry, i nekolikrat denne, atd, atd. V absolutnich cislech obrovska uspora prenesenych dat... Linuxove stanice zase zabiraly velke mnostvi diskoveho prostoru; velke mnozstvi ruznych balicku, casto ruzne verze tehoz SW.

Urcite mohu provoz cachovaciho serveru pro provoz lokalni site doporucit; vyplati se...