On 11.10.2007 20:36, Hans de Goede wrote: This is what it would look like when we want to replicate the Fedora layout (example only for el5 and Fedora 8/development; both only i386 to keep things simple): . `-- free |-- el | |-- 5 | | `-- i386 | | |-- all_the.rpms | | `-- repodata | `-- testing | `-- 5 | `-- i386 | |-- all_the.rpms | `-- repodata `-- fedora |-- development | `-- i386 | `-- os | `-- repodata |-- releases | `-- 8 | |-- AddOn | | `-- addon.i386.iso | |-- Everything | | `-- i386 | | `-- os | | |-- all_the.rpms | | `-- repodata | |-- Live | | `-- coolspin.i386.iso | `-- RPMFusion | `-- i386 | |-- iso | | `-- rpmfusion_spin.iso | `-- os | |-- repodata | `-- subset_of_everything.rpms `-- updates |-- 8 | `-- i386 | |-- all_the.rpms | `-- repodata `-- testing `-- 8 `-- i386 |-- all_the.rpms `-- repodata Benefits: - people are used to the layout - room for spins, add-on CDs Disadvantage: - might be more complicated than actually needed Comments? Cu knurd

Matthias Saou wrote: Actually those won't be seperated at the root dir, but even higher at the domain-names AFAIK, the whole idea of the split is to have something for Fedora to point at which is 101% Fedora guidelines compatible except for patents. This should be separated at such a level that users will only see the free part when following the fedora link. Sure we can have something like part of the rpmfusion project on there, which will link to the main rpmforge page, but there needs to be a distinct seperation of the repo's and a seperate (mockup) website for the free repo. This is all done in the hope that Fedora's lawyers will actually allow pointing to patented software in the light of recent High Court verdicts in the US. AFAIK Rahul is loby-ing for this to happen. Regards, Hans

About hosting, why not rr dns (so easy it's insulting: just setup multiple A records in bind zone file...) with every vhosts on both matthias and my server(s) ? I can dedicace space and vhosts on two servers but in the same colo ( 300Mb/s transit + 200Mb/s peering with major french isps) On Thu, 11 Oct 2007 20:10:45 +0200, Thorsten Leemhuis <fedora(a)leemhuis.info&gt; wrote:

On 15.10.2007 11:54, Matthias Saou wrote: We used it for Livna already and it worked without problems. /me would strongly prefer download.rpmfusion.org (just as download.fedoraproject.org). But having ftp.rpmfusion.org in dns as well actually doesn't hurt ;-) Which fill fail with the host that hosts the mirrorlist is down. +1 Cu knurd

Hello, sorry to chime in pretty late... On Mon, 15 Oct 2007, Matthias Saou wrote: [Round-Robin DNS] I think that having a failover in place for our repository is not a bad idea. Mirrorlist is okay if you do not have full control over your mirrors as it is the case with fedora. For livna we are in the lucky position to have at least two distribution sites under full controll in addition to some mirrors. Thus I'd suggest we use the available RR-facility to have a simple DNS round robin to share the load between the different distribution sites and in addition offer a mirrorlist on these RR hosts as well. That way we gain redundancy for our users together with at least half the load per box for us not counting the users which are not pulling from our main distribution site but from our mirrors. You are right however that having a desynched main-site is going to pose a problem. I do not consider that a problem for us in the real world, though: Scripting the repopush to be a near atomic operation is no problem but solved by a tiny shell script called via ssh remote execution. We are internally using some scripts to solve a similar issue where we need to roll out files at different location at the same time. These scripts could be easily adapted or simply rewritten for rpmfusion, a task I'd offer to do. The general setup for rpmfusion would work along the following lines: repopush creates a local repo-tree with the existing rpms and the new ones. We solved that with a simply copy of the old repo and then copied the freshly built files into it, but hardlinking might be a bit easier on the disk-space for rpmfusion. For this repo the necessary repodata files are created by running createrepo on the new tree. The local tree is then rsynced to a temporary directory on the frontend servers. By copying or hardlinking the old files to the temporary tree on the frontend servers the rsync operation only has to transfer the absolute minimum of traffic. The freshly synched temporary repo is then then softlinked to the docroot of the webserver overwriting the symlink to the older repo. That way we have an absolut atomic switch to a new repository with no inconsistency at all. Additionally we gain the ability to keep timestamped backups of the repository. This was one very important feature for us but might not be important for livna. With a bit of serverside-complexity in the repo-push we suddenly have doubled the availability of our infrastructure not yet relying on the additional mirror network. If I were in the office I'd probably say something about a good value-proposition. :-) regards, andreas

On Thu, 18 Oct 2007, Ville Skyttä wrote: Including these calls shouldn't be a problem, we just need to decide on a policy for that. How many versions do we wanna keep et al. --delay-updates and --delete-after work great if you are only syncing one repo. If you need to update two repos atomically you cannot do that with rsync alone anymore as you can never be sure how long each rsync will take. Even if you're starting them at the same time but they finish differently you'll have a desynced repo while the slower sync is finishing. That would make the many good things about a round-robin main distribution site somewhat moot. Thus the ssh remote execution logic. regards, andreas