There are hardware monitoring tools that are published by the vendors in binary format only. Some of the binaries require a level of access not provided by plugs such as hardware-observe or system-observe. This is the case of the sas2ircu binary published by Huawei under “FusionServer Tools InfoCollect” archive.
For such reason, I request this snap to be allowed as non-confined. When the snap is in strict confinement, binary always returns code 1.
Other snaps I’m working on are sas3ircu and megacli.
need /dev/mpt2ctl and /dev/mpt2ctl_wd added to the device cgroup
add /dev/mpt2ctl{,_wd} rw, to the apparmor policy
Beyond that, it is just ioctls that are required. An interface implementing this would be easy enough, but it isn’t clear to me what should be in the interface, and therefore, what it should be called. We have hardware-observe which allows reading from various hardware, so hardware-control seems like an option, but with a name like that, we’d eventually add other accesses to it and while grouping reads of hardware seems somewhat ok, grouping writes feels wrong (we did just add a new cpu-control recently after all). I think I’m leaning towards something related to ‘disks’, eg, disks-control. Perhaps in it we would allow access to block devices, as is suggested in Classic Confinement Request for the wimlib Snap and it could also cover smartctl and hdparm (Snap interface to run smartctl) along with /dev/mpt2ctl.
I don’t think we should conflate basic read/write access to (some) block-devices, with control over params etc. It still feels like we should have a more basic block-devices interface as well.
Sorry, I’m arguing that a block-device-control is not the answer to something like wimlib that only needs to read or write block devices under /dev/* , we had a silimar discussion about fwupd where Gustavo proposed block-devices.
@pedronis - I understood what you meant and that you wanted two separate interfaces, one with access to block devices and one with accesses for sas2ircu, smartctl and hdparm. My question was about naming the interfaces. @niemeyer said "something likeblock-devices" for the former, but my point is that “block-devices” doesn’t fit our current naming pattern. If you prefer block-devices, I’m not opposed to that. What should the 2nd interface (the one for smartctl, hdparm and sas2ircu) be named? harddrive-control? disks-control? something else?
can you explain why you think it doesn’t fit the current patterns? notice that actually some our singular names are problematic with hindsight like “camera” for an interface that let access all cameras.
It depends on what is in the interface of course. If we had smartctl in there, I would strongly argue for ‘-control’, but that will now be in a different interface. Since it will just be block devices, holding up the camera interface as an interface (though it should be plural like you said) supports that ‘block-devices’ is suitable. There is a good deal of ‘control’ granted with this interface, since one can control partitions, filesystems, data, etc, but the simple ‘block-devices’ is clear enough I suppose (I did say I wasn’t opposed to it).
What would be the best approach while support for “block-devices” is being discussed/worked out? Would it be possible to get [1] approved (in classic mode) until this is supported so I could push a newer version in strict mode when such interface is available?
I must admit I’m not sure if a snap can be refreshed and moved from classic to strict automatically, just by updating the revision (and having such revision built using strict confinement).
@aluria - the block-devices interface (or whatever it will be named) could be implemented quickly. To answer your question, my understanding is upgrades from classic to strict is supported but the other way around is not (less strict to more strict is ok).
@pedronis - can you comment on a finalized name? In the meantime, what do you think about allowing classic for now?
Is the ETA for having this new interface available short or could I ask for classic snaps approval for megacli, sas2ircu, sas3ircu snaps in the meantime?
