Free/busy lists broken - HELP!

[Gunnar Wrobel]

Quoting Albrecht Dreß <albrecht.dress at lios-tech.com>:

> Quoting Albrecht Dreß <albrecht.dress at lios-tech.com>:
>> /kolab/var/kolab-freebusy/cache/ and all files and sub-folders are
>> world-readable, i.e. the usual owner is kolab-n:kolab-n, files have
>> (at least) 0644 permissions, and folders 0755.  Or are you referring
>> to /imap/ folder permissions?
>
> As to get more information about this bug and following a hint by
> Saim, I made a few tests.  Before starting each test, I completely
> erased the contents of the /kolab/var/kolab-freebusy/cache folder and
> then triggered the re-generation of the fb lists for
> "first.user at my-domain.com" and "second.user at my-domain.com" by calling
> the /freebusy/trigger/<user-name>/Kalender.pfb uri's as calendar user.
>   Here are my observations:
>
>
> (1) Enable unauthorised download of fb lists in the admin ui (my
> standard setting).
> The file aclcache.db does not contain data, the file xaclcache.db
> contains two lines in the form
>
>   calendar at my-domain.com
>   my-domain^com/first^user/Kalender,my-domain^com/second^user/Kalender
>
> The Kalender.pvc files seem to contain the proper appointment data.
>
> However, when I download the fb list via the /freebusy/<user-name>.ifb
> uri, I get the dummy freebusy lists.  The same applies for the *.vc
> files.  The log file tells me: "Free/busy data of owner
> first.user at my-domain.com on server srv-portal.my-server.de requested
> by user ."
>
>
> (2) Disable unauthorised download of fb lists in the admin ui.
> The contents of the x?aclcache.db files is the same as above.  And,
> again, the Kalender.pvc files seem to contain the proper data.
>
> When I now try to access the *.ifb uri's, Firefox asks me to
> authenticate.  Entering first.user at my-domain.com and the proper
> password, I still get empty (dummy) fb lists, bor *both*
> first.user at my-domain.com and for second.user at my-domain.com.  However,
> the *.vc files now reside in the
> my-domain^com/first^user/my-domain^com/ sub-folder of the cache
> folder, and are all "dummy" ones.
>
> BTW, the log file now says "Free/busy data of owner
> first.user at my-domain.com on server srv-portal.my-server.de requested
> by user first.user at my-domain.com."
>
>
> (3) Switch back to unauthorised download.  The log file still says
> that I try to download as authenticated user, and the vc files are
> created below each "user folder", but they are still "dummy" ones.
>
>
> I added some more debug calls to
> /kolab/lib/php/Kolab/Freebusy/Cache.php (which seems to be used by
> /kolab/var/kolab/www/freebusy/freebusy.php), and apparently it
> consults the file /kolab/var/kolab-freebusy/cache/aclcache.db.  As
> this one seems to be always empty, this might be an explanation for
> the empty fb lists.
>
> This leads me to the question if I completely misunderstood the
> concept of fb lists (which IMHO should *always* return the fb
> information for every user, regardless of the IMAP acl setting for the
> Calender folder which should only apply to the /contents/ of
> appointments, right?), of if the creation of the lists and/or the
> related ACL's is broken.
>
> Still, the big question is how to fix this bug...

Can you check if the patch in  
https://www.intevation.de/roundup/kolab/issue3074 helps?

Cheers,

Gunnar

>
> Thanks, Albrecht.
>
> _______________________________________________
> Kolab-users mailing list
> Kolab-users at kolab.org
> https://kolab.org/mailman/listinfo/kolab-users
>



-- 
______ http://kdab.com _______________ http://kolab-konsortium.com _

p at rdus Kolab work is funded in part by KDAB and the Kolab Konsortium

____ http://www.pardus.de _________________ http://gunnarwrobel.de _
E-mail : p at rdus.de                                 Dr. Gunnar Wrobel
Tel.   : +49 700 6245 0000                          Bundesstrasse 29
Fax    : +49 721 1513 52322                          D-20146 Hamburg
--------------------------------------------------------------------
    >> Mail at ease - Rent a kolab groupware server at p at rdus <<
--------------------------------------------------------------------


----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digitale PGP-Unterschrift
URL: <http://lists.kolab.org/pipermail/users/attachments/20081103/377859c2/attachment.sig>