I am fully onboard with the appliance model of IncusOS - in fact it’s partly what attracts me to it.
But the deliberate inability to access a shell or run diagnostic commands I find a real challenge. Some use cases:
renaming ZFS datasets on pre-existing disks I am adding to IncusOS as custom storage volumes (with existing data)
Checking file ownership of data in my custom volumes that I am sharing between containers (based on host user namespace) - so that I can ensure the bindmounts are providing the correct idmaps
Troubleshooting network access to the host (e.g. ss, ping, traceroute, tcpdump)
Is there a thought on providing shell access in the future for this - or alternative ways to perform the above examples?
Cleanest would have been to attach the disk to a VM and get the ZFS pool in the desired state prior to importing it into IncusOS. Now that it’s imported, you can go the hackish route of using a privileged container with /dev/zfs passed in as a unix-char device.
That one you should be able to handle by using incus storage volume file mount to get remote access to the volume. Alternative would be to attach it to a privileged container, but the SFTP API should work just fine for this and be easier/cleaner.
For ping/traceroute, easiest is to do it from a container running on the system. You’ll just get an extra hop but it’s otherwise still fine. Those are also good candidates for the debug API but because you can usually use a container, it’s not been as important as tcpdump.
ss (connections) is something we could add too alongside our existing ps (processes) debug API endpoint, feel free to file a feature request for it on the IncusOS repo.