It never ends, bumping sogod daemons much CPU.

These two addressbooks are LDAP address books. The "normal" ones are working 
properly. But these LDAP address books seem to make probles with SOGo connector. Any hint?

It's a mix of a bug in SOGo, a lack of feature in Thunderbird and a configuration issue. Let me explain....

In SOGo, we use SQL-based addressbooks for all user addressbooks and LDAP-based addressbooks for "system addressbooks". What "system" means is that it represents a read-only source of user informations that is managed only by the system administrator and outside of SOGo itself. In Thunderbird, all user addressbooks but only one system addressbook can be used for finding users when composing emails or inviting people to an event. That's a limit of Thunderbird. In SOGo Connector, user addressbooks are synchronized (via webdav sync) with local Thunderbird addressbooks while system addressbooks are queried in real time via a carddav request.

I suspect the problem that occurs is that SOGo Connector considers those 2 addressbooks as "user addressbooks" rather than "system addressbooks", which trigger webdav sync queried, which are not supported for system addressbooks. There would thus be 2 bugs:
- SOGo Connector must consider them as system addressbooks
- SOGo must not report those addressbooks as "webdavsync capable"
In order to confirm this, please provide us with a sniff log of the SOGo traffic when this occurs, from the moment you launch Thunderbird until the problem starts to show up.

Regarding your configuration, you should probably declare "unikn_users" as value for the "publicid" key mentionned by Ludovic. Following its name I believe it is more likely to be queried for useful information than the other ones.

Cheers,
--
Wolfgang Sourdeau  ::  +1 (514) 447-4918 ext. 125  ::  wsourd...@inverse.ca
Inverse inc. Leaders behind SOGo (sogo.nu) and PacketFence (www.packetfence.org)
--
users@sogo.nu
https://inverse.ca/sogo/lists

Reply via email to