Auxiliary root access

Two commands create and remove a root account named xuser. They are F5’s, absent from the debug API, and they are the escape hatch for work the admin account cannot do.

These change the node's account state, and are not run here

get-auxilary-root-access-to-node creates a root user. That is a change to the node that outlives your session, and it is not something to do exploratively. Both commands are documented from the appliance’s own completion menu; neither was run, and the harvest harness refuses both.

The misspelling of “auxiliary” is the appliance’s, not a typo in this page. Type it as shown or the command will not be found.

get-auxilary-root-access-to-node

Creates the xuser root account.

execcli get-auxilary-root-access-to-node

When this is genuinely the answer. Some diagnostics are simply unreachable as admin. The clearest verified example on this build is kubelet-get-params, which fails with open /etc/vpm/kubelet-custom-params.txt: permission denied — the file exists and the admin account cannot read it. Root access is the documented route to that class of problem.

Before reaching for it, consider whether the debug API already answers the question. Its exec tier runs privileged commands without creating a persistent account, which is a smaller change to the node.

remove-auxilary-root-access-to-node

Deletes the xuser account.

execcli remove-auxilary-root-access-to-node

Run this when you are done. A root account created for one diagnostic session and left in place is a standing credential on the appliance that nothing will remind you about. Treat create and remove as a pair, in the same session, the way vifdump and vifdump-file-rm are a pair.

What was not established

Neither command’s output is recorded, so this page cannot tell you what success looks like, what password or key xuser is created with, or whether removal is refused while a session is open. Those need a node you are willing to modify.