The very intersting thing on the one server sign-on was physically impossible
(Even as Root AT the Linux guest console - I have root access via SSH
disabled)
My surmization of this is that it was a combination of no functioning DNS and
NO entry in /etc/hosts/ for LDAP to resolve. Please let me know what
you all think:
My LDAP definition has say for example purposes : host server.ethernet.dns.name
and my /etc/hosts file has this : 137.222.222.60 host
server.ethernet.dns.name hawk
And until changed, the DNS entries were for two bind DNS's and the third slot
was blank. (Last test, the third slot had the IP address of the DNS
server on z/OS)
This gives LDAP (and by extension PAM modules) an IP address resolved from the
name in /etc/hosts
So on those machines with this configuration, even though NO valid DNS service
was available, it still had an IP address because of /etc/hosts lookup.
No DNS query was needed so the LDAP call times out/comes back unable to
connect. PAM authentication falls through to local password.
On the one machine where no entry in /etc/hosts for host
server.ethernet.dns.name, DNS resolution would be attempted. DNS call would
fail to DNS 1.
DNS call would fail to DNS 2. By the time this has returned (if LDAP ever
recovered from having no resolution) The 60 second linux timeout has already
hit and PAM fallthrough to local authentication never gets the chance to try
authentication.
When I put the entry into /etc/hosts, DNS resolution was not needed and local
authentication was allowed after LDAP authentication failed. When
removed the problem returned.
So after discussion at our staff meeting it seems to me that if I put an entry
in /etc/hosts for the hipersocket address of the z/OS system where DNS
runs, point the LDAP services HOSTentry to that name, LDAP will resolve the
name of, lets say 'zos.hipersocket.dns' to an IP address. Whether or not
then, the service is there, I will either authenticate against z/OS RACFLDAP or
I will authenticate locally but I will not be stuck in DNS resolution
limbo until the linux logon time out is reached.
Does that make sense?
-J
Adam Thornton <[EMAIL PROTECTED]>
Sent by: Linux on 390 Port
<[email protected]>
To
[email protected]
cc
04/24/2007 02:01 PM
Subject
Re: DNS
and Disaster Recovery
Please respond to
Linux on 390 Port <[email protected]>
On Apr 24, 2007, at 1:52 PM, James Melin wrote:
> That would work, provided I could log on to the linux guest in
> order to change the /etc/hosts file in the first place, which I was
> not able to do on
> one of the guests because the authentication was NOT dropping
> through to local authentication after the timeout. I think the
> logon timed out before
> the LDAP call failed, actually. I was able to mount the root dir on
> a guest that did work and change it so that we had function. Trying
> to get away
> from the very real possibility of having IPL'ed sucessfully but
> being unable to log on because DNS and LDAP are both unavailable.
This is among the reasons that you always, *always* should have a
local user that is either privileged or that can get a privileged
shell when all network connections are inoperative, which means local
authentication is sufficient for that user and for its privilege
escalation.
This becomes merely very convenient rather than utterly necessary in
a virtual environment where you can attach the disks to something
else (you can do this with SAN rather easily, of course; doing it by
physically transplanting an internal disk is no fun at all, although
I've had to do it before).
Adam
----------------------------------------------------------------------
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
----------------------------------------------------------------------
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
