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