/srv/irclogs.ubuntu.com/2020/09/18/#cloud-init.txt

=== cpaelzer__ is now known as cpaelzer
=== vrubiolo1 is now known as vrubiolo
=== cpaelzer__ is now known as cpaelzer
otuboAnyone 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
meenaotubo: that is correct and the intended behaviour10:52
otubomeena: 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=186717010:54
ubot5bugzilla.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
otubomeena: on the BZ the iid is removed, but I think it was locked from the start10:59
=== cpaelzer__ is now known as cpaelzer
Odd_Blokemeena: 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_BlokeI might be being too cautious about it, I'm not sure.13:52
Odd_Blokeotubo: I think the reasoning is just that passwordful logins are insecure, and we shouldn't default to insecure behaviour.13:57
otuboOdd_Bloke: thanks! On a side note, just got a confirmation the bug I posted is about ssh logins, and not terminal login.14:25
smoserotubo:wrt "why is lock_password the default"14:28
smoserif you set a password, it would make sense to allow local logins with it./14:29
Odd_BlokeI 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
smoserwell... I think you shoudl read the statement you just wrote ;)14:41
smoserfor clarity: "I do not think setting a password implies you want to login using that password".14:41
smoserthat seems odd.14:41
smoserand then... a.) do you know if sudo will work with that password ?14:41
smoserso14:42
smosermainly, i agree with otubo that it does seem odd.14:42
smoserand 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
beantaxiOdd_Bloke: I've never thought about that but it's intriguiing. Is that possibly, outside of a shared account/password?15:04
Odd_Blokebeantaxi: 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
beantaxiOdd_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 curious15:08
Odd_BlokeYou can disable password auth in sshd (which is the default on Ubuntu systems, either via packaging or cloud-init).15:10
Odd_Blokesmoser: OK, I've tested and yeah, if a password is locked then it also cannot be used for sudo.15:54
Odd_BlokeHowever, 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_BlokeAnd 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-groups15:57
Odd_Bloke(Which I'm about to submit a PR to fix the formatting of.)15:57
Odd_Blokehttps://github.com/canonical/cloud-init/pull/57716:05
thegreatbigbearWas 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_Blokethegreatbigbear: Are you able to pastebin (https://paste.ubuntu.com) your user-data?16:46
thegreatbigbearOdd_Bloke https://paste.ubuntu.com/p/ngyRY2Hrzy/16:48
thegreatbigbeari removed the register red hat subscriptions16:48
Odd_Blokethegreatbigbear: Does that script complete if you run it in an interactive shell?16:49
thegreatbigbearyep16:49
Odd_Blokethegreatbigbear: "!bin/bash/" isn't a valid shebang, perhaps that's causing issues?16:49
thegreatbigbearoh yep. second eye help there16:50
thegreatbigbearill try it16:50
thegreatbigbearlikely will fix .16:51
Odd_BlokePotentially; 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_BlokeIf you weren't invoking it with bash explicitly, that would be a different matter.16:52
Odd_BlokeThe 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_BlokeBut I'm not 100% sure on that, by any means.16:53
thegreatbigbearya it does not background it16:53
thegreatbigbearit follows the output16:54
thegreatbigbearcloud-init-output.log continues to provide the out regardless of the background. I was hoping cloud init would let it go.16:56
thegreatbigbearhmm still hanging at the same spot.17:05
thegreatbigbearazure-user@rhel-ansible-help log]$ cloud-init status status: done17:06
thegreatbigbearTASK [firewall : Determine if firewalld is running] ****************************17:07
thegreatbigbearsystemctl 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 ago17:07
Odd_Blokethegreatbigbear: Where is it hanging?17:59
thegreatbigbearTASK [firewall : Determine if firewalld is running] ****************************18:07
thegreatbigbearis where it is hanging18:07
thegreatbigbearI believe the run command is timing out.18:09
Odd_Blokethegreatbigbear: I suggest trying to find a minimal reproducer, then we can figure out what's going on.18:15
Odd_BlokeAs 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_Blokeotubo: 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
thegreatbigbearI will update the pieces to use the right module. I think I can thin this out to a single runcmd18:34
thegreatbigbearcan you add timeouts to cloud-init. runcmd ?18:36
Smithx10I 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 seconds19:26
Smithx10I see it setting it and then unsetting it etc  is there a way to just disable selinxu and call it a day?19:28
Smithx10digging 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_BlokeSmithx10: 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
Smithx10cloud-init versions19:46
Odd_BlokeWhat are the two versions in question?19:47
Smithx10Both centos images have selinux=permissive19:47
Smithx1018.2 vs 20.219:47
Smithx1019.4 not 20.2 sorry19:47
Smithx10ran it in the shell :(19:48
Smithx10wrong shelll*19:48
Smithx10I'm building a new image with selinux disabled to see if it still tries restoring selinux mode for /19:48
Odd_BlokeSure, no worries.19:48
Smithx10I was looking at https://github.com/canonical/cloud-init/blob/ubuntu/19.4-1-g8c96cbc1-0ubuntu1/ChangeLog19:48
Odd_BlokeSmithx10: 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
Smithx10centos7 vs 8stream19:49
Smithx10Was thinking maybe the selinux python library  version might have been bumped?19:50
Odd_BlokeOK, I suspect that the difference in behaviour lies in differences between those distro releases, rather than changes within cloud-init.19:50
Smithx10and maybe that we treat permissive different?19:50
Odd_BlokeYeah, something like that would do it.19:50
Smithx10or.... yea.... maybe selinux in centos8stream behaves different :)19:50
Smithx10I'm probably just going to keep it disabled instead of running permissive if that's doing it19:51
Odd_BlokeUnfortunately (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
Smithx10Odd_Bloke:  no problem thanks for taking a peak19:52
Smithx10I 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 seconds19:53
Odd_BlokeSmithx10: Let me know if you figure it out, good luck! :)19:54
Smithx10Odd_Bloke:  with it disabled and not in permissive we don't try to set selinux mode.19:58
Smithx10no more 15 seconds19:59
Smithx10I imagine the logic their may have changed....  like if selinux != disabled ; do stuff.  instead of disabled || permissive19:59
Odd_BlokeOK, nice!20:13

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!