minimal | with the recent rationalisation of module settings' names to use underscores rather than minuses should the names of modules in cloud.cfg.tmpl also standardise on using underscores? | 13:17 |
---|---|---|
falcojr | minimal: yes, both are currently supported but we should really standardize on one | 13:18 |
minimal | perhaps I'll raise a PR to do this | 13:24 |
minimal | also I'm confused about gateway4 & gateway6 in network-config v2 - recently I noticed these were depricated so changed my YAML files to use "route" instead. However a recent PR appears to have removed the deprecated note from the docs (though I don't see which PR did it) | 13:26 |
minimal | so are gateway4/gateway6 deprecated or not for network-config v2? | 13:26 |
falcojr | we removed the deprecated note? It's still deprecated for v2. For v1, we changed the netplan implementation to use routes instead | 13:28 |
minimal | yupe, it was removed some time since Nov 21 (as I just did a "git pull" which last run then) | 13:29 |
minimal | doc/rtd/topics/network-config-format-v2.rst was updated to remove the deprecated note | 13:29 |
minimal | maybe because the previous note had a reference to "netplan#default-routes"? I'm using v2 with eni myself. | 13:30 |
falcojr | hmmm, I think that might've just been a mistake/oversight | 13:31 |
falcojr | I put up a PR to fix it. Thanks for letting us know! | 13:50 |
minimal | np, I have another related issue to investigate as I have found that using "to: default" does NOT work for network-config v2 "routes:" (at least for eni) | 14:04 |
minimal | the docs mention default but ~I had to use 0.0.0.0 to get it working | 14:05 |
Teridon | I'm having with cloud-init 22.4.2-0ubuntu0~20.04.1 . I defined 3 types of SSH host keys and certs in user-data. All 3 keys and certs ended up in /etc/ssh/, but in sshd_config, there is only one HostCertificate line for the RSA key. Did I do something wrong ? user-data excerpt : https://dpaste.org/EL03J cloud-init.log: https://dpaste.org/R1EhU | 14:22 |
Teridon | jeez. obviously. "I'm having *a problem* with ... " | 14:23 |
minimal | Teridon: I don't understand the problem, you specified 3 different certs in user_data and 3 HostCertificate lines were written | 14:28 |
falcojr | there's a single host certificate in /etc/ssh/sshd_config.d rather than all 3 | 14:29 |
minimal | ah, that it wrote 1 line, updating it 2 times | 14:29 |
falcojr | Teridon: Looks like we have a bug. Would you mind filing this at https://bugs.launchpad.net/cloud-init ? | 14:30 |
minimal | the sshd_config manpage entry for HostCertificate says "Specifies *a* file...", that's file singular | 14:31 |
Teridon | You can specify HostCertificate multiple times | 14:31 |
minimal | it's not clear if sshd_config can have multiple HostCertificate lines though | 14:31 |
minimal | ok, the manpage doesn't indicate that either way | 14:32 |
Teridon | yes it can. I do that normally on all my systems... and sshd presents the proper certificate depending on the key type you use to connect | 14:32 |
Teridon | I will file a bug, thx | 14:33 |
minimal | looks like the update_ssh_config_lines function only adds a line if it is not present and updates it otherwise, so doesn't cater for adding multiple such lines | 14:35 |
minimal | in cloudinit/ssh_util.py | 14:35 |
meena | https://github.com/canonical/cloud-init/compare/main...igalic:cloud-init:bsd/device_drivers?expand=1 i had to do this on my phone, because my laptop('s battery) died | 15:27 |
meena | minimal: netplan runs on alpine? | 15:28 |
meena | minimal: does netplan require dbus? | 15:29 |
meena | https://github.com/canonical/netplan/blob/main/meson.build#L28 can't tell if this is a joke | 15:32 |
falcojr | nah, I'm sure that find_program is searching the path...find is different | 15:33 |
meena | anyway, i can't tell from that meson file of systemd and dbus are hard dependencies | 15:35 |
meena | can't find netplan here, https://git.alpinelinux.org/aports/log/?qt=grep&q=netplan | 15:38 |
minimal | meena: no, I'm using network-config v2 with eni, not netplan | 15:43 |
minimal | what made you think I/Alpine was using netplan? | 15:43 |
meena | minimal: my misreading of what you said | 15:45 |
minimal | meena: there's no systemd on Alpine, someone tried to package it about 6 months ago and it didn't go down well... | 15:46 |
meena | yeah, just looking at netplan's code, looks like it's deeply interwoven with systemd | 15:47 |
minimal | meena: the issue with trying to get systemd on Alpine was two-fold, (1) the package submitter sort of indicated he was doing so to troll some Alpine people and (2) systemd people do not support musl and will accept any musl-related packages and so if an Alpine package was ever added it would have to carry around a large number of downstream patches forever | 15:49 |
minimal | s/will accept/will not accept/ | 15:50 |
minimal | s/packages/patches/ | 15:50 |
minimal | my typing is awful today lol | 15:50 |
meena | hands frozen? | 15:56 |
* meena points at https://github.com/freebsd/freebsd-ports/tree/main/www/chromium/files | 15:57 | |
minimal | nope, probably not enough/too much coffee ;-) | 15:57 |
meena | most of these patches are so trivial it's deeply frustrating | 16:00 |
meena | https://github.com/freebsd/freebsd-ports/blob/main/www/chromium/files/patch-chrome_browser_metrics_power_process__metrics__recorder__util.cc | 16:02 |
meena | AIX: chromium supported platform. BSD? nope | 16:03 |
Teridon | I tried to submit a bug at https://bugs.launchpad.net/cloud-init/+filebug but the site had some kind of error | 17:06 |
blackboxsw | checking Teridon an OOPS message ? | 17:07 |
Teridon | yes. Unfortunately I didn't get the code. I tried to go back to my bug form to resubmit but it was gone | 17:07 |
blackboxsw | that route looks like it works for me... checking to see if your bug got submitted | 17:07 |
blackboxsw | hrm latest bug I see is https://bugs.launchpad.net/cloud-init/+bug/1999042. so something didn't submit | 17:08 |
-ubottu:#cloud-init- Launchpad bug 1999042 in cloud-init "In openEuler, distro.osfamily is incorrect" [Undecided, New] | 17:08 | |
Teridon | let me try again I guess | 17:09 |
Teridon | Well I think I got the bug submitted (1999164) but I just failed to add an attachment (Error ID: OOPS-487354aacd8f1d4dbe05652042959d86) | 17:14 |
Teridon | got both my attachments done. I guess it was something with my proxy https://bugs.launchpad.net/cloud-init/+bug/1999164 | 17:42 |
-ubottu:#cloud-init- Launchpad bug 1999164 in cloud-init "when multiple SSH host key certificates are defined, only one HostCertificate is referenced in sshd_config" [Undecided, New] | 17:42 | |
minimal | falcojr: remember when I mentioned an issue a month ago where I was having problems on Alpine with the boot services and cloud-init.log all complained about distro being ubuntu and I eventually figured out it was a syntatically invalid /etc/cloud/cloud.cfg file? | 18:50 |
minimal | I had had another similar report on Alpine and it think it was introduced in cloud-init in a PR between 22.3 and 22.4 - the 2nd line of cloud.cfg.tmpl is a blank line and once the jinja templating occurs to create cloud.cfg that 2nd blank line becomes a blank 1st line, which yamllint says in a syntax error | 18:52 |
blackboxsw | do tell minimal: invalid YAML? | 18:52 |
blackboxsw | interesting. checking commit history there | 18:52 |
blackboxsw | wow so a blank line is a yaml error? | 18:54 |
blackboxsw | checking yamllint behavior | 18:54 |
blackboxsw | it's most likely this commit https://github.com/canonical/cloud-init/commit/cd2cca35a1 but hrm. | 18:56 |
-ubottu:#cloud-init- Commit cd2cca3 in canonical/cloud-init "Create reference documentation for base config" | 18:56 | |
minimal | blackboxsw: not simple a blank line, I believe the *1st* line of a valid YAML file cannot be blank | 19:05 |
minimal | yamllint says: | 19:06 |
minimal | 1:1 error too many blank lines (1 > 0) (empty-lines) | 19:06 |
blackboxsw | hrm.yet yaml.safe_load('\n\n1:2') seems to process fine :/ | 19:07 |
holmanb | looks like a configurable yamllint value | 19:07 |
holmanb | https://yamllint.readthedocs.io/en/stable/rules.html#module-yamllint.rules.empty_lines | 19:07 |
blackboxsw | I have no qualms with us dropping that leading new line. ... it's not needed for anything and as part of a jinja template it doesn't make sense to have the spacer anyway | 19:09 |
blackboxsw | as the file will get processed before rendering. | 19:09 |
minimal | yeah it's certainly technically not valid to have it | 19:10 |
blackboxsw | minimal: is there something else that is malformed in the jinja rendered cloud.cfg file? | 19:10 |
blackboxsw | besides the leading empty newlin | 19:10 |
minimal | it may not be the underlying cause of the issue the person is having, I'm now getting more feedback and it might be something else | 19:10 |
minimal | it seems they are replacing the cloud.cfg with their own version that doesn't have "system_info:" section or "distro:" subsection" so that's probably the root cause of their fallback to ubuntu | 19:11 |
minimal | don't know how it works for them with other distros then | 19:13 |
blackboxsw | for karma :) https://github.com/canonical/cloud-init/pull/1902 | 19:14 |
-ubottu:#cloud-init- Pull 1902 in canonical/cloud-init "cloud.cfg.tmpl: drop leading newline in jinja-rendered YAML content" [Open] | 19:14 | |
minimal | blackboxsw: I'll raise a PR to fix various cloud.cfg.tmpl warning/errors that yamllint flags | 19:15 |
blackboxsw | minimal: that's better. than my tongue in cheek pr 1902 :) | 19:16 |
blackboxsw | I'll close it | 19:16 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!