Sender | Message | Time |
---|---|---|
5 Jan 2022 | ||
And from
| 21:51:31 | |
But hey, if it worked back then accidentally and doesn't now because I wasn't doing this correctly, that is 100% on me and I can at least do things right now :D | 21:52:10 | |
So thank you! | 21:52:15 | |
So I'm curious. In my setup my servers all exist inside of my flake outputs.nixosConfigurations, and my outputs.colmena is just a stub that consumes nixosConfigurations and emits a colmena configuration. Is anyone else doing it this way, or just me? I really like the portability of keeping my hosts in nixosConfigurations | 23:27:16 | |
the stub:
| 23:29:18 | |
6 Jan 2022 | ||
05:29:17 | ||
In reply to @buckley310:matrix.orgOh this is exactly what I was just looking for today actually! | 12:55:04 | |
In reply to @buckley310:matrix.orgHmm, I tried implementing this, but I'm not sure where you're getting config.sconfig from? I don't see an sconfig attribute to be fetched from there? | 13:14:17 | |
In reply to @necrophcodr:matrix.orghttps://github.com/buckley310/nixos-config/blob/master/modules/deploy.nix itโs my own module that just adds the deployment settings there. | 15:04:14 | |
Ah okay that makes sense | 15:27:20 | |
So, what would people think about a PR that adds a deployment.targetSshPubKey setting, which when set, would change SSH's "StrictHostKeyChecking" to "yes"? ๐ค also thoughts on the option name? | 22:15:21 | |
i have been deploying stuff with a config file that sets StrictHostKeyChecking=yes , until just now where I realized colmena was overriding my settting with accept-new ๐
https://github.com/zhaofengli/colmena/blob/6401ce4c3c6300b7e2eec059aacd9a1059f28fa5/src/nix/host/ssh.rs#L209 | 22:17:04 | |
or perhaps deployment.targetPublicKeys = [ "ssh-ed25519 AAAAC.....GwLfx" ]; | 22:23:21 | |
Yeah, we should probably have an option like that, or have an option to configure a set of "freeform" SSH configs. | 23:48:53 | |
7 Jan 2022 | ||
Yeah, Iโve basically got a flake devshell that sets up a handful of options including known hosts using $SSH_CONFIG_FILE | 00:02:30 | |
Maybe I can freshen up my rust skills and give it some time | 00:02:53 | |
In reply to @zhaofeng:zhaofeng.liThat would be pretty cool indeed | 21:16:20 | |
8 Jan 2022 | ||
one possible way to pull off custom SSH options is for eval.nix to basically ocmpile an SSH config file, and pass it up to colmena. one side benefit to this would be that the username and port configurations wouldn't even need to touch the rust code at that point, they could just be yet more options in the config file. one downside of that solution though is that, as far as i know, SSH can only handle one config file, so that would kill the usefullness of $SSH_CONFIG_FILE . although there's an argument to be made at that point whether that variable is needed, if the builtin ssh config stuff is complete enough | 02:28:01 | |
* one possible way to pull off custom SSH options is for eval.nix to basically compile an SSH config file, and pass it up to colmena. one side benefit to this would be that the username and port configurations wouldn't even need to touch the rust code at that point, they could just be yet more options in the config file. one downside of that solution though is that, as far as i know, SSH can only handle one config file, so that would kill the usefullness of $SSH_CONFIG_FILE . although there's an argument to be made at that point whether that variable is needed, if the builtin ssh config stuff is complete enough | 02:28:17 | |
* one possible way to pull off custom SSH options is for eval.nix to basically compile an SSH config file, and pass it up to colmena. one side benefit to this would be that the username and port configurations wouldn't even need to touch the rust code at that point, they could just be yet more options in the config file. one downside of that solution though is that, as far as i know, SSH can only handle one config file, so that would kill $SSH_CONFIG_FILE . although there's an argument to be made at that point whether that variable is needed, if the builtin ssh config stuff is complete enough | 02:28:46 | |
* one possible way to pull off custom SSH options is for eval.nix to basically compile an SSH config file, and pass it up to colmena. one side benefit to this would be that the username and port configurations wouldn't even need to touch the rust code at that point, they could just be yet more options in the config file. one downside of that solution though is that, as far as i know, SSH can only handle one config file, so that would kill $SSH_CONFIG_FILE . although there's an argument to be made whether that variable is needed anymore, if the builtin ssh config stuff is complete enough | 02:29:06 | |
thought experiment, what if basically all of the connection settings got merged into SSH options. get rid of
which would then compile this following ssh config file for colmena to just blindly pass to
| 02:37:43 | |
the old settings could link to the new settings with like aliases or something, and then presto, it simplifies the code, and unlocks every setting available in SSH ๐ค | 02:38:52 | |
Good idea! We can add aliases, and the whole config will be generated as a string by eval.nix | 02:45:12 | |
[zhaofengli/colmena] Repo forked into buckley310/colmena | 16:36:39 | |
9 Jan 2022 | ||
18:49:53 | ||
Hey there, is there currently an option to pass --max-jobs 0 to the nix build command or to achive something similar (e.g. don't build anything on the machine running colmena, only on the remote builders)? | 18:52:40 | |
No, there isn't one at the moment, and a --max-jobs parameter that gets passed to all Nix commands doesn't fit well with Colmena's own job abstraction (it launches one nix-build for each node). | 18:59:26 | |
Though if you don't rely on the "distributed" part of the native distributed build feature in Nix, there is a way for Colmena to initiate builds on the target nodes themselves (deployment.buildOnTarget, only available on the unstable branch at the moment) | 19:01:42 | |
13 Jan 2022 | ||
23:03:14 |