public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
* [gentoo-dev] Fwd: open pull requests [was on netifrc]
       [not found] <57f08773-f7b8-4a05-b792-442ef2330ed1@uls.co.za>
@ 2024-08-28  6:48 ` Jaco Kroon
  0 siblings, 0 replies; only message in thread
From: Jaco Kroon @ 2024-08-28  6:48 UTC (permalink / raw
  To: gentoo development

[-- Attachment #1: Type: text/plain, Size: 2477 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 4237 bytes --]

^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2024-08-28  6:48 UTC | newest]

Thread overview: (only message) (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
     [not found] <57f08773-f7b8-4a05-b792-442ef2330ed1@uls.co.za>
2024-08-28  6:48 ` [gentoo-dev] Fwd: open pull requests [was on netifrc] Jaco Kroon

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox