<clever>
ahh, if your copying it from a->b, then it cant reuse the a between copy-closure runs, and every time b changes, yeah that can be a pain
<clever>
and confirm if its a dependency or not, and via what
<clever>
eacameron: run nix-store --query --tree on the final result
<clever>
eacameron: you can use grep to check for its old path within the file and see if thats causing the issue
<clever>
eacameron: if you copy the files, and they dont contain any internal references, there should be no runtime dependency
<clever>
preferLocalBuild = true; i think
<clever>
grep on nixpkgs should confirm
<clever>
oh that, thats also possible
<clever>
eacamero_: --option binary-caches "" i think
<clever>
endformationage: most places ive seen use $NIX_CC/nix-support/dynamic-linker
<clever>
i would always delete configuration.nix from nixops machines
<clever>
the config must be built by the original master that made it
<clever>
nixops servers shouldnt even have a configuration.nix, as far as im concerned
<clever>
ahh
<clever>
also, you shouldnt be using nixos-rebuild on a nixops target
<clever>
so id say nixops has to have the path fixed
<clever>
you should either be using ~/.ssh/authorized_keys, or the configuration.nix
<clever>
/etc/ssh/authorized_keys.d/root is managed by setup-etc.pl, and should never be touched directly
<clever>
yeah
<clever>
need to store it to a file and -i then
<clever>
ouch
<clever>
which assumes you can either enter a pw, or your ssh agent has a key not in ~/.ssh/id_rsa that can get in
<clever>
ToxicFrog: related, there is ssh-copy-id
<clever>
ive found that kernel compiles are fairly short now, compared to things like chromium
<clever>
the nix functions for haskell
<clever>
and haskell may be messing with the attrset some
<clever>
this is also how src = fetchurl ... winds up in $src during the build
<clever>
deepfire: so env vars outside of nix-build cant leak in, only attributes set on the derivation, which affect its hash
<clever>
deepfire: nix will nuke the environment variables at the start of every build, and initialize it with all attributes inside the derivation its building
<clever>
deepfire: its not an env variable, its an attribute you have to set inside the nix expression
<clever>
justan0theruser: and further down, you want tar -xzvf $src, otherwise the build will fail when the sandbox is enabled
<clever>
justan0theruser: are you just testing it, or do you want to install it?
<clever>
justan0theruser: remove line 1&2, and uncomment line 3
<clever>
deepfire: add NIX_DEBUG=true; to the derivation, and nix-build will tell you a lot more
<clever>
deepfire: there is also a debug variable, one min
<clever>
Unode: currently in NB canada, with no fixed schedule
<clever>
Unode: today, i slept from 11am to 8pm
<clever>
main thing, is that i sleep when you least expect it :P
<clever>
Unode: Fri Jan 20 21:00:58 AST 2017
<clever>
Unode: i happen to be awake now
2017-01-20
<clever>
but it was simple enough to add nix back to it
<clever>
ixxie: it was originaly designed for a different embeded purpose, and didnt even have nix at runtime
<clever>
its heavily stripped down, but has enough to allow nix-daemon to handle remote builds
<clever>
ive also made a custom OS based on nixos, that can run on the rpi3 via network booting
<clever>
justan0theruser: create a derivation that unpacks those files to $out/include and $out/lib
2017-01-18
<clever>
would need to read the grub source then
<clever>
ah, losetup would require root
<clever>
Nadrieril: but then boot.loader.grub.deivce has to be /dev/loop0 or you need to bypass that config flag
<clever>
Nadrieril: simplest thing i can think of is losetup, and tell it to enable partition tables
<clever>
Nadrieril: i believe grub needs access to the block device, so it can inspect the partition tables and write the MBR and stage 1.5, plus it needs access to whatever you decided /boot will reside on, so it can store further stages as proper files
<clever>
gchristensen: i sleep when you least expect it :P
<clever>
i think in this case, its just that nobody has tested that combination, because its not normal
<clever>
endformationage: with nix and nixos, your not supposed to install compiler toolchains, your supposed to use nix-shell
<clever>
gchristensen: im around
2017-01-17
<clever>
gchristensen: one user in wheel, or those properties on root
<clever>
which only leaves sudo, but there is not much choice there enless you want to criple yourself
<clever>
that should cover 99% of the ways the unix password can be used
<clever>
ssh keys, stop su from working, stop ssh from accepting a password
<clever>
so even if they get the pw, it cant do anything
<clever>
i prefer to just disable every way of using a password
<clever>
and if you want to actualy detur somebody that has a shell, you need to change it often enough that they can never finish cracking
<clever>
hashes at least slow the attacker down, complex passwords slow them down more
<clever>
yeah
<clever>
but nixos requires all such config to be world-readable
<clever>
the point of shadow, was to make those hashes only readable by root
<clever>
this program can brute-force such hashes
<clever>
nix-repl> pkgs.john.meta.description
<clever>
"John the Ripper password cracker"
<clever>
eacameron: in the json file i pasted, should be the hash of all configured passwords (or plaintext passwords if you did it wrong)
<clever>
eacameron: blkid /dev/sd* and then guess/remember
<clever>
eacameron: just mount the root fs to /mnt and then edit /mnt/root/.ssh/authorized_keys
<clever>
eacameron: but i often skip that step entirely
<clever>
eacameron: i think nixos-generate-config will detect your usb drivers and insert them into the initrd
<clever>
yeah
<clever>
eacameron: you can either edit /root/.ssh/authorized_keys directly and call it done, or chroot in and rebuild the system to directly fix it
<clever>
eacameron: yeah
<clever>
eacameron: there is a nixos-install --chroot, that will do what you expect, then you are free to "nixos-rebuild boot" with the proper nix-channel, rather then the one the cd had setup
<clever>
back to the cdrom others have mentioned, though there is a tweak, you dont need full nixos-install
<clever>
cant think of any way around that, the initrd shell would have the same issue
<clever>
eacameron: eek!, do you have a ps2 keyboard available?
<clever>
eacameron: ah, forgot it already has a init= in there, that does make it simpler
<clever>
eacameron: yeah
<clever>
if done correctly, you will get root without any systemd in the way, and will have full control of the system
<clever>
eacameron: you shouldnt need the old systemConfig=, so you can just edit around the giant hash
<clever>
eacameron: use that long path as an example, and change the commandline to init=/nix/store/wl9nfdjkr0yyqpv81i1vsfi8cxvpvhg8-nixos-system-amd-nixos-17.03pre96925.1c50bdd/sw/bin/bash
<clever>
eacameron: you can hit E at the grub menu to edit any entry
<clever>
eacameron: see the long path in systemConfig, within the grub config?
<clever>
gchristensen: you linked it to me a few hours ago
<clever>
ixxie: yeah, the rpi2 is armv7, and the rpi3 is backwards compat with v7
<clever>
that would reduce the memory usage by dedup
<clever>
you can enable dedup on just that block device in zfs
<clever>
how much disk per vm will be dedicated to the /nix/store/ ?
<clever>
how much disk will each vm have?
<clever>
ah
<clever>
BlessJah: how many VM's?
<clever>
BlessJah: it will have some overhead, reading the files, then writing them back out and dedup detecting things
<clever>
BlessJah: and possibly NIX_OTHER_STORES so they can steal files from eachother
<clever>
BlessJah: in the case of VM's, i would use dedup on the host, like ZFS
<clever>
BlessJah: getting multiple systems to share a single /nix/store is a lot more difficult, because of concurrent modifications and garbage collection
<clever>
BlessJah: NIX_OTHER_STORES is mainly to allow one nix instance to copy things out of another nix install, so you save on download time, but not disk usage
2017-01-14
<clever>
sphalerite: nix-env -f stuff.nix -i ?
<clever>
kk
<clever>
gchristensen: pong
2017-01-13
<clever>
i really need to update that box
<clever>
# nixos-version
<clever>
16.03pre76756.885acea (Emu)
<clever>
LnL: it probably has to be paired with the equaly old nix i'm running
<clever>
various things failing to build for various reasons
<clever>
i have had trouble updating that system to the latest nixos-unstable
<clever>
didnt realize it was that old now
<clever>
LnL: i'm still running hydra 29db16bc69d90b7bc851ed15c38dc7f7d1240637 from dec of 2015, heh
<clever>
i usualy -Q -j8, so the messages dont get interleaved, then rerun with -j1 to see just the first failure
<clever>
but nix doesnt allow ~ in a storepath entry
<clever>
and it uses the name of the file for that
<clever>
nix-prefetch-url needs to save the file to /nix/store after the download is done
<clever>
glines: nixpkgs also uses a $sourceRoot to manage some things
<clever>
eacameron: so nix-shell will still give you a shell as it always does
<clever>
eacameron: it will only return after nix-shell returns
<clever>
eacameron: you could just make a 2 line bash script that does nix-shell -I nixpkgs=https://github.com/NixOS/nixpkgs-channels/archive/497e6d2f1d149f5fbe004e15fe8c384eed993943.zip
<clever>
ah
<clever>
so just nix-shell -I nixpkgs=/home/clever/nixpkgs
<clever>
you can modify the nix-path with -I
<clever>
ah
<clever>
which vars?
<clever>
eacameron: so you could just nix-shell -E 'with import <nixpkgs> {}; runCommand "dummy1" { buildInputs = [ hello ]; env1 = "valu1"; } "dummy2"'
<clever>
eacameron: any attribute in a derivation becomes an env variable inside the nix-shell
<clever>
pikajude: i always invalidate the hash by incrementing a random digit
<clever>
pikajude: i believe nix operates purely on the filename and hash, and if the filename hasnt changedm it can find the old tar, which still has the old hash
<clever>
eacameron: nixos makes use of this to map nixpkgs.config over to the actual import <nixpkgs> that all of nixos uses
<clever>
i often also just do { config = {}; };, because i dont want old overrides from past projects to mess with things
<clever>
eacameron: if the config argument isnt supplied, it will default to import ~/.nixpkgs/conig.nix
<clever>
eacameron: one option is just import <nixpkgs> { config = { packageOverrides = super: { .... }; };
<clever>
sometimes its simpler to just edit borgbackup/default.nix directly
<clever>
or however its getting it, need to read its source
<clever>
i would do borgbackup = super.borgbackup.override { acl = null; llfuse = null; };
<clever>
then any reference to fuse in all of nixpkgs becomes a nop
<clever>
eacameron: simplest thing would be to just set fuse to null like you did acl on 5
<clever>
eacameron: do you know what borg uses fuse to do?
<clever>
eacameron: just need to add fuse = null; and see what fails next!
<clever>
yeah, gpt gets rid of all of those risks by forcing you to allocate that kind of thing in the table
<clever>
aszlig: i have used the bios boot partition without problem on all of my machines, and i have also used it to boot over iscsi once
<clever>
grub will install its raw x86 assembly to that partition, and then point to it from the MBR stub
<clever>
thats the guid type code for "bios boot partition"
<clever>
aszlig: you can always create a dedicated partition for it, thats what grub demands whenever you want legacy booting
<clever>
aszlig: i have also had no trouble getting legacy booting to work on gpt, so just say no to MBR :P
<clever>
aszlig: also, with gpt, you have 2 uuid's and 2 labels, one each on the partition table, and the filesystem
<clever>
aszlig: either go entirely disk the label field, or find some PRNG that can generate UUID's
2017-01-12
<clever>
eacameron: you cant access anything inside acl, because its not a supported package
<clever>
error: Package ‘acl-2.2.52’ in ‘/nix/store/jk5dvrv6w9bcgh88g0x7clk19df3q28f-nixos-17.03pre96925.1c50bdd/nixos/pkgs/development/libraries/acl/default.nix:29’ is not supported on ‘x86_64-darwin’, refusing to evaluate.
<clever>
nix-repl> (import <nixpkgs> { system = "x86_64-darwin"; }).acl.meta
<clever>
*looks*
<clever>
not sure if there is an easy way to detect if acl is compatible
<clever>
i believe there is stdenv.isDarwin you can use
<clever>
as long as i guessed all of the attribute names right
<clever>
eacameron: this will just build it without acl
<clever>
eacameron: there is also a shortcut, one sec
<clever>
eacameron: yeah
<clever>
eacameron: i would try just not giving it acl and see what happens
<clever>
but you have to do that by pasting keys into the qemu input buffer
<clever>
so you could force it to only test 250 thru 260mb, with #9
<clever>
i did see an option to force it to scan only a range of addresses
<clever>
it also takes 30-40mins to hit the fault, if you dont force it directly to test#9
<clever>
how much ram do we give that test?
<clever>
are there more faults at higher addresses?
<clever>
yeah, but you need to know that a fault exists at 257mb to do that
<clever>
so you have to know about this exact fault, and bump the ram up
<clever>
aszlig: and more anoyingly, the fault happens at 257mb, and qemu defaults to 128mb
<clever>
aszlig: there doesnt appear to be any automated way to control memtest, or to read its status back
<clever>
the hardening changes in nixpkgs are to blame
<clever>
everything, including the laptop, had the exact same problem
<clever>
no amount of shuffling of hardware would clear the error
<clever>
main issue i had ~2 days ago, is that memtest86 said my ram was bad, in 3 different machines
<clever>
you have to create the filesystem within after you tell libparted to write the tables to disk
<clever>
it doesnt seem to really handle any fs specialy
<clever>
and if it wasnt using unique zfs pool names, that could have turned uglier
<clever>
i had to shove the root-disk of 2 different nixos machines into the same case ~2 days ago
<clever>
but i can see how labels can potentialy cause problems in the future
<clever>
label based is how most of the nixos stuff solves it
<clever>
aszlig: with some changes, libparted could give the uuid, but you still need to generate parts of configuration.nix after partitioning
<clever>
aszlig: so i need a 2nd library to inspect the tables after libparted write them out to disk, which is just ugly
<clever>
aszlig: i had gone with libparted in my installer, but i have since discovered, it has no api to get the UUID out of partitions it has made
<clever>
Baughn: systemctl restart containers@foo
<clever>
Baughn: the containrs have to be manualy restarted
<clever>
nix-env is weird
<clever>
Baughn: nixos-rebuild build-vm is one way to avoid changing the host
<clever>
Baughn: db.sqlite is how nix keeps track of all of the dependencies, and which files are in /nix/store
<clever>
that only effects pgsql and sshd
<clever>
Baughn: but you can mess with a nix-shell binary without impacting db.sqlite at all
<clever>
Baughn: if the nix-daemon is too old for the db.sqlite file, it wont be able to do anything
<clever>
ah yeah
<clever>
it depends on what changed
<clever>
gchristensen: i have manualy downgraded the schema before
<clever>
and then just chgrp to temporarily test if that is all it is
<clever>
you can find the bus and node# with lsusb
<clever>
that would rely on other udev rules putting the usb device into the scanner group
<clever>
ah
<clever>
gchristensen: what about a read-only account that can watch things without the server commiting suicide? lol
<clever>
ixxie: yeah, about 1 or 2 weeks i think
<clever>
simpson: you can just pass a custom config attrset via import <nixpkgs> { config = { packageOverrides = ... ; }; }
<clever>
simpson: my only thought is to try using packageOverride instead
<clever>
simpson: and the nix language has proper support to detect infinite recursion
<clever>
simpson: nothing stands out, it should just work
<clever>
and with 2 pi's in the cluster, it can build twice as fast
<clever>
ixxie: more that i can build just the 50mb part and get the rpi3 to join my cluster much sooner, otherwise i'm stuck with just a single rpi2
<clever>
ixxie: so i dont need full-blown nixos to build nixos
<clever>
ixxie: yeah, making an rpi3 build of nixos using not-os as a more trimmed down build-slave
<clever>
simpson: nope, but i have messed with running the hydra-evaluator outside of hydra
<clever>
ixxie: yeah, i also planned to use not-os as a build slave on my rpi3, to build full nixos
<clever>
simpson: so it doesnt need the ability to edit its own config
<clever>
simpson: you have to edit the config and build it from another box
<clever>
simpson: another thing that makes not-os special, it can lack all nix tools at runtime, so nixos-rebuild isnt a thing
<clever>
simpson: yeah, nano as a default is a good idea, but there is no way to turn that off right now
<clever>
simpson: and in an embeded situation, you dont need any editor
<clever>
simpson: my thought, is that after a user switches to a better editor, why do they still need nano?
<clever>
ixxie: for example, nano is pre-installed in nixos and cant be removed easily
<clever>
ixxie: i used the module framework in nixos, and a small number of its modules, to create a new distro that removes a lot of the un-nessesary things
<clever>
ixxie: i still have the root-disk for a pair of armv6 pi's, but i havent gotten around to finishing a v7 build of nixos, closest i have right now is a not-os build that includes nix-daemon support
<clever>
heh
<clever>
i currently have nixos on my laptop, router, nas, and desktop
<clever>
pi3r: yeah
<clever>
pi3r: try copying it to the other one, ive had similar problems
<clever>
and bisect doesnt find that kind of thing
<clever>
but everything from cache.nixos.org was broken
<clever>
it was a nightmare to git bisect, because everything i was building localy had no sandbox and worked
<clever>
and some nix.conf options would of of use, ive had the sandbox break small features of a project, without the entire build failing
<clever>
copumpkin: i am now
<clever>
but its 1am now, i should get some sleep and deal with it in the morning
<clever>
i believe one of these flags is breaking memtest, need to try them all and see which one is to blame
<clever>
the mobo had everything i needed for a nas
<clever>
that was the first time the pci slot had been used
<clever>
so its not a major loss
<clever>
on the nas, which has a gpu on the cpu die
<clever>
and even that came up faulty
<clever>
thinking it was the mobo, i swapped all the hardware to the NAS mobo
<clever>
and after swapping in the ram from my NAS, it said that ram was bad too
<clever>
memtest86 said the ram in my main desktop was toast
<clever>
unlmtd[m]: i also had a small scare with zfs and defective ram last night
<clever>
unlmtd[m]: but now that ive learned more, i would just use zfs snapshots to do the same job
<clever>
unlmtd[m]: the hdd did fail at one point, i was able to copy an old image of the hdd to a new disk, and basicaly "git pull" the missing changes in
<clever>
unlmtd[m]: i once did that with svn on my router
<clever>
we need a way to override the entire kernel config, and bypass the defaults nixpkgs wants
<clever>
nope, and the kernel config options nixos sets make it a nightmare to build via the proper kernel package
<clever>
contrapumpkin: so you can still get most of the benefits of a virtual machine, but you can skip qemu itself, the kernel just does the emulation directly
<clever>
contrapumpkin: UML is basicaly compiling the linux kernel, to act as a normal linux program
<clever>
contrapumpkin: something ive been interested in, another way of solving the same problem, usermode linux, have you heard of it?
<clever>
then it will import that fixed password file into /nix/store, and bash's $( stuff will strip the trailing newline
<clever>
you could also do "pwgen -s 20 1 > password" once, and then have a nix build do databasePassword = $(cat ${./password});
<clever>
nekroze: the mysql module has something similar, if /var/lib/mysql does not exist during pre-start, it creates /tmp/mysq_init, and then in post-start (the server is now up), it runs some one-time stuff to configure everything
<clever>
sheenobu: so if a /etc/nix/nix.conf file happens to get in the way, setup-etc just replaces it with the correct symlink, and the previous contents are lost
<clever>
sheenobu: the way setup-etc.pl handles the situation pxc mentioned, symlinks can overwrite normal files and symlinks, but it cant overwrite a directory
<clever>
sheenobu: i was initialy just symlinking /etc directly to the store, but sshd gets upset if its private keys are world-readable
<clever>
sheenobu: but bringing in setup-etc.pl has also brought in perl, and thats something like 10 or 15mb, and the entire distro builds down to 47mb
<clever>
sheenobu: it came from nixos, and i am also using it in not-os to manage /etc there
<clever>
sheenobu: i have been considering rewriting setup-etc.pl in c/c++, it is the only thing in not-os that depends on perl, which is adding a large chunk of bloat
<clever>
sheenobu: so it can now edit the /etc/static symlink, and atomicly update every single file that exists in the old&new version
<clever>
sheenobu: one trick setup-etc.pl uses to make things more atomic, is that it symlinks /etc/static to /nix/store/foo-etc/, then it symlinks each config file from /etc/foo.conf to /etc/static/foo.conf