[IPA] SID allocation using DNA plugin
dpal at redhat.com
Tue Nov 3 18:19:52 MST 2009
Andrew Bartlett wrote:
> On Tue, 2009-11-03 at 17:50 -0500, Endi Sukma Dewata wrote:
>> Please take a look at the attached patch files.
>> The first patch contains bug fixes for some minor issues.
>> The second patch contains a number of additional schema mapping. When
>> I tested the patches that I submitted previously, the schema mappings
>> seemed to be enough for avoiding conflicts between AD schema and FDS
>> schema. But now it seems there has been some changes so I have to add
>> some more mappings.
>> In this patch I'm renaming some AD object classes using 'samba4' prefix
>> because there are already FDS object classes with the same name/OID.
>> I don't think we can just skip the AD classes and use the FDS classes
>> because although they may look the same they are actually different.
>> The AD classes are subclasses of samba4Top which requires AD-specific
> I would prefer a more elegant solution. Perhaps not loading those
> classes in FDS, and allowing the FDS users to see the inheritance from
> Samba4Top? However, this is your mapping, and in the end I don't mind
> how you do it (make sure you update the simple_ldap_map however!)
I am not sure it is possible since this implies that the FDS user has to
decide whether or
not to load the conflicting schema before he starts to use his instance
of FDS as a Samba
back end. The general assumption about any DS instance OpenLDAP, FDS or
any other IMO
should be that it has been deployed before customer decided to use it as
Samba back end with it.
I know that it adds more burden to Samba but I think respecting this
assumption would make
Samba 4 more attractive to people who already deployed some kind of DS
based solution and want to add Windows users and machines to it.
> Renames are great where this a problem we can't solve any other way, but
> I would hate to inflict Samba4* on the world where we could come up with
> better solutions.
> If you are going to rename this much, then I suggest you may wish to, as
> you proposed earlier, rewrite simple_ldap_map to use a real
> configuration file, shared with the schema mapping code. Otherwise,
> these will get out of sync.
>> There is still another problem with the provisioning tool that I'm
>> still investigating. Once this is working I will be able to look into
>> the 'make test'.
> Any chance you can post these (particularly the first patch) as
Engineering Manager IPA project,
Red Hat Inc.
Looking to carve out IT costs?
More information about the samba-technical