| === cpaelzer_ is now known as cpaelzer | ||
| dngray[m]1 | is it possible to add a repository in the archlinux cloud-init images? | 10:55 |
|---|---|---|
| dngray[m]1 | or would i just overwrite /etc/pacman.d/mirrorlist | 10:56 |
| 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:17 |
| 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:47 |
| 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:53 |
| 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:54 |
| 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:55 |
| 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:57 |
| dngray[m]1 | guess i could cert somewhere and make it run trust anchor --store | 12:59 |
| 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:25 |
| 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:26 |
| 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:27 |
| 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:32 |
| 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:41 |
| 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:42 |
| dngray[m]1 | <holmanb> "dngray: re: adding pacman repos..." <- yeah, it would be nice | 13:55 |
| 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:29 |
| minimal | dngray[m]1: right, so its waiting for someone to submit a PR to add support for that :-) | 14:30 |
| 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:32 |
| dngray[m]1 | yeah maybe lol. | 14:49 |
| 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.. | 14:50 |
| === haise01 is now known as haise01_ | ||
| 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:49 |
| minimal | flaf: I generally use the old style network interface naming myself (i.e. eth0, eth1) | 17:54 |
| minimal | flaf: not the cloud-init docs you referenced says this about "match:" with globs (wildcards): "Note that currently only networkd supports globbing" | 17:56 |
| 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:57 |
| 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? | 17:59 |
| minimal | "Note that currently only networkd supports globbing" | 18:00 |
| minimal | so "name: ens*" will only work with networkd | 18:00 |
| minimal | I assume this means systemd-networkd | 18:01 |
| flaf | minimal: currently I just test in cmdline, so I thought that it was independent of the environment. Am I wrong? | 18:04 |
| 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:06 |
| 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:07 |
| 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:08 |
| flaf | minimal: https://gist.github.com/flaf/c2402cdbae190a35809f786e8c5044a0#gistcomment-3943486 <= the test without globbing. | 18:09 |
| flaf | minimal: ah ok. Interesting. I will try debugging in log. | 18:10 |
| 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:11 |
| falcojr | flaf: so your example will only work if you do "--output-kind networkd" rather than "--output-kind eni" | 18:47 |
| 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 | 18:48 |
| 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:17 |
| 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 | 19:39 |
| 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:07 |
| 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:09 |
| 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:19 |
| 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:20 |
| 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:22 |
| 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:24 |
| 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:29 |
| flaf | In fact I never mana to make work match: in any case. | 20:31 |
| flaf | manage | 20:31 |
| minimal | as well as "macaddress:" also specify "name: ens192" and try that | 20:59 |
| minimal | that's what I use for physical machines | 21:00 |
| 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:30 |
| 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:34 |
| flaf | another question: in fact the goal of "match:" rule is to match only one interface, correct? | 21:43 |
| flaf | Anyway, I have the feeling that match: rule with name doesn't work even with renderer == "networkd" (with or without globbing). | 21:48 |
| minimal | flaf: try it and see if it works, I've never used networkd renderer | 21:50 |
| 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:53 |
| flaf | OK, I see. | 21:54 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!