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 | [email protected] 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" <[email protected]> wrote on 2017-10-06 23:41:06: > From: "Sergio O. Fuentes" <[email protected]> > To: [email protected] > Date: 2017-10-06 23:43 > Subject: Re: 7.1.8/8.1.3 Security Upgrade Install Issues > Sent by: "ADSM: Dist Stor Manager" <[email protected]> > > 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 <[email protected]> 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 <[email protected] > > > > > 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 > > [email protected] > > > > ======I have not lost my mind -- it is backed up on tape > > somewhere.===== > > > > > > -- > > > -- Skylar Thompson ([email protected]) > > > -- 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 > > [email protected] - 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= > > >
