Hi Zoltan,
I know you referenced
http://www.ibm.com/support/docview.wss?uid=swg22004844 earlier, but have
you gone back and revisited it? A couple of possible questions covered in
that document:
* If you have an existing cert.kdb database and cert.arm file that were
created before V7.1.8 or V8.1, then V7.1.8, V8.1.2, and V8.1.3 clients and
the Operations Center are unable to connect to a V7.1.8, V8.1.2, V8.1.3
server
* Restrictions apply when you specify the SSL-only server ports (SSLTCPPORT
and SSLTCPADMINPORT)
(Sergio also covered the latter item in his recent post..)
Best regards,
Andy
____________________________________________________________________________
Andrew Raibeck | IBM Spectrum Protect Level 3 | storman AT us.ibm DOT com
IBM Tivoli Storage Manager links:
Product support:
https://www.ibm.com/support/entry/portal/product/tivoli/tivoli_storage_manager
Online documentation:
http://www.ibm.com/support/knowledgecenter/SSGSG7/landing/welcome_ssgsg7.html
Product Wiki:
https://www.ibm.com/developerworks/community/wikis/home/wiki/Tivoli%20Storage%20Manager
"ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU> wrote on 2017-10-06
15:30:56:
> From: Zoltan Forray <zforray AT VCU DOT EDU>
> To: ADSM-L AT VM.MARIST DOT EDU
> Date: 2017-10-06 15:32
> Subject: Re: 7.1.8/8.1.3 Security Upgrade Install Issues
> Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
>
> Well, my testing of upgrading to 8.1.2/3 is not going well. Sure glad I
am
> doing this on a test server, since it doesn't bode well for a production
> system. This is what we did in our testing.
>
> 1. Server was upgraded from 8.1.1 to 8.1.3
> 2. Created a new node. Installed 7.1.6 client on a W10E workstation.
> Connected to the 8.1.3 server with no issues. Performed backups, etc.
> Even tried the webGUI/client with no issues.
> 3. Upgraded workstation client to 8.1.2 and now we can't connect to the
> server. Keeps giving us an SSL error. Checked all configuration for the
> node and opt file. Everything was set to SESSIONSECURITY Transitional.
> Now all we get (using the default client) is: 10/06/2017 15:09:25
ANS1592E
> Failed to initialize SSL protocol.
>
> I thought you were supposed to be able to upgrade the server to 8.1.2+
and
> then all of the clients would automagically get the cert/key from the
> server once they upgraded to 8.1.2+
>
> What am I missing?
>
> On Fri, Oct 6, 2017 at 10:00 AM, Skylar Thompson
<skylar2 AT u.washington DOT edu>
> wrote:
>
> > Content preview: We recently went from 7.1.7.300 to 7.1.8 in a
3-server
> > environment
> > (one library manager, two library clients). As always, do the
library
> > manager
> > before any of the clients. We had some communication problems with
one
> > of
> > the library clients that we ended up solving like so: [...]
> >
> > 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: 1507298431
> > X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384
> > X-Barracuda-URL: https://urldefense.proofpoint.com/v2/url?
> u=https-3A__148.100.49.
> 27-3A443_cgi-2Dmod_mark.cgi&d=DwIBaQ&c=jf_iaSHvJObTbx-
>
siA1ZOg&r=Ij6DLy1l7wDpCbTfcDkLC_KknvhyGdCy_RnAGnhV37I&m=vl-75QIYV_QPCqd2PTVfJN6vvkPdw3imy5SDMv7Vif0&s=8KOXc3Ke8u4JzOpQnZinbSxSMaUTAk8-
> zn1JzyjwTyQ&e=
> > X-Barracuda-Scan-Msg-Size: 4257
> > 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.43662
> > Rule breakdown below
> > pts rule name description
> > ---- ---------------------- ------------------------------
> > --------------------
> >
> > We recently went from 7.1.7.300 to 7.1.8 in a 3-server environment (one
> > library manager, two library clients). As always, do the library
manager
> > before any of the clients. We had some communication problems with one
of
> > the library clients that we ended up solving like so:
> >
> > 1. Make sure SSL certificates are distributed:
> > https://www.ibm.com/support/knowledgecenter/SSGSG7_7.1.8/
> > srv.admin/t_ssl_srvcfg_s2s.html
> > 2. Delete and redefine server definitions on both the client and
manager
> > using CROSSDEFINE
> >
> > The other library client was fine. I agree with Zoltan that the bigger
> > problem is actually admin account access; make sure that the systems
you
> > make admin connections from already have the 7.1.8/8.1.3 client
installed.
> >
> > On Thu, Oct 05, 2017 at 09:07:19PM -0500, Roger Deschner wrote:
> > > Versions 7.1.8 and 8.1.3 of WDSF/ADSM/TSM/SP have now been made
> > > available containing substantial security upgrades. A bunch of
security
> > > advisories were sent this week containing details of the
vulnerabilities
> > > patched. Some are serious; our security folks are pushing to get
patches
> > > applied.
> > >
> > > For the sake of discussion, I will simply call versions 7.1.7 and
before
> > > and 8.1.1 "Old", and I'll call 7.1.8 and 8.1.3 "New". (Not really
sure
> > > where 8.1.2 falls, because some of the security issues are only fixed
in
> > > 8.1.3.)
> > >
> > > There are some totally unclear details outlined in
> > > http://www-01.ibm.com/support/docview.wss?uid=swg22004844. What's
most
> > > unclear is how to upgrade a complex, multi-server, library-manager
> > > configuration. It appears from this document, that you must jump all
in
> > > at once, and upgrade all servers and clients from Old to New at the
same
> > > time. That is simply impractical. There is extensive discussion of
the
> > > new SESSIONSECURITY parameter, but no discussion of what happens when
> > > connecting to an Old client or server that does not even have the
> > > SESSIONSECURITY parameter.
> > >
> > > We have 4 TSM servers. One is a library manager. Two of them are
clients
> > > of the manager. The 4th server manages its tapes by itself, though it
> > > still communicates with all the other servers. That 4th server, the
> > > independent one, is what I'm going to upgrade first, because it is
the
> > > easiest. All our clients are Old.
> > >
> > > The question is, what's going to happen next? Will this one New
server
> > > still be able communicate with the other Old servers?
> > >
> > > Once my administrator id connects to a New server, this document says
> > > that my admin id can no longer connect to Old servers.
(SESSIONSECURITY
> > > is automatically changed to STRICT.) Or does that restriction only
apply
> > > if I connect from a New client? This could be an issue since I
regularly
> > > connect to all servers in a normal day's work. We also have automated
> > > scripts driven by cron that fetch information from each of the
servers.
> > > The bypass of creating another administrator ID is also not
practical,
> > > because that would involve tracking down and changing all of these
> > > cron-driven scripts. So, the question here is, at the intermediate
phase
> > > where some servers are Old and some New, can I circumvent this
Old/New
> > > administrator ID issue by only connecting using dsmadmc on Old
clients?
> > >
> > > This has also got to have an impact on users of software like
> > > Servergraph.
> > >
> > > There's also the issue of having to manually configure certificates
> > > between our library managers and library clients, but at least the
steps
> > > to do that are listed in that document. (Comments? Circumventions?)
> > >
> > > We're plunging ahead regardless, because of a general policy to apply
> > > patches quickly for all published security issues. (Like Equifax
didn't
> > > do for Apache.) I'm trying to figure this out fast, because we're
doing
> > > it this coming weekend. I'm sure there are parts of this I don't
> > > understand. I'm trying to figure out how ugly it's going to be.
> > >
> > > Roger Deschner University of Illinois at Chicago
rogerd AT uic DOT edu
> > > ======I have not lost my mind -- it is backed up on tape
somewhere.=====
> >
> > --
> > -- 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 https://urldefense.proofpoint.com/v2/url?
> u=http-3A__phishing.vcu.edu_&d=DwIBaQ&c=jf_iaSHvJObTbx-
>
siA1ZOg&r=Ij6DLy1l7wDpCbTfcDkLC_KknvhyGdCy_RnAGnhV37I&m=vl-75QIYV_QPCqd2PTVfJN6vvkPdw3imy5SDMv7Vif0&s=UHFHVxi_HK-
> bDGfzASgP7lNeKd4IAmkmqWxE8NF1ZHM&e=
>
|
