Hallo Holger,
…danke, dann probiere ich gleich mal…
powercfg.exe /hibernate off
…ich bin gespannt ob es funktioniert…(Meldung folgt…)
MfG
Mario
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.
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
,
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
)
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