[Freeipa-devel] What about desktop policies?

Loris Santamaria loris at lgs.com.ve
Wed Feb 27 13:16:41 UTC 2013


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.

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.

Thanks!

-- 
Loris Santamaria   linux user #70506   xmpp:loris at lgs.com.ve
Links Global Services, C.A.            http://www.lgs.com.ve
Tel: 0286 952.06.87  Cel: 0414 095.00.10  sip:103 at lgs.com.ve
------------------------------------------------------------
"If I'd asked my customers what they wanted, they'd have said
a faster horse" - Henry Ford
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6173 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/freeipa-devel/attachments/20130227/e047c6b8/attachment.bin>


More information about the Freeipa-devel mailing list