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.