Originally looked into
Starting API dispatcher
2021-12-22 11:03:56: (configfile.c.426) Warning: mod_auth should be listed in server.modules before dynamic backends such as mod_cgi
2021-12-22 11:03:56: (configfile.c.426) Warning: mod_auth should be listed in server.modules before dynamic backends such as mod_fastcgi
but it looks like this is a false positive since we don't have mod_auth in there.
This formatted number is used by the Interface Statistics widget,
and makes the columns go wider than necessary when going above a
terabyte of data. Add petabytes for good measure.
Although a direct table lookup will be faster than using a lookup in isAlias(), it's likely not problematic to have a slightly slower lookup using is_alias(), but if performance is of the essence at some point we can easily cache results in isAlias() to reach the same target.
Although there probably are a couple of Huawei modems which do report status info as advertised in the script, there are also a lot who don't and maybe deadlocked when pulling for data on a "random" port.
For now we should remove this, if at some point in the future a sensible method would be supported to poll status in a more "vendor independent" manor, we can always revise.
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
