<clever>
talqu: so all caching is based on your file size!
<clever>
talqu: nix then forces the lastmod to 1 second after unix epoch
<clever>
talqu: nginx sets the etag based on the filesize and last-mod stamp
<clever>
ZoomZoomZoom: is the bios booting from the right ESP? your using sde1, so there are another 4 drives in the machine...
<clever>
ZoomZoomZoom: sounds like everything should just work
<clever>
ZoomZoomZoom: and also `cat /etc/fstab` ?
<clever>
ZoomZoomZoom: what does `mount` output?
<clever>
ZoomZoomZoom: dont think so
<clever>
ZoomZoomZoom: it will show a clear error when that happens, but it doesnt happen often
<clever>
DigitalKiwi: it will auto-create well-known and configure nginx to share it
<clever>
ZoomZoomZoom: that happens when you remove keys in configuration.nix and switch
<clever>
ZoomZoomZoom: when nixos boots, it will also copy them over to /etc/ssh/
<clever>
DigitalKiwi: that wont make things expire any faster
<clever>
DigitalKiwi: looks like the A record is missing now
<clever>
ZoomZoomZoom: ok, thats odd, its pointing to the latest generation, can you confirm that the ssh pubkeys are all present in /run/current-system/etc/ssh/ ?
<clever>
HangoverGenius: so its identical to doing import ./thing.nix { mkDerivation = pkgs.haskellPackages.mkDerivation; base = pkgs.haskellPackages.base; .... }
<clever>
HangoverGenius: callPackage will lookup any arguments it needs in haskellPackages
<clever>
DigitalKiwi: this implies that either the firewall is blocking it, or the ip is wrong
<clever>
DigitalKiwi: * connect to 206.189.253.184 port 80 failed: Connection timed out
<clever>
ZoomZoomZoom: can you `ls -l /run/ /nix/var/nix/profiles/` and pastebin the output immediately after a reboot?
<clever>
ZoomZoomZoom: that sounds more like you didnt configure /boot properly, so EVERYTHING is being undone at reboot
<clever>
DigitalKiwi: the v4 from the error logs matches what i get, and you previously claimed the dns in the logs is right
<clever>
DigitalKiwi: and they dont have their own firewall thing, right?
<clever>
DigitalKiwi: is there a router in the way?
<clever>
DigitalKiwi: you are also not responding over ipv4
<clever>
DigitalKiwi nginx isnt listening on 443, something weird is going on
<clever>
marek: its a kernel level problem, if the #! is too long, the kernel ignores it entirely, then bash tries to be too smart and thinks its a bash script
<clever>
DigitalKiwi: is that domain pointing to the nixos machine correctly?
<clever>
DigitalKiwi: i think your returning status code 404, when its trying to query the .well-known addr
<clever>
May 26 15:24:50 absurd-nixos in66lxxs1z3my4claslchxw6bgkwhm1v-unit-script-acme-myfriendshate.me-start[30148]: "status": 403
<clever>
May 26 15:24:50 absurd-nixos in66lxxs1z3my4claslchxw6bgkwhm1v-unit-script-acme-myfriendshate.me-start[30148]: "detail": "Invalid response from http://myfriendshate.me/.well-known/acme-challenge/6iJ2SThXX7lFlsfZKOzASrqiD7AIM-Y5Fbl8LxsYBsQ [2604:a880:400:d1::6c3:3001]: \"\u003chtml\u003e\\r\\n\u003chead\u003e\u003ctitle\u003e404 Not Found\u003c/title\u003e\u003c/head\u003e\\r\\n\u003cbody bgcolor=\\\"white\\\"\u003e\\r\\n\u003ccenter\u003e\u003ch1\u0
<clever>
DigitalKiwi: oh, forgot, `-o cat` makes the journal a lot simpler to read
<clever>
yes, thats weird
<clever>
DigitalKiwi: enableSSL conflicts with enableACME (which enables ssl for you)
<clever>
DigitalKiwi: the errors are cut short, you need to `journalctl -f -u X -n 1000`
<clever>
DigitalKiwi: what errors is it giving, and what config did you try?
<clever>
yeah
2019-05-25
<clever>
and then point open_basedir to that
<clever>
it sounds like you want to use pkgs.runCommand to create a single directory, that has all involved files in it
<clever>
yep :)
<clever>
yeah, nix.sandboxPaths are required, to sneak the qemu binary into the sandbox
<clever>
but if you use a pure arm nixpkgs, via `import <nixpkgs> { system = "armv7l-linux"; }` it will be the arm ldd
<clever>
so its running the x86 ld.so against things
<clever>
behind the scenes, ldd just runs ld.so on the target file
<clever>
are you using the arm ldd?
<clever>
somebody else gave it to me, but it looks like i forgot to tie it in
<clever>
das_j: looks like it, heh
<clever>
das_j: *looks*
<clever>
das_j: thats to deal with argv[0] issues
<clever>
so when you use arm ldd, on an arm binary, the dynamic qemu prints its deps out!
<clever>
the problem is that ldd functions by setting env vars, and then ld.so will print the deps, rather then execute a thing
<clever>
it 90% works with a dynamic qemu
<clever>
and line 38 will setup binfmt-misc
<clever>
line 45 will configure nix, so that it believes you can run those things natively
<clever>
line 36 will add qemu binaries to make it all work
<clever>
just add the path of that to your imports list, and then flip on an enable from lines 24-26
<clever>
`nix run -f ~/.nix-defexpr/channels/unstable drawpile` ?
<clever>
what about `nix-instantiate --find-file unstable` ?
<clever>
nix-channel then adds things to that dir
<clever>
yeah, thats how non-root channels get in
<clever>
root's channels are already in your search path
<clever>
just add the channel to root :P
<clever>
compare $NIX_PATH before and after
<clever>
pie_: `bash -l` may also work
<clever>
infinisil: i think `nix run` operates entirely on NIX_PATH, which is why you need nixpkgs.foo, not nixos.foo
<clever>
probably
<clever>
its simpler to just put all channels on root
<clever>
pie_: its not in NIX_PATH if you have no channels at login
<clever>
pie_: oh, and the first time you add a non-root channel, i think you have to relaunch the shell
<clever>
which can be both good and bad
<clever>
that will re-download the whole channel at random times, so you wont always get the same version you had yesterday
<clever>
did you also --update?
<clever>
if you dont want to develop with it, you can likely also use `nix run unstable.drawpile`
<clever>
pie_: nix-instantiate --find-file unstable, to find it
<clever>
pie_: -p only ever uses <nixpkgs> but you can use -I nixpkgs=something to remap it
<clever>
if you have console access...
<clever>
ambro718: if the 64bit stuff is still in grub, you can just reboot and select an older version
<clever>
so it ignores the #! line
<clever>
ambro718: i just manually ran the 32bit perl against the 64bit activation script
<clever>
ambro718: ah, ive solved that before
<clever>
ambro718: why do you want to do that?
<clever>
jlv: also make sure you are on the alsa device, not the pulse device, f6 to select the card
<clever>
i have options like front-mic-boost, and auto-mute-mode
<clever>
jlv: if you scroll thru alsamixer, you may find the preamp option in there
<clever>
jlv: run alsamixer in a terminal and poke about
2019-05-23
<clever>
`nix-collect-garbage --max-freed 1g` will limit how much it deletes, so valid (but un-rooted) things can survive
<clever>
and if one is in the way at the start of a build, its cleaned up first
<clever>
any lingering $out's will be marked as invalid, and nix-collect-garbage will delete them first
<clever>
dminuoso: the above error isnt the installPhase
<clever>
dminuoso: it may be a bug in the nix-env buildenv stuff, its no longer allowed to point to things that dont exist
<clever>
ahh
<clever>
i'm probably mixing it up with something else
<clever>
pie_: you must still have outputHash if you want network
<clever>
pie_: i think __impure is for things like current date/time, so it wont cache
<clever>
dminuoso: when nix-env is ran?
<clever>
(at build time)
<clever>
dminuoso: you can symlink $out/tmp to /tmp, without having access to the real /tmp
<clever>
nh2: callCabal2nix cant get internet access, your just giving it a storepath with everything it needed
<clever>
i just run ssh-agent
2019-05-22
<clever>
,locate wireguard.ko
<clever>
and you also need a way to tell ssh multiple keys you can use
<clever>
so some wont obey that
<clever>
but, every backend handles ssh keys differently (see ec2 above)
<clever>
gchristensen: i think the safest way to do that, is to generate a new keypair, but keep the old pair, and deploy the new nixops config
<clever>
so they forever have root, on everything
<clever>
and you can never revoke those keys (with current nixops)
<clever>
they have a copy of every single ssh private key
<clever>
gchristensen: for example, if somebody is upset over being fired, and has a copy of ~/.nixops/deployments.nixops
<clever>
gchristensen: another thing id like to see, is a way to SAFELY rotate ssh keys
<clever>
so you cant enforce it being 100% declarative!
<clever>
the other problem there, is that if you disable ~/.ssh/authorized_keys, you lock nixops out!
<clever>
but it wont delete the private, so if you undo the rename, it can regain access
<clever>
and then lock itself out
<clever>
also, the ec2 backend remembers the name of the keypair you used, and if you rename it, nixops will notice the name is "wrong" and choose to use no keys!
<clever>
but the ec2 backend relies ENTIRELY on the /root/.ssh/authorized_keys that was made on first-boot
<clever>
the none backend gets into the machine "somehow" (password usually), then generates its own key and lets itself in via the deployed config
<clever>
gchristensen: and ec2 can easily "forget" keys
<clever>
gchristensen: ive noticed the none and ec2 backends handle it very differently
2019-05-21
<clever>
elvishjerricco: refer to the example i linked, it maps 8080 to 80
<clever>
virtualisation.graphics=false switched the console, and the qemu cfg at the same time
<clever>
thats what lets you see ttyS0
<clever>
but if you specify -nographic to qemu, it will remap the stdin/stdout to the serial port for you
<clever>
the serial port is hidden by default
<clever>
elvishjerricco: oh, i know why
<clever>
elvishjerricco: you can also use code like this to simplify the commandline, i just `nix-build test-monitoring-locally.nix -A vm`, and thats it
<clever>
cizra: my desktop has libGL in /run/opengl-drivers
<clever>
cizra: that will depend on if the gpu drivers have it or not
<clever>
pie_: and "prebuild" the wrong one
<clever>
pie_: but if you can predict what root is going to nixos-rebuild to next, you could beat them to it
<clever>
pie_: so you could maliciously provide a trojaned copy of sudo, but you cant make root run it
<clever>
pie_: nearly, you can basically just unpack whatever NAR you want to /nix/store/
<clever>
ondrejsl: so you can either `nix-copy-closure --to root@something` or `sudo nix-copy-closure --from notroot@something`
<clever>
ondrejsl: if the recieving end is a trusted user in nix.conf (root is by default), it wont check signatures
<clever>
ondrejsl: or if you would rather ignore stack.yaml and get help from cache.nixos.org!
<clever>
ondrejsl: so now you should have 2 ways of building it, with either cabal or stack2nix, and need to decide if obeying stack.yaml is worth the build time
<clever>
ondrejsl: so -lc and -lgmp failed
<clever>
ondrejsl: ah, so you forced it to be fully static, and it couldnt find libgmp.a and libc.a
<clever>
ondrejsl: can you pastebin the cabal file?
<clever>
ondrejsl: yeah, thats one reason i avoid stack2nix when possible
<clever>
ondrejsl: i'm thinking you can just ignore stack2nix, and use normal cabal2nix
<clever>
ondrejsl: looks like regular stack2nix, is the haskell source online publicly?
<clever>
ondrejsl: are you doing anything weird like forcing static or cross-compiling?
<clever>
ondrejsl: it cant even find -lc, something is wrong with the entire compiler
<clever>
ondrejsl: why do you need to add things like pthread and gmp?
<clever>
ondrejsl: the extend function takes a single overlay, and returns a new package set, that also has its own .extend
<clever>
> haskellPackages.extend
<clever>
ondrejsl: you can use .extend to add more overlays to things
<clever>
johnw: nix-store -r /nix/store/foo -vvvvv, and then read the logs
<clever>
devalot: -I can work with files and directories
2019-05-19
<clever>
v0id72[m]: possibly
<clever>
v0id72[m]: line 227, its commented out, and the value should be a string, not a call to callPackage
<clever>
v0id72[m]: can you pastebin your configuration.nix?
<clever>
v0id72[m]: what happens when you try that method?
<clever>
v0id72[m]: environment.etc should be the simplest way, that will just create a file in /etc/
<clever>
v0id72[m]: environment.etc."i3status.conf".text = ''config goes here''; i believe
<clever>
ondrejs: and you can still get (single-cabal level) incremental building with nix
<clever>
ondrejs: you can auto-generate the nix code from the stack.yaml file
<clever>
only something you can build with nix-build will be portable to other nix machines
<clever>
ondrejs: that still doesnt put the binary into the nix store, so it has the same problems
<clever>
ondrejs: any binary you build with bare stack will break when copied to another machine, and can even break if you simply run a garbage collection
<clever>
ondrejs: if you are dealing with nix on both ends, then you can just use nix-copy-closure, to copy the binary, and everything it depends on
<clever>
talqu: it may be differences between your .cabl file, and whatever new-repl reads
<clever>
v0id72[m]: its in the nixpkgs docs
<clever>
the error mentions it looking in 4 places
<clever>
Unable to find the configuration file (looked at ~/.i3status.conf, $XDG_CONFIG_HOME/i3status/config, /etc/i3status.conf and $XDG_CONFIG_DIRS/i3status/config)
<clever>
ekleog: does that somehow have any special permissions like quotas?
<clever>
ekleog: i think /var/lib/docker/btrfs/subvolumes/648592fdb43c4df55d71f9592c2d4202d9b83dc027c10d6b5158cda8d0d4aacf is a btrfs subvolume, that it is then using as the rootfs for the docker container
<clever>
ekleog: maybe just search for `mount(` in all logs, only one thing should be doing it
<clever>
ekleog: this process may be inside a docker container, find the chain of ancestors (where clone() returned its pid), and then see if any of them did clone() with weird namespace related flags, or called mount
<clever>
ottidmes: so you could just use deployment.keys directly
<clever>
ottidmes: i have plans to add the kexec stuff into nixops
<clever>
ottidmes: most of the time, i would just scp them over, or use nixops deployment.keys
<clever>
ottidmes: but i can see how you cant verify the identify of the system you initially ssh into after a kexec, and it could be a malicious vm
<clever>
ottidmes: for ssh private keys, i usually just let the server auto-generate random ones
<clever>
ekleog: you can also do `strace -o logfiles -ff -p <something>` against the pid of the daemon
<clever>
ekleog: perhaps starting with `grep ENOSPC logfile.*`
<clever>
and then analyze the log to see what failed
<clever>
ekleog: all i can think of then is `strace -o logfile -ff docker-compose up`
<clever>
ekleog: what about the btrfs metadata stuff?
<clever>
ekleog: what about `watch -d "df -h ; df -i"` while docker-compose is running
<clever>
ekleog: what does `df -i` report?
<clever>
marek: this will show the differences between the current system, and the current configuration.nix