{^_^} has quit [Read error: Connection reset by peer]
{^_^} has joined #nixos-dev
justanotheruser has quit [Ping timeout: 258 seconds]
Synthetica has quit [Quit: Connection closed for inactivity]
justanotheruser has joined #nixos-dev
justanotheruser has quit [Read error: Connection reset by peer]
justanotheruser has joined #nixos-dev
justanotheruser has quit [Ping timeout: 258 seconds]
drakonis1 has joined #nixos-dev
justanotheruser has joined #nixos-dev
drakonis has joined #nixos-dev
<gchristensen>
using nixops: I would like to be able to sync some data back *from* the host. For example, host's ssh public key, wireguard public key, other ... things ... like this. This is pretty counter to how nixops works now. any ideas on implementation?
<gchristensen>
I suppose this is very ugly, as it means deploys aren't idempotent, but also it punts on handling this problem
orivej has quit [Ping timeout: 258 seconds]
v0|d has joined #nixos-dev
<clever>
gchristensen: another tricky thing with wireguard, you would want to generate the keys on the remote box, before you build the nixos config (so you know what pub to put into it)
<clever>
gchristensen: so you would need to copy-closure the wg binary to the remote machine, run it to generate keys, then bake those into the physical.nix, build, and deploy
<Shados>
Sounds like a use-case for a wrapper script around your deploy process, probably
<clever>
Shados: there is no trivial way to make nixops copy-closure something to a remote target, from the commandline
<clever>
you would need to ssh into each box, and `nix run nixpkgs.wireguard --run ...`
<Shados>
clever: I was thinking along the lines of using Nix to get the machine info out of the existing expressions into a parseable form (JSON I guess) and leverage that in a script to pre-generate missing keys, but I hadn't considered nixops' weirdness around ssh and key management, so actually I don't know how viable that would be.
<clever>
Shados: such a script would be generating keys on the nixops box, and then it knows all the secrets
<clever>
it would be more secure, if you did the gen-generation on the remote target, and pull the public out
<clever>
which nixops does for ssh host keys
<clever>
but, its easy to assume the remote box has ssh-keygen, because how else did you just ssh into it?
* clever
heads off to bed
<Shados>
clever: No, I was thinking the script would ssh into the target systems to do the keygen
<clever>
ah, but to generate the keys, the target needs wireguard in PATH
<clever>
and the script has to be able to run, before `nixops deploy --copy-only` (because it hasnt built it yet)
<Shados>
Yes. The idea was to use Nix get the target host information from the existing Nix expressions, and use that to do a direct nix-copy-closure for wireguard, generate the keys remotely, and scp back the public keys.
<Shados>
But FWIR nixops doesn't actually keep the ssh and key info in the Nix expressions, it has its own state stuff, yeah? Hence the problem
<clever>
yeah, nixops keeps the private keys in sqlite
<clever>
and when you `nixops ssh`, it will temporarily put the priv key in /tmp, use it, then delete it
<clever>
so you really need the python code to be playing along, to be able to copy-closure other things
<clever>
at the bare minimum, `nixops copy-closure` to let you copy whatever you want
* clever
heads off to bed
orivej has joined #nixos-dev
gchristensen has quit [Quit: Connection closed for inactivity]
sir_guy_carleton has quit [Quit: WeeChat 2.4]
drakonis has quit [Quit: WeeChat 2.4]
drakonis has joined #nixos-dev
drakonis_ has joined #nixos-dev
drakonis1 has quit [Ping timeout: 248 seconds]
drakonis has quit [Ping timeout: 248 seconds]
pie_ has quit [Ping timeout: 252 seconds]
Synthetica has joined #nixos-dev
pie_ has joined #nixos-dev
orivej has quit [Ping timeout: 245 seconds]
pie_ has quit [Remote host closed the connection]
pie_ has joined #nixos-dev
pie_ has quit [Ping timeout: 258 seconds]
pie_ has joined #nixos-dev
pie_ has quit [Remote host closed the connection]
pie_ has joined #nixos-dev
pie___ has joined #nixos-dev
pie_ has quit [Ping timeout: 248 seconds]
pie___ has quit [Remote host closed the connection]
pie___ has joined #nixos-dev
pie_ has joined #nixos-dev
pie___ has quit [Ping timeout: 246 seconds]
gchristensen has joined #nixos-dev
drakonis has joined #nixos-dev
drakonis_ has quit [Ping timeout: 244 seconds]
noonien has joined #nixos-dev
<gchristensen>
I settled on a systemd unit to create a single JSON document describing the system, which I can import as needed locally. the JSON document sets values in the module system with a null-like default. the import is just a little script, ssh-for-each like
orivej has joined #nixos-dev
drakonis_ has joined #nixos-dev
drakonis has quit [Ping timeout: 250 seconds]
<yorick>
nixops keeps some nix expressions in the state file :/
<gchristensen>
yeah the `physical` expression (`nixops show-physical`)
<clever>
more, that it saves metadata about the machine, then uses python code to generate the nix expr at deploy time
justanotheruser has quit [Quit: WeeChat 2.4]
drakonis has joined #nixos-dev
ryantm has joined #nixos-dev
drakonis_ has quit [Ping timeout: 250 seconds]
<clever>
gchristensen: https://github.com/NixOS/hydra/pull/648 any idea whats going on with this PR? i ran into the same problem because it hasnt been merged
<{^_^}>
hydra#648 (by danbst, 7 weeks ago, open): tests: change postgresql socket dir to /tmp
<gchristensen>
seems weird, since hydra definitely builds -- since we can deploy it
<clever>
gchristensen: there is also a nixpkgs pr, to apply this diff to hydra
<niksnut>
what is -k anyway? I get pg_ctl: invalid option -- 'k'
<niksnut>
using /tmp seems risky from a security perspective
<globin>
it was the old default
<globin>
with current 19.03 it works correctly again
<globin>
I think someone said aszlig fixed something wrt default psql socket location