April 2022 - openSUSE Bugs - openSUSE Mailing Lists

[Bug 1197490] Kubic 20220322 fails to set up CNI with weave
by bugzilla_noreply＠suse.com 07 Apr '22

07 Apr '22

https://bugzilla.suse.com/show_bug.cgi?id=1197490 https://bugzilla.suse.com/show_bug.cgi?id=1197490#c32 Robert Munteanu <rombert(a)apache.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(rombert(a)apache.or | |g) | --- Comment #32 from Robert Munteanu <rombert(a)apache.org> --- (In reply to Fabian Vogt from comment #31) > (In reply to Robert Munteanu from comment #30) > > (In reply to Fabian Vogt from comment #29) > > > That looks like the used CNI plugin is still the old broken one. Did the > > > weave-init container run and replace it? > > > > I am not sure about replacing it. Initially the output from the weave-init > > container is > > > > modprobe: can't load module ip_set > > (kernel/net/netfilter/ipset/ip_set.ko.zst): invalid module format > > Ignore the error if "xt_set" is built-in in the kernel > > > > I restarted all pods in the weave daemonset, but that did not help. There is > > no more output from the weave-init container, but the containers are still > > stuck in the ContainerCreating status. > > FWICT, weave-init does > > if [ ! -f "$1/$CNI_PLUGIN_NAME" ]; then > cp /usr/bin/weaveutil "$1/$CNI_PLUGIN_NAME" > fi > > so it doesn't overwrite an existing cni plugin. You can try rm > /opt/cni/bin/weave* and restarting weave-init. That was it, thanks! After performing this operation on all nodes the workloads are slowly recovering. This explains why a new installation worked out of the box, but an upgraded cluster did not work. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1197490] Kubic 20220322 fails to set up CNI with weave
by bugzilla_noreply＠suse.com 07 Apr '22

07 Apr '22

https://bugzilla.suse.com/show_bug.cgi?id=1197490 https://bugzilla.suse.com/show_bug.cgi?id=1197490#c31 Fabian Vogt <fvogt(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags| |needinfo?(rombert(a)apache.or | |g) --- Comment #31 from Fabian Vogt <fvogt(a)suse.com> --- (In reply to Robert Munteanu from comment #30) > (In reply to Fabian Vogt from comment #29) > > That looks like the used CNI plugin is still the old broken one. Did the > > weave-init container run and replace it? > > I am not sure about replacing it. Initially the output from the weave-init > container is > > modprobe: can't load module ip_set > (kernel/net/netfilter/ipset/ip_set.ko.zst): invalid module format > Ignore the error if "xt_set" is built-in in the kernel > > I restarted all pods in the weave daemonset, but that did not help. There is > no more output from the weave-init container, but the containers are still > stuck in the ContainerCreating status. FWICT, weave-init does if [ ! -f "$1/$CNI_PLUGIN_NAME" ]; then cp /usr/bin/weaveutil "$1/$CNI_PLUGIN_NAME" fi so it doesn't overwrite an existing cni plugin. You can try rm /opt/cni/bin/weave* and restarting weave-init. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1198120] Build Service GCC-11: Cross Toolchain for X86_64 (i586) totally useless (missing libgcc)
by bugzilla_noreply＠suse.com 07 Apr '22

07 Apr '22

https://bugzilla.suse.com/show_bug.cgi?id=1198120 https://bugzilla.suse.com/show_bug.cgi?id=1198120#c5 --- Comment #5 from Michael Matz <matz(a)suse.com> --- (In reply to �� from comment #4) > cross-aarch64-gcc7 on Leap 15.3��x86_64) also missing libgcc. > > I got "cannot find -lgcc" message during compiling u-boot for aarch64. That's correct. The transition to proper cross compilers on aarch64 only happened starting with gcc9. But you might want to use gcc11 as the most current released one. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1197490] Kubic 20220322 fails to set up CNI with weave
by bugzilla_noreply＠suse.com 07 Apr '22

07 Apr '22

https://bugzilla.suse.com/show_bug.cgi?id=1197490 https://bugzilla.suse.com/show_bug.cgi?id=1197490#c30 Robert Munteanu <rombert(a)apache.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(rombert(a)apache.or | |g) | --- Comment #30 from Robert Munteanu <rombert(a)apache.org> --- (In reply to Fabian Vogt from comment #29) > That looks like the used CNI plugin is still the old broken one. Did the > weave-init container run and replace it? I am not sure about replacing it. Initially the output from the weave-init container is modprobe: can't load module ip_set (kernel/net/netfilter/ipset/ip_set.ko.zst): invalid module format Ignore the error if "xt_set" is built-in in the kernel I restarted all pods in the weave daemonset, but that did not help. There is no more output from the weave-init container, but the containers are still stuck in the ContainerCreating status. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1198203] New: VUL-1: CVE-2022-24758: python-noteboook: information leak in server logs before 6.4.9
by bugzilla_noreply＠suse.com 07 Apr '22

07 Apr '22

https://bugzilla.suse.com/show_bug.cgi?id=1198203 Bug ID: 1198203 Summary: VUL-1: CVE-2022-24758: python-noteboook: information leak in server logs before 6.4.9 Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.4 Hardware: Other URL: https://smash.suse.de/issue/327810/ OS: Other Status: NEW Severity: Minor Priority: P5 - None Component: Security Assignee: arun(a)gmx.de Reporter: gabriele.sonnu(a)suse.com QA Contact: security-team(a)suse.de Found By: Security Response Team Blocker: --- CVE-2022-24758 The Jupyter notebook is a web-based notebook environment for interactive computing. Prior to version 6.4.9, unauthorized actors can access sensitive information from server logs. Anytime a 5xx error is triggered, the auth cookie and other header values are recorded in Jupyter server logs by default. Considering these logs do not require root access, an attacker can monitor these logs, steal sensitive auth/cookie information, and gain access to the Jupyter server. Jupyter notebook version 6.4.x contains a patch for this issue. There are currently no known workarounds. References: http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-24758 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-24758 https://github.com/jupyter/notebook/security/advisories/GHSA-m87f-39q9-6f55 http://www.cvedetails.com/cve/CVE-2022-24758/ -- You are receiving this mail because: You are on the CC list for the bug.

1 2

[Bug 1197490] Kubic 20220322 fails to set up CNI with weave
by bugzilla_noreply＠suse.com 07 Apr '22

07 Apr '22

https://bugzilla.suse.com/show_bug.cgi?id=1197490 https://bugzilla.suse.com/show_bug.cgi?id=1197490#c29 Fabian Vogt <fvogt(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags| |needinfo?(rombert(a)apache.or | |g) --- Comment #29 from Fabian Vogt <fvogt(a)suse.com> --- (In reply to Robert Munteanu from comment #28) > (In reply to Fabian Vogt from comment #27) > > openQA agrees that weave is fixed: > > https://openqa.opensuse.org/tests/2282201#step/kubead > > Something is still wrong with my Kubic cluster. I upgraded the control plane > + workers to 20220405 , and the pods still fail to create. This time the > message is > > Warning FailedCreatePodSandBox 16m kubelet Failed to > create pod sandbox: rpc error: code = Unknown desc = failed to create pod > network sandbox > k8s_promtail-sfljk_lmn-system_4828843e-a491-4ee6-bce5- > 6a256f2c65cb_0(c14e6bd431ff06ab322887c4b7b17e7cc9c0ea5d39e16a56ee3e5192422511 > 93): error adding pod lmn-system_promtail-sfljk to CNI network "weave": > plugin type="portmap" failed (add): failed to parse config: could not parse > prevResult: could not parse prevResult: result type supports [0.3.0 0.3.1 > 0.4.0] but unmarshalled CNIVersion is "0.1.0" > > I am not sure where that is coming from; /etc/cni/net.d/10-weave.conflist > looks ok in terms of versions: > > { > "cniVersion": "0.3.0", > "name": "weave", > "plugins": [ > { > "name": "weave", > "type": "weave-net", > "hairpinMode": true > }, > { > "type": "portmap", > "capabilities": {"portMappings": true}, > "snat": true > } > ] > } > > I checked and the image that I have locally seems fine: > > $ crictl pull registry.opensuse.org/kubic/weave-kube:2.8.1 > Image is up to date for > registry.opensuse.org/kubic/weave-kube@sha256: > 61b541bb0b05ddf8f58e73fb5e53b6a9a44b6c26bda5edc3719f8445f1acb7e0 > > Do you have any idea about what is going wrong here? That looks like the used CNI plugin is still the old broken one. Did the weave-init container run and replace it? -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1197490] Kubic 20220322 fails to set up CNI with weave
by bugzilla_noreply＠suse.com 07 Apr '22

07 Apr '22

https://bugzilla.suse.com/show_bug.cgi?id=1197490 https://bugzilla.suse.com/show_bug.cgi?id=1197490#c28 --- Comment #28 from Robert Munteanu <rombert(a)apache.org> --- (In reply to Fabian Vogt from comment #27) > openQA agrees that weave is fixed: > https://openqa.opensuse.org/tests/2282201#step/kubead Something is still wrong with my Kubic cluster. I upgraded the control plane + workers to 20220405 , and the pods still fail to create. This time the message is Warning FailedCreatePodSandBox 16m kubelet Failed to create pod sandbox: rpc error: code = Unknown desc = failed to create pod network sandbox k8s_promtail-sfljk_lmn-system_4828843e-a491-4ee6-bce5-6a256f2c65cb_0(c14e6bd431ff06ab322887c4b7b17e7cc9c0ea5d39e16a56ee3e519242251193): error adding pod lmn-system_promtail-sfljk to CNI network "weave": plugin type="portmap" failed (add): failed to parse config: could not parse prevResult: could not parse prevResult: result type supports [0.3.0 0.3.1 0.4.0] but unmarshalled CNIVersion is "0.1.0" I am not sure where that is coming from; /etc/cni/net.d/10-weave.conflist looks ok in terms of versions: { "cniVersion": "0.3.0", "name": "weave", "plugins": [ { "name": "weave", "type": "weave-net", "hairpinMode": true }, { "type": "portmap", "capabilities": {"portMappings": true}, "snat": true } ] } I checked and the image that I have locally seems fine: $ crictl pull registry.opensuse.org/kubic/weave-kube:2.8.1 Image is up to date for registry.opensuse.org/kubic/weave-kube@sha256:61b541bb0b05ddf8f58e73fb5e53b… Do you have any idea about what is going wrong here? -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1198171] New: Missing UTT (update-test-trivial) package in Leap Micro 5.2
by bugzilla_noreply＠suse.com 07 Apr '22

07 Apr '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1198171 Bug ID: 1198171 Summary: Missing UTT (update-test-trivial) package in Leap Micro 5.2 Classification: openSUSE Product: openSUSE Leap Micro Version: 5.2 Hardware: Other OS: Other Status: NEW Severity: Major Priority: P5 - None Component: Transactional Update Assignee: lubos.kocman(a)suse.com Reporter: jalausuch(a)suse.com QA Contact: qa-bugs(a)suse.de CC: fvogt(a)suse.com, mloviska(a)suse.com Found By: --- Blocker: --- Transactional update tests does the following: 1) Download UTT rpm from https://github.com/os-autoinst/os-autoinst-distri-opensuse/blob/master/data… 2) Install it using > transactional-update ptf install update-test-trivial/update-test-security-5-2.29.x86_64.rpm reboot to apply changes 3) Package is installed > # rpm -q update-test-security > update-test-security-5-2.29.x86_64 4) - in SLE Micro: add utt.repo which points to some suse.de repo with another version of that rpm (update-test-security-5.1-4.23.1.x86_64.rpm) - in MicroOS, this package is already available in Factory: https://build.opensuse.org/package/show/devel:openSUSE:Factory/update-test-… 5) Run cleanup > transactional-update cleanup up 6) Reboot to apply changes 7) Package is downgraded > # rpm -q update-test-security > update-test-security-5.1-4.23.1.x86_64 Since we can't use the utt.repo which we use in SLE Micro https://github.com/os-autoinst/os-autoinst-distri-opensuse/blob/master/data… as it points to suse.de, the test fails because that package doesn't exist in Leap Micro repo. I have observed that UTT is available somehow in Leap Micro 5.1 Update repo: https://build.opensuse.org/package/show/openSUSE:Leap:Micro:5.1:Update/upda… It would be great if UTT package can be included in openSUSE:Leap:Micro:5.2 the same way as it's done for Factory. -- You are receiving this mail because: You are on the CC list for the bug.

1 3

[Bug 1198171] Missing UTT (update-test-trivial) package in Leap Micro 5.2
by bugzilla_noreply＠suse.com 07 Apr '22

07 Apr '22

https://bugzilla.suse.com/show_bug.cgi?id=1198171 Marcus Meissner <meissner(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |meissner(a)suse.com -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1198195] VUL-0: CVE-2022-26110: htcondor: mishandled privileges allow possible command injection
by bugzilla_noreply＠suse.com 07 Apr '22

07 Apr '22

https://bugzilla.suse.com/show_bug.cgi?id=1198195 Maintenance Robot <maint-coord+maintenance_robot(a)suse.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Priority|P5 - None |P3 - Medium -- You are receiving this mail because: You are on the CC list for the bug.

1 0