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
