You know, my first thought was to simply delete your ranting but then I
decided to respond because it seems there are a few people on this board
who seem to think their sole purpose is to blast others rather than to
try to help. If I sound like I'm ticked, it is because I'm sick of
having my in-box cluttered up by these type of posts.
For everybody else on the list, I apologize in advance for my ranting
back but I am looking for help, not ranting about everything I
apparently did wrong.
In <[EMAIL PROTECTED]>,
on 02/01/2006
at 11:40 AM, "Pommier, Rex R." <[EMAIL PROTECTED]> said:
>I have a strange one. z/OS 1.4 on a Multiprise 3000 H50 box. Last
>night I got a call from operations that a FTP job blew on the 390
>trying to FTP to a wintel server with a "connection refused" error. In
>trying to diagnose the problem I had the operator try a ping to the
>same machine and then to a couple others. Each time, they received
>this error: "EZZ3115I Unable to open RAW socket: EDC5139I Operation not
>permitted." I logged on and was able to ping and ftp all I wanted
>without any errors. What I discovered was that I have an OMVS segment
>in RACF giving me UID 0 access and the IDs the operators are using have
>no OMVS segment at all. Giving them UID 0 in newly-created OMVS
>segments allowed them to now run ping and FTP.
WTF? Talk about killing a fly with a sledge hammer, and begging to be
written up by the next auditor to come in the door. If someone couldn't
get into his office because he had no key, would you give him a master
key that let him open any door in the building instead of a key to his
office? Well, that's what you just did. You need to RTFM, then create an
*appropriate* OMVS segment.
My response: No kidding! Thanks for all your help! NOT! I got a call
in the night about a FTP job that has been working for years then it
went down with the "connection refused". No changes had been made to
the job or to the security definitions on the system. I had the
operator try a ping to the box they were trying to FTP to and got the
"raw socket" problem. Working production job stops working with as best
I can see no changes. I patched it up by giving access to the operator
IDs so they could CONTINUE PRODUCTION. I know I opened up a huge hole.
Do you suppose that just maybe that was one reason I asked this group
what could be causing the problem and how I could fix it to close the
hole back up and continue allowing production to work??? I have
RTFM'ed as you so glibly suggested and from my later posts, it looks
like everything was/is set up as it should be. That's why I'm confused
as to what caused it and how to fix it.
>I made NO changes to RACF yet these things worked 1 day and not
>the next.
What things worked? Had the operator ever done a ping before?
My response: What things worked? Uh, FTP and PING??!!! Yes, they have
done ping before from the 390 and yes they have worked.
>The only thing that I can see that changed was one of my network
>associates started working on building pools into a pair of F5 load
>balancers to allow me to load balance telnet and ftp traffic across
>both of the BusTech appliances we front-end the MP3000 with.
Aside from that, Mrs. Licoln, how was the play? That should have been
the first thing you looked at.
My response: "started working on". He had not completed building the
pools much less activating them, and further, to actually use them, we
would have to modify the client machines to access the pool rather than
straight to the 390 IP addresses. When FTP broke, I had him remove the
changes from the F5's and it didn't help.
In <[EMAIL PROTECTED]>,
on 02/01/2006
at 02:43 PM, "Pommier, Rex R." <[EMAIL PROTECTED]> said:
>Thanks for the hints, but as you can see from above, it all looks OK
>- except that all the sudden I need UID 0.
Nothing that you described supports such a belief.
Response: What part of "On my playground system I just changed the UID
of OEDFLTU to 0 and mortal users can PING. If I set the UID to 7, they
can't." is not understandable?
In <[EMAIL PROTECTED]>,
on 02/01/2006
at 03:25 PM, "Pommier, Rex R." <[EMAIL PROTECTED]> said:
>That's the problem. It broke on all 3 LPARs
What broke? FTP? That had nothing to do with RACF. As for ping, nothing
that you wrote suggests that the operator was ever able to use it.
My response: The operator could and did use PING before. Is that plain
enough? Yes, I left it implied, and if that confused you, I'm sorry
about that. When I said it "broke", FTP worked before and now it
doesn't. Ping worked, now it doesn't. To me, that's a pretty good
definition of "broke". From the helpful reply that Peggy sent me, it
looks like it is a security issue on both parts. That has a lot to do
with RACF. I have double-checked all my RACF settings and I can't see
anything wrong. I dug through the SMF records related to RACF and they
show that nothing was changed in the RACF environment.
--
Shmuel (Seymour J.) Metz, SysProg and JOAT
ISO position; see <http://patriot.net/~shmuel/resume/brief.html>
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send
email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search
the archives at http://bama.ua.edu/archives/ibm-main.html
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
