LXD built successfully
root@debianstable:~/go/src/github.com/lxc/lxd# echo “root:1000000:65536” | sudo tee -a /etc/subuid /etc/subgid
root:1000000:65536
root@debianstable:~/go/src/github.com/lxc/lxd# sudo -E $GOPATH/bin/lxd --group sudo
WARN[06-21|11:23:01] AppArmor support has been disabled because of lack of kernel support
WARN[06-21|11:23:01] CGroup memory swap accounting is disabled, swap limits will be ignored.
now it says:
If it is your first time running LXD on this machine, you should also run : lxd init
To start your first container, try: lxc launch ubuntu:16.04
Error: Get http://unix.socket/1.0: dial unix /var/lib/lxd/unix.socket: connect: no such file or directory
root@debianstable:~/go/bin# lxd init
bash: lxd: command not found
root@debianstable:~/go/bin# $GOPATH/bin/lxd init
Error: Failed to connect to local LXD: Get http://unix.socket/1.0: dial unix /var/lib/lxd/unix.socket: connect: no such file or directory
root@debianstable:~/go/bin# $GOPATH/bin/lxc/lxd init
bash: /root/go/bin/lxc/lxd: Not a directory
root@debianstable:~/go/bin# $GOPATH/bin/lxc/lxd/lxd init
bash: /root/go/bin/lxc/lxd/lxd: Not a directory
root@debianstable:~/go/bin# ls
deps fuidshift lxc lxd lxd-benchmark lxd-p2c macaroon-identity
It seems like nothing is straightforward. I’m really not sure how to preface commands so something happens. This environment is VERY different than working from one where it is first install snapd and then use snap to install lxd.
Did you have the daemon running in another terminal while you were running lxc list and lxd init above?
Building by hand is always going to be more difficult than using packages, that’s to be expected. Packages ship init scripts and installation scripts to put things in the right place and run the services in the background, when building by hand, you have none of that so need to make sure to start things in the right way and keep the daemon running.
root@debianstable:~/go/src/github.com/lxc/lxd# sudo -E $GOPATH/bin/lxd --group sudo
WARN[06-21|11:23:01] AppArmor support has been disabled because of lack of kernel support
WARN[06-21|11:23:01] CGroup memory swap accounting is disabled, swap limits will be ignored.
^C
So do that again but don’t ctrl+c it. Then in another terminal, run the other commands.
memyself@debiantesting:~$ sudo -E $GOPATH/bin/lxd --group sudo
WARN[06-26|08:16:05] AppArmor support has been disabled because ‘apparmor_parser’ couldn’t be found
WARN[06-26|08:16:05] CGroup memory swap accounting is disabled, swap limits will be ignored.
the above is in the first terminal.
The second gives:
memyself@debiantesting:~/go/bin$ lxc list
bash: lxc: command not found
memyself@debiantesting:~/go/bin$ lxd init
bash: lxd: command not found
also tried:
memyself@debiantesting:~/go/bin$ $GOPATH/bin/lxc list
bash: /bin/lxc: No such file or directory
yet:
memyself@debiantesting:~/go/bin$ ls
deps fuidshift lxc lxd lxd-benchmark lxd-p2c macaroon-identity
So, as far as I can tell - - - - well - - - bluntly - - - - nothing is working.
OK - – its clear that it doesn’t exist and its also clear that the lxc/lxd combination also doesn’t seem to be working.
So - - - what to do?
(Are things set up this way so that to maintain any sanity one will ‘just use snapd’?)
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.
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/.
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.
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.