[Solved? / new question] Q: triggering freebusy updates

Bernhard Reiter bernhard at intevation.de
Thu Jan 21 16:01:10 CET 2010


Am Mittwoch, 20. Januar 2010 21:11:47 schrieb Albrecht Dreß:
> Am 19.01.10 17:12 schrieb(en) Albrecht Dreß:
> > I noticed that the cache file
> > /kolab/var/kolab-freebusy/cache/my-domain^com/some^user.vc got updated,
> > but contained ancient information.  Looking deeper, the file
> > /kolab/var/kolab-freebusy/cache/my-domain^com/some^user/Kalender.pvc was
> > also very old (actually, all Kalender.* files in this folder).  This
> > apparently happens to all users.
> >
> > I could call
> > https://kolab.my-server.de/freebusy/trigger/some.user@my-domain.com/Kalen
> >der.pfb, which returned the correct data, and afterwards both the .vc file
> > and the Kalender.* files were up-to-date.  But shouldn't the update of
> > the Kalender.* be performed automatically, e.g. each time the user
> > inserts a new appointment into the calendar?

The client is responsible for issuing the trigger link after writing the 
calender file. How freebusy should work, see

http://kolab.org/cgi-bin/viewcvs-kolab.cgi/doc/architecture/freebusy.txt?rev=HEAD
ftp://intevation.de/users/bernhard/scratch/extended-freebusy-concept-0.92%2Bdev20080503-ber1-pub2.pdf

> Apparently, the problem were wrong permissions of
> /kolab/etc/kolab/kolab.conf, which was read-only for root.  Making the file
> world-readable, adding a new appointment does update the Kalender.* files
> again, and also the 'do_search: invalid dn (k=kolab,)' warnings in the
> OpenLDAP log disappeared (caused by kolabquotawarn).
>
> I guess it's not a clever idea to make kolab.conf world-readable.  

Correct. It contains the password for the calender user, which is the daemon
that can accept invitations automatically. In order for this daemon to do so,
the "calender" needs write permissions on the folders in question. (Regular 
accounts need to grant it. Resource accounts usually get initialised with 
it.)

> What are 
> the right permissions for this file? 

One of my test installation has: 
-rw-------   1 kolab kolab     kolab.conf

> Unfortunately, the template (unlike 
> other files) does not contain a KOLAB_META_* header indicating the proper
> ownership and mode.

kolab.conf is not a regular template.

-- 
Managing Director - Owner: www.intevation.net       (Free Software Company)
Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com.
Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998
Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.kolab.org/pipermail/users/attachments/20100121/2ed3dc9a/attachment.sig>


More information about the users mailing list