Potential problem with yp in current?

bender647 · 02-01-2022, 11:05 AM

There seems to be some inconsistency in the YP configuration now (this may not be new, and I never noticed).

The man page for ypbind says it will default to use /etc/yp.conf, and Slackware still ships with an example. I tested with ypbind -d that this is read if no other options are given.

It seems you can also config in /etc/default/yp, and there is a comment in there saying you can override /etc/yp.conf this way.

But in /etc/rc.d/rc.yp, these lines will ignore /etc/yp.conf and do a broadcast even if a server is specified in yp.conf:

Code:

if [ $YP_CLIENT_ENABLE -ne 0 ]; then
    # NIS CLIENT CONFIGURATION:
    # If you are a NIS client, all you need to do is run ypbind.
    # Your NIS server might also be a client.
    if [ -d /var/yp ]; then
      if [ -z "$YPBIND_OPTS" ]; then
        YPBIND_OPTS="-broadcast"
      fi
      echo "Starting NIS services:  /usr/sbin/ypbind $YPBIND_OPTS"
      /usr/sbin/ypbind $YPBIND_OPTS
    fi
  fi

It seems we're missing code that would check if a server is preconfigured in yp.conf.

volkerdi · 02-01-2022, 11:28 AM

What if in /etc/default/yp, you set YPBIND_OPTS=" "?

bender647 · 02-01-2022, 01:02 PM

Using

Code:

YPBIND_OPTS=" "

(a space) works, or more explicitly,

Code:

YPBIND_OPTS="-f /etc/yp.conf"

Also, uncommenting "broadcast" in /etc/yp.conf and removing the if -z YPBIND_OPTS stanza in /etc/rc.d/rc.yp has the effect of defaulting to broadcast unless something, somewhere has been done to override that.

jwoithe · 02-01-2022, 04:21 PM

I agree the behaviour is surprising. Given the current state of comments in the respective files I think it is reasonable for a user to believe that configuring a server in yp.conf would be sufficient. However, as bender647 notes, it is not.

In my personal view, having the rc.yp script assume broadcast in the absence of any content in YPBIND_OPTS is suboptimal. If one wishes to bind to a specific server the only way to do it is to configure this in /etc/yp.conf: there are no command line options for this. It means that for someone who only wants to specify a server name, YPBIND_OPTS would be left empty. Unfortunately this means that rc.yp decides that a broadcast is required.

The link between an empty YPBIND_OPTS and the need for a broadcast may be historical. However, I think it would be good to revisit this sometime after 15.0 is released. As explained above, the lack of any command line options to ypbind does not imply that the user wishes to use a broadcast. It is therefore not appropriate for this to be assumed by rc.yp.

I personally avoid editing rc.d scripts unless absolutely necessary, especially for configuration (that's what configuration files are for). I have therefore been pleased to see a shift away from configuration in the /etc/rc.d/ scripts themselves over the 15.0 development cycle, and the appearance of /etc/default/yp is (in my opinion) a good thing. It allows the server or client to be enabled as needed without having to resort to editing the rc.yp script itself. It does mean that ypbind is configured in two different locations (/etc/yp.conf and /etc/rc.d/rc.yp). However, this is as much a result of the way ypbind works as anything else. If, for example, there was a command line option to set the server then /etc/yp.conf could be ignored for most users with configuration isolated entirely to /etc/default/yp. It is, therefore, something we have to live with. This part of the issue isn't Slackware specific.

On my systems I solve this particular problem as bender647 does: by setting YPBIND_OPTS to a single space.

The suggestion of bender647 to use "-f /etc/yp.conf" is also good, and is in many ways better. I like it because it effectively stops rc.yp making the "broadcast" decision and defers it to /etc/yp.conf. If Slackware were to make this change and put "broadcast" into /etc/yp.conf, the current default condition would be preserved. At the same time, the default "broadcast" setting would be obvious to a user who wanted to configure a server explicitly in yp.conf, avoiding the surprise experienced by the OP that entries in /etc/yp.conf appear to be ignored. I would support such a change.

This issue came up for me following a recent update of an NIS server system to Slackware64-current just over a month ago. I found that the NIS broadcast packets from clients were not being seen by the NIS server process (but they were received by the system, confirmed with tcpdump). A quick test suggested it was not due to iptable entries which hadn't changed from those used in Slackware64 14.2 where yp client broadcasts worked fine. In the end I needed to get the system going so I simply pushed a change to the clients to specify a specific server in /etc/yp.conf. It was at this point I discovered the OP's issue. I hope to do some more experiments at some point to clarify what was going on with the NIS broadcast packets. That said, having systems specify a server explicitly is arguably a little more secure, so regardless of what I might find I will probably leave the yp.conf server setting in place.