Colmena | 323 Members | |
| A simple, stateless NixOS deployment tool - https://github.com/zhaofengli/colmena | 110 Servers |
| Sender | Message | Time |
|---|---|---|
| 30 Jul 2022 | ||
| They say the repro here was fixed, and then provide a workaround for here, but I'm not sure what the still broken usecase is. | 06:32:41 | |
| * They say the repro here was fixed, and then provide a workaround for some usecase here, but I'm not sure what the still broken usecase is. | 06:32:54 | |
| ugh element just stripped the formatting, cool | 06:33:05 | |
In reply to @winterqt:nixos.devI think it can be closed. One remaining issue was the merging of nixpkgs.config, which was broken because all of the config keys were untyped prior to 22.11 unstable. Now most of the config keys are typed and can be correctly merged. | 06:34:03 | |
| Ah, neat. I feel like I asked this before but I can't find the logs or any reasoning in the source, but why is impure evaluation used? Is it for the non-flake case or something? (Also, nix-eval-jobs is the default evaluator on master, at least until the chunked evaluator is ported over to the new trait, right?) | 06:38:50 | |
In reply to @winterqt:nixos.devIt's mostly because we have a custom entry point for our evaluation (eval.nix) and it's difficult to use it in pure evaluation mode. I recently did some experiments on that front, which is to make eval.nix and friends a flake so we can use builtins.getFlake with a locked URI to get it in pure evaluation mode. Going forward I think the easiest way is to generate a temporary flake that contains eval.nix with the hive flake as a locked input. | 06:46:22 | |
The chunked evaluator is the default, with nix-eval-jobs behind --evaluator streaming. There are still a few usecases nix-eval-jobs doesn't support, like remote builders during evaluation (needed for FOD with foreign architectures, used in mobile-nixos). | 06:47:52 | |
* The chunked evaluator is the default, with nix-eval-jobs behind --evaluator streaming. There are still a few usecases nix-eval-jobs doesn't support, like remote builders during evaluation (needed for <s>FOD</s>IFD with foreign architectures, used in mobile-nixos). | 06:51:11 | |
In reply to @zhaofeng:zhaofeng.li Oh I missed it since I thought it would pass impure (which is the default for nix-instantiate, so obviously it doesn't), then I saw the comment and thought it was removed or something. For that IFD case, I assume it wouldn't be possible to setup something where we pass remote builders to Nix during eval (if that's possible) if ~~that wording probably doesn't make sense at all 😅~~ | 06:57:19 | |
In reply to @zhaofeng:zhaofeng.li* Oh I missed it since I thought it would pass impure (which is the default for nix-instantiate, so obviously it doesn't), then I saw the comment and thought it was removed temporarily. For that IFD case, I assume it wouldn't be possible to setup something where we pass remote builders to Nix during eval (if that's possible) if buildOnTarget is true, so that's handled transparently? (that would require either being root on the remote host) ~~that wording probably doesn't make sense at all 😅~~ | 06:57:32 | |
In reply to @winterqt:nixos.devnix-instantiate already uses remote builders if configured globally, and we will pass --builders if meta.machinesFile is set. The problem is that nix-eval-jobs forcibly disables it due to an outstanding issue. | 07:01:59 | |
| I'm wondering if we can construct a builders argument with the data from the machines that have buildOnTarget set as well | 07:03:29 | |
| To transparently handle that IFD case | 07:03:38 | |
| Without manual configuration ahead of time | 07:03:44 | |
Yeah, it could work pretty well combined with the recent --eval-store suggestion. | 07:06:10 | |
| The next step is to perform the actual evaluation remotely, but we aren't there yet. | 07:06:55 | |
In reply to @zhaofeng:zhaofeng.liYeah, I did see that. Is that suggesting using the target machine as the store for eval with that flag? I'm pretty sure that's what they're suggesting, but the "local --eval-store" part is throwing me off. | 07:14:49 | |
| Yeah, it's a bit confusing but I think that's what they meant. | 07:15:59 | |
In reply to @zhaofeng:zhaofeng.liOk, just tested, and the colmena apply-local --sudo test goal works as it currently stands. The interactive prompts of sudo don't use stdin/out. | 07:26:53 | |
| Oh, huh, they... don't? | 07:42:55 | |
| Interesting! | 07:43:09 | |
Although, keep in mind that other privilege escalation commands (doas comes to mind) may not give us that luxury. | 07:43:33 | |
| I would assume it's the same, otherwise it won't play well with pipes and be insecure | 07:44:33 | |
| Oh, fair point. | 08:03:05 | |
| What even is there to use other than stdin/stdout in a console, though? ~~This is obviously magic.~~ | 08:03:36 | |
| I'll look into it later, I'm intrigued. | 08:03:44 | |
| Zhaofeng Li: That begs the question: why passthrough the profile switch execution, then? Were you under the assumption that it would be needed for ? | 08:04:30 | |
In reply to @winterqt:nixos.devIIRC it uses /dev/console. There is a flag to make sudo use stdin though | 08:06:51 | |
In reply to @winterqt:nixos.devNo, it was from way before apply-local was changed to escalate privileges during activation. passthrough() is just a simple way to execute commands with both stdin/stdout piped | 08:08:27 | |
In reply to @winterqt:nixos.dev* IIRC it uses /dev/console. There is a flag to make sudo use stdin though (edit: it's -S) | 08:10:23 | |