Zoltan,
I'm pretty sure IBM they just want to cover all all the things that could
go wrong with that statement, as long as a downlevel client node isn't used
with a 8.1.2+ client version there shouldn't be any interruption in the
client activity.
There are also potential issues with tooling and scripting of course such
as TSMmanager that need to be upgraded to the current (as of now) release
otherwise it can't connect once your admin goes strict.
People build really crazy things with clients sharing nodes all over the
place, upgrading a part of that or just having a part of that on 8.1.2
already and then upgrading the server will move that node into strict once
the 8.1.2 client connects again, after that the older clients won't connect.
It's basically impossible for IBM to write out every possible scenario so
they don't. It wasn't clear for me for a while but the ISP Symposium of
last week sorted that out nicely.
On Tue, Oct 3, 2017 at 2:29 PM, Zoltan Forray <zforray AT vcu DOT edu> wrote:
> 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/
>
|
