DS 6.0 - Bind through PTA failed
I am deploying DSEE 6.0 in a multimaster topology with 3 servers (call them A, B and C). The platform is Solaris 10 x86 running in the root zone. Through the DSCC running on server A I can create and instance and start it with no problem and all runs fine. Through the DSCC on server A i can create an instance on server B, but under operational status it shows
Warning: [LDAP: error code 1 - Can't connect to the LDAP server]
Server B seems to be running fine, can start and stop from the command line. When i try and restart or 'enable access' from the DSCC on server B i get the following message repeated in the error logs on server B (although it does restart the server):
[20/Jun/2007:21:23:43 -0400] - ERROR<53761> - Plugins - conn=-1 op=-1 msgId=-1 - Connection Bind through PTA failed (91)
Any ideas?
Thanks
[863 byte] By [
mdpiot1a] at [2007-11-27 8:28:05]
# 1
On the instance 2, can you check in the config/dse.ldif the value of the nsslapd-pluginarg0 for the Passthrough Authentication Plugin.
The value should be something like this:
nsslapd-pluginarg0: ldap://hostsname:3998/cn=dscc
Make sure the <hostname> is a valid hostname, fully qualified or not, that can be addressed from server B.
If it isn't, you may want to change the value manually while DS is stopped.
And could you please report here if the value was incorrect, why it was not the correct one. This may help us identify some specific misconfiguration.
Regards,
Ludovic.
# 2
Ludovic,
Thank you for your help, though the problem went away when we configured DNS on the server. I didnt think that would have been a problem with the fqdn specified in the etc/hosts file. Also i had no problem accessing server A from server B. Here is the entries from the dse.ldif.
nsslapd-pluginPath: /opt/SUNWdsee/ds6/lib/uid-plugin.so
nsslapd-pluginInitfunc: NS7bitAttr_Init
nsslapd-pluginType: preoperation
nsslapd-pluginEnabled: off
nsslapd-pluginarg0: uid
nsslapd-pluginarg1: mail
nsslapd-pluginarg2: userpassword
nsslapd-pluginarg3: ,
nsslapd-pluginarg4: dc=dummysuffix
nsslapd-plugin-depends-on-type: database
nsslapd-pluginId: NS7bitAttr
nsslapd-pluginVersion: 6.0
nsslapd-pluginVendor: Sun Microsystems, Inc.
nsslapd-pluginDescription: Enforce 7-bit clean attribute values
Thanks for your help.
# 3
> Ludovic,
>
> Thank you for your help, though the problem went away
> when we configured DNS on the server. I didnt think
> that would have been a problem with the fqdn
> specified in the etc/hosts file. Also i had no
> problem accessing server A from server B. Here is
> the entries from the dse.ldif.
We have also seen DSCC and DS ignore the name service settings in the nsswitch.conf (i.e. ignoring the hosts file and going right to DNS). This is causing a lot of problems, since we are trying to force our DSCC<->DS<->DPS traffic to go on a private network for security, while only exposing the DPS servers to the world. We tried putting the hostnames for everything in /etc/hosts, setting the hostnames to the "internal" IP addresses, but the traffic still goes out the public interfaces for these systems.
The main culprit, it seems to me, is the DSCC components (cacao).
# 4
We are aware of some issues with hostnames and machines will multiple interfaces with DSCC and its sub-components.We will fully address them in future releases of Directory Server. Some of them do require some interface changes (including GUI).Regards,Ludovic.
