[WIP] Post inventory to server after install #2396
Conversation
There was a problem hiding this comment.
In general, this is a very welcome addition. However, my biggest concern is /config vs. /persist and also -- what would be the danger of trying to post it immediately and if that fails delaying it until the actual boot of EVE @eriknordmark ?
conf/grub.cfg
Outdated
| @@ -3,3 +3,5 @@ | |||
| # set_global eve_flavor kvm | |||
| # to force booting in Xen mode, uncomment: | |||
| # set_global eve_flavor xen | |||
| # set_global dom0_cmdline eve_inventory_server=http://10.129.17.151:8888 | |||
| set_global dom0_cmdline "$dom0_cmdline eve_inventory_server=http://192.168.1.55:8888" | |||
There was a problem hiding this comment.
surely last line was included by accident?
There was a problem hiding this comment.
This is an example in this draft. Will be removed.
| mkdir /config/inventory | ||
| echo "$INVENTORY_SERVER" >/config/inventory/server | ||
| cp -rp "$REPORT" /config/inventory/ | ||
| fi |
There was a problem hiding this comment.
I really don't like this to go into /config since we're still trying to make config as small (and immutable) as possible. Why can't we put this into /persist?
There was a problem hiding this comment.
In general, this is a very welcome addition. However, my biggest concern is /config vs. /persist and also -- what would be the danger of trying to post it immediately and if that fails delaying it until the actual boot of EVE @eriknordmark ?
I'd love to change that, but the issues are that when the installer is running we do not have a /persist (that is created by storage-init on first boot), nor do we have a networking configured in the Linux kernel.
There was a problem hiding this comment.
While strictly speaking true, as we've discussed this shouldn't be too big of a deal to change that if needed. However, I'd agree -- for the proptotype/WIP it doesn't matter where it is.
|
Hey @eriknordmark -- I see changes, but you still planning to move this all the way to |
Either that (which means running the storage-init container at install time to create /persist), or use the network to push the inventory to the server (including retrying forever?) to the inventory server. In the latter case we don't need to save it on the device. But there are some benefits of having the model json (in particular the iommu groups) as determined at install time before we boot into some particular hypervisor and save that for when EVE-OS is running. So that means creating /persist/ |
| { | ||
| "destination": "/persist", | ||
| "type": "tmpfs", | ||
| "source": "tmpfs", | ||
| "options": [ | ||
| "rw" | ||
| ] | ||
| }, |
There was a problem hiding this comment.
Please do not mount tmpfs to /persist, we prepare and mount persist partition/pool to /persist during installation.
Signed-off-by: eriknordmark <erik@zededa.com>
Signed-off-by: eriknordmark <erik@zededa.com>
Signed-off-by: eriknordmark <erik@zededa.com>
Signed-off-by: eriknordmark <erik@zededa.com>
Signed-off-by: eriknordmark <erik@zededa.com>
Signed-off-by: eriknordmark <erik@zededa.com>
This introduces a eve_inventory_server URL which can either be set from ipxe or in config/grub.cfg. If that is set it the EVE-OS will POST to that URL when it boots after the install is complete.
The POSTs are retried until they are all accepted by the server at that URL.
This initial implementation does not use any secure client identifier hence only makes sense with server on a locally secure network. A possible improvement is to use the /config/onboarding.key.pem to sign the payloads using the authcontainer we use for the rest of the API, but that implies a server which does authcontainer verification and protobuf decode of the payloads.