This is Red Hat 6.2 with ypserv-1.3.11-2

The problem is not NFS or the automounter. That all works fine. The
problem is that when we start the Linux NIS server, and then start the SCO
or Solaris NIS clients, they both get NIS timeouts. When we make the
Solaris platform be the server, then SCO is perfectly happy.

If anyone has Linux serving a SCO client, I'd love to hear about it.

TIA

-- 
-Time flies like the wind. Fruit flies like a banana. [EMAIL PROTECTED]
-Stranger things have happened but none stranger than this. Steven W. Orr-
Does your driver's license say Organ Donor?Black holes are where God \
-------divided by zero. Listen to me! We are all individuals!---------

On Tue, 13 Jun 2000, Pete Peterson wrote:

=>
=>
=>
=>> From: "Steven W. Orr" <[EMAIL PROTECTED]>
=>> To: Cartman List <[EMAIL PROTECTED]>,
=>>         Hedwig List <[EMAIL PROTECTED]>,
=>>         redhat-list <[EMAIL PROTECTED]>,
=>>         Greater New Hampshire Linux User Group <[EMAIL PROTECTED]>
=>> Subject: Problems with NIS Linux server and either Solaris or SCO as client.
=>> 
=>> 
=>> Both SCO and Solaris would not talk to the Linux platform when I made it a
=>> NIS server. When I made the Solaris platform the server, the SCO box
=>> talked nicely with the Solaris server.
=>
=>What Linux release are you running and what set up have you done?
=>     Do you have a /etc/exports with appropriate entries?
=>     Have you started nfsd and nfslock, either manually or automagically?
=>          /etc/rc.d/init.d/nfs start
=>          /etc/rc.d/init.d/nfslock start
=>          (or corresponding entries in /etc/rc*.d)
=>     You should see something like:
=>         [root@redhat60 init.d]# ps axww|grep nfs
=>         7434 ?        S      0:00 rpc.mountd --no-nfs-version 3
=>         7445 pts/0    SW     0:00 [nfsd]
=>         7446 pts/0    SW     0:00 [nfsd]
=>         7447 pts/0    SW     0:00 [nfsd]
=>         7448 pts/0    SW     0:00 [nfsd]
=>         7449 pts/0    SW     0:00 [nfsd]
=>         7450 pts/0    SW     0:00 [nfsd]
=>         7451 pts/0    SW     0:00 [nfsd]
=>         7452 pts/0    SW     0:00 [nfsd]
=>         7489 pts/0    S      0:00 grep nfs
=>
=>     What does "exportfs -v" show?
=>        [root@redhat60 init.d]# exportfs -v
=>        /usr/local      <world>(ro,async,wdelay,root_squash)
=>        /mnt/cdrom      <world>(ro,async,wdelay,root_squash)
=>        /mnt/cdrom      ns2.genrad.com(ro,async,wdelay,root_squash)
=>        /usr/local      ultra9.genrad.com(ro,async,wdelay,root_squash)
=>
=>
=>Thankfully I no longer have any contact with SCO, so I can't comment on
=>that one.  The general rule I used to follow, which was valid 99% of the
=>time, is that in any conflict between SCO and anything else, the problem was
=>with SCO.  I used to build programs for about 8 different platforms and SCO
=>was by far the most troublesome.
=>
=>My Solaris 2.6 box, that I'm sitting at, mounts NFS file systems on
=>both RedHat 6.1 and Redhat 6.2 boxen with no problems.  It does complain,
=>but still works, if you don't start the lock daemon.
=>
=>
=>> Does anyone have any clue what's going on here? I have noticed that
=>> this problem has been raised before, but I haven't heard of anyone
=>> solving it. 
=>
=>I don't know where this rumor came from, but I've never seen a problem.
=>A friend of mine had his boss tell him some story like that, claiming
=>that NFS server didn't work on RedHat 6.x boxen (his boss was a Micro$oft
=>FUD brainwashed drone).  It took us all of 5 minutes to prove him wrong.
=>
=>> I *really* need this.
=>
=>It should be easy!  Really!  :-)
=>
=>
=>        pete peterson
=>        GenRad, Inc.
=>        7 Technology Park Drive
=>        Westford, MA 01886-0033
=>
=>        [EMAIL PROTECTED] or [EMAIL PROTECTED]
=>        +1-978-589-7478 (GenRad);  +1-978-256-5829 (Home: Chelmsford, MA)
=>        +1-978-589-2088 (Closest FAX); +1-978-589-7007 (Main GenRad FAX)
=> 
=>


**********************************************************
To unsubscribe from this list, send mail to
[EMAIL PROTECTED] with the following text in the
*body* (*not* the subject line) of the letter:
unsubscribe gnhlug
**********************************************************

Reply via email to