Zoltan is correct... you have to install the license package from 8.1.0.0, I believe. Otherwise you'll get nasty messages in the actlog. Though I'm not sure if it actually breaks functionality.
If there any IBMers browsing on a Friday afternoon, PMR 53017,082,000 is opened in reference to our issues with the 3rd party certificates and the operations center. Thank you! Sergio On Fri, Nov 17, 2017 at 2:36 PM, Zoltan Forray <zfor...@vcu.edu> wrote: > I would assume the server license as a minimum. Every time we have jumped > a version, there is a new server licensing part/files and we have to do a > REGister LICense FILE=*.lic on the server after it is up-and-running. > > On Fri, Nov 17, 2017 at 2:11 PM, Sasa Drnjevic <sasa.drnje...@srce.hr> > wrote: > > > 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/ > > >> > > > > > > -- > *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/ >