Duplicate eth0 definition

[Adam Collard]

Using maas 1.7.0~rc1+bzr3295-0ubuntu1~trusty1 and the daily image stream, when I start a MAAS node I get a machine with a duplicate eth0 configuration.

It's configured in both /etc/network/interfaces and /etc/network/interfaces.d/eth0.cfg

[Julian Edwards (julian-edwards)]

Sounds like this is related to jtv's networks changes.

[Julian Edwards (julian-edwards)]

Is this consistently re-created?

[Jeroen T. Vermeulen (jtv)]

Yes, I think the installer now writes the interface's definition to a different file than the /etc/network/interfaces we're used to, whereas my changes made MAAS write it to /etc/network/interfaces. It seems to be something the cloud image does, but the end-user Server install image doesn't.

The eth0.cfg shouldn't affect the system though. The files contained in /etc/network/interfaces.d are inert by default; the directory does not work in the usual run-parts fashion. You can configure /etc/network/interfaces to do that through an explicit command, but the file as we write it won't do that. Apparently the default Debian install does write that command into /etc/network/interfaces, but the Ubuntu server install doesn't.

So as far as I can see, the problems here are (1) a misleading, inert file; and (2) concerns about what will happen in the future if it becomes more desirable for the default /etc/network/interfaces to include all of /etc/network/interfaces.d. Is that right?

[Jeroen T. Vermeulen (jtv)]

This does look a lot like a manifestation of bug 1315501, however.

[Adam Collard (adam-collard)]

On 5 November 2014 11:26, Jeroen T. Vermeulen <email address hidden>
wrote:

> Yes, I think the installer now writes the interface's definition to a
> different file than the /etc/network/interfaces we're used to, whereas
> my changes made MAAS write it to /etc/network/interfaces. It seems to
> be something the cloud image does, but the end-user Server install image
> doesn't.
>
> The eth0.cfg shouldn't affect the system though. The files contained in
> /etc/network/interfaces.d are inert by default; the directory does not
> work in the usual run-parts fashion. You can configure
> /etc/network/interfaces to do that through an explicit command, but the
> file as we write it won't do that. Apparently the default Debian
> install does write that command into /etc/network/interfaces, but the
> Ubuntu server install doesn't.
>

Right, the situation which it caused issues with was where something else
was manipulating the interfaces file, dropping files into interfaces.d and
doing source *.cfg (a la run-parts). The presence of this (previously
inert) file caused issues.

>
> So as far as I can see, the problems here are (1) a misleading, inert
> file; and (2) concerns about what will happen in the future if it
> becomes more desirable for the default /etc/network/interfaces to
> include all of /etc/network/interfaces.d. Is that right?
>
>
Agreed on both counts.

[Jeroen T. Vermeulen (jtv)]

Thanks for the quick explanation. I guess the most sensible thing for MAAS to do then is to write its own snippets (/etc/network/interfaces.d/eth0.cfg and such), and populate /etc/network/interfaces with one “source” statement per snippet.

(Including the whole directory would make me nervous if a standard install doesn't do it, but if somebody else on the system adds that statement, I guess reading the interface definitions twice won't actually hurt.)

[Andres Rodriguez (andreserl)]

What about this being a cause of Juju trying to write the network itnerfaces file to support their bridges? I think that juju creates /etc/network/interfaces.d/eth0.cfg and has nothing to do with MAAS. Could this be the reason?

[Adam Collard (adam-collard)]

On 5 November 2014 14:42, Andres Rodriguez <email address hidden> wrote:

> What about this being a cause of Juju trying to write the network
> itnerfaces file to support their bridges? I think that juju creates
> /etc/network/interfaces.d/eth0.cfg and has nothing to do with MAAS.
> Could this be the reason?
>

It's not Juju, I promise you. Just start a node in MAAS and you should be
able to see the error.