[Freeipa-devel] What about desktop policies?

[Petr Spacek]

On 27.2.2013 14:16, Loris Santamaria wrote:
> El mar, 26-02-2013 a las 15:11 -0500, Dmitri Pal escribió:
>> 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.
>
> Hey puppet is great and we use it a lot to install packages and to
> distribute configuration files, yet it is not so great to set these
> key=value kind of settings of which more and more "modern" software
> consists of. When you take into consideration gconf settings for gnome
> 2.x, dconf settings for gnome 3.x, mozilla settings, thunderbird
> settings it quickly becomes a PITA to manage them distributing around
> files with puppet.

Did you look at http://augeas.net/ ? Puppet + Augeas could be very very strong 
combination.

Petr^2 Spacek

> Having those key=value pairs in an ldap would allow a helper on the
> client to pull only the keys it understands and to merge them in the
> configuration database in the appropriate way.
>
> Of course i took inspiration from AD GPOs, yet I think that IPA should
> manage these key=value kind of policies in a more general way, for one
> because nobody in the linux world controls all of the desktop stack and
> because the end user experience is changing so fast that we can't really
> know how the user will access IT resources ten year from now.
>>
>> 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.
>
> Ok I'll file the RFE.