Loeb | How exactly does cloud-init determine where the cloud config file is read from? | 03:42 |
---|---|---|
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:45 |
blackboxsw | your datasource docs might describe those locations https://cloudinit.readthedocs.io/en/latest/topics/datasources.html | 03:46 |
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:48 |
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:49 |
Loeb | and what I'm seeing for the nocloud config is WAY different from the config file/examples I was seeing | 03:53 |
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:54 |
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. | 03:55 |
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:32 |
Loeb | I do see it grabbing the files from the network and reading them in | 04:33 |
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:13 |
Loeb | Regardless, it does appear to be functional now. I had a big 'ol fight with subiquity afterwords. It's problematic. | 09:14 |
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 :) | 13:49 |
meena | uh… i was gonna say they're too impatient for quitting before getting an answer, but it's been over an hour | 15:08 |
Odd_Bloke | Maybe they fixed it. :p | 15:14 |
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:19 |
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:35 |
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:36 |
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:37 |
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:38 |
testcla234 | unfortunately that is the path using by google - https://cloud.google.com/sdk/docs/quickstart#installing_the_latest_version | 15:40 |
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:41 |
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:42 |
testcla234 | is not possible to use LVM on disk_setup , right? | 15:47 |
Odd_Bloke | testcla234: Correct. | 16:05 |
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:08 |
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:10 |
Odd_Bloke | But yeah, if that's not created by cloud-init then bets are off. :) | 16:11 |
=== ijohnson is now known as ijohnson|lunch | ||
=== ijohnson|lunch is now known as ijohnson |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!