Comment 2 for bug 1854594

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…