[12:46] e: /etc/ssh/sshd_config.d/50-cloud-init.conf generated by cloud-init I see it is removed using packages/debian/cloud-init.postrm . Since the package manager does not install the conf, could we not have cleaned it up as a part of "cloud-init clean" operation? [12:47] blackboxsw [12:47] The reason I ask is that for centos/rhel, if we took similar approach, we would have to remove it from the rpm spec file. Instead we could have a common place to remove such conf files [12:47] falcojr [12:48] Please see https://github.com/canonical/cloud-init/pull/1618 [12:48] -ubottu:#cloud-init- Pull 1618 in canonical/cloud-init "ssh_util: Handle sshd_config.d folder" [Merged] [14:52] running tox -e py3 with a freshly patched python… [15:38] https://github.com/python/cpython/pull/107813 [15:38] -ubottu:#cloud-init- Pull 107813 in python/cpython "GH-107812: extend `socket`'s netlink support to FreeBSD" [Open] === TimS is now known as TimKumina [18:18] Hey all, I was wondering, when using a datasource like Ec2, is config in /etc/cloud/cloud.cfg.d still expected to be applied? We're using some write_files in userdata in an Ec2 datasource, but also have one in /etc/cloud/cloud.cfg.d/10-local.cfg. However, the one from /etc/cloud/cloud.cfg.d is never applied and we cannot figure out why, except that [18:18] the Ec2 datasource simply overwrites the entire write_files key? [18:19] When I do "cloud-init query merged_cfg", I do see the write_files we have locally, but I'm unsure how much value the merged_cfg has in this case. [18:24] I believe that shows merged *system* config, rather than merged user-data [18:32] hmm, I guess they're used as cloud-config even if the files are missing the "#cloud-config" line [18:34] That is kinda what I expected, at least [18:34] Docs aren't super clear about it :-| Basically, I'm looking for a way to inject "vendor data" [18:35] TimKumina: I think you need to read this page: https://cloudinit.readthedocs.io/en/latest/reference/merging.html [18:35] it might also be affected by which version of cloud-init you're using [18:36] TimKumina: vendor-data? that's provided by the vendor (i.e. AWS/Ec2 in your case) [18:36] Running 23.1.1 (Ubuntu provided) and I tried adding the merge_how key to my file as well, didn't seem to make a difference [18:36] Well no, this is in premise with Hegel, which acts like Ec2 [18:36] *on premise [18:37] if you look at that page, with older versions of cloud-init you can see that merged would result in the "latest" write_files replacing any other write_files entries [18:37] that page talks about how you can control the merging behaviour [18:39] yes, by adding the merge_how key, but it seems like it's ignored [18:42] Ah, found this note: "Note, however, that merge algorithms are not used across configuration types. [18:42] As was the case before merging was implemented, user data will overwrite [18:42] 'conf.d' configuration without merging." [18:42] guess we have to look for another method, then :( [18:45] right, so merging across /etc/cloud/cloud.cfg and any other /etc/cloud/cloud.cfg.d/* files occurs, but not between /etc/cloud/* and provided user-data [18:46] what exactly are you trying to achieve though? [18:52] cluster-api provider tinkerbell does not allow overriding over userdata currently, so we're trying to hack some of our custom config either into the image or in some other way [18:52] we were hoping that there was a way to merge provided userdata with stuff on disk, but we'll go the nocloud route now and just merge the data ourselves, i think [18:53] you mentionedf write_files, so it's not exactly "user-data" but rather files on the OS you want to modify, so why not modify them when creating the OS image? [18:54] because they differ per machine (we need to set the ip address that kubelet listens on by providing a patch file to the kubeadm init process, as it does not support setting an interface instead of an ip address) [18:55] we already have per-machine manifests with networking data in cloud-config format, so we were hoping we could simply add it in there [18:55] but networking data is handled differently from other data [18:56] so this solution works for "network:", but not for "write_files:" [18:58] or rather, "network:" is not passed in the user data, which seems a more likely explanation of why this works :) [18:59] hm that gives me another idea... if i user a resource that's not passed in the userdata, it should not merge it away... [19:02] anyway, thanks for the help! off again [19:02] not sure I understand exactly what you mean [19:11] cjp256: https://github.com/python/cpython/pull/107813 [19:11] -ubottu:#cloud-init- Pull 107813 in python/cpython "GH-107812: extend `socket`'s netlink support to FreeBSD" [Open]