April 2023 - openSUSE Users - openSUSE Mailing Lists

Creating a new user for a deamon
by Rowan Reid 15 Jan '24

15 Jan '24

I'm setting up a cron job for a analysis tool, I'm trying to use the SuSE tools where possible but YAST doent' allow you to create new user without a home I tried /dev/null is there a proper way to do this ? Rowan Reid Job Captain, Systems Administrator STUDIO 3 ARCHITECTS 909 982 1717

3 2

[oS-EN] Question on full disk encription
by Carlos E. R. 02 Sep '23

02 Sep '23

Hi, new laptop here, and I decided to install Leap 15.4 with full disk encryption, no LVM (a feature I wanted to have for years, so I'm happy). It asks for the password twice (contrary to my customs, I'm using plymouth). It asks once before grub loads. Well, ok, there is no separate /boot, so it has to read "/" which is encrypted. Nice. But after selecting the boot entry in grub, it asks again. Once, despite being 3 partitions ("/", "/boot" and swap). Ok. Is there some way to make it ask only once? I guess not, but perhaps I'm wrong. -- Cheers / Saludos, Carlos E. R. (from Elesar, using openSUSE Leap 15.4)

10 60

KDE keyboard layout not starting on login
by Stratos Zolotas 15 May '23

15 May '23

Hello, I have a strange issue that appears in two systems. One Tumbleweed and one 15.4. I use en and gr keyboard layouts configured from the KDE settings. Although the setting is valid and as soon as I apply it the keyboard layout indicator appears in the system tray, after reboot it disappears and I have to go and re-apply the settings (it is not deleted just not "executed") to make it visible and working again. I usually use keep last session on KDE but I also tried to start with a clean session or with a manual saved session. Nothing seems to affect the keyboard layout indicator, it is always disappearing after reboot. Both systems were working as expected before. The only difference is that the issue on 15.4 appeared just after dist-upgrading from 15.3. Any ideas on how to debug it? Regards Stratos

3 6

Bonding?
by Lew Wolfgang 10 May '23

10 May '23

Hi Folks, We've been collecting data through four 1-GbE Ethernet interfaces configured as independent connections on different subnets. This has been working well enough for years. But now someone has suggested bonding those four interfaces into one virtual interface. I've never had any experience with this sort of thing, it looks like there's "bonding" and a newer thing called "teaming". We're already getting 950-Mb/channel so we'd be looking more for load-leveling and fall-over reliability. I wonder if any of you might have some suggestions or experience you might share? Regards, Lew

5 14

[oS-en] Testing the new configuration of firewalld
by Carlos E. R. 02 May '23

02 May '23

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Content-ID: <5bf6502a-a6a1-9cf4-dce1-355b4d5b564b(a)Telcontar.valinor> Hi, (This is a thinking aloud post, so of course there is conflict in what I say) So I converted my miniserver to use firewalld instead of SuSEfirewalld, using "susefirewall2-to-firewalld" script. I added the rule to block incoming packets from the router. The resulting config is: Isengard:/etc/firewalld/zones # firewall-cmd --list-all external (active) target: default icmp-block-inversion: no interfaces: eth0 wlan0 sources: services: dns http https mountd nfs nfs3 ntp rpc-bind ssh ports: 12854/tcp 50000/tcp 12858/udp 47981/udp 38059/tcp 56517/udp 40399/tcp protocols: forward: no masquerade: no forward-ports: source-ports: icmp-blocks: address-unreachable bad-header beyond-scope communication-prohibited destination-unreachable echo-reply failed-policy fragmentation-needed host-precedence-violation host-prohibited host-redirect host-unknown host-unreachable ip-header-bad network-prohibited network-redirect network-unknown network-unreachable no-route packet-too-big parameter-problem port-unreachable precedence-cutoff protocol-unreachable reject-route required-option-missing source-route-failed time-exceeded timestamp-reply timestamp-request tos-host-redirect tos-host-unreachable tos-network-redirect tos-network-unreachable ttl-zero-during-reassembly ttl-zero-during-transit unknown-header-type unknown-option rich rules: rule family="ipv4" source address="192.168.1.55/32" port port="5556" protocol="tcp" accept rule family="ipv4" source address="192.168.1.128/32" port port="2908" protocol="udp" accept rule family="ipv4" source address="192.168.1.129/32" port port="53" protocol="udp" accept rule family="ipv4" source address="192.168.1.57/32" accept rule family="ipv4" source address="192.168.1.14/32" port port="2049" protocol="tcp" accept rule family="ipv4" source address="192.168.1.14/32" port port="80" protocol="tcp" accept rule family="ipv4" source address="192.168.1.0/24" port port="80" protocol="tcp" accept rule family="ipv4" source address="192.168.1.5/32" protocol value="icmp" accept rule family="ipv4" source address="192.168.1.14/32" port port="514" protocol="udp" accept rule family="ipv4" source address="192.168.1.14/32" port port="4080" protocol="tcp" accept rule family="ipv4" source address="192.168.1.128/32" port port="4080" protocol="tcp" accept rule family="ipv4" source address="192.168.1.7/32" port port="137" protocol="tcp" accept rule family="ipv4" source address="172.26.0.0/16" protocol value="udp" accept rule family="ipv4" source address="192.168.1.126/32" port port="2049" protocol="tcp" accept rule family="ipv4" source address="192.168.1.14/32" port port="4243" protocol="tcp" accept rule family="ipv4" source address="192.168.1.54/32" port port="4243" protocol="tcp" accept rule family="ipv4" source address="192.168.1.129/32" port port="53" protocol="tcp" accept rule family="ipv4" source address="192.168.1.7/32" protocol value="udp" accept rule family="ipv4" source address="192.168.1.7/32" port port="139" protocol="tcp" accept rule family="ipv4" source address="192.168.1.127/32" port port="873" protocol="tcp" accept rule family="ipv4" source address="192.168.1.1/32" port port="162" protocol="udp" accept rule family="ipv4" source address="192.168.1.55/32" accept rule family="ipv4" source address="192.168.1.0/24" port port="111" protocol="tcp" accept rule family="ipv4" source address="192.168.1.129/32" port port="5000" protocol="tcp" accept rule family="ipv4" source address="192.168.1.14/32" port port="8080" protocol="tcp" accept rule family="ipv4" source address="192.168.1.14/32" port port="4001" protocol="tcp" accept rule family="ipv4" source address="192.168.1.14/32" port port="25" protocol="tcp" accept rule family="ipv4" source address="192.168.1.14/32" port port="4000" protocol="tcp" accept rule family="ipv4" source address="192.168.1.1/32" port port="50000" protocol="tcp" accept rule family="ipv4" source address="192.168.1.128/32" port port="445" protocol="tcp" accept rule family="ipv4" source address="192.168.1.128/32" port port="5353" protocol="tcp" accept rule family="ipv4" source address="192.168.1.56/32" port port="5556" protocol="tcp" accept rule family="ipv4" source address="192.168.1.128/32" port port="4120" protocol="udp" accept rule family="ipv4" source address="192.168.1.126/32" port port="873" protocol="tcp" accept rule family="ipv4" source address="192.168.1.0/24" port port="2049" protocol="tcp" accept rule family="ipv4" source address="192.168.1.14/32" port port="4242" protocol="tcp" accept rule family="ipv4" source address="192.168.1.128/32" port port="4243" protocol="tcp" accept rule family="ipv4" source address="192.168.1.128/32" port port="1252" protocol="tcp" accept rule family="ipv4" source address="192.168.1.14/32" port port="4243" protocol="udp" accept rule family="ipv4" source address="192.168.1.14/32" port port="8081" protocol="tcp" accept rule family="ipv4" source address="192.168.1.14/32" port port="9090" protocol="tcp" accept rule family="ipv4" source address="192.168.1.129/32" port port="2049" protocol="tcp" accept rule family="ipv6" source address="fc00::/64" port port="5353" protocol="udp" accept rule family="ipv4" source address="192.168.1.1/32" port port="514" protocol="udp" accept rule family="ipv4" source address="192.168.1.128/32" port port="1625" protocol="tcp" accept rule family="ipv4" source address="192.168.1.127/32" port port="2049" protocol="tcp" accept rule family="ipv4" source address="192.168.1.129/32" port port="4080" protocol="tcp" accept rule family="ipv4" source address="192.168.1.54/32" accept rule family="ipv4" source address="192.168.1.128/32" port port="137" protocol="udp" accept rule family="ipv4" source address="192.168.1.0/24" port port="2049" protocol="udp" accept rule family="ipv4" source address="192.168.1.7/32" port port="53" protocol="udp" accept rule family="ipv4" source address="192.168.1.129/32" port port="9090" protocol="tcp" accept rule family="ipv4" source address="192.168.1.14/32" port port="162" protocol="udp" accept rule family="ipv4" source address="192.168.1.129/32" port port="4000" protocol="tcp" accept rule family="ipv4" source address="192.168.1.14/32" port port="8000" protocol="tcp" accept rule family="ipv4" source address="192.168.1.50/32" port port="53" protocol="tcp" accept rule family="ipv4" source address="192.168.1.0/24" port port="111" protocol="udp" accept rule family="ipv4" source address="192.168.1.7/32" port port="514" protocol="udp" accept rule family="ipv4" source address="192.168.1.5/32" port port="162" protocol="udp" accept rule family="ipv4" source address="192.168.1.14/32" port port="514" protocol="tcp" accept rule family="ipv4" source address="192.168.1.7/32" port port="5353" protocol="tcp" accept rule family="ipv4" source address="192.168.1.14/32" port port="873" protocol="tcp" accept rule family="ipv4" source address="192.168.1.14/32" protocol value="icmp" accept rule family="ipv4" source address="192.168.1.128/32" port port="4754" protocol="udp" accept rule family="ipv4" source address="192.168.1.128/32" port port="53" protocol="tcp" accept rule family="ipv4" source address="192.168.1.56/32" port port="5558" protocol="tcp" accept rule family="ipv4" source address="192.168.1.128/32" port port="53" protocol="udp" accept rule family="ipv4" source address="192.168.1.129/32" port port="4001" protocol="tcp" accept rule family="ipv4" source address="192.168.1.15/32" port port="2049" protocol="tcp" accept rule family="ipv4" source address="192.168.1.1/32" protocol value="udp" accept rule family="ipv4" source address="192.168.1.0/24" port port="22" protocol="tcp" accept rule family="ipv4" source address="192.168.1.14/32" port port="6666" protocol="udp" accept rule family="ipv4" source address="192.168.1.54/32" port port="5558" protocol="tcp" accept rule family="ipv6" source address="fe80::/64" port port="5353" protocol="udp" accept rule family="ipv4" source address="192.168.1.50/32" port port="53" protocol="udp" accept rule family="ipv4" source address="192.168.1.7/32" port port="3553" protocol="udp" accept rule family="ipv4" source address="192.168.1.54/32" port port="5556" protocol="tcp" accept rule family="ipv4" source address="192.168.1.1/32" protocol value="icmp" accept rule family="ipv4" source address="192.168.1.7/32" port port="515" protocol="tcp" accept rule family="ipv4" source address="192.168.1.5/32" port port="514" protocol="udp" accept rule family="ipv4" source address="192.168.1.128/32" port port="138" protocol="udp" accept rule family="ipv4" source address="192.168.1.56/32" accept rule family="ipv4" source address="192.168.1.128/32" port port="139" protocol="tcp" accept rule family="ipv4" source address="192.168.1.55/32" port port="5558" protocol="tcp" accept rule family="ipv4" source address="192.168.1.129/32" port port="8081" protocol="tcp" accept rule priority="10" source mac="ROUTER_MAC" reject Isengard:/etc/firewalld/zones # So, I want to try the access to apache and ssh from outside. I connect via ssh to a Friend's machine, and try. Ipv4 first. carlos@Friend:~ $ curl http://isengard_rmt_dns ^C carlos@Friend:~ $ No response on port 80, good. carlos@Friend:~ $ curl http://isengard_rmt_dns:50000 <html><body><h1>Hola tio.</h1></body></html>carlos@Friend:~ $ Correct response on a high port. carlos@Friend:~ $ ssh cer@isengard_rmt_dns ^C carlos@Friend:~ $ No response on port 22, correct. carlos@Friend:~ $ ssh -p 51000 cer@isengard_rmt_dns The authenticity of host '[isengard_rmt_dns]:51000 ([IPv4_ADDR]:51000)' can't be established. ECDSA key fingerprint is SHA256:ILyba.... Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added '[isengard_rmt_dns]:51000,[IPv4_ADDR]:51000' (ECDSA) to the list of known hosts. cer@isengard_rmt_dns: Permission denied (publickey). carlos@Friend:~ $ Expected response on a high port. Notice that on IPv4 the router intervenes with translations (virtual server). Incoming to port 51000 is sent to Isengard on LAN, port 22. Incoming to port 50000 is sent to port Isengard on LAN, port 50000. (not the actual ports, I edited them for privacy; but close). The Virtual Server config of the router doesn't work on IPv6 - correct, it is a NAT hack. Apache on IPv6 and high port: carlos@Friend:~ $ curl http://[Ipv6_ADDR]:50000 <html><body><h1>Hola tio.</h1></body></html>carlos@Friend:~ $ This is correct. carlos@Friend:~ $curl http://[Ipv6_ADDR] <html><body> <h1>Welcome to Isengard</a></h1> <h3>Letras: \ | @ # € </h3> <h2> <a href="/ficheros" title="Ficheros">[ficheros]</a> <br> <a href="/ficheros/mirrors" title="Mirrors">[Mirrors]</a> <br> <a href="/data/hoard/TheHoard/jd">[Shared J]</a> <br> <a href="/data/hoard/">[Data]</a> <br> <a href="/data/waterhoard/Fusion/Videos">[Fusion]</a> <br> <a href="/data/My_Book/Fusion/Videos">[Fusion MyBook]</a> <br>   </h2> </body></html> carlos@Friend:~ $ Now, this is not correct, it is the response expected INSIDE the LAN. That means a problem in the Apache configuration for virtual hosts, but also that port 80 is not closed on IPv6. ssh on IPv6 and default port: carlos@Friend:~ $ ssh cer@Ipv6_ADDR The authenticity of host 'Ipv6_ADDR (Ipv6_ADDR)' can't be established. ECDSA key fingerprint is SHA256:ILyba. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added 'Ipv6_ADDR' (ECDSA) to the list of known hosts. cer@Ipv6_ADDR: Permission denied (publickey). carlos@Friend:~ $ Well, this is not correct, it should be denied by the rich rule. Obviously, computers have their own mind, but I'm not familiar with the firewalld "mind". And I'm getting a headache. There is this rule: rule family="ipv4" source address="192.168.1.1/32" port port="50000" protocol="tcp" accept which might conflict with: rule priority="10" source mac="ROUTER_MAC" reject but it is for Ipv4 only, so it shouldn't. It seems that: services: dns http https mountd nfs nfs3 ntp rpc-bind ssh takes precedence over the rich rule denying packets via router. [headache] Obviously, being a server, both ssh and http have to be open even if the packet is incoming from the router, but not on the 22 and 80 ports, but on the high ports only. So maybe I have to remove the line services: dns http https mountd nfs nfs3 ntp rpc-bind ssh move all that to rich rules that open those ports on IPv4 only, and open generically ports 50000 and 51000 only. Wait, ssh comes from the router on port 22, it is translated. Making sshd listen on 51000 is not that easy. So, generically open port 50000. Open port 22 on IPv4, close on IPv6? Or open generically. Ideas? (Can I write comments in xml file /etc/firewalld/zones/external.xml?) - -- Cheers Carlos E. R. (from 15.4 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iHoEARECADoWIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCZEg+2Rwccm9iaW4ubGlz dGFzQHRlbGVmb25pY2EubmV0AAoJELUzGBxtjUfVN8kAnjDt2n+lyVtMRz7zT+Ih EiOCzJ8mAJ4pxKkBZj3nxuRjOT9DM7TClL87Tg== =tCZ9 -----END PGP SIGNATURE-----

12 156

[oS-en] Another SuSEfirewall2 to firewall conversion.
by Carlos E. R. 02 May '23

02 May '23

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, This particular post is rantish. Telcontar:~ # time susefirewall2-to-firewalld -c 2>&1 | tee susefirewall2-to-firewalld_2.2.txt ... Error: INVALID_PORT: 30000:30100 FIREWALLD ERROR: Command 'firewall-cmd ' failed But: /etc/sysconfig/SuSEfirewall2 192.168.1.126,tcp,smtp 192.168.1.126,tcp,imap 192.168.1.126,tcp,imaps\ 192.168.1.126,tcp,ftp 192.168.1.126,tcp,ftp-data 192.168.1.126,tcp,http \ # 192.168.1.126,tcp,30000:30100 \ 192.168.1.126,tcp,nfs 192.168.1.126,udp,sunrpc 192.168.1.126,tcp,rsync \ 192.168.1.127,tcp,smtp 192.168.1.127,tcp,imap 192.168.1.127,tcp,imaps\ 192.168.1.127,tcp,ftp 192.168.1.127,tcp,ftp-data 192.168.1.127,tcp,http \ # 192.168.1.127,tcp,30000:30100 \ 192.168.1.127,tcp,nfs 192.168.1.127,udp,sunrpc 192.168.1.127,tcp,rsync \ The line that triggers the error is commented out! I will delete it, of course. - -- Cheers Carlos E. R. (from 15.4 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iHoEARECADoWIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCZE5fhxwccm9iaW4ubGlz dGFzQHRlbGVmb25pY2EubmV0AAoJELUzGBxtjUfVtLwAnRvBv8Yc6XXRxeW+kxCm f6qp8BajAJ93uud6tgspD2+i1/XPRbVH+8nffQ== =Re/K -----END PGP SIGNATURE-----

7 35

Tumbleweed install with secure boot failing
by Wolfgang Rosenauer 01 May '23

01 May '23

Hi, just got a new laptop with Windows 11 installed and I'm not supposed to remove Win 11 completely ;-) but want to install Tumbleweed in dual boot. Since apparently I'm installing only every few years it's always again "interesting". I downloaded a recent Tumbleweed snapshot and wrote it to a USB stick but I cannot boot from it as the system tells me that the secure boot signature is invalid. When trying to search for the issue I cannot find much. I found that Tumbleweed should be supporting secure boot completely and therefore I have no idea what might be wrong as apparently is meant to just work. Any pointers? Thanks, Wolfgang

5 11

sfw2 to firewalld conversion
by Per Jessen 01 May '23

01 May '23

Carlos was right, it is ancient news - the script is dated 2016. I guess it is well off-topic too, but at least it is SUSE related :-) I needed a bit of a distraction, I've been working on a website, so after dinner I installed the migration script on my tw64 test box, along with firewalld. If need be, I can wipe the whole slate clean. After starting firewalld (with an empty config I presume), I tried the first run of susefirewall2-to-firewalld. It took 5m49s - seemed to spend much of it with a whole slew of icmps. Two initial comments - after looking at the output - the conversion script isn't quite ipv6 aware: INFO: RICH: Adding rich rule="rule family=ipv4 source address=fe80::/64 port port=5353 protocol=udp accept" to zone="ext" INFO: RICH: Adding rich rule="rule family=ipv4 source address=fc00::/64 port port=5353 protocol=udp accept" to zone="ext" INFO: RICH: Adding rich rule="rule family=ipv4 source address=fe80::/64 port port=5353 protocol=udp accept" to zone="int" It does however seem to understand your "from:to": port-range syntax: INFO: Adding port(s)="30000-30010/tcp" to zone="external" INFO: Adding port(s)="4664/tcp" to zone="external" INFO: Adding port(s)="427/tcp" to zone="external" INFO: Adding port(s)="5060-5100/udp" to zone="external" -- Per Jessen, Zürich (14.6°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes

2 11

Re: What will IPv6 actually do for you?
by Per Jessen 30 Apr '23

30 Apr '23

Lew Wolfgang wrote: > On 4/28/23 04:18, Carlos E. R. wrote: >>> If you are not going to use IPv6 internally, having source zone for >>> 192.168.1.0/24 (or whatever your internal addresses are) and >>> fallback zone for external traffic would be much more clean. >> >> I expect^H^H^H^H^H^Hhope to have proper IPv6 one day... > > What will IPv6 actually do for you? It's a serious question, > what will it give you that you don't already have with > IPv4 and NAT? > > From my experience at work it's nothing but a PITA that > reduces reliability. Really?? or are you just trolling? I certainly can't say that matches my experience, at all. I have been running ipv6 since around 2007, first with a tunnel, later with fixed ISP ranges and since 2015 with our own /28. We also still have a number of leased external machines, all with ipv6. Reliability is fine, I don't understand how ipv6 could possibly reduce reliability of anything. Some PIT ... minor issues: * Wifi access points by Tp-Link have had trouble with ipv6. (okay, identifying that issue was a royal PITA) * dynamic ipv6 dns updates worked until we upgraded bind (they work again now) * recently, radvd threw a wobbly, still pondering that. * androids don't work with dhcpv6. I have one issue I have only just this week picked up - we need to get the reverse zone dynamic updates to work too. There is some odd bind error when we enable updates. Some days our public opensuse mirror has up to 33% ipv6 traffic. (from http://mirror.hostsuisse.com/stats/opensuse) Switzerland - 19.4% of traffic, 169 unique clients France - 34.6% of traffic, 473 unique clients Germany - 18.7% of traffic, 3333 unique clients Portugal - 47.5% of traffic, 63 unique clients Netherlands - 18.4% of traffic, 152 unique clients Spain - 3.5% of traffic, 9 unique clients However, the question in $SUBJ _is_ certainly valid, Andrei brought it up too. Well, for Joe Consumer in his armchair it brings nothing, and he or she will not even notice. When I started playing with ipv6, I think I had the following reasons - * ipv4 is boring, btdt. * need to have ipv6, to write/test code for it. * want to know ipv6, it's a challenge and fun learning. * avoid problems when the ipv4 pool is exhausted. -- Per Jessen, Zürich (17.5°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes

7 84

Boot Problem
by Mark Misulich 29 Apr '23

29 Apr '23

Hi, I restarted my computer and when it attempted to restart, it didn't boot to the opensuse grub operating system selection screen for my multiboot computer with Opensuse Tumbleweed and Windows11. It instead booted to grub command line. I tried to research the problem on the internet to try to correct this problem from grub command line, but none of the attempts I have made have worked. The commands only bring up the response "file system unknown" instead of the expected response. I've gotten Tumbleweed to boot with supergrub2-206s2-beta1-multiarch-USB, where no other version of supergrub2 would work to boot Tumbleweed from the bios bootmenu. I thought, "Great, I'm out of the woods. I'll just reinstall the grub2-efi bootloader via yast2, and I'll be back in business!" But it didn't work out that way. When I try to do that, I get this message: Error Execution of command "[["/usr/sbin/shim-install", "-config-file=/boot/grub2/grub.cfg"]]" failed. Exit code: 1 Error output: /usr/sbin/grub2-probe: error: ../grub-core/kern/fs.c: 121:unknown filesystem. I've been launched into another Linux learning adventure without asking for the opportunity, so can the list advise me how to get this problem fixed? This may not be pertinent to this problem, but when I select Windows boot manager from the bios boot list, windows boots normally from that point. I'm running opensuse Tumbleweed 20230416 with KDE PLasma version: 5.27.4 KDE Frameworks Version: 5.105.0 Qt Version: 5.15.8 Kernel Version: 6.2.10-1-default (64-bit) Thanks, Mark

3 9