Ubuntu

nis package must provide DHCP client scripts

Reported by Paul Smith on 2008-07-07
18
This bug affects 2 people
Affects Status Importance Assigned to Milestone
dhcp3 (Ubuntu)
Wishlist
Unassigned
nis (Debian)
New
Unknown
nis (Ubuntu)
Wishlist
Unassigned

Bug Description

Binary package hint: nis

Enterprise environments quite often distribute network settings such as domain name servers, NTP servers, etc. via DHCP. One of the network settings that can be distributed this way is the NIS server, via the nis-domain and nis-servers options in DHCP (see the dhcp-options(5) man page for a complete list). Also available is nisplus-domain and nisplus-servers.

On other enterprise Linux desktops like Red Hat Enterprise, the DHCP client script notices these settings and configures the NIS setup on the client when they are present (modifying /etc/yp.conf as needed).

On Ubuntu, this is not done currently, so it needs to be done. The steps needed are the following:

* A new sh script needs to be created in the nis package, /etc/dhclient-exit-hooks.d/nis This script should check the $reason variable and either update or reset the /etc/yp.conf file as appropriate. The values of the options will be available in shell variables. It should also restart ypbind. For an example of how to do this see the NTP scripts.

* On package install, the /etc/dhclient.conf file needs to be updated to ask for the above options in the "request" option field. If there's no good way to do that then I guess we need to request that the dhcp3-client package be updated to ask for these by default (it shouldn't hurt anything if we "request" them and they're not there, or they are there but we have not installed the nis package to handle them).

Marcus Asshauer (mcas) wrote :

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.

Changed in nis:
status: New → Invalid
Mark Brown (broonie) wrote :

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.

Iulian Udrea (iulian) on 2008-07-08
Changed in nis:
importance: Undecided → Wishlist
status: Invalid → New
Mark Brown (broonie) on 2008-07-08
Changed in nis:
status: New → Confirmed
Paul Smith (psmith-gnu) wrote :

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.

Mark Brown (broonie) wrote :

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.

Changed in nis:
status: Unknown → New
Harri (harald-dunkel) wrote :

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.

Mark Brown (broonie) wrote :

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.

Harri (harald-dunkel) wrote :

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.

Mark Brown (broonie) 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.

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

Mark Brown (broonie) 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.

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.

Harri (harald-dunkel) wrote :

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

Mark Brown (broonie) wrote :

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.

Harri (harald-dunkel) wrote :

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.

Mark Brown (broonie) wrote :

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.

Håvard Espeland (haavares) wrote :

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.

Chuck Short (zulcss) on 2009-09-23
Changed in dhcp3 (Ubuntu):
status: New → Confirmed
importance: Undecided → Wishlist
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Bug attachments

Remote bug watches

Bug watches keep track of this bug in other bug trackers.