[08:54] Howdy all - A brief question if I may... [08:54] Updating config of interface linux OSes [08:55] ie, enabling inet6 auto [08:55] Is the only way via a runcmd? [08:55] Anything native that you guys have run into? [09:00] Hmm [09:00] http://curtin.readthedocs.io/en/latest/topics/networking.html#subnet-ip [13:51] bbabich, so what you can do is put networking config with that inside [13:51] in the image. === rangerpbzzzz is now known as rangerpb [14:57] bbabich, see the 'example config' at https://launchpad.net/ubuntu/+source/curtin/0.1.0~bzr479-0ubuntu1 [14:57] bah [14:57] at [14:57] https://gist.github.com/smoser/45935e78bf1b21ee7696be083240aa0f [14:57] but if you do use that, you have to know the name (or mac) of eth0. the "fallback" config is more dynamic as cloud-init picks what it views as "the first network device". [15:45] utlemming, http://paste.ubuntu.com/24268424/ [15:45] rharper, take a read of ^ and let me know if you disagree with the suggestion. i think that is what we agreed to yesterday. [15:45] its not idea. [15:45] ideal [15:46] smoser, rharper: that will result in the second nameserver overriding the first [15:47] yeah, resolvconf sucks [15:47] I dug in on resolvconf, and you'll see `dns-nameservers 10.0.0.1` as the final [15:47] well, in that case we'd get both. if you declare all on all. [15:47] yeah, we need to combine dns_* entries from all subnets, and put them in the network_state 'dns_*' fields [15:48] okay, that's seems simple enough...but it feels icky [15:48] just looking at resolvconf man page it looks like it sort of supports this, but it would expect ENI to run resolvconf with a different IFACE.PROG for each of those stanzas. [15:48] smoser: the issue is resolvconf being called for each iface stanza, and collecting the dns- values and overwriting [15:49] smoser: right, but when the hook runs, IFACE=eth0 for each stanza [15:49] which clobbers subsequent calls [15:49] i could imagine ENI being extended to either let you declare the name to go to resolvconf or consistently create one (as long as it could do the same on takedown) [15:49] the best debugging is to dump the ENV that ifupdown sets when the 00resolvconf ifup hook it is called [15:50] there maybe other information that we could use in the hook (before we call resolvconf -a ) [15:51] it looks like it does *sort* of handle it. [15:51] it uses "ADDRFAM" [15:51] so it would seem that one ipv4 and one ipv6 would work [15:52] right ? [15:52] smoser: that is how I read it [15:53] I'm wondering though if there is a simplier way, but I don't like it either: install a new parser in /etc/resolvconf/update-libc.d/ that handles it all [15:58] smoser, rharper: what do you guys think of that approach? [15:58] if our problem is that resolvconf is being obtuse, adding a hook that renders it right might be the cleanest [15:59] both DNSMasq and Avahi use hooks to do that [16:00] utlemming: indeed; I've not looked at the hook but something needs to know about the multiple stanzas and indicate that the configs should be merged; not sure how to handle when it should know it should replace the value vs. append/merge [16:01] well... [16:01] so here is one path. [16:03] i have a stanza like this: [16:03] iface eth0 inet6 dhcp [16:03] smoser_name eth0_dhcp1 [16:03] ifupdown puts 'smoser_name=' into the environment of the hooks [16:04] err... [16:04] IF_SMOSER_NAME='eth0_dhcp1' [16:05] so we can just have resolvconf 'opt in' to honoring some variable to influence its name used in [16:05] /etc/network/if-{down,up}.d/*resolvconf [16:05] smoser: heh [16:06] not joking. [16:06] in general, I think I'd like resolvconf to do the right thing without something like placeholder_for_resolvconf [16:06] we then, as the oracle rendering ENI just have to put sane names [16:06] which name field does resolvconf look at ? [16:06] resolvconf_name=eth0_addr1 [16:06] IFACe [16:06] interesting [16:06] right. currently [16:07] look at /etc/network/if-up.d/000resolvconf [16:07] its fairly obvious [16:07] if we put somnething in there, then it gets into the environment at IF_= [16:08] that's a lot cleaner [16:09] right, but this is a change to the resolvconf ifupdown hooks and requires coordination; [16:09] yes. [16:09] and SRU and such. [16:09] we;ll need to define the IF key we want, document and push to upstream resolvconf [16:09] but ends in something that can at least be made reliable [16:09] while what currently have is not [16:09] I think so, yes [16:09] do we? [16:10] add /etc/network/if-up.d/000cloudinit [16:10] and provide it in the cloud-init sru [16:10] nah. we have to update resolvconf [16:10] which exports the name of the IFACE [16:10] you dont have to export [16:10] ifupdown does that already [16:10] any "option" in a given stanza [16:11] gets exported as [16:11] well, change the IFACE to the key that we want to use [16:11] how will we handle upgrades for eni's already rendered without the key ? [16:11] IF_