nm_keyfile_read() and nm_keyfile_write() will be public API.
As such, it must be flexible and extendible for future needs.
There is already the handler callback that fully solves this
(e.g. a future handler event could request whether a certain
behavior is enabled or not).
As additional possibility for future extension, add a flags
argument. Currently no flags are implemented.
For introspection/bindings it is cumbersome to access the
fields of the NMKeyfileHandlerData struct. Instead add accessor
functions.
Also, we wouldn't want to expose the struct in public API directly,
because it makes it harder to extend it without breaking ABI.
From inside a callback 4 properties are potentially interesting
to all callbacks: the currenty group, key, setting and property-name.
Refactor the code to track these properties in NMKeyfileHandlerData
and distinguish between the property name and the keyfile key.
When an error gets set, we should abort right away. We should
not come into a situation where we would try to emit another warning.
Don't check for a condition that should never happen and assert
against it.
Setting the error on the callback does not work well from bindings.
Instead, let bindings call a (future) nm_keyfile_handler_data_fail_with_error()
function on the handler_data to indicate failure.
As the keyfile handler callback will become public API, it needs to be
usable via bindings. A plain void pointer is not usable. Instead, add
a new type that can be used via introspection.
This will become public API. The enum for read and write callback
serves very similar purposes. Merge them so that we have fewer
types in the public API.
This defaults to $DO_RELEASE. In that case, the script will also GPG sign
the source tarball.
The purpose is that when we do a release we want to ensure that the
published tarball is really the one that we generated. In that case,
the SHA sum would suffice, however that requires you to manually note
it down and compare the result. With the gpg signature, that
verification can be better automated.
Currently only "minor" and "devel" releases are implement. It's also not yet
tested with --no-dry-run, because that would actually create a release.
Test it when using it the next time.
On Debian sid, libnss3-dev (2:3.53-1) causes a compiler warning:
In file included from ../libnm-core/nm-crypto-nss.c:13:
/usr/include/nss/pk11pub.h:951:1: error: function declaration isn't a prototype [-Werror=strict-prototypes]
951 | int SECMOD_GetSystemFIPSEnabled();
| ^~~
6876b73ec113 all: rework logging to append logging messages to the event queue
65ca0e4bea32 client: check length of client id for n_dhcp4_client_config_set_client_id()
6a9ca10b7ad6 client: close timer file descriptor explicitly when EPOLL_CTL_ADD fails
e5f3b27f5301 connection: don't fail dispatch in case of receive errors
68790d5ec950 connection: keep trying after a failure in send()
788b03891cd0 n-dhcp4: fix logging macro
6cd0fd5e8b3f probe: request previous address after expiration
ef11c7079ad7 connection: avoid double free of NDhcp4Outgoing
922a9a2326e7 n-dhcp4: fix initialization of the 'secs' DHCP header field
7fff54117436 outgoing: fix uninitialized variable in n_dhcp4_outgoing_append()
27547faaf258 probe: move back to INIT after lease expires
d07cb4e32884 incoming: accept options that are longer than requested
34d365e2267f client: handle invalid return codes gracefully during n_dhcp4_client_dispatch()
2e8c6017f85b n-dhcp4: use packet socket in rebinding state
9a7c82143c06 n-dhcp4: support init-reboot state
e615e3f5b063 n-dhcp4/socket: use SO_REUSEADDR on UDP socket
8dbfa1ad2549 merge branch 'bengal:log'
6e50189fba86 n-dhcp4: log outgoing packets
aea0315d3862 n-dhcp4: log incoming packets
1ca64a82393d n-dhcp4: add logging API
72c16a0028ac client-probe: fix state transitions on timer dispatch
c023ae2ad829 merge branch 'leasetime'
780f94c333ca lease: add n_dhcp4_client_lease_get_basetime()
a94378274cf4 incoming: don't handle 0xFFFFFFFF timestamps special in n_dhcp4_incoming_query_u32()
6bb277aefe0b probe: unconditionally pass ownership of message in n_dhcp4_client_probe_dispatch_io()
1cf87c90c6a1 probe: fix leaking message during client probe
55239cef2d63 lease: remove unreachable code in n_dhcp4_incoming_get_timeouts()
fa5ee7903061 lease: expose the server IP address
0cfce4a4fe07 all: merge branch 'th/build-centos76'
cae4868e5f7e all: avoid {net,linux}/if.h clashes on old distros
05859a3e4d32 all: avoid c_min() macro to work with old GCC
0be7033dd940 probe: arm timers in bound state
8735cdb0f95f ci: switch to c-util automation
a0bb7c69a11a client: fallback to CLOCK_MONOTONIC for timerfd
308cb242caf7 ci: disable valgrind run
468c93195ad3 build: update submodules
9d0f690f9ee8 ci: switch to github actions
9ba143a037bb probe: allocate memory of right size in n_dhcp4_client_probe_option_new()
2546aa2c809d util/link: suppress gcc warning
e4a01f5870a6 ci: drop broken armv7hl
2e2fbfa18f2c build: update submodules
6277dfd20eca Merge pull request #2 from NetworkManager/th/declaration-after-statement
1b660ae2d12a outgoing: avoid "-Werror=declaration-after-statement" warning with static_assert
f34a54cd9719 client/probe: fix memory leak
21e68f3bba80 client/connection: fix memory leak
git-subtree-dir: shared/n-dhcp4
git-subtree-split: 6876b73ec113328712a5cdc2ffb9497fd774c0e2
This is mostly done. What is not done is to delay the ACTIVATED state
until the connectivty check passed. Delaying that might be problematic
and should only be done as opt-in. Unclear whether that would ever be useful
though.
../src/nm-manager.c: In function periodic_update_active_connection_timestamps:
../src/nm-manager.c:7358:43: error: t may be used uninitialized in this function [-Werror=maybe-uninitialized]
nm_settings_connection_update_timestamp (nm_active_connection_get_settings_connection (ac),
^
Fixes: 6f3ae8a563 ('core: in periodic_update_active_connection_timestamps() use same timestamp')
We don't need the mask argument. If the caller wants to check only for certain
flags, she can do that right away with
NM_FLAGS_ANY (nm_settings_connection_autoconnect_blocked_reason_get (sett_con), flags)
When the secrets for a connection are updated, unblock autoconnection
in case it had been blocked previously due to bad or no
secrets. Otherwise we would need to manually activate the connection
or restart NM to get another try with the new secrets.
As commit ccfe5fec8d ('wifi: don't autoconnect to networks that have
never been successful') explains, Wi-Fi profiles only autoconnected
if they had no or a positive timestamp.
The problem that tried to solve is when a user accidentally clicks on a
Wi-Fi network in applet. Then the created profile may not be usable
(because of wrong credentials). To avoid indefinitely to autoconnect,
uch a profile will have a timestamp of 0, which prevents further
auto activations.
However, I find that problematic.
An important use case is pre-deploying profiles. In that case, the user
cannot set the timestamp, because the timestamp cache
/var/lib/NetworkManager/timestamps is internal, undocumented API. Also,
ifcfg-rh doesn't support the timestamp and anyway, does the timestamp
of the NMConnection does not get honored (only the one from the
timestamps file).
Maybe that could be an alternative solution here, to allow the user to
mark profiles as "I really want it to autoconnect". But that seems
unnecessary and wrong to me.
The problem really is that the user cannot do anything to ensure that
autoconnect will work tomorrow (short of editing the timestamps
database). The problem is that the property of whether a profile
every connected successfully is not in direct control of the user (it
depends on external conditions).
If the user has bogus profiles configured, those profiles should be
deleted (or autoconnect disabled) and not keep autoconnect blocked.
Also note that if you are at home and accidentally click on your
neighbour's Wi-Fi network, then you presumably still also have a working
profile to your own network. That usable profile will have a more
recent timestamp and be preferred during autoconnect already.
This reverts commit ccfe5fec8d.
https://bugzilla.redhat.com/show_bug.cgi?id=1781253
Updating the timestamp marks the keyfile database as dirty. Avoid
that, if there is no change. Of course, nm_key_file_db_set_value()
itself already checks whether the are any changes, and does nothing
if there aren't.
Simply perform the check earlier, to do nothing.
When performing a synchronous action together (like iterating
over all settings and set the current timestamp), it's nicer
to pretend that all this would happen instantaneously. That means,
ensure we use the same timestamp throughout.
On a minor point, there really is no need to call time() multiple times.
Code like
»···»···if (strcmp (tag, "net.ifnames") == 0)
»···»···»···net_ifnames = strcmp (argument, "0") != 0;
is really hard to understand (at least to me). Compare to
»···»···if (nm_streq (tag, "net.ifnames"))
»···»···»···net_ifnames = !nm_streq (argument, "0");
