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 >>doing >> 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. Excellent! 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. >> >> Or >> >> 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 >>the >> hostgroup into the nisNetgroup... >> * Allow translation to occur and point everything with 1-to-1 except >>for: >> -sudocmdgroups are unknown to sudo, so the individual commands need to >>be >> 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, >>it >> 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 >>to >> 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 >netgroup DN 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 the framework. >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. -JR _______________________________________________ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel