Bug 44466 - BDB-Listener cache on DC Backup not converted to mdb
BDB-Listener cache on DC Backup not converted to mdb
Status: CLOSED FIXED
Product: UCS
Classification: Unclassified
Component: Listener (univention-directory-listener)
UCS 4.2
Other Linux
: P5 critical (vote)
: UCS 4.2-0-errata
Assigned To: Arvid Requate
Felix Botner
:
Depends on: 23367
Blocks:
  Show dependency treegraph
 
Reported: 2017-04-25 14:28 CEST by Arvid Requate
Modified: 2017-05-03 15:16 CEST (History)
2 users (show)

See Also:
What kind of report is it?: Bug Report
What type of bug is this?: 3: Simply Wrong: The implementation doesn't match the docu
Who will be affected by this bug?: 4: Will affect most installed domains
How will those affected feel about the bug?: 5: Blocking further progress on the daily work
User Pain: 0.343
Enterprise Customer affected?:
School Customer affected?:
ISV affected?:
Waiting Support:
Flags outvoted (downgraded) after PO Review:
Ticket number:
Bug group (optional): Troubleshooting
Max CVSS v3 score:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Arvid Requate univentionstaff 2017-04-25 14:28:37 CEST
On my updated UCS 4.2-0 DC Backup the /var/lib/univention-directory-listener/cache.db has not been converted to MDB. Apparently the listener was restarted during update between unpack and postinst, so the /var/lib/univention-directory-listener/cache/data.mdb was already created before the update. As a result the cache doesn't contain the pre-UCS-4.2 data.

==============================================================================
Entpacken von univention-directory-listener (11.0.1-26A~4.2.0.201703301642) über (10.0.0-20.338.201610211230) ...

[...]
univention-samba4 (6.0.9-10A~4.2.0.201703301128) wird eingerichtet ...
[...]
Restarting univention-directory-listener daemon.
ok: run: univention-directory-listener: (pid 26562) 0s, normally down
done.

[...]
univention-pam (10.0.0-4A~4.2.0.201701292009) wird eingerichtet ...
[...]
Restarting univention-directory-listener daemon.
ok: run: univention-directory-listener: (pid 26741) 0s, normally down
done.

[...]
univention-pkgdb-tools (10.0.2-2A~4.2.0.201703241416) wird eingerichtet ...
Restarting univention-directory-listener daemon.
ok: run: univention-directory-listener: (pid 32350) 0s, normally down
done.

[...]
univention-quota (11.0.0-5A~4.2.0.201703231014) wird eingerichtet ...
[...]
Restarting univention-directory-listener daemon.
ok: run: univention-directory-listener: (pid 14601) 0s, normally down
done.

[...]
univention-mail-postfix (11.0.0-4A~4.2.0.201703151926) wird eingerichtet ...
[...]
Restarting univention-directory-listener daemon.
ok: run: univention-directory-listener: (pid 15046) 0s, normally down
done.

univention-directory-listener (11.0.1-26A~4.2.0.201703301642) wird eingerichtet ...
+ [ -f /var/lib/univention-directory-listener/cache/data.mdb ]
+ return 0
==============================================================================
Comment 1 Arvid Requate univentionstaff 2017-04-25 14:59:47 CEST
I've added another conversion section to the postinst.

Advisory: univention-directory-listener.yaml
Comment 2 Felix Botner univentionstaff 2017-04-26 11:00:48 CEST
UCS 4.1-4 master + backup (with s4 con) + slave + member

=> update to 4.2-0

I could reproduce this on my backup, slave and member (master was ok).

After the update 

/var/lib/univention-directory-listener/cache.db

still existed and the listener cache was rather empty.

 -> univention-directory-listener-dump | grep dn:| wc -l
 17

Replication (and s4 con) worked at this point, now objects where added to the listener cache. 

Then i updated the univention-directory-listener package (errata4.2-0)

master: OK

cache convert omitted

backup: OK
...
[....] Stopping univention-directory-listener (via systemctl): univention-directory-listener.service^[[?25l^[7^[[1G[^[[32m ok ^[[39;49m^[8^[[?12l^[[?25h.^M
25.04.17 17:34:42.654  DEBUG_INIT^M
Converting listener cache to LMDB^M
cached notifier_id:     1270^M
cached schema_id:       11^M
...

Cache has been converted successfully, listener id has been decreased to the id from before the update, but no sign of hickups (s4 connector got an extra add for objects created after the update, but also no problems here).

Replication (s4 con) still works.

slave: OK
...
26.04.17 00:36:38.768  DEBUG_INIT
Converting listener cache to LMDB
cached notifier_id:     1270
cached schema_id:       11
...

member: OK
...
26.04.17 00:42:44.222  DEBUG_INIT
Converting listener cache to LMDB
cached notifier_id:     1270
cached schema_id:       11
...

OK - On all system the cache has been converted, cache.db has been removed and the number of cache entries was bigger then before the update (which is OK, because i created objects after the upate)

OK - YAML
Comment 3 Janek Walkenhorst univentionstaff 2017-05-03 15:16:17 CEST
<http://errata.software-univention.de/ucs/4.2/10.html>