It’s been awhile since I last wrote any updates about Fleet Commander, that’s not to say that there hasn’t been any progress since 0.8. In many senses we (Oliver and I) feel like we should present Fleet Commander as a shiny new project now as many changes have gone through and this is the first release we feel is robust enough to call it production ready.
What is Fleet Commander?
For those missing some background, let me introduce Fleet Commander for you, Fleet Commander is an integrated solution for large Linux desktop deployments that provides a configuration management interface that is controlled centrally and that covers desktop, applications and network configuration. For people familiar with Group Policy Objects in Active Directory in Windows, it is very similar.
Many people ask why not use other popular Linux configuration management tools like Ansible or Puppet, the answer is simple, those are designed for servers that run in a controlled environment like a data center or the cloud, it follows a push model where the configuration changes happen as a series of commands run in the server. If something goes wrong it is easy to audit and rollback if you have access to that server. However desktop machines in large corporate environments can run many times behind a NAT on a public WiFi, think a laptop owned by an on-site support engineer that roams from site to site. Fleet Commander pulls a bunch of configuration data and makes it available to apps without running intrusive shell scripts or walking in into users’ $HOME directory. Ansible and puppet did not solve the core problems of desktop session configuration management so we had to create something new.
At Red Hat we talk to many enterprise desktop customers with a mixed environment of Windows, Macs and Linux desktops and our interaction with them has helped us identify this gap in the GNOME ecosystem and motivated us to roll up our sleeves and try to come up with an answer.
How to build a profile
The way Fleet Commander works when building profiles is somewhat interesting compared to its competitors. We’ve inspired our solution on the good old Sabayon tool. On our admin web UI you get a VM desktop session where you run and configure your apps, Fleet Commander will record those changes and list them. The user will select them and the final selection will get bound together as part of the profile.
You can then apply the profile to individual users, groups, hosts or host groups.
Supported apps/settings
Right now we support anything dconf based (GSettings), GNOME Online Accounts, LibreOffice and NetworkManager. In the near future we plan to tackle our main problem which is giving support to browsers, we’re probably going to start just with bookmarks as it is the most demanded use case.
Cockpit integration
The Fleet Commander UI runs on top of the Cockpit admin UI. Cockpit has given us a lot of stuff for free (a basic UI framework, a web service, built-in websocket support for our SPICE javascript client, among many other things).
FreeIPA Integration
A desktop configuration management solution has to be tightly tied to an identity management solution, (like in Active Directory), FreeIPA is the best Free Software corporate identity management project out there and integrating with it allowed us to remove quite a bit of complexity from our code base while improving security. FreeIPA now stores the profile data and the assignments to users, groups and hosts.
SSSD
SSSD is the client daemon that enrolls and authenticates a Linux machine in a FreeIPA or Active Directory domain, having fleet commander hooking into it was a perfect fit for us and also allowed us to remove a bunch of code from previous versions while having a much more robust implementation. SSSD now retrieves and stores the profile data from FreeIPA.
fleet-commander.org
Our new website is live! We have updated introduction materials and documentation and jimmac has put together a great design and layout. Check it out!
I’d like to thank Alexander Bokovoy and Fabiano Fidencio for their invaluable help extending FreeIPA and SSSD to integrate with Fleet Commander and Jakub for his help on the website design. If you want to know more, join us on our IRC channel (#fleet-commander @ freenode) and our GitHub project page.
It is currently available in Fedora 26 and we are in the process of releasing EPEL packages for CentOS/RHEL.
Silicon Island 
Just tried installing admin portal on F27:
sudo dnf install fleet-commander-admin
When I navigate to fleet commander section in cockpit, it fails with:
Can’t initialize Fleet Commander
Error during service connection. Check system logs for details
Log:
Oct 18 15:41:17 computer-name dbus-daemon[1874]: [session uid=1986800001 pid=1874] Activating service name=’org.freedesktop.FleetCommander’ requested by ‘:1.90’ (uid=1986800001 pid=9743 comm=”cockpit-bridge ” label=”unconfined_u:unconfined_r:unconfined_t:s0″)
Oct 18 15:41:17 computer-name org.freedesktop.FleetCommander[1874]: Traceback (most recent call last):
Oct 18 15:41:17 computer-name org.freedesktop.FleetCommander[1874]: File “/usr/lib64/python2.7/runpy.py”, line 174, in _run_module_as_main
Oct 18 15:41:17 computer-name org.freedesktop.FleetCommander[1874]: “__main__”, fname, loader, pkg_name)
Oct 18 15:41:17 computer-name org.freedesktop.FleetCommander[1874]: File “/usr/lib64/python2.7/runpy.py”, line 72, in _run_code
Oct 18 15:41:17 computer-name org.freedesktop.FleetCommander[1874]: exec code in run_globals
Oct 18 15:41:17 computer-name org.freedesktop.FleetCommander[1874]: File “/usr/share/fleet-commander-admin/python/fleetcommander/fcdbus.py”, line 46, in
Oct 18 15:41:17 computer-name org.freedesktop.FleetCommander[1874]: import fcfreeipa
Oct 18 15:41:17 computer-name org.freedesktop.FleetCommander[1874]: File “/usr/share/fleet-commander-admin/python/fleetcommander/fcfreeipa.py”, line 26, in
Oct 18 15:41:17 computer-name org.freedesktop.FleetCommander[1874]: from ipalib import api
Oct 18 15:41:17 computer-name org.freedesktop.FleetCommander[1874]: ImportError: No module named ipalib
Oct 18 15:41:17 computer-name dbus-daemon[1874]: [session uid=1986800001 pid=1874] Activated service ‘org.freedesktop.FleetCommander’ failed: Process org.freedesktop.FleetCommander exited with status 1
Dependency missing somewhere?
LikeLike
Looks like I have to manually install python2-ipalib and python2-ipaclient to make it work (by default python3-XXX versions were installed).
LikeLike
Hi Rob. I’m currently pushing package updates to fix that dependency problem.
If you want to check the status and test them you can check it at Fedora Updates (I can not post links here)
LikeLike
This looks very promising! Any chance to plug-in Debian systems?
LikeLike
Cockpit, FreeIPA and SSSD are present in Debian, so I don’t see why Fleet Commander wouldn’t work there. However somebody has to do the packaging and integration.
LikeLike
I think it’s really unfortunate that design decisions that went into this were made so reliant upon cockpit and FreeIPA. Most heterogeneous environments use Active Directory directly instead of placing FreeIPA between enterprise AD and the endpoint. Since the outcome of creating a desktop profile is just a bundle of dconf settings it also seems kind of weird to create an extremely complicated moustrap to create and distribute those settings. We achieve all of this pretty easily by distributing said dconf settings via Puppet.
If you had problems with leveraging Puppet or Ansible to manage desktops, addressing those issues directly probably would have been time better spent than coming up with completely new infrastructure to manage, in my humble sysadmin opinion.
LikeLike
Hey Kodiak,
We’re working on AD integration as we speak. The very reason we’re using FreeIPA/SSSD is because on the SSSD end we have a single point for profile gathering/caching for both FreeIPA and AD domains, so this was taken into account. We designed Fleet Commander profile delivery pretty much after AD’s model.
As per the Cockpit integration, we need a management UI _somewhere_ to create the Linux specific profiles and Cockpit makes a lot of sense as a management interface in a Linux environment.
Puppet and Ansible are just not fit by design is not a matter of a feature gap but rather a “sqare peg into a round hole” kind of situation, they assume things like ssh and are pretty much tailored to host-wide configuration rather than per session configuration. It’s for the most part a push model and the assumptions about access to the machines do not fit well with desktop environments that might be behind a firewall and are hard to recover if something goes wrong.
At the point where we want familiarity with AD environments we want to pull data using an SSSD plugin for both GPOs under AD and FC profiles under FreeIPA.
dconf is a write database in people’s homes, we needed to teach dconf to have another layer for sysadmin provided outside of the home, we certainly didn’t want a situation where an Ansible/Puppet like tool would walk into each users’ home so we added support in dconf upstream and LibreOffice for this and reused the profile functionality from Chrome/Firefox to deploy.
Having said that, nothing stops you from delivering dconf profiles using Ansible or Puppet, it’s just an odd fit in the overall architecture and it’s a solution that didn’t bring anything in to attract the type of users we’re after (AD admins).
LikeLike