[PATCH] new idmap module autorid

Christian M Ambach christian.ambach at de.ibm.com
Fri Nov 5 11:00:27 MDT 2010


Hi list,

talking to Volker, he brought the idea of adding a new idmap module
that combines the advantages of the tdb and rid backends and eliminates
some of their deficiencies.

So what is good about idmap_rid?
1. it uses a deterministic approach
2. it does not need a database
The bad stuff:
1. you have to configure it for each domain in your forest
   adding a trusted domain means changing smb.conf

idmap_tdb:
1. Easy to configure
2. You do not have to care about trusted domains
Bad stuff:
1. it is non-deterministic, mappings are done on
   first-come first-serve creating an unpredictable mapping for a
   given user/group
2. it uses a database to store the mappings to. If you loose this
   database, you have a really problematic situation. There is no 
   easy way to recover from this. You will wish you had a backup of it! 
3. creating new mappings is very slow in a CTDB environment and there
   is a risk of a new users timing out if there are lots of mappings to
   be created (imagine you put a new CTDB cluster into production over
   the weekend and on Monday morning 8AM hundreds of users try to access
   their home directory at the same time)

So how does the new module essentially work?
It uses a similar calculation of mappings as the rid backend does,
but it automatically picks ranges for the principal and trusted
domains. Each time a new domain comes in, the module will assign a 
new range for this domain and in that domain apply the rid algorithm 
to mappings.

So the benefits are:
1. easy to configure: it just has one optional configuration parameter:
   the size of the ranges to be used. The default I chose should be 
   good enough for an average Samba installation.
2. no need to update smb.conf when adding a new trusted domain 
3. fast operation: we will only need one TDB transaction when a new
   trusted domain comes in, after that mappings are just a matter of
  some mathematical operations
4. mapping behaviour is quite deterministic, the only unpredictable
   factor is in which order domains will come in and get ranges
   assigned.

The drawbacks are:
1. the module still needs a TDB to store the mappings to, but 
   this should be much easier to recover in case it gets lost
2. all domains get ranges of equal size, so we might leave large holes
   in the idmap ranges, leading to shortages in enterprises with many
   domains

Ideas for improvements:
1. make ranges smaller and offer range extensions in case one range
   runs out of space
2. make first configuration permanent to prevent admins from changing
   the rangesize after first mappings have been done

(the first patch is a prereq patch for the module)

Awaiting comments :)

Have a nice weekend,
Christian


-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-s3-winbind-add-wcache_tdc_fetch_domainbysid.patch
Type: application/octet-stream
Size: 2950 bytes
Desc: not available
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20101105/9564bde7/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-s3-idmap-add-a-new-ID-mapping-module-autorid.patch
Type: application/octet-stream
Size: 19546 bytes
Desc: not available
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20101105/9564bde7/attachment-0001.obj>


More information about the samba-technical mailing list