Closed pento closed 6 years ago
.localhost
seems particularly appropriate among these options. But what about .local
?
That has too many overloaded meanings in a Bonjour environment. Unless specifically going for such a la VIP QuickStart, it may be more trouble than it's worth.
Doug Stewart
On Feb 28, 2015, at 9:00 PM, Weston Ruter notifications@github.com wrote:
.localhost seems particularly appropriate among these options. But what about .local?
— Reply to this email directly or view it on GitHub.
.test
would seem to be the better of the options.
I'm up for .test
as well. We can probably introduce the new TLD in the configs while continuing to support old .dev
installations.
I would vote for .localhost
since it would make the most sense to me.
.local
can not be used because it would clash with directory and other services.
We need to reach some kind of consensus here and can add the tld to the configs of the sites while keeping the current domain endings for the time being.
Ok, feedback time.
Options:
.localhost
.test
.local
I excluded .example
and .invalid
because they don't seem right. Decisions. :)
Please leave a comment, this is super serious stuff.
Short is best. I would go for dot test.
Edit (after finding out that local is avail.): Could it not be a choice on provision? If not, I'd prefer .local
over the other options
Per @rmccue, .local
is a valid option too. IMO, better than .localhost
. https://twitter.com/rmccue/status/701526969008062465
.local
.test
I'd like to avoid potential problems with Apple and .local.
if we opt for .local, can I suggest that some work be put towards setting-up avahi/zeroconf/mdns/bonjour support so that we don't need to utilise the hostsupdater plugin (which doesn't seem to be working for me atm)
.local
is super neat, since it's very easy to use with Avahi. Just install avahi-daemon
via apt-get, and you're basically done. No messing about with hosts files, no installing vagrant-hostsmanager/etc, just done. Works automatically on all OSX systems, most Linux desktops automatically (or install avahi-dnsconfd
on Ubuntu), and Windows systems with Bonjour installed (i.e. iTunes, Bonjour Print Services, Adobe CS3+ installed, or install manually. (Check the Chassis instructions.)
That is: intentionally use Zeroconf/Avahi. You can also use the dbus interface to avahi to automatically add subdomains if you want, although it's tricky.
Other .local
reading material (I haven't parsed it yet): http://www.justincarmony.com/blog/2011/07/27/mac-os-x-lion-etc-hosts-bugs-and-dns-resolution/
Other
.local
reading material (I haven't parsed it yet):
This stuff only applies if you're using the hosts
file, by the way. Zeroconf itself is pretty flawless (although Avahi not so much).
.local
providing zeroconf sounds excellent
Not .test
. Local sites are not necessarily test sites.
.local
Today I learned statistics for the L root name DNS server operated by ICANN
"As of August 14, 2015, that server has received approximately 1331 .local queries per second, third in frequency after .com (4355 queries per second), and .net (2481 queries per second)"
The anal-retentive perfectionist in my head strongly prefers .localhost
over .local
, since it's more descriptive, but if .local
makes configuration easier and removes a point of failure -- especially given https://github.com/cogitatio/vagrant-hostsupdater/issues/92 (cc @diddledan) -- then that's more important.
I agree with Gary that .test
doesn't really describe what VVV sites are typically used for.
.local
@iandunn's comment sums up my thoughts exactly. .localhost
is more correct and "better", but if .local
brings more things to the table than just less characters, then it probably makes more sense to go that direction.
I think that as long as VVV is using the hosts
file on the local computer for name resolution, even if Google gets the TLD .dev
, the local hosts
file will override any potential conflict. Having said that, I echo @iandunn's and @Viper007Bond's sentiments: .localhost
is more accurate but if .local
makes things easier that works too.
I originally voted for .test
because of my concerns for how .local
is handled by mDNS. After some additional research, I don't feel that .test
is really the appropriate TLD, but I still feel that .local
isn't appropriate, either.
Since we rely on local hosts files to manage DNS, .localhost
seems to be the most appropriate for our use. RFC2606 lists four internal TLDs with descriptions; RFC6761 goes into even more detail about the TLDs. Based on these docs, it seems that .localhost
is the most likely candidate to replace .dev
, based on how VVV uses domains and how its use is defined.
If the point is to make sense, this should go a bit more specific like .dev
was.
I update my vote from .test
to .vvv
(and .vv
for @bradp :stuck_out_tongue_winking_eye: ).
I think .vvv
was rejected as an option because it's not a reserved TLD. ICANN could issue .vvv
to a registrar at any point in the future, and then we'd be right back in this same situation.
I don't think Vietnamese Viagra Vendors request that TLD, but ok. :_)
Anyway .local
and .localhost
feels like out of the (virtual) box.
I don't want to rain on the "naming the band" discussion, but the testing I was doing to deal with #810 leads me to be concerned that the /etc/hosts approach may not be long for this world. If indeed one has to go to a dynamic DNS based-approach, the suffix may be determined for us.
That being said, if indeed I'm confused and /etc/hosts still remains a bright and vibrant future, I support @morganestes rationale for .localhost. There's lots to be said for using a name blessed by the RFCs.
At the very least, maybe make the domain suffix be easily changeable in the Vagrantfile or a known config file? (right now, there's a partial implementation of this idea using www/vvv-hosts) Then it could say "We recommend .localhost, but you should choose a suffix not in use in the real world." If you want to be really cool and impress your friends, the provisioning could do a quick lookup and say "hey, I can resolve vvv.something already, that seems bad and is likely to cause you strife, are you sure you want to do this? (y/n)".
@FYI: .local
is a reserved multicast DNS domain see https://tools.ietf.org/html/rfc6762
i.e. We can use .local
as it is reserved and with the extra benefits noted here I think its win-win
I guess that leaves us with .localhost
.
My vote is for .localhost
.
I'm partial to .dev
(given my name) but given the above options and the fact that .local
is a reserved multicast DNS domain and may introduce some as-of-yet-unforeseen confusion and gotcha's around configuration of VVV, I'd say that .localhost
makes the most sense here.
I've used .local (with the Zeroconf benefits) on our company standardized Vagrant box for WordPress development for some time and it works great. I really hope VVV would use .local out-of-the-box.
As long as you don't mind being inundated with issues relating to link-local collisions, this is a solution. I strongly suggest there be a way to choose TLD in configuration. That also lets someone use their own private domain, which is even better. local.wordpress.[example].[com]
FYI, I encountered this on Windows (where I'm running VVV inside of Hyper-V instead of VirtualBox, and where I've never been able to get the automatic vagrant-hostsupdater plugin to work, so I have to manually edit my hosts file), and found that the issue appeared to be related to how many domain names were defined on each line of my hosts file (or, possibly, the number of characters).
For me, once I added a 10th host name to a single line, I started getting the ERR_ICANN_NAME_COLLISION
error in Chrome, but once I split those host definitions onto two separate lines, the error went away.
Just a possible troubleshooting suggestion for those that might be running into this issue.
As #1282 says, it's time to get rolling on this. :)
I've been using some other local dev environments that still use a local hosts file with custom TLDs instead of zeroconf. In that vein, if VVV moves to a zeroconf system, then it makes sense now to implement it with .local
, else use .localhost
since it conveys better what VVV is used for.
Implementing with .local
would be extremely problematic, especially if it wasn't easily configurable. The .local
extension is used pretty extensively within enterprise to represent everything inside the corporate firewall (including, but not limited to, anything related to LDAP/Active Directory).
Relevant to the discussion here, it sounds like Chrome is going to start forcing .dev
domains to HTTPS via preloaded HSTS (Google owns the .dev
TLD).
There's also a proposal to add the .localhost
domain as a new standard, so it sounds like using .localhost
for test sites is the best option at this time.
Copying in @leewillis77's comment from Laravel's valet
, which has the same problem: https://github.com/laravel/valet/pull/436#issuecomment-330578317
Just for reference
.localhost
is defined to have some non-standard behaviour. Of relevance, it's defined to always resolve to the local loopback address, so using it precludes you from mapping anything under the TLD to an address other than 127.0.0.1. The TLD also specifies (same RFC) that any DNS request other than an address query should fail which again may cause issues somewhere (think querying for TXT, or MX records etc.)
.test
would seem more flexible as it's defined to act "normally".
I've created PR's for the dashboard and the default stable WP install. I've also added warnings on the new dashboard for sites that have .dev TLD's so that people are aware:
New installs will get the .test
domains, and existing installs will accept them but WP internally will have .dev
in its DB, I'm evaluating options as to wether a search replace will work, or if it's as simple as just changing the site URL. I don't want to break everybodies local environments doing the change
We use a WP site URL migration script. Would that be useful here to migrate an install to a new TLD?
@rmurillo21 a WP CLI search replace should be enough, it's more the risk involved that's concerning
Could we add some documentation what is required to migrate to .test
? Even just adding a comment that one needs to do a search and replace on the DB would help.
As @cgrymala mentioned, I also don't recommend .local
domain for default. In some networks like a big enterprise's intranet, you may be redirect to unknown IIS server. It requires hard googling.
@grappler I think the process is still being tested, to determine best route.
I did a quick search for local.wordpress.dev
in project folders, and a global search/replace to local.wordpress.test
looks pretty straight forward, with no unintended replacements.
For the DB, others have suggested a DB level search/replace: wp search-replace 'local.wordpress.dev' 'local.wordpress.test'
Follow that by a vagrant reload --provision
This should work but I have not yet tested. YMMV - Just wanted to outline a possible process.
For my custom sites, I have moved to the .test
TLD. All good.
NOTE: The codex also suggests these two options for changing site url:
wp option update home 'http://example.com'
wp option update siteurl 'http://example.com'
.test
is the way forward, and the PR's so far stick to that, dashboard works well on .test
here, and .local
and .localhost
were also added for good measure, but all references to the dashboard use .test
as the preferred TLD
@grappler I'd have implemented automated migration but I was hoping other people would advise on the best approach to migrating, be it:
wp option
( results in a mixture of URLs, has the least risk )This also doesn't solve the issue of people who used the custom site template and chose a .dev
domain.
For now, I see the PR's as mergeable without the automated migration, as those can be implemented via follow up PR's
As for documentation, I'm happy for a PR with a stub to be created, I'd prefer to have https://github.com/Varying-Vagrant-Vagrants/varyingvagrantvagrants.org/pull/23 merged first though to avoid conflicts and make sure no editorial work is needed so it makes sense in the new format
PR's exist for all the relevant repos to set the new default to .test
, once those are approved I'll work on automatic migration PR's for the 2 bundled site provisioners
All the relevant PR's have been merged save for https://github.com/Varying-Vagrant-Vagrants/custom-site-template/pull/6 so brand new installs of VVV should be impervious to this issue
I'm going to vote against adding automated migration to the custom site template repo as it's a lot more generic and the risk is substantially higher, but the 2 defaults could use it. I'll work on follow up PR's later this week
FWIW I just installed on OS X using VirtualBox 5.1.28, Vagrant 2.0.0, and the VVV master (commit SHA 70e9bc4486cf369445c7935407576cd65a90ae1b), and the install is broken - the Vagrant /etc/hosts entry is for "local.wordpress.dev" but all the asset requests go to "local.wordpress.test" which cannot be found. Manually adding the entry for the ".test" domain fixed this.
Let me know if you'd like me to open a separate issue for this (and if this is the correct repository for doing so.)
As Google has applied for control of the .dev TLD, there's the potential for all sorts of weirdness to occur if their application is accepted.
Per RFC 2608, Section 2,
.test
,.example
,.invalid
and.localhost
are the only TLDs guaranteed to never be allocated.