!Beta-Test v7.3 - 2. Phase!

Hallo Holger,

…danke, dann probiere ich gleich mal…

powercfg.exe /hibernate off

…ich bin gespannt ob es funktioniert…(Meldung folgt…)

MfG
Mario

Doch:

openssl s_client -connect localhost:636 -showcerts
CONNECTED(00000003)
Can't use SSL_get_servername
depth=0 C = DE, ST = BW, L = Schorndorf, O = Johann-Philipp-Palm-Schule, OU = JPP, CN = server.jpp.lan, emailAddress = administrator@jpp.lan
verify error:num=18:self-signed certificate
verify return:1
depth=0 C = DE, ST = BW, L = Schorndorf, O = Johann-Philipp-Palm-Schule, OU = JPP, CN = server.jpp.lan, emailAddress = administrator@jpp.lan
verify return:1
---
Certificate chain
 0 s:C = DE, ST = BW, L = Schorndorf, O = Johann-Philipp-Palm-Schule, OU = JPP, CN = server.jpp.lan, emailAddress = administrator@jpp.lan
   i:C = DE, ST = BW, L = Schorndorf, O = Johann-Philipp-Palm-Schule, OU = JPP, CN = server.jpp.lan, emailAddress = administrator@jpp.lan
   a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
   v:NotBefore: May 28 10:25:55 2025 GMT; NotAfter: May 28 10:25:55 2026 GMT

Uhm, danke.
Ist die Datei /etc/linuxmuster/webui/config.yml vollständig mit Bind-DN und Bind-Pwd ?

Ja, ist komplett. Denke auch nicht, dass es an der Webui liegt, sophomorix-check ging ja auch erst, als ich das Gruppenrecht auf administrator gesetzt habe.

Hallo Holger,
auch das hat nicht geholfen…, mit v7.2 und den selben Client funktioniert es übrigens ganz wunderbar.

Hier noch schnell ein Bild…

MfG Mario

Hi Lars,

Das habe ich entweder verpasst oder nicht verstanden: was musstest du genau machen ?

Gruß

Arnaud

Ich wollte sehen, ob der LDAP reagiert und habe ein sophomorix-check gemacht. Das hat nicht funktioniert.

Nachdem ich die Rechte für die .secret/administrator von -r-------- 1 auf -r--r----- 1 gesetzt hatte, ging das sophomorix-check durch.

Hallo LArs,

als wer warst du den an der console angemeldet?
LG
Holger

als root…

Hallo Lars,

Das ist nicht normal. Die Datei .secret/administrator sollte schon die Rechte 400 haben und nicht 440, und sophomorix-check sollte es problemlos damit umgehen. Ich verstehe ehrlich nicht was da los ist und kann es nicht auf meinen Testssystem reproduzieren.

Diese Meldung in sophomorix-check bedeutet auf jedem Fall, dass das Passwort nicht lesbar war. Falls der AD nicht läuft, gibt es eine andere Fehlermeldung bei sophomorix.

Wurde sophomorix-check als root (der User, nicht einen User aus der Gruppe root) ausgeführt ?

Gruß

Arnaud

Lieber Arnaud,

da hast du mich kalt erwischt. Nein, sophomorix-check habe ich in der Aufregung nicht als root gemacht. Ich habe jetzt wieder die Rechte 400 vergeben und als root kann man es auch ausführen.

Trotzdem kann man sich über die WebUI nicht einloggen, hier der Stacktrace:

Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/linuxmusterTools/ldapconnector/connector.py", line 78, in _connect
    conn.bind_s(binddn, bindpwd)
  File "/usr/lib/python3/dist-packages/ldap/ldapobject.py", line 263, in bind_s
    msgid = self.bind(who,cred,method)
            ^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/ldap/ldapobject.py", line 257, in bind
    return self.simple_bind(who,cred)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/ldap/ldapobject.py", line 242, in simple_bind
    return self._ldap_call(self._l.simple_bind,who,cred,RequestControlTuples(serverctrls),RequestControlTuples(clientctrls))
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/ldap/ldapobject.py", line 128, in _ldap_call
    result = func(*args,**kwargs)
             ^^^^^^^^^^^^^^^^^^^^
ldap.SERVER_DOWN: {'result': -1, 'desc': "Can't contact LDAP server", 'ctrls': [], 'info': '(unknown error code)'}

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/opt/linuxmuster/lib/python3.12/site-packages/aj/api/endpoint.py", line 77, in wrapper
    result = fx(self, context, *args, **kwargs)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/opt/linuxmuster/lib/python3.12/site-packages/ajenti_plugin_core/views/api.py", line 141, in handle_api_auth
    auth_info = auth.check_password(username, password)
                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/opt/linuxmuster/lib/python3.12/site-packages/aj/auth.py", line 192, in check_password
    return self.get_provider().authenticate(username, password)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/linuxmuster-webui/plugins/lmn_auth/api.py", line 204, in authenticate
    userAttrs = self.get_ldap_user(username, attributes=attributes)
                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/linuxmuster-webui/plugins/lmn_auth/api.py", line 59, in get_ldap_user
    return self.lr.get(f'/users/{username}', attributes=attributes)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/linuxmusterTools/ldapconnector/urls/ldaprouter.py", line 57, in get
    return self.lr.get_single(func.model, ldap_filter, scope=func.scope, subdn=subdn, dn_filter=func.dn_filter, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/linuxmusterTools/ldapconnector/ldap_reader.py", line 80, in get_single
    results = self.lc._get(ldap_filter, scope=scope, subdn=subdn)
              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/linuxmusterTools/ldapconnector/connector.py", line 108, in _get
    conn, _searchdn = self._connect()
                      ^^^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/linuxmusterTools/ldapconnector/connector.py", line 87, in _connect
    raise Exception(f'Ldap server down: {str(e)}')
Exception: Ldap server down: {'result': -1, 'desc': "Can't contact LDAP server", 'ctrls': [], 'info': '(unknown error code)'}

samba-ad-dc ist nach wie vor running.

LG

Lars

Login an den Clients funktioniert - Problem scheint also an der LDAP-Connection zu liegen (was die Meldungen ja auch sagen).

Edit:
Wir haben einen Dienst, der auch über LDAPS (636) connected, da kann ich mich ebenfalls noch anmelden. Hmmmm…

Hallo an alle,

ein neues Problem ist aufgepoppt. Heute kam es bei einigen Clients vor, das die Serverfreigaben nicht gemountet werden konnten. Nach langer Suche habe ich gesehen, dass diese Clients nicht mehr die richtige Uhrzeit hatten.
Die Zeitsynchronisation des Servers mit der OPNSense klappt, d.h. der Server bekommt die richtige Zeit.
Es ist so, dass seit dem Update auf 7.3 die Clients die Zeit nicht mehr mit dem Server synchronisieren können.
Eigentlich dachte ich, dass Linbo die richtige Uhrzeit beim Sync setzt aber das funktioniert auch nicht mehr!? Stellt nicht Linbo normalerweise die Hardwarezeit auf die Zeit des Servers?

Hier der Fehler auf den Clients und die config:

root@hp-client-test:~ systemctl status systemd-timesyncd.service 
● systemd-timesyncd.service - Network Time Synchronization
     Loaded: loaded (/usr/lib/systemd/system/systemd-timesyncd.service; enabled; preset: enabled)
     Active: active (running) since Thu 2025-07-17 20:07:10 CEST; 6min ago
       Docs: man:systemd-timesyncd.service(8)
   Main PID: 3738 (systemd-timesyn)
     Status: "Idle."
      Tasks: 2 (limit: 8970)
     Memory: 1.3M (peak: 2.1M)
        CPU: 32ms
     CGroup: /system.slice/systemd-timesyncd.service
             └─3738 /usr/lib/systemd/systemd-timesyncd

Jul 17 20:07:10 hp-client-test systemd[1]: Starting systemd-timesyncd.service - Network Time Synchronization...
Jul 17 20:07:10 hp-client-test systemd[1]: Started systemd-timesyncd.service - Network Time Synchronization.
Jul 17 20:07:21 hp-client-test systemd-timesyncd[3738]: Timed out waiting for reply from 10.16.1.1:123 (server.linuxmuster.windeck-gymnasium.de).
root@hp-client-test:~ cat /etc/systemd/timesyncd.conf

#
# WARNING! All changes to this file will be overwritten by linuxmuster-linuxclient7 setup and upgrade!
#

[Time]
NTP=server.xxxxxxxx.xxxxxxxxxx-gymnasium.de

Der Client darf den Server auf Port 123 kontaktieren, daran liegt es nicht.

Wenn ich als NTP-Server auf dem Client die OPNSense eintrage funktioniert der timesync sofort…das ist auch gerade mein Workaround. Aus irgendeinem Grund lehnt der Server NTP Anfragen seit 7.3 ab:

root@hp-client-test:~ telnet 10.16.1.1 123
Trying 10.16.1.1...
telnet: Unable to connect to remote host: Verbindungsaufbau abgelehnt

Auf dem Server wird aber eigentlich gelauscht:

> netstat -tulpn | grep ntp                                                                                                      23m 2s root@server 20:21:18
udp        0      0 10.16.1.1:123           0.0.0.0:*                           59235/ntpd          
udp        0      0 127.0.0.1:123           0.0.0.0:*                           59235/ntpd          
udp        0      0 0.0.0.0:123             0.0.0.0:*                           59235/ntpd

Hier die ntp.conf:

> cat /etc/ntpsec/ntp.conf                                                                                                              root@server 20:21:28
# /etc/ntpsec/ntp.conf
#
# thomas@linuxmuster.net
# 20250707
#
# configuration for ntpd; see ntp.conf(5) for help

driftfile /var/lib/ntpsec/ntp.drift
statistics loopstats peerstats clockstats
filegen loopstats file loopstats type day enable
filegen peerstats file peerstats type day enable
filegen clockstats file clockstats type day enable
server 10.16.1.254 iburst prefer
restrict -4 default kod notrap nomodify nopeer noquery limited mssntp
restrict -6 default kod notrap nomodify nopeer noquery limited mssntp
restrict 127.0.0.1
restrict ::1
restrict source notrap nomodify noquery
ntpsigndsocket /var/lib/samba/ntp_signd

Wo läuft das was falsch? Ich hätte gerne wieder, dass die Clients ihre Zeit mit dem Server synchronisieren, denn selbst wenn der mal falsch geht hätte ich keine Zeitdrift und es gäbe kein Problem.

VG

Dominik

Ich führe mal wieder Selbstgespräche :see_no_evil:,

hier habe ich einen Ansatz gefunden.

Ich habe bei mir die folgende Zeile in die ntp.conf auf dem Server eingetragen:

restrict 10.16.0.0 mask 255.240.0.0 nomodify notrap

Das umfasst alle meine Subnetze.

Jetzt funktioniert die Zeitsynchronisation vom Client mit dem Server.

Habe ich da einen Bug in der Konfiguration gefunden, d.h. müsste der Eintrag je nach Subnetzen in der subnet.conf erfolgen oder ist bei mir etwas nicht so wie es sein sollte?

Was mir immer noch nicht klar ist, wieso Linbo beim Syncen nicht die richtige Hardwarezeit einstellt…ist das nicht mehr so oder funktioniert das in der 7.3 nicht oder funktioniert das nur bei mir nicht @thomas ?

VG

Dominik

Hi Lars,

Funktioniert ein ldapsearch auf dem Server ?

ldapsearch -x -H ldaps://localhost:636 -LLL "sAMAccountName=global-admin" -b 'DC=DEIN,DC=DOMAIN' -D 'CN=Administrator,CN=Users,DC=DEIN,DC=DOMAIN' -w $(cat /etc/linuxmuster/.secret/administrator) cn

(DEIN DOMAIN bitte anpassen :wink: )

Wenn nicht, geht es mit ldap://localhost:389 ?

Gruß

Arnaud

Hallo Arnaud,

nein, bei beiden kommt ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1).

Andererseits funktioniert auch der Login mit Webuntis per LDAP-Integration…

LG

Lars

Mit LDAPTLS_REQCERT=never funktioniert die Abfrage auf dem localhost mit 636.

Könnte es daran liegen, dass ich das Server-Zertifikat neu erstellt habe (damit die Browser die Verbindung zur Schulkonsole als sicher anzeigen)?

Die ldap.conf sagt:

#
# LDAP Defaults
#

# See ldap.conf(5) for details
# This file should be world readable but not world writable.

#BASE   dc=example,dc=com
#URI    ldap://ldap.example.com ldap://ldap-provider.example.com:666

#SIZELIMIT      12
#TIMELIMIT      15
#DEREF          never

# TLS certificates (needed for GnuTLS)
TLS_CACERT      /etc/ssl/certs/ca-certificates.crt

Muss evtl. ca-certificates.crt ersetzt werden?

Hallo Dominik,

so muss die eigentlich aussehen:

# /etc/ntpsec/ntp.conf
#
# thomas@linuxmuster.net
# 20250707
#
# configuration for ntpd; see ntp.conf(5) for help

driftfile /var/lib/ntpsec/ntp.drift
statistics loopstats peerstats clockstats
filegen loopstats file loopstats type day enable
filegen peerstats file peerstats type day enable
filegen clockstats file clockstats type day enable
server 10.0.0.254 iburst prefer
restrict -4 default kod notrap nomodify nopeer noquery limited mssntp
restrict -6 default kod notrap nomodify nopeer noquery limited mssntp
restrict source notrap nomodify noquery
ntpsigndsocket /var/lib/samba/ntp_signd

Die localhost-Zeilen müssen raus. Irgendwo war das auch schon Thema hier. Nur seltsam, dass das bei dir noch drinsteht.

Daran wie Linbo die Zeit einstellt, wurde schon ewig nichts mehr geändert.

VG, Thomas

Hallo @thomas ,

die Einträge waren da nach dem Udate von 7.2 zu 7.3 drin!?

Ich habe die Einträge entfernt…trotzdem bekommen die Clients vom Server keine Uhrzeit! Ohne den Eintrag:

restrict 10.16.0.0 mask 255.240.0.0 nomodify notrap

geht es nicht! Es wäre gut, wenn das auch mal andere verifizieren könnten, die Subnetting verwenden. Wenn ich mir die Doku von ntp ansehe, dann muss so ein Eintrag eigentlich rein? …zumindest, wenn ich das richtig verstehe!?

Wie kann ich testen, ob das noch funktioniert? Ich habe mehrere Clients mit falscher Uhrzeit und nach der Behandlung mit Linbo ist die Uhrzeit immer noch falsch. Linbo selbst hat aber die richtige Zeit. Da tut was nicht!?

VG

Dominik

Sollte eigentlich mit einem linuxmuster-base-Update korrigiert werden, funktionierte wohl nicht, weil ich das Datum des Konfigurationstemplates nicht aktualisiert habe.

Mein Noble-Client hat kein systemd-timesyncd installiert und hat nach dem Sync die richtige Zeit, kann aber auch am qemu-agent liegen.

Die Subnetze werden nicht in ntp.conf eingetragen, weil das unter 22.04 nicht notwendig war, es hat sich zumindest nie jemand beschwert. Ich würde das auch ungern machen und lieber 0.0.0.0 in ntp.conf eintragen, auf Server-Dienste hat man sowieso nur aus dem LAN heraus Zugriff, wozu das also nochmal explizit für jeden Dienst einstellen?

VG, Thomas