[Kolab-devel] Kolab 3.3 feedback

[Daniel Hoffend]

Hi Thomas

Thomas Brüderli wrote:
>The message should be fully consumed by wallace and don't get passed
>along. Need to investigate this.
I'm debugging as well. seems like wallace is doing the wrong lookup 
using shared at example.org instead of resource-beamer-beamer1 at example.org 
Not sure exactly where the error is buried.

>These are just samples and are not supposed to be adapted by 
>setup-kolab
>for only serve as reference for manual configuration.
Well but the packing is copying config.ini.sample to 
/etc/kolab-freebusy/config.ini and then setup-kolab is overwriting parts 
of the configuration using the given defaults.
But it looks with the newest changes in setup-kolab and freebusy that 
the default configuration seems usable apart from the imaps:// 
certificate problem.

>You likely have fbsource = imap://... configured which is not
>recommended for productive systems.
Well ... it's the configuration that is supplied in the default vanilla 
setup and the only option apart from --generateall that works in kolab 
<= 3.3 This database error only happens when all directory 
configurations have been searched and ended up with no result. In this 
case it seems that freebusy is trying to do another lookup run with an 
empty or non-given configuration ending with the given database driver 
error.


>However, the imap:// source uses the Roundcube framework to access 
>event
>data in IMAP and also attempts to use caching for this.
>
>Symlinking /etc/roundcubemail/config.inc.php and
>/etc/roundcubemail/defaults.inc.php in /etc/kolab-freebusy/ should
>resolve these errors.
Yes that works and the packages have already been updated. It was a 
packaging error.

>cacheto is optional and not required when free-busy data is generated 
>by
>kolab-freebusyd --generateall into /var/lib/kolab-freebusy/.
>
>Some basic information is available here:
>http://docs.kolab.org/architecture-and-design/kolab-freebusy.html
>
>But full documentation of the configuration options is yet missing.
That's was the biggest problem. Without a proper configuration I could 
only take the sample configurations and made them run. And tbh. I 
personally prefer the imaps:// over the generateall method because the 
ldap+imap version is also accepting alias addresses while the generated 
version only matches the primary mail which doesn't always has to be the 
address people are used to use.

>kolab-freebusyd now has a daemon mode which is the preferred way to run
>it. It's intended to let the kolab-freebusy service connect to the
>daemon and get updated free-busy data when requested:
>
>[directory "kolab-ldap"]
>...
>fbsource = "fbdaemon://localhost:4455?user=%mail"
>
>This is all bleeding-edge development and unfortunately isn't yet all
>reflected in setup-kolab.
Ah you're speaking about "that" daemon :-)

# kolab-freebusyd --help | grep daemon
   -d, --daemon              Run daemon (todo)
Which is marked as "todo" an therefore I didn't even looked at it that 
the development has been finished. I guess a init rc file is missing. 
IMHO I would consider imaps:// access for kolab-freebusy webservice the 
way to go for Kolab 3.3 (as it is close to release) and the fbdaemon 
could become the prefered method for the next Kolab version (3.4?). This 
way there's enough time to actually test and prepare the daemon.


--
Best Regards
Daniel Hoffend
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 2423 bytes
Desc: not available
URL: <http://lists.kolab.org/pipermail/devel/attachments/20140815/4166e58c/attachment.bin>