http://www.sogo.nu/bugs/view.php?id=2253
Am 22.02.2013 16:39, schrieb Achim Gottinger:
Am 22.02.2013 15:50, schrieb Achim Gottinger:
Am 22.02.2013 13:21, schrieb Achim Gottinger:
Am 19.02.2013 13:01, schrieb Achim Gottinger:
Am 19.02.2013 12:16, schrieb Achim Gottinger:
Am 17.02.2013 14:59, schrieb Achim Gottinger:
Since I upgraded to SOGo 2.0.4b the Calendars I had shared for
LDAP Groups before are no longer visible for the members of these
groups. Also they do not show up if i try to readd them manually
via the web fronted calendar abo. Fortunately sharing these
calendars for autheticated users works again so i shared these
calendars for all authenticated users meanwhile.
Looking at the git commits i guess some change in sope caused
that different behaviour. I have abit of spare time to add a few
debugging lines to the source and try to detect where it went
wrong but i'd be glad for an pointer into the right direction.
achim~
Getting lost in the source code here. I can not find the place
where the ACL's for LDAP Groups get resolved.
To specify my issue abit more. I created an user to share a few
google calendars for users here. I can add the ACL for my LDAP
Groups via Thunderbird and SOGo-Web, edit them and they get still
stored proper in the mysql db. I did the configuration with 2.0.3a
and at that time the calendars showed up for all members of the
assigned LDAP Group. For some reason this is no longer the case
with 2.0.4b, i'm unsure if i tested it with 2.0.4a. And now even
if i downggrade to 2.0.3a the calendars do not appear and can
neighter be manually subscribed.
The sogo logs are not helpfull and debugging samba4 LDAP queries
is abit painfull so i thought it's easier to add a bit more
verbosity to logging output in the source if i could only find an
good point to start.
Thanks in advance
achim~
So far this is the memcached log when I hit the plus sign at the
subscriptions dialog for the user google whom shares the calendars
for the group info. jg is the current user.
<27 get jg+settings
>27 sending key jg+settings
>27 END
<27 get google/Calendar/personal+acl
>27 END
<27 get google/Calendar/personal+acl
>27 END
<27 set google/Calendar/personal+acl 0 300 10
>27 STORED
<27 set google/Calendar/personal+acl 0 300 27
>27 STORED
<27 get google/Calendar/7C2F-510A6D80-1-62488280+acl
>27 END
<27 get info+
>27 END
.........
<27 get jxxxx.gxxxx+attributes
>27 END
<27 set jxxxx.gxxxx+attributes 0 300 4
>27 STORED
..........
<27 set info+ 0 300 39
>27 STORED
<27 get info+
>27 sending key info+
>27 END
To me that memcached log looked like the group acls get inspected
and the assigned users are enumerated but then the acls are not
mapped correct to the current user. I tried to debug what's going on
with gdb and inspecting objects with the po command but i'm still
struggling to find the correct place for an breakpoint and i'm
unsure if the problem is located inside sope or sogo. I'd really
appreciate any input on how to figure out the cause of the problem.
achim~
K, an good point for an breakpoint was [SOGOGroup _member]
*
*In line 264
login = [um getLoginForDN: [dn lowercaseString]
If the inspected user dn has the description attribute set
login=description otherwise login=sAMAccountName.
If description is returned the next line
user = [SOGoUser userWithLogin: login roles:nil]
returns nil.
For my LDAP Group's (Samba4 AD) I use
CNFieldsName: cn
IDFieldName: cn
UIDFieldName: description
For the Users these are all sAMAccountName.
So as an quick workaround i removed the description attribute values
for the users i do not need em anyway and the calendars can be
subscribed again.
Inspecting things abit further:
SOGoUserManager.m getLoginForDN
does call currentSource lookupLoginByDN in line 972.
currentSource is LDAPSource.m
And in that function the UIDFiled variable has the value "description"
coming from my LDAP Group definitions if the User has "description"
defined in hist ldap entry.
And so that value is returned instead of the attribue samaccountname's
value.
This looks like an bug to me, i'll try to describe that in an bug report.
cheers,
achim~
--
[email protected]
https://inverse.ca/sogo/lists
