Enhancements to xoa-first-run

[kevemueller]

Is your feature request related to a problem? Please describe. I would like to automate the (initial) configuration of xcp-ng and XOA to replicate the provisioning of hosts that I was used to with that other hypervisor I want to migrate away from. The configuration need goes beyond IP and a password.

Describe the solution you'd like I would like to set additional core parameters at XOA vm creation time, these include:

• an ssh authorized key string for the xoa user (absolute minimum to enable the rest if chosen to be NTH)
• a TLS key + certificate for the XOA web server
• a system wide CA certificate (own CA)
• XOA proxy settings (to reach the updater)
• XOA registration information / auto-registration

This information shall be added to vm-data and picked up by xoa-first-run and templated out into the existing configuration sites inside the appliance. There is no need to track changes to these values in vm-data, this is a one-shot initial configuration.

Describe alternatives you've considered The current alternative is to use a cumbersome interactive authenticated SSH session to perform above tasks. Long-shot alternative is to change the appliance to use cloud-init.

Additional context Happy to provide a merge to xoa-first-run, but failing to find the sources in the repository.

[olivierlambert]

That should be doable, let's see with @julien-f the next steps.

[julien-f]

1. Implemented by system-account-xoa-ssh-key (will be available in the next appliances) :heavy_check_mark:
2. This should be implemented in xo-server
3. This could be done
4. already handled by xoa-updater: xoa-updater-proxy-url (JSON-encoded) :heavy_check_mark:
5. already handled by xoa-updater: xoa-updater-credentials (JSON-encoded, object with email and password property). :heavy_check_mark:

[kevemueller]

Hi Julien,

thank you for looking into this. I am now passing in the following xenstore-data parameters before starting the appliance:

# xe vm-param-get uuid=$uuid param-name=xenstore-data
vm-data/xoa-updater-credentials: {"email": "a@b", "password": "changeme"}; 
vm-data/xoa-updater-proxy-url: {"proxyHost": "proxy.example.com", "proxyPort": 3128, "proxyProtocol": "http", "proxyUser": "a", "proxyPassword": "changeme"}; 
vm-data/system-account-xoa-ssh-key: ssh-ed25519 ... a@b; 
vm-data/system-account-xoa-password: secret; 
vm-data/dns: 1.1.1.1; 
vm-data/gateway: 1.1.1.1; 
vm-data/netmask: 255.255.255.0; 
vm-data/ip: 1.1.1.1; 
vm-data: 

There was an appliance update, but I am not seeing these newvariables to be picked up. Is there any issue with the JSON? I have not found a documentation, so I tried to look at the Node.js sources to come up with the JSON keys.

Could you also please elaborate on what you mean with 'This should be implemented in xo-server'?

[kevemueller]

Update: after digging into some ugly node.js code, the parameter needs to be

xe vm-param-set uuid=$uuid xenstore-data:vm-data/xoa-updater-proxy-url='"http://a@b:proxy.example.com:3128"'

NB: \' is eaten by the shell, \" is needed for JSON.parse, the resulting object must be a string.

So that one I can confirm to be fixed.

[kevemueller]

Update: the provided credentials are ok and in a a good format, the error is transient. A simple systemctl restart xoa-updater later performs the registration and removes the key.

This is highly unsatisfactory to debug and not stable to script.

[kevemueller]

Update: around this topic there is another bug that prevents setting xenstore-data:vm-data/xoa-updater-channel, in a setup which runs through, adding this setting prevents xoa-updater to properly initialize. Neither stable, which should be a no-op, nor latest work. Setting any of these values results in none of the other values of xoa-updater being honored.

[julien-f]

The changes will not be available until we package and publish a new XOA.