This is kind of an installation issue, but I think this thread might be the best place.

I did a fresh install on a NIS client, using Slackwre -current (15beta).

After doing some of my re-customizations, I can not log in with a user id. Root logs in fine, but others refuse. If from another machine, I just get connection refused.

tail -f syslog secure and messages does not yield any clues.

ypcat passwd and ypcat hosts seem to work fine.

However make -C /var/yp yields a message "failed to send 'clear' to local ypserv: RPC: Program not registered.

So I have now tried to figure out what that means, and tried several things.

Pn the server, I can see connections to ypserv, with each loging attempt, as would be expected, as well as with each ypcat run.

So I even went to the extreme of entering in the local passwd a new user id, matching one in the yp password, but that does not work.

Any ideas as to where I should be looking? Based upon my searching all day, I think I have covered everything. But there are lots of smarter people out there. Thanks for your thoughts.

The yp server seems to work well for other 14.2 clients. The server and those clients have not be modified.

I have searched for two days, and cannot find a solution to this issue. This system has a fresh slackware -current (15.0beta) install.

But here's where I am at:

-ypcat and similar utilities appear to work

-make -C /var/yp yeilds: failed to send 'clear' to local ypserv: RPC: Program not registered

-As near as I can tell RPC is working, but the traditional portmapper is not there, now rpcbind is in use.

-if I restart rpc, nfsd, and yp, sometimes the errors for make -C /var/yp disappear for a few minutes

-still unable to login on client machine

-existing NIS/yp on 14.2 clients still continue to work.

So I am suspicious that perhaps this is unique to this distribution. While there is some documentation on NIS/yp out there, it is influenced by the specific distro implementation, and I am unable to move forward.

At this moment in time I do not have a configuration which exactly matches your situation. While I have a Slackware64-current install running an NIS server, all the clients (except one) are presently Slackware64 14.2 or Slackware 14.2. The exception is a Slackware64-current from quite some time ago, so it doesn't count. It sounds like your case is the opposite: you have a Slackware64-current NIS client (the newly installed system) connecting to a Slackware64 14.2 NIS server (I think).

When you talk about running ypcat, I assume this is on the NIS client. Generally speaking if ypcat displays the required maps then NIS should work. What does "ypwhich" report on the Slackware64-current client?

You mentioned running "make -C /var/yp". Is this on the (Slackware64-current) NIS client, or your NIS server? Normally one wouldn't run "make" in that directory on a client, so I'm a little confused by this.

The RPC portmapper is now called rpcbind. AFAIK though, the RPC daemons are only required for NFS, so the presence or absence of rpcbind may not be related to the NIS issue. While NFS and NIS both make use of RPC, neither NFS nor NIS are not dependent on the other. This means that RPC (rpcbind in particular) must be running on the client for NIS to function, but NFS is not required.

If NIS is delivering the maps (evidenced by "ypcat passwd" working), then the most likely issue is that the authentication system might not be set up to authenticate via NIS. Slackware64-current ships with the relevant /etc/nsswitch entries set to "compat". Without the associated entries in /etc/passwd, /etc/group and perhaps /etc/shadow, NIS may not be consulted. On my NIS clients I usually set "passwd", "group" and "shadow" to "files nis" in /etc/nsswitch.conf to be explicit. With these settings there is no need for the special entries in /etc/passwd or /etc/group. You may like to try testing with this.

I may be able to offer further suggestions if you can clarify which systems (NIS server or client) you've been running the various test commands on.

As a final comment for now, when I deployed an NIS server on Slackware64-current I discovered that NIS clients (all Slackware64 14.2) using the "-broadcast" option could no longer connect. The broadcast packets were making it to the server according to tcpdump, but the NIS server never acknowledged them. All clients could connect if I gave an explicit server in /etc/yp.conf. Unfortunately I did not have time to debug this further, and in any case having a named server is arguably better anyway. This problem is clearly different to yours because in my case the clients could not successfully run ypcat or even ypwhich. I mention it only in case it helps others who find this thread in the future.

1 members found this post helpful.

jwoithe, thank you for responding.

You correctly understand my configuration in the first paragraph.

I do not remember the results with ypwhich. I ran ypmatch and other variants. I can reinstall the SSD and run ypwhich.

I ran the make -C /var/yp on the client. Perhaps I misunderstood the documentation.

Because of the RPC error code, I chased the rpc configuration. I looked at my 14.2 rc.rpc and the 15.0beta, looking for anything which seemed like it could be an issue. I did find numerous references to nfs being needed for nis. So I figured this was an area to investigate.

/etc/nsswitch was configured to run as distributed, and later I changed it to various forms, ending in my determination of "compat nis" or "compat nis files" with files as it seemed appropriate. Again, I tried several combinations in various parts of the configuration, while exploring for a solution. Normally, I reverted back to the distribution.

jwoithe, the bulk of my configuration changes were limited to the client, and since the server was working with other 14.2 clients, I left it alone, except to monitor log files for clues.

I should mention that at one point, I did add a user for test purposes on the server, and while I could run ypcat passwd on the client, I found that the new user would not propagate to the ypcat password on the client. That concerned me and I refocused on the rpc, assuming that something broken there might be causing that behavior.

Notable that I found that adding a user to the client's passwd file did not enable login to that user, and that I was not getting failed login attempts on the logs of either machine, I am suspicious that for some reason login is not completing it's role, but that was not verified.

I appreciate your response, and with the exception of the make on /var/yp, I think I have covered your suggestions. However experience suggests that there is some small parameter which I have somehow messed up. It would be nice to have a tarball of the relevant files, including /etc/hosts, nsswitch, the rc.* files, and so on. That way I could readily inspect each file at a time.

Another thing I have considered, since I have more SSD drives, is to do a fresh install of 15.0beta, and setup NIS and see if the failure to login is replicated. Given that others like yourself have already confirmed operation with similar configurations, it is perhaps more likely that I made an error at some point during the configuration after the install. I think I may do that, because the elapsed time for a new installation would be far less than I have spent trying to debug things. If the reinstall fails, then I have a more controlled sequence I can share.

Thanks again for your considerate response.

If it's not too much trouble, knowing the output of "ypwhich" on the client may be instructive. It will at least confirm that you are associating with the expected NIS server.

Running "make" in /var/yp is only required on NIS servers, and only when the sources for your maps have changed. It has no purpose on NIS clients, so at this point it's probably safe to discount the "make" failure on the client.

It's interesting that your added user on the server did not appear in the NIS passwd map as viewed on the client. After adding the user on the NIS server, did you remember to run "make" in /var/yp on the NIS *server*? This is required so that any changes to the map source files are propagated into the NIS maps provided by the server. A lack of the "make" is the most obvious explanation for the missing user in this scenario. Either that or the client is binding to some other NIS server that you're not aware of.

Adding a local user only to /etc/passwd may not be sufficient: you probably also need to add relevant details to /etc/shadow too. If this *was* done then perhaps there's a problem with the system authentication system (PAM) - maybe one of its dependencies hasn't been installed, for example. With Slackware64-current, the system requires the cracklib and libpwquality packages which are new additions since Slackware64 14.2. As I understand it though, the lack of these packages would prevent even root from logging in. Since it seems you are able to log in as root, the lack of these packages may not be the problem in your case.

In your first post you mentioned applying some customisations. Do you make any changes to the PAM configuration, or the system authentication setup in general?

NFS is not required for NIS: NIS can function without any NFS volumes being active or mounted. NIS and NFS have historically often been run together, but there is no formal dependency between them. However (to correct something I wrote earlier thanks to a brain fade), both NIS and NFS make use of the RPC system. In a Slackware context, this means that on a client /etc/rc.d/rc.rpc must be made executable and be run (normally as "/etc/rc.d/rc.rpc start") before either NIS or NFS can be started.

Failing all that, your suggestion to try a fresh install of Slackware64-current on another disc may be worthwhile. Do a full install (to make sure you have all the packages) and then do the minimal changes to allow NIS to function as a client. Assuming I haven't overlooked something, this would normally amount to the following:

• Put your NIS domain in /etc/defaultdomain
• Edit /etc/yp.conf to contain a line "domain <NISdomain> server <servername>"
• Edit /etc/nssswitch.conf to make "passwd", "group" and "shadow" use "files nis"
• Make /etc/rc.d/rc.rpc and /etc/rc.d/rc.yp executable
• Run "/etc/rc.d/rc.rpc start" followed by "/etc/rc.d/rc.yp start"
• Test to see which NIS server was bound to: ypwhich
• Test the availability of the passwd map: ypcat passwd
• See if an NIS user is resolved: id <NISusername>

Things may not work if there is an underlying problem, but this would remove many of the variables from the equation and perhaps help identify the cause of your trouble.

1 members found this post helpful.

I will run ypwhich tomorrow and post the results.

I will likely also do a fresh install, and minimally bring up NIS, or attempt to, and take notes as to what I do so that I can readily repeat things. Doing a full install is not a problem.

Shot in the dark here... in /etc/pam.d/system-auth, this line:

password sufficient pam_unix.so nullok sha512 shadow minlen=6 try_first_pass use_authtok

Try adding nis to the end of it.

2 members found this post helpful.

BINGO!!!



Thanks everyone for looking at this, and for those who were able to respond.

2 members found this post helpful.

Based on the OP's confirmation, it seems to me that the change to /etc/pam.d/system-auth ought to be included in the PAM Slackware package, since without it, NIS authentication is not functional. While NIS has its issues, it remains adequate for some use cases and user lookups is perhaps the most common NIS task. The only difficulty would be if inclusion of "nis" in the system-auth file has a negative effect on systems which do not use NIS for authentication. In this case, perhaps a note in /etc/default/yp or /etc/rc.d/rc.yp might be in order, alerting users who make use of NIS for authentication that the system-auth change is required.

2 members found this post helpful.