2

I would like to ask about best practice how to serve and update private rpm repos (epel, centos, rhel mirror).

I used the reposync and createrepo tools to download packages and generate 'repodata', exposed it through webserver, everything works perfect, but ...

What is the best way to update repository ?

Complex way

I was wondering to have symlink in folder structure like this:

/repos/7Server/x86_64/Ref -> /repos/7Server/x86_64/Ref.2016-06-22

So everytime I update repository:

  1. will create copy
  2. sync it with upstream
  3. regenerate metadata
  4. point symlink to most recent version
  5. delete old version (folder)

Metadata will alway match packages and the repository will be in consistent way.

Easy way

But in every documentation I found, people just do simple reposync with delete and update new packages parameter. Don't care about any incosistent state for the clients.

So I am just wondering, which way ist the best, because the simple method can save some time, disk io, configuration & automation complexity.

Thanks for any help.

Maros Mitucha
  • 23
  • 3

1 Answers1

0

That is a valid concern, however the client side is also an issue. The clients also cache the repo information. This means you can still have problems when a client tries to update when the repo has changed, but the client hasn't updated its local cache information yet. So you end up running yum clean all anyway to force them to update their local cache.

So really, worrying about consistency in the repo is okay, but you also have to deal with it on the client side. So I would just update the repo, and clean the cache on the clients.

Also, how often are you updating packages on the clients? You could schedule reposyncs after hours or at times that client updates won't happen.

lsd
  • 1,673
  • 10
  • 10
  • I will be updating the repo once a week. It is just for private dev environment. As I see in 'yum.conf' man, the `metadata_expire` default value is 5h, so no problem with clients yum cache. And sorry, I did not properly understand how you mean the worry about "consistency on the repo side" ? The **Complex way** is good practice, worth the complexity ? – Maros Mitucha Jun 22 '16 at 12:32
  • So I would just update the repo in place. There doesn't seem to be a reason to have links for consistency reason, as there will always be a brief bit of inconsistency anyway, between the time the repo is updated and the time the clients decide to rebuild the cache. At my work, our automation does a `yum clean all; yum makecache fast` before any updates to make sure everything is consistent. – lsd Jun 22 '16 at 12:34
  • Ok perfect, I also like the `easy way` more, easier and elegant to update in place and handle i on clients. Thank you very much. – Maros Mitucha Jun 22 '16 at 12:38