ldap_sasl_bind(SIMPLE): Can't contact LDAP server

Guten Morgen,

wir haben einen Backup DC zu einem Master hochgestuft und den alten Master DC ausser Betrieb genommen. Bisher gab es keine Probleme. Nun wurde ein Slave DC aufgesetzt auf dem Zarafa installiert werden sollte.
Die Installation schlägt fehlt mit folgender Meldung:

Die Ausführung des Kommandos appcenter/invoke_dry_run ist fehlgeschlagen:

Traceback (most recent call last):
  File "/usr/lib/pymodules/python2.7/univention/management/console/base.py", line 283, in execute
    function(self, request)
  File "/usr/lib/pymodules/python2.7/univention/management/console/modules/appcenter/__init__.py", line 291, in invoke_dry_run
    self.invoke(request)
  File "/usr/lib/pymodules/python2.7/univention/management/console/modules/decorators.py", line 656, in _decorated
    return function(self, request, *args, **kwargs)
  File "/usr/lib/pymodules/python2.7/univention/management/console/modules/decorators.py", line 190, in _response
    return function(self, request)
  File "/usr/lib/pymodules/python2.7/univention/management/console/modules/appcenter/__init__.py", line 492, in invoke
    dry_run_result, previously_registered_by_dry_run = application.install_dry_run(self.package_manager, self.component_manager, remove_component=remove_component, username=self._username, password=self.password, only_master_packages=only_master_packages, dont_remote_install=dont_remote_install, function=function, force=force)
  File "/usr/lib/pymodules/python2.7/univention/management/console/modules/appcenter/app_center.py", line 1272, in install_dry_run
    hosts = self.find_all_hosts(is_master=is_master)
  File "/usr/lib/pymodules/python2.7/univention/management/console/ldap.py", line 135, in _decorated
    result = func(*args, **kwargs)
  File "/usr/lib/pymodules/python2.7/univention/management/console/modules/appcenter/app_center.py", line 1575, in find_all_hosts
    hosts.append((get_master(lo), True))
  File "/usr/lib/pymodules/python2.7/univention/management/console/modules/appcenter/util.py", line 102, in get_master
    return get_hosts(domaincontroller_master, lo)[0].info['fqdn']
IndexError: list index out of range

Anscheinend findet der Slave keinen Master mit LDAP. Im Computer-Objekt des neuen Masters ist jedoch der Dienst ausgeführt und ist auch gestartet.
Führe ich jedoch [quote]ldapsearch -x -h ucs[/quote] aus erhalte ich sowohl auf dem Slave als auch auf dem Master:

ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)

Desweiteren gibt es rejects auf dem S4 Connector:

[code]root@bernd:~# univention-s4connector-list-rejected

UCS rejected

1:   UCS DN: cn=Printer-Admins,cn=groups,dc=mueller,dc=lan
      S4 DN: <not found>
     Filename: /var/lib/univention-connector/s4/1448301751.800197

2:   UCS DN: cn=Printer-Admins,cn=groups,dc=mueller,dc=lan
      S4 DN: <not found>
     Filename: /var/lib/univention-connector/s4/1448301793.611938

S4 rejected

1:    S4 DN: CN=Print Operators,CN=Builtin,DC=mueller,DC=lan
     UCS DN: <not found>

    last synced USN: 3863

[/code]

Im /var/log/univention/connector-s4.log steht:

[code]02.12.2015 23:01:46,533 LDAP (PROCESS): sync to ucs: Resync rejected dn: CN=Print Operators,CN=Builtin,DC=mueller,DC=lan
02.12.2015 23:01:46,535 LDAP (PROCESS): sync to ucs: [ group] [ modify] cn=Printer-Admins,cn=groups,dc=mueller,dc=lan
02.12.2015 23:01:46,555 LDAP (PROCESS): Unable to sync cn=Printer-Admins,cn=groups,dc=mueller,dc=lan (UUID: f1a7be28-f974-1034-8e10-ef3f8c0cae3a). The object is currently locked.
02.12.2015 23:02:41,830 LDAP (PROCESS): sync from ucs: Resync rejected file: /var/lib/univention-connector/s4/1448301751.800197
02.12.2015 23:02:41,833 LDAP (PROCESS): sync from ucs: [ group] [ add] cn=Printer-Admins,cn=groups,DC=mueller,DC=lan
02.12.2015 23:02:41,835 LDAP (ERROR ): sync_from_ucs: traceback during add object: cn=Printer-Admins,cn=groups,DC=mueller,DC=lan
02.12.2015 23:02:41,836 LDAP (ERROR ): sync_from_ucs: traceback due to addlist: [(‘objectClass’, [‘top’, ‘group’]), (‘groupType’, [u’-2147483643’]), (u’description’, [u’Members can administer domain printers’]), (‘sAMAccountName’, [u’Print Operators’]), (‘objectSid’, [’\x01\x02\x00\x00\x00\x00\x00\x05 \x00\x00\x00&\x02\x00\x00’])]
02.12.2015 23:02:41,836 LDAP (WARNING): sync failed, saved as rejected
/var/lib/univention-connector/s4/1448301751.800197
02.12.2015 23:02:41,836 LDAP (WARNING): Traceback (most recent call last):
File “/usr/lib/pymodules/python2.7/univention/s4connector/init.py”, line 802, in __sync_file_from_ucs
or (not old_dn and not self.sync_from_ucs(key, object, premapped_ucs_dn, old_dn, old, new))):
File “/usr/lib/pymodules/python2.7/univention/s4connector/s4/init.py”, line 2402, in sync_from_ucs
self.lo_s4.lo.add_ext_s(compatible_modstring(object[‘dn’]), compatible_addlist(addlist), serverctrls=ctrls) #FIXME encoding
File “/usr/lib/python2.7/dist-packages/ldap/ldapobject.py”, line 187, in add_ext_s
resp_type, resp_data, resp_msgid, resp_ctrls = self.result3(msgid,all=1,timeout=self.timeout)
File “/usr/lib/python2.7/dist-packages/ldap/ldapobject.py”, line 476, in result3
resp_ctrl_classes=resp_ctrl_classes
File “/usr/lib/python2.7/dist-packages/ldap/ldapobject.py”, line 483, in result4
ldap_result = self._ldap_call(self._l.result4,msgid,all,timeout,add_ctrls,add_intermediates,add_extop)
File “/usr/lib/python2.7/dist-packages/ldap/ldapobject.py”, line 106, in _ldap_call
result = func(*args,**kwargs)
ALREADY_EXISTS: {‘info’: ‘00002071: …/ldb_tdb/ldb_index.c:1216: Failed to re-index objectSid in CN=Printer-Admins,CN=Groups,DC=mueller,DC=lan - …/ldb_tdb/ldb_index.c:1148: unique index violation on objectSid in CN=Printer-Admins,CN=Groups,DC=mueller,DC=lan’, ‘desc’: ‘Already exists’}

02.12.2015 23:02:41,837 LDAP (PROCESS): sync from ucs: Resync rejected file: /var/lib/univention-connector/s4/1448301793.611938
02.12.2015 23:02:41,839 LDAP (PROCESS): sync from ucs: [ group] [ add] cn=Printer-Admins,cn=groups,DC=mueller,DC=lan
02.12.2015 23:02:41,841 LDAP (ERROR ): sync_from_ucs: traceback during add object: cn=Printer-Admins,cn=groups,DC=mueller,DC=lan
02.12.2015 23:02:41,841 LDAP (ERROR ): sync_from_ucs: traceback due to addlist: [(‘objectClass’, [‘top’, ‘group’]), (‘groupType’, [u’-2147483643’]), (u’description’, [u’Members can administer domain printers’]), (‘sAMAccountName’, [u’Print Operators’]), (‘objectSid’, [’\x01\x02\x00\x00\x00\x00\x00\x05 \x00\x00\x00&\x02\x00\x00’])]
02.12.2015 23:02:41,844 LDAP (WARNING): sync failed, saved as rejected
/var/lib/univention-connector/s4/1448301793.611938
02.12.2015 23:02:41,844 LDAP (WARNING): Traceback (most recent call last):
File “/usr/lib/pymodules/python2.7/univention/s4connector/init.py”, line 802, in __sync_file_from_ucs
or (not old_dn and not self.sync_from_ucs(key, object, premapped_ucs_dn, old_dn, old, new))):
File “/usr/lib/pymodules/python2.7/univention/s4connector/s4/init.py”, line 2402, in sync_from_ucs
self.lo_s4.lo.add_ext_s(compatible_modstring(object[‘dn’]), compatible_addlist(addlist), serverctrls=ctrls) #FIXME encoding
File “/usr/lib/python2.7/dist-packages/ldap/ldapobject.py”, line 187, in add_ext_s
resp_type, resp_data, resp_msgid, resp_ctrls = self.result3(msgid,all=1,timeout=self.timeout)
File “/usr/lib/python2.7/dist-packages/ldap/ldapobject.py”, line 476, in result3
resp_ctrl_classes=resp_ctrl_classes
File “/usr/lib/python2.7/dist-packages/ldap/ldapobject.py”, line 483, in result4
ldap_result = self._ldap_call(self._l.result4,msgid,all,timeout,add_ctrls,add_intermediates,add_extop)
File “/usr/lib/python2.7/dist-packages/ldap/ldapobject.py”, line 106, in _ldap_call
result = func(*args,**kwargs)
ALREADY_EXISTS: {‘info’: ‘00002071: …/ldb_tdb/ldb_index.c:1216: Failed to re-index objectSid in CN=Printer-Admins,CN=Groups,DC=mueller,DC=lan - …/ldb_tdb/ldb_index.c:1148: unique index violation on objectSid in CN=Printer-Admins,CN=Groups,DC=mueller,DC=lan’, ‘desc’: ‘Already exists’}
[/code]

Im Computer Objekt vom neuen Master steht als Typ noch [quote]Typ: Rechner: Domänencontroller Backup[/quote]
Im LDAP ist der Master unter [quote]Position: lan.mueller:/computers/dc[/quote] aufgeführt. Müsste er nicht unter [quote]lan.mueller:/Domain Controllers[/quote] stehen?

Ich benötige Unterstützung, da ich derzeit nicht wirklich weiß wo ich ansetzen kann.

Hallo,

nein die Position ist auf jeden Fall richtig. Der Typ sollte wahrscheinlich angepaßt worden sein, aber genau weiß ich das nicht. Warscheinlich lief der Hochsatufungsprozeß nicht korrekt durch.

Was ist die Ausgabe auf dem Master von:

ps aux |grep slapd
/etc/init.d/slapd restart
ps aux |grep slapd

Hallo,

die Ausgabe ist wie folgt:

root@bernd:~# ps aux |grep slapd root 9687 0.0 0.2 2572036 23324 ? Ssl 09:32 0:10 /usr/sbin/slapd -h ldapi:/// ldap://:7389/ ldaps://:7636/ root 25820 0.0 0.0 11308 1948 pts/0 S+ 13:42 0:00 grep slapd root@bernd:~# /etc/init.d/slapd restart [info] Restarting ldap server(s). [ ok ] Stopping ldap server(s): slapd ...done. [ ok ] Starting ldap server(s): slapd ...done. [ ok ] Checking Schema ID: ...done. root@bernd:~# ps aux |grep slapd root 25877 0.3 0.2 2460352 19616 ? Ssl 13:42 0:00 /usr/sbin/slapd -h ldapi:/// ldap://:7389/ ldaps://:7636/ root 25923 0.0 0.0 11308 1948 pts/0 S+ 13:42 0:00 grep slapd root@bernd:~#

der LDAp läuft also. Klappt univention-ldapsearch?

Ja-funktioniert.

# search result
search: 3
result: 0 Success

# numResponses: 483
# numEntries: 482

Die Ausführung des Befehls

war falsch. Der Hostname war falsch. Die Eingabe von ldapsearch -x -h bernd ergab folgende Ausgabe:

[code]# extended LDIF

LDAPv3

base <dc=mueller,dc=lan> (default) with scope subtree

filter: (objectclass=*)

requesting: ALL

search result

search: 2
result: 1 Operations error
text: 00002020: Operation unavailable without authentication

numResponses: 1[/code]

Das Problem ist vermutlich ein anderes. Der Master DC war seinerzeit ein Backup DC und wurde hochgestuft. Im Computer Typ steht im LDAP noch

Das ist doch nicht korrekt, oder? Kann man dies ändern?

Die Ausgabe von der fehlgeschlagenen Zarafa-Installation zeigt, dass kein Master DC mit LDAP gefunden wird. Der LDAP Dienst ist jedoch am Computer-Objekt des Master DC vorhanden.

In einem anderen Forenbeitrag habe ich folgendes Test-Skript gefunden, welches diese Prüfung ebenfalls durchführt:

from univention.admin.handlers.computers import domaincontroller_master
from univention.admin.handlers.computers import domaincontroller_backup
import univention.uldap as uldap

def get_hosts(module, lo, ucr=None):
        hosts = module.lookup(None, lo, None)
        hostnames = []
        if ucr is not None:
                local_hostname = ucr.get('hostname')
        else:
                local_hostname = None
        for host in hosts:
                host.open() # needed for fqdn. it may be enough to return 'name'
                hostname = host.info.get('name')
                if hostname == local_hostname:
                        print('%s is me. Skipping' % host.dn)
                        continue
                if 'LDAP' not in host.info.get('service', []):
                        print('%s does not provide LDAP. Skipping' % host.dn)
                        continue
                if 'fqdn' not in host.info:
                        print('%s does not have an FQDN. Skipping' % host.dn)
                        continue
                hostnames.append(host.info['fqdn'])
        return hostnames

lo = uldap.getMachineConnection(ldap_master=False)
print get_hosts(domaincontroller_master, lo)[0]

ergibt:

Ändere ich die Zeile

zu

ist die Ausgabe korrekt


root@bernd:/tmp# python apptest.py
bernd.mueller.lan

An welcher Stelle kann ich die nötige Angabe ändern, so dass der Master DC nicht mehr als Backup DC aufgeführt wird?

In der Univention Configuration Registry steht der Server sowohl unter
[ul]ldap/master[/ul]
als auch unter
[ul]ldap/backup[/ul]

In Ergänzung:

Bei Ausführen von
[ul]udm computers/domaincontroller_master list[/ul]
ist die Liste leer

Beim Ausführen von [ul]udm computers/domaincontroller_backup list[/ul]
wird der Master DC aufgeführt

Wie kann das korrigiert werden?

Ich empfehle einen Blick auf das backup2master-Script.

EDIT: Beim verlinkten Script handelt es sich übrigens nicht um die richtige Version. Ich empfehle daher sofern es noch vorhanden ist mir das Script auf dem Master anzuschauen.

Das war es!

Im Log war folgender Eintrag zu sehen:

+ temp_file=/tmp/tmp.bwLdWVSLap
+ echo 'dn: cn=bernd,cn=dc,cn=computers,dc=mueller,dc=lan'
+ echo 'changetype: modify'
+ echo 'replace: univentionServerRole'
+ echo 'univentionServerRole: master'
+ echo -
+ echo 'replace: univentionObjectType'
+ echo 'univentionObjectType: computers/domaincontroller_master'
++ cat /etc/ldap.secret
+ ldapmodify -x -D cn=admin,dc=mueller,dc=lan -w ********* -f /tmp/tmp.bwLdWVSLap
ldap_modify: Object class violation (65)
	additional info: unrecognized objectClass 'univentionXMPPHost'

Das ist wohl fehlgeschlagen.

univentionServerRole war noch auf “backup”
univentionObjectType war auf “computers/domaincontroller_backup”

Nachdem dies korrigiert war gab es keine Probleme mehr.

Vielen Dank!

Mastodon