| minimal | meena: likewise with LVM you'd not care (assuming roofs is a LV on LVM) | 00:14 |
|---|---|---|
| minimal | bottom line: partitions, whether on MBR or GPT are placed at specific disk sectors, you can't grow a partition if the sector after the end of that partition is allocated to another partition... | 00:16 |
| minimal | not having used ZFS I assume it works in a similar fashion to LVM, you're either not partitioning a disk or you're putting ZFS on a partition and then dividing that up inside ZFS | 00:17 |
| Ani | anyone looking at https://github.com/canonical/cloud-init/pull/3671 ? | 05:59 |
| -ubottu:#cloud-init- Pull 3671 in canonical/cloud-init "network-manager: Set higher autoconnect priority for nm keyfiles" [Open] | 05:59 | |
| meena | minimal: i reckon btrfs might also fall into this category, but I've never heard anything good said about that thing | 06:37 |
| meena | Ani: looks sensible to me, but then, i have no clue about Linux (any more) | 06:40 |
| Ani | Need someone to review and merhe | 07:04 |
| Ani | merge | 07:04 |
| === philroche_ is now known as philroche | ||
| meena | cc_rsyslog is both over engineered and underwhelming / unambitious | 13:34 |
| minimal | meena: yes apparently btrfs supports partitionless use directly on a disk (and then you use subvolumes rather than partitions), however we're talking about cloud-init's rootfs' partition growing functionality which obviously only applies where partitioning is used and where the partition containing the rootfs is not "blocked" from growing by there being another partition directly adjacent to the end of that partition | 14:00 |
| meena | minimal: i still expanded the documentation for people like me, who are not very good at knowing obvious things | 14:01 |
| meena | ready to merge: https://github.com/canonical/cloud-init/pull/4114 | 14:01 |
| -ubottu:#cloud-init- Pull 4114 in canonical/cloud-init "FreeBSD: Fix user account locking" [Open] | 14:02 | |
| meena | ready to review https://github.com/canonical/cloud-init/pull/2334 (by someone who's not cjp256 ;) | 14:03 |
| -ubottu:#cloud-init- Pull 2334 in canonical/cloud-init "FreeBSD: add ResizeGrowFS class to cc_growpart" [Open] | 14:03 | |
| minimal | meena: another "obvious" thing to point out is regarding cloud-init's "resizefs" functionality - if you do have your rootfs on LVM/btrfs subvolume/ZFS equivalent then obviously you don't want the rootfs resized to use all available space as typically the main reason to use the like of LVM (and I assume btrfs/ZFS) is so that individual LVs and filesystems can be grown and shrunk as and when required | 14:04 |
| minimal | meena: interesting to see #4114 as I thought that on BSD systems there is no separation of locking only password access and locking accounts in general | 14:09 |
| minimal | I've hit a related issue in the past with "portable OpenSSH" which treats an account with a locked password as being locked completely for SSH access (even via key), unless PAM is enabled, which seems to relate to OpenSSH's BSD original | 14:11 |
| minimal | s/original/origins/ | 14:11 |
| meena | ah, probably: OpenBSD doesn't have PAM | 14:14 |
| minimal | from https://man.freebsd.org/cgi/man.cgi?query=passwd&sektion=5 | 14:15 |
| minimal | "An encrypted password prefixed by `*LOCKED*' means that the account is temporarily locked out and no one can log into it using any authentication." | 14:15 |
| minimal | note the "using any authentication" part | 14:15 |
| minimal | so on FreeBSD if cloud-init locked the password then that means the intention is to prevent both password and SSH key-based access | 14:16 |
| meena | yeah, but look at pw(8) for comparison | 14:17 |
| meena | minimal: yeah, that was the behaviour so far | 14:17 |
| meena | reportedly bad. | 14:17 |
| minimal | meena: yes, pw(8) says "to prevent successful authentication", it doesn't say "to prevent successful *password* authentication" ;-) | 14:18 |
| minimal | so pw(8) and passwd(5) so FreeBSD appear to agree with each other | 14:18 |
| meena | minimal: did you see the section on -w ? | 14:19 |
| minimal | of pw(8)? I looked at the "USER LOCKING" section | 14:20 |
| meena | that's what we've been doing so far, but that's wrong | 14:21 |
| minimal | why is it wrong? | 14:21 |
| meena | because it completely prevents an account from logging in | 14:22 |
| minimal | that's intended as indicated in passwd(5) that I just quoted from | 14:22 |
| minimal | "An encrypted password prefixed by `*LOCKED*' means that the account is temporarily locked out and no one can log into it using any authentication." | 14:22 |
| minimal | *any* authentication | 14:22 |
| minimal | which is a difference between BSDs and Linux, in Linux locked the password is only intended to prevent password access, whereas to prevent all forms of access on Linux you'd have to set the account expiration date (from memory) | 14:24 |
| meena | my Patch changes that. however, it's still not like on Linux | 14:24 |
| minimal | meena: right but isn't your patch then going against standard BSD behaviour? | 14:25 |
| meena | I don't think so? it's just fixing a bug in cloud-init on FreeBSD | 14:26 |
| minimal | meena: confused. Do you agree that the FreeBSD passwd(5) manpage indicates that locking a password is intended to prevent all forms of access? | 14:27 |
| meena | minimal: if on Linux you set an account as locked, and your sudo requires password, can you use sudo? | 14:27 |
| minimal | I'm talking about logging into an account | 14:28 |
| meena | minimal: locking the password seems to refer to the field | 14:28 |
| minimal | the field? on FreeBSD? "no one can log into it using any authentication" | 14:29 |
| minimal | if locking the password field on FreeBSD was only intended to lock password then the manpage wouldn't say that doing so would prevent logins using *ANY* authentication | 14:30 |
| meena | A passwordof `*' indicates that password authentication is disabled for | 14:31 |
| meena | that account (logins through otherforms of authentication, e.g., using | 14:31 |
| meena | ssh(1) keys, will still work). The field only contains encrypted pass- | 14:31 |
| meena | words, and`*' cannever be the result of encrypting a password. | 14:31 |
| meena | that's the section above | 14:31 |
| meena | that's what I've changed it to | 14:31 |
| minimal | meena: are you quoting FreeBSD or Linux manpage? That looks like Linux manpage | 14:33 |
| meena | https://man.freebsd.org/cgi/man.cgi?query=passwd&sektion=5 | 14:34 |
| minimal | meena: this is not referring to a *locked* (e.g. by "pw") password however, see the next paragraph | 14:37 |
| minimal | in the case of "*" you CANNOT later unlock it as the password field only contains "*", whereas for a locked password the encrypted password is PREFIXED by "*LOCKED*" which means it can later be unlocked by removing that prefix | 14:38 |
| meena | that's why i was saying it's not entirely the same as Linux, and asking about the sudo case | 14:40 |
| meena | you unlock it, by setting a password | 14:40 |
| minimal | we are talking about controlling *logins*, using sudo isn't exactly a "login", is it switching to a different user | 14:40 |
| minimal | on both FreeBSD (with "pw unlock") and on Linux (with "passwd -u") you unlock merely by indicating which account and the previous password is reinstated | 14:42 |
| minimal | ....which is why on Linux you can't use "passwd -u" on a user account that previously didn't have a password as unlocking would leave it passwordless - "passwd -l" specifically refused to unlock in this scenario | 14:43 |
| minimal | oops s/-l/-u/ | 14:43 |
| meena | passwd -l on FreeBSD sets a NIS account to local only… | 14:45 |
| meena | that was… somewhere between bad and useless, but definitely broken. i then changed it to pw usermod -h, which, as it turns out, it's also broken | 14:46 |
| minimal | I think part of the "confusion" is that the cloud-init settings is called "lock_passwd" but the description is "Disable password login" which is not the same thing - as on some systems locking the password will disable all logins, no just via passwords. Perhaps the setting should be renamed to something like "disable_password_login" ;-) | 14:51 |
| minimal | blackboxsw, falcojr, rharper: ^^^ | 14:52 |
| meena | speaking of esoteric Systems | 14:55 |
| meena | minimal: does cc_rsyslog work on Alpine? | 14:55 |
| minimal | yes | 14:55 |
| minimal | AFAIK | 14:56 |
| minimal | (from memory) I'm using it as the default syslog daemon on my cloud-init enabled Alpine disk images | 14:57 |
| rharper | minimal: it's called lock_password because the GNU tools call it that, and it's not disabling the account, you can still get in with ssh key or some other auth, but you cannot change the account password. | 15:01 |
| rharper | passwd --lock, usermod --lock; man pages both indicate it just prevents use of the account password. | 15:02 |
| minimal | rharper: right on Linux locking the password entry is only expected to disable password acces, however on BSDs that is not the case | 15:02 |
| rharper | Yeah, I was remembering that | 15:02 |
| minimal | also the problem I had in the past is that "portable" OpenSSH does not behave that way if PAM is disable - it treats locked passwords as preventing all access *UNLESS* PAM is enabled (OpenSSH code has a specific "override" for PAM) | 15:03 |
| minimal | as "locking" does not mean the same thing on all systems, perhaps 2 different settings "disable_password_access" and "disable_account" would be less confusing/more consistent to implement? | 15:04 |
| rharper | maybe, I suppose we should construct a matrix of what locking user password does in different systems, that might help creating the right abstraction. that might just be useful docs to go along with the lock_passwd: setting ; could even be sufficient to leave lock_passwd as is and explain the differing behaviors. | 15:06 |
| rharper | is there something tunable for BSD that we'd want separately as a new key? | 15:06 |
| minimal | rharper: as I mentioned above FreeBSD's "pw" manpage indicates locking prevents all forms of login auth | 15:06 |
| rharper | and there's some other way to disable password login but not disabling account on FreeBSD ? | 15:07 |
| minimal | my own "problem" is that Alpine's sshd by default does not have PAM functionality compiled in and so "lock_passwd: true" also blocks SSH key-based access | 15:07 |
| minimal | so to date my "workaround" has been to install the alternative Alpine sshd that *does* have PAM compiled in (so increasing size of disk image) | 15:08 |
| rharper | yeah -- and I suppose other Non-PAM systems linux or BSD would have that issue. | 15:08 |
| rharper | and non-pam sshd can't do it's own ssh key auth ? | 15:09 |
| minimal | rharper: yes on FreeBSD you can set the password to just "*" to prevent password-only access, but then you can't later unlock the password as obviously there is no password to restore | 15:09 |
| minimal | I assume that Alpine is one of the few Linux distros to have a non-PAM sshd so that's why no-one else sees the issue | 15:09 |
| minimal | as for BSD, I don't know, the code for OpenSSH on BSD is not 100% the same as for non-BSD (the "portable OpenSSH" they ship) | 15:10 |
| rharper | ok | 15:11 |
| minimal | rharper: basically there's a couple of lines in "portable OpenSSH" source code that say something like: | 15:11 |
| minimal | if account password is locked; then if pam != enabled then; error "Account is locked for SSH access"; fi; fi | 15:12 |
| rharper | well, so even if we changed the key name, the net is if you set it, no account login for you | 15:14 |
| rharper | so it _seems_ to me, enough to mention this in docs, if you have non-PAM sshd or BSD ssh and no PAM, this will prevent account access. | 15:15 |
| minimal | in summary: on both Linux & BSDs method of locking passwords comes with a reprocial method to unlock (reinstate) passwords, how on some systems doing a lock doesn't have the desired (block only password access) effect | 15:15 |
| minimal | s/how/so/ | 15:15 |
| minimal | rharper: I guess it is about intentions: if I use cloud-init with both various Linux distros and FreeBSD and make use of "lock_passwd: true" I expect the end result to be the same - the account(s) has password access, but not SSH key, access disabled | 15:16 |
| rharper | but we literally cannot make them the same unless the OSes all have PAM | 15:17 |
| rharper | unless I'm missing something | 15:17 |
| rharper | systems with pam will still want a way to say, no using passwords, ssh keys only; | 15:17 |
| blackboxsw | > undigging from previous IRC thread.... From the previous conversation it sounds like there there is not an option on Alpine to lock only paswd due to missing PAM? Is there no alternative to lock only the passwd on Alpine? | 15:18 |
| rharper | systems without pam cannot do that IFAICT | 15:18 |
| rharper | blackboxsw: UUIC, you can still lock the password (put ! at the start) but sshd built-in to the image does not enable PAM, so no way to auth ssh keys to login | 15:18 |
| rharper | minimal has been using an alternative sshd (larger than the default) which as PAM, but wanted to not carry larger sshd in the image | 15:19 |
| minimal | rharper: the PAM "thing" is I think a non-BSD issue | 15:21 |
| blackboxsw | hrm docs should call that out reasonably. PAM-compiled SSH has support for ssh key based auth and we don't want to lose that if we can avoid it. Can cloud-init query whether PAM is enabled in the ssh on the system? if that's easy we could also warn in logs (limited usefulness anyway because nobody can get into the system at that point w/ an ssh key). | 15:21 |
| minimal | the same issue would appear on Ubuntu if the sshd_config had "UsePAM no" (from memory) | 15:22 |
| minimal | blackboxsw: in the case of Alpine the openssh-server's sshd is *NOT COMPLIED* with PAM, so "UsePAM" has no effect | 15:22 |
| blackboxsw | docs are needed to call this out both in the ssh lock_passwd example and the module in general. | 15:23 |
| blackboxsw | minimal: so ideally what is it you'd want to see on Alpine with a openssh-server that doesn't have PAM support compiled in? | 15:23 |
| blackboxsw | I'm keying off of Ryan's "systems with pam will still want a way to say, no using passwords, ssh keys only; " | 15:24 |
| minimal | well first you'd have to indicate which the general cloud-init functionality is supposed to be, is it meant to be "lock passwords" or "disable password logins"? ;-) | 15:25 |
| minimal | as the 2 things are not necessarily the same | 15:25 |
| minimal | the 1st thing is what the setting in c-i is called, the 2nd is the description for the setting | 15:26 |
| minimal | confused? | 15:32 |
| blackboxsw | just going through the git commit history of the original intent of the lock_passwd key from cloud-init perspective | 15:33 |
| blackboxsw | and comparing against the docs we have related to it as well. | 15:33 |
| blackboxsw | yeah generally I'd say our lock_passwd should mean/imply 'disable paswword logins' though I do see some comments float by about disabling the account as a whole. Was just doing some bug archeology to see if the original intent was expressed | 15:34 |
| minimal | I expect the vast majority of people using "lock_passwd: true" expect it to prevent password logins but let key logins still function | 15:35 |
| blackboxsw | as something different than 'disable password login' | 15:35 |
| blackboxsw | agreed. on your comment. | 15:35 |
| minimal | so then it would make sense to rename the setting to "disable_password" or similar | 15:36 |
| minimal | then I could modify alpine.py to NOT lock the password but rather replace it with "*" or "!" (forget the difference in meaning) but then "disable_password: false" (or current "lock_passwd: true") would not work on Alpine to restore the previous password | 15:38 |
| minimal | likewise on FreeBSD meena could then have freebsd.py change the password to "*" for similar functionality (and with similar limitation) | 15:39 |
| minimal | and then secondary point would be whether to add a new setting to control completely disabling an account (for password and key access) | 15:39 |
| minimal | oops s/lock_passwd: true/lock_passwd: false/ | 15:40 |
| blackboxsw | the rename is a bit more of a lift given the support/migration deprecation path. I'm wondeirng about the possibility of just adding the `disable_password` key and having BSD/Alpine leverage that with known expected behavior, Linux w/ PAM-support in openssh would still retain passswd login disabled and SSH key support on either lock_passwd or disabled_password. | 15:54 |
| blackboxsw | and we add example docs, module docs and schema docs referencing the preference for `disable_pasword` on non-PAM openssh environments. | 15:56 |
| minimal | well by rename I meant adding the new setting but keeping lock_passwd for some time in line with deprication policy | 15:56 |
| blackboxsw | I think that makes sense and probably should be floated to cloud-init mailinglist to float the proposal asynch and allow other perspectives to come in on that. | 15:57 |
| minimal | I'd say "referencing the prefernce for `disable_password` over `lock_passwd` in *all* cases" as it is then clear to the cloud-init user what the intended behaviour is | 15:58 |
| blackboxsw | and to double check here, the proposal would be for openssh with PAM-support, that those systems would continue to use `passwd -l` or some such which disables the password authentication, but leaves SSH key-based access permitted. | 16:02 |
| minimal | on Linux yes (should the cc_ssh.py code check for "EnablePAM" setting and its value in sshd_config?) | 16:03 |
| minimal | on FreeBSD then meena would have to use alternative functionality as "pw lock" prevents SSH key-based access also | 16:04 |
| blackboxsw | minimal: what would cloud-init do differently if it sees a deactivated EnablePAM setting? I think it could warn that the account is fully disabled in this case and still attempt to `passwd -l` | 16:09 |
| minimal | Good question. It should warn that account will not be accessible (on console? as if you do this for the "default" you won't be able to SSH in to check the logs lol) | 16:11 |
| blackboxsw | I'm trying to think through the use-case: If you don't have PAM enabled and you are locking the passwd of the user, you are creating some shell user/bot account for running services on the VM that you don't expect to login and you have an alternate admin/primary user that actually has access to the system maybe. | 16:13 |
| blackboxsw | I think WARNINGs should be spit out to console, so serial console access would see that true. And yes you wouldn't be able to access the system w/ that use ras it's fully locked | 16:14 |
| minimal | well the person who decided to not have PAM enabled ("disk image creator") is not necessarily the same person supplying the user-data ("end user") | 16:14 |
| minimal | so "end user" may intend the "default" account to only be accessible via SSH using key and so decides to set "disable_password: true") | 16:15 |
| blackboxsw | I'd agree, but educating them with a warning log telling them that the user is now inaccessible via ssh due to lock_passwd plus lack of PAM support in openssh would give enough of a breadcrumb that they can either opt to avoid using lock_passwd|disable_password, or opt to work with an image that has PAM | 16:15 |
| minimal | not realising the disk image comes with sshd PAM disabled and then the "end user" can't understand why they can't SSH into their newly created VM/Cloud instance... | 16:16 |
| minimal | with a warning on console, yes - in log alone is not useful if they can't SSH into to see it | 16:17 |
| blackboxsw | yes on WARN that needs to make it to console | 16:17 |
| minimal | yes as e.g. some of the older AWS instance don't have a "usable" console (there's only a way to view console output) so now way to log in via there | 16:18 |
| blackboxsw | minimal: are you aware is there any config artifact that can be queries to determine whether the openssh library has PAM support compiled in or not? I'm wondering if there are simple ways to determine whether a given pkg on Alpine would show whether PAM support is possible. Just looking through config modules to see if UsePAM = true|false doesn't really tell us for certain if the underlying libs actually honor those values | 16:23 |
| minimal | from memory if there is a "UsePAM" of *any* sort present in sshd_config then a sshd compiled without PAM support will object and fail to start | 16:25 |
| blackboxsw | but, my quesiton is if I'm on a system that has no UsePAM key (active or commented out) in /etc/ssh/sshd_config how do I know if that version of openssh supports PAM? Given that you mentioned you've installed an openssh-server w/ PAM support as a workaround, how does cloud-init know for certain on Alpine that the version of SSH we are interacting with is not capable of PAM and therefore we can't rely on `passwd -l` behavior? | 16:28 |
| minimal | yeah I just checked the "sshd" options and there's none to show programs compile info | 16:29 |
| blackboxsw | I ask that question with the underlying thought, **if** we are on Alpine and the openssh-server supports PAM, wouldn't we want behavior of disable_password to be equivalent to what we do on Linux ? | 16:29 |
| minimal | on Alpine the difference can be detected by the package name "openssh-server" vs "openssh-server-pam" | 16:30 |
| blackboxsw | yeah I was looking at deb pkg dependencies, knowing that it pulls in libpam-modules is a pretty good indicator | 16:30 |
| blackboxsw | heh. well that's a good indicator too | 16:30 |
| blackboxsw | or the fact that that pkg delivers /etc/pam.d/sshd | 16:32 |
| meena | There's no package on FreeBSD :P | 16:33 |
| meena | it's just there | 16:33 |
| meena | (until I can have my way) | 16:33 |
| blackboxsw | <<magic>>> :) | 16:33 |
| meena | blackboxsw: nah, the base system is just setup by copying base.tgz onto a disk | 16:33 |
| meena | but there's been a project underway since at least 2012 to break up the base system into packages so you don't have to recompile the whole thing just because you hate sendmail and don't want it anywhere near your system | 16:34 |
| minimal | or the binary name: /usr/sbin/sshd vs /usr/sbin/sshd.pam | 16:34 |
| meena | why are integration tests failing https://github.com/canonical/cloud-init/pull/4114 ? | 16:35 |
| -ubottu:#cloud-init- Pull 4114 in canonical/cloud-init "FreeBSD: Fix user account locking" [Open] | 16:35 | |
| blackboxsw | meena: does the base filesystem also carry an etc/pam.d/sshd config artifact? | 16:35 |
| meena | blackboxsw: yes | 16:35 |
| blackboxsw | minimal: is it possible to open a GH issue suggesting that behavior of lock_passwd on BSD/Alpine | 16:36 |
| blackboxsw | minimal: is it possible to open a GH issue suggesting that behavior of lock_passwd on BSD/Alpine/Linux is clear nor uniform on each distro and propose an alternative. We can then float that broadly for comment? | 16:36 |
| minimal | sure | 16:37 |
| meena | 👍 cc goneri | 16:37 |
| blackboxsw | thanks! I think the proposed path makes sense w/ deprectation of old keys and plan for more strict behavior related to the intent of the config key. Just want a bit of time to marinate on it and discuss async | 16:38 |
| meena | anyway, this: https://github.com/canonical/cloud-init/blob/main/cloudinit/config/cc_rsyslog.py#L70-L81 is absolutely horrific. | 16:39 |
| meena | it's from 2011, so maybe that's somewhat understandable, but still | 16:40 |
| minimal | you're welcome. The past few days seem to be the time for complex/complicated discussions lol. Just been though a whole one about Alpine's opendoas specific "extension" functionality that upstream opendoas now don't seem to want - so that's likely to result in my modifying my Alpine-specific cloud-init doas module and upstreaming it in the near future | 16:40 |
| meena | I think we should refactor cc_rsyslog to be a bit like cc_ntp | 16:47 |
| meena | The current redirecting keys mess is… a mess. | 16:47 |
| blackboxsw | meena: I'm rerunning the failed pkging job, not hitting archives for some reason was the prob | 16:55 |
| blackboxsw | on your PR | 16:55 |
| meena | blackboxsw: thank you | 17:13 |
| meena | same here https://github.com/canonical/cloud-init/actions/runs/4994414479/jobs/8944941998?pr=4115 | 17:14 |
| meena | it's there a way to (bulk) assign all (Free)BSD issues to me? | 18:14 |
| meena | https://github.com/canonical/cloud-init/issues?q=is%3Aissue+is%3Aopen+%28FreeBSD+OR+OpenBSD+OR+NetBSD+OR+BSD+OR+Dragonfly%29 | 18:16 |
| blackboxsw | meena: we can do that, though processwise I don't know if we preferred only assigning issues as an indication that they were being actively worked (as a signal that the issue may be resolved shortly)... falcojr holmanb did we chat about defining the policies for issue ownership? | 18:18 |
| blackboxsw | as an alterative I could also see distro labels being potentially valuable for ease of issue search alpine, redhat, suse, bsd, debian, but maybe we'd back ourselves into the 'too many labels' camp | 18:21 |
| meena | 👍 | 18:21 |
| meena | go uses https://github.com/golang/go/labels/OS-FreeBSD | 18:22 |
| meena | but i think in our case we can just do distro-BaseDistro if it's something affecting or relating only to a specific thing | 18:23 |
| blackboxsw | same w/ cpython https://github.com/python/cpython/labels/OS-freebsd | 18:26 |
| meena | https://github.com/rust-lang/rust/labels/O-freebsd | 18:26 |
| meena | etc | 18:26 |
| blackboxsw | I think labels may be the easiest way to go for distro-specific classes of issues. I'd +1 os-<distro> as a convention.... but leave that to others who may have strong opinions on this. | 18:27 |
| meena | can't wait until rust drops Compat for FreeBSD 10… | 18:27 |
| meena | I realise why they use os or even O: it's shorter than distro | 18:28 |
| falcojr | I'm fine with a label convention. In general, we're wary of assigning issues unless they're actively being worked on...just in case somebody else might like to pick it up in the mean time | 18:34 |
| meena | aye | 18:39 |
| meena | I just can't self assign, is all. | 18:40 |
| falcojr | is adding a comment good enough? We can always assign you based on that | 18:41 |
| meena | 👍 | 18:41 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!