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=AOblRbTBLmBTudSCNDB6TBPBcPJGmslItiMF916OZpg&e=
>
|
