Beta Test linuxmuster.net 7.4

thomas · 26. August 2026 um 17:24

Moin!

linuxmuster-base v7.4.18 liefert 3 Fixes, die durch OPNsense 26.7 notwendig geworden sind:

Squid startet nicht auf frisch installierten Firewalls (#200) – Auf einer frischen OPNsense-Installation der Version 26.7 bekam der Squid-Konfigurationsordner durch OPNsenses eigenen gehärteten Prozess-Umask die falsche Gruppen-Zuordnung (wheel statt squid) – Squid konnte seine eigene Konfiguration nicht mehr lesen und startete mit „Permission denied" nicht. Wird jetzt automatisch korrigiert.
linuxmuster-opnsense-reset bricht auf Firewalls ohne bestehendes Keytab ab (#201) – Der Befehl prüfte vor dem Erstellen eines Keytabs, ob schon eines existiert, und brach bei „keins vorhanden" fälschlich komplett ab, statt einfach ein Neues zu erstellen. Betraf jede Firewall, die noch nie erfolgreich ein Keytab hatte.
os-squid/os-web-proxy-sso/os-freeradius zeigen dauerhaft „misconfigured" (#202) – Da die Pakete per rohem pkg install statt über OPNsenses eigene Plugin-Verwaltung installiert werden, fehlten sie in deren interner Buchführungsliste und wurden in System → Firmware → Plugins fälschlich als fehlkonfiguriert angezeigt – ein rein kosmetisches Problem, jetzt behoben.

Neuinstallationen, die den unter 3. dargestellten Fehler aufweisen, lassen sich auf dem Server einfach mit linuxmuster-opnsense-reset reparieren.

(Assisted by Claude)

VG, Thomas

thomas · 27. August 2026 um 08:19

Hallo Mille!

Danke füt deine Rückmeldung.

Das ist natürlich ein Bug, wenn lmn-appliance startet, ohne dass ein Parameter übergeben wurde. Mindestens -p muss angegeben werden. Ist jetzt gefixt. Das README wurde auch aktualisiert mit Hinweis auf linuxmuster.net 7.3 und LVM.

LVM-Support wurde entfernt, da in der Zwischenzeit für Userdaten ein externer Fileserver empfohlen wird, sodass ein Server mit mehreren Partitionen nicht mehr benötigt wird. Siehe Lmn 7.3 - Fileserver nachträglich einbinden - #9 von brummel

VG, Thomas

ebert · 29. August 2026 um 09:01

Hallo Thomas,

ich habe die von Dir genannten Rechte für die Squid-Konfigurationsdateien erfolgreich getestet. Auch nach einem Reboot startet Squid jetzt sauber.

Ein linuxmuster-opnsense-reset war nicht nötig, um das kosmetische „misconfigured“-Problem zu beheben. Es hat genügt, die drei Plugins zu deinstallieren und wieder manuell zu installieren. Die Konfigurationen, Benutzer und Gruppen werden bei der Deinstallation nicht gelöscht.

Viele Grüße
Matthias

ebert · 1. September 2026 um 14:05

Hallo zusammen,

es scheint so, als hätte ich noch zwei Bugs gefunden:

Neu angelegte Schul-Administratoren und Schüler bekommen ein Erstpasswort, aber es wird sofort angezeigt, dass sie es schon geändert hätten, obwohl das gar nicht stimmt. Man muss das Erstpasswort nochmal explizit setzen.
Bislang wurden doppelte MAC- und IP-Adresse in der Geräteliste der Web-UI farbig hervorgehoben. Dieses Feature scheint jetzt zu fehlen. Die Fehlermeldungen auf der Konsole und in der UI beim Import sind auch nicht sonderlich aussagekräftig. Man müsste also die Log-Datei bemühen, was doch etwas umständlich ist.

Viele Grüße
Matthias

thomas · 1. September 2026 um 17:43

Moin!

Es gibt jetzt ein linuxmuster-linbo v7.4.13 Maintenance-Release:

Netzwerk beim LINBO-Boot (#167): LINBO wartet jetzt beim Booten kurz (standardmäßig bis zu 10s, per neuem Parameter netwait=<n> einstellbar), bis überhaupt ein Netzwerk-Interface auftaucht, bevor es versucht eine IP zu bekommen. Betraf vor allem USB-Netzwerkadapter (z.B. RTL8153), deren Treiber/Firmware ein paar Sekunden später fertig wird als der übrige Hardware-Erkennungslauf — bisher ging LINBO in dem Fall direkt auf „OFFLINE“, ohne es je zu versuchen. Zusätzlich zeigt der Boot-Splash jetzt eine Fortschrittsmeldung, während gewartet wird.

linbo-torrent stop/restart (#168): Ein Fix aus 7.4.12 (#166 — verhindert, dass stop versehentlich die eigene tmux-Session killt) hatte einen Nebeneffekt: von einer ganz normalen Shell aus (kein tmux) wurde stop/restart fälschlich verweigert, sobald nur eine Torrent-Session lief — restart wurde dadurch zum stillen No-Op. Jetzt korrekt behoben, der ursprüngliche #166-Schutz bleibt dabei erhalten.
Shell-Kompatibilität (interne Testabdeckung): Drei echte Bugs in shell_functions behoben, die unter dash (nicht unter der busybox ash, mit der bisher primär getestet wurde) zu Fehlverhalten führten: isalnum() (Bashismus [[ =~ ]], akzeptierte nie gültige Eingaben), iseven() (== statt =, erkannte nie gerade Zahlen), printargs() ($((count++)), crashte komplett unter dash).

Ist alles in den jeweiligen GitHub-Issues (#166, #167, #168) sowie im Changelog dokumentiert. (Co-authored by Claude.)

VG, Thomas

thomas · 2. September 2026 um 15:09

Moin!

linuxmuster-base v7.4.19 fixt einen Bug in linuxmuster-opnsense-reset, der dafür sorgte, dass die Subnetz-Routen verloren gingen. Jetzt ruft es nach dem Reset linuxmuster-import-subnets auf und stellt die Routen für alle in subnets.csv definierten Netze wieder her (b6e4878).

VG, Thomas

baumhof · 2. September 2026 um 19:16

Hallo zusammen,

.. da ist man mal 3 Wochen weg, und wenn man wieder kommt, sind kiloweise neue Pakete da: lauter Probleme gefunden und schon gefixed: ihr habt 54 Meldungen in diesen Tread geschrieben, als ich nicht da war (und ich hab sie jetzt alle gelesen).

Tausend Dank an euch allen, den Findern und den Fixern!

Es macht einfach Spaß, Teil dieser Community zu sein

LG
Holger

juergen · 3. September 2026 um 08:36

Hallo zusammen,

beim Upgrade von 7.3 auf 7.4, genauer bei der Installation des Pakets linuxmuster-tools7 wird bei uns folgender Fehler ausgegeben:

...
Checking students group in LDAP

Checking students groups from schoolclass klassenname
Empty value given for 'member' via setattr(); use delattr() to clear an attribute.

Checking sophomorix hook scripts
...

An dieser Stelle wird das Python Skript /usr/lib/python3/dist-packages/linuxmusterTools/install-scripts/create_students_groups.py aufgerufen, das für jede Klasse die Gruppenzugehörigkeiten zu den Subgruppen *-teachers, *-parents und *-students prüft und ggf. neu setzt.

Da wir keine Eltern-Accounts angelegt haben, hat die Gruppe klassenname-parents logischerweise auch keine Mitglieder.

Ein

python3 -c "
from linuxmusterTools.ldapconnector import LMNLdapReader as lr
for suf in ['-students', '-teachers', '-parents']:
    m = lr.getval(f'/units/klassenname{suf}', 'member')
    print(suf, '->', len(m) if m else 0, 'Mitglieder')
"

im Terminal gibt das auch aus:

-students -> 23 Mitglieder
-teachers -> 2 Mitglieder
-parents -> 0 Mitglieder

Da ich des Pythons nicht sehr mächtig bin, hab ich das Problem mal vom Chatbot meiner Wahl analysieren lassen. Folgende Lösung wurde mir angeboten:

In der Datei /usr/lib/python3/dist-packages/linuxmusterTools/ldapconnector/writers/schoolclass.py steht in Zeile 113

        self.setattr(data={'member': list(set(members))})

Und genau dort entsteht wohl das Problem. Wenn nämlich die Liste members leer ist, wird versucht mit self.setattr(data={'member': []}) eine leere Liste zu setzen, was von ldap3 anscheinend nicht toleriert wird. Die Fehlermeldung von oben gibt den entscheidenden Hinweis: use delattr() to clear an attribute. Hat eine Gruppe keine Mitglieder soll das Attribut gelöscht werden. Wenn das Attribut member einer Subgruppe jedoch nicht existiert, braucht es auch nicht gelöscht werden.

Ersetzt man die Zeile 113 mit folgendem Code

        members = list(set(members))
        if members:
            self.setattr(data={'member': members})
        elif self.schoolclass_data and self.data.get('member'):
            self.delattr(data={'member': None})

läuft das Subgruppen-Checking mit

lmncli schoolclass sync --all

erfolgreich durch:

lmncli: Checking groups of schoolclass klassenname in default-school
	--> teachers group ✅
	--> parents group  ✅
	--> students group ✅
lmncli: Checking groups of schoolclass ...

@Arnaud: Da ich mir nicht zu 100% sicher bin, ob diese Lösung hinreichend ist, kannst Du dir das bei Gelegenheit mal ansehen?

Eventuell löst das ja auch das Problem im Nachbarthread

LG
Jürgen

juergen · 3. September 2026 um 10:17

Hallo @thomas,

im Upgrade-Skript linuxmuster-release-upgrade habe ich in den Zeilen 163-169, genauer in Zeile 165 einen kleinen Fehler entdeckt:

163	# disable obsolete services
164	echo -e "\n## Disabling obsolete services..."
165	for s in isc-dhcp-server6 networkd-wait-online.service systemd-resolved; do
166	     for c in stop disable mask; do
167	         systemctl $c $s
168	     done
169	 done

In Ubuntu 26.04 existiert die Systemd-Unit networkd-wait-online.service nicht. Ich denke, da sollte systemd-networkd-wait-online.service stehen.

Das ist mir aufgefallen, als ich mit

systemctl --failed

nach dem Upgrade mir die Systemd-Units ausgeben ließ, die aufgrund eines Fehlers nicht gestartet werden konnten:

  UNIT                                 LOAD   ACTIVE SUB    DESCRIPTION                  
● systemd-networkd-wait-online.service loaded failed failed Wait for Network to be Online

Ein

systemctl status systemd-networkd-wait-online.service

gab folgende Fehlermeldung aus:

× systemd-networkd-wait-online.service - Wait for Network to be Online
     Loaded: loaded (/usr/lib/systemd/system/systemd-networkd-wait-online.service; enabled; preset: enabled)
    Drop-In: /run/systemd/generator.late/systemd-networkd-wait-online.service.d
             └─10-netplan.conf
     Active: failed (Result: exit-code) since Thu 2026-09-03 11:03:58 CEST; 2min 26s ago
 Invocation: 1b2d3faf7318491db2021d84d845351d
       Docs: man:systemd-networkd-wait-online.service(8)
    Process: 1622 ExecStart=/lib/systemd/systemd-networkd-wait-online -i ens18:degraded (code=exited, status=0/SUCCESS)
    Process: 1634 ExecStart=/lib/systemd/systemd-networkd-wait-online --any --dns -o routable -i ens18 (code=exited, status=1/FAILURE)
   Main PID: 1634 (code=exited, status=1/FAILURE)
   Mem peak: 2.1M
        CPU: 6ms

Sep 03 11:03:58 server.domain.tld systemd[1]: Starting systemd-networkd-wait-online.service - Wait for Network to be Online...
Sep 03 11:03:58 server.domain.tld systemd-networkd-wait-online[1634]: Failed to connect to io.systemd.Resolve.Monitor: No such file or directory
Sep 03 11:03:58 server.domain.tld systemd-networkd-wait-online[1634]: Could not create manager: No such file or directory
Sep 03 11:03:58 server.domain.tld systemd[1]: systemd-networkd-wait-online.service: Main process exited, code=exited, status=1/FAILURE
Sep 03 11:03:58 server.domain.tld systemd[1]: systemd-networkd-wait-online.service: Failed with result 'exit-code'.
Sep 03 11:03:58 server.domain.tld systemd[1]: Failed to start systemd-networkd-wait-online.service - Wait for Network to be Online.

Die Fehlermeldung deuted darauf hin, dass die Systemd-Unit systemd-resolved nicht gestartet ist, was auch logisch ist, die wurde ja im Update-Skript in den Zeilen 163-169 gestoppt, deaktiviert und maskiert.

Und jetzt kommt das große ABER:

Grundsätzlich halte ich es für keine gute Idee, gewisse Systemd-Units pauschal für obsolet zu betrachten und das aus zwei Gründen:

Die beiden Systemd-Units systemd-networkd-wait-online.service und systemd-resolved sind in Ubuntu integraler Bestandteil und sind standardmäßig gestartet. Durch die Deaktivierung und Maskierung entfernen wir uns vom Standardunterbau.
Die Deaktivierung und Maskierung der Systemd-Unit isc-dhcp-server6.service ist bei IPv4-only Netzwerken die einzige Möglichkeit, um IPv6-DHCP-Server abzuschalten. Das geht mMn also in Ordnung.
Auf die Units systemd-networkd-wait-online.service und systemd-resolved verlassen sich jedoch andere Systemd-Units. Eine Deaktivierung und Maskierung der beiden Units kann unter Umständen dafür sorgen, dass sich das System nicht so verhält wie vorgesehen.

Erklärung

systemd-networkd-wait-online.service ist beispielsweise dazu da, auf eine funktionierende Netzwerkverbindung zu warten. Der Start von Diensten, die eine funktionierende Netzwerkverbindung brauchen, um korrekt starten zu können, kann damit entsprechend verzögert werden.

Welche Dienste das konkret sind, kann man sich mit

systemctl list-dependencies systemd-networkd-wait-online.service --reverse

ausgeben lassen:

systemd-networkd-wait-online.service
● └─network-online.target
●   ├─bittorrent.service
●   ├─cups-browsed.service
●   ├─isc-dhcp-server.service
○   ├─iscsid.service
○   ├─open-iscsi.service
●   └─samba-ad-dc.service

Der erfolgreiche Start der Unit systemd-networkd-wait-online.service hängt jedoch wie oben bereits erwähnt von systemd-resolved.service ab, was uns zum eigentlichen

Problem

führt:

Startet man systemd-resolved.service mit den Standardeinstellungen kommen sich systemd-resolved und samba-ad-dc ins Gehege, da systemd-resolved seinen DNS Stub Listener (noch vor dem Starten von samba-ad-dc) an 127.0.0.1:53 bindet, was aber auch samba-ad-dc möchte und für die lokale Namensauflösung essentiell ist. Das führt zu folgendem Fehler beim Starten von samba-ad-dc.service:

...
Sep 03 11:57:17 server.domain.tld systemd[1]: Starting samba-ad-dc.service - Samba AD Daemon...
Sep 03 11:57:17 server.domain.tld systemd[1]: Started samba-ad-dc.service - Samba AD Daemon.
Sep 03 11:57:17 server.domain.tld samba[3245]: [2026/09/03 11:57:17.591265,  0] source4/samba/service_stream.c:371(stream_setup_socket)
Sep 03 11:57:17 server.domain.tld samba[3245]:   stream_setup_socket: Failed to listen on 0.0.0.0:53 - NT_STATUS_ADDRESS_ALREADY_ASSOCIATED
Sep 03 11:57:17 server.domain.tld samba[3245]: [2026/09/03 11:57:17.591303,  0] source4/dns_server/dns_server.c:672(dns_add_socket)
Sep 03 11:57:17 server.domain.tld samba[3245]:   Failed to bind to 0.0.0.0:53 TCP - NT_STATUS_ADDRESS_ALREADY_ASSOCIATED

Lösung

Um zu verhindern, dass systemd-resolved seinen Stub-Listener startet, muss man im Verzeichnis /etc/systemd/resolved.conf.d die Datei no-stub.conf mit folgendem Inhalt erstellen. (Es kann sein, dass das Verzeichnis /etc/systemd/resolved.conf.d noch nicht existiert → mkdir -p /etc/systemd/resolved.conf.d)

# /etc/systemd/resolved.conf.d/no-stub.conf
[Resolve]
DNSStubListener=no

Ein anschließendes

systemctl restart systemd-resolved.service
systemctl restart systemd-networkd-wait-online.service
systemctl restart samba-ad-dc.service

startet die Dienste in der richtigen Reihenfolge.

Auf Systemen, auf denen das Upgrade bereits durchgelaufen ist, muss man vorher die beiden System-Units systemd-resolved.service und systemd-networkd-wait-online.service wieder demaskieren und aktivieren:

systemctl unmask networkd-wait-online.service
for s in systemd-resolved.service systemd-networkd-wait-online.service; do
    for c in unmask enable; do
        systemctl $c $s
    done
done

LG
Jürgen

Jesko · 3. September 2026 um 11:07

Hallo Jürgen,

systemd-resolved absichtlich abzuschalten, ist auf einem Samba-AD-Domaincontroller durchaus plausibel: Samba soll selbst DNS auf Port 53 bereitstellen. Aktiviert man systemd-resolved, entsteht genau der beobachtete Portkonflikt. Mit DNSStubListener=no lässt sich der Konflikt zwar vermeiden, aber danach muss zusätzlich sehr sorgfältig geklärt werden:

Worauf zeigt /etc/resolv.conf?
Nutzt der Server für seine eigene Auflösung weiterhin den Samba-DNS?
Werden die eigene AD-Domain und kurze Rechnernamen richtig aufgelöst?
Entsteht eventuell eine DNS-Schleife oder wird Samba-DNS umgangen?

Ich hab bei mir die Dienste auch maskiert und daraufhin im Boot-Log keine weiteren Auffälligkeiten feststellen können, die darauf hindeuten, dass systemd durcheinander gekommen wäre…
LG Jesko

thomas · 3. September 2026 um 11:52

Hallo Jürgen und Jesko,

vielen Dank für die Beiträge.

D.h. du hast systemd-networkd-wait-online.service auch maskiert, da ja sonst wg. maskiertem systemd-resolved.service der Bootprozess hängt?

VG, Thomas

thomas · 3. September 2026 um 13:02

Ich fixe jetzt erstmal den Typo bzgl. systemd-networkd-wait-online.service und lasse die angesprochenen Services maskiert.

thomas · 3. September 2026 um 13:11

juergen · 3. September 2026 um 13:21

Hallo @Jesko,

Das ist bei systemd-resolved zweitrangig, da die Informationen in /etc/resolv.conf im Global-Block landen und nur dann genutzt werden, wenn kein Interface eigene DNS-Einstellungen mitbringt. Da in der Netplan-Konfiguration die Nameserver hinterlegt sind, greifen diese auch.
Ausgabe von resolvectl status (die 10.0.0.6 ist unser zweiter DC, warum da bei uns aber noch die firewall als DNS-Server drinsteht, kann ich im Moment auch nicht beantworten, muss das nochmal prüfen):

Global
         Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
  resolv.conf mode: foreign
Current DNS Server: 10.0.0.1
       DNS Servers: 10.0.0.1 10.0.0.254 10.0.0.6
        DNS Domain: domain.tld

Link 2 (ens160)
    Current Scopes: DNS
         Protocols: +DefaultRoute -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
       DNS Servers: 10.0.0.1 10.0.0.254 10.0.0.6
        DNS Domain: domain.tld
     Default Route: yes

Übrigens: das foreign in der Zeile resolv.conf mode: bedeutet, dass /etc/resolv.conf eine Datei ist. Wenn /etc/resolv.conf ein Symlink auf /run/systemd/resolve/stub-resolv.conf wäre, dann stünde dort statt foreign uplink.

Netplan-Konfig /etc/netplan/01-netcfg.yaml:

network:
  ethernets:
    ens160:
      addresses:
      - 10.0.0.1/24
      dhcp4: false
      dhcp6: false
      nameservers:
        addresses:
        - 10.0.0.1
        - 10.0.0.254
        - 10.0.0.6
        search:
        - domain.tld
      routes:
      - to: default
        via: 10.0.0.254
      ...
  version: 2

Ja, siehe Zeile Current DNS Server: 10.0.0.1 in obiger Ausgabe von resolvectl status.

Ja, siehe Ausgabe von resolvectl query a015-lpc03

a015-lpc03: 10.10.15.109                       -- link: ens160
            (a015-lpc03.domain.tld)

-- Information acquired via protocol DNS in 2.0ms.
-- Data is authenticated: no; Data was acquired via local or encrypted transport: no
-- Data from: network

Wenn die Firewall korrekt konfiguriert ist (wovon ich ausgehe, da an deren Konfiguration nichts geändert wurde) und in der /etc/samba/smb.conf die Firewall als DNS Forwarder eingetragen ist dns forwarder = 10.0.0.254 sehe ich keine Gefahr für einen DNS-Loop oder das Umgehen vom Samba-DNS. Vielleicht übersehe ich da aber auch etwas…

Auf unserem zweiten DC, der ziemlich ähnlich konfiguriert ist wie der server hat sich ntpsec genau deswegen beim Starten verschluckt, weil die Netzwerkverbindung noch nicht vollständig hergestellt war.

Mit gestarteten Units systemd-resolved und systemd-networkd-wait-online sowie der Datei /etc/systemd/resolved.conf.d/no-stub.conf gab es hier auch keine Auffälligkeiten im Bootlog oder sonstige Probleme mit dem DNS. Ich beobachte aber weiter.

Mir persönlich ist es lieber, wenn ich 1. verstehe, wie die Dienste funktionieren und 2. nur minimale Anpassungen am darunterliegenden System vorgenommen werden müssen, das ja auch austauschbar im Sinne von upgradefähig sein soll.

Am Ende des Tages ist es aber eine Designentscheidung der Entwickler.

LG
Jürgen

thomas · 3. September 2026 um 13:30

Hallo Jürgen,

Ja, das ist ein Argument. Es gibt einen Issue hierzu. Evtl. wäre es ganz gut, wenn noch jemand deinen Vorschlag mal eine Weile auf seinem Produktivsystem laufen lässt.

VG, Thomas

Jesko · 3. September 2026 um 14:28

Genau. Dass der bootprozess hing ist mur nicht aufgefallen aber dass die unit „failed“ war schon. Und dann hab ich die dependency gesehen und den service maskiert. Ich hatte sonst keine Abhängigkeit festgestellt wenn ich mich richtig erinnere.

Jesko · 3. September 2026 um 14:31

Das ist unbestritten ein Standpunkt den ich auch unterschreiben würde

Ich mach das dann bei mir auch mal so und dann sehen wie schon auf zwei Systemen ob es klappt

Jesko · 3. September 2026 um 14:32

Ich richte das heut abend ein.

juergen · 4. September 2026 um 20:51

Hallo @Arnaud,

wir nutzen an unserer Schule kein Quota und haben deshalb in der schul.conf die Quota-Parameter in den Abschnitten [role.student], [role.teacher] und [role.schooladministrator] wie folgt gesetzt:

QUOTA_DEFAULT_GLOBAL = -1
QUOTA_DEFAULT_SCHOOL = -1
MAILQUOTA_DEFAULT = -1

sophomorix-quota setzt Hard- und Softlimits für jeden User korrekt auf 0K (unlimited), was man mit

repquota -s /srv/samba/schools/default-school/

prüfen kann:

*** Report for user quotas on device /dev/mapper/vg_srv-default--school
Block grace time: 7days; Inode grace time: 7days
                        Space limits                File limits
User            used    soft    hard  grace    used  soft  hard  grace
----------------------------------------------------------------------
...
#3006538  --  14536K      0K      0K             46     0     0       
#3008510  --     48K      0K      0K              4     0     0
...

Wenn ich nun in der Schulkonsole als Global-Administrator oder Schul-Administrator anmelde und in der Navigationsleiste EINSTELLUNGEN → Schuleinstellungen auswähle, erscheinen rechts oben im Browser mehrere dieser Warnungen:

Wähle ich in den Schuleinstellungen den Reiter Kontingent aus, dann sind die Felder für die Standardquotas leer:

In der Web-Konsole werden mehrere der nachstehenden Ausnahmefehler ausgegeben:

Offenbar versteht Ajenti -1 nicht als Number. Kannst Du Dir das bei Gelegenheit mal anschauen?

LG
Jürgen