Managing local dns (/etc/hosts) & development certificates

[blaggacao]

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 .etchosts file 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. 😄

[06kellyjac]

I don't expect devshell to touch anything outside of the project folder

[blaggacao]

@06kellyjac I agree! Which (theoretically) leaves us with orthogonal infrastructure akin to https://github.com/bAndie91/libnss_homehosts

[06kellyjac]

libns_homehosts can use files outside of home?
Could this be done already with devshell's bash.extra?

[blaggacao]

libns_homehosts can use files outside of home?

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]

I'm +- reaching the conclusion that a tight integration with devshell would be an ideal complement:

[hostnames]

regsitry.mylocaldomain.com = "127.0.0.1"
idp.mylocaldomain.com = "127.0.0.1"

which then generates a .etchosts and a hostctl wrapper (to consume that specific path) — also automatically provides hostctl in PATH.

It can also wrap the mkcert command in appropriate ways:

mkcert regsitry.mylocaldomain.com idp.mylocaldomain.com localhost 127.0.0.1 ::1

In case [hostnames] is configured, both (wrapped) commands would get added to the devshell-menu cmd.

Sounds viable?

[blaggacao]

A transcript of mkcert's cli

$ mkcert
Created a new local CA at "/home/blaggacao/.local/share/mkcert" 💥
Warning: the local CA is not installed in the system trust store! ⚠️
Warning: the local CA is not installed in the Firefox and/or Chrome/Chromium trust store! ⚠️
Run "mkcert -install" to avoid verification errors ‼️
Usage of mkcert:

        $ mkcert -install
        Install the local CA in the system trust store.

        $ mkcert example.org
        Generate "example.org.pem" and "example.org-key.pem".

        $ mkcert example.com myapp.dev localhost 127.0.0.1 ::1
        Generate "example.com+4.pem" and "example.com+4-key.pem".

        $ mkcert "*.example.it"
        Generate "_wildcard.example.it.pem" and "_wildcard.example.it-key.pem".

        $ mkcert -uninstall
        Uninstall the local CA (but do not delete it).

For more options, run "mkcert -help".

$ mkcert -install
Using the local CA at "/home/blaggacao/.local/share/mkcert" ✨
Sudo password:
The local CA is now installed in the system trust store! ⚡️
The local CA is now installed in the Firefox and/or Chrome/Chromium trust store (requires browser restart)! 🦊


$ mkcert example.com
Using the local CA at "/home/blaggacao/.local/share/mkcert" ✨

Created a new certificate valid for the following names 📜
 - "example.com"

The certificate is at "./example.com.pem" and the key at "./example.com-key.pem" ✅

$ ll ex*
.rw------- blaggacao blaggacao 1.7 KB Tue Oct  6 20:03:38 2020  example.com-key.pem
.rw-r--r-- blaggacao blaggacao 1.5 KB Tue Oct  6 20:03:38 2020  example.com.pem

Of special interest is:

        $CAROOT (environment variable)
            Set the CA certificate and key storage location. (This allows
            maintaining multiple local CAs in parallel.)

Which makes a project-shared dev CA checked into version control a piece of cake.

[blaggacao]

@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]

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]

Closing as #28 shows how to implement a custom extension