Docs/Mirrors: Difference between revisions

 
|rsync
|}
 
 
 
It's just a repo that was <code>git pull</code>'d, and was not natively installed on the system via pkg.
 
WhenIf we rebuild mirrors, we should either install it via pkg (if available) or <code>git pull</code> it anew, and place it in <code>/opt/archvsync/</code>
 
===== cron =====
<code>cron</code> calls <code>ftpsync</code> to run at certain times.
 
This is what determines that, say,Arch archLinux is synced with upstream every ~15 minutes, while Debian is only synced four times a day, for example.
 
This should be set according to theeach distribution's official docsrules on mirrorsmirror servers.
 
Most distros want tier 1's to sync 4 times a day, and setwant the exact hours/minutes slightlyset randomly so theythe Tier0's don't get every downstream serverTier1 hammering requests all at once.
 
Currently, this is the schedule Mirrors uses (all times in EST):
 
It has a hardcoded <code>if</code> block pointing to each distro's dataset path, I'm almost certain could just be replaced with <code>root /lug</code> in the <code>server</code> block.
 
 
 
salt.tar.gz contains all the configuration for salt, and the config files it uses to overwrite the config files located in the standard location (as well as the template files it uses to 'build' configs for services like rsyncd and archvsync when a new distro is added to the primary salt config)
 
 
=== Salt ===
Salt used to administer these services, but it's half-broken at the moment and ''should not be reinstalled'' (in my opinion).
 
As such, I think the way Mirrors is setup is essentially perfect, sans salt.
 
 
salt.tar.gz contains all the configuration for salt, and the config files it uses to overwrite the config files located in the standard location (as well as the template files it uses to 'build' configs for services like rsyncd and archvsync when a new distro is added to the primary salt config)