ADSM-L

Re: [ADSM-L] 8.1.2 client and 7.1.7 servers

2017-10-02 22:42:42
Subject: Re: [ADSM-L] 8.1.2 client and 7.1.7 servers
From: "J. Pohlmann" <jpohlmann AT SHAW DOT CA>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Mon, 2 Oct 2017 19:26:57 -0700
I have tried an 8.1.2 client on an 8.1.1.0 server, and as in your case, it 
worked fine. Then, when I upgraded the server to 8.1.2, the client stopped 
working until I ran dsmcert.exe on my Windows client machine to install the 
certificate. After that, the client worked. I  have not tried this scenario 
with UNIX. If anyone has any experience, please let us know.

I am also concerned as to what needs to be done with "really old" clients. I 
have some installations that are running v5 and v6 clients due to old OS 
levels. Again, if anyone has any experience, I would appreciate knowing.

Best regards,
Joerg Pohlmann

-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of 
Zoltan Forray
Sent: Monday, October 02, 2017 13:21
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L] 8.1.2 client and 7.1.7 servers

I want to revisit this thread.  Unbeknownst to me, many of my co-workers have 
installed 8.1.2.0 (both Windows and Linux systems), totally ignoring
my email that said not to.   However, we have not experienced any
disruptions in communications, in contradiction to IBM's dire warning that said 
not to upgrade clients to 8.1.2.0 before first upgrading the servers to 8.1.2.0 
(now 8.1.3.0).

Can someone from IBM explain the details behind the dire warning and perhaps 
explain what combination of server/client will NOT work if someone installs 
8.1.2.x client?

We aren't running any kind of TLS between our servers, although moving to TLS 
is on the horizon due to a big PCI projects that will totally isolate such 
servers and even require me to stand up a lone, isolated SP server within the 
PCI walled-garden/network.

On Tue, Aug 29, 2017 at 6:08 PM, Remco Post <r.post AT plcs DOT nl> wrote:

> What is totally clear to me is that the entire transition to TLS1.2 
> all the way is potentially messy. We possibly have to remove server 
> definitions in an enterprise setup, communications might (or might 
> not) break, and in any case an extra server restart is required after 
> everything has been upgraded.
>
> What is not clear to me is what will and will not be encrypted by the 
> TLS once it is in place? Will that be everything, all server 2 server 
> and client 2 server comms? And if so, what can we expect the impact on 
> the CPU load to be? Our servers move a substantial amount of data 
> every night ( 50
> - 100 TB each ) how many CPU’s should we be adding?
>
> And then the administrators… really, is there no way to guarantee that 
> an admin can connect to the server using a downlevel client once he 
> has used TLS? At least in my world the server and OC get upgraded by 
> one team, while the client is managed by a different team, each at their 
> discretion.
>
> > On 29 Aug 2017, at 15:24, Mikhail Tolkonyuk <mtolkonyuk AT CINIMEX DOT RU>
> wrote:
> >
> > You must update server certificate to SHA-256 before upgrading 
> > clients
> or disable SSL in dsm.opt on all of them.
> >
> > BAC 8.1.2 remembers server certificate and uses TLS by default, it 
> > will
> work with old 7.1.x SHA-1 (or MD5) certificate until you upgrade 
> server and OC to 8.1.2. During upgrade server generates new SHA-256 
> certificate and clients no more able to connect to "untrusted server" with 
> new certificate.
> > As workaround you can remove dsmcert.idx, dsmcert.kdb, dsmcert.sth 
> > files
> from client folder and reset transport method for node after server 
> update, but it's much easier to solve the issue in advance.
> >
> > Check the default cert with the following command:
> > gsk8capicmd_64 -cert -list -db C:\tsminst1\cert.kdb -stashed
> >
> > For more details watch Tricia's video about TLS 1.2:
> > https://youtu.be/QVPrxjmo_aU
> >
> > And see technote 2004844:
> > https://www-01.ibm.com/support/docview.wss?uid=swg22004844
> >
> >
> > -----Original Message-----
> > From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On 
> > Behalf
> Of Zoltan Forray
> > Sent: Tuesday, August 22, 2017 4:03 PM
> > To: ADSM-L AT VM.MARIST DOT EDU
> > Subject: [ADSM-L] 8.1.2 client and 7.1.7 servers
> >
> > Has anyone tried using the latest 8.1.2 clients with 7.1.7 servers?  
> > I
> haven't had the chance to test such a configuration (since my lone 
> test server is at 8.1.1) and with the dire-warnings in the readme 
> docs, I made sure everyone on my staff knows to NOT install 8.1.2 clients.
> >
> > From the readme/docs:
> >
> > Upgrade your IBM Spectrum Protect™ servers to Version 8.1.2 before 
> > you
> upgrade the backup-archive clients.
> >
> >
> >
> > If you do not upgrade your servers first, communication between 
> > servers
> and clients might be interrupted.
> >
> >
> > --
> > *Zoltan Forray*
> > Spectrum Protect (p.k.a. TSM) Software & Hardware Administrator 
> > Xymon
> Monitor Administrator VMware Administrator Virginia Commonwealth 
> University UCC/Office of Technology Services www.ucc.vcu.edu 
> zforray AT vcu DOT edu -
> 804-828-4807 Don't be a phishing victim - VCU and other reputable 
> organizations will never use email to request that you reply with your 
> password, social security number or confidential personal information. 
> For more details visit http://infosecurity.vcu.edu/phishing.html
>
> --
>
>  Met vriendelijke groeten/Kind Regards,
>
> Remco Post
> r.post AT plcs DOT nl
> +31 6 248 21 622
>



--
*Zoltan Forray*
Spectrum Protect (p.k.a. TSM) Software & Hardware Administrator Xymon Monitor 
Administrator VMware Administrator Virginia Commonwealth University UCC/Office 
of Technology Services www.ucc.vcu.edu zforray AT vcu DOT edu - 804-828-4807 
Don't be a phishing victim - VCU and other reputable organizations will never 
use email to request that you reply with your password, social security number 
or confidential personal information. For more details visit 
http://phishing.vcu.edu/

<Prev in Thread] Current Thread [Next in Thread>

ADSM.ORG Privacy and Data Security by KimLaw, PLLC