v0.84.0 — enable finishes the job
dns enable finishes the job now
Two commands were always meant to be the whole of it: install or upgrade, then moshcode dns enable. Getting a desktop actually working took eleven manual steps, and the largest reason was a component that nothing ever started.
moshpit-proxy ships no unit of its own. Its installer puts the code in place and sets up browser trust, and then nothing runs it. On every machine that installed it, the proxy sat there installed, trusted, and idle — which is indistinguishable from absent from every direction. Nothing on 443, no certificate, and dns enable correctly reporting that it could not find a proxy on a machine that had one.
dns enable now writes and starts that unit before it goes looking, and waits for 443 to actually be held rather than trusting Type=simple's idea of "active" — which reports success the moment a process forks, whatever it goes on to do.
The unit is generated from the running install, like the bridge's. It runs moshpit-proxy's own wrapper with a PATH containing the interpreter executing this code, rather than trusting systemd's: the wrapper execs node, and on a mise, nvm or asdf machine that is a shim under $HOME which systemd has never heard of. That single mistake has now caused three separate failures in this project, so it is made deliberately once, here. The service drops to the operator's account, because the local root lives in their ~/.moshpit and a system unit would otherwise look in /root. And it is granted CAP_NET_BIND_SERVICE rather than run as root — 443 is the one privilege it needs, since DNS carries an address and has nowhere to put a port, so a browser sent to a Moshpit name arrives at 443 or nowhere.
The shape was checked against the hand-written unit on the one machine where this has worked for months. It had independently arrived at the same answers.
None of it is fatal. A machine without a working proxy resolves Moshpit names and cannot verify them, which is bad. A machine whose DNS was refused because an optional component would not start is worse.
dns disable puts the units back too
It stops and removes the proxy service — but only when the restore point says this tool installed it. A unit at that path which enable did not write belongs to somebody else, and stopping it for sharing a filename is exactly the guessing the restore point exists to prevent.
captureRestorePoint records both units the same way it records everything else: the file's prior content, or null for "there was nothing here". null is the load-bearing value in that sentence. It is what removes a unit this run created, and equally what preserves one that was already on the machine.
The trust anchor needed no work at all
applyTrust has always installed the local root into /usr/local/share/ca-certificates, and applyUntrust has always removed it. That step simply never ran, because every enable on an affected machine died before reaching it.
That is why curl failed with unable to get local issuer certificate while a browser would have been fine: moshpit-trust sets up NSS, which Chrome and Firefox read, and nothing had put the root where curl looks.