seems like carving out a system-wide unique name like this when there could be multiple containers/VMs running doesn't scale

We are already doing a lot to special-case the Crostini container for ease of access, eg building a setup flow. For power users who want to run multiple containers, they can use IP or we can consider some combo of container/VM names (eg. <container>.<vm>.local).

(this is related to  issue 626377 )

If you are using "dev.local", you should be implementing the name conflict resolution algorithm for multicast DNS:
https://tools.ietf.org/html/rfc6762#section-9

See also https://support.apple.com/en-us/HT201275

Maybe it would be better to use ".test", or have Google register a domain name reserved for this?
https://en.wikipedia.org/wiki/.test

re-#2, i don't think that's a good argument for continuing to make crostini special.  i also don't think "just use the IP" is an acceptable solution.  we're building a general platform which crostini is a showcase.  we're not building all this container/vm stuff for crostini.

imo we should sort this out sooner rather than just "we'll redo it later" because we're going to be training people/scripts to rely on specific behavior that we can't undo later.  and honestly, we never "get to it later".

using something like <container>.<vm>.vm.local might be a good starting point for only on the local device.  but what about supporting people who want to run a server in their container for access outside of the Chromebook ?  i get that we haven't fully fleshed out this on the actual networking side, but we should have a design that doesn't paint us into a corner from the outset.

as Adam points out, typically ".local" is used for local hostname registration and not just within a single machine to facilitate LAN communication.

maybe "<container>.<vm>.test" would be sufficient.  or "<container>.<vm>.localhost" ?

considering all the issues raised, maybe this deserves a design doc so we can clearly record the reasoning behind each choice :P.

As I said, I'm definitely open to a strategy for assigning names to each container. "<container>.<vm>.localhost" would be a nice default, and I think the tie-in to "localhost" would make it feel familiar to developers.

Separately, I do think we should have mechanisms that treat Crostini better *by default*, but could easily be applied to other containers. Eg. if we have a mechanism where users can set up a shortcut for a container (eg. "<custom_name>.localhost"), we could also have it by default used to map "dev.localhost" to "penguin.termina.localhost" (or whatever our full name would be), which would make it easier to access for new users. Other users could also then create shortcuts to the containers they use most often.

In general I'm all for finding solutions that treat all containers equally.  Since I do believe that far more users will interact directly with the Crostini container than manually manage their own VMs/conainers, I just want to make sure they can have as smooth an experience as possible.

glancing at RFC6761, i don't think we'd be violating the letter by using "xxx.localhost" to resolve to something other than 127.0.0.1/::1.  maybe Adam can sanity check the spirit or future developments to make sure we don't head in the wrong direction now.

otherwise, "xxx.test" is prob our next best bet.  if/when we want to get into VMs/containers being accessible externally, we'll look at "xxx.local".

Also, re: accessing a server from outside of the Chromebook --

My typical experience has been to run ifconfig, grab the IP address from there, and type it on another device along with whatever my port is. My assumption is that we'll need some way to have users expose ports from their containers, and then find their Chromebook's IP address. While that wouldn't tie into the naming, let me know if there's a nicer flow we should support.

that's the point of the ".local" domain.  the Chromebook could broadcast xxx.local is the Chromebook's IP, and any other system on the LAN that supports mDNS would be able to use that name.  but then you run into possible conflicts as Adam pointed out, so that's why it'd be nice to have both a localhost-always-usable one and a best-effort-LAN one.

If you broadcast the ".local" with avahi, then you do get automatic name conflict resolution. This is how it works on Mac. We'd probably need a way to set the hostname of the chromebook and show the user what the un-conflicted name is.

If you have a port-exporting mechanism, then outside computers can reach the chromebook this way. So that all sounds fine.

As for reaching the virtual hosts, I'm not an expert here. It doesn't sound like .localhost is the right thing though. ".test" is probably safer.

What I typically do on my home machine with containers is to install avahi in each container and assign a unique hostname. Then ".local" works from the local machine.


Also:

Google owns ".dev". It would be nice if we could get a subdomain like ".local.dev" reserved permanently and globally for this. (See external sadness around this: https://medium.engineering/use-a-dev-domain-not-anymore-95219778e6fd)

This is another option:
https://wiki.libvirt.org/page/NSS_module

There isn't really a need for DNS names, just a bare hostname is fine.

I vote for localhostini

linuxhost it is based on a bikeshed discussion we just had in the leads meeting.

This may help if you are choosing a name: https://support.comodo.com/index.php?/Knowledgebase/Article/View/722

I think in addition to using 'linuxhost' as the hostname for the primary Crostini container, we can then also do <container>.<vm>.localhost as mentioned by vapier. Then we have the easy one for the general case, and then specific ones for more advanced cases.

Since the default container.vm name is penguin.termina, it'll also be nice to type in just 'linuxhost' rather than penguin.termina.localhost.

I'll start looking into how to implement this.

Comment #15 sounds good to me, thanks!

For I/O, just run "xdg-open http://localhost:8000" (or whatever other local URL). This will be automatically replaced with the container's IP.

> Google owns ".dev". It would be nice if we could get a subdomain like ".local.dev" reserved permanently and globally for this.

I prefer this idea.  According to RFC 6761 and RFC 2606, .localhost should resolve to a loopback address.  These containers are on a private subnet; the interfaces in question are not loopback interfaces.

I concur with @cernekee on this, it's pretty clear in the spec that .localhost is only for loopback addresses (thanks for diving into that). For now I'll just have it register 'linuxhost' and then I'll get started on figuring out who I need to talk to in order to see if we can reserve the 'local.dev' subdomain for this purpose...or find out what other options we have within that TLD.  Having the one name (i.e. linuxhost) will fit all the needed use cases for now though so I don't want to block the work on resolving the .dev issue.

There's also another option we have here rather than using the .local.dev subdomain. We can just generate unqualified hostnames for these instead. Such as <container>-<vm>-local which avoids dealing with the TLD.

Might be good to avoid .dev : https://medium.engineering/use-a-dev-domain-not-anymore-95219778e6fd

"Almost three years later, a commit to Chromium ... would throw sand in the gears of our development environment. ... What changed? Chromium forced all domains with the .dev TLD to only respond to secure connections."

Does our PA own the .chrome TLD?

https://icannwiki.org/Google#Applications

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/overlays/eclass-overlay/+/b651a0c7ff81a7f1a29375d278c1711d8006e73b

commit b651a0c7ff81a7f1a29375d278c1711d8006e73b
Author: Jeffrey Kardatzke <jkardatzke@google.com>
Date: Tue May 08 03:45:36 2018

Add users for crosdns service

Design doc here: go/crostini-hostnames

BUG= chromium:825010 
TEST=Emerge works

Change-Id: I61479182d202af68f546c44a26dca148d878a819
Reviewed-on: https://chromium-review.googlesource.com/1045100
Commit-Ready: Jeffrey Kardatzke <jkardatzke@google.com>
Tested-by: Jeffrey Kardatzke <jkardatzke@google.com>
Reviewed-by: Dan Erat <derat@chromium.org>

[add] https://crrev.com/b651a0c7ff81a7f1a29375d278c1711d8006e73b/profiles/base/accounts/user/crosdns
[add] https://crrev.com/b651a0c7ff81a7f1a29375d278c1711d8006e73b/profiles/base/accounts/group/crosdns

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/platform/system_api/+/7eb063355cb60abacd67c9d142bee4b7fea7c07a

commit 7eb063355cb60abacd67c9d142bee4b7fea7c07a
Author: Jeffrey Kardatzke <jkardatzke@google.com>
Date: Tue May 08 03:45:52 2018

Add D-Bus service constants for CrosDNS service.

Design doc here: go/crostini-hostnames

BUG= chromium:825010 
TEST=Builds

Change-Id: I9b80513b2ac771dde7def6aefe45c658fd17f112
Reviewed-on: https://chromium-review.googlesource.com/1045140
Commit-Ready: Jeffrey Kardatzke <jkardatzke@google.com>
Tested-by: Jeffrey Kardatzke <jkardatzke@google.com>
Reviewed-by: Dan Erat <derat@chromium.org>

[modify] https://crrev.com/7eb063355cb60abacd67c9d142bee4b7fea7c07a/dbus/service_constants.h

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/platform2/+/c9a77b91d455f9f209152a2e02a73e6137807407

commit c9a77b91d455f9f209152a2e02a73e6137807407
Author: Jeffrey Kardatzke <jkardatzke@google.com>
Date: Wed May 09 11:33:16 2018

crosdns: Initial version of hostname resolver service

Design doc: go/crostini-hostnames

This adds a service where hostname:ip mappings can be set and removed.
Currently this will write to the /etc/hosts file in order to accomplish
this. Later this service can be expanded to cover additional name
resolution/DNS functionality.

This is the complete code for the first version, with the exception of
the seccomp policy which will be done after the code is approved for the
service.

BUG= chromium:825010 
TEST=Unit tests pass, verified with dbus-send on Chromebook
CQ-DEPEND=CL:1045140

Change-Id: I97c8b471d4f156a33e0392eeee55d96d49488781
Reviewed-on: https://chromium-review.googlesource.com/1045250
Commit-Ready: Jeffrey Kardatzke <jkardatzke@google.com>
Tested-by: Jeffrey Kardatzke <jkardatzke@google.com>
Reviewed-by: Ben Chan <benchan@chromium.org>

[add] https://crrev.com/c9a77b91d455f9f209152a2e02a73e6137807407/crosdns/dbus_adaptors/org.chromium.CrosDns.xml
[add] https://crrev.com/c9a77b91d455f9f209152a2e02a73e6137807407/crosdns/hosts_modifier_unittest.cc
[add] https://crrev.com/c9a77b91d455f9f209152a2e02a73e6137807407/crosdns/hosts_modifier.h
[add] https://crrev.com/c9a77b91d455f9f209152a2e02a73e6137807407/crosdns/crosdns_daemon.h
[add] https://crrev.com/c9a77b91d455f9f209152a2e02a73e6137807407/crosdns/hosts_modifier.cc
[add] https://crrev.com/c9a77b91d455f9f209152a2e02a73e6137807407/crosdns/dbus_permissions/org.chromium.CrosDns.conf
[modify] https://crrev.com/c9a77b91d455f9f209152a2e02a73e6137807407/PRESUBMIT.cfg
[add] https://crrev.com/c9a77b91d455f9f209152a2e02a73e6137807407/crosdns/main.cc
[add] https://crrev.com/c9a77b91d455f9f209152a2e02a73e6137807407/crosdns/crosdns.gyp
[add] https://crrev.com/c9a77b91d455f9f209152a2e02a73e6137807407/crosdns/README.md
[add] https://crrev.com/c9a77b91d455f9f209152a2e02a73e6137807407/crosdns/init/crosdns.conf
[add] https://crrev.com/c9a77b91d455f9f209152a2e02a73e6137807407/crosdns/OWNERS
[add] https://crrev.com/c9a77b91d455f9f209152a2e02a73e6137807407/crosdns/dbus_adaptors/dbus-service-config.json
[add] https://crrev.com/c9a77b91d455f9f209152a2e02a73e6137807407/crosdns/crosdns_daemon.cc
[modify] https://crrev.com/c9a77b91d455f9f209152a2e02a73e6137807407/README.md

As mentioned above, "xdg-open" translates "localhost" address inside the container into the IP address of the VM+container in Chrome OS. Will it also support translation of the "0.0.0.0" address? Otherwise, this approach may lead to user confusion that a server inside the container only needs to listen on "localhost", while it should be listening on "0.0.0.0". In addition, clicking on a link with "0.0.0.0" inside the container fails to reach it in Chrome, since it's not translated (unlike a "localhost" link).

Which module is in charge of this translation at the moment (pardon if that's out of scope of this issue)?

@dinvlad@gmail.com vm_concierge is what does the translation currently, and this is done after any request like this is sent out of the container. If someone is developing a server in the container, I'd expect them to bind the server to the wildcard address instead of localhost...and when trying to hit the server they would use the localhost address. I haven't ever heard of somebody using 0.0.0.0 from the client to try to connect to a server on the wildcard address so it doesn't seem like we'd want to translate that one as well....unless this is just something I'm not familiar with developers doing.

jkardatzke@chromium.org - that's understandable, thanks for the feedback!

Some editors (e.g. VS Code) open links when the user Ctrl-clicks on them in the terminal; and some developer tools (e.g. Webpack dev server) may automatically open the URL according to the value of their "host" parameter.

If the host is wildcard, currently these mechanisms open a non-working URL, because it's not routed to the VM. Whereas, if we develop on the same host (e.g. outside of a VM in another OS), these links are resolved successfully.

It'd be really convenient if the wildcard address was translated into "linuxhost" mentioned above (or any other suitable address). This is surely just a nice-to-have, as we can listen on the IP address of the container instead, but it'd improve developer experience.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/overlays/chromiumos-overlay/+/eca1b3fc5ab32ed5aaaf6962f747b483b22b2b62

commit eca1b3fc5ab32ed5aaaf6962f747b483b22b2b62
Author: Jeffrey Kardatzke <jkardatzke@google.com>
Date: Sat May 12 06:22:18 2018

Add ebuild for crosdns service

Design doc: go/crostini-hostnames

This adds the ebuild for the new crosdns service and then lists that as
a dependency when kvm_host is set for the overall build.

In order to allow dynamically updating the /etc/hosts file in an atomic
way through bind mounting, this makes a new directory /etc/hostsdir
which the /etc/hosts file is moved into and then /etc/hosts is symlinked
to /etc/hostsdir/hosts. Then the crosdns service bind mounts its
/run/crosdns directory on top of /etc/hostsdir. That way changes to
/run/crosdns/hosts can be done atomically and reflect in /etc/hosts.

BUG= chromium:825010 
TEST=Built image and verified functionality on eve
CQ-DEPEND=CL:1045250,CL:1045100

Change-Id: I4e25c497d9aad9afd0b8600c32c8122f6792438c
Reviewed-on: https://chromium-review.googlesource.com/1045251
Commit-Ready: Jeffrey Kardatzke <jkardatzke@google.com>
Tested-by: Jeffrey Kardatzke <jkardatzke@google.com>
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>

[rename] https://crrev.com/eca1b3fc5ab32ed5aaaf6962f747b483b22b2b62/virtual/target-chromium-os/target-chromium-os-1-r99.ebuild
[add] https://crrev.com/eca1b3fc5ab32ed5aaaf6962f747b483b22b2b62/chromeos-base/crosdns/crosdns-9999.ebuild
[modify] https://crrev.com/eca1b3fc5ab32ed5aaaf6962f747b483b22b2b62/virtual/target-chromium-os/target-chromium-os-1.ebuild
[modify] https://crrev.com/eca1b3fc5ab32ed5aaaf6962f747b483b22b2b62/sys-apps/baselayout/baselayout-2.2.ebuild

> "xdg-open" translates "localhost" address inside the container into the IP address of the VM+container in Chrome OS. Will it also support translation of the "0.0.0.0" address?

I'm not sure if there is a good way around this; it seems like it's best to change the application's behavior so that it is aware it is serving out pages to other hosts on the LAN, and specifies a legitimate hostname in the URL.  Don't developers need that functionality anyway to work with other team members?

http://0.0.0.0 might happen to work (as do e.g. `telnet 0 22` and http://2130706433 ) but it's sort of a strange thing to see in practice...

> http://0.0.0.0 might happen to work (as do e.g. `telnet 0 22` and http://2130706433 ) but it's sort of a strange thing to see in practice...

Understood - this is technically true. However, many folks on message boards are now stumbling on this issue, and seem confused about the whole VM+container setup. The most common suggested solution is to listen on 0.0.0.0, and then open the IP address of the container reported through `ip addr` or `hostname -I`.

I think the crosdns solution suggested above will work nicely, as long as it's prominently documented somewhere. Sorry if this is more of a documentation issue that probably belongs elsewhere.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/platform2/+/a90e55ea443fa14e96f6229eada3567d0d20917c

commit a90e55ea443fa14e96f6229eada3567d0d20917c
Author: Jeffrey Kardatzke <jkardatzke@google.com>
Date: Thu May 17 10:24:17 2018

crosdns: Add seccomp policies and change /etc/hostsdir to /etc/hosts.d

This adds the seccomp policy files for the crosdns service and then also
changes the location of the bind mounted /etc/hosts file from
/etc/hostsdir/hosts to /etc/hosts.d/hosts.

BUG= chromium:825010 
TEST=Verified with manual testing on kevin and eve
CQ-DEPEND=CL:1060160

Change-Id: I9f301396226e069e7d7ac21dd11f3c243e253076
Reviewed-on: https://chromium-review.googlesource.com/1060159
Commit-Ready: Jeffrey Kardatzke <jkardatzke@google.com>
Tested-by: Jeffrey Kardatzke <jkardatzke@google.com>
Reviewed-by: Jorge Lucangeli Obes <jorgelo@chromium.org>

[modify] https://crrev.com/a90e55ea443fa14e96f6229eada3567d0d20917c/crosdns/init/crosdns.conf
[add] https://crrev.com/a90e55ea443fa14e96f6229eada3567d0d20917c/crosdns/init/crosdns-seccomp-arm.policy
[add] https://crrev.com/a90e55ea443fa14e96f6229eada3567d0d20917c/crosdns/init/crosdns-seccomp-amd64.policy

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/overlays/chromiumos-overlay/+/7a60bad15cb94749a1dea8351c6866612abe71fe

commit 7a60bad15cb94749a1dea8351c6866612abe71fe
Author: Jeffrey Kardatzke <jkardatzke@google.com>
Date: Thu May 17 10:24:18 2018

Change hostdir to hosts.d, add seccomp for crosdns

This changes the symlink target for /etc/hosts from /etc/hostsdir/hosts
to be /etc/hosts.d/hosts instead. It also adds installation of the
seccomp policy files for crosdns.

BUG= chromium:825010 
TEST=Built and verified works on kevin and eve
CQ-DEPEND=CL:1060159

Change-Id: I8706784820457431363b9912e8ad1291cd8770a0
Reviewed-on: https://chromium-review.googlesource.com/1060160
Commit-Ready: Jeffrey Kardatzke <jkardatzke@google.com>
Tested-by: Jeffrey Kardatzke <jkardatzke@google.com>
Reviewed-by: Dan Erat <derat@chromium.org>

[modify] https://crrev.com/7a60bad15cb94749a1dea8351c6866612abe71fe/chromeos-base/crosdns/crosdns-9999.ebuild
[modify] https://crrev.com/7a60bad15cb94749a1dea8351c6866612abe71fe/sys-apps/baselayout/baselayout-2.2.ebuild

There was one CL still hanging around that wasn't merged yet...removing Fixed.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/platform2/+/54d46c569a82619790c4f9c080d9e6fd0744b51d

commit 54d46c569a82619790c4f9c080d9e6fd0744b51d
Author: Jeffrey Kardatzke <jkardatzke@google.com>
Date: Fri May 18 08:27:46 2018

vm_tools: Use crosdns for container hostnames

This integrates concierge with the crosdns service for registering and
unregistering hostnames for containers. It uses 'linuxhost' for the
default VM/container of termina/penguin and then also uses
<container>-<vm>-local for all containers. If crosdns restarts, it will
re-register all the names.

BUG= chromium:825010 
TEST=Verified with manual testing

Change-Id: I8321231c753426b22dbe2c61023a34e6534dc436
Reviewed-on: https://chromium-review.googlesource.com/1060130
Commit-Ready: Jeffrey Kardatzke <jkardatzke@google.com>
Tested-by: Jeffrey Kardatzke <jkardatzke@google.com>
Reviewed-by: Stephen Barber <smbarber@chromium.org>

[modify] https://crrev.com/54d46c569a82619790c4f9c080d9e6fd0744b51d/vm_tools/concierge/service.h
[modify] https://crrev.com/54d46c569a82619790c4f9c080d9e6fd0744b51d/vm_tools/concierge/virtual_machine.cc
[modify] https://crrev.com/54d46c569a82619790c4f9c080d9e6fd0744b51d/vm_tools/concierge/virtual_machine.h
[modify] https://crrev.com/54d46c569a82619790c4f9c080d9e6fd0744b51d/vm_tools/concierge/service.cc

We are changing the hostname to be 'linux.test', so reopening this bug.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/platform/system_api/+/7d5a3280d573935518e4047623634fd08e7f6c31

commit 7d5a3280d573935518e4047623634fd08e7f6c31
Author: Jeffrey Kardatzke <jkardatzke@google.com>
Date: Tue Jun 26 09:55:42 2018

Add hostname to ContainerSshKeysResponse

BUG= chromium:825010 
TEST=Builds

Change-Id: I3488ba7a4ba5fef9cb03c642b28d42842fc6b704
Reviewed-on: https://chromium-review.googlesource.com/1113908
Commit-Ready: Jeffrey Kardatzke <jkardatzke@google.com>
Tested-by: Jeffrey Kardatzke <jkardatzke@google.com>
Reviewed-by: Dan Erat <derat@chromium.org>
Reviewed-by: Stephen Barber <smbarber@chromium.org>
Reviewed-by: Joel Hockey <joelhockey@chromium.org>

[modify] https://crrev.com/7d5a3280d573935518e4047623634fd08e7f6c31/dbus/vm_concierge/service.proto

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/platform2/+/26ac616732223d01e2bf60936790786f21baa71c

commit 26ac616732223d01e2bf60936790786f21baa71c
Author: Jeffrey Kardatzke <jkardatzke@google.com>
Date: Thu Jun 28 07:58:05 2018

vm_tools: concierge: Set hostname in SSH keys response

This sets the hostname to be the <container>-<vm>-local in the SSH keys
response. This is so that we can safely transition to
<container>.<vm>.test soon without introducing temporary breakage. Once
Chrome has updated to this change and Chrome OS is uprev'd to that
version of Chrome the we can do the change to .test.

BUG= chromium:825010 
TEST=Builds
CQ-DEPEND=CL:1113908

Change-Id: Ieb61885bcb160c0b01d7b297bf7c3f994682b19a
Reviewed-on: https://chromium-review.googlesource.com/1113913
Commit-Ready: Jeffrey Kardatzke <jkardatzke@google.com>
Tested-by: Jeffrey Kardatzke <jkardatzke@google.com>
Reviewed-by: Stephen Barber <smbarber@chromium.org>
Reviewed-by: Joel Hockey <joelhockey@chromium.org>

[modify] https://crrev.com/26ac616732223d01e2bf60936790786f21baa71c/vm_tools/concierge/service.cc

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/4d2da274d9e6e13f7710547575964e40e9e80ce0

commit 4d2da274d9e6e13f7710547575964e40e9e80ce0
Author: Joel Hockey <joelhockey@chromium.org>
Date: Fri Jun 29 03:02:25 2018

FilesApp get crostini hostname from concierge::ContainerSshKeysResponse

FakeConciergeClient test updates in crosreview.com/1119611

Bug:  825010 
Change-Id: I8d5a5f37a4f5dd30f450a36c4e0c61d4c4b41598
Reviewed-on: https://chromium-review.googlesource.com/1119506
Commit-Queue: Joel Hockey <joelhockey@chromium.org>
Reviewed-by: Nicholas Verne <nverne@chromium.org>
Cr-Commit-Position: refs/heads/master@{#571370}
[modify] https://crrev.com/4d2da274d9e6e13f7710547575964e40e9e80ce0/chrome/browser/chromeos/crostini/crostini_manager.cc
[modify] https://crrev.com/4d2da274d9e6e13f7710547575964e40e9e80ce0/chrome/browser/chromeos/crostini/crostini_manager.h
[modify] https://crrev.com/4d2da274d9e6e13f7710547575964e40e9e80ce0/chrome/browser/chromeos/extensions/file_manager/file_manager_private_apitest.cc
[modify] https://crrev.com/4d2da274d9e6e13f7710547575964e40e9e80ce0/chrome/browser/chromeos/extensions/file_manager/private_api_misc.cc
[modify] https://crrev.com/4d2da274d9e6e13f7710547575964e40e9e80ce0/chrome/browser/chromeos/extensions/file_manager/private_api_misc.h

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/29e5b214bc0a7d16610d41053a77a271e758d653

commit 29e5b214bc0a7d16610d41053a77a271e758d653
Author: Joel Hockey <joelhockey@chromium.org>
Date: Fri Jun 29 04:12:57 2018

FilesApp improve test for crostini hostname from FakeConciergeClient

Bug:  825010 
Change-Id: I384e1fc1e24572a2fc185d2ceac1bd9fa0b8a5bc
Reviewed-on: https://chromium-review.googlesource.com/1119611
Commit-Queue: Joel Hockey <joelhockey@chromium.org>
Reviewed-by: Ryo Hashimoto <hashimoto@chromium.org>
Cr-Commit-Position: refs/heads/master@{#571381}
[modify] https://crrev.com/29e5b214bc0a7d16610d41053a77a271e758d653/chrome/browser/chromeos/extensions/file_manager/file_manager_private_apitest.cc
[modify] https://crrev.com/29e5b214bc0a7d16610d41053a77a271e758d653/chromeos/dbus/fake_concierge_client.cc

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/platform2/+/4bbb4d9a8e0ac36a7a6f99afb8ad9d6204ac6afb

commit 4bbb4d9a8e0ac36a7a6f99afb8ad9d6204ac6afb
Author: Jeffrey Kardatzke <jkardatzke@google.com>
Date: Wed Jul 04 01:18:23 2018

crosdns/vm_tools: Use penguin.linux.test hostname for container

This changes the hostname for the default Crostini container to be
penguin.linux.test. It also changes the hostnames for any container to be
<container>.<vm>.linux.test.

BUG= chromium:849134 , chromium:825010 
TEST=Unit tests pass, verified /etc/host and Chrome connection

Change-Id: Ibee8acf994036775fed92c12cd4ffeb92f691790
Reviewed-on: https://chromium-review.googlesource.com/1112570
Commit-Ready: Jeffrey Kardatzke <jkardatzke@google.com>
Tested-by: Jeffrey Kardatzke <jkardatzke@google.com>
Reviewed-by: Jorge Lucangeli Obes <jorgelo@chromium.org>

[modify] https://crrev.com/4bbb4d9a8e0ac36a7a6f99afb8ad9d6204ac6afb/crosdns/hosts_modifier_unittest.cc
[modify] https://crrev.com/4bbb4d9a8e0ac36a7a6f99afb8ad9d6204ac6afb/vm_tools/cicerone/service.cc
[modify] https://crrev.com/4bbb4d9a8e0ac36a7a6f99afb8ad9d6204ac6afb/crosdns/hosts_modifier.cc
[modify] https://crrev.com/4bbb4d9a8e0ac36a7a6f99afb8ad9d6204ac6afb/vm_tools/concierge/service.cc

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/overlays/chromiumos-overlay/+/31ff951f1d977b7284f1952818313ca9a2650ee3

commit 31ff951f1d977b7284f1952818313ca9a2650ee3
Author: Mike Frysinger <vapier@chromium.org>
Date: Tue Jul 10 00:59:32 2018

vm_host_tools: update min system_api requirement

There were some API changes that current vm_tools requires.

BUG= chromium:825010 
TEST=precq passes

Change-Id: Ic3431e6fc2f54e6b49234378f8eb224d6974bd30
Reviewed-on: https://chromium-review.googlesource.com/1118859
Commit-Ready: Mike Frysinger <vapier@chromium.org>
Tested-by: Mike Frysinger <vapier@chromium.org>
Reviewed-by: Stephen Barber <smbarber@chromium.org>

[modify] https://crrev.com/31ff951f1d977b7284f1952818313ca9a2650ee3/chromeos-base/vm_host_tools/vm_host_tools-9999.ebuild

There might be a bug with setting up the hosts file?

https://www.reddit.com/r/Crostini/comments/8yelhn/chrome_dev_69034860/e2apzgu/

I can reproduce not being able to ping it from crosh...which is very weird. I just tested again with a python HTTP server and was able to connect to that from Chrome.

I'll reopen this bug to investigate more because I'd like to understand why we can't ping it from crosh since that'll be a typical debugging step for connection issues..

I chatted with vapier@ about this and crosh won't see the bind mount for /etc/hosts.d because it's running through debugd which has it's own mount namespace. We knew we'd have potential issues with mount namespaces when we set this whole thing up if we wanted to access the hostname from any jailed process (Chrome wouldn't have issues).  To make ping in crosh work we'd either have to have debugd be the one that spawns crosdns or we'd have to run the ping command in the namespace of the chronos user. Neither really sounds worth the trouble....but worth mentioning in that reddit thread that pinging penguin.linux.test is not expected to work from crosh (I'm not on reddit, so hopefully someone else will comment to that effect).

Updated r/Crostini with a reference to #c50 -
https://www.reddit.com/r/Crostini/comments/8yelhn/chrome_dev_69034860/e2bx9l7