Very Computer

Hi all
   I am new to NIS world and I am trying to connect a NIS client (RH
8.0) to a Solaris 2.8 NIS server and having mount and NIS login
problems.

   I am following Linux documentation project NIS How-to and
http://www.siliconvalleyccie.com/linux-adv/nis.htm.

   I have done the following:
   a. Set up NIS server to recognize the linux IP and hostname. (done
by someone else).  NIS server runs in NIS (YP) mode.
   b. Changed nsswitch.conf
      passwd:     compat files nis
      shadow:     compat files nis
      group:      compat files nis

      hosts:      nis files dns
   c. changed resolv.conf to add domain and nameserver IP address
      Able to ping NIS server by DNS name.
   d. modified /etc/auto.master and /etc/auto.nfs
   e. Ran authconfig - /etc/sysconfig/network looks fine
   f. /etc/hosts.conf - order hosts,bind,nis
   g. /etc/hosts - Added DNS-IP address of the NIS server and the
linux host
   h. Changed /etc/passwd and /etc/group and /etc/shadow
   i. Started NIS related client daemons. Ran chkconfig to save.

   Now, after reboot, login and mounts does not work.

   1. ypwhich shows the NIS server's DNS name (fully-qualified)
   2. ypcat passwd shows error
      No such map passwd.byname. Reason: Can't bind to server which
serves this domain
   3. rpcinfo -p localhost outputs:
    program vers proto   port
    100000    2   tcp    111  portmapper
    100000    2   udp    111  portmapper
    100024    1   udp  32768  status
    100024    1   tcp  32768  status
    100007    2   udp    914  ypbind
    100007    1   udp    914  ypbind
    100007    2   tcp    917  ypbind
    100007    1   tcp    917  ypbind
    391002    2   tcp  32769  sgi_fam
    100009    1   udp   1020  yppasswdd

Any help is deeply appreciated
Thanks
Sri

Who told you to do that? All of the examples I've ever seen say to use
just compat, and that's what I use with SuSE Linux (currently 9.1), i.e.:

passwd:     compat
shadow:     compat
group:      compat

Quote:>       hosts:      nis files dns

That seems to be the way to set it up on Linux, or you might want to put
dns after nis and before files (for consistency with Solaris?). On Solaris
I don't have dns in the hosts list, but I can resolve internet host names.
I think there is a subtle difference in the lookup of host names between
Linux and Solaris? I believe Solaris automagically "falls back" to using
DNS if the nis lookup does not work? Linux does not seem to do so? In any
case, I've found that I need to have dns in hosts list on the Linux side.

Also, I have found (but not tracked down) that if one of my Solaris
machines refers to ypserv from a Linux machine (i.e. ypwhich gives a
Linux machine name), then it cannot resolve DNS names. I have not tracked
that problem down. Instead, I have made sure to refer to Solaris ypserv.

BTW, have a look at the /etc/nsswitch.* files on a Solaris system. There
are several templates there, for: files, nis, dns, ldap, nisplus.

Quote:> 1. ypwhich shows the NIS server's DNS name (fully-qualified)
> 2. ypcat passwd shows error
>      No such map passwd.byname. Reason: Can't bind to server which
>      serves this domain

This looks strange. The ypwhich should show the server, and then ypcat
should get the map from that server. Did the other person rebuild the
updated maps on the master server? Did he push them out to all server(s)?
Have a look at:

        ypwhich -m

Which will list all the maps and their master server(s).
Is passwd.byname in there? If not, why not? Fix it.

BTW, does your hosts map give both FQDN and hostname for each machine?
Try doing a:

        ypcat -h <hostname> <map>

Try different values in <hostname> (FQDN, hostname, IP address). All of
those variants should work. If not, fix it/them.

--
Juhan Leemet
Logicognosis, Inc.

Hi Juhan
   Thank you very much for your reply.  I have tried out all the
changes and commands and still, there seems to be some issue. I am
suspecting the server side settings.  If you have any other comments,
pl. let me know.

   a. Changed nsswitch.conf to only compat..values
   b. Changed nsswitch.conf for hosts values.

=====
passwd:     compat
shadow:     compat
group:      compat

#hosts:     db files nisplus nis dns
hosts:      nis dns files

=====
Here are the outputs:

/var/log/messages output

Sep  2 09:59:56 spock ypbind: Setting NIS domain name <domain>:
succeeded
Sep  2 09:59:56 spock ypbind: ypbind startup succeeded
Sep  2 09:59:57 spock ypbind: bound to NIS server odin.<domain>
Sep  2 09:59:57 spock autofs: automount startup succeeded
Sep  2 09:59:57 spock automount[798]: starting automounter version
3.1.7, path = /fs, maptype = file, mapname = /etc/auto.nfs

Sep  2 10:00:02 spock yppasswdd: rpc.yppasswdd startup succeeded
Sep  2 10:02:46 spock login(pam_unix)[1115]: check pass; user unknown
Sep  2 10:02:46 spock login(pam_unix)[1115]: authentication failure;
logname= uid=0 euid=0 tty=pts/0 ruser= rhost=cherry.<domain>

Sep  2 10:02:49 spock login[1115]: FAILED LOGIN 1 FROM cherry.<domain>
FOR <login>, Authentication failure
Sep  2 10:02:52 spock login(pam_unix)[1115]: session opened for user
<another_login> by (uid=0)
Sep  2 10:02:52 spock  -- [1115]: LOGIN ON pts/0 BY <another_login>
FROM cherry.<domain>

[]$ ypwhich
<server>.<domain>

[]$ ypwhich -m
Can't get map list for domain <domain>. Reason: Can't bind to server
which serves this domain

[]$ ypcat -h <ipaddr> passwd
No such map passwd.byname. Reason: Can't bind to server which serves
this domain

Thanks in advance
Sri

Don't know about the others, but with Linux clients we always had to use

passwd:         files nis
group:          files nis
shadow:         files

hosts:          files dns
networks:       files

protocols:      db files
services:       db files
ethers:         db files
rpc:            db files

netgroup:       nis

automount:      files nis

compat has never worked for us.

Dragan

--
Dragan Cvetkovic,

To be or not to be is true. G. Boole      No it isn't.  L. E. J. Brouwer

!!! Sender/From address is bogus. Use reply-to one !!!

Exceedingly strange! I don't think I've ever seen that kind of thing
before (but that may not mean much). How did ypwhich get setup with
<server>.<domain> if ypbind cannot bind to the server that serves your
domain? Hmm...

Does your default domain in /etc/defaultdomain correspond to the domain
that you have used in /etc/resolv.conf? Can you ping the <server>.<domain>
from your client (you probably can... clutching at straws...). There must
be something funky with your domain specification or routing?

Maybe try starting up ypbind manually with the debug switch (on Linux),
and see what it reports in your session. You should get some error
messages there, and hopefully something informative. Maybe try broadcast
while testing, to see if that finds a good NIS server?

OTOH, maybe the NIS maps have not been built right? Can you bind to that
NIS server from any other machine? from any Sun Solaris machine? you
should be able to test NIS lookups on the server itself (also a client).
On the NIS server you can ypbind either to <server>.<domain> or localhost.

Anyone else have any ideas?

--
Juhan Leemet
Logicognosis, Inc.

Quote:> OTOH, maybe the NIS maps have not been built right? Can you bind to that
> NIS server from any other machine? from any Sun Solaris machine? you
> should be able to test NIS lookups on the server itself (also a client).
> On the NIS server you can ypbind either to <server>.<domain> or localhost.

> Anyone else have any ideas?

Maybe.  I've had a similar problem when trying to integrate a NIS master
  (Solaris9) and a NIS slave (IRIX 6.5.22f).  What was screwing me is
that IRIX uses a master daemon, nsd, and it was caching the data from
previous sessions, which were "growing pains".  By manually flushing the
nsd cache, everything started working like a charm between IRIX and Solaris.

What I'm getting to is, does RH 8.0 have a similar network master daemon
whose cache needs flushed?  I don't remember any more.

Hi Juhan and others
   Thanks for all your suggestions.  I have done all the required
changes and still I seem to have some issues.  The next item on my
checklist is the server configurations.  But, here are the details of
what I have tried.

Stopped ypbind

[]# ps -ef |grep ypbind

[]# ypbind -debug
parsing config file
Trying entry: domain <domain>.com server odin
parsed domain '<domain>' server 'odin'
add_server() domain: <domain>, host: odin, slot: 0
[Welcome to ypbind-mt, version 1.11]

ping host 'odin', domain '<domain>'
Answer for domain '<domain>' from server 'odin'

Pinging all active server.
Server 'odin' for domain '<domain>' doesn't answer.
ping host 'odin', domain '<domain>'
Answer for domain '<domain>' from server 'odin'

Signal (2) for quitting program arrived.

[]# ypbind -broadcast -debug
add_server() domain: <domain>, broadcast
[Welcome to ypbind-mt, version 1.11]

do_broadcast() for domain '<domain>' is called

ypbindproc_domain_2_svc (<domain>)
Status: YPBIND_FAIL_VAL
ypbindproc_domain_2_svc (<domain>)
Status: YPBIND_FAIL_VAL
broadcast: RPC: Timed out.
leave do_broadcast() for domain '<domain>'

[]# ypbind -c
Trying entry: domain <domain> server odin
Config file /etc/yp.conf is ok.
[]#

[]# cat /etc/rndc.conf

/* $Id: rndc.conf,v 1.7 2001/01/09 21:40:45 bwelling Exp $ */

/*
 * Sample rndc configuration file.
 */

options {
        default-server  localhost;
        default-key     "rndckey";

Quote:};

server localhost {
        key     "rndckey";

Quote:};

key "rndckey" {
        algorithm       hmac-md5;
        secret "xdrXBlDGbQoYsCbTs7n20hDiionbWhDy0SetE3g5Iyk3eFflkEAiHOOHEjVF";

Quote:};

-Stopped and restarted service named

[]# service named status
number of zones: 4
debug level: 0
xfers running: 0
xfers deferred: 0
soa queries in progress: 0
query logging is OFF
server is up and running
[]#

My concern is about the rndc.conf file contents. Please comment.

Thanks
Sri

Hmm, SuSE Linux and Solaris have nscd running locally in each workstation
or server. It does local cache'ing of name lookups. I do remember having
to clear the local cache when rehosting my Solaris NIS master and
slave(s). I don't remember needing to do that for client Linux machines,
but didn't really do any serious tests. It just worked for me. Good
suggestion though, I had forgotten about the name cache(s).

--
Juhan Leemet
Logicognosis, Inc.

[snippage]

The message about your server not answering is not a good sign. Fix it.

Quote:> My concern is about the rndc.conf file contents. Please comment.

I had to look up what that was. Never dealt with it (explicitly). The
Linux docs mention that is a "bind" (i.e. DNS) thing. That should not have
anything to do with NIS. I would recommend that you think of resolving
local NIS references first (by preference) and then fall back to remote
DNS references. I would expect that in most networks local addresses need
looking up more frequently and faster than remote addresses. Why do you
think this file is giving you problems? Maybe back off and simplify your
setup, and get a smaller subset to work first, then build it up?

NIS is a pretty simple thing. It should not give you so much trouble.

If your environment is complicated because it is not all within your
control, then maybe try setting up your own small LAN with just a client
and server, and get NIS to work. Then connect to your LAN, and get NIS and
DNS to work together. Then (with experience) approach your problem again?

--
Juhan Leemet
Logicognosis, Inc.