Am 20.10.2014 um 13:57 schrieb Nico Kadel-Garcia:
On Mon, Oct 20, 2014 at 4:22 AM, Reindl Harald <h.reindl@xxxxxxxxxxxxx> wrote:Am 20.10.2014 um 04:02 schrieb Nico Kadel-Garcia:On Sun, Oct 19, 2014 at 5:26 AM, Reindl Harald <h.reindl@xxxxxxxxxxxxx> wrote:Am 19.10.2014 um 06:37 schrieb Nico Kadel-Garcia:On Sat, Oct 18, 2014 at 8:28 PM, Reindl Harald <h.reindl@xxxxxxxxxxxxx> wrote:It starts with the the fact that your script has not verified *any* of your RPM's, and reposync does not ordinarily verify file contents unless you activate GPG verification. So any partial transfer or interrupted transfer will effectively corrupted your local repo, especially if anything else is dependent on that package. Do take a look at the github scripts I pointed out, they do a more thorough job.what are you talking about reposync all the time?You've a point, I was misreading your script.
now we come together :-) not that it is a large or complex script
frankly i have posted the whole source above "/buildserver/repo-create.sh" can be read as "createrepo && chown && chmod && rsync-to-failover maschine on the cluster"Mind you, putting this stuff in places like "/repo/cache" and "/buildserver" is a direct violation of the file system hierarchy, but that's your own local policy and potential problem.
that are just symlinks and having that folders not in the FHS means never ever some package will start to use them - so violate the FHS is by intention also as mountpoints for datadisks /Volumes/dune
*/var/cache/yum/* is the source *after* ran updates on that machine ordinary with yum - guess what - after that suceeded the RPM's GPG verified and *that* is what i try to explain the whole time - yum don't need to know about deltarpm and so other scripts using the yum-cache don't tooI do think you'd be much better off with using rsync and a local mirror. You can point it to architectures and OS releases you aren't currently running, and point it to include all potential updates. Even your your setup, you can use 'yum --doanloadonly' and 'yum install *' to ensure the presence of more packages in /var/cache/yum
no because anything wich touchs the infarstructure is tested or in a lot of cases built on that machine (sample setups and so on) and there is no need for anything more starting 2008 on F9 until now upgraded with yum to F20 on around 30 machines
Last, doing this on an individual machine does not scale You're chewing up disk space on each machine, and bandwitdh, with all the required 'repodata' downloadsWTF - no single other machine has *any* repo in the WAN configured*That* part was missing. You've configured your local hosts to all point to an individual mirror? And that local repo has *all* packages you might possibly install on the other machines?
no it was not, please go back to the first message you responded tothe idea doing what i described is to not have any machine touch repos in the internt and so after test a update which don't work on the buildserver results in delete it instead push to the local repo so no other machine can see it - frankly if you build up a maitained infrastructure you don't want that one server has a chance to pull a more recent mirror and update stuff you have never seen in the QA
the first message you responded to had the following paragraph you even quoted
>> that few lines below are enough to use createrepo and >> build up a local cache without mirror the whole upstream, >> you just need to have one machine with any pakcge you >> use installed on it - works perfect over 6 years including >> dist-upgrades *and* benefits from deltarpm in the first step as well follow-up quotes from you contained >> * that single machine has all used packages installed >> * that single machine builds a repo below /repo/cache/fc$releasever/ >> * that repo don't mirror blindly anything, just used RPM's >> * that RPMs are the result *after* apply deltarpm out of yum cache
Attachment:
signature.asc
Description: OpenPGP digital signature
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
