Hi Community,
I’m trying the Cool Solutions sync users/groups into second domain on 2 freshly installed servers, but this does not seem to work any more.
When trying to run the shown ssh-copy-id command from the source server we get the following error:
/usr/bin/ssh-copy-id: ERROR: failed to open ID file '/var/lib/univention-user-group-sync/.ssh/id_rsa.pub': No such file
The ssh keys for the ucs-sync user seems to not have been created.
Anyone knows if this Cool Solution is still usable/maintaned?!
Kind regards.
was the join script 99univention-user-group-sync-source_add-ucs-sync.inst executed successfully?
You can check that by running univention-check-join-status or looking in the UMC module “Domain Join” in the “Domain” tab. The scripts adds the user and the SSH key. If it was not executed and the aforementioned command tells you so, you can run it by executing univention-run-join-scripts.
On which server role are you trying to set up the sync?
Hey Valentin,
Thanks for your reply. The output of those commands looks all right (see further below), but the log /var/log/univention/listener.log is showing some related errors i think:
22.03.20 19:49:11.257 LISTENER ( WARN ) : received signal 15
22.03.20 19:49:16.546 DEBUG_INIT
22.03.20 19:49:16.553 LISTENER ( WARN ) : Notifier/LDAP server is ucs.mydomain.loc:7389
22.03.20 19:49:16.553 LDAP ( PROCESS ) : connecting to ldap://ucs.mydomain.loc:7389
22.03.20 19:49:17.554 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'
22.03.20 19:49:17.554 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=ucs.mydomain.loc port=7389 base=dc=mydomain,dc=loc
UNIVENTION_DEBUG_END : uldap.__open host=ucs.mydomain.loc port=7389 base=dc=mydomain,dc=loc
The requested output of univention-check-join-status and univention-run-join-scripts:
it seems the user does not exist at least on the local system. I have an idea why but to confirm that I need the server role of your system. You can get it like so: ucr get server/role
Also does the following command give anything back? univention-ldapsearch -LLL -b “uid=ucs-sync,cn=users,$(ucr get ldap/base)”
thanks for the note! I think that’s the problem. The join script creates a new user, which is required for managing the user/group data files created by the sync. It seems that this does not work in your scenario.
You can try to create the user manually.
User name: ucs-sync
unixhome: /var/lib/univention-user-group-sync
uidNumber: 342
After the user has been created generate the SSH key su - ucs-sync -c “ssh-keygen -q -f ~/.ssh/id_rsa -t rsa -N ‘’”
Lastly, restart the listener /etc/init.d/univention-directory-listener restart
and see if the error in /var/log/univention/listener.log persists.
We’re only getting some different errors now, but no users/groups on the target system (see below). Any other logs i can check or some debug setting i can adjust to get some insight?
those messages mean that the module was initialized successfully, so it should be working.
Some things you can check now:
Are files being generated below /var/lib/univention-user-group-sync when you change a user?
Are those files successfully being transferred to the destination system?
Does univention_user_group_sync_dest.py put out any errors when importing these files?
Also check /var/log/univention/user-group-sync.log on the destination for that
Make sure that the objects you’re trying to sync are matched by the default filter mentioned in the docs: Cool Solution - Sync Users and Groups into a second Domain
Search for the paragraph " Filter the LDAP objects to be synchronized".
If you have set a custom filter with ldap/sync/filter, make sure that the objects you’re trying to transfer are actually matched by that filter (use univention-ldapsearch to test both).
I’m guessing the files are being transferred with scp to the ‘destination’, so i logged in as the ucs-sync user and tried it manually:
root:# su - ucs-sync
ucs-sync:$ cd ~
ucs-sync:$ pwd
/var/lib/univention-user-group-sync
ucs-sync:$ scp -i ~/.ssh/id_rsa.pub /var/lib/univention-user-group-sync/test.txt ucs-sync@192.168.0.16:/var/lib/univention-user-group-sync/
Enter passphrase for key '/var/lib/univention-user-group-sync/.ssh/id_rsa.pub':
Password:
This seems odd. I’ve re-created the rsa keys as root with your command from a few posts back and also as the ucs-sync user and made sure no password was entered… Result is the same.
Did you copy the ssh key to the destination system? Your output looks like you’re being asked for the (empty) password for the key first and then for the password of ucs-sync@192.168.0.16. That hints at the ssh key not being present at the destination.
Please execute the ssh-copy-id from the cool solution again.
‘source’ server is a domain member (of Windows domain).
Installing the univention-user-group-sync-source package on the ‘source’ server i straight away get 2 lines of text in red (full output at the end of post):
Warning: cron.service changed on disk. Run 'systemctl daemon-reload' to reload units.
This output means that the initialization of the listener module failed. Very likely due to the error you posted in your last comment.
The user creation works and the user does appear in the local passwd db but a su ucs-sync does not work. I assume this is due to your AD Member Setup. I haven’t seen this cool solution work in such an environment - only in UCS domains, with and without a connected AD.
Depending on what you intend to use UCS for in your scenario, it might be feasible to install UCS not as a member but as an independent DC master and install the AD Connector from the App Center on it to get users and groups from AD. In that scenario the cool solution should work.
We can also modify the cool solution to work in such a scenario in the professional service. Feel free to drop me a message for that. I can get you in touch with sales then.
Hi @jester,
I might have another interesting finding here. By coincidence we were able to observe the problem on another standard UCS domain as well yesterday and I’ve implemented a fix. Package updates should be available soon. It seems to be a timing problem between restarting the listener, it noticing that the import of the listener module which generates the files succeeds and triggering a resync of that module.
Hi Valentin,
Sorry for the lack of response, awkward times at the moment.
Hope to find some time tomorrow to see if your fix will help my case… would be great.
we have just released an update for the sync packages, that should fix the issue that occurs during the installation of the source package.
I suggest you clean up just to make sure, then update the package:
eval "$(ucr shell)"
udm users/user remove --ignore_not_exists --dn "uid=ucs-sync,cn=users,$ldap_base"
rm -rf /var/lib/univention-user-group-sync
# This will put out an error from postrm, you can ignore that
apt remove univention-user-group-sync-source
univention-install univention-user-group-sync-source