vpn.data, bond.options, and user.data encode their values directly as
keys in keyfile. However, keys for GKeyFile may not contain characters
like '='.
We need to escape such special characters, otherwise an assertion
is hit on the server:
$ nmcli connection modify "$VPN_NAME" +vpn.data 'aa[=value'
Another example of encountering the assertion is when setting user-data key
with an invalid character "my.this=key=is=causes=a=crash".
(cherry picked from commit 8ef57d0f7e)
With commit 4f6c91d696, we aimed to
enable mac-address-randomization by default for Wi-Fi. That however
is not possible by default because it breaks various scenarios.
Also, later wifi.mac-address-randomization was deprecated in favor
of wifi.cloned-mac-address setting.
Both wifi.mac-address-randomization and wifi.cloned-mac-address support
global default values, so it is wrong to read a missing
mac-address-randomization as "NEVER" -- which due to
normalization also results in cloned-mac-address=permanent.
It's not the job of keyfile writer to enforce certain settings. A
%NULL GBytes property is shall be treated distinct from a byte array
with zero length.
The NMSetting may or may not reject such settings as invalid during
verify() or mangle them during normalize(). But reader/writer should
just serialize every property as-is.
We use write_array_of_uint() for G_TYPE_ARRAY. In practice, only
NMSettingDcb has any properties of this type.
Furthermore, all valid values are either gboolean or guints of
restricted range. Thus, no valid NMSettingDcb should violate the
range check.
Same for reader.
It's really ugly to blindly use uint-list reader for G_TYPE_ARRAY.
Especially, because certain G_TYPE_ARRAY properties of NMSettingDcb
are actually arrays of gboolean, which only ~accidentally~ has the same
memory layout as guint.
This sorts the entries of the [vpn] section alphabetically.
The sorting order doesn't really matter, but having a defined,
stable way to export a connection is preferred. Also, it looks
better when looking at the keyfile with an editor.
- All internal source files (except "examples", which are not internal)
should include "config.h" first. As also all internal source
files should include "nm-default.h", let "config.h" be included
by "nm-default.h" and include "nm-default.h" as first in every
source file.
We already wanted to include "nm-default.h" before other headers
because it might contains some fixes (like "nm-glib.h" compatibility)
that is required first.
- After including "nm-default.h", we optinally allow for including the
corresponding header file for the source file at hand. The idea
is to ensure that each header file is self contained.
- Don't include "config.h" or "nm-default.h" in any header file
(except "nm-sd-adapt.h"). Public headers anyway must not include
these headers, and internal headers are never included after
"nm-default.h", as of the first previous point.
- Include all internal headers with quotes instead of angle brackets.
In practice it doesn't matter, because in our public headers we must
include other headers with angle brackets. As we use our public
headers also to compile our interal source files, effectively the
result must be the same. Still do it for consistency.
- Except for <config.h> itself. Include it with angle brackets as suggested by
https://www.gnu.org/software/autoconf/manual/autoconf.html#Configuration-Headers
- "gsystem-local-alloc.h" and <gio/gio.h> are already included via
"nm-default.h". No need to include them separately.
- include "nm-macros-internal.h" via "nm-default.h" and drop all
explict includes.
- in the modified files, ensure that we always include "config.h"
and "nm-default.h" first. As second, include the header file
for the current source file (if applicable). Then follow external
includes and finally internal nm includes.
- include nm headers inside source code files with quotes
- internal header files don't need to include default headers.
They can savely assume that "nm-default.h" is already included
and with it glib, nm-glib.h, nm-macros-internal.h, etc.
Take a missing value in keyfile/ifcfg-rh as EUI-64 to keep the compatibility
with the old conneciton. Nevertheless, the new connections should default to
the RFC7217 addresses.
The kernel defaults REORDER_HDR to 1 when creating a new VLAN, but
NetworkManager's VLAN flags property defaulted to 0. Thus REORDER_HDR was not
set for NM-created VLANs with default values.
We want to match the kernel default, so we change the default value for the
vlan.flags property. However, we do not want to change the flags for existing
connections if the property is missing in connection files. Thus we have to
update plugins for that. We also make sure that vlan.flags is always written
by 'keyfile' when the value is default. That way new connections have flags
property explicitly written and it will be loaded as expected.
https://bugzilla.redhat.com/show_bug.cgi?id=1250225
The localization headers are now included via "nm-default.h".
Also fixes several places, where we wrongly included <glib/gi18n-lib.h>
instead of <glib/gi18n.h>. For example under "clients/" directory.
Rather than randomly including one or more of <glib.h>,
<glib-object.h>, and <gio/gio.h> everywhere (and forgetting to include
"nm-glib-compat.h" most of the time), rename nm-glib-compat.h to
nm-glib.h, include <gio/gio.h> from there, and then change all .c
files in NM to include "nm-glib.h" rather than including the glib
headers directly.
(Public headers files still have to include the real glib headers,
since nm-glib.h isn't installed...)
Also, remove glib includes from header files that are already
including a base object header file (which must itself already include
the glib headers).
keyfile should become our main import/export format. It is desirable,
that a keyfile can contain every aspect of a connection.
For blob certificates, the writer in core daemon would always write
them to a file and convert the scheme to path.
This behavior is not great for a (hyptetical) `nmcli connection export`
command because it would have to export them somehow outside of keyfile,
e.g. by writing them to temporary files.
Instead, if the write handler does not handle a certificate, use a
default implementation in nm_keyfile_write() which adds the blob inside
the keyfile.
Interestingly, keyfile reader already supported reading certificate
blobs. But this legacy format accepts the blob as arbitrary
binary without marking the format and without scheme prefix.
Instead of writing the binary data directly, write it with a new
uri scheme "data:;base64," and encode it in base64.
Also go through some lengths to make sure that whatever path
keyfile plugin writes, can be read back again. That is, because
keyfile writer preferably writes relative paths without prefix.
Add nm_keyfile_detect_unqualified_path_scheme() to encapsulate
the detection of pathnames without file:// prefix and use it to
check whether the path name must be fully qualified.
These headers are not entirely private to libnm-core as they are also
used by keyfile plugin. Merge them to a new header file
nm-keyfile-internal.h so that the name makes the internal nature of the
header more apparent.
This is the first step to move keyfile to libnm. For now, only
copy the files to make later changes nicer in git-history.
/bin/cp src/settings/plugins/keyfile/reader.c libnm-core/nm-keyfile-reader.c
/bin/cp src/settings/plugins/keyfile/reader.h libnm-core/nm-keyfile-reader.h
/bin/cp src/settings/plugins/keyfile/utils.c libnm-core/nm-keyfile-utils.c
/bin/cp src/settings/plugins/keyfile/utils.h libnm-core/nm-keyfile-utils.h
/bin/cp src/settings/plugins/keyfile/writer.c libnm-core/nm-keyfile-writer.c
/bin/cp src/settings/plugins/keyfile/writer.h libnm-core/nm-keyfile-writer.h
