maybe switching the local domains from .local to .test removes the need of a proxy anyway, since .te

U01MPS2P823

maybe switching the local domains from .local to .test removes the need of a proxy anyway, since .test is actually a standardized dev/local TLD 🙂 cc @U01FMSKE9E3

Valerii Trots

cc @UPZH5HHEV

U01N167PSBC

Was just proposing the proxy since the gateway is doing the routing to the containers at the moment, dinghy would just be a replacement for convenience, making the setup of different projects und different domains a lot easier, ... but yes *.test would be the lowest hanging fruit at the moment 🙂

U01FMSKE9E3

I ended up placing all the domains needed into the Linux host /etc/hosts file (which is kinda 1990 technology ), because at least modern Ubuntu distributions use avahi and scrue up any clean attempt to configure .local nicely without /etc/hosts hacking.

But in general, with debian/Ubuntu or RedHat like systems, the "recommended" way to masquerade domains to local addresses is simply... well - masquerading it! As a proxy is a little bit heavy-weight just for this purpose:

• install dnsmasq package
• Make NetworkManager to use it (usually found in a typical LSB configuration somewhere under /etc/NetworkManager/<>.conf or /etc/NetworkManager/conf.d/<>.conf

dns=dnsmasq

• Add the local addresses you want to masquerade to your own dnsmasq plugin configuration file

# New file, for instance: /etc/NetworkManager/dnsmasq.d/devbox

local=/test/
local=/localhost/
local=/local/

address=/test/127.0.0.1
address=/localhost/127.0.0.1
address=/local/127.0.0.1

This is it. Everything mentioned there will go to localhost, everything else will fallback to dns / mdns or other internal configuration of name lookups.

However, on modern Ubuntu distributions, and I guess also on other Linux derivates, .local is not allowed anymore and usually used by avahi daemon or "forbidden" in some default mdns configurations, so you will experience special defects only with this TLD like I did.

And because browsers like Chrome will still complain an simply not work with this "special" domain (just try setting up self-signed certificates for a .local domain and accessing it with Chrome, good luck! ;-)), IMHO the easiest and most elegant way would be to simply follow the IETF recommendations and avoid any other problems from the beginning. Which is: use ._test_ for local domains instead.

"The first is using a generic top-level domain. Generic TLDs like .local, .lan, .corp, etc, are now being sold by ICANN, so the domain you’re using internally today – company.local could potentially become another company’s property tomorrow. If you’re still not convinced, here are some more reasons why you shouldn’t use .local in your Active Directory domain name"

U01FMSKE9E3

Google of course jumped pretty early on the train and also used the new SSL layer implementation recommendation in their browser, so the problem is known already since 2017, when Chromium-Browsers simply started denying using .local with a self-signed certificate. And later also screwing more an more things when trying to run local stuff under this domain and mistakenly pointing an internal address 😉.

sprymiker

@U01MPS2P823 You can set any domain names in your deploy.yml as you fully control it on your side.

Anyway thanks for the hint.

sprymiker

@U01FMSKE9E3 Thank you very much for your propositions. It is very valuable for us. I’ve already get some new clues from your post.

Some notes from my side:

1. We chose /etc/hosts as it is (regardless it is the 1990th approach)
   a. Very simple. Simple documentation, simple actions.
   b. Cross-platform. It works in any linux, MacOS, Windows+WSL.
   c. No impact on the host system. No additional software, etc.
2. docker/sdk does not interfere with the host system directly. It just recommends to run some specific commands. And that is user’s will how to configure the host system. You can use any local domain names as you control your deploy.yml. You can use any DNS solutions locally on on CI/CD. No limitations from docker/sdk.
3. .test still is not self resolved (at least on my MacOS). You will need the very same actions as we do with .local domain. I do not see any significant differences, others when Chrome tries to search spryker.local instead of opening it.
4. .local will never be sold by ICANN as it is reserved domain name according to specifications here: https://www.iana.org/assignments/special-use-domain-names/special-use-domain-names.xhtml. It is similar to localhost, but Multicast DNS. And it is not listed in https://data.iana.org/TLD/tlds-alpha-by-domain.txt as zero-level domains.
5. SSL does work for .local domains in Chrome, Safari without any problems by registering self-signed root certificate in the host system.
   Yes, in general, I agree that .localhost or .test match better than .local from technical perspective, but it does not matter from user perspective. And IMO spryker.local looks more reliable and obvious than spryker.test or spryker.localhost .

We will consider this topic and probably change default values in the Spyker demoshops later.

Thank you for you contribution, guys!

sprymiker

The best solution would be using
http://localtest.me/

Description:
https://readme.localtest.me/