<gchristensen> Dezgeg: ping
<gchristensen> Dezgeg: I have a type 2A running nixos via netboot for community use
<gchristensen> let's talk tomorrow about it
<Dezgeg> pong
<gchristensen> hi
<gchristensen> Dezgeg: I just PM'd you some creds
<sphalerite> and the 2As definitely can't run ARMv7 userspace?
<gchristensen> right
<sphalerite> :(
<gchristensen> when we get aarch64 ok we can send ed-packet another proposal for some armv7-supporting hw :)
<sphalerite> That would be cool. I've set up a Scaleway C1 server (ARM quad-core, 2GB RAM, 50GB storage, 3€/mo) to try and start distributing my builds so my poor Chromebook doesn't have to do everything
<sphalerite> just debian+nix for now though, no nixos
<gchristensen> making netboot images with remote builders requires so many big uploads and downloads across slow links for me
<gchristensen> it takes almost 2x as long to xfer the things around as it does to actually build it
vcunat has joined joined #nixos-aarch64
<vcunat> 0.1s latency actually feels strange when typing into terminal :-)
<gchristensen> hehe yeah
<gchristensen> ok so I have a community system booted up
<gchristensen> I guess we should figure out _how_ we want to use it exactly: do we want to use it as a remote builder, or actually clone nixpkgs and hack and nix-build on the box? as a remote builder, keeping it netboot would be fine... although its SSH host key will change on each boot (unless there is a way to "fix" it)
<vcunat> I expect remote builder will be more comfortable for me, at least for most tasks.
<gchristensen> will nix-daemon complain if the host key changes?
<vcunat> probably it will
<vcunat> IIRC there are some non-obvious steps when setting up remote builders
<gchristensen> yes there are
<vcunat> I wonder if we've improved the docs for that yet :-)
<Dezgeg> I hear it's improved in nix 1.12 but haven't tried
<gchristensen> of course using it as a remote builder means every user who can use it must be a `trusted user`
<gchristensen> this has real down-sides
<vcunat> we only have nix 1.11 there ATM
<Dezgeg> I don't think the version on the build slave matters
<gchristensen> it doesn't
<vcunat> There were some changes, I think.
<vcunat> Like using /build in the sandbox.
<gchristensen> well w.r.t. remote building being a bit easier
<vcunat> but nothing important, I think
<gchristensen> we should probably use nixUnstable on aarch64 anyway
<gchristensen> I guess I'd be fine adding say vcunat, Dezgeg, clever, sphalerite as trusted users, but for example I'd be less comfortable adding flokli or grw who I don't really know as trusted users
<gchristensen> (I didn't mean to leave out andi-, I'd trust andi- to be "trusted")
<flokli> :-D
<gchristensen> whereas I think would be comfortable giving flokli and grw ssh access
<gchristensen> unless y'all think I shouldn't :)
<vcunat> I wonder about remote-builder usability for "untrusted users"
<gchristensen> it can't be done currently because the user must be able to directly import things in to the store
<vcunat> the problem is transferring the /nix/store paths, right?
<gchristensen> yeah
<vcunat> as nix-build is usable by anyone
<vcunat> it might be nice if nix supported the substitute-only mode for untrusted users...
<gchristensen> that would be cool
<vcunat> Do you plan the add this machine to borg, bumping it to three platforms?
<gchristensen> yes :)
<flokli> awesome :-)
<flokli> anybody of you thought about buying a [Gemini PDA](https://www.indiegogo.com/projects/gemini-pda-android-linux-keyboard-mobile-device-phone) ? Sounds like a nice portable piece of hardware
<flokli> wonder about mainline support… there are already MT6797 devicetree files in the kernel…
<sphalerite> eh, I would, but I'm not sure I'd like the tiny keyboard
<sphalerite> (also money)
<gchristensen> as a rule I don't buy complicated looking hardware from kickstarter or indigogo
<flokli> there is already a review
<flokli> "The Gemini PDA is an all new device that has modern specs, but retains the original keyboard design. Not a lookalike, but the same tech that made it so uniquely comfortable to type on."
<gchristensen> oh hi
<flokli> so i'm really tempted
<vcunat> flokli: do I connect people correctly? You bought Turris Omnia via crowdfunding and then encountered problems with HW support not really upstreamed?
<flokli> vcunat: right. I was sitting next to andi in this restaurant thingie during nixcon
<flokli> andi- is the one who talked about knot resolver
<vcunat> OK, thanks :-)
<flokli> vcunat: currently, turris is still doing a godd job as my home router - but I'd like to move to a declarative router, so nixos on clearfog pro is the current plan ;-)
<flokli> gchristensen: right, something like this :-) maybe a bit more detailed firewalling, using ferm
<gchristensen> what would that look like / do? I say, inherently interested in making mine better ;)
<andi-> well ferm is just an ancient perl-wrapper around iptables that uses ipstables-restore/save.. I'd use the nftables things these days.. looks almost the same and is the newer (and proper?) kernel way of doing firewalling these days
<vcunat> flokli: I really hope I can look into nix-* containers (LXC) on Omnia over Christmas
<andi-> gchristensen: replace isc-dhcpd with isc-kea and you can use `toJSON` for the configuration and transformat nix to dhcp configuration without large text blocks ;-)
<gchristensen> ooohh
<andi-> I meant to write a module (if it is missing) and also work on a migration towards `nft` for the firewall module.. but there are just so many hours each day..
<flokli> gchristensen: basically, ip range whitelisting in the forwarding chain. I might also use nix to do the abstractions and grouping I currently have with ferm and go the nftables way as andi- suggested
<flokli> vcunat: sounds good :-) Other thing would be a switchdev driver for the switch chip
<flokli> But having nix in a container would already allow me to move some parts inside a container
<gchristensen> neat, flokli
<clever> andi-: would it still support things like lines 21, 40-43, and some other stuff not in that gist? https://gist.github.com/cleverca22/5fb37427c8d944626a49eff525a91d06
<andi-> clever: probably yes, I am not sure how to (gracefully) handle those inline iptables commands...
<andi-> the idea would be to be compatible with the current firewalling (except for the extraRules) and thus introduce it on a different name and/or have a switch to select between old & new
<clever> andi-: those are more about the existing system not supporting things
<clever> andi-: so i would have to replace them with inline NF rules
<andi-> yes
<clever> the root issue, is that i want to allow 53 on one interface, but block it on another
<clever> so i dont wind up becoming a dns reflection attack
<andi-> clever: that is a MUST have feature.. otherwise the firewall isn't really useful :-)
<clever> oh right, and there is a secondary problem that i never bothered to fix
<clever> the port forwarding needs to SNAT anything coming from the lan
<clever> if i try to access a forwarded port from inside the lan, the source ip isnt mangled
<clever> and so the reply bypasses the router
<clever> and then the destination isnt un-mangled
<clever> so the connection fails
<andi-> this is goinf off-topic ^^ I still have to read what those highlights earlier were about
<gchristensen> LOL right, sorry
<gchristensen> #nixos-on-your-router (not a real channel)
<clever> it is now!, lol
<vcunat> clever: or you can make resolver listen only on some interfaces (i.e. addresses)
<clever> vcunat: that works for udp based things, but for tcp based things, it would result in connection refused errors leaking
<clever> which reveals that the port is partially open
<vcunat> right, I can't judge if it's bad to have an open TCP port with nothing listening
<clever> i was also the victim of a ddos attack on sunday
<clever> dns based, ~80 byte packets, 89,000 packets/second
<gchristensen> lets move this to the router channel :P
ed-packet has quit [(Quit: leaving)]
vcunat has quit [(Ping timeout: 250 seconds)]
<Dezgeg> next up on the way to images is https://github.com/NixOS/nixpkgs/pull/32618
<gchristensen> needless cross-post, you can now curl | bash and get nix on aarch64
<gchristensen> $ nix-shell -p nix-info --run nix-info
<gchristensen> system: "aarch64-linux", multi-user?: no, version: nix-env (Nix) 1.11.16, channels(ubuntu): "nixpkgs-18.03pre122433.8a7b2f889dd", nixpkgs: /home/ubuntu/.nix-defexpr/channels/nixpkgs
<gchristensen> how should I divvy access to this community box? a github issue for people to request access?
<gchristensen> should each user be trusted?
<gchristensen> let's make a choice for now annd then we can improve or change it later