The log file you’re showing us is not from bind9 but from the Univention Directory Listener process. This makes more sense, too, as it’s unusual to run bind9 on a member server, but a Directory Listener is always running on each and every server.
The Directory Listener process uses the server’s LDAP machine account for authentication. Fortunately it’s easy to check whether or that account still works. Just run the command univention-ldapsearch on your member server. It should output a lot of data.
If that works, try restarting the Directory Listener process with systemctl restart univention-directory-listener.service and see if that makes a difference.
Thanks, I have restarted and it did not make a difference.
I do not know why DNS was enabled for this member server, I removed that service from univention management centre however it is still present on that server. Is there any command I can use to forcefully disable DNS on member server?
I don’t believe you actually do have DNS on your member server. Your interpretation of the log file seems wrong. Check if dpkg -l univention-bind bind9 shows both packages as not being installed (the lines should start with un).
Try rejoining the server to the domain with univention-join. You won’t lose data that way, but the server will copy important data such as the machine account’s credentials, and this often solves issues such as this.
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
ii bind9 1:9.8.4.dfsg amd64 Internet Domain Name Server
ii univention-bin 10.0.2-5.218 all UCS - DNS server
Bind is indeed installed on your machine. Interesting. It’s quite possible that having bind running on a member server isn’t supported, and that the member server’s machine account simply doesn’t have write access to the LDAP’s DNS objects.
Is this really a member server? Please post the output of ucr get server/role before we remove potentially important packages.
Joining is done with a user account from the LDAP who has domain admin privileges. The user root is not an LDAP user, though — you usually have to use administrator for joining.
So it isn’t a member server after all. The term “member server” has a very distinct meaning in the UCS context — it’s one of the four possible roles a server can have (domaincontroller_master, domaincontroller_backup, domaincontroller_slave or memberserver). The big difference between a DC Slave and a Member server is that a DC Slave runs its own LDAP server with a partial or full copy of the DC Master’s LDAP server while a Member server doesn’t run its own LDAP server. A DC Slave is usually used for remote locations/branch offices where you want to have access to your authentication services without having to go over the wire.
A DC Slave also runs its own bind name server. Therefore removing it is not a good idea.
About the failing join: please post the content of the following log file: /var/log/univention/join.log. Thanks.
Mon Aug 14 12:05:59 BST 2017: starting /usr/sbin/univention-join
running version check
OK: UCS version on sub.domain.com is higher or equal (4.14) to the local version (4.14).
Stopping ldap server(s): slapd ...retry #1....done.
Starting ldap server(s): slapd ...done.
Found failed.ldif. Importing ...failed.
Please check /var/log/univention/listener.log.
Mon Aug 14 12:07:25 BST 2017: finish /usr/sbin/univention-join
Mon Aug 14 12:31:00 BST 2017: starting /usr/sbin/univention-join
running version check
OK: UCS version on sub.domain.com is higher or equal (4.14) to the local version (4.14).
Stopping ldap server(s): slapd ...done.
Starting ldap server(s): slapd ...done.
Found failed.ldif. Importing ...failed.
Please check /var/log/univention/listener.log.
Mon Aug 14 12:31:13 BST 2017
univention-server-join: joins a server to an univention domain
copyright (c) 2001-2017 Univention GmbH, Germany
E: failed to create DC Slave (1) [E: Object exists: (mac) 52:54:00:87:01:3f]
Mon Aug 14 12:31:15 BST 2017: finish /usr/sbin/univention-join
By the way, DC slave was created probably for reason to use LDAP authentication for web apps we run on this server.
Alright. You should now remove the computer object for that DC Slave in the Univention Management Console. Afterwards make sure that the MAC address isn’t used anywhere else in the LDAP directory by running this on your DC Master: