We have a 3-tier architecture so no "real users" are actually on the
iSeries, it's just the back end DB. The network god's concern is that
they *might* accidently bring up a new application server that points to
the wrong database. I've already set up packet filtering to exclude
test servers from the prod DB and vice-versa but their preference is
that I exclude everything except servers that are explicitly allowed.
And then they want me to monitor this so that I can immediately
authorize a new server that *should not* be excluded from any particular
environment. I told them that I could do one or the other, but not both
at the same time.
My biggest concern is that rather than addressing access or authority,
which I would have agreed with, they want to address this from the
direction of connectivity. All this really does is make moving data a
two-step process rather than a one-step process and creates the
necessity of teaching ops and programmers how to change their central
systems and debug iNav command failures. Oh yea, and combining this
with the IP packet rules any connection can now fail from either side so
I'll expect a lot of finger pointing.
Regards,
Scott Ingvaldson
Senior IBM Support Specialist
Fiserv Midwest
-----Original Message-----
From: rob@xxxxxxxxx [mailto:rob@xxxxxxxxx]
Sent: Tuesday, May 20, 2008 9:38 AM
To: Midrange Systems Technical Discussion
Subject: Re: Management Central and Network Security
So the network God's concern is that a test lpar might have a database
copied from production that has a list of environments and no one
updated that database so when an application runs it does a CONNECT TO
(or DDM, or
...) and ends up accessing production when it should be accessing the
test lpar, right? Of course, if you're running a C/S application and
you have that same setup on your client you have the same issue (and as
your pc can already access all environments...). So how do you address
their concerns while still getting your job done?
I like the compare ptf's. Beats the old DSPPTF OUTPUT(*OUTFILE) and
squealing the heck out of those. That old workaround may work for you.
Or you could use the port solution you already alluded to, or just get
your manager to kick the network guy's ...
Rob Berendt
--
Group Dekko Services, LLC
Dept 01.073
Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com
"Ingvaldson, Scott" <scott.ingvaldson@xxxxxxxxxx>
Sent by: midrange-l-bounces@xxxxxxxxxxxx
05/20/2008 10:09 AM
Please respond to
Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
To
<midrange-l@xxxxxxxxxxxx>
cc
Subject
Management Central and Network Security
I am running into difficulties justifying intersystem access for
Management Central here, has anyone else had to do this?
We have an LPARed 550 with a dev, test and production environments, we
also have a completely segregated DR system and a 520 that's being
designated as a "Demo" system for our sales force.
Our network group has recommended that there be no access between
environments, so even though my workstation can contact every system
here, I need to have three separate MC monitors in three different iNav
sessions to view all the systems. This is also affecting running
commands on the Demo system through iNav because the Test LPAR was
designated as the central system and as near as I can tell makes the
compare and update fixes function unusable.
I know that I can request that the specific MC ports be opened, but I
was wondering how many others have had to go through this exercise.
I'm hoping that John or Tom will chime in on this...
Regards,
Scott Ingvaldson
Senior IBM Support Specialist
Fiserv Midwest
midrange.com
