Andrew,
On Sat, Oct 12, 2002 at 09:25:22AM +1000, Andrew Bartlett wrote:
You either need to keep the 'unixsam' in your 'passdb backends' line in
your smb.conf, or add a 'guest' account to ldap, with a real unix UID
(possibly the same as nobody, should be the same as 'guest account') and
with
[EMAIL PROTECTED] wrote:
Andrew,
On Sat, Oct 12, 2002 at 09:25:22AM +1000, Andrew Bartlett wrote:
You either need to keep the 'unixsam' in your 'passdb backends' line in
your smb.conf, or add a 'guest' account to ldap, with a real unix UID
(possibly the same as nobody, should be the
Andrew Bartlett wrote:
Samba 3.0 is starting to be used in a lot of places, and I'm starting to
look into how we can best ensure we don't get bottlenecks in our
performance.
Metze has raised a number of issues with pdb_ldap:
- We do a Get_Pwnam() on every user - even in enums.
- We hit the
I've been thinking about the problem of allocating RIDs in LDAP.
We need a race-proof scheme to allocate RIDs, and I would prefer not to
need to use a local TDB - I would like it all 'in ldap', if at all
possible.
While the real solution is an LDAP server that imposes restrictions on
attributes
Andrew Bartlett wrote:
I've been thinking about the problem of allocating RIDs in LDAP.
We need a race-proof scheme to allocate RIDs, and I would prefer not to
need to use a local TDB - I would like it all 'in ldap', if at all
possible.
yes, and is better because several PDC may share the
Ignacio Coupeau wrote:
Andrew Bartlett wrote:
I've been thinking about the problem of allocating RIDs in LDAP.
We need a race-proof scheme to allocate RIDs, and I would prefer not to
need to use a local TDB - I would like it all 'in ldap', if at all
possible.
yes, and is better
On Sat, 12 Oct 2002, Andrew Bartlett wrote:
We need a race-proof scheme to allocate RIDs, and I would prefer not to
need to use a local TDB - I would like it all 'in ldap', if at all
possible.
See the uidPool objectclass in samba.schema. You would do it like
this
do {
get the curent
On Sat, 12 Oct 2002, Andrew Bartlett wrote:
OK, that make much more sense. But what to do in between the delete and
the add? Spin, and hope the entry 'comes back'?
It should local the entry, test for the presence of the old
value/attribute before any delete, remove it, and add the new one.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi!
Discussion moved to samba-technical.
Instead of just doing a pdb_getsampwnam() on the name from pass struct,
I would prefer that we instead change the callers. Most of the callers
can be changed to do the pdb_getsampwnam() instead of
On Sat, Oct 12, 2002 at 07:17:10PM +1000, Andrew Bartlett wrote:
I've been thinking about the problem of allocating RIDs in LDAP.
Look at google for 'ldap atomic increment'. The second article gives some hints
on how an atomic increment might be implemented in LDAP. I have not programmed
LDAP
Our implementation updates the nextRid attribute in the
domain entry (eg. dc=windows,dc=samba,dc=org) whenever a
RID needs to be allocated. Removing the old value and
adding the new one is used to guarantee atomicity.
It is interesting to note that the distributed RID
allocation scheme used in
Dear Sir or Madam
In the past you have requested information on discounted products. If you are not a
smoker, and find this email offensive, then we sincerely apologise. We will be only
too happy to take you off our database.
If you are a smoker, however, you are probably fed up with paying
[EMAIL PROTECTED] wrote:
On Sat, Oct 12, 2002 at 07:17:10PM +1000, Andrew Bartlett wrote:
I've been thinking about the problem of allocating RIDs in LDAP.
Look at google for 'ldap atomic increment'. The second article gives some hints
on how an atomic increment might be implemented in
[EMAIL PROTECTED] wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi!
Discussion moved to samba-technical.
Instead of just doing a pdb_getsampwnam() on the name from pass struct,
I would prefer that we instead change the callers. Most of the callers
can be changed to do the
14 matches
Mail list logo
