Hi,
could you elaborate a little bit more about this error? Do you have a screenshot? I am currently confused what the error is…
/CV
Hello Mr. Voelker,
thank you for your quick reply.
Here is the screenshot.
The first item is due to a server which doesn’t exist any more.
The third item is the gateway, which I had to set as dns server. Otherwise no updates are downloaded.
This udn-prob leads to the unability to setting up new shares or new users via umc
even though existing ones work well.
Hi,
I am pretty sure this is a DNS issue. Whatever warnings appear here, most of them are related to DNS settings
Check this link.
/CV
Following your advice (thanks for the link) I could get rid of the dns-server-warning but the udn-error still shows up. Also on the two member servers that udn-replication-warning is to be found.
There are no var/lib/univention-ldap/notify/transaction-files on the memberservers but the last IDs match the one on the DC-Backup.
Doing samba-tool ntacl sysvolreset seemed to solve the sysvol-warning but after rebooting the master-dc showed up again:
Hello again,
while a second and third samba-tool ntacl sysvolreset did it’s job,
my UCS is still suffering from udn-probs.
There are two DCs (Master+Backup) and two memberservers.
All of them are showing this warning as a result of the umc-system-diagnosis.
As written above, the listener/notifier-IDs match and the enumeration in the transaction file is ok.
So all steps in this article are passed.
DNS works except for a new prob that appeared yesterday (I’ll open up another topic later) and thus shouldn’t be related to the udn-issue.
At the moment administrative work like setting up shares or adding new users etc. is impossible.
Please let me know what kind of information I can supply for further analysis.
Best Regards
Bernhard
Hi,
have you seen this article? Does it help?
Edit: Sorry, just seen my article just links to the one you already mentioned. There has been an issue with the translog file. You might want to check Bugzilla about this, I am unsure here.
/CV
Ok. I found nothing there.
Do you think there is an alternative to setting up the domain again from the beginning?
Is there a way to reset the transaction count to zero?
Hi,
I am currently unsure about the state of your system. Which errors are shown? I did a quick search in bugzilla for “translog”, probably some might be useful.
Otherwise, I am out of options except the forced re-join of your backup servers…
/CV
Hi,
the errors shown by umc->system->sytemdiagnosis on all four servers
(dc-m,dc-bu,2xmember) is: 
This makes administration mostly impossible; ldap/samba related changes are not accepted.
I’ve looked at the translog related bugzilla-topics but I don’t know how to make use of them.
I think I’ll try to rejoin all servers into the domain. I’ll let you know …
Thanks
Bernhard
Rejoin of dc-backup has failed.
The join log ends with:
Summary
Configure 01univention-ldap-server-init.inst Tue Feb 26 19:46:27 CET 2019
2019-02-26 19:46:27.067760455+01:00 (in joinscript_init)
File: /var/lib/univention-ldap/translog/DB_CONFIG
Warning: slapd.service changed on disk. Run 'systemctl daemon-reload' to reload units.
2019-02-26 19:46:28.353253182+01:00 (in joinscript_save_current_version)
Configure 02univention-directory-notifier.inst Tue Feb 26 19:46:28 CET 2019
2019-02-26 19:46:28.390286310+01:00 (in joinscript_init)
Starting univention-directory-notifier (via systemctl): univention-directory-notifier.service.
2019-02-26 19:46:28.441514715+01:00 (in joinscript_save_current_version)
Configure 03univention-directory-listener.inst Tue Feb 26 19:46:28 CET 2019
2019-02-26 19:46:28.481519323+01:00 (in joinscript_init)
26.02.19 19:46:29.113 DEBUG_INIT
26.02.19 19:46:29.123 LDAP ( PROCESS ) : connecting to ldap://hipsctrl-1.hipsy.intranet:7389
26.02.19 19:46:29.138 LISTENER ( ERROR ) : failed to connect to any notifier
26.02.19 19:46:29.138 LISTENER ( ERROR ) : can not connect any server, exit
Warning: slapd.service changed on disk. Run 'systemctl daemon-reload' to reload units.
03univention-directory-listener.inst: Failed to start Listener
**************************************************************************
* Join failed! *
* Contact your system administrator *
**************************************************************************
Regrettably that’s me … rolled back to the pre-join snapshots.
Could it be a problem with the ssh-certificate?
Hi!
Looks like DC backup fails to establish a connection to your DC master on port 6669.
Please run the following commands on your DC backup and check the output:
host FQDNOFYOURDCMASTER
ping IPADDRESSOFYOURDCMASTER
echo "TEST" | nc -q 2 -w 2 IPADDRESSOFYOURDCMASTER 6669
- Is the correct IP address of your DC master returned by the
hostcommand? → If not, the DC backup is using the wrong DNS server or the DNS setup is somehow faulty. - Can you ping the IP address of your DC master? → If not, check your firewall/routing.
- Does the last command return something like
Connection refused? → If the connection is refused, then check if the Univention Directory Notifier is running on your DC master and if this is the case, check your firewall.
Best regards,
Sönke
Hello Sönke,
host and ping are working well but: connection refused.
The notifier seems to be running:
Summary
`# service univention-directory-notifier status
● univention-directory-notifier.service - LSB: Univention Directory Notifier Daemon
Loaded: loaded (/etc/init.d/univention-directory-notifier; generated; vendor preset: enabled)
Active: active (exited) since Tue 2019-02-26 20:19:11 CET; 2h 44min ago
Docs: man:systemd-sysv-generator(8)
Process: 1646 ExecStart=/etc/init.d/univention-directory-notifier start (code=exited, status=0/SUCCESS)
Tasks: 0 (limit: 4915)
Memory: 0B
CPU: 0
CGroup: /system.slice/univention-directory-notifier.service
Feb 26 20:19:04 hipsctrl-1 systemd[1]: Starting LSB: Univention Directory Notifier Daemon…
Feb 26 20:19:11 hipsctrl-1 univention-directory-notifier[1646]: Starting Univention Directory Notifier Daemon: univention-directory-notifierok: run: univention-directory-notifier: (pid 1685) 5s, normally down
Feb 26 20:19:11 hipsctrl-1 univention-directory-notifier[1646]: .
Feb 26 20:19:11 hipsctrl-1 systemd[1]: Started LSB: Univention Directory Notifier Daemon.
`
With the firewall disabled (security/packetfilter/disabled=true) the connection to the dc-master is still refused.
Regards
Bernhard
Hi!
The UCR variable security/packetfilter/disabled disables the firewall for incoming connections. Outgoing connections are unfiltered.
Just to be sure: is hipsctrl-1 your DC master or your DC backup?
You have to call service univention-directory-notifier status on the DC master, because the Univention Directory Listener on the DC backup is connecting to the UDN on the DC master.
If the service is running on your DC master, please restart it to be sure.
If the connection does not work, please shut down the firewall on the DC master:
service univention-firewall stop
If it still does not work, I would suspect a firewalling device between your DC master and your DC backup.
Greetings,
Sönke
Hello Sönke,
thanks for your reply.
Yes, it’s the master and hipstrl-3 is the dc-backup.
I now stopped the ucs-firewall on both, restarted the univention-directory-notifier on the dc-master and the connection was still refused. No other firewalling devices had been installed or changed. Also with the firewall of the hypervisor switched off the connection ist refused.
Hi!
That is strange. What does netstat -anvpt | grep 6669 return on your master?
Please check on both systems, if the packetfilter is really empty: iptables -L -n -v
fingers crossed
Sönke
Hi,
netstat delivered no output.
Here is the result from both commands:
Summary
`
root@hipsctrl-1:~# netstat -anvpt | grep 6669
root@hipsctrl-1:~# iptables -L -n -v
Chain INPUT (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
165K 39M ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0
170K 26M ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
53 3396 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:7636
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:111
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpts:32765:32769
75 26641 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:67
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:544
272 14144 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:88
4643 272K ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:7389
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:3268
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:464
5401 1166K ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:88
1050 63000 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:6669
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:5432
0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpts:32765:32769
36 1872 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:53
89 7644 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:123
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:3269
0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:464
4 240 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:80
11034 1382K ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:389
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:6080
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:443
81 4212 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpts:49152:65535
24525 2398K ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:53
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:2049
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:5666
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:636
2130 261K ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpts:137:139
0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:445
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:6670
2781 166K ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:445
119 7132 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:22
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:749
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:7777
0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:7777
125 6844 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpts:137:139
0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:2049
155 8060 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:389
48 2496 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:135
0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:111
129 40599 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:68
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:1024
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:11212
0 0 ACCEPT tcp -- * * 172.17.0.0/16 0.0.0.0/0 tcp dpt:3306
127 4572 REJECT all -- * * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 DOCKER-ISOLATION all -- * * 0.0.0.0/0 0.0.0 .0/0
0 0 DOCKER all -- * docker0 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT all -- * docker0 0.0.0.0/0 0.0.0.0/0 ctstate RELATED,ESTABLISHED
0 0 ACCEPT all -- docker0 !docker0 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT all -- docker0 docker0 0.0.0.0/0 0.0.0.0/0
Chain OUTPUT (policy ACCEPT 204K packets, 52M bytes)
pkts bytes target prot opt in out source destination
165K 39M ACCEPT all -- * lo 0.0.0.0/0 0.0.0.0/0
Chain DOCKER (1 references)
pkts bytes target prot opt in out source destination
Chain DOCKER-ISOLATION (1 references)
pkts bytes target prot opt in out source destination
0 0 RETURN all -- * * 0.0.0.0/0 0.0.0.0/0 `
What do you think?
If the netstat command does not return any output, your UDN is not running on your DC master.
Please try to restart it: service univention-directory-notifier restart and check the log file /var/log/univention/notifier.log
(Btw: your filewall on the DC master is still running, but I can see, that the port 6669 for the UDN is correctly opened, so this is not your actual problem)
This is strange, because I did restart that service in the morning (as written in post 14).
Now restarted again and service univention-directory-notifier status tells:
Summary
`
# service univention-directory-notifier status
● univention-directory-notifier.service - LSB: Univention Directory Notifier Daemon
Loaded: loaded (/etc/init.d/univention-directory-notifier; generated; vendor preset: enabled)
Active: active (exited) since Wed 2019-02-27 13:58:15 CET; 3min 30s ago
Docs: man:systemd-sysv-generator(8)
Process: 23318 ExecStop=/etc/init.d/univention-directory-notifier stop (code=exited, status=0/SUCCESS)
Process: 23330 ExecStart=/etc/init.d/univention-directory-notifier start (code=exited, status=0/SUCCESS)
CPU: 61ms
Feb 27 13:58:14 hipsctrl-1 systemd[1]: Starting LSB: Univention Directory Notifier Daemon...
Feb 27 13:58:15 hipsctrl-1 univention-directory-notifier[23330]: Starting Univention Directory Notifier Daemon: univention-directory-notifierok: run: univention-directory-notifier:
Feb 27 13:58:15 hipsctrl-1 univention-directory-notifier[23330]: .
Feb 27 13:58:15 hipsctrl-1 systemd[1]: Started LSB: Univention Directory Notifier Daemon.
`
And here are the last few lines of notifier.log:
Summary
alueError: need more than 1 value to unpack 2019-02-27 14:02:22,599:CRITICAL:ldap_search(reqSession=13907,cn=translog): No such object Traceback (most recent call last): File "/usr/share/univention-directory-notifier/univention-translog", line 713, in <module> exit(main()) File "/usr/share/univention-directory-notifier/univention-translog", line 374, in main return opt.func(opt) or 0 File "/usr/share/univention-directory-notifier/univention-translog", line 458, in import_all for rec in chain(lead, translog): File "/usr/share/univention-directory-notifier/univention-translog", line 306, in __iter__ rec = self.parse_line(line) File "/usr/share/univention-directory-notifier/univention-translog", line 234, in parse_line dn, command = rest.rsplit(' ', 1) ValueError: need more than 1 value to unpack 2019-02-27 14:02:34,205:CRITICAL:ldap_search(reqSession=13907,cn=translog): No such object
Formatting was lost, sorry for that.
Edit: directly after restarting the notifier service netstat again returned no result.
hm, no more ideas?
here are the last lines of th listener logs from master:
Summary
28.02.19 12:54:13.622 LDAP ( PROCESS ) : connecting to ldap://hipsctrl-1.hipsy.intranet:7389
28.02.19 12:54:13.628 LDAP ( INFO ) : simple_bind as cn=admin,dc=hipsy,dc=intranet
28.02.19 12:54:13.936 LISTENER ( INFO ) : connecting to notifier hipsctrl-1.hipsy.intranet:6669
28.02.19 12:54:13.991 LISTENER ( INFO ) : connection to 10.0.0.26 failed with errorcode 111: Connection refused
28.02.19 12:54:14.245 LISTENER ( ERROR ) : failed to connect to any notifier
28.02.19 12:54:14.245 LISTENER ( WARN ) : can not connect any server, retrying in 30 seconds
and backup-dc
Summary
28.02.19 12:59:14.992 LISTENER ( WARN ) : can not connect any server, retrying in 30 seconds
28.02.19 12:59:44.992 LISTENER ( WARN ) : Notifier/LDAP server is hipsctrl-1.hipsy.intranet:7389
28.02.19 12:59:44.992 LDAP ( PROCESS ) : connecting to ldap://hipsctrl-1.hipsy.intranet:7389
28.02.19 12:59:45.002 LISTENER ( ERROR ) : failed to connect to any notifier
28.02.19 12:59:45.002 LISTENER ( WARN ) : can not connect any server, retrying in 30 seconds
Do you think backup2master is the right choice?
I Don’t know what else to do … .
Hi!
Something is wrong with the notifier on your DC master. It seems to die directly after starting it.
Can you please send some more last lines of the notifier.log?
Sönke