| |
@@ -34,74 +34,30 @@
|
| |
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.
|
| |
+ * a Cockpit plugin that connects to the freeIPA and sets up profiles
|
| |
+ for different users.
|
| |
+ * a client side component activated by SSSD, which applies all the
|
| |
+ profiles retrieved by the latter.
|
| |
|
| |
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.
|
| |
+ component 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_deskprofile = 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.
|
| |
+ This provider will be enabled by default and can be disabled by setting
|
| |
+ ``ipa_enable_deskprofile = False``.
|
| |
|
| |
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).
|
| |
+ details) and the FC client will be DBus activated by SSSD.
|
| |
|
| |
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/deskprofile.conf
|
| |
-
|
| |
- [Service]
|
| |
- Type=oneshot
|
| |
- ExecStartPre=/bin/cp -a /usr/share/fleetcommander/sssd.snippet.conf /etc/sssd/conf.d/deskprofile.conf
|
| |
- ExecStart=/bin/systemctl try-restart sssd
|
| |
- ExecStopPos=/bin/rm /etc/sssd/conf.d/deskprofile.conf
|
| |
-
|
| |
-
|
| |
- This systemd unit might be stored in
|
| |
- ``/lib/systemd/system/sssd-deskprofile.service``.
|
| |
-
|
| |
- The sssd.snippet.conf file should look like::
|
| |
-
|
| |
- [domain/example.com]
|
| |
- ipa_enable_deskprofile = True
|
| |
-
|
| |
- Having to setup the domain name is something that must be done either by
|
| |
- the administrator or by the FC client daemon. Currently we have a Python
|
| |
- API that provides the domains in the config file and maybe the FC client
|
| |
- daemon could use that or maybe IPA client could generate the file and
|
| |
- put it somewhere where it's inactive for FC client daemon to pick it up.
|
| |
- It's a problem that still has to be solved on FC client daemon's side.
|
| |
|
| |
Looking up the Fleet Commander profiles and storing the JSON profile data
|
| |
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
| |
@@ -136,14 +92,14 @@
|
| |
|
| |
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
|
| |
+ ``/var/lib/sss/deskprofile/`` with per-user subdirectories. So each
|
| |
per-user JSON file would be stored at
|
| |
``/var/lib/sss/deskprofile/<domain>/<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
|
| |
+ client component 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
|
| |
@@ -172,6 +128,16 @@
|
| |
proposed option name is ``ipa_enable_deskprofile`` with boolean
|
| |
semantics.
|
| |
|
| |
+ Disabling 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, and this functionality will be enabled by default in
|
| |
+ order to have it working "out of the box" for Fleet Commander's users,
|
| |
+ we should keep a way to disable the functionality if needed. It can be
|
| |
+ easily done by setting ``ipa_enable_deskprofile = False``, under the
|
| |
+ domain's section, in the ``sssd.conf`` file.
|
| |
+
|
| |
How To Test
|
| |
-----------
|
| |
Please see the use-cases above.
|
| |
@@ -182,7 +148,7 @@
|
| |
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.
|
| |
+ client side component.
|
| |
|
| |
Authors
|
| |
-------
|
| |
fidencio
commented 6 years ago
Let's update the FC's integration design page in order to have it
matching with the current state of the work.
The main changes here are that FleetCommander is not a daemon anymore,
but a client side component that will be DBus activated by SSSD when the
latter retrieves the profiles that must be applied.
Signed-off-by: Fabiano Fidêncio fidencio@redhat.com