=== logan_ is now known as logan-
=== tds7 is now known as tds
[09:13] <kqkq95> hi all ! i use Cloud-init with foreman, I have a vmware template under Centos 8, and when my vm starts my network interfaces are disconnected, I use open-vm-tools-10.3.10-3.el8 and cloud-init v18.5-7.el8, and when I delete the cloud-init package from my template it works fine, I have been looking for several hours but nothing
[11:11] <kqkq95> ?
=== vrubiolo1 is now known as vrubiolo
=== hggdh is now known as hggdh-msft
[13:19] <kqkq95> nobody uses cloud-init and open-vm-tools ?
[13:28] <Odd_Bloke> johnsonshi: tox does attempt to detect when declared dependencies have changed and automatically recreate, but it isn't always perfect (as you now know ;).
[13:32] <Odd_Bloke> kqkq95: The cloud-init core team are all based in US timezones, so we're only just coming online now.  There are ongoing issues with VMWare and cloud-init, which the cloud-init core team don't have the expertise to address.  We work with the VMWare developers who contribute to cloud-init, but as we don't have a depth of VMWare knowledge (or access to different environments etc.), there's only so much we
[13:32] <Odd_Bloke> can do independent of them.
[13:33] <Odd_Bloke> kqkq95: All that said, if you could run `cloud-init collect-logs` in a failing instance and make that tarball available somewhere, then I can see if there's anything obvious going on. :)
[13:40] <apollo13> kqkq95: did you get guest customizations to work with a golden image against vmware?
[13:41] <apollo13> I always fail because vmware won't detect that the open-vm-tools are installed till I start the vm the first time
[13:41] <apollo13> which I especially do not want to do because it is a clean template
[13:41] <kqkq95> hi all
[13:44] <kqkq95> yes i use a vmware template under Centos 8, I do not know too much comment configure cloud-init with the value: disable_vmware_customization: false
[13:45] <kqkq95> because i configure my static network with foreman who use open-vm-tools
[13:46] <apollo13> kqkq95: curious, if you do not mind, how did you create the template? and does vmware detect guest customizations in the template without ever starting the template on vmware?
[13:47] <kqkq95> the template was created with the official CentOS ISO
[13:48] <kqkq95> everything works fine without cloud-init :(
[14:10] <kqkq95> ok i follow this : https://kb.vmware.com/s/article/59557
[14:10] <kqkq95> the network is now good :)
[14:11] <kqkq95> but i have error in log : https://pastebin.com/X92rReed
[14:14] <kqkq95> why eth0 show nothing while my network is good "ip address list" is ok
[14:16] <apollo13> kqkq95: so you created the template by installing it on vmware and then convert to template?
[14:17] <apollo13> Odd_Bloke: are you around by any chance and can help me with an ubuntu cloud image? I am trying to get rid of the console changes they do for grub
[14:17] <kqkq95> appollo13: yes
[14:17] <kqkq95> apollo13: yep
[14:17] <apollo13> kqkq95: ah okay, how do you clean the system up afterwards?
[14:18] <apollo13> although I guess you might just rely on cloud-init to set machine-id to something new etc
[14:18] <kqkq95> apollo13: iarf
[14:18] <apollo13> I went another way and used virt-sysprep to pregenerate clean images but then vmware won't realize that they include guest tools *shrug*
[14:18] <kqkq95> apollo13: I don't clean...
[14:19] <kqkq95> apollo13: is there a procedure or script to put on the model ?
[14:20] <apollo13> na I scripted it myself with packer from hashicorp to automate the install and then cleaned it with virt-sysprep and generated an ova that I could import in vmware
[14:24] <kqkq95> i can use : cloud-init clean
[14:24] <apollo13> interesting, didn't know of that one :)
[14:26] <kqkq95> ok cloud-init show all my interfaces when i run cloud-init init :)
[14:26] <kqkq95> but why he says "Did not find any data source, search classes"
[14:27] <kqkq95> i setup a file name 10_foreman.cfg in directory /etc/cloud/cloud.cfg.d/
[14:27] <Odd_Bloke> apollo13: Sure, what's up?
[14:28] <apollo13> Odd_Bloke: so ubuntu cloud-init images inject console=tty1 console=ttyS0 into grub.cfg
[14:28] <apollo13> somewhere very early, I am trying to find out were so I can remove that
[14:28] <Odd_Bloke> I believe it's in the shipped image.
[14:28] <apollo13> not exactly sure why one would want a serial console :)
[14:28] <apollo13> yes, but where :)
[14:28] <apollo13> I am remastering the image with guestfish and I'd like to get rid of that
[14:29] <Odd_Bloke> Oh, I see, you're asking where it's configured in the image?
[14:29] <apollo13> debian had it in /etc/default/grub, ubuntu has it (after boot) in /etc/default/grub.d/50-cloudinit-settings.cfg
[14:29] <Odd_Bloke> /etc/default/grub.d/50-cloudimg-settings.cfg
[14:29] <apollo13> but the latter only exists after first boot?
[14:30] <Odd_Bloke> I don't think so, I think it's in the shipped image.
[14:30] <apollo13> let me recheck
[14:30] <Odd_Bloke> (As an aside, the Ubuntu cloud images are designed to boot in as many scenarios as possible, and some places need a serial console for that.)
[14:31] <apollo13> openstack I presume?
[14:32] <apollo13> you might be right, I just checked the sha on my image and it doesn't match the one from https://cloud-images.ubuntu.com/focal/current/SHA1SUMS -- maybe I deleted it already
[14:32] <apollo13> let me redownload that
[14:33] <Odd_Bloke> I'm not sure off-hand which scenarios require it, but given how configurable OpenStack is, I'm sure there are OpenStacks that require it, yeah. :p
[14:33] <apollo13> the funny thing is that by requiring a serial console it doesn't work on proxmox etc by default
[14:33] <apollo13> or rather then I have to switch to serial and I rather have spice displays
[14:35] <apollo13> Odd_Bloke: perfect the file is there, thank you.
[14:37] <Odd_Bloke> OK, phew. :)
[14:38] <Odd_Bloke> rharper: blackboxsw: openssh now (in focal since February) supports .d directories for ssh_config and sshd_config.  I've filed two bugs related to this (basically, one for reading, one for writing): https://bugs.launchpad.net/cloud-init/+bug/1871858 https://bugs.launchpad.net/cloud-init/+bug/1871859
[14:38] <ubot5> Ubuntu bug 1871858 in cloud-init "cloud-init should support parsing ssh_config/sshd_config files with Include directives" [Undecided,New]
[14:38] <ubot5> Ubuntu bug 1871859 in cloud-init "cloud-init should write ssh_config.d/sshd_config.d snippets (when supported) instead of modifying config files" [Undecided,New]
[14:39] <Odd_Bloke> These seem like good candidates for our roadmap for next cycle to me.
[14:39] <Odd_Bloke> powersj: rick_h_: ^ FYI.
[14:40] <rick_h_> Odd_Bloke:  cool ty
[14:50] <rharper> Odd_Bloke: ok
=== cpaelzer__ is now known as cpaelzer
[15:35] <andras-kovacs> Hi! Is there a way to disable cloud-init to write in the root users's authorized-keys file?
[15:59] <Odd_Bloke> andras-kovacs: What is currently being written in there that you would prefer wasn't?
[16:01] <andras-kovacs> Odd_Bloke:  no-port-forwarding,no-agent-forwarding,no-X11-forwarding,command="echo 'Please login as the user \"myusername\" rather than the user \"root\".';echo;sleep 10" + my pubkey
[16:01] <andras-kovacs> Nothing, I decided to remove the whole file in the end with runcmd.
[16:04] <kqkq95> ok I have made good progress in my problem, my configuration seems good, but it seems that the client cannot reach foreman, the flows are however very open
[16:04] <kqkq95> error here : https://pastebin.com/hqnMrZFy
[16:09] <andras-kovacs> kqkq95: what OS do you have exactly?
[16:11] <andras-kovacs> what does systemctl status cloud-init.target says?
[16:11] <blackboxsw> andras-kovacs: I think you are looking at #cloud-config`disable_root` and `disable_root_opts` settings
[16:11] <blackboxsw>     disable_root: <true/false>
[16:11] <blackboxsw>     disable_root_opts: <disable root options string>
[16:11] <blackboxsw> https://cloudinit.readthedocs.io/en/latest/topics/modules.html#authorized-keys
[16:12] <blackboxsw> you should be able to provide disable_root: false to avoid adding that to /root/.ssh/authorized_keys file
[16:13] <blackboxsw> andras-kovacs: or alternately you could provide a different set of opts than the default .... no-port-forwarding,no-agent-forwarding,no-X11-forwarding,command
[16:13] <blackboxsw> by setting disable_root_opts: 'something else'
[16:13] <andras-kovacs> thank you! and what about the ssh pubkey?
[16:14] <andras-kovacs> I get it from a datastore but it would be enough if the default user would get it.
[16:15] <kqkq95> andras-kovacs: CentOS 8
[16:16] <andras-kovacs> kqkq95: if cloud-init services are enabled, no file or kernel parameter which disables it, try:
[16:16] <andras-kovacs> mv /etc/systemd/system/cloud-init.target.wants/cloud-* /etc/systemd/system/multi-user.target.wants/
[16:16] <andras-kovacs> cloud-init clean --reboot
[16:16] <blackboxsw> andras-kovacs: ssh_import_id: [gh:<youruser]   or [lp:<youruser>]   or ssh_authorized_keys per https://cloudinit.readthedocs.io/en/latest/topics/examples.html#configure-instances-ssh-keys
[16:17] <blackboxsw> any of those keys get assigned to the default user
[16:17] <kqkq95> andras-kovacs: why mv ?
[16:18] <andras-kovacs> There was a significant change with cloud-init in RHEL. Previously all these services were wanted by the multiuser.target
[16:18] <andras-kovacs> now it moved to it's custom, cloud-init.target
[16:18] <andras-kovacs> It's not working for me either in RHEL 7.8
[16:18] <andras-kovacs> https://bugzilla.redhat.com/show_bug.cgi?id=1820540
[16:18] <ubot5> bugzilla.redhat.com bug 1820540 in cloud-init "cloud-init package broken post 7.8 upgrade" [Medium,Assigned]
[16:19] <andras-kovacs> I know the mv part is dirty, but it is the easiest way to test it IMHO
[16:19] <kqkq95> my unit vloud* is already on multi-user.target.wants
[16:19] <kqkq95> *cloud
[16:21] <Odd_Bloke> Moving units around is very heavyweight (and could cause upgrade problems), it would be better to add additional dependencies IMO.
[16:21] <kqkq95> andras-kovacs: cloud-init target does not exist, I have cloud-config.service, cloud-final.service, cloud-init-local.service and cloud-init.service
[16:21] <andras-kovacs> which version of cloud-init do you have there? :O
[16:22] <kqkq95> 18.5-7.el8
[16:22] <andras-kovacs> Odd_Bloke: these are not the units just the symlinks :) Easy to revert/disable them.
[16:23] <Odd_Bloke> Aha, right.  Still, better to express a dependency on cloud-init.target, probably?
[16:25] <andras-kovacs> with systemctl edit yes
[16:25] <andras-kovacs> but it was the shortest and fastest idea to test it
[16:25] <andras-kovacs> but cloud-init.target is not there
[16:25] <kqkq95> yes
[16:27] <apollo13> ha I have the same question as andras-kovacs, disable_root: false and ssh_authorized_keys still writes to root as well as the configured user
[16:28] <apollo13> just tested on ubuntu focal
[16:28] <andras-kovacs> runcmd:
[16:28] <andras-kovacs>  - rm -f /root/.ssh/authorized_keys
[16:28] <andras-kovacs> it will be fine for me
[16:28] <apollo13> that will work, but if my user actually set root as the default user I'd remove that again…
[16:29]  * apollo13 checks cloud-init source
[16:29] <andras-kovacs> oh you are right :S
[16:29] <andras-kovacs> but the funny thing is runcmd doesn't work if there is LVM on the server (which is sick in cloud env, I know I know.. .but still a requirement)
[16:29] <andras-kovacs> And there is no info in the logs about it why :(
[16:30] <andras-kovacs> at the end of the day I made a custom systemd unit which replaces the runcmd part and destroys itself
[16:30] <apollo13> looking at current master of cloud-init: https://dpaste.org/zi5J/raw
[16:30] <andras-kovacs> and noone should use the root user as the default one
[16:31] <apollo13> doesn't look as if there were __any__ way to disable setting the key for root
[16:31] <andras-kovacs> openssh is not bulletproof (nothing is)
[16:31] <blackboxsw> apollo13:/andras-kovacs hrm right disable_root is actually saying any configured ssh keys are put in both root and <default_user> because we expect users may have accidentally tried to login as root and we steer them to the actual default user instead with a printed message breadcrumb.
[16:31] <rharper> andras-kovacs: there's no interesection between lvm and runcmd ...     are you seeing an error in cloud-init status or cloud-init.log ?    or expecting output from runcmd to be somewhere on the filesystem and it's not ?
[16:31] <apollo13> blackboxsw: yeah I'd like to prevent that because it leaks user information
[16:31] <blackboxsw> so apollo13 andras-kovacs is the feature, that you want cloud-init to avoid touching root at all?
[16:32] <blackboxsw> and only setup default_user
[16:32] <kqkq95> andras-kovacs: no idea for me :(
[16:32] <andras-kovacs> yes
[16:32] <apollo13> blackboxsw: if use X is configured as default_user I do not want the ssh keys applied to root
[16:32] <apollo13> yes
[16:32] <apollo13> if user X *
[16:33] <andras-kovacs> blackboxsw: I totally got your point and I was thinking previously like how smart was it.
[16:33] <apollo13> andras-kovacs: funny though that we have the same problem the same day :D and I am pretty sure I do not know you
[16:33] <andras-kovacs> to think about this scenario
[16:33] <blackboxsw> I know there is a way to avoid dropping keys in root && default_user. just trying to think it through.
[16:34] <andras-kovacs> set an immutable flag on it (but cloud-init would probably fail?)
[16:34] <apollo13> blackboxsw: looking at the link I just posted from cloud-init master I doubt it
[16:34] <andras-kovacs> I'll remove it at the end, that should be ok.
[16:35] <apollo13> andras-kovacs: setting immutable would work, but that also means you have to generate .ssh/authorized_keys in the first place since it's not there by default
[16:37] <andras-kovacs> apollo13: yes and I have a feeling cloud-init would fail (maybe silently) if it can't write there
[16:37] <andras-kovacs> so I'll remove the file in the runcmd part at the end
[16:38] <apollo13> is there any way to allow password logins?
[16:39] <apollo13> and yes I know it's insecure, but it is just to allow initial login on the box and easy testing, our cfg mgmt will forbid it globally anyways
[16:39] <rharper> ssh_pwauth: True
[16:39] <rharper> password: XXXXXX
[16:39] <apollo13> ah thx
[16:40] <rharper> chpasswd: { expire: False }
[16:40] <rharper> that's in my debugging user-data
[16:41] <blackboxsw> andras-kovacs: apollo13 yeah looks like a feature request for cloud-init to avoid reflecting/disabled keys into 'root' user's authorized_keys file.
[16:41] <blackboxsw> as you mentioned.
[16:42] <blackboxsw> a bug would be nice for that and upstream can discuss whether this is a feature is something that we will be tackling in short term.
[16:42] <apollo13> rharper: mhm, I am having a hard time finding what "password" does
[16:43] <apollo13> ah it's from the default user, nevermind
[16:43] <apollo13> the docs are confusing sometimes
[16:44] <apollo13> interesting enough proxmox sets chpasswd.expire: false but not ssh_pwauth :D
[16:45] <rharper> apollo13: yeah;  some of this config is quite old so it's not well scoped under which module uses it;
[16:46] <apollo13> blackboxsw: https://bugs.launchpad.net/cloud-init/+filebug ?
[16:46] <blackboxsw> yes please apollo13
[16:47] <blackboxsw> just describe the feature and we'll triage it and determine how best to address it.
[16:47] <apollo13> ffs I tried searching if such a bug already exists but timeout error on search
[16:47] <apollo13> so might be a dupe :/
[16:52] <blackboxsw> no worries, can check that.
[16:52] <blackboxsw> thanks
[16:54] <apollo13> blackboxsw: https://bugs.launchpad.net/cloud-init/+bug/1871879 -- not the end of the world for me, but would be nice if there were an option to disable it. Thanks for caring!
[16:54] <ubot5> Ubuntu bug 1871879 in cloud-init "Configuring a user should not configure root's authorized_keys" [Undecided,New]
[18:25] <blackboxsw> Odd_Bloke: rharper I have updated the branching/cherry-pick process spec https://hackmd.io/VbmtcZLyR4650aqqmfMMYg  to reflect yesterday's conversation and I have updated tooling to codify that.
[18:26] <blackboxsw> I'm about to push up doc changes to uss-tableflip PR#45 and cloud-init PR 308 with the steps to fix daily build recipe
[19:35] <blackboxsw> ok rharper Odd_Bloke I've closed 308  in favor of manual PR https://github.com/canonical/cloud-init/pull/312 for fixing ubuntu daily build recipe
[19:36] <blackboxsw> thanks for the discussions yesterday about the best approach for branch management to avoid push/pop of cpicks in the ubuntu/series branches
[19:40] <rharper> blackboxsw: ok ... I'll try to look;  grinding through some more curtin bits first
=== tds7 is now known as tds
[22:50] <blackboxsw> rharper: responded to the big question https://github.com/CanonicalLtd/uss-tableflip/pull/45#discussion_r406505316
[22:52] <blackboxsw> and updated that I misread your 2nd question there
[23:10] <blackboxsw> I think I may have missed the point of your question about 'only needing the commit' from ubuntu/devel in ubuntu/daily/devel in order to revert.
[23:11] <blackboxsw> so I think on rereading the 3rd time yoy may have meant that ubuntu/daily/devel could actually just 'git cherry-pick cpick_commit_from_ubuntu_devel; git revert cpick_commit_from_ubuntu_devel' ? maybe
[23:22] <blackboxsw> the issue with just git cherry-picking a single commit into ubuntu/daily/devel and reverting it is that ubuntu/daily/devel is essentially a downstream, so that revert we'd perform there is on a comittish that is local only do ubuntu/daily/devel branch, so it won't revert the parent's commitish.
[23:22] <blackboxsw> ... when we merge back ubuntu/daily/devel into ubuntu/devel for daily recipe builds