Re: [SOGo] LDAP Odditiy
Hello folks, And thanks Ludovic : the problem was indeed related to an incomplete index. The trick here was to add a "substring match" on all the field that are used by sogo when querying the LDAP server. Regards, Didier. Le 14/10/11 16:39, Ludovic Marcotte a écrit : On 14/10/11 10:20, Didier Belhomme wrote: I'm also experiencing slow LDAP query, but in my case it seems to be related to a specific configuration of 389-DS (aka Fedora Directory Server, aka RedHat Directory Server). In our case, the test ldap server is running well (although it's a small virtual machine) whereas ou production server (running on a much more healthier system with 16 GB RAM) is a dog, taking sometimes 10 times more times to answer the same query :-/ (and yes, the data are the same). Did anyone experienced problems with the very latest version of 389-DS (ie 389-ds-1.2.1-1.el5) on RedHat EL 5 (64bit) ? Any clue about this will be very appreciated... You have to make sure some attributes queried by SOGo are well indexed, like: givenName cn mail sn Your problem is only related to proper LDAP indexing. Regards, -- Didier Belhomme FUNDP - SIU Gestionnaire Systemes Unix/GNU/Linux E-mail: didier.belho...@fundp.ac.be Tel : +32 81 72 50 25 Fax : +32 81 72 50 23 -- users@sogo.nu https://inverse.ca/sogo/lists
Re: [SOGo] LDAP Odditiy
Thanks, After adding it 'default reads' shows filter = "(userClass=''AE'' OR userClass=''AS'')"; Is that correct??? -Ron On 10/14/11 11:16 AM, "Ludovic Marcotte" wrote: >On 14/10/11 11:12, Ronald Yacketta wrote: >> On a separate LDAP topic, what is the proper filter syntax? We need to >> limit results using (|(userClass=AE)(userClass=AS)) >> I have tried several combinations of that but each attempt leaves SOGo >> unusable (users can not login). >> >filter = "(userClass='AE' OR userClass='AS')"; > >-- >Ludovic Marcotte >lmarco...@inverse.ca :: +1.514.755.3630 :: www.inverse.ca >Inverse inc. :: Leaders behind SOGo (www.sogo.nu) and PacketFence >(www.packetfence.org) > >-- >users@sogo.nu >https://inverse.ca/sogo/lists -- users@sogo.nu https://inverse.ca/sogo/lists
Re: [SOGo] LDAP Odditiy
On 14/10/11 11:12, Ronald Yacketta wrote: On a separate LDAP topic, what is the proper filter syntax? We need to limit results using (|(userClass=AE)(userClass=AS)) I have tried several combinations of that but each attempt leaves SOGo unusable (users can not login). filter = "(userClass='AE' OR userClass='AS')"; -- Ludovic Marcotte lmarco...@inverse.ca :: +1.514.755.3630 :: www.inverse.ca Inverse inc. :: Leaders behind SOGo (www.sogo.nu) and PacketFence (www.packetfence.org) -- users@sogo.nu https://inverse.ca/sogo/lists
Re: [SOGo] LDAP Odditiy
Ludovic, After spending some time in wireshark and looking at logs our LDAP guy had to index the following attrs in order to fix the slow queries: cn, sn, mail, telephoneNumber, givenName and displayName Again, once those attrs were properly indexed then and only then did LDAP queries return in expected time frames. On a separate LDAP topic, what is the proper filter syntax? We need to limit results using (|(userClass=AE)(userClass=AS)) I have tried several combinations of that but each attempt leaves SOGo unusable (users can not login). (userClass=AE) AND (userClass=AS) (userClass='AE') AND (userClass='AS') ((userClass=AE) AND (userClass=AS)) ((userClass='AE') AND (userClass='AS') (userClass=AE AND userClass=AS) (userClass='AE' AND userClass='AS') ((userClass=AE AND userClass=AS)) ((userClass='AE' AND userClass='AS')) What would the proper syntax be? Regards, Ron On 10/14/11 10:39 AM, "Ludovic Marcotte" wrote: >On 14/10/11 10:20, Didier Belhomme wrote: >> I'm also experiencing slow LDAP query, but in my case it seems to be >> related to a specific configuration of 389-DS (aka Fedora Directory >> Server, aka RedHat Directory Server). >> >> In our case, the test ldap server is running well (although it's a >> small virtual machine) whereas ou production server (running on a much >> more healthier system with 16 GB RAM) is a dog, taking sometimes 10 >> times more times to answer the same query :-/ (and yes, the data are >> the same). >> >> Did anyone experienced problems with the very latest version of 389-DS >> (ie 389-ds-1.2.1-1.el5) on RedHat EL 5 (64bit) ? Any clue about this >> will be very appreciated... >You have to make sure some attributes queried by SOGo are well indexed, >like: > >givenName >cn >mail >sn > >Your problem is only related to proper LDAP indexing. > >Regards, > >-- >Ludovic Marcotte >lmarco...@inverse.ca :: +1.514.755.3630 :: www.inverse.ca >Inverse inc. :: Leaders behind SOGo (www.sogo.nu) and PacketFence >(www.packetfence.org) > >-- >users@sogo.nu >https://inverse.ca/sogo/lists -- users@sogo.nu https://inverse.ca/sogo/lists
Re: [SOGo] LDAP Odditiy
On 14/10/11 10:20, Didier Belhomme wrote: I'm also experiencing slow LDAP query, but in my case it seems to be related to a specific configuration of 389-DS (aka Fedora Directory Server, aka RedHat Directory Server). In our case, the test ldap server is running well (although it's a small virtual machine) whereas ou production server (running on a much more healthier system with 16 GB RAM) is a dog, taking sometimes 10 times more times to answer the same query :-/ (and yes, the data are the same). Did anyone experienced problems with the very latest version of 389-DS (ie 389-ds-1.2.1-1.el5) on RedHat EL 5 (64bit) ? Any clue about this will be very appreciated... You have to make sure some attributes queried by SOGo are well indexed, like: givenName cn mail sn Your problem is only related to proper LDAP indexing. Regards, -- Ludovic Marcotte lmarco...@inverse.ca :: +1.514.755.3630 :: www.inverse.ca Inverse inc. :: Leaders behind SOGo (www.sogo.nu) and PacketFence (www.packetfence.org) -- users@sogo.nu https://inverse.ca/sogo/lists
Re: [SOGo] LDAP Odditiy
Regards everyone,
I'm also experiencing slow LDAP query, but in my case it seems to be
related to a specific configuration of 389-DS (aka Fedora Directory
Server, aka RedHat Directory Server).
In our case, the test ldap server is running well (although it's a small
virtual machine) whereas ou production server (running on a much more
healthier system with 16 GB RAM) is a dog, taking sometimes 10 times
more times to answer the same query :-/ (and yes, the data are the same).
Did anyone experienced problems with the very latest version of 389-DS
(ie 389-ds-1.2.1-1.el5) on RedHat EL 5 (64bit) ? Any clue about this
will be very appreciated...
Regards,
Didier.
Le 14/10/11 15:18, Ronald Yacketta a écrit :
Fellow SOGo users & Dev:
We are seeing a lot of LDAP queries from SOGo using a filter of
"(|(uid=OPTIONS)(mail=OPTIONS))", obviously this will not return
anything. Also notice that user searches (when inviting to a meeting or
address book search) take an extremely long time, trying to track down
this huge delay (some times 15+ seconds).
This is the query that hammers our LDAP server; In a 2 minute span I
can't even begin count how many times it happens.. its insane with just
4 users using SOGo, can't imagine what would happen when we open the
flood gates to 4k+ end users.
SRCH base="ou=people,o=potsdam.edu" scope=2
filter="(|(uid=OPTIONS)(mail=OPTIONS))"
attrs="objectClass cn uid mail ou title company o displayName
modifyTimestamp
mozillaHomeState mozillaHomeUrl homeUrl st region mozillaCustom2 custom2
mozillaHomeCountryName description notes department departmentNumber ou
orgunit mobile
cellphone carphone mozillaCustom1 custom1 mozillaNickname mozillaNickname
mozillaWorkUrl workurl facsimileTelephoneNumber facsimileTelephoneNumber
telephoneNumber mozillaHomeStreet mozillaSecondEmail mozillaSecondEmail
mozillaCustom4
custom4 nsAIMid nsAIMid street street postOfficeBox homePhone cn cn
givenName
mozillaHomePostalCode mozillaHomeLocalityName mozillaWorkStreet2
mozillaUseHtmlMail
mozillaUseHtmlMail mozillaHomeStreet2 postalCode zip c c pager
pagerphone mail sn sn
mozillaCustom3 custom3 l l birthyear serialNumber calFBURL
proxyaddresses mailHost"
We have also been trying to track down the initial LDAP login query as
well as the actual query used where searching LDAP for user invitees,
any one know?
Here is our LDAP config for SOGo
sogod SOGoUserSources '(
{
CNFieldName = cn;
IDFieldName = uid;
IMAPHostFieldName = mailHost;
ModulesConstraints = {
Mail = {
ou = People;
};
};
UIDFieldName = uid;
baseDN = "ou=People,o=potsdam.edu";
bindAsCurrentUser = YES;
bindFields = (
uid
);
canAuthenticate = YES;
displayName = "SPOT Users";
hostname = LDAP-SRVR;
id = public;
isAddressBook = YES;
port = 389;
},
{
CNFieldName = cn;
IDFieldName = uid;
KindFieldName = Kind;
MultipleBookingsFieldName = Multiplebookings;
UIDFieldName = uid;
baseDN = "ou=Resources,o=potsdam.edu";
bindDN = "cn=***";
bindPassword = "***";
canAuthenticate = YES;
displayName = "SPOT Resources";
hostname = LDAP-SRVR;
id = resources;
isAddressBook = YES;
port = 389;
},
{
CNFieldName = ou;
IDFieldName = ou;
UIDFieldName = ou;
baseDN = "ou=Departments,o=potsdam.edu";
bindDN = "cn=***";
bindPassword = "***";
canAuthenticate = YES;
displayName = "SPOT Departments";
hostname = LDAP-SRVR;
id = departments;
isAddressBook = YES;
port = 389;
}
)'
sogod LDAPDebugEnabled YES – Seems useless, not getting anything out of
SOGo for LDAP
Regards,
Ron
--
Didier Belhomme
FUNDP - SIU
Gestionnaire Systemes Unix/GNU/Linux
E-mail: didier.belho...@fundp.ac.be
Tel : +32 81 72 50 25
Fax : +32 81 72 50 23
--
users@sogo.nu
https://inverse.ca/sogo/lists
[SOGo] LDAP Odditiy
Fellow SOGo users & Dev:
We are seeing a lot of LDAP queries from SOGo using a filter of
"(|(uid=OPTIONS)(mail=OPTIONS))", obviously this will not return anything.
Also notice that user searches (when inviting to a meeting or address book
search) take an extremely long time, trying to track down this huge delay
(some times 15+ seconds).
This is the query that hammers our LDAP server; In a 2 minute span I can't
even begin count how many times it happens.. its insane with just 4 users
using SOGo, can't imagine what would happen when we open the flood gates to
4k+ end users.
SRCH base="ou=people,o=potsdam.edu" scope=2
filter="(|(uid=OPTIONS)(mail=OPTIONS))"
attrs="objectClass cn uid mail ou title company o displayName
modifyTimestamp
mozillaHomeState mozillaHomeUrl homeUrl st region mozillaCustom2 custom2
mozillaHomeCountryName description notes department departmentNumber ou
orgunit mobile
cellphone carphone mozillaCustom1 custom1 mozillaNickname mozillaNickname
mozillaWorkUrl workurl facsimileTelephoneNumber facsimileTelephoneNumber
telephoneNumber mozillaHomeStreet mozillaSecondEmail mozillaSecondEmail
mozillaCustom4
custom4 nsAIMid nsAIMid street street postOfficeBox homePhone cn cn
givenName
mozillaHomePostalCode mozillaHomeLocalityName mozillaWorkStreet2
mozillaUseHtmlMail
mozillaUseHtmlMail mozillaHomeStreet2 postalCode zip c c pager pagerphone
mail sn sn
mozillaCustom3 custom3 l l birthyear serialNumber calFBURL proxyaddresses
mailHost"
We have also been trying to track down the initial LDAP login query as well
as the actual query used where searching LDAP for user invitees, any one
know?
Here is our LDAP config for SOGo
sogod SOGoUserSources '(
{
CNFieldName = cn;
IDFieldName = uid;
IMAPHostFieldName = mailHost;
ModulesConstraints = {
Mail = {
ou = People;
};
};
UIDFieldName = uid;
baseDN = "ou=People,o=potsdam.edu";
bindAsCurrentUser = YES;
bindFields = (
uid
);
canAuthenticate = YES;
displayName = "SPOT Users";
hostname = LDAP-SRVR;
id = public;
isAddressBook = YES;
port = 389;
},
{
CNFieldName = cn;
IDFieldName = uid;
KindFieldName = Kind;
MultipleBookingsFieldName = Multiplebookings;
UIDFieldName = uid;
baseDN = "ou=Resources,o=potsdam.edu";
bindDN = "cn=***";
bindPassword = "***";
canAuthenticate = YES;
displayName = "SPOT Resources";
hostname = LDAP-SRVR;
id = resources;
isAddressBook = YES;
port = 389;
},
{
CNFieldName = ou;
IDFieldName = ou;
UIDFieldName = ou;
baseDN = "ou=Departments,o=potsdam.edu";
bindDN = "cn=***";
bindPassword = "***";
canAuthenticate = YES;
displayName = "SPOT Departments";
hostname = LDAP-SRVR;
id = departments;
isAddressBook = YES;
port = 389;
}
)'
sogod LDAPDebugEnabled YES Seems useless, not getting anything out of SOGo
for LDAP
Regards,
Ron
--
users@sogo.nu
https://inverse.ca/sogo/lists
