First of all thank you so much for all the info! Can you please just clarify the following:
"Licensing files need to be updated with the 8.1.0.x packages." Which/whose "Licensing files"? Client, server or OC? In which case (upgrade to 8.1.2.0 or 8.1.3.0? THNX! -- Sasa Drnjevic www.srce.unizg.hr On 2017-11-17 19:55, Sergio O. Fuentes wrote: > I wanted to update this email thread with some of the gotchas that we have > or are experiencing due to our upgrade from 7.1.7 to 8.1.3: > > - Watch out when using configuration management or a library manager. I > don't have it documented very carefully, but if you're in a configuration > management environment or a shared scsi library environment, be very > careful on how you plan the upgrade. Firstly, if you don't do SSL between > TSM servers prior to the upgrade, don't turn it on in the middle of the > upgrade process. We have 4 servers in a config management/library manager > configuration. We had the bright idea to just turn on SSL before all > servers were upgraded and we subsequently broke communication somewhere. > Config management died, library manager died and now we have to remediate > all that configuration again. The best thing to do.... do all servers > exactly the same way with as few changes as necessary. Turn on SSL > wherever desired in a later plan. > > - The biggest headache so far has been the interoperability with the > Operations Center. The Operations Center was upgraded to 8.1.2 and we > expected the SSL handshake to go without a hitch. Incorrect: our 3rd party > CA certs don't appear to be compatible with the OC configuration files and > we have a ticket open up with IBM to figure out what the issue is. > Documentation on how to use 3rd party CA certs between the User Browser -> > OC -> Hub Server -> Spokes is very spotty and not well documented at all. > This is a very big gap in my opinion on true adoption for the Operations > Center. Our Operation Centers are down until we can figure out what's > wrong with the 3rd party certs. There is only true documentation of > OC->Hub, but what we really need is User Browser -> OC so we get that green > lovey-dovey secure feeling when we show our bosses. I had this working in > previous versions of the O.C. > > - Client transitions to SSL indeed won't occur until later. However, we > made it a plan to test any client versions that were out of IBM support. > Those tests went fine and so far we have minimal core functionality > issues. Some clients are locking themselves out and our TSM admins keep > locking themselves out depending on where they log into the admin client > from, so that's a little headache. > > - Licensing files need to be updated with the 8.1.0.x packages. > > Thanks! > Sergio > > On Tue, Oct 10, 2017 at 1:22 PM, Zoltan Forray <zfor...@vcu.edu> wrote: > >> That is probably due to: >> >> SSLACCEPTCERTFROMSERV - The default value Yes enables the client to >> automatically accept a self-signed public certificate from the server, and >> to automatically configure the client to use that certificate when the >> client connects to a V8.1.2 or later server. >> >> >> On Tue, Oct 10, 2017 at 11:58 AM, Sergio O. Fuentes <sfuen...@umd.edu> >> wrote: >> >>> My digicert signed certs are loaded into the server cert.kdb using the >>> gsk8apicmd functions. That's working. My question was getting those >>> non-existent root and intermediate CA certs loaded into the client. >>> Normally, in order to get SSL working, you need the whole signing chain >> on >>> the client (not the private TSM server signed cert). In prior versions >> to >>> 8.1.2 you had to manually add any commercial root certs that were not >>> included in the original dsmcert.kdb. >>> >>> I just did a quick test on a new client, and it looks like the whole >> public >>> cert chain is negotiated correctly with a CA signed certificate. >>> >>> Initial environment was with the admin client (dsmadmc) and admin >>> sessionsecurity=transitional. Both server and client are on the same >>> machine 8.1.3 server and 8.1.2 client. I'm not sure if that factored >> into >>> the negotiation. >>> >>> So far, I think we're in good shape to have this pushed out in the next >> two >>> weeks to production. We'll be upgrading the servers first and the ops >>> center shortly thereafter. Then we'll be recommending that all clients >>> start the upgrade process (providing SSL guidance where necessary). >>> Therefore, most of our admins and nodes will be in the transitional state >>> for quite some time. >>> >>> Thanks! >>> Sergio >>> >>> >>> On Tue, Oct 10, 2017 at 10:43 AM, Zoltan Forray <zfor...@vcu.edu> wrote: >>> >>>> As I read it, "vendor-acquired certificates" need to be loaded/added to >>> the >>>> server using the gsk8capicmd function. This link, while it's for >> 7.1.1, >>>> talks about it: >>>> >>>> https://www.ibm.com/support/knowledgecenter/en/SSGSG7_7.1. >>>> 1/com.ibm.itsm.tshoot.doc/r_pdg_ssl_comm.html >>>> >>>> On Tue, Oct 10, 2017 at 10:00 AM, Sergio O. Fuentes <sfuen...@umd.edu> >>>> wrote: >>>> >>>>> I have one other question for any IBMers or people who may have had >>>>> experience with this: >>>>> >>>>> If 8.1.2 clients can negotiate certificates with a 8.1.3 TSM server, >>> does >>>>> this mean that for users who use third-party signed certificates (not >>>>> loaded by default in the TSM client) that the certificate chain will >>>>> automatically be loaded to an 8.1.2 client? For example, we use >>> digicert >>>>> signed certs. Digicert is not one of the pre-loaded root certificates >>> in >>>>> the TSM client (Verisign and Thawte are). Can an 8.1.2 client >>> negotiate >>>>> the entire cert chain or will we be required to load the root and >>>>> intermediate digicert certs into the client? >>>>> >>>>> To ask more directly, how can I petition IBM to release a client with >>>>> pre-loaded DigiCert CA certificates? >>>>> >>>>> Thanks! >>>>> Sergio >>>>> >>>>> On Mon, Oct 9, 2017 at 12:14 PM, Skylar Thompson < >>>> skyl...@u.washington.edu >>>>>> >>>>> wrote: >>>>> >>>>>> Content preview: I definitely agree with this; at least for TSM >> v7 >>> it >>>>>> would >>>>>> have been far better to call it v7.2.0 to make it clear that >>> it's a >>>>>> huge >>>>>> change with lots of caveats and potential failure points. We've >>> just >>>>>> now discovered >>>>>> that TSM v7.1.8 does not play nicely with GPFS/mmbackup due to >> a >>>>>> change in >>>>>> how SSL certificates are loaded - hopefully it's a simple fix >> but >>>> who >>>>>> knows... >>>>>> [...] >>>>>> >>>>>> 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: 1507565699 >>>>>> X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 >>>>>> X-Barracuda-URL: https://148.100.49.27:443/cgi-mod/mark.cgi >>>>>> X-Barracuda-Scan-Msg-Size: 1182 >>>>>> 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.43739 >>>>>> Rule breakdown below >>>>>> pts rule name description >>>>>> ---- ---------------------- ------------------------------ >>>>>> -------------------- >>>>>> >>>>>> I definitely agree with this; at least for TSM v7 it would have >> been >>>> far >>>>>> better to call it v7.2.0 to make it clear that it's a huge change >>> with >>>>> lots >>>>>> of caveats and potential failure points. We've just now discovered >>> that >>>>> TSM >>>>>> v7.1.8 does not play nicely with GPFS/mmbackup due to a change in >> how >>>> SSL >>>>>> certificates are loaded - hopefully it's a simple fix but who >>> knows... >>>>>> >>>>>> On Sat, Oct 07, 2017 at 02:36:13PM -0500, Roger Deschner wrote: >>>>>>> This difficulty comes up while there are open, now-published >>> security >>>>>>> vulnerabilities out there inviting exploits, and making our >>> Security >>>>>>> people very nervous. But the considerations described in >>>>>>> http://www-01.ibm.com/support/docview.wss?uid=swg22004844 make >> it >>>> very >>>>>>> difficult and risky to proceed with 7.1.8/8.1.3 as though it was >>>> just a >>>>>>> patch. It's a major upgrade, requiring major research and >> planning, >>>>> with >>>>>>> the threat of an exploit constantly hanging over our heads. I >>> really >>>>>>> wish this had been handled differently. >>>>>> >>>>>> -- >>>>>> -- Skylar Thompson (skyl...@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 >>>> zfor...@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/ >>>> >>> >> >> >> >> -- >> *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 >> zfor...@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/ >>