On Tuesday, Aug 26, 2003, at 16:55 America/New_York, Rick Warner wrote:
On Tue, 2003-08-26 at 13:17, jurvis lasalle wrote:
Sorry, I failed to post the resolution to my problem. Once I turned
off iptables, the client bound to the server and all the yptools worked
as usual. As I stated in the post at the time, I was (and still am)
very perplexed by ypcat working without being able to authenticate as
any nis-user. I didn't pursue the matter any further though once I
turned off iptables (you know how it is when the resolution to a
mystery you never understood in the first place comes along). So
sorry- no elucidation here.
Do you really think that such a situation is impossible? The settings
were a default red hat 9 install with firewall on medium and holes for
dhcp and ssh, and ypbind in broadcast mode (ypcat and ypwhich would not
work at all if i specified the server). I don't know much about the
underlying system calls you mention, i'm just relaying my own
(documented) observations. hope someone can make sense of this...
Jurvis,
Perplexing. I still do not see a mechanism for any iptables interference, and am very skeptical. Further, ypbind uses the same mechanism for binding when using broadcast and directed server mode; in fact it is more common for failure to happen with broadcast mode due to problems like routers/switches blocking broadcast messages, etc. What I truly suspect happened is that you had an ancillary network issue that was preventing ypbind from locating the server and that was iptables related. I would bet that if you fixed that issue that ypbind would then work fine with a specified server. The only real difference in broadcast mode and where a specified server is set is how ypbind locates the server, and if a server is specified then there is a name resolution component! The binding is essentially the same mechanism either way. So, color me skeptical that there is a yp related iptables issue, but I do think you might have had an iptables issue related to some other network component that ypbind might have used in non-broadcast mode. Of course, the best way to discern what is happening is to run ypbind with the debug flag and then browse the debug file for info; a significant portion of the ypbind source code is for debug/logging so might as well put that to use :-)
- rick
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.
thanks, jurvis
-- redhat-list mailing list unsubscribe mailto:[EMAIL PROTECTED] https://www.redhat.com/mailman/listinfo/redhat-list
