Pau, thanks for your answer:

Am 01.06.2020 um 16:43 schrieb Pau Garcia Quiles :

On dl, 2020-06-01 at 11:30 +0200, Thomas Weis wrote:

...

Hello everybody

we installed Uyuni 2020.05 from scratch, an update from 4.01 did not work for us.

What problem did you have when updating from 4.0.1?

Did you follow the migration steps in the 4.0.2 release notes? https://www.uyuni-project.org/doc/2020.05/release-notes-uyuni-server.ht https://www.uyuni-project.org/doc/2020.05/release-notes-uyuni-server.ht ml#_migrating_the_server_from_4_0_1_to_4_0_2

Ashes on my head, I thought an update from ## 4.02 ## (not 4.01) to 2020.01 did not work. However, the cause is to be found with us and not in the release notes! Our 4.02 installation is an internal pilot, in which we had "tinkered" violently and we had decided that the time spent on troubleshooting would be out of proportion to a new installation. But it works except for the OES2018-SP2 Repos

...

After the first product initialization, the OES2018 Repos cannot be synchronized via the GUI. Since the GPG keys are probably not imported during the first synchronization via the GUI, we synchronize the repos manually, e.g .:

spacewalk-repo-sync -v -c oes2018-sp2-sles12-sp5-pool-x86_64

Under Release 4.01, this worked with OES2018-SP1 *, the keys could then be imported manually.

This is expected. We are working on a solution for this for every non- SUSE vendor.

manual import was not an obstacle in 4.02. A TID from Microfocus exists for the corresponding procedure

...

With 2020.05 we receive the following error message:

Sync of channel started. Get metadata from repository 'oes2018-sp2-sles12-sp5-pool-x86_64' ................................. ................................................. [ Error] Repository 'oes2018-sp2-sles12-sp5-pool-x86_64' is invalid. [oes2018-sp2-sles12-sp5-pool-x86_64 | https: // <mirrorcredential username> @ nu.novell.com / repo / $ RCE / OES2018-SP2-SLES12-SP5- Pool / sle-12-x86_64 /] No valid metadata found at the specified URL Course: - [|] Error while trying to read from 'https: // <mirrorcredential username> @nu.novell.com/repo/$RCE/OES2018-SP2-SLES12-SP5-Pool/sle- 12-x86_64/' - Access to 'https: // <mirrorcredential username> @nu.novell.com/repo/$RCE/OES2018-SP2-SLES12-SP5-Pool/sle-12- x86_64/content' denied. Visit the Novell Customer Center to check that your registration is valid and has not expired.

I mean when you access the repository with

https: // <mirrorcredential username> @ nu.novell.com / repo / $ RCE / OES2018-SP2-SLES12-SP5-Pool / sle-12-x86_64 /

would have to include the URL

https: // <mirrorcredential username>: <mirrorcredential password> @ nu.novell.com / repo / $ RCE / OES2018-SP2-SLES12-SP5-Pool / sle-12- x86_64 /

to be translated?

<mirrorcredential username>: <mirrorcredential password> are of course stored in the Uyuni setup with the correct access data.

where's our mistake

Pablo, could you please take a look. Maybe this broke when we added the additional custom headers for reposync?

if it helps, I can grant remote access to both installations

...

Thanks and best regards

Thomas-- To unsubscribe, e-mail: uyuni-users+unsubscribe@opensuse.org mailto:uyuni-users+unsubscribe@opensuse.org To contact the owner, e-mail: uyuni-users+owner@opensuse.org mailto:uyuni-users+owner@opensuse.org

Thank you

Pau Garcia Quiles SUSE Manager Product Owner & Technical Project Manager Phone: +1 385-666-5608 SUSE Software Solutions Spain N‹§ēæėrļ›y隊[ēšxŪąęėúéėđŧŪ&ÞĒ—§ēëĒļĄĘ'ĩ§-ķĻÂwŦzfĒ–ėŪž+Žzŧ>Ģ ÞŪŠ^žËŽzŠā

Regards Thomas

El 2/6/20 a las 15:29, Pablo Suárez Hernández escribió:

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/

I didn't mention before but be careful with the "$" symbol in the URL, it needs to be escaped with "\" (as in the example) when passing it to "spacewalk-repo-sync" via CLI. -- Pablo Suárez Hernández - SUSE Manager Development Team SUSE Linux GmbH, Maxfeldstr. 5, D-90409 Nürnberg - https://www.suse.com/ GF: Felix Imendörffer, Mary Higgins, Sri Rasiah, HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: uyuni-users+unsubscribe@opensuse.org To contact the owner, e-mail: uyuni-users+owner@opensuse.org

Hi Am Dienstag, 2. Juni 2020, 21:50:56 CEST schrieb Thomas Weis:

...

Am 02.06.2020 um 16:29 schrieb Pablo Suárez Hernández :

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-S LES12-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-S LES12-SP5-Pool/sle-12-x86_64/ <https://MIRROR_USERNAME:MIRROR_PASS@nu.novell.com/repo/%5C$RCE/OES2018-S P2-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?

Well, maybe this is just the consequence of SUSE becoming independent? All customer data had to be splitted in MF and SUSE. Remember that OES is a MF product and you can only access it, when you have mirror credentials from MF which allows you to access their products. The SCC (SUSE Customer Center) do not offer OES as product. So it is expected that you need to configure 2 Mirror Credentials in Uyuni to get access to SUSE and MF products. -- Regards Michael Calmer -------------------------------------------------------------------------- Michael Calmer SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, D-90409 Nuernberg T: +49 (0) 911 74053 0 F: +49 (0) 911 74053575 - e-mail: Michael.Calmer@suse.com -------------------------------------------------------------------------- SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer (HRB 36809, AG Nürnberg) -- To unsubscribe, e-mail: uyuni-users+unsubscribe@opensuse.org To contact the owner, e-mail: uyuni-users+owner@opensuse.org