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/
>>
|
