This patch is introducing the wired setting accept-all-mac-addresses
property. The value corresponds to the kernel flag IFF_PROMISC.
When accept-all-mac-address is enabled, the interface will accept all
the packets without checking the destination mac address.
Signed-off-by: Fernando Fernandez Mancera <ffmancera@riseup.net>
Extend nm_utils_file_set_contents to be able to optionally set the last
access + last modification times on the file being created, in addition
to the mode.
initscripts don't support "$VLAN_ID". They actually support "$VID",
which NetworkManager doesn't.
"$VLAN_ID" was introduced by commit 10b32be37b ('ifcfg-rh: various VLAN
cleanups'). It has a comment about "backward compatibility" for the case
where the reader would ignore "$VLAN_ID" if "$DEVICE"'s name contains
a suffix that is parsable as VLAN ID.
That is wrong. If a new feature gets introduce (like NetworkManager
supporting "$VLAN_ID"), then there is no way that an older version of the
tool -- which doesn't know the new feature yet (initscripts) -- supports it.
This is not what backward compatibility means. Backward compatibility
means that if a user has an old ifcfg-file without "$VLAN_ID", then we
continue parsing it as before.
Consider, when a user (or NetworkManager) writes a configuration
DEVICE=vlan9
PHYSDEV=eth0
VLAN_ID=10
then it makes no sense to ignore VLAN_ID=10 and use "9" instead.
Otherwise the user (or NetworkManager) should not have written the
file this way.
Also, NetworkManager profiles support "connection.interface-name=vlan9"
together with "vlan.id=10". Such a configuration is valid and must be
expressible in ifcfg-rh format. The ifcfg-rh writer code did not somehow
restrict the setting of "$VLAN_ID" to account for this odd behavior. Whenever
NetworkManager in the past wrote VLAN_ID variable to file, it really meant
it.
https://bugzilla.redhat.com/show_bug.cgi?id=1907960https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/794
Asserting against user input is not nice, because it always requires the
caller to check the value first. Don't do that.
Also, don't even check. You can set NM_SETTING_WIRED_S390_OPTIONS
property to any values (except duplicated keys). The C add function
should not be more limited than that. This is also right because
we have verify() which checks for valid settings. And it does so beyond
only checking the keys.
So you could set NM_SETTING_WIRED_S390_OPTIONS properties to invalid
keys. And you could use nm_setting_wired_add_s390_option() to set
invalid values. No need to let nm_setting_wired_add_s390_option() check
for valid keys.
glib requires G_LOG_DOMAIN defined so that log messages are labeled
to belong to NetworkManager or libnm.
However, we don't actually want to use glib logging. Our library libnm
MUST not log anything, because it spams the user's stdout/stderr.
Instead, a library must report notable events via its API. Note that
there is also LIBNM_CLIENT_DEBUG to explicitly enable debug logging,
but that doesn't use glib logging either.
Also, the daemon does not use glib logging instead it logs to syslog.
When run with `--debug`.
Hence, it's not useful for us to define different G_LOG_DOMAIN per
library/application, because none of our libraries/applications should
use glib logging.
It also gets slightly confusing, because we have the static library like
`src/libnm-core-impl`, which is both linked into `libnm` (the library)
and `NetworkManager` (the daemon). Which logging domain should they use?
Set the G_LOG_DOMAIN to "nm" everywhere. But no longer do it via `-D`
arguments to the compiler.
See-also: https://developer.gnome.org/glib/stable/glib-Message-Logging.html#G-LOG-DOMAIN:CAPS
"libnm-core/" is rather complicated. It provides a static library that
is linked into libnm.so and NetworkManager. It also contains public
headers (like "nm-setting.h") which are part of public libnm API.
Then we have helper libraries ("libnm-core/nm-libnm-core-*/") which
only rely on public API of libnm-core, but are themself static
libraries that can be used by anybody who uses libnm-core. And
"libnm-core/nm-libnm-core-intern" is used by libnm-core itself.
Move "libnm-core/" to "src/". But also split it in different
directories so that they have a clearer purpose.
The goal is to have a flat directory hierarchy. The "src/libnm-core*/"
directories correspond to the different modules (static libraries and set
of headers that we have). We have different kinds of such modules because
of how we combine various code together. The directory layout now reflects
this.
Before there was a licensing conflict between the keyfile code
(libnm-keyfile) and libnm. The latter would require LGPL-2.1+ while
keyfile code was GPL-2.0+.
Consequently we were linking libnm-keyfile into the daemon, but not in
libnm.so.
This conflict has been resolved and keyfile API is part of libnm.so.
There is no more need to build a separate (intermediary) library. Merge
them.
This also makes sense because keyfile code needs access to private code
from libnm-core. It is closely tied to libnm-core, so that building them
separate makes no sense (anymore).
"shared/nm-meta-setting.[hc]" contains meta data about settings.
As such it is similarly used by libnm-core (as internal API) and
by clients (as extension of public API of libnm). However, it must
be compiled twice, because while it defines in both cases a
NMMetaSettingInfo type, these types are different between internal and
public API.
Hence, the files must also be compiled twice (and differently), once
against libnm-core and once against the client helper library.
Previously, the file was under "shared/", but there it's a bit odd
it doesn't clearly belong anywhere.
There are two goals here:
- copy the file to the two places where it is used. We also have
a "check-tree" unit test that ensures those files don't diverge in
the future.
- we no longer require CFLAGS set during built. Instead, the sources
should control the build. For that we have new (simple) headers
"nm-meta-setting-base.h" that define the right behavior for the
impl files.
There is still an ugliness (among several): the files must be named the
same for libnm-core and clients/common. Preferably, all our sources have
unique names, but that is not possible with this scheme (without
introducing other ugliness). To mitigate that, include the files only at
one exact place.
Currently "src/" mostly contains the source code of the daemon.
I say mostly, because that is not true, there are also the device,
settings, wwan, ppp plugins, the initrd generator, the pppd and dhcp
helper, and probably more.
Also we have source code under libnm-core/, libnm/, clients/, and
shared/ directories. That is all confusing.
We should have one "src" directory, that contains subdirectories. Those
subdirectories should contain individual parts (libraries or
applications), that possibly have dependencies on other subdirectories.
There should be a flat hierarchy of directories under src/, which
contains individual modules.
As the name "src/" is already taken, that prevents any sensible
restructuring of the code.
As a first step, move "src/" to "src/core/". This gives space to
reorganize the code better by moving individual components into "src/".
For inspiration, look at systemd's "src/" directory.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/743
