ah yes i've done it now. thought i'd post my results in case any other ldap
newbies have a similar problem. :-)
the problems with my setup stemmed from not setting up a dedicated replication
account with access to the slave database. i had to create a replicator account
and give that full access to the slave, removing the existing acls, ie.
access to *
by dn="uid=replicator,ou=users,dc=my,dc=local" write
by * read
my master server also had a 'syncrepl' entry (which i probably added in a
moment of desperate frustration) and it wasn't needed in this case.
thank you everyone who helped me out!
john
--- On Fri 11/11, John Halfpenny < [EMAIL PROTECTED] > wrote:
From: John Halfpenny [mailto: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: [email protected]
Date: Fri, 11 Nov 2005 04:10:51 -0500 (EST)
Subject: Re: replication security (i)
<br>thanks for replying.<br><br>that makes sense. let me see if i have the
logic right.<br><br>the reason my updates are being processed on the slave is
because i'm not using a specific replication account as my updatedn. i am in
fact using the manager dn, which explains why updates to it are being accepted
when i connect directly to the slave with the manager's
credentials.<br><br>presumably then i need to change my slave acls to allow
only the replication account write access, which will force any update requests
to be handed up to the master.<br><br>if that is right then the reason i
confused the issue was to simply copy the config file from the master to the
slave without setting separate acls on it.<br><br>john<br><br> --- On Thu
11/10, Buchan Milne < [EMAIL PROTECTED] > wrote:<br>From: Buchan Milne [mailto:
[EMAIL PROTECTED]<br>To: [EMAIL PROTECTED]<br> Cc:
[email protected]<br>Date: Thu, 10 Nov 2005 19:03:45
+0200<br>Subject: Re!
:
replication security (i)<br><br>On Thursday 10 November 2005 17:48, John
Halfpenny wrote:<br>> hi quanah.<br>><br>> i've been using the oreilly book on
ldap admin for a bit of guidance on<br>> this, but from what i can make out any
changes i make to the slave stay<br>> there and aren't redirected to the
master... (with readonly turned off that<br>> is)<br><br>If you have an
'updateref' directive for the database on the slave, a <br>non-replicadn client
should get a referral to the value following the <br>directive. Usually, this
should point to your master.<br><br>Whether the client will chase the referral
or not is up to the client.<br><br>But, your slave should not be accepting any
changes not made by the replicadn.<br><br>If you are using the rootdn for the
replicadn, and making changes to the slave <br>from the rootdn, it will accept
them.<br><br>The replicadn should not be used for *anything* but replication,
which is why <br>you should not use the rootdn (which you may
use for something <br>else).<br><br>> is it password related? does it make a
difference which hashed password i<br>> use for the rootdn (ie. can i use the
same SSHA coded password at both ends<br>> or do i have to generate them
separately?)<br><br>Password hash is
irrelevant.<br><br>Regards,<br>Buchan<br><br>-- <br>Buchan Milne<br>ISP Systems
Specialist<br>B.Eng,RHCE(803004789010797),LPIC-2(LPI000074592)<br>Attachment:
Attachment
(0.19KB)<br><br><br>_______________________________________________<br>Join
Excite! - http://www.excite.com<br>The most personalized portal on the Web!<br>
_______________________________________________
Join Excite! - http://www.excite.com
The most personalized portal on the Web!
