Making the LVFS and fwupd work in the enterprise

I’ve spent some time over the weekend thinking about how firmware updates should work when you’re an enterprise, i.e. when you’re responsible for more than about 100 broadly similar computers. Some companies using fwupd right now are managing over a 100,000 devices (!) using a variety of non-awesome workarounds. So far we’ve not had a very good story on how to make firmware updates for corporate or IoT “just work” as we’ve been concentrating on the desktop use-cases.

We’ve started working on some functionality in fwupd to install an optional “agent” that reports the versions of firmware installed to a central internal web service daily, so that the site admin can see what computers are not up-to-date with the latest firmware updates. I’d expect there the admin could also approve updates after in-house QA testing, and also rate-limit the flow of updates to hardware of the same type. The reference web app would visually look like some kind of dashboard, although I’d be happy to also plug this information into existing system management systems like Lenovo XClarity or even Red Hat Satellite. The deliverable here would be to provide the information and the mechanism that can be used to implement whatever policy the management console defines.

This stuff isn’t particularly relevant to the average Linux user, and enabling this special “enterprise mode” would involve spinning up a web app on the internal network, manually enabling a systemd timer on all clients in the enterprise and also perhaps setting up a LVFS mirror. The console certainly isn’t the kind of thing you’d run on the Internet or be provided by the LVFS.

If this sounds interesting, I’d love to hear some comments, feedback and wish list items. We’re at the pre-alpha stage right now and are just prototyping some toy code. Thanks!

Published by

hughsie

Richard has over 10 years of experience developing open source software. He is the maintainer of GNOME Software, PackageKit, GNOME Packagekit, GNOME Power Manager, GNOME Color Manager, colord, and UPower and also contributes to many other projects and opensource standards. Richard has three main areas of interest on the free desktop, color management, package management, and power management. Richard graduated a few years ago from the University of Surrey with a Masters in Electronics Engineering. He now works for Red Hat in the desktop group, and also manages a company selling open source calibration equipment. Richard's outside interests include taking photos and eating good food.

15 thoughts on “Making the LVFS and fwupd work in the enterprise”

    1. Isn’t cockpit more for single-machine configuration? Red Hat Satellite seems to be the fleet management thing right now.

    1. Isn’t there an impedance mismatch with deployment tools v.s. keeping a machine updated? I’ll certainly do some research on those projects tho, thanks.

      1. Eg It’s more the inventory part of these software suites I was referring to (facter (https://docs.puppet.com/facter/) for puppet, unknown for others). These usually integrate to things like foreman and you can query your fleet and see what’s installed or not based on facts.

        1. It’s worth noting that Foreman can use Puppet (or Ansible, with the right plugin) to perform tasks on the hosts that it manages. A Puppet plugin or Ansible module could be a step towards integration with Foreman.

          Red Hat Satellite, mentioned above, is Foreman plus plugins.

          1. I’d be really interested if you have more details about what Foreman expects. I’ve been talking to James about mgmt and it seems like if we can give the management layer all the methods and metadata about the system it’s pretty easy to wire wire everything together.

  3. I think the problem with this plan is that different enterprises use wildly different monitoring setups, so whatever you’ll do won’t integrate with the majority of them. And the last thing people need is to setup yet another bespoke single-use infrastructure.

    Thus I think if you want to do anything in this space it should be providing building blocks so that people can easily integrate it into their own setups, e.g. that the fwupd daemon would have some simple http(s) server spitting out JSON, or maybe a d-bus(?) API that some local monitoring agent (e.g. a prometheus plugin?) could query, or something like that.

    That being said, what I’m personally waiting and hoping for would be to get the server vendors onboard, so I could update server firmware (including peripherals, disks, etc.!) via LVFS.

  4. I’d suggest to look at OCZ StoragePeek solution (I’ve not used it personally, but have heard good things about it).

  6. Rather than yet another daemon, perhaps providing command line utilities that one could call from their monitoring system would be more useful. That way one could monitor out of date systems through existing monitoring systems, and then use already-existing automation tooling around fwupd to update it.

    [WORDPRESS HASHCASH] The poster sent us ‘0 which is not a hashcash value.

    1. It’s not a daemon, it’s a systemd timer that runs an executable. Valid points about making it more useful as a component, thanks.

  7. I also think this could be done with ansible, puppet, chef.. and others provisioning, configuration management, and application deployment tools.
    I would focus in give fwupdmgr the right options and outputs so it’s easy to work with (I don’t know the limitations right now), so each company can use what they already have in-house.
    OCS-Inventory would be another product to check/collaborate for support.

Comments are closed.