Colmena | 311 Members | |
| A simple, stateless NixOS deployment tool - https://github.com/zhaofengli/colmena | 110 Servers |
| Sender | Message | Time |
|---|---|---|
| 30 Jul 2022 | ||
| 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 | |
In reply to @zhaofeng:zhaofeng.liWhy was it needed for the profile switch, out of curiosity? | 08:12:58 | |
In reply to @winterqt:nixos.devIt was one of the four custom methods that I have to "execute" the command and get back a ColmenaResult. It's just a simple version of Command::status() which needs two layers of checking (the outer Result and the exit code). | 08:22:44 | |
| 19:09:28 | ||
| 4 Aug 2022 | ||
| 04:31:26 | ||
| 6 Aug 2022 | ||
| 22:00:09 | ||
| 7 Aug 2022 | ||
| Is there any way to do a healthcheck with colmena? I see some other deployment tools support this. All I want to do is make sure that if I push a new config that disables SSH access accidentally, this is caught and rolled back. | 15:37:30 | |
In reply to @swissrouting:matrix.orgi'm curious if tests as described here suffice your requirement? https://nixos.mayflower.consulting/blog/2019/07/11/leveraging-nixos-tests-in-your-project/ | 20:49:02 | |
In reply to @dantefromhell:matrix.orgThat seems pretty much what I want, will give it a try. Thanks! | 22:44:16 | |
In reply to @dantefromhell:matrix.orgHow would that help without a mechanism to run the test? (Also, tests are within VMs.) | 23:25:19 | |
In reply to @dantefromhell:matrix.org* How would that help without a mechanism to run the test? (Also, tests are within VMs, and can't access the host.) | 23:25:26 | |
| * How would that help without a mechanism to run the test? (Also, tests are within VMs, and can't access the host. So tests probably aren't the solution here.) | 23:25:37 | |
| 8 Aug 2022 | ||
| You could put a NixOS test in system.extraDependencies (or similar, can't remember if that was the exact name of the option) so that the system won't build if the test doesn't pass, but yeah, it won't get you automatic rollback of changes that break your access | 06:03:18 | |
| There's nothing in colmena that would really support building this though | 06:19:32 | |
| I suppose you could hack something together with post-activation key upload | 06:19:50 | |
| Also keep in mind that you'd have to break ControlPersist on the client somehow, if you do that (delete the socket?) | 06:24:57 | |
| (break = sever the connection, poor choice of wording maybe?) | 06:25:11 | |
| * Also keep in mind that you'd have to break ControlPersist on the client somehow, if you use that (delete the socket?) | 06:25:15 | |
| Can I also run the evaluation of my configuration on a separate host? Currently working around multiple issues where I can't update the configuration of my x86_64 Linux host, because I am running on a M1 Mac. I was able to work around the issue of
by running a Linux (micro-)VM. Unfortunately evaluation still fails because of my architecture:
| 13:09:13 | |
| Zhaofeng Li: I find this resumes well the impetus of a swappable evaluator. We have to introduce the two thought categories of vartical software feameworks and horizontal ones. True congruent configurations (even: hypercongruent) need both interfaces:
| 17:09:10 | |
| * Zhaofeng Li: I find this resumes well the impetus of a swappable evaluator. We have to introduce the two thought categories of _vartical_ software feameworks and _horizontal_ ones. True _congruent configurations_ (even: _hypercongruent_) need both interfaces. I'm copying my agrument from a private discussion: > `styx` has the same problem as `colmena` , `deploy-rs`, et al. > It evolved into a _vertical_ (tool centric) framework that is a bit hard to marry with a _horizontal_ (integration centric) one like `std`. > I understood this abstract pattern with colemna and came up with a solution that involves for such tooling to have a pluggable evaluator interface to accomodate integration-centric evalutors, while still mostly preserving the look & feel (and branding/docs) of the native tooling. | 17:09:50 | |