Install. von UCS@school a. frischem UCS4-System schlägt fehl

UCS@school
#1

Hallo zusammen!

Ich habe ein Problem mit der Installation von UCS@school in UCS4:

Ausgangslage: frische Neuinstallation eines DC-Master, DC-Backup, DC-Slave - alle Join-Scripte sind erfolgreich beendet worden
DC-M und DC-B befinden sich in einem Subnet, der DC-S in einem anderen. Das Routing zwischen beiden Netzen funktioniert uneingeschränkt. Der DC-S konnte problemlos der UCS-Domäne beitreten.

Installation und Multiserver-Konfiguration von UCS@school gemäß Doku auf DC-M, sowie dem DC-B - alles ohne Probleme

Anschließend Installation und Konfiguration von UCS@school mit Einrichtung der Schule auf dem DC-S (edukativer Schulserver)

Beim erneuten Joinen des Schulservers kommt es zu Problemen:

97univention-s4-connector bricht mit Fehler ab.
Ein manueller Versuch eines erneuten Joins mit ‘univention-join’ schlägt ebenfalls fehl.

Offenbar funktioniert der S4-Connector nicht richtig. Laut Statuslog gibt es einen Auth-Fehler.

Seit der Installation von UCS@school auf dem Schulserver tauchen außerdem diverse Fehler im Samba-Log auf (sieht nach kerberos aus) - sowohl beim DC-M/DC-B als auch beim Schulserver.

Ich habe die komplette Installation aller UCS-Systeme bereits zwei Mal als saubere Neuinstallation durchgeführt - beide Male tauchten diese Probleme auf (=> reproduzierbar!).

Ausschnitt aus join.log:

[...]
Configure 03univention-directory-listener.inst Sun Jan 25 15:28:18 CET 2015
2015-01-25 15:28:18.663274738+01:00 (in joinscript_init)
Setting ldap/database/ldbm/dbsync
Multifile: /etc/ldap/slapd.conf
25.01.15 15:28:19.568  DEBUG_INIT
WARNING: No path in service IPC$ - making it unavailable!
NOTE: Service IPC$ is flagged unavailable.
UNIVENTION_DEBUG_BEGIN  : uldap.__open host=sydney.domain.local port=7389 base=dc=domain,dc=local
UNIVENTION_DEBUG_END    : uldap.__open host=sydney.domain.local port=7389 base=dc=domain,dc=local
25.01.15 15:28:21.421  LISTENER    ( ERROR   ) : import of filename=/usr/lib/univention-directory-listener/system/ucsschool-s4-branch-site.py failed
Traceback (most recent call last):
  File "/usr/lib/univention-directory-listener/system/ucsschool-s4-branch-site.py", line 134, in <module>
    raise ImportError("Error accessing LDAP via machine account: %s" % (ex,))
ImportError: Error accessing LDAP via machine account: {'desc': 'Invalid credentials'}
25.01.15 15:28:21.421  LISTENER    ( ERROR   ) : import of filename=/usr/lib/univention-directory-listener/system/ucsschool-s4-branch-site.py failed in module_import()

[...]

Configure 97univention-s4-connector.inst Sun Jan 25 15:41:57 CET 2015
[...]
Starting univention-s4-connector daemon.
done.
Setting dns/backend
Restarting bind9 daemon: .
done.
Wait for bind9: .Restarting bind9 daemon: .
done.
Stopping Samba AD DC daemon: samba.
Starting Samba AD DC daemon: samba.
....................................................................................................Restarting bind9 daemon: .
done.
....................................................................................................Restarting bind9 daemon: .
done.
Stopping Samba AD DC daemon: samba.
Starting Samba AD DC daemon: samba.
....................................................................................................Restarting bind9 daemon: .
done.
....................................................................................................Restarting bind9 daemon: .
done.
Stopping Samba AD DC daemon: samba.
Starting Samba AD DC daemon: samba.
....................................................................................................Restarting bind9 daemon: .
done.
....................................................................................................Restarting bind9 daemon: .
done.
Stopping Samba AD DC daemon: samba.
Starting Samba AD DC daemon: samba.
Setting connector/s4/poll/sleep
Setting connector/s4/retryrejected
 failed
Setting dns/backend
Restarting bind9 daemon: .
done.
**************************************************************
* ERROR: Failed to configure Samba4 as backend for bind.     *
*        Please check the samba and the s4-connector logfile.*
**************************************************************
Sun Jan 25 15:53:34 CET 2015: finish /usr/sbin/univention-join

connector-s4-status.log:

[code]Sun Jan 25 15:55:16 2015
— connect failed, failure was: —

Traceback (most recent call last):
File “/usr/lib/pymodules/python2.7/univention/s4connector/s4/main.py”, line 280, in main
connect()
File “/usr/lib/pymodules/python2.7/univention/s4connector/s4/main.py”, line 163, in connect
baseConfig[’%s/s4/listener/dir’ % CONFIGBASENAME])
File “/usr/lib/pymodules/python2.7/univention/s4connector/s4/init.py”, line 723, in init
univention.s4connector.ucs.init(self, CONFIGBASENAME, property, baseConfig, listener_dir)
File “/usr/lib/pymodules/python2.7/univention/s4connector/init.py”, line 436, in init
self.open_ucs()
File “/usr/lib/pymodules/python2.7/univention/s4connector/init.py”, line 469, in open_ucs
self.lo=univention.admin.uldap.access(host=host, port=port, base=self.baseConfig[‘ldap/base’], binddn=binddn, bindpw=bindpw, start_tls=2, follow_referral=True)
File “/usr/lib/pymodules/python2.7/univention/admin/uldap.py”, line 263, in init
raise univention.admin.uexceptions.authFail, _( “Authentication failed” )
authFail: Authentication failed

— retry in 30 seconds —
[/code]

Ausschnitt aus log.samba (Schulserver):

[2015/01/25 16:03:32.216254, 1, pid=3338] ../source4/auth/gensec/gensec_gssapi.c:650(gensec_gssapi_update) GSS server Update(krb5)(1) Update failed: Miscellaneous failure (see text): Decrypt integrity check failed [2015/01/25 16:03:34.294930, 0, pid=3348] ../lib/util/util_runcmd.c:324(samba_runcmd_io_handler) /usr/sbin/samba_dnsupdate: Traceback (most recent call last): [2015/01/25 16:03:34.295003, 0, pid=3348] ../lib/util/util_runcmd.c:324(samba_runcmd_io_handler) /usr/sbin/samba_dnsupdate: File "/usr/sbin/samba_dnsupdate", line 619, in <module> [2015/01/25 16:03:34.295106, 0, pid=3348] ../lib/util/util_runcmd.c:324(samba_runcmd_io_handler) /usr/sbin/samba_dnsupdate: get_credentials(lp) [2015/01/25 16:03:34.295158, 0, pid=3348] ../lib/util/util_runcmd.c:324(samba_runcmd_io_handler) /usr/sbin/samba_dnsupdate: File "/usr/sbin/samba_dnsupdate", line 130, in get_credentials [2015/01/25 16:03:34.295171, 0, pid=3348] ../lib/util/util_runcmd.c:324(samba_runcmd_io_handler) /usr/sbin/samba_dnsupdate: raise e [2015/01/25 16:03:34.295207, 0, pid=3348] ../lib/util/util_runcmd.c:324(samba_runcmd_io_handler) /usr/sbin/samba_dnsupdate: RuntimeError: kinit for SYDNEY$@DOMAIN.LOCAL failed (Looping detected inside krb5_get_in_tkt) [2015/01/25 16:03:34.295224, 0, pid=3348] ../lib/util/util_runcmd.c:324(samba_runcmd_io_handler) /usr/sbin/samba_dnsupdate: [2015/01/25 16:03:38.348659, 1, pid=3338] ../source4/auth/gensec/gensec_gssapi.c:650(gensec_gssapi_update) GSS server Update(krb5)(1) Update failed: Miscellaneous failure (see text): Decrypt integrity check failed

Ausschnitt aus log.samba (DC-Master):

[2015/01/25 16:10:42.641985, 0, pid=11292] ../source4/librpc/rpc/dcerpc_util.c:729(dcerpc_pipe_auth_recv) Failed to bind to uuid e3514235-4b06-11d1-ab04-00c04fc2dcd2 for ncacn_ip_tcp:172.17.10.1[1024,seal,krb5,target_hostname=47fd3445-bf56-48d8-8380-0191d36a8e18._msdcs.domain.local,target_principal=GC/sydney.domain.local/domain.local,abstract_syntax=e3514235-4b06-11d1-ab04-00c04fc2dcd2/0x00000004,localaddress=172.28.10.1] NT_STATUS_UNSUCCESSFUL

#2

Hallo,

das habe ich so noch nicht gesehen - das sollte natürlich funktionieren.
Ich werde parallel einmal eine entsprechende Testumgebung vorbereiten - könnten Sie mir zu Vergleichszwecken bitte die komplette join.log vom Schulslave zukommen lassen?
Weiterhin hilfreich könnten die Paketlisten aller drei Systeme sein (dpkg -l).

Mit freundlichen Grüßen,
Tim Petersen

#3

Hallo,

ich habe das Verhalten gerade eben tatsächlich doch reproduziert und ein Problem identifiziert (Bug #35248).

Bitte prüfen Sie die UCR-Variable connector/ldap/binddn:

ucr get connector/ldap/binddn

Ich vermute Sie ist nicht identisch mit ldap/hostdn:

ucr get ucr get ldap/hostdn

Das muss sie aber sein :slight_smile: - folgende Schritte werden das korrigieren und den Schul-Slave sauber joinen:

ucr set connector/ldap/binddn=$(ucr get ldap/hostdn) invoke-rc.d univention-s4-connector restart univention-run-join-scripts

Der alte Wert wird beim initialen join des Slaves gesetzt, sofern hier Samba 4 installiert wurde. Der Wert ist die DN des Slaves zu diesem Zeitpunkt. Beim Einrichten von UCS@School wird das Rechnerobjekt verschoben - diese Änderung wird momentan nicht im Joinskript korrigiert. Wir werden dies zeitnah per Erratum beheben.

Mit freundlichen Grüßen,
Tim Petersen

#4

Hallo,

vielen Dank!

Ich werde mir das morgen einmal anschauen. Aber da ich bereits vor der UCS@school-Installation Samba4 (sowie auch den DHCP-Server) auf dem Slave installiert hatte, klingt dies plausibel.

Gruß,
H. Röhrup

#5

Hallo,

so, nach einem Check und auch einer erneuten Installation in einer Testumgebung kann ich die Variablenbelegung bestätigen und auch den Workaround. Der Join-Vorgang funktioniert dann.

Die beobachteten Fehlermeldungen im Samba-Log, welche nach der UCS@school-Installation und -Konfiguration auftauchen, bleiben aber bestehen. Kann man diese ignorieren? Das Logfile wächst jedenfalls relativ schnell… Die Einträge scheinen sich alle 5 Sekunden zu wiederholen.

Gruß,
H. Röhrup

#6

Sehr schön!

Die Meldungen sind tatsächlich harmlos - das sind Verbindungsanfragen des Masters (und vermutlich des Backups) via Samba 4 - da der Schulslave initial in “deren” Samba 4 gejoined war, ist der Slave dort noch “bekannt”. Da auf dem Schulslave aber ein eigenes Samba 4 provisioniert wurde (Standard UCS@School Konzept) antwortet er nicht.

Sie können das ganz simpel bereinigen, indem Sie das Rechnerobjekt des Schulslaves auf dem Master im S4 entfernen (als computername entsprechend den hostnamen des slave eintragen - bei mir “slave”):

[code]root@master:/usr/share/univention-samba4/scripts# ./purge_s4_computer.py --computername=slave
WARNING: No path in service IPC$ - making it unavailable!
NOTE: Service IPC$ is flagged unavailable.
Really remove slave from Samba 4? [y/N]: y
If you are really sure type YES and hit enter: YES
Ok, continuing as requested.

Removing dns/alias ‘f15943f3-0fec-4e65-87c6-4fa880bc624a._msdcs’ from Univention Directory Manager
Removing location ‘0 100 88 slave.schule.domain.’ from dns/srv_record _kerberos._tcp.Default-First-Site-Name._sites via UDM
Removing location ‘0 100 88 slave.schule.domain.’ from dns/srv_record _kerberos._tcp.Default-First-Site-Name._sites.dc._msdcs via UDM
Removing location ‘0 100 389 slave.schule.domain.’ from dns/srv_record _ldap._tcp.311dbf58-3736-4024-bdac-3e44d65bba37.domains._msdcs via UDM
Removing location ‘0 100 389 slave.schule.domain.’ from dns/srv_record _ldap._tcp.Default-First-Site-Name._sites via UDM
Removing location ‘0 100 389 slave.schule.domain.’ from dns/srv_record _ldap._tcp.Default-First-Site-Name._sites.dc._msdcs via UDM
Removing location ‘0 100 3268 slave.schule.domain.’ from dns/srv_record _gc._tcp via UDM
Removing location ‘0 100 3268 slave.schule.domain.’ from dns/srv_record _ldap._tcp.gc._msdcs via UDM
Removing location ‘0 100 3268 slave.schule.domain.’ from dns/srv_record _gc._tcp.Default-First-Site-Name._sites via UDM
Removing location ‘0 100 3268 slave.schule.domain.’ from dns/srv_record _ldap._tcp.Default-First-Site-Name._sites.gc._msdcs via UDM
Removing CN=SLAVE,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=schule,DC=domain from SAM database.
Removing CN=RID Set,CN=SLAVE,OU=Domain Controllers,DC=schule,DC=domain from SAM database.
Removing CN=SLAVE,OU=Domain Controllers,DC=schule,DC=domain from SAM database.
Really remove slave from UDM as well? [y/N]: N
Ok, stopping as requested.[/code]

Die letzte Abfrage ist natürlich wichtig - im UDM/LDAP wollen wir das Objekt nicht löschen.

Kurz am Rande: In einem Standardszenario wird der Schul-Slave _ohne Samba 4 installiert und dadurch nie initial in das Master S4 gejoined. Die Provisionierung von Samba 4 auf dem Schulslave erfolgt dann via Wizard bei der Einrichtung von UCS@School. Dies nur als kurze Info, es geht natürlich auch so.

Mit freundlichen Grüßen,
Tim Petersen

#7

OK!
Vielen Dank! :slight_smile:

Mastodon