ADSM-L

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

2017-10-03 08:31:46
Subject: Re: [ADSM-L] 8.1.2 client and 7.1.7 servers
From: Zoltan Forray <zforray AT VCU DOT EDU>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Tue, 3 Oct 2017 08:29:20 -0400
Thanks for all the feedback. Lots of good information. I did not mention
that all of my servers are 7.1.7.300 (soon to look at 7.1.8.000 just
release).  I have no plans or desires to jump to 8.1.2/3 if it is going to
cause such disruption, especially if I have to run a utility on clients to
install certs.

That being said, with a big PCI project on the horizon, I am probably going
to be forced to turn on SSL/TLS communications between SP servers, as a
minimum.  However, if I install 8.1.2 on the PCI SP server, I won't be able
to perform replication to my target replica server until I upgrade it to
8.1.2/3, which would then disrupt the 5-other SP servers doing replication
 - What a mess!

So, back to IBM's statement of "*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.*"  Since in many cases, this has not been true, what
is the mix of client/server/config that might cause communications to be
disrupted?


On Tue, Oct 3, 2017 at 4:41 AM, Stefan Folkerts <stefan.folkerts AT gmail DOT 
com>
wrote:

> 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/
> >
>



-- 
*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