Hi Zoltan,
When you upgrade the server, the updated clients will be allowed to
connect the first time (trust on first use) and automatically exchange the
certificates.
Del
----------------------------------------------------
"ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU> wrote on 01/05/2018
10:45:19 AM:
> From: Zoltan Forray <zforray AT VCU DOT EDU>
> To: ADSM-L AT VM.MARIST DOT EDU
> Date: 01/05/2018 10:47 AM
> Subject: Re: Should I upgrade to 7.1.8.x ??? (on the client end only)
> Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
>
> Del,
>
> Glad to here there should be no issue in upgrading the clients to 7.1.8
or
> 8.1.2 before the servers are upgraded.
>
> So, what can I expect when I upgrade the servers to 7.1.8 / 8.1.2/4 as
for
> the certificates? I realize I have to run the utility to convert the
> server cert.kdb file to cert256.arm (eventhough I have never used SSL on
> any of my TSM servers, the file exists and I had this problem on my test
> server when I upgraded it to 8.1.3).
>
> Will the clients that upgraded to >=7.1.8 properly/automatically
exchange
> the required certs once the client realizes it is talking to a server
with
> the right "language" or will that be a manual thing? As most folks, I
plan
> to keep SESSIONSECURITY TRANSITIONAL as long as possible, easing into it
as
> gradually as possible.....
>
> But if upgrading to >=7.1.8 is going to require manual updates to get
the
> certs right, I would rather hold off. Right now it is manageable.....
>
> On Thu, Jan 4, 2018 at 2:54 PM, Del Hoobler <hoobler AT us.ibm DOT com> wrote:
>
> > Hi Zoltan,
> >
> > It's fine to upgrade the clients first... you won't see warnings
because
> > the clients know they are talking to a back-level server and will
speak
> > the right "language". The best practice is to upgrade the servers
first so
> > all the certificates are there and it will make sure the security
issues
> > are addressed, but it is not required.
> >
> > We understand the gap with regards to the web interface. We are
evaluating
> > possible ways forward for that.
> >
> >
> > Del
> >
> > ----------------------------------------------------
> >
> >
> > "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU> wrote on 01/04/2018
> > 09:16:25 AM:
> >
> > > From: Zoltan Forray <zforray AT VCU DOT EDU>
> > > To: ADSM-L AT VM.MARIST DOT EDU
> > > Date: 01/04/2018 09:17 AM
> > > Subject: Re: Should I upgrade to 7.1.8.x ??? (on the client end
only)
> > > Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
> > >
> > > Del,
> > >
> > > Thanks for the info. Some of it is useful and I have seen most of
it.
> > >
> > > I have a question about the reverse i.e. clients who have upgraded
to
> > > 8.1.2+ and 7.1.8. There was this dire warning in the 8.1.2
upgrade
> > docs
> > > about upgrading your servers before installing 8.1.2 clients or your
> > > backups would fail. I downloaded all of the latest clients and
> > eventhough
> > > I sent an email to my co-workers about *NOT* using 8.1.2/7.1.8, some
> > > ignored me and installed 8.1.2 (and then 7.1.8) with no issues I am
> > aware
> > > of (remember all of my servers are RHEL 7.1.7.300).
> > >
> > > At what point do these dire warnings kick-in? Is it safe to deploy
> > 7.1.8 /
> > > 8.1.2 (holding off on 8.1.4) throughout my complex without fears of
> > > mass-destruction?
> > >
> > > Plus the issue of the "BA web interface" going away (if I understand
> > this
> > > correctly) is a major problem for us. Unless of course I am
completely
> > > misunderstanding and it is only the web Administrator interface
(which
> > we
> > > don't use).
> > >
> > > On Thu, Jan 4, 2018 at 7:45 AM, Del Hoobler <hoobler AT us.ibm DOT com>
wrote:
> > >
> > > > Here are a few links that might help:
> > > >
> > > > https://www.ibm.com/support/knowledgecenter/en/SSEQVQ_8.1.
> > > > 2/srv.install/r_srv_knowsec-aix.html
> > > >
> > > > http://www-01.ibm.com/support/docview.wss?uid=swg22004844
> > > >
> > > >
> > > >
> > > > Del
> > > >
> > > > ----------------------------------------------------
> > > >
> > > >
> > > > "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU> wrote on
01/04/2018
> > > > 03:37:53 AM:
> > > >
> > > > > From: "Loon, Eric van (ITOPT3) - KLM" <Eric-van.Loon AT KLM DOT COM>
> > > > > To: ADSM-L AT VM.MARIST DOT EDU
> > > > > Date: 01/04/2018 03:40 AM
> > > > > Subject: Re: Should I upgrade to 7.1.8.x ??? (on the client end
> > only)
> > > > > Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
> > > > >
> > > > > I too read all the previous posts, but I still don't know what
to
> > > > > do. Your mail also indicates that your upgrade planning is based
on
> > > > > several assumptions and I think it is really time for IBM to
jump in
> > > > > here. I think someone from development should explain a little
bit
> > > > > about the new security design and tell us how we should upgrade
> > > > > without impact. Which components in which order to which
recommended
> > > > level.
> > > > > Kind regards,
> > > > > Eric van Loon
> > > > > Air France/KLM Storage Engineering
> > > > >
> > > > > -----Original Message-----
> > > > > From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On
> > > > > Behalf Of Deschner, Roger Douglas
> > > > > Sent: donderdag 4 januari 2018 0:14
> > > > > To: ADSM-L AT VM.MARIST DOT EDU
> > > > > Subject: Re: Should I upgrade to 7.1.8.x ??? (on the client end
> > only)
> > > > >
> > > > > Test! Test! Test! Search this forum for previous posts about
this.
> > > > > There are a bunch of gotchas. Perhaps one of the most severe is
what
> > > > > happens to administrator IDS. Create some dummy admin IDS to use
in
> > > > > testing, because you can permanently disable your own admin ID
if
> > > > > you're not careful. We also know there will be library sharing
> > gotchas.
> > > > >
> > > > > We're actually going to do the backup servers first - after
thorough
> > > > > testing. We think we can minimize the risk to things like admin
IDS
> > > > > if we upgrade the servers with NO clients yet on 7.1.8. I think
that
> > > > > having 7.1.8 clients around will greatly complicate the process
of
> > > > > upgrading the servers, especially if any of those 7.1.8 clients
are
> > > > > the desktop workstations used by you and your coworkers. It's
> > > > > possible that when you do eventually upgrade your servers to
7.1.8,
> > > > > you'll have to backtrack to each client and manually install new
SSL
> > > > > keys, on all client systems, all at once. I hope that
cat-herding
> > > > > nightmare can be avoided by upgrading servers first, which will
then
> > > > > manage key distribution among clients more gracefully, as they
> > > > > upgrade to 7.1.8 one at a time. If I'm wrong about any of this,
> > > > > please chime in.
> > > > >
> > > > > This thing has a big effect. Careful testing is necessary.
> > > > >
> > > > > Roger Deschner
> > > > > University of Illinois at Chicago
> > > > > "I have not lost my mind - it is backed up on tape somewhere."
> > > > > ________________________________________
> > > > > From: Skylar Thompson <skylar2 AT U.WASHINGTON DOT EDU>
> > > > > Sent: Tuesday, January 2, 2018 16:19
> > > > > Subject: Re: Should I upgrade to 7.1.8.x ??? (on the client end
> > only)
> > > > >
> > > > > Content preview: I believe the incompatibility arises if you
set
> > > > > SESSIONSECURITY
> > > > > to STRICT for your nodes. The default is TRANSITIONAL so you
> > > > > should be fine;
> > > > > IIRC the only communication problems we had when upgrading
our
> > > > servers to
> > > > > v7.1.8 was with library sharing. [...]
> > > > >
> > > > > Content analysis details: (0.6 points, 5.0 required)
> > > > >
> > > > > pts rule name description
> > > > > ---- ----------------------
> > > > > --------------------------------------------------
> > > > > 0.7 SPF_NEUTRAL SPF: sender does not match SPF
record
> > > > (neutral)
> > > > > -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches
handover
> > > > relay
> > > > > domain
> > > > > X-Barracuda-Connect: mx.gs.washington.edu[128.208.8.134]
> > > > > X-Barracuda-Start-Time: 1514931575
> > > > > X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384
> > > > > X-Barracuda-URL: https://urldefense.proofpoint.com/v2/url?
> > > > > u=https-3A__148.100.49.
> > > > > 28-3A443_cgi-2Dmod_mark.cgi&d=DwIFAg&c=jf_iaSHvJObTbx-
> > > > >
> > > > siA1ZOg&r=0hq2JX5c3TEZNriHEs7Zf7HrkY2fNtONOrEOM8Txvk8&m=
> > > > 529NKbiDtCmhOp63H3nZmM0Pnv-
> > > > >
V1fHyDWeSXJ-s-1I&s=wL7qg-bC6229Rs0MHKXxo50WnAcsl_tyXg8N0DW_oQA&e=
> > > > > X-Virus-Scanned: by bsmtpd at marist.edu
> > > > > X-Barracuda-Scan-Msg-Size: 3241
> > > > > X-Barracuda-BRTS-Status: 1
> > > > > X-Barracuda-Spam-Score: 0.00
> > > > > X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of
> > > > > TAG_LEVEL=3.5 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=5.5 tests=
> > > > > X-Barracuda-Spam-Report: Code version 3.2, rules version
3.2.3.46484
> > > > > Rule breakdown below
> > > > > pts rule name description
> > > > > ---- ----------------------
> > > > > --------------------------------------------------
> > > > >
> > > > > I believe the incompatibility arises if you set SESSIONSECURITY
to
> > > > > STRICT for your nodes. The default is TRANSITIONAL so you should
be
> > > > > fine; IIRC the only communication problems we had when upgrading
our
> > > > > servers to v7.1.8 was with library sharing.
> > > > >
> > > > > That said, v7.1.8 was a huge change so I would test it if
possible
> > > > first.
> > > > >
> > > > > On Tue, Jan 02, 2018 at 05:12:44PM -0500, Tom Alverson wrote:
> > > > > > Thanks for that link, I am more worried about any "gotcha's"
> > caused by
> > > >
> > > > > > upgrading the client to 7.1.8 or 8.1.2 before the storage
servers
> > get
> > > > > > upgraded (and start using the new authentication). What I
had
> > not
> > > > > > realized until I saw the chart is that the new clients are NOT
> > > > > > backward compatible with old storage servers (which doesn't
really
> > > > > > affect me since we have those all at 7.1.7.2 now).
> > > > > >
> > > > > >
> > > > > > *IBM SPECTRUM PROTECT CLIENT SUPPORT*
> > > > > >
> > > > > > includes the Backup-Archive, API, UNIX HSM, and Web clients
that
> > are
> > > > > > compatible with, and currently supported with, IBM Spectrum
> > Protect
> > > > > > Servers and Storage Agents.
> > > > > > *IBM Spectrum Protect*
> > > > > > *Client Version*
> > > > > > *Supported IBM Spectrum Protect*
> > > > > > *Server and Storage Agent Versions*
> > > > > > 8.1.2
> > > > > > 8.1, 7.1
> > > > > > 8.1.0
> > > > > > 8.1, 7.1, 6.3.x 1
> > > > > > 7.1.8
> > > > > > 8.1, 7.1
> > > > > > 7.1
> > > > > > 8.1, 7.1, 6.3.x 1
> > > > > > 6.4 1
> > > > > > 8.1, 7.1, 6.3.x 1
> > > > > > 6.3 1, 2
> > > > > > 8.1, 7.1, 6.3.x 1
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Tue, Jan 2, 2018 at 4:42 PM, Skylar Thompson
> > > > > > <skylar2 AT u.washington DOT edu>
> > > > > > wrote:
> > > > > >
> > > > > > > There's pretty wide version compatibility between clients
and
> > > > > > > servers; we didn't go v7 server-side until pretty recently
but
> > have
> > > > > > > been running the v7 client for a while. IBM has a matrix
> > published
> > > > here:
> > > > > > >
> > > > > > > http://www-01.ibm.com/support/docview.wss?uid=swg21053218
> > > > > > >
> > > > > > > For basic backups and restores I think you can deviate even
> > more,
> > > > > > > but obviously you won't get support.
> > > > > > >
> > > > > > > On Tue, Jan 02, 2018 at 03:14:24PM -0500, Tom Alverson
wrote:
> > > > > > > > Our TSM storage servers were all upgraded last year to
7.1.7.2
> > > > > > > > (before
> > > > > > > this
> > > > > > > > new security update came out). Now I am wondering if I
> > should
> > > > start
> > > > > > > using
> > > > > > > > the updated client or not? If the servers stay at
7.1.7.2
> > for
> > > > now is
> > > > > > > > there any harm in using the newer client? I would have to
use
> > > > > > > > 7.1.8.0 on anything older than 2012. I saw some email
traffic
> > > > > > > > earlier that once you use the new authentication mode on a
> > node
> > > > > > > > you can't go back? But it
> > > > > > > seems
> > > > > > > > that would not be possible until our storage servers get
> > upgraded.
> > > > > > > >
> > > > > > > > Is there any downside in my case (where the storage
servers
> > are
> > > > > > > > still at
> > > > > > > > 7.1.7.2) of using the latest client versions in the
interim??
> > Our
> > > > > > > current
> > > > > > > > standard client versions now are 7.1.6.4 for 2008 and
older,
> > and
> > > > > > > > 8.1.0.0 (yes the horrible buggy one) on newer servers.
> > > > > > > >
> > > > > > > > Tom
> > > > > > >
> > > > > > > --
> > > > > > > -- Skylar Thompson (skylar2 AT u.washington DOT edu)
> > > > > > > -- Genome Sciences Department, System Administrator
> > > > > > > -- Foege Building S046, (206)-685-7354
> > > > > > > -- University of Washington School of Medicine
> > > > > > >
> > > > >
> > > > > --
> > > > > -- Skylar Thompson (skylar2 AT u.washington DOT edu)
> > > > > -- Genome Sciences Department, System Administrator
> > > > > -- Foege Building S046, (206)-685-7354
> > > > > -- University of Washington School of Medicine
> > > > > ********************************************************
> > > > > For information, services and offers, please visit our web site:
> > > > > https://urldefense.proofpoint.com/v2/url?
> > > > > u=http-3A__www.klm.com&d=DwIFAg&c=jf_iaSHvJObTbx-
> > > > >
> > > > siA1ZOg&r=0hq2JX5c3TEZNriHEs7Zf7HrkY2fNtONOrEOM8Txvk8&m=
> > > > 529NKbiDtCmhOp63H3nZmM0Pnv-
> > > > >
V1fHyDWeSXJ-s-1I&s=XYtqCkcBf_H0a_PotsgLeuvoQb1r1IZarPTXr5rPT6s&e=.
> > > > > This e-mail and any attachment may contain confidential and
> > > > > privileged material intended for the addressee only. If you are
not
> > > > > the addressee, you are notified that no part of the e-mail or
any
> > > > > attachment may be disclosed, copied or distributed, and that any
> > > > > other action related to this e-mail or attachment is strictly
> > > > > prohibited, and may be unlawful. If you have received this
e-mail by
> > > > > error, please notify the sender immediately by return e-mail,
and
> > > > > delete this message.
> > > > >
> > > > > Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries
and/
> > > > > or its employees shall not be liable for the incorrect or
incomplete
> > > > > transmission of this e-mail or any attachments, nor responsible
for
> > > > > any delay in receipt.
> > > > > Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM
Royal
> > > > > Dutch Airlines) is registered in Amstelveen, The Netherlands,
with
> > > > > registered number 33014286
> > > > > ********************************************************
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > > *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 https://urldefense.proofpoint.com/v2/url?
> > > u=http-3A__phishing.vcu.edu_&d=DwIBaQ&c=jf_iaSHvJObTbx-
> > >
> > siA1ZOg&r=0hq2JX5c3TEZNriHEs7Zf7HrkY2fNtONOrEOM8Txvk8&m=Oi_0es_
> > MvTRexX_Xc5JcXtZc2zewiI_HBJ_3Kz5k4Qw&s=AOblRbTBLmBTudSCNDB6TBPBcPJGms
> > lItiMF916OZpg&e=
> > >
> >
>
>
>
> --
> *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 https://urldefense.proofpoint.com/v2/url?
> u=http-3A__phishing.vcu.edu_&d=DwIBaQ&c=jf_iaSHvJObTbx-
>
siA1ZOg&r=0hq2JX5c3TEZNriHEs7Zf7HrkY2fNtONOrEOM8Txvk8&m=aMix5X6trKFEW3KtuLsdZgap05ThAy1F7nxImRiBVbg&s=1F0herjCW4Okr2iURg7vrQEpqGSguI_hGscX2IVm47g&e=
>
|
