Cohesity Appliance Reinstall¶

This content package provides RackN DRP resources to install Cohesity products from ISO through the network.

This currently supports Cohesity versions 6.3.1d, 6.3.1e, 6.5.1b, and 6.6.0d

Usage¶

To use this set of content, apply the cohesity-6.3.1d, cohesity-6.3.1e, cohesity-6.5.1b, or cohesity-6.6.0d profiles to the machine and set a workflow that uses the install tasks, e.g. cohesity-basic-install. One could also add the cohesity-install stage to an existing workflow to do installation.

There are three tasks that need to be done.

Test for previous installation
Discover the hardware to define the disk layouts
Apply post-installation kickstart-based tasks.

Test for Previous Installation¶

cohesity-install-check is used to test if cohesity has already been installed. This can be overridden by setting the cohesity/allow-reinstall parameter to true. Otherwise, if the system has cohesity on it the task will fail.

Discover Hardware Layout¶

This task is defined by the cohesity-classify-task parameter. This usually specified in the version specific Cohesity profile applied to the machine.

This task needs to run a modified version of the %pre section of the kickstart file on the iso. This generates three parameters on the machine that the kickstart file uses to setup partitions, bootloaders, and mount points. This is implemented as a task/template pair. See the cohesity-classify-node-6.5.1b task and the cohesity-classify-6.5.1b.tmpl template for examples.

Apply Post-Installation Tasks¶

This is a set of tasks that are needed to finish the installation. These are tasks that are post tasks from the kickstart file within the iso. The cohesity-choose-version script will append these tasks to the post install part of the kickstart install process. This is a list of task specified in cohesity-post-install-tasks and is usually contained in the cohesity profile assigned to the machine.

A big change from 6.3 to 6.5 is that most of the post install tasks are moved into a single RPM install. There are example tasks for each release.

Adding New ISOs¶

To add a new iso support, you will need the ISO for the release and to perform the following steps:

Create a new cohesity profile. Start with making a copy of the previous release profile in profiles/ and fixing up the names in the params to match the current release. You will also need to find the swrpms file on the ISO and fix the relative path to it.
Create a new bootenv for the ISO. This is also pretty straightforward, just copy/paste from the previous one in bootenvs/ and fix up the names.
Create a classify task/template from the kickstart on the Cohesity ISO.
Create a new post-install task.
Test and Iteratively Fix

All of this assumes that you have the ISO and extract the kickstart file from the ISO.

Create Cohesity Profile¶

Starting with the closest release, clone the profile with the new release name.

The profile has the following parameters that need to be updated:

cohesity/install-version: This is the short version string it should match the ISO name. e.g. cohesity-6.5.1b
cohesity/release-package: This is the post-install software RPM. It should be the path to it on the ISO. e.g. postinstall/swrpms-6.5.1b_ent_release-20201220_b00dce0c.x86_64.rpm
cohesity/classify-task: This is name of the pre-install classification task. e.g. "cohesity-classify-node-6.5.1b"
cohesity/post-install-tasks: This is the post install task list. It is a space separated list. e.g. "cohesity-copy-and-install-release-6.5.1b"

Create BootEnv for ISO¶

Starting with the closest BootEnv to this release, clone it to a new name.

Update the name fields to match the new release. This is an example of the top part. All the templates can stay the same. Other than the name, the main fields to update are the IsoFile and the Sha256. These need to match the ISO name and the SHA256 sum of the iso. Name must end in -install.

Name: cohesity-6.5.1b-install
Description: Install environment for Cohesity appliances.
Loaders:
  amd64-uefi: 'EFI/BOOT/BOOTX64.EFI'
OS:
  Name: cohesity-6.5.1b
  Family: "redhat"
  SupportedArchitectures:
    x86_64:
      IsoFile: cohesity-6.5.1b_ent_release-20201220_b00dce0c-centos.iso
      Sha256: 'd7b5b3c4977600e6c2dea8340cde933ed3a4f4e764e2bfa416be90598b8d09df'
      Kernel: images/pxeboot/vmlinuz
      Initrds:
        - "images/pxeboot/initrd.img"
      BootParams: >-
        ksdevice=bootif
        ks={{.Machine.Url}}/compute.ks
        method={{.Env.InstallUrl}}
        inst.geoloc=0
        {{.Param "kernel-options"}}
        --
        {{.Param "kernel-console"}}
OptionalParams:
  - "operating-system-disk"
  - "provisioner-default-password-hash"
  - "kernel-console"
  - "kernel-options"
  - "proxy-servers"
  ```

### Create Classify Task

This is where things get fun.
The task is simple, just copy/paste from the last one in `tasks/` and fix up the names.
The template is tricker, since we are converting the `%pre` section of the kickstart into
a task that will run in Sledgehammer.

1. Create a new template in `templates/` named `cohesity-classify-$RELEASE.tmpl` (where $RELEASE is the Cohesity version
   as recorded in the `cohesity/install-version` param in the profile you created above) and copy the
   entire `%pre` section from the kickstart pointed at in the `isolinux/isolinux.cfg` file on the extracted ISO.
1. Strip out anything related to console redirection or redirection to a log file.  This will run as a task under
   Sledgehammer (our in-memory utility OS image), so all output will be captured and logged to the dr-provision
   endpoint.  We don't want operators to have to log into the box to review the log output from this script when
   they could just look at the job log output instead.
1. Convert any code that would stop and ask a question or attempt to stop the install by whatever means to instead
   just `exit 1`. That will stop the install process until an operator can examine the job log and take whatever
   remedial action is needed.
1. Delete the DHCP config section.  Network configuration during the install will always be via DHCP, and network
   configuration post-install is handled by `tasks/cohesity-post-ip-boot-configure.yaml`.
1. Delete the root password configuration section.  That is handled via the `cohesity/root-password` param in
   `params/cohesity-root-password.yaml`.  If it needs to change from the default, add the new correct value to the
   new profile you created in step 1.
1. Add the following lines to the end of the template:

```sh
echo "Finish preinstall script."
if [[ "$HOME" == "" ]] ; then
export HOME=/root
fi
drpcli machines set {{.Machine.UUID}} param cohesity/bootloader-configuration to - < <(jq -Rsc '. |split ("\n")' < /tmp/create_bootloader_configuration)
drpcli machines set {{.Machine.UUID}} param cohesity/boot-partition-configuration to - < <(jq -Rsc '. |split ("\n")' < /tmp/create_boot_partition)
drpcli machines set {{.Machine.UUID}} param cohesity/install-partition-configuration to - < <(jq -Rsc '. |split ("\n")' < /tmp/create_install_partitions)

This will make sure the parameters that templates/cohesity-kickstart.tmpl uses to generate the proper partition layout for the device are set.

Make sure you remember to add the task name to the cohesity profile as the parameter, cohesity/classify-task.

Create Post-Install Tasks¶

In the 6.3 release, this was a set of tasks that created users, mounted filesystems, and installed content.

In the 6.5 and up releases, this was converted into a single RPM install. Review the kickstart post install to make sure that the only actions being taken are:

Copy RPM to the local system.
Copy the module enable script to the local system.
Install the RPM and check for errors.

Once that is done, copy and paste the previous post install task (tasks/cohesity-copy-and-install-release-$VERSION.yaml), fixing up names and versions as appropriate. If there are any new files that need to be copied based on what is in the %post section of the new kickstart, include them. Do not copy over any console redirection stuff, since this code will run as a job and all output from it will be logged back to dr-provision.

Remember to set the post-install tasks in the cohesity profile with the cohesity/post-install-tasks parameter.

Test and Iteratively Fix¶

Upload the ISO you are testing to the dr-provision endpoint with drpcli isos upload $COHESITY, where $COHESITY is the ISO name you put in the bootenv.
Run tools/package.sh to generate a cohesity.yaml content bundle from the source tree. If the package script record any errors, fix them and rerun the script.
Upload cohesity.yaml to the DRP endpoint with drpcli contents upload cohesity.yaml. If the upload process fails, it is generally because of a syntax error in whatever you were last editing. Fix it, rerun tools/package.sh, and proceed.
Pick a target machine and set its workflow to cohesity-basic-install. That will cause the machine to:
Reboot into Sledgehammer
Check that there isn't a preexisting Cohesity install. If there is, the install process must be forced by setting the cohesity/allow-reinstall Param on the machine to true.
Run the version-specific slassify task to figure out what the appropriate disk layout for this system should be. This is what was extracted from the %pre section of the kickstart. If it fails, the appropriate job log will contain the failure message. Fix whatever was broken, regenerate and reupload content with needed, then mark the machine as Runnable and execution will restart with this job.
Reboot into the Cohesity install boot environment and perform the OS install.
Execute the post-install taks to install the Cohesity RPMs and stage our agent.
Reboot to the local disk, finish up the install, configure the network according to the cohesity/configure/management param if set, then remove our agent. If everything gets this far without error, the install is complete.