School labs, Education, (grand)Parents and fleet management patterns

[blaisep]

Can anyone suggest a solution for the computer lab scenario ?

Using Silverblue/Aurora for a few years now, I decided to set up my kids' laptops to reduce the MS and Apple dependency. It's been decades since I have had to manage a fleet of machines used by other people but I didn't want to manually support the machines knowing how they can find ingenious ways to break things.
So I looked around for the generally accepted way of managing school labs (a similar use case). I know that Chromebooks at our school seem to be managed individually, but assume that is because of a lack of IT expertise.

I expected this to be a no brainer, but searching for schools and education the closest I got was a detailed question about
education lab software distribution. It helped, but only for part of the problem.

Aren't Linux laptops an alternative to Chromebooks? Is there already a place where those people hang out?
I expected that some one would have a SaltStack/Puppet/Ansible repo full of templates for things like software distribution, user management, alert and log aggregation.
This seems like lifetime employment for Linux admins.

NB: useful responses are I tried XXX and decided YYY
less useful you should be able to use ....

[castrojo]

I expected that some one would have a SaltStack/Puppet/Ansible repo full of templates for things like software distribution, user management, alert and log aggregation.

Those days are gone we can just use container tools to manage everything. We're working on this:

https://projectbluefin.io/server/

This seems like lifetime employment for Linux admins.

Yes now that K8s and Bluefin are united we can work on this next.

[p-bo]

Hello @blaisep,

if also centralized desktop (and apps) settings management is what you have on mind, situation is less than optimal.
The best solution was Fleet Commander, but it was abandoned unfortunately.
Other solutions are either waporware (Zorin Grid) or highly depended on MS architecture (adsys, himmelblau).
Some more info there:
fleet-commander/fc-admin#278

[castrojo]

You don't need any of these - the entire point is to get rid of all of that stuff.

You manage the images like you do any other server thing, like how we're doing it here.

[p-bo]

That will be great, but please how it will cover use case where:

• there is fleet of managed desktops (think of school, institution, company, etc)
• correctness of every single desktop environment and app setting is IT department responsibility (personal computers are just tools for education/work done there), which also relies that every single computer has appropriate settings to be able to provide support/guidance to users (custom users settings are causing problems/misunderstandings there)
• managed settings of desktop environment/apps is stored in dot files/directories in user home directories, thus layering above system itself probably isn't much helpful here (but hopefully I'm wrong)
• dot files with desktop environment / apps settings are undergoing massive changes in each new version release (options deprecated, added, renamed, spited, merged, etc) so continuous updating of templates for orchestration tools (thing of Puppet, Salt, Ansible, Chef, etc) is overwhelming task and there is not any central repository, where to share these recipes to don't have to do it whole itself in every single organization independently (waste of redundant human work)
  (In Windows world, this is done by ADMX templates - often supplied by software vendors themselves)

The most close was Fleet Commander (capturing changes in settings on template computer and distribute it to others managed ones).

[castrojo]

I do not understand the question, you've described Bluefin. You'd use a template or fork or start from scratch, etc. You'd be doing what we do now except they'd be your decisions, your apps, etc.

[p-bo]

I'm sorry to cannot to describe it better, but lets imagine you have to set myriad of things like for example disable inactivity autosuspend on AC power in Gnome settings on lot of bluefin installations (but only in selected groups of machines) and need some tooling how to do it at scale (and without reinventing wheel).
Maintaining own respin of Ublue-OS just to achieve these things in every single organization seems perhaps like overkill there.

Meanwhile premade tooling (templates) for these things on other platforms:

• Windows - legacy Active Directory or modern Intune MDM (both with predefined settings templates)

• macOS - school/business manager for basic things, 3rd party MDM systems for broader scope of predefined centralized settings

• ChromeOS (and next Googlebooks Aluminium) - predefined device policies to choose settings from in admin console

• Linux desktop - nothing premade (everyone must maintain their own ansible/salt/puppet/cheff/etc. receipes like on servers) or distro respins (think of that unfortunate Munchen LIMUX)
  (because Redhat abandoned RHEL desktop (thus also Fleet Commander) and for its (roughly continuation) RHEL Workstation centralized settings management isn't needed anymore - they are targeting AV industry, where users have winbooks/macbooks/chromebooks in paralell to linux workstations to have that managed secondary desktops to be compatible with rest of organization)

And that is exactly the reason, why is problem with Linux desktop settings management in organizations except really small ones and (in oposit) huge ones. In first case, admin is managing few computers simply by clicking one by one, in the second one they have IT team large enough to be able to maintain their own set of ansible/salt/puppet/cheff/etc receipes for desktops (much broader set of settings than for servers) as they do for servers. Or custom distributions respin.

But organizations of middle size have too much computers to manage them one by one but in the same time have to few IT staffers to maintain their own set of of ansible/salt/puppet/cheff/etc receipes for desktops (much larger set of settings) as they do for servers. Or custom distributions respin (or templating, forking, starting from scratch, etc).

Once again, sorry for not able to explain this more clearly - whole concept maybe isn't comprehensible from point of people, who never wasn't responsible (no offense intended please) for fleet of end users endpoints desktops and sheer amount of constantly changing implementations of settings on them (i.e. need for some abstraction layer to not have to cope directly with registry settings, config files content, etc, which are subject of constant change due new versions, thus unmanageable this direct way over time).

But hopefully this all is just old way of doing things and next time when someone will want toggle some random settings in desktop env / app at scale (but also with granularity based on something) , K8s&Bluefin is the answer, just for present time not comprehensible to non-devops people (old school admins) ;-)

Many thanks for bearing with my incomprehension :-)

[castrojo]

Maintaining own respin of Ublue-OS just to achieve these things in every single organization seems perhaps like overkill there.

Every single tool you mentioned is more complex, costs money, and gives you less control and introduces vendor lockin. Millions of people know how to make these systems, we picked this on purpose.

be able to maintain their own set of ansible/salt/puppet/cheff/etc receipes for desktops (much broader set of settings than for servers) as they do for servers.

The reason we picked bootc and cloud native tech so we can get rid of all of that.

K8s&Bluefin is the answer, just for present time not comprehensible to non-devops people (old school admins) ;-)

I had my students do it. Here's a picture. I don't have the exact year but the monitors should help.

Here is the file that controls your desktop:

https://github.com/projectbluefin/common/blob/f6a54f251a787bfecabf2010b38387cb3579f0bf/system_files/bluefin/usr/share/glib-2.0/schemas/zz0-bluefin-modifications.gschema.override

And here are the instructions I used back then. And then 5 years ago when we started Bluefin, and it all applies today: https://help.gnome.org/system-admin-guide/

It's the same on any GNOME system, it's designed to be deployed at mass scale, that's exactly what we do.

[castrojo]

One of those kids is going to spend a weekend and disrupt this entire industry and burn it down. And we get front row seats!

[p-bo]

One of those kids is going to spend a weekend and disrupt this entire industry and burn it down. And we get front row seats!

That would be great!

To finally have premade (ie. be able to concentrate to just choosing what to change to on/off (or to what value), without continued maintenance of recipes with how to do it by own) solution for managing fleet of Linux desktops at scale, it would be equivalent to moment of Steam released for Linux (inability to run - at least for regular users - AAA games on Linux blocked spreading of Linux on home computers for decades). Unavailability of centralized settings management (roughly on pair with above mentioned ones) is blocking spreading of Linux desktops (not the case of servers) in middle sized organizations/companies for decades too.

Looking for it :-)