[Spacewalk-list] Fwd: spacewalk-repo-sync

Fri Jan 25 21:32:42 UTC 2019

Hello and thanks for your response

I run the commands to re-generate the repomd.xml and I saw in 
taskomatic_daeamon logs and in the respective directories of the 
repositories that the files were recreated.

However, if I rerun the command to synchronize the channel it fails again.

/usr/bin/spacewalk-repo-sync -c centos7_x86_64_ceph1.1
  ======================================
| Channel: centos7_x86_64_ceph1.1
  ======================================
Sync of channel started.

  Processing repository with URL: 
http://download.ceph.com/rpm-luminous/el7/x86_64/
ERROR: Cannot retrieve repository metadata (repomd.xml) for repository: 
centos7_x86_64_ceph1.1. Please verify its path and try again
  Sync of channel completed in 0:00:30.
  Total time: 0:00:30

IINFO: Connected to https://SPACEWALK/rpc/api as USER

Repository Label:                 ceph
Repository URL: http://download.ceph.com/rpm-luminous/el7/x86_64/
Repository Type:                   yum
Repository SSL Ca Certificate:     None
Repository SSL Client Certificate: None

Thanks

V

On 25/01/2019 21:00, Dennis Pittman wrote:
> Hello V,
>
> I think missed the point during my last response.
> Check your configured repos:
>   "spacecmd repo_details centos7_x86_64_ceph"
> or
>   "spacewalk-repo-sync -l" to get a list of software channels with 
> associated repos.
>
> --Dennis P
>
> ------------------------------------------------------------------------
> *From:* Dennis Pittman <djpittma at outlook.com>
> *Sent:* Friday, January 25, 2019 3:52 PM
> *To:* Vasileios Baousis; spacewalk-list at redhat.com
> *Subject:* Re: [Spacewalk-list] Fwd: spacewalk-repo-sync
> Hello V,
>
> There could be several reasons why the repodata "repomd.xml" is not 
> being created or updated.  The simple step would be to look at your 
> taskomatic logs and see where the failure occurs.
>
> EL type hosts log locations are:  "/var/log/rhn"  In there you'll find 
> most of the logs needed to diagnose what's failing.
>
> Here's some other stuff I pulled together from the web and this community.
>
> =====
> How To - Regenerate Spacewalk\Satellite software channel(s) repodata
>
> << Source: 
>  https://www.unixinfo.nl/rh-red-hat-satellite-re-generating-repodata-channel-fix/ 
> >>
> << Source : Redhat Solution 319983 >>
>
> Issue:
>     * Red Hat Satellite is not re-generating repodata for any channel 
> , How to fix and regenerate the repodata ?
>     * On the Red Hat Satellite server repodata is missing under 
> /var/cache/rhn/repodata/channel-label , even after restarting 
> taskomatic service repodata is not getting generated
>     * On the Red Hat Satellite client, yum fails with;
>
>       "Error: Cannot retrieve repository metadata (repomd.xml) for 
> repository: channel-label.
>       Please verify its path and  try again"
>
>     * Difference in Packages Count on satellite and on client for same 
> channel
>
>
> Environment:
>     * Red Hat Satellite
>     * Red Hat Enterprise Linux (RHEL)
>
>
> Resolution:
> Follow the steps below on your Red Hat Satellite server to force 
> repodata generation for any software channel (problematic or not).
>
>     Option 1: Schedule repodata re-generation task for taskomatic 
> daemon using API:
>
>     # spacewalk-api --server=<your Satellite FQDN> --user=<admin user> 
> --password=< paswword> channel.software.regenerateYumCache %session% 
> <Channel Label>
>
>     Note: Replace satellite server hostname , username/password and 
> channel label with proper values.
>     If there is more than one affected channel, then run this command 
> multiple time with different channel labels.
>
>     Example: To re-generate repodata for 
> rhn-tools-rhel-x86_64-server-6 channel you can use this command:
>
>     # spacewalk-api --server=sw.sciquest.com --user=sciquest1 
> --password=secret channel.software.regenerateYumCache %session% 
> rhel6-rhn-tools-x86_64-20180618
>
>     Option 2: Force execution of the scheduled task
>
>     - Login to `RH Satellite` WebUi
>     - Click on `Admin` tab
>     - Click on `Task Schedules` on left hand menu
>     - Click on `Channel-repodata-bunch`
>     - Click on button "Single Run Schedule"
>
>     Monitor /var/log/rhn/rhn_taskomatic_daemon.log file on the 
> spacewalk server for progress of the repodata re-generation and 
> confirm whether repodata files got created under 
> /var/cache/rhn/repodata/channel-label directory or not.
>
>     # ls -l /var/cache/rhn/repodata/<channel-label>
>
>
>     Note:  Initially we can see files with ".new" extension which 
> means that repodata re-generation is in progress.
>     Once the ".new" extension is removed, this means that repodata 
> generation has completed.
>
>     After the above steps are completed you can run the below 
> mentioned commands on the client and confirm Channel contents are 
> available to the client or not:
>
>     # yum clean all
>     # yum repolist
>
> --Dennis P
>
>
> ------------------------------------------------------------------------
> *From:* spacewalk-list-bounces at redhat.com 
> <spacewalk-list-bounces at redhat.com> on behalf of Vasileios Baousis 
> <bbaous at gmail.com>
> *Sent:* Friday, January 25, 2019 3:41 PM
> *To:* spacewalk-list at redhat.com
> *Subject:* [Spacewalk-list] Fwd: spacewalk-repo-sync
> Hello,
>
> After my spacewalk upgrade to 2.9 all my channel synchronizations are 
> failing . e.g
>
> /usr/bin/spacewalk-repo-sync -c centos7_x86_64_ceph -t yum
>
> Processing repository with URL: 
> http://download.ceph.com/rpm-luminous/el7/x86_64/ 
> <https://nam05.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdownload.ceph.com%2Frpm-luminous%2Fel7%2Fx86_64%2F%3Ffbclid%3DIwAR1aUnNiBiKu_SCxkWCK2GH48PZwKDshJdxHzBZ64uoiDVQ9ecjKhlN7izY&data=02%7C01%7C%7C65793e5366b44996dc4c08d683058820%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636840457109278687&sdata=QjwWNn7jcwgE4ba%2BKbYBvmVuj69ubwpc0VxwlWzvDN0%3D&reserved=0>
>
>
> ERROR: Cannot retrieve repository metadata (repomd.xml) for 
> repository: centos7_x86_64_ceph1.1. Please verify its path and try again
>
> All the channel sync used to work properly before the upgrade.
>
> Any suggestions?
> Thanks
>
> V
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/spacewalk-list/attachments/20190125/cec4ac5c/attachment.htm>