add tunnel-local-dev for tunnel-local iface-based ip configuration
CosmicToast opened this issue · comments
Tunnel local is often defined as a shell blurb, so eval-ing it makes sense.
This is particularly useful now that iproute2 has json output.
Also consider a user-selectable (or generalized) way to eval shell blurbs, as they're commonly used in even more places (though this is the one I'm thinking of currently.
One potential method would be via a builtin executor-like, that would iterate over all IF_* variables and eval them - this would be purely opt-in (this can't be a user-made executor since, as far as my understanding goes, modifications to variables to not propagate up in executors, unless ifupdown-ng bundles a shell parser).
Can you give an example of a config where this would be useful?
iface he6
#requires eth0 # bug #115
address 2001::2/64 # he6 tunnel
gateway 2001::1
endpoint 216.66.38.58 # he6 tunnel
# this will not work as it is now,
# but is guaranteed to succeed as long as eth0 is configured, which it is if we `requires` it
local $(ip -j -4 addr show eth0 | jq -r '.[0].addr_info[0].local')
ttl 255
mode sit
this may still be a race condition in theory depending on the behavior of the dhcp client, but it's better than just having a curl --retry 5 loop in if-up.d
as for the ip + jq blurb, it is guaranteed to work so long as there's only one ip, which for dhcp (which is the use-case here) is always true
tl;dr eth0 is dhcp, he6 is a sit tunnel for hurricane electric, the use-case is not needing to modify the config when dhcp on eth0 gets invalidated
this is indeed possible -- original ifupdown synthesizes a shell script and so the $() is passed through bare to that shell script.
we could emulate this, but i think it would be ideal to have it behind a config option as it is a security concern (running arbitrary code that may or may not be actually intended)
Are there other applications than for tunnel local?
How about adding something like tunnel-local-dev IFACE {4|6} and we grab the IP from there, so no shell is needed at all? I would prefer this a lot about running some shell fragment which somehow while configuring the tunnel get's this information from another device which MAY have been configured and thereby adding internal dependencies.
This behavior is already present in the dhcp executor, so it's clearly ok when used judiciously.
It also shows that the general use-case for "shell blurb as parameter" is semi-common (e.g hostnames, though ifupdown-ng already handles that separately).
For this specific example, I'd be fine with a -local-dev (which could also imply a requires, at least after #115 is fixed), but I do think an emulation system (disabled by default, enabled via conf) would be good to have for all of the use-cases I'm not thinking of right now.
Said emulation would not interfere with allowlist approaches (e.g dhcp executor) since the eval approach used in the dhcp executor is idempotent.
The reason why we allow it in the dhcp executor is because traditional ifupdown would include $(hostname) in the shell fragment it generated to bring up an interface.
Your other example will not work under traditional ifupdown and I am not enthusiastic about adding support for arbitrary shell fragments when building environments.
Well, for this specific case something ala tunnel-local-dev would be fine by me.
I do expect other use-cases to pop up eventually, but those can be dealt with when the time comes I guess. 😄
@CosmicToast can you drop by our IRC channel? we are discussing this at the moment.
I tried doing so (around 3:30 EST, I was at work up until then).
Unfortunately I think the client I tried with was unhappy (only showed me in the room, though it detected 13 members prior to joining).
I'm pretty tired today but have tomorrow off, so do name a time (in EST or UTC, either works) and I'll try again then (if still desired).