Submit Hint Search The Forums LinksStatsPollsHeadlinesRSS
14,000 hints and counting!


Click here to return to the 'Automate the download and installation of a hosts file' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
Automate the download and installation of a hosts file
Authored by: fooljay on May 14, '10 09:39:02PM

Actually, it would be much easier if you, as a rule, disallowed any non-joint/non-collaborative modifications of /etc/hosts and instead maintained two separate files that you concatenate any time there’s a change to one or the other.

For example:

  • You maintain your own hosts file in any arbitrary but safe place (where the bigger threat is often Apple and their dreaded Software Update). Let’s say /usr/local/etc/hosts just because it’s so darn fitting.
  • You set up a script to download the MVPS hosts file periodically placing it in an equally safe but fitting place, say, /usr/local/etc/hosts-MVPS
  • Finally, you create a separate, standalone script (even as something as simple as sudo cat /usr/local/etc/hosts{,-MVPS} >| /etc/hosts) which you will use to effortlessly combine the two files and push the new content to /etc/hosts, replacing it in its entirety each time there’s an update to either MVPS’ hosts file or yours.

If you have to edit your hosts file with an regularity, there’s room for a massive amount of automation here which will not only save you time and make the setup above completely invisible but it could also keep you safe from your own oopsies.

For example, you could create a command line utility through which you can very easily view/add/modify/delete host entries without ever firing up an editor. Since shell scripts never get tired of doing boring, routine things, it could handle the whole “concatenate and clobber” process better and more reliably and tirelessly than you can and it could also serve as the conduit for MVPS’ entries into the system.

Or, to take that up a few hundred notches: You could add Git into the mix to act as sort of a hyper-powerful “caching server” with change control management capabilities. Imagine this—you set up a Git repo with three branches—“Master” (the default name), “MVPS” and “Mine”—each containing a single file: /etc/hosts. Of course, the three are very different: The one in the MVPS branch is huge, the one in the “Mine” branch is small and focused and the one in the master branch is a perfect union of the two.

With that in place, when you need to modify the host file, you modify your version checked out from your branch and then commit the changes back into Git. When the cron process downloads the latest version of the MVPS’ file, it would do the exact same, finishing off with a git commit. Both of those separate actions would immediately trigger a post-commit hook script which pulls (i.e. merges) the changes into the Master branch and then immediately performs a git update from the master branch to…./etc/hosts of course. So, your respective changes are merged and published immediately and automatically almost no extra effort on your part and neither list can ever pollute the other because because they live in alternate realities (i.e. git branches).

And, to top it all off, since Git always knows the latest state of the file, it could take a page from Tripwire’s book by “watching” /etc/hosts (and any other file you deem important enough) for unauthorized changes. Any change to a file managed by Git (on its master branch of course) would garner a swift reply including immediate restoration of the “last known good” version of the file and an urgent “WARNING! WILL ROBINSON!” alert notification to you.

Ta da… Version control, vendor change management and intrusion detection, response and notification system all rolled into one…



[ Reply to This | # ]