2018-03-02

<clever> ive also seen somebody use that for their desktop, the nixpkgs would chain itself from the current generation to all future generations, so its managed in nix, but not nix-channel
<clever> disasm: so you never have to deal with channels on the servers, the nixpkgs just always matches the current build
<clever> disasm: the nixops-managed.nix file also messes with $NIX_PATH, pointing it to whatever nixpkgs was used to build the machine
<clever> michas_: i figured that out just by reading all of the nixos sources
<clever> then it actually "worked", lol
<clever> gchristensen: then one day, his new machine did have a configuration.nix
<clever> gchristensen: and he claimed it has worked before (because they lacked a configuration.nix, and it did nothing)
<clever> gchristensen: ive also seen somebody in this channel set the auto-upgrade flag in nixos, on nixops managed machines
<clever> michas_: nixos cheats, by keeping a copy of the generation you originally booted
<clever> michas_: if you nixos-rebuild switch too far into the future of nixpkgs, the kernel modules cease to be compatible
<clever> michas_: yeah, it nees to root the booted version, for kernel modules
<clever> disasm: some nixops images include a dummy configuration.nix, and nixos-rebuild would undo the entire deployment, reverting it back to a fresh state
<clever> disasm: also, i use this to prevent nixos-rebuild from being used: https://github.com/cleverca22/nixos-configs/blob/master/nixops-managed.nix#L3-L10
<clever> disasm: yeah, thats why i'm considering builtins.fetchGit ./. since it strips out all files git isnt managing
<clever> michas_: what is the root holding on to it?
<clever> michas_: ok, then run nix-store --query --roots on the wayland path
<clever> ottidmes: yeah, those can be tricky, mostly just takes experience to know the flow of things and how to avoid it
<clever> ottidmes: but with nix, it makes one on every build, and keeps them with the build
<clever> ottidmes: i also have zfs snapshoting, with snapshots being made monthly,weekly,daily, hourly, and every 15mins
<clever> michas_: look at nix-store --query --tree /run/current-system, and see what the path is
<clever> ottidmes: and then if i need to undo something, i have history in the store
<clever> ottidmes: so i let nix snapshot the entire config on every build
<clever> ottidmes: more, that i dont want to commit every single 2 line change
<clever> matt_r_: i recently converted my router from nixos to nixops, and it has made it much simpler to manage
<clever> ottidmes: the revision wont tell you the changes, and i use that trick to get the smaller iterative stuff i do between commits
<clever> ottidmes: i have recently considered switching to `builtins.fetchGit ./.` from nix 2.0, which cleans the directory, but .git is also lost, so no more diffs
<clever> ottidmes: but nix-store --optimize can dedup those copies together
<clever> ottidmes: nix just clones the whole thing, including all of the .git
<clever> what hostname is it trying to connect to?, can you gist the output and nix expressions?
<clever> matt_r_: i recently had to fix something with `nixops deploy --allow-recreate --include HOST -d cluster --check`
<clever> that should test everything, and re-create anything thats missing
<clever> another thing you can try, nixops deploy --check
<clever> ah, thats it
<clever> matt_r_: do you have deployment.type = "ec2"; ?
<clever> yeah, its broken that --include can skip dependencies
<clever> this reports what i had changed when building 356
<clever> git -C /nix/var/nix/profiles/system-356-link/nixcfg/ diff
<clever> and the .git comes along for the ride, so you can `git diff` in every one of them
<clever> so now every single generation of nixos has an archive of how it was made
<clever> and it winds up at /run/current-system/nixcfg/
<clever> matt_r_: every time you make a build of nixos, it will copy the directory core.nix is in (which contains all the nix files) into /nix/store
<clever> matt_r_: another thing that can help in a similar way to git is this: https://github.com/cleverca22/nixos-configs/blob/master/core.nix#L117-L119
<clever> matt_r_: it helps if you keep the nix expressions in git, then you can just `git diff` to see what you did to break it
<clever> matt_r_: that shouldnt happen
<clever> matt_r_: what params are you running it with?
<clever> matt_r_: the parallelism in nixops sometimes gets ahead of itself, and --include forces it to skip creating some times
<clever> sphalerit: yeah, pushbullet does full instant messaging, both between friends, and your own devices, so i can push a url to the desktop, and it can attach images to those IM's
<clever> sphalerit: ive been using pushbullet for that lately, does syncthing support similar?
<clever> gchristensen: i think it waits for a reply from an ELF binary in /tmp to shut itself down for updates, so it just semi-hangs when it tries to update itself
<clever> gchristensen: last time i used it on nixos, it worked out of the box with a nix-env -iA nixos.dropbox, and as long as i dont let it update, it keeps working
<clever> and also ive run out of space anyways
<clever> i should look into that then, ive had trouble with dropbox breaking on nixos because it self-updates
<clever> i'm used to forcing answers out of unfree software
<clever> yeah, lol
<clever> sphalerit: more thinking about how you would decrypt it, to confirm what its doing
<clever> ottidmes: but burp will need root to listen on 443
<clever> ottidmes: ah yeah, that works perfectly, and burp supports such modes
<clever> ive used it before to see what android apps are up to
<clever> ottidmes: and using https://portswigger.net/burp you can mitm https
<clever> only tricky part is getting syncthing to use it as a proxy
<clever> ottidmes: using security.pki.certificates you can get the system to globally trust a self-signed cert, which allows you to mitm anything https
<clever> ottidmes: ah, that will be tricky to inspect then
<clever> ottidmes: http or https?
<clever> jsgrant: ghc as well
<clever> jsgrant: cmake sort of has one
<clever> drdaeman: and a partially written nixos module that is going to use it: https://github.com/cleverca22/nixos-configs/blob/master/qemu.nix
<clever> phdoerfler_: when using startAt, the type and timers can be omited entirely
<clever> phdoerfler_: the startAt on a service auto-generates a timer, let me grab a full example
<clever> tnks: buildins.readDir i think can help
<clever> phdoerfler_: yeah
<clever> phdoerfler_: it is using that command to build a mini nix package
<clever> phdoerfler_: the thing to keep in mind, is that it doesnt run the command outside of nix
<clever> phdoerfler_: and nix will always build that first, then the runCommand
<clever> phdoerfler_: refer to the other nix expression in the bash code passed to runCommand
<clever> tnks: i think hydra can use github auth, but i havent looked at how its configured
<clever> phdoerfler_: you may need to copy the thing your wanting to read ingo . first
<clever> phdoerfler_: that will run the command in an empty directory, so it wont be able to read anything
<clever> tnks: the hydra config is either thru the web gui, or json&nix files
<clever> mfiano: it already has power/lid/ac_adapter handlers
<clever> yeah
<clever> tnks: what does it need github oauth for?
<clever> phdoerfler_: buildInputs are the packages your bash code needs to run
<clever> phdoerfler_: both runCommand and stdenv are part of pkgs
<clever> phdoerfler_: basically, you can just runCommand "name" { buildInputs = [ foo ]; }; ''some bash code'';
<clever> though this one doesnt copy the docker image over, the metadata is just the path to the docker image
<clever> tnks: you would want to use pkgs.runCommand to create a directory containing that info, and a symlink to the image
<clever> tnks: yeah, it lands in /nix/store/
<clever> tnks: but hydra can build docker images, so you just need an external script that does curl ... | docker load ; docker push
<clever> symphorien: there is something in nixos to handle that, at nixos-rebuild, it will generate a secondary initrd, and cat the 2 together
<clever> tnks: and in the hydra config, you can set it to root everything for the last X builds
<clever> tnks: hydra then builds every derivation, and keeps the build-time closure rooted, so it can re-build new versions with minimal downloads
<clever> tnks: with hydra, you give it a release.nix file, which returns an attr set of derivations to build
<clever> tnks: just remove the job from the release.nix file, and it will expire naturally
<clever> tnks: hydra automatically roots the entire build-time closure of every active job, and also acts as a nix cache
<clever> tnks: there is also nix-collect-garbage --max-freed 1G, which stops after 1gig, but its random which paths it deletes
<clever> enp3s0 maps to 03:00.0 Ethernet controller: Qualcomm Atheros QCA8171 Gigabit Ethernet (rev 10)
<clever> mfiano: lspci tells you that info
<clever> sebboh: the repl says :? for help, and you can just eval config.boot to see the config
<clever> priority=10
<clever> mfiano: you can edit the wpa_supplicant.conf after the above cmd, to set a priority
<clever> sebboh: the man page is auto-generated from the nix expressions
<clever> mfiano: wpa_gui works on nixos and i think it can write to wpa_supplicant.conf for you
<clever> sebboh: nix-repl '<nixpkgs/nixos>'
<clever> pmade: nix.package = pkgs.nixUnstable; to upgrade it
<clever> mfiano: leave /etc/wpa_supplicant.conf unmanaged by nix, and just manualy copy the file in after the install
<clever> pmade: builtins.fetchGit ./.
<clever> deanman: try both?
<clever> deanman: for channels, it should honor them
<clever> joko: originalSystem may be {}, but never null
<clever> phdoerfler_: one-shot systemd units that check for the existance of the resource they create
<clever> joko: toplevel is a package
<clever> mfiano: so <nixos/nixpkgs/nixpkgs/nixpkgs> is the same as <nixos>
<clever> mfiano: <nixos> gives the channel named nixos, and nixpkgs is a symlink to . within that
<clever> TonyTheLion: and if you have a boot partition, that should be at /mnt/boot/
<clever> TonyTheLion: while booted into a recovery environment, you need to move the contents of /nix to the new partition, while preserving all ownership bits, then mount the original rootfs to /mnt and the store to /mnt/nix, then `nixos-install --chroot`, fix configuration.nix, and `nixos-rebuild boot`
<clever> mfiano: nix-repl '<nixpkgs/nixos>'
<clever> TonyTheLion: i have changed it after install, but you need enough free space to make the partition, and you have to move the data over while booted into a recovery mode
<clever> TonyTheLion: thats also something you usually can only change at install time
<clever> TonyTheLion: if your using nixos, you have to set fileSystems."/nix" = { ... to configure it to mount on bootup
<clever> TonyTheLion: i always put /nix on its own zfs dataset
<clever> the_real_plumps: your welcome :)
<clever> the_real_plumps: bienvenue
<clever> the_real_plumps: set nix.package = pkgs.nixUnstable; in configuration.nix
<clever> the_real_plumps: yeah, that "release" is a bit confusing
<clever> matt_r_: ssh should just come up on its own
<clever> nix-env -e nix
<clever> you installed the unstable one with nix-env, and now its having a small conflict
<clever> yep
<clever> without the realpath
<clever> the_real_plumps: where is nix-build?
<clever> what about just which nix-build?
<clever> thats 1.12, the pre-release of 2.0
<clever> the_real_plumps: what does this say: realpath $(which nix-build)
<clever> the_real_plumps: your using 2.0 features with a 1.11 daemon
<clever> { resources, ... }:
<clever> the deployment accepts a resources parameter
<clever> matt_r_: resources.ec2SecurityGroups.mygroup
<clever> and then you can refer to it
<clever> matt_r_: so you have to set resources.ec2SecurityGroups.mygroup at another point, and specify what is in the security group
<clever> matt_r_: i believe its a name from when you created it
<clever> electrocat: ah, then just remove it from root
<clever> electrocat: so id still remove it from the non-root user
<clever> electrocat: ah, then the root channels are also the default for all other users
<clever> electrocat: multi-user install?
<clever> electrocat: what OS is this?
<clever> electrocat: remove the channel from the non-root user
<clever> electrocat: it shouldnt be
<clever> electrocat: thats because you have channnels with colliding names on your user and root, check nix-channel --list with and without root
<clever> electrocat: why does it give you warnings?
<clever> matt_r_: ive never had issues with the master socket nixops uses in ssh
<clever> matt_r_: and if you do the same ps at the laptop?
<clever> matt_r_: try ctrl+c and re-deploy?
<clever> disasm: double-check that nixos is still in /etc/nix/nix.conf
<clever> matt_r_: yeah, nothing is running at all
<clever> yeah
<clever> matt_r_: can you pastebin the whole `ps -eH x`
<clever> so it has to boot linux, unlock, then kexec linux (or soft reboot)
<clever> samueldr: when the drive is encrypted, all you can see is a special shadow partition, which will boot using this image, if you then run a special sedutil, the drive unlocks, and then you can only see the protected content, and the shadow is missing
<clever> samueldr: i also wrote this yesterday to help somebody with their sata drive encryption: https://github.com/cleverca22/nixos-configs/blob/master/pre-boot-image.nix
<clever> ive used it with both u-boot and pxelinux
<clever> yeah
<clever> shlevy: but if you ssh in, it stops the count-down, and you can pick which generation to kexec into, or just get a shell
<clever> shlevy: the bootloader, is a linux kernel+initrd, that runs something like dropbear, and waits 30-60 seconds, then it will kexec the default option
<clever> shlevy: ive had an idea ive been wanting to write for a while, a dropbear based bootloader
<clever> neat
<clever> snajpa: nixos has been mounting /nix/store over /nix/store for ages, to make it read-only
<clever> though i have made a custom character device in the kernel itself, it implements a sub-section of the handlers
<clever> ive only felt with the filesystem api via fuse, for the most part
<clever> Mic92: i *think* that the readdir/open syscalls on the root directory can know that, but they would then have to propagate it via special handles to the subdirectories?
<clever> then you have proper length prefixed strings and multiple channels
<clever> launch your haskell program inside the guest, and setup a muxed channel over the serial port
<clever> what if you want to run 2 things in parallel?
<clever> what happens if the command happens to print an EOF?
<clever> srk: it just runs the command, echo's the return code, then prints EOF
<clever> let me find the code...
<clever> srk: you can only run one command at a time, and the parsing to get its stdout is pretty hacky
<clever> srk: nixos uses this to create a root shell at /dev/hvc0, which maps to a socket on the host
<clever> srk: oh, something you could improve on a lot, is the backdoor shell
<clever> then the lua script contained the actual testcase
<clever> srk: the c/c++ end handled loading the test driver, the protocol decoding/encoding, and converting protobuf to/from lua tables
<clever> srk: i once wrote a fairly massive (and protocol specific) test harness in c++/lua, just so i could avoid dealing with the protocol in perl
<clever> srk: ever hear about disorderfs?
<clever> but containers handle that better
<clever> some of the magic like the systemd units wont work as well in a systemd unit
<clever> ah

2018-03-01

<clever> Mic92: and there is a system_tarball_pc on line 190
<clever> Mic92: just add an attribute to release.nix, for either nixos or nixpkgs
<clever> Mic92: ah, release.nix should be fine then
<clever> Mic92: packages are just a PR against release.nix
<clever> Mic92: package, or jobset?
<clever> Mic92: yeah, i see no signs of declarative jobs on the hydran.nixos machine
<clever> and thats where it leaks the declarative config: https://hydra.angeldsis.com/jobset/not-os/.jobsets#tabs-configuration
<clever> that means its declarative
<clever> Mic92: in this hydra, you can see a jobset called .jobsets
<clever> Mic92: up one level, in the project itself
<clever> and .jobsets also leaks some of the info on where to find that declarative config
<clever> if its declarative, it will always have .jobsets
<clever> Mic92: open the hydra itself, and look for a jobset called .jobsets
<clever> youll need to share something then, and put the ssh agent socket there
<clever> and i think my trick relies on /tmp being shared
<clever> viric: the env vars are cleared
<clever> viric: if you run strace on the ssh agent, do you see a connection coming in?
<clever> Baughn: also, it refuses to begin a download until all the dependencies of that item are done downloading
<clever> ottidmes: nix-prefetch-url '<nixpkgs>' -A hello.src
<clever> ottidmes: nix-prefetch-url also accepts an attr path i believe
<clever> ottidmes: either nix-prefetch-url first, or use one of the new-ish nix flags, let me find it
<clever> Baughn: nice
<clever> so every time the user fixed the hash, it changed
<clever> also, ive seen a similar problem months ago, there was a timestamp in the 404 page
<clever> globin_: read its contents, before assuming the hash it gave is valid
<clever> globin_: a tip, nix leaves the .zip file in the store after the hash check fails
<clever> ryantm: run "file" on that zip file
<clever> Baughn: nix.package = pkgs.nixUnstable;
<clever> Baughn: possibly
<clever> gchristensen: the store caches a lot of things
<clever> Baughn: your `lacks a signature` error is because the nix-daemon is too old for the client
<clever> tnks: and root can already safely do things without talking to the daemon
<clever> tnks: it uses .lock files in the store to manage most exclusive access
<clever> Izorkin: ah, that can break a number of things
<clever> srid: adding it to systemPackages wont recompile anything to use it
<clever> mfiano: id just skip lvm in that case
<clever> srid: and as long as the channel is named nixpkgs-unstable in --list, it will be safe to use on nixos, and the above snippet will find it
<clever> srid: you can do (import <nixpkgs-unstable> {}).glm in your configuration.nix
<clever> Izorkin: if you can document how to reproduce the issue, sure
<clever> srid: that is how you break things
<clever> srid: you must never run nixos from the nixpkgs-unstable channel
<clever> srid: what does sudo nix-channel --list say?
<clever> Izorkin: maybe
<clever> gchristensen: or launch each shell in a unique directory
<clever> gchristensen: nix-shell breaks that assumption, you have to rm -rf the dir after closing the shell
<clever> gchristensen: thats a bug in the qt setup hooks, it creates a directory on startup, and assumes it doesnt already exist, because nix starts all builds in a fresh dir
<clever> Izorkin: how much free ram?, any swap?
<clever> Izorkin: are you inside a container?
<clever> srhb: i think it should be type = types.uniq types.attrs;
<clever> srhb: aha, uniq, line 308
<clever> no, that still merges, hmm
<clever> srhb: options occuring later in the sequence overwrite ones earlier, but options absent in the 2nd will let the 1st bleed thru, mixing kernel versions
<clever> srhb: since it lacks a type, nixos will run mergeAttrs over things
<clever> srhb: it doesnt even have a type!!
<clever> srhb: i would expect that to error, what actually happens?
<clever> mfiano: ive only used zfs-on-linux variant, not the openzfs one
<clever> lejonet: create systemd units that run on startup, and create files somewhere, and if the file exists, do nothing
<clever> mfiano: it tries to be smart, and update less channels, but its basically the same
<clever> mfiano: yes
<clever> viric: the namespaces are just avaialble by default
<clever> viric: funnily enough, 17.09 got 2.0 before master
<clever> viric: mount namespaces can do a chroot without root
<clever> viric: it lets you bundle the entire closure of a nix derivation into a single blob, much like the dell installer joko was packaging
<clever> viric: with that, you could just namespace yourself into what is essentialy a single-user install like on debian, even if your on nixos
<clever> and to make it very simple to install/manage
<clever> viric: basically, i want to use nix-bundle to install nix into ~/nix/, without the normal mass-recompile issues
<clever> viric: i was actually planning on something today that would happen to solve your issue as well
<clever> viric: so you then need either some namespace magic (doesnt need root) or nix copy (needs root) to move the binaries into /nix/store
<clever> viric: nix 2.0 sort of allows that, with the --store stuff, but the resulting products are at the wrong path and cant just be ran
<clever> viric: ah, yeah, i see the issue
<clever> viric: and nix will proxy it around to the right user
<clever> viric: basically, it would work the same as `ssh -A`, the daemon makes a listening unix socket inside the sandbox, and the nix-build process running as a normal user connects to the ssh agent normally
<clever> viric: thats why i have an issue open about adding ssh agent support to nix
<clever> joko: why does it say nativeBuild*Outputs* ?
<clever> joko: nix will expect the unpackPhase to create exactly 1 directory, and auto-detect that as a sourceRoot
<clever> joko: you still need to set sourceRoot, or make a directory you copy it to
<clever> joko: oh, and the coreutils, no need to mess with PATH, just put coreutils into buildInputs
<clever> joko: also, you probably want to use unpackPhase rather then unpackCmd
<clever> then make a patch against that now-constant name
<clever> chmod +x whatever.bin
<clever> cp $src ./whatever.bin
<clever> rename it when you cp
<clever> no
<clever> so you can never predict what it will be called
<clever> and then the cp copies it to hash-name in the current directory
<clever> first problem there, is that the fetchurl lands at /nix/store/hash-name
<clever> joko: ah, src is just a an executable
<clever> joko: can you gist the nix expression?
<clever> joko: try prePatch = "ls -l"; to see what files are in the directory
<clever> if you add prePatch = "ls -l SINGLEFILE"; does it find it?
<clever> that should work, does that file exist in the root of the unpacked source?
<clever> is there one with +++ and a filename?
<clever> joko: next one?
<clever> joko: what is the first 2 lines of the .patch?
<clever> joko: is the path in the patch file correct?
<clever> robstr: sudo -i
<clever> BlessJah: though it is more bulky to "dock" a phone into a tablet or laptop when you want a bigger screen
<clever> BlessJah: yeah