2019-06-22

<clever> day|flip: why not use the youtube-dl in nixpkgs?

2019-06-21

<clever> but you can also just set it to the right server
<clever> so if you dont set it at all, it will obey dhcp
<clever> Interstitial: i think the problem is caused by setting nameservers to an empty list
<clever> Interstitial: the wifi and ethernet are not down
<clever> Interstitial: then its only a dns problem, and i believe a ticket is already open for it
<clever> Interstitial: can you ping 8.8.8.8?
<clever> skdfjh: thats the name that winds up in the $out path
<clever> skdfjh: then src = thing;
<clever> skdfjh: and thing2 = fetch-it-from-git-somehow;
<clever> skdfjh: thing = runCommand "name" {} "cp -rv ${thing2}/thing3 $out"
<clever> skdfjh: you must use runCommand to mutate the path before it goes into src
<clever> skdfjh: i see the problem, src goes to one derivation, postUnpack goes to another, so you cant use postUnpack, and you cant even use unpackPhase
<clever> stepcut: sounds like thats all right
<clever> skdfjh: it will use your ssh agent to auth
<clever> skdfjh: that would just make the code cleaner
<clever> skdfjh: private git repo? you want builtins.fetchGit
<clever> skdfjh: can you pastebin your current nix file?
<clever> skdfjh: you need to be using the default unpackPhase for it to work
<clever> postUnpack = "sourceRoot+=/socket-io; echo source root reset to $sourceRoot";
<clever> skdfjh: you want to append to sourceRoot in postUnpack
<clever> skdfjh: and also `nix show-derivation` on that same drv
<clever> skdfjh: run `nix-store -r` on the .drv file that is failing to build
<clever> now you dont know the paths until bash time, and the job is still done
<clever> erasmas: then loop over every path in the closure
<clever> for x in $(cat ${pkgs.closureInfo foo}/thing); do
<clever> erasmas: create a derivation, that will use runCommand to do
<clever> erasmas: why do you need it at eval time?
<clever> erasmas: you cant really get that sanely at eval time, without IFD (which is messy)
<clever> erasmas: buildEnv, or writeText
<clever> i work exclusively in old-repl
<clever> ive also not used the new-repl stuff at all
<clever> which wont reload the libraries it depends on
<clever> NemesisD: the quick flash is just it doing :r in ghci i believe
<clever> NemesisD: i think you need to give it files
<clever> NemesisD: `runhaskell Setup.hs repl` is identical to `cabal repl`, but saves you from having to install cabal-install
<clever> then cabal will build the library, and then re-repl the tests
<clever> NemesisD: any time the given path is modified, it will quit and re-run `runhaskell Setup.hs repl`
<clever> --restart=PATH Restart the command when the given file or directory
<clever> contents change (defaults to .ghci and any .cabal file)
<clever> $ ghcid --help
<clever> NemesisD: one min
<clever> NemesisD: i just add the library srcs to the test and remove the dependency on the library, most of the time
<clever> NemesisD: and yeah, that repl wont deal with the library changing under the tests
<clever> NemesisD: ghcid -c "runhaskell Setup.hs repl"
<clever> dsx: ive yet to try home-manager, i just manage home myself
<clever> at_spi2_atk.out 238,496 x /nix/store/0ig02wzzjm4bz16zp99ff3zm5xn097qj-at-spi2-atk-2.22.0/lib/libatk-bridge-2.0.so.0.0.0
<clever> $ nix-locate libatk-bridge-2.0.so
<clever> dsx: you could use activation scripts, or a systemd user unit
<clever> stepcut: and the nix.package option to tell it which nix to use
<clever> stepcut: you want to use nixpkgs.config within configuration.nix
<clever> stepcut: note, that ~/.nixpkgs/config.nix has zero impact on nixos
<clever> crap, lol
<clever> stepcut: is this on nixos?
<clever> stepcut: what are you trying to do with the patch?
<clever> stepcut: nixos is dynamically generating a service file, based on lines 414-432
<clever> stepcut: line 414 is to blame, its ignoring the .service file in nix itself
<clever> oh, buildFHSUserEnv, yeah, that may behave differently
<clever> elux: it does that entirely with env variables
<clever> rprije: import (pkgs.fetchFromGitHub { ...})
<clever> rprije: you dont have to checkout a copy yourself, import from derivation
<clever> rprije: there is no real way to turn a drv back into a nix expr, but you can just use import to load the original nix file

2019-06-20

<clever> zachk: neat
<clever> kisik21: you would need to have a second domain for testing purposes then, that fully works
<clever> kisik21: i just disable acme when testing things on a local machine
<clever> kisik21: one min
<clever> kisik21: there is a seperate option for that
<clever> kisik21: it will be stuck with the self-signed example.com certs until lets encrypt can access it, via the domain it claims to be
<clever> kisik21: when you set enableACME = true; yep
<clever> kisik21: the acme stuff is in a map function, that applies to every virtualhost
<clever> kisik21: what is it doing?
<clever> jbaum98: thats weird
<clever> MichaelRaskin: lol
<clever> jbaum98: identical ssl cert to what i get
<clever> jbaum98: can you pastebin the output of `openssl s_client -connect cache.nixos.org:443` ?
<clever> so the fw is effectively off on that side
<clever> ashkitten: but you can also just allow the wireguard interface to do whatever it wants
<clever> ashkitten: the existing nixos firewall still comes into play
<clever> ashkitten: have you considered a vpn? either toxvpn or wireguard
<clever> hyper_ch: the secondary failure is likely that the irc client doesnt reconnect right
<clever> hyper_ch: the initial failure was on freenode's end
<clever> hyper_ch: the irc server, not client
<clever> qyliss: the server it was on died
<clever> 2019-06-20 13:03:18 -!- Netsplit *.net <-> *.split quits: {^_^}
<clever> so the existing data, turns into random garbage after you decrypt it with the "wrong" key
<clever> aminechikhaoui: and it then tries to decrypt whatever was already on the disk, using that key
<clever> aminechikhaoui: i believe luksformat just sets up the header, with a random encryption key, and your passphrase
<clever> aminechikhaoui: ahh
<clever> aminechikhaoui: there is wipefs to erase known signatures, and you can also just dd /dev/zero into the device to wipe it fully
<clever> PyroLagus: yes
<clever> ashkitten: maybe we should move all this spam to #nixos-chat ?
<clever> but that doesnt have n band speeds
<clever> ashkitten: by using an old g band d-link router, with its dhcp disabled
<clever> ashkitten: the router my isp provides, doesnt allow wifi to ever talk to wired machines
<clever> ashkitten: in my case, its the router thats to blame
<clever> https://nixos.org/nixos/options.html#hostapd i really need to get around to this...
<clever> which reminds me, hostapd
<clever> my laptop is getting 18mbps down
<clever> ar: lol
<clever> ar: only on g band here, so my laptop would be <56mbit
<clever> ashkitten: fiber here
<clever> ashkitten: https://beta.speedtest.net/result/8353169397 is my current speed.....
<clever> it reads from 0-100, it just slams into the end, and reads 500
<clever> ashkitten: the needle on the guage just pegs, lol
<clever> ashkitten: every time i go to speedtest.net, damn
<clever> also, its nixos, and the interfaces file doesnt do anything
<clever> i was one step ahead of them :P
<clever> then they realized, its already got the right ip....
<clever> after they installed it, they asked for the root pw, so they could login and fix /etc/networking/interfaces to match my static ip
<clever> so, i just whipped up a virtualbox disk image, with the fixes done, and sent them the whole disk image!
<clever> when getting errors from them, i got back a screenshot of virtualbox running on windows, lol
<clever> at the same datacenter, i had tried to install nixos in a vm, but the vm and baremetal machines had differing network setup, so bricked the guest
<clever> without telling me anything, they also rebooted every machine in my account, thinking it was connectivity problems and they where doing me a favor :P
<clever> however
<clever> the answer, is that for privacy reasons, they cant tell me what the ip is connected to
<clever> ashkitten: so i asked the via a support ticket
<clever> ashkitten: i had the ip, but couldnt remember if it had been terminated, or was on a 2nd account
<clever> ashkitten: that reminds me, a few years ago at another datacenter, i was looking for an old server
<clever> ashkitten: tell them that its already installed and to shut up, lol
<clever> ashkitten: lol
<clever> adfaure: i would say the 2 terms are interchangable
<clever> xok: https://nixos.org/nix/manual/index.html is the nix manual
<clever> thats the nixos manual
<clever> xok: the nix manual
<clever> xok: the nix manual
<clever> > :p map (v: { key = v; }) [ "a" "b" "c" ]
<clever> > map (v: { key = v; }) [ "a" "b" "c" ]
<clever> xok: a map function probably
<clever> xok: a map function probably
<clever> > let key = "foo"; set.foo = 42; in set.${key}
<clever> > let key = "foo"; in { ${key} = 42; }
<clever> and with keys
<clever> mpickering: ive been using buildkite lately and it works great
<clever> mpickering: and i discovered this, because the container and vm are different versions of ubuntu, and that broke nixops
<clever> mpickering: it will silently enable sudo support if it thinks your trying to use it
<clever> mpickering: this is different from the sudo flag, this is just a string search of sudo in your script!
<clever> Okinan: nope, it checks the hash after unpacking everything
<clever> Okinan: what if git has an exploit?
<clever> Okinan: your cloning the entire git repo, and then getting the dir at a given rev
<clever> Okinan: pkgs.fetchgit had the exact same problem
<clever> mpickering: that can even happen if you put sudo anywhere in your script, and dont change any flags
<clever> mpickering: and full VM's perform worse
<clever> mpickering: i believe travis will automatically switch from containers to full VM's based on certain flags you set
<clever> Okinan: the only way to prevent that, is to convince github to make the zip's deterministic
<clever> simpson: yeah, i would also just fix unzip, rather then break fetchFromGithub globally
<clever> simpson: and i already have working examples of getting a reverse shell from a fixed-output derivation
<clever> simpson: i'm saying, if an exploit against unzip is inserted into the stream, you can exploit the nix builder, before the hash is validated
<clever> and the server saves cpu cycles
<clever> nginx can also be configured to serve pre-gz'd content, and they claim its gzip'd, so the client decodes
<clever> the Content-Encoding: header
<clever> simpson: http itself supports gzip encoding, so i could gz bomb you over a simple index.html
<clever> and the problem remains, if the unpacked gets exploited
<clever> simpson: so we must hash after unpacking
<clever> simpson: github can produce both, but i dont think it does it deterministicly
<clever> Okinan: the hash is over the result of unpacking, so you cant verify the hash until after you unpack
<clever> MichaelRaskin: line 18 results in it ignoring all ssl errors
<clever> MichaelRaskin: *looks*
<clever> simpson: i think its more that we dont care about hiding what we download and ensuring the server is authentic, because we validate the result directly
<clever> simpson: so if you are in the right place on the network, you can mitm fetchFromGitHub
<clever> simpson: nix disables CA checking when fetching, because it assumes the hash of the output is enough
<clever> Okinan: that same argument applies to curl itself and the entire ssl/tls layer
<clever> Okinan: and if the hash is wrong, nix wont register the output as valid, so no other nix builds will ever make use of it
<clever> Okinan: but this unpacking happens inside a nix sandbox, so it cant do much else
<clever> Okinan: one problem i can see, is that you must unpack the zip, to check the hash, so you dont know if the hash is valid or not until after its unpacked
<clever> ashkitten: getting late here, send the pastebin in a PM and i can look over it in ~9-10 hours
<clever> ashkitten: just make sure to umount it before you kexec
<clever> ashkitten: /boot is ext4, and the rescue system should support that
<clever> ashkitten: if you pastebin configuration.nix and hardware-configuration.nix, i can also take a glance
<clever> then adjust configuration.nix and nixos-install again
<clever> ashkitten: if you did an install, but it fails to boot, you can just go back into kexec, and mount the FS's back at /mnt/
<clever> ashkitten: and further nixos-install's will be faster, since it should be incremental, based on what you changed
<clever> ashkitten: you can save time by mounting the existing fs, once your back in the kexec image
<clever> but i dont think its following the dep tree, but rather, just doing every single thing under pkgs
<clever> samueldr: its using nix-instantiate --json to dump the entire expr tree
<clever> samueldr: that, plus the perl script it names, will find the url of nearly every fetchurl call, and then upload copies to tarballs.nixos.org
<clever> Church-: the web app
<clever> Shados: i think slack keeps the scrollback history loaded, ive noticed in a free slack, that my desktop can see back going weeks, but my laptop cant even seen a single msg, due to the free msg cut-off
<clever> and the most active slack, isnt even visible in the first page of the memory usage
<clever> the weirdest part, is that the 2 slacks i use the least, where using the most ram
<clever> 46gig of swap now in use!
<clever> and simply hitting refresh makes it drop off so much i cant find it now
<clever> chrome also says that its using 2gig of JS memory!
<clever> the pid managing a single instance of slack, is only using 156mb of ram, and 2gig of swap, but chrome claims its using 2.2gig of "memory"
<clever> ashkitten: aha, the "memory footprint" according to chrome's task manager, is not the RSS usage!
<clever> ashkitten: i have 64gig of swap on my desktop, and am currently using 49gig of it.....
<clever> but ive not tested it much, and that relies on you already having systemd on the host
<clever> adamantium: i believe you can also `systemctl kexec` to do a clean shutdown, and then execute at the end
<clever> adamantium: ah, i mostly just use `kexec -e`, which triggers an improper shutdown of the current os
<clever> adamantium: i mostly use kexec on systems that are about to be wiped, and then use zfs within the kexec image, as i format the disk
<clever> Shados: `Consider setting dnodesize to auto if the dataset uses the xattr=sa property setting and the workload makes heavy use of extended attributes.`
<clever> i always have a `sudo -i` open, and switch to that tab in screen if i get any permission errors
<clever> Shados: the only xattr i believe i'm using is /var/empty
<clever> adamantium: ah, i just assumed that was due to not setting systemd to let users own their own log files
<clever> Shados: i dont really use acl's though
<clever> Shados: oh, xattr=sa looks nice
<clever> ashkitten: ashift is about the only one i ever set
<clever> ashkitten: main one is to find the block or io size for your disk, fdisk -l /dev/sda should show it
<clever> adamantium: not sure, you would need to figure out how to add a custom kernel+initrd pair to the boot menu
<clever> ashkitten: and `man zpool`, look for the mirror option under create
<clever> ashkitten: there is also https://nixos.wiki/wiki/NixOS_on_ZFS
<clever> ashkitten: youll mostly want to read the generated justdoit script, and use it as a guide on how to install nixos with zfs
<clever> ashkitten: the entire rootfs is a single file inside the initrd
<clever> ashkitten: ah, this works even without loop-mount
<clever> would your tar fit into a 500mb /boot/ ?
<clever> so its just as fat
<clever> ashkitten: it uses the exact same type of kernel+initrd your booting with kexec
<clever> ashkitten: this puts the entire nixos installer in /boot/ and adds a grub entry for it
<clever> but you may want more swap, and/or boot
<clever> so the amount of non-zfs stuff, totals to the same, and the zfs partitions are of equal size
<clever> ashkitten: and then 2gig of swap on the other disk
<clever> ashkitten: what i typically do, is something like 1.5gig of swap + 500mb of /boot, on one disk
<clever> ashkitten: you only need a ext4 /boot/ partition
<clever> but it doesnt setup mirror or raidz, which i think you wanted
<clever> ashkitten: it adds an array of nixos options, which you could set in the configuration.nix before making the tar
<clever> ashkitten: thats exactly what justdoit does, but its likely not configured for your disk layout
<clever> ashkitten: you may also want to read `cat /run/current-system/sw/bin/justdoit`
<clever> ashkitten: i do zfs on all of my machines
<clever> ashkitten: but even if you do forget, its using a delayed shutdown, which alerts to every console, and you can `shutdown -c` to cancel it, 5 minute warning period
<clever> ashkitten: which reminds me, once you do get in, systemctl stop autoreboot.timer
<clever> ashkitten: so even if you lacked the console controls from OVH, you can still recover!
<clever> ashkitten: it will reboot itself every hour, 5 minutes after the hour starts
<clever> ashkitten: also
<clever> ashkitten: adding it to configuration.nix just saves a step if you want to use the image many times
<clever> ashkitten: and it will copy that to /root/.ssh/authorized_keys as it boots
<clever> ashkitten: you can also put an ssh public key in /ssh_pubkey before you run kexec_nixos
<clever> ashkitten: oh right
<clever> yeah
<clever> ashkitten: only the tar itself has to be copied, it contains everything it needs
<clever> ashkitten: keeping the server out of america
<clever> ashkitten: what about keeping it out of trumps reach? lol
<clever> ashkitten: ive got a soyoustart machine, but ive yet to migrate it to nixos
<clever> ashkitten: and it will then try the next device in your boot order
<clever> ashkitten: i recently discovered, that you can `exit` when at the grub command prompt, and the bios will treat that as the drive being non-bootable
<clever> ashkitten: it may be scanning the drive to see if its bootable
<clever> ashkitten: after you clone my repo
<clever> ashkitten: just run the exact nix-build command it shows, in the kexec directory, with the configuration.nix that is in that dir
<clever> ashkitten: you need to use the configuration.nix in the kexec dir, when making the tarball
<clever> ashkitten: ah, you only generate one after booting into the kexec image
<clever> aoeu: ive never seen a cross-compiler that can target darwin
<clever> ashkitten: did you include the correct configuration.nix in the -I flag?
<clever> aoeu: but you need another mac to build it
<clever> aoeu: this is an old hack i did to see how hard it could be, and it might work for you
<clever> aoeu: as are most of the good solutions i was going to mention, lol
<clever> aoeu: nix-user-chroot is linux only
<clever> aoeu: are you on linux or mac?
<clever> ivan: and just being able to skip creating a tar
<clever> ivan: the main benefit over your tar idea, is that it can deal with a nix store already existing there, and do an incremental copy, and merge things in, if that happens to be needed
<clever> ivan: basically, once you have nix installed in the rescue environment, you can use this to copy to /mnt/nix/store on a remote machine, over ssh
<clever> ashkitten: you can probably just use a normal nixos-generate-config, and make sure to enable ssh
<clever> ivan: oh, i have a trick related to that

2019-06-19

<clever> ashkitten: you can then ssh back in, and treat it like you had booted from a USB stick, and install as-normal
<clever> within ~3 minutes, it will be running full nixos, purely from ram
<clever> ashkitten: nix-build a magic tar, upload it to the rescue console, unpack it to / and run /kexec_nixos
<clever> ashkitten: i would try my kexec stuff from the rescue console
<clever> manveru: and within the narinfo file, is the path that the .nar.xz is at, relative to the narinfo
<clever> manveru: the above path, has the narinfo at https://cache.nixos.org/rq17dz8iaj99nmax47584xkmp1cjwyfg.narinfo
<clever> > "${hello}"
<clever> manveru: use --to to make such a dir, and see what the file layout should be
<clever> manveru: i think you could maybe put both the .nar.xz and the .narinfo into a directory, and then use `nix copy --from file:///path/to/dir /nix/store/path`
<clever> but kill is send to the shell itself i think, so the whole terminal dies
<clever> you have the option to send stop, cont, int hup, term, and kill!
<clever> in xterm, you can hold control, and hold left-mouse, to get a menu
<clever> i just ran `strace sh` and then whacked ctrl+\ to see what happened
<clever> same
<clever> zachk: sends SIGQUIT
<clever> nix-env -iA nixos.htop will just go directly to htop
<clever> `nix-env -i htop` will search every single package to see if the name patches htop
<clever> ,-A zachk
<clever> i visit https://nixos.org/nixos/options.html so often, that just typing `ni` into the address bar auto-completes it
<clever> manveru: you dont need passthru to access the buildInputs
<clever> stepcut: single-user nix runs everything as a child-proc of nix-build, and it will just inherit access to the agent with no trouble
<clever> stepcut: and then tell ssh-agent to use a given path, rather then making a dynamic one
<clever> stepcut: you probably want systemd.services.nix-daemon.environment.SSH_AUTH_SOCK = "/whatever";
<clever> stepcut: i dont think thats used on nixos machines
<clever> ambro718: yeah, i believ it would leak /tmp/nix-build-name/ if it wasnt sandboxed
<clever> looks more like 71.8 got rounded up to 72
<clever> looks like your username has a rounding error though, lol
<clever> ah, i see your one reply down
<clever> ambro718: did you check free inodes? df -i
<clever> ambro718: it helps to quote the output with ``` in the comment
<clever> and newer nixos wont set it if nix is new enough, causing old nix to break
<clever> older versions lack auto, and will actually fail with permission errors if you dont set NIX_REMOTE
<clever> auto is the default when unset, and that will test write access to figure out daemon vs local
<clever> NIX_REMOTE=daemon forces it to use the daemon