| === cpaelzer__ is now known as cpaelzer | ||
| === vrubiolo1 is now known as vrubiolo | ||
| === cpaelzer__ is now known as cpaelzer | ||
| 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:50 |
|---|---|---|
| meena | otubo: that is correct and the intended behaviour | 10:52 |
| 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:54 |
| ubot5 | 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:54 |
| otubo | meena: on the BZ the iid is removed, but I think it was locked from the start | 10:59 |
| === cpaelzer__ is now known as cpaelzer | ||
| 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:52 |
| Odd_Bloke | otubo: I think the reasoning is just that passwordful logins are insecure, and we shouldn't default to insecure behaviour. | 13:57 |
| 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:25 |
| smoser | otubo:wrt "why is lock_password the default" | 14:28 |
| smoser | if you set a password, it would make sense to allow local logins with it./ | 14:29 |
| 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:36 |
| 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:41 |
| 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:42 |
| 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. | 14:52 |
| beantaxi | Odd_Bloke: I've never thought about that but it's intriguiing. Is that possibly, outside of a shared account/password? | 15:04 |
| 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:07 |
| 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:08 |
| Odd_Bloke | You can disable password auth in sshd (which is the default on Ubuntu systems, either via packaging or cloud-init). | 15:10 |
| 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:54 |
| Odd_Bloke | (The locked password in this case being just "!" because no password was specified.) | 15:55 |
| 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.) | 15:57 |
| Odd_Bloke | https://github.com/canonical/cloud-init/pull/577 | 16:05 |
| 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:44 |
| Odd_Bloke | thegreatbigbear: Are you able to pastebin (https://paste.ubuntu.com) your user-data? | 16:46 |
| thegreatbigbear | Odd_Bloke https://paste.ubuntu.com/p/ngyRY2Hrzy/ | 16:48 |
| thegreatbigbear | i removed the register red hat subscriptions | 16:48 |
| 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:49 |
| thegreatbigbear | oh yep. second eye help there | 16:50 |
| thegreatbigbear | ill try it | 16:50 |
| thegreatbigbear | likely will fix . | 16:51 |
| 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:52 |
| 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:53 |
| thegreatbigbear | it follows the output | 16:54 |
| thegreatbigbear | cloud-init-output.log continues to provide the out regardless of the background. I was hoping cloud init would let it go. | 16:56 |
| thegreatbigbear | hmm still hanging at the same spot. | 17:05 |
| thegreatbigbear | azure-user@rhel-ansible-help log]$ cloud-init status status: done | 17:06 |
| 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:07 |
| Odd_Bloke | thegreatbigbear: Where is it hanging? | 17:59 |
| thegreatbigbear | TASK [firewall : Determine if firewalld is running] **************************** | 18:07 |
| thegreatbigbear | is where it is hanging | 18:07 |
| thegreatbigbear | I believe the run command is timing out. | 18:09 |
| Odd_Bloke | thegreatbigbear: I suggest trying to find a minimal reproducer, then we can figure out what's going on. | 18:15 |
| 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:16 |
| 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:19 |
| thegreatbigbear | I will update the pieces to use the right module. I think I can thin this out to a single runcmd | 18:34 |
| thegreatbigbear | can you add timeouts to cloud-init. runcmd ? | 18:36 |
| 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:26 |
| 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:28 |
| 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:37 |
| 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:46 |
| 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:47 |
| 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:48 |
| 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:49 |
| 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:50 |
| Smithx10 | I'm probably just going to keep it disabled instead of running permissive if that's doing it | 19:51 |
| 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:52 |
| 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:53 |
| Odd_Bloke | Smithx10: Let me know if you figure it out, good luck! :) | 19:54 |
| Smithx10 | Odd_Bloke: with it disabled and not in permissive we don't try to set selinux mode. | 19:58 |
| 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 | 19:59 |
| Odd_Bloke | OK, nice! | 20:13 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!