When an "option nis-domain" ist set via a DHCP server, there is no need for
the file /etc/defaultdomain (in addition, dpkg -S does not know this file).
So, if the command "domainname" succeeds AND the file /etc/defaultdomain
doesn't exist, the nis-domain should be the output of "domainname".

In this manner, a single read-only (NFS-rooted, for example) Debian System
easily can be used in different NIS domains.

That's very common - the only configuration files that can be managed by
dpkg are conffiles but the conffile mechanism is not suitable for any
configuration file which is expected to be edited.

severity 456299 wishlist
thanks

Requests for new features should generally be wishlist.

dhcp3-client looks like it supports exporting this information via the
hooks directory.  However, it may be some time before I have a suitable
test environment to do any development on.

I assume you mean to say that you want to set the NIS domain from the
DHCP option here?

Yes, that's what I meant.

Turning on the kernel level autoconfiguration (CONFIG_IP_PNP=y) will
suffice to test the use of "option nis-domain".

Erik

That testing is going to go better if one has access to a DHCP server
which is providing the option, though.

Sorry to resuscitate up this bug 5 years later.

I am interested in getting this resolved. The way I see it, this is a
two-part bug.

First of all, NIS should provide a hook script in
/etc/dhcp/dhclient-enter-hooks.d/ It should handle both NIS domain and
NIS server.

Secondly, dhclient needs to provide a way to request both the
nis-domain and nis-server DHCP options. However, this is not clearcut
since it shouldn't be simply enabled by default (such as ntp); there
are some security concerns IMO. #686236 possibly is an answer.

I'd like to use the DHCP nis-domain and nis-server options on a
cluster I admin. I'd be happy to test out scripts or provide any info
you may need.

---Alex

... and after other 7 years, some considerations by me with the hat of new
maintainer for NIS packages.

First of all, the bullseye package is now split in nis-client (ypbind-mt) and
nis-server (ypserv). Both them use the usual /etc/defaultdomain as
taken from Sun convention for Solaris boxes. Basically, any dynamic setup
just needs to set that file appropriately, before running the right services.

I guess the required dyanamic capability is requested for clients, in order
to load ypbind-mt only on request, with the required setup. I think that a
dynamic setup is a non₋sense for servers.

Even in the case of multiple NIS domains, it is always possible to set domain
and NIS servers in advance in /etc/yp.conf statically. Then, it is also
possible to add Wants/After to ypbind.service on
systemd-networkd-wait-online.service after enabling it. This should be totally
optional in order to start the ypbind service only after one network goes up.

That does not solve the issue of recognizing the host network, of course.
Even in case of broadcasting, you need an oracle to know the domain and bind
to it. One way to do that is of course having the nis-domain and nis-servers
set at dhcp server level.

In bullseye, systemd version is able to wait any of a specific pool of
interfaces before binding (that is not possibile in buster: you need to choose
a single interface and wait on that), therefore IFF the dhcp server is able
to provide the required nis-* vars, one can set the /etc/defaultdomain just
before running ypbind. In the other case, the system could use the existing
file, as plan B. The problem is that in general you would not do that if
the host network is the wrong one: running ypbind when not expected is not
nice for timeouts.

IMHO this kind of setup is complex enough and dependent on quite enough
implementations and use cases to avoid installing any dhcp snippet per
default, and leave the whole beast as a possible solution (with variants) in
the doc section, including manipulation of /etc/nsswitch.conf, changes to
systemd services, etc.

Anyone there, still interested to comment?