May 2020 - openSUSE Bugs - openSUSE Mailing Lists

[Bug 1139022] New: fence_rhevm uses the old api of oVirt/RHV
by bugzilla_noreply＠novell.com 12 May '21

12 May '21

http://bugzilla.suse.com/show_bug.cgi?id=1139022 Bug ID: 1139022 Summary: fence_rhevm uses the old api of oVirt/RHV Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.1 Hardware: x86-64 OS: SUSE Other Status: NEW Severity: Normal Priority: P5 - None Component: High Availability Assignee: ha-bugs(a)suse.de Reporter: hunter86_bg(a)yahoo.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Description of problem: Fence agent fence_rhevm is using the old API which will be deprecated on newer versions of oVirt/RHV Version-Release number of selected component (if applicable): git.1537269352.7b1fd536-lp151.1.2.x86_64 How reproducible: Always Steps to Reproduce: 1.Configure a fence agent on openSUSE 15.1 system: primitive fencing stonith:fence_rhevm \ params ipaddr=ovirt-engine.localdomain ipport=443 ssl_insecure=1 ssl=1 login="cluster@internal" passwd="lrm://" pcmk_host_map="node1:node1 node2:node2 node3:node3" pcmk_host_check=static-list pcmk_host_list="node1 node2 node3" power_wait=3 \ op monitor interval=90s 2. Fence a node: crm node fence node2 3.Get a warning in oVirt (4.3.4) as follows: Client from address "192.168.1.38" is using version 3 of the API, which has been deprecated since version 4.0 of the engine, and will no longer be supported starting with version 4.3. It is highly recommended to update the client to use a supported version of the API and the SDKs, before upgrading to version 4.3 of the engine. Actual results: Old API is used , which will soon be completely unusable. Expected results: A newer version of the API to be used. Additional info: RHEL systems do not produce such warning. -- You are receiving this mail because: You are on the CC list for the bug.

2 1

[Bug 1090641] New: kronosnet-1.3 is available now
by bugzilla_noreply＠novell.com 12 May '21

12 May '21

http://bugzilla.suse.com/show_bug.cgi?id=1090641 Bug ID: 1090641 Summary: kronosnet-1.3 is available now Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: High Availability Assignee: ha-bugs(a)suse.de Reporter: bliu(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- kronosnet-1.3 is available now -- You are receiving this mail because: You are on the CC list for the bug.

2 2

[Bug 1153280] New: fillup breaks on some multiline variables
by bugzilla_noreply＠novell.com 12 May '21

12 May '21

http://bugzilla.suse.com/show_bug.cgi?id=1153280 Bug ID: 1153280 Summary: fillup breaks on some multiline variables Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem Assignee: bnc-team-screening(a)forge.provo.novell.com Reporter: jan.fajerski(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- The prometheus node exporter takes cli arguments that can include regular expression strings. For example /etc/sysconfig/prometheus-node_exporter can have content like so: ARGS="-collector.diskstats.ignored-devices=^(ram|loop|fd)\d+$ \ -collector.filesystem.ignored-mount-points=^/(sys|proc|dev|run)($|/) \ -collector.textfile.directory=/var/lib/prometheus/node-exporter" The package https://build.opensuse.org/package/show/server:monitoring/golang-github-pro… recently introduced the use of %fillup_only in its spec file. This however breaks existing sysconfig files. This behaviour can be reproduced by only calling fillup. With the content as listed above in prometheus-node_exporter, a file prometheus-node_exporter.default with this content: ARGS="foo" Calling fillup prometheus-node_exporter prometheus-node_exporter.default prometheus-node_exporter.out produces ARGS="-collector.diskstats.ignored-devices=^(ram|loop|fd)\d+$ \ -- You are receiving this mail because: You are on the CC list for the bug.

2 5

[Bug 1057349] New: postfix/smtpd[3493]: fatal: bad string length 0 < 1: smtpd_sasl_path =
by bugzilla_noreply＠novell.com 12 May '21

12 May '21

http://bugzilla.suse.com/show_bug.cgi?id=1057349 Bug ID: 1057349 Summary: postfix/smtpd[3493]: fatal: bad string length 0 < 1: smtpd_sasl_path = Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem Assignee: bnc-team-screening(a)forge.provo.novell.com Reporter: qingming.su(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- The problem is found by fetchmail, which fails to fetch mail from a remote mailserver (runing postfix+dovecot) The console output looks like: admin@localhost:~> fetchmail -v --ssl mail.openqa.suse fetchmail: 6.3.26 querying mail.openqa.suse (protocol POP3) at Wed 06 Sep 2017 03:12:03 PM CST: poll started Trying to connect to 10.67.18.229/995...connected. fetchmail: Server certificate: fetchmail: Issuer Organization: SUSE fetchmail: Issuer CommonName: openQA CA fetchmail: Subject CommonName: mail.openqa.suse fetchmail: mail.openqa.suse key fingerprint: 4E:FD:84:BE:B5:6C:BF:B0:75:F2:F4:EF:E8:7F:50:9E fetchmail: POP3< +OK Dovecot ready. fetchmail: POP3> CAPA fetchmail: POP3< +OK fetchmail: POP3< CAPA fetchmail: POP3< TOP fetchmail: POP3< UIDL fetchmail: POP3< RESP-CODES fetchmail: POP3< PIPELINING fetchmail: POP3< AUTH-RESP-CODE fetchmail: POP3< USER fetchmail: POP3< SASL PLAIN fetchmail: POP3< . fetchmail: POP3> USER admin fetchmail: POP3< +OK fetchmail: POP3> PASS * fetchmail: POP3< +OK Logged in. fetchmail: POP3> STAT fetchmail: POP3< +OK 2 1446 fetchmail: POP3> LAST fetchmail: POP3< -ERR Unknown command: LAST fetchmail: Unknown command: LAST fetchmail: POP3> UIDL fetchmail: POP3< +OK fetchmail: POP3< 1 00000016599145ec fetchmail: POP3< 2 00000017599145ec fetchmail: POP3< . 2 messages for admin at mail.openqa.suse (1446 octets). fetchmail: POP3> LIST 1 fetchmail: POP3< +OK 1 741 fetchmail: POP3> TOP 1 99999999 fetchmail: POP3< +OK reading message admin@mail.openqa.suse:1 of 2 (741 octets) Trying to connect to ::1/25...connected. <fetchmail hangs here> The system journal disclosures the real issue: Sep 06 15:03:49 localhost postfix/smtpd[3442]: fatal: bad string length 0 < 1: smtpd_sasl_path = Sep 06 15:03:50 localhost postfix/master[2712]: warning: process /usr/lib/postfix/smtpd pid 3442 exit status 1 Sep 06 15:03:50 localhost postfix/master[2712]: warning: /usr/lib/postfix/smtpd: bad command startup -- throttling The error can be fixed by editing the configuration file /etc/postfix/main.cf, comment out the following lines: smtpd_sasl_path = smtpd_sasl_type = Note: the new lines look like: #smtpd_sasl_path = #smtpd_sasl_type = -- You are receiving this mail because: You are on the CC list for the bug.

2 2

[Bug 1037846] New: rpm -qf shows files as part of postfix, despite "files or directories still exist but are no longer part of Postfix"
by bugzilla_noreply＠novell.com 12 May '21

12 May '21

http://bugzilla.suse.com/show_bug.cgi?id=1037846 Bug ID: 1037846 Summary: rpm -qf shows files as part of postfix, despite "files or directories still exist but are no longer part of Postfix" Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem Assignee: bnc-team-screening(a)forge.provo.novell.com Reporter: gp(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- I saw the following when updating postfix the last few times: (18/50) Installing: postfix-3.2.0-4.1.x86_64 .............................[done] Additional rpm output: warning: /etc/postfix/main.cf created as /etc/postfix/main.cf.rpmnew Executing upgrade-configuration. Note: the following files or directories still exist but are no longer part of Postfix: /etc/postfix/postfix-files /etc/postfix/postfix-script /etc/postfix/post-install Updating /etc/sysconfig/postfix ... Updating /etc/sysconfig/mail ... Alas: > rpm -qf /etc/postfix/postfix-files postfix-3.2.0-4.1.x86_64 > rpm -qf /etc/postfix/postfix-script postfix-3.2.0-4.1.x86_64 > rpm -qf /etc/postfix/post-install postfix-3.2.0-4.1.x86_64 Isn't that inconsistent? -- You are receiving this mail because: You are on the CC list for the bug.

2 2

[Bug 1042529] New: YaST submodule windows don't remember their size and position when opened as standalone programs
by bugzilla_noreply＠novell.com 11 May '21

11 May '21

http://bugzilla.opensuse.org/show_bug.cgi?id=1042529 Bug ID: 1042529 Summary: YaST submodule windows don't remember their size and position when opened as standalone programs Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: x86-64 OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: YaST2 Assignee: yast2-maintainers(a)suse.de Reporter: pointedstick(a)zoho.com QA Contact: jsrain(a)suse.com Found By: --- Blocker: --- Steps to reproduce: 1. Open any YaST submodule directly (e.g. search for "Software Management" from KRunner) 2. Adjust the window size and position 3. Close the window 4. Open it again the same way as in 1 Expected results: - The window spawns with the same size and position as it had when you last closed it Actual results: - The window opens at position 0,0 with a size of 1344x771. Additional information: - YaST's main window behaves properly and remembers its position; it's only submodule windows when opened directly that exhibit this issue. -- You are receiving this mail because: You are on the CC list for the bug.

2 3

[Bug 1115436] New: cacti: migrate from cron to systemd timers
by bugzilla_noreply＠novell.com 11 May '21

11 May '21

http://bugzilla.suse.com/show_bug.cgi?id=1115436 Bug ID: 1115436 Summary: cacti: migrate from cron to systemd timers Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: x86-64 OS: openSUSE Factory Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem Assignee: liedke(a)rz.uni-mannheim.de Reporter: kstreitova(a)suse.com QA Contact: qa-bugs(a)suse.de CC: kstreitova(a)suse.com Found By: --- Blocker: --- This bug is part of TRACKERBUG bug#1115430. Based on fate#323635 (Reduce usage of cron package in favor of systemd timers) we would like to minimize the number of packages that use cron in favour of systemd timers. It seems that your package uses cron. Please take a look at it and evaluate if it's possible to migrate your package to use systemd timers without impacting behaviour. If it's not possible, please write down the reason. Please note that by default, services are not enabled when the package is installed. You probably want your service to be enabled by default so you should create a submit request on systemd-presets-branding-openSUSE package, modifying default-openSUSE.preset file by adding "enable your_service_name.service". -- You are receiving this mail because: You are on the CC list for the bug.

2 9

[Bug 1145194] New: network/rsync: stall during duplicity backup over NFS
by bugzilla_noreply＠novell.com 11 May '21

11 May '21

http://bugzilla.opensuse.org/show_bug.cgi?id=1145194 Bug ID: 1145194 Summary: network/rsync: stall during duplicity backup over NFS Classification: openSUSE Product: openSUSE.org Version: unspecified Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: 3rd party software Assignee: tchvatal(a)suse.com Reporter: jon(a)moozaad.co.uk QA Contact: bnc-team-screening(a)forge.provo.novell.com Found By: --- Blocker: --- Created attachment 813627 --> http://bugzilla.opensuse.org/attachment.cgi?id=813627&action=edit command line and strace, bt When backing up a snapshot with duplicity it gets about 16MB in and then hangs. I've tried resetting the backups with fresh instances but the issue is definitely with rsync. The NFS drives it connects to works fine throughout. It stopped working around April/March this year but I don't think it's related to the patch from then. Looking at the trace it seems to be stuck on a chown... ? Maybe related to the % in the files name? Though it appears there's plenty others that transferred fine. -rw------- 1 nobody users 18227 Aug 11 12:38 %gconf-tree-nso.xml -rw------- 1 nobody users 7043 Aug 11 12:38 %gconf-tree-oc.xml -rw------- 1 nobody users 98592 Aug 11 12:38 %gconf-tree-or.xml -rw------- 1 nobody users 87970 Aug 11 12:38 %gconf-tree-pa.xml -rw------- 1 nobody users 65723 Aug 11 12:38 .%gconf-tree-pl.xml.f2lGL8 -- You are receiving this mail because: You are on the CC list for the bug.

2 6

[Bug 1003362] New: server:monitoring/nagios: Bug
by bugzilla_noreply＠novell.com 11 May '21

11 May '21

http://bugzilla.opensuse.org/show_bug.cgi?id=1003362 Bug ID: 1003362 Summary: server:monitoring/nagios: Bug Classification: openSUSE Product: openSUSE.org Version: unspecified Hardware: x86-64 OS: openSUSE 42.1 Status: NEW Severity: Normal Priority: P5 - None Component: 3rd party software Assignee: lars.vogdt(a)suse.com Reporter: ian.mcconnell(a)denbridgemarine.com QA Contact: opensuse-communityscreening(a)forge.provo.novell.com CC: nix(a)opensuse.org Found By: --- Blocker: --- Created attachment 696185 --> http://bugzilla.opensuse.org/attachment.cgi?id=696185&action=edit Fix permissions on command files. nagios creates the following files with the wrong permissions: # ls -l /var/spool/nagios/ srw-rw---- 1 nagios nagios 0 Oct 6 13:47 live prw-rw---- 1 nagios nagios 0 Oct 6 13:47 nagios.cmd For nagvis to access them, they need to be in group "nagcmd" srw-rw---- 1 nagios nagcmd 0 Oct 6 13:47 live prw-rw---- 1 nagios nagcmd 0 Oct 6 13:47 nagios.cmd Since "nagios.cmd" is a named pipe, the permission can be changed once to correct it, but "live" needs changing each time "nagios" is run. The following lines in /etc/nagios/nagios.cfg set these files: command_file=/var/spool/nagios/nagios.cmd broker_module=/usr/lib/check_mk/livestatus-nagios4.o /var/spool/nagios/live I noticed that the file "/usr/lib/nagios/nagios-exec-start-pre" tried to set these permissions by setting the variable nagios_cmdgrp. nagios_cmdgrp="$(get_var nagios_cmdgrp)" but nagois_cmdgrp isn't in /etc/nagios/nagios.cfg. It can't be added as nagios complains about an unknown definition and won't start. Also the line : ${nagios_cmdgrp:-nagcmd} doesn't seem to work for me when /bin/sh is linked to bash /bin/sh --version GNU bash, version 4.2.47(1)-release (x86_64-suse-linux-gnu) nagios_cmdgrp="" echo $nagios_cmdgrp : ${nagios_cmdgrp:-nagcmd} echo $nagios_cmdgrp : ${nagios_cmdgrp:=nagcmd} echo $nagios_cmdgrp nagcmd nagios_cmdgrp="xxxx" : ${nagios_cmdgrp:=nagcmd} echo $nagios_cmdgrp xxxx Unfortunately changing : ${nagios_cmdgrp:-nagcmd} to : ${nagios_cmdgrp:=nagcmd} doesn't fix the permissions on the command files # ls -l /var/spool/nagios/ srw-rw---- 1 nagios nagios 0 Oct 6 14:16 live prw-rw---- 1 nagios nagios 0 Oct 6 14:16 nagios.cmd as these are created after the process "nagios" starts. A workaround is to add the line ExecStartPost=/usr/lib/nagios/nagios-exec-start-post to nagios.service. I have attached the nagios-exec-start-post script. This works with # systemctl start nagios.service # systemctl restart nagios.service but for # systemctl reload nagios.service I get the wrong permissions: # ls -l /var/spool/nagios/ srw-rw---- 1 nagios nagios 0 Oct 6 14:23 live prw-rw---- 1 nagios nagcmd 0 Oct 6 14:16 nagios.cmd These are the nagios packages I installed: nagios-4.2.1-1.1.x86_64 nagios-www-4.2.1-1.1.x86_64 nagios-www-dch-4.2.1-1.1.x86_64 pnp4nagios-0.6.25-6.24.x86_64 pnp4nagios-nagios-0.6.25-6.24.x86_64 nagvis-1.8.5-3.1.noarch mk-livestatus-1.2.8p11-3.2.x86_64 -- You are receiving this mail because: You are on the CC list for the bug.

2 1

[Bug 1029970] New: ksh has binaries in /bin
by bugzilla_noreply＠novell.com 10 May '21

10 May '21

http://bugzilla.opensuse.org/show_bug.cgi?id=1029970 Bug ID: 1029970 Summary: ksh has binaries in /bin Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem Assignee: bnc-team-screening(a)forge.provo.novell.com Reporter: daniel.molkentin(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- ksh has binaries in /bin ksh is one of the remaining packages in Tumbleweed to install binaries to /bin. Please make sure all binaries previously in /usr go to %_bindir (aka /usr/bin), and /bin contains a symlink to those. See https://bugzilla.opensuse.org/show_bug.cgi?id=1029961 for an overview. If you need assistance, don't hesitate to ask. General discussions should happen in the meta bug (see previous link). -- You are receiving this mail because: You are on the CC list for the bug.

2 5