[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: Issue in syncprov findcsn code
----- "Pierangelo Masarati" <ando@sys-net.it> wrote:
> Gavin Henry wrote:
>
> > Can I confirm the use case here? I've not used the -S option and it
> sounds
> > very important. According to Ando it should be clearly documented
> too.
> >
> > Is it used in a MM/N-Way when exporting via slapcat and then
> importing to
> > another server that will have its own serverID, hence the -S to
> override the
> > currently exported serverID from the first server?
>
> As far as I know, you don't need it unless you're initializing a
> MM/N-Way from a clean LDIF (i.e. without entryCSN). Usually, when you
>
> restore from a backup, you want existing entryCSN to be preserved. -S
>
> only affects the SID portion of entryCSN *generated* by slapadd, i.e.
>
> those that were missing in the source LDIF. I added that option some
>
> time ago, when I needed to generate a database for a N-Way by
> importing
> an LDIF obtained from SunONE. The procedure then was:
>
> - slapadd -w -S 001 -l plain.ldif
> - slapcat -l full.ldif
> - scp full.ldif other-n-way:
>
> on other-n-way:
>
> - slapadd -l full.ldif
OK, that's perfectly clear.
>
> This way, all N-Way would get the same database with the SID of the
> first one, "001". As an alternative, I could have fired up the first
>
> one and let the others sync.
Yes, the later way is done by most folks except by the ones who have massive
data sets and can't/won't sync online.
Thanks for the clear up.
Gavin.
--
Kind Regards,
Gavin Henry.
OpenLDAP Engineering Team.
E ghenry@OpenLDAP.org
Community developed LDAP software.
http://www.openldap.org/project/