Need DHCP client scripts for NIS

[Paul Smith]

On Tue, 2008-07-08 at 16:23 +0100, Mark Brown wrote:
> > In order for overwriting to occur, the following must be true: the user
> > must have installed the NIS package (it's not installed by default on
> > Ubuntu), and the user must use DHCP for their network settings, and the
> > DHCP server must be configured to provide nis-domain and nis-server
> > settings as options (this is rare since only larger enterprises with
> > lots of UNIX systems bother with NIS), and finally the user must, for
> > some reason, want to use a different value for either/or the NIS domain
> > and the NIS servers than the one the DHCP admin suggested.
> 
> The main use case this breaks is people using NIS to distribute
> information to laptops which then work off-line, potentially on other
> networks (I am aware of people doing this, usually with a slave
> configured on the laptop for disconnected operation).

I'm not sure I see the breakage, unless you mean you don't think such a
user would want to connect to the master server while on-line.  If
that's OK, then the user-configured /etc/yp.conf would specify the local
slave, then when the system was on-line DHCP would provide a new server
(the master or another slave) instead, then when the system went
off-line the local slave info would be restored to /etc/yp.conf.

ypbind would have to be restarted of course but that's true in all
cases.

> This is what low priority debconf questions are for - they're there if
> they are needed but not enabled by default so they don't confuse users
> in the normal course of affairs.

This sounds good to me.

> > There is a change in behavior, potentially, but Ubuntu changes behaviors
> > every release.  Finally, remember that the dhclient exit hook preserves
> 
> The reason for being especially conservative here is that breaking the
> NIS configuration can render the user unable to log in to the system -
> the consequences of getting it wrong are extremely serious.

True, but it takes a lot of customization to get there.  There's no way
to integrate NIS with the initial Ubuntu account since Ubuntu doesn't
allow you to choose their own UID at install time.  You're basically
stuck with a massive "chown" operation after the fact (which gets pretty
tricky when you throw in odd things like gvfs FUSE filesystems in $HOME
etc.), or else you create a local user account with a different username
then configure your NIS account to be an admin--in this case you always
have that local user account to fall back on (of course, people with UID
1000 won't be able to log into your box).

I do agree that losing your account is a big problem (I lost sudo access
due to the Hardy bug regarding sudo and hostnames--had to boot from CD
to recover.  That sucked.)  I am still skeptical about the _real_
threat, though, since if you are using NIS as your sole login to the box
you're really playing with fire anyway.  Nevertheless it's better safe
than sorry.

> > I don't think any change is needed here.  The base system nsswitch.conf
> > uses "compat" for the passwd, group, and shadow entries which is fine.
> 
> compat is only half the story - you also need to add the appropriate
> +:::: entries to the relevant files for it to have any effect.

Oh right.  I wonder why Debian/Ubuntu uses "compat" instead of "files
nis" like most other distros?

Don't get me wrong, I like "compat" as it's more powerful than "files
nis".  But, as you point out, changes are required to base files in
order to enable it.