On 11/18/10 3:11 PM, "Dmitri Pal" <d...@redhat.com> wrote:
>JR Aquino wrote:
>> The IPA SudoRule Structure has largely been based off of what we are
>> today with HBAC.
>> HBAC does not distinguish between memberGroup or memberNetgroup... Its
>> simply, memberHost and memberUser for both HBAC and IPASudoRules.
>> Also, when HBAC or IPASudoRules add a member, there is no resulting
>> 'memberOf' or (hbacMemberOf/sudoMemberOf) inserted into the usergroup,
>> hostgroup, command group, etc... Whereas, if you add a host to a
>> hostgroup, the host ends up with a pointer referring back to the
>> hostgroup. I believe this was done to provide referential integrity.
>> We will definitely need to modify the schema under the hood if it is
>> necessary to make these shifts, but I am not sure if that sort of change
>> will be effected by the way the backend treats these sorts of objects.
>Nalin is working on a solution to this. We do not need to modify schema.
>Instead he is adding code to make checks on the object type and have a
>way to transform the value in different ways based on this check.
I'll retest as soon as the new patch is available!
>>Sudo, does not support hostgroups, it only knows about nisnetgroups.
>> As such, either we need the backend code to translate this information
>> automatically for us.
>> We need to go down the path of procedurally solving this issue.
>> For example:
>> * Create a user + usergroup
>> * Create a command + commandgroup
>> * Create a host + hostgroup
>> * Create a nisNetgroup with the same name as the ipaHostgroup, and add
>> hostgroup into the nisNetgroup...
>> * Allow translation to occur and point everything with 1-to-1 except
>> -sudocmdgroups are unknown to sudo, so the individual commands need to
>> broken out and listed individually in the translation.
>> -sudoHost will need to point to a (shared name) that represents both an
>> ipaHostgroup and an ipaNisNetgroup.
>> We have discussed this challenge at length, and everyone agrees that
>> nisNetgroups are a thing of the past, that is best forgotten. However,
>> is necessary to support them in the interim because sudo currently does
>> not support anything else. It is an ideal to strive toward getting sudo
>> to support hostgroups, and also to support sssd, but we have a long way
>> go to get there.
>I was assuming that this is a procedurally solvable solution during
>migration. In your case when you move to IPA you would need to transfer
>data from the original data source.
>1) All the netgroups that store the hosts and used in SUDO and other
>places need to be migrated into IPA back end schema. As you prepare
>data for migration the following reshuffling needs to be done with the
>original data and the resulting LDIF should have:
> a) all the hosts should be created as host entries
> b) all hosts should be added to a host group - probably with the
>same name as the name of the netgroup in the original data set
> c) a netgroup entry with the same name is in the source data set
>should be created pointing to this host group
> d) memberHost attribute of the SUDO rule should then point to the
The Sudo Plugin currently points to the HostGroup DN. Since we must
solve this issue procedurally by using the same name for the Hostgroup
and nisNetgroup, I would prefer to continue to point to the
HostGroup DN. This allows for the future of the plugin to remain
sane after sudo natively support sssd/FreeIPA...
I'm concerned that if we force the Sudo Piece to only look at the
nisNetgroup, that it will encourage siloing to occur; the goal is
to facilitate and encourage the usage of hostgroup objects throughout
>This solves the issue of migrating data from the old model to the new
>model. Would be nice to have some scripts in the project that would help
>people to take the 2307 + SUDO schema and move to IPA. We do not have
>cycles to do it ourselves and hope that something like this would be
>eventually developed and contributed by the community.
>2) The other question is management of SUDO data on the ongoing basis.
>Until SUDO does not support host groups via a policy plugin the IPA
>admins would have to wrap host groups into netgroups.
Depending on size, this can be daunting...
>A special wrapper
>can be created for the CLI to create a netgroup out of the hostgroup or
>may be it can be a flag to the hostgroup-add to automatically create a
>netgroup with the same name. Something similar to what we do with
>host-add and DNS.
That sounds VERY promising! I wasn't aware that we had a plugin that could
have triggered adds!
>An alternative is to have a managed entry plugin to
>automatically create a netgroup for every hostgroup in the system. This
>might be even simpler.
I'm not sure how I would go about coding this option...
>I am open to suggestions here but hope that since this is an
>optimization and we are in a bit of ramp up to the release this
>functionality can be contributed soon or can be added later.
I agree. We are very very close to functional and it makes sense to get
over the hump while bookmarking 'optimizations' that can be revisited
after the major release.
Freeipa-devel mailing list