(New to Colmena and just Nix in general).

How do y'all deal with bootstrapping secrets in a Colmena deployment. For example, I have a secret key that I don't want to keep in repo. So every time a developer clones the colmena nix code they would have to get the secret key and create the file on their local machine.

I want to split my colmena deploymeny into 2 parts:

1. Bootstrapping secrets. Should only be done by very few people who have access to the secrets.
2. Any other configuration that can be run by anyone and CI. They should be able to colmena apply without getting secret keys from somewhere else manually.

Does this make sense to do?

In reply to @linus:schreibt.jetzt
lemmalamma: colmena stores the secrets unencrypted on the target hosts, so these "unauthorised" users can still fairly trivially get the secret keys by deploying their own code to the machines.

In reply to @linus:schreibt.jetzt
you also don't need to split it into two, since colmena supports using a command to get secrets -- so you can store them together with your deployment, encrypted (with a tool of your choice) to the authorised users.

In reply to @tiha889a:tu-dresden.de
you can also check out agenix, it is basically sops-nix but with age and I am happily using it, not with colmena yet though.. it is dead simple especially when using the system ssh keys in /etc/ssh/

I'm using the colmena from git (commit 9db25bd) with flakes.

I'm struggling to understand how to define a hive w/ 2 systems where one is using nixpkgs/22.05 while the other is using nixpkgs/unstable as pkgs source.

      meta = {
        nixpkgs = import nixpkgs { system = "x86_64-linux"; };
        nodeNixpkgs = {
          rpi-tv = import nixpkgs-unstable {};
        };
...      
}```

In reply to @janejasperous:one.ems.host

      meta = {
        nixpkgs = import nixpkgs { system = "x86_64-linux"; };
        nodeNixpkgs = {
          rpi-tv = import nixpkgs-unstable {};
        };
...      
}```

Until I change the system in nodeNixpkgs to something different than nixpkgs. Than I get the error

[ERROR]   stderr) error: a 'aarch64-linux' with features {} is required to build '/nix/store/h5ggpshqjbl14pp1qri043d5dk0n2iyc-append-initrd-secrets.drv', but I am a 'x86_64-linux' with features {benchmark, big-parallel, kvm, nixos-test}

In reply to @dantefromhell:matrix.org

Until I change the system in nodeNixpkgs to something different than nixpkgs. Than I get the error

[ERROR]   stderr) error: a 'aarch64-linux' with features {} is required to build '/nix/store/h5ggpshqjbl14pp1qri043d5dk0n2iyc-append-initrd-secrets.drv', but I am a 'x86_64-linux' with features {benchmark, big-parallel, kvm, nixos-test}

In reply to @schnecfk:ruhr-uni-bochum.de
Either use deploy.buildOnTarget, enable qemu binfmt emulation or try and get it running using pkgsCross for true cross compilation

Thx, worked.

For anyone interested, my solution was to add

boot.binfmt.emulatedSystems = [ "aarch64-linux" ];

to configuration.nix on the machine that I run colmena build on

In reply to @dantefromhell:matrix.org

Thx, worked.

For anyone interested, my solution was to add

boot.binfmt.emulatedSystems = [ "aarch64-linux" ];

to configuration.nix on the machine that I run colmena build on

In reply to @huyage:matrix.org
Colmena is working well for me after I had trouble using nixops. I'm just curious: why are there so many nix-based deployment/config management tools? AFAIK nixops is the OG one. (I understand Colmena doesn't provision resource like nixops) Is there some history here?

In reply to @huyage:matrix.org
Colmena is working well for me after I had trouble using nixops. I'm just curious: why are there so many nix-based deployment/config management tools? AFAIK nixops is the OG one. (I understand Colmena doesn't provision resource like nixops) Is there some history here?

To add on the answer by Buckley (Which answers why so many alternatives to NixOps appeared), it's also because it's somewhat easy to build such a tool based on nix.

Being a bit handwavy here, but it generally boils down to some combination of nix-build and nix-copy-closure. I've also seen some messages of people doing these steps with a shell script instead of any deployment tool.
This "foundation" is really clear if you've switched the deployment tool (e.g. from nixops to colmena) - you don't have to change that much to get it working, especially in comparison to switching between puppet, ansible or similar tools (or even the initial nix migration).

The deployment tools nonetheless offer a big plus, the more obvious ones would be secret management and the generally better user experience.

In reply to @janejasperous:one.ems.host
nixops is maybe more in terraform league

In reply to @schnecfk:ruhr-uni-bochum.de

To add on the answer by Buckley (Which answers why so many alternatives to NixOps appeared), it's also because it's somewhat easy to build such a tool based on nix.

Being a bit handwavy here, but it generally boils down to some combination of nix-build and nix-copy-closure. I've also seen some messages of people doing these steps with a shell script instead of any deployment tool.
This "foundation" is really clear if you've switched the deployment tool (e.g. from nixops to colmena) - you don't have to change that much to get it working, especially in comparison to switching between puppet, ansible or similar tools (or even the initial nix migration).

The deployment tools nonetheless offer a big plus, the more obvious ones would be secret management and the generally better user experience.