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.

_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Reply via email to