Hello,
Sorry i don't get it, but maybe it is not the same issue.
The pref:
pref("sogo-integrator.autocomplete.server.urlid", "mydomain.tld-public");
match sogo configuration:
id = mydomain.tld-public;
with "isAddressBook = YES;" for each domain.
The private "SQL" addressebook and the LDAP "system" addressebook are
working fine, but sogo keep asking for one more adressebook call
mydomain.tld-public.
"REPORT /SOGo/dav/myuser/Contacts/mydomain.tld-public/ HTTP/1.1" 207 126
As you describe the private "SQL" addressebook is read/write enable
and the LDAP "system" addressebook is readonly as it is LDAP.
Why is sogo asking for a new adressbook as all of the configure
addressbook are there and working.
Regards,
Francois
Wolfgang Sourdeau <[email protected]> a écrit :
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 :: [email protected]
Inverse inc. Leaders behind SOGo (sogo.nu) and PacketFence
(www.packetfence.org)
--
[email protected]
https://inverse.ca/sogo/lists
--
[email protected]
https://inverse.ca/sogo/lists