Am 02.06.2020 um 16:29 schrieb Pablo Suárez Hernández <psuarezhernandez@suse.de>:

Hey Pau and Thomas,

the additional custom headers should not interfere here if there is no
custom header defined at "/etc/rhn/spacewalk-repo-sync/extra_headers.conf".


Thomas, what happens if you manually call reposync and passes the mirror
credentials from the CLI?

Something like:

# spacewalk-repo-sync -c oes2018-sp2-sles12-sp5-pool-x86_64 -u
https://MIRROR_USERNAME:MIRROR_PASS@nu.novell.com/repo/\$RCE/OES2018-SP2-SLES12-SP5-Pool/sle-12-x86_64/



Additionally, taking a look at "/var/log/zypper.log" might bring some
more light to the issue.

Hth!

Hey Pablo,

yes, it helped ;-)

# spacewalk-repo-sync -c oes2018-sp2-sles12-sp5-pool-x86_64 -u
https://MIRROR_USERNAME:MIRROR_PASS@nu.novell.com/repo/\$RCE/OES2018-SP2-SLES12-SP5-Pool/sle-12-x86_64/


works correctly and easily with any valid user: password combination for NCC / MFCC.

But I have observed the following:

For the Uyinu Credentials we used the site ID 6616920 for the SCC
With this ID the Repo Sync worked without problems up to 4.02, including OES2018 to OES2018-SP1.
Therefore, we also used the ID for 2020.05, but the repo sync for the OES2018 repos was broken.
Initially, there was another SIte ID in SCC before 6616920, which is exactly the same in the NCC / MFCC. I think this ID was replicated from the NCC to the SCC earlier?
If we now use this first ID in 2020.05, we will easily receive all SLES repos and the OES2018-SPX repos. Of course we have to initiate the OES2018-SPX repos initially with spacewalk-repo-sync to be able to import the GpG keys, but now our 2020.05 works for all SLES subscriptions and in the MFCC.
Maybe there is a break in the background?

Thanks for the food for thought!

Regards
Thomas