June 2015 - openSUSE Bugs - openSUSE Mailing Lists

[Bug 904712] New: Network Manager
by bugzilla_noreply＠novell.com 14 May '17

14 May '17

http://bugzilla.opensuse.org/show_bug.cgi?id=904712 Bug ID: 904712 Summary: Network Manager Classification: openSUSE Product: openSUSE 13.1 Version: Final Hardware: Other OS: openSUSE 13.1 Status: NEW Severity: Normal Priority: P5 - None Component: Network Assignee: bnc-team-screening(a)forge.provo.novell.com Reporter: jzimm0007(a)aol.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- The following bug report has been submitted: Product: SUSE 13.1 32bit I bet it's all of them. Patch Level: Defect: I have a printer (Canon MX749) that requires the wpa/wpa2 key to be lowercase and the SSID for the router has to be lowercase for it to connect to the router so I can print from SUSE wirelessly. (Yes it is possible, the driver is just hard to find) Every time I boot up the system I have to reconnect and fiddle with the network manager to get it to recognize that the hidden SSID is lowercase, because it automatically capitalizes the first letter in the SSID, it won't connect or sometimes it asks for a password even though it's properly entered in the network manager app. I actually installed it on a Gigabyte computer for my dad and it also kept asking for the password to the wifi (totally different router) even though it was typed properly. Other Software and Versions Being Used: I'm guessing it's in all of them since this is the first time (I'm assuming) it's been noticed. Steps to Duplicate: 1.)rename the router to a lowercase SSID with a lowercase 'Mixed WPA/WPA2' AES key The key renewal interval was set to 3600 if that's relevant. It's an 8 letter lowercase word password. 2.)Delete all the wireless connections like where it says when they are last used under manage connections in the network manager app if there are any. Reboot the computer 3.)Click on the network manager app in the tray. Click hidden network>Type in the lowercase SSID name and hit enter. 4.)Type in the correct WPA/WPA2 key (8 letter lowercase password) Notice it capitalizes the SSID so you have to make it lowercase. (Don't lowercase it until you want it to work) Go to the Wireless screen and click on select and random. 5.)Click apply and okay or whatever to keep the settings. 6.)Now if you didn't lowercase the SSID first letter it won't connect or sometimes it'll ask for the password after it's entered properly. I didn't use the KDE Wallet (I don't think I'm pretty sure I just canceled it or hit finish to make it so I didn't have to use it) 7.)So basically to get it to work in Network Manager I had to keep typing in the lowercase SSID and the WPA/WPA2 password every time I booted the computer and it kept adding entries to the network management, but it would eventually connect. I hit cancel in the authentication dialog and kept trying it again and things like that to make it want to connect. Other Scenarios: Yes Environment Description: I'm using a laptop and two desktops all with SUSE 13.1. It's a Netgear PCI Card with a Tenda Router (It has no external antennas and it's white) The netgear has a white box antenna with 2 wires to connect to the HP Computer. I have an MSI E45 gaming computer it's on also. The laptop is a Toshiba Sattelite L25-S119 that randomly freezes when it unlocks like when it adjusts the brightness or something and it uses the Atheros driver which doesn't work right either, but those are other bugs. Problem Environment: Don't know Testing Environment: Didn't try that Fix: Just make the name lowercase when it pops up and asks you, but you keep getting entries in Network Manager after you type in the new lowercase SSID;s Additional: I have all the latest updates installed and it's because I have a wireless printer that requires it to be setup that way. -- You are receiving this mail because: You are on the CC list for the bug.

1 12

[Bug 916771] New: no traffic through sshuttle possible while SuSEfirewall2 is running
by bugzilla_noreply＠novell.com 02 May '17

02 May '17

http://bugzilla.suse.com/show_bug.cgi?id=916771 Bug ID: 916771 Summary: no traffic through sshuttle possible while SuSEfirewall2 is running Classification: openSUSE Product: openSUSE 13.1 Version: Final Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Network Assignee: bnc-team-screening(a)forge.provo.novell.com Reporter: wagner-thomas(a)gmx.at QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- On openSUSE 13.1, I investigated sshuttle from the security repository and noticed that is doesn't work while SuSEfirewall2 is running with default settings. "Doesn't work" means: When sshuttle is started all network-traffic is blocked (can't ping, can't do nslookup) instead of tunneled. However, there is no sign in /var/log/messages or /var/log/firewall that SuSEfirewall2 would have blocked something. I used the following command line to start sshuttle as root sshuttle --dns -r user@ssh-tunnel-host 0.0.0.0/0 -v When doing a "rcSuSEfirwall2 stop" prior starting sshuttle, tunneling works fine. Now I wonder: Can the default setting of SuSEfirewall2 can be modified in order to let sshuttle do it's work? -- You are receiving this mail because: You are on the CC list for the bug.

1 9

[Bug 929471] New: hostname is not initialized so postfix default hostname/domainname faile
by bugzilla_noreply＠novell.com 02 May '17

02 May '17

http://bugzilla.suse.com/show_bug.cgi?id=929471 Bug ID: 929471 Summary: hostname is not initialized so postfix default hostname/domainname faile Classification: openSUSE Product: openSUSE Distribution Version: 13.2 Hardware: x86-64 OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem Assignee: bnc-team-screening(a)forge.provo.novell.com Reporter: dgolden(a)golden-consulting.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Created attachment 633096 --> http://bugzilla.suse.com/attachment.cgi?id=633096&action=edit console output 1) When the system is booted, the hostname is never initialized. 2) Postfix uses the gethostname() system call to establish the "myhostname" and "mydomain" variables; therefore setting the domain name wrong. This causes all the postfix configuration files to fail on systems upgraded to 13.2. -- You are receiving this mail because: You are on the CC list for the bug.

1 39

[Bug 906379] New: autofs - "Local domain name not set" during booting
by bugzilla_noreply＠novell.com 01 May '17

01 May '17

http://bugzilla.opensuse.org/show_bug.cgi?id=906379 Bug ID: 906379 Summary: autofs - "Local domain name not set" during booting Classification: openSUSE Product: openSUSE Factory Version: 201411* Hardware: x86-64 OS: openSUSE 13.2 Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem Assignee: bnc-team-screening(a)forge.provo.novell.com Reporter: renda.krell(a)gmail.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/39.0.2171.65 Safari/537.36 Build Identifier: I use autofs for mounting some NFS and CIFS shares. In OpenSUSE 13.1 I haven't seen any error with the same configuration. In OpenSUSE 13.2 incl. Tumbleweed/Factory, 'systemctl status' returns: --- autofs.service - Automounts filesystems on demand Loaded: loaded (/usr/lib/systemd/system/autofs.service; enabled) Active: active (running) since Thu 2014-11-20 08:54:52 CET; 1h 47min ago Docs: man:automount(8) man:autofs(5) Process: 1709 ExecStart=/usr/sbin/automount ${AUTOFS_OPTIONS} -p /var/run/automount.pid (code=exited, status=0/SUCCESS) Main PID: 1712 (automount) CGroup: /system.slice/autofs.service └─1712 /usr/sbin/automount -p /var/run/automount.pid Nov 20 08:54:52 rkrell automount[1712]: lookup_init:139: lookup(yp): map auto.master: Local domain name not set --- In fact, the domain name is not set: rkrell:~ # hostname rkrell rkrell:~ # domainname (none) but the network is set up correctly using NetworkManager and a local LAN connection. Reproducible: Always Steps to Reproduce: 1. Boot the system 2. 3. -- You are receiving this mail because: You are on the CC list for the bug.

1 10

[Bug 909695] New: segmentation fault after pack & ioctl & unpack
by bugzilla_noreply＠novell.com 28 Apr '17

28 Apr '17

http://bugzilla.suse.com/show_bug.cgi?id=909695 Bug ID: 909695 Summary: segmentation fault after pack & ioctl & unpack Classification: openSUSE Product: openSUSE Distribution Version: 13.2 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Ruby Assignee: ruby-devel(a)suse.de Reporter: bkutil(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- This snippet (requires sudo due to ioctl call) produces a segmentation fault on the 13.2 ruby [1], affecting current ruby2.0 and ruby2.1 packages. The bug is currently tracked upstream [2], but not yet fixed, however, a patch is known to work as a fix when backported [3]. require 'socket' SIOCETHTOOL = 0x8946 i = ["lo", "\n"].pack("a16p") s = Socket.new(Socket::AF_INET, Socket::SOCK_DGRAM, 0) s.ioctl(SIOCETHTOOL, i) i.unpack("a16p")[1] [1] ruby 2.1.3p242 (2014-09-19 revision 47630) [x86_64-linux-gnu] [2] https://bugs.ruby-lang.org/issues/10568 [3] https://github.com/ruby/ruby/commit/4b146b25333c52ca4503dfc3c4215b583e8e9963 -- You are receiving this mail because: You are on the CC list for the bug.

1 18

[Bug 926766] New: rpm: BuildArch resets %patches and %sources
by bugzilla_noreply＠novell.com 26 Apr '17

26 Apr '17

http://bugzilla.suse.com/show_bug.cgi?id=926766 Bug ID: 926766 Summary: rpm: BuildArch resets %patches and %sources Classification: openSUSE Product: openSUSE Factory Version: 201503* Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem Assignee: mls(a)suse.com Reporter: lnussel(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- %patches and %sources are lua scripts that should print the patches and sources. That works fine as long as Source and Patch lines are before BuildArch. Anything that comes after BuildArch is ignored. -- You are receiving this mail because: You are on the CC list for the bug.

1 3

[Bug 695322] New: home:dannori: Bug
by bugzilla_noreply＠novell.com 23 Apr '17

23 Apr '17

https://bugzilla.novell.com/show_bug.cgi?id=695322 https://bugzilla.novell.com/show_bug.cgi?id=695322#c0 Summary: home:dannori: Bug Classification: openSUSE Product: openSUSE.org Version: unspecified Platform: x86-64 OS/Version: openSUSE 11.4 Status: NEW Severity: Normal Priority: P5 - None Component: 3rd party software AssignedTo: dannoritzer(a)web.de ReportedBy: melchiaros(a)aol.com QAContact: opensuse-communityscreening(a)forge.provo.novell.com Found By: Other Blocker: No Hi, I try to install ghdl from your repo. Yast shows me that ghdl-grt needs libada >= 3.1. A look at my system shows that I´ve installed libada46 from devel:/gcc. So all what ghdl need should be there?! Please make a correction when it is necessary. Greetings -- 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

[Bug 903989] New: lynis permissions needs small changes.
by bugzilla_noreply＠novell.com 19 Apr '17

19 Apr '17

http://bugzilla.opensuse.org/show_bug.cgi?id=903989 Bug ID: 903989 Summary: lynis permissions needs small changes. Classification: openSUSE Product: openSUSE Distribution Version: 13.2 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Security Assignee: security-team(a)suse.de Reporter: roeland(a)linux-it.nl QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- I just installed lynis-1.6.2-1.2.noarch to assess the syate of my 13.2 setup. It appears that the rpm content does not have correct permissions on some files. if I exec the first time: taplop:~ # lynis -h [!] Change file permissions of /usr/share/lynis/include/consts to 640. Command: chmod 640 /usr/share/lynis/include/consts [!] Change file permissions of /usr/share/lynis/include/functions to 640. Command: chmod 640 /usr/share/lynis/include/functions [X] Security check failed: See action above to correct this issue. Please change ownership and permissions of the related files and start Lynis again. taplop:~ # chmod 640 /usr/share/lynis/include/consts taplop:~ # chmod 640 /usr/share/lynis/include/functions taplop:~ # lynis -h Fatal error: permissions of file /usr/share/lynis/include/parameters are not strict enough. Access to 'other' should be denied or read-only. taplop:~ # ls -l /usr/share/lynis/include/parameters -rwxr-xr-x 1 root root 5187 Oct 6 17:43 /usr/share/lynis/include/parameters taplop:~ # chmod o-x /usr/share/lynis/include/parameters taplop:~ # ls -l /usr/share/lynis/include/parameters -rwxr-xr-- 1 root root 5187 Oct 6 17:43 /usr/share/lynis/include/parameters after this correction it works: taplop:~ # lynis -h [ Lynis 1.6.2 ] ################################################################################ Lynis comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to redistribute it under the terms of the GNU General Public License. See the LICENSE file for details about using this software. Copyright 2007-2014 - Michael Boelen, http://cisofy.com Enterprise support and plugins available via CISOfy - http://cisofy.com ################################################################################ [+] Initializing program ------------------------------------ Scan options: --auditor "<name>" : Auditor name --check-all (-c) : Check system --no-log : Don't create a log file --pentest : Non-privileged scan (useful for pentest) --profile <profile> : Scan the system with the given profile file --quick (-Q) : Quick mode, don't wait for user input --tests "<tests>" : Run only tests defined by <tests> --tests-category "<category>" : Run only tests defined by <category> Layout options: --no-colors : Don't use colors in output --quiet (-q) : No output, except warnings --reverse-colors : Optimize color display for light backgrounds Misc options: --check-update : Check for updates --debug : Debug logging to screen --view-manpage (--man) : View man page --version (-V) : Display version number and quit Enterprise options: --plugin-dir "<path"> : Define path of available plugins --upload : Upload data to central node See man page and documentation for all available options. Exiting.. -- You are receiving this mail because: You are on the CC list for the bug.

1 7

[Bug 914698] New: Regression - plymoth no longer prompts for password for encrypted partition
by bugzilla_noreply＠novell.com 19 Apr '17

19 Apr '17

http://bugzilla.opensuse.org/show_bug.cgi?id=914698 Bug ID: 914698 Summary: Regression - plymoth no longer prompts for password for encrypted partition Classification: openSUSE Product: openSUSE Distribution Version: 13.2 Hardware: x86-64 OS: openSUSE 13.2 Status: NEW Severity: Normal Priority: P5 - None Component: Bootloader Assignee: jsrain(a)suse.com Reporter: robert.munteanu(a)gmail.com QA Contact: jsrain(a)suse.com Found By: --- Blocker: --- (Initially posted at https://forums.opensuse.org/showthread.php/504578-Booting-from-encrypted-pa… ) Running 13.2 x86_64 with all updates applied, nvidia proprietary driver. I have disk encryption set up with the YAST parititioner ( I assume LUKS is used ). After updating to kernel 3.16.7 I noticed that I could not boot with it - never got asked to enter my passphrase. So I stuck to using 3.16.6 and after some other updates not even 3.16.6 would work. Sorry for being fuzzy, I don't remember exactly when it happened. The workaround I found was to remove the 'splash=slient quiet' options from the linux line in grub and got the the point where the passphrase was asked for. However, the prompt was different than the one I used to get. The old one was green text and centered in the screen, the current one has the same colour as the text and for each character I input the previous line gets echoed with an additional '*' character appended. I have tried the following to change the plymouth theme # plymouth-set-default-theme text # grub2-mkconfig -o /boot/grub2/grub.cfg However, I get the same behaviour as before. -- You are receiving this mail because: You are on the CC list for the bug.

1 4

[Bug 884398] New: libvirt-created iptables rules lost on DHCP lease renewal
by bugzilla_noreply＠novell.com 17 Apr '17

17 Apr '17

https://bugzilla.novell.com/show_bug.cgi?id=884398 https://bugzilla.novell.com/show_bug.cgi?id=884398#c0 Summary: libvirt-created iptables rules lost on DHCP lease renewal Classification: openSUSE Product: openSUSE 13.1 Version: Final Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: P5 - None Component: Network AssignedTo: lnussel(a)suse.com ReportedBy: vuntz(a)suse.com QAContact: qa-bugs(a)suse.de CC: mt(a)suse.com Found By: --- Blocker: --- libvirt is adding some rules to the firewall for the networks configured for the VMs (to allow some NAT). However, when using dhcpcd (ie, default network configuration on a workstation), every time the lease is renewed, /etc/sysconfig/network/if-up.d/SuSEfirewall2 is run and is resetting the firewall rules to what is configured, which doesn't include the libvirt rules. That means that the libvirt rules are lost every now and then. A similar issue was debugged in bug 573246 and the fix was http://bugzillafiles.novell.org/attachment.cgi?id=378796. Is this fix acceptable for SuSEfirewall too? -- 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 2