vagrant xenial box is not provided with vagrant/vagrant username and password

[domnulnopcea]

It is Vagrant convention that the default user is named "vagrant"[0], and a whole host of scripts assume this to be the default.

The xenial box is substantially less useful to Vagrant users with the "ubuntu" user as the default.

[0] Search for "user to SSH" in https://www.vagrantup.com/docs/boxes/base.html.

------------

Xenial SRU:

[impact]

* An additional "vagrant" user is available in the created image once the proposed patch is applied. The normal "ubuntu" user is also available, and is conforming to the "ubuntu experience" (it requires cloud-init or another mechanism to be given keys/a password).

* The vagrant boxes produced by livecd-rootfs hooks do not conform to the vagrant community's guidelines for box creation, leading vagrant users to use non-official (unaudited) boxes instead, where a "vagrant" user can be found.

* A large portion of vagrant automation (3rd party tools, scripts) rely on the presence of a "vagrant" user conforming to the above guidelines. The official ubuntu images are ones of the very few not conforming to the expected user layout.

* The official Ubuntu trusty image previously offered a "vagrant" user, and that was lost or omitted when migrating xenial+ to a new build system. This could be considered a regression, although historical context of that change is unfortunately not available anymore.

[test case]

From a fresh Ubuntu install:

* sudo apt install vagrant

* vagrant init ubuntu/xenial64

* vagrant up

* vagrant ssh

notice the user being logged in as is "ubuntu"

With either ubuntu/artful64 or ubuntu/trusty64, the same steps log the user in as "vagrant".

An image with the proposed changes was built and uploaded as "tribaal/xenial64".

[Regression potential]

* Users who worked around this behavior in their automation are the most at-risk. They might not be able to login to their boxes anymore, if they worked around by extracting the ubuntu password from the box metadata. If they worked around the problem using cloud-init, no regression will be visible.

* The changes introduce a new insecure user, users having worked around the problem on their own might be be unaware of this.

* The general consensus in the vagrant community is to install third-party boxes instead of spending time to try and workaround the problems with the official ubuntu boxes, so it is likely to be a limited real-world impact.

* The change might affect exotic systems where people for some reason decided to build a non-vagrant machine out of our official vagrant image

Note that these regressions will apply to users upgrading their installations to future releases (artful, bionic, and later).

[domnulnopcea (domnulnopcea)]

issue still present in image 20160420.3

[christophe (christophe-bornet)]

still present in v20160502.0.0

[christophe (christophe-bornet)]

Actually the whole vagrant base box configuration is missing (https://www.vagrantup.com/docs/boxes/base.html)

[domnulnopcea (domnulnopcea)]

Is there any activity here from ubuntu guys? the xenial vagrant image right now is not usable...

[Tang Jianyu (jianyu)]

I'm also getting this issue on v20160509.0.0, system is working but annoying

[Jack Peterson (jack-peterson)]

Still impacting Ubuntu 16.04 adoption. Vagrant is a great way to test functionality out and not having Xenial work with vagrant out of the box is frustrating to say the least. Can we get this assigned / triaged?

This is still an issue.

VirtualBox - Version 5.0.20 r106931

$ vagrant --version
Vagrant 1.8.1

$ vagrant box list | grep xenial
ubuntu/xenial64 (virtualbox, 20160606.1.0)

[Jack Peterson (jack-peterson)]

I'm cross-referencing this to the bug https://bugs.launchpad.net/ubuntu/+source/livecd-rootfs/+bug/1589721 that I just posted. The bug above appears to be the correct place to place a report based on the email referenced at http://www.kennybastani.com/2015/08/polyglot-persistence-spring-cloud-docker.html

[Jack Peterson (jack-peterson)]

Steps to reproduce this issue:

$ vagrant init ubuntu/xenial64
$ vagrant up

Console output:

Bringing machine 'default' up with 'virtualbox' provider...
==> default: Importing base box 'ubuntu/xenial64'...
==> default: Matching MAC address for NAT networking...
==> default: Checking if box 'ubuntu/xenial64' is up to date...
==> default: Setting the name of the VM: ubuntu-xenial-16.04-cloudimg
==> default: Clearing any previously set network interfaces...
==> default: Preparing network interfaces based on configuration...
    default: Adapter 1: nat
==> default: Forwarding ports...
    default: 22 (guest) => 2222 (host) (adapter 1)
==> default: Running 'pre-boot' VM customizations...
==> default: Booting VM...
==> default: Waiting for machine to boot. This may take a few minutes...
    default: SSH address: 127.0.0.1:2222
    default: SSH username: ubuntu
    default: SSH auth method: password
    default: Warning: Remote connection disconnect. Retrying...
^C==> default: Waiting for cleanup before exiting...
    default: Warning: Connection refused. Retrying...
    default: Warning: Remote connection disconnect. Retrying...
Vagrant exited after cleanup due to external interrupt.

[Dan Watkins (oddbloke)]

So this is what I see when I boot up the latest xenial64 box:

Bringing machine 'default' up with 'virtualbox' provider...
==> default: Importing base box 'ubuntu/xenial64'...
==> default: Matching MAC address for NAT networking...
==> default: Checking if box 'ubuntu/xenial64' is up to date...
==> default: Setting the name of the VM: ubuntu-xenial-16.04-cloudimg
==> default: Clearing any previously set network interfaces...
==> default: Preparing network interfaces based on configuration...
    default: Adapter 1: nat
==> default: Forwarding ports...
    default: 22 (guest) => 2222 (host) (adapter 1)
==> default: Running 'pre-boot' VM customizations...
==> default: Booting VM...
==> default: Waiting for machine to boot. This may take a few minutes...
    default: SSH address: 127.0.0.1:2222
    default: SSH username: ubuntu
    default: SSH auth method: password
    default: Warning: Remote connection disconnect. Retrying...
    default: Warning: Remote connection disconnect. Retrying...
    default: Warning: Remote connection disconnect. Retrying...
    default: Warning: Remote connection disconnect. Retrying...
    default: Warning: Remote connection disconnect. Retrying...
    default: Warning: Remote connection disconnect. Retrying...
    default: Warning: Remote connection disconnect. Retrying...
    default: Warning: Remote connection disconnect. Retrying...
    default: Warning: Remote connection disconnect. Retrying...
    default: Warning: Remote connection disconnect. Retrying...
    default: Warning: Remote connection disconnect. Retrying...
    default: Warning: Remote connection disconnect. Retrying...
    default: Warning: Remote connection disconnect. Retrying...
    default: Warning: Remote connection disconnect. Retrying...
    default:
    default: Inserting generated public key within guest...
    default: Removing insecure key from the guest if it's present...
    default: Key inserted! Disconnecting and reconnecting using new SSH key...
==> default: Machine booted and ready!

(I'm looking at what the trusty box does now)

[Dan Watkins (oddbloke)]

And this is what I see with trusty:

Bringing machine 'default' up with 'virtualbox' provider...
==> default: Importing base box 'ubuntu/trusty64'...
==> default: Matching MAC address for NAT networking...
==> default: Checking if box 'ubuntu/trusty64' is up to date...
==> default: Setting the name of the VM: trusty_default_1465318955637_45016
==> default: Clearing any previously set forwarded ports...
==> default: Fixed port collision for 22 => 2222. Now on port 2200.
==> default: Clearing any previously set network interfaces...
==> default: Preparing network interfaces based on configuration...
    default: Adapter 1: nat
==> default: Forwarding ports...
    default: 22 (guest) => 2200 (host) (adapter 1)
==> default: Booting VM...
==> default: Waiting for machine to boot. This may take a few minutes...
    default: SSH address: 127.0.0.1:2200
    default: SSH username: vagrant
    default: SSH auth method: private key
    default: Warning: Remote connection disconnect. Retrying...
    default:
    default: Vagrant insecure key detected. Vagrant will automatically replace
    default: this with a newly generated keypair for better security.
    default:
    default: Inserting generated public key within guest...
    default: Removing insecure key from the guest if it's present...
    default: Key inserted! Disconnecting and reconnecting using new SSH key...
==> default: Machine booted and ready!

So this looks pretty much the same, except my xenial box took longer to come up. Is it possible people are just seeing a timeout?

[Jack Peterson (jack-peterson)]

I can get this to sign in after a period of time with the ubuntu user (so that part works); however, I think the real issue is that the username / password defaults are inconsistent with the documentation on Vagrant's documentation https://www.vagrantup.com/docs/boxes/base.html -- which then causes later provisioning issues / machine portability issues.

So this ticket should reflect the need for the ubuntu/xenial64 image to match how ubuntu/trusty64 was configured for vagrant's recommendations with a default user of vagrant and a default password of vagrant with password-less sudo.

A workaround for this would be to create the vagrant user as a pre-provisioning step (assuming additional provisioners like puppet are used that depend on the vagrant user) with sudo permissions; however, that's a bit of a hack to get things to play nicely. An example of where something wouldn't play nicely is when one has baked in vagrant user availability / defaults and file/folder permissions for their provisioning steps.

[Dan Watkins (oddbloke)]

OK, I've updated the bug description; the login timeouts were a red herring, this is really just about changing the default username.

(We can, and have, instructed Vagrant to SSH in using the correct user, but this information is not generally used outside of `vagrant ssh`)

[Keilo (keilo)]

This is slowing down 16.04 adoption due to breaking changes from 14.04 such as the default username and generally missing a lot of other standard settings that vagrant expects to find in the base box.

Can confirm that this affects ubuntu/xenial64 20160610.0.0

[Jack Peterson (jack-peterson)]

I abandoned using the Ubuntu/* vagrant images in favor of kaorimatz/ubuntu-16.04-amd64 (https://github.com/kaorimatz/packer-templates). This is at least an open-source project so you could rebuild the images from scratch if you so desired ... and it's built using the vagrant way rather than the super obscure ubuntu imaging way -- which I found almost no documentation to reproduce a local environment to create the images. I'd suggest going that route since everything works well out of the box and it's well documented as well as well-contributed to (fairly reliable).

[Socketz (socketz)]

Temporary solution:
1. Modify the Vagrantfile before to execute 'vagrant up' command:

  config.vm.provision "shell", inline: <<-SHELL
     passwd -d -u ubuntu
     chage -d0 ubuntu
  SHELL

2. Execute 'vagrant up --provider virtualbox' # or without provider args
3. After VM is up, click on Virtualbox to show the VM GUI and change the password.
4. Login on ssh with user ubuntu correctly.

[domnulnopcea (domnulnopcea)]

is this bug going to be addressed?

[meteor (604733992-qq)]

@socketz It works. Thanks.
When can Ubuntu fix this bug?

[meteor (604733992-qq)]

I use https://atlas.hashicorp.com/bento/boxes/ubuntu-16.04 now.
No crappy any more.

[Sam Bull (dreamsorcerer)]

This is causing issues for our development setup as well.

As per the documentation:
  By default, Vagrant expects a "vagrant" user to SSH into the machine as.
https://www.vagrantup.com/docs/boxes/base.html#quot-vagrant-quot-user

[Flavio Fernandes (ffernand)]

This is still an issue when using vagrant in xenial host,
with vbox 20160826.0.0

$ VBoxManage --version
5.0.24_Ubuntur108355

$ vagrant --version
Vagrant 1.8.5

$ vagrant box list | grep xenial
ubuntu/xenial64 (virtualbox, 20160826.0.0)

$ grep box Vagrantfile
    ubuntu.vm.box = "ubuntu/xenial64"

$ vagrant up
...
==> ubuntu: chown: invalid user: ‘vagrant:vagrant’
...

$ vagrant ssh
 INFO ssh: Invoking SSH: ssh ["ubuntu@127.0.0.1", "-p", "2222", "-o", "Compression=yes", "-o", "DSAAuthentication=yes", "-o", "LogLevel=FATAL", "-o", "StrictHostKeyChecking=no", "-o", "UserKnownHostsFile=/dev/null", "-o", "IdentitiesOnly=yes"]
ubuntu@127.0.0.1's password:

[David Reagan (jerrac)]

I can ssh into the box using the private key, or vagrant ssh. But if I want to just ssh in normally, I have to use a password. And I have no idea what the password for "ubuntu" would be. It would be much better to use the normal vagrant/vagrant user.

VBoxManage --version
5.1.0r108711

vagrant --version
Vagrant 1.8.4

xenial.vm.box = "ubuntu/xenial64"
xenial.vm.box_url = "https://cloud-images.ubuntu.com/xenial/current/xenial-server-cloudimg-amd64-vagrant.box"

[benjamin orion sweetnam (ben-s247)]

hey David a temp fix is to set the username and password for vagrant like so:
```ruby
Vagrant.configure(2) do |config|

  config.vm.define "master" do |master|
    config.ssh.username = "ubuntu"
    config.ssh.password = ""
    master.vm.box = "ubuntu/xenial64"
    master.vm.hostname = "master"
    master.vm.network :private_network, ip: "172.0.0.10"
  end

end
```
please note I've defined those attributes to the box if you want them to apply to all nodes ie your using all the same box you should place all three username password and box out side the define "master" block.

[domnulnopcea (domnulnopcea)]

hello,

the temp fix is not working. It still hangs asking for password.

[Kristian Lewis Jones (klj613)]

hello,

this affects me. all my scripts assumes the user is vagrant with the default ssh key. back to 14.04.

[Ruijing (ruijing-guo)]

who can help to triage this issue?

[Ruijing (ruijing-guo)]

where is source code to build vagrant box? we may help to fix the issue

[denix (denics)]

Ok, I confirm the problem is still present for version: 20161014.0.0

Concerning workarounds you can set:

# SSH options.
    config.ssh.insert_key = true
    config.ssh.forward_agent = true

which will copy your public ssh key in the "ubuntu" account. You'll be then able to login using
vagrant ssh

If you want you can also set a password during your provision phase (I've tested with a shell provision), or make sure that your user is listed in the sudoers users. @ruijing-guo Having the source code for the box would indeed help fixing the issue!

Denis

[Brian (egee-irl)]

This is a pretty serious but and I am not sure why it isn't being triaged by the Ubuntu team. The fix is trivial on Canonical's end.

[Bogdan Ghervan (bogdanghervan)]

I get it that vagrant / vagrant should be the default, but what is the default password for the "ubuntu" account? I already tried "ubuntu", "vagrant" and a blank password, clearly I'm missing something.

[auxbuss (launchpad-auxbuss)]

Astonished that no-one has looked into this. I'm abandoning the Ubuntu boxes, because there is no indication that they have an interest in maintaining them.

[Florian Heyer (heyho-flanto)]

This problem still exists in
ubuntu/xenial64 (virtualbox, 20161104.0.0)
Please fix!

[David Warkentin (ev0rtex)]

This is killing me - I just installed the latest 20161104.0.0 and experienced this. I was stuck on this for hours trying to find a workaround before giving up (and just now finding this issue). All of my scripts, SaltStack configs, etc. rely on the user being 'vagrant' and I can't just simply adapt to this change - I could spend days on this. Canonical...please pay attention and help us out!

[David Warkentin (ev0rtex)]

FYI, to all those who want a working base box I gave up and just repackaged a corrected version of ubuntu/xenial64 last night. Mine is on atlas as "v0rtex/xenial64" and so far I only did a version for the virtualbox provider since I do not have vmware at the moment.

I updated guest additions and package versions and then changed the username from 'ubuntu' to 'vagrant' along with all the dependent sudo, group and permission fixes. This is working great for me so far.

[Alex Afanasyev (alex.afanasyev)]

ubuntu/xenial64/32 boxes have been incorrectly packaged since conception and Ubuntu team hasn't even attempted to fix many known issues. I can only guess, Ubuntu is not interested at all in providing usable vagrant boxes.

[Andrew Robbins (agdrew)]

ubuntu/xenial64 is useless, when is this going to be fixed?

[Joel Handwell (joelhandwell)]

Ubuntu 14 and 12 vagrant boxes are using vagrant/vagrant username/password and keep updating. So I assume ubuntu team acknowledges that there is demand for vagrant box. There should be more direct communication channel outside of launchpad to reach their decision making process or priority setter person.

[Visnusaran Murugan (ckmvishnu)]

Adding the below mentioned config to Vagrantfile, i'm able to "vagrant ssh" in to 16.04 machine.

config.ssh.username = "ubuntu"

I've created a golang devbox based on xenial and using it without issues.

[leed (leed)]

Seriously, this needs fixing. I don't want to have to instruct all co-workers that they should be using the "ubuntu" user instead of the "vagrant" user. Besides the fact, that the "ubuntu" user has issues with the password and uses a different root path and also can't provision correctly without using sudo.

Please fix this back to the previous vagrant:vagrant user. We have enough other problems and new things to learn.

[ugmoe2000 (ericpulvino)]

Please address this, the image is almost useless if users cannot easily log in.

[gitarr (gitarr)]

Why is this cloud image on atlas.hashicorp.com as the official Ubuntu vagrant box?

(https://atlas.hashicorp.com/ubuntu/boxes/xenial64)

This box isn't configured right and just not working for vagrant. This is your current LTS release? I'd be ashamed at this point.

[Dan Watkins (oddbloke)]

On Sat, Sep 16, 2017 at 07:48:12AM -0000, windowsguy wrote:
> Almost 3 million downloads from app.vagrant.com and likely no one can
> log in. Great job!

As I understand it, the box as configured today works as expected if you
use `vagrant ssh` or Vagrant provisioners. How are you trying to log
in?

I understand that the lack of a Vagrant user is frustrating (and we are
working to address this in a way which will work for _all_ of our
users), but broad (and, if I understand correctly, inaccurate)
statements that this is totally broken aren't particularly constructive.

[Rune Philosof (olberd)]

But it is totally unusable when you can't log in...

```
$ vagrant up
Bringing machine 'default' up with 'virtualbox' provider...
==> default: Box 'ubuntu/xenial64' could not be found. Attempting to find and install...
    default: Box Provider: virtualbox
    default: Box Version: >= 0
==> default: Loading metadata for box 'ubuntu/xenial64'
    default: URL: https://atlas.hashicorp.com/ubuntu/xenial64
==> default: Adding box 'ubuntu/xenial64' (v20170919.0.0) for provider: virtualbox
    default: Downloading: https://vagrantcloud.com/ubuntu/boxes/xenial64/versions/20170919.0.0/providers/virtualbox.box
==> default: Box download is resuming from prior download progress
==> default: Successfully added box 'ubuntu/xenial64' (v20170919.0.0) for 'virtualbox'!
==> default: Importing base box 'ubuntu/xenial64'...
==> default: Matching MAC address for NAT networking...
==> default: Checking if box 'ubuntu/xenial64' is up to date...
==> default: Setting the name of the VM: upgraded_default_1505909538747_12474
==> default: Fixed port collision for 22 => 2222. Now on port 2200.
==> default: Clearing any previously set network interfaces...
==> default: Preparing network interfaces based on configuration...
    default: Adapter 1: nat
    default: Adapter 2: hostonly
==> default: Forwarding ports...
    default: 80 (guest) => 8180 (host) (adapter 1)
    default: 22 (guest) => 2200 (host) (adapter 1)
==> default: Running 'pre-boot' VM customizations...
==> default: Booting VM...
==> default: Waiting for machine to boot. This may take a few minutes...
    default: SSH address: 127.0.0.1:2200
    default: SSH username: ubuntu
    default: SSH auth method: password
Text will be echoed in the clear. Please install the HighLine or Termios libraries to suppress echoed text.
ubuntu@127.0.0.1's password:vagrant
ubuntu@127.0.0.1's password:ubuntu
    default: Warning: Authentication failure. Retrying...
Text will be echoed in the clear. Please install the HighLine or Termios libraries to suppress echoed text.
ubuntu@127.0.0.1's password:^C==> default: Waiting for cleanup before exiting...
Vagrant exited after cleanup due to external interrupt.

$ vagrant ssh
==> default: The machine you're attempting to SSH into is configured to use
==> default: password-based authentication. Vagrant can't script entering the
==> default: password for you. If you're prompted for a password, please enter
==> default: the same password you have configured in the Vagrantfile.
ubuntu@127.0.0.1's password:
ubuntu@127.0.0.1's password:
ubuntu@127.0.0.1's password:
Permission denied (publickey,password).
```

[Rune Philosof (olberd)]

Sorry, my bad. I had a `config.ssh.password = 'vagrant'` in my Vagrantfile.
It totally works...

[Salvadore Yutations (sal-yutations)]

I can't believe this issue is still around. It's really hard to develop new things on 16.04 when the vagrant box is consistently broken.

I may be switching things over to Debian over this.

[Dan Watkins (oddbloke)]

Hi Salvadore,

On Thu, Oct 05, 2017 at 09:55:29PM -0000, Salvadore Yutations wrote:
> I can't believe this issue is still around. It's really hard to develop
> new things on 16.04 when the vagrant box is consistently broken.
>
> I may be switching things over to Debian over this.

Using `vagrant ssh` works with the box; could you clarify what issues
you are seeing?

Thanks,

Dan

[Oskar Blom (oskar-blom)]

You shouldn't have to use vagrant ssh. See https://www.vagrantup.com/docs/boxes/base.html#quot-vagrant-quot-user

To quote that page
> Just about every aspect of Vagrant can be modified. However, Vagrant does expect some defaults which will
> cause your base box to "just work" out of the box. You should create these as defaults if you intend to
> publicly distribute your box.

> By default, Vagrant expects a "vagrant" user to SSH into the machine as. This user should be setup with the > insecure keypair that Vagrant uses as a default to attempt to SSH

Why isn't this honored?

[Dan Watkins (oddbloke)]

On Wed, Oct 11, 2017 at 11:52:44AM -0000, Oskar Blom wrote:
> You shouldn't have to use vagrant ssh. See
> https://www.vagrantup.com/docs/boxes/base.html#quot-vagrant-quot-user

Agreed.

> To quote that page
> > Just about every aspect of Vagrant can be modified. However, Vagrant does expect some defaults which will
> > cause your base box to "just work" out of the box. You should create these as defaults if you intend to
> > publicly distribute your box.
>
> > By default, Vagrant expects a "vagrant" user to SSH into the machine
> as. This user should be setup with the > insecure keypair that Vagrant
> uses as a default to attempt to SSH
>
> Why isn't this honored?

This has been covered already in comments on this bug.

[Fabien COMBERNOUS (fc.)]

The boxes packaged by ubuntu are buggy. it is explained here in details :
https://github.com/hashicorp/vagrant/issues/5186

[James (james-jarofgreen)]

Can I beg that at least that this is documented properly?

https://app.vagrantup.com/ubuntu/boxes/xenial64 just has lots of "There isn't a description.".

Why not?

Please at least add a basic description with an note about the different user name and maybe this very handy bit of Vagrant config:

    config.ssh.username = "ubuntu"

Thanks.

[Chris Glass (tribaal)]

Hi all!

I am in the process of changing the default behaviour of Ubuntu vagrant images.
I think I have a behaviour that is consistent with what you guys expect, but I'd like some feedback.

Would you please confirm that "ubuntu/artful64" behaves as you expect it to? It follows all the instructions in https://www.vagrantup.com/docs/boxes/base.html except setting the root password.

A quick run of "vagrant init ubuntu/artful64; vagrant up; vagrant ssh" seems to do what I expect should happen, but I'd like your feedback before I backport it to other releases.

Thanks!

Specifically:

- image has a vagrant:vagrant user as well as the usual ubuntu user.
- ubuntu user doesn't have password or keys set.
- vagrant user has the insecure ssh pubkey in ~/.ssh/authorized_keys.
- vagrant user has passwordless sudo.
- "vagrant ssh" just works, logging you in as "vagrant" user
- root user is still locked

[Owen Raccuglia (ojracc)]

Hi Chris -- "ubuntu/artful64" works for me. I ran into some trouble with config.vm.network "public_network", but that feels like an unrelated bug. The actual VM creation part works great.

Looking forward to moving back to an official image :)

[domnulnopcea (domnulnopcea)]

Hi Chris,

all your suggestions are OK.

BUT, what do you mean exactly by "root user is still locked"? We should still be able to do "sudo su"

when do you think your changes will go live?

thanks

[Chris Glass (tribaal)]

Yes, you can "sudo su" from the vagrant user and you'll get root.

You cannot login as root directly (the account is locked in the "passwd -l" sense: there is no password).

The changes are already live in artful (using the "ubuntu/artful64" box for example). I'd like to have some feedback before backporting the changes: it's a relatively large task, I'd like to make sure the changes are good before I start.

[Chris Glass (tribaal)]

I'm marking this bug as fixed in trunk, since a fix landed there (https://bazaar.launchpad.net/~ubuntu-core-dev/livecd-rootfs/trunk/revision/1504) and several users reported the new behavior as desirable.

The change is already live in the ubuntu/artful64 and ubuntu/bionic64 boxes.

[Chris Glass (tribaal)]

Untargetting vagrant as the bug is not in vagrant at all but in the image creation code instead (livecd-rootfs)

[Scott Moser (smoser)]

Quote:
 | The xenial box is substantially less useful to Vagrant users with the
 | "ubuntu" user as the default, and there is limited benefit to having the
 | "ubuntu" user.

This is entirely untrue. There is *substantial* benefit in Ubuntu consistency across platforms. Users who are familiar with non-ubuntu images on vagrant may well find use of Ubuntu images made easier the first time if the default user is changed to 'vagrant'. However, users of Ubuntu on any other platform will find Ubuntu *harder* to use on vagrant after your change. Since vagrant users do not make up a majority of Ubuntu users, there is thus more value in Ubuntu acting the same across platforms than there is in Ubuntu changing its behavior to fit vagrant (or any platform that does not hold the majority of Ubuntu users).

[dizeee (dizeee)]

> However, users of Ubuntu on any other platform will find Ubuntu *harder* to use on vagrant after your change. Since vagrant users do not make up a majority of Ubuntu users, there is thus more value in Ubuntu acting the same across platforms than there is in Ubuntu changing its behavior to fit vagrant

Sounds like some religious b#@*S%^t or a f#%@*&g vendor lock. We use Ubuntu for development, testing and production. It's great, but not unique. We could use let's say Debian instead as well. I didn't even know/care about the ubuntu user until faced this issue. What is that extremely common and massive use case that requires a user with an OS specific name? I need root user to create other users I need. E. g. some internal users to perform tasks like www-data to run my web server and application code or automation user with extended privileges to perform software/configuration updates, and real user accounts for team members. And I need an abstract user for local development and vagrant is there for me in every project I work on, not depending on any particular OS. And if there's one box of a million that doesn't respect that, I don't care. But when it's one of the major vendors out there, it should be ashamed because it's wasting time, traffic and nerves of it's users.

[Chris Glass (tribaal)]

Clarified the description by the original bug author.

The proposed solution for SRUing does *not* drop the ubuntu@ user, and the ubuntu user behaves exactly the same way as with every other cloud-image we deliver.

There is an *additional* default user (the "vagrant" user), that conforms to the community's expectations.

Please be kind enough to either keep the conversation civil and adhering to the Ubuntu community's code of conduct, or refrain from making further comments. The behavior is being changed, swearing and calling names won't make it go any faster.

[dizeee (dizeee)]

@tribaal thanks for taking care! It was really a long-awaited fix.

[Gopinath Taget (gopinatht)]

@tribaal Just to confirm, is this fix back-ported to Xenial64 yet?

[Chris Glass (tribaal)]

Not yet.

This is currently in the sponsorship queue, so for those not familiar with the procedure, point 6 in https://wiki.ubuntu.com/StableReleaseUpdates#Procedure .

As you can see using "rmadison livecd-rootfs" another SRU for livecd-rootfs is under way (for something unrelated to this bug), so we need to wait for it to land or be rejected (the full SRU review queue is here https://people.canonical.com/~ubuntu-archive/pending-sru.html).

Once the changes are uploaded to xenial-proposed, we will build a test vagrant box for xenial, push it *somewhere* and let you all know.

Then we'll need your help!

The change won't move forward without your help testing it. You can already contribute some useful testing today by using "ubuntu/artful64" and checking that it behaves according to what you expect (and commenting on this bug, even as simple as "ubuntu/artful64 works for me").

So once it hits proposed we need people to test the box and report here that it works for them, or not. This part is very important! Once it has been verified (tested), then the SRU team will hopefully promote the change, and once that lands the normal build process will publish new vagrant boxes.

At this point you'll see the change appear in the boxes you use in your normal vagrant workflow, and I'll mark the bug as "fix released".

This process takes time - and unfortunately the timing with end of year holidays is not going to help, but it's under way :) Besides, changing an LTS release of Ubuntu is slow "by design" - is allows for more testing to occur, as nobody wants bad code to be sent to millions of machines.

[Scott Moser (smoser)]

> Sounds like some religious b#@*S%^t or a f#%@*&g vendor lock. We use
> Ubuntu for development, testing and production. It's great, but not
> unique. We could use let's say Debian instead as well. I didn't even
> know/care about the ubuntu user until faced this issue.

???

Its vendor lock to have an 'ubuntu' user on Ubuntu, but having a
'vagrant' user on guests running under vagrant is just expected ?

[dizeee (dizeee)]

> Its vendor lock to have an 'ubuntu' user on Ubuntu, but having a
> 'vagrant' user on guests running under vagrant is just expected ?

Well, no and yes. I'm not talking about having the `ubuntu` user, I'm talking about not having the `vagrant` user for Vagrant to work as expected out of the box. Imagine there's a prebuilt mysql package for some Bananas OS that at some point became configured to run mysql daemon under `bananas` user rather then `mysql` by default, and after it's installed there's no `mysql` user in the system. Imagine then that you have some automation that installs mysql and creates some files with `mysql` owner. Would you expect it to fail with 'No such user' error? Or would you be happy to add conditions to your code like `if (os == 'Bananas' and os_version >= 16.04) mysql_user = 'bananas'` I guess not. And what if it happened to all software for every Linux distribution? That would be a nightmare. That's why it's important to follow conventions like the one about the vagrant user.

[Jakub Nowakowski (nkuba8)]

ubuntu/artful64 works for me
"vagrant ssh" logins succesfully as "vagrant" user

[Łukasz Zemczak (sil2100)]

Uploaded to the xenial queue, waiting for SRU review.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Dan Watkins (oddbloke)]

We've seen a couple of potential regressions in artful, so we should hold off on this xenial SRU until we've triaged these:

https://bugs.launchpad.net/cloud-images/+bug/1740176
https://bugs.launchpad.net/cloud-images/+bug/1740178

[Chris Glass (tribaal)]

It seems those bugs are not affecting the xenial release. They are however important to tackle/investigate.

The proposed SRU changes can be tested by using the "tribaal/xenial64" image.

The SRU process can go ahead/restart as far as I can tell.

[Łukasz Zemczak (sil2100)]

Hello domnulnopcea, or anyone else affected,

Accepted livecd-rootfs into xenial-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/livecd-rootfs/2.408.27 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed.Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-xenial to verification-done-xenial. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-xenial. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

[Chris Glass (tribaal)]

This is when you all can help: as you can see the proposed fix landed in -proposed: if you know how, feel free to build images yourself using the livecd-rootfs package in -proposed.

If you would still like to help testing the change but don't know how to build images with livecd-rootfs, please give the following a try and report if it behaves as you would expect. If you have automated test infrastructures in place, it would help to plug this image in as well and see how it fares.

vagrant init tribaal/xenial64
vagrant up

Note: the "tribaal/xenial64" box is obviously not a production image so please don't treat it as such. Once the changes are verified and landed in -updates, we will build a "real" xenial image with a vagrant user and will update this bug when that happened.

[Dan Watkins (oddbloke)]

I've followed the steps Chris gave above, and have confirmed that the vagrant user is the default via SSH. The ubuntu user also exists, and is in the appropriate groups.

[Yong Li (hungrybirder)]

The issue is STILL not fixed?
I can't believe this.
Please fix it ASAP.

[Łukasz Zemczak (sil2100)]

The verification of the Stable Release Update for livecd-rootfs has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

[Launchpad Janitor (janitor)]

This bug was fixed in the package livecd-rootfs - 2.408.27

---------------
livecd-rootfs (2.408.27) xenial; urgency=medium

  * Don't ask for password and GECOS while creating vagrant user
    (LP: #1569237)

livecd-rootfs (2.408.26) xenial; urgency=medium

  * Added a "vagrant" user to the vagrant image in addition to the "ubuntu"
    user, in accordance with the vagrant community's expectations (LP: #1569237)

 -- Balint Reczey <email address hidden> Thu, 21 Dec 2017 09:20:32 +0100

[Chris Glass (tribaal)]

The fix landed in the livecd-rootfs package, so expect to see the fix in the ubuntu/xenial64 images very soon (next image build, or the one after).

[Chris Glass (tribaal)]

Quick update:

We would normally respin an image build right now to put this to bed once and for all, but since we're in the middle of the Meltdown/Spectre crisis it's best to keep the build system available for security-related work.

The vagrant image will be built and pushed along with the rest of the images whenever the build system triggers next (so if security-work needs a respin of cloud images the Vagrant box will be published as well).

I'll update this bug and mark it fix released once and image is available.

[Chris Glass (tribaal)]

This bug is now fixed in ubuntu/xenial64 v20180112.0.0.

Update your vagrant boxes:

vagrant box update
vagrant up
vagrant ssh

(notice you're "vagrant").

[Yong Li (hungrybirder)]

Thanks.
It works well.

Chris Glass <email address hidden>于2018年1月13日 周六16:20写道：

> This bug is now fixed in ubuntu/xenial64 v20180112.0.0.
>
> Update your vagrant boxes:
>
> vagrant box update
> vagrant up
> vagrant ssh
>
> (notice you're "vagrant").
>
> ** Changed in: cloud-images/x-series
> Status: Fix Committed => Fix Released
>
> ** Changed in: cloud-images/trunk
> Status: Fix Committed => Fix Released
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1569237
>
> Title:
> vagrant xenial box is not provided with vagrant/vagrant username and
> password
>
> Status in cloud-images:
> Fix Released
> Status in cloud-images trunk series:
> Fix Released
> Status in cloud-images x-series series:
> Fix Released
> Status in vagrant:
> Invalid
> Status in Xenial Backports:
> New
> Status in livecd-rootfs package in Ubuntu:
> Fix Released
> Status in livecd-rootfs source package in Xenial:
> Fix Released
>
> Bug description:
> It is Vagrant convention that the default user is named "vagrant"[0],
> and a whole host of scripts assume this to be the default.
>
> The xenial box is substantially less useful to Vagrant users with the
> "ubuntu" user as the default.
>
> [0] Search for "user to SSH" in
> https://www.vagrantup.com/docs/boxes/base.html.
>
> ------------
>
> Xenial SRU:
>
> [impact]
>
> * An additional "vagrant" user is available in the created image once
> the proposed patch is applied. The normal "ubuntu" user is also
> available, and is conforming to the "ubuntu experience" (it requires
> cloud-init or another mechanism to be given keys/a password).
>
> * The vagrant boxes produced by livecd-rootfs hooks do not conform to
> the vagrant community's guidelines for box creation, leading vagrant
> users to use non-official (unaudited) boxes instead, where a "vagrant"
> user can be found.
>
> * A large portion of vagrant automation (3rd party tools, scripts)
> rely on the presence of a "vagrant" user conforming to the above
> guidelines. The official ubuntu images are ones of the very few not
> conforming to the expected user layout.
>
> * The official Ubuntu trusty image previously offered a "vagrant"
> user, and that was lost or omitted when migrating xenial+ to a new
> build system. This could be considered a regression, although
> historical context of that change is unfortunately not available
> anymore.
>
> [test case]
>
> From a fresh Ubuntu install:
>
> * sudo apt install vagrant
>
> * vagrant init ubuntu/xenial64
>
> * vagrant up
>
> * vagrant ssh
>
> notice the user being logged in as is "ubuntu"
>
> With either ubuntu/artful64 or ubuntu/trusty64, the same steps log the
> user in as "vagrant".
>
> An image with the proposed changes was built and uploaded as
> "tribaal/xenial64".
>
> [Regression potential]
>
> * Users who worked around this behavior in their automation are the
> most at-risk. They might not be able to login to their boxes anymore,
> if they worked around by extracting the ubuntu password from the box
> metadata. If they worked around t...

[dizeee (dizeee)]

Sorry for late reply. Just tested the box. My provisions work fine but I can't ssh to the box using password. Not a major issue for me but it's definitely not an expected behavior.

[Jim Adamson (jimadine)]

@dizeee Perhaps add the following to your Vagrantfiles to enable password authentication?

config.vm.provision :shell, :inline => "sed -i 's/PasswordAuthentication no/PasswordAuthentication yes/g' /etc/ssh/sshd_config && systemctl reload sshd"

Not sure if password disabled by default is by design or not.