Welcome! » Log In » Create A New Profile

Should I upgrade to 7.1.8.x ??? (on the client end only)

Posted by Tom Alverson 
Tom Alverson
Should I upgrade to 7.1.8.x ??? (on the client end only)
January 02, 2018 12:59PM
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
This message was imported via the External PhorumMail Module
Skylar Thompson
Re: Should I upgrade to 7.1.8.x ??? (on the client end only)
January 02, 2018 01:59PM
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@u.washington.edu)
-- Genome Sciences Department, System Administrator
-- Foege Building S046, (206)-685-7354
-- University of Washington School of Medicine
This message was imported via the External PhorumMail Module
Tom Alverson
Re: Should I upgrade to 7.1.8.x ??? (on the client end only)
January 02, 2018 02:59PM
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@u.washington.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@u.washington.edu)
> -- Genome Sciences Department, System Administrator
> -- Foege Building S046, (206)-685-7354
> -- University of Washington School of Medicine
>
This message was imported via the External PhorumMail Module
Skylar Thompson
Re: Should I upgrade to 7.1.8.x ??? (on the client end only)
January 02, 2018 02:59PM
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@u.washington.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@u.washington.edu)
> > -- Genome Sciences Department, System Administrator
> > -- Foege Building S046, (206)-685-7354
> > -- University of Washington School of Medicine
> >

--
-- Skylar Thompson (skylar2@u.washington.edu)
-- Genome Sciences Department, System Administrator
-- Foege Building S046, (206)-685-7354
-- University of Washington School of Medicine
This message was imported via the External PhorumMail Module
Zoltan Forray
Re: Should I upgrade to 7.1.8.x ??? (on the client end only)
January 03, 2018 11:59AM
I too am looking to upgrade all of my servers from 7.1.7.300, soon. I went
through the documents in your link (IBM - one of them 404's). My first
concern would be upgrading the offsite replica server. While there is
documentation about library manager/client server levels/compatibility
(pretty sure need to do LM servers first), does the new forced security
require SSL/TLS for server-to-server communications? If I upgrade/update
the replica server to 7.1.8, will that kill it's communication with the
5-other 7.1.7.3 servers that aren't talking SSL/TLS?

On Tue, Jan 2, 2018 at 4:42 PM, Skylar Thompson <skylar2@u.washington.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@u.washington.edu)
> -- Genome Sciences Department, System Administrator
> -- Foege Building S046, (206)-685-7354
> -- University of Washington School of Medicine
>



--
*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@vcu.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/
This message was imported via the External PhorumMail Module
Deschner, Roger Douglas
Re: Should I upgrade to 7.1.8.x ??? (on the client end only)
January 03, 2018 03:59PM
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@U.WASHINGTON.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@u.washington.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@u.washington.edu)
> > -- Genome Sciences Department, System Administrator
> > -- Foege Building S046, (206)-685-7354
> > -- University of Washington School of Medicine
> >

--
-- Skylar Thompson (skylar2@u.washington.edu)
-- Genome Sciences Department, System Administrator
-- Foege Building S046, (206)-685-7354
-- University of Washington School of Medicine
This message was imported via the External PhorumMail Module
Loon, Eric van (ITOPT3) - KLM
Re: Should I upgrade to 7.1.8.x ??? (on the client end only)
January 04, 2018 12:59AM
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@VM.MARIST.EDU] On Behalf Of Deschner, Roger Douglas
Sent: donderdag 4 januari 2018 0:14
To: ADSM-L@VM.MARIST.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@U.WASHINGTON.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@u.washington.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@u.washington.edu)
> > -- Genome Sciences Department, System Administrator
> > -- Foege Building S046, (206)-685-7354
> > -- University of Washington School of Medicine
> >

--
-- Skylar Thompson (skylar2@u.washington.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
********************************************************
This message was imported via the External PhorumMail Module
Zoltan Forray
Re: Should I upgrade to 7.1.8.x ??? (on the client end only)
January 04, 2018 04:59AM
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@vcu.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@klm.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@VM.MARIST.EDU] On Behalf Of
Deschner, Roger Douglas
Sent: donderdag 4 januari 2018 0:14
To: ADSM-L@VM.MARIST.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@U.WASHINGTON.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@u.washington.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@u.washington.edu)
> > -- Genome Sciences Department, System Administrator
> > -- Foege Building S046, (206)-685-7354
> > -- University of Washington School of Medicine
> >

--
-- Skylar Thompson (skylar2@u.washington.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
********************************************************
This message was imported via the External PhorumMail Module
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@VM.MARIST.EDU> wrote on 01/04/2018
03:37:53 AM:

> From: "Loon, Eric van (ITOPT3) - KLM" <Eric-van.Loon@KLM.COM>
> To: ADSM-L@VM.MARIST.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@VM.MARIST.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@VM.MARIST.EDU] On
> Behalf Of Deschner, Roger Douglas
> Sent: donderdag 4 januari 2018 0:14
> To: ADSM-L@VM.MARIST.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@U.WASHINGTON.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@u.washington.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@u.washington.edu)
> > > -- Genome Sciences Department, System Administrator
> > > -- Foege Building S046, (206)-685-7354
> > > -- University of Washington School of Medicine
> > >
>
> --
> -- Skylar Thompson (skylar2@u.washington.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
> ********************************************************
>
This message was imported via the External PhorumMail Module
Loon, Eric van (ITOPT3) - KLM
Re: Should I upgrade to 7.1.8.x ??? (on the client end only)
January 04, 2018 05:59AM
Hi Del,
Well, not really... I'm currently installing a 7.1.8 server and noticed that I could no longer use a 7.1.7 admin commandline:

ANR0404W Session 22 for administrator ADMIN (Linux x86-64) refused - client is down-level with this server version.

So I upgraded it to 7.1.8, but it was still not working:

On the client side: ANS1592E Failed to initialize SSL protocol.
On the server side: ANR3335W Unable to distribute certificate to KLM35757 for session 24.

So I updated my admin to sessionsecurity=transitional (strange, this should be the default...) and now I could start a session successful. I tried the same admin account on another TSM client and again On the client side: ANS1592E Failed to initialize SSL protocol. A q admin f=d showed that sessionsecurity was again set to strict! I'm lost...
Kind regards,
Eric van Loon
Air France/KLM Storage Engineering


-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Del Hoobler
Sent: donderdag 4 januari 2018 13:45
To: ADSM-L@VM.MARIST.EDU
Subject: Re: Should I upgrade to 7.1.8.x ??? (on the client end only)

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@VM.MARIST.EDU> wrote on 01/04/2018
03:37:53 AM:

> From: "Loon, Eric van (ITOPT3) - KLM" <Eric-van.Loon@KLM.COM>
> To: ADSM-L@VM.MARIST.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@VM.MARIST.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@VM.MARIST.EDU] On Behalf
> Of Deschner, Roger Douglas
> Sent: donderdag 4 januari 2018 0:14
> To: ADSM-L@VM.MARIST.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@U.WASHINGTON.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@u.washington.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@u.washington.edu)
> > > -- Genome Sciences Department, System Administrator
> > > -- Foege Building S046, (206)-685-7354
> > > -- University of Washington School of Medicine
> > >
>
> --
> -- Skylar Thompson (skylar2@u.washington.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
> ********************************************************
>
********************************************************
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
********************************************************
This message was imported via the External PhorumMail Module
Zoltan Forray
Re: Should I upgrade to 7.1.8.x ??? (on the client end only)
January 04, 2018 06:59AM
>>>admin to sessionsecurity=transitional (strange, this should be the
default...) and now I could start a session successful.

I concur. I remember having this same problem when I upgraded my test
server to 8.1.3 eventhough the docs say "transitional" is the default.

On Thu, Jan 4, 2018 at 8:42 AM, Loon, Eric van (ITOPT3) - KLM <
Eric-van.Loon@klm.com> wrote:

> Hi Del,
> Well, not really... I'm currently installing a 7.1.8 server and noticed
> that I could no longer use a 7.1.7 admin commandline:
>
> ANR0404W Session 22 for administrator ADMIN (Linux x86-64) refused -
> client is down-level with this server version.
>
> So I upgraded it to 7.1.8, but it was still not working:
>
> On the client side: ANS1592E Failed to initialize SSL protocol.
> On the server side: ANR3335W Unable to distribute certificate to KLM35757
> for session 24.
>
> So I updated my admin to sessionsecurity=transitional (strange, this
> should be the default...) and now I could start a session successful. I
> tried the same admin account on another TSM client and again On the client
> side: ANS1592E Failed to initialize SSL protocol. A q admin f=d showed that
> sessionsecurity was again set to strict! I'm lost...
> Kind regards,
> Eric van Loon
> Air France/KLM Storage Engineering
>
>
> -----Original Message-----
> From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of
> Del Hoobler
> Sent: donderdag 4 januari 2018 13:45
> To: ADSM-L@VM.MARIST.EDU
> Subject: Re: Should I upgrade to 7.1.8.x ??? (on the client end only)
>
> 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@VM.MARIST.EDU> wrote on 01/04/2018
> 03:37:53 AM:
>
> > From: "Loon, Eric van (ITOPT3) - KLM" <Eric-van.Loon@KLM.COM>
> > To: ADSM-L@VM.MARIST.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@VM.MARIST.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@VM.MARIST.EDU] On Behalf
> > Of Deschner, Roger Douglas
> > Sent: donderdag 4 januari 2018 0:14
> > To: ADSM-L@VM.MARIST.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@U.WASHINGTON.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@u.washington.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@u.washington.edu)
> > > > -- Genome Sciences Department, System Administrator
> > > > -- Foege Building S046, (206)-685-7354
> > > > -- University of Washington School of Medicine
> > > >
> >
> > --
> > -- Skylar Thompson (skylar2@u.washington.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
> > ********************************************************
> >
> ********************************************************
> 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
> ********************************************************
>



--
*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@vcu.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/
This message was imported via the External PhorumMail Module
Zoltan Forray
Re: Should I upgrade to 7.1.8.x ??? (on the client end only)
January 04, 2018 06:59AM
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@us.ibm.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@VM.MARIST.EDU> wrote on 01/04/2018
> 03:37:53 AM:
>
> > From: "Loon, Eric van (ITOPT3) - KLM" <Eric-van.Loon@KLM.COM>
> > To: ADSM-L@VM.MARIST.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@VM.MARIST.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@VM.MARIST.EDU] On
> > Behalf Of Deschner, Roger Douglas
> > Sent: donderdag 4 januari 2018 0:14
> > To: ADSM-L@VM.MARIST.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@U.WASHINGTON.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@u.washington.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@u.washington.edu)
> > > > -- Genome Sciences Department, System Administrator
> > > > -- Foege Building S046, (206)-685-7354
> > > > -- University of Washington School of Medicine
> > > >
> >
> > --
> > -- Skylar Thompson (skylar2@u.washington.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@vcu.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/
This message was imported via the External PhorumMail Module
Skylar Thompson
Re: Should I upgrade to 7.1.8.x ??? (on the client end only)
January 04, 2018 06:59AM
Content preview: Yeah, now that you mention it, we ran into this as well. It
wasn't so serious for us since we already had one of our admin systems upgraded
to 7.1.8, but it was kind of surprising for the folks that still used the
down-level client. Fortunately there were no dependencies that prevented
us from going to the 7.1.8 client everywhere. [...]

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: 1515075698
X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384
X-Barracuda-URL: https://148.100.49.27:443/cgi-mod/mark.cgi
X-Virus-Scanned: by bsmtpd at marist.edu
X-Barracuda-Scan-Msg-Size: 13112
X-Barracuda-BRTS-Status: 1
X-Barracuda-Spam-Score: 0.50
X-Barracuda-Spam-Status: No, SCORE=0.50 using global scores of TAG_LEVEL=3.5 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=5.5 tests=BSF_RULE7568M
X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.46540
Rule breakdown below
pts rule name description
---- ---------------------- --------------------------------------------------
0.50 BSF_RULE7568M Custom Rule 7568M

Yeah, now that you mention it, we ran into this as well. It wasn't so
serious for us since we already had one of our admin systems upgraded to
7.1.8, but it was kind of surprising for the folks that still used the
down-level client. Fortunately there were no dependencies that prevented us
from going to the 7.1.8 client everywhere.

It seems that the BA client was more tolerant of the SSL changes than the
admin client, though; I don't remember any client backup problems after the
server upgrade.

On Thu, Jan 04, 2018 at 01:42:50PM +0000, Loon, Eric van (ITOPT3) - KLM wrote:
> Hi Del,
> Well, not really... I'm currently installing a 7.1.8 server and noticed that I could no longer use a 7.1.7 admin commandline:
>
> ANR0404W Session 22 for administrator ADMIN (Linux x86-64) refused - client is down-level with this server version.
>
> So I upgraded it to 7.1.8, but it was still not working:
>
> On the client side: ANS1592E Failed to initialize SSL protocol.
> On the server side: ANR3335W Unable to distribute certificate to KLM35757 for session 24.
>
> So I updated my admin to sessionsecurity=transitional (strange, this should be the default...) and now I could start a session successful. I tried the same admin account on another TSM client and again On the client side: ANS1592E Failed to initialize SSL protocol. A q admin f=d showed that sessionsecurity was again set to strict! I'm lost...
> Kind regards,
> Eric van Loon
> Air France/KLM Storage Engineering
>
>
> -----Original Message-----
> From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Del Hoobler
> Sent: donderdag 4 januari 2018 13:45
> To: ADSM-L@VM.MARIST.EDU
> Subject: Re: Should I upgrade to 7.1.8.x ??? (on the client end only)
>
> 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@VM.MARIST.EDU> wrote on 01/04/2018
> 03:37:53 AM:
>
> > From: "Loon, Eric van (ITOPT3) - KLM" <Eric-van.Loon@KLM.COM>
> > To: ADSM-L@VM.MARIST.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@VM.MARIST.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@VM.MARIST.EDU] On Behalf
> > Of Deschner, Roger Douglas
> > Sent: donderdag 4 januari 2018 0:14
> > To: ADSM-L@VM.MARIST.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@U.WASHINGTON.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@u.washington.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@u.washington.edu)
> > > > -- Genome Sciences Department, System Administrator
> > > > -- Foege Building S046, (206)-685-7354
> > > > -- University of Washington School of Medicine
> > > >
> >
> > --
> > -- Skylar Thompson (skylar2@u.washington.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
> > ********************************************************
> >
> ********************************************************
> 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
> ********************************************************

--
-- Skylar Thompson (skylar2@u.washington.edu)
-- Genome Sciences Department, System Administrator
-- Foege Building S046, (206)-685-7354
-- University of Washington School of Medicine
This message was imported via the External PhorumMail Module
Hi Eric,

Once you connect with a "trusted" client and the certificate is
distributed, the mode is set to back to STRICT. The idea is that
userid/adminid now has the certificate, it must supply it when you
reconnect to verify you are who you say you are.

You could reset the admin back to TRANSITIONAL and do the same thing for
the second machine.


Del

----------------------------------------------------

"ADSM: Dist Stor Manager" <ADSM-L@VM.MARIST.EDU> wrote on 01/04/2018
08:42:50 AM:

> From: "Loon, Eric van (ITOPT3) - KLM" <Eric-van.Loon@KLM.COM>
> To: ADSM-L@VM.MARIST.EDU
> Date: 01/04/2018 08:46 AM
> Subject: Re: Should I upgrade to 7.1.8.x ??? (on the client end only)
> Sent by: "ADSM: Dist Stor Manager" <ADSM-L@VM.MARIST.EDU>
>
> Hi Del,
> Well, not really... I'm currently installing a 7.1.8 server and
> noticed that I could no longer use a 7.1.7 admin commandline:
>
> ANR0404W Session 22 for administrator ADMIN (Linux x86-64) refused -
> client is down-level with this server version.
>
> So I upgraded it to 7.1.8, but it was still not working:
>
> On the client side: ANS1592E Failed to initialize SSL protocol.
> On the server side: ANR3335W Unable to distribute certificate to
> KLM35757 for session 24.
>
> So I updated my admin to sessionsecurity=transitional (strange, this
> should be the default...) and now I could start a session
> successful. I tried the same admin account on another TSM client and
> again On the client side: ANS1592E Failed to initialize SSL
> protocol. A q admin f=d showed that sessionsecurity was again set to
> strict! I'm lost...
> Kind regards,
> Eric van Loon
> Air France/KLM Storage Engineering
>
>
> -----Original Message-----
> From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On
> Behalf Of Del Hoobler
> Sent: donderdag 4 januari 2018 13:45
> To: ADSM-L@VM.MARIST.EDU
> Subject: Re: Should I upgrade to 7.1.8.x ??? (on the client end only)
>
> 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@VM.MARIST.EDU> wrote on 01/04/2018
> 03:37:53 AM:
>
> > From: "Loon, Eric van (ITOPT3) - KLM" <Eric-van.Loon@KLM.COM>
> > To: ADSM-L@VM.MARIST.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@VM.MARIST.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@VM.MARIST.EDU] On Behalf
> > Of Deschner, Roger Douglas
> > Sent: donderdag 4 januari 2018 0:14
> > To: ADSM-L@VM.MARIST.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@U.WASHINGTON.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@u.washington.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@u.washington.edu)
> > > > -- Genome Sciences Department, System Administrator
> > > > -- Foege Building S046, (206)-685-7354
> > > > -- University of Washington School of Medicine
> > > >
> >
> > --
> > -- Skylar Thompson (skylar2@u.washington.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
> > ********************************************************
> >
> ********************************************************
> 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=pc1RpqM0VdilqdI8f8wSgnq-
> BKzWTnhzFQcUMsuS12U&s=7QaTvQoGfzsKQB1cEuQQJbsoahWvUjUSoHN7VuR0FTs&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
> ********************************************************
>
This message was imported via the External PhorumMail Module
Loon, Eric van (ITOPT3) - KLM
Re: Should I upgrade to 7.1.8.x ??? (on the client end only)
January 04, 2018 06:59AM
In fact a q server f=d shows Session Security: Transitional, but each time I log on to the server using the admin command line, my admin userid is getting updated from transitional to strict! Upd admin transitional works but as soon as I log on it's being switched back to Strict.
Kind regards,
Eric van Loon
Air France/KLM Storage Engineering


-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Zoltan Forray
Sent: donderdag 4 januari 2018 15:03
To: ADSM-L@VM.MARIST.EDU
Subject: Re: Should I upgrade to 7.1.8.x ??? (on the client end only)

>>>admin to sessionsecurity=transitional (strange, this should be the
default...) and now I could start a session successful.

I concur. I remember having this same problem when I upgraded my test server to 8.1.3 eventhough the docs say "transitional" is the default.

On Thu, Jan 4, 2018 at 8:42 AM, Loon, Eric van (ITOPT3) - KLM < Eric-van.Loon@klm.com> wrote:

> Hi Del,
> Well, not really... I'm currently installing a 7.1.8 server and
> noticed that I could no longer use a 7.1.7 admin commandline:
>
> ANR0404W Session 22 for administrator ADMIN (Linux x86-64) refused -
> client is down-level with this server version.
>
> So I upgraded it to 7.1.8, but it was still not working:
>
> On the client side: ANS1592E Failed to initialize SSL protocol.
> On the server side: ANR3335W Unable to distribute certificate to
> KLM35757 for session 24.
>
> So I updated my admin to sessionsecurity=transitional (strange, this
> should be the default...) and now I could start a session successful.
> I tried the same admin account on another TSM client and again On the
> client
> side: ANS1592E Failed to initialize SSL protocol. A q admin f=d showed
> that sessionsecurity was again set to strict! I'm lost...
> Kind regards,
> Eric van Loon
> Air France/KLM Storage Engineering
>
>
> -----Original Message-----
> From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf
> Of Del Hoobler
> Sent: donderdag 4 januari 2018 13:45
> To: ADSM-L@VM.MARIST.EDU
> Subject: Re: Should I upgrade to 7.1.8.x ??? (on the client end only)
>
> 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@VM.MARIST.EDU> wrote on 01/04/2018
> 03:37:53 AM:
>
> > From: "Loon, Eric van (ITOPT3) - KLM" <Eric-van.Loon@KLM.COM>
> > To: ADSM-L@VM.MARIST.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@VM.MARIST.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@VM.MARIST.EDU] On
> > Behalf Of Deschner, Roger Douglas
> > Sent: donderdag 4 januari 2018 0:14
> > To: ADSM-L@VM.MARIST.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@U.WASHINGTON.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@u.washington.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@u.washington.edu)
> > > > -- Genome Sciences Department, System Administrator
> > > > -- Foege Building S046, (206)-685-7354
> > > > -- University of Washington School of Medicine
> > > >
> >
> > --
> > -- Skylar Thompson (skylar2@u.washington.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
> > ********************************************************
> >
> ********************************************************
> 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
> ********************************************************
>



--
*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@vcu.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/
********************************************************
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
********************************************************
This message was imported via the External PhorumMail Module
HI Eric,

This is intentional. See my previous reply.


Del

----------------------------------------------------


"ADSM: Dist Stor Manager" <ADSM-L@VM.MARIST.EDU> wrote on 01/04/2018
09:44:42 AM:

> From: "Loon, Eric van (ITOPT3) - KLM" <Eric-van.Loon@KLM.COM>
> To: ADSM-L@VM.MARIST.EDU
> Date: 01/04/2018 09:46 AM
> Subject: Re: Should I upgrade to 7.1.8.x ??? (on the client end only)
> Sent by: "ADSM: Dist Stor Manager" <ADSM-L@VM.MARIST.EDU>
>
> In fact a q server f=d shows Session Security: Transitional, but
> each time I log on to the server using the admin command line, my
> admin userid is getting updated from transitional to strict! Upd
> admin transitional works but as soon as I log on it's being switched
> back to Strict.
>
> Kind regards,
>
> Eric van Loon
>
> Air France/KLM Storage Engineering
>
>
>
>
>
> -----Original Message-----
>
> From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On
> Behalf Of Zoltan Forray
>
> Sent: donderdag 4 januari 2018 15:03
>
> To: ADSM-L@VM.MARIST.EDU
>
> Subject: Re: Should I upgrade to 7.1.8.x ??? (on the client end only)
>
>
>
> >>>admin to sessionsecurity=transitional (strange, this should be the
>
> default...) and now I could start a session successful.
>
>
>
> I concur. I remember having this same problem when I upgraded my
> test server to 8.1.3 eventhough the docs say "transitional" is the
default.
>
>
>
> On Thu, Jan 4, 2018 at 8:42 AM, Loon, Eric van (ITOPT3) - KLM <
> Eric-van.Loon@klm.com> wrote:
>
>
>
> > Hi Del,
>
> > Well, not really... I'm currently installing a 7.1.8 server and
>
> > noticed that I could no longer use a 7.1.7 admin commandline:
>
> >
>
> > ANR0404W Session 22 for administrator ADMIN (Linux x86-64) refused -
>
> > client is down-level with this server version.
>
> >
>
> > So I upgraded it to 7.1.8, but it was still not working:
>
> >
>
> > On the client side: ANS1592E Failed to initialize SSL protocol.
>
> > On the server side: ANR3335W Unable to distribute certificate to
>
> > KLM35757 for session 24.
>
> >
>
> > So I updated my admin to sessionsecurity=transitional (strange, this
>
> > should be the default...) and now I could start a session successful.
>
> > I tried the same admin account on another TSM client and again On the
>
> > client
>
> > side: ANS1592E Failed to initialize SSL protocol. A q admin f=d showed

>
> > that sessionsecurity was again set to strict! I'm lost...
>
> > Kind regards,
>
> > Eric van Loon
>
> > Air France/KLM Storage Engineering
>
> >
>
> >
>
> > -----Original Message-----
>
> > From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf
>
> > Of Del Hoobler
>
> > Sent: donderdag 4 januari 2018 13:45
>
> > To: ADSM-L@VM.MARIST.EDU
>
> > Subject: Re: Should I upgrade to 7.1.8.x ??? (on the client end only)
>
> >
>
> > 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@VM.MARIST.EDU> wrote on 01/04/2018
>
> > 03:37:53 AM:
>
> >
>
> > > From: "Loon, Eric van (ITOPT3) - KLM" <Eric-van.Loon@KLM.COM>
>
> > > To: ADSM-L@VM.MARIST.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@VM.MARIST.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@VM.MARIST.EDU] On
>
> > > Behalf Of Deschner, Roger Douglas
>
> > > Sent: donderdag 4 januari 2018 0:14
>
> > > To: ADSM-L@VM.MARIST.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@U.WASHINGTON.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@u.washington.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@u.washington.edu)
>
> > > > > -- Genome Sciences Department, System Administrator
>
> > > > > -- Foege Building S046, (206)-685-7354
>
> > > > > -- University of Washington School of Medicine
>
> > > > >
>
> > >
>
> > > --
>
> > > -- Skylar Thompson (skylar2@u.washington.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
>
> > > ********************************************************
>
> > >
>
> > ********************************************************
>
> > For information, services and offers, please visit our web site:
>
> > https://urldefense.proofpoint.com/v2/url?
> u=http-3A__www.klm.com&d=DwIGaQ&c=jf_iaSHvJObTbx-
>
siA1ZOg&r=0hq2JX5c3TEZNriHEs7Zf7HrkY2fNtONOrEOM8Txvk8&m=8XN09ZoIl16Qv_q1NGIiVtRTgXB00ElZ5HZbmdaZiKM&s=dC8dKPm_8e0OnHDhUDMhvXVt_7cGrc4MJjBP5j2kH8c&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@vcu.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=DwIGaQ&c=jf_iaSHvJObTbx-
>
siA1ZOg&r=0hq2JX5c3TEZNriHEs7Zf7HrkY2fNtONOrEOM8Txvk8&m=8XN09ZoIl16Qv_q1NGIiVtRTgXB00ElZ5HZbmdaZiKM&s=7aBr99tHGlPgXLESFJlw0baocFrUV6ZhcvLwF27qsCY&e=
>
> ********************************************************
>
> For information, services and offers, please visit our web site:
> https://urldefense.proofpoint.com/v2/url?
> u=http-3A__www.klm.com&d=DwIGaQ&c=jf_iaSHvJObTbx-
>
siA1ZOg&r=0hq2JX5c3TEZNriHEs7Zf7HrkY2fNtONOrEOM8Txvk8&m=8XN09ZoIl16Qv_q1NGIiVtRTgXB00ElZ5HZbmdaZiKM&s=dC8dKPm_8e0OnHDhUDMhvXVt_7cGrc4MJjBP5j2kH8c&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
>
> ********************************************************
>
This message was imported via the External PhorumMail Module
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@VM.MARIST.EDU> wrote on 01/04/2018
09:16:25 AM:

> From: Zoltan Forray <zforray@VCU.EDU>
> To: ADSM-L@VM.MARIST.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@VM.MARIST.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@us.ibm.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@VM.MARIST.EDU> wrote on 01/04/2018
> > 03:37:53 AM:
> >
> > > From: "Loon, Eric van (ITOPT3) - KLM" <Eric-van.Loon@KLM.COM>
> > > To: ADSM-L@VM.MARIST.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@VM.MARIST.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@VM.MARIST.EDU] On
> > > Behalf Of Deschner, Roger Douglas
> > > Sent: donderdag 4 januari 2018 0:14
> > > To: ADSM-L@VM.MARIST.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@U.WASHINGTON.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@u.washington.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@u.washington.edu)
> > > > > -- Genome Sciences Department, System Administrator
> > > > > -- Foege Building S046, (206)-685-7354
> > > > > -- University of Washington School of Medicine
> > > > >
> > >
> > > --
> > > -- Skylar Thompson (skylar2@u.washington.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@vcu.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=
>
This message was imported via the External PhorumMail Module
Zoltan Forray
Re: Should I upgrade to 7.1.8.x ??? (on the client end only)
January 05, 2018 07:59AM
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@us.ibm.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@VM.MARIST.EDU> wrote on 01/04/2018
> 09:16:25 AM:
>
> > From: Zoltan Forray <zforray@VCU.EDU>
> > To: ADSM-L@VM.MARIST.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@VM.MARIST.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@us.ibm.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@VM.MARIST.EDU> wrote on 01/04/2018
> > > 03:37:53 AM:
> > >
> > > > From: "Loon, Eric van (ITOPT3) - KLM" <Eric-van.Loon@KLM.COM>
> > > > To: ADSM-L@VM.MARIST.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@VM.MARIST.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@VM.MARIST.EDU] On
> > > > Behalf Of Deschner, Roger Douglas
> > > > Sent: donderdag 4 januari 2018 0:14
> > > > To: ADSM-L@VM.MARIST.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@U.WASHINGTON.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@u.washington.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@u.washington.edu)
> > > > > > -- Genome Sciences Department, System Administrator
> > > > > > -- Foege Building S046, (206)-685-7354
> > > > > > -- University of Washington School of Medicine
> > > > > >
> > > >
> > > > --
> > > > -- Skylar Thompson (skylar2@u.washington.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@vcu.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@vcu.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/
This message was imported via the External PhorumMail Module
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@VM.MARIST.EDU> wrote on 01/05/2018
10:45:19 AM:

> From: Zoltan Forray <zforray@VCU.EDU>
> To: ADSM-L@VM.MARIST.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@VM.MARIST.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@us.ibm.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@VM.MARIST.EDU> wrote on 01/04/2018
> > 09:16:25 AM:
> >
> > > From: Zoltan Forray <zforray@VCU.EDU>
> > > To: ADSM-L@VM.MARIST.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@VM.MARIST.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@us.ibm.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@VM.MARIST.EDU> wrote on
01/04/2018
> > > > 03:37:53 AM:
> > > >
> > > > > From: "Loon, Eric van (ITOPT3) - KLM" <Eric-van.Loon@KLM.COM>
> > > > > To: ADSM-L@VM.MARIST.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@VM.MARIST.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@VM.MARIST.EDU] On
> > > > > Behalf Of Deschner, Roger Douglas
> > > > > Sent: donderdag 4 januari 2018 0:14
> > > > > To: ADSM-L@VM.MARIST.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@U.WASHINGTON.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@u.washington.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@u.washington.edu)
> > > > > > > -- Genome Sciences Department, System Administrator
> > > > > > > -- Foege Building S046, (206)-685-7354
> > > > > > > -- University of Washington School of Medicine
> > > > > > >
> > > > >
> > > > > --
> > > > > -- Skylar Thompson (skylar2@u.washington.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@vcu.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@vcu.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=
>
This message was imported via the External PhorumMail Module
Sorry, only registered users may post in this forum.

Click here to login