>I think this is how it is designed right now. >The migration to host groups will be slow and painful. >I think that approach we planned covers all main use cases and provides >enough flexibility for administrators transition from old models and >concepts to the new ones. >There will be need to the compatibility for older clients for the years >to come.
The design doc seems to disagree: http://freeipa.org/page/SUDO_Schema_Design objectclass: ipaSudoRule ... memberHost: cn=VirtGuests,cn=hostgroups,cn=accounts,... ... Just to review, so that I can make sure the patch is posted correctly: The current Sudo Compat Plugin functions as long as: An IPASudoRule can consist of: memberUser: <Single_User|Group> memberAllowCmd: <Single_CMD|SudoCmdGroup> memberDenyCmd: <Single_CMD|SudoCmdGroup> memberHost: <Single_Host|ipaNetGroup> ??? ^ The Schema Design originally suggested that for an ipaSudoRule an ipaHostGroup would be used. This ipaHostGroup would then be duplicated into a ipaNetGroup (Managed Entry). This ipaNetGroup would then be translated into an ldap backed nisNetGroup (Compat). I am ok changing the sudorule plugin to point memberHost to an ipaNetgroup, however, I think we need to be correct and clear in all the previous references. There are a LOT of moving parts behind the scenes to make this work natively, so the chance for confusion is very high. What I was suggesting, was that perhaps its not necessary to change the sudorule plugin if the eventual end goal is to utilize hostgroups natively. The compat pieces and Managed Entry pieces already handle the translation as elegantly as they can given the circumstances. Is there a negative aspect of having the SudoCompat piece look to an ipaHostgroup for its conversion? Thanks! -JR _______________________________________________ Freeipa-devel mailing list Freeipafirstname.lastname@example.org https://www.redhat.com/mailman/listinfo/freeipa-devel