Patching the OS of Swarm Infrastructure servers

We are frequently asked whether it is OK or not to patch the OS via standard package managers (eg yum). In a nutshell it is fine, though the following needs to be borne in mind:

• If the patching uses mirrors of the public repos for Centos7/RHEL7, and provided you have not installed anything other than standard Centos/Linux tools from those repos, then this is fine.

• If the repos are however NOT mirrors (eg they contain upstream packages), then we cannot guarantee these will be fine. This is also the case if these upstream repos are public (eg local customised repos).

• We simply don't test interoperability with anything other than standard packages from standard Centos7 repo (http://mirror.centos.org/centos/7/os/x86_64/)

The OS stack is far too large for us to certify a complete set of “compatible” patches. We simply state we will work with the latest patches PROVIDED you are ONLY patching the core packages that were installed as part of the OS at deployment, that you are using trusted sources of repos (ie mirrors of the distribution, and NOT using upstream versions of packages), and we state that we routinely upgrade our test servers to the latest patch versions and perform our QA testing on those.

We do not control “your” OS – it is for you to modify as you require but it is important that you understand you are responsible for those changes as you would be any other server in your organisation. We want to give you certain freedom to control your own security processes, otherwise you would be required to only follow basic security configurations, and that would likely limit other aspects of your process.

Ultimately, OS patching is a judgement call by you. It will be actioned and performed by you and is not a role for DataCore support. If you follow the guidance given everything should be fine, but in the event of an issue DataCore Support is there to help you out to the best of our ability, but remember we are not the OS Distribution Maintainer.

It is important to understand the following

• Swarm applications are software products that operate on top of standard RHEL7/CentOS7 servers.

• The operating system (OS) is always the responsibility of the customer

• We do not lock down the OS in any way, therefore it is entirely at the customer’s risk if additional software is installed, upstream versions of standard distribution packages are installed, or the OS is reconfigured outside of how it was initially installed

• DataCore provides virtual machine deployments (by OVA or SCI), but this is entirely as a convenience for the customer, not a statement of our intention to support the OS. It should not be considered as a virtual appliance. Once deployed, the OS becomes the responsibly of the customer, not DataCore.

• Within our QA testing, DataCore uses minimal installs of RHEL7 and CentOS7 distributions, along with a few key additional packages. We do not “harden” these installations. We will routinely upgrade those core packages to latest security builds using only standard RHEL/CentOS repositories, along with latest versions of Swarm software. This is the extent of the testing of package interoperability. We do not regressively check packages against older versions of Swarm software. We do not and will not check against customer installed OS packages or hardening requirements.

• It is the customer’s responsibly to take dure care and attention when performing any upgrades to the core OS. DataCore recommends that any upgrades should be first tested on a test environment, and prior to push upgrades to the production environment, those production servers should be protected via snapshots and/or backups

• DataCore may make suggestions as to changes to the OS configuration, but it is the customer’s responsibility to understand the effect of those changes. If DataCore feels that customer changes or patches have created a major interoperability issue, DataCore will not be involved in trying to remediate it and will suggest a rollback to the last known working snapshot/backup or a reinstallation/redeployment from scratch. The customer will be responsible for retaining and reconstituting configurations and/or logging and telemetry data that will have been created since the last-known-good copy.

• DataCore does not and will not validate customer’s OS environments, their patching requests, or their hardening requirements.