[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.


Kind Regards,

Gavin Henry.
OpenLDAP Engineering Team.

E ghenry@OpenLDAP.org

Community developed LDAP software.