Rich--
As I mentioned on IRC, I got about 90% of the way through the SSL
setup before my deadline hit and I had to go live without SSL fully
working. My machines are all listening on port 636, but don't do SSL
properly. As far as I can tell/remember, I provisioned the boxes
identically, so they
After the update from 1.0.2 to 1.0.3, I had some replication problems,
and it appears that one of my four servers was no longer properly
replicating to the others. I recreated the replication agreements and
reinitialized the replications, but now I'm getting some strange
errors in the error logs
Chris St. Pierre wrote:
After the update from 1.0.2 to 1.0.3, I had some replication problems,
and it appears that one of my four servers was no longer properly
replicating to the others. I recreated the replication agreements and
reinitialized the replications, but now I'm getting some strange
Any thoughts on what logs from FDS would be slurp-able, or if FDS
supports writing that kind of replication log?
Originally the two came from the same code. Netscape Directory Server 1.x
used a replication mechanism that was derived from slurpd (but the slurp
functionality was included in
I notice 2 differences. The BIND is using version 2 when trying to
start the admin server. That shouldn't matter.
The problem seems to be with the BIND'ing. When trying to start the
admin server, the RESULT to the BIND contains an empty dn. When run
manually, the dn is correct.
It
Dan wrote:
I notice 2 differences. The BIND is using version 2 when trying to
start the admin server. That shouldn't matter.
The problem seems to be with the BIND'ing. When trying to start the
admin server, the RESULT to the BIND contains an empty dn. When run
manually, the dn is correct.
On Fri, 3 Nov 2006, Richard Megginson wrote:
The consumer. The supplier thinks the consumer suffix is disabled. It might
be as simple a fix as restarting the consumer.
That changed the error message.
[03/Nov/2006:11:21:24 -0600] NSMMReplicationPlugin -
agmt=cn=Replication to
