Hi,
with Alexander's help, I wrote up a design page about how SSSD should read Fleet Commander data from IPA and present them to the FC client component. The SSSD part is described here: https://fedorahosted.org/sssd/wiki/DesignDocs/FleetCommanderIntegration and the IPA part is here: https://github.com/abbra/freeipa-desktop-profile/blob/master/plugin/Feature....
For convenience, I copied the SSSD wiki page below. Comments are welcome!
= Feature Name =
Related ticket(s): * https://fedorahosted.org/sssd/ticket/2995
=== Problem statement === FleetCommander is a service to centrally manage Desktop environments. It includes a server to define desktop profiles and a client to apply profile information to the user's desktop session on a specified machine.
This design document describes the SSSD part of an integration of FleetCommander with FreeIPA. The integration is done two-fold, the IPA part of the integration is [https://github.com/abbra/freeipa-desktop-profile/blob/master/plugin/Feature.... documented separately].
=== Use cases === As an administrator, I want to manage desktop profiles in a centralized way
As an administrator, I want to use centrally defined users, groups, hosts and host groups to specify how desktop profiles should be applied.
As an administrator, I want to make sure desktop profiles associated with a specific user or user group are downloaded and applied on a specific FreeIPA client according to the desktop profile rules defined in FreeIPA.
=== Overview of the solution === FleetCommander consists on two components: * a web service integrated with Cockpit that serves the dynamic application and the profile data to the network. * and a client side daemon that runs on every host of the network. Since this design page deals with the client side of the whole picture, this paragraph will focus on the integration of the FC client side daemon with SSSD.
The FC profiles will be downloaded by a new `session_provider` of IPA. This provider will do nothing by default and will include an option to download FC rules from IPA LDAP (perhaps `ipa_enable_fleetcmd = true`).
In order to minimize the required client-side configuration changes, enabling the Fleet Commander client side deamon will drop SSSD configuration that enables the SSSD functionality and restarts SSSD.
When a FreeIPA domain user logs in, the IPA provider will download the Fleet Commander profile and rule objects and drop the resulting JSON files into a per-user directory. The file names must be normalized and prepended with priority (please refer to the IPA design page for more details).
In the future, we would like to link the Fleet Commander profiles with HBAC rules, but the first implementation will not include this part.
=== Implementation details === The implementation has two distinct parts -- enabling the IPA session provider's Fleet Commander functionality and actually fetching the Fleet Commander data.
==== Enabling the IPA session provider ==== Since searching for the Fleet Commander profiles does not come for free - at least one LDAP search must be issued, perhaps more unless we cache the host groups, we should only enable this functionality if the Fleet Commander client daemon is enabled as well. To this end, enabling the FC client deamon would trigger a one-shot systemd service that would drop an include file to SSSD's `conf.d` directory.
The systemd service might be implemented along these lines: {{{ [Unit] ConditionFileNotEmpty=/etc/sssd/sssd.conf ConditionFileNotEmpty=!/etc/sssd/conf.d/fleetcommander.conf
[Service] Type=oneshot ExecStartPre=/bin/cp -y /usr/share/fleetcommander/sssd.snippet.conf /etc/sssd/conf.d/fleetcommander.conf ExecStart=/bin/systemctl try-restart sssd }}} This systemd unit might be stored in `/lib/systemd/system/fleetagent.service.d/sssd.conf`. A similar functionality in this file should remove the included config file when the FC client deamon is disabled.
==== Looking up the Fleet Commander profiles and storing the JSON profile data ==== Since the first implementation will only fetch rules that are linked to this host and the user in question, the SSSD's session provider will issue an LDAP search along these lines: {{{ (&(objectclass=ipadeskprofilerule)(memberHost=my_fqdn_or_my_host_group)(memberUser=user_login_or_group)) }}}
All host groups the IPA client is a member of must be included in the `memberHost` part of the filter. Additionally, all user groups must be included in the `memberUser` part of the filter. Since in most cases, the user's groups will be resolved during the login, we will only issue an initgroups request in case the user's initgroups are expired already to cover cases where the sessions provider was invoked separately.
The host groups are typically also resolved by the IPA access control provider, but currently not cached. In the initial implementation, we can just search the host groups again, but subsequent patches should optimize the searches by storing the host groups in the cache or in an intermediate in-memory result.
The LDAP search will include the Fleet Commander payload data in the profile's `data` attribute. Once the data are known, SSSD will write them to the disk. Since writing to the disk is typically quite fast
The JSON files will be stored in a new directory owned by the `sssd-ipa` subpackage. The top-level directory could be at `/var/lib/sss/fleetcmd/` with per-user subdirectories. So each per-user JSON file would be stored at `/var/lib/sss/fleetcmd/<username>/<profilename>.json`. The `<username>` directories need to be owned by the user being logged in.
The `<profilename.json>` file must include the priority as a number which is read from the rule's `prio` attribute. The Fleet Commander client deamon will then process the JSON files in this priority. The filenames must also be normalized so that characters with a special meaning in shell are escaped and spaces are converted to another character such as underscores. Please refer to the IPA design page for more details.
In the first version, the profiles will always be written again. In the future, we might want to optimize the process further by only writing the JSON profiles if they differ from what's already stored on the disk. This might be doable by storing the modifyTimestamp in the JSON profiles again, if FC is able to ignore certain JSON key-value pairs that would be private to SSSD or just storing the largest USN value of the found profiles in the included directory in a specially-named file.
=== Configuration changes === Two new configuration options will be added: * `session_provider` that will be inherited from the `id_provider` value, so for IPA clients, this provider will default to `ipa`. A default `session_provider` for other providers will just shortcut and return success. * An option that enables the FC rules and profiles processing. A proposed option name is `ipa_enable_fleetcmd` with boolean semantics.
=== How To Test === Please see the use-cases above.
=== How To Debug === DEBUG messages will be added to the new session provider so that the admin can trace if the session provider was invoked at all. An easy way to debug the integration is to enable the sessions provider and the FleetCommander integration manually w/o dropping the file by the FC client side daemon.
=== Authors === * Alexander Bokovoy * Jakub Hrozek
On Thu, Oct 06, 2016 at 04:41:10PM +0200, Jakub Hrozek wrote:
Hi,
with Alexander's help, I wrote up a design page about how SSSD should read Fleet Commander data from IPA and present them to the FC client component. The SSSD part is described here: https://fedorahosted.org/sssd/wiki/DesignDocs/FleetCommanderIntegration and the IPA part is here: https://github.com/abbra/freeipa-desktop-profile/blob/master/plugin/Feature....
For convenience, I copied the SSSD wiki page below. Comments are welcome!
...
==== Looking up the Fleet Commander profiles and storing the JSON profile data ==== Since the first implementation will only fetch rules that are linked to this host and the user in question, the SSSD's session provider will issue an LDAP search along these lines: {{{ (&(objectclass=ipadeskprofilerule)(memberHost=my_fqdn_or_my_host_group)(memberUser=user_login_or_group)) }}}
All host groups the IPA client is a member of must be included in the `memberHost` part of the filter. Additionally, all user groups must be included in the `memberUser` part of the filter. Since in most cases, the user's groups will be resolved during the login, we will only issue an initgroups request in case the user's initgroups are expired already to cover cases where the sessions provider was invoked separately.
I wonder if it would be more efficient to read all profiles which apply to the host in a single run store them in the cache and do the remaining part of the processing locally? Iirc this is what we do with HBAC rules and there might be a chance to reuse some of the HBAC code but just look for objectclass ipadeskprofilerule instead of ipahbacrule?
Since there are host and user categories mentioned on the server side design page I guess the underlying objectclass is ipaAssociation and because of this it makes even more sense to reuse as much of the HBAC lookup code as possible.
The host groups are typically also resolved by the IPA access control provider, but currently not cached. In the initial implementation, we can just search the host groups again, but subsequent patches should optimize the searches by storing the host groups in the cache or in an intermediate in-memory result.
If the same scheme as for the HBAC is used (see above) it might no be necessary to cache the host groups (with the side-effect that all profiles which apply to the host must be cached :-)
bye, Sumit
The LDAP search will include the Fleet Commander payload data in the profile's `data` attribute. Once the data are known, SSSD will write them to the disk. Since writing to the disk is typically quite fast
The JSON files will be stored in a new directory owned by the `sssd-ipa` subpackage. The top-level directory could be at `/var/lib/sss/fleetcmd/` with per-user subdirectories. So each per-user JSON file would be stored at `/var/lib/sss/fleetcmd/<username>/<profilename>.json`. The `<username>` directories need to be owned by the user being logged in.
The `<profilename.json>` file must include the priority as a number which is read from the rule's `prio` attribute. The Fleet Commander client deamon will then process the JSON files in this priority. The filenames must also be normalized so that characters with a special meaning in shell are escaped and spaces are converted to another character such as underscores. Please refer to the IPA design page for more details.
In the first version, the profiles will always be written again. In the future, we might want to optimize the process further by only writing the JSON profiles if they differ from what's already stored on the disk. This might be doable by storing the modifyTimestamp in the JSON profiles again, if FC is able to ignore certain JSON key-value pairs that would be private to SSSD or just storing the largest USN value of the found profiles in the included directory in a specially-named file.
=== Configuration changes === Two new configuration options will be added: * `session_provider` that will be inherited from the `id_provider` value, so for IPA clients, this provider will default to `ipa`. A default `session_provider` for other providers will just shortcut and return success. * An option that enables the FC rules and profiles processing. A proposed option name is `ipa_enable_fleetcmd` with boolean semantics.
=== How To Test === Please see the use-cases above.
=== How To Debug === DEBUG messages will be added to the new session provider so that the admin can trace if the session provider was invoked at all. An easy way to debug the integration is to enable the sessions provider and the FleetCommander integration manually w/o dropping the file by the FC client side daemon.
=== Authors ===
- Alexander Bokovoy
- Jakub Hrozek
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-leave@lists.fedorahosted.org
On Thu, Oct 06, 2016 at 06:38:23PM +0200, Sumit Bose wrote:
On Thu, Oct 06, 2016 at 04:41:10PM +0200, Jakub Hrozek wrote:
Hi,
with Alexander's help, I wrote up a design page about how SSSD should read Fleet Commander data from IPA and present them to the FC client component. The SSSD part is described here: https://fedorahosted.org/sssd/wiki/DesignDocs/FleetCommanderIntegration and the IPA part is here: https://github.com/abbra/freeipa-desktop-profile/blob/master/plugin/Feature....
For convenience, I copied the SSSD wiki page below. Comments are welcome!
...
==== Looking up the Fleet Commander profiles and storing the JSON profile data ==== Since the first implementation will only fetch rules that are linked to this host and the user in question, the SSSD's session provider will issue an LDAP search along these lines: {{{ (&(objectclass=ipadeskprofilerule)(memberHost=my_fqdn_or_my_host_group)(memberUser=user_login_or_group)) }}}
All host groups the IPA client is a member of must be included in the `memberHost` part of the filter. Additionally, all user groups must be included in the `memberUser` part of the filter. Since in most cases, the user's groups will be resolved during the login, we will only issue an initgroups request in case the user's initgroups are expired already to cover cases where the sessions provider was invoked separately.
I wonder if it would be more efficient to read all profiles which apply to the host in a single run store them in the cache and do the remaining part of the processing locally? Iirc this is what we do with HBAC rules and there might be a chance to reuse some of the HBAC code but just look for objectclass ipadeskprofilerule instead of ipahbacrule?
Since there are host and user categories mentioned on the server side design page I guess the underlying objectclass is ipaAssociation and because of this it makes even more sense to reuse as much of the HBAC lookup code as possible.
Yes, of course you are right, fetching the per-host data is almost always a good idea. I changed the wiki page: https://fedorahosted.org/sssd/wiki/DesignDocs/FleetCommanderIntegration?acti...
On Fri, Oct 7, 2016 at 10:22 AM, Jakub Hrozek jhrozek@redhat.com wrote:
On Thu, Oct 06, 2016 at 06:38:23PM +0200, Sumit Bose wrote:
On Thu, Oct 06, 2016 at 04:41:10PM +0200, Jakub Hrozek wrote:
Hi,
with Alexander's help, I wrote up a design page about how SSSD should read Fleet Commander data from IPA and present them to the FC client component. The SSSD part is described here: https://fedorahosted.org/sssd/wiki/DesignDocs/FleetCommanderIntegration and the IPA part is here: https://github.com/abbra/freeipa-desktop-profile/blob/master/plugin/Feature....
For convenience, I copied the SSSD wiki page below. Comments are welcome!
...
==== Looking up the Fleet Commander profiles and storing the JSON profile data ==== Since the first implementation will only fetch rules that are linked to this host and the user in question, the SSSD's session provider will issue an LDAP search along these lines: {{{ (&(objectclass=ipadeskprofilerule)(memberHost=my_fqdn_or_my_host_group)(memberUser=user_login_or_group)) }}}
All host groups the IPA client is a member of must be included in the `memberHost` part of the filter. Additionally, all user groups must be included in the `memberUser` part of the filter. Since in most cases, the user's groups will be resolved during the login, we will only issue an initgroups request in case the user's initgroups are expired already to cover cases where the sessions provider was invoked separately.
I wonder if it would be more efficient to read all profiles which apply to the host in a single run store them in the cache and do the remaining part of the processing locally? Iirc this is what we do with HBAC rules and there might be a chance to reuse some of the HBAC code but just look for objectclass ipadeskprofilerule instead of ipahbacrule?
Since there are host and user categories mentioned on the server side design page I guess the underlying objectclass is ipaAssociation and because of this it makes even more sense to reuse as much of the HBAC lookup code as possible.
Yes, of course you are right, fetching the per-host data is almost always a good idea. I changed the wiki page: https://fedorahosted.org/sssd/wiki/DesignDocs/FleetCommanderIntegration?acti...
Since I started working on this a few changes have been done in the Design (and I've talked to Jakub on IRC about those all the time). In case anyone is interested, here are the changes: https://fedorahosted.org/sssd/wiki/DesignDocs/FleetCommanderIntegration?acti...
Best Regards, -- Fabiano Fidêncio
Hi everybody,
As I started to design nd develop the changes needed in Fleet Commander, and after a meeting with Alberto Ruiz about the things we need, in the FreeIPA side of the things it is all Ok.
The only thing that should be added is the ability to select what is the priority in the desktop profile resolution. For example: The admin wants to setup the profile resolution should be host over group over user, or maybe host over user over group, or user over group over host. That setting should be available to set at a "global" level, so the Fleet Commander Client can get that setting and apply the configuration using that priority. That priority is apart of the numerical priority we already have.
At SSSD level we need to do 2 changes. They are very simple so whey would not be a problem:
1) We need to know if the profile downloaded by SSSD was downloaded because it applied to the host, user or group rule. So, the option we think is better should be to add 3 characters to the profile file saved ny SSSD that specifies if that file applies because of a host, group or/and user rule. For example:
000101_ugh_profile1.json # Is a profile that applies to user, group and host 000121_u-h_profile2.json # Is a profile that applies to user and host 000001_--h_profile3.json # Is a profile that applies only to host 000003_--h_profile4.json # Is a profile that applies only to host but will be highest priority than profile3
On the other hand, we need to know when SSSD has finished to download the data so Fleet Commander can start to apply the user configuration. For that the best option should be sending a dbus message or calling a dbus method for Fleet Commander Client with the path where the files have been downloaded, so the FC client can know that the process of downloading the data has finished and also where the files are located.
This are the things we need right now. Would like to know your thoughts about this.
Thank you and best regards
On ma, 28 marras 2016, Oliver Gutiérrez wrote:
Hi everybody,
As I started to design nd develop the changes needed in Fleet Commander, and after a meeting with Alberto Ruiz about the things we need, in the FreeIPA side of the things it is all Ok.
The only thing that should be added is the ability to select what is the priority in the desktop profile resolution. For example: The admin wants to setup the profile resolution should be host over group over user, or maybe host over user over group, or user over group over host. That setting should be available to set at a "global" level, so the Fleet Commander Client can get that setting and apply the configuration using that priority. That priority is apart of the numerical priority we already have.
Not sure where to put this. Rules are separate from the profiles, and this resolution priority seem to be a third thing. Looks like it asks for a 'desktop profile global settings' kind of object...
What else could be defined in such an object?
I will add on CC to Alberto because he is the one that knows better this feature, but AFAIK the only thing to be defined in that object is that resolution order setting, and should be downloaded also with SSSD at login time so the Fleet Commander Client can read it.
The global settings object seems the best option to me.
On Tue, Nov 29, 2016 at 12:23 PM, Alexander Bokovoy abokovoy@redhat.com wrote:
On ma, 28 marras 2016, Oliver Gutiérrez wrote:
Hi everybody,
As I started to design nd develop the changes needed in Fleet Commander, and after a meeting with Alberto Ruiz about the things we need, in the FreeIPA side of the things it is all Ok.
The only thing that should be added is the ability to select what is the priority in the desktop profile resolution. For example: The admin wants to setup the profile resolution should be host over group over user, or maybe host over user over group, or user over group over host. That setting should be available to set at a "global" level, so the Fleet Commander Client can get that setting and apply the configuration using that priority. That priority is apart of the numerical priority we already have.
Not sure where to put this. Rules are separate from the profiles, and this resolution priority seem to be a third thing. Looks like it asks for a 'desktop profile global settings' kind of object...
What else could be defined in such an object?
-- / Alexander Bokovoy
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-leave@lists.fedorahosted.org
Other than the precedence policy I can't think of any other global setting as of now. Before SSSD was handling this for us at login time, defining the polling interval could have been an option but as we're doing this on-demand polling doesn't make sense any more.
On Tue, Nov 29, 2016 at 2:33 PM, Oliver Gutierrez ogutierrez@redhat.com wrote:
I will add on CC to Alberto because he is the one that knows better this feature, but AFAIK the only thing to be defined in that object is that resolution order setting, and should be downloaded also with SSSD at login time so the Fleet Commander Client can read it.
The global settings object seems the best option to me.
On Tue, Nov 29, 2016 at 12:23 PM, Alexander Bokovoy abokovoy@redhat.com wrote:
On ma, 28 marras 2016, Oliver Gutiérrez wrote:
Hi everybody,
As I started to design nd develop the changes needed in Fleet Commander, and after a meeting with Alberto Ruiz about the things we need, in the FreeIPA side of the things it is all Ok.
The only thing that should be added is the ability to select what is the priority in the desktop profile resolution. For example: The admin wants to setup the profile resolution should be host over group over user, or maybe host over user over group, or user over group over host. That setting should be available to set at a "global" level, so the Fleet Commander Client can get that setting and apply the configuration using that priority. That priority is apart of the numerical priority we already have.
Not sure where to put this. Rules are separate from the profiles, and this resolution priority seem to be a third thing. Looks like it asks for a 'desktop profile global settings' kind of object...
What else could be defined in such an object?
-- / Alexander Bokovoy
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-leave@lists.fedorahosted.org
-- Oliver Gutierrez Associate Software Engineer - Desktop Management tools Red Hat
Hi everybody!
We have been investigating about the process to include Fleet Commander in RHEL and we were aiming to have it included in RHEL 7.4.
Can you tell us the planning for including the FreeIPA/SSSD modifications in RHEL? Will be in RHEL 7.4?
We are currently starting the process of including it in RHEL 7.4 so we don't know if we will be able to make it before the deadlines, but anyway, if we don't achieve it, we will make it available to RHEL sysadmins, so would be awesome to have FreeIPA changes already included in the repos.
Thanks you very much and enjoy the holidays!
On Wed, Nov 30, 2016 at 5:20 PM, Alberto Ruiz aruiz@redhat.com wrote:
Other than the precedence policy I can't think of any other global setting as of now. Before SSSD was handling this for us at login time, defining the polling interval could have been an option but as we're doing this on-demand polling doesn't make sense any more.
On Tue, Nov 29, 2016 at 2:33 PM, Oliver Gutierrez ogutierrez@redhat.com wrote:
I will add on CC to Alberto because he is the one that knows better this feature, but AFAIK the only thing to be defined in that object is that resolution order setting, and should be downloaded also with SSSD at login time so the Fleet Commander Client can read it.
The global settings object seems the best option to me.
On Tue, Nov 29, 2016 at 12:23 PM, Alexander Bokovoy abokovoy@redhat.com wrote:
On ma, 28 marras 2016, Oliver Gutiérrez wrote:
Hi everybody,
As I started to design nd develop the changes needed in Fleet Commander, and after a meeting with Alberto Ruiz about the things we need, in the FreeIPA side of the things it is all Ok.
The only thing that should be added is the ability to select what is the priority in the desktop profile resolution. For example: The admin wants to setup the profile resolution should be host over group over user, or maybe host over user over group, or user over group over host. That setting should be available to set at a "global" level, so the Fleet Commander Client can get that setting and apply the configuration using that priority. That priority is apart of the numerical priority we already have.
Not sure where to put this. Rules are separate from the profiles, and this resolution priority seem to be a third thing. Looks like it asks for a 'desktop profile global settings' kind of object...
What else could be defined in such an object?
-- / Alexander Bokovoy
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-leave@lists.fedorahosted.org
-- Oliver Gutierrez Associate Software Engineer - Desktop Management tools Red Hat
-- Alberto Ruiz Associate Engineering Manager - Desktop Hardware Enablement Red Hat
On Thu, Dec 22, 2016 at 2:11 PM, Oliver Gutierrez ogutierrez@redhat.com wrote:
Hi everybody!
We have been investigating about the process to include Fleet Commander in RHEL and we were aiming to have it included in RHEL 7.4.
Can you tell us the planning for including the FreeIPA/SSSD modifications in RHEL? Will be in RHEL 7.4?
I sincerely don't think we should rush it in for RHEL-7.4.
Alexander said he will work in the missing part by the end of this year/beginning of next year. After that I'll have to work on the SSSD part, have it released upstream and then discuss whether it makes sense or not (and here is a question for Martin Košek) to have it for 7.4, but that's something that shouldn't be discussed here (on this ML) yet.
[snip]
Best Regards, -- Fabiano Fidêncio
sssd-devel@lists.fedorahosted.org
-
Alberto Ruiz -
Alexander Bokovoy -
Fabiano Fidêncio -
Jakub Hrozek -
Oliver Gutierrez -
Oliver Gutiérrez -
Sumit Bose