RH Satellite Sync took two months to sync updated packages with clients?
So I've been downloading incremental ISOs from the RH website and importing them into my disconnected RH 5.6 Satellite and from there update my RHEL 5/6 servers. Doing this monthly.
At first the process was working great, however since early August, when loading the updated ISOs into the RH Satellite, none of the new packages were appearing to the clients. I kind of thought something wasn't right, however I've downloaded more ISOs and was going to try again before saying anything. However this morning, I came into work and logged into the RH Satellite and noticed that the clients are all finally seeing the errata and update packages. I have no idea why this is happening.
The Satellite is a VM living in VMWare with the following:
- 8 CPUs
- 16 GB of RAM
- Plenty of HD Space
- As of late July 2015, updates with the latest packages/errata.
The database is external, on another RHEL server which is a VM also living in VMWare and running Oracle.
Right now, there aren't any obvious issues on RH Satellite of the Oracle database as to why this is happening. It takes normal time, around 20 to 30 minutes to process and I write the output to script and don't get any errors.
However if I've been importing incremental ISOs monthly for August and September 2015 and they are finally showing up now, something isn't correct.
I found an older thread about the same type of situation: https://access.redhat.com/discussions/960443
However I wanted to see what other though.
thanks
Responses
I do not think discussion 960443 is relevant.
The problem is the 'errata cache' computation took to long. This is currently
processed by taskomatic. So, either taskomatic wasn't running and not processing
the requests, or there are simply too many requests to regenerate 'errata cache' in
the taskomatic queue.
Lately we saw customers with too many requests in the queue, however we are not sure,
how customers came to that state. We introduced a patch not to create duplicate entries
in the queue (for Sat5.7 only) to keep the queue shorter.
https://bugzilla.redhat.com/show_bug.cgi?id=1227335
There's a hotfix reuqest for Sat 5.6 as well in https://bugzilla.redhat.com/show_bug.cgi?id=1243948. Please, make sure with engineering the hotfix is still applicable on current Sat5.6 if you plan to apply it. In the future there's a risk it may not be applicable, or it may introduce other kind of issues.
a side note, somewhat related, see this discussion https://access.redhat.com/discussions/1597433, and the new base channels are available for RHEL 6.7 for Satellite 5.x. NOTE: that discussion has to do with -disconnected- satellite servers. Just an FYI.
I wouldn't recommend that. Especially for larger number of clients. If your clients work with outdated repository metadata and do not update them, isn't your problem caused by having metadata_expire or a similar option set to a high number? Or, wouldn't setting of metadata_expire to 1 day solve your problem exactly as your current cron job does?
Welcome! Check out the Getting Started with Red Hat page for quick tours and guides for common tasks.
