| === logan_ is now known as logan- | ||
| === tds7 is now known as tds | ||
| 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 | 09:13 |
|---|---|---|
| kqkq95 | ? | 11:11 |
| === vrubiolo1 is now known as vrubiolo | ||
| === hggdh is now known as hggdh-msft | ||
| kqkq95 | nobody uses cloud-init and open-vm-tools ? | 13:19 |
| 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:28 |
| 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:32 |
| 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:33 |
| apollo13 | kqkq95: did you get guest customizations to work with a golden image against vmware? | 13:40 |
| 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:41 |
| 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:44 |
| kqkq95 | because i configure my static network with foreman who use open-vm-tools | 13:45 |
| 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:46 |
| kqkq95 | the template was created with the official CentOS ISO | 13:47 |
| kqkq95 | everything works fine without cloud-init :( | 13:48 |
| kqkq95 | ok i follow this : https://kb.vmware.com/s/article/59557 | 14:10 |
| kqkq95 | the network is now good :) | 14:10 |
| kqkq95 | but i have error in log : https://pastebin.com/X92rReed | 14:11 |
| kqkq95 | why eth0 show nothing while my network is good "ip address list" is ok | 14:14 |
| apollo13 | kqkq95: so you created the template by installing it on vmware and then convert to template? | 14:16 |
| 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:17 |
| 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:18 |
| kqkq95 | apollo13: is there a procedure or script to put on the model ? | 14:19 |
| 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:20 |
| kqkq95 | i can use : cloud-init clean | 14:24 |
| apollo13 | interesting, didn't know of that one :) | 14:24 |
| 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:26 |
| 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:27 |
| 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:28 |
| 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:29 |
| 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:30 |
| apollo13 | openstack I presume? | 14:31 |
| 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:32 |
| 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:33 |
| apollo13 | Odd_Bloke: perfect the file is there, thank you. | 14:35 |
| Odd_Bloke | OK, phew. :) | 14:37 |
| 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:38 |
| Odd_Bloke | These seem like good candidates for our roadmap for next cycle to me. | 14:39 |
| Odd_Bloke | powersj: rick_h_: ^ FYI. | 14:39 |
| rick_h_ | Odd_Bloke: cool ty | 14:40 |
| rharper | Odd_Bloke: ok | 14:50 |
| === cpaelzer__ is now known as cpaelzer | ||
| andras-kovacs | Hi! Is there a way to disable cloud-init to write in the root users's authorized-keys file? | 15:35 |
| Odd_Bloke | andras-kovacs: What is currently being written in there that you would prefer wasn't? | 15:59 |
| 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:01 |
| 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:04 |
| andras-kovacs | kqkq95: what OS do you have exactly? | 16:09 |
| 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:11 |
| blackboxsw | you should be able to provide disable_root: false to avoid adding that to /root/.ssh/authorized_keys file | 16:12 |
| 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:13 |
| andras-kovacs | I get it from a datastore but it would be enough if the default user would get it. | 16:14 |
| kqkq95 | andras-kovacs: CentOS 8 | 16:15 |
| 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:16 |
| blackboxsw | any of those keys get assigned to the default user | 16:17 |
| kqkq95 | andras-kovacs: why mv ? | 16:17 |
| 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:18 |
| 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:19 |
| 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:21 |
| 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:22 |
| Odd_Bloke | Aha, right. Still, better to express a dependency on cloud-init.target, probably? | 16:23 |
| 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:25 |
| 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:27 |
| 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:28 |
| * 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:29 |
| 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:30 |
| 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:31 |
| 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:32 |
| 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:33 |
| 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:34 |
| 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:35 |
| 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:37 |
| apollo13 | is there any way to allow password logins? | 16:38 |
| 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:39 |
| rharper | chpasswd: { expire: False } | 16:40 |
| rharper | that's in my debugging user-data | 16:40 |
| 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:41 |
| 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:42 |
| apollo13 | ah it's from the default user, nevermind | 16:43 |
| apollo13 | the docs are confusing sometimes | 16:43 |
| apollo13 | interesting enough proxmox sets chpasswd.expire: false but not ssh_pwauth :D | 16:44 |
| rharper | apollo13: yeah; some of this config is quite old so it's not well scoped under which module uses it; | 16:45 |
| apollo13 | blackboxsw: https://bugs.launchpad.net/cloud-init/+filebug ? | 16:46 |
| blackboxsw | yes please apollo13 | 16:46 |
| 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:47 |
| blackboxsw | no worries, can check that. | 16:52 |
| blackboxsw | thanks | 16:52 |
| 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] | 16:54 |
| 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:25 |
| 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 | 18:26 |
| 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:35 |
| 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:36 |
| rharper | blackboxsw: ok ... I'll try to look; grinding through some more curtin bits first | 19:40 |
| === tds7 is now known as tds | ||
| blackboxsw | rharper: responded to the big question https://github.com/CanonicalLtd/uss-tableflip/pull/45#discussion_r406505316 | 22:50 |
| blackboxsw | and updated that I misread your 2nd question there | 22:52 |
| 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:10 |
| 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:11 |
| 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 | 23:22 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!