OpenStack image should not manually create user

[jonhoo]

This is taken care of by cloud-init. When the user is created through _create_sudo_nopasswd_user, the cloud-init user creation code doesn't kick in because it detects that the user already exists:

[CLOUDINIT] stages.py[DEBUG]: Running module users-groups (<module 'cloudinit.config.cc_users_groups' from '/usr/lib/python2.7/site-packages/cloudinit/config/cc_users_groups.pyc'>) with frequency once-per-instance
[CLOUDINIT] util.py[DEBUG]: Writing to /var/lib/cloud/instances/iid-local01/sem/config_users_groups - wb: [420] 19 bytes
[CLOUDINIT] helpers.py[DEBUG]: Running config-users-groups using lock (<FileLock using file '/var/lib/cloud/instances/iid-local01/sem/config_users_groups'>)
[CLOUDINIT] __init__.py[INFO]: User arch already exists, skipping.

This in turn means that the modifications made by adjust_cloud_cfg_dict and friends do not take effect, and the user does not get added to other groups such as adm.

[jonhoo]

ping @hartwork — this one is actually pretty severe, as it means I can't customize the cloud user (in particular, I need to force them to have a particular home directory and UID). Do you remember why you made it so that image-bootstrap manually creates the user?

[hartwork]

Should be out of the way now for OpenStack. I hope that's not causing any new problems.

[jonhoo]

Hmm, now I get errors when cloud-init tries to create the user:

useradd: group 'cdrom' does not exist
useradd: group 'dialout' does not exist
useradd: group 'dip' does not exist
useradd: group 'netdev' does not exist
useradd: group 'plugdev' does not exist
useradd: group 'sudo' does not exist

[hartwork]

Should I revert? Are those errors or warnings / just noise?

[jonhoo]

Those errors result in the user not being created at all. I believe the correct thing to do is remove those groups from the groups array in /etc/cloud/cloud.cfg. I'm not entirely sure how you currently give sudo access to the cloud user, but you may also have to adapt it to make that work too.

[hartwork]

The code that adds sudo permissions to the user went away with 326e226 above. Are we supposed to set the user up with sudo but not create it, from a cloud-init point of view?

[jonhoo]

Judging from the Arch Linux cloud.cfg, a sudo entry is needed:

sudo: ["ALL=(ALL) NOPASSWD:ALL"]

This is further supported by the cloud-init docs, which say:

#   sudo: Defaults to none. Set to the sudo string you want to use, i.e.
#           ALL=(ALL) NOPASSWD:ALL. To add multiple rules, use the following
#           format.
#               sudo:
#                   - ALL=(ALL) NOPASSWD:/bin/mysql
#                   - ALL=(ALL) ALL
#           Note: Please double check your syntax and make sure it is valid.
#               cloud-init does not parse/check the syntax of the sudo
#               directive.
...
# Unless you define users, you will get a 'ubuntu' user on ubuntu systems with the
# legacy permission (no password sudo, locked user, etc).

[hartwork]

There is method adjust_cloud_cfg_dict at https://github.com/hartwork/image-bootstrap/blob/master/image_bootstrap/distros/base.py#L166. Could you experiment with that and make a pull request?

[jonhoo]

Fixed in #50. Note that there are still some errors due to an Ubuntu-centric cloud.cfg (e.g., it still tries to run apt-configure and friends), but those aren't really that much of an issue.