On the getting started page, we should use the request data to determine the way the user is accessing the OVA

[zjs]

VIC Product version:

vic-v1.3.0-rc2-2628-9e2a95b6.ova

Deployment details:

N/A

Steps to reproduce:

N/A

Actual behavior:

As of #1066, we use the OVA's hostname from its point of view when rendering links to other services hosted on the OVA.

Expected behavior:

We should use the hostname from the user's point of view. In complex networking scenarios, the OVA may be behind NAT or reverse proxy. In those cases, the OVA's hostname or IP address from its point of view may not be reachable by the user. The request contains the hostname that worked for the user to access the OVA — it's likely that's what they would expect to be used when clicking links.

Additional details as necessary:

This has an added benefit of removing the need for sub-process execution:

vic-product/installer/fileserver/tasks.go

Lines 138 to 162 in bf98353

	func getHostname(ovf lib.Environment, vmIP net.IP) string {
	// Until we gix transient hostnames, use the static hostname reported by hostnamectl.
	// os.Hostname() returns the kernel hostname, with no regard to transient or static classifications.
	// fqdn, err := os.Hostname()
	// var url string
	// if err == nil && fqdn != "" {
	// return fqdn
	// } else {
	// return vmIP.String()
	// }
	command := "hostnamectl status --static"
	// #nosec: Subprocess launching with variable.
	out, err := exec.Command("/bin/bash", "-c", command).Output()
	if err != nil {
	log.Errorf(err.Error())
	return vmIP.String()
	}
	outString := strings.TrimSpace(string(out))
	if outString == "" {
	return vmIP.String()
	}
	return outString
	}

Acceptance Criteria

• We can run a full workflow against an OVA which is hidden behind NAT.

[mlh78750]

@pdaigle how common do you think the appliance having a different DNS name behind NAT will be for customers?

[mlh78750]

@stuclem Do we have this limitation documented anywhere? We might need to release note this if we decide not to fix for 1.3.

[stuclem]

@mlh78750 and @zjs, no we do not document this limitation. Is there a workaround?

[mdubya66]

added to 1.3 for further investigation and response from @pdaigle

[zjs]

@stuclem: The release note for this would be [a wordsmithed version of] something like: The "Getting Started" page of the VIC Appliance includes links to other services running on the VIC Appliance. The way those links are constructed assume that users connect to the appliance using its IP or FQDN (i.e., that it is not hidden behind NAT or a reverse proxy).

I don't think we want to try to fix this for 1.3; I suspect we haven't tested this case at all so even if we fix the Getting Started page, it's likely that other things don't handle this case well either.

[mlh78750]

Additionally, the work around could be to add the FDQN that the appliance knows itself as to the /etc/hosts file (or the windows equiv) of the client machine pointing to the translated IP the client sees and everything will work.

[stuclem]

Attempted release note:

• Services are not available if accessed through NAT or a reverse proxy. #1172
  The Getting Started page of the appliance includes links to the services running on the appliance. These links are constructed assuming that users connect to the appliance by using its IP or FQDN, and that it is not hidden behind NAT or a reverse proxy.

  Workaround: Add the FDQN by which the appliance identifies itself to the /etc/hosts file of the client machine, pointing to the translated IP address that the client sees.

@mlh78750 @zjs is this OK?

[stuclem]

Thanks @zjs. Removing kind/note.

[ghost]

Ensure that any changes to the getHostname function do not affect the psc registration process.
The links can be generated by using the request host headers from the http request.

Additionally, we should also ensure that this line is functional with a "hidden" hostname.