Re: [Freeipa-devel] What about desktop policies?
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
Re: [Freeipa-devel] What about desktop policies?
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
Re: [Freeipa-devel] What about desktop policies?
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 Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel -- Thank you, Dmitri
[Freeipa-devel] What about desktop policies?
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. -- Loris Santamaria linux user #70506 xmpp:lo...@lgs.com.ve Links Global Services, C.A.http://www.lgs.com.ve Tel: 0286 952.06.87 Cel: 0414 095.00.10 sip:1...@lgs.com.ve If I'd asked my customers what they wanted, they'd have said a faster horse - Henry Ford smime.p7s Description: S/MIME cryptographic signature ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
