=== djhankb2 is now known as djhankb
[14:44] <minimal> any thoughts on my earlier question about ca-certs?
[14:50] <falcojr> minimal: I don't know, but if you want them removed I'm not sure why we'd just remove the pointer to them
[14:51] <falcojr> later running an 'update-ca-certificates' could bring back certs you didn't expect to be there
[14:57] <minimal> update-ca-certificates reads the /etc/ca-certificates.conf file which ca-certs empties
[14:59] <minimal> so the only certs that would come back are those from /usr/local/share/ca-certificates, but those are not "default" certs, they are site-specific certs and so I wouldn't expect a "remove defaults" option to remove them
[15:00] <minimal> the only way for the default certs to reappear would be if someone re-added their filenames to /etc/ca-certificates.conf and then ran update-ca-certificates
[15:05] <falcojr> ah, right. Yeah, I'm not sure there's a specific reason it was done this way. Is it causing problems for you?
[15:06] <minimal> it is no causing problems, it just doesn't make sense. The currently functionality both stops the certs being used but ALSO deleted the files for no apparent reason, the distro's package manager may reinstall those files upon package update
[15:07] <minimal> so I'm trying to understand why the current code works the way it does
[15:08] <minimal> it also means that if someone later wants to re-add one of the default CAs they need "fix" the problem of the missing file(s)
[15:08] <minimal> when there's no need for the files to be removed in the 1st place
[15:08] <falcojr> that code is over 10 years old, so any of the current devs will probably be guessing as to the answer
[15:10] <minimal> I've looked at the update-ca-certificates manpage for both Alpine and Debian and they both agree on how update-ca-certificates behaves. I expect Ubuntu behaves in the same way.
[15:10] <minimal> I'm not sure about RHEL, I'll have to read up on it
[15:11] <minimal> ok, I was going in raise a PR to change behaviour for Alpine but thinking about it the same change in behaviour should also apply to Debian & Ubuntu. Once I figure out how RedHat behaves I'll think about the PR
[15:14] <minimal> separate unrelated question - whilst working on a different issue I notice a c-i module is using deprecated options for a Unix utility (the utility indicates this on stdout), from checking that codebase those options were deprecated in (June?) 2014, would there be any objections to removing those CLI options from c-i's use of the command as they've been deprecated for more than 8 years now?
[15:43] <falcojr> minimal: : which utility are we talking about?
[15:51] <minimal> sfdisk
[15:52] <minimal> the "--Linux" and "--unit" option
[15:52] <minimal> I spotted this which working on fixed another issue in cc_disk_setup
[15:52] <minimal> so was thinking of removing these options as part of a PR
[15:52] <minimal> s/which/while/
[15:53] <falcojr> yeah, I think it makes sense to remove them as long as we're keeping the same behavior
[15:53] <minimal> ok, will do
[15:53] <falcojr> thanks!
[17:00] <bittin_> https://www.youtube.com/watch?v=MOmXqcRfpBI free Cloud Init course starting now
[19:09] <shivaya> hi folks, is there a post-install cloud init file that I can take a look at? as in yaml with all the options I've manually selected during the instsall
[19:37] <falcojr> shivaya: Running "cloud-init query userdata" should give you that
[19:38] <falcojr> it will also be stored in /run/cloud-init/instance-data-sensitive.json (amid other keys)
[19:39] <falcojr> erhm...actually are you referring to the user data you passed into cloud-init, or something else?
[19:39] <falcojr> I was answering the question for user data
[20:07] <minimal> Python related question, looking here: https://github.com/canonical/cloud-init/blob/main/cloudinit/config/cc_ca_certs.py#L84
[20:07] <minimal> for distro rhel, is the value of ca_cert_config then None? based on https://github.com/canonical/cloud-init/blob/main/cloudinit/config/cc_ca_certs.py#L28
[20:08] <minimal> or is it set to the value from DEFAULT_CONFIG?
[20:19] <shivaya> thanks falcojr! 
[20:23] <falcojr> minimal: It will be None
[20:30] <minimal> falcojr: that's what I though, so then the write_file later makes no sense for rhel: https://github.com/canonical/cloud-init/blob/main/cloudinit/config/cc_ca_certs.py#L157
[20:30] <minimal> I guess that's another thing for me to fix as I'm working on that module currently ;-)
[23:04] <blackboxsw> [ubuntu/lunar-proposed] cloud-init 22.4-0ubuntu4 (Accepted) upload accepted with tip of main. Contains bug fixes for (LP: #1844191, #1906849, #1992512)
[23:04] -ubottu:#cloud-init- Launchpad bug 1992512 in cloud-init "gateway4 and gateway6 have been deprecated in netplan" [High, Fix Committed] https://launchpad.net/bugs/1992512
[23:04] -ubottu:#cloud-init- Launchpad bug 1844191 in cloud-init "azure advanced networking sometimes triggers duplicate mac detection" [Critical, Confirmed] https://launchpad.net/bugs/1844191
[23:04] -ubottu:#cloud-init- Launchpad bug 1906849 in cloud-init "Support for metadata over IPv6" [Wishlist, Triaged] https://launchpad.net/bugs/1906849
[23:05] <blackboxsw> I'm syncing these fixes as well to our daily repo ppa:cloud-init-dev/daily. On Monday we'll discuss about expediting the release of 1844191
[23:06] <blackboxsw> as it stands Lunar cloudimages will contain all three fixes or features in short order.
[23:06] <blackboxsw> as it stands Lunar cloudimages will contain all three fixes or features in short order as will ppa:cloud-init-dev/daily