This is a multi-part message in MIME format.
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
<!DOCTYPE html>
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Hi All,</p>
<p>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.</p>
<p>Hoping for some advise on how to proceed.<br>
</p>
<p>Kind regards,<br>
Jaco<br>
</p>
<div class="moz-forward-container"><br>
<br>
-------- Forwarded Message --------
<table class="moz-email-headers-table" cellspacing="0"
cellpadding="0" border="0">
<tbody>
<tr>
<th valign="BASELINE" nowrap="nowrap" align="RIGHT">Subject:
</th>
<td>open pull requests</td>
</tr>
<tr>
<th valign="BASELINE" nowrap="nowrap" align="RIGHT">Date: </th>
<td>Thu, 22 Aug 2024 09:06:58 +0200</td>
</tr>
<tr>
<th valign="BASELINE" nowrap="nowrap" align="RIGHT">From: </th>
<td>Jaco Kroon <a class="moz-txt-link-rfc2396E" href="mailto:
jaco@uls.co.za"><
jaco@uls.co.za></a></td>
</tr>
<tr>
<th valign="BASELINE" nowrap="nowrap" align="RIGHT">Organization:
</th>
<td>Ultimate Linux Solutions (Pty) Ltd</td>
</tr>
<tr>
<th valign="BASELINE" nowrap="nowrap" align="RIGHT">To: </th>
<td><a class="moz-txt-link-abbreviated" href="mailto:
netifrc@gentoo.org">
netifrc@gentoo.org</a></td>
</tr>
</tbody>
</table>
<br>
<br>
Hi,<br>
<br>
Would someone please be able to look at the open pull requests for
netifrc?<br>
<br>
I'm in more and more need of
<a class="moz-txt-link-freetext" href="
https://github.com/gentoo/netifrc/pull/56">https://github.com/gentoo/netifrc/pull/56</a> 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.<br>
<br>
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:<br>
<br>
1. Rely on DHCPv6 (requires a dhcp client to be running,
something I prefer to avoid in DC);<br>
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.<br>
<br>
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.<br>
<br>
Kind regards,<br>
Jaco<br>
<br>
1.
<a class="moz-txt-link-freetext" href="
https://github.com/gentoo/netifrc/commit/7c6a8de0c521ea474bccb0dbda4338ff293cdfc6">https://github.com/gentoo/netifrc/commit/7c6a8de0c521ea474bccb0dbda4338ff293cdfc6</a><br>
<br>
</div>
</body>
</html>
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)