Back to CA-MSM Pre-req verify

Gibney, Dave

unread,

Jan 7, 2010, 2:58:48 PM1/7/10

to

I'm getting back to this after the holidays.
I've downloaded and run the validator and get three errors:

1. JESINTERFACELEVEL =UNKNOWN Required JESINTERFACELEVEL Level is :2

In the validator log is:

INFO 2010-01-07 19:31:18,697 (FTPUtil.java:260): FTP Credential Checked
:n
DEBUG 2010-01-07 19:31:19,119 (FTPUtil.java:273): Output of STAT command
:
DEBUG 2010-01-07 19:31:19,122 (FTPUtil.java:274): 534 Server requires
authentication before command processing.

DEBUG 2010-01-07 19:31:19,124 (FTPUtil.java:277): Null Return in STAT
command
INFO 2010-01-07 19:31:19,126 (GatherEnvDetails.java:867):
JESINTERFACELEVEL level:0
INFO 2010-01-07 19:31:19,130 (GatherEnvDetails.java:869): Default
JESINTERFACELEVEL :2
INFO 2010-01-07 19:31:19,131 (GatherEnvDetails.java:877):
JESINTERFACELEVEL :0
INFO 2010-01-07 19:31:19,164 (FTPUtil.java:432): Logout From FTP server

DEBUG 2010-01-07 19:31:19,166 (GatherEnvDetails.java:155):
JESINTERFACELEVEL validation Done

2. CCI =CCI Availability Check Failed

This sandbox is currently CA-free, do I have to get CCI working the old
way to use MSM.

And finally:

BPX.SERVER (READ) |No Access |No

But I have access:
CLASS NAME
----- ----
FACILITY BPX.SERVER

LEVEL OWNER UNIVERSAL ACCESS YOUR ACCESS WARNING
----- -------- ---------------- ----------- -------
00 SYS1 NONE READ NO

In the validator log:

(GatherEnvDetailsRepo.java:233): PlatformSecurity is active

(GatherEnvDetailsRepo.java:238): SAF Resource Access Check done for User
id : GIBNEY
(GatherEnvDetailsRepo.java:275): Check for READ Access on BPX.SERVER :
errnoMsg:EDC5139I Operation not permitted., errno : 139& errn o2 :
154665647
(InternalPropertyReader.java:140): bpx.arg.5

(InternalPropertyReader.java:142): BPX.SERVER,UPDATE

I haven't followed the EDC5139I path to the specific yet :)
I did search CA-Support, but haven't opened a ticket yet :)
I would appreciate any assistance.

Dave Gibney
Information Technology Services
Washington State University

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to list...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Mark Zelden

unread,

Jan 7, 2010, 3:22:39 PM1/7/10

to

On Thu, 7 Jan 2010 11:58:05 -0800, Gibney, Dave <gib...@WSU.EDU> wrote:

> I'm getting back to this after the holidays.
> I've downloaded and run the validator and get three errors:
>
>1. JESINTERFACELEVEL =UNKNOWN Required JESINTERFACELEVEL Level is :2
>

You need level 2 in your FTP server parms. PLEASE read the caveats that
come along with doing that. It is a security exposure if you don't have
the JES RACF classes active and secured. For example, someone could
FTP into JES and get payroll output without any problems just by knowing
a jobname. If you control SDSF via SAF rules today (not just ISFPARMS),
then you probably are safe.

>
>2. CCI =CCI Availability Check Failed
>
>This sandbox is currently CA-free, do I have to get CCI working the old
>way to use MSM.
>

MSM requires CCI. I'm sure it's documented.

>And finally:
>
>BPX.SERVER (READ) |No Access |No
>
>But I have access:
>CLASS NAME
>----- ----
>FACILITY BPX.SERVER
>
>LEVEL OWNER UNIVERSAL ACCESS YOUR ACCESS WARNING
>----- -------- ---------------- ----------- -------
> 00 SYS1 NONE READ NO
>

I posted about this previously. Search the archives. It's a bug in the
pre-validation utility for RACF systems. Here is the fix:

After unwinding the pax file:

cd <utility path>/Bin
extattr +p ./lib/*.so

Mark
--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America / Farmers Insurance Group - ZFUS G-ITO
mailto:mark....@zurichna.com
z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/
Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html

Gibney, Dave

unread,

Jan 7, 2010, 3:42:36 PM1/7/10

to

> >
> >1. JESINTERFACELEVEL =UNKNOWN Required JESINTERFACELEVEL Level is :2
> >
>
> You need level 2 in your FTP server parms. PLEASE read the caveats
> that
> come along with doing that. It is a security exposure if you don't
> have
> the JES RACF classes active and secured. For example, someone could
> FTP into JES and get payroll output without any problems just by
> knowing
> a jobname. If you control SDSF via SAF rules today (not just
> ISFPARMS),
> then you probably are safe.

Thank you, I missed the INTERFACELEVEL part :( I'm still ISFPARMS so
need to research.

>
> >
> >2. CCI =CCI Availability Check Failed
> >
> >This sandbox is currently CA-free, do I have to get CCI working the
> old
> >way to use MSM.
> >
>
> MSM requires CCI. I'm sure it's documented.
>

Yup, I got sidetracked by next issue and missed this.

> >And finally:
> >
> >BPX.SERVER (READ) |No Access |No
> >
> >But I have access:
> >CLASS NAME
> >----- ----
> >FACILITY BPX.SERVER
> >
> >LEVEL OWNER UNIVERSAL ACCESS YOUR ACCESS WARNING
> >----- -------- ---------------- ----------- -------
> > 00 SYS1 NONE READ NO
> >
>
>
> I posted about this previously. Search the archives. It's a bug in
> the
> pre-validation utility for RACF systems. Here is the fix:
>
> After unwinding the pax file:
>
> cd <utility path>/Bin
> extattr +p ./lib/*.so
>

I did this and I still get:

SAF resource access check done for user id : GIBNEY

------------------------------------------------------------------------
--------
RESOURCE (Expected Access) |Site Version |Acceptable?

------------------------------------------------------------------------
--------

BPX.SERVER (READ) |No Access |No

cd lib
$ ls -E

total 3520

-rwxrwxrwx --s- 1 BOOTSTRP SYSTEMS 18305 Oct 30 14:52
ApplicationMessages.properties
-rwxrwxrwx -ps- 1 BOOTSTRP SYSTEMS 94208 Oct 30 14:52 ICSF.so

.....

It also seems to require UID=0

Mark Zelden

unread,

Jan 7, 2010, 3:51:47 PM1/7/10

to

On Thu, 7 Jan 2010 12:23:44 -0800, Norman Hollander on DesertWiz
<norman.h...@DESERTWIZ.BIZ> wrote:

>It really is best to go through the Support channel.
>They are quite knowledgeable in MSM and really helpful.
>

They have been very slow to respond to open issues.

>You do need to have CA Common Services up and running.
>While you are doing the install, you do want JESINTERFACLEVEL
>to be 2. This has been around for quite a while, is not risky,

Disagree there. It can be risky since it opens up the spool with possibly
no security access via FTP. Whether it's for 15 minutes or 15 hours,
it's still a security risk I would never consider in a production
environment. I thought it was documented in the MSM
manual, but may have been a tech note on the CA MSM web site.

>and allows the MSM installer to access the JES spool to check on
>the jobs it ran. You could always return it to 1 after the install.
>

Thanks. That I was not aware of. The install manual didn't spell this
out at all (it did explain it was needed for the install process).

Since it was part of the pre-req check, I assumed it was needed
for normal operation also. This may make me re-think were I
run MSM in my environment. My first choice was a sysplex without
JESINTERFACELEVEL 2 and getting the RACF rules in place would
have been a PITA. But that environment and LPAR I wanted to
run it on has zAAPs and CSF, so I may change my mind since
that is already the environment we typically do installs from.

Mark Zelden

unread,

Jan 7, 2010, 3:58:48 PM1/7/10

to

I don't think it did for me. It did spit out a message about not having
root authority. I deleted all the pre validation stuff, so I don't have the
output report to look at any longer without doing it over. To be honest,
I spent a few days trying to get it to work and working with CA support,
and it only took my a couple of hours to do the actual install once I
got past the pre-validation.

Gibney, Dave

unread,

Jan 7, 2010, 4:23:41 PM1/7/10

to

I found this in the log:
ICH420I PROGRAM CELHV003 FROM LIBRARY CEE.SCEERUN2 CAUSED THE ENVIRONMEN

T TO BECOME UNCONTROLLED.

BPXP014I ENVIRONMENT MUST BE CONTROLLED FOR SERVER (BPX.SERVER)

PROCESSING.

I bet this was documented in the z/OS 1.9 migration somewhere :(
Unfortunately, it took me two years dodging multiple distractions to get
from 1.7 to 1.9

I'll install CCI and company, look at SAF for SPOOL, and proceed. As
well as z/OS 1.11, and EJES 4.7 and, and, and...

Thanks for your help Mark, Norm, Dave.

Dave Gibney
Information Technology Services
Washington State University

> >

----------------------------------------------------------------------

Mark Zelden

unread,

Jan 7, 2010, 4:35:04 PM1/7/10

to

On Thu, 7 Jan 2010 13:23:03 -0800, Gibney, Dave <gib...@WSU.EDU> wrote:

> I found this in the log:
>ICH420I PROGRAM CELHV003 FROM LIBRARY CEE.SCEERUN2 CAUSED THE ENVIRONMEN
>
>T TO BECOME UNCONTROLLED.
>
>BPXP014I ENVIRONMENT MUST BE CONTROLLED FOR SERVER (BPX.SERVER)
>
>PROCESSING.
>
>
> I bet this was documented in the z/OS 1.9 migration somewhere :(

It is documented in the security section of the MSM manual (around page 24):

If you are using IBM RACF, access to the following data sets for
program control:

SYSx.MIGLIB
CEE.SCEERUN2
member IEANTCR of SYS1.CSSLIB
Optional) member IDIXCEE of SYS1.IDI.SIDIAUTH, only if you use
IDIXCEE as an optional exit

You can set programs to be controlled by IBM RACF using the following
command:

RDEFINE PROGRAM member ADDMEM('hlq.libraryname'//NOPADCHK) UACC(READ)

For example:
RDEFINE PROGRAM IEANTCR ADDMEM('SYS1.CSSLIB'//NOPADCHK) UACC(READ)

Note: To set all members of a data set as a controlled program,
replace the member name with an asterisk (*). For example:

RDEFINE PROGRAM * ADDMEM('SYS1.CSSLIB'//NOPADCHK) UACC(READ)

Important! If you are planning to use zFS, you must add
IOE.SIOELMOD (or equivalent library) to program control.

Mark
--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America / Farmers Insurance Group - ZFUS G-ITO
mailto:mark....@zurichna.com
z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/
Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html

----------------------------------------------------------------------

Mark Zelden

unread,

Jan 7, 2010, 5:39:38 PM1/7/10

to

On Thu, 7 Jan 2010 14:04:13 -0800, Norman Hollander on DesertWiz
<norman.h...@DESERTWIZ.BIZ> wrote:

>I've recommended that MSM is best run in your sandbox environment, or the
>location where you
>currently install software and maintenance first. Although MSM really is
>localized, in that
>it is doing installs and interfacing with SMP/E; you could say there is
>minimal risk in the
>SysProg sandbox. I'll be glad to pass on your observation that issue
>response is slow. Support
>does keep track of that, I have not heard that concern before.
>

Today, I can install products and maintenance them pretty much on any
LPAR since there is a HLQ and catalog on a shared set of dasd volumes
that we do our ISV installs to. Although we typically do the work from
a development LPAR.

Once the team starts using MSM, I have to consider DR also. While all
maintenance, fixes, etc. could be done outside of MSM, I think once
we are installing and maintaining CA products with MSM, I'll want to
have MSM running on a system that is recovered for DR also.

With a shared file system environment in the sysplex I was going to run
this in (not the development sandbox I initially wanted), moving MSM to
another (recovered) LPAR is easy. There only thing that has to change
is one Tomcat config file that points at the CA-ENF SYSID. I've already
tested moving it in my sandbox sysplex where it is running now and
didn't run into any problems.

I wouldn't have this flexibility with the development sysplex system since
that LPAR isn't recovered. I'd need to have more preparation and special
DR setup to run it in a different sysplex. But it is something that can be
done and I need to consider.

Regards,