Data Protector Practitioners Forum

Upgrading a DP9 Client to DP10

harrytewkesbury Regular Contributor.
Regular Contributor.

Upgrading a DP9 Client to DP10


I have recently upgradede my Cell Manger to version 10.02 which is great. I decided to build a Unix Installation Server also to help with this, which is now built at 10.02 and imported in to the Cell Manager.

I am finding that for both windows and linux clients, I cannot upgrade via the IS. This is not the end of the world with Windows clients, as I can manually browse to the DP_Depot and install there before manually updating the TLS config. For linux clients, this is much more tricky.

What is the best way to get this process started?

JBasilio Acclaimed Contributor..
Acclaimed Contributor..

Re: Upgrading a DP9 Client to DP10


No idea about which error message are you receiving anyway please be sure that you have followed those steps

Environment 2: Cell Manager and Installation Server are on different hosts

If the Cell Manager and Installation Servers are on different hosts, then upgrade the Cell Manager first,
then the Installation Server. Run following commands as explained in the “
Introduction to the new
security of DP 10.00
” section.
On Cell Manager : omnicc –secure_comm –configure_peer <IS NAME>
On Installation Server : omnicc –secure_comm –configure_peer <CM NAME>
After executing these commands, import the Installation Server in the Cell Manager. If one Installation
Server is imported in multiple Cell Managers, then these commands need to be run for respective Cell
Manager / Installation Server pair.


Client installation procedure (push installation to Linux and UNIX clients)
Linux clients used to take rsh and rexec on Installation Servers (IS) to push packages to be locally installed
on clients (if not already configured to SSH).
From Data Protector 10.00, Data Protector is using SSH as
the default mechanism to send and install software on new clients. If SSH Keys are not pre-configured
between the IS and the clients, then a password will be prompted for on a per-client basis.
Benefit: SSH is a much more secure protocol when compared to rsh and rexec, which both send and
receive data in an unencrypted format. SSH sends data encrypted and is widely regarded as one of the
most secure protocols within the network. Another inherent benefit is that mutual exchange certificates
(public keys) between a Cell Manager and client will happen over this secure SSH channel.

Best Regards

harrytewkesbury Regular Contributor.
Regular Contributor.

Re: Upgrading a DP9 Client to DP10

Hi, thanks for responding.

I have gotten ssh enabled (OB2_SSH_ENABLED=1) and placed the RSA+DSA public keys on to the client's authorised_keys and can ssh from the IS to the client.

What I am unable to work out is where the connection fails. I am receiving the following error:

[Critical] <clienthostname>  [110:24] Client clienthostname : client not responding.

[Critical] <clienthostname>  Error connecting to client clienthostname
    Skipping client!

I can telnet also both ways on 5555, and from the client to the cell manager etc. The DP10 manual is very sparse on information in this regard.

Additionally, my company policy has SSH running on a non-default port. Is there a way to have DP use a different port? There's no section in omnirc that would indicate this.

JBasilio Acclaimed Contributor..
Acclaimed Contributor..

Re: Upgrading a DP9 Client to DP10

Hi harrytewkesbury

DP use port 22 for SSH conenction and there are not option for use a different one. This is described into documentation Admin.pdf page 69.

I guess that you can open support requesting any hotfix or workaround but maybe will not be implemented in this version. R&D must determine if this possible or require a lot of code changes.

Best Regards

harrytewkesbury Regular Contributor.
Regular Contributor.

Re: Upgrading a DP9 Client to DP10

I am happy to report that a ssh config file is sufficient to allow this to work. Thank the Gods that HP didn't decide to use a proprietary SSH binary.

All one need do is create a config file in /root/.ssh/config and the following (or variations thereof) will do the trick:

Host *
    User root
    Port 2230
    ForwardAgent yes
    StrictHostKeyChecking no

Well, I have been able to get at least one client to upgrade this way. Remains to be seen if I can replicate it...