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.

[jonhoo]

Also, 0.7.6 bites us again here, as it doesn't include the fix for https://bugs.launchpad.net/cloud-init/+bug/1396362 (whereas >= 0.7.7 does). This doesn't matter in the common case, but is of importance for VMs that need to be able to control the UID of the created user.

[jonhoo]

The latter problem is fixed in #51.

[jonhoo]

For the record, I also filed a bug with Arch about how they're including groups that do not exist: https://bugs.archlinux.org/task/54911

[kpcyrd]

I've adopted the package at the aur. I'm currently preparing the 17.2 upload, I plan to remove all groups that do not exist in a standard archlinux install. This includes the sudo group. I'm also going to set distro: arch which should resolve the debian specific commands.

Does this work for you/are there any objections?

[hartwork]

Hi @kpcyrd, thanks for asking! Removal of the sudo group sounds troublesome to me. If user arch no longer is in group sudo, how would he/she escalate to root? Or is there a substitute group with a different name that is empowerd by /etc/sudoers.d* out of the box?

PS: I should mention that image-bootstrap uses cloud-init 0.7.6 still because upgrading resulted in non-trivial breakage, regarding network and hostnames for instance, afair. I'd be happy to upgrade to 0.7.9+ but I'll need help with that.

[jonhoo]

@hartwork I think we can work around not having a sudo group using what I suggested in #49 (comment).

[hartwork]

ALL=(ALL) NOPASSWD:ALL would allow turning any local user to root, including machine users like www-data or apache. It turns the next shell-shock into root-shock. Am I missing something?

[kpcyrd]

@hartwork this would be true for ALL ALL=(ALL) NOPASSWD: ALL, I assume this is prefixed by something. I think the bigger issue here might be that sudo is not available in minimal images of archlinux.

[hartwork]

Of course, my bad. I'd vote for having cloud-init depend on sudo on package level. Is that an option?

[kpcyrd]

@hartwork that might work, I've added sudo as a dependency and the user to the wheel group. The wheel group is not configured by default, as far as I can tell the sudo attribute from the config is prefixed with the username and should work without an explicit group.

https://github.com/cloud-init/cloud-init/blob/99171fb7b9bec446e25a338a0d36a820844fbc2d/cloudinit/distros/__init__.py#L616-L633

Could you try if 17.2-5 works for you?

[hartwork]

Looks good to me but I cannot help test it.