Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Linux NIS client to Solaris server issue 1

Status
Not open for further replies.

InigoMontoya

IS-IT--Management
Jun 18, 2003
51
0
0
US
I'm about ready to pull my hair out! I have a SUsE 9.2 on an AMD Opteron w2100z. It's the first machine in its subnet that will be a NIS Client to a Sun NIS master on another subnet. I am able to bind to the domain. ypwhich returns the right server but when i do any ypcat command i receive no such map in server's domain.

I found a posting by another admin online that resolved the issue by adding the new subnet to the /var/yp/securenets file and doing a ypstop/ypstart.

I modified the file as recommended and restart NIS but the issue remains. I still get the same message with ypcat. Does anyone have a suggestion on what I can do next? I'm out of ideas. Thanks.

-ryan
 
See if this leads you anywhere;
I will keep looking;


no such map in server's domain

A user or an application tried to look up something using Network Information Services (NIS), but NIS has no corresponding database for this request.

Make sure the NIS map name is spelled correctly. To see a list of nicknames for the various NIS maps, run the ypcat -x command. To see a full list of the various NIS maps (databases), run the ypwhich -m command. If the NIS service were not running on the current machine, these commands would result in a "can't communicate with ypbind" message.


CA
 
More info;

4.6: ypcat Problems

Q: How come I can't ypcat a map that I know exists in NIS?

A1: You might have this problem when you try and look at a map in NIS, as follows: # ypcat netmasks no such map in server's domain This occurs because NIS maps actually have unique names that are dependent upon how the map is indexed. Certain NIS maps (ethers, group, hosts, aliases, passwd, protocols, services) have standard nicknames, to make them easier to access. Run ypcat -x to see the list of aliases: # ypcat -x Use "passwd" for map "passwd.byname" ... You can access maps without aliases by using the real name. For example, the real name for the netmasks map is netmasks.byaddr: # ypcat netmasks.byaddr If you cd into /var/yp/`domainname` on your master server, you will see the complete list of actual NIS map names. Ignore the .dir and .pag suffixes.

A2: It may also be that the server you are bound to does not have that map on it. Do a ypwhich to find out what machine you are bound to. If for example, you are bound to a slave server and you cannot ypcat aliases you should check on both that slave server and the master server in the /var/yp/'domainname' directory for the existence of files called mail.aliases.dir and .pag Chances are your master has that map while the slave does not. Follow the procedure listed in the first question in section 4.3 for how to remedy this situation.


Section 4.3

Q: Why does yppush refuse to transfer my brand new map when I do a make? -or-

Q: Why do I get the following message when doing a make: "Can't bind master to send ypclear message to ypserv for map mail.aliases." { See also the next question for another possible answer to this error. } There are two solutions to this problem. If you are running a mix of operating systems on your network (Solaris, IRIX, HPUX) you should probably consider the second solution since the maps should be built by the slave servers themselves as the dbm format may be different on different OS'es.

A1: ypxfr is confused, because copies of the new map do not exist on one of your NIS slaves. You must manually copy the maps. This can be done by copying /var/yp/`domainname`/map.* from the master to /var/yp/`domainname` on each of the slaves, using either rcp or ftp.

A2: First make the map on your master without pushing it to the slaves since it is the push (and thus the resulting ypxfr) to hang: # cd /var/yp # make -DNOPUSH mapname.byname mapname.bynumber Now, on each slave server, transfer the map over from your master server: # cd /var/yp # ypxfr -h NIS-master mapname.byname


CA



 
Last thing and I will wait for a response good or bad.

3.6: How to Run NIS from a Remote Subnet?
-----------------------------------------

By default, you can not run a NIS client if your NIS server is on a
different subnet. This is because NIS usually runs in broadcast mode,
which means that it only queries local servers when starting.

In Solaris, if you want to bind to a remote server, simply initialize
the client with the -c flag:

% ypinit -c


Thanks CA
 
4.3: I still have the same issue. I've checked out the map names and made sure they are the same. I checked on the NIS master (which is the server my machine is bound to) and copied and did a ypcat on my machine for it and i still get the same message.

3.6: I'm not using broadcast mode. I've specified the NIS server to bind which happens to be the master server. I am able to bind to it fine. I'm just not able to pull any maps from it. (ypcat).
 
I get the following when doing a ypwhich -m:

Can't find master for map mounts.byname. Reason: No such map in server's domain
Can't find master for map ypservers. Reason: No such map in server's domain
Can't find master for map ipnodes.byaddr. Reason: No such map in server's domain
Can't find master for map ipnodes.byname. Reason: No such map in server's domain
Can't find master for map mail.byaddr. Reason: No such map in server's domain
Can't find master for map auto.direct. Reason: No such map in server's domain
...etc...

ypwhich returns...
<mynis.server.com>
 
The only thing I can think of is Solaris NIS doesn't support NIS accross subnets w/out a slave server on subnets other than the one the master server occupies.
 
Inigo...
If you are running Solaris 8 or newer, NIS will run across subnets. I am doing it on several workstations.

Just a side line, are you sure your NIS Server is not running NIS+. I ask that because of the response of ypwhich. The .com response is typical of a NIS+ set up.
 
the NIS master is running on 5.8 and yes, i am certain it is a nis domain not nis+.
 
Is your client's domain the same as the NIS Master?
 
yes...domainname returns the right NIS domain name. The client binds to the domain just fine. I'm thinking I'll just set it as a slave server and hope it'll get the maps.
 
What about /var/yp/nicknames, how do you have that configured.

Adding the nicknames

In order for NIS to find all of the maps, you must supply "nicknames" for the maps to the NIS server. The nicknames as defined in /var/yp/nicknames.

You should add the following nicknames to your nicknames file:
timezone timezone.byname
netmasks netmasks.byaddr
locale locale.byname

Amongst other things, this will allow you to run command like "ypcat timezone" to verify the the timezone map is correct.


CA
 
I know you can run NIS across subnets since I do that here. Is your /var/yp/securenets file in a similar format?:
Code:
255.0.0.0 10.0.0.0

You said it was able to bind, so I am assuming you have done this but is the NIS server in the local /etc/hosts file? I would also try running the full syntax of the ypcat command, no just ypcat passwd. See if that works

ypcat -d nis.your.domain.name passwd
 
My /var/yp/nicknames file has entries which I have checked against the master server's. They are there and spelling matches.
 
Man ya have really run into it!!

So The server has been up and running for a while?
Clients on the same subnet have no problem running ypcat commands?
Are there Linux boxes on the same subnet as server and do they ypcat fine?

Have you tried setting up another system on the same subnet as the linux box that does not work?

CA

 
coffeysm,

yes the entry in the securenets file follows that format. In fact there is already an entry in there for the subnet the Master server runs on. I simply followed that. I also made sure that the subnetmask is accurate.

The NIS server is in the /etc/hosts file of the client machine.

I tried the full syntax of the command and it gave me the same message.
 
Inigo,
My next step would be to run snoop on the client and run one of the ypcat commands: "ypcat hosts | grep <client name>" to see what type of error message the NIS server is sending back. It may lead you toward the problem. This is starting to look like some type of permission problem.
 
cndcadams,

yes, yes, yes and no...this is the first nis client on this subnet. I guess I can try that but I think it's highly unlikely that it's hardware related.
 
I agree, I also do not think it is hardware related. Sometimes when installing software applications I have made mistakes in configuration setups causing me a big headache. I find it helpful to install another system to see if I made a mistake in setup or there is actually a problem which spans across systems. This procedure has eliminated my frustrations before.

Are you able to telnet into the server from your linux box?
Not sure if this is relevant but I am just wondering.

CA
 
cndcadams,

You're right it could be some configuration that affects NIS somehow. I can test on another box later today or monday next week.

But...to answer your question I am unable to telnet because we've disabled this on all machines. I am able to ssh in just fine.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top