=== cpaelzer__ is now known as cpaelzer === vrubiolo1 is now known as vrubiolo === cpaelzer__ is now known as cpaelzer [10:50] 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] otubo: that is correct and the intended behaviour [10:54] 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:54] bugzilla.redhat.com bug 1867170 in cloud-init "[cloud-init][rhel-8.3] User password lockout when the instance cache folder re-created" [Unspecified,Assigned] [10:59] meena: on the BZ the iid is removed, but I think it was locked from the start === cpaelzer__ is now known as cpaelzer [13:52] 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] I might be being too cautious about it, I'm not sure. [13:57] otubo: I think the reasoning is just that passwordful logins are insecure, and we shouldn't default to insecure behaviour. [14:25] 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] otubo:wrt "why is lock_password the default" [14:29] if you set a password, it would make sense to allow local logins with it./ [14:36] 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] well... I think you shoudl read the statement you just wrote ;) [14:41] for clarity: "I do not think setting a password implies you want to login using that password". [14:41] that seems odd. [14:41] and then... a.) do you know if sudo will work with that password ? [14:42] so [14:42] mainly, i agree with otubo that it does seem odd. [14:42] and it is the way it is primarily because of evolution of features over time rather than concerted design. [14:52] "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] Odd_Bloke: I've never thought about that but it's intriguiing. Is that possibly, outside of a shared account/password? [15:07] 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] 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] You can disable password auth in sshd (which is the default on Ubuntu systems, either via packaging or cloud-init). [15:54] smoser: OK, I've tested and yeah, if a password is locked then it also cannot be used for sudo. [15:54] 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] (The locked password in this case being just "!" because no password was specified.) [15:57] 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] (Which I'm about to submit a PR to fix the formatting of.) [16:05] https://github.com/canonical/cloud-init/pull/577 [16:44] 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] thegreatbigbear: Are you able to pastebin (https://paste.ubuntu.com) your user-data? [16:48] Odd_Bloke https://paste.ubuntu.com/p/ngyRY2Hrzy/ [16:48] i removed the register red hat subscriptions [16:49] thegreatbigbear: Does that script complete if you run it in an interactive shell? [16:49] yep [16:49] thegreatbigbear: "!bin/bash/" isn't a valid shebang, perhaps that's causing issues? [16:50] oh yep. second eye help there [16:50] ill try it [16:51] likely will fix . [16:52] 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] If you weren't invoking it with bash explicitly, that would be a different matter. [16:53] 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] But I'm not 100% sure on that, by any means. [16:53] ya it does not background it [16:54] it follows the output [16:56] cloud-init-output.log continues to provide the out regardless of the background. I was hoping cloud init would let it go. [17:05] hmm still hanging at the same spot. [17:06] azure-user@rhel-ansible-help log]$ cloud-init status status: done [17:07] TASK [firewall : Determine if firewalld is running] **************************** [17:07] 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] thegreatbigbear: Where is it hanging? [18:07] TASK [firewall : Determine if firewalld is running] **************************** [18:07] is where it is hanging [18:09] I believe the run command is timing out. [18:15] thegreatbigbear: I suggest trying to find a minimal reproducer, then we can figure out what's going on. [18:16] 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] 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] I will update the pieces to use the right module. I think I can thin this out to a single runcmd [18:36] can you add timeouts to cloud-init. runcmd ? [19:26] 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] 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] 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] 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] cloud-init versions [19:47] What are the two versions in question? [19:47] Both centos images have selinux=permissive [19:47] 18.2 vs 20.2 [19:47] 19.4 not 20.2 sorry [19:48] ran it in the shell :( [19:48] wrong shelll* [19:48] I'm building a new image with selinux disabled to see if it still tries restoring selinux mode for / [19:48] Sure, no worries. [19:48] I was looking at https://github.com/canonical/cloud-init/blob/ubuntu/19.4-1-g8c96cbc1-0ubuntu1/ChangeLog [19:49] 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] centos7 vs 8stream [19:50] Was thinking maybe the selinux python library version might have been bumped? [19:50] OK, I suspect that the difference in behaviour lies in differences between those distro releases, rather than changes within cloud-init. [19:50] and maybe that we treat permissive different? [19:50] Yeah, something like that would do it. [19:50] or.... yea.... maybe selinux in centos8stream behaves different :) [19:51] I'm probably just going to keep it disabled instead of running permissive if that's doing it [19:52] 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] Odd_Bloke: no problem thanks for taking a peak [19:53] 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] Smithx10: Let me know if you figure it out, good luck! :) [19:58] Odd_Bloke: with it disabled and not in permissive we don't try to set selinux mode. [19:59] no more 15 seconds [19:59] I imagine the logic their may have changed.... like if selinux != disabled ; do stuff. instead of disabled || permissive [20:13] OK, nice!