Poor choice of port 8001 in Ubuntu Server 14.04 LTS (Trusty Tahr) Cloud VM images conflicts

[philpraxis]

Using port 8001/tcp for Juju server in Ubuntu Server 14.04 LTS (Trusty Tahr) Cloud VM images is a poor choice.

It conflicts with many of the frameworks for webapp development and therefore make it fail when doing Vagrant setup of such cloud images.

In: https://cloud-images.ubuntu.com/vagrant/trusty/

trusty-server-cloudimg-amd64-juju-vagrant-disk1.box 30-Jul-2014 06:29  638M  Ubuntu Server 14.04 LTS (Trusty Tahr) daily builds
trusty-server-cloudimg-i386-juju-vagrant-disk1.box  30-Jul-2014 06:34  628M  Ubuntu Server 14.04 LTS (Trusty Tahr) daily builds

This creates problem such as:

~/dev/vagrant user$ vagrant up
Bringing machine 'default' up with 'virtualbox' provider...
==> default: Box 'trusty' could not be found. Attempting to find and install...
    default: Box Provider: virtualbox
    default: Box Version: >= 0
==> default: Adding box 'trusty' (v0) for provider: virtualbox
    default: Downloading: https://cloud-images.ubuntu.com/vagrant/trusty/trusty-server-cloudimg-amd64-juju-vagrant-disk1.box
    default: Progress: 0% (Rate: 1271k/s, Estimated time remaining: 0:08:32)
    default: Progress: 1% (Rate: 1532k/s, Estimated time remaining: 0:07:15)
    default: Progress: 41% (Rate: 1520k/s, Estimated time remaining: 0:04:10)
    default: Progress: 81% (Rate: 1532k/s, Estimated time remaining: 0:01:18)
    default: Progress: 84% (Rate: 1545k/s, Estimated time remaining: 0:01:06)
==> default: Successfully added box 'trusty' (v0) for 'virtualbox'!
==> default: Importing base box 'trusty'...
==> default: Matching MAC address for NAT networking...
==> default: Setting the name of the VM: vagrant_default_1407250776484_38665
==> default: Clearing any previously set forwarded ports...
Vagrant cannot forward the specified ports on this VM, since they
would collide with some other application that is already listening
on these ports. The forwarded port to 8001 is already in use
on the host machine.

To fix this, modify your current projects Vagrantfile to use another
port. Example, where '1234' would be replaced by a unique host port:

  config.vm.network :forwarded_port, guest: 8001, host: 1234

Sometimes, Vagrant will attempt to auto-correct this for you. In this
case, Vagrant was unable to. This is usually because the guest machine
is in a state which doesn't allow modifying port forwarding.
~/dev/vagrant user$ 

https://stackoverflow.com/questions/10953070/how-to-debug-vagrant-cannot-forward-the-specified-ports-on-this-vm-message/25142933#25142933

And the result is not seamless (and first impression is that something called Juju which is default in new Ubuntu is causing problems, not what you want.)

Defaulting to a less frequently used application port (better, ask Service Name and Port Number Registry at https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?&page=128 if you can).

Thank you,
Best regards,
Philippe.

[mattyw]

@philpraxis thanks for your bug report. We'll investigate what options are open to us. Just out of interest which framework were you using at the time of this issue?

Some more analysis for interested parties:

I believe it's the juju-gui that is listening on 8001. Vagrant is forwarding host:8001 -> vm:8001 for the gui that's causing this problem. Maybe this is something we could fix in the vagrant box?

[philpraxis]

A. Usage

@mattyw I'm using Django, it starts its web server at 8000 and then correct practice is keeping incrementing for each new app.

But this is a commonly used port by services you'll typically find associated with the kind of virtualized, cloud and devops environment (such as Juju plays in):
Splunk IIRC,
many Vagrant docs, tutorials and example configs, ( https://www.google.fr/search?q=vagrant+port+8001 == About 101,000 results )

B. Vagrant box file

Yes, I think you can change this within the box file. No need to change the default in upstream (juju).

[castrojo]

Going to ask Ben to have a look. Shouldn't we be putting things like the GUI in a container and mapped out instead of hulk smashing inside the box?

[mattyw]

@castrojo Thanks, this might end up tying in with the "deploy gui as default" discussion happening on the mailing list

[chuckbutler]

@castrojo The purpose behind smashing the GUI on the VM instead of a LXC container was to provide the GUI out of the box, vs if you deploy it into a container, the user will be required to use sshuttle just to get to the gui.

I'm going to kick around some ideas relating to iptables rule sets to do mappings to the containers, and follow up on the list with this idea.

@philpraxis Thank you for identifying this as an issue.

[marcoceppi]

@chuckbutler Why not just have the GUI map to another port? Maybe something we can expose in the the Vagrantfile as an override?

[philpraxis]

@chuckbutler You're welcome. I think the entire point of this whole dynamic (what to call it? DevOps? Containerization? Atomic-based operations?) is to have sensible defaults in ops, just like Rails was quite a blast for its pioneer usage of "sensible defaults" in dev.
For that reason, starting to play with iptables to "fix" this issue feels weird: it adds a layer of complexity that IMO is overkill. It doesn't appear in "netstat -tunlp" and therefore is uneasy for the newbie.

[chuckbutler]

Abel Deuring is actually working on this at present, and has some notes regarding the issues he's running into. I'll defer unto that list pending a proposed solution and update accordingly.

[AdamIsrael]

I'm unable to recreate this using the latest Vagrant and Trusty cloud image. @philpraxis, can you confirm that this is still an issue for you?

[anastasiamac]

We have not heard back for almost a year.

If the issues persists, please file a bug in https://bugs.launchpad.net/juju-core/