I was looking for a source that suggested changing lock_passwd to lock_password, but
I couldn’t find any documentation, but I did find some code that looked like it might work.
Try “lock_password”.
■ Source Code
/root/rpmbuild/SOURCES/cloud-init-24.4/cloudinit/distros/__init__.py
"__init__.py" 1792L, 66714B 1,1 Top
password_key = "passwd"
# Only "plain_text_passwd" and "hashed_passwd"
# are valid for an existing user.
LOG.warning(
"'passwd' in user-data is ignored for existing "
"user %s",
name,
)
# As no password is specified for the existing user in user-data
# Then check if the existing user's hashed password value is
# empty (whether locked or not).
has_existing_password = not (
self._shadow_file_has_empty_user_password(name)
)
else:
if "passwd" in kwargs:
ud_password_specified = True
password_key = "passwd"
if not kwargs["passwd"]:
ud_blank_password_specified = True
# Default locking down the account. 'lock_passwd' defaults to True.
# Lock account unless lock_password is False in which case unlock
# account as long as a password (blank or otherwise) was specified.
if kwargs.get("lock_passwd", True):
self.lock_passwd(name)
elif has_existing_password or ud_password_specified:
# 'lock_passwd: False' and either existing account already with
# non-blank password or else existing/new account with password
# explicitly set in user-data.
if ud_blank_password_specified:
LOG.debug(
"Allowing unlocking empty password for %s based on empty"
" '%s' in user-data",
name, password_key,
)
# Unlock the existing/new account
self.unlock_passwd(name)
elif pre_existing_user:
# Pre-existing user with no existing password and none
# explicitly set in user-data.
LOG.warning(
"Not unlocking blank password for existing user %s."
" 'lock_passwd: false' present in user-data but no existing"
"password set and no 'plain_text_passwd'/'hashed_passwd'"
"provided in user-data",
name,
)
else:
# No password (whether blank or otherwise) explicitly set
LOG.warning(
"Not unlocking password for user %s. 'lock_passwd: false'"
" present in user-data but no 'passwd'/'plain_text_passwd'/"
"'hashed_passwd' provided in user-data",
name,
)
Sorry, by fail I mean doesn’t run the config at all. The user doesn’t get created as far as I can tell. The SSH keys aren’t usable. Its pretty hard to debug what is going on when you can’t log in at all though.
Maybe this is due to some interaction with a dhcp client change in v10 vs v9. I honestly haven’t looked to see how v10 does dhcp vs v9, but my first thought is maybe it moved away from dhcpcd/dhclient and to systemd or NetworkManager’s newer equivalent which maybe doesn’t pass this data through.
I forced my cloudstack instance to use ConfigDrive instead, and the config now works. Since my cloudstack instance is new, this is fine, but its not really going to work for existing instances.
I can tell from the cloud-init logs after switching to ConfigDrive that there is mention of the “CloudStack” provider being attempted, so it is clearly enabled in cloud-init, just can’t get the data from dhcp it looks like.
Does not use “lock_password” anywhere in it. (The comment does not count.)
Thank you for pointing this out. Thanks to you, the cause has become clear.
It seems my initial predictions and investigations were incorrect.
Ultimately, I had been proceeding with the investigation based on the assumption that AlmaLinux 10’s cloud-init intentionally ignores plain_text_passwd by design, and that using hashed_passwd would resolve the issue.