| holmanb | minimal: nice :) thanks for sharing | 00:31 |
|---|---|---|
| holmanb | meena: is there anything special about freebsd on ec2 that would warrant this being datasource specific behavior? https://github.com/canonical/cloud-init/blob/040090a31f483014ec78cd353bb55bfae121bebd/cloudinit/sources/DataSourceEc2.py#L130 | 00:33 |
| meena | holmanb: what does a dhclient-script look like? | 00:39 |
| holmanb | meena: by default in cloud-init, it looks a lot like /bin/true ;) | 00:40 |
| holmanb | we use that as a hack to limit side-effects | 00:41 |
| meena | holmanb: then why does it need special-casing…? | 00:41 |
| holmanb | hrm? | 00:41 |
| holmanb | what do you mean by special-casing? | 00:41 |
| meena | or rather: What does it look like on EC2 that it needs special-casing? | 00:41 |
| holmanb | errr, I think you may be asking the same thing I am? | 00:42 |
| holmanb | I'm wondering why this behavior is specific to ec2 | 00:42 |
| holmanb | the /bin/true reference: https://github.com/canonical/cloud-init/blob/main/cloudinit/net/dhcp.py#L150 | 00:43 |
| minimal | cloudinit/net/dhcp.py also uses "-sf /bin/true" | 00:43 |
| minimal | snap :-) | 00:43 |
| holmanb | :) | 00:43 |
| minimal | holmanb: not directly related, but when I looked at the dhclient related stuff recently I was confused as to whether IPv6 is ever used (as then dhclient would need "-6" option) | 00:45 |
| meena | why use -sf then to begin with?? | 00:45 |
| minimal | meena: i think he means to avoid any script being unexpectedly used | 00:45 |
| holmanb | yeah, avoiding using the default script is I think the end goal - there isn't a way to disable running the script, so it just uses /bin/true as a no-op | 00:46 |
| holmanb | minimal: I don't htink v6 is used yet | 00:46 |
| minimal | if you don't specify "-sf" at all then /sbin/dhclient-script is used if it exists | 00:46 |
| holmanb | and since avoiding calling /sbin/dhclient-script was the goal, which freebsd didn't support, I think that's why this freebsd-specific call ended up in the ec2 datasource | 00:47 |
| holmanb | looking at the commit history that's the story I'm seeing anyways | 00:47 |
| minimal | holmanb: ok, make sense. I was just starting to sketch out udhcpc and dhcpcd support and trying to understand current dhclient behavoiur as part of that | 00:47 |
| holmanb | minimal: +1 nice, udhcp and dhcpcd are the interesting ones on the ubuntu side as well | 00:48 |
| holmanb | however some sad news on the dhcpcd side | 00:49 |
| holmanb | the last post on the mailing list | 00:49 |
| minimal | let me check..........but I can guess what it is about | 00:49 |
| meena | either someone died, or they're ending development | 00:50 |
| holmanb | somewhere in between, yeah | 00:50 |
| holmanb | https://roy.marples.name/archives/dhcpcd-discuss/0003457.html | 00:50 |
| holmanb | :/ | 00:50 |
| meena | oh gosh | 00:51 |
| holmanb | updated on github as recently as 3 months ago by Roy | 00:51 |
| minimal | oh yeah, I read that at the time, I thought something had happened recently | 00:51 |
| holmanb | not that I know of | 00:53 |
| meena | holmanb: so, to summarize: https://github.com/canonical/cloud-init/blob/main/WIP-ONGOING-REFACTORIZATION.rst . DHCP needs to move into distro. | 00:54 |
| meena | seeing as the Azure people are going to rip out their special-casing (blacklist_driver[s]), I'm going to focus on moving get_interfaces/get_interface(s)_by_mac() into distro. All the ground-work is now there in BSD. | 00:56 |
| meena | And I can probably happily ignore some weird Linux weirdnesses, especially where they are completely undocumented. | 00:56 |
| holmanb | undocumented weirdness is where the fun is at | 00:56 |
| meena | holmanb: aaaaaaand that's why i like BSD… if something is undocumented, it's a bug, but even so, at least the code is easy to read and understand… and FIND. | 00:57 |
| holmanb | heh :D | 00:58 |
| minimal | well what I was going to point out is that both dhclient and udhcpc handle IPv4 and IPv6 via two different binaries/cli calls ("dhclient" and "dhclient -6", "udhcpc" and "udhcpc6") whereas dhcpcd does/can do both via a single call | 00:59 |
| holmanb | minimal: yeah, that's one of the reasons for the dhcpcd preference on our side as well | 00:59 |
| minimal | that was why I was tryingf to figure out if existing dhclient code used "-6" or not, and if so in which situation/order | 01:00 |
| minimal | as dropping dhcpcd in "out of the box" would try both v4 & v6 unless configured othewise | 01:00 |
| holmanb | minimal: I'll be queuing up some time for provisional dhcpcd support within the next month or two | 01:01 |
| holmanb | minimal: I was just comparing the man pages side by side and noticed that as well :-) | 01:01 |
| holmanb | never used cd myself | 01:01 |
| holmanb | dhcpcd | 01:01 |
| minimal | yeah I've not had much time to do clound-init stuff recently, only got rid of other stuff yesterday so want to get some backlogged c-i changes out as PRs in the next week or so | 01:02 |
| holmanb | we have datasource-specific dhclient calls scattered about as well, which complicate the task a bit | 01:02 |
| minimal | holmanb: my brief look into udhcpc/dhcpcd was also why I started wondering about network-config v2 DHCP settings as well (and then how they'd appear in eni so I could check they'd then get acted upon correctly in Alpine) | 01:04 |
| minimal | ^ IPv6 DHCP related settings I mean | 01:05 |
| minimal | well IPv6 SLAAC/DHCPv6/RA etc | 01:05 |
| holmanb | :) | 01:06 |
| minimal | but 1st to get those other code changes out the door.... | 01:07 |
| meena | I'm fairly certain, btw, that FreeBSD's dhclient can't do DHCPv6 out of the box. You'd need to install something else… which could turn into a chicken egg problm | 01:14 |
| minimal | meena: no "-6" option for it? | 01:14 |
| meena | minimal: nope | 01:15 |
| minimal | it's ISC dhclient isn't it? | 01:15 |
| meena | https://github.com/freebsd/freebsd-src/tree/main/sbin/dhclient | 01:16 |
| meena | good grief… /*$OpenBSD: dhclient.c,v 1.63 2005/02/06 17:10:13 krw Exp $*/ | 01:16 |
| holmanb | goodness | 01:17 |
| meena | like, it's been updated, or at least secured, and all, but… brrrr… | 01:17 |
| minimal | .\" Copyright (c) 1997 The Internet Software Consortium. | 01:17 |
| minimal | so its based on ISC's code, perhaps a prehistoric version | 01:17 |
| meena | #include <sys/capsicum.h> ← "secured" | 01:18 |
| holmanb | ah, yeah there's a comment about capsicum on the manpage as well | 01:18 |
| holmanb | falls back to a chroot for sandboxing | 01:18 |
| minimal | so I guess they forked it before ISC added IPv6 support | 01:18 |
| meena | they forked it before IPv6 was standardized, minimal. | 01:19 |
| minimal | meena: doesn't make my statement incorrect though ;-) | 01:20 |
| holmanb | LOL | 01:20 |
| meena | imagine sifting thru 25 years of ISC dhcplient code to try add IPv6 support today. | 01:20 |
| minimal | wonder if there's some more recent "useful" DHCPv4 options not supported then | 01:21 |
| meena | other than -sf? 🤷🏻♀️ | 01:25 |
| meena | -1 seems useful… | 01:26 |
| minimal | well I'm guess it supports RFC3442 | 01:26 |
| minimal | meena: yupe, the c-i code uses "-1" when it calls dhclient | 01:26 |
| minimal | it runs "/usr/sbin/dhclient -1 -v -lf /run/dhclient.lease -pf /run/dhclient.pid eth0 -sf /bin/true" on Linux | 01:28 |
| holmanb | I need to run | 01:29 |
| meena | i need to sleep | 01:29 |
| holmanb | seeya o/ | 01:29 |
| minimal | cya | 01:29 |
| blackboxsw | aciba: ubuntu/devel branch merge to tip of main. I'm syncing it now, and will rekick integration test runners | 15:58 |
| aciba | blackboxsw: let's see the green color there :) | 16:01 |
| meena | minimal / holmanb: https://reviews.freebsd.org/D22012 | 16:27 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!