Stephen Meatheringham writes:
Having dug around in the Courier installation directories I find
another ldapsearch binary (in the /usr/lib/courier/share/sqwebmail
directory). I can get no response from that program at all.
Well, your first step would be to run this one as follows, and see what
happens:
ldapsearch [server] [port] [base] [search]
server - LDAP server's hostname, port - LDAP port, usually 389.
base - your LDAP root suffix
search - the search string
Ex:
ldapsearch ldap.example.com 389 dc=example,dc=com 'Smith'
Sorry, I may not have been completely clear in my original posting.
I get nothing back from the ldapsearch provided with sqwebmail.
The above syntax is quite different to the usual ldapsearch format which I
Well, that's not your regular ldapsearch command. This is sqwebmail's code,
not OpenLDAP's, and sqwebmail's ldapsearch binary has nothing to do with
OpenLDAP's. It is NOT a general purpose LDAP search tool. If it confuses
you too much, rename sqwebmail's binary from ldapsearch to foobazblat, and
try again.
would expect to give as:
ldapsearch -x -h ldap.example.com -b 'base' '(cn=search)'
Either form gives nothing though.
The ldapsearch in sqwebmail doesn't even print anything out when I try
"--help" on the commandline.
Because it's not supposed to do it. It's supposed to be invoked from
sqwebmail, in response to a web request. As such, it has only a single
purpose in life.
Generally, if the search fails it does not return anything, which is
probably what you're seeing. My guess is that your LDAP search is
configured not to accept anonymous binds as searches. LDAP connection
negotiation is notoriously difficult to debug. I suggest that you turn up
the logging on your LDAP server to the maximum, and run sqwebmail's LDAP
search, and see what happens.
8 messages in net.sourceforge.lists.courier-sqwebmailRe: [sqwebmail] LDAP Address Books in...
