Luna Command line interface
The luna cli or commandline interface allows one to configure, modify and extend the cluster configuration. Typically, the configuration is devided into sections with their respective tasks (=configuration items).
for nearly all sections there are two most commenly used parameters: list and show. List typically lists all the components of that section, where show returns the details of a component.
Example:
# luna osimage list
+-------------------------------------------------------------------------------------------------+
| << Osimage >> |
+---+---------+------------------------------+-------------------------+--------------+-----------+
| # | name | kernelversion | path | distribution | osrelease |
+---+---------+------------------------------+-------------------------+--------------+-----------+
| 1 | compute | 5.14.0-362.24.1.el9_3.x86_64 | /trinity/images/compute | redhat | 9 |
| 2 | ubuntu | 5.15.0-25-generic | /trinity/images/ubuntu | ubuntu | None |
+---+---------+------------------------------+-------------------------+--------------+-----------+
# luna osimage show compute
+------------------------------------------------------------------------------+
| Osimage => compute |
+------------------+-----------------------------------------------------------+
| name | compute |
| grab_filesystems | /, /boot |
| grab_exclude | /proc/*, /sys/*, /dev/*, /tmp/*, /run/*, /var/log/* |
| initrdfile | compute-1715339776-initramfs-5.14.0-362.24.1.el9_3.x86_64 |
| kernelversion | 5.14.0-362.24.1.el9_3.x86_64 |
| kernelfile | compute-1715339776-vmlinuz-5.14.0-362.24.1.el9_3.x86_64 |
| kernelmodules | ipmi_devintf, ipmi_si, ipmi_msghandler |
| kerneloptions | net.ifnames=0 biosdevname=0 |
| path | /trinity/images/compute |
| imagefile | compute-1715339818.tar.bz2 |
| distribution | redhat |
| osrelease | 9 |
| comment | None |
| tag | default |
+------------------+-----------------------------------------------------------+
Usefull flags:
| Flag | Description |
|---|---|
| -h | At any point -h can be added to get more information regarding the task to be requested |
| -v | At any point -v will provide more debugging information of the requested task |
| -r | Output of task in json format |
Luna cluster
Luna cluster shows and alters cluster level configuration like DNS forwarders, provisioning method etc.
Example:
# luna cluster
+-----------------------------------------------------------------------------------+
| Cluster => mycluster |
+-----------------------+-----------------------------------------------------------+
| name | mycluster |
| controller | hostname = controller |
| | status = None |
| | vendor = None |
| | serverport = 7050 |
| | beacon = 1 |
| | ipaddress = 10.141.255.254 |
| | luna_config = /trinity/local/luna/daemon/config/luna.ini |
| technical_contacts | root@localhost |
| provision_method | torrent |
| provision_fallback | http |
| nameserver_ip | 10.141.255.254 |
| forwardserver_ip | 192.168.160.20,8.8.4.4 |
| domain_search | None |
| ntp_server | 10.141.255.254 |
| security | False |
| createnode_ondemand | True |
| user | None |
| debug | False |
| nameserver_ip_ipv6 | None |
| forwardserver_ip_ipv6 | None |
| nextnode_discover | True |
+-----------------------+-----------------------------------------------------------+
Changing the DNS forwarder:
# luna cluster change --forwardserver_ip 192.168.200.200
Luna network
Luna network manages the networks. Changed values will also automatically be reflected in depended components like groups and nodes where respective interfaces are member of the altered network.
Example:
# luna network list
+--------------------------------------------------------------------------------------+
| << Network >> |
+---+---------+---------------+------------+-------+------------------+----------------+
| # | name | network | type | dhcp | dhcp_range_begin | dhcp_range_end |
+---+---------+---------------+------------+-------+------------------+----------------+
| 1 | cluster | 10.141.0.0/16 | ethernet | True | 10.141.128.0 | 10.141.140.0 |
| | | | | | | |
| 2 | ipmi | 10.148.0.0/16 | ethernet | False | --NA-- | --NA-- |
| | | | | | | |
| 3 | ib | 10.149.0.0/16 | infiniband | False | --NA-- | --NA-- |
+---+---------+---------------+------------+-------+------------------+----------------+
Changing the gateway for example external net
# luna network change -g 192.168.160.1 --gateway_metric 1 externalnet
Luna osimage
Luna osimage manages images.
Example:
# luna osimage list
+-------------------------------------------------------------------------------------------------+
| << Osimage >> |
+---+---------+------------------------------+-------------------------+--------------+-----------+
| # | name | kernelversion | path | distribution | osrelease |
+---+---------+------------------------------+-------------------------+--------------+-----------+
| 1 | compute | 5.14.0-362.24.1.el9_3.x86_64 | /trinity/images/compute | redhat | 9 |
| 2 | ubuntu | 5.15.0-25-generic | /trinity/images/ubuntu | ubuntu | None |
+---+---------+------------------------------+-------------------------+--------------+-----------+
Packing an image after modification (e.g. through adding packages using lchroot or changing kernel modules):
# luna osimage pack compute
osimage pack for compute queued
2024-06-14 12:27:26 :: queued pack osimage compute with id 1077
2024-06-14 12:27:26 :: assembling kernel and ramdisk for osimage compute
2024-06-14 12:28:09 :: finished assembling kernel and ramdisk for osimage compute
2024-06-14 12:28:09 :: building osimage compute
2024-06-14 12:29:09 :: finished building osimage compute
2024-06-14 12:29:09 :: creating provisioning for osimage compute
2024-06-14 12:29:13 :: created torrent provisioning for osimage compute
2024-06-14 12:29:14 :: created http provisioning for osimage compute
[========] Image compute Packed.
Luna bmcsetup
Luna bmcsetup manages bmc or ipmi configurations through profiles. In here netchannels and passwords can be configured.
Example:
# luna bmcsetup show compute
+--------------------------------+
| Bmcsetup => compute |
+---------------------+----------+
| name | compute |
| userid | 2 |
| username | admin |
| password | password |
| netchannel | 1 |
| mgmtchannel | 1 |
| unmanaged_bmc_users | None |
| comment | None |
+---------------------+----------+
Luna switch
Luna switch manages the optional switches. Switches configured with an IP address and OID will be scanned on interval to aid in switch port based node detection.
Example:
# luna switch show switch01
+-------------------------------------------+
| Switch => switch01 |
+-------------+-----------------------------+
| name | switch01 |
| oid | .1.3.6.1.2.1.17.7.1.2.2.1.2 |
| ipaddress | 10.141.255.240 |
| read | public |
| rw | trusted |
| comment | None |
| macaddress | None |
| uplinkports | 48,49,50,51 |
| vendor | None |
+-------------+-----------------------------+
Luna otherdev
Luna otherdev(ices) allows to add, change and remove devices like cameras, PDU-s and UPS-es. These devices will not be probed or accessed are primarily there to complete a rack layout (pun) or cluster interal DNS zone information.
Luna group
Luna group manages the groups or categories of nodes. Nodes are typically member of a group where equal configuration can be done on a higher level. Good examples are to use a group for nodes where these boot the same osimage. It is common practice to have separate groups for a function or category like a compute node category, storage servers and login nodes.
Example:
# luna group show compute
+-------------------------------------------------------------------------------+
| Group => compute |
+---------------------+---------------------------------------------------------+
| name | compute |
| domain | cluster |
| osimage | compute |
| osimagetag | default (default) |
| interfaces | interface = BOOTIF |
| | network = cluster |
| | interface = BMC |
| | network = ipmi |
| setupbmc | True |
| bmcsetupname | compute |
| unmanaged_bmc_users | None |
| netboot | True |
| localinstall | False (default) |
| bootmenu | False (default) |
| roles | None |
| prescript | <empty> (default) |
| partscript | mount -t tmpfs tmpfs /sysroot |
| postscript | echo 'tmpfs / tmpfs defaults 0 0' >> /sysroot/etc/fstab |
| provision_interface | BOOTIF (default) |
| provision_method | torrent (cluster) |
| provision_fallback | http (cluster) |
| comment | None |
| kerneloptions | None |
+---------------------+---------------------------------------------------------+
Nodes member of a group will inherit the settings of the group, unless overridden (see Luna node section). This includes the interfaces of a group.
Example of adding an interface to group compute:
# luna group change -if ib0 -N ib compute
The nodes member of group compute will automatically receive the ib0 interface with an assigned IP address:
# luna node show node001
+-----------------------------------------------------------------------------------------+
| Node => node001 |
+---------------------+-------------------------------------------------------------------+
| name | node001 |
| hostname | node001.cluster |
| group | compute |
...
| interfaces | interface = BOOTIF |
| | ipaddress = 10.141.0.1 |
| | macaddress = 00:50:56:b3:9c:dd |
| | network = cluster |
| | interface = BMC |
| | ipaddress = 10.148.0.1 |
| | macaddress = None |
| | network = ipmi |
| | interface = ib0 |
| | ipaddress = 10.149.0.1 |
| | macaddress = None |
| | network = ib |
...
Luna node
Luna node manages the nodes. All inheritable configuration from the group or cluster can be overridden here. This offers a great range of freedom where a set of nodes being nearly identical except for e.g. the bmcsetup can be setup without having duplicate configuration. The alternative bmcsetup profile can be simply set for just that node.
Example overriding the bmcsetup profile:
# luna node change --bmcsetup my_new_bmc_profile node001
Example unsetting the override (falls back to group level configuration):
# luna node change --bmcsetup "" node001
Example changing the group of a node. Where applicable interfaces will be added or removed as per group definition.
# luna node change -g my_new_group node001
Luna secrets
Luna secrets stores data for groups and nodes in an encrypted way. Secrets is typically used to store keytabs, certificates or other sensitive information that would otherwise be stored inside the osimage. At boot time, the secrets will be copied to the node.
Example:
# luna secrets list
+----------------------------------------------------------------+
| << Group Secrets >> |
+---+--------------+--------------+---------------+--------------+
| # | Group | name | path | content |
+---+--------------+--------------+---------------+--------------+
| 1 | compute | group_secret | /root/db.pw | my secret |
| | | | | password |
| | | | | |
+---+--------------+--------------+---------------+--------------+
Luna service
Luna service allows to manually stop, start, restart and status services like dns and dhcp.
Example:
# luna service dhcp restart
(re)starting and reloading the service implies regenerating configuration files used by the service.
Luna control power
The Luna tool fully supports the API. A separate tool named lpower also controls the nodes.
Usage:
# luna control power [on|off|status|reset] [hnode|hostlist]
Where hostlist is a range of nodes. The returned output contains the nodes with their command status output.
Example:
# luna control power status node001
+----------------------------------------------------------+
| << Control Power Node Status >> |
+-----------+----------------------------------------------+
| Node Name | node001 |
| Status | [...] |
+-----------+----------------------------------------------+
# luna control power status node00[1-4]
X----------------------------------------------------------------------------------------X
| # | Node Name | Status |
X----------------------------------------------------------------------------------------X
| 1 | node001 | [...] |
| 2 | node002 | [...] |
| 3 | node003 | [...] |
| 4 | node004 | [...] |
X----------------------------------------------------------------------------------------X
Luna control sel
Retrieves the SEL list or clears the SEL for a single node. This command does not support retrieving multiple nodes in one call as the output may be very large. Note that the BMCsetup must be configured for the node and IPMI on the node be fully functional.
Usage:
# luna control sel [list|clear] [node]
Luna control chassis
Controls the chassis via IPMI.
Usage:
# luna control chassis [identify,noidentify] [node|hostlist]
Osgrab and ospush
Osgrab and ospush allow for grabbing a running node's state into an image or from an image to a node or group of nodes. It provides a way to either capture a node or to push to sync changes made in an image without a node's reboot.
This functionality is extremely powerful but also very destructive when not taken care off properly. It is extremely important to have the correct excludes configured for the involved osimage when performing these actions. By default a dry run is performed allowing a close scrutiny before performing the real action.
*Examples
verify the grab_filesystems and grab_exclude to match expectations. This matters for the image involved. By default the assigned image to the node is used but can be overridden. In that case ensure to verify the correct image:
# luna osimage show compute-image
+--------------------------------------------------------------------------------+
| Osimage => compute-image |
+------------------+-------------------------------------------------------------+
| name | compute-image |
| grab_filesystems | /, /boot | <--- Set the filesystems involved
| grab_exclude | /proc/*, /sys/*, /dev/*, /tmp/*, /run/*, /opt/*, /var/log/* | <--- Set the directories/files to be excluded
| initrdfile | None |
....
+--------------------------------------------------------------------------------+
By default, the image assigned to a node will be used, but can be overridden as seen below:
# luna node osgrab -o compute-image node001
2025-10-10 23:13:38 :: queued grab osimage compute-image with id 38
2025-10-10 23:13:38 :: grabbing osimage compute-image [DRY RUN]
2025-10-10 23:13:41 :: finished grabbing osimage compute-image: Success. See /tmp/osgrab.out for details
[========] OS Image Grabbed for node node001.
With the --nodry parameter, the grab is done for real. Please make sure to have seen the output listed in /tmp/osgrab.out during a dry run before proceeding. Adjust the grab_exclude or grab_filesystems where needed. These are used for both grabbing and pushing.
Below an example where we push, using the assigned image (i.e. not specifying the osimage name):
# luna node ospush node001
2025-10-10 23:16:49 :: queued push osimage compute-image with id 39
2025-10-10 23:16:49 :: pushing osimage compute-image->node node001 [DRY RUN]
2025-10-10 23:16:50 :: finished pushing osimage: Success. See /tmp/ospush.out for details
[========] OS Image Pushed for node node001.
Pushing to a whole group (all nodes in that group) is also supported:
# luna group ospush compute-group
2025-10-10 23:18:36 :: queued push osimage compute-image with id 40
2025-10-10 23:18:36 :: pushing osimage compute-image->group compute-group [DRY RUN]
2025-10-10 23:18:41 :: finished pushing osimage
[========] OS Image Pushed for group compute-group.
the file /tmp/ospush.out allows for verification before applying --nodry.
Shown in the examples are the dry runs. supplying --nodry to these commands will perform the actions for real. Once again a big warning: be cautious using ospush and osgrab. Be aware of its powers.