[13:37] hey folks, I don't believe the user module includes a way to specify the desired userid of the admin/default user, is there ? [13:39] esv: I think only if you override the default user with your own definition [13:40] yeah, have "users:\n- default\n- \n uid: 1234\n" [13:40] I am looking at the docs, I don't see a uid field. [13:41] https://cloudinit.readthedocs.io/en/latest/reference/modules.html#users-and-groups [13:42] "uid: (integer/string) The user’s ID. Default is next available value.." [13:43] minimal: your snippet will work for normal users, but not the default user, right? For the default user I think don't include '- default' and manually create the user [13:44] I did not see the uid field in this page, https://cloudinit.readthedocs.io/en/latest/reference/examples.html , I guess the one you pointed is more relevant [13:44] falcojr: I do something similar to that when I want to override some settings for the default user. Perhaps it doesn't work for a fields? [13:44] esv: look at the link I posted [13:44] the examples page does not necessarily give examples of everything [13:44] yep [13:44] thnx [13:46] falcojr: e.g. I use that method to set the ssh_authorized_keys value for the default account [13:47] minimal: the default account being the one created by cloud-init? Not "your" default? [13:48] falcojr: yes [13:50] I guess it depends on how exactly this is handled, is the default user settings (from /etc/cloud/cloud.cfg) merged with the user-data values (I think) so before account creation [13:50] as the docs say "Most of these configuration options will not be honoured if the user already exists." [13:51] gotcha, yeah that makes sense [13:52] so on Alpine Linux, where "alpine" is the default this works fine: [13:52] users: [13:52] - default [13:52] - name: alpine [13:52] ssh_authorized_keys: [13:52] - > [13:52] ssh-ed25519 [13:52] ...... [13:55] I'm trying to modify the uid of the default user :D [13:55] esv: yeah, I was just giving falcojr a general example of what works for me [14:15] while waiting for some hardware to magically drop in front of me, I've been trying to get FreeBSD to work on LXD, so it could be integrated into tests at some point [14:17] i got it to boot, https://github.com/freebsd/freebsd-src/pull/664 but the performance is abysmal, thanks to a virtio random bug, so I've been stuck in kgdb for two days [14:17] -ubottu:#cloud-init- Pull 664 in freebsd/freebsd-src "apic: prevent divide by zero in CPU frequency init" [Closed] [14:20] meena: a random bug with random? ;-) [14:33] minimal: it's been a while that I've been this deep a rabbit hole filled with yaks that all need shaving [14:56] hello holmanb, first of all, thanks for your quick first pass on of https://github.com/canonical/cloud-init/pull/2033 [14:56] -ubottu:#cloud-init- Pull 2033 in canonical/cloud-init "Adapt DataSourceScaleway to IPv6" [Open] [14:56] I've made sensible modifications following your suggestions/comments [14:57] caribou: welcome :) [14:58] caribou: I'll try to give it another review today [14:59] you were right that using url_helper.wait_on_url() makes things sensibly simpler [15:00] glad to hear it [21:24] what would be the expected interaction if kernel command line had both cloud-config-url and ds arguments? [21:58] dbungert: hadn't thought about it, but looks like cloud-init writes out custom config file to /etc/cloud/cloud.cfg.d/91_kernel_cmdline_url.cfg https://github.com/canonical/cloud-init/blob/main/cloudinit/cmd/main.py#L298 [21:58] since files on the system override config from the datasource, I think cmdilne config wins if any config keys conflict... but I'll have to check how that's merged [22:00] and given that the /proc/cmdline read is done before init.read_cfg() is called, the datasource detected would be able to see the config from disk during its initialization