lock passwd implemented wrong on FreeBSD

i think i misinterpreted the failure here…
I got a password prompt for root, and assumed it came from a `passwd -l root` call, but the same could be easily true of the equally wrong implementation we have here:

    def lock_passwd(self, name):
        try:
            util.subp(['pw', 'usermod', name, '-h', '-'])
        except Exception as e:
            util.logexc(LOG, "Failed to lock user %s", name)
            raise e

this means, modify this user, read input from the FD supplied after -h, in this case, stdin.

okay, so, here's the log output from (re-)running cloud-init clean --logs --reboot:

2019-12-04 10:25:32,678 - handlers.py[DEBUG]: start: init-network/config-users-groups: running config-users-groups with frequency once-per-instance
2019-12-04 10:25:32,678 - util.py[DEBUG]: Writing to /var/lib/cloud/instances/3623889/sem/config_users_groups - wb: [644] 26 bytes
2019-12-04 10:25:32,680 - helpers.py[DEBUG]: Running config-users-groups using lock (<FileLock using file '/var/lib/cloud/instances/3623889/sem/config_users_gr
oups'>)
2019-12-04 10:25:32,681 - __init__.py[INFO]: User root already exists, skipping.
2019-12-04 10:25:32,682 - util.py[DEBUG]: Running command ['passwd', '-l', 'root'] with allowed return codes [0] (shell=False, capture=True)

That means, despite a (wrong) definition of lock_passwd in distros/freebsd.py, we're somehow calling the one for Linux…
Which seems unlikely, given the callpath:

cc_user_groups.py:handle() → cloud.distro.create_users()

$distro.py:add_user() → util.py:is_user() → pwd.is_user() # this is patform independent
$distro.py:lock_passwd() → where are we now?

I wonder if this has anything to do with Hetzner's vendor-data:

system_info:
    default_user:
        lock_passwd: true
        name: root
        shell: /bin/bash
    distro: ubuntu

it seems pretty ridiculous that the system_info can override the system's reality, but i guess sometimes this is necessary…

"it seems pretty ridiculous that the system_info can override the system's reality, but i guess sometimes this is necessary…"

Yeah... feel free to fix.

i should create a separate bug for the bug i discovered while triaging this one

the /other/ bug: https://bugs.launchpad.net/cloud-init/+bug/1855170

Patch: https://github.com/canonical/cloud-init/pull/93
(tests failing)

committed in e2840f1771158748780a768f6bfbb117cd7610c6

> this means, modify this user, read input from the FD supplied after -h, in this case, stdin.

no, it doesn't.

it really does mean that *this* bug: https://bugs.launchpad.net/cloud-init/+bug/1855170 was getting so much in the way, it broke my reading comprehension.

and that `-h -` was the correct implementation:

from http://man.freebsd.org/pw

      If a value of ‘-’ is given as the argument fd, then
      the password will be set to ‘*’, rendering the
      account inaccessible via password-based login.

This bug is believed to be fixed in cloud-init in version 19.4. If this is still a problem for you, please make a comment and set the state back to New

Thank you.

Tracked in Github Issues as https://github.com/canonical/cloud-init/issues/3507