This post will cover a new hot fix (HF) build for the Dockers version of the SRDF SRA. The new release is tagged as version Development has worked overtime to come up with solutions to the couple of issues I’ve outlined in this previous post:

  • Requirement to re-run the shell script after reboot (for hostname use in Solutions Enabler)

  • Requirement to re-add vCenter authorizations after upload of new configuration files/reboot

There was an additional issue where the script failed to create the directory /tmp/vmware-root, but the new changes do away with storing the hostname file under /tmp so it is no longer required.

As is sometimes necessary, a quick disclaimer:

Because this HF has not undergone the VMware certification tests, it will not be posted on the VMware site and will only be posted on our site. In addition, it will not replace the current GA software. Therefore my official TechBook documentation will NOT change. It will only cover the GA release. This blog post will serve, along with perhaps a future KB, as the only documentation for this fix. I do, however, recommend using this HF instead of the GA version to avoid the manual workarounds I have previously documented.

That taken care of, let’s start with the changes.

If the SRDF SRA adapter is used in conjunction with the RecoverPoint SRA, this hot fix must be used or the two adapters cannot coexist.

New Changes

Hostname file

The hostname file is created as part of the initial installation of the SRA, so that when the SRA communicates with the remote Solutions Enabler installation, it passes the correct name of the SRM VM, and not the name of the container that is running in Docker on it. Without this file, the two will not communicate properly. I cover this in the TechBook. Unfortunately with the GA release of the SRA, this file is stored under /tmp and thus is removed when the SRM VM is rebooted. This can also occur with a container reload. To avoid the loss of this file upon container reload or OS reboot, the script now places the file on a mounted volume related to the SRA: /var/lib/docker/volumes/*. Therefore we don’t have to worry about the contents disappearing on a reboot because it isn’t in /tmp.

Now, because the file relies on the mounted volume, the shell script must be run after the SRA is installed, not before as was done in the GA release of the SRA. It is a small but important change. I should make mention that while it is possible to delete the mounted volume, and thus the hostname file, it can’t be done by accident and it certainly is not recommended under any circumstance. I would not worry about it, but wanted to mention it just to be thorough.

vCenter authorization

This change revolves around adding authorization for a vCenter user which will allow the SRA to filter out non-VMware devices. It is not a requirement, but many customers use the functionality. It currently requires the SYMCLI command symcfg auth. The problem with the GA version of the SRA is that these authorizations are lost if you reboot the SRM VM or upload new configuration files. Authorizations are normally stored by Solutions Enabler (SE) and persist through reboot fine; however because SE cannot be installed on Photon OS, the authorizations are lost when you reboot the OS. This means that the customer has to add back the authorizations for the SRA when the system comes up. Obviously this is untenable to most customers. In the hot fix, to enable this change, development removed the requirement for the command symcfg auth. We will now store the authorizations in an encrypted file by accepting credentials via the script. The script will prompt you for the credentials, though again this is optional. This is a one-time operation unless the username or password is changed. At that point you would have to run the script again to store the new password, as well as run a reload of the adapter in the SRM Appliance Management screen.

If you are still using Windows SRM, you will continue to use the old symcfg auth functionality since this shell script has no bearing on that operating system.


With the new build, the process to install the SRA includes a single step change, but the upgrade is more involved so I will cover that in detail.


The install process is essentially the same as I outlined in the original post save for the change to the script and when to run it as I wrote above. In the GA SRDF SRA 9.2 release, the script was run before installing the SRA. Now, it should be run after, as it relies on the mounted volumes from the SRA. 


For the upgrade, the first thing you want to do is remove any workarounds you may have implemented, in particular the one to run the shell script after each reboot. If you did follow my post, you need to login as root and remove the timer to re-run the script upon reboot. You may have modified the names, but basically you need to disable the timer. Here is an example of the command to run as root to disable the timer if you followed my naming convention from the post:

systemctl disable enableAutoSSLCertGen.timer

For good measure I recommend you remove the script itself, wherever you put it. You don’t want to accidentally run it instead of the new one with the fix. Once that is complete, you can proceed with the steps below (done on protection and recovery appliance).

  • Install the new tar file extracted from the zip file in the same way you would if installing the SRA for the first time, through the appliance management interface.

You will now have two SRAs, with the new one on the right.

  • Copy over the configuration files from the GA SRA. Fortunately you don’t have to manually back up the files from the existing SRA as you can copy them over directly in the management interface. Do this by using the 3 dots and selecting “Copy configuration”. We are able to do this because the files themselves have not been changed by development in the hot fix. If we were doing an upgrade to a new release and not a hot fix, likely we would have to use a different procedure.

The target adapter will be set automatically.

  • Next reset the configuration for the old SRA before removing it. The reset is necessary to avoid issues with the new adapter. Be careful to note that after the last step, the SRAs have swapped location in the appliance management so the new one is listed on the left. You don’t want to accidentally reset the wrong one.

  • After resetting, delete the old SRA using the same menu off the three dots from above and selecting “Delete”. You’ll need to check the boxes before being allowed to delete it.

  • Now you can run the new shell script that was part of the new zip file. Transfer it over to the SRM VM and run it as root. As I explained above, you will be prompted to enter authorization credentials if you wish. Simply enter ‘n’ if you want to skip this step. Remember credentials are to enable filtering of VMware devices, but the lack of them will not cause the SRA to fail in any way. The script will store the credentials encrypted in a hidden file, .emcpwddb (boxed below). Be aware that the only validation that the script does is force you to enter the password twice. It will not try to connect to the vCenter to validate your credentials so be sure what you are entering is correct. Once entered there is no way to view the encrypted file, but the script will list the vCenter and username upon execution, so you may wish to grab a screenshot to file away. But if you need to make changes to the credentials (because you forgot what is there or need to change them) you can re-run the shell script at any time and a new password file will be generated.

And that will complete the upgrade. From that point forward, assuming no credential changes, no additional steps will be needed, regardless of configuration file changes or appliance reboot.

Support has a technote which essentially is an abbreviated version of my post here.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Website Powered by

Up ↑

%d bloggers like this: