The Pre-Install Toolkit (PIT) node needs to be bootstrapped from the LiveCD. There are two media available to bootstrap the PIT node: the RemoteISO or a bootable USB device. This procedure describes using the USB device. If not using the USB device, see Bootstrap PIT Node from LiveCD Remote ISO.
These steps provide a bootable USB with SSH enabled, capable of installing this CSM release.
Fetch the base installation CSM tarball, extract it, and install the contained CSI tool.
Create a working area for this procedure:
linux# mkdir usb
linux# cd usb
Set up the initial typescript.
linux# SCRIPT_FILE=$(pwd)/csm-install-usb.$(date +%Y-%m-%d).txt
linux# script -af ${SCRIPT_FILE}
linux# export PS1='\u@\H \D{%Y-%m-%d} \t \w # '
Set and export helper variables.
Important: All CSM install procedures for preparing the PIT node assume that these variables are set and exported.
linux# export CSM_RELEASE=csm-x.y.z
linux# export SYSTEM_NAME=eniac
linux# export PITDATA=/mnt/pitdata
Download and expand the CSM software release.
Important: Ensure that you have the CSM release plus any patches or hotfixes by following the instructions in Update CSM Product Stream
Important: Download to a location that has sufficient space for both the tarball and the expanded tarball.
Important: All CSM install procedures for preparing the PIT node assume that the
CSM_PATHvariable has been set and exported.Note: Expansion of the tarball may take more than 45 minutes.
linux# tar -zxvf ${CSM_RELEASE}.tar.gz
linux# ls -l ${CSM_RELEASE}
linux# export CSM_PATH=$(pwd)/${CSM_RELEASE}
The ISO and other files are now available in the directory from the extracted CSM tarball.
Install the latest version of CSI tool.
linux# rpm -Uvh --force $(find ${CSM_PATH}/rpm/cray/csm/ -name "cray-site-init-*.x86_64.rpm" | sort -V | tail -1)
Install the latest documentation RPM.
Show the version of CSI installed.
linux# csi version
Expected output looks similar to the following:
CRAY-Site-Init build signature...
Build Commit : b3ed3046a460d804eb545d21a362b3a5c7d517a3-release-shasta-1.4
Build Time : 2021-02-04T21:05:32Z
Go Version : go1.14.9
Git Version : b3ed3046a460d804eb545d21a362b3a5c7d517a3
Platform : linux/amd64
App. Version : 1.5.18
Configure zypper with the embedded repository from the CSM release.
linux# zypper ar -fG "${CSM_PATH}/rpm/embedded" "${CSM_RELEASE}-embedded"
Install Podman or Docker to support container tools required to generate sealed secrets.
Podman RPMs are included in the embedded repository in the CSM release and
may be installed in your pre-LiveCD environment using zypper as follows:
Install podman and podman-cni-config packages:
linux# zypper in --repo ${CSM_RELEASE}-embedded -y podman podman-cni-config
Alternatively, one may use rpm -Uvh to install RPMs (and their dependencies) manually
from the ${CSM_PATH}/rpm/embedded directory.
linux# rpm -Uvh $(find ${CSM_PATH}/rpm/embedded -name "podman-*.x86_64.rpm" | sort -V | tail -1) \
$(find ${CSM_PATH}/rpm/embedded -name "podman-cni-config-*.noarch.rpm" | sort -V | tail -1)
Install lsscsi to view attached storage devices.
lsscsi RPMs are included in the embedded repository in the CSM release and
may be installed in your pre-LiveCD environment using zypper as follows:
Install lsscsi package:
linux# zypper in --repo ${CSM_RELEASE}-embedded -y lsscsi
Alternatively, one may use rpm -Uvh to install RPMs (and their dependencies) manually
from the ${CSM_PATH}/rpm/embedded directory.
linux# rpm -Uvh $(find ${CSM_PATH}/rpm/embedded -name "lsscsi-*.x86_64.rpm" | sort -V | tail -1)
Remove CNI configuration from prior install
If reinstalling the system and using ncn-m001 to prepare the USB image, then remove the prior CNI configuration.
Remove the configuration files.
ncn-m001# rm -rf /etc/cni/net.d/00-multus.conf /etc/cni/net.d/10-*.conflist /etc/cni/net.d/multus.d
List the remaining contents of the /etc/cni/net.d directory.
ncn-m001# ls /etc/cni/net.d
Example output:
87-podman-bridge.conflist 99-loopback.conf.sample
The exact directory contents may vary depending on the CSM version previously installed on ncn-m001.
Before creating the the bootable LiveCD, identify which device will be used for it.
Identify the USB device.
This example shows the USB device is /dev/sdd on the host.
linux# lsscsi
Expected output looks similar to the following:
[6:0:0:0] disk ATA SAMSUNG MZ7LH480 404Q /dev/sda
[7:0:0:0] disk ATA SAMSUNG MZ7LH480 404Q /dev/sdb
[8:0:0:0] disk ATA SAMSUNG MZ7LH480 404Q /dev/sdc
[14:0:0:0] disk SanDisk Extreme SSD 1012 /dev/sdd
[14:0:0:1] enclosu SanDisk SES Device 1012 -
In the above example, internal disks are the ATA devices and USB drives are final two devices.
Set a variable with your disk to avoid mistakes:
linux# USB=/dev/sd<disk_letter>
Format the USB device.
On Linux, use the CSI application to do this:
linux# csi pit format ${USB} ${CSM_PATH}/cray-pre-install-toolkit-*.iso 50000
Note: If the previous command fails with the following error message, it indicates that this Linux computer does not have the
checkmediaRPM installed. In that case, install the RPM and runcsi pit formatagain.ERROR: Unable to validate ISO. Please install checkmedia
- Install the missing RPMs
linux# zypper in --repo ${CSM_RELEASE}-embedded -y libmediacheck5 checkmedia linux# csi pit format ${USB} ${CSM_PATH}/cray-pre-install-toolkit-*.iso 50000
On MacOS, use the write-livecd.sh script to do this.
This script is contained in the CSI tool RPM. See install latest version of the CSI tool step.
macos# write-livecd.sh ${USB} ${CSM_PATH}/cray-pre-install-toolkit-*.iso 50000
Note: At this point, the USB device is usable in any server with a CPU with x86_64 architecture. The remaining steps help add the installation data and enable SSH on boot.
Mount the configuration and persistent data partitions.
linux# mkdir -pv /mnt/cow ${PITDATA} &&
mount -vL cow /mnt/cow &&
mount -vL PITDATA ${PITDATA} &&
mkdir -pv ${PITDATA}/configs ${PITDATA}/prep/{admin,logs} ${PITDATA}/data/{ceph,k8s}
Copy and extract the tarball into the USB.
linux# cp -v ${CSM_PATH}.tar.gz ${PITDATA} &&
tar -zxvf ${CSM_PATH}.tar.gz -C ${PITDATA}/
The USB device is now bootable and contains the CSM artifacts. This may be useful for internal or quick usage. Administrators seeking a Shasta installation must continue on to the configuration payload.
The SHASTA-CFG structure and other configuration files will be prepared, then csi will generate a system-unique configuration payload.
This payload will be used for the rest of the CSM installation on the USB device.
Some files are needed for generating the configuration payload. See these topics in Prepare Configuration Payload if the information for this system has not yet been prepared.
Note:: The USB device is usable at this time, but without SSH enabled as well as core services. This means the USB device could be used to boot the system now, and this step can be returned to at another time.
At this time see Create HMN Connections JSON for instructions about creating the hmn_connections.json.
Create the configuration input files if needed and copy them into the preparation directory.
The preparation directory is ${PITDATA}/prep.
Copy these files into the preparation directory, or create them if this is an initial install of the system:
application_node_config.yaml (optional - see below)cabinets.yaml (optional - see below)hmn_connections.jsonncn_metadata.csvswitch_metadata.csvsystem_config.yaml (only available after first-install generation of system files)The optional
application_node_config.yamlfile may be provided for further definition of settings relating to how application nodes will appear in HSM for roles and subroles. See Create Application Node YAMLThe optional
cabinets.yamlfile allows cabinet naming and numbering as well as some VLAN overrides. See Create Cabinets YAML.The
system_config.yamlfile is generated by thecsitool during the first install of a system, and can later be used for reinstalls of the system. For the initial install, the information in it must be provided as command line arguments tocsi config init.
Proceed to the appropriate next step.
For subsequent fresh-installs (re-installs) where the system_config.yaml parameter file is available, generate the updated system configuration
(see Cray Site Init Files).
Warning: If the
system_config.yamlfile is unavailable, then skip this step and proceed to Initial Installs (bare-metal).
Check for the configuration files. The needed files should be in the preparation directory.
linux# ls -1 ${PITDATA}/prep
Expected output looks similar to the following:
application_node_config.yaml
cabinets.yaml
hmn_connections.json
ncn_metadata.csv
switch_metadata.csv
system_config.yaml
Generate the system configuration.
Note: Ensure that you specify a reachable NTP pool or server using the
ntp-poolsorntp-serversfields, respectively. Adding an unreachable server can cause clock skew aschronytries to continually reach out to a server it can never reach.
linux# cd ${PITDATA}/prep && csi config init
A new directory matching the system-name field in system_config.yaml will now exist in the working directory.
Note: These warnings from
csi config initfor issues inhmn_connections.jsoncan be ignored.
The node with the external connection (
ncn-m001) will have a warning similar to this because its BMC is connected to the site and not the HMN like the other management NCNs. It can be ignored."Couldn't find switch port for NCN: x3000c0s1b0"An unexpected component may have this message. If this component is an application node with an unusual prefix, it should be added to the
application_node_config.yamlfile. Then reruncsi config init. See the procedure to Create Application Node Config YAML.{"level":"warn","ts":1610405168.8705149,"msg":"Found unknown source prefix! If this is expected to be an Application node, please update application_node_config.yaml","row": {"Source":"gateway01","SourceRack":"x3000","SourceLocation":"u33","DestinationRack":"x3002","DestinationLocation":"u48","DestinationPort":"j29"}}If a cooling door is found in
hmn_connections.json, there may be a message like the following. It can be safely ignored.{"level":"warn","ts":1612552159.2962296,"msg":"Cooling door found, but xname does not yet exist for cooling doors!","row": {"Source":"x3000door-Motiv","SourceRack":"x3000","SourceLocation":" ","DestinationRack":"x3000","DestinationLocation":"u36","DestinationPort":"j27"}}
Skip the next step and continue to verify and backup system_config.yaml.
For first-time/initial installs (without a system_config.yamlfile), generate the system configuration. See below for an explanation of the command line parameters and
some common settings.
Check for the configuration files. The needed files should be in the preparation directory.
linux# ls -1 ${PITDATA}/prep
Expected output looks similar to the following:
application_node_config.yaml
cabinets.yaml
hmn_connections.json
ncn_metadata.csv
switch_metadata.csv
Generate the system configuration.
Notes:
- Run
csi config init --helpto print a full list of parameters that must be set. These will vary significantly depending on the system and site configuration.- Ensure that you specify a reachable NTP pool or server using the
--ntp-poolsor--ntp-serversflags, respectively. Adding an unreachable server can cause clock skew aschronytries to continually reach out to a server it can never reach.
linux# cd ${PITDATA}/prep && csi config init <options>
A new directory matching the --system-name argument will now exist in the working directory.
Important: After generating a configuration, a visual audit of the generated files for network data should be performed.
Special Notes: Certain parameters to
csi config initmay be hard to grasp on first-time configuration generations:
- The optional
application_node_config.yamlfile is used to map prefixes inhmn_connections.csvto HSM subroles. A command line option is required in order forcsito use the file. See Create Application Node YAML.- The
bootstrap-ncn-bmc-userandbootstrap-ncn-bmc-passmust match what is used for the BMC account and its password for the management NCNs.- Set site parameters (
site-domain,site-ip,site-gw,site-nic,site-dns) for the network information which connectsncn-m001(the PIT node) to the site. Thesite-nicis the interface onncn-m001that is connected to the site network.- There are other interfaces possible, but the
install-ncn-bond-membersare typically:
p1p1,p10p1for HPE nodesp1p1,p1p2for Gigabyte nodesp801p1,p801p2for Intel nodes- If not using a
cabinets-yamlfile, then set the three cabinet parameters (mountain-cabinets,hill-cabinets, andriver-cabinets) to the quantity of each cabinet type included in this system.- The starting cabinet number for each type of cabinet (for example,
starting-mountain-cabinet) has a default that can be overridden. See thecsi config init --help.- For systems that use non-sequential cabinet ID numbers, use the
cabinets-yamlargument to include thecabinets.yamlfile. This file gives the ability to explicitly specify the ID of every cabinet in the system. When specifying acabinets.yamlfile with thecabinets-yamlargument, other command line arguments related to cabinets will be ignored bycsi. See Create Cabinets YAML.- An override to default cabinet IPv4 subnets can be made with the
hmn-mtn-cidrandnmn-mtn-cidrparameters.Note: These warnings from
csi config initfor issues inhmn_connections.jsoncan be ignored.
The node with the external connection (
ncn-m001) will have a warning similar to this because its BMC is connected to the site and not the HMN like the other management NCNs. It can be ignored."Couldn't find switch port for NCN: x3000c0s1b0"An unexpected component may have this message. If this component is an application node with an unusual prefix, it should be added to the
application_node_config.yamlfile. Then reruncsi config init. See the procedure to Create Application Node Config YAML.{"level":"warn","ts":1610405168.8705149,"msg":"Found unknown source prefix! If this is expected to be an Application node, please update application_node_config.yaml","row": {"Source":"gateway01","SourceRack":"x3000","SourceLocation":"u33","DestinationRack":"x3002","DestinationLocation":"u48","DestinationPort":"j29"}}If a cooling door is found in
hmn_connections.json, there may be a message like the following. It can be safely ignored.{"level":"warn","ts":1612552159.2962296,"msg":"Cooling door found, but xname does not yet exist for cooling doors!","row": {"Source":"x3000door-Motiv","SourceRack":"x3000","SourceLocation":" ","DestinationRack":"x3000","DestinationLocation":"u36","DestinationPort":"j27"}}
Link the generated system_config.yaml file into the prep/ directory. This is needed for pit-init to find and resolve the file.
NOTEThis step is needed only for fresh installs wheresystem_config.yamlis missing from theprep/directory.
linux# cd ${PITDATA}/prep && ln ${SYSTEM_NAME}/system_config.yaml
Continue to the next step to verify and backup system_config.yaml.
system_config.yamlVerify that the newly generated system_config.yaml matches the current version of CSI.
View the new system_config.yaml file and note the CSI version reported near the end of the file.
linux# cat ${PITDATA}/prep/${SYSTEM_NAME}/system_config.yaml
Note the version reported by the csi tool.
NOTE The
App. Versionwill report incorrectly in CSM 1.2.0 and CSM 1.2.1. Please obtain the version information by running the step below and by invokingrpm -q cray-site-init.
linux# csi version
The two versions should match. If they do not, determine the cause and regenerate the file.
Copy the new system_config.yaml file somewhere safe to facilitate re-installs.
Continue to the next step to Prepare Site Init.
Site InitNote:: It is assumed at this point that
$PITDATA(that is,/mnt/pitdata) is still mounted on the Linux system. This is important because the following procedure depends on that mount existing.
Install Git if not already installed.
Prepare the site-init directory.
Perform the Prepare Site Init procedures.
Now that the configuration is generated, the LiveCD must be populated with the generated files.
Use CSI to populate the LiveCD with networking files so SSH will work on the first boot.
linux# cd ${PITDATA}/prep && csi pit populate cow /mnt/cow/ ${SYSTEM_NAME}/
Expected output looks similar to the following:
config------------------------> /mnt/cow/rw/etc/sysconfig/network/config...OK
ifcfg-bond0-------------------> /mnt/cow/rw/etc/sysconfig/network/ifcfg-bond0...OK
ifcfg-lan0--------------------> /mnt/cow/rw/etc/sysconfig/network/ifcfg-lan0...OK
ifcfg-bond0.nmn0--------------> /mnt/cow/rw/etc/sysconfig/network/ifcfg-bond0.nmn0...OK
ifcfg-bond0.hmn0--------------> /mnt/cow/rw/etc/sysconfig/network/ifcfg-bond0.hmn0...OK
ifcfg-bond0.can0--------------> /mnt/cow/rw/etc/sysconfig/network/ifcfg-bond0.can0...OK
ifcfg-bond0.cmn0--------------> /mnt/cow/rw/etc/sysconfig/network/ifcfg-bond0.cmn0...OK
ifroute-lan0------------------> /mnt/cow/rw/etc/sysconfig/network/ifroute-lan0...OK
ifroute-bond0.nmn0------------> /mnt/cow/rw/etc/sysconfig/network/ifroute-bond0.nmn0...OK
CAN.conf----------------------> /mnt/cow/rw/etc/dnsmasq.d/CAN.conf...OK
CMN.conf----------------------> /mnt/cow/rw/etc/dnsmasq.d/CMN.conf...OK
HMN.conf----------------------> /mnt/cow/rw/etc/dnsmasq.d/HMN.conf...OK
NMN.conf----------------------> /mnt/cow/rw/etc/dnsmasq.d/NMN.conf...OK
MTL.conf----------------------> /mnt/cow/rw/etc/dnsmasq.d/MTL.conf...OK
statics.conf------------------> /mnt/cow/rw/etc/dnsmasq.d/statics.conf...OK
conman.conf-------------------> /mnt/cow/rw/etc/conman.conf...OK
Set the hostname and print it into the hostname file.
Note: Do not confuse other administrators by naming the LiveCD
ncn-m001. Append the-pitsuffix, indicating that the node is booted from the LiveCD.
linux# echo "${SYSTEM_NAME}-ncn-m001-pit" | tee /mnt/cow/rw/etc/hostname
Add some helpful variables to the PIT environment.
By adding these to the /etc/environment file of the PIT image, these variables will be
automatically set and exported in shell sessions on the booted PIT node.
Important: All CSM install procedures on the booted PIT node assume that these variables are set and exported.
The
echoprepends a newline to ensure that the variable assignment occurs on a unique line, and not at the end of another line.
linux# echo "
CSM_RELEASE=${CSM_RELEASE}
SYSTEM_NAME=${SYSTEM_NAME}" | tee -a /mnt/cow/rw/etc/environment
Unmount the overlay.
linux# umount -v /mnt/cow
Copy the NCN artifacts.
Copy Kubernetes node artifacts:
linux# csi pit populate pitdata "${CSM_PATH}/images/kubernetes/" ${PITDATA}/data/k8s/ -kiK
Expected output looks similar to the following:
5.3.18-24.37-default-0.0.6.kernel-----------------> /mnt/pitdata/data/k8s/...OK
initrd.img-0.0.6.xz-------------------------------> /mnt/pitdata/data/k8s/...OK
kubernetes-0.0.6.squashfs-------------------------> /mnt/pitdata/data/k8s/...OK
Copy Ceph/storage node artifacts:
linux# csi pit populate pitdata "${CSM_PATH}/images/storage-ceph/" ${PITDATA}/data/ceph/ -kiC
Expected output looks similar to the following:
5.3.18-24.37-default-0.0.5.kernel-----------------> /mnt/pitdata/data/ceph/...OK
initrd.img-0.0.5.xz-------------------------------> /mnt/pitdata/data/ceph/...OK
storage-ceph-0.0.5.squashfs-----------------------> /mnt/pitdata/data/ceph/...OK
Quit the typescript session with the exit command and copy the typescript file to the data partition on the USB drive.
linux# exit
linux# cp -v ${SCRIPT_FILE} /mnt/pitdata/prep/admin
Unmount the data partition:
linux# cd ~ && umount -v /mnt/pitdata
Move the USB device to the system to be installed, if needed.
If the USB device was created somewhere other than ncn-m001 of the system to be installed,
move it there from its current location.
Proceed to the next step to boot into the LiveCD image.
Some systems will boot the USB device automatically if no other OS exists (bare-metal). Otherwise the administrator may need to use the BIOS Boot Selection menu to choose the USB device.
If an administrator has the node booted with an operating system which will next be rebooting into the LiveCD,
then use efibootmgr to set the boot order to be the USB device. See the
set boot order page for more information about how to set the
boot order to have the USB device first.
Note: UEFI booting must be enabled in order for the system to find the USB device’s EFI bootloader.
Start a typescript on an external system.
This will record this section of activities done on the console of ncn-m001 using IPMI.
external# script -a boot.livecd.$(date +%Y-%m-%d).txt
external# export PS1='\u@\H \D{%Y-%m-%d} \t \w # '
Confirm that the IPMI credentials work for the BMC by checking the power status.
Set the BMC variable to the hostname or IP address of the BMC of the PIT node.
read -sis used in order to prevent the credentials from being displayed on the screen or recorded in the shell history.
external# BMC=eniac-ncn-m001-mgmt
external# read -s IPMI_PASSWORD
external# export IPMI_PASSWORD ; ipmitool -I lanplus -U root -E -H ${BMC} chassis power status
Connect to the IPMI console.
external# ipmitool -I lanplus -U root -E -H ${BMC} sol activate
Reboot ncn-m001.
ncn-m001# reboot
Watch the shutdown and boot from the ipmitool console session.
An integrity check runs before Linux starts by default; it can be skipped by selecting
OKin its prompt.
On first log in (over SSH or at local console), the LiveCD will prompt the administrator to change the password.
The initial password is empty; enter the username of root and press return twice.
pit login: root
Expected output looks similar to the following:
Password: <-------just press Enter here for a blank password
You are required to change your password immediately (administrator enforced)
Changing password for root.
Current password: <------- press Enter here, again, for a blank password
New password: <------- type new password
Retype new password:<------- retype new password
Welcome to the CRAY Pre-Install Toolkit (LiveOS)
Note: If this password ever becomes lost or forgotten, one may reset it by mounting the USB device on another computer. See Reset root Password on LiveCD for information on clearing the password.
Disconnect from IPMI console.
Once the network is up so that SSH to the node works, disconnect from the IPMI console.
You can disconnect from the IPMI console by entering ~.; That is, the tilde character followed by a period character.
Exit the typescript started on the external system and use scp to transfer it to the PIT node.
Set
PIT_NODEvariable to the site IP address or hostname of the PIT node.
external# exit
external# PIT_NODE=eniac-ncn-m001
external# scp boot.livecd.*.txt root@${PIT_NODE}:/root
Log in to the PIT node as root using ssh.
external# ssh root@${PIT_NODE}
Mount the data partition.
The data partition is set to fsopt=noauto to facilitate LiveCDs over virtual-ISO mount. Therefore, USB installations
need to mount this manually by running the following command.
Note: When creating the USB PIT image, this was mounted over
/mnt/pitdata. Now that the USB PIT is booted, it will mount over/var/www/ephemeral. TheFSLabelPITDATAis already in/etc/fstab, so the path is omitted in the followingmountcommand.
pit# mount -vL PITDATA
Set and export new environment variables.
The commands below save them to /etc/environment as well, which makes them available in all new shell sessions on the PIT node.
pit# export PITDATA=$(lsblk -o MOUNTPOINT -nr /dev/disk/by-label/PITDATA)
pit# export CSM_PATH=${PITDATA}/${CSM_RELEASE}
pit# echo "
PITDATA=${PITDATA}
CSM_PATH=${CSM_PATH}" | tee -a /etc/environment
Start a typescript to record this section of activities done on ncn-m001 while booted from the LiveCD.
pit# script -af "${PITDATA}/prep/admin/booted-csm-livecd.$(date +%Y-%m-%d).txt"
pit# export PS1='\u@\H \D{%Y-%m-%d} \t \w # '
Verify that expected environment variables are set in the new login shell.
These were written into /etc/environment on the USB PIT image earlier in this procedure, before it was booted.
pit# echo -e "CSM_PATH=${CSM_PATH}\nCSM_RELEASE=${CSM_RELEASE}\nPITDATA=${PITDATA}\nSYSTEM_NAME=${SYSTEM_NAME}"
Copy the typescript made on the external system into the PITDATA mount.
pit# cp -v /root/boot.livecd.*.txt ${PITDATA}/prep/admin
Check the hostname.
pit# hostnamectl
Note:
- The hostname should be similar to
eniac-ncn-m001-pitwhen booted from the LiveCD, but it will be shown aspit#in the documentation command prompts from this point onward.- If the hostname returned by the
hostnamectlcommand ispit, then set the hostname manually withhostnamectl. In that case, do not confuse other administrators by using the hostnamencn-m001. Append the-pitsuffix, indicating that the node is booted from the LiveCD.
Install the latest documentation RPM.
Print information about the booted PIT image.
There is nothing in the output that needs to be verified. This is run in order to ensure the information is recorded in the typescript file, in case it is needed later. For example, this information is useful to include in any bug reports or service queries for issues encountered on the PIT node.
NOTE The
App. Versionwill report incorrectly in CSM 1.2. Please obtain the version information by running the step below and by invokingrpm -q cray-site-init.
pit# /root/bin/metalid.sh
Expected output looks similar to the following:
= PIT Identification = COPY/CUT START =======================================
VERSION=1.5.7
TIMESTAMP=20211028194247
HASH=ge4aceb1
CRAY-Site-Init build signature...
Build Commit : a6c8dddf9df1a9fc7f8c4f17cb26568a8b41d433-main
Build Time : 2021-12-01T16:16:41Z
Go Version : go1.16.10
Git Version : a6c8dddf9df1a9fc7f8c4f17cb26568a8b41d433
Platform : linux/amd64
App. Version : 1.12.2
metal-net-scripts-0.0.2-1.noarch
metal-basecamp-1.1.9-1.x86_64
metal-ipxe-2.0.10-1.noarch
pit-init-1.2.12-1.noarch
= PIT Identification = COPY/CUT END =========================================
Set and export BMC credential variables.
read -sis used in order to prevent the credentials from being displayed on the screen or recorded in the shell history.
pit# read -s IPMI_PASSWORD
pit# USERNAME=root
pit# export IPMI_PASSWORD USERNAME
Initialize the PIT.
The pit-init.sh script will prepare the PIT server for deploying NCNs.
pit# /root/bin/pit-init.sh
Install csm-testing and hpe-csm-goss-package.
The following assumes the CSM_PATH environment variable is set to the absolute path of the unpacked CSM release.
pit# rpm -Uvh --force $(find ${CSM_PATH}/rpm/ -name "csm-testing*.rpm" | sort -V | tail -1) $(find ${CSM_PATH}/rpm/ -name "hpe-csm-goss-package*.rpm" | sort -V | tail -1)
After completing this procedure, proceed to configure the management network switches.