November 2013 - openSUSE Bugs - openSUSE Mailing Lists

[Bug 835815] New: Redis init script ignores bind address on stop
by bugzilla_noreply＠novell.com 28 Jun '16

28 Jun '16

https://bugzilla.novell.com/show_bug.cgi?id=835815 https://bugzilla.novell.com/show_bug.cgi?id=835815#c0 Summary: Redis init script ignores bind address on stop Classification: openSUSE Product: openSUSE 12.3 Version: Final Platform: x86-64 OS/Version: openSUSE 12.3 Status: NEW Severity: Normal Priority: P5 - None Component: Other AssignedTo: bnc-team-screening(a)forge.provo.novell.com ReportedBy: thomas(a)cupracer.de QAContact: qa-bugs(a)suse.de Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/27.0.1453.110 Safari/537.36 Redis may be configured to not listen to all network interfaces, but to a single one, like: # If you want you can bind a single interface, if the bind option is not # specified all the interfaces will listen for incoming connections. # bind 10.0.1.107 The problem is that the corresponding init script tries to stop Redis by using "redis-cli" with $PASS and $PORT as parameters. The configured bind address is missing here, so it just tries 127.0.0.1 and fails to connect to Redis. The bind address has to be added here. Something like this has to be added in /etc/init.d/redis: stop() { .. BIND=`grep ^bind $CONFIG | awk '{print $2}'` [ -n "$BIND" ] && CLI="$CLI -h $BIND" .. } Reproducible: Always Steps to Reproduce: 1. Configure Redis as usual. 2. Add "bind <some-non-lo-ip>" to the config file. 3. Start Redis: /etc/init.d/redis start 4. Make sure that Redis is running. 5. Try to stop Redis: /etc/init.d/redis stop Actual Results: The init script fails to Stop Redis as it doesn't know the correct bind address. Expected Results: The init script should stop Redis by connecting to its bind address. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

1 11

[Bug 673937] New: apache2: provide rpm macros file for 3rd party modules
by bugzilla_noreply＠novell.com 28 Jun '16

28 Jun '16

https://bugzilla.novell.com/show_bug.cgi?id=673937 https://bugzilla.novell.com/show_bug.cgi?id=673937#c0 Summary: apache2: provide rpm macros file for 3rd party modules Classification: openSUSE Product: openSUSE 11.4 Version: Factory Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: P5 - None Component: Apache AssignedTo: bnc-team-apache(a)forge.provo.novell.com ReportedBy: lnussel(a)novell.com QAContact: qa(a)suse.de Found By: --- Blocker: --- 3rd party modules currently have code like this in the .spec file: %define apxs /usr/sbin/apxs2 %define apache_libexecdir %(%{apxs} -q LIBEXECDIR) Stuff like that should be put into a macro file with pre-computed values. e.g. /etc/rpm/macros.apache2 that is provided by apache2-devel. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

1 4

[Bug 597744] New: alpine: Missing umlaut in date column: our_strftime does not always return utf8-encoded strings
by bugzilla_noreply＠novell.com 28 Jun '16

28 Jun '16

http://bugzilla.novell.com/show_bug.cgi?id=597744 http://bugzilla.novell.com/show_bug.cgi?id=597744#c0 Summary: alpine: Missing umlaut in date column: our_strftime does not always return utf8-encoded strings Classification: openSUSE Product: openSUSE 11.1 Version: Final Platform: x86-64 OS/Version: openSUSE 11.1 Status: NEW Severity: Normal Priority: P5 - None Component: Other AssignedTo: bnc-team-screening(a)forge.provo.novell.com ReportedBy: kdevel(a)vogtner.de QAContact: qa(a)suse.de Found By: --- Blocker: --- User-Agent: Alpine does not correctly encode non-utf-8-data from locale's time and date formatting. Reproducible: Always Steps to Reproduce: 1. open console/xterm with 8-Bit character encoding (i.e. ISO-8859-1) 2. start alpine with LANG=de_DE@euro 3. have an e-mail in your inbox with a date of March. Actual Results: The Date displayed is "M" Expected Results: "Mär" strftime may return non-utf8 data if operated in a non-utf8 environment. In The non-WINDOWS-case no change of encoding to utf8 is performed in our_strftime (pith/string.c) but utf8 is expected from functions calling our_strftime. -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

1 14

[Bug 558841] New: alpine: incorrect transformation patch included
by bugzilla_noreply＠novell.com 28 Jun '16

28 Jun '16

http://bugzilla.novell.com/show_bug.cgi?id=558841 http://bugzilla.novell.com/show_bug.cgi?id=558841#c0 Summary: alpine: incorrect transformation patch included Classification: openSUSE Product: openSUSE 11.2 Version: Final Platform: All OS/Version: Linux Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem AssignedTo: bnc-team-screening(a)forge.provo.novell.com ReportedBy: jengelh(a)medozas.de QAContact: qa(a)suse.de Found By: Beta-Customer Blocker: --- In alpine's operation-may-be-undefined-warning.diff, there is: - m = strtoul (++s,(char **) &s,10); - y = (*s == ':') ? strtoul (++s,(char **) &s,10) : 0; + s++; + m = strtoul (s,(char **) &s,10); + s++; + y = (*s == ':') ? strtoul (s,(char **) &s,10) : 0; But the last two + lines seem wrong. SUSE is incrementing s here before the test for ':', while the original patch only did it _after_. It should probably have been: s++; m = strtoul(s, (char **)&s, 10); if (*s == ':') { ++s; y = strtoul(s, (char **)&s, 10); } else { y = 0; } -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

1 11

[Bug 792947] New: warnings in BigInt.pm
by bugzilla_noreply＠novell.com 23 Jun '16

23 Jun '16

https://bugzilla.novell.com/show_bug.cgi?id=792947 https://bugzilla.novell.com/show_bug.cgi?id=792947#c0 Summary: warnings in BigInt.pm Classification: openSUSE Product: openSUSE 12.2 Version: Final Platform: x86-64 OS/Version: openSUSE 12.2 Status: NEW Severity: Normal Priority: P5 - None Component: Other AssignedTo: bnc-team-screening(a)forge.provo.novell.com ReportedBy: ccrssaa(a)karelia.ru QAContact: qa-bugs(a)suse.de Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Firefox/17.0 SeaMonkey/2.14 ipcount IP/len produces warnings in BigInt.pm Reproducible: Always Steps to Reproduce: run ipcount 1.1.1.1/32 Actual Results: > ipcount 1.1.1.1/32 1.1.1.1/32 1.1.1.1 - 1.1.1.1 [1] Use of uninitialized value in pattern match (m//) at /usr/lib/perl5/5.16.0/Math/BigInt.pm line 1136. Use of uninitialized value in string eq at /usr/lib/perl5/5.16.0/Math/BigInt.pm line 1139. Use of uninitialized value in pattern match (m//) at /usr/lib/perl5/5.16.0/Math/BigInt.pm line 1149. Expected Results: expected ipcount result without warnings > ipcount 1.1.1.1/32 1.1.1.1/32 1.1.1.1 - 1.1.1.1 [1] Quick workaround: copy BigInt.pm from openSUSE 12.1 and add { no warnings; ... } around lines 44-155 to suppress "overload arg '..' is invalid" message -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

1 7

[Bug 842360] New: dhcpd does not listen for dhcp requests
by bugzilla_noreply＠novell.com 16 Jun '16

16 Jun '16

https://bugzilla.novell.com/show_bug.cgi?id=842360 https://bugzilla.novell.com/show_bug.cgi?id=842360#c0 Summary: dhcpd does not listen for dhcp requests Classification: openSUSE Product: openSUSE 12.3 Version: Final Platform: x86-64 OS/Version: openSUSE 12.3 Status: NEW Severity: Major Priority: P5 - None Component: Network AssignedTo: bnc-team-screening(a)forge.provo.novell.com ReportedBy: Mathias.Homann(a)opensuse.org QAContact: qa-bugs(a)suse.de Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:23.0) Gecko/20100101 Firefox/23.0 When running the dhcp server that is included with opensuse 12.3,l it simply "doe not work at all". on closer inspection it turns out that the dhcpd does not listen on port 67... and so it can't serve dhcp requests. Reproducible: Always Steps to Reproduce: 1. start dhcpd 2. run dhcpcd-test from another computer 3. observe it failing w/o getting an answer 4. check with netstat -ulpn|grep dhcp that the dhcp server listens on two random udp ports but *not* on port 67 Actual Results: running a dhcp server with openSUSE 12.3 does not work at all. Expected Results: it "should just work". -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

1 30

[Bug 843734] New: security: Bug
by bugzilla_noreply＠novell.com 13 Jun '16

13 Jun '16

https://bugzilla.novell.com/show_bug.cgi?id=843734 https://bugzilla.novell.com/show_bug.cgi?id=843734#c0 Summary: security: Bug Classification: openSUSE Product: openSUSE.org Version: unspecified Platform: x86 OS/Version: openSUSE 12.3 Status: NEW Severity: Minor Priority: P5 - None Component: 3rd party software AssignedTo: lnussel(a)suse.com ReportedBy: lutchy.horace(a)outlook.com QAContact: opensuse-communityscreening(a)forge.provo.novell.com CC: meissner(a)suse.com Found By: --- Blocker: --- In /etc/sysconfig/sshguard, option PORTS separated by comma. Processed in /etc/init.d/sshguard by iptables_start() function. Iptables doesn't accept multiple ports with just '/usr/sbin/iptables -A INPUT -p tcp --dport $PORTS'. It must be specified in the format of '/usr/sbin/iptables -A INPUT -p tcp -m multiport --dport $PORTS' otherwise it will fail with: iptables v1.4.16.3: invalid port/service `22,443' specified Try `iptables -h' or 'iptables --help' for more information. Best Regards -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

1 3

[Bug 786024] New: vsftpd broken - OOPS: priv_sock_get_cmd
by bugzilla_noreply＠novell.com 11 Jun '16

11 Jun '16

https://bugzilla.novell.com/show_bug.cgi?id=786024 https://bugzilla.novell.com/show_bug.cgi?id=786024#c0 Summary: vsftpd broken - OOPS: priv_sock_get_cmd Classification: openSUSE Product: openSUSE Factory Version: 12.3 Milestone 0 Platform: Other OS/Version: openSUSE 12.2 Status: NEW Severity: Major Priority: P5 - None Component: Network AssignedTo: mvyskocil(a)suse.com ReportedBy: suse-beta(a)cboltz.de QAContact: qa-bugs(a)suse.de Found By: Beta-Customer Blocker: --- vsftpd is running, but... # ncftp -u demo localhost NcFTP 3.2.4 (May 16, 2010) by Mike Gleason (http://www.NcFTP.com/contact/) Server hungup immediately after connect. OOPS: priv_sock_get_cmd Workaround: add seccomp_sandbox=NO to vsftpd.conf See also https://bbs.archlinux.org/viewtopic.php?id=147074 - the page says this is fixed in vsftpd 3.0.2, so updating vsftpd to this version should be enough. I did not test if this bug is only in Factory (I'm using factory-tested from 2012-10-03) or also in 12.2. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

1 75

[Bug 831629] New: python3-base test test_faulthandler fails on ppc64
by bugzilla_noreply＠novell.com 09 Jun '16

09 Jun '16

https://bugzilla.novell.com/show_bug.cgi?id=831629 https://bugzilla.novell.com/show_bug.cgi?id=831629#c0 Summary: python3-base test test_faulthandler fails on ppc64 Classification: openSUSE Product: openSUSE Factory Version: 13.1 Milestone 3 Platform: PowerPC-64 OS/Version: openSUSE 12.3 Status: NEW Severity: Normal Priority: P5 - None Component: Development AssignedTo: bnc-team-screening(a)forge.provo.novell.com ReportedBy: dvaleev(a)suse.com QAContact: qa-bugs(a)suse.de Found By: --- Blocker: --- [ 456s] test_unregister (test.test_faulthandler.FaultHandlerTests) ... test test_faulthandler failed [ 456s] ok [ 456s] [ 456s] ====================================================================== [ 456s] FAIL: test_register_chain (test.test_faulthandler.FaultHandlerTests) [ 456s] ---------------------------------------------------------------------- [ 456s] Traceback (most recent call last): [ 456s] File "/home/abuild/rpmbuild/BUILD/Python-3.3.2/Lib/test/test_faulthandler.py", line 588, in test_register_chain [ 456s] self.check_register(chain=True) [ 456s] File "/home/abuild/rpmbuild/BUILD/Python-3.3.2/Lib/test/test_faulthandler.py", line 572, in check_register [ 456s] self.assertEqual(exitcode, 0) [ 456s] AssertionError: -11 != 0 [ 456s] [ 456s] ---------------------------------------------------------------------- -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

1 19

[Bug 837290] New: xl2tpd: kernel oops (system hangs) when start VPN connection
by bugzilla_noreply＠novell.com 08 Jun '16

08 Jun '16

https://bugzilla.novell.com/show_bug.cgi?id=837290 https://bugzilla.novell.com/show_bug.cgi?id=837290#c0 Summary: xl2tpd: kernel oops (system hangs) when start VPN connection Classification: openSUSE Product: openSUSE 12.3 Version: Final Platform: i686 OS/Version: openSUSE 12.3 Status: NEW Severity: Critical Priority: P5 - None Component: Network AssignedTo: bnc-team-screening(a)forge.provo.novell.com ReportedBy: alerom-666(a)yandex.ru QAContact: qa-bugs(a)suse.de Found By: --- Blocker: --- Created an attachment (id=554749) --> (http://bugzilla.novell.com/attachment.cgi?id=554749) ctrl+alt+f10 terminal screenshot User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:23.0) Gecko/20100101 Firefox/23.0 When I start connection with xl2tpd -D -c /etc/xl2tpd/xl2tpd.conf i've: xl2tpd[18159]: setsockopt recvref[22]: Protocol not available xl2tpd[18159]: Using l2tp kernel support. xl2tpd[18159]: xl2tpd version xl2tpd-1.3.0 started on linux-t9pv PID:18159 xl2tpd[18159]: Written by Mark Spencer, Copyright (C) 1998, Adtran, Inc. xl2tpd[18159]: Forked by Scott Balmos and David Stipp, (C) 2001 xl2tpd[18159]: Inherited by Jeff McAdams, (C) 2002 xl2tpd[18159]: Forked again by Xelerance (www.xelerance.com) (C) 2006 xl2tpd[18159]: Listening on IP address 0.0.0.0, port 1701 xl2tpd[18159]: get_call: allocating new tunnel for host 78.107.1.49, port 1701. xl2tpd[18159]: Connecting to host tp.internet.beeline.ru, port 1701 xl2tpd[18159]: control_finish: message type is (null)(0). Tunnel is 0, call is 0. xl2tpd[18159]: control_finish: sending SCCRQ xl2tpd[18159]: network_thread: recv packet from 78.107.1.49, size = 110, tunnel = 25911, call = 0 ref=0 refhim=0 xl2tpd[18159]: handle_avps: handling avp's for tunnel 25911, call 0 xl2tpd[18159]: message_type_avp: message type 2 (Start-Control-Connection-Reply) xl2tpd[18159]: protocol_version_avp: peer is using version 1, revision 0. xl2tpd[18159]: firmware_rev_avp: peer reports firmware version 4384 (0x1120) xl2tpd[18159]: hostname_avp: peer reports hostname 'bras304' xl2tpd[18159]: vendor_avp: peer reports vendor 'Cisco Systems, Inc.' xl2tpd[18159]: receive_window_size_avp: peer wants RWS of 32000. Will use flow control. xl2tpd[18159]: assigned_tunnel_avp: using peer's tunnel 43115 xl2tpd[18159]: framing_caps_avp: supported peer frames: xl2tpd[18159]: bearer_caps_avp: supported peer bearers: xl2tpd[18159]: control_finish: message type is Start-Control-Connection-Reply(2). Tunnel is 43115, call is 0. xl2tpd[18159]: control_finish: sending SCCCN xl2tpd[18159]: Connection established to 78.107.1.49, 1701. Local: 25911, Remote: 43115 (ref=0/0). xl2tpd[18159]: Calling on tunnel 25911 xl2tpd[18159]: control_finish: message type is (null)(0). Tunnel is 43115, call is 0. xl2tpd[18159]: control_finish: sending ICRQ xl2tpd[18159]: network_thread: recv packet from 78.107.1.49, size = 12, tunnel = 25911, call = 0 ref=0 refhim=0 xl2tpd[18159]: network_thread: recv packet from 78.107.1.49, size = 28, tunnel = 25911, call = 51794 ref=0 refhim=0 xl2tpd[18159]: handle_avps: handling avp's for tunnel 25911, call 51794 xl2tpd[18159]: message_type_avp: message type 11 (Incoming-Call-Reply) xl2tpd[18159]: assigned_call_avp: using peer's call 7161 xl2tpd[18159]: control_finish: message type is Incoming-Call-Reply(11). Tunnel is 43115, call is 7161. xl2tpd[18159]: control_finish: Sending ICCN xl2tpd[18159]: Call established with 78.107.1.49, Local: 51794, Remote: 7161, Serial: 1 (ref=0/0) xl2tpd[18159]: network_thread: recv packet from 78.107.1.49, size = 12, tunnel = 25911, call = 0 ref=0 refhim=0 xl2tpd[18159]: network_thread: select timeout xl2tpd[18159]: network_thread: select timeout xl2tpd[18159]: network_thread: select timeout xl2tpd[18159]: network_thread: select timeout xl2tpd[18159]: network_thread: select timeout xl2tpd[18159]: network_thread: select timeout And at this time - the system hangs. Screenshot is attached. xl2tp developers said that it fixed in kernel https://github.com/xelerance/xl2tpd/issues/28 A latest system updates is installed Reproducible: Always Steps to Reproduce: 1.start xl2tpd 2. 3. Actual Results: System hangs Expected Results: VPN is up and running -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

1 5