[uyuni-users] Uyuni release 2020.05 error message with manual reposync
Hello everybody we installed Uyuni 2020.05 from scratch, an update from 4.01 did not work for us. 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. 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 Thanks and best regards Thomas-- To unsubscribe, e-mail: uyuni-users+unsubscribe@opensuse.org To contact the owner, e-mail: uyuni-users+owner@opensuse.org
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 ml#_migrating_the_server_from_4_0_1_to_4_0_2
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.
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?
Thanks and best regards
Thomas-- To unsubscribe, e-mail: uyuni-users+unsubscribe@opensuse.org To contact the owner, e-mail: 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
Pau, thanks for your answer:
Am 01.06.2020 um 16:43 schrieb Pau Garcia Quiles <pau.garcia@suse.com>:
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 1/6/20 a las 15:43, Pau Garcia Quiles escribió:
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?
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! -- Pablo Suárez Hernández - <psuarezhernandez@suse.de> 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
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 - <psuarezhernandez@suse.de> 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
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/ <https://MIRROR_USERNAME:MIRROR_PASS@nu.novell.com/repo/%5C$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
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 <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-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
Hi, of course Suse does not offer MF products. For many MF products (Groupwise etc.) I don't necessarily need an OES, but a SLES. I can use it for this purpose under license law, but I only have support if I have a subscription from Suse. If I am not mistaken, it will not work with two different mirror credentials, the first, primary, is always used. If this primary is the one that existed before the separation of Suse / MF, it works for both. I will test that. Regards Thomas
Am 03.06.2020 um 10:05 schrieb Michael Calmer <mc@suse.de>:
Hi
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 <mailto: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 <mailto:uyuni-users+unsubscribe@opensuse.org> To contact the owner, e-mail: uyuni-users+owner@opensuse.org <mailto:uyuni-users+owner@opensuse.org>
participants (4)
-
Michael Calmer -
Pablo Suárez Hernández -
Pau Garcia Quiles -
Thomas Weis