/etc/hosts management

[nico-loeber]

Currently the hosts management is skipped when starting a project via the plugin, as this is a non interactive process and entering the sudo password is required for this step.
Another problem is, that using ddev inside wsl the host entry needs to be set in Windows and not the WSL environment.
The ddev integration plugin should have all required information and permissions to do the /etc/hosts management bypassing the ddev internal one to allow a better OS compatible permission management and a better WSL integration.

[nico-loeber]

This issue might be solved or at least by changing the way DDEV is used inside WSL.
As I currently discuss this with @rfay, I will delay the work on this issue.

[nico-loeber]

Installing DDEV like like described in this documentation, solves the WSL part of this issue.
It is based on this concept: https://gist.github.com/nico-loeber/6d6e8261827c5e4efa4ccf5b5cd04140

Sadly this way will probably no become the officially supported one.

[rfay]

Note that /etc/hosts is not a part of the picture when using *.ddev.site, only when using additional_fqdns or an alternate tld. The hosts file does not have to be touched either on Windows or inside WSL2 in the "normal" workflow.

I would like to see dual-hosts-file management for the non-ddev.site situation though in

• Make WSL2 setup for Windows easier ddev/ddev#3277

[nico-loeber]

Created the issue ddev/ddev#3818 for this.

@rfay, sorry noticed your comment just after creating the issue. In case I normally don't need to touch the hosts file, there might be a misconfiguration or misunderstand on my side. Lets discuss this in the ddev issue.

[nico-loeber]

As @rfay already stated there is no need for editing host files in common sitations.
The problem we encountered here was that the resolution of *.ddev.site was rejected by the router for sercurity reasons.
This behavior is explained in the DDEV documentation: https://ddev.readthedocs.io/en/latest/users/troubleshooting/#dns-rebinding-prohibited
There seems to be no need to resolve this issue on the plugin side, so this issue is closed.