>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:

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
This ipaNetGroup would then be translated into an ldap backed nisNetGroup

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?



Freeipa-devel mailing list

Reply via email to