Was in need of something like this to gain access to a ZFS pool without
having to run a command sequence from the top of my head.
Comes in pretty handy when being included from a recovery install stick.
... leaves us with permission 640 even though we have copied a
644 file. Removing the unlink() makes this work without a
chmod but the unlink is there for the fact that /etc/ssl/cert.pem
used to be a symlink and could clobber the actual file linked
which was the original package provided.
Might be an umask issue, but better leave it where it is.
Instead move the out-of-band configuration into the same area where
the ipaddr/ipaddrv6 configuration is taking place. Should a tunnel
not come up we have clearer readings now of which part of the GUI
can force this...
o The spot is already treated with suspicion that the situation cannot happen
o interfaces_addresses_flush() will ignore an empty realif(v6) so remove comment
Since the code was only fixed in 024c7e1694 and the lookup is
questionable (especially on IPv4 real interface which is vanilla
as opposed to PPP IPv6 shifting).
The problem with e.g. a wan: pppoe0 -> em1 situation is that
if you assign em1 the answer to the query shifts from "wan" to
"opt1" so we would rather miss the situation to resolve "em1"
since the correct interface is "pppoe0" anyway.
Also looking at callers of convert_real_interface_to_friendly_interface_name()
there isn't a PPP-related call in there anyway that would require
this.
* Make it only react to PPP related lookups, no generic fallback
* Move the VLAN portion to a simplified dedicated function
* As a placeholder we shall see if bridges and LAGGs benefit from it
This looks like a typo in the original code as we expect to return
a "wan|lan|optx" thingy.
"Parent" lookup isn't really very useful except for PPP types.
The question is if there is an edge case that would still allow
this to resolve when the other code preceeding it can not.
The trigger was filename + filename32 + filename64 which probably
doesn't work very well for newly added ARM types. Instead write
the conditional architectures as they are filled in. The GUI
certainly doesn't make any restrictions and I believe neiter does
isc-dhcp.
While here polish the GUI labels a little to make the requirements
clearer.
Apparently, Charlie Root was in a hurry when introducing this
back in 2014: https://github.com/pfsense/pfsense/commit/7023c602b
Moral of the story: don't try to call backend scripts to grab env
variables that you could easily read using the acual nameserver
script sort of like dhclient-script is doing it.
ALLOWOVERRIDE is silly as we guard against that in get_nameservers().
