New Host not found in DNS

[ncdivebum515]

After the last update to xxx, I am unable to create a new host “computer”. I have added the computer as I have always done, as well as make sure the MAC, IP, and reverse DNS entries are properly created. The host is listed in the system in the “Computers” module as well as DNS modules. However, when I try to resolve the hostname, it says ‘host not found’. Looking through the forum, it seems to hint at a possible new bug introduced in the last update? I cannot find any errors in logs…it simply does not resolve.

Any suggestions would be greatly appreciated.

[thorp-hansen]

Looking through the forum, it seems to hint at a possible new bug introduced in the last update?

Can you tell me what bug you mean?

[ncdivebum515]

I dont have a bug number, I just happened to see a post hinting at it. I have removed and recreated the host several times using both the UI and CLI. I have restarted BIND and then even tried restarting the entire server…still no joy. Host will not resolve using hostname or FQDN. What log should I check? I do not see anything in the bind9 log or syslog.

[thorp-hansen]

I just happened to see a post hinting at it.

Can you tell me where that was (Link)? Maybe there is a bug, but we need to know it so we can fix it. I am asking, because the behaviour seems new to me. If you have the host record in the DNS you should be able to successfully ping/host it (if the client asks this DNS server).

[ncdivebum515]

I have found these:

Replication error between UCS master and Windows AD DC

I'm going to remove the remain Windows AD Domain Controller after migrating to UCS successfully. But I several days ago, I found that when I created a domain account on UCS, this account did not appear on the Windows DC. I tried to create an account on Windows DC and it appeared on UCS Master automatically. So there's something wrong with the UCS master and Windows DC. I've checked both on UCS and Windows AD. Below is output of some command on both servers: UCS: (it seems to be OK) root@xx…

DNS on a UCS Backup server

Hi all, I have the following setup: a new UCS domain with: UCS-Master , with ldap & dns (called 'officedomain.lcl') UCS-Backup , also with ldap & dns On both systems I can go to the web interface, click on Domain -> DNS and see all the hosts I added to the officedomain.lcl When I use the UCS-Master as a DNS server I can resolve all the hosts in the lcl domain, when I use the UCS-Backup server as DNS server I cannot resolve hosts in the lcl domain, I can resolve any other hostname (ie: yah…

UCS AD Conncetor and Windows 2012 Domain

I am trying to join my UCS Master to a Windows 2012 Domain. I have installed the UCS AD connector. No errors/Issues with install. However upon attempting to Join the domain (bebconsultingservices.com / BEBCONSULTING) it fails (screenshot of error) this happens regardless of what option I select for AD connector. The log files below are empty....so that provides me with NO clues on a problem or fix. /var/log/univention/connector-status.log /var/log/univention/connector.log /var/log/univent…

LDAP error on UCS system

Hi Michael, thank you for your help. Pls have a look at my answer in blue color. If you need any logs or result of which command, pls let me know. Thank you.

Computer added to domain does not appear in Computers

Hello friends, I am again raising a testing environment for a service that I will have to start this week and I am facing some problems in Univention 4.1-4. This time I uploaded the domain correctly and it is working correctly, I added a Windows 10 and it responds to DNS and everything. The problem is that after adding I went to Devices -> Computers, however only the dc01.multiti.local Univention is listed, the WIN10-TI01 is not listed. The same occurs in DHCP, in DNS it has the registry cre…

Bear in mind, none of these are exactly the problem I am seeing. I have UCS setup as my main AD (with DNS etc). DHCP is on another dedicated host that is NOT UCS. I also have a backup DC that is running UCS. Everything was working as expected until recently.

Where do look for answers? As I said, there are no errors appearing in bind or syslog.

[thorp-hansen]

Can you have a look at “# univention-s4connector-list-rejected” if there is an entry? Can you also have a look at “/var/log/univention/connectors4.log” if there are tracebacks?

[ncdivebum515]

Where do I look for the univention-s4connector-list-rejected?

There is nothing in connectors4.log except the following repeated over and over:

(------ ): DEBUG_INIT
(PROCESS): Building internal group membership cache
(PROCESS): Internal group membership cache was created

[thorp-hansen]

as root run the following command:

univention-s4connector-list-rejected
ucr search --brief dns/backend

[ncdivebum515]

results of univention-s4connector-list-rejected:

UCS rejected

S4 rejected

There may be no rejected DNs if the connector is in progress, to be
sure stop the connector before running this script.

last synced USN: 56506

Results of ucr search --brief dns/backend:

dns/backend: samba4

[thorp-hansen]

very very strange. There is something missing. Start some services anew:

service univention-directory-notifier restart
service univention-directory-listener restart
service univention-s4-connector restart
service bind9 restart

And have again a look at the reject list and the connectors4.log.Additionally have a look at the syslog directly after bind9 restart. No idea why a new host entry would not be reachable if every service runs and you have no errors.

[ncdivebum515]

after all restarts, nothing in connecter log or in syslog. results of reject list the same:

UCS rejected

S4 rejected

There may be no rejected DNs if the connector is in progress, to be
sure stop the connector before running this script.

last synced USN: 56506

[Grandjean]

In addition to

/var/log/univention/connector-s4.log

you might also want to check:

/var/log/univention/connector-s4-status.log

for anything “atypical”.

[ncdivebum515]

Well…there is some nasty looking stuff in connector-s4-status.log:

ed Apr  5 11:38:29 2017
 --- connect failed, failure was: ---

Traceback (most recent call last):
  File "/usr/lib/pymodules/python2.7/univention/s4connector/s4/main.py", line 282, in main
    connect()
  File "/usr/lib/pymodules/python2.7/univention/s4connector/s4/main.py", line 181, in connect
    s4.initialize_ucs()
  File "/usr/lib/pymodules/python2.7/univention/s4connector/__init__.py", line 964, in initialize_ucs
    self.poll_ucs()
  File "/usr/lib/pymodules/python2.7/univention/s4connector/__init__.py", line 1044, in poll_ucs
    dn, new, old, old_dn = cPickle.load(f)
EOFError

 ---     retry in 30 seconds      ---

[thorp-hansen]

AHA! There you go…

Have a look at the following folder, there may be some (many) pickle (reject) files:

/var/lib/univention-connector/s4

Please delete the files (only the files) in this folder manually and restart the services again:

service univention-directory-notifier restart
service univention-directory-listener restart
service univention-s4-connector restart
service bind9 restart

After that, have a look at the connector and the connector-status log.

[ncdivebum515]

There were a LOT of files in /var/lib/univention-connector/s4. Manually deleted them and restarted services as requested. Name resolution for the one host is still not working.

Getting NEW errors in connectors4.log:

06.04.2017 06:46:47,548 LDAP        (ERROR  ): Traceback (most recent call last):
  File "/usr/lib/pymodules/python2.7/univention/s4connector/__init__.py", line 1493, in sync_to_ucs
    result = self.modify_in_ucs(property_type, object, module, position)
  File "/usr/lib/pymodules/python2.7/univention/s4connector/__init__.py", line 1275, in modify_in_ucs
    self.__set_values(property_type, object, ucs_object)
  File "/usr/lib/pymodules/python2.7/univention/s4connector/__init__.py", line 1087, in __set_values
    ucs_object.open()
  File "/usr/lib/pymodules/python2.7/univention/admin/handlers/computers/windows.py", line 391, in open
    self['primaryGroup'] = None
  File "/usr/lib/pymodules/python2.7/univention/admin/handlers/__init__.py", line 2660, in __setitem__
    super(simpleComputer, self).__setitem__(key, value)
  File "/usr/lib/pymodules/python2.7/univention/admin/handlers/__init__.py", line 208, in __setitem__
    raise univention.admin.uexceptions.valueRequired, _('The property %s is required') % self.descriptions[key].short_description
valueRequired: The property Primary group is required

I am now getting messages in the connector status log:

--------------------------------------
try to sync 0 changes from S4
done:
Changes from S4:  0 (1 saved rejected)
--------------------------------------
- sleep 5 seconds (3/10 until resync) -

[Grandjean]

Could you please add the couple of lines above the Traceback from connector-s4.log? There should be a line that says which object the S4-Connector currently tries to sync (that causes the error then). Then we can check for the (missing) primary group of that object.

univention-s4connector-list-rejected should also give you that one reject with its DN now

[ncdivebum515]

complete lines from connector-s4.log:

06.04.2017 09:25:50,290 LDAP        (PROCESS): sync to ucs: Resync rejected dn: CN=SYNOLOGY,CN=Computers,DC=xxxx,DC=local
06.04.2017 09:25:50,293 LDAP        (PROCESS): sync to ucs:   [windowscomputer] [    modify] cn=SYNOLOGY,CN=Computers,dc=xxxx,dc=local
06.04.2017 09:25:50,295 LDAP        (ERROR  ): Unknown Exception during sync_to_ucs
06.04.2017 09:25:50,295 LDAP        (ERROR  ): Traceback (most recent call last):
  File "/usr/lib/pymodules/python2.7/univention/s4connector/__init__.py", line 1493, in sync_to_ucs
    result = self.modify_in_ucs(property_type, object, module, position)
  File "/usr/lib/pymodules/python2.7/univention/s4connector/__init__.py", line 1275, in modify_in_ucs
    self.__set_values(property_type, object, ucs_object)
  File "/usr/lib/pymodules/python2.7/univention/s4connector/__init__.py", line 1087, in __set_values
    ucs_object.open()
  File "/usr/lib/pymodules/python2.7/univention/admin/handlers/computers/windows.py", line 391, in open
    self['primaryGroup'] = None
  File "/usr/lib/pymodules/python2.7/univention/admin/handlers/__init__.py", line 2660, in __setitem__
    super(simpleComputer, self).__setitem__(key, value)
  File "/usr/lib/pymodules/python2.7/univention/admin/handlers/__init__.py", line 208, in __setitem__
    raise univention.admin.uexceptions.valueRequired, _('The property %s is required') % self.descriptions[key].short_description
valueRequired: The property Primary group is required

univention-s4connector-list-rejected shows:

UCS rejected


S4 rejected

    1:    S4 DN: CN=SYNOLOGY,CN=Computers,DC=xxxx,DC=local
         UCS DN: <not found>

	last synced USN: 88176

Curiously, the “rejected” item is NOT the one that is not resolving

[Grandjean]

The problem of the CN=SYNOLOGY machine is that it is missing a primary group (which is mandatory). This should be easy:

• If you can see the computer account in the UMC (Webinterface), just open it and set a Primary Group
• If you can’t see the computer account in the UMC (Webinterface), you might want to use RSAT for this task
• If you want to use the command-line:

udm computers/windows modify --dn "cn=SYNOLOGY,CN=Computers,dc=xxxx,dc=local" \
  --set primaryGroup="cn=Windows Hosts,cn=groups,dc=xxxx,dc=local"

Curiously, the “rejected” item is NOT the one that is not resolving

You can use this command to trigger a re-sync of the object that is not resolving:

/usr/share/univention-s4-connector/resync_object_from_ucs.py "DN"

The "DN" is a placeholder in this case. If you don’t know the DN of the item, you can search for it this way:

univention-ldapsearch -LLLo ldif-wrap=no cn=computername dn

Just replace computername with the actual hostname of the computer.

Triggering a re-sync might also produce a new reject (because we probably haven’t solved the root cause so far), but then we should at least see the error message in the log file.

[ncdivebum515]

Just back from vacation and getting back to this. Grandjean, sorry but you missed two critical elements. First, the host that is not resolving is NOT the SYNOLOGY host above. SYNOLOGY resolves just fine. Second, SYNOLOGY is actually an IPManagedClient, not a Windows host, so there is not a primary group. The host that is not resolving is VMANAGE, which is a LinuxHost…and has a primary group.

[thorp-hansen]

SYNOLOGY may not be the problematic host, but it has a problem nonetheless. Please proceed with the steps my collegue provided, so that we may get a clue where the problem with VMANAGE lies. A quick question additional: is VMANAGE the only host that is not resolvable at the moment (can you create new hosts that can be resolved)?