NIS problem
in [RedHat]
|
Prev: Firefox can't browse, but lynx can
Next: NIS problem
From: Art Werschulz on 30 Mar 2007 08:48 Hi. Running Fedora Core 6 on an Intel x86 platform ... The hard drive on our NIS master server just died. We are in the process of rebuilding the server. (We have no slave servers.) On the NIS master server, I did /usr/lib/yp/ypinit -m I took the default action of only using the hostname of our one NIS server. I then did service ypbind start service ypxfrd start (The latter was to play it safe; we haven't used it before.) The output of "rpcinfo -p localhost" is program vers proto port 100000 2 tcp 111 portmapper 100000 2 udp 111 portmapper 100024 1 udp 654 status 100024 1 tcp 657 status 100009 1 udp 969 yppasswdd 100021 1 tcp 44909 nlockmgr 100021 3 tcp 44909 nlockmgr 100021 4 tcp 44909 nlockmgr 100007 2 udp 639 ypbind 100007 1 udp 639 ypbind 100007 2 tcp 642 ypbind 100007 1 tcp 642 ypbind 600100069 1 udp 688 fypxfrd 600100069 1 tcp 690 fypxfrd 100004 2 udp 983 ypserv 100004 1 udp 983 ypserv 100004 2 tcp 986 ypserv 100004 1 tcp 986 ypserv This looks pretty good. Moreover, on the master server, the commands ypwhich ypmatch joeuser passwd getent joeuser passwd give the expected results. I then go over to an NIS client. (Please note that nothing evil has happened to the client.) The command service ypbind start gives me Turning on allow_ypbind SELinux boolean Binding to the NIS domain: [ OK ] Listening for an NIS domain server.................... Turning off allow_ypbind SELinux boolean [FAILED] Note that the client *can* ping the server. What have I forgotten to do? Many thanks! -- Art Werschulz (agw STRUDEL comcast.net) 207 Stoughton Ave Cranford NJ 07016 (908) 272-1146
From: Phil Sherman on 30 Mar 2007 10:18 Did you verify that the server's firewall allows the traffic from the clients? A quick check is to temporarily (long enough to run the test) disable the server's firewall and see if the clients can properly connect. I don't use NIS but a check of my /etc/services file doesn't show any reserved ports for ypbind and ypserv. If these are being dynamically set at startup, you'll have to allow all traffic from your internal network through the firewall or use monitoring software to locate and open the appropriate ports. Phil Sherman Art Werschulz wrote: > Hi. > > I am sorry to repost this. However, I have been told that > comp.os.linux.misc is a quasi-bogus newsgroup. Since I had directed > all responses to comp.os.linux.misc, I'm afraid that any responses > will simply go into /dev/null. > > Running Fedora Core 6 on an Intel x86 platform ... > > The hard drive on our NIS master server just died. We are in the > process of rebuilding the server. (We have no slave servers.) > > On the NIS master server, I did > /usr/lib/yp/ypinit -m > I took the default action of only using the hostname of our one NIS > server. I then did > service ypbind start > service ypxfrd start > (The latter was to play it safe; we haven't used it before.) > The output of "rpcinfo -p localhost" is > program vers proto port > 100000 2 tcp 111 portmapper > 100000 2 udp 111 portmapper > 100024 1 udp 654 status > 100024 1 tcp 657 status > 100009 1 udp 969 yppasswdd > 100021 1 tcp 44909 nlockmgr > 100021 3 tcp 44909 nlockmgr > 100021 4 tcp 44909 nlockmgr > 100007 2 udp 639 ypbind > 100007 1 udp 639 ypbind > 100007 2 tcp 642 ypbind > 100007 1 tcp 642 ypbind > 600100069 1 udp 688 fypxfrd > 600100069 1 tcp 690 fypxfrd > 100004 2 udp 983 ypserv > 100004 1 udp 983 ypserv > 100004 2 tcp 986 ypserv > 100004 1 tcp 986 ypserv > This looks pretty good. Moreover, on the master server, the commands > ypwhich > ypmatch joeuser passwd > getent joeuser passwd > give the expected results. > > I then go over to an NIS client. (Please note that nothing evil has > happened to the client.) The command > service ypbind start > gives me > Turning on allow_ypbind SELinux boolean > Binding to the NIS domain: [ OK ] > Listening for an NIS domain server.................... > Turning off allow_ypbind SELinux boolean > [FAILED] > > Note that the client *can* ping the server. > > What have I forgotten to do? > > Many thanks! >
From: Moe Trin on 30 Mar 2007 16:11 On 30 Mar 2007, in the Usenet newsgroup alt.os.linux.redhat, in article <m27isyzwzj.fsf(a)Machshevet-Werschulz-2.local>, Art Werschulz wrote: >I am sorry to repost this. However, I have been told that >comp.os.linux.misc is a quasi-bogus newsgroup. Since I had directed >all responses to comp.os.linux.misc, I'm afraid that any responses >will simply go into /dev/null. On the 15th of each month, there is a posting to the newsgroups news.announce.newgroups, news.groups, and news.lists.misc with the subject "List of Big Eight Newsgroups" - so it's ignoring 'alt.*'. Doing a search for the word linux - you'd find: [compton ~]$ zgrep linux ../big.8.list.03.15.07.gz | cut -f1 | column comp.os.linux.advocacy comp.os.linux.misc comp.os.linux.alpha comp.os.linux.networking comp.os.linux.announce comp.os.linux.portable comp.os.linux.answers comp.os.linux.powerpc comp.os.linux.development.apps comp.os.linux.security comp.os.linux.development.system comp.os.linux.setup comp.os.linux.embedded comp.os.linux.x comp.os.linux.hardware comp.os.linux.xbox comp.os.linux.m68k [compton ~]$ zgrep comp.os.linux.misc ../big.8.list.03.15.07.gz comp.os.linux.misc Linux-specific topics not covered by other groups. [compton ~]$ Lo - comp.os.linux.misc is there and sorta on-topic, while the other three groups you posted to are the bogus ones. Unfortunately, the big-eight list doesn't have a newsgroup for NIS, and neither does the comcast news server. >The hard drive on our NIS master server just died. We are in the >process of rebuilding the server. (We have no slave servers.) Bad doggy! Bad doggy. No biscuit! And no backups either. >On the NIS master server, I did OK... but what does 'netstat -anup' show? Are you listening on an external interface (no firewall)? >Moreover, on the master server, the commands > ypwhich > ypmatch joeuser passwd > getent joeuser passwd >give the expected results. OK - server is at least running and listening on the loopback. >I then go over to an NIS client. (Please note that nothing evil has >happened to the client.) The command > service ypbind start >gives me > Turning on allow_ypbind SELinux boolean > Binding to the NIS domain: [ OK ] > Listening for an NIS domain server.................... > Turning off allow_ypbind SELinux boolean > [FAILED] Ah, don't you just love windoze - and windoze wannabe interfaces? So informative - so much useful feedback. >Note that the client *can* ping the server. Yeah, but ping is ICMP - has virtually nothing to do with NIS. >What have I forgotten to do? My guess - firewall setup. You might also use a packet sniffer like tcpdump, ethereal or wireshark to see what the packets are on the wire. Old guy
From: Art Werschulz on 30 Mar 2007 16:45 Hi. ibuprofin(a)painkiller.example.tld (Moe Trin) writes: > >The hard drive on our NIS master server just died. We are in the > >process of rebuilding the server. (We have no slave servers.) > > Bad doggy! Bad doggy. No biscuit! And no backups either. We had a backup. But it wasn't as recent as I would've liked. > My guess - firewall setup. That was it. -- Art Werschulz (agw STRUDEL comcast.net) 207 Stoughton Ave Cranford NJ 07016 (908) 272-1146
From: mark south on 17 Apr 2007 14:33
On Fri, 30 Mar 2007 09:23:12 -0400, Art Werschulz wrote: > I have been told that > comp.os.linux.misc is a quasi-bogus newsgroup. It's a real newsgroup, it just suffers from being filled with crossposted garbage from c.o.l.a, which is why everyone else has taken refuge in the alt.os.linux.* hierarchy.... |