There’s nothing particularly weird with how LXD is built and works. When you build it, you get two binaries lxc and lxd. Put those somewhere reachable in your PATH and write an init script to run the lxd one in the background. Then you can run lxc to talk to it.
Hmmmmmmmm - – interesting - - - especially as nothing was changed from the previous attempt as I had just shut the machine down (it is a test bed machine) waiting for further information. This means that from installation something changed in the install and as I followed instructions on what to do I thought that would mean that I might get something to work. That things were changed internally in the install without my asking for it is quite concerning to me. My tools need to do what I ask them to do and when they don’t do that - - - - well I don’t/won’t use them.
That’s how most client/server software works, the only weirdness is that Go tends to be pretty opinionated as to where it puts things, so you either need to change your PATH to accommodate that or you need to copy the binaries to somewhere like /usr/loca/bin/.
I have also been working with Postgresql - - - it also uses a client/server system. That system doesn’t require any weirdnesses that I’ve been able to find to date.
If you’re looking for an easy experience with proper init scripts, … then yes, you should be using a packaged version of LXD which on Debian currently means using the snap.
Sorry that’s not an option for my systems. The combination of snapd and lxd not only demands regular updates it forces updates. As what I am looking for is process and/or system control I need something that can function without forcing a system reboot when that particular software isn’t updated.
Oh well - - - it seems that linux containers aren’t for my use case.
Thank you for your assistance.