7

I've read How to configure user specific hosts file on Windows, it has no answers and is from 2012 so the chance that anyone revives it is pretty much zero.

Here's my use case: we have a nodejs tool suite that lets users generate content that is saved to their own subdomain on the production system. Say it's deployed on example.org, and you're registered with username xyz then the content you generate ends up on xyz.examplecontent.org (different domain because of obvious security issues).

The problem is that this also needs to be tested locally by devs, including the system that does username-prefixed domain routing. Since on a clean checkout, there are no prebaked users, each dev would have to set up some users (this part is essential, because it tests the user-creation process), but then also manually edit their hosts file so that there are (As far as the computer knows) user subdomain hosts that will resolve correctly.

It's possible to sort-of-kind-of automate the hosts modifications using libraries like https://npmjs.org/package/hostile or https://npmjs.org/package/mod-hosts (discounting https://npmjs.org/package/local-tld because it's OSX only) but since modifying the hosts file on windows or OSX requires administrative rights, and you're definitely not going to run any app with admin rights, these libraries are cool, but not actually usable.

Are there any Node.js packages that I can't find when searching http://npmjs.org for "hosts" that would solve this issue, or do windows and OSX have ways to set up complimentary hosts files so that additional hosts rules can be specified without polluting the master file, and not needing admin rights?

note: Answers of the kind "this automation tool can do that for you and runs on *n*x, OSX and windows, but requires ruby/python/perl/whatever" are also perfectly acceptable of course. As long as it's cross-platform and doesn't require admin rights, that's already better than hand curating.

Mike 'Pomax' Kamermans
  • 49,297
  • 16
  • 112
  • 153
  • This doesn't sound like a situation for the hosts file, but rather DNS. You could set a couple DNS entries for project.dev and *.projectcontent.dev that both point to 127.0.0.1 – terite Sep 20 '13 at 18:36
  • for local work, doesn't that literally involve appending the hosts file? specifically, the ideal solution is one that runs concurrent with the tools, and updates the DNS/hosts when (and only when) a new user is created – Mike 'Pomax' Kamermans Sep 20 '13 at 18:42
  • Modifying the hosts file is not the only way to solve this problem. In this case, where subdomains will have to be dynamic, a wildcard catch-all subdomain that always points to your code would be the better option. – terite Sep 20 '13 at 19:00
  • true, although that'd still require manual hosts editing. Less of it of course, so a good suggestion. – Mike 'Pomax' Kamermans Sep 20 '13 at 19:02
  • I agree that DNS is best. I guess I don't completely understand the situation since I don't see why, given the DNS approach, you would have to edit `hosts`. In any case, and for completeness sake, I want to state another, simpler, approach: by convention, decide that users that dev create are always called `u1` thru `u10`. Have each dev add a single entry to their hosts file (`127.0.0.1 u1.devdomain u2.devdomain ...`) and that's it. That's a one-time modification to the `hosts` file for each dev. – Nitzan Shaked Sep 21 '13 at 06:38
  • And one more thing: if you really want to go all-out, you can have a simple DNS server running on a local unix box, provide some sort of API to it, and have dev scripts invoke that. That way, their window boxes resolve the specific subdomains from the unix box and there is no `hosts` file to change. Though it's admittedly much more work. – Nitzan Shaked Sep 21 '13 at 06:39
  • @NitzanShaked given that we need to verify a large number of username patterns, that's not an option. Usernames from "u1" to "小猿マン" need to work, and always testing against the same usernames is going to be a guaranteed problem. The solution also has to take external contributors into account: people have to be able to just grab our codebase, install it, and then test it without being forced into being user "u1" etc. Testing has to be real testing. Setting up a DNS might work, as long as we can talk to it from Node.js to add/remove rules. – Mike 'Pomax' Kamermans Sep 21 '13 at 15:19
  • So do it. Set up a small bind instance, and have a small "api server" running on it, which will append lines to a zone file and restart bind. Talk to that server from node. – Nitzan Shaked Sep 21 '13 at 16:18
  • sounds good, except for the "small api server" part. googling for things like "nodejs bind server" or "nodejs bind api" pretty much fails thanks to bind being a common verb, too. would you happen to know any places that explain how to write a server that talks to (or calls) bind? – Mike 'Pomax' Kamermans Sep 21 '13 at 18:17

1 Answers1

1

I would perhaps suggest creating a custom DNS server that responds to *.somespecificdomain.ext requests and run it locally.

There are several DNS servers written in Node JS, this is one example: https://github.com/tjfontaine/node-dns

More nodejs DNS servers in this question: Simple DNS Server in Node.JS? (Primary/Authoritative DNS Server) (maybe ndns?)

You could then add this DNS server to the bottom of your local network devices DNS servers. If you use DHCP on your primary network device then perhaps add it to a Virtual Network Adapter or similar on the specific target OS.

Yes you need admin / root permissions to add the DNS server to a network adapter - but that's a one time task.

Community
  • 1
  • 1
Dean Taylor
  • 40,514
  • 3
  • 31
  • 50