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