Manual for nodegroupattrib

nodegroupattrib(8) - List or change confluent nodegroup attributes

nodegroupattrib(8)
nodegroupattrib(8)

NAME

nodegroupattrib - List or change confluent nodegroup attributes

SYNOPSIS

nodegroupattrib <group> [ current | all ]
nodegroupattrib <group> [<nodeattribute>...]
nodegroupattrib <group> [<nodeattribute1=value1> <nodeattribute2=value2> ...]
nodegroupattrib <group> [-c] [<nodeattribute1> <nodeattribute2=value2> ...]
nodeattrib -p <noderange> <nodeattribute1> <nodeattribute2> ...

DESCRIPTION

nodegroupattrip queries the confluent server to get information about nodes. In the simplest form, it simply takes the given group and lists the attributes of that group.

Contrasted with nodeattrib(8), settings managed by nodegroupattrib will be added and removed from a node as it is added or removed from a group. If an attribute is set using nodeattrib(8) against a noderange(5) that happens to be a group name, nodeattrib(8) individually sets attributes directly on each individual node that is currently a member of that group. Removing group membership or adding a new node after using the nodeattrib(8) command will not have attributes change automatically. It's easiest to see by using the nodeattrib <noderange> -b to understand how the attributes are set on the node versus a group to which a node belongs.

OPTIONS

-b, --blame: Show information about how attributes inherited
-e, --environment: Set attributes, but from environment variable of same name
-c, --clear: Clear specified nodeattributes.
-p, --prompt: Prompt for attribute values interactively
-h, --help: Show help message and exit

EXAMPLES

Show attributes of a group called demogrp: # nodegroupattrib demogrp
demogrp: hardwaremanagement.manager: (will derive from expression 10.30.{n0/255}.{n0%255})
demogrp: nodes: n12,n13,n10,n11,n9,n1,n2,n3,n4
Set location.u to be the remainder of first number in node name when divided by 42: # nodegroupattrib demogrp location.u={n1%42}

ATTRIBUTES

collective.manager: When in collective mode, the member of the collective currently considered to be responsible for this node. At a future date, this may be modified automatically if another attribute indicates candidate managers, either for high availability or load balancing purposes.
collective.managercandidates: A noderange of nodes permitted to be a manager for the node. This controls failover and deployment. If not defined, all managers may deploy and no automatic failover will be performed. Using this requires that collective members be defined as nodes for noderange expansion
console.logging: Indicate logging level to apply to console. Valid values are currently "full", "interactive", "memory", and "none". Defaults to "full".
console.method: Indicate the method used to access the console of the managed node. If not specified, then console is disabled. "ipmi" should be specified for most systems if console is desired.
crypted.grubpassword: Password required to modify grub behavior at boot
crypted.rootpassword: The password of the local root password. This is stored as a non-recoverable hash. If unspecified and confluent is used to deploy, then login at console using password will be impossible and only key based login can work for root.
crypted.selfapikey: Crypt of api key for self api requests by node
deployment.apiarmed: Indicates whether the node authentication token interface is armed. If set to once, it will grant only the next request. If set to continuous, will allow many requests, which greatly reduces security, particularly when connected to untrusted networks. Should not be set unless an OS deployment is pending on the node. Generally this is not directly modified, but is modified by the "nodedeploy" command
deployment.encryptboot: Specify a strategy for encrypting the volume. Support for this setting is currently only enabled for RedHat 8 and CentOS 8 profiles. If blank or unset, no encryption is done. If set to "tpm2" then the OS will freely decrypt so long as the same Trusted Platform Module is available to decrypt the volume. Note that versions earlier than 8.2 may malfunction at boot time if this feature is attempted, depending on configuration.
deployment.pendingprofile: An OS profile that is pending deployment. This indicates to the network boot subsystem what should be offered when a potential network boot request comes in
deployment.profile: The profile that has most recently reported completion of deployment. Note that an image may opt to leave itself both current and pending, for example a stateless profile would be both after first boot.
deployment.sealedapikey: This attribute is used by some images to save a sealed version of a node apikey, so that a subsequent run with same TPM2 will use the TPM2 to protect the API key rather than local network verification. If this is set, then an api key request will receive this if the api key grant is not armed
deployment.stagedprofile: A profile that has been staged, but is awaiting final boot to be activated. This allows an OS profile to remove itself from netboot without indicating completion to any watcher.
deployment.state: Profiles may push more specific state, for example, it may set the state to "failed" or "succeded"
deployment.state_detail: Detailed state information as reported by an OS profile, when available
deployment.useinsecureprotocols: What phase(s) of boot are permitted to use insecure protocols (TFTP and HTTP without TLS. By default, only HTTPS is used. However this is not compatible with most firmware in most scenarios. Using "firmware" as the setting will still use HTTPS after the initial download, though be aware that a successful attack during the firmware phase will negate future TLS protections. The value "always" will result in tftp/http being used for most of the deployment. The value "never" will allow HTTPS only. Note that Ubuntu will still use HTTP without TLS for a phase of the installation process.
discovery.nodeconfig: Set of nodeconfig arguments to apply after automatic discovery
discovery.passwordrules: Any specified rules shall be configured on the BMC upon discovery. "expiration=no,loginfailures=no,complexity=no,reuse=no" would disable password expiration, login failures triggering a lockout, password complexity requirements,and any restrictions around reusing an old password.
discovery.policy: Policy to use for auto-configuration of discovered and identified nodes. Valid values are "manual", "permissive", or "open". "manual" means nodes are detected, but not autoconfigured until a user approves. "permissive" indicates to allow discovery, so long as the node has no existing public key. "open" allows discovery even if a known public key is already stored
dns.domain: DNS Domain searched by default by the system
dns.servers: DNS Server or servers to provide to node
enclosure.bay: The bay in the enclosure, if any
enclosure.extends: When using an extendable enclosure, this is the node representing the manager that is one closer to the uplink.
enclosure.manager: The management device for this node's chassis
groups: List of static groups for which this node is considered a member
hardwaremanagement.manager: The management address dedicated to this node. This is the address of, for example, the Lenovo XCC. It may optionally include /prefixlen CIDR suffix to indicate subnet length, which is autodetected by default where possible.
hardwaremanagement.method: The method used to perform operations such as power control, get sensor data, get inventory, and so on. ipmi is used if not specified.
hardwaremanagement.port: The port the BMC should be configured to connect to network. This only has effect during deployment and does not apply to out of band discovery. Example values include "ocp", "ml2", "lom" (for on board port shared with operating system), or "dedicated"
hardwaremanagement.vlan: The vlan that a BMC should be configured to tag traffic. This only has effect during OS deployment and does not apply to out of band discovery.
id.model: The model number of a node. In scenarios where there is both a name and a model number, it is generally expected that this would be the generally more specific model number.
id.serial: The manufacturer serial number of node
id.uuid: The UUID of the node as presented in DMI.
info.note: A field used for administrators to make arbitrary notations about nodes. This is meant entirely for human use and not programmatic use, so it can be freeform text data without concern for issues in how the server will process it.
location.height: Height in RU of the system (defaults to query the systems)
location.rack: Rack number of the rack the node is in
location.room: Room description for the node
location.row: Row description for the rack the node is in
location.u: Position in the rack of the node
net.bootable: Whether or not the indicated network interface is to be used for booting. This is used by the discovery process to decide where to place the mac address of a detected PXE nic.
net.connection_name: Name to use when specifiying a name for connection and/or interface name for a team. This may be the name of a team interface, the connection name in network manager for the interface, or may be installed as an altname as supported by the respective OS deployment profiles. Default is to accept default name for a team consistent with the respective OS, or to use the matching original port name as connection name.
net.hostname: Used to specify hostnames per interface. Can be a comma delimited list to indicate aliases
net.hwaddr: The hardware address, aka MAC address of the interface indicated, generally populated by the PXE discovery mechanism
net.interface_names: Interface name or comma delimited list of names to match for this interface. It is generally recommended to leave this blank unless needing to set up interfaces that are not on a common subnet with a confluent server, as confluent servers provide autodetection for matching the correct network definition to an interface. This would be the default name per the deployed OS and can be a comma delimited list to denote members of a team or a single interface for VLAN/PKEY connections.
net.ipv4_address: When configuring static, use this address. If unspecified, it will check if the node name resolves to an IP address. Additionally, the subnet prefix may be specified with a suffix, e.g. "/16". If not specified, it will attempt to autodetect based on current network configuration.
net.ipv4_gateway: The IPv4 gateway to use if applicable. As is the case for other net attributes, net.eth0.ipv4_gateway and similar is accepted.
net.ipv4_method: Whether to use static or dhcp when configuring this interface for IPv4. "firmwaredhcp" means to defer to external DHCP server during firmware execution, but use static for OS. "firmwarenone" means to suppress even the no-IP dhcp offers, to fully delegate to an external dhcp/pxe configuration, even for confluent deployment.
net.ipv6_address: When configuring static, use this address. If unspecified, it will check if the node name resolves to an IP address. Additionally, the subnet prefix may be specified with a suffix, e.g. "/64". If not specified, it will attempt to autodetect based on current network configuration.
net.ipv6_gateway: The IPv6 gateway to use if applicable. As is the case for other net attributes, net.eth0.ipv6_gateway and similar is accepted.
net.ipv6_method: Whether to use static or dhcp when configuring this interface for IPv6. "firmwaredhcp" means to defer to external DHCP server during firmware execution, but use static for OS. "firmwarenone" means to suppress even the no-IP dhcp offers, to fully delegate to an external dhcp/pxe configuration, even for confluent deployment
net.switch: An ethernet switch the node is connected to. Note that net.* attributes may be indexed by interface. For example instead of using net.switch, it is possible to use net.eth0.switch and net.eth1.switch or net.0.switch and net.1.switch to define multiple sets of net connectivity associated with each other.
net.switchport: The port on the switch that corresponds to this node. See information on net.switch for more on the flexibility of net.* attributes.
net.team_mode: Indicates that this interface should be a team and what mode or runner to use when teamed. If this covers a deployment interface, one of the member interfaces may be brought up as a standalone interface until deployment is complete, as supported by the OS deployment profile. To support this scenario, the switch should be set up to allow independent operation of member ports123654 (e.g. lacp bypass mode or fallback mode).
net.vlan_id: Ethernet VLAN or InfiniBand PKEY to use for this connection. Specify the parent device using net.interface_names.
ntp.servers: NTP server or servers to provide to node during deployment. An OS profile may default to internet NTP, depending on default configuration of the respective operating system
power.outlet: Species the outlet identifier on the PDU associoted with a power input on the node
power.pdu: Specifies the managed PDU associated with a power input on the node
pubkeys.addpolicy: Policy to use when encountering unknown public keys. Choices are "automatic" to accept and store new key if no key known and "manual" to always reject a new key, even if no key knownNote that if the trusted CA verifies the certificate, that is accepted ignoring this policy. Default policy is "automatic"
pubkeys.ssh: Fingerprint of the SSH key of the OS running on the system.
pubkeys.tls_hardwaremanager: Fingerprint of the TLS certificate recognized asbelonging to the hardware manager of the server
secret.hardwaremanagementpassword: Password to use when connecting to the hardware manager. Aliases for this attribute include bmcpass and switchpass
secret.hardwaremanagementuser: The username to use when connecting to the hardware manager. Aliases for this attribute include bmcuser and switchuser
secret.ipmikg: Optional Integrity key for IPMI communication. This should generally be ignored, as mutual authentication is normally done with the password alone (which is a shared secret in IPMI)
secret.selfapiarmtoken: A one-time use shared secret to authenticate a node api token
secret.snmpcommunity: SNMPv1 community string, it is highly recommended tostep up to SNMPv3
ssh.trustnodes: Nodes that are allowed to ssh into the node, expressed in noderange syntax. This is used during deployment if the confluent SSH certificate authority is configured. Default behavior is for all nodes to trust each other.
trusted.subnets: Remote subnets in CIDR notation that should be considered as trusted as local networks
type: Classification of node as server or switch. By default a node is presumed to be a server.