[10:50] <otubo> Anyone around to talk about the logic around lock_passwd=True by default? If you configure user/passwd you won't be able to login on the terminal, only ssh? Is that correct?
[10:52] <meena> otubo: that is correct and the intended behaviour
[10:54] <otubo> meena: why is that the intended behavior? And also, I guess this bug has nothing to do with it, right? https://bugzilla.redhat.com/show_bug.cgi?id=1867170
[10:59] <otubo> meena: on the BZ the iid is removed, but I think it was locked from the start
[13:52] <Odd_Bloke> meena: I don't really know; that's just an example though, my broader point is that ID_LIKE is good enough to use as a heuristic but is not (IMO) a replacement for first-class distro support in cloud-init.
[13:52] <Odd_Bloke> I might be being too cautious about it, I'm not sure.
[13:57] <Odd_Bloke> otubo: I think the reasoning is just that passwordful logins are insecure, and we shouldn't default to insecure behaviour.
[14:25] <otubo> Odd_Bloke: thanks! On a side note, just got a confirmation the bug I posted is about ssh logins, and not terminal login.
[14:28] <smoser> otubo:wrt "why is lock_password the default"
[14:29] <smoser> if you set a password, it would make sense to allow local logins with it./
[14:36] <Odd_Bloke> I don't think setting a password implies you want to login using that password; you may just want to require a password for sudo, for example.
[14:41] <smoser> well... I think you shoudl read the statement you just wrote ;)
[14:41] <smoser> for clarity: "I do not think setting a password implies you want to login using that password".
[14:41] <smoser> that seems odd.
[14:41] <smoser> and then... a.) do you know if sudo will work with that password ?
[14:42] <smoser> so
[14:42] <smoser> mainly, i agree with otubo that it does seem odd.
[14:42] <smoser> and it is the way it is primarily because of evolution of features over time rather than concerted design.
[14:52] <Odd_Bloke> "I only want to allow people to access this machine using SSH keys, and then once they are on it I further want them to have to use a password for sudo" seems very reasonable to me.
[15:04] <beantaxi> Odd_Bloke: I've never thought about that but it's intriguiing. Is that possibly, outside of a shared account/password?
[15:07] <Odd_Bloke> beantaxi: If you configure all your users with passwords and SSH keys, and configure sudo to require a password then I think you have it.
[15:08] <beantaxi> Odd_Bloke: Would that prevent a password-based normal login? Or would it allow both password and ssh. I'm not sure which is 'better', just curious
[15:10] <Odd_Bloke> You can disable password auth in sshd (which is the default on Ubuntu systems, either via packaging or cloud-init).
[15:54] <Odd_Bloke> smoser: OK, I've tested and yeah, if a password is locked then it also cannot be used for sudo.
[15:54] <Odd_Bloke> However, if you specify a password via `password: ...` then that runs later in boot than the `passwd -l` call during user creation and overwrites the "locked" password with its value.
[15:55] <Odd_Bloke> (The locked password in this case being just "!" because no password was specified.)
[15:57] <Odd_Bloke> And in the BZ in question, we lock the password because it's one of the config options for user creation which is applied to already-existing users: see the last note in https://cloudinit.readthedocs.io/en/latest/topics/modules.html#users-and-groups
[15:57] <Odd_Bloke> (Which I'm about to submit a PR to fix the formatting of.)
[16:05] <Odd_Bloke> https://github.com/canonical/cloud-init/pull/577
[16:44] <thegreatbigbear> Was hoping somone could help. I am trying to run a script in cloud-init in Azure and the script just hangs i kick the script off using runcmd. I have ran it in sh and bash same issue.
[16:46] <Odd_Bloke> thegreatbigbear: Are you able to pastebin (https://paste.ubuntu.com) your user-data?
[16:48] <thegreatbigbear> Odd_Bloke https://paste.ubuntu.com/p/ngyRY2Hrzy/
[16:48] <thegreatbigbear> i removed the register red hat subscriptions
[16:49] <Odd_Bloke> thegreatbigbear: Does that script complete if you run it in an interactive shell?
[16:49] <thegreatbigbear> yep
[16:49] <Odd_Bloke> thegreatbigbear: "!bin/bash/" isn't a valid shebang, perhaps that's causing issues?
[16:50] <thegreatbigbear> oh yep. second eye help there
[16:50] <thegreatbigbear> ill try it
[16:51] <thegreatbigbear> likely will fix .
[16:52] <Odd_Bloke> Potentially; you aren't `set -e`, so I would expect that line would emit an error but everything else would continue to run as expected.
[16:52] <Odd_Bloke> If you weren't invoking it with bash explicitly, that would be a different matter.
[16:53] <Odd_Bloke> The other thing is I'm not sure how backgrounding a task will work when the script is executed by cloud-init; if you're expecting setup.sh to run in the background while cloud-init completes independent of it, then that may also be tripping you up.
[16:53] <Odd_Bloke> But I'm not 100% sure on that, by any means.
[16:53] <thegreatbigbear> ya it does not background it
[16:54] <thegreatbigbear> it follows the output
[16:56] <thegreatbigbear> cloud-init-output.log continues to provide the out regardless of the background. I was hoping cloud init would let it go.
[17:05] <thegreatbigbear> hmm still hanging at the same spot.
[17:06] <thegreatbigbear> azure-user@rhel-ansible-help log]$ cloud-init status status: done
[17:07] <thegreatbigbear> TASK [firewall : Determine if firewalld is running] ****************************
[17:07] <thegreatbigbear> systemctl status firewalld● firewalld.service - firewalld - dynamic firewall daemon   Loaded: loaded (/usr/lib/systemd/system/firewalld.service; enabled; vendor preset: enabled)   Active: active (running) since Fri 2020-09-18 16:56:38 UTC; 10min ago
[17:59] <Odd_Bloke> thegreatbigbear: Where is it hanging?
[18:07] <thegreatbigbear> TASK [firewall : Determine if firewalld is running] ****************************
[18:07] <thegreatbigbear> is where it is hanging
[18:09] <thegreatbigbear> I believe the run command is timing out.
[18:15] <Odd_Bloke> thegreatbigbear: I suggest trying to find a minimal reproducer, then we can figure out what's going on.
[18:16] <Odd_Bloke> As it is, there's way too much non-cloud-init code being executed to understand what the issue is (and if it's even a cloud-init issue; if something you're running expects an interactive shell, then you'd see this fail but it's not a cloud-init issue).
[18:19] <Odd_Bloke> otubo: I'm updating the Python version slide for the cloud-init summit; I assume it's still true that RHEL {6, 7, 8} use Python {2.6, 2.7, 3.6}?
[18:34] <thegreatbigbear> I will update the pieces to use the right module. I think I can thin this out to a single runcmd
[18:36] <thegreatbigbear> can you add timeouts to cloud-init. runcmd ?
[19:26] <Smithx10> I dug into my logs and it looks like selinux retore "2020-09-18 19:17:11,304 - util.py[DEBUG]: Restoring selinux mode for / (recursive=True)" is taking 14 seconds
[19:28] <Smithx10> I see it setting it and then unsetting it etc  is there a way to just disable selinxu and call it a day?
[19:37] <Smithx10> digging into my 2 different images,  one restores selinux mode on /  and one doesn't  but they ahve teh same config but are different versions....  anyway to stop the "/" ?
[19:46] <Odd_Bloke> Smithx10: Disabling SELinux would be a distro question; I think cloud-init is smart enough to not do SELinux-related things if it doesn't need to (though I'm much more familiar with Ubuntu, so I may be misunderstanding something).  When you say "different versions": different versions of what?
[19:46] <Smithx10> cloud-init versions
[19:47] <Odd_Bloke> What are the two versions in question?
[19:47] <Smithx10> Both centos images have selinux=permissive
[19:47] <Smithx10> 18.2 vs 20.2
[19:47] <Smithx10> 19.4 not 20.2 sorry
[19:48] <Smithx10> ran it in the shell :(
[19:48] <Smithx10> wrong shelll*
[19:48] <Smithx10> I'm building a new image with selinux disabled to see if it still tries restoring selinux mode for /
[19:48] <Odd_Bloke> Sure, no worries.
[19:48] <Smithx10> I was looking at https://github.com/canonical/cloud-init/blob/ubuntu/19.4-1-g8c96cbc1-0ubuntu1/ChangeLog
[19:49] <Odd_Bloke> Smithx10: So I don't really see much to do with SELinux between 18.2 and 19.4, either in the changelog or the git history.  Are these the same version of CentOS?
[19:49] <Smithx10> centos7 vs 8stream
[19:50] <Smithx10> Was thinking maybe the selinux python library  version might have been bumped?
[19:50] <Odd_Bloke> OK, I suspect that the difference in behaviour lies in differences between those distro releases, rather than changes within cloud-init.
[19:50] <Smithx10> and maybe that we treat permissive different?
[19:50] <Odd_Bloke> Yeah, something like that would do it.
[19:50] <Smithx10> or.... yea.... maybe selinux in centos8stream behaves different :)
[19:51] <Smithx10> I'm probably just going to keep it disabled instead of running permissive if that's doing it
[19:52] <Odd_Bloke> Unfortunately (for you; I'm perfectly happy with this situation ;) I know next to nothing about SELinux, so I'm out of ways I can help. :)
[19:52] <Smithx10> Odd_Bloke:  no problem thanks for taking a peak
[19:53] <Smithx10> I can dig in and find it.  googling didn't really uncover anything ... because I imagine most just disable vs permissive or dont mind the 15 seconds
[19:54] <Odd_Bloke> Smithx10: Let me know if you figure it out, good luck! :)
[19:58] <Smithx10> Odd_Bloke:  with it disabled and not in permissive we don't try to set selinux mode.
[19:59] <Smithx10> no more 15 seconds
[19:59] <Smithx10> I imagine the logic their may have changed....  like if selinux != disabled ; do stuff.  instead of disabled || permissive
[20:13] <Odd_Bloke> OK, nice!