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/