Re: Some openldap 2.4 questions

[Howard Chu <hyc@symas.com>]

Prentice Bisbal wrote:
> Radosław Antoniuk wrote:
>> On Fri, Jan 15, 2010 at 2:01 AM, Howard Chu <hyc@symas.com
>> <mailto:hyc@symas.com>> wrote:
>>
>>     Radosław Antoniuk wrote:
>>     > Hi,
>>     >
>>     > Three quick issues about slapd 2.4.
>>     >
>>     > 1. I'm setting up a syncrepl replication. In the process of
>>     testing, I had
>>     > added three syncprov overlays instead of one, and I ended up with:
>>
>>     > The thing is, that I cannot delete any of them because cn=config
>>     does not
>>     > support delete operation.
>>     > Is this ok to leave it as is? or any workaround to get rid of the
>>     unwanted ones?
>>
>>     Since it's just a test installation, your best action is to delete
>>     it all and
>>     start over with the correct LDIF.
>>
>>     > 2. About N-Way replication... What's the best authentication to
>>     use? Because
>>     > (1) RootDN is the admin, and (2) in simple authentication I would
>>     store cleartext
>>     > password in the syncrepl configuration, I'm assuming that (3) the
>>     best here would
>>     > be to use some SASL mech?
>>
>>     What do any of these 3 points have to do with each other, let alone
>>     with N-way
>>     replication?
>>
>>     > 3. Assuming a running normal replication(master-slave) with
>>     refreshAndPersist,
>>     > is there any method of checking of the status of the replication?
>>     like show
>>     > slave status in MySQL. I have tested it with cutting the
>>     transmission by
>>     > iptables, and ok, it caught up after reconnection, but the master
>>     did not
>>     > complain at all when the connection was not there...
>>
>>     If you had read the docs
>>     http://www.openldap.org/doc/admin24/replication.html
>>     you wouldn't need to ask such questions.
>>
>>
>> Hello,
>>
>> None of the answers was valid actually.
>> If I could start all over, I wouldn't ask, right?
>>
>> What it has to do ? It has to do the fact that in this kind of
>> replication you are replicating cn=config as well, which usually in
>> other kinds is not the case.
>>
>> And yes, I read the link you mentioned, hint: the word "status" shows up
>> there three times in one sentence that does *not* mention anything about
>> external checking of LDAP replication status.
>>
>> Ergo, if you don't want to help, don't frustrate the asker :)
> 
> I agree. Howard's response was an unwarranted RTFM. If you don't want to
> help another subscriber on this list, please don't reply. Helpless
> replies are not constructive.

Generally, as the person asking a question, you're in no position to judge the
value of the replies. As the person who wrote the code, I know definitively
what is relevant and what is not.

And in general, people who don't know what they're doing ask the wrong
questions, and provide the wrong information as context for their question.
People who try to answer the questions as-stated merely waste everyone's time.
Such is the case here.

1) The poster clearly should not have been *testing* on a valuable server.
Answering their direct question has no value because it doesn't teach the more
important lesson: never experiment on production servers. Without learning
that lesson, they will simply continue to make the same type of mistakes and
continue to waste everyone's time.

2) The question simply makes no sense, because none of the mentioned points
bear any relation to each other. Without reframing the question there's no way
to answer it.

3) As plainly documented, in syncrepl all of the configuration and important
state is consumer-side; the provider doesn't keep track of anything about any
consumers. This is why syncrepl is flexible enough to allow consumers to be
added arbitrarily without needing to reconfig/restart or otherwise disturb the
provider. It's also the only way to have really scalable replication. Since
the provider has no knowledge of individual consumers, *of course* the
provider doesn't complain when a consumer goes down. This fact is self-evident
if you actually read the docs.

-- 
  -- Howard Chu
  CTO, Symas Corp.           http://www.symas.com
  Director, Highland Sun     http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/