Thank you both :-)
Now I see what you meant.
I did that the other day when upgrading v7.1.7.0 to v8.1.0.0
And I did a test from v8.1.0.0 to v8.1.1.0 and even that small step
included new licenses, so I did "REGister LICense FILE=*.lic"
I was only doing it once per version jump before... when upgrading from
v5 to v6, and v6 to v7, but never had to do it for maintenance and patch
releases.
Tnx again.
--
Sasa Drnjevic
www.srce.unizg.hr
On 2017-11-17 21:49, Sergio O. Fuentes wrote:
> 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 <zforray AT vcu DOT 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.Drnjevic AT srce DOT 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 <zforray AT vcu DOT 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 <sfuentes AT umd DOT
>>>>> 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 <zforray AT vcu DOT 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 <
>> sfuentes AT umd DOT 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 <
>>>>>>> skylar2 AT u.washington DOT 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 (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 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
>>>>> 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 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
>> 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 http://phishing.vcu.edu/
>>
|
