Comment 11 for bug 351378

Bryan McLellan wrote:
> Tom Metro wrote:
>> I'll have to take a look at ubuntu-minimal to see what it is.
>
> It's a meta package...

I figured that from the name, but I wondered what packages it pulled in,
and what the consequences were for removing it were.

> Uninstalling it would mean that in the future if another package was
> added to to the meta package, you wouldn't get that additional
> package on upgrade.

Which sounds fairly low risk, but something one would ideally want to avoid.

> You could also remove the dhcp3-client package with
> --force-depends, which just runs the risk that it gets reinstalled
> later during an upgrade. There's probably a complex pinning solution
> too, but I can't fathom it.

I couldn't figure out a way around it. Any combination I came up with
(like putting dhcp3-client on hold, then removing it), just left the
package system in a broken state.

More importantly, on Hardy there are additional dependencies on
dhcp3-client. dhcdbd depends on it, which provides the DBus interface to
dhcp3-client that's used by network manager, which in turn Network
Manager depends on, which in turn ubuntu-desktop depends on.

The resolutions offered up by aptitude (supposedly the best tool for
resolving dependency issues) all involved uninstalling more packages
than I cared to.

To work around this I ended up creating a dummy package using the equivs
package. That lets me replace the real dhcp3-client with a dummy one,
which uninstalled the dhcp3-client binaries and scripts.

All this makes me wonder if ubuntu-minimal ought to be dependent on the
generic dhcp-client (which dhcp3-client, dhcpcd, and udhcpc all
provide), rather than a specific package. (Of course on Hardy that won't
fix the dhcdbd dependency. I'm guessing that means dhcp3 is probably the
only client Network Manager knows how to control.)

I'm also wondering if uninstalling dhcp3-client was even necessary. I
noticed when I installed udhcpc that it didn't cause any conflicts, even
though it ought to have conflicted with another package providing
dhcp-client. Either udhcpc isn't correctly tagged as providing
dhcp-client, or the two can peacefully coexist.

Looks like dhcpcd has dhcp-client listed as a conflict, while udhcpc
doesn't. Given that they all are driven by the sane interfaces config
file, I'd expect there to be conflicts. I'd like to understand better
how that works. Is each overwriting the other's ifupdown scripts? Is
there a common script with a bunch of -x tests to see which binaries are
present?

> I did test and confirm that dhcpcd=1:3.2.3-1.1 does work on alias
> interfaces on intrepid.

Unfortunately this doesn't work on Hardy with dhcpcd=1:3.0.17-2:

# init.d/networking restart
                                       * Reconfiguring network interfaces...
Error, eth0: dhcpcd not running
dhcpcd.sh: interface eth0 has been configured with new IP=192.168.0.203
  * Stopping NTP server ntpd
    ...done.
  * Starting NTP server ntpd
    ...done.
Error, eth0:1: ioctl SIOCSIFFLAGS: Cannot assign requested address
Failed to bring up eth0:1.
[...]
    ...done.

Looks like the usual failure, though in a bit different format than what
ifconfig produces, suggesting it is making its own syscalls, and they're
failing in the kernel code. At least it positively states that it failed
to bring up the interface (confirmed), unlike dhcp3-client.

A second look at the interfaces man page shows that the DHCP
configuration directives there are supported by udhcpc in addition to
dhcpcd. I hadn't noticed that before, and the udhcpc documentation omits
to mention it (should probably file a bug for that).

Given that udhcpc spits out warnings, but did appear to work when
invoked directly on Hardy, I'm going to try that next.

Hurray, it finally worked:

# init.d/networking restart
  * Reconfiguring network interfaces...
RTNETLINK answers: No such process
udhcpc (v0.9.9-pre) started
Sending discover...
Sending select for 192.168.0.203...
Lease of 192.168.0.203 obtained, lease time -1
Resetting default routes
adding dns 192.168.0.35
  * Stopping NTP server ntpd
    ...done.
  * Starting NTP server ntpd
    ...done.
udhcpc (v0.9.9-pre) started
SIOCSIFFLAGS: Cannot assign requested address
Sending discover...
Sending select for 192.168.0.238...
Lease of 192.168.0.238 obtained, lease time -1
Resetting default routes
adding dns 192.168.0.35
  * Stopping NTP server ntpd
    ...done.
Ignoring unknown interface eth1=eth1.
Ignoring unknown interface eth2=eth2.
Ignoring unknown interface ath0=ath0.
Ignoring unknown interface wlan0=wlan0.
[ OK ]
* Starting NTP server ntpd
    ...done.

# ifconfig
eth0 Link encap:Ethernet HWaddr 00:04:...:d1:33
         inet addr:192.168.0.203 Bcast:192.168.0.255 Mask:255.255.255.0
[...]
eth0:1 Link encap:Ethernet HWaddr 00:04:...:d1:33
         inet addr:192.168.0.238 Bcast:192.168.0.255 Mask:255.255.255.0

I did have to apply some additional tweaks to interfaces to get udhcpc
to behave correctly. It apparently doesn't send the host name by default
as part of the DHCP discover packet, unlike the other two clients, which
resulted in a new IP address getting assigned to the primary interface
(and Dnsmasq no longer knowing how to reach the machine by name). But
that's easy enough to remedy with a hostname argument.

I also previously determined that to force a DHCP server to issue two
different IP addresses to requests coming from the same hardware address
requires specifying unique client IDs for each request. (Specifying a
unique host name alone is apparently not sufficient, according to the
standard.)

So my interfaces ended up like:
[...]
auto eth0
iface eth0 inet dhcp
   hostname mythtv
   client mythtv

auto eth0:1
iface eth0:1 inet dhcp
   hostname indianpoint
   client indianpoint
[...]