The following is logging messages from NIS client machine when I log into this machine with a normal NIS account. Thanks.
Aug 27 14:18:57 rzhoux-dev03 sshd(pam_unix)[881]: check pass; user unknown -----Original Message----- From: Rick Warner [mailto:[EMAIL PROTECTED] Sent: 2003?8?28? 2:25 To: [EMAIL PROTECTED] Cc: jurvis lasalle Subject: Re: NIS client couldn't log in On Wed, 2003-08-27 at 11:08, jurvis lasalle wrote: > sorry for the delay- i'm moving this week and things are a little > hectic. i'll try to be as brief as possible (hah!)- > i have been configuring a kickstart installation for a college CS lab. > my configuration installs a base rh9 development environment with nis > authentication. i decided to test whether i had really seen the > behavior i described in that post and just what role iptables played in > that debacle. my kickstart file is posted on the web here, > http://turing.bard.edu/~lasalle/nisprobs/ks.cfg . i booted two > computers from disc and had one load a copy of the file with the > firewall disabled and one with the firewall line that Jason Dixon > suggested last week (otherwise the systems are completely identical- > can you tell i was an experimental physicist before i got into > systems?). As usual, i can authenticate via nis on the machine without > a firewall but not the one with it. > I ssh'd in as root on the firewalled system and grabbed an informative > screenshot posted here, > http://turing.bard.edu/~lasalle/nisprobs/ypprobs.jpg . I'd like to > note that my suspicion of broadcast mode was a red herring. i was able > to use ypcat even without starting ypbind in broadcast mode. Yet > despite ypcat being able to query the server, I cannot authenticate via > nis. Note in the screenshot how long ypwhich took to execute (can you > explain the error it produced). the screenshot is continued here > http://turing.bard.edu/~lasalle/nisprobs/ypdebug.jpg where i start > ypbind in debug mode for you. > so i emphasize that I don't know what is wrong, but that stopping > iptables is a solution. if you'd like to look, my iptables rules are > here, http://turing.bard.edu/~lasalle/nisprobs/iptables.txt . i hope > this was informative. if you need any further info, just ask. > Again, I suspect that *iptables* is your red herring and not broadcast mode. If you really wanted to be experimental you would try starting ypbind with the debug flag and then look at the logs to see where it is hanging up. Your screenshot really tells us very little; the only real information is that ypwhich takes a long time, then succeeds, but gives zero insight into the source of the problem. Much more informative, to you and anyone else, would be to run strace ypwhich and look to see which system call it is spending all its time waiting to complete; I strongly suspect your culprit is in the name resolution and not at all with NIS stuff. When you do the strace you will find that a lot of what transpires is an attempt to resolve the IP information back to a name. Please do an experiment that can show the nature and source; you experiment presumed that iptables was the source and you followed only that lead; go deeper. - rick -- redhat-list mailing list unsubscribe mailto:[EMAIL PROTECTED] https://www.redhat.com/mailman/listinfo/redhat-list -- redhat-list mailing list unsubscribe mailto:[EMAIL PROTECTED] https://www.redhat.com/mailman/listinfo/redhat-list
