I created a hosted YUM repository. In the build process I pushed a number of RPMs into it. In the initial push, the repodata folder was generated after about 1-2 minutes. From a CentOS VM I ran the YUM client to list the content of the repo. All was good. I updated the version names of my RPM packages and did another push. I waited for about 5 minutes and ran YUM once more from my VM. The new packages were not listed. From the host, I browsed the repo into the repodata folder and I noticed the blob date/time stamps of the items in the folder had not been updated. What can I do to resolve this problem?
Do you mean the packages are not listed when browsing NXRM or when searching via the yum client?
There is a task that you can run to repair the metadata files if something has gone wrong called “Repair - Rebuild Yum repository metadata (repodata)”. I’d be interested to know more about how your repository got into that state though - Did you get any exceptions in your nexus.log file?
When searching for the updates executing [ # yum list ] at the console window in the VM. I’ll check the log. I setup a repo on CentOS 7 and Windows 7 pro. Same behavior. Executing YUM client will not display any updated packages. I did build a task to repair the metadata. I’m watching to see what happens.
We’ve had similar reports in the past and it has been a case of people needing to clear their local Yum cache yum clean all. What made me hesitate to suggest that was that you saw the times were not updated on the metadata assets - but worth a try.
I think creating the scheduled task might have done the trick. I’ll do some more testing and monitoring in the next few hours and report back. Thanks for the quick replies.
No problem. If that fixes it sounds like a bug in the automated process - if you could file a ticket at https://issues.sonatype.org/secure/Dashboard.jspa and include a support zip by following the instructions here Support Features (note: tickets are secure by default and only you and sonatype can see it and the contents of the support zip).
I was too quick to claim success. I set the task schedule to update every 2 minutes. I also push more RPMs into the repo. But nothing updated. I even executed “yum clean && yum makecache” (which I should not have to do) from a console on the VM. Yum is still displaying the old packages. Yes, I’ll submit a ticket.
@tekknj833 Another thing to be aware of is https://issues.sonatype.org/browse/NEXUS-17263 which makes it look like the task has finished before it actually has.
Another thing you can try is disabling the cache option in the task - this will be much slower (depending on how many RPMs you have) but it will rebuild the metadata from scratch by scanning all RPMs in your repository.
I think I figured out something about yum that wasn’t really apparent to me. when I execute ‘yum list’, it displays the packages in columns as: $name.$arch, $version.$release, $repo
When I pushed my updated RPM packages I did not change the name or architecture. On the NX host for example, I would have multiple RPMs and the only difference being the version. I took a guess and deleted the older RPMs. Then waiting for the yum cache to expire on the client. I executed ‘yum list’ and the updated RPMs were displayed.
Is this the proper way that yum works?
I can never see the following:
mytestrpm.x86_64 1.2.2-1.el7
mytestrpm.x86_64 1.3.3-1.el7 (this is the rpm I expected to see displayed)
But if the architecture value is different then I can see:
mytestrpm.i686 1.2.2-1.el6
mytestrpm.x86_64 1.2.2-1.el7
Last, is there an automated way to clean up older RPMs on the host when updated RPMs arrive?
Or the trick is to somehow get the NXRM host and yum client to the list latest version. Which I can’t seem to make happen.
@tekknj833 I’ve just tested this and yum list is correctly displaying the latest version of the package I upload. You could take a look in the primary.xml file to check that the version numbers listed are what you expect. You could also try using yum list available --showduplicates to show you all versions of available packages.
There is no way to clean up older RPMs when updated RPMs arrive. We are working on a new cleanup feature that will initially be able to delete by age and last downloaded time (likely to be released in the next version) and in a future iteration of this feature we will be adding “keep n versions of packages”.
Thanks. Here’s what I discovered this morning. Running ‘yum clean expire-cache’ appears to resolve my problem. I did add the parameter ‘metadata_expire=1m’ in my yum.conf but the yum cache just does not keep pace with the revision changes on the host. Seems I have to force the cache update to see the latest revisions of the rpms. In addition, I have a NXRM yum rebuild metadata task running. I now feel confident that the issue lies with yum and not NXRM3.
Additional info:
Browsing the hosts I have the following rpms.
mytestrpm.x86_64 1.2.2-1.el7
mytestrpm.x86_64 1.3.3-1.el7
mytestrpm.x86_64 1.4.4-1.el7
mytestrpm.x86_64 1.5.5-1.el7
When I run ‘yum list available’, I get: mytestrpm.x86_64 1.5.5-1.el7
After the NXRM rebuild meta-data task runs and the I run ‘yum clean expire-cache’.
My last experiment was to create a cronjob with ‘yum clean expire-cache’ every hour so the cache stays in sync with the hourly NXRM task. Now when new revisions are published I always see the current rpms on the clients.
Has this been released, or still on the roadmap?
Would very much like the “keep n versions of packages” feature.
2 Likes