November 2020 - openSUSE Bugs - openSUSE Mailing Lists

[opensuse-bugs] [Bug 1178655] Failed to start The PHP FastCGI Process Manager.
by bugzilla_noreply＠suse.com 13 Nov '20

13 Nov '20

https://bugzilla.suse.com/show_bug.cgi?id=1178655 https://bugzilla.suse.com/show_bug.cgi?id=1178655#c13 --- Comment #13 from Petr Gajdos <pgajdos(a)suse.com> --- (In reply to Petr Gajdos from comment #10) > For further testing, the config file used in the test is just > [global] > pid = ~/php-fpm.pid > error_log = ~/php-fpm.log > > [www] > listen = 127.0.0.1:60009 > pm = dynamic > pm.max_children = 5 > pm.start_servers = 2 > pm.min_spare_servers = 1 > pm.max_spare_servers = 3 > > But so far it does not matter, of course. This is not correct, apologize, ~ could be replaced by /home/<USER> or something like that. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[opensuse-bugs] [Bug 1178655] Failed to start The PHP FastCGI Process Manager.
by bugzilla_noreply＠suse.com 13 Nov '20

13 Nov '20

https://bugzilla.suse.com/show_bug.cgi?id=1178655 https://bugzilla.suse.com/show_bug.cgi?id=1178655#c12 --- Comment #12 from Petr Gajdos <pgajdos(a)suse.com> --- It was, however, turning it off does not help: pgajdos@test:~[0]> /usr/sbin/php-fpm --fpm-config php-fpm.conf [13-Nov-2020 13:38:29] ERROR: failed to open configuration file 'php-fpm.conf': Permission denied (13) [13-Nov-2020 13:38:29] ERROR: failed to load configuration file 'php-fpm.conf' [13-Nov-2020 13:38:29] ERROR: FPM initialization failed pgajdos@test:~[78]> systemctl status apparmor �� apparmor.service - Load AppArmor profiles Loaded: loaded (/usr/lib/systemd/system/apparmor.service; enabled; vendor preset: enabled) Active: active (exited) since Thu 2020-11-12 11:36:57 CET; 1 day 2h ago Main PID: 485 (code=exited, status=0/SUCCESS) Tasks: 0 (limit: 4915) CGroup: /system.slice/apparmor.service Nov 12 11:36:57 linux-hi1k apparmor.systemd[485]: Restarting AppArmor Nov 12 11:36:57 linux-hi1k apparmor.systemd[485]: Reloading AppArmor profiles Nov 12 11:36:57 linux-hi1k systemd[1]: Finished Load AppArmor profiles. pgajdos@test:~[0]> sudo systemctl stop apparmor pgajdos@beth:~[0]> /usr/sbin/php-fpm --fpm-config php-fpm.conf [13-Nov-2020 13:38:59] ERROR: failed to open configuration file 'php-fpm.conf': Permission denied (13) [13-Nov-2020 13:38:59] ERROR: failed to load configuration file 'php-fpm.conf' [13-Nov-2020 13:38:59] ERROR: FPM initialization failed pgajdos@beth:~[78]> -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[opensuse-bugs] [Bug 961804] The module Remote Administration (VNC) crash X server
by bugzilla_noreply＠suse.com 13 Nov '20

13 Nov '20

https://bugzilla.suse.com/show_bug.cgi?id=961804 https://bugzilla.suse.com/show_bug.cgi?id=961804#c4 Martin Caj <mcaj(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|CONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #4 from Martin Caj <mcaj(a)suse.com> --- Yes please close it. thanks Martin -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[opensuse-bugs] [Bug 1178655] Failed to start The PHP FastCGI Process Manager.
by bugzilla_noreply＠suse.com 13 Nov '20

13 Nov '20

https://bugzilla.suse.com/show_bug.cgi?id=1178655 https://bugzilla.suse.com/show_bug.cgi?id=1178655#c11 --- Comment #11 from Marcus Meissner <meissner(a)suse.com> --- is apparmor active? -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[opensuse-bugs] [Bug 1178741] New: VUL-0: tor: ed25519 identity not checked when competing a channel (TROVE-2020-005)
by bugzilla_noreply＠suse.com 13 Nov '20

13 Nov '20

http://bugzilla.opensuse.org/show_bug.cgi?id=1178741 Bug ID: 1178741 Summary: VUL-0: tor: ed25519 identity not checked when competing a channel (TROVE-2020-005) Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.2 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Security Assignee: bwiedemann(a)suse.com Reporter: Andreas.Stieger(a)gmx.de QA Contact: qa-bugs(a)suse.de CC: security-team(a)suse.de Found By: --- Blocker: --- Fixed in tor 0.3.5.12, 0.4.3.7, 0.4.4.6 TROVE-2020-005: In certain cases an adversary to observe traffic patterns on a limited number of circuits intended for a different relay. o Major bugfixes (security, backport from 0.4.5.1-alpha): - When completing a channel, relays now check more thoroughly to make sure that it matches any pending circuits before attaching those circuits. Previously, address correctness and Ed25519 identities were not checked in this case, but only when extending circuits on an existing channel. Fixes bug 40080; bugfix on 0.2.7.2-alpha. Resolves TROVE-2020-005. circuit_n_chan_done() checked rsa identity digest, but not ed25519 identity or is_canonical. References: https://gitlab.torproject.org/tpo/core/tor/-/issues/40080 https://lists.torproject.org/pipermail/tor-announce/2020-November/000206.ht… -- You are receiving this mail because: You are on the CC list for the bug.

1 2

[opensuse-bugs] [Bug 1178743] New: AutoYast parses non existing rules.xml
by bugzilla_noreply＠suse.com 13 Nov '20

13 Nov '20

http://bugzilla.opensuse.org/show_bug.cgi?id=1178743 Bug ID: 1178743 Summary: AutoYast parses non existing rules.xml Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: x86-64 OS: Linux Status: NEW Severity: Normal Priority: P5 - None Component: AutoYaST Assignee: yast2-maintainers(a)suse.de Reporter: hubba(a)unixcook.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- I do autoinstallations via HTTP so I append autoyast=http://blah/blah/ to the boot options and I expect the autoyast profile to be picked up vi the mac address which I can see happening fine. When trying to do autoyast installations via mac address or IP address autoyast will also try to retrieve a rules.xml file which is the correct behavior from the documentation. However I do not have a rules.xml file and the web server (apache) correctly returns a 404 error. autoyast does retrieve the error page though and then fauls over as it tries to parse it as an XML file. AutoYast should honor the 404 error and not try to parse the error page which is obviously in HTML. If I point tumbleweed to http://blah/blah/blah.xml it will not try to do its magic with rules and the installation proceeds as expected. My tumble weed repos where last synced earlier today on the 12th of November 2020. Best regards Hubba -- You are receiving this mail because: You are on the CC list for the bug.

1 3

[opensuse-bugs] [Bug 1176692] gpg --recv-keys error
by bugzilla_noreply＠suse.com 13 Nov '20

13 Nov '20

https://bugzilla.suse.com/show_bug.cgi?id=1176692 https://bugzilla.suse.com/show_bug.cgi?id=1176692#c7 Christoph Wickert <cwickert(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|fs(a)suse.com |cwickert(a)suse.com --- Comment #7 from Christoph Wickert <cwickert(a)suse.com> --- You are welcome! Last but not least: This is a wiki, a collaborative effort. If you like, go ahead change it yourself. You were the one who ran into trouble, I would never have found the problem because of my configuration. So even if I dislike hardcoding a particular server, it might make sense. Feel free to change the wiki yourself! -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[opensuse-bugs] [Bug 1178727] pam_unix contains uninitialized var leading to bogus password expiry warning
by bugzilla_noreply＠suse.com 13 Nov '20

13 Nov '20

https://bugzilla.suse.com/show_bug.cgi?id=1178727 https://bugzilla.suse.com/show_bug.cgi?id=1178727#c1 Josef M�llers <josef.moellers(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |IN_PROGRESS --- Comment #1 from Josef M�llers <josef.moellers(a)suse.com> --- Thanks Michael, Factory - https://build.opensuse.org/request/show/848315 SUSE:SLE-15:Update - https://build.suse.de/request/show/230626 SUSE:SLE-12:Update - https://build.suse.de/request/show/230628 -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[opensuse-bugs] [Bug 1178738] haveged command mode dubious
by bugzilla_noreply＠suse.com 13 Nov '20

13 Nov '20

http://bugzilla.opensuse.org/show_bug.cgi?id=1178738 http://bugzilla.opensuse.org/show_bug.cgi?id=1178738#c3 --- Comment #3 from Michal Suchanek <msuchanek(a)suse.com> --- Trigger what? I suppose any client that opens a socket connection and immediately closes it would crash haveged. I did not really test it, though. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[opensuse-bugs] [Bug 1151174] udev-configure-printer and hplip interference: HP LaserJet 1018 printer configured, but fails to print: io/hpmud/musb.c 153: unable get_string_descriptor
by bugzilla_noreply＠suse.com 13 Nov '20

13 Nov '20

https://bugzilla.suse.com/show_bug.cgi?id=1151174 https://bugzilla.suse.com/show_bug.cgi?id=1151174#c5 --- Comment #5 from Martin Wilck <martin.wilck(a)suse.com> --- (In reply to Mindaugas Baranauskas from comment #2) > I still had the same bug in openSUSE Leap 15.2. > Finally I found more reliable SULUTION for openSUSE Leap 15.2: > simply REMOVE "udev-configure-printer" package > ...and then it will no longer interfere with hplip. Seems > udev-configure-printer reinitiallizes communication when plugged in to the > USB port, and by doing so interupted normal hplip work. Yes, that makes sense. (In reply to Mindaugas Baranauskas from comment #3) > Maybe udev-configure-printer should check whether hplip is installed and > then ignore all printers managed by hplip? Maybe this would allow > udev-configure-printer and hplip to co-exist, but without interference? Uploading the FW seems to be a time-consuming operation. Arguably, doing that in an udev rule is wrong. So the error is probably on the hplip side here. The "right thing" to do would be to introduce some generic udev variable similar to SYSTEMD_READY=0 that udev-configure-printer would recognize as a warning no to touch the device. The FW upload process should be handled by some daemon in the background. When it's finished and the printer is operational, another uevent could be triggered, and udev-configure-printer would then hopefully be able to deal with the printer in healthy status. (In reply to Johannes Meixner from comment #4) > Martin Wilck, > FYI see in particular > https://bugzilla.opensuse.org/show_bug.cgi?id=1151174#c2 > > This issue here is yet another example where automated actions > when pug-in a USB printer (here what udev-configure-printer does) > could cause more harm than good in some cases. Right. I think we could cover this specific case, but avoiding such issues generally will be hard. -- You are receiving this mail because: You are on the CC list for the bug.

1 0