<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?
<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
<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 :-)