[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Can't contact LDAP Server

--On Wednesday, January 30, 2008 11:51 PM +0530 shanmuga priya <mailmeshanmu@gmail.com > wrote: 
Actually we are getting "can't contact ldap server" error while using
ldapsearch command itself!!

Gone through the openldap docs in
http://www.openldap.org/doc/admin24/appendix-common- errors.html#ldap_*:%2
0Can\'t%20contact%20LDAP%20serverand used telnet localhost 389 and got
the out put as "Trying 127.0.0.1...
telnet: Unable to connect to remote host: Connection refused"
and we used the command netstat -an|grep 389 and didn get a output..
how to enable the port no 389?
we tried to open port through iptables..but not able to do that too..we
are doing this in debian etch


On 2008, Jan 30, at 13:44, Quanah Gibson-Mount wrote:
Are you sure slapd is even running?

And for that matter, looking at the URL you first mentioned that you were following, I see some items that raise a few questions:

Section (prefixed with "Jukie" to distinguish from section numbers I use later that point to he official OpenLDAP site):

Jukie2.2 (installing): It does not mention which version (minimum, expected, or anything) it thinks you are installing with those commands. It does note that you should stick with BDB, though.

Jukie2.4.1 (starting): Did the "pidof slapd" output anything?

Jukie2.4.2 (test): It notes that the database should be off-line to slapcat, but that is definitely incorrect with recent ("recent" being on the order of years) versions with the recommended BDB backend. This relates, in part, to the lack of version info listed above.


I see you found the admin guide's appendix on common errors, Quannah's question was also basically step #2 from the checklist in that admin guide:

	<http://www.openldap.org/doc/admin24/troubleshooting.html#Checklist>

The other chapters in that guide would probably be a good read as you experiment as well. In particular, testing the server configs prior to starting and then adding some server logging to make sure it is running and answering properly would probably help. [For the check if the daemon is listening, besides the netstat you mentioned and adding logging, lsof and other OS-level tools would be good to get to know to make sure things are as you expect as well.] Though if nothing is listening on port 389, you are looking at a much more fundamental problem than the firewall...check the server configs/logs first, and/ or start the daemon manually with "-d -1" as mentioned in the troubleshooting guide in step 20.7.


-philip