This is preparational work to reduce the surface are of the different mappings
We want to reduce the following:
/guides/secrets.md -> Guides/getting started/How to use flakes with sops -> with '# Secrets Management'
- Title
- URI
- Filepath
should follow a stricter pattern to make it easy to maintain
Skip persisting the current date after successful install
This is a workaround due to incomplete test setup - installing a clan machine without having a clan
This uses the networking module to find the best_host, as we already do
with ssh and install. So if we don't supply a --target-host and a
networking module is configured, the remote should be autodetected.
Since vars upload doesn't have a --target-host argument, we always try
to use get_best_remote
- Remove DeployInfo class entirely, replacing with direct Remote usage
- Update parse_qr_json_to_networks to return dict with network and remote
- Refactor all code to work with Remote lists instead of DeployInfo
- Add get_remote_for_machine context manager for network connections
- Update tests to use new Network/Remote structure
This is basically
<af7ce9b8ed>,
but with support for deploying locally.
This failed to install secrets to `/var/lib/sops-nix`. That's because
our `LocalHost` didn't have support for sudo yet. I fixed that.
Now the user can pass `--build-host local`, to select the local machine as a build host, in which case no ssh is used.
This means the admin machine does not necessarily have ssh set up to itself, which was confusing for many users.
Also this makes it easier to re-use a well configured nix remote build setup which is only available on the local machine. Eg if `--build-host local` nix' defaults for remote builds on that machine will be utilized.
Motivation: updating a machine fails, if it depends on a private github repo, as the remote will likely not be authenticated.
This adds a new flag `--fetch-local` to `clan machines update` which fetches all flake inputs prior to building, then uploads them to the build-host.
This also adds a new error message, when flake inputs could not fetched, to hint the user to use `--fetch-local`
- Replace Tor-specific implementation with generic SOCKS5 proxy support
- Change `tor_socks` boolean to `socks_port` and `socks_wrapper` parameters
- Move Tor functionality to clan_lib.network.tor submodule
- Add connection context managers to NetworkTechnologyBase
- Improve network abstraction with proper remote() and connection() methods
- Update all callers to use new SOCKS5 proxy interface
- Fix network ping command to properly handle connection contexts
This allows for more flexible proxy configurations beyond just Tor,
while maintaining backward compatibility for Tor usage.
