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.
--
[email protected]
https://inverse.ca/sogo/lists
