|
| 1 | +--- |
| 2 | +title: "Azure Operator Nexus: Running bare metal actions directly with nexusctl" |
| 3 | +description: Learn how to bypass Azure and run bare metal actions directly in an emergency using nexusctl. |
| 4 | +author: DanCrank |
| 5 | +ms.author: danielcrank |
| 6 | +ms.service: azure-operator-nexus |
| 7 | +ms.topic: how-to |
| 8 | +ms.date: 08/26/2024 |
| 9 | +ms.custom: template-how-to, devx-track-azurecli |
| 10 | +--- |
| 11 | + |
| 12 | +# Run emergency bare metal actions outside of Azure using nexusctl |
| 13 | + |
| 14 | +This article describes the `nexusctl` utility, which can be used in break-glass (emergency) situations to |
| 15 | +run simple actions on bare metal machines without using the Azure console or command-line interface (CLI). |
| 16 | + |
| 17 | +> [!CAUTION] |
| 18 | +> Do not perform any action against management servers without first consulting with Microsoft support personnel. Doing so could affect the integrity of the Operator Nexus Cluster. |
| 19 | +
|
| 20 | +> [!IMPORTANT] |
| 21 | +> Disruptive command requests against a Kubernetes Control Plane (KCP) node are rejected if there is another disruptive action command already running against another KCP node or if the full KCP is not available. This check is done to maintain the integrity of the Nexus instance and ensure multiple KCP nodes don't go down at once due to simultaneous disruptive actions. If multiple nodes go down, it will break the healthy quorum threshold of the Kubernetes Control Plane. |
| 22 | +> |
| 23 | +> Powering off a KCP node is the only nexusctl action considered disruptive in the context of this check. |
| 24 | +
|
| 25 | +## Prerequisites |
| 26 | + |
| 27 | +1. Create a [BareMetalMachineKeySet](./howto-baremetal-bmm-ssh.md) to allow ssh access to the bare metal machines. |
| 28 | + |
| 29 | +## Overview |
| 30 | + |
| 31 | +`nexusctl` is a stand-alone program that can be run using `nc-toolbox` from an `ssh` session on any management node. Since `nexusctl` is contained in the `nc-toolbox-breakglass` container image and isn't installed directly on the host, it must be run with a command-line like: |
| 32 | + |
| 33 | +``` |
| 34 | +sudo nc-toolbox nc-toolbox-breakglass nexusctl <command> [subcommand] [options] |
| 35 | +``` |
| 36 | + |
| 37 | +(`nc-toolbox` must always be run as root or with `sudo`.) |
| 38 | + |
| 39 | +Like most other command-line programs, the `--help` option can be used with any command or subcommand to see more information: |
| 40 | + |
| 41 | +``` |
| 42 | +sudo nc-toolbox nc-toolbox-breakglass nexusctl --help |
| 43 | +sudo nc-toolbox nc-toolbox-breakglass nexusctl baremetal --help |
| 44 | +sudo nc-toolbox nc-toolbox-breakglass nexusctl baremetal power-off --help |
| 45 | +``` |
| 46 | + |
| 47 | +etc. |
| 48 | + |
| 49 | +## Power off a bare metal machine |
| 50 | + |
| 51 | +A single bare metal machine can be powered off by connecting to a management node via ssh and running the command: |
| 52 | + |
| 53 | +``` |
| 54 | +sudo nc-toolbox nc-toolbox-breakglass nexusctl baremetal power-off --name <machine name> |
| 55 | +``` |
| 56 | + |
| 57 | +If the command is accepted, `nexusctl` responds with another command line that can be used to view the status of the long-running operation. Prefix this command with `sudo nc-toolbox nc-toolbox-breakglass`, as follows: |
| 58 | + |
| 59 | +``` |
| 60 | +sudo nc-toolbox nc-toolbox-breakglass nexusctl baremetal power-off --status --name <machine name> --operation-id <operation-id> |
| 61 | +``` |
| 62 | + |
| 63 | +The status is blank until the operation completes and reaches either a "succeeded" or "failed" state. While it's blank, assume that the operation is still in progress. |
| 64 | + |
| 65 | +## Start a bare metal machine |
| 66 | + |
| 67 | +A single bare metal machine can be started from a power-off state by connecting to a management node via ssh and running the command: |
| 68 | + |
| 69 | +``` |
| 70 | +sudo nc-toolbox nc-toolbox-breakglass nexusctl baremetal start --name <machine name> |
| 71 | +``` |
| 72 | + |
| 73 | +If the command is accepted, `nexusctl` responds with another command line that can be used to view the status of the long-running operation. Prefix this command with `sudo nc-toolbox nc-toolbox-breakglass`, as follows: |
| 74 | + |
| 75 | +``` |
| 76 | +sudo nc-toolbox nc-toolbox-breakglass nexusctl baremetal start --status --name <machine name> --operation-id <operation-id> |
| 77 | +``` |
| 78 | + |
| 79 | +The status is blank until the operation completes and reaches either a "succeeded" or "failed" state. While it's blank, assume that the operation is still in progress. |
| 80 | + |
| 81 | +## Unmanage a bare metal machine (set to unmanaged state) |
| 82 | + |
| 83 | +A single bare metal machine can be moved from a managed state to an unmanaged state by connecting to a management node via ssh and running the command: |
| 84 | + |
| 85 | +``` |
| 86 | +sudo nc-toolbox nc-toolbox-breakglass nexusctl baremetal unmanage --name <machine name> |
| 87 | +``` |
| 88 | + |
| 89 | +While in an unmanaged state, no actions are permitted for that machine, except for returning it to a managed state (see next section). |
| 90 | + |
| 91 | +`unmanage` isn't a long-running command, so there's no associated command to check operation status. |
| 92 | + |
| 93 | +## Manage a bare metal machine (set to managed state) |
| 94 | + |
| 95 | +A single bare metal machine can be moved from an unmanaged state to a managed state by connecting to a management node via ssh and running the command: |
| 96 | + |
| 97 | +``` |
| 98 | +sudo nc-toolbox nc-toolbox-breakglass nexusctl baremetal manage --name <machine name> |
| 99 | +``` |
| 100 | + |
| 101 | +`manage` isn't a long-running command, so there's no associated command to check operation status. |
| 102 | + |
| 103 | +## Create users on storage appliances |
| 104 | + |
| 105 | +User accounts can be created on the Pure storage appliance by connecting to a management node via ssh and running the command: |
| 106 | + |
| 107 | +``` |
| 108 | +sudo nc-toolbox nc-toolbox-breakglass nexusctl storage users create --file <user-file> --keyvault <keyvault> |
| 109 | +``` |
| 110 | + |
| 111 | +`user-file` is the name of a file containing user names and roles, one per line, with a comma between the user name and the role. Allowed roles are `readonly`, `storage_admin`, and `array_admin`. For example: |
| 112 | + |
| 113 | +``` |
| 114 | +userA,readonly |
| 115 | +userB,storage_admin |
| 116 | +userC,array_admin |
| 117 | +``` |
| 118 | + |
| 119 | +`keyvault` is the name of the keyvault in which the user passwords are stored. `nexusctl` generates these passwords. |
| 120 | + |
| 121 | +If a user in the given list already exists on the appliance, their account and password isn't changed. |
| 122 | + |
| 123 | +## Delete users on storage appliances |
| 124 | + |
| 125 | +User accounts can be deleted on the Pure storage appliance by connecting to a management node via ssh and running the command: |
| 126 | + |
| 127 | +``` |
| 128 | +sudo nc-toolbox nc-toolbox-breakglass nexusctl storage users delete --file <user-file> --keyvault <keyvault> |
| 129 | +``` |
| 130 | + |
| 131 | +`user-file` is the name of a file containing user names and roles, as described in the previous section. For each user in the list, if it exists on the appliance with the role specified, the user is deleted and their password removed from the keyvault. If the user doesn't exist on the appliance, or exists with a different role, they aren't deleted. |
| 132 | + |
| 133 | +## List users on storage appliances |
| 134 | + |
| 135 | +The current user accounts on the storage appliance can be listed by connecting to a management node via ssh and running the command: |
| 136 | + |
| 137 | +``` |
| 138 | +sudo nc-toolbox nc-toolbox-breakglass nexusctl storage users get |
| 139 | +``` |
| 140 | + |
| 141 | +## Rotate passwords for users on storage appliances |
| 142 | + |
| 143 | +Passwords can be rotated for users on the Pure storage appliance by connecting to a management node via ssh and running the command: |
| 144 | + |
| 145 | +``` |
| 146 | +sudo nc-toolbox nc-toolbox-breakglass nexusctl storage users rotate --file <user-file> --keyvault <keyvault> |
| 147 | +``` |
| 148 | + |
| 149 | +`user-file` is the name of a file containing user names and roles, as described in the previous section. For each user in the list, if it exists on the appliance with the role specified, a new password is generated for the user and stored in the keyvault. If the user doesn't exist on the appliance, or exists with a different role, their password isn't changed. |
0 commit comments