Re: AW: replication questions

["Daniel Tiefnig" <openldap@qmail.infonova.at@infonova.at>]

Dan Shriver wrote:

> I have some questions regarding what you said (and where I'm
> currently at with replication)
>
>
>>> I am confused about several points:
>>>
>>> -updatedn should be different from rootdn (right?) but if so
>>
> how
>
>>> do I specify a password for it (updatepw in the slaves
>>> slapd.conf causes an error when I try to start it up).
>>> Right now I've been using the rootdn (which for simplicity

>>> is the same on slave and master...)
>>
>> you'll have to store the updatedn entry in both master and
>> slave db. specify
>> 'userpassword' attribute to authenticate.

> I'm confused about this.  Am I adding a user object to the DB?
> Do you have an example of doing this (I am a newcomer to LDAP).

hmm:) just add your basic entries before you configure replication. so..
add your basedn and replicator entry. the replicator may look something
like:
  dn: cn=replicator,dc=SharemediaTest,dc=com
  objectclass: person
  sn: replicator
  cn: replicator
  userpassword: {crypt}foo

note: this isn't a must. you can use whatever objectclass you want. it
just has to allow/require the userpassword attribute. and the foo should
be replaced by a crypted 'secret' concerning your slapd.conf.

after you've added this one to both master and slave, set 'em up fpr
replication. (i know, this is all a bit <..> but at the moment i don't
know a better way. but.. at least you might also add these initial
entries offline with slapadd, so you don't have to reconfigure your
servers if you want to rebuild the db..)

in your slapd.conf, specify the replica entry _after_ the database ldbm
line. (it belongs there, might be slurpd doesn't complain, maybe because
it just supports one single replication at all.. (per slurpd process))


>> hmm, are not sure about ldapmodify, but i think, you'll have
>
> to check the
>
>> server's response, and relaunch ldapmodify with the correct
>
> host flag.
>
> -C -> chase is supposed to (I think) work but instead I get some
> confusing results.  I do the ldapmodifies on the slave and if
> the entry is in the master I get "Already exists" (note it
> doesn't exist on the slave) see below.  If the entry isn't on
> the master I get "Insufficient access".

insufficient access.. due to anonymous rebind..? and, of course, you'll
get an 'already exists' if the entry is present in the master db.
replication is an, uhm, quite 'silly' process. it doesn't check
consistence of the databases. i.e. the master doesn't know the status of
the slave at all..
basically, keep care of the status of your databases.. they should
_always_ contain the same entries.. (allthought it doesn't hurt, unless
you try to do something like you described above..)

daniel
_________________________________________
Tiefnig Daniel
Server-Technology

INFONOVA IT GesmbH
Seering 6, A-8141 Unterpremstätten
AUSTRIA

E-Mail: mailto:daniel.tiefnig@infonova.at
Web: http://www.infonova.at