build_message() is an internal helper function with a very specific
purpose.
Let's change it to take an NMStrBuf argument for generating
the string. The advantage is that we don't need to allocate and
free the buffers in between, but can just reuse it.
When using a GValue, we really should call g_value_unset(). Otherwise
it is a code smell, even if we technically only created GValue with
static strings and integers.
But changing that is not easy, because the AuditField structs are
allocated on the stack, and in different functions. So we cannot just
pass a GDestroyNotify to GPtrArray to cleanup all those fields, because
by then they will be out of scope.
The proper solution would be to heap allocate the AuditField struct, add
them to the GPtrArray, and free them with the free function. But that
seams really unnecessary overhead, for something that is correct in
practice. Let's accept the fact that by the time the fields array gets
destroyed, it contains dangling pointers.
If we already embrace the dangling pointers and that stuff is allocated
on the stack and that we don't need to free, also get rid of GValue
and use our plain NMValueType and NMValueTypUnion. GValue really doesn't
give us much here. And it only makes us wonder: is it OK to not call
g_value_unset()? With the plain tracking of the values, we know that
it is OK.
_nm_log_impl() is the underlying implementation. As we have
multiple implementations, it's a bit confusing how it all works
together.
We thus should not call this directly, so that there are few (literal)
uses of this symbol.
Still, we may need to call this version of the logging statement,
because it's the only one that allows to provide the file location.
Add a wrapper macro for this, that callers can use.
$ make src/libnm-systemd-shared/src/fundamental/libnm_systemd_shared_la-string-util-fundamental.lo
CC src/libnm-systemd-shared/src/fundamental/libnm_systemd_shared_la-string-util-fundamental.lo
In file included from ./src/libnm-glib-aux/nm-default-glib.h:11,
from ./src/libnm-systemd-shared/nm-default-systemd-shared.h:11,
from ./src/libnm-systemd-shared/sd-adapt-shared/nm-sd-adapt-shared.h:9,
from src/libnm-systemd-shared/src/fundamental/string-util-fundamental.c:3:
./src/libnm-std-aux/nm-default-std.h:32:10: fatal error: config-extra.h: No such file or directory
32 | #include "config-extra.h"
| ^~~~~~~~~~~~~~~~
compilation terminated.
make: *** [Makefile:15660: src/libnm-systemd-shared/src/fundamental/libnm_systemd_shared_la-string-util-fundamental.lo] Error 1
Fixes: 2a88de2280 ('systemd: merge branch systemd into master')
Previously, nmtui would set the newt color "checkbox" to a hard coded
value. This made it impossible to override the color via "$NEWT_COLORS".
With this change, nmtui also parses "$NEWT_COLORS" to allow setting
newt colors:
$ NEWT_COLORS='
window=white,red
border=white,red
checkbox=white,red
actcheckbox=white,green
' nmtui
Custom nmtui colors can now also be set via "$NMT_NEWT_COLORS":
"badLabel"
"plainLabel"
"disabledButton"
"textboxWithBackground"
For example:
$ NMT_NEWT_COLORS='plainLabel=green,lightgray' nmtui
The environment variables "$NEWT_COLORS_FILE" and "NMT_NEWT_COLORS_FILE"
are honored too.
The code is based on libnewt code ([1]), authored by Miroslav Lichvar.
That patch is originally LGPL-2.0-only licensed, but for inclusion in
NetworkManager we require it to be LGPL-2.1-or-later. Miroslav kindly
agreed to use his original contribution in NetworkManager.
[1] https://pagure.io/newt/c/34e56d12931a25222d7debb22f95bb2f9fa696a0
Signed-off-by: Miroslav Lichvar <mlichvar@redhat.com>
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/653https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/793
In many cases, macros should aim to be function-like. That is,
to evaluate all arguments and evaluate them exactly once.
Fix NM_FLAGS_ALL() to evaluate the "check" argument only once.
One downside of this change is that the result is no longer a compile
time constance and cannot be used to initialize static variables. But
that isn't used much anyway.
The "_lst" suffix already indicates that this is a list. We have
a list of ip-configs, so the prefix should be singular. It also matches
the "NMDnsConfigIPData.ip_config_lst" field.
The main reason for this renaming is that I want to search the file
for /ip_config_lst/ and find both the list head and the list elements.
Better fix for https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/732
The original issue was that when compiling NetworkManager with slibtool
the create-exports-NetworkManager.sh script gave the NetworkManager-all-sym
slibtool wrapper script to nm(1) instead of the actual binary. This is
because slibtool and GNU libtool do not place the compiled programs in
the same location. The original fix was to test both locations, but this
is bit of a hack especially since the build system should not be using the
.libs directory directly. However with $(LIBTOOL) --mode=execute this is
not a problem since both implementations can figure out where the correct
binary is.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/805
- add more error handling and free/unref data.
- split code in 3 functions: vpn_connection_import(),
connection_add() and main(). These steps are mostly
independent, and having them in separate functions
makes their separation clearer.
- handle error from nm_client_add_connection_async() to
exit program with non zero exit code.
Review and replace usages of the two nm_connection_to_dbus() flags
marked deprecated in commit 84648e562c98 ('libnm: Refactor
NM_CONNECTION_SERIALIZE_* flags'):
NM_CONNECTION_SERIALIZE_NO_SECRETS and
NM_CONNECTION_SERIALIZE_ONLY_SECRETS.
Use the new nm_connection_to_dbus() flags to filter secrets instead of
cloning connections and using
_nm_connection_clear_secrets_by_secret_flags() and then serializing all
secrets in NMSettingsConnection. Fix a related comment.
nm-settings-connection.c has code similar to this in two places:
/* FIXME: improve NMConnection API so we can avoid the overhead of cloning the connection,
* in particular if there are no secrets to begin with. */
connection_cloned = nm_simple_connection_new_clone(new);
/* Clear out unwanted secrets */
_nm_connection_clear_secrets_by_secret_flags(connection_cloned,
NM_SETTING_SECRET_FLAG_NOT_SAVED
| NM_SETTING_SECRET_FLAG_AGENT_OWNED);
secrets = nm_g_variant_ref_sink(
nm_connection_to_dbus(connection_cloned, NM_CONNECTION_SERIALIZE_ONLY_SECRETS));
It seems the secrets filtering can be done by nm_connection_to_dbus() if
the NM_CONNECTION_SERIALIZE_* flags are extended. The current set of
flags contains flags that start with NO, ONLY and WITH prefixes, which
makes it useless for combining the flags because most combinations of
more than one flag don't have a clear interpretation. So they're mostly
useful when used alone, i.e. you'd need to add a new enum value for
each new subset of settings to be serialized.
To get the most flexibility from a small set of flags they should
either all be of the WITH_* type or NO_* type. In the former case they
could be combined to extend the subset of properties serialized, in the
latter case each flag would reduce the subset. After trying both
options I found it's easier to adapt the current set of flags to the
WITH_* schema while keeping binary and source compatibility. This
commit changes the set of flags in the following way:
NM_CONNECTION_SERIALIZE_ALL is kept for compatibility but is equivalent
to a combination of other flags.
NM_CONNECTION_SERIALIZE_WITH_NON_SECRET is added with the same value as
NM_CONNECTION_SERIALIZE_NO_SECRETS, it implies that non-secret
properties are included but doesn't prevent including other properties.
Since it couldn't be meaningfully combined with any other flag this
change shouldn't break compatibility.
Similarly NM_CONNECTION_SERIALIZE_WITH_SECRETS is added with the same
value as existing NM_CONNECTION_SERIALIZE_ONLY_SECRETS with the same
consideration about compatibility.
NM_CONNECTION_SERIALIZE_WITH_SECRETS_AGENT_OWNED and the new
NM_CONNECTION_SERIALIZE_WITH_SECRETS_SYSTEM_OWNED and
NM_CONNECTION_SERIALIZE_WITH_SECRETS_NOT_SAVED add only subsets of
secrets and can be combined. For backwards compatibility
NM_CONNECTION_SERIALIZE_ONLY_SECRETS is basically ignored when either of
these three is present, so that the value:
..ONLY_SECRETS | ..AGENT_OWNED works as previously.
This introduces no change. On systemd branch files were moved
around to follow what also happened on master. The merge commit
just makes git aware of this part of history.
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
