image-bootstrap
image-bootstrap copied to clipboard
OpenStack image should not manually create user
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
.
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?
Should be out of the way now for OpenStack. I hope that's not causing any new problems.
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
Should I revert? Are those errors or warnings / just noise?
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.
The code that adds sudo permissions to the user went away with 326e226eaaec5acb7ded278ccf367ba1b53cf950 above. Are we supposed to set the user up with sudo but not create it, from a cloud-init point of view?
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).
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?
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.
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.
The latter problem is fixed in #51.
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
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?
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.
@hartwork I think we can work around not having a sudo
group using what I suggested in https://github.com/hartwork/image-bootstrap/issues/49#issuecomment-317196142.
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?
@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.
Of course, my bad. I'd vote for having cloud-init depend on sudo on package level. Is that an option?
@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?
Looks good to me but I cannot help test it.