=== vrubiolo1 is now known as vrubiolo
[13:33] <Krikke> hey, testing out the archlinux openstack image and a centos image with terraform libvirt provider, I can't seem to get cloud-init to run or at least it's not making any changes
[13:34] <Krikke> if cloud-init is installed in the image it should just run if the commoninit.iso is mounted or?
[13:34] <Krikke> this is on kvm/qemu
[13:37] <Krikke> hmm I'm reading now that networking should be working, does it not work with a bridge device?
[13:37] <Odd_Bloke> Krikke: cloud-init will run in some capacity on every boot (because it needs to check if this is a first instance boot to determine whether it should be doing anything more).  Do you have a /var/log/cloud-init.log in these instances?
[13:38] <Krikke> I have a hard time accessing the instances since I can't configure credentials to login
[13:38] <Krikke> is it possible to mount the qcow2 images to inspect them?
[13:39] <Krikke> I tried with this one https://linuximages.de/openstack/arch/arch-openstack-LATEST-image-bootstrap.qcow2
[13:39] <Krikke> and this one https://cloud.centos.org/centos/7/images/CentOS-7-x86_64-GenericCloud.qcow2
[13:44] <Krikke> hmm I found out how to mount the things
[13:44] <Krikke> checking the log now
[13:47] <Krikke> I added my ssh rsa public key but it still asks for password on connect to ssh
[13:48] <Krikke> 2020-09-10 13:38:06,180 - util.py[DEBUG]: Read 619 bytes from /run/cloud-init/tmp/tmpvym7iuca//user-data
[13:49] <Odd_Bloke> OK, so cloud-init is running.
[13:49] <Krikke> yeah seems so
[13:49] <Odd_Bloke> And that suggests it is finding your configuration ISO.
[13:49] <Krikke> 2020-09-10 13:38:06,180 - util.py[DEBUG]: Running command ['umount', '/run/cloud-init/tmp/tmpvym7iuca'] with allowed return codes [0] (shell=False, capture=True)
[13:49] <Krikke> 2020-09-10 13:38:06,181 - util.py[DEBUG]: Attempting to load yaml from string of length 0 with allowed root types (<class 'dict'>,)
[13:49] <Krikke> maybe I'm configuring it wrong
[13:50] <Krikke> I have everything in user-data
[13:50] <Odd_Bloke> Yeah, potentially; could you pastebin (https://paste.ubuntu.com/) your user-data?
[13:51] <Krikke> trying with this atm https://paste.ubuntu.com/p/WhMQY4cmVf/
[13:51] <Krikke> I remove the public key
[13:58] <Krikke> I don't see any mentions of my user in the logs, only the default arch user
[13:58] <Krikke> Read 0 bytes from /home/arch/.ssh/authorized_keys
[13:59] <Krikke> Writing to /home/arch/.ssh/authorized_keys - wb: [600] 0 bytes
[13:59] <Krikke> it's not even the correct user
[14:01] <rharper> Krikke: do you have #cloud-config at the top of your user-data file ?
[14:01] <Krikke> probably not
[14:01] <Krikke> is that a requirement?
[14:01] <rharper> yes
[14:01] <Krikke> oh
[14:01] <Krikke> seemed like an arbitrary comment to me :D
[14:02] <Krikke> like who forces these kind of things?
[14:02] <rharper> hehe
[14:02] <rharper> detecting whether a file is a specific sort of input needs something;
[14:03] <Krikke> as long as it's documented somewhere
[14:05] <rharper> https://cloudinit.readthedocs.io/en/latest/topics/format.html
[14:07] <Krikke> I usually skip the documentation
[14:07] <Krikke> seems I also need to recreate the volume after fixing the config
[14:09] <rharper> if it's an iso, then yes
[14:12] <Krikke> it works!
[14:12] <rharper> \o/
[14:13] <Krikke> I mean, cloud-init only runs on first boot right?
[14:13] <Krikke> so if I want to test changes to the image I need to recreate it
[14:18] <Odd_Bloke> Krikke: cloud-init runs on every boot; I actually recently wrote some documentation about it that hasn't landed yet: https://github.com/canonical/cloud-init/pull/568/files
[14:18] <Odd_Bloke> As that doc outlines, cloud-init determines whether this is an instance's first boot to decide what it will execute during this particular boot.
[14:19] <Odd_Bloke> It does this using the cache in /var/lib/cloud/; if you want to force cloud-init to detect a first boot (and therefore re-apply your configuration), then you can run `cloud-init clean`.
[14:20] <Krikke> ok
[14:20] <Odd_Bloke> Then reboot, to be clear.
[14:20] <Krikke> cool
[14:21] <Odd_Bloke> Note that that only undoes cloud-init's state: any changes you asked cloud-init to make to the system will persist.
[14:21] <Krikke> the packages section works for archlixux right?
[14:22] <Odd_Bloke> I can't speak from experience, but we have code that certainly suggests it should. :)
[14:22] <Krikke> ok :)
[14:22] <Krikke> wonder why their image doesn't provide "which" command
[14:23] <Odd_Bloke> (And the bug link is in the topic if it doesn't. ^_^)
[14:24] <Odd_Bloke> Most (all?) shells provide `which` builtin, that may be the thinking?
[14:25] <Odd_Bloke> (It's in an essential package in Debian (and therefore Ubuntu), so it's likely to be on Debian-derived systems for eternity, even if people wanted to remove it; Arch may not have had their hand forced that way.)
[14:27] <Krikke> yeah that's what is says when I do which which on my host system
[14:38] <Krikke> starting to get there, wow this is so much nicer than nixos :D
[14:56] <rharper> Quote of the day right there ^
[14:57] <smoser> Odd_Bloke:which is almost never a shell builtin
[14:57] <smoser> command -v is the posix shell builtin.
[15:04] <Odd_Bloke> Oh, huh, I did not realise that was only a zsh thing.
[15:05] <Krikke> any way to change the root shell?
[15:06] <Krikke> just add root to users section?
[15:11] <Krikke> maybe I just run chsh
[15:13] <Krikke> hmmm, cloud init is overwriting locale-gen
[15:13] <Krikke> /etc/locale.gen
[15:18] <Krikke> ah I can just override that
[15:39] <Krikke> seems the owner param doesn't work for write_files: content:
[15:42] <Krikke> need to set them in runcmd after write_files
[16:28] <rharper> Krikke: owner works.  it's but the user/group has to exist at the time the file is written; write-files runs before users-groups runs so that's likely what' you're seeing
=== MAbeeTT4 is now known as MAbeeTT
[16:29] <rharper> I have a branch, I need to put it up, called write-files-late, which would run after user-groups are created to sort out the write-file ownership issue with dynamically created user/groups
[17:58] <smoser> Krikke: that is bug https://bugs.launchpad.net/cloud-init/+bug/1486113
[17:58] <ubot5> Ubuntu bug 1486113 in cloud-init "write_files runs before users/groups, renders "owner" useless" [Medium,Triaged]
=== paride is now known as paride|off