to answer your first question, yes I still explored that possibility, and indeed I still embedded dmidecode (with
try; directive as not supported on few arch), usbutils, pciutils and hdparm. These commands are the most basic of the useful ones and we recommend they are installed on computers when the agent is run natively. But we can’t really embed all needed command as:
- the principle of the agent is to run many dedicated modules on conditions, and many conditions are defined by checking a command is runable, as example, we does snap software inventory on the condition the
snap command is runable…
- the idea is anyway to create an inventory with what is available on the computer, not with what we can install ourself (even if few commands like dmidecode can help a lot, so they are recommended)
- some of the command the agent could start are simply proprietary (I think for example all the commands used to parse hardware drive array setups, like tw_cli for 3ware RAID arrays)
- this would make the snap larger and larger and this is not suitable in most usage.
The agent still needs to be run as root to be able to produce the best inventory as many used commands still have security issues if they are used to write things or modify the system. In our PR review process, we only accept command options that make them only affect the output without modifying the system. Indeed, one goal of the agent is really to safely use dangerous commands… and the strict confinement makes most of them unusable or simply not runable/seen.
I firstly tried to use strict confinement for the snap and I still didn’t find the right way to access all what we need to produce the same inventory as if the agent was run natively. The first major issues I found on my own computer (fedora 33) was the computer was reported as running on ubuntu and the software inventory simply failed as
rpm is not runable.
mount-observe, I still tried it and even with others as I used:
plugs: [hardware-observe, system-observe, network-observe, mount-observe, kvm, system-files]
But I didn’t obtain the expected result as explain earlier. I also though to rebase our command search other the snap internally mounted filesystem showing original filesystem but I read somewhere this should be avoided as the mount point is not in the snap specs. I guess this can be used for debug or diagnostic purpose only and we have no guaranty the mount point will not change in the future.
About interfaces like mount-observe, I must admit I’m definitively frustrated as the documentation is so light. I would expect for such important feature a full description of what it provides/permit. And at worst, I would expect a link toward the implementation in source so a dev like me can read the source as documentation (and eventually contribute the doc back for more lazy people ).
About taking care of the snap working reliably across distributions, I think our context is an exception:
- we uses perl which is portable other targeted platforms as a logic layer and to secure requested command runs,
- we makes a real effort to protect our users from any abuse even if no body is perfect and so mistakes are still possible.
And to conclude, having glpi-agent in snap store is finally not a major goal for us as we still can provide native rpm & deb packages for major distros (including Ubuntu ). This would simply be handy to have it in store as it would be a way for some people to obtain quick updates or be able to try development releases or hotfixs. Snap store is really a nice facility.
Sorry for this long comment but I like to be as clear as possible and I apologize if my english is not finally as this is not my primary language. I’m still a new snap enthusiast user