Hello,
> Now to find out where this SESSIONSECURITY parameters is located....
See the reference information for REGISTER NODE and UPDATE NODE.
Best regards,
Andy
____________________________________________________________________________
Andrew Raibeck | IBM Spectrum Protect Level 3 | storman AT us.ibm DOT com
IBM Tivoli Storage Manager links:
Product support:
https://www.ibm.com/support/entry/portal/product/tivoli/tivoli_storage_manager
Online documentation:
http://www.ibm.com/support/knowledgecenter/SSGSG7/landing/welcome_ssgsg7.html
Product Wiki:
https://www.ibm.com/developerworks/community/wikis/home/wiki/Tivoli%20Storage%20Manager
"ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU> wrote on 2017-10-06
23:41:06:
> From: "Sergio O. Fuentes" <sfuentes AT UMD DOT EDU>
> To: ADSM-L AT VM.MARIST DOT EDU
> Date: 2017-10-06 23:43
> Subject: Re: 7.1.8/8.1.3 Security Upgrade Install Issues
> Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
>
> Hello all!
>
> I just discovered this thread today because I had been testing 8.1.1
server
> very recently. I had some issues with that on Thursday and then Friday I
> went further down the rabbit hole. Now I'm finding that major portions
of
> our environment will have to be upgraded very soon.
>
> I'm just starting testing all sorts of client versions against the new
> 8.1.3 instance I have, however, I found this tidbit on "q opt tcpport":
>
> If you specify the same port number for both the SSLTCPPORT and TCPPORT
> >
> > options, only SSL connections are accepted and TCP/IP connections are
> >
> > disabled for the port.
> >
> >
> I read this as, "If you have SSLTCPPORT and TCPPORT as different numbers,
> TCPPORT will allow non-SSL TCP/IP connections".
>
> We actually do this. Does that mean our "old" clients will still be able
> to use TCPPORT without any issues?
>
> Now to find out where this SESSIONSECURITY parameters is located....
>
> Thanks!
>
> SF
>
>
> On Fri, Oct 6, 2017 at 3:30 PM, Zoltan Forray <zforray AT vcu DOT edu> wrote:
>
> > Well, my testing of upgrading to 8.1.2/3 is not going well. Sure glad
I am
> > doing this on a test server, since it doesn't bode well for a
production
> > system. This is what we did in our testing.
> >
> > 1. Server was upgraded from 8.1.1 to 8.1.3
> > 2. Created a new node. Installed 7.1.6 client on a W10E workstation.
> > Connected to the 8.1.3 server with no issues. Performed backups, etc.
> > Even tried the webGUI/client with no issues.
> > 3. Upgraded workstation client to 8.1.2 and now we can't connect to
the
> > server. Keeps giving us an SSL error. Checked all configuration for
the
> > node and opt file. Everything was set to SESSIONSECURITY Transitional.
> > Now all we get (using the default client) is: 10/06/2017 15:09:25
ANS1592E
> > Failed to initialize SSL protocol.
> >
> > I thought you were supposed to be able to upgrade the server to 8.1.2+
and
> > then all of the clients would automagically get the cert/key from the
> > server once they upgraded to 8.1.2+
> >
> > What am I missing?
> >
> > On Fri, Oct 6, 2017 at 10:00 AM, Skylar Thompson
<skylar2 AT u.washington DOT edu
> > >
> > wrote:
> >
> > > Content preview: We recently went from 7.1.7.300 to 7.1.8 in a
3-server
> > > environment
> > > (one library manager, two library clients). As always, do the
library
> > > manager
> > > before any of the clients. We had some communication problems
with
> > one
> > > of
> > > the library clients that we ended up solving like so: [...]
> > >
> > > Content analysis details: (0.7 points, 5.0 required)
> > >
> > > pts rule name description
> > > ---- ---------------------- ------------------------------
> > > --------------------
> > > 0.7 SPF_NEUTRAL SPF: sender does not match SPF record
> > > (neutral)
> > > -0.0 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: 1507298431
> > > X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384
> > > X-Barracuda-URL: https://urldefense.proofpoint.com/v2/url?
> u=https-3A__148.100.49.
> 27-3A443_cgi-2Dmod_mark.cgi&d=DwIBaQ&c=jf_iaSHvJObTbx-
> siA1ZOg&r=Ij6DLy1l7wDpCbTfcDkLC_KknvhyGdCy_RnAGnhV37I&m=ukO93-
> pLAC20rrzdR5oGl4Y3ggbt-C7QpoJC1J-g9P4&s=-mQcZbd_mU9Jo8Idj2qGVO-
> ef8PzRzsuE7nXhIYyqOQ&e=
> > > X-Barracuda-Scan-Msg-Size: 4257
> > > X-Virus-Scanned: by bsmtpd at marist.edu
> > > 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.43662
> > > Rule breakdown below
> > > pts rule name description
> > > ---- ---------------------- ------------------------------
> > > --------------------
> > >
> > > We recently went from 7.1.7.300 to 7.1.8 in a 3-server environment
(one
> > > library manager, two library clients). As always, do the library
manager
> > > before any of the clients. We had some communication problems with
one of
> > > the library clients that we ended up solving like so:
> > >
> > > 1. Make sure SSL certificates are distributed:
> > > https://www.ibm.com/support/knowledgecenter/SSGSG7_7.1.8/
> > > srv.admin/t_ssl_srvcfg_s2s.html
> > > 2. Delete and redefine server definitions on both the client and
manager
> > > using CROSSDEFINE
> > >
> > > The other library client was fine. I agree with Zoltan that the
bigger
> > > problem is actually admin account access; make sure that the systems
you
> > > make admin connections from already have the 7.1.8/8.1.3 client
> > installed.
> > >
> > > On Thu, Oct 05, 2017 at 09:07:19PM -0500, Roger Deschner wrote:
> > > > Versions 7.1.8 and 8.1.3 of WDSF/ADSM/TSM/SP have now been made
> > > > available containing substantial security upgrades. A bunch of
security
> > > > advisories were sent this week containing details of the
> > vulnerabilities
> > > > patched. Some are serious; our security folks are pushing to get
> > patches
> > > > applied.
> > > >
> > > > For the sake of discussion, I will simply call versions 7.1.7 and
> > before
> > > > and 8.1.1 "Old", and I'll call 7.1.8 and 8.1.3 "New". (Not really
sure
> > > > where 8.1.2 falls, because some of the security issues are only
fixed
> > in
> > > > 8.1.3.)
> > > >
> > > > There are some totally unclear details outlined in
> > > > http://www-01.ibm.com/support/docview.wss?uid=swg22004844. What's
most
> > > > unclear is how to upgrade a complex, multi-server, library-manager
> > > > configuration. It appears from this document, that you must jump
all in
> > > > at once, and upgrade all servers and clients from Old to New at the
> > same
> > > > time. That is simply impractical. There is extensive discussion of
the
> > > > new SESSIONSECURITY parameter, but no discussion of what happens
when
> > > > connecting to an Old client or server that does not even have the
> > > > SESSIONSECURITY parameter.
> > > >
> > > > We have 4 TSM servers. One is a library manager. Two of them are
> > clients
> > > > of the manager. The 4th server manages its tapes by itself, though
it
> > > > still communicates with all the other servers. That 4th server, the
> > > > independent one, is what I'm going to upgrade first, because it is
the
> > > > easiest. All our clients are Old.
> > > >
> > > > The question is, what's going to happen next? Will this one New
server
> > > > still be able communicate with the other Old servers?
> > > >
> > > > Once my administrator id connects to a New server, this document
says
> > > > that my admin id can no longer connect to Old servers.
(SESSIONSECURITY
> > > > is automatically changed to STRICT.) Or does that restriction only
> > apply
> > > > if I connect from a New client? This could be an issue since I
> > regularly
> > > > connect to all servers in a normal day's work. We also have
automated
> > > > scripts driven by cron that fetch information from each of the
servers.
> > > > The bypass of creating another administrator ID is also not
practical,
> > > > because that would involve tracking down and changing all of these
> > > > cron-driven scripts. So, the question here is, at the intermediate
> > phase
> > > > where some servers are Old and some New, can I circumvent this
Old/New
> > > > administrator ID issue by only connecting using dsmadmc on Old
clients?
> > > >
> > > > This has also got to have an impact on users of software like
> > > > Servergraph.
> > > >
> > > > There's also the issue of having to manually configure certificates
> > > > between our library managers and library clients, but at least the
> > steps
> > > > to do that are listed in that document. (Comments? Circumventions?)
> > > >
> > > > We're plunging ahead regardless, because of a general policy to
apply
> > > > patches quickly for all published security issues. (Like Equifax
didn't
> > > > do for Apache.) I'm trying to figure this out fast, because we're
doing
> > > > it this coming weekend. I'm sure there are parts of this I don't
> > > > understand. I'm trying to figure out how ugly it's going to be.
> > > >
> > > > Roger Deschner University of Illinois at Chicago
> > rogerd AT uic DOT edu
> > > > ======I have not lost my mind -- it is backed up on tape
> > somewhere.=====
> > >
> > > --
> > > -- Skylar Thompson (skylar2 AT u.washington DOT edu)
> > > -- Genome Sciences Department, System Administrator
> > > -- Foege Building S046, (206)-685-7354
> > > -- University of Washington School of Medicine
> > >
> >
> >
> >
> > --
> > *Zoltan Forray*
> > Spectrum Protect (p.k.a. TSM) Software & Hardware Administrator
> > Xymon Monitor Administrator
> > VMware Administrator
> > Virginia Commonwealth University
> > UCC/Office of Technology Services
> > www.ucc.vcu.edu
> > zforray AT vcu DOT edu - 804-828-4807
> > Don't be a phishing victim - VCU and other reputable organizations will
> > never use email to request that you reply with your password, social
> > security number or confidential personal information. For more details
> > visit https://urldefense.proofpoint.com/v2/url?
> u=http-3A__phishing.vcu.edu_&d=DwIBaQ&c=jf_iaSHvJObTbx-
> siA1ZOg&r=Ij6DLy1l7wDpCbTfcDkLC_KknvhyGdCy_RnAGnhV37I&m=ukO93-
> pLAC20rrzdR5oGl4Y3ggbt-C7QpoJC1J-
> g9P4&s=HKOalDk02Uzznskbh5uFD18M24VahC1LPhmuvXz4IwY&e=
> >
>
|
