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