search

lxc / incus

Powerful system container and virtual machine manager
https://linuxcontainers.org/incus
Apache License 2.0
2.8k stars 224 forks source link

lxd-to-incus not working with headless server #333

Closed mcondarelli closed 11 months ago

mcondarelli commented 11 months ago

Required information

Issue description

I tried to follow instructions but I hit an error:

root@lxd:~# lxd-to-incus 
=> Looking for source server
==> Detected: .deb package
=> Looking for target server
==> Detected: systemd
=> Connecting to source server
=> Connecting to the target server
=> Checking server versions
==> Source version: 5.0.2
==> Target version: 0.4
=> Validating version compatibility
=> Checking that the source server isn't empty
=> Checking that the target server is empty
=> Validating source server configuration

Source server uses obsolete features:
 - Source server is using deprecated key "core.trust_password"
Error: Source server is using incompatible configuration

I assume there's some problem in transporting certificate, but I'm unsure how to proceed. Documentation includes a relevant, but rather terse, paragraph:

The tool will also look for any configuration that is incompatible with Incus and fail before any data is migrated.

A slightly expanded version about how to overcome possible problems would be highly appreciated.

I willing to write it, if someone tells me what should I do in this specific case.

Steps to reproduce

  1. Have a working LXD installation remotely manageable. Note: I issued:

    mcon@lxd:~$ lxc config trust add
To start your first container, try: lxc launch ubuntu:22.04
Or for a virtual machine: lxc launch ubuntu:22.04 --vm

Please provide client name: cinderella
Client cinderella certificate add token:
eyJjbGl...many more chars...wWiJ9

    to be able to remotely manage from cinderella.

  2. Install Incus (daily 27/12/2023, if it matters)
  3. Run lxd-to-incus
stgraber commented 11 months ago

- Source server is using deprecated key "core.trust_password"

That gets solved by unsetting that config key with lxc config unset core.trust_password

mcondarelli commented 11 months ago

Thanks @stgraber, Can you confirm that will not impair my ability to control that server (lxd) from outside (cinderella)? I do not remember explicitly setting that variable (I assume it was implicitly set when I issued lxc config trust add). I am (was) unsure if it is needed or not. If it is "not used anymore" as I seem to understand we can close this. I will reopen (or open a new one) if I get further errors in lxd-to-incus

To be clear, I will:

  1. remove variable with lxc config unset core.trust_password
  2. run again lxd-to-incus
  3. expect to be able to control Incus server using the same certificate as before (or should I re-run incus config trust add?)
stgraber commented 11 months ago

The certificate will be kept as part of the migration.

core.trust_password is a very unsafe way to add clients to a server which predates the current token based method (incus config trust add).

So there's no real reason why anyone would still want to use that, it's just that LXD can't remove it due to API backward compatibility concerns. With Incus we just decided not to offer it from the start.

knutov commented 11 months ago

core.trust_password is simple to use and acceptable/secure enough in some situations.

It's sad it was removed from Incus, I used it a lot and have many scripts that requires core.trust_password.

stgraber commented 11 months ago

Trust tokens work almost the same way except that they can only be used a single time and can be easily revoked and controlled on the server side.

If you absolutely need to have a fixed credential, your other option would be to generate a client certificate, add that to the server trust store and then just use that client certificate on all the clients you need it to.

It's still not great security wise but you'll still avoid brute force attacks and can still revoke the whole thing easily enough.

A variation on that option would be to use the PKI mode instead. Which then allows you to generate as many client certificates as you want and have them be automatically allowed to interact with Incus so long as they're signed by the CA that Incus is using.