Hi All,

I've got two PRs open on netifrc project, one of which is becoming more and more of a pain for us, I'd prefer to push it upstream into netifrc since more people can benefit from it than just us, but I'm struggling to get that done so may have to revert to pushing it into our local repositories and projects instead.

Hoping for some advise on how to proceed.

Kind regards,
Jaco



-------- Forwarded Message --------
Subject: open pull requests
Date: Thu, 22 Aug 2024 09:06:58 +0200
From: Jaco Kroon <jaco@uls.co.za>
Organization: Ultimate Linux Solutions (Pty) Ltd
To: netifrc@gentoo.org


Hi,

Would someone please be able to look at the open pull requests for netifrc?

I'm in more and more need of https://github.com/gentoo/netifrc/pull/56 in particular, the other PR I'm much less worried about, and was a "simple" drive-by based on the suggestion from the referenced bug.

I've deployed same to one or two servers already, but we really want it more widespread.  Due to the way ipv6 routing works configuring that by hand is a massive PITA, thus the only effective solutions (which is really much more convenient than IPv4) is to:

1.  Rely on DHCPv6 (requires a dhcp client to be running, something I prefer to avoid in DC);
2.  Rely on RAs from the gateways (yea, plural), the host can then self-configure using EUI64 or the iptoken mechanism, MAC addresses can (and does) change, tokens can be configured which gives predictability.

Combined with other changes since last release may warrant a new point release as well (wireguard improvements, as well as non-device routes - something which we've done in a custom netifrc script for quite some time already, including routing rules, and specific to net.lo, so we loaded these as unreachable_routes=(...) and prohibit_routes=(...), and route[46]_rules=(...) in conf.d/net, happy to share these, they'll conflict a bit with [1] as in it's providing multiple mechanisms to get the same job done.  I think it would be good for Gentoo to standardise the mechanisms.  I do like the idea of just adding non-device routes to routes_lo=, that said, I've often wondered about just externalising non-devices routes and routing rules out of netifrc handling completely into it's own init script which does depend() { before net.lo; }.  This is a separate discussion though.

Kind regards,
Jaco

1. https://github.com/gentoo/netifrc/commit/7c6a8de0c521ea474bccb0dbda4338ff293cdfc6