Debugging

Here are different ways to help troubleshooting lxc and lxd code.

lxc --debug

Adding --debug flag to any client command will give extra information about internals. If there is no useful info, it can be added with the logging call:

logger.Debugf("Hello: %s", "Debug")

lxc monitor

This command will monitor messages as they appear on remote server.

lxd --debug

Shutting down lxd server and running it in foreground with --debug flag will bring a lot of (hopefully) useful info:

systemctl stop lxd lxd.socket
lxd --debug --group lxd
 ```

`--group lxd` is needed to grant access to unprivileged users in this
group.


### REST API through local socket

On server side the most easy way is to communicate with LXD through
local socket. This command accesses `GET /1.0` and formats JSON into
human readable form using [jq](https://stedolan.github.io/jq/tutorial/)
utility:

```bash
curl --unix-socket /var/lib/lxd/unix.socket lxd/1.0 | jq .

See the RESTful API for available API.

REST API through HTTPS

HTTPS connection to LXD requires valid client certificate, generated in ~/.config/lxc/client.crt on first lxc remote add. This certificate should be passed to connection tools for authentication and encryption.

Examining certificate. In case you are curious:

openssl x509 -in client.crt -purpose

Among the lines you should see:

Certificate purposes:
SSL client : Yes

with command line tools

wget --no-check-certificate https://127.0.0.1:8443/1.0 --certificate=$HOME/.config/lxc/client.crt --private-key=$HOME/.config/lxc/client.key -O - -q

with browser

Some browser plugins provide convenient interface to create, modify and replay web requests. To authenticate againsg LXD server, convert lxc client certificate into importable format and import it into browser.

For example this produces client.pfx in Windows-compatible format:

openssl pkcs12 -clcerts -inkey client.key -in client.crt -export -out client.pfx

After that, opening https://127.0.0.1:8443/1.0 should work as expected.