July 2022 - openSUSE Bugs - openSUSE Mailing Lists

[Bug 1119619] New: certbot does not renew certificates (again)
by bugzilla_noreply＠novell.com 11 Jul '22

11 Jul '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1119619 Bug ID: 1119619 Summary: certbot does not renew certificates (again) Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: x86-64 OS: openSUSE Factory Status: NEW Severity: Normal Priority: P5 - None Component: Security Assignee: security-team(a)suse.de Reporter: jimc(a)math.ucla.edu QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Formerly I had python-certbot-0.26.1-1.1.noarch and it could renew certs. Now I have python3-certbot-0.28.0-2.1.noarch on OpenSuSE Tumbleweed VERSION="20181208" This is the one with the dependency on python-mock restored/added. It says "No renewals were attempted" on both of my hosts that use certbot. I tracked this down to a (non) migration issue: formerly the state dir was /etc/certbot but now it is /etc/letsencrypt, which of course contains no lineages, so no renewals were attempted. Workaround: mv /etc/letsencrypt /etc/letsencrypt.empty mv /etc/certbot /etc/letsencrypt ln -s letsencrypt certbot The symlink is so explicit filenames in config files, or symlinks in e.g. /etc/openssl/private, will still find the cert and key until I locate and fix them. Tested: my Apache webserver still can authenticate using the (not quite expired) old cert. I ran "certbot renew", its webroot challenges were acceptable (despite some DNAT stuff), and the report was: Congratulations, all renewals succeeded... (list of 1 renewed cert). Testing: the webserver successfully uses the new cert. By the way, old logs are in /var/log/certbot which is still there but is supplanted by /var/log/letsencrypt. It would be nice if the python3-certbot and python2-certbot packages had a migration script for users who are having trouble figuring out why their certs are not being renewed. I'm not sure whether migration scripts in packages should be reported upstream, or to the distro; if the former, let me know and I'll open a ticket upstream. Also I set the component to "security" since the X.509 certificate's purpose is security, but if a different component would be more appropriate please feel free to change it. -- You are receiving this mail because: You are on the CC list for the bug.

2 6

[Bug 1196547] MicroOS Desktop GNOME system role doesn't preinstall language subpackages
by bugzilla_noreply＠suse.com 11 Jul '22

11 Jul '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1196547 http://bugzilla.opensuse.org/show_bug.cgi?id=1196547#c13 --- Comment #13 from Ludwig Nussel <lnussel(a)suse.com> --- (In reply to Alois Wohlschlager from comment #12) > Recommends are, in my book, supposed to be things which are in fact *not* strictly mandatory, but generally useful to have. That's the theory. In practice we ended up with a mess and without soft locks. Now those recommends are just a pita, haunting you if you don't also lock packages :-) They might be ok actually for something like, say FreeCAD, ie some extra app that you will for sure install manually and interactively. So the UI can show you specifically for that app what it recommends. For the thousands of OS components the recommends just lead to not seeing the forest for all the trees though. We'd be better off trying harder to avoid them. > [...] Some concrete examples > TW/MicroOS experience: > * enhanced_base -> plymouth: This is a Recommends, so it's not installed on > MicroOS today. The system works without a boot splash, but it looks nicer > with one. Plymouth needs to be made a requirement for graphical desktops unfortunately. If someone desperately doesn't want it installed, the pattern dragging plymouth in would have to be uninstalled. > (Same with the language magic this issue is about, but I don't > understand how it works exactly. The locale is some kind of virtual provides of the system and packages containing localization files supplement that. Hardware supplements work in a similar way. > * microos_desktop_common -> hplip-hpijs, OpenPrintingPPDs: This is in fact a > Requires today. A desktop system can work without printing if so desired, > but a significant part of the userbase appreciates their printer working. That should neither be required nor recommended. If one plugs a USB printer, hardware supplements are supposed to pull in required packages. I wouldn't be surprised if that's broken (again) on openSUSE though. Also any assumptions about whether or not users with local printers constitute a significant part of the user base are based on pure guessing related to personal bias :-) > As a concrete example again, the x11 -> x11_enhanced -> web_browser > Recommends chain does make sense on traditional systems. On MicroOS not so > much, since you just install the browser using Flatpak. Also in that case the recommends should be removed IMO. Default applications can be pulled in by a specific pattern that is added explicitly by YaST when selecting a desktop via role. No need to express this via dependencies. But then maybe we should also stop treating the traditional desktop install as the Linux desktop demo show we have currently. We can do it like in MicroOS. Basic desktop only, ie fast install. Then have eg opensuse-welcome suggest a bunch of common apps with a nice UI on first boot. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1198331] python-moto: failed on test_boto3_availability_zones test_create_notebook_instance_bad_volume_size
by bugzilla_noreply＠suse.com 11 Jul '22

11 Jul '22

https://bugzilla.suse.com/show_bug.cgi?id=1198331 https://bugzilla.suse.com/show_bug.cgi?id=1198331#c14 --- Comment #14 from Swamp Workflow Management <swamp(a)suse.de> --- SUSE-RU-2022:2355-1: An update that has one recommended fix and contains one feature can now be installed. Category: recommended (moderate) Bug References: 1198331 CVE References: JIRA References: PM-3445 Sources used: openSUSE Leap 15.4 (src): python-cryptography-3.3.2-150400.16.3.1, python-cryptography-vectors-3.3.2-150400.7.3.1 SUSE Linux Enterprise Module for Basesystem 15-SP4 (src): python-cryptography-3.3.2-150400.16.3.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.

1 0

[Bug 1119619] certbot does not renew certificates (again)
by bugzilla_noreply＠suse.com 11 Jul '22

11 Jul '22

https://bugzilla.suse.com/show_bug.cgi?id=1119619 https://bugzilla.suse.com/show_bug.cgi?id=1119619#c11 Dirk Mueller <dmueller(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED OS|openSUSE Factory |All --- Comment #11 from Dirk Mueller <dmueller(a)suse.com> --- assuming this is fixed nowadays? -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1201348] [Build 20220708] transactional update: exit 1 without real indication
by bugzilla_noreply＠suse.com 11 Jul '22

11 Jul '22

https://bugzilla.suse.com/show_bug.cgi?id=1201348 https://bugzilla.suse.com/show_bug.cgi?id=1201348#c4 --- Comment #4 from Fabian Vogt <fvogt(a)suse.com> --- (In reply to Fabian Vogt from comment #3) > (In reply to Dominique Leuenberger from comment #2) > > @Fabien: you mentioned that you had a more recent image available that we > > could use for the update tests? > > > > This image in use is ~ 2 years old - half an eternity for a rolling distro. > > Having a more recent base might be close to reality > > Yep, 20220301, which is reasonable IMO. I swapped it out and triggered a run: > https://openqa.opensuse.org/tests/2462901#step/tdup/11 > > Now it fails in two other ways instead :-/ Time to get into the rabbit hole! libpcre2-8-0 gets updated, which apparently invalidates the semodule cache or something like that. That's the cause of the "regex version mismatch" messages. However, the cache can't be rebuilt for two separate reasons: 1. For some reason, if combustion ran on the first boot, some files in /var/lib/selinux/... get missing (rpm -qV selinux-policy-targeted complains) 2. Avoiding combustion, the files are there, but semodule -B fails anyway: Failed to resolve allow statement at /var/lib/selinux/targeted/tmp/modules/200/container/cil:1257 Failed to resolve AST /usr/sbin/semodule: Failed! This can be reproduced easily by just updating libpcre2-8-0 only and then running semodule -B. Updating policyutils (and libselinux etc.) doesn't help either. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1199895] PackageKit does not honor zypper package locks
by bugzilla_noreply＠suse.com 11 Jul '22

11 Jul '22

https://bugzilla.suse.com/show_bug.cgi?id=1199895 https://bugzilla.suse.com/show_bug.cgi?id=1199895#c17 Michael Andres <ma(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags| |needinfo? --- Comment #17 from Michael Andres <ma(a)suse.com> --- (In reply to Jonathan Kang from comment #16) > ... I think the problem is that they gained "ToBeInstall" status > even they were locked, after doing a "resolver->doUpgrade()" > for tumbleweed. I can hardly imagine how this should happen in PK only. If a locked package has to be amended, the resolver will raise the problem and someone has to select the appropriate solution ('removing the lock' rather than 'drop the jpb'). Is someone able to reproduce it or has a system where this happened? If resolver->doUpgrade() (DUP) was called and the result is committed, zypp should auto-write a testcase. The testcase is named /var/log/updateTestcase-YYYY-MM-DD-hh-mm-ss (date the dup was performed). The pk_backend_zypp[_#] log should also show a line like > ... [zypp] Testcase.cc(createTestcase):388 createTestcase done at /var/log/updateTestcase-2022-07-07-11-06-04 if a testcase was written. If one is available somewhere, it should reveal what happenend during DUP. The corresponding pk_backend_zypp log would be helpfull as well. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1200911] [SELINUX] A denial is observed after upgrading to systemd v251
by bugzilla_noreply＠suse.com 11 Jul '22

11 Jul '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1200911 Martin Li��ka <martin.liska(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |martin.liska(a)suse.com -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1196547] MicroOS Desktop GNOME system role doesn't preinstall language subpackages
by bugzilla_noreply＠suse.com 11 Jul '22

11 Jul '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1196547 http://bugzilla.opensuse.org/show_bug.cgi?id=1196547#c12 --- Comment #12 from Alois Wohlschlager <alois1(a)gmx-topmail.de> --- (In reply to Ludwig Nussel from comment #11) > If you have such a list already, a first approach could also be to try to > simply file sr's to eliminate those recommends. That's what I did in the > past with some packages and generally didn't get much pushback. Mind trying? > :-) I don't really have a list handy, but I definitely can (and in fact planned to) try to create such a list (part of that will involve tracking down the SELinux -> Jupyter madness, which will most likely result in a SR). However, just eliminating these recommends unconditionally won't work, see below why. I will answer your other two points in the opposite order that you have mentioned them, since I think this is more logical. > I'd prefer to get rid of recommends. As OS vendor we > have to decide whether a package is needed or not. A stricter definition of > what is a mandatory part of the OS really helps in other areas too (eg > transactional-update status). That decision was already made, and such a definition already exists: it's called Requires. We already have that situation in today's MicroOS. Recommends are, in my book, supposed to be things which are in fact *not* strictly mandatory, but generally useful to have. Some concrete examples TW/MicroOS experience: * enhanced_base -> plymouth: This is a Recommends, so it's not installed on MicroOS today. The system works without a boot splash, but it looks nicer with one. (Same with the language magic this issue is about, but I don't understand how it works exactly. Emoji fonts and color management are also in this category.) * microos_desktop_common -> hplip-hpijs, OpenPrintingPPDs: This is in fact a Requires today. A desktop system can work without printing if so desired, but a significant part of the userbase appreciates their printer working. With Recommends, everyone can have a good experience, while users can choose to slim their systems down further. In a world without Recommends, this option doesn't exist any more: in order not to bloat everyone's system, many "nice to have" things have to be left out, leading to degraded experience after installation (of course you can install these things after the fact, but that's not user-friendly at all). > Yes that is likely possible via boolean dependencies. I wonder whether it's > really needed though. As a concrete example again, the x11 -> x11_enhanced -> web_browser Recommends chain does make sense on traditional systems. On MicroOS not so much, since you just install the browser using Flatpak. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1197242] server:mail/postfix: postdrop error with enabled SELINUX when sending mail from a systemd service
by bugzilla_noreply＠suse.com 11 Jul '22

11 Jul '22

https://bugzilla.suse.com/show_bug.cgi?id=1197242 https://bugzilla.suse.com/show_bug.cgi?id=1197242#c5 Johannes Segitz <jsegitz(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |IN_PROGRESS Assignee|varkoly(a)suse.com |jsegitz(a)suse.com --- Comment #5 from Johannes Segitz <jsegitz(a)suse.com> --- so this is not a policy issue. transactional-update has a helper that creates some directories upon boot and it's currently missing https://github.com/openSUSE/transactional-update/commit/feaacbac258845a5a86… once this is released this should work directly. There's a minor policy adjustment for the PID files I want to add so I'll take the bug -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1201348] [Build 20220708] transactional update: exit 1 without real indication
by bugzilla_noreply＠suse.com 11 Jul '22

11 Jul '22

https://bugzilla.suse.com/show_bug.cgi?id=1201348 https://bugzilla.suse.com/show_bug.cgi?id=1201348#c3 Fabian Vogt <fvogt(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(fvogt(a)suse.com) | --- Comment #3 from Fabian Vogt <fvogt(a)suse.com> --- (In reply to Dominique Leuenberger from comment #2) > @Fabien: you mentioned that you had a more recent image available that we > could use for the update tests? > > This image in use is ~ 2 years old - half an eternity for a rolling distro. > Having a more recent base might be close to reality Yep, 20220301, which is reasonable IMO. I swapped it out and triggered a run: https://openqa.opensuse.org/tests/2462901#step/tdup/11 Now it fails in two other ways instead :-/ -- You are receiving this mail because: You are on the CC list for the bug.

1 0