samba - Jun 2004 - [EXPERIENCES] with OpenLDAP and Samba and Redundancy???

I can't say I've tested this in any depth. Where multiple LDAP servers
are listed as the LDAP
backend is the behaviour of Samba that if it fails to contact the first listed
server it will
try the second and so on? If that's the case Samba should only ever try and
update the password
on a single LDAP server which would then replicate the change to any other
master and slave LDAP
servers in the environment. This should work pretty well no? Are my assumptions
on Samba correct?

cheers Andy.

On Wed, 2004-06-30 at 20:19, ww m-pubsyssamba wrote:
> Or you could buy a couple of $/?1000 Sun Sparc servers and use SunONE LDAP
with multi master support???
> Depends if you already have and OpenLDAP environment and don't object
to using Solaris instead of
> Linux... (can still run Samba on whatever platform you want)
Samba doesn't expect a multi-master OpenLDAP backend.  It expects that
when it changes a record, that upon success the record is finally
modified.

It will probably work quite well, but I'm worried about things like
conflicting password changes.

Andrew Bartlett


This e-mail (and any attachments) is confidential and may contain personal views
which are not the views of the BBC unless specifically
stated.
If you have received it in error, please delete it from your system. Do not use,
copy or disclose the information in any way nor act in
reliance on it and notify the sender immediately. Please note that the BBC
monitors e-mails sent or received.
Further communication will signify your consent to this.

On Wed, 2004-06-30 at 21:32, ww m-pubsyssamba wrote:
> I can't say I've tested this in any depth. Where multiple LDAP
servers are listed as the LDAP
> backend is the behaviour of Samba that if it fails to contact the first
listed server it will
> try the second and so on? If that's the case Samba should only ever try
and update the password
> on a single LDAP server which would then replicate the change to any other
master and slave LDAP
> servers in the environment. This should work pretty well no? Are my
assumptions on Samba correct?
My worry is if two independent client update to two independent,
disconnected LDAP peers.  This particularly applies when we are doing an
atomic increment in LDAP, like we do in IDMAP, and like a good 'add user
script' should do.

Andrew Bartlett
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url :
http://lists.samba.org/archive/samba/attachments/20040630/96663f68/attachment.bin

Mmm, you mean if two master replica's are disconnected by a network failure?
Guess this might cause
some problems, but if you simply have a master replica down for the duration of
a password update
as soon as it restarts it should sync up with it's peer?? This should cater
for server redundency but
maybe leaves some issues open with relation to network connectivity...

Andy.

On Wed, 2004-06-30 at 21:32, ww m-pubsyssamba wrote:
> I can't say I've tested this in any depth. Where multiple LDAP
servers are listed as the LDAP
> backend is the behaviour of Samba that if it fails to contact the first
listed server it will
> try the second and so on? If that's the case Samba should only ever try
and update the password
> on a single LDAP server which would then replicate the change to any other
master and slave LDAP
> servers in the environment. This should work pretty well no? Are my
assumptions on Samba correct?
My worry is if two independent client update to two independent,
disconnected LDAP peers.  This particularly applies when we are doing an
atomic increment in LDAP, like we do in IDMAP, and like a good 'add user
script' should do.

Andrew Bartlett


This e-mail (and any attachments) is confidential and may contain personal views
which are not the views of the BBC unless specifically
stated.
If you have received it in error, please delete it from your system. Do not use,
copy or disclose the information in any way nor act in
reliance on it and notify the sender immediately. Please note that the BBC
monitors e-mails sent or received.
Further communication will signify your consent to this.