Comment 1 Felix Botner 2014-07-30 13:37:14 CEST

lookup_adds_dc() now supports the ip address of the ad server or a domain name. If the domain name is used, lookup_adds_dc() executes a "dig @dns/forwarder1" on the name to get the dc ips.

For each ip a cldap and dns check (dig) is performed. If both test succeed, this server is used.

Comment 2 Arvid Requate 2014-07-31 14:50:26 CEST

Looks good apart from one thing: if ad_ldap_base cannot be determined (i.e. an exception occurs during the remote_ldb.connect) then the function should probably indicate this by exiting with an exception?

Comment 3 Felix Botner 2014-07-31 15:06:06 CEST

fixed

Comment 4 Arvid Requate 2014-07-31 16:30:20 CEST

Verified, advisory is ok too.

Comment 5 Arvid Requate 2014-07-31 18:33:13 CEST

Created attachment 6034 [details]
fix_name_lookup_with_nameserver1_instead_of_forwarder1.patch

Reopen because while checking Bug 35467 I found two things that happen when the AD IP is not set in dns/forwarder1 but in nameserver1 itself:

* In the server_password_change case a call to 
  univention.lib.admember.lookup_adds_dc()
  results in an exception univention.lib.admember.failedADConnect:
  ['Connection to AD Server arw2k8r2i2.qa failed']

* A call to univention.lib.admember.lookup_adds_dc(<FQDN of AD server>) fails.

The attached patch fixes this by also trying a dig against the usual nameservers configured in resolv.conf in case dns/forwarder1 didn't return a result.

Comment 6 Felix Botner 2014-08-01 09:36:03 CEST

fixed, lookup_adds_dc now tries 'dns/forwarder1', 'dns/forwarder2', 'dns/forwarder3', 'nameserver1', 'nameserver2', 'nameserver3'

also added a switch (check_dns=True) for the dns test

Comment 7 Arvid Requate 2014-08-04 12:09:51 CEST

Ok, works. Advisory Ok.

Comment 8 Janek Walkenhorst 2014-08-07 17:45:53 CEST

http://errata.univention.de/ucs/3.2/165.html