=== cpaelzer_ is now known as cpaelzer
[10:55] <dngray[m]1> is it possible to add a repository in the archlinux cloud-init images?
[10:56] <dngray[m]1> or would i just overwrite /etc/pacman.d/mirrorlist
[12:17] <dngray[m]1> https://cloudinit.readthedocs.io/en/latest/topics/examples.html?highlight=certificate#configure-an-instances-trusted-ca-certificates
[12:17] <dngray[m]1> oh this is unlikely to work on archlinux hmm
[12:47] <dngray[m]1> stages.py[INFO]: Skipping modules 'ca-certs' because they are not verified on distro 'arch'.  To run anyway, add them to 'unverified_modules' in config.
[12:47] <dngray[m]1> oh maybe that's the issue hmm
[12:53] <skywalker> blackboxsw: it's hard to include the logs, cause there's company data i can't share
[12:53] <dngray[m]1> skywalker: can you censor them then
[12:54] <skywalker> you want logs from  packer dngray[m]1 ?
[12:54] <skywalker> blackboxsw / dngray[m]1 
[12:54] <skywalker> there's no errors in the logs
[12:54] <dngray[m]1> personally i wouldn't be supplying logs i haven't thoroughly checked for sensitive information
[12:55] <skywalker> yea, i will try to redact them
[12:55] <dngray[m]1> might give some idea what was going on
[12:55] <dngray[m]1> even if there's nothing expressly in there.
[12:55] <skywalker> k. anyway, i will do as you guys asked
[12:57] <dngray[m]1> okay so forcing ca-certs to run does not work hah
[12:57] <dngray[m]1> worth a try i guess
[12:59] <dngray[m]1> guess i could cert somewhere and make it run trust anchor --store
[13:25] <minimal> dngray[m]1: the ca-certs module was originally written for debian/ubuntu and uses the "update-ca-certificates" script. When I added Alpine support to cloud-init I modified the cc_ca_certs.py nmodule so it is supported on Alpine as it aslo has the update-ca-certificates script. Do arch have this script? If so then you could submit a PR to enable it for Arch
[13:25] <dngray[m]1> in arch i think the recommended way is to just use "trust anchor --store certname"
[13:25] <dngray[m]1> it's included in the default image
[13:26] <dngray[m]1> minimal: will do
[13:26] <dngray[m]1> archlinux comes with p11-kit
[13:26] <dngray[m]1> https://archlinux.org/packages/core/x86_64/p11-kit/
[13:26] <minimal> dngray[m]1: my point is that if you look at the cc_ca_certs.py code you will see if only (currently) supports update CA info via update-ca-certificates
[13:26] <dngray[m]1> https://p11-glue.freedesktop.org/ seems to be some distribution independent method
[13:27] <dngray[m]1> minimal: yeah, fair enough, well then it should probably support p11-kit too then
[13:27] <dngray[m]1> because iirc update-ca-certificates is only on debian distributions
[13:27] <minimal> and on alpine, that was my point :-)
[13:32] <minimal> but does p11-kit do what is required? update-ca-certificates is used to read all the various individual *.pem files in /etc/ssl/ to then create a single "bundle" PEM file containing them all concatenated
[13:32] <dngray[m]1> yes, p11-kit does, and it is included with archlinux
[13:32] <dngray[m]1> when you run "trust anchor --store certname.pem"
[13:32] <dngray[m]1> it does a few things
[13:32] <minimal> as some software (wget? curl?) only reads bundle files rather than individual PEM files
[13:32] <dngray[m]1> ill explain
[13:32] <dngray[m]1> it creates a symlink from /etc/ssl/certs/CERT_NAME_CA.pem to ../../ca-certificates/extracted/cadir/CERT_NAME.pem
[13:32] <dngray[m]1> that is read from the CN of the certificate
[13:32] <dngray[m]1> then it copies a file in /etc/ca-certificates/trust-source/CERT_NAME.p11-kit (which has some state information in it)
[13:32] <dngray[m]1> finally the actual PEM file goes in /etc/ca-certificates/extracted/cadir/CA_CERTNAME.pem
[13:32] <dngray[m]1> i think it's the method commonly used on archlinux/fedora/redhat distributions
[13:32] <dngray[m]1> in some ways archlinux is more like redhat
[13:32] <minimal> ok, but that's still 1 file per CA? or just a single resultant bundle file containing all CAs?
[13:41] <holmanb> dngray: re: adding pacman repos - we don't have a pacman config module right now, but I assume that a PR would probably be welcome. 
[13:42] <holmanb> I'm currently making some updates to the apt module regarding key management stuff. If you are looking for ideas you could take a look at that PR
[13:55] <dngray[m]1> <holmanb> "dngray: re: adding pacman repos..." <- yeah, it would be nice
[14:29] <dngray[m]1> minimal: looks like it was some time ago https://bugs.launchpad.net/cloud-init/+bug/1599694
[14:29] <ubottu> Launchpad bug 1599694 in cloud-init "RFE:  make ca-certs work on Fedora" [Wishlist, Confirmed]
[14:30] <minimal> dngray[m]1: right, so its waiting for someone to submit a PR to add support for that :-)
[14:32] <minimal> that's "add" rather than "replace" as debian, ubuntu, and alpine distros assume update-ca-certificates is the standard/only official way to manipulate their CA cert stores
[14:49] <dngray[m]1> yeah maybe lol.
[14:50] <dngray[m]1> https://bugs.launchpad.net/cloud-init/+bug/1949093
[14:50] <ubottu> Launchpad bug 1949093 in cloud-init "Pacman config module" [Undecided, New]
[14:50] <dngray[m]1> i'm new to cloud-init so can't say i'll be implementing it shortly..
=== haise01 is now known as haise01_
[17:49] <flaf> Hi @all. I'm trying to use cloud-init and network configuration via the syntax "networking config version 2". I have a simple example which doesn't seem to work => https://gist.github.com/flaf/c2402cdbae190a35809f786e8c5044a0 . Is it a bug or have I missed something? Thx for your help.
[17:54] <minimal> flaf: I generally use the old style network interface naming myself (i.e. eth0, eth1)
[17:56] <minimal> flaf: not the cloud-init docs you referenced says this about "match:" with globs (wildcards): "Note that currently only networkd supports globbing"
[17:57] <flaf> minimal: I did that before. But now I keep the names of interfaces. And I like the "networking config version 2" syntax with the "match:" key. I would like to make it work.
[17:57] <minimal> I've only used match: with mac addresses for physical machines
[17:59] <flaf> minimal: an example with "match:" here https://cloudinit.readthedocs.io/en/latest/topics/datasources/vmware.html#walkthrough <= exactly the same I have tested.
[17:59] <minimal> so are you using networkd? as that part of the docs I quoted says wildcards for "name:" inside "match:" only works with networkd
[17:59] <flaf> minimal: do you think my example is wrong?
[17:59] <minimal> are you using networkd?
[18:00] <minimal>  "Note that currently only networkd supports globbing"
[18:00] <minimal> so "name: ens*" will only work with networkd
[18:01] <minimal> I assume this means systemd-networkd
[18:04] <flaf> minimal: currently I just test in cmdline, so I thought that it was independent of the environment. Am I wrong?
[18:06] <flaf> minimal: if I replace "name: ens*" by "name: ens192", I have exactly the same problem: the generated config set an interface "id0".
[18:06] <minimal> all I can say is to repeat that the docs say what you are trying to do only works with systemd-networkd
[18:07] <minimal> if you have debugging enabled then you can "grep -i render /var/log/cloud-init.log" to see which renderer is being used (i.e. 'eni', 'networkd', etc)
[18:08] <minimal> the renderer is what converts a v1 or v2 network YAML config into the appropriate config for the machine (i.e. /etc/network/interfaces if 'eni' is the renderer)
[18:09] <flaf> minimal: https://gist.github.com/flaf/c2402cdbae190a35809f786e8c5044a0#gistcomment-3943486 <= the test without globbing.
[18:10] <flaf> minimal: ah ok. Interesting. I will try debugging in log.
[18:11] <flaf> minimal: sorry, I got to go. I'll be back. thx for your help. Indeed, it's possible that I have misunderstood the doc... I will reread it...
[18:47] <falcojr> flaf: so your example will only work if you do "--output-kind networkd" rather than "--output-kind eni"
[18:48] <falcojr> the doc minimal referencing is here: https://cloudinit.readthedocs.io/en/latest/topics/network-config-format-v2.html#common-properties-for-physical-device-types
[19:17] <flaf> falcojr: I have tried with --output-kind networkd, but the result is not correct, no? https://gist.github.com/flaf/c2402cdbae190a35809f786e8c5044a0#gistcomment-3943584 . Or I have maybe understood something wrongly?
[19:39] <minimal> flaf: what is wrong, it appears to be working as expected based on the YAML you provided
[19:39] <minimal> if you do not the interface named 'id0' then change that in the YAML to what you want it to be called
[20:07] <flaf> minimal: the doc says: "If there are match: rules, then the ID field [id0 in my case] is a purely opaque name which is only being used for references from definitions of compound devices in the config." Or maybe I have not understood the goal of "match:"?
[20:09] <flaf> minimal: for me id0 is a pure internal ID and the goal is to set dhcp for all interfaces which match with the "match:" rule.
[20:19] <minimal> flaf: I use v2 file and rename VLAN interfaces by specifying the ID value to be the name of the resultant interface
[20:19] <minimal> I haven't however used wildcards as I'm working with 'eni' (/etc/network/interfaces) which does not support wildcards
[20:20] <flaf> minimal: of course I can replace "id0" by "ens192" en remove the "match:" rule, it works. But I found the match: rule elegant because sometimes (ok it's rare) when VM are created, the name of the interface can change (ensX).
[20:22] <minimal> flaf: indeed but a "ens*" wildcard doesn't handle any potential reordering of interfaces, for that you'd need to specify "mac:" with the MAC address
[20:22] <flaf> minimal: furthermore I though that cloud-init was independent on the backend (networkd, eni, sysconfig etc.) but on this point maybe I have missunderstood the doc I admit.
[20:24] <minimal> yes the network YAML is "independant" but something has to map that to the OS-specific settings and that is the renderer: 'eni', 'netplan', 'networkd', 'sysconfig' etc
[20:29] <flaf> minimal: https://gist.github.com/flaf/c2402cdbae190a35809f786e8c5044a0#gistcomment-3943669 <= example with match: rule via macaddress and with renderer eni. I have the feeling the "match:" doesn't work well. Am I wrong?
[20:31] <flaf> In fact I never mana to make work match: in any case.
[20:31] <flaf> manage
[20:59] <minimal> as well as "macaddress:" also specify "name: ens192" and try that
[21:00] <minimal> that's what I use for physical machines
[21:30] <flaf> minimal: ok, it works. In fact, id0 is always used but a udev rule rename the interface to id0 and it's id0 which used in the network configuration.
[21:34] <flaf> minimal: anyway, thx for your help. Is there a way to have an explicit list of all files that cloud-init has changed during the boot?
[21:43] <flaf> another question: in fact the goal of "match:" rule is to match only one interface, correct?
[21:48] <flaf> Anyway, I have the feeling that match: rule with name doesn't work even with renderer == "networkd" (with or without globbing).
[21:50] <minimal> flaf: try it and see if it works, I've never used networkd renderer
[21:53] <minimal> the goal of match is to match one, or more, interfaces to apply settings - so if your machine had 4 ethernet interfaces for example you could use 2 different match rules to one ethernet to static IP and the rest to DHCP
[21:54] <flaf> OK, I see.