** No longer affects: maas
** No longer affects: nplan (Ubuntu)
** No longer affects: systemd (Ubuntu)
** Changed in: cloud-init
Status: New => Confirmed
** Changed in: cloud-init
Importance: Undecided => Medium
** Changed in: cloud-init
Assignee: (unassigned) => Ryan Harper (ra
On Thu, Mar 08, 2018 at 04:30:30PM -, Scott Moser wrote:
> I'm pretty sure that if you you rm /etc/resolv.conf
> and then just write what ever you want in there, it wont get overritten.
>
> mv /etc/resolv.conf /etc/resolv.conf.dist
> echo "nameserver 8.8.8.8" > /etc/resolv.conf
Apologies, I t
I'm pretty sure that if you you rm /etc/resolv.conf
and then just write what ever you want in there, it wont get overritten.
mv /etc/resolv.conf /etc/resolv.conf.dist
echo "nameserver 8.8.8.8" > /etc/resolv.conf
On Thu, Mar 8, 2018 at 4:36 PM, Mike Pontillo
wrote:
> We discussed this today and
We discussed this today and decided that the proper place to fix this is
not in MAAS; the v1 YAML containing global DNS servers should be
converted to equivalent valid Netplan (using a heuristic).
Alternatively, global DNS could be added to the Netplan schema (possibly
as a shortcut to apply confi
** Changed in: maas
Importance: High => Medium
** Changed in: maas
Status: Won't Fix => Triaged
** Changed in: maas
Importance: Medium => Low
** Changed in: maas
Milestone: None => 2.4.x
--
You received this bug notification because you are a member of Ubuntu
Touch seeded pack
** Changed in: maas
Status: Triaged => Won't Fix
** Changed in: maas
Assignee: Mike Pontillo (mpontillo) => (unassigned)
** Changed in: maas
Milestone: 2.4.0alpha2 => None
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is su
Ok, that's not much of a workaround then :).
On Thu, Mar 8, 2018 at 3:52 AM, Dan Watkins
wrote:
> On Wed, Mar 07, 2018 at 11:42:29PM -, Jason Hobbs wrote:
>> Is there a workaround for this? I can just rm /etc/resolv.conf and
>> create it with the contents I want, right?
>
> Yep, though you'll
On Wed, Mar 07, 2018 at 11:42:29PM -, Jason Hobbs wrote:
> Is there a workaround for this? I can just rm /etc/resolv.conf and
> create it with the contents I want, right?
Yep, though you'll need to recreate it every so often as it will be
replaced.
--
You received this bug notification becau
Is there a workaround for this? I can just rm /etc/resolv.conf and
create it with the contents I want, right?
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1750884
Title:
Currently maas sends v1 config to cloud-init. cloud-init converts
that to netplan. MAAS could certainly change change to either
a.) improve the v1 config that it sends to put dns as per-interface
b.) send v2 config with dns per-interface.
I don't think there is reason to justify either of those a
Whether or not /e/n/i supports something correctly or just happens to
work by sheer luck has no bearing on what is technically correct and
sensical -- let's abstract this, what we need to concern ourselves with
here is netplan, cloud-init and maas.
In the network world, it is absolutely true that
I don't want to change the v1 YAML in MAAS to output per-interface DNS,
because this risks causing a change of behavior in pre-netplan
deployments. It seems this is necessary in Netplan, but it isn't clear
to me that this is correct. I think it's valuable to take a step back
and look at the require
On Fri, Feb 23, 2018 at 04:09:07AM -, Andres Rodriguez wrote:
> On Thu, Feb 22, 2018 at 10:30 PM Scott Moser
> wrote:
> > Getting this fixed in cloud-init is tricky.
> > In ifupdown (/etc/network/interfaces) world, we just took the "global dns"
> > entries and put them on the loopback device
If we don't know, then maybe things should be passed to netplan, in a way for
it to generate global resolved config? as in, create
/run/systemd/resolved.conf.d/global.conf
[Resolve]
DNS=999.999.999.999
(Maybe FallbackDNS=, if we want it to leave DNS= setting for users to tweak)
Or whatnot, which
On Thu, Feb 22, 2018 at 10:30 PM Scott Moser
wrote:
> Getting this fixed in cloud-init is tricky.
> In ifupdown (/etc/network/interfaces) world, we just took the "global dns"
> entries and put them on the loopback device (lo). Since that device would
> always be brought up, and never really brou
Getting this fixed in cloud-init is tricky.
In ifupdown (/etc/network/interfaces) world, we just took the "global dns"
entries and put them on the loopback device (lo). Since that device would
always be brought up, and never really brought down, it served its purpose.
That is what Ryan tried ab
** Changed in: maas
Importance: Low => High
** Changed in: maas
Assignee: (unassigned) => Mike Pontillo (mpontillo)
** Changed in: maas
Milestone: None => 2.4.0alpha2
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed
I gave the "loopback" trick a go like so:
root@b1:~# cat /etc/systemd/network/10-netplan-lo.network
[Match]
Name=lo
[Network]
Address=127.0.0.1
DNS=10.90.90.1
Domains=maaslab maas
root@b1:~# networkctl status --all
● 1: lo
Link File: n/a
Network File: /etc/systemd/network/10-netplan-l
Let's make sure this is fixed for bionic. The scope of nameservers has
changed and maas should do the right thing.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1750884
Tit
** Changed in: maas
Importance: Undecided => Low
** Changed in: maas
Status: Invalid => Triaged
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1750884
Title:
[2
@Scott,
Sure, we can all improve but I just want to note one thing. The "Silly"
config that MAAS sends to curtin is valid config. That yields valid
configuration in Xenial. Since Curtin is now passing the /same/
configuration to cloud-init, cloud-init is not generating valid
configuration in Bioni
In terms of expectations on bionic:
1) /etc/resolv.conf should be a symlink to ../run/systemd/resolve/stub-
resolv.conf
2) The contents should point at `nameserver 127.0.0.53` and list search
domains, if any are available. I.e. the contents shown in the bug
description is correct.
3) The nameser
It seems to me that each of maas, cloud-init and netplan could do better
here.
a.) maas declares 'global' nameserver/dns info.
this is kind of silly in that such a thing doesn't really exist.
maas has the information necessary to declare the nameserver on the
device with the address that has a rou
@Matthieu,
ubuntu@node01:~$ systemd-resolve google.com
google.com: resolve call failed: No appropriate name servers or networks for
name found
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.l
MAAS is sending a "global" nameserver, and a ethernet device on a bridge.
cloud-init is rendering that nameserver onto the ethernet device rather
than on the bridge or as a "global" entry.
$ cat my.yaml
network:
config: [
{"id": "enp0s25", "type": "physical", "name": "enp0s25",
"mac_addr
Why aren't the nameservers set under the br0 interface, if the interface
is supposed to be in a bridge?
The /e/n/i config and netplan configs here are not equivalent. I expect
that systemd-resolved should be happy with the config as it is anyway,
but this may be a special case where systemd thinks
@Mathieu,
Good catch.
@Scott:
Network config MAAS sent is correect, it is the same config sent to
xenial: https://pastebin.canonical.com/p/rjBgzKjdxR/
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https
ubuntu@node03:~$ systemd-resolve --status --no-pager
Global
DNSSEC NTA: 10.in-addr.arpa
16.172.in-addr.arpa
168.192.in-addr.arpa
17.172.in-addr.arpa
18.172.in-addr.arpa
19.172.in-
Hi,
cloud-init has never updated resolv.conf directly.
/etc/resolv.conf in 16.04 is managed via resolvconf through
/etc/network/interfaces.
/etc/resolv.conf in 18.04 is managed via systemd-resolve (netplan ->
systemd-networkd -> systemd-resolve).
Can you provide the content of:
systemd-resol
29 matches
Mail list logo