Join Script for ox failed (exit code 1)

[kreiner]

Hello,

today I tried to add a new user. This user couldn’t log in to ox.
I updated UCS to 4.4.2 and tried to run the join scripts.

univention-run-join-scripts showed, that 65univention-ox.inst failed with exit code 1

join.log:

Waiting for activation of the extension object oxmail/oxcontext: …ERROR: Master did not mark the extension object active within 180 seconds.
ERROR
ucs_registerLDAPExtension: registraton of /usr/share/univention-ox/udm/oxmail/oxcontext.py failed.
65univention-ox.inst: Failed to register LDAP module.
EXITCODE=1

listener.log

11.11.19 15:34:24.110 LDAP ( PROCESS ) : connecting to ldap://my.domain:7389
11.11.19 15:34:24.117 LISTENER ( ERROR ) : failed to connect to any notifier
11.11.19 15:34:24.118 LISTENER ( WARN ) : can not connect any server, retrying in 30 seconds

Anyone know how to fix this?

Regards,
Flo

[troeder]

Looks like the notifier (used replicate changes in LDAP) is not reachable.
Either the network connection to the master is not OK (firewall?) or it is simply not running (on the master), then run service univention-directory-notifier restart (on the master).

Greetings
Daniel

[kreiner]

I only have one server, which is the master.
Both listener and notifier are running.

Regards,
Flo

[troeder]

listener.log
connecting to ldap://my.domain:7389
failed to connect to any notifier
can not connect any server, retrying in 30 seconds

• Was it later able to connect to the notifier?
• Is the FQDN resolvable? → nslookup my.domain
• Restart both notifier and listener, check: systemctl status univention-directory-notifier.service and systemctl status univention-directory-listener.service

[kreiner]

• It was not able to connect
• FQDN is resolvable

root@ldap:~# systemctl status univention-directory-notifier.service && systemctl status univention-directory-listener.service
● 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-11-13 10:31:36 CET; 50s ago
Docs: man:systemd-sysv-generator(8)
Process: 4342 ExecStop=/etc/init.d/univention-directory-notifier stop (code=exited, status=0/SUCCESS)
Process: 4351 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

Nov 13 10:31:35 ldap systemd[1]: Starting LSB: Univention Directory Notifier Daemon…
Nov 13 10:31:36 ldap univention-directory-notifier[4351]: Starting Univention Directory Notifier Daemon: univention-directory-notifierok: run: univention-directory-notifier: (pid 4365) 0s, normally down
Nov 13 10:31:36 ldap univention-directory-notifier[4351]: .
Nov 13 10:31:36 ldap systemd[1]: Started LSB: Univention Directory Notifier Daemon.
● univention-directory-listener.service - LSB: Univention Directory Listener Daemon
Loaded: loaded (/etc/init.d/univention-directory-listener; generated; vendor preset: enabled)
Active: active (exited) since Wed 2019-11-13 10:31:59 CET; 28s ago
Docs: man:systemd-sysv-generator(8)
Process: 4403 ExecStop=/etc/init.d/univention-directory-listener stop (code=exited, status=0/SUCCESS)
Process: 4425 ExecStart=/etc/init.d/univention-directory-listener start (code=exited, status=0/SUCCESS)
CPU: 94ms

Nov 13 10:31:58 ldap systemd[1]: Stopped LSB: Univention Directory Listener Daemon.
Nov 13 10:31:58 ldap systemd[1]: Starting LSB: Univention Directory Listener Daemon…
Nov 13 10:31:59 ldap univention-directory-listener[4425]: Starting Univention Directory Listener Daemon: univention-directory-listener.
Nov 13 10:31:59 ldap systemd[1]: Started LSB: Univention Directory Listener Daemon.

• We have some iptable rules in place for ldap. But those should not affect internal traffic.
• I disabled iptables by putting accept as first rule, still the listener cant connect

[troeder]

1. Please verify with ps aux | grep notifier that the process is actually running.
2. Please remove all firewall rules and see if that fixes the problem. Best would be to remove the firewall and reboot.

[kreiner]

root@ldap:~# ps aux | grep notifier
root 561 0.0 0.0 4048 936 ? Ss Nov11 1:59 runsv univention-directory-notifier
root 29114 0.0 0.0 14320 1012 pts/0 S+ 14:29 0:00 grep notifier

I’ll try 2. later today.

Thanks for your help.

[kreiner]

Removed our packetfilter rules, rebooted, the listener still cant connect.

[kreiner]

notifier log:
13.11.19 14:58:20.373 DEBUG_INIT
13.11.19 14:58:20.510 TRANSFILE ( ERROR ) : 7719586 ldap_add(): Other (e.g., implementation specific) error
13.11.19 14:58:28.707 DEBUG_INIT

Is there more verbose logging?

[kreiner]

I increased the debug level and now the log is full of TRANSFILE messages.

[kreiner]

univention-translog check output:

/var/lib/univention-ldap/notify/transaction needs fixing:                                                                              
- missing transactions in sequence

[kreiner]

This

How-To: Check for listener / notifier Service Status

Howto Check for Listener/ Notifier Service Status This article will describe how to check if an issue with listener or notifier service on UCS hosts exist. Environment: For checking the current Listener/ Notifier Service Status, we are using a nagios-plugin, deployed by us automatically. You can find it (and many others) in /usr/lib/nagios/plugins/ Hint: Even after upgrading to UCS 5 and switching from Nagios to our dashboard, these plugins are available and can still be used. Step 1: Get …

and this

Problem: MDB_MAP_FULL

Problem You notice a message from OpenLDAP MDB_MAP_FULL and your see related entries in /var/log/syslog: MDB_MAP_FULL: Environment mapsize limit reached Or maybe you find something like this in the listener.log: ldapError: Other (e.g., implementation specific) error: entry update failed this also means the maxium databasesize is reached In the listener.log you may see: LISTENER ( ERROR ) : couldn't receive header Could be an indication of the mdb size full, too. Investigation Check the…

fixed my issue.