| 30 Apr 2023 |
 hexa | haha, ok. so | 19:23:33 |
 @obsidianical:matrix.org | (not with colmena specifically that i know of, but i've seen that quite often with other tools and i'd say it's worth a try generally) | 19:23:36 |
| hexa | extraConfig is just php, so you can fopen things | 19:23:42 |
| hexa | or file_get_contents, as you tried | 19:23:53 |
| @obsidianical:matrix.org | i know, as you can see with me trying that hack | 19:23:52 |
| @obsidianical:matrix.org | which doesn't work | 19:24:00 |
| @obsidianical:matrix.org | pasting in the raw key string works, but i intend to make the repo public | 19:24:15 |
| hexa | you could add an EnvironmentFile to the systemd unit and read from the environment | 19:24:23 |
| hexa | and use getenv() instead | 19:24:46 |
| hexa | or use LoadCredential on the unit, and read from $CREDENTIALS_ROOT | 19:25:23 |
| @obsidianical:matrix.org | gonna try the environment var thing | 19:30:06 |
 emily | In reply to @obsidianical:matrix.org
clipboard.png has the service user permissions to access /var/mediawiki?
seems like an usual path -- I would expect something like /var/lib/mediawiki instead.
but I am not familiar with whatever service that is.
plus, I am on mobile rn
but with extraConfigs just being php, you should be able to debug it fairly decently
(just my two cents) | 19:38:22 |
| @obsidianical:matrix.org | if it didn't it'd throw a permission error (which it did before, now there's no error at all and it still doesn't seem to work) | 19:39:21 |
| @obsidianical:matrix.org | I figured it out why it doesn't work with files... for some reason there's a newline at the end by default | 20:41:25 |
| hexa | https://www.php.net/manual/de/function.trim.php 🤘 | 20:44:16 |
| @obsidianical:matrix.org | I barely know php, and i didn't expect the newline at the end | 20:45:41 |
| 1 May 2023 |
 @yuka:yuka.dev | In reply to @obsidianical:matrix.org
hello, i'm trying to deploy a system on a hetzner ARM vps. it worked well so far, until I tried to use arion for a docker compose app.
these are the resulting logs: https://s10e.de/p/bkjN5a The reason for this error is an import-from-derivation | 06:33:32 |
| @yuka:yuka.dev | I have recently tried nix build [...] --store ssh-ng://remote-host again, and found out that when specifying --eval-store ssh-ng://localhost in addition, it works really nicely | 08:31:26 |
| @yuka:yuka.dev | I would love to see the build-on-target mode uset hat | 08:31:44 |
| @yuka:yuka.dev | * I would love to see the build-on-target mode use that | 08:31:46 |
| @yuka:yuka.dev | this also allows fun things like nix build .#nixosConfigurations.host.config.system.build.toplevel --eval-store ssh-ng://localhost --store ssh-ng://remote-host?remote-store=/mnt when the remote host is booted into a live iso for installation | 08:32:46 |
| @yuka:yuka.dev | * this also allows fun things like
$ ssh remote-host "sudo mkdir -p /mnt/nix; sudo chown -R nixos /mnt/nix"
$ system=$(nix build .#nixosConfigurations.host.config.system.build.toplevel --eval-store ssh-ng://localhost --store ssh-ng://nixos@remote-host?remote-store=/mnt --print-out-paths)
$ ssh remote-host "sudo chown -R root:root /mnt/nix; sudo nixos-install --no-root-passwd --root /mnt --system $system"
when the remote host is booted into a live iso for installation
| 08:34:49 |
| @yuka:yuka.dev | * this also allows fun things like
$ ssh nixos@remote-host "sudo mkdir -p /mnt/nix; sudo chown -R nixos /mnt/nix"
$ system=$(nix build .#nixosConfigurations.host.config.system.build.toplevel --eval-store ssh-ng://localhost --store ssh-ng://nixos@remote-host?remote-store=/mnt --print-out-paths)
$ ssh nixos@remote-host "sudo chown -R root:root /mnt/nix; sudo nixos-install --no-root-passwd --root /mnt --system $system"
when the remote host is booted into a live iso for installation
| 08:35:09 |
| hexa | In reply to @yuka:yuka.dev
The reason for this error is an import-from-derivation huh? how so? I see
stderr) error: a 'aarch64-linux' with features {} is required to build '/nix/store/21pl4g80gyk0jn77fy5pg4pr3vixj0vj-cabal2nix-arion-compose.drv', but I am a 'x86_64-linux' with features {benchmark, big-parallel, kvm, nixos-test}
| 09:40:02 |
| hexa | does ifd not respect configured builders? | 09:40:27 |
| @yuka:yuka.dev | from what I understood, no remote builders are configured on the system where colmena is run | 09:42:06 |
| @yuka:yuka.dev | --build-on-target does not work by passing the target host as builder to nix | 09:42:22 |
| @yuka:yuka.dev | * --build-on-target does pass the target host as builder to nix | 09:42:30 |
| @yuka:yuka.dev | it just runs a nix-instantiate locally, then nix-copy-closure the .drv to the remote host, and then nix-store --realise on the remote host | 09:43:16 |
| @yuka:yuka.dev | usually this works fine when the local host has a different arch because nix-instantiate only does evaluation and no builds.
however, when some expression does an import-from-derivation it will suddenly also have to run builds during the nix-instantiate phase on the local host. and since the nixos system is being evaluated as system = aarch64-linux, those derivations are also using aarch64 binaries | 09:44:44 |
