On 02/25/2013 02:15 PM, Loris Santamaria wrote: > Hi all, > > some customers of ours are interested in managing desktop policies for > their linux workstations, really nothing fancy, corporate background and > proxy settings are the most common requests. > > In the past I created Gnome desktop profiles using Sabayon, distributed > them using puppet and associated them to user accounts with a Sabayon > specific LDAP attribute, a process a bit convoluted, and no longer > possible since sabayon is no longer developed. Also it was really buggy, > and very gnome specific. > > I was thinking in how integrate desktop policies in freeIPA in a general > manner and I wanted to share my ideas with you. Hopefully some of this > may be incorporated in IPA at some point in the future. > > Properties of a "policy": > > * is a collection of "settings" > * can be associated with users or groups (desktop policy) or with > hosts or hostgroups (system policy) > * is associated with a "consumer", the client software that > interprets and applies the policy. This way one could define > policies for dconf, policies for kde, policies for WBEM. > > Properties of a "setting" > * is a key-value pair > * must conform to a "schema" > * may be mandatory > > The schema: > * indicates which attributes a policy may consist of > * indicates which kind of value may take an attribute. Bool, > string, etc. > * There may be more than one schema for a given "consumer". For > example for dconf you may have an evolution schema, a > gnome-games schema, etc. > > Sample policy creation process: > 1. The admin creates a new schema in IPA, with a command like "ipa > schema-add --consumer=dconf gnomeSettingsSchema" > 2. The admin adds some definition to the schema: "ipa > schema-add-setting gnomeSettingsSchema > --name=/schemas/desktop/gnome/background/picture_filename > --type=string --description='File to use for the background > image.'" > 3. He creates a new policy: "ipa policy-add corporateBackground > --type=desktop --consumer=dconf > 4. He adds a setting to the policy: "ipa policy-add-setting > corporateBackground > --name=/schemas/desktop/gnome/background/picture_filename > --value=file:///san/wp/wallpaper.jpg --mandatory". Ipa would > check that the key is defined in one of the dconf related > schemas and the value is acceptable for that key. > 5. He associates the policy with users: "ipa-policy-add-user > corporateBackground --groups=ipausers" > > How should the policy be applied? On the workstation, on startup, an ipa > related utility should check if there are any policies related to the > workstation, if there are any it should call a helper capable of > applying a specific type of policy. Then on user logon another ipa > related utility should check if there are any policies associated with > the user and call the appropriate helper, if available. > > For the policy created in the above example, on logon the ipa policy > utility would find that there is a policy of type dconf associated with > the user. It would check if there is a dconf policy helper installed and > if positive it would call the helper passing it the parameters defined > in the policy. > > Hope this is useful at least as a starting point in defining desktop > policies in IPA.
This is great! Thank you for sharing some ideas. We sort of stayed away from centralized policy management for quite some time. Originally we thought that IPA will do policy management and did a lot of design around it. However at some point we realized that there is an overlap with the system management and content management for which things like puppet are more suitable. We said then that IdM would focus on managing identity related policies that are traditionally served via LDAP. The things that you are talking about resemble to some extent MSFT GPO and we felt that IdM might not be the right place for it. May be it is time to reassess it. I would however not go that route at least yet. If Desktop can read additional properties related to user (background, default language, etc.) from SSSD over a DBUS interface the SSSD should be able to pull this data from the IdM (eventually). On the IdM we probably can make these additional attributes available in the user entries using class of service like we do with password policies. We have plans for SSSD to handle more attributes than posix and integrate with Desktop. https://fedorahosted.org/sssd/wiki/DesignDocs/AccountsService IMO once this work is started we would be able to see how we can configure and serve more data from IPA for clients to consume. Meanwhile I suggest you create a ticket in IPA trac and put your ideas there. > > > _______________________________________________ > Freeipa-devel mailing list > Freeipafirstname.lastname@example.org > https://www.redhat.com/mailman/listinfo/freeipa-devel -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/
_______________________________________________ Freeipa-devel mailing list Freeipaemail@example.com https://www.redhat.com/mailman/listinfo/freeipa-devel