nis package must provide DHCP client scripts

Thank you for your suggestion. However, the changes you are requesting aren't really a bug and require more discussion, which should be done on an appropriate mailing list or forum. [WWW] http://www.ubuntu.com/support/community/mailinglists might be a good start for determining which mailing list to use.

This seems like a perfectly valid wishlist bug which I'd have expected to see forwarded on to Debian at least (I am the Debian NIS maintainer).

FWIW this is more complicated than the report suggests. For example, it'd need to be optional and off by default like the similar configuration for WINS in the samba package to avoid breaking upgraded systems and trampling over explicit user settings. Also, the dhclient side needs to be done in the dhclient package.

After I filed this I realized there was no facility for updating dhclient.conf via dpkg scripting, so I also filed bug #246343 to have these fields added to the dhclient.conf "request" line by default. It won't hurt anything to have them requested there: if they're not available from the server then there's no problem; if they are available and the nis package is not installed (which it is not by default!) then no difference.

As for extra complications, I don't know that I agree. The NTP package, for example, doesn't require extra setup to "turn on" this feature. The scripts are added to the dhclient exit hooks on package install without any confirmation from the user. We don't ask them whether they'd like to allow their DNS servers to be overridden or not. Like NTP, NIS is not installed by default: the user must explicitly install it. I honestly can't think of any reason why someone would NOT want to use the nis-domain and nis-server settings that are provided to them from their DHCP server. The only time a DHCP server would be configured to provide that information, after all, was if the admin knew it was needed. NIS is NOT something you find in your everyday internet cafe etc.

I can see why this might be problematic based on the fact that it's potentially a change in behavior, but that's what Intrepid is for right? Many, many other behaviors are changed without warning on every release if Ubuntu. My opinion is that the default on package install should be to automatically accept DHCP settings, and if users want to disable this they can either (a) edit dhclient.conf and turn off the "request" entry, or (b) there can be some other facility via /etc/defaults or whatever that the NIS dhclient exit hooks look at to disable it. Note that the hook script would of course be written to preserve the existing /etc/yp.conf file (traditionally it would be renamed to /etc/yp.conf.dhcp) when obtaining a lease and put it back when releasing the lease, so we only override explicit user settings for the duration of the DHCP client connection, then they are put back.

I'll point out that the "enabled by default" behavior is how other distros do this.

The main reason to be extra careful with this sort of setup is that messing up NIS can prevent users logging in to their system which is obviously an extremely serious issue for upgrades since it could render the system non-functional. This means that we need to be very conservative about changes which risk causing such breakage.

Other distributions have very different models for how NIS and other authentication methods are configured so it's difficult to directly compare.

Usually root can always login to fix things on the console, unless you explicitly disable root login, and rely upon an unprivileged user running sudo, as Ubuntu does. So your "system non-functional" argument is surely a home-made problem.

Maybe it would be possible to introduce some debconf menu to enable this feature? The central configuration via dhcp options is in very wide use, especially in enterprise environments. I really would like to see this feature implemented.

Yes, a Debconf note would be the way forward, though it'd have to be a low priority one. Note that I'm mostly talking about enabling this on upgrade here - new systems are a bit different since you won't damage anyone's running system.

Given that this is Launchpad I'd presume that any discussion here is Ubuntu-specific.

You mean you would accept dhcpd's nis options for new installs by providing a client script, and provide a debconf note pointing to the change on an upgrade? I could live with that.

I am not sure that this discussion is Ubuntu-only. In general I would suggest to keep Debian and Ubuntu in sync, but there is surely no need to put Lenny at risk.

If the discussion is going on in Launchpad it's pretty much Ubuntu-specific. Note that I'm the Debian NIS maintainer; it's unlikely that I'll do anything directly with the Ubuntu packages.

No Debconf *note* (they're deprecated) but possibly a low priority question offering to enable the option defaulting to off - like I say, take a look at the Samba WINS configuration, that's a good example.

In any case, you need to get dhclient to export the information first.

Mark Brown wrote:
> If the discussion is going on in Launchpad it's pretty much Ubuntu-
> specific. Note that I'm the Debian NIS maintainer; it's unlikely that
> I'll do anything directly with the Ubuntu packages.
>

A fix in Debian is fine for me. If its available in Debian, then it is
just a matter of time till it reaches Ubuntu (hopefully).

I just posted a metoo for the bug report on Launchpad, since I stumbled
over it on an Ubuntu installation.

> No Debconf *note* (they're deprecated) but possibly a low priority
> question offering to enable the option defaulting to off - like I say,
> take a look at the Samba WINS configuration, that's a good example.
>

Actually I would suggest to accept the dhcp options by default
(independent from nis or Samba or whatever). Either dhcp is available,
or it is not. _If_ dhcp is there, then this is a central part of the
infrastructure, usually managed by somebody who feels responsible for
the whole local network. In general I doubt that this admin guy prefers
to see all the dhcp options in his precious config file being ignored
by the clients.

I understand that there might be security concerns about the options
provided by any dhcpd, but authentication of the server would be the job
of the dhcp-client package.

> In any case, you need to get dhclient to export the information first.
>

I had the chance to check OpenSuse's support for this feature today:
Suse's dhclient-script simply generates /etc/ypserv.conf. I could
provide a similar script for the dhclient hook directories, if you
are interested?

Regards

Harri

It's not quite that simple - people use NIS on computers which move between networks, such as laptops, and run multiple NIS domains on the same network (which means that any DHCP configuration will only apply to some systems). This makes it difficult to tell if the configuration on the network applies to the current system.

Like I say, enabling DHCP support on systems where it was not previously enabled is not going to happen: the systems already work so any risk of breaking them is unacceptable, which means that this can't be enabled for upgrades. As I have said, it may be OK to default this on for new installs but never for old installs.

Something which overwrites the configuration unconditionally wouldn't be good enough - this would prevent use of any manual configuration and would doubtless lead to users having their configuration destroyed.

Mark Brown wrote:
> It's not quite that simple - people use NIS on computers which move
> between networks, such as laptops, and run multiple NIS domains on the
> same network (which means that any DHCP configuration will only apply to
> some systems). This makes it difficult to tell if the configuration on
> the network applies to the current system.
>

Dhpc can send options to the client depending upon its mac address,
its subnet, etc. Configuring multiple nis domains via dhcp would be
easy.

About hibernate and moving your laptop from one network to another:
These special cases were never considered for either dhcp nor nis,
when these services were specified. I would suggest to start with
the "regular" operations for nis and dhcp, and to look at hibernate
support later.

Keep it simple. It is still Unix.

> Like I say, enabling DHCP support on systems where it was not previously
> enabled is not going to happen: the systems already work so any risk of
> breaking them is unacceptable, which means that this can't be enabled
> for upgrades. As I have said, it may be OK to default this on for new
> installs but never for old installs.
>

Agreed. I thought you were talking about (version) upgrades in general.
A one-time confirmation dialog is surely OK.

> Something which overwrites the configuration unconditionally wouldn't be
> good enough - this would prevent use of any manual configuration and
> would doubtless lead to users having their configuration destroyed.
>

Sure. Looking for some line like

 # DO NOT EDIT THIS FILE, or remove this line.

should work.

Regards

Harri

You're missing the point with laptops and so on: these are use cases that are already supported and can be broken by a poor DHCP implementation. This is especially the case if your preferred implementation with overwriting the configuration file were done - the user configuration would be unconditionally deleted if they connected to the wrong network.

Adding a "DO NOT EDIT THIS FILE" note doesn't really address the problem: it's not really compliant with policy (users should be able to do static configuration) and means that it becomes impossible to set any configuration which is not offered over DHCP. You should do something like have the DHCP configuration go in a separate file and source that from the main configuration file.

Of course the script should not overwrite modifications done by the user. If Debian doesn't allow to use a comment line tag like "# DO NOT EDIT THIS FILE, or remove this line", then you could store the md5sum of yp.conf somewhere to check for user modifications on the next run. If the md5sum file doesn't exist, then the postinst script could ask the user.

BTW, the default /etc/dhcp3/dhclient.conf doesn't list the nis options in the "require" statement, anyway, i.e. the dhclient script for nis would not see the nis options set on the dhcp server, unless this feature is explicitly enabled in dhclient.conf.

Yes, the md5sum approach is what some other packages use - but ideally there wouldn't be the all or nothing and it'd only be applied to a file included from the main confiugration.

The other part of this bug was to get those options added to the default dhclient.conf so this would all work out of the box.

Some of our workstations have a problem with switches that take a while before the link is up (span-tree), which makes the nis client start before the interface is completely up even if you set nis to start at S99 in rc2.d. A simple solution is to add the following file to /etc/network/if-up.d
The script checks if ypbind is running when an interface comes up, and if not, starts ypbind.
It has not been tested with networkmanager, but works great if you have trouble with nis not starting because of a slow switch.