USC System / Web Console defekt

Das UCS System lief 1,5 Jahre ohne Probleme bis es seit ein Paar Tagen nicht mehr richtig funktioniert. Beim Durchsuchen des Forums fand ich bislang keine Lösung. Das System lief in Form einer Xen VM. Das Zurückspielen eines Backups brachte keine Lösung. Zum Problem:

  • Webconsole Login möglich, jedoch bekomme ich bei Aufruf von den meisten Modulen Fehlermeldungen oder leere Seiten
  • Die Verbindung zu den Freigaben des angeschlossenen FreeNAS Server bricht ständig ab
  • Die CPU Auslastung der virtuellen Machine ist oft bei 100% (bei 4 virtuellen Kernen)
  • Ein Versuch einen neu installierten USC 4.4 Server mit univention-join einzubinden schlägt mit Fehlermeldung “Join failed!.. Please visit https://help.univention.com/t/8842…” nameserver1 ist auf die Adresse des Masters gesetzt, die USC Versionen sind gleich (4.4-0 errata113)
    Was empfielt ihr mir als nächstes zu tun?

Hier noch ein kleiner Auszug aus den log Dateien:
management-console-server.log:

26.05.19 15:21:15.352  MAIN        ( PROCESS ) : running: ['/usr/sbin/univention-management-console-module', '-m', 'udm', '-s', '/var/run/univention-management-console/1097-1558876875351.socket', '-d', '2', '-l', 'de_DE.UTF-8']
26.05.19 15:23:11.897  MAIN        ( PROCESS ) : running: ['/usr/sbin/univention-management-console-module', '-m', 'join', '-s', '/var/run/univention-management-console/1097-1558876991896.socket', '-d', '2', '-l', 'de_DE.UTF-8']
26.05.19 15:27:05.350  MAIN        ( WARN    ) : Socket died (module=top)
26.05.19 15:27:05.350  MAIN        ( WARN    ) : Module process top died (pid: 7578, exit status: -1, signal: -1, status: -1)
26.05.19 15:27:05.351  MAIN        ( WARN    ) : Cleaning up requests
26.05.19 15:27:05.351  MAIN        ( PROCESS ) : ModuleProcess: child died
26.05.19 15:33:23.825  MAIN        ( WARN    ) : Socket died (module=join)
26.05.19 15:33:23.825  MAIN        ( WARN    ) : Module process join died (pid: 7868, exit status: -1, signal: -1, status: -1)
26.05.19 15:33:23.825  MAIN        ( WARN    ) : Cleaning up requests
26.05.19 15:33:23.826  MAIN        ( PROCESS ) : ModuleProcess: child died
26.05.19 15:35:44.287  MAIN        ( WARN    ) : Socket died (module=udm)
26.05.19 15:35:44.287  MAIN        ( WARN    ) : Module process udm died (pid: 7785, exit status: -1, signal: -1, status: -1)
26.05.19 15:35:44.287  MAIN        ( WARN    ) : Cleaning up requests
26.05.19 15:35:44.287  MAIN        ( PROCESS ) : ModuleProcess: child died

/management-console-web-server.log:

26.05.19 14:21:10.618  MAIN        ( PROCESS ) : SessionClient(0x7fb3f46c9850): _authenticated: success=True  status=200  message=None
26.05.19 14:21:10.618  MAIN        ( PROCESS ) : auth_type=None
26.05.19 14:21:39.522  MAIN        ( PROCESS ) : CPCommand (192.168.113.104:41658) response status code: 511
26.05.19 14:21:39.522  MAIN        ( PROCESS ) : CPCommand (192.168.113.104:41658) response message: Connection to module process failed
26.05.19 14:21:39.522  MAIN        ( PROCESS ) : CPCommand (192.168.113.104:41658) response result: None

apache2/error.log:

...AH01102: error reading status line from remote server 127.0.0.1:8090..
... AH00898: Error reading from remote server returned by /univention/command/updater/maintenance_information...
...AH00898: Error reading from remote server returned by /univention/command/udm/meta_info...
...AH00898: Error reading from remote server returned by /univention/command/udm/types...

Huhu,

eine Möglichkeit ist, dass die SSL-Zertifikate abgelaufen sind. Was ergeben denn die folgenden Befehle, wenn sie auf dem DC Master ausgeführt werden?

openssl x509 -in /etc/univention/ssl/ucsCA/CAcert.pem -noout -text | grep -Ei 'before|after'
openssl x509 -in /etc/univention/ssl/$(hostname)/cert.pem -noout -text | grep -Ei 'before|after'

Gruß
mosu

Habe nun das Problem lokalisiert. Moglicherweise ist durch den Defekt an der Festplatte der XEN-Servers die virtuelle Festplatte korrumpiert worden. Das Zurückspielen des Backups brachte nichts, da anscheinend unbemerkt die defekte Image-Datei gesichert worden.
Ich konnte nach der Anleitung von hier: https://wiki.univention.de/index.php/Cool_Solution_-_Single_Server_Backup_and_Restore das System neu installieren und Daten wiederherstellen.
Das Einzige, was ich nicht nicht geschafft habe, die Anbindung des FreeNAS Systems.
Scheinbar ist das Zertifikat des neuen Systems anders. Kenne mich mit Zertifikaten nicht besonders aus. Allerdings bekomme ich die Verbindung auch nach dem Importieren der neuen CA unter „System - Certificate Authorities – Add“ nicht.
Kennt vielleicht jemand eine Schritt für Schritt Anleitung zur Anbindung der FreeNAS Samba Freigaben an die UCS Domaine? Oder gibt es einen anderen Tipp?
Gruß
Viktor

PS: habe smbclient -k -L //srv.domain.local -d5 ausprobiert, kann jemand mit der Fehlermeldung etwas anfangen?

“…negotiated dialect[SMB3_11] against server[…]
got OID=1.2.840.48018.1.2.2
GENSEC backend ‘gssapi_spnego’ registered
GENSEC backend ‘gssapi_krb5’ registered
GENSEC backend ‘gssapi_krb5_sasl’ registered
GENSEC backend ‘spnego’ registered
GENSEC backend ‘schannel’ registered
GENSEC backend ‘naclrpc_as_system’ registered
GENSEC backend ‘sasl-EXTERNAL’ registered
GENSEC backend ‘ntlmssp’ registered
GENSEC backend ‘ntlmssp_resume_ccache’ registered
GENSEC backend ‘http_basic’ registered
GENSEC backend ‘http_ntlm’ registered
GENSEC backend ‘http_negotiate’ registered
GENSEC backend ‘krb5’ registered
GENSEC backend ‘fake_gssapi_krb5’ registered
Starting GENSEC mechanism spnego
Starting GENSEC submechanism gse_krb5
smb_gss_krb5_import_cred ccache[FILE:/tmp/krb5cc_0] failed with [ Miscellaneous failure (see text): unknown mech-code 2 for mech 1 2 840 113554 1 2 2] -the caller may retry after a kinit.
Failed to start GENSEC client mech gse_krb5: NT_STATUS_INTERNAL_ERROR
gensec_spnego_client_negTokenInit_step: Could not find a suitable mechtype in NEG_TOKEN_INIT
gensec_update_done: spnego[0x811a57c60]: NT_STATUS_INVALID_PARAMETER
SPNEGO login failed: An invalid parameter was passed to a service or function.
session setup failed: NT_STATUS_INVALID_PARAMETER”

Mastodon