2:28 p.m.
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:
dn: olcOverlay={0}syncprov,olcDatabase={0}config,cn=config
objectClass: olcOverlayConfig
objectClass: olcSyncProvConfig
olcOverlay: {0}syncprov
structuralObjectClass: olcSyncProvConfig
entryUUID: 600b89e6-9317-102e-9872-8714c398f98b
creatorsName: cn=admin,cn=config
createTimestamp: 20100111160900Z
entryCSN: 20100111160900.858973Z#000000#000#000000
modifiersName: cn=admin,cn=config
modifyTimestamp: 20100111160900Z
dn: olcOverlay={1}syncprov,olcDatabase={0}config,cn=config
objectClass: olcOverlayConfig
objectClass: olcSyncProvConfig
olcOverlay: {1}syncprov
olcSpCheckpoint: 20 10
structuralObjectClass: olcSyncProvConfig
entryUUID: 600ba142-9317-102e-9873-8714c398f98b
creatorsName: cn=admin,cn=config
createTimestamp: 20100111160900Z
entryCSN: 20100111160900.859584Z#000000#000#000000
modifiersName: cn=admin,cn=config
modifyTimestamp: 20100111160900Z
dn: olcOverlay={2}syncprov,olcDatabase={0}config,cn=config
objectClass: olcOverlayConfig
objectClass: olcSyncProvConfig
olcOverlay: {2}syncprov
olcSpSessionlog: 500
structuralObjectClass: olcSyncProvConfig
entryUUID: 600badea-9317-102e-9874-8714c398f98b
creatorsName: cn=admin,cn=config
createTimestamp: 20100111160900Z
entryCSN: 20100111160900.859909Z#000000#000#000000
modifiersName: cn=admin,cn=config
modifyTimestamp: 20100111160900Z
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?
2. About N-Way replication... What's the best authentication to use? Because
RootDN is the admin, and in simple authentication I would store cleartext
password in the syncrepl configuration, I'm assuming that the best here
would be to use some SASL mech?
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...
--
Best regards,
Radosław Antoniuk
2:09 p.m.
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:
dn: olcOverlay={0}syncprov,olcDatabase={0}config,cn=config
objectClass: olcOverlayConfig
objectClass: olcSyncProvConfig
olcOverlay: {0}syncprov
structuralObjectClass: olcSyncProvConfig
entryUUID: 600b89e6-9317-102e-9872-8714c398f98b
creatorsName: cn=admin,cn=config
createTimestamp: 20100111160900Z
entryCSN: 20100111160900.858973Z#000000#000#000000
modifiersName: cn=admin,cn=config
modifyTimestamp: 20100111160900Z
dn: olcOverlay={1}syncprov,olcDatabase={0}config,cn=config
objectClass: olcOverlayConfig
objectClass: olcSyncProvConfig
olcOverlay: {1}syncprov
olcSpCheckpoint: 20 10
structuralObjectClass: olcSyncProvConfig
entryUUID: 600ba142-9317-102e-9873-8714c398f98b
creatorsName: cn=admin,cn=config
createTimestamp: 20100111160900Z
entryCSN: 20100111160900.859584Z#000000#000#000000
modifiersName: cn=admin,cn=config
modifyTimestamp: 20100111160900Z
dn: olcOverlay={2}syncprov,olcDatabase={0}config,cn=config
objectClass: olcOverlayConfig
objectClass: olcSyncProvConfig
olcOverlay: {2}syncprov
olcSpSessionlog: 500
structuralObjectClass: olcSyncProvConfig
entryUUID: 600badea-9317-102e-9874-8714c398f98b
creatorsName: cn=admin,cn=config
createTimestamp: 20100111160900Z
entryCSN: 20100111160900.859909Z#000000#000#000000
modifiersName: cn=admin,cn=config
modifyTimestamp: 20100111160900Z
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?
2. About N-Way replication... What's the best authentication to use? Because
RootDN is the admin, and in simple authentication I would store cleartext
password in the syncrepl configuration, I'm assuming that the best here
would be to use some SASL mech?
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...
--
Best regards,
Radosław Antoniuk
5:01 p.m.
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.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
11:44 p.m.
On Fri, Jan 15, 2010 at 2:01 AM, Howard Chu <hyc(a)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 :)
--
Best regards,
Radosław Antoniuk
12:22 a.m.
On Fri, Jan 15, 2010 at 08:44:47AM +0100, Radosław Antoniuk wrote:
On Fri, Jan 15, 2010 at 2:01 AM, Howard Chu <hyc(a)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.
I have been able to delete (I had the same problem as you). but i used
the rootdn of the config db
> > Is this ok to leave it as is? or any workaround to get rid
of the
> unwanted ones?
[snip]
> > 3. Assuming a running normal replication(master-slave)
with
> refreshAndPersist,
> > is there any method of checking of the status of the replication? like
I believe you can look at the CSN cookie - not sure how though
2:52 a.m.
> > > 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
5:58 a.m.
Radosław Antoniuk wrote:
On Fri, Jan 15, 2010 at 2:01 AM, Howard Chu <hyc(a)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.
--
Prentice
1:37 p.m.
Prentice Bisbal wrote:
Radosław Antoniuk wrote:
> On Fri, Jan 15, 2010 at 2:01 AM, Howard Chu <hyc(a)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/
4:40 p.m.
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.
In fact, if you stated this this thing, you have *clearly no idea* how
replication (as a term) should work.
So, again, I don't care if you write the code, and if you want to help or
not. If you don't want to help, just don't write.
*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.
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).
Are you an engineer geek in the cellar? Stay there. Sorry, real world of
*clearly* undocumented things.
Irritated night wishes.
Regards,
Radoslaw Antoniuk
4:58 p.m.
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.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
5:25 p.m.
--On Saturday, January 16, 2010 01:40:30 AM +0100 Radosław Antoniuk
<radek.antoniuk(a)gmail.com> wrote:
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).
Well, we clearly have decended to questioning other's motives. Once a
discussion gets to that point it is fairly useless continue to talk. I
am reminded of a passage from William Faulkner's "Light in August".
"Man knows so little about his fellows. In his eyes all men or women
act upon what he believes would motivate him if he were mad enough
to do what that other man or woman is doing."
Bill
--
Bill MacAllister, System Software Programmer
Unix Systems Group, Stanford University
2:07 a.m.
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
12:37 a.m.
Am Montag 18 Januar 2010 11:07:50 schrieb Radosław Antoniuk:
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 wouldn't recommend doing that. But
you might try to remove the
corresponding "olcOverlay{[1-3]}=syncprov" files and see what happens.
YMMV. Starting over otoh shouldn't be too hard normally. Just slapcat you
configuration, cleanup and slapadd it again. Same for the "real"
(bdb/hdb) databases.
I presume that something stays in the bdb/hdb or this is just the
place of the status counter/pointer?
For the syncprov overlay at least the
contextCsn Attribute is stored in
the underlying database backend.
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?
I don't know a valid usecase
for multiple instances of the syncprov
overlay on one databases. But AFAIK for some other overlays is is
perfectly fine. IIRC the "memberof" Overlay is one of them.
You might want to file an enhancement request that "syncprov" shouldn't
be allowed to be configured multiple times for a single database.
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?
One reason is, that it
is pretty hard to cleanup correctly the remaining
of an overlay during runtime. For some overlays it might not be possible
with reasonalbe effort at all. There is however experimental delete
support for databases and overlays in HEAD you might want to test that.
--
Ralf
2:09 a.m.
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!
--
Best regards,
Radek Antoniuk
On Tue, Jan 19, 2010 at 9:37 AM, Ralf Haferkamp <rhafer(a)suse.de> wrote:
Am Montag 18 Januar 2010 11:07:50 schrieb Radosław Antoniuk:
> 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 wouldn't recommend doing that. But you might try to remove the
corresponding "olcOverlay{[1-3]}=syncprov" files and see what happens.
YMMV. Starting over otoh shouldn't be too hard normally. Just slapcat you
configuration, cleanup and slapadd it again. Same for the "real"
(bdb/hdb) databases.
> I presume that something stays in the bdb/hdb or this is just the
> place of the status counter/pointer?
For the syncprov overlay at least the contextCsn Attribute is stored in
the underlying database backend.
> 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?
I don't know a valid usecase for multiple instances of the syncprov
overlay on one databases. But AFAIK for some other overlays is is
perfectly fine. IIRC the "memberof" Overlay is one of them.
You might want to file an enhancement request that "syncprov" shouldn't
be allowed to be configured multiple times for a single database.
> 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?
One reason is, that it is pretty hard to cleanup correctly the remaining
of an overlay during runtime. For some overlays it might not be possible
with reasonalbe effort at all. There is however experimental delete
support for databases and overlays in HEAD you might want to test that.
--
Ralf
4888
days inactive
4894
days old
openldap-technical@openldap.org
13 comments
6 participants
participants (6)
-
Alex Samad -
Bill MacAllister -
Howard Chu -
Prentice Bisbal -
Radosław Antoniuk -
Ralf Haferkamp