Repository navigation
Managing local dns (/etc/hosts) & development certificates #27
Description
https://github.com/guumaster/hostctl is a great tool for manipulating local /etc/hosts for development.
But it also defies the very principles of isolated devshell environments.
The way it usually works is:
- a
.etchostsfile checked into version control - this is then loaded with
sudo $(which hostctl) add $profilename --from .etchosts - and removed with
sudo $(which hostctl) remove $profilename
It also can be activated and deactivated, once loaded, with:
... enable... disable
But those latter commands seem more useful for interactive usage for special requirements or temporary profile switches, and are not relevant to the genuine setup of a devshell.
Though in order to accommodate for this local /etc/hosts management through devshell, I think two things would have to be achieved.
- acquire sudo privileges during setup (well... 😉 I'm already running away)
- provide finalizer hooks
Or take a completely other approach, like: https://github.com/bAndie91/libnss_homehosts (at least for nixos users that might be a hidden goodie, if packaged there)
Or just acknowledge it would be cool, but no thanks! Too complicated. 😄
Activity
06kellyjac commentedon Oct 5, 2020
I don't expect devshell to touch anything outside of the project folder
blaggacao commentedon Oct 5, 2020
@06kellyjac I agree! Which (theoretically) leaves us with orthogonal infrastructure akin to https://github.com/bAndie91/libnss_homehosts
06kellyjac commentedon Oct 5, 2020
libns_homehosts can use files outside of home?
Could this be done already with devshell's bash.extra?
blaggacao commentedon Oct 5, 2020
As is, unfortunately not as first class use case. It probably wasn't built with a hermetic devshell use case in mind, but that should be rather a solvable problem.
I think the most critical part is to reason about a way to promote and distribute a non intrusive, encapsulated way of managing hosts during dev at the OS level.
blaggacao commentedon Oct 7, 2020
I'm +- reaching the conclusion that a tight integration with devshell would be an ideal complement:
which then generates a
.etchostsand ahostctlwrapper (to consume that specific path) — also automatically provides hostctl inPATH.It can also wrap the
mkcertcommand in appropriate ways:mkcert regsitry.mylocaldomain.com idp.mylocaldomain.com localhost 127.0.0.1 ::1In case
[hostnames]is configured, both (wrapped) commands would get added to thedevshell-menucmd.Sounds viable?
blaggacao commentedon Oct 7, 2020
A transcript of mkcert's cli
Of special interest is:
Which makes a project-shared dev CA checked into version control a piece of cake.
[-]Managing /etc/hosts -- devshell finalizers[/-][+]Managing local dns (/etc/hosts) & development certificates[/+]blaggacao commentedon Oct 7, 2020
@zimbatm Since I'm probably in the concrete and immediate need to implement such a development infrastructure on top of devshell right now, I might as well propose a PR. Would you welcome such contribution?
zimbatm commentedon Oct 7, 2020
Here are a few thoughts and observations:
In the context of a company monorepo, all the customers I worked with so far have had several system-level pre-requisites per project. A few examples: specific Nix version, specific Nix configuration like the Nix binary cache, Git LFS, a VPN, some credentials to access the binary cache, and the code repository. Needing specific hostnames also falls in that category.
As a consultant, this is often a problem as I don't want to have to re-configure my machine all of the time. The same desire is also quite present when working on open source projects. It also applies within teams in a company if there are multiple repositories. Adding too many system pre-requisites is bad for third-party participation and creates silos.
In that regard, I think that devshell or a surrounding tool needs to handle system configuration. I have been taking a two-fold approach: 1) move as much as possible into the devshell environment and 2) add a "doctor" script, which verifies but doesn't change the system configuration. The script is executed on direnv activation and reports back if there are detected errors, suggesting how to fix it. System configuration mustn't get changed without at least the user's approval for each change.
Adding a number of "doctor" checks is something that falls within the scope of the devshell. To actually converge system configuration is something that would be best served by another tool like Chef, Puppet, or Ansible.
This is the generic answer. I haven't had the time to think about this particular use-case yet.
blaggacao commentedon Oct 9, 2020
Closing as #28 shows how to implement a custom extension