A 8.1.2.0 server should work with older clients as long as the node is in
transitional mode (q node f=d), when they jump to strict because, for
example, a 8.1.2 (or higher) client version restored something from that
node it jumps to strict and pre 8.1.2 clients will no longer be able to
connect using that nodename.
The same goes for admins.
The moment an admin uses the 8.1.2 (or higher) dsmadmc it jumps to strict
and that specific admin won't be able to connect to the server using a pre
8.1.2 dsmadmc anymore.
As far as I have seen there are no other reasons why older clients would
have issues, just keep them in transitional and don't connect to that
nodename with a 8.1.2 or higher client.
You can also manually set the nodes to strict using update node but that
can't be reversed.
That is what I understand about the situation at this point, it's all
related to TLS strict mode that is used on a per node and per admin basis.
On Tue, Oct 3, 2017 at 4:26 AM, J. Pohlmann <jpohlmann AT shaw DOT ca> wrote:
> 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/
>
|
