[Bug 1180689] New: MicroOS defaults to using the SUSE NTP pool
https://bugzilla.suse.com/show_bug.cgi?id=1180689 Bug ID: 1180689 Summary: MicroOS defaults to using the SUSE NTP pool Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other URL: https://openqa.opensuse.org/tests/1545137/modules/ntp_ config_settings/steps/1 OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: MicroOS Assignee: kubic-bugs@opensuse.org Reporter: fvogt@suse.com QA Contact: qa-bugs@suse.de Found By: openQA Blocker: Yes It has to use the opensuse pool instead. Kubic is affected as well: https://openqa.opensuse.org/tests/1545143#step/ntp_config_settings/1 Plain Tumbleweed seems to be fine. ## Observation openQA test in scenario microos-Tumbleweed-DVD-x86_64-microos@64bit fails in [ntp_config_settings](https://openqa.opensuse.org/tests/1545137/modules/ntp_config_settings/steps/...) ## Further details Always latest result in this scenario: [latest](https://openqa.opensuse.org/tests/latest?arch=x86_64&distri=microos&flavor=DVD&machine=64bit&test=microos&version=Tumbleweed) -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1180689 https://bugzilla.suse.com/show_bug.cgi?id=1180689#c1 Richard Brown <rbrown@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |rbrown@suse.com Component|MicroOS |YaST2 Assignee|kubic-bugs@opensuse.org |yast2-maintainers@suse.de QA Contact|qa-bugs@suse.de |jsrain@suse.com --- Comment #1 from Richard Brown <rbrown@suse.com> --- Looks like a YaST bug to me - there is no logic in the control file that sets the default ntp servers, so whatever logic YaST is applying regarding which servers when the skelcd-control-* has <default_ntp_setup config:type="boolean">true</default_ntp_setup> is probably wrong for openSUSE MicroOS (and possibly other openSUSE distributions also) Yastees can you please confirm either my hypothesis is correct, or explain how you expect this to be corrected by skelcd-control-* or such? -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1180689 https://bugzilla.suse.com/show_bug.cgi?id=1180689#c2 Thorsten Kukuk <kukuk@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Component|YaST2 |Other Assignee|yast2-maintainers@suse.de |max@suse.com QA Contact|jsrain@suse.com |qa-bugs@suse.de --- Comment #2 from Thorsten Kukuk <kukuk@suse.com> --- I guess more a packaging bug: | chrony-pool-empty | Empty pool preconfiguration for chrony | package i | chrony-pool-openSUSE | Chrony preconfiguration for openSUSE | package | chrony-pool-suse | Chrony preconfiguration for SUSE | package We have three chrony pool packages, and zypper uses the wrong one. There are ways to tell zypper which chrony-pool-* to prefer depending on the product/release package/branding. Seems this is missing. My guess is adding: Supplements: packageand(chrony:branding-openSUSE) to chrony-pool-openSUSE and packageand(chrony:branding-SLE) to chrony-pool-SUSE would fix this. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1180689 https://bugzilla.suse.com/show_bug.cgi?id=1180689#c3 Martin Pluskal <mpluskal@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mpluskal@suse.com --- Comment #3 from Martin Pluskal <mpluskal@suse.com> --- (In reply to Thorsten Kukuk from comment #2)
I guess more a packaging bug:
| chrony-pool-empty | Empty pool preconfiguration for chrony | package i | chrony-pool-openSUSE | Chrony preconfiguration for openSUSE | package | chrony-pool-suse | Chrony preconfiguration for SUSE | package
We have three chrony pool packages, and zypper uses the wrong one. There are ways to tell zypper which chrony-pool-* to prefer depending on the product/release package/branding. Seems this is missing.
My guess is adding: Supplements: packageand(chrony:branding-openSUSE)
to chrony-pool-openSUSE and packageand(chrony:branding-SLE)
to chrony-pool-SUSE would fix this.
packageand() is deprecated, boolean rpm expressions should be used (and rpm/zypper on all affected distros should be able to handle them), it should be used like: Supplements: (chrony and branding-SLE) -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1180689 Thorsten Kukuk <kukuk@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |1180699 -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1180689 https://bugzilla.suse.com/show_bug.cgi?id=1180689#c4 --- Comment #4 from Reinhard Max <max@suse.com> --- (In reply to Thorsten Kukuk from comment #2)
I guess more a packaging bug:
| chrony-pool-empty | Empty pool preconfiguration for chrony | package i | chrony-pool-openSUSE | Chrony preconfiguration for openSUSE | package | chrony-pool-suse | Chrony preconfiguration for SUSE | package
We have three chrony pool packages, and zypper uses the wrong one. There are ways to tell zypper which chrony-pool-* to prefer depending on the product/release package/branding. Seems this is missing.
It is a bug in the package selection for the respective products. When I was forced to introduce these preconfiguration packages despite of the concerns I had, it was promised to me that it would be made sure that openSUSE and SLE would alsways only contain their respective pool package, but not the other one. That way it would be impossible that the wrong one gets installed. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1180689 https://bugzilla.suse.com/show_bug.cgi?id=1180689#c5 --- Comment #5 from Thorsten Kukuk <kukuk@suse.com> --- (In reply to Reinhard Max from comment #4)
It is a bug in the package selection for the respective products.
When I was forced to introduce these preconfiguration packages despite of the concerns I had, it was promised to me that it would be made sure that openSUSE and SLE would alsways only contain their respective pool package, but not the other one. That way it would be impossible that the wrong one gets installed.
This is solveable for initial installations, correct. This is impossible to solve on zypper level for later installations, because the only way to make sure zypper selects the right package is a hint in the package dependencies. There is no pattern or anything else involved. Please look at any branding package how to tell the solver how to select the right sub-package. This supplements is missing for chrony. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1180689 https://bugzilla.suse.com/show_bug.cgi?id=1180689#c6 --- Comment #6 from Reinhard Max <max@suse.com> --- With "package selection" I don't mean install-time selection, I mean the selection of packages that go onto the media for either openSUSE or SLE. If the wrong package is not on the media (as was promised) it cannot be selected during initial installation or upgrade. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1180689 https://bugzilla.suse.com/show_bug.cgi?id=1180689#c7 --- Comment #7 from Reinhard Max <max@suse.com> --- Again: Why is the "wrong" package on the media at all? It shouldn't be shipped on a product it isn't meant for. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1180689 https://bugzilla.suse.com/show_bug.cgi?id=1180689#c8 Reinhard Max <max@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |NORESPONSE --- Comment #8 from Reinhard Max <max@suse.com> --- No response -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1180689 https://bugzilla.suse.com/show_bug.cgi?id=1180689#c9 Fabian Vogt <fvogt@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|NORESPONSE |--- --- Comment #9 from Fabian Vogt <fvogt@suse.com> --- Closed with "NORESPONSE", but there wasn't a needinfo. Reopening. Comment #3 shows how this can be fixed, but using branding packages is very fragile as those aren't always installed. So I suggest to use conflicts on release packages instead, e.g. Conflicts: product(SUSE_SLE) and Conflicts: product(openSUSE). -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1180689 https://bugzilla.suse.com/show_bug.cgi?id=1180689#c10 --- Comment #10 from Reinhard Max <max@suse.com> --- AFAICS these packaged defaults have done more harm than good, as I was predicting when they were requested initially. So, I am inclined to call these pool packages and packaged defaults a fail, drop them and leave it up to the installers to set defaults (or not) depending on the needs of the respective product, target platform and target audience. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1180689 https://bugzilla.suse.com/show_bug.cgi?id=1180689#c11 --- Comment #11 from Fabian Vogt <fvogt@suse.com> --- (In reply to Reinhard Max from comment #10)
AFAICS these packaged defaults have done more harm than good, as I was predicting when they were requested initially. So, I am inclined to call these pool packages and packaged defaults a fail, drop them and leave it up to the installers to set defaults (or not) depending on the needs of the respective product, target platform and target audience.
I'm fairly confident that when implemented properly (using Conflicts or Requires), they work just fine. Currently the implementation is just incomplete, so the results reflect that. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1180689 https://bugzilla.suse.com/show_bug.cgi?id=1180689#c12 --- Comment #12 from Reinhard Max <max@suse.com> --- I am not only talking about this particular bug which I agree can be solved one way or the other (IMO preferrably by not putting unwanted brandings on the respective media). But there have also been complaints from SLE customers who ran into problems with this preconfiguration in their data centers and who had issues switching to the empty preconfiguration. See bug 1174524. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1180689 https://bugzilla.suse.com/show_bug.cgi?id=1180689#c13 --- Comment #13 from Fabian Vogt <fvogt@suse.com> --- (In reply to Reinhard Max from comment #12)
I am not only talking about this particular bug which I agree can be solved one way or the other (IMO preferrably by not putting unwanted brandings on the respective media).
But there have also been complaints from SLE customers who ran into problems with this preconfiguration in their data centers and who had issues switching to the empty preconfiguration. See bug 1174524.
Which can be addressed by replacing chrony-pool-suse with chrony-pool-empty. "zypper in chrony-pool-empty -chrony-pool-suse" should work for that, and YaST can handle that as well. This configuration could also be handled by YaST, but then it would have to be duplicated in all kiwi images, Yomi, JeOS, possibly SUMA, etc., just to have a default pool. All of them would have to decide which one to use, and that gets messy quickly. So far nobody came up with a better suggestion FWICT. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1180689 https://bugzilla.suse.com/show_bug.cgi?id=1180689#c14 --- Comment #14 from Reinhard Max <max@suse.com> --- (In reply to Fabian Vogt from comment #13)
Which can be addressed by replacing chrony-pool-suse with chrony-pool-empty. "zypper in chrony-pool-empty -chrony-pool-suse" should work for that, and YaST can handle that as well.
Nice syntactic variant that I wasn't aware of so far, but the customer was using different tools (also provided by us) that weren't able to do the switch that easily.
This configuration could also be handled by YaST, but then it would have to be duplicated in all kiwi images, Yomi, JeOS, possibly SUMA, etc., just to have a default pool.
Looks like we simply have too many different installers. ;)
All of them would have to decide which one to use, and that gets messy quickly. So far nobody came up with a better suggestion FWICT.
Well, currently the mess lies in imposing a default that is important for a minority of installations onto the majority of installations for which it is unimportant at best, but often simply undesirable. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1180689 https://bugzilla.suse.com/show_bug.cgi?id=1180689#c15 --- Comment #15 from Reinhard Max <max@suse.com> --- One question regarding the "Supplements" clauses: is it correct to use branding-openSUSE and branding-SLE here, although the pool packages are not branding in the sense of artwork, but rather a technical thing? It would feel more natural to me to use openSUSE-release and SLE-release instead, so that it is based on the product and not on the branding. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1180689 https://bugzilla.suse.com/show_bug.cgi?id=1180689#c16 --- Comment #16 from Richard Brown <rbrown@suse.com> --- (In reply to Reinhard Max from comment #15)
One question regarding the "Supplements" clauses: is it correct to use branding-openSUSE and branding-SLE here, although the pool packages are not branding in the sense of artwork, but rather a technical thing? It would feel more natural to me to use openSUSE-release and SLE-release instead, so that it is based on the product and not on the branding.
'branding' packages are routinely used for convaying configuration settings and not just artwork. Only a small minority of 'branding' packages in our distributions carry artwork. Where as -release packages ONLY carry specific information regarding the -release of a distribution and should NEVER carry any configuration. So, please, use the branding packages, yes. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1180689 https://bugzilla.suse.com/show_bug.cgi?id=1180689#c21 --- Comment #21 from Swamp Workflow Management <swamp@suse.de> --- SUSE-SU-2021:4147-1: An update that solves one vulnerability, contains three features and has 22 fixes is now available. Category: security (moderate) Bug References: 1063704,1069468,1082318,1083597,1099272,1115529,1128846,1156884,1159840,1161119,1162964,1171806,1172113,1173277,1173760,1174075,1174911,1180689,1181826,1183783,1184400,1187906,1190926 CVE References: CVE-2020-14367 JIRA References: SLE-11424,SLE-22248,SLE-22292 Sources used: SUSE OpenStack Cloud Crowbar 9 (src): chrony-4.1-5.9.1 SUSE OpenStack Cloud Crowbar 8 (src): chrony-4.1-5.9.1 SUSE OpenStack Cloud 9 (src): chrony-4.1-5.9.1 SUSE OpenStack Cloud 8 (src): chrony-4.1-5.9.1 SUSE Linux Enterprise Server for SAP 12-SP4 (src): chrony-4.1-5.9.1 SUSE Linux Enterprise Server for SAP 12-SP3 (src): chrony-4.1-5.9.1 SUSE Linux Enterprise Server 12-SP5 (src): chrony-4.1-5.9.1 SUSE Linux Enterprise Server 12-SP4-LTSS (src): chrony-4.1-5.9.1 SUSE Linux Enterprise Server 12-SP3-LTSS (src): chrony-4.1-5.9.1 SUSE Linux Enterprise Server 12-SP3-BCL (src): chrony-4.1-5.9.1 SUSE Linux Enterprise Server 12-SP2-BCL (src): chrony-4.1-5.9.1 HPE Helion Openstack 8 (src): chrony-4.1-5.9.1 NOTE: This line indicates an update has been released for the listed product(s). At times this might be only a partial fix. If you have questions please reach out to maintenance coordination. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1180689 https://bugzilla.suse.com/show_bug.cgi?id=1180689#c23 --- Comment #23 from Swamp Workflow Management <swamp@suse.de> --- SUSE-SU-2022:0845-1: An update that solves one vulnerability, contains one feature and has 12 fixes is now available. Category: security (moderate) Bug References: 1099272,1115529,1128846,1162964,1172113,1173277,1174075,1174911,1180689,1181826,1187906,1190926,1194229 CVE References: CVE-2020-14367 JIRA References: SLE-17334 Sources used: SUSE Linux Enterprise Realtime Extension 15-SP2 (src): augeas-1.10.1-3.9.1 SUSE Linux Enterprise Module for Basesystem 15-SP3 (src): augeas-1.10.1-3.9.1, chrony-4.1-150300.16.3.1 SUSE Linux Enterprise Micro 5.1 (src): augeas-1.10.1-3.9.1, chrony-4.1-150300.16.3.1 SUSE Linux Enterprise Micro 5.0 (src): augeas-1.10.1-3.9.1 SUSE Linux Enterprise Installer 15-SP3 (src): augeas-1.10.1-3.9.1 NOTE: This line indicates an update has been released for the listed product(s). At times this might be only a partial fix. If you have questions please reach out to maintenance coordination. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1180689 https://bugzilla.suse.com/show_bug.cgi?id=1180689#c24 --- Comment #24 from Swamp Workflow Management <swamp@suse.de> --- openSUSE-SU-2022:0845-1: An update that solves one vulnerability, contains one feature and has 12 fixes is now available. Category: security (moderate) Bug References: 1099272,1115529,1128846,1162964,1172113,1173277,1174075,1174911,1180689,1181826,1187906,1190926,1194229 CVE References: CVE-2020-14367 JIRA References: SLE-17334 Sources used: openSUSE Leap 15.3 (src): augeas-1.10.1-3.9.1, chrony-4.1-150300.16.3.1 -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1180689 https://bugzilla.suse.com/show_bug.cgi?id=1180689#c25 --- Comment #25 from Swamp Workflow Management <swamp@suse.de> --- SUSE-SU-2022:0845-2: An update that solves one vulnerability, contains one feature and has 12 fixes is now available. Category: security (moderate) Bug References: 1099272,1115529,1128846,1162964,1172113,1173277,1174075,1174911,1180689,1181826,1187906,1190926,1194229 CVE References: CVE-2020-14367 JIRA References: SLE-17334 Sources used: SUSE Linux Enterprise Micro 5.2 (src): augeas-1.10.1-3.9.1 NOTE: This line indicates an update has been released for the listed product(s). At times this might be only a partial fix. If you have questions please reach out to maintenance coordination. -- You are receiving this mail because: You are on the CC list for the bug.
participants (1)
-
bugzilla_noreply＠suse.com