Bug#447071: use ntp server provided by dhcp

[dann frazier <dannf@hp.com>]

Package: clock-setup
Version: 0.92
Severity: wishlist

Some users, like myself, are behind a firewall which blocks outgoing
NTP requests. This prevents the installer, running with the default
priority, from properly setting the clock. Worse yet (imo), the
installer hangs for an inordinate amount of time until the ntp
request times out.

The following patches allow NTP server information provide by the DHCP
server to override the current built-in default.

This feature is implemented in two udebs:

netcfg has been modified to request the ntp-servers option from the
DHCP server. A 'request' entry is added in the dhclient.conf
file. This entry requests the same options that dhclient requests when
no explicit request option is present (see dhclient.conf(5)), plus the
ntp-servers option. If this field is non-empty, netcfg simply stores
away this data in netcfg/dhcp_ntp_servers for later processing by
clock-setup.

clock-setup checks the setting of netcfg/dhcp_net_servers. If
this variable has been set, clock-setup extracts the first server
(this implementation ignores any additional servers) and uses it as
the new default ntp server.

I've tested the following in a normal-priority install:
 * DHCP provides no ntp-servers option
 * DHCP server provides a single ntp server
 * DHCP server provides a list of ntp servers

And I also verified that an expert install still asks the user for an
ntp server, presenting the dhcp-provided server as the default.

I guess the only thing I'm unsure about is the appropriate size of the
ntpservers array. _UTSNAME_LENGTH should be big enough as long as
clock-setup is ignoring all but the first server in the list, but I'd
prefer this to be the maximum size of the list a dhcp server could
provide. That would allow clock-setup to later be modified to use the
entire list in the future without having to update netcfg again later.

-- 
dann frazier