Idmap feature request/suggestion

[Nimrod Sapir]

Volker Lendecke <Volker.Lendecke at sernet.de> wrote on 15/05/2012 17:59:08:

> > I understand the risk here. The user will have to be aware of the fact 

> > that adding a new mapping on an external database (for example, SFU) 
for 
> > an account that is already using the file system will have impact on 
the 
> > permissions of his files. Still, consider this scenario: A customer 
has an 
> > Active Directory of 10,000 accounts, of which 100 also have a 
> > corresponding Linux accounts. Assuming he has SFU enabled, he will 
> > actually need to provide a uid for each of the 10,000 user accounts, 
while 
> > making sure those UIDs do not belong to other windows users (across 
the 
> > forest), other linux users (including the ones who do not have a 
windows 
> > account at all), and any internal UID used by the system. This is a 
> > configuration nightmare and not always feasible. If he had a 
possibility 
> > of using two different backends (with two different ranges), he would 
be 
> > able to only provide the UID information for the 100 relevant accounts 

> > (whose UIDs he already knows), and let the system (usind rid/tdb2) 
provide 
> > auto-generated UIDs for all the other accounts, from a different pool. 
The 
> > same goes for users who want to use NIS as a backend for id mapping. 
Do 
> > you have any suggestion on how to handle such scenario?
> 
> If you pre-fill the directory correctly for the 100
> accounts, idmap_ldap will pick values itself for the rest.

This is relevant for ldap only, right? not for using SFU/NIS. Also (and 
correct me if I am wrong), the ldap will assign the UIDs using a 
non-deterministic tdb2-style allocation. If I want to use a deterministic 
backend (like RID), while allowing the customer to pre-define some of the 
mapping entries (using either NIS, LDAP or SFU), I don't believe that 
there is currently any good solution.