I agree with you about the lack of completely clear information.
I have a test server that I upgraded to 8.1.3 and with the default
SESSIONSECURITY
value we had mixed and inconsistent results with the few clients I tested.
We also had to go through the key conversion process even though (IIRC)
docs said we shouldn't have to since we never used encryption or SSL on any
server (except for the lone LM server that creates off-site tapes which are
encrypted).
And the whole issue of the web interface going away is really confusing and
will cause us issues since we have processes that require the web interface
to access node backups (no way around it). We haven't had a chance to test
what will happen in that scenario due to lack of people time and too many
active projects.
Zoltan Forray
Spectrum Protect (p.k.a. TSM) Software & Hardware Administrator
VMware Administrator
Xymon Administrator
VCU Computer Center
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://phishing.vcu.edu
On Jan 4, 2018 3:39 AM, "Loon, Eric van (ITOPT3) - KLM" <
Eric-van.Loon AT klm DOT com> wrote:
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://148.100.49.28:443/cgi-mod/mark.cgi
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:
http://www.klm.com. 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
********************************************************
|
