Cool Solution user-group-sync fails

UCS - Univention Corporate Server
#21

Hi Valentin,
Finally found some time to give the updated package a test.

The files in /var/lib/univention-user-group-sync are now being transferred to the ‘destination’ system, so that part is working now!

On the destination system some of the users from the source system have been imported, but only a small part. When running the command univention_user_group_sync_dest.py i get:

Reading file /var/lib/univention-user-group-sync/01586186643.9837890
W: Different objectClasses detected NEW ['krb5KDCEntry', 'person', 'automount', 'top', 'inetOrgPerson', 'krb5Principal', 'organizationalPerson', 'univentionPWHistory', 'univentionMail', 'univentionObject', 'shadowAccount', 'sambaSamAccount', 'posixAccount'] vs. OLD ['krb5KDCEntry', 'organizationalPerson', 'automount', 'top', 'inetOrgPerson', 'krb5Principal', 'person', 'univentionPWHistory', 'univentionMail', 'univentionSAMLEnabled', 'shadowAccount', 'sambaSamAccount', 'nextcloudUser', 'posixAccount', 'univentionObject']
W: Ignoring difference in objectClass as specified in ldap/sync/ignore_error/objectClass_difference : univentionSAMLEnabled
E: During User.modify_ldap: Traceback (most recent call last):
  File "/usr/bin/univention_user_group_sync_dest.py", line 440, in _direct_update
    lo.modify(user.position.getDn(), modlist)
  File "/usr/lib/python2.7/dist-packages/univention/admin/uldap.py", line 902, in modify
    raise univention.admin.uexceptions.ldapError(_err2str(msg), original_exception=msg)
ldapError: Object class violation: attribute 'nextcloudEnabled' not allowed

And in /var/log/univention/user-group-sync.log i see a similar error repeat:

Apr 06 18:50:02: Reading file /var/lib/univention-user-group-sync/01586186643.9837890
Apr 06 18:50:02: Modify User: 'uid=myuser,cn=users,dc=mydomain,dc=loc'
Apr 06 18:50:02: W: Different objectClasses detected NEW ['krb5KDCEntry', 'person', 'automount', 'top', 'inetOrgPerson', 'krb5Principal', 'organizationalPerson', 'univentionPWHistory', 'univentionMail', 'univentionObject', 'shadowAccount', 'sambaSamAccount', 'posixAccount'] vs. OLD ['krb5KDCEntry', 'organizationalPerson', 'automount', 'top', 'inetOrgPerson', 'krb5Principal', 'person', 'univentionPWHistory', 'univentionMail', 'univentionSAMLEnabled', 'shadowAccount', 'sambaSamAccount', 'nextcloudUser', 'posixAccount', 'univentionObject']
Apr 06 18:50:02: W: Ignoring difference in objectClass as specified in ldap/sync/ignore_error/objectClass_difference : univentionSAMLEnabled
Apr 06 18:50:02: E: During User.modify_ldap: Traceback (most recent call last):
  File "/usr/bin/univention_user_group_sync_dest.py", line 440, in _direct_update
    lo.modify(user.position.getDn(), modlist)
  File "/usr/lib/python2.7/dist-packages/univention/admin/uldap.py", line 902, in modify
    raise univention.admin.uexceptions.ldapError(_err2str(msg), original_exception=msg)
ldapError: Object class violation: attribute 'nextcloudEnabled' not allowed

I’m guessing the warnings can be ignored (possibly resolved by installing Active Directory-compatible Domain Controller component), but the error looks more serious.

Kind regards.

#22

Hi jester,

please refer to the paragraph " Remove attributes/objectClasses before sync" in the docs on how to deal with attributes or objectClasses which are not present in both domains.

Best regards,
Valentin

#23

Hi Valentin,
Thanks again for your reply!

Right, missed that. My test apps were installed on the destination system (in dmz) so was “Object class violation” paragraph in my case. But still it would not work, changes did not get replicated.

I’ve started over again, one freshly installed source UCS in LAN (just domaincontroller_master, no AD member this time) and a fresh UCS (also domaincontroller_master) destination install in DMZ. Both fully updated.

Ran through the ‘User roup sync’ installation again, everything fine. But even after >10min. no LDAP export files appearing in /var/lib/univention-user-group-sync.

On both source and target systems:

  • univention-check-join-status = .Joined successfully
  • univention-run-join-scripts = everything skipped (already executed) - all OK
  • univention-ldapsearch -LLL -b "uid=ucs-sync,cn=users,$(ucr get ldap/base)" - both return LDAP account info, so ucs-sync user is present.

After a source server reboot: LDAP export files are created… And after some time they are transferred to the target system and my test user appears… But only this once!

Any changes to my test user on the source system do not get replicated, not even after a reboot.

18.04.20 16:18:47.004  LDAP        ( PROCESS ) : connecting to ldap://ucs01.mydomain.loc:7389
18.04.20 16:18:47.008  LISTENER    ( PROCESS ) : updating 'uid=user01,cn=users,dc=mydomain,dc=loc' command m
18.04.20 16:28:09.680  LDAP        ( PROCESS ) : connecting to ldap://ucs01.mydomain.loc:7389
18.04.20 16:28:09.683  LISTENER    ( PROCESS ) : updating 'uid=user01,cn=users,dc=mydomain,dc=loc' command m
18.04.20 17:21:22.009  LDAP        ( PROCESS ) : connecting to ldap://ucs01.mydomain.loc:7389
18.04.20 17:21:22.013  LISTENER    ( PROCESS ) : updating 'uid=user01,cn=users,dc=mydomain,dc=loc' command m
18.04.20 17:22:03.629  LISTENER    ( WARN    ) : received signal 15
18.04.20 17:22:30.465  DEBUG_INIT
18.04.20 17:22:30.480  LISTENER    ( WARN    ) : Notifier/LDAP server is ucs01.mydomain.loc:7389
18.04.20 17:22:30.480  LDAP        ( PROCESS ) : connecting to ldap://ucs01.mydomain.loc:7389
18.04.20 17:22:31.675  LISTENER    ( ERROR   ) : import of filename=/usr/lib/univention-directory-listener/system/univention_user_group_sync_source_generate.py failed
Traceback (most recent call last):
  File "/usr/lib/univention-directory-listener/system/univention_user_group_sync_source_generate.py", line 74, in <module>
    owning_user_number = pwd.getpwnam('ucs-sync').pw_uid
KeyError: 'getpwnam(): name not found: ucs-sync'
18.04.20 17:22:31.675  LISTENER    ( ERROR   ) : import of filename=/usr/lib/univention-directory-listener/system/univention_user_group_sync_source_generate.py failed in module_import()
UNIVENTION_DEBUG_BEGIN  : uldap.__open host=ucs01.mydomain.loc port=7389 base=dc=mydomain,dc=loc
UNIVENTION_DEBUG_END    : uldap.__open host=ucs01.mydomain.loc port=7389 base=dc=mydomain,dc=loc
18.04.20 17:39:48.092  LDAP        ( PROCESS ) : connecting to ldap://ucs01.mydomain.loc:7389
18.04.20 17:39:48.096  LISTENER    ( PROCESS ) : updating 'uid=user01,cn=users,dc=mydomain,dc=loc' command m
#24

Some more findings:

Looking at /var/lib/univention-user-group-sync there are no LDAP export files, even after reboot. Running univention-directory-listener-ctrl resync univention_user_group_sync_source_generate will generate LDAP export files again in /var/lib/univention-user-group-sync but they never get synced.

Changing to ucs-sync (su - ucs-sync) and manually running univention_user_group_sync_source_synchronize (as what etc/cron.d/univention-ucr-cronjobs does) will sync all LDAP exports. After the import process has finished my changes are visible on the destination server in DMZ.

So to sum things up: only the initial export gets synced, once after a reboot. And then it stops working, on the source system.

I think it would be wise to remove the ucs-4-4 tag from the article for now (because it’s not working on a clean UCS 4.4-4 install)… Just to indicate others to refrain from using it for the moment.

I’ve got the test VMs running with snapshots of a clean state right after a fresh install of UCS …so shoot if you want me to test something.

Kind regards.

#25

Hi jester,

thanks for the details. Unfortunately, I don’t think I can assist you further without having a look at the system. Sorry about that. It seems that there is a problem with the ucs-sync user being replicated as a local user on your system or the Python library fails at least sometimes.

The sync is running without problems at several customers of ours on UCS 4.4 and we couldn’t reproduce this problem in any of the last quality assurances, so at this point I wouldn’t remove the tag. If you’d like to request further assistance by the Professional Service at Univention, feel free to contact us.

Best regards,
Valentin

#26

Hi Valentin,

Just contacted the Univention Head Office to ask how to get further assistance. I explained my situation: user accounts from our Windows AD to a UCS in DMZ for Rocket.Chat. They wondered why i was using this Cool Solution and not the usual way this was set up: a read-only sync to the DMZ.

I was under the impression that a read only sync (I’m guessing we’re talking about a UCS Slave DC in the DMZ) would be less safe and a lot more ports would have to be opened on the firewall.

I was told to ask you this here on the forum, because the person i spoke to was no engineer… so:

  • Could you tell me if we are talking about a UCS Slave DC in the DMZ for this ‘usual way’ or something else?
  • Is this (more or less) just as safe as the Cool Solution one-way-sync?
  • And if so, could you tell me the ports that need to be opened on the firewall between LAN <-> DMZ for this to work?

Kind regards.

Mastodon