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 <[email protected]> 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 <[email protected]> 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:[email protected]] On Behalf Of > > Zoltan Forray > > Sent: Monday, October 02, 2017 13:21 > > To: [email protected] > > 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 <[email protected]> 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 <[email protected]> > > > 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:[email protected]] On > > > > Behalf > > > Of Zoltan Forray > > > > Sent: Tuesday, August 22, 2017 4:03 PM > > > > To: [email protected] > > > > 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 > > > [email protected] - > > > 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 > > > [email protected] > > > +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 [email protected] - > > 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 [email protected] - 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/
