Re: Bug#846583: cloud.debian.org: AWS Image should enable DHCPv6 client
On Wed, Dec 14, 2016 at 08:17:28AM +0100, Thomas Lange wrote: > I wonder why you need to source /usr/lib/fai/subroutines for importing > the ifclass subroutine. If your scripts are bash scripts, this > function should be already available. Hm. I have no idea why I thought that would be necessary. Confirmed that it's not, so I've removed that. noah signature.asc Description: PGP signature
Bug#846583: cloud.debian.org: AWS Image should enable DHCPv6 client
On Sat, Dec 10, 2016 at 08:57:22PM +0100, Bernhard Schmidt wrote: > I don't think this will ever be fixed with ifupdown. I think > systemd-networkd and NetworkManager do the right thing here, but I have > never had a look at either for maintaining a _server_. So I will not > propose switching to those. I've put together a workaround for ifupdown that does the right thing for both dual-stack and ipv4-only instances: https://anonscm.debian.org/cgit/cloud/fai-cloud-images.git/commit/?h=dhcpv6=ff79069df0eb08634f52a355e5c578c10532479c This change isn't merged into the master branch in the fai-cloud-images repo, and I'd like others on the cloud team to review it and see if there's anything I'm missing or that could be improved. Of course, it should go without saying that such a hack is unfortunate, and it'd be preferable if ifupdown did the right thing, but as you say, it probably never will. Something similar should work for the jessie images, but I'm not familiar with how they're generated. jessie doesn't have /lib/ifupdown/wait-for-ll6.sh, so that functionality may need to be incorporated into a helper script similar to the one in my branch. The key is that /etc/network/interfaces is populated with entries of the form: iface eth0 inet dhcp iface eth0 inet6 manual up /usr/local/sbin/inet6-ifup-helper down /usr/local/sbin/inet6-ifup-helper The inet6-ifup-helper takes care of starting and stopping dhclient -6 on the appropriate interfaces. It should only exit 0, so it shouldn't interfere with ifupdown's operation. I've tested this configuration on the primary interface and on secondary interfaces on instances in both dual-stack and v4-only networks and it works as expected. I don't really like the idea of installing actual code on AMIs from the fai-cloud-images repo, but I'm not really interested in packaging inet6-ifup-helper either. I've created public AMIs ami-290ca649 (us-west-2) and ami-95a7fdf0 (us-east-2) based on these changes if anyone would like to perform additional testing... noah signature.asc Description: PGP signature
Bug#846583: cloud.debian.org: AWS Image should enable DHCPv6 client
I've played with systemd-networkd a bit. It seems capable enough to handle this use case, but it has some significant drawbacks. It's not very backward compatible with expected sysadmin patterns. That is, as a sysadmin, I'd expect ifup and ifdown to work. I expect to be able to do things like ifdown eth0& eth0 to bounce the network on an instance. And with systemd-networkd, that doesn't work. Also, since it uses a different DHCP implementation, you end up with an entirenly different set of ways of configuring dhcp client options and dhcp scripts. So, while it works, it's a big change--probably too big to introduce for stretch images. I'll also caution against systemd-resolved. I have had very bad success with the legacy DNS proxy included in systemd-resolved. Networkmanager does play less destructively with /etc/network/interfaces than systemd-networkd, although that only means they play well on the same system. But only one of them manages a given interface. I've chosen to use networkmanager on several of my cloud images, but I'm not sure it is playing great with cloudinit.
Bug#846583: cloud.debian.org: AWS Image should enable DHCPv6 client
On Thu, Dec 08, 2016 at 10:23:22PM -0800, Noah Meyerhans wrote: Hi Noah, > On Fri, Dec 02, 2016 at 12:25:44PM +0100, Bernhard Schmidt wrote: > > thanks for providing an AWS EC2 Image with Debian Jessie. > > > > AWS is now supporting IPv6 on EC2 instances, see > > > > > > https://aws.amazon.com/de/blogs/aws/new-ipv6-support-for-ec2-instances-in-virtual-private-clouds/. > > > > The support is currently limited to the zone us-east2, but should be > > available in all regions shortly. The provisioning of the IPv6 address > > on the machine is done through stateful DHCPv6. > > > > For this /etc/network/interfaces needs to be amended with > > > > iface eth0 inet6 dhcp > > Unfortunately this breaks networking for instances in subnets with IPv6 > *disabled*, which is likely the vast majority of them for the forseeable > future. Argh ... > What seems to happen is that eth0 is brought up, and dhclient runs > twice, once for each supported protocol. eth0 is properly configured > with an IPv4 address, but (after a timeout) the IPv6 dhclient reports a > failure, and ifup returns nonzero. I haven't looked deeply into exactly > what happens next, but the end result is that cloud-init never runs, so > the instance doesn't get properly configured. Most notably this means > that ssh keys aren't installed. > > I've investigated a number of possible solutions to this, but haven't > come up with anything better than shell script kludges. For example, it > could work to run the IPv6 dhclient from a post-up script associated > with eth0. > > Note that my testing has been with the stretch AMIs generated from > https://anonscm.debian.org/cgit/cloud/fai-cloud-images.git/ so it's > possible the jessie images will behave slightly differently, but I > expect them to have similar problems. Thanks for debugging this, I didn't think of this. The main problem is that one has to configure it at all for ifupdown. In IPv6 you are supposed to have a look at the O-flag (for stateless DHCPv6) or M-flag (for stateful DHCPv6) in an incoming router advertisement, and start the DHCPv6 client in an appropriate mode if necessary. Also see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=759215 I don't think this will ever be fixed with ifupdown. I think systemd-networkd and NetworkManager do the right thing here, but I have never had a look at either for maintaining a _server_. So I will not propose switching to those. Best Regards, Bernhard signature.asc Description: Digital signature
