On Fri, Jan 15, 2010 at 2:01 AM, Howard Chu 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 :)

...

...

...

The thing is, that I cannot delete any of them because cn=config does

not

...

...

...

support delete operation.

I have been able to delete (I had the same problem as you). but i used the rootdn of the config db

Hi Alex,

Hmm, that's interesting. RooDN of the configdb? you mean 'cn=admin,cn=config' ? If so, I've obviously tried to do it with exactly this DN :) But, as documentation states , cn=config deletion is not supported now (experimental). I'm thinking. Maybe shutting down the daemon and removing it manually from the slapd.d config files is enough? Or will that brake the database?

I did a change of RootDN password like that and it worked, but...

Regards, Radek Antoniuk

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.

Radosław Antoniuk wrote:

*Clearly* the provider SHOULD provide information, if it has pushed all the updates to the slaves. Ok, your excuse is that this is due to the fact, that the provider does not keep track of slaves. Ergo? The slaves are wrongly implemented. And *they* should provide the information if they have the connection and are up2date or not. This is of course totally implementation-dependent (in this case, I'd even risk the statement that it is quite wrongly implemented), when we have *no idea* if the slave copy is up2date or not.

Obviously the consumer knows what its replication status is, but you can only determine whether a consumer is up to date or not when you have simultaneous access to both the consumer and the provider, to compare their status. If you sever the network connection, nothing can be inferred on either side about the other.

Since you haven't bothered to read the design of syncrepl or the motivation behind it, you're in no position to judge the correctness of it.

Answers like those, make me think that open-source is a waste of time comparing to paid solutions (even though I am a strong evangelist of Debian and other open source solutions, which I think the writer does not care about).

The defining characteristic of open source is that the code is openly shared amongst developers and users. There is nothing implied about costs of operating it. If you believe there's a distinction between "paid solutions" and "open source" you're quite mistaken, the two are completely orthogonal. If you have a commercial enterprise, and you have even half a brain, you pay for support for your solutions, whether they are open or closed source.

Hi again guys,

Ok, coming back on the technical track. Nobody replied so I'll ask again.. and few more thoughts actually:

1. Is it okay to stop the daemon, and literally remove the lines from the config files in slapd.d dir? (i.e. actually removing the file in cn=config/olcDatabase={0}config/* ) I presume that something stays in the bdb/hdb or this is just the place of the status counter/pointer? I know that probably it is a dirty hack but actually when I did that for rootDN password it worked..

Or... I'll ask the question again because there was no answer - is it safe to leave it as is and don't bother?

2. What is the sence at all of having more than one overlay of the same type for a backend? shouldn't it be prohibited by the engine? or is there a use case when it actually is needed?

Question out of curiosity, why the backend doesn't support delete? Issues with deletion of the database or a simple reason like "don't delete your database" or something deeper technically?

Thanks.

Best regards, Radoslaw Antoniuk

Hi Ralf,

Thanks for that, after quick discussion with other admins, we've decided just to drop the cn=config configuration and switch the database to file config. Although cn=config gives the nice ability to do the config on the fly, it is still too undocumented and irritating to use... And I did what I want in ten minutes with file config, instead of 3 days :) Anyway, thanks for all answers.

One suggestion is, that it would be great to have a 'config-like' interface for editing cn=config. I mean something like visudo, so an overlay that converts the cn=config to file, displays for editing and then does the forward conversion again when saving.. But this is probably too complicated to implement :)

Thanks guys!