The nsswtich.conf file is using default values and I've never tried to do
anything with nis. My understanding of the situation is that the pam modules
are making an ldap call, through local ldap services, which was configured to
go against the dns resolvable name for the z/OS system where we run
RACFLDAP.
I've thought about leaving root logged in at the VM console. That bothers me.
Alot. However, it would have solved the problem by giving access.
I've verified that my supposition was correct. As long as LDAP has a resolved
address, it will fail within the time frame of the logon window if it
cannot reach the service. Whether that is provided by DNS or an entry in
/etc/hosts it is irrelevant. If it has to wait for DNS resolution from two
DNS sources that do not exist, the linux logon times out after 60 seconds.
So, the solution of pointing linux at the RACFLDAP server on the z/OS image via
that image's hipersocket via the /etc/hosts file will work. I
understand of course, that this is only valid within the z/box and is not going
to work for non z/vm linuxen. We will never have another mainframe
with a separate vm image on it, so for now I can live with this.
Marcy Cortes <[EMAIL PROTECTED]>
Sent by: Linux on 390 Port
<[email protected]>
To
[email protected]
cc
04/24/2007 04:19 PM
Subject
Re: DNS
and Disaster Recovery
Please respond to
Linux on 390 Port <[email protected]>
So it sounds like your nsswitch.conf has you authenticated against LDAP
before any files? Could that be what screwed up root at the local
console?
A few weeks back on this list, I asked about the /etc/inittab change to
leave root logged in to the VM console. Perhaps that's something you
should consider doing as well so you always have root if you have VM (we
have PermitRootLogin NO in sshd_config as well).
Marcy Cortes
"This message may contain confidential and/or privileged information.
If you are not the addressee or authorized to receive this for the
addressee, you must not use, copy, disclose, or take any action based on
this message or any information herein. If you have received this
message in error, please advise the sender immediately by reply e-mail
and delete this message. Thank you for your cooperation."
-----Original Message-----
From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of
James Melin
Sent: Tuesday, April 24, 2007 1:14 PM
To: [email protected]
Subject: Re: [LINUX-390] DNS and Disaster Recovery
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
----------------------------------------------------------------------
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
