2018-02-28

<clever> import ./. {}
<clever> lol
<clever> davidak[m]: the last bit is identical to `ps: [ ps.Nikola ps.micawber ]`
<clever> davidak[m]: and `ps: with ps; [Nikola micawber]` is a function that accepts a set of python packages, then puts all of them into scope for the list
<clever> davidak[m]: withPackages wants a function as an argument
<clever> davidak[m]: nix-shell -p python36Packages.Nikola
<clever> sphalerite_: neat
<clever> adisbladis: the only network it does is against 127.0.0.1
<clever> adisbladis: daedalus never loads anything over http or https, so how is the exploit going to get in?
<clever> adisbladis: daedalus for example, it has no website version
<clever> adisbladis: what about electron based apps that are just a GUI over an larger binary your running?
<clever> null_: it will search for any package whose .name is similar to an installed item, and install it
<clever> it cant update itself
<clever> and nix makes things read-only, so you have to patch the expression to update
<clever> etu: i find that it just looses audio capture if you leave it running for 2 days in a row
<clever> null_: and the actual binary is called Discord, after its installed
<clever> null_: once you enable the option to allow unfree packages, the nix-env based search can see it
<clever> null_: its non-free, so the website doesnt include it
<clever> null_: nix-env -iA nixos.discord
<clever> null_: its already packaged
<clever> null_: what are you trying to package?
<clever> electron just happens to include its own copy, rather then using the proper one in ffmpeg
<clever> null_: it might be a config flag thats missing in ffmpeg, or a different version
<clever> null_: libffmpeg.so is from ffmpeg
<clever> null_: which file are you looking for?
<clever> gillmanash: ah, i was trying to help somebody install nixos on a macbook today, but wpa_supplicant cant find any wifi networks in range
<clever> gillmanash: yep
<clever> muzzy_: after a certain age, they just fail the erase cycle
<clever> muzzy_: but there has been problems with the flash memory in FPGA's that are in the beam path
<clever> muzzy_: this machine was out of the beam path, in a cabinet on the side of the room
<clever> mfiano: yeah, its an old rack-mount server out of an xray machine, has 3 gigabit ethernet ports and ECC ram
<clever> gillmanash: and 86 configures a static ip on the LAN port, along with forwarding
<clever> gillmanash: 81 supplies dns to the private network
<clever> gillmanash: 77 is an optional tftp server
<clever> gillmanash: 57 does a dhcp server, you might want to remove the 68-73 area, since its network-boot related
<clever> gillmanash: line 51 sets up an http server, you probably dont need one
<clever> gillmanash: yep
<clever> muzzy_: and 8gigs of ram
<clever> muzzy_: 2 processors (seperate sockets) with Intel(R) Xeon(TM) CPU 3.20GHz
<clever> muzzy_: Supermicro-X6DH8
<clever> thoughtpolice: i suspect it needs a new firmware in the boot rom to solve that problem
<clever> ` from bootmodes/README.md
<clever> thoughtpolice: i was only able to get netboot to work via the `Special bootcode.bin-only boot mode
<clever> thoughtpolice: and these document how it works
<clever> thoughtpolice: and this is fragemnts of what i had on the tftp server, to support netboot
<clever> and thats before i even knew of nix
<clever> simpson: they have made firmware changes to support my demands! :P
<clever> thoughtpolice: and i think 125 was also involved
<clever> thoughtpolice: you need lines 117 and 132 to even tell the rpi to allow network booting
<clever> thoughtpolice: part of the config to support that is in my github repos
<clever> muzzy_: i just dont give up, lol
<clever> thoughtpolice: there is some limited network boot support in the newer rpi's, but ive only gotten them to work if i had a bootcode.bin on the SD card
<clever> thoughtpolice: the rpi still needs a /boot/ on the SD card
<clever> thoughtpolice: there is only one minor problem with the network boot on rpi's right now
<clever> muzzy_: so the computer your taking over, can borrow the wifi temporarily
<clever> muzzy_: it treats the wifi card as the "modem", and the ethernet jack as the "local network"
<clever> muzzy_: this module also sets up packet routing, in a weird direction
<clever> type 'justdoit' into the shell, it wipes the hdd, and now nixos is installed
<clever> you plug almost any machine into the ethernet jack, select network boot, and nixos boots up
<clever> thoughtpolice: and over here, i practically turned nixos into a virus, lol
<clever> and has a password prompt protecting the ipxe shell
<clever> muzzy_: this is an ipxe script that does full signature checking on the kernel/initrd/rootfs
<clever> muzzy_: ive done more crazy things with ipxe and nix
<clever> grub has no clue its network booting and once the initrd is in ram, linux and iscsi-boot.nix can finish the job
<clever> and a normal /boot
<clever> muzzy_: so the disk image on the server, is just bog-standard MBR partition table with grub in the MBR
<clever> muzzy_: so when grub tries to read the local hdd, it winds up reading the iSCSI driver instead
<clever> muzzy_: but ipxe has a function in it called sanhook, which will hijack the legacy api between dos and the BIOS, for accessing the local hdd's
<clever> muzzy_: nfs has given me trouble, and grub doesnt support it
<clever> and the crazy part, is that grub didnt even know it was network booting
<clever> thoughtpolice: so i could test nixos out on my laptop, before wiping the gentoo off of it
<clever> thoughtpolice: and due to how simple nix is, i was able to take that module, almost un-altered, and boot an x86 laptop with it, lol
<clever> thoughtpolice: i started it with my rpi's booting over iscsi, because its both larger and more reliable then an SD card
<clever> muzzy_: it lets you connect to block devices over the network
<clever> muzzy_: scsi over tcp
<clever> and then nixos just automatically connects it at the initrd
<clever> thoughtpolice: this module allows you to set fileSystems."/".iscsi = { enable = true; host = "192.168.2.15"; lun = "something"; };
<clever> simpson: and then the rootfs is iSCSI'd
<clever> simpson: not directly, but if you can boot a kernel+initrd on the rpi, then linux can just open iSCSI over the network
<clever> simpson: and made an attempt at writing drivers for the rpi GPU
<clever> simpson: ive booted my laptop and rpi's over iSCSI with nixos
<clever> thoughtpolice: ive done package overrides against opengl to debug a problem, lol
<clever> muzzy_: line 44 turns on NAT, 45&46 define the LAN and WAN interfaces (see lines 4-6), and 46 defines the LAN network ranges
<clever> including my router, lol
<clever> muzzy_: i use nixos on every piece of hardware i can get it working on
<clever> muzzy_: the rpi support isnt as good as x86, so it takes more effort to install
<clever> muzzy_: as long as you know some c, you can use that book to write kernel drivers for pretty much anything
<clever> muzzy_: there is a book called LDD3 (linux device drivers 3) that goes into depth on how the kernel works
<clever> mfiano: i'm guessing a dependency was updated and nobody noticed the breakage
<clever> plugin.h:24:3: error: unknown type name 'fz_stext_sheet'
<clever> mfiano: which package is it?
<clever> mfiano: that can happen if the package is broken
<clever> null_: nix-locate and nix-index
<clever> mfiano: which consumes a lot of ram
<clever> mfiano: -u will search everything in all of nixpkgs for things with a matching .name
<clever> path*
<clever> mfiano: you just have to know the attr apth
<clever> mfiano: you can upgrade using -iA
<clever> mfiano: -iA uses far less ram
<clever> mfiano: -u and -i involve scanning the entire nixpkgs
<clever> mfiano: depends on what arguments you give it
<clever> ah, yeah, that causes lots of problems
<clever> wilornel: also, try the arrow keys?
<clever> mfiano: check dmesg
<clever> mfiano: you ran out of memory
<clever> wilornel: is bash in the buildEnv?
<clever> ryantm_: :D
<clever> gchristensen: *poke*
<clever> wilornel: it depends on what your default.nix expects
<clever> wilornel: you may need to strip the {} out
<clever> nix-shell -p '(import ./. {}).myHumanInterfacePackages'
<clever> oh, oops
<clever> and now nobody else can use it until the file is deleted
<clever> wilornel: thats a bug, the last user to run nix-shell used /tmp/env-vars and left it behind
<clever> wilornel: nix-shell -p '(with import ./. {}).myHumanInterfacePackages' would just use your existing buildEnv, but its often a lot better to make a shell.nix with a dummy derivation, and put everything into its buildInputs
<clever> so your doing better
<clever> mfiano: my router is at 1.7gig
<clever> wilornel: is there any reason you cant just use nix-shell instead of nix-env?
<clever> wilornel: try "sudo -u alice -i"
<clever> wilornel: how did you get a shell for the other users?
<clever> wilornel: so $NIX_USER_PROFILE_DIR is unique for each user?
<clever> null_: and then it will not care what the url contains
<clever> null_: set the name attribute inside the fetchurl
<clever> mfiano: that is weird
<clever> bash shouldnt depend on dbus
<clever> thats a bit odd
<clever> nix will just start it again if it has to
<clever> yes
<clever> just removing auto-complete from vim did that, lol
<clever> before: 3.0gig, after: 1.7gig
<clever> my laptop has an entire win10 VM in virtualbox, which saves the disk images to $HOME
<clever> mfiano: that wont even store half of my /home partition on the laptop
<clever> i have bigger fish, no point in trying to purge the X :P
<clever> 578M /nix/store/c1lqq2yd6xgk2m940m6ldhlnbwgj0vah-clang-4.0.1
<clever> X is present, but its only 3.4mb
<clever> 3.4M /nix/store/1yd9g0wl9qgf2iysxizwxn7k936jv439-libX11-1.6.5
<clever> [root@router:~]# du --max=0 -hc $(nix-store -qR /run/current-system) | sort -h | grep -i x11
<clever> mfiano: this lists every active path, sorted by size
<clever> [root@router:~]# du --max=0 -hc $(nix-store -qR /run/current-system) | sort -h
<clever> mfiano: let me analyze my router and strip it down...
<clever> cant find the flag i was thinking of
<clever> mfiano: nixops can help a lot with that kind of thing, build it on one machine, then push it out to the server
<clever> mfiano: oh, there is also a flag i forget about, elt me find it
<clever> wilornel: oh, and what does "env | grep NIX" say, are there any vars pointing under per-user?
<clever> wilornel: they should be unique, can you "ls -ltrh /nix/var/nix/profiles/per-user" ?
<clever> wilornel: and if you run nix-env -q as each user, do they have different things installed?
<clever> wilornel: does each user have ~/.nix-profile/ pointing to a unique path?
<clever> wilornel: are they actually different users in linux?
<clever> mfiano: dbus = pkgs.dbus.override { x11Support = false; };
<clever> wilornel: so its not that the redis's are colliding, but the buildEnv symlinks
<clever> wilornel: and the 2 buildEnvs both have a symlink called redis-benchmark
<clever> wilornel: the buildEnv is just a bin directory full of symlinks, pointing to redis
<clever> mfiano: you can also just sort by size, one min
<clever> mfiano: yeah, youll want to try a few greps
<clever> wilornel: nix treats that as a single package, and doesnt know it contains a copy of redis
<clever> mfiano: nix-store -qR /run/current-system | grep xorg
<clever> wilornel: does that file contain a buildEnv?
<clever> mfiano: change the pinentry one to pinentry = pkgs.pinentry.override { gtk2 = null; };
<clever> mfiano: oh wait, i think i know
<clever> mfiano: and you did it exactly like i typed?
<clever> nixpkgs.config.packageOverrides = pkgs: { gnupg = pkgs.gnupg.override { guiSupport = false; }; pinentry = pkgs.pinentry_ncurses; };
<clever> so you can do a packageOverride that sets gnupg = pkgs.gnupg.override { guiSupport = false; };
<clever> mfiano: that installs whatever pkgs.gnupg maps to
<clever> how did you cause gpg to be installed?
<clever> mfiano: do you currently have gnupg in a list somewhere?
<clever> you can also make a packageOverride that does pinentry = pkgs.pinentry_ncurses; to force it globally
<clever> i see a pinentry_ncurses
<clever> mfiano: and if you instead use this variant?
<clever> nix-repl> gnupg.override { guiSupport = false; }
<clever> 6 , pinentry ? null, guiSupport ? true
<clever> nix-repl> gnupg.meta.position
<clever> "/nix/store/pqs6qsjwfrjf0g3gf58drk16q1izby9i-nixos-18.03pre129076.831ef4756e3/nixos/pkgs/tools/security/gnupg/22.nix:56"
<clever> mfiano: then use / to search, and follow things up the tree
<clever> mfiano: run nix-store -q --tree /run/current-system
<clever> mfiano: termite.terminfo doesnt depend on anything else, so you should be able to just add it to systemPackages
<clever> mfiano: and it may already be installed, because you could be experiencing an xterm terminal, via ssh
<clever> mfiano: its part of the ncurses package
<clever> /nix/store/069g827lh3hrhp4vkcq3rsh5jh65pm3l-ncurses-6.0-20171125/share/terminfo/x/xterm
<clever> [clever@amd-nixos:~/.local/share/applications]$ realpath /run/current-system/sw/share/terminfo/x/xterm
<clever> boomshroom: so nix doesnt bother checking for a new version
<clever> boomshroom: you left the hash unchanged, which is telling nix that the contents are unchanged
<clever> boomshroom: you have to tweak the hash, its a common issue
<clever> mfiano: ah, that also works
<clever> boomshroom: ah, lowercase m
<clever> boomshroom: which version of nixpkgs?
<clever> boomshroom: it does, if you set fetchSubModules = true;
<clever> Dezgeg: i cant find it in the source, but the article i remember reading claimed it happened that way
<clever> ottidmes: sudo does have options to fully wipe the env vars
<clever> so now you have 100% root
<clever> ottidmes: and if you just play with ulimit, you can break fuse trying to read /proc/filesystems, causing it to falsely think you dont have fuse
<clever> ottidmes: it didnt sanitize the env, and modprobe obeys an ENV variable for its config, and the config can say "run this instead of loading fuse"
<clever> ottidmes: and if the kernel doesnt support fuse, it will automatically execute `modprobe fuse` as root
<clever> ottidmes: fuse for example has a setuid binary to aid with mounting fuse FS's
<clever> ottidmes: ive also seem that setuid and sudo can be very tricky to secure properly
<clever> but that still gives them nearly root level access to a section of zfs
<clever> i think if you chmod and chgrp /dev/zfs, you can run some zfs commands without root
<clever> ah
<clever> ottidmes: what background services need root ssh?
<clever> ottidmes: when i leave home, take it out, and it becomes password based
<clever> ottidmes: when i'm at home, leave the literal key in the laptop, and it boots without any prompt
<clever> ottidmes: i also have an idea i want to experiment with, i'm thinking i can add a keyfile to my luks volume, and store that on an SD card in the SD reader of my laptop
<clever> ottidmes: also, i luks every machine that is remotely portable
<clever> ottidmes: so you can just delete the ~/.ssh/authorized_keys that gave nixops access, and use a password protected key in your agent
<clever> ottidmes: nixops can work with an ssh agent
<clever> mfiano: JBOD mode
<clever> mfiano: oh, btrfs supports raid like features, what if you just make a 2gig swap partition, then delete it and raid it into the main volume to regain the space?
<clever> ottidmes: nixos has to know which FS drivers to include into the initrd
<clever> ottidmes: boot.initrd.supportedFilesystems = [ "vfat" ];
<clever> mfiano: one where nixos-install uses /mnt properly
<clever> mfiano: dang, you might have to use an older nixos install image
<clever> mfiano: dang, btrfs has no swap file support, how big is /boot ?
<clever> mfiano: ah, that doesnt support swap files, one min
<clever> mfiano: what FS are you using?
<clever> mfiano: with what error?, and what FS are you using?
<clever> mfiano: that would make a 1gig swap file
<clever> mfiano: dd if=/dev/zero of=/mnt/swap bs=1024 count=$((1024*1024)) ; mkswap /mnt/swap ; swapon /mnt/swap
<clever> mfiano: you can use a swap file on the same partition, and just delete it afterwards
<clever> mfiano: and resize the .rw-store tmpfs with `mount /path/to/it -o remount,size=1g`
<clever> mfiano: enable some swap then
<clever> mfiano: and also .rw-store
<clever> gchristensen: ah
<clever> mfiano: check df -h and youll see something that is nearly full
<clever> gchristensen: heh, i was just thinking it should be added to {^_^}
<clever> mfiano: the host /nix/store, which is in a tmpfs
<clever> ottidmes: and wants the bios to re-initialize it
<clever> ottidmes: its possible that the drive itself is demanding that you reboot
<clever> ottidmes: just try each one until it works
<clever> ottidmes: brute-force is what i do
<clever> we can +n again after ryan is done with his own spam :P
<clever> which cuts the spam down to 1/3rd
<clever> gchristensen: if you -n the room, then NixOS_GitHub can msg without joining
<clever> gchristensen: try -n instead
<clever> ottidmes: i would also expect these commands to fully wipe all related caches and re-initialize things
<clever> ottidmes: these commands are for sata hotplug, they let you safely disconnect, and reconnect a sata drive with the machine on
<clever> ottidmes: one last thing
<clever> ottidmes: weird
<clever> ldlework: weird
<clever> ldlework: what are you doing?
<clever> ldlework: are you using the right version of python?
<clever> ottidmes: dang :(
<clever> ottidmes: and then just reload it with `modprobe sd_mod`
<clever> i think the modprobe will also eliminate the need for partprobe
<clever> if it works right, sda should vanish from /proc/partitions
<clever> ottidmes: lets try unloading sd_mod and reloading then
<clever> rmmod, then modprobe
<clever> check lsmod, find the driver for sata drives
<clever> oh, another idea
<clever> there is a number before that timestamp that is important
<clever> 8 1 76052568 sda1
<clever> and does it match up with /proc/partitions ?
<clever> 8,1 in my case
<clever> brw-rw---- 1 root disk 8, 1 Dec 8 00:37 /dev/sda1
<clever> ottidmes: ls -l /dev/sda1 shows what major/minor on the block device?
<clever> ottidmes: what does dmesg say?
<clever> ottidmes: try drop_caches and partprobe again?
<clever> ottidmes: and /proc/partitions ?
<clever> ottidmes: then you dont need to umount it
<clever> ottidmes: what about cat /proc/mounts ?
<clever> ottidmes: then either boots the default, or gives a network accessible boot menu
<clever> ottidmes: my idea, is to have a thin OS (like what you have), that reads grub.conf and sets up the network for remote access for 30 seconds
<clever> and dmesg
<clever> ottidmes: check /proc/partitions and see if it has updated
<clever> ottidmes: basically, the rollback options in grub are useless on remote machines
<clever> ottidmes: ive also had an idea for a software i want to write, that does a lot of what your doing
<clever> ottidmes: you also need to ensure you umount the partition before you partprobe
<clever> ottidmes: and this command will force it to rereat the tables
<clever> partprobe /dev/sdX
<clever> ottidmes: first, if you `echo 1 > /proc/sys/vm/drop_caches` the kernel will just discard all caches
<clever> ottidmes: thats easy
<clever> ottidmes: ah, so you want to wipe the read cache and partition table cache
<clever> ottidmes: ahhh, and then you have zero way to update the shadow
<clever> ottidmes: what happens to the shadow partition table when you unlock?
<clever> ottidmes: ah
<clever> ottidmes: kexec?
<clever> «lambda»
<clever> nix-repl> pkgs.writeText
<clever> ToxicFrog: it should be in pkgs
<clever> ToxicFrog: it accepts just 2 arguments, name: contents:
<clever> ToxicFrog: try just writeText ?
<clever> gchristensen: are they multi-threaded?
<clever> Exec=/nix/store/2j0anj185jb0w7zxpp5q3q6cqib956ib-chromium-62.0.3202.62/libexec/chromium/chromium --profile-directory=Default --app-id=gbchcmhmhahfdphkhkmpfmihenigjmpp
<clever> Name=Chrome Remote Desktop
<clever> and chrome-gbchcmhmhahfdphkhkmpfmihenigjmpp-Default.desktop is chrome remote desktop
<clever> Acou_Bass: this one is to launch the google drive application
<clever> Acou_Bass: and a closer look, reveals that the hash is a chrome extension id