Adding default user fails due to lack of 'netdev' group

[Neil Wilson]

I've created a build using the 'standard' and 'cloud-image' tasks on Quantal, but without setting a default user.

Cloud-init fails with the following in the log.

2012-09-21 12:47:31,426 - helpers.py[DEBUG]: Running config-users-groups using lock (<FileLock using file '/var/lib/cloud/instances/srv-p9zyv/sem/config-users-groups'>)
2012-09-21 12:47:31,427 - cc_users_groups.py[INFO]: Creating default user
2012-09-21 12:47:31,427 - __init__.py[DEBUG]: Creating name ubuntu
2012-09-21 12:47:31,427 - util.py[DEBUG]: Running hidden command to protect sensitive input/output logstring: ['useradd', 'ubuntu', '--shell', '/bin/bash', '--comment', 'Ubuntu', '--groups', 'adm,audio,cdrom,dialout,floppy,video,plugdev,dip,netdev,sudo']
2012-09-21 12:47:31,440 - util.py[WARNING]: Failed to create user Unexpected error while running command.
Command: ['useradd', 'ubuntu', '--shell', '/bin/bash', '--comment', 'Ubuntu', '--groups', 'adm,audio,cdrom,dialout,floppy,video,plugdev,dip,netdev,sudo', '-m']
Exit code: 6
Reason: -
Stdout: ''
Stderr: "useradd: group 'netdev' does not exist\n" due to error.
2012-09-21 12:47:31,440 - util.py[DEBUG]: Failed to create user Unexpected error while running command.

ProblemType: Bug
DistroRelease: Ubuntu 12.10
Package: cloud-init 0.7.0~bzr659-0ubuntu2
ProcVersionSignature: Ubuntu 3.5.0-15.22-generic 3.5.4
Uname: Linux 3.5.0-15-generic x86_64
ApportVersion: 2.5.2-0ubuntu4
Architecture: amd64
Date: Fri Sep 21 12:57:45 2012
PackageArchitecture: all
SourcePackage: cloud-init
UpgradeStatus: No upgrade log present (probably fresh install)

[Scott Moser (smoser)]

Neil,
  I'm curious as to what you tihnk the right behavior would be here.
a.) add the netdev user
b.) fail as it does now.

[Neil Wilson (neil-aldur)]

Is the netdev *group* used by Ubuntu server?

The way I've done it myself prior to Quantal is to delegate the problem to the user-setup package.

add_default_user() {
 echo "Setting up '${CLOUD_DEFAULT_USERNAME}' default user"
 debconf-set-selections <<EOF
user-setup passwd/username string ${CLOUD_DEFAULT_USERNAME}
user-setup passwd/user-fullname string Default Cloud User
user-setup passwd/user-password-crypted string !
EOF
 user-setup
}

Certainly I'd expect the default user to get created. I'd consider the current failure to be an error.

[Scott Moser (smoser)]

I'm not sure I understand.
The way to handle this in cloud-init now is just to be more explicit with your user-data or config (/etc/cloud/cloud.cfg.d).

#cloud-config
groups:
 - foogroup
users:
 - name: ubuntu
   primary-group: foogroup

Then you'll get what you asked for.
In the past if the user 'ubuntu' did not exist, it would not be created at all.
Now, if no 'users' item is specified in config, then it expects that the default user can be created.

So, since that default user cannot be created, it is at least arguable that the right path is to fail. Creating groups not explicitly requested by the user would seem wrong.

[Neil Wilson (neil-aldur)]

Why are you creating a default user in the 'netdev' group by default
when the standard Ubuntu server installation doesn't appear to create
that group?

That doesn't make any sense. It's always going to fail.

On 24 September 2012 16:24, Scott Moser <email address hidden> wrote:
> I'm not sure I understand.
> The way to handle this in cloud-init now is just to be more explicit with your user-data or config (/etc/cloud/cloud.cfg.d).
>
> #cloud-config
> groups:
> - foogroup
> users:
> - name: ubuntu
> primary-group: foogroup
>
> Then you'll get what you asked for.
> In the past if the user 'ubuntu' did not exist, it would not be created at all.
> Now, if no 'users' item is specified in config, then it expects that the default user can be created.
>
> So, since that default user cannot be created, it is at least arguable
> that the right path is to fail. Creating groups not explicitly
> requested by the user would seem wrong.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1054035
>
> Title:
> Adding default user fails due to lack of 'netdev' group
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1054035/+subscriptions

--
Neil Wilson

[Scott Moser (smoser)]

On Mon, 24 Sep 2012, Neil Wilson wrote:

> Why are you creating a default user in the 'netdev' group by default
> when the standard Ubuntu server installation doesn't appear to create
> that group?

I suppose this is probably for historical reasons. For all versions of
our cloud images (hardy+), there was a 'netdev' user in which the 'ubuntu'
was present (it is added by 'vmbuilder').

'netdev' is also present in 2 ubuntu server installations i have
(admittedly likely done via the network installer).

It is related to network-manager, clearly not important for server, but
still there nonetheless (https://wiki.ubuntu.com/Security/Privileges)

So its not going to fail in most cases. I agree that it seems
un-necessary, but I'd rather leave it as is then change the default groups
that the user is in.

[Neil Wilson (neil-aldur)]

On 24 September 2012 18:10, Scott Moser <email address hidden> wrote:
> I suppose this is probably for historical reasons. For all versions of
> our cloud images (hardy+), there was a 'netdev' user in which the 'ubuntu'
> was present (it is added by 'vmbuilder').

But the current stuff uses live-build - my system is derived from the
scripts that builds your cloud images.

And the hook in 030-create-user.chroot disable user creation for Quantal.

if dist_ge "${codename}" quantal; then
    echo "User creation on 12.10 is handled by cloud-init."
    exit 0
fi

Netdev is created in a 025 default group hook.

echo "Adding admin group..."
addgroup --system --quiet admin

echo "Adding netdev group..."
addgroup --system --quiet netdev

Why have the hooks creating the default groups? Shouldn't they be in
the standard server installation packages so that a debootstrapped
Ubuntu system has the expected /etc/group layout?

--
Neil Wilson

[James Falcon (falcojr)]

User creation no longer runs this way.