[03:42] <Loeb> How exactly does cloud-init determine where the cloud config file is read from?
[03:45] <blackboxsw> Loeb: it depends on the datasource detected where the cloud-config sources are. `cloud-init status --long` will show you what your datasource is and may show you where the seed files for user-data is read for that datasource. `sudo cloud-init query userdata` will tell you what userdata values were read.
[03:45] <blackboxsw> ... some datasources support multiple locations for cloud-config userdata.
[03:46] <blackboxsw> your datasource docs might describe those locations https://cloudinit.readthedocs.io/en/latest/topics/datasources.html
[03:48] <Loeb> ok so, in this case I'm PXE booting and appending what I believe to be the location info in the pxelinux config. "ds=nocloud-net;s=<URL>" I believe is what is supposed to determine the location
[03:48] <Loeb> but digging through the logs it only appears to look for the "meta-data" file there, which (I think) isn't relevant in my case?
[03:49] <Loeb> That's the only thing I see it failing to read, anyhow. I also saw it didn't see a leading "#cloud-config" line at the URL pointing towards the ISO.
[03:53] <Loeb> and what I'm seeing for the nocloud config is WAY different from the config file/examples I was seeing
[03:54] <Loeb> I've been trying to set up a bare metal unattended install. From what I've seen it appears that the way to do this on ubuntu nowadays is cloud-init???
[03:55] <Loeb> I've seen documentation for anaconda, debian-installer, and now cloud-init. I could be wrong on this but the docs are a bit of a mess.
[03:55] <Loeb> The docs for the ubuntu unattended install, that is.
[04:32] <Loeb> blackboxsw, for funsies I named my config yaml file "meta-data" and touched "user-data" and "vendor-data" to see what the installer did... and I don't see any explicit errors in /var/log/cloud-init.log ? Not sure what' it's doing at this point, it drops me into the interactive ubuntu gui installer each time.
[04:33] <Loeb> I do see it grabbing the files from the network and reading them in
[09:13] <Loeb> I did have the right config, but the info needed to reside in "user-data" not "meta-data". I still find the documentation for this a bit lacking, along with cloud-init not spitting out particularly useful error messages when it say, reads an empty config file like this and defaults to something else.
[09:14] <Loeb> Regardless, it does appear to be functional now. I had a big 'ol fight with subiquity afterwords. It's problematic.
[13:49] <krysenn> Hi,
[13:49] <krysenn> I'm new with cloud-init, and i'm trying to configure an ssh key on my instance through meta-data with a NoCloud datasource, but it not works.
[13:49] <krysenn> Anybody can help me ? Thanks :)
[15:08] <meena> uh… i was gonna say they're too impatient for quitting before getting an answer, but it's been over an hour
[15:14] <Odd_Bloke> Maybe they fixed it. :p
[15:19] <testcla234> is possible to achieve this :
[15:19] <testcla234> curl https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key --keyring /usr/share/keyrings/cloud.google.gpg add -
[15:19] <testcla234> with <sources:?
[15:19] <testcla234> * with <sources:>
[15:35] <Odd_Bloke> testcla234: I don't believe so, no, unfortunately.  I think your best bet is probably to fetch the key and include it as `key` in the appropriate `sources` section.  Looks like the keys get cycled every 2/3 years, so that's not totally impossible to manage.  Not ideal, certainly!
[15:36] <testcla234> on ubuntu the 2 keys need to be store in here
[15:36] <testcla234> ls -al /usr/share/keyrings/cloud.google.gpg
[15:36] <testcla234> -rw-r--r-- 1 root root 2054 Feb 26 15:16 /usr/share/keyrings/cloud.google.gpg
[15:36] <testcla234> otherwise failed on apt update
[15:37] <testcla234> I just avoid using <source:> and use runcmd
[15:37] <Odd_Bloke> That's not the correct path for user-installed keys, /etc/apt/trusted.gpg.d/ is preferred.
[15:38] <Odd_Bloke> `runcmd` will work fine, but the key won't be in place in time for cloud-init's apt installation, I believe.
[15:38] <Odd_Bloke> If you aren't using that, not a problem, ofc.
[15:40] <testcla234> unfortunately that is the path using by google - https://cloud.google.com/sdk/docs/quickstart#installing_the_latest_version
[15:41] <testcla234> on `runcmd` I just use :
[15:41] <testcla234>  echo "deb [signed-by=/usr/share/keyrings/cloud.google.gpg] http://packages.cloud.google.com/apt cloud-sdk main" | tee -a /etc/apt/sources.list.d/google-cloud-sdk.list && curl https://packages.cloud.google.com/apt/doc/apt-key.gpg | apt-key --keyring /usr/share/keyrings/cloud.google.gpg  add - && apt-get update -y && apt-get install
[15:41] <testcla234> google-cloud-sdk -y
[15:41] <testcla234> testing now
[15:41] <Odd_Bloke> Yeah, I expect that will work.
[15:42] <Odd_Bloke> Just that's not the preferred path for keyrings that aren't installed by system packages.
[15:42] <Odd_Bloke> (And I don't know if there might be other consequences of putting it there.)
[15:47] <testcla234> is not possible to use LVM on disk_setup , right?
[16:05] <Odd_Bloke> testcla234: Correct.
[16:08] <testcla234> strange this
[16:08] <testcla234> [   35.315499] cloud-init[866]: 2021-02-26 15:54:19,903 - __init__.py[WARNING]: Unable to add group member 'user1' to group 'docker'; user does not exist.
[16:08] <testcla234> grep -i user1 /etc/passwd
[16:08] <testcla234> user1:x:1000:1001:Ubuntu:/home/user1:/bin/bash
[16:10] <testcla234> ignore this on azure the user1 seems to create after cloud-init
[16:10] <Odd_Bloke> cloud-init creates groups before it creates users (so that user definitions can refer to those groups); doing, roughly, `groups: [docker]` and `users: [{..., "groups": ["docker"]}, ...]` should work.
[16:11] <Odd_Bloke> But yeah, if that's not created by cloud-init then bets are off. :)
=== ijohnson is now known as ijohnson|lunch
=== ijohnson|lunch is now known as ijohnson