Finally found the issue. By default, after the setup the property ranger.usersync.enabled is set to false in ranger-ugsync-site.xml. Setting it to true made synchronisation from LDAP work. Don't know why this behaviour has been implemented, but it seems very unnatural as this isn't even described in the install.properties file. Maybe it's a bug ? Best regards,
Loïc CHANEL Technical leader Big Data Capgemini (Lyon, France) Le ven. 16 févr. 2024 à 11:53, Loïc CHANEL <loic.cha...@telecomnancy.net> a écrit : > Adding more details to this : I provided usersync with a wrong password > for LDAP, but it's still showing the exact same logs. Therefore I'm > wondering where I would be able to get more details about the LDAP > connection from usersync, because the logs are clearly not enough. > Thanks, > > > Loïc CHANEL > Technical leader Big Data > Capgemini (Lyon, France) > > > Le ven. 16 févr. 2024 à 09:05, Loïc CHANEL <loic.cha...@telecomnancy.net> > a écrit : > >> Hi Sailaja, >> >> I already restarted usersync since I deleted the user, but nothing >> happened. Where is this cache supposed to be stored ? >> By the way, SYNC_LDAP_DELTASYNC is set to false in my case, so I guess it >> could change the behaviour ? >> Thanks, >> >> >> Loïc CHANEL >> Technical leader Big Data >> Capgemini (Lyon, France) >> >> >> Le jeu. 15 févr. 2024 à 23:23, Sailaja Polavarapu < >> spolavar...@cloudera.com> a écrit : >> >>> Ranger Usersync caches the users and groups that are sync'd from LDAP >>> and uses this to compute delta for every sync cycle in order to update >>> ranger admin with the changes. Initially, during start up, this cache is >>> built from the users and groups that are in Ranger admin and is updated >>> only when the changes happen at the sync source (like LDAP) for every sync >>> cycle. If you delete the user in Ranger admin, usersync is notified with >>> this change and this user still exists in usersync cache. In order to >>> re-populate this cache from what is updated in ranger admin, you need to >>> restart usersync. Hope this helps. >>> >>> Thanks, >>> Sailaja. >>> >>> On Thu, Feb 15, 2024 at 9:28 AM Loïc CHANEL < >>> loic.cha...@telecomnancy.net> wrote: >>> >>>> Hi guys, >>>> >>>> I'm still working on user sync based on LDAP, I'm afraid the sync >>>> doesn't work without showing any logs. >>>> I performed an initial sync in an older version, and just upgraded to >>>> 2.4. Now, to check the usersync is still working, I deleted a user and >>>> waited for it to be created again except ... it's not, even though the user >>>> is still in the LDAP. >>>> In the logs I can see that usersync is trying to reach the LDAP, but >>>> even with DEBUG log level I can't either see the user is retrieved, nor >>>> there is an error while trying to retrieve it. Here's the only log I get : >>>> >>>> 15 Feb 2024 16:57:02 INFO o.a.r.u.UserGroupSync [UnixUserSyncThread] - >>>> initializing source: >>>> org.apache.ranger.ldapusersync.process.LdapUserGroupBuilder >>>> 15 Feb 2024 16:57:02 INFO o.a.r.l.p.LdapUserGroupBuilder >>>> [UnixUserSyncThread] - LdapUserGroupBuilder initialization started >>>> 15 Feb 2024 16:57:02 DEBUG o.a.h.s.a.AbstractJavaKeyStoreProvider >>>> [UnixUserSyncThread] - backing jks path initialized to >>>> file:/etc/ranger/usersync/conf/rangerusersync.jceks >>>> 15 Feb 2024 16:57:02 INFO o.a.r.l.p.LdapUserGroupBuilder >>>> [UnixUserSyncThread] - LdapUserGroupBuilder initialization completed with >>>> -- ldapUrl: ldap://cmb.blabla.org:389, ldapBindDn: >>>> CN=itsme,ou=CACM,ou=utilisateurs,dc=cmb,dc=blabla,dc=org, >>>> ldapBindPassword: ***** , ldapAuthenticationMechanism: simple, >>>> searchBase: dc=cmb,dc=blabla,dc=org, userSearchBase: >>>> [ou=CACM,ou=utilisateurs,dc=cmb,dc=blabla,dc=org], userSearchScope: 2, >>>> userObjectClass: organizationalPerson, userSearchFilter: >>>> (memberOf=CN=usr_prd,OU=Component,OU=Groupes,DC=blabla,DC=org), >>>> extendedUserSearchFilter: null, userNameAttribute: name, >>>> userSearchAttributes: [postOfficeBox, uSNChanged, name, modifytimestamp, >>>> objectid, userurincipaluame], userGroupNameAttributeSet: [postOfficeBox], >>>> otherUserAttributes: [userurincipaluame], pagedResultsEnabled: true, >>>> pagedResultsSize: 500, groupSearchEnabled: true, groupSearchBase: >>>> [dc=cmb,dc=blabla,dc=org], groupSearchScope: 2, groupObjectClass: >>>> groupofnames, groupSearchFilter: , extendedGroupSearchFilter: >>>> (&null(|(member={0})(member={1}))), extendedAllGroupsSearchFilter: null, >>>> groupMemberAttributeName: member, groupNameAttribute: cn, >>>> groupSearchAttributes: [uSNChanged, displayname, member, cn, >>>> modifytimestamp, objectid], groupSearchFirstEnabled: true, >>>> userSearchEnabled: true, ldapReferral: ignore >>>> 15 Feb 2024 16:57:02 INFO o.a.r.u.UserGroupSync [UnixUserSyncThread] - >>>> Begin: initial load of user/group from source==>sink >>>> 15 Feb 2024 16:57:02 INFO o.a.r.u.UserGroupSync [UnixUserSyncThread] - >>>> End: initial load of user/group from source==>sink >>>> 15 Feb 2024 16:57:02 INFO o.a.r.u.UserGroupSync [UnixUserSyncThread] - >>>> Done initializing user/group source and sink >>>> 15 Feb 2024 16:57:02 DEBUG o.a.r.u.UserGroupSync [UnixUserSyncThread] - >>>> Sleeping for [3600000] milliSeconds >>>> >>>> Could you help me identify what's wrong ? >>>> Thanks, >>>> >>>> Loïc CHANEL >>>> Technical leader Big Data >>>> Capgemini (Lyon, France) >>>> >>>
