By default /etc/passwd in container build sandboxes have two users
(root,nixbld) mapped to root. This confuses nix especially it behaves
different if it runs as root. setuid/setgid() is not enough because ssh
will break if the current uid does not exist in /etc/passwd.
Along with this we now also only run the setup for setting up the
network bridge and cgroup filesystems once and not per container.
since this code is used as a default in the cli parser, we should not
crash on OSError because we wouldn't be abe to perform basic tasks such
as --help.
pathlib.Path("git+file:///foo").resolve() might resolve to urls like
PosixPath('/home/joerg/work/clan/clan-core/git+file:/foo'). If those
then actually exist, this can have weird behavior. We should in general
avoid changing directories for everything except for subprocess.run.
This is an attempt to reduce cognitive load when trying to understand the host related logic in run_machine_update.
The change should not affect behavior.
Done:
- make it very clear early on, that build_host == target_host if build_host is not set.
- rename some variables to make relations more clear
- remove `deploy_host` variable. unnecessary complexity
- remove `become_root` variable. After simplifying via boolean algebra, this boils down to `build_host == target_host`.
Fix the directory functionality of clan (clan.directory).
The python API interface was not able to distinguish if the directory
was set to anything other than `self.src`.
Breaking every command that relied on the clan directory, for example:
- `clan machines update`
- `clan machines update-hardware-config`
See more in #2906
This is the first step in fixing all those commands.
Individual command support and implementation will be implemented in
follow ups.
This now gives a clearer error than:
```
Traceback (most recent call last):
File "/nix/store/mznnb8il3njp6jxn5i57d0myjdh6cs0i-clan-cli/bin/.clan-wrapped", line 9, in <module>
sys.exit(main())
~~~~^^
File "/nix/store/mznnb8il3njp6jxn5i57d0myjdh6cs0i-clan-cli/lib/python3.13/site-packages/clan_cli/cli.py", line 516, in main
args.func(args)
~~~~~~~~~^^^^^^
File "/nix/store/mznnb8il3njp6jxn5i57d0myjdh6cs0i-clan-cli/lib/python3.13/site-packages/clan_cli/vars/check.py", line 113, in check_command
ok = check_vars(args.machine, args.flake, generator_name=args.generator)
File "/nix/store/mznnb8il3njp6jxn5i57d0myjdh6cs0i-clan-cli/lib/python3.13/site-packages/clan_cli/vars/check.py", line 103, in check_vars
status = vars_status(machine_name, flake, generator_name=generator_name)
File "/nix/store/mznnb8il3njp6jxn5i57d0myjdh6cs0i-clan-cli/lib/python3.13/site-packages/clan_cli/vars/check.py", line 41, in vars_status
generators = Generator.generators_from_flake(machine.name, machine.flake)
File "/nix/store/mznnb8il3njp6jxn5i57d0myjdh6cs0i-clan-cli/lib/python3.13/site-packages/clan_cli/vars/generate.py", line 67, in generators_from_flake
generators_data = flake.select_machine(
^^^^^^^^^^^^^^^^^^^^
AttributeError: 'NoneType' object has no attribute 'select_machine'
```
When not being in a flake.
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`
