| 23 Oct 2021 |
 David Arnold (blaggacao) | ~/Workspace/devos is good. Or just ~/devos. | 22:18:46 |
| David Arnold (blaggacao) | I organize my local checkputs like so:
~/src/github.com/blaggacao/...
| 22:19:11 |
| David Arnold (blaggacao) | I use ghq for that, but since recently there is a tool called gst (ghost) in nixpkgs that does the same but a little better still (havn't had the chance to switch, yet). | 22:20:06 |
| David Arnold (blaggacao) | How does the devos repo know to which host to deploy to, you might ask. | 22:20:48 |
| David Arnold (blaggacao) | deploy-rs does it via the IP of that host. | 22:21:05 |
| David Arnold (blaggacao) | (& ssh) | 22:21:16 |
 genadij.udarov | Makes sense. My main confusion was how to run nixos-rebuild switch from any dir (which was mentioned in the docs I've linked) | 22:21:51 |
| David Arnold (blaggacao) | Oh, you'd be able to run bud ... (ask bud --help). | 22:23:10 |
| David Arnold (blaggacao) | (within the devshell of that repo) | 22:23:20 |
| David Arnold (blaggacao) | Currently those are "smart" wrappers. Unfortunately, they are not yet ported to deploy-rs to have the benefit of a unified and easy to maintain /explain codepath. | 22:24:08 |
| genadij.udarov | Yeah, I'm able to run that.
Is the statement It is convenient to have the template living at /etc/nixos so you can simply sudo nixos-rebuild switch from anywhere on the system, but it is not required. outdated? | 22:24:31 |
| David Arnold (blaggacao) | Yes! Definitly! Please do your first PR 😆 | 22:25:07 |
| genadij.udarov | Removing that line would be enough, right? | 22:25:42 |
| David Arnold (blaggacao) | Yep, I'd say so. | 22:26:06 |
| genadij.udarov | Here's a PR: https://github.com/divnix/devos/pull/393
I hope to extend the docs and/or code once I'll get familiar with the system. One thing in particular, which was PITA, was that running bud with wrong args doesn't print any error. | 22:40:23 |
| 24 Oct 2021 |
 @teutat3s:pub.solar | I think I've come across the nixos-option garbage collector bug (that should be fixed in devos but we didn't downstream the fix up until now) | 00:15:05 |
| @teutat3s:pub.solar | https://github.com/divnix/devos/issues/138 | 00:15:20 |
| @teutat3s:pub.solar | ❯ nixos-option -I nixpkgs=/nix/store/37gmnpdbgcfhfd577ijm1b0yxaxp2pwk-source/lib/compat boot.loader
terminate called after throwing an instance of 'nix::EvalError'
what(): cannot import '/nix/store/bc0cqsq1fklw4k61y5v3xinalshrfz8k-6mfkswqi67m35qwv0vh7kpk8rypbl2rq-source/flake.nix', since path '/nix/store/bc0cqsq1fklw4k61y5v3xinalshrfz8k-6mfkswqi67m35qwv0vh7kpk8rypbl2rq-source' is not valid, at /nix/store/0n6nqnb6b6cs3hjqprq9k10a1nc2rgiy-source/default.nix:134:19
zsh: abort (core dumped) nixos-option -I -I boot.loader
| 00:15:27 |
| @teutat3s:pub.solar | how do I convince it to re-evaluate and put a new hashed entry of the missing file into the store? | 00:16:14 |
| @teutat3s:pub.solar | this is a fix I've now applied, too. it still tries to access the old gc'ed path though
https://github.com/divnix/devos/commit/8a590c9fefa893dd738bc3161052ac9ea5c72c80 | 00:17:48 |
 ultranix | for devops what's the workflow for public repositories, say on github. do you make a bot that rebuilds nixos machines with the proper keys using agenix, when a commit is added? | 05:22:59 |
| ultranix | i was thinking of doing that but never have before, so far i have only built the machines locally and deployed | 05:23:24 |
 b12f | basic PR, only removing git-crypt for now https://github.com/divnix/devos/pull/395 | 17:38:51 |
 @kraftnix:matrix.org | In reply to @teutat3s:pub.solar
Did anybody already try using agenix for grub / initrd keyfiles? Upon rebuild switch the step updating GRUB 2 menu comes before agenix decryption step and thus fails because the secret is not yet copied in clear text to /run/secrets yes, i have been managing initrd ssh keys with devos/agenix for a few months now without issue.
it does have a few pain points but you can work around them for now without any upstream changes.
you can currently point agenix to decrypt secrets to a location other than /run/secrets, if you set it to somewhere in /etc, then you can access those secrets during a rebuild, which means rebuild can use those agenix secrets for building the bootloader.
however because the bootloader is built before the agenix secrets are decrypted you have an issue where the agenix initrd secrets are always lagging one generation behind the current build, so you need to rebuild/deploy twice to have the bootloader rebuilt with the correct keys, which is not great ergonomics but it works, and since i almost never change the initrd ssh keys, it works fine.
the other small issue is the rebuild will not work unless there are already keys present when you first use agenix for initrd ssh keys, however this can be worked around by either generating fake keys (that will be replaced instantly by agenix on rebuild), just to get you past the first rebuild. | 19:13:49 |
| @kraftnix:matrix.org | admittedly it is a bit of a hack that goes around/against properly reproducible builds/deployments | 19:14:51 |
| 25 Oct 2021 |
|  andrew joined the room. | 00:13:48 |
| genadij.udarov | According to [1], devos should replace nixops? Or is it still possible use them in together? To avoid XY problem: I'm trying to use nix to provision throwaway environments in GCE. I'd like to avoid terraform. My plan here would be to use NixOPS to create GCE resources (VPCs, VMs, whatnot), and then use devos to provision them via deploy-rs. Would this be viable approach? Are there any alternatives?
[1] https://devos.divnix.com/integrations/deploy.html
| 17:24:59 |
| genadij.udarov | * According to [1], devos should replace nixops? Or is it still possible use them in together? To avoid XY problem: I'm trying to use nix to provision throwaway environments in GCE. I'd like to avoid terraform. My plan here would be to use NixOPS to create GCE resources (VPCs, VMs, whatnot), and then use devos to provision them via deploy-rs. Would this be viable approach? Are there any alternatives?
Edit: I'd like to point out that I'm a newbie when it comes to nix stuff.
[1] https://devos.divnix.com/integrations/deploy.html
| 17:25:34 |
| David Arnold (blaggacao) | genadij.udarov From my standpoint I'd try to use terraform. You can write tf files in json, instead of hcl (hcl is a superset of json). | 17:28:21 |
| David Arnold (blaggacao) | You can write json in nix. | 17:28:35 |
