Upgrades and updates#
To ensure a consistently feature-rich and secure experience, all supported versions of Scrutinizer will continuously be updated. When installed, update packages may add new features, improve existing functionality, and/or apply patches for emerging security threats. All update packages will have been applied to Plixer’s own QA servers and extensively tested before they are made available.
Important
While it is possible to install Scrutinizer update packages without assistance, it is highly recommended to contact Plixer Technical Support and allow our engineers to guide you through the process.
On this page:
Pre-upgrade checks/preparations#
The checks below are meant to identify and resolve any underlying issues with the current Scrutinizer install and should be completed before the scheduled upgrade window to help ensure that the upgrade will be successfully completed.
All install logs are saved to /var/log/Scrutinizer-Install.log.
All upgrades#
A current backup of the install is available:
Virtual appliances: Take a snapshot, ideally with the appliance powered off.
Hardware appliances: Perform a full or configuration backup. For further details, see the Backups subsection of this documentation or contact Plixer Technical Support.
Web interface and SSH (
plixeruser) credentials are available for every Scrutinizer server/collector being upgraded.Vitals LEDs are green in the Scrutinizer Admin interface.
The root disk has at least 5 GB of free space:
df -h /The upgrade path and estimated duration have been confirmed against the upgrade path table.
Offline upgrades#
The offline packages have been downloaded, moved to
/var/db/big/offline/(requires 100 GB free), and checksum-verified. Allow extra time to download/transfer the offline bundle due to its size. If necessary, add more storage or deploy a temporary Scrutinizer as the offline repository host.The offline packages should not be staged on the root filesystem as they can fill the root disk and stop flow collection.
If using an active primary reporter for the offline repository, 10% of its total disk space must remain available after the offline packages are downloaded and extracted. This will prevent automatic history trimming.
Situational checks#
Each check below leads with the situation it applies to. Skim the bold labels and complete only the checks that match the deployment being upgraded.
Click to view checks
Version upgrades - Verify that the Scrutinizer server/appliance meets the target version’s minimum resource requirements for:
Flows per second
Number of active Exporters
CPU (number of cores, clock speeds)
Amount of RAM
Disk speed and RAID type
Flow Analytics Algorithms enabled
Important
Do not proceed with the upgrade if the server is underprovisioned. Contact Plixer Technical Support for assistance with tuning system parameters or allocating additional resources to the server.
Scrutinizer 19.7.0+ upgrades - If Scrutinizer is being upgraded to v19.7.0 or higher for the first time, contact Plixer Technical Support for a new Plixer One license key to enable AI features.
Internal NTP server - If the Scrutinizer server being upgraded does not have Internet access, an internal NTP server can be configured by running the following:
sed -i -e '/^pool/aserver NTP_ADDRESS' -e 's/^pool/#&/' /etc/chrony.confOnline upgrades - Confirm that all Scrutinizer collectors/servers can reach
https://files.plixer.comby downloading the checksum file:curl -O https://files.plixer.com/plixer-repo/scrutinizer/19.8.0/scrutinizer-install.run.sha256
For deployments without Internet access, download the file from the
REPO_HOST_IPof the offline yum/dnf repository instead.Licensing - Obtain a valid license key if one has not already been acquired for the target version.
Previously upgraded servers - Delete any older versions of
scrutinizer-install.runon the Scrutinizer instance. This prevents them from being used instead of the correct installer.Hardware appliances - Log in to iDRAC and perform a hardware health check. Escalate any issues found to Dell for resolution. A reboot is also recommended as an additional check for underlying hardware issues.
AWS AMI Scrutinizer 19.4.0 deployments - AWS AMI deployments on v19.4.0 should follow this guide to upgrade to v19.5.4 instead of upgrading to v19.5.3. The latest AMI installer is available from Plixer Technical Support.
Once all applicable checks are complete, follow the instructions in the next section to upgrade Scrutinizer to the latest version.
Changed in version 19.1: plixer is the recommended OS user for command line access. The root user is no longer required.
Scrutinizer 19.8.0#
The standard upgrade procedure updates Scrutinizer to the latest release, which may include new functionality, performance enhancements, and/or fixes.
Upgrade paths#
The Scrutinizer 19.8.0 upgrade can only be installed on Scrutinizer servers running v19.6.0 or higher. Deployments on older versions must be upgraded in stages, as shown below.
Starting version |
Upgrade path |
Estimated time |
|---|---|---|
19.6.x / 19.7.x |
19.8.0 |
30 -> 45 minutes |
19.5.x |
19.7.2 -> 19.8.0 |
~1 hour |
19.4.0 |
19.5.3 -> 19.7.2 -> 19.8.0 |
~2 hours |
Pre-19.4.0 |
3+ hours |
Intermediary upgrades between 19.x versions are installed following the same procedure as the upgrade to the latest version (download URLs must be edited to use the correct target version e.g., 19.8.0 -> 19.7.2). For upgrades to v19.4.0 and v19.5.3, follow the links in the table above.
Upgrade steps#
After the recommended update checks/preparations have been completed, the Scrutinizer 19.8.0 installer can be downloaded and installed as follows:
Click to view instructions
SSH to the primary reporter as the
plixeruser:ssh plixer@SCRUTINIZER_IPStart a new tmux session (to maintain the upgrade session if the SSH connection is lost):
tmux new -s upgradeDownload the installer and the checksum file for the latest version:
curl -O https://files.plixer.com/plixer-repo/scrutinizer/19.8.0/scrutinizer-install.run curl -O https://files.plixer.com/plixer-repo/scrutinizer/19.8.0/scrutinizer-install.run.sha256
Verify the checksum:
sha256sum -c scrutinizer-install.run.sha256Set the correct permissions for the installer:
chmod 755 scrutinizer-install.runRun the installer as the
plixeruser:./scrutinizer-install.run[Distributed cluster upgrades only] When prompted for the authentication method to use for remote collectors in the cluster, enter either
existing(recommended) orpasswords.After the installer finishes running, execute the following heartbeat checks to verify communication between nodes:
scrut_util --check heartbeat --type database scrut_util --check heartbeat --type api
If the heartbeat checks are successful, the upgrade is complete.
Offline upgrades#
Offline Scrutinizer servers (i.e., servers that cannot access the default yum/dnf repository on https://files.plixer.com/plixer-repo/scrutinizer/19.8.0) can be upgraded by setting up an offline repository on any local Scrutinizer server, including the primary reporter.
Warning
Always download and stage the offline bundle under /var/db/big/offline/. Downloading it to the root filesystem (e.g., to /home/plixer) can fill the root disk and stop flow collection.
Before starting, verify that /var/db/big/offline/ on the repo host has at least 100 GB of free disk space:
df -h --output='avail' /var/db/big/offline
If necessary, add more storage or deploy a temporary Scrutinizer server to serve as the offline repository host.
Follow these steps to set up the offline repository on a Scrutinizer server (with IP address REPO_HOST_IP):
Click to view instructions
Start an SSH session with the offline repo host as the
plixeruser:ssh plixer@REPO_HOST_IPCreate a new directory for the offline installation files and set the correct permissions to give the plixer user access to it:
sudo mkdir -p /var/db/big/offline sudo chown plixer:plixer /var/db/big/offline
If the directory already exists, delete all its contents (older offline installation files) before continuing.
Download the offline repo package and checksum file, specifying
/var/db/big/offlineas the destination:curl -o /var/db/big/offline/19.8.0_offline.tgz https://files.plixer.com/plixer-repo/scrutinizer/19.8.0_offline.tgz curl -o /var/db/big/offline/19.8.0_offline.tgz.sha256 https://files.plixer.com/plixer-repo/scrutinizer/19.8.0_offline.tgz.sha256
Note
If the repo host does not have Internet access, download both files on a separate Internet-connected host - to a staging directory with at least 84 GB of free space - and then copy them to the repo host:
scp 19.8.0_offline.tgz* plixer@REPO_HOST_IP:/var/db/big/offline/
On the repo host, validate the checksum:
(cd /var/db/big/offline/ ; sha256sum -c 19.8.0_offline.tgz.sha256)Extract the repository:
tar -zxvf /var/db/big/offline/19.8.0_offline.tgz -C /var/db/big/offlineCreate a link to the offline repo in a directory accessible to the web server:
sudo -u webapp ln -sf /var/db/big/offline/plixer-repo /home/webapp/html/Note
For versions before 19.7.0, use
ln -sf /var/db/big/offline/plixer-repo /home/plixer/scrutinizer/html/plixer-repoinstead.After the offline repo host has been set up, SSH to the primary reporter as the
plixeruser:ssh plixer@SCRUTINIZER_IPStart a new tmux session (to maintain the upgrade session if the SSH connection is lost):
tmux new -s upgradeDownload the installer and the checksum file for the latest version:
curl -O https://REPO_HOST_IP/plixer-repo/scrutinizer/19.8.0/scrutinizer-install.run curl -O https://REPO_HOST_IP/plixer-repo/scrutinizer/19.8.0/scrutinizer-install.run.sha256
Verify the checksum:
sha256sum -c scrutinizer-install.run.sha256Set the correct permissions for the installer:
chmod 755 scrutinizer-install.runRun the installer:
If the offline repo is hosted on the primary reporter:
REPO_HOST=local LOCAL_REPO_BASEDIR=/var/db/big/offline ./scrutinizer-install.run
If the offline repo is hosted on a different Scrutinizer server:
REPO_HOST=REPO_HOST_IP ./scrutinizer-install.run -- -k
[Distributed cluster upgrades only] When prompted for the authentication method to use for remote collectors in the cluster, enter either
existing(recommended) orpasswords.After the installer finishes running, execute the following heartbeat checks to verify communication between nodes:
scrut_util --check heartbeat --type database scrut_util --check heartbeat --type api
If the heartbeat checks are successful, the upgrade is complete.
[Optional] Delete the bundle to reclaim disk space now that the repository has been extracted:
rm /var/db/big/offline/19.8.0_offline.tgz
Upgrading pre-19.6.0 Scrutinizer servers#
Scrutinizer servers running versions older than 19.6.0 must be upgraded to v19.6.0+ (v19.7.2 is recommended) before the final upgrade to v19.8.0.
Changed in version 19.5.0: The Scrutinizer 19.5.0 upgrade includes the migration to Oracle Linux 9, which will be required for all new versions/releases going forward. Deployments on older versions must first be upgraded to the latest v19.5.x release before being upgraded further.
Follow the guides below based on the starting version of the Scrutinizer server.
Upgrading from older versions to Scrutinizer 19.4.0 (required to upgrade to v19.5.3)#
Click to expand instructions
Pre-v19.4.0 Scrutinizer deployments must first be upgraded to v19.4.0 before being upgraded to v19.5.3, which includes the migration to Oracle Linux 9.
Follow these instructions to download the v19.4.0 installer (replace 19.8.0 with 19.4.0 in the download URLs) and apply the update. When done, proceed with the upgrade from 19.4.0 to v19.5.3 (or v19.5.4 for AWS AMI deployments) as described below.
Note
When upgrading an appliance that was previously upgraded from v18.20, the installer script will ask whether to delete the
data.oldbackup created during that upgrade. Since a more recent backup should be created before the current upgrade process, this file can safely be deleted.If a distributed cluster is being upgraded from v18.20, the prompt to create a new Plixer control key should be left blank unless encrypted keys are required. Additionally,
passwordsshould be selected in the next step, when prompted for the login method to use for remote collectors.
Upgrading from 19.4.0 to 19.5.3#
Click to expand instructions
Follow the steps outlined below to upgrade a Scrutinizer deployment on v19.4.x to v19.5.3.
To upgrade an AWS AMI from 19.4.0 to v19.5.4, follow this guide instead.
Note
The upgrade will take at least one hour to complete.
The
plixeruser SSH password will be needed during the upgrade. If necessary, it can be reset when the OS upgrade script is run.If root SSH login is enabled on the Scrutinizer server, it will be disabled as part of the upgrade.
If upgrading from v19.5.0 or above, proceed directly to upgrading to Scrutinizer 19.5.3.
If the Scrutinizer server is able to access
files.plixer.com, theREPO_HOSTvariable should be set tofiles.plixer.comfor the steps outlined below. For offline upgrades, the IP address of the offline repo should be used instead.
For assistance or clarifications, contact Plixer Technical Support.
Upgrade process
The process of upgrading a v19.4.0 Scrutinizer server to v19.5.3 involves the following steps:
Backing up the current install’s database and server-specific files
Downloading the operating system upgrade script,
olmigrate.run, and running it a total of four times (with a reboot between runs). This only applies if upgrading from v19.4.0.Downloading and running the Scrutinizer v19.5.3 installation script (
scrutinizer-install.run)Verifying that the current install’s data has been successfully migrated after v19.5.3 is installed
Pre-upgrade checks/preparation
[Hardware appliances] Create a full backup of the current Scrutinizer install and store it on an external system/drive.
[Virtual appliances] Back up the current Scrutinizer install by taking a VM snapshot.
Review the general update preparation guide and complete any steps that apply.
[Offline upgrades] If the Scrutinizer server does not have access to
files.plixer.com, set up an offline repository for this upgrade.
Distributed cluster upgrades
Remote collectors in distributed clusters must be reverted to standalone appliances before being individually upgraded to v19.5.3:
Click to view instructions
Navigate to Admin > Resources > Collectors and delete all remote collectors.
SSH to each remote collector as the
plixeruser and register it as a standalone appliance:scrut_util --set selfregister --resetVerify that each appliance is now running in standalone mode (no other addresses under
collector_ips):scrut_util --check dist_info
When done, proceed with the OS migration and v19.5.3 upgrade for each node, and then rebuild the distributed cluster.
OS migration
Once all preparation steps have been completed, follow these steps to migrate the v19.4.0 appliance to the new operating system:
Click to view instructions
Important
For offline upgrades,
REPO_HOSTshould point to the IP address of the offline repo instead offiles.plixer.com.In distributed clusters, complete the upgrade for all remote collectors before upgrading the primary reporter.
To verify the current progress of the OS upgrade at any time:
cat /etc/motdor check versions between runs (
NAME=andVERSION=lines):cat /etc/os-releaseIf any errors are encountered during the upgrade process, run the following to collect log files:
sudo tar -czf /tmp/olmigrate_logs.tar.gz /var/log/olmigration/ /var/log/leapp/ /var/log/messages /var/log/Scrutinizer-Install.logAfterwards, move
/tmp/olmigrate_logs.tar.gzoff the server before reverting. Plixer Technical Support will require the logs to better assist you with any issues.
SSH to the v19.4.0 server to be upgraded as the
plixeruser.Verify that the current working directory is correct (
plixer):cd /home/plixer/Download the OS upgrade script and its checksum file:
REPO_HOST=files.plixer.com curl -k -o olmigrate.run https://$REPO_HOST/plixer-repo/scrutinizer/19.5.3/olmigrate.run curl -k -o olmigrate.run.sha256 https://$REPO_HOST/plixer-repo/scrutinizer/19.5.3/olmigrate.run.sha256
Validate the integrity of
olmigrate.run:sha256sum -c olmigrate.run.sha256Update permissions for the OS upgrade script:
chmod a+x olmigrate.runRun the
olmigrate.runscript a total of four times:REPO_HOST=files.plixer.com ./olmigrate.run -- -k
Important
Reboots between runs of the OS upgrade script (
olmigrate.run) can take a long time. Before trying to reconnect to the server, start aPINGto the Scrutinizer IP address and wait for it to become available again. Do NOT manually reboot the server.
After the fourth olmigrate.run run (there will be no reboot), the OS migration will be complete.
Upgrading to Scrutinizer 19.5.3
Once the appliance is on the new OS, Scrutinizer can be upgraded to v19.5.3 as follows:
Click to view instructions
Change directories to
/tmp:cd /tmp/Download the Scrutinizer v19.5.3 installation script and its checksum file:
REPO_HOST=files.plixer.com curl -k -o scrutinizer-install.run https://$REPO_HOST/plixer-repo/scrutinizer/19.5.3/scrutinizer-install.run curl -k -o scrutinizer-install.run.sha256 https://$REPO_HOST/plixer-repo/scrutinizer/19.5.3/scrutinizer-install.run.sha256
Validate the integrity of
scrutinizer-install.run:sha256sum -c scrutinizer-install.run.sha256Update permissions for the installation script:
chmod a+x scrutinizer-install.runRun
scrutinizer-install.runto begin the upgrade to Scrutinizer v19.5.3:REPO_HOST=files.plixer.com ./scrutinizer-install.run -- -k
After the installation script finishes running, reboot the appliance:
sudo shutdown -r nowAfter the reboot, run the following commands to verify that the system is in working order:
scrut_util --check heartbeat --type database scrut_util --check heartbeat --type api
Important
For distributed clusters, the heartbeat checks should only be run on remote collectors after the primary reporter has been upgraded, and the cluster has been reestablished.
If the heartbeat checks are successful, then the Scrutinizer appliance has been successfully upgraded to v19.5.3.
Offline upgrades to v19.5.3
The following instructions for setting up an offline repo are intended for upgrading to Scrutinizer v19.5.3 only.
Click to view instructions
SSH to the VM as the
plixeruser:ssh plixer@SCRUTINIZER_VM_IPCreate the offline repo directory and assign it the correct permissions:
sudo mkdir /var/db/big/offline sudo chown plixer:plixer /var/db/big/offline
Download the offline tar file for 19.5.3 and its checksum file:
curl -o /var/db/big/offline/19.5.3_offline.tgz https://files.plixer.com/plixer-repo/scrutinizer/19.5.3_offline.tgz curl -o /var/db/big/offline/19.5.3_offline.tgz.sha256 https://files.plixer.com/plixer-repo/scrutinizer/19.5.3_offline.tgz.sha256
Validate the integrity of
19.5.3_offline.tgz:sha256sum -c /var/db/big/offline/19.5.3_offline.tgz.sha256Extract the offline tar file:
cd /var/db/big/offline tar xvf 19.5.3_offline.tgz
Create a symlink in the html directory to the offline repo:
ln -s /var/db/big/offline/plixer-repo /home/plixer/scrutinizer/html/plixer-repoAfter the offline repository has been created, start an SSH session with the Scrutinizer server to be upgraded as the
plixeruser and change directories to/tmp:ssh plixer@SCRUTINIZER_IP cd /tmp/
Download the Scrutinizer v19.5.3 installer and its checksum file from the offline repository VM:
REPO_HOST=OFFLINE_REPO_VM_IP curl -k -o scrutinizer-install.run https://$REPO_HOST/plixer-repo/scrutinizer/19.5.3/scrutinizer-install.run curl -k -o scrutinizer-install.run.sha256 https://$REPO_HOST/plixer-repo/scrutinizer/19.5.3/scrutinizer-install.run.sha256
Validate the integrity of
scrutinizer-install.run:
sha256sum -c scrutinizer-install.run.sha256
Update permissions for the installation script:
chmod a+x scrutinizer-install.run
Run
scrutinizer-install.runto begin the upgrade to Scrutinizer v19.5.3:
REPO_HOST=OFFLINE_REPO_VM_IP ./scrutinizer-install.run -- -k
After the installation script finishes running, reboot the appliance:
sudo shutdown -r now
After the reboot, run the following commands to verify that the system is in working order:
scrut_util --check heartbeat --type database
scrut_util --check heartbeat --type api
Important
For distributed clusters, the heartbeat checks should only be run on remote collectors after the primary reporter has been upgraded, and the cluster has been reestablished.
If the heartbeat checks are successful, then the Scrutinizer appliance has been successfully upgraded to v19.5.3.
Upgrading from Scrutinizer 19.4.0 to 19.5.4 (AMI only)#
Click to view guide
Follow the steps outlined below to upgrade a Scrutinizer AMI on v19.4.0 or above to v19.5.4.
For versions < 19.4.0, refer to this guide to upgrade to v19.4.0 before proceeding.
Note
The upgrade will take at least one hour to complete.
The
plixeruser SSH password will be needed during the upgrade.If root SSH login is enabled on the Scrutinizer server, it will be disabled as part of the upgrade.
The new v19.5.4 instance must be in the same availability zone as the original v19.4.0 machine. Volumes outside the current availability zone will not be accessible from the AWS console.
Distributed cluster upgrades
Remote collectors in distributed clusters must be reverted to standalone appliances before being individually upgraded to v19.5.4:
Click to view instructions
Navigate to Admin > Resources > Collectors and delete all remote collectors.
SSH to each remote collector as the
plixeruser and register it as a standalone appliance:scrut_util --set selfregister --resetVerify that each appliance is now running in standalone mode (no other addresses under
collector_ips):scrut_util --check dist_info
When done, proceed with upgrading each node as described below, and then rebuild the distributed cluster.
For assistance or clarifications, contact Plixer Technical Support.
Upgrade process
The process of upgrading a Scrutinizer 19.4.0 Scrutinizer AMI to v19.5.4 involves the following steps:
Backing up the current Scrutinizer install by taking a VM snapshot
Deploying a new v19.5.4 AMI appliance
Copying the
dbexport.shfile from the new v19.5.4 appliance to the current v19.4.0 applianceDetaching the storage volume from the v19.4.0 instance (using
dbexport.shand running as therootuser)Attaching the storage volume to the new v19.5.4 instance (using
dbimport.shand running as therootuser)Verifying that the v19.4.0 data has been successfully migrated after v19.5.4 is installed
Expanding storage
AMI deployments will require additional storage to be upgraded to v19.5.4.
Click to view instructions
To verify whether the Scrutinizer 19.4.0 AMI instance is running on the default sizing, run the following:
df -h
If the output does not list a line that includes vg_scrut-lv_db, contact Plixer Technical Support for assistance with expanding storage before proceeding.
Upgrading to Scrutinizer 19.5.4
Click to view instructions
Copy the following file from the new v19.5.4 appliance to your current v19.4.0 appliance:
/home/plixer/scrutinizer/files/dbimport/dbexport.shRun the following command to make
dbexport.shexecutable:sudo chmod +x dbexport.shSSH to the 19.4.0 appliance as the
plixeruser, and then navigate to the location wheredbexport.shwas saved.Run the script to prepare the 19.4.0 storage volume to be detached:
sudo ./dbexport.sh exportdbShut down the Scrutinizer v19.4.0 instance.
In the AWS EC2 management page, navigate to the Volumes page.
In the Volume Management page, select the storage volume, click the Actions menu, and then select Detach volume. It may take a minute for the storage volume to go from In use to Available.
Once the detached storage volume(s) are marked as Available (it may take several minutes), attach it to the Scrutinizer v19.5.4 instance. Refer to STEP 6 of the storage expansion instructions.
After the storage volume(s) have been attached, SSH to the 19.5.4 instance as the
plixeruser.Run the following to import and set up the database on the 19.5.4 instance.
/home/plixer/scrutinizer/files/dbimport/dbimport.sh importdb <device name for the storage volume, e.g. /dev/xvdg>
Use the lsblk and show partitions commands to get the correct partition/device name to use. Once the script completes running, Scrutinizer will run a self-register reset that requires user input for verification.
Add a new license key to fully activate your Scrutinizer v19.5.4 instance.
Note
If there are multiple volumes listed after
dbexport.shcompletes running, all volumes will need to be detached from the v19.4.0 instance and attached to the v19.5.4 instance.At the end of the output from
dbexport, the volumes that are part of the volume group for the database are listed. If the volume group contains more than one volume, the output will list all of those volumes, which will need to be detached and then attached to the Scrutinizer v19.5.4 instance.When you first log in to the v19.5.4 UI to add a new Scrutinizer license, you must use the UI admin password for the v19.4.0 AWS instance. Alternatively, you can reset the UI admin password in
scrut_utilfirst.
General and CVE patches#
From time to time, customers may be notified that general and/or CVE patches are available for the Scrutinizer version they are currently running. These patches typically address noncritical system issues and/or improve protections against new security threats.
Note
The Scrutinizer version number is not incremented as a result of general or CVE patches.
To apply these updates, follow the version upgrade instructions to download and run the latest installer for the current Scrutinizer version. Going through the standard update preparations is also highly recommended.
When run, the installer will automatically download and apply all available patches.
Vulnerability patch verification#
Some vulnerability scanning and auditing solutions may report vulnerabilities that have already been patched in the most recent update. This is typically the combined result of a backported security patch and the tool only scanning for component version numbers.
If this happens, there are two ways to verify the validity of the vulnerability report:
Check the package changelog for the CVE identifier/number of the vulnerability (e.g., CVE-2017-3169)
Download and install the latest OVAL definitions from
oval.cisecurity.org/repository, which will allow any compatible tools to determine the status of vulnerabilities, even when security patches have been backported.
For additional assistance, contact Plixer Technical Support.
Plixer ML Engine 19.8.0#
Follow the steps below (after completing the recommended update preparations) to upgrade a Plixer ML Engine deployment to v19.8.0:
Important
Scrutinizer 19.8.0 requires Plixer ML Engine deployments to be upgraded to v19.5.0+. v19.8.0 is recommended.
Click to view instructions
SSH to the ML VM (i.e., the host used for management/deployment) as the
plixeruser.Download the installer for the latest version:
curl -o plixer-machine-learning-update.run https://files.plixer.com/scripts/plixer-machine-learning/release/19.8.0/plixer-machine-learning-update.run
Download the checksum file and validate the integrity of
plixer-machine-learning-update.run:curl -o plixer-machine-learning-checksums.txt https://files.plixer.com/scripts/plixer-machine-learning/release/19.8.0/plixer-machine-learning-checksums.txt cat plixer-machine-learning-checksums.txt sha256sum plixer-machine-learning-update.run
Set the correct permissions for the installer:
chmod +x plixer-machine-learning-update.runRun the installer as the
plixeruser:STAGE="release" VERSION="19.8.0" STAGE=$STAGE ./plixer-machine-learning-update.run
After the installer script completes running, setup.sh will automatically be run to pull in any configuration changes and redeploy pods with new images. AWS ML engine deployments will require these additional steps to be upgraded.
Important
When an upgrade includes a newer version of pxi-settings.yaml, azure.tfvars, aws.tfvars, and/or vsphere.tfvars, the pre-upgrade files are retained, and the latest versions are saved with the .dpk-dist extension instead.
Migrate any custom settings that should not be overwritten from the existing configuration files to their .dpk-dist counterparts before replacing the former with the latter.
Once the upgrade process is complete, wait for the rke2-server service to restart. This sequence can be monitored by running:
journalctl -xeu rke2-server -f
Plixer ML Engine 19.8.0 - AWS deployments#
After the ML VM (management/deployment host) has been upgraded, follow these steps to upgrade an AWS ML engine cluster to 19.8.0:
Click to view instructions
Copy the contents of ~/common/kubernetes/aws/.terraform.lock.hcl to ~/common/kubernetes/aws/.terraform.lock.hcl.bak on the ML VM.
Navigate to
/home/plixer/common/kubernetesand run the Kubernetes cluster deployment script:./01_aws_infrastructure.shVerify that there were no errors during the script.
Update the
kube_versionvalue to"1.32"in/home/plixer/common/kubernetes/aws.tfvars.Run
01_aws_infrastructure.shagain and check for errors.Update the
kube_versionvalue to"1.33".Run
01_aws_infrastructure.shagain and check for errors.Navigate to
/home/plixer/mland re-initialize the cluster:./setup.sh --redeploy
The rke2-server service will restart after configurations are updated and pods are re-deployed with new images.
ML engine upgrades from v19.4.0 to v19.5.0+#
Scrutinizer 19.6.0+ features a new management/configuration UI for the ML engine. Any v19.4.0 ML engine deployments will need to be re-registered in the Scrutinizer web interface and then upgraded (not re-deployed) to v19.5.0 or higher.
If the ML engine is deployed as a standalone/single-node VM, new Docker images will be downloaded (may take several minutes) after the package updates. This step is skipped for cloud deployments.