[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: quick question about a slave openldap server

bulk@alfredsson.org writes:

On Tue, Apr 02, 2002 at 09:59:48AM +0200, Turbo Fredriksson wrote:
>>>>> "Andreas" == Andreas Hasenack <andreas@conectiva.com.br> writes:
Andreas> Em Wed, Mar 27, 2002 at 01:42:07PM +0100, Turbo
Andreas> Fredriksson escreveu:
>> If you have the slave read-only, NO modification is possible,
>> only the replication daemon can write to it...

Andreas> I couldn't reproduce this, I set readonly to yes and the
Andreas> updatedn couldn't write to it anymore... This with
Andreas> openldap-2.0.22.

Then the bug isn't fixed (YET!?!?)

Is it a bug? I thought the readonly option made slapd open the database
files readonly (e.g. fopen("/var/lib/ldap/...", "r"); )

One use for this could be when making backups; i.e. restart slapd in
readonly mode, and then copy the database files or via slapcat,
which is not recommended on a readwrite installation.

Theoretically I can see the the use of having a readonly-but-updateable
replica, but would not have understood that "readonly on" did this
from the documentation.

----
5.2.3.2. readonly { on | off }

This directive puts the database into "read-only" mode. Any attempts to
modify the database will return an "unwilling to perform" error.
----

"any attempts" would include the replicadn, in my world.

Andreas> Could you confirm this? Setting "readonly yes" on the

maybe "readonly on" works better? 

----- s n i p -----
access to
+attr=cn,givenName,sn,krbName,krb5PrincipalName,loginShell,gecos,mail,mailAltern+ateAddress,mailHost,mailQuota,trustModel,accessTo,uidNumber,gidNumber,homeDirec+tory,homePostalAddress,mobile,labeledURI,homePhone,userPassword,ldapPassword,cl+earTextPassword
        by dn="uid=turbo.+\+realm=BAYOUR.COM" read
        by dn="uid=replicator.+\+realm=BAYOUR.COM" write
        by users read
       by * none

access to *
by dn="uid=turbo.+\+realm=BAYOUR.COM" read
by dn="uid=replicator.+\+realm=BAYOUR.COM" write
by * read
----- s n i p ----- 

I should really remove the last 'by * read' and the 'by users read'
but...

If you did that, would not the first access rule become unneccessary?
I.e. all accesses allowed/denied in rule one would be the same in rule
two... (by * none is implicit?)

Which leads to a quite straightforward ACL :)

Regards,
Stefan


I think nobody should count on "readonly on" to disallow ANY writing
to the database. This is basically meant to inhibit normal usage
writes to the database, while rootdn (and updatedn, but I need to
check and anyway this might be subject to change) can still write
to the database.

Readonly ought to be set on on the MASTER when the replicas are
not working for some reason (e.g. maintenance), so normal writes
that would not be replicated are explicitly refused by the master.
It has nothing to do with the slaves. A slave is by definition
read-only, since it returns a referral to the master for any write
attempt that is not performed by the updatedn. Even the rootdn
of a slave cannot write to it (of course unless it is the same
as the updatedn ...)

Pierangelo.

Dr. Pierangelo Masarati | voice: +39 02 2399 8309
Dip. Ing. Aerospaziale | fax: +39 02 2399 8334
Politecnico di Milano | mailto:pierangelo.masarati@polimi.it
via La Masa 34, 20156 Milano, Italy | http://www.aero.polimi.it/~masarati