Yes, 1 catcher with control/usage on 1 domain and control on the rest to load
all the keys on a card.
If we did it on the Linux guest that will actually use the key, I would have to
move all those guests around to 8 different CEC's in two different datacenters.
That's just not going to happen. I have to have the keys there before it
gets to the other data center. So hence a Linux whose only purpose in life is
to run catcher (hmmm, how about delivering this as an SSC?)
I don't envision a situation where we have to do lots quickly since the other
CEC's are available all the time. We'd just move the servers to where the key
is available. z/OS has been using keys for a while and they load when a new CEC
comes in or if a card dies. And that's about it.
Linux in an LPAR is a pain, especially in a GPDS and hyperswap environment
where it's considered a foreign system and so would need its own LCU. We will
likely just put it on non-replicated disk. The console is the HMC ascii, which
isn't accessible to Linux engineers- we'd have to get an operator to screen
share. So if that Linux doesn't boot after patching, we're looking at some
fun in recovery.
My thought was to have one per data center. Bring it up in the LPAR reserved
for key loading when needed, but then put it back under z/VM (where Linux
belongs __ ) on a routine basis. No, I can't just leave it down due to
compliance reasons (must be subject to scanning and other asset management
policy tools).
IP changes would be problematic to the authentication software we use.
On 9/24/20, 10:37 PM, "Linux on 390 Port on behalf of Timothy Sipples"
<LINUX-390@VM.MARIST.EDU on behalf of sipp...@sg.ibm.com> wrote:
Marcy,
It seems like what you're envisioning is to have a "service" image to run
catcher.exe (slight correction: it's actually catcher.exe rather than
panel.exe) to facilitate TKE Workstation interactions with various Crypto
Express CCA mode physical features (and associated domains) spread across
several machines. That all seems fine to me, but one threshold question
that comes to mind is whether sharing a single IP address supports "fast
enough" operations. What I mean is that with a single IP address you'll
only be able to have one instance of this service image running at any one
time. If you're in a future situation where you have to perform lots of
TKE operations across multiple machines/features/domains very quickly --
some sort of calamity involving rapid fire TKE operations -- your
operational "throughput" *could* be significantly limited with only one
running service image at a time.
A slight, simple variation here would be to have a single service image
with a default startup IP address but then allow an authorized operator to
switch the image to a different IP address once that image starts up. That
way you could have multiple instances of this service image running as
long as only one of them is starting up at any one time.
- - - - - - - - - -
Timothy Sipples
I.T. Architect Executive
Digital Asset & Other Industry Solutions
IBM Z & LinuxONE
- - - - - - - - - -
E-Mail: sipp...@sg.ibm.com
----------------------------------------------------------------------
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or
visit
http://www2.marist.edu/htbin/wlvindex?LINUX-390
----------------------------------------------------------------------
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www2.marist.edu/htbin/wlvindex?LINUX-390
