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