1:53 p.m.
There are (at least as far as I know) no other way than slapcat/slapadd
to get rid of any incorrect contextCSN values, at least on servers where
syncprov is enabled. I have been down that road some times already,
each time being equally annoyed by the fact that there are no easier way
to fix it..
Removing a contextCSN value is required in order to remove a server from
a multi-master configuration, or to get rid of the values with SID=0
that is far to easy to slip in if slapd or slapadd is started without
the proper serverID setting.
The slapd -c option requires a rid=XXX to be specified, but also allows
sid=XXX (which I haven't quite understood the usefulness of..). I
suggest that the -c option is extended to also allow only sid=XXX
without any rid.
With only sid=XXX,csn=XXX specified both syncrepl and syncprov should
replace the contextCSN value with that sid (as read from the database
upon startup) with the specified csn. Obviously, only a single csn
value can be accepted, and an absent or zero csn value should mean to
delete the contextCSN value with that sid. Well, deleting a contextCSN
value is really all I need, so I would be I more than happy to leave the
replace possibility out...
Adding an easy way to get rid of invalid contextCSN values should make a
transition to enforcing serverID 0 for single-master only configs much
more acceptable for those that have used serverID 0 in multi-master setups.
Comments?
Rein
2:17 p.m.
Rein Tollevik wrote:
There are (at least as far as I know) no other way than
slapcat/slapadd
to get rid of any incorrect contextCSN values, at least on servers where
syncprov is enabled. I have been down that road some times already,
each time being equally annoyed by the fact that there are no easier way
to fix it..
I would expect ldapmodify with relax/manage control to work as well.
Removing a contextCSN value is required in order to remove a server
from
a multi-master configuration, or to get rid of the values with SID=0
that is far to easy to slip in if slapd or slapadd is started without
the proper serverID setting.
The slapd -c option requires a rid=XXX to be specified, but also allows
sid=XXX (which I haven't quite understood the usefulness of..). I
suggest that the -c option is extended to also allow only sid=XXX
without any rid.
No. The rid=xxx is required; that's the only key that associates anything with
a particular syncrepl instance.
With only sid=XXX,csn=XXX specified both syncrepl and syncprov
should
replace the contextCSN value with that sid (as read from the database
upon startup) with the specified csn. Obviously, only a single csn
Which "the contextcsn" are you referring to? Without the rid, we don't have
any idea which database is relevant.
value can be accepted, and an absent or zero csn value should mean
to
delete the contextCSN value with that sid. Well, deleting a contextCSN
value is really all I need, so I would be I more than happy to leave the
replace possibility out...
Adding an easy way to get rid of invalid contextCSN values should
make a
transition to enforcing serverID 0 for single-master only configs much
more acceptable for those that have used serverID 0 in multi-master setups.
Comments?
Just use ldapmodify.
Chasing down the -c function isn't useful anyway since it requires a server
restart. If ldapmodify currently doesn't give you what you want, then that
should be fixed.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
3:11 p.m.
Howard Chu wrote:
Rein Tollevik wrote:
> There are (at least as far as I know) no other way than slapcat/slapadd
> to get rid of any incorrect contextCSN values, at least on servers where
> syncprov is enabled. I have been down that road some times already,
> each time being equally annoyed by the fact that there are no easier way
> to fix it..
I would expect ldapmodify with relax/manage control to work as well.
Neither the -M nor -e relax options work, nor both. All I get is a
"no-user-modification attribute not manageable" error. And if it had
succeeded I'm very uncertain as to what effect it would have on a
running server.
> Removing a contextCSN value is required in order to remove a
server from
> a multi-master configuration, or to get rid of the values with SID=0
> that is far to easy to slip in if slapd or slapadd is started without
> the proper serverID setting.
>
> The slapd -c option requires a rid=XXX to be specified, but also allows
> sid=XXX (which I haven't quite understood the usefulness of..). I
> suggest that the -c option is extended to also allow only sid=XXX
> without any rid.
No. The rid=xxx is required; that's the only key that associates
anything with a particular syncrepl instance.
My idea was to not associate it with any particular syncrepl instance. I
want to target csn values with the specified sid in all database,
leaving csns with other sids unchanged.
> With only sid=XXX,csn=XXX specified both syncrepl and syncprov
should
> replace the contextCSN value with that sid (as read from the database
> upon startup) with the specified csn. Obviously, only a single csn
Which "the contextcsn" are you referring to? Without the rid, we don't
have any idea which database is relevant.
All contextCSN values with the given sid stored in all of the syncrepl
and syncprov enabled databases. I.e, it will modify and/or delete one
contextCSN value (those with the specified sid) in many databases, while
the rid=xxx can modify many values in one syncrepl database.
> value can be accepted, and an absent or zero csn value should
mean to
> delete the contextCSN value with that sid. Well, deleting a contextCSN
> value is really all I need, so I would be I more than happy to leave the
> replace possibility out...
> Adding an easy way to get rid of invalid contextCSN values should make a
> transition to enforcing serverID 0 for single-master only configs much
> more acceptable for those that have used serverID 0 in multi-master
> setups.
Just use ldapmodify.
Chasing down the -c function isn't useful anyway since it requires a
server restart. If ldapmodify currently doesn't give you what you want,
then that should be fixed.
The main problem comes if serverID 0 is enforced for single-master
configurations, and slapd refuses to start if it finds invalid csn
values. Then I would be stuck with no server to run ldapmodify against..
The server restart doesn't bother me, as this is primarly indented to
easy the software upgrade to a newer version that enforces serverID 0
for single-master configurations. And that requires a server restart
anyhow..
Nor does it bother med if anyone that have run slapadd (and hopefully
stopped slapd first) have to restart slapd to fix the contextCSN with
sid=0 that is far to ease to slip in.
Rein
3:16 p.m.
Rein Tollevik wrote:
All contextCSN values with the given sid stored in all of the
syncrepl
and syncprov enabled databases. I.e, it will modify and/or delete one
contextCSN value (those with the specified sid) in many databases, while
the rid=xxx can modify many values in one syncrepl database.
The -c option only overrides the in-memory copy; it performs no database
operations on its own. It causes the database copy to be overwritten as a
result of subsequent refresh operations.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
3:28 p.m.
Howard Chu wrote:
Rein Tollevik wrote:
> All contextCSN values with the given sid stored in all of the syncrepl
> and syncprov enabled databases. I.e, it will modify and/or delete one
> contextCSN value (those with the specified sid) in many databases, while
> the rid=xxx can modify many values in one syncrepl database.
The -c option only overrides the in-memory copy; it performs no database
operations on its own. It causes the database copy to be overwritten as
a result of subsequent refresh operations.
Which is how I ment -c sid=xxx should work as well. Read inital value
from database, modify it according to -c sid=xxx option, and continue as
if the new set of csns was read from the database.
Rein
5198
days inactive
5198
days old
4 comments
2 participants
participants (2)
-
Howard Chu -
Rein Tollevik