This drops some redundant rules and orderes the remaining ones by
precedence.
The 'root' rules take precedence over the 'default' rules, so order
the file accordingly.
It is not necessary to repeat send_destination rules, as the default
rules already allows everyone to send to the interface.
Moreover, it is not necessary to restrict the ownership of the name
in the default context, as this is already done by the system-wide
default rule.
Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
There are a lot of places where we want to either write a number,
or conditionally clear it. Like:
mtu = nm_setting_wireless_get_mtu (s_wireless);
if (mtu)
svSetValueInt64 (ifcfg, "MTU", mtu);
else
svUnsetValue (ifcfg, "MTU");
To support legacy scripts, we want to write out the NETMASK
key whenever the ifcfg file has a NETMASK key previously.
Note, that we anyway always write the relevant PREFIX key.
The NETMASK is redundant, only there to help legacy scripts.
That was broken, because we would svUnsetValue("NETMASK") before
checking whether the NETMASK key is present.
Also, when saving a connection to ifcfg-rh file that was created
by other tools, we might mix up the numbering. E.g. we never
write out IPADDR0. Hence, turn on legacy mode whenever the ifcfg-rh
file has any key starting with "NETMASK".
The user data values are encoded in shell variables named
prefix "NM_USER_". The variable name is an encoded form of the
data key, consisting only of upper-case letters, digits, and underscore.
The alternative would be something like
NM_USER_1_KEY=my.keys.1
NM_USER_1_VAL='some value'
NM_USER_2_KEY=my.other.KEY.42
NM_USER_2_VAL='other value'
contary to
NM_USER_MY__KEYS__1='some value'
NM_USER_MY__OTHER___K_E_Y__42='other value'
The advantage of the former, numbered scheme is that it may be easier to
find the key of a user-data entry. With the current implementation, the
shell script would have to decode the key, like the ifcfg-rh plugin
does.
However, user data keys are opaque identifers for values. Usually, you
are not concerned with a certain name of the key, you already know it.
Hence, you don't need to write a shell script to decode the key name,
instead, you can use it directly:
if [ -z ${NM_USER_MY__OTHER___K_E_Y__42+x} ]; then
do_something_with_key "$NM_USER_MY__OTHER___K_E_Y__42"
fi
Otherwise, you'd first have to search write a shell script to search
for the interesting key -- in this example "$NM_USER_2_KEY", before being
able to access the value "$NM_USER_2_VAL".
The PMF property is an GEnum, not GFlags. We only have the GObject
property NM_SETTING_WIRELESS_SECURITY_PMF as plain integer type
to allow for future extensions.
But commonly, enums are signed int, while flags are unsigned. Change
the property to be signed for consistency.
py-kickstart writes this out and there apparently are users using this.
Let them have one less problem.
Co-Authored-By: Thomas Haller <thaller@redhat.com>
https://bugzilla.redhat.com/show_bug.cgi?id=1445414
For example, if you want to test whether a value is present and
reset it to a different value (only if it is present), it would
be reasonable to do
if (svGetValue (s, key, &tmp)) {
svSetValue (s, key, "new-value");
g_free (tmp);
}
Without this patch, you could not be sure that key is not
set to some inparsable value, which svWriteFile() would then
write out as empty string.
Have invalid values returned by svGetValue() as empty string.
That is how svWriteFile() treats them.
We have unit tests for writing and re-reading ifcfg file. Those
tests compare whether a file can be successfully read and is
semantically identical.
However, there were no tests that a certain output is written in
a stable format. We aim not to change the output of what we write.
For that, add tests to not only check the semantic of the written
ifcfg file, but their bits and bytes.
Some future changes may well intentionally change the current
output. That will require to update the expected result files
and can be done via
NMTST_IFCFG_RH_UPDATE_EXPECTED=yes src/settings/plugins/ifcfg-rh/tests/test-ifcfg-rh
Note that alias, route, and key files are not checked.
Related: https://bugzilla.redhat.com/show_bug.cgi?id=1445414
libnm contains the public function nm_utils_enum_from_str() et al.
The function is not flexible enough for nmcli's usecase. So, I would
need another public function like nm_utils_enum_from_str_full() that
has an extended API.
That was already required previously for ifcfg-rh writer, but in that
case I could just add it as internal API as libnm-core is linked statically
with NetworkManager.
I don't want to commit to a public API for an utility function. So move
the code instead to the shared directory, so that nmcli may link
statically against it and use the internal API.
This part contains static functions and variables to describe
settings. It is distinct from the mechanism to use them, or
access them.
Split it out.
It still uses clients/cli/common.h and clients/cli/utils.h
which shall be fixed next.
In practice, this should only matter when there are multiple
header files with the same name. That is something we try
to avoid already, by giving headers a distinct name.
When building NetworkManager itself, we clearly want to use
double-quotes for including our own headers.
But we also want to do that in our public headers. For example:
./a.c
#include <stdio.h>
#include <nm-1.h>
void main() {
printf ("INCLUDED %s/nm-2.h\n", SYMB);
}
./1/nm-1.h
#include <nm-2.h>
./1/nm-2.h
#define SYMB "1"
./2/nm-2.h
#define SYMB "2"
$ cc -I./2 -I./1 ./a.c
$ ./a.out
INCLUDED 2/nm-2.h
Exceptions to this are
- headers in "shared/nm-utils" that include <NetworkManager.h>. These
headers are copied into projects and hence used like headers owned by
those projects.
- examples/C
For IPv4 we support both the legacy and the new route file format. In
the legacy format, option are appended to the "ip route" command
arguments:
203.0.113.0/24 metric 3 via 198.51.100.1 dev eth2 cwnd 14 mtu lock 1500
This is backwards compatible with initscripts. In the new format, a
OPTIONSx= variable is added to represent the options in the same
format understood by iproute2:
ADDRESS0=203.0.113.0
NETMASK0=255.255.255.0
GATEWAY0=198.51.100.1
METRIC0=3
OPTIONS0="cwnd 14 mtu lock 1500"
initscripts do not support this variable at the moment (but the
changes needed to support it are trivial).
By default the new format is used, unless the route file is already in
the legacy format.
For IPv6 only the legacy format is supported, as before.
