summaryrefslogtreecommitdiff
path: root/src/settings
Commit message (Collapse)AuthorAgeFilesLines
* settings: drop redundant check from have_connection_for_device()Thomas Haller2019-09-231-6/+0
| | | | | | have_connection_for_device() really should just call nm_device_check_connection_compatible(). Note that nm_device_check_connection_compatible() of course checks the connection type already, so this is redundant.
* settings: shortcut check for whether to create auto-default wired connectionThomas Haller2019-09-231-1/+2
| | | | | | This check is only useful for devices that implement new_default_connection. We can shortcut the possibly expensive checks like have_connection_for_device(), which need to iterate all profiles.
* core: fix wrongly generating "Wired connection 1" (auto-default) for ↵Thomas Haller2019-09-231-30/+3
| | | | | | | | | | | | | | | | | | | | | | | ethernet with MAC If a profile has only "ethernet.mac-address" set, but "connection.interface-name" not, then the previous check iface = nm_setting_connection_get_interface_name (s_con); if (!nm_streq0 (iface, nm_device_get_iface (device))) continue; would wrongly consider the profile not matching for the device. As a result, we would wrongly create a auto-default connection. Fix that. We already call nm_device_check_connection_compatible() above. That is fully suitable to compare the interface name and the MAC address. We don't need to duplicate this check (wrongly). See also commit 77d01c909470 ('settings: ignore incompatible connections when looking for existing ones') for how this code changed. https://bugzilla.redhat.com/show_bug.cgi?id=1727909
* core: extend nm_shutdown_wait_obj_*() to support notification via a GCancellableThomas Haller2019-09-222-4/+4
| | | | | | | | | | | | | | | | | | | | Now nm_shutdown_wait_obj_*() supports two styles: - NM_SHUTDOWN_WAIT_TYPE_OBJECT: this just registers a weak pointer on a source GObject. As long as the object is not destroyed (and the object is not unregistered), the shutdown gets blocked. - now new is NM_SHUTDOWN_WAIT_TYPE_CANCELLABLE: this source object is a GCancellable, and during shutdown, the system will cancel the instances to notify about the shutdown. That aside, the GCancellable is tracked exactly like a regular NM_SHUTDOWN_WAIT_TYPE_OBJECT (meaning: a weak pointer is registered and shutdown gets delayed as long as the instance lives). As the rest of the shutdown, it's not yet implemented on the shutdown-side. What is now possible is to register such cancellables, so that users can make use of this API before we fix shutdown. We cannot fix it all at the same time, so first users must be ready for this approach.
* core: add and use NM_MANAGER_GET macroThomas Haller2019-09-221-1/+1
| | | | | | | For our singleton getters we usually have such a macro. See NM_PLATFORM_GET and NM_SETTINGS_GET. Add such a macro for NMManager and use it.
* all: SPDX header conversionLubomir Rintel2019-09-1046-647/+46
| | | | | $ find * -type f |xargs perl contrib/scripts/spdx.pl $ git rm contrib/scripts/spdx.pl
* core: add audit log for the SaveHostname callBeniamino Galvani2019-09-051-12/+26
| | | | https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/260
* core: add defines for common authentication-related error messagesBeniamino Galvani2019-09-053-8/+8
| | | | | | All D-Bus method call implementations use similar error messages when authenticating requests; add defines for them to ensure the same exact message is reused.
* settings/keyfile: check whether profile can be re-read before writing to ↵Thomas Haller2019-08-271-34/+38
| | | | | | | | | | | | | | | | | | | | | | | | disk and fail First of all, keyfile writer (and reader) are supposed to be able to store every profile to disk and re-read a valid profile back. Note that the profile might be modified in the process, for example, blob certificates are written to a file. So, the result might no be exactly the same, but it must still be valid (and should only diverge in expected ways from the original, like mangled certificates). Previously, we would re-read the profile after writing to disk. If that failed, we would only fail an assertion but otherwise proceeed. It is a bug after all. However, it's bad to check only after writing to file, because it results in a unreadable profile on disk, and in the first moment it appears that noting went wrong. Instead, we should fail early. Note that nms_keyfile_reader_from_keyfile() must entirely operate on the in-memory representation of the keyfile. It must not actually access any files on disk. Hence, moving this check before writing the profile must work. Otherwise, that would be a separate bug. Actually, keyfile reader and writer violate this. I added FIXME comments for that. But it doesn't interfere with this patch.
* settings/keyfile: log reason why re-read connection cannot be normalizedThomas Haller2019-08-271-2/+3
| | | | It's a bug either way, but let's log what exactly went wrong.
* wifi: support WPA2 ad-hoc (ibss-rsn)Beniamino Galvani2019-08-263-23/+9
| | | | | | | | If the device supports it, allow usage of WPA2 in ad-hoc networks. Based-on-patch-by: Nicolas Cavallari <cavallar@lri.fr> https://gitlab.freedesktop.org/NetworkManager/NetworkManager/issues/184
* wifi: drop support for wpa-none key-mgmtBeniamino Galvani2019-08-264-17/+4
| | | | | | | | NM didn't support wpa-none for years because kernel drivers used to be broken. Note that it wasn't even possible to *add* a connection with wpa-none because it was rejected in nm_settings_add_connection_dbus(). Given that wpa-none is also deprecated in wpa_supplicant and is considered insecure, drop altogether any reference to it.
* ifupdown: fix crash loading ifupdown settings with empty entries like ↵Thomas Haller2019-08-241-0/+2
| | | | | | | | bridge-ports and mappings Fixes: d35d3c468a30 ('settings: rework tracking settings connections and settings plugins') https://gitlab.freedesktop.org/NetworkManager/NetworkManager/issues/235
* ifupdown/tests: add test with duplicate interfacesThomas Haller2019-08-242-0/+33
| | | | | | | | | | This file causes a crash [1], add it to the tests. Note that the test only check parsing the file and the crash happens in the "upper" layers. So, it's not really a test for the crash. But at least have such a file in our repository. [1] https://gitlab.freedesktop.org/NetworkManager/NetworkManager/issues/235
* ifupdown/tests: cleanup tests by freeing Expected variable with nm_auto()Thomas Haller2019-08-241-45/+21
|
* all: allow configuring default-routes as manual, static routesThomas Haller2019-08-132-15/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Up until now, a default-route (with prefix length zero) could not be configured directly. The user could only set ipv4.gateway, ipv4.never-default, ipv4.route-metric and ipv4.route-table to influence the setting of the default-route (respectively for IPv6). That is a problematic limitation. For one, whether a route has prefix length zero or non-zero does not make a fundamental difference. Also, it makes it impossible to configure all the routing attributes that one can configure otherwise for static routes. For example, the default-route could not be configured as "onlink", could not have a special MTU, nor could it be placed in a dedicated routing table. Fix that by lifting the restriction. Note that "ipv4.never-default" does not apply to /0 manual routes. Likewise, the previous manners of configuring default-routes ("ipv4.gateway") don't conflict with manual default-routes. Server-side this all the pieces are already in place to accept a default-route as static routes. This was done by earlier commits like 5c299454b49b ('core: rework tracking of gateway/default-route in ip-config'). A long time ago, NMIPRoute would assert that the prefix length is positive. That was relaxed by commit a2e93f2de4ac ('libnm: allow zero prefix length for NMIPRoute'), already before 1.0.0. Using libnm from before 1.0.0 would result in assertion failures. Note that the default-route-metric-penalty based on connectivity checking applies to all /0 routes, even these static routes. Be they added due to DHCP, "ipv4.gateway", "ipv4.routes" or "wireguard.peer-routes". I wonder whether doing that unconditionally is desirable, and maybe there should be a way to opt-out/opt-in for the entire profile or even per-routes. https://bugzilla.redhat.com/show_bug.cgi?id=1714438
* settings: return errno from nms_keyfile_nmmeta_write() for better loggingth/settings-improvementsThomas Haller2019-08-084-34/+42
| | | | | | | | | | | | I encountered a failure in the log <trace> [1564647990.7822] keyfile: commit: deleting nmmeta file "/etc/NetworkManager/system-connections/35370b0b-e53b-42ea-9fe3-f1b1d552343b.nmmeta" failed <trace> [1564647990.7822] keyfile: commit: deleting nmmeta file "/etc/NetworkManager/system-connections/35370b0b-e53b-42ea-9fe3-f1b1d552343b.nmmeta" simulated I think that was due to SELinux (rh #1738010). Let nms_keyfile_nmmeta_write() return an errno code so we can log more information about the failure.
* shared,all: return boolean success from nm_utils_file_get_contents()Thomas Haller2019-08-084-18/+33
| | | | | | | | | | | | | | | | | | | | | | ... and nm_utils_fd_get_contents() and nm_utils_file_set_contents(). Don't mix negative errno return value with a GError output. Instead, return a boolean result indicating success or failure. Also, optionally - output GError - set out_errsv to the positive errno (or 0 on success) Obviously, the return value and the output arguments (contents, length, out_errsv, error) must all agree in their success/failure result. That means, you may check any of the return value, out_errsv, error, and contents to reliably detect failure or success. Also note that out_errsv gives the positive(!) errno. But you probably shouldn't care about the distinction and use nm_errno_native() either way to normalize the value.
* shared: let nm_utils_file_set_contents() return a errno error codeThomas Haller2019-08-083-8/+8
| | | | | | | | | | | | | | | | nm_utils_file_set_contents() is a re-implementation of g_file_set_contents(), as such it returned merely a boolean success value. It's sometimes interesting to get the native error code. Let the function deviate from glib's original g_file_set_contents() and return the error code (as negative value) instead. This requires all callers to change. Also, it's potentially a dangerous change, as this is easy to miss. Note that nm_utils_file_get_contents() also returns an errno, and already deviates from g_file_get_contents() in the same way. This patch resolves at least the inconsistency with nm_utils_file_get_contents().
* secret-agent: rework secret-agent to better handle service shutdownThomas Haller2019-08-083-313/+351
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The secret-agent D-Bus API knows 4 methods: GetSecrets, SaveSecrets, DeleteSecrets and CancelGetSecrets. When we cancel a GetSecrets request, we must issue another CancelGetSecrets to tell the agent that the request was aborted. This is also true during shutdown. Well, technically, during shutdown we anyway drop off the bus and it woudn't matter. In practice, I think we should get this right and always cancel properly. To better handle shutdown change the following: - each request now takes a reference on NMSecretAgent. That means, as long as there are pending requests, the instance stays alive. The way to get this right during shutdown, is that NMSecretAgent registers itself via nm_shutdown_wait_obj_register() and NetworkManager is supposed to keep running as long as requests are keeping the instance alive. - now, the 3 regular methods are cancellable (which means: we are no longer interested in the result). CancelGetSecrets is not cancellable, but it has a short timeout NM_SHUTDOWN_TIMEOUT_MS to handle this. We anyway don't really care about the result, aside logging and to be sure that the request fully completed. - this means, a request (NMSecretAgentCallId) can now immediately be cancelled and destroyed, both when the request returns and when the caller cancels it. The exception is GetSecrets which keeps the request alive while waiting for CancelGetSecrets. But this is easily handled by unlinking the call-id and pass it on to the CancelGetSecrets callback. Previously, the NMSecretAgentCallId was only destroyed when the D-Bus call returns, even if it was cancelled earlier. That's unnecessary complicated. - previously, D-Bus requests SaveSecrets and DeleteSecrets were not cancellable. That is a problem. We need to be able to cancel them in order to shutdown in time. - use GDBusConnection instead of GDBusProxy. As most of the time, GDBusProxy provides features we don't use. - again, don't log direct pointer values, but obfuscate the indentifiers.
* secret-agent: use NMCListElem to track permissions in NMSecretAgentThomas Haller2019-08-081-30/+17
| | | | I don't like GSList.
* secret-agent/trivial: rename dbus_connection field of NMSecretAgentPrivateThomas Haller2019-08-081-11/+11
|
* secret-agent: avoid log plain pointer valuesThomas Haller2019-08-081-9/+23
| | | | This defeats ASLR. Obfuscate the pointers.
* secret-agent: drop unused private-socket code from secret-agentThomas Haller2019-08-081-57/+26
| | | | | | | | | | In the past, we had a private unix socket. That is long gone. Drop the remains in "nm-secret-agent.c". The request here really always comes from the main D-Bus connection. Maybe the private unix socket makes sense and we might resurrect it one day. But at that point it would be an entire rewrite and the existing code is probably not useful either way. Drop it.
* secret-agent: enable trace log messagesThomas Haller2019-08-081-5/+5
| | | | They seem useful for debugging. Don't only enable them --with-more-logging.
* ifupdown: fix assertion during logging %NULL storage in load_eni_ifaces()Thomas Haller2019-08-061-1/+1
| | | | (cherry picked from commit ddb08e3602607a5e137c05c4da25e2b4ab4166dd)
* settings: fix memory leakBeniamino Galvani2019-08-051-2/+2
| | | | | Fixes: d35d3c468a304c3e0e78b4b068d105b1d753876c (cherry picked from commit 956ffb7e9602f7d53e5eb693d1b0155913de45bc)
* settings: fix registering AgentManager.RegisterWithCapabilities() twiceThomas Haller2019-08-031-10/+0
| | | | | Fixes: 297d4985abcc7b571b8c090ee90622357fc60e16 (cherry picked from commit 1634fff1adf71b01e494056669d150fde96018f4)
* core: fix coverity warning about memset() non-char value in assertionThomas Haller2019-08-021-1/+1
| | | | | | | CID 202432 (#1 of 1): Memset fill truncated (NO_EFFECT) bad_memset: Argument -559030611 in memset loses precision in memset(priv->connections_cached_list, -559030611, 8UL * (priv->connections_len + 1U)). (cherry picked from commit 026739eb9faf45ade38cf450430c26d638445453)
* ifcfg-rh: drop g_assert_not_reached() that clearly cannot be reachedThomas Haller2019-08-021-3/+3
| | | | | | Use nm_assert() which is disabled in production builds. (cherry picked from commit 43575513ca91993c5a5995d492361c477b05a99d)
* ifcfg-rh: drop unreachable code in make_wpa_setting()Thomas Haller2019-08-021-6/+7
| | | | | | | | | This triggers a coverity warning because we above already check that not all relevant keys are NULL together. Work around warning by modifying the code. (cherry picked from commit 210d7eb5282ca7c21d5d1fd5b10ee37d297fddf2)
* settings: fix priority for settings-storages for tombstonesth/settings-shadowed-storageThomas Haller2019-07-251-13/+72
| | | | | | | | | | | | | | | | Tombstones in /etc are not only to hide storages of type keyfile. They are for hiding/shadowing any profile from persistant storage. That's why we need to compare them already in _sett_conn_entry_sds_update(). Fix the prioriy of storages for the same UUID. Note that the "$UUID.nmmeta" files (the tombstones) are handled by keyfile plugin. But that is only to load them together during `nmcli connection reload` when we iterate the files of the system-connections directory. For the most part, nmmeta/tombstones are not keyfile specific and handled by NMSettings. A tombstone in /run hides any profile (regardless of the settings plugin). And a tombstones in /etc hides any profile, except in-memory connections from keyfile /run directory.
* settings: no longer honor read-only flag to prevent modifying connection ↵Thomas Haller2019-07-252-42/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | profiles Note that we now support keyfiles from read-only storage in /usr/lib. Note also that we do support modifying and deleting these profiles. That works by placing a shadowing profile to /etc or /run. Surely this is questionable. It means that once the user uses D-Bus to modify/delete a profile in /usr/lib, that profile becomes forever shadowed by a different file, and there is no D-Bus API to return to the original file. The user would have to drop the shadowing storages from the file system. That is a problem. But on the other hand, disallowing changes to such read-only profiles is not very useful either. If you no longer can use D-Bus to modify such profiles, what's the value here? How are applications supposed to handle such profiles if there is no D-Bus API to do something sensible to them? So, whatever problems read-only profiles and this shadowing causes, I don't think that the solution is to entirely disallow changes via D-Bus. At that point, we can just as well allow changes to profiles from ifupdown. Note that you still cannot modify the profile directly (as the ifupdown plugin does not support that). But you can delete the profile (either temporarily via a tombstone in /run or permanently via a tombstone in /etc). You also can make the profile in-memory, and take it from there. Note that if you try to later store the in-memory profile to disk again, then it depends on the order of settings plugins whether that succeeds. If you have "plugins=keyfile,ifupdown", then the profile will be stored as keyfile to /etc. If you have "plugins=ifupdown,keyfile", then the modification will only be done in /run and the "to-disk" command silently ignored (there really is no better solution).
* settings: track profiles on disk that are shadowed by in-memory connectionsThomas Haller2019-07-253-182/+444
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Via Update2() D-Bus API there are three ways how a profile can be stored (or migrated) to in-memory: - NM_SETTINGS_UPDATE2_FLAG_IN_MEMORY - NM_SETTINGS_UPDATE2_FLAG_IN_MEMORY_DETACHED - NM_SETTINGS_UPDATE2_FLAG_IN_MEMORY_ONLY With the recent rework of settings I dropped NM_SETTINGS_UPDATE2_FLAG_IN_MEMORY and it had the same meaning as NM_SETTINGS_UPDATE2_FLAG_IN_MEMORY_DETACHED. However, the way NM_SETTINGS_UPDATE2_FLAG_IN_MEMORY_DETACHED was implemented is problematic. The problem is that it leaves the profile on disk but creates an in-memory representation which shadows the persistent storage. Later, when storing the profile to disk again, a new filename is chosen. This allows via D-Bus API to toggle between NM_SETTINGS_UPDATE2_FLAG_IN_MEMORY_DETACHED and NM_SETTINGS_UPDATE2_FLAG_TO_DISK, and thereby pilling up profiles on disk. Also, there is no D-Bus API to do anything sensible with these leaked, shadowed profiles on disk. Note that if we have a read-only profile in /usr/lib or in ifupdown plugin, then the problem is not made any worse. That is, because via D-Bus API such profiles can be made in-memory, and afterwards stored to /etc. Thereby too the profile gets duplicate on disk, but this game only works once. Afterwards, you cannot repeat it to create additional profiles on disk. It means, you can only leak profiles once, and only if they already exist in read-only storage to begin with. This problem with NM_SETTINGS_UPDATE2_FLAG_IN_MEMORY_DETACHED already existed before the settings-delegate-storage rework, and is unrelated to whether in-memory profiles now happen to be persisted to /run. Note that NM_SETTINGS_UPDATE2_FLAG_IN_MEMORY_ONLY is simple and does not suffer from this problem. When you move a profile to in-memory-only, it gets deleted from persistent storage and no duplication happens. The problem is that NM_SETTINGS_UPDATE2_FLAG_IN_MEMORY_DETACHED used to forget about the profile that it shadows, and that is wrong. So, first re-add proper support for NM_SETTINGS_UPDATE2_FLAG_IN_MEMORY. This works by remembering the "shadowed-storage" path for in-memory profiles. When later saving such a profile to disk again, the shadowed-storage will be re-used. Likewise, when deleting such a profile, the shadowed storage will be deleted. Note that we keep NM_SETTINGS_UPDATE2_FLAG_IN_MEMORY_DETACHED and it also remembers the shadowed storage (but without "owning" it). That means, when such a profile gets saved to disk again, the orginal storage is reused too. As such, during future updates it behaves just like NM_SETTINGS_UPDATE2_FLAG_IN_MEMORY. The difference is when deleting such a profile. In this case, the profile is left on storage and a tombstone gets written. So, how is this better than before and why even keep this complicated flag? First, we keep this flag because we really want the ansible role to be able to do in-memory changes only. That implies being able to delete a profile from NetworkManager's view, but not from persistent storage. Without this flag there is no way to do that. You can only modify an on-disk profile by shadowing it, but you could not delete it form NetworkManager's view while keeping it on disk. The new form of NM_SETTINGS_UPDATE2_FLAG_IN_MEMORY_DETACHED is safe and avoids the duplication problem because also for tombstones it remembers the original "shadowed-storage". That is, when the profile gets recreated later via D-Bus API AddConnection, then the re-created profile will still reference and reuse the shadowed storage that it had before deletion.
* settings: avoid adding a profile that would be hidden by an existing profileThomas Haller2019-07-251-2/+102
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Say, you configure "plugins=ifcfg-rh,keyfile" and have an ifcfg file for a certain profile. Then you make it IN-MEMORY-DETACHED and delete it. The result is that the ifcfg file still exists, but there is a tombstone nmmeta file that shadows the profile. Now, if you want to re-add the same profile (same UUID) and store it to persistent storage, then first it will try to persist the profile via the ifcfg-rh plugin. That may not be possible, for example because the connection type is not supported by the plugin. Now, you could write it to /etc as keyfile, but then there would still be a higher priority profile. Note that after calling _add_connection_to_first_plugin() we issue _connection_changed_track (self, new_storage, new_connection, TRUE); (note the prioritize=TRUE parameter). So, in the first moment, all looks good. However it is not because upon first reload the change gets reverted and the other profile resurfaces. The problem are that all settings plugins (except keyfile) may be completely unable to persist a profile. The real and only solution is not to use any settings plugins except keyfile. In a previous version (that never was merged), the "loaded-path" of nmmeta files was used to prioritize profiles. Since that was not done, we should not add profiles that we know have lower priority than existing profiles.
* settings: log information about shadowed-storage for change eventsThomas Haller2019-07-251-13/+14
|
* settings: refactor call to nm_settings_plugin_update_connection() in ↵Thomas Haller2019-07-251-36/+61
| | | | | | | | "nm-settings.c" The function will be re-used later, because also during "add-connection" we might need to update an existing storage instead of creating a new one.
* settings: minor refactoring handling NMSettingsUpdate2Flags in ↵Thomas Haller2019-07-251-9/+13
| | | | "nm-settings-connection.c"
* settings: support storing "shadowed-storage" to .nmmeta filesThomas Haller2019-07-258-37/+137
| | | | | | | | | | | | | | | | | | | | | | | | | Before, the .nmmeta file could only contain one piece of information: the loaded-path. This was persisted to disk by writing a "$UUID.nmmeta" symlink that links to the loaded-path. Also, in practice this is used for tombstones, so the only valid loaded-path is "/dev/null" (all other paths are ignored). Extend the .nmmeta file format to also be able to store additional data: the shadowed-storage path. We will need that later but the idea is that if we have a tombstone on disk, then this tombstone might explicitly shadow another file. The use is when re-adding a profile with the same UUID, then the existing storage is used (instead of creating a new file). This will be necessary with Update2(NM_SETTINGS_UPDATE2_FLAG_IN_MEMORY_DETACHED) flag. This flag first allows to clone a profile from persistent storage to a profile in /run. Later, when this profile gets deleted, the original profile will be left on disk. If the same profile then gets re-created with AddConnection(), then the original filename must be taken over again. This is to avoid duplication of profiles on disk. Note that this piece of information is relevent per-UUID, and as such it's correct to store it in the .nmmeta file. That is related to the "shadowed-storage" information that we store in the [.nmmeta] section of keyfiles.
* settings: support storing "shadowed-storage" to [.nmmeta] section for ↵Thomas Haller2019-07-2510-12/+191
| | | | | | | | | | | | | | | | | | keyfiles in /run When we make runtime only changes, we may leave the profile in persistent storage and store a overlay profile in /run. However, in various cases we need to remember the original path. Add code to store and retrieve that path from the keyfile. Note that this data is written inside the keyfile in /run. That is because this piece of information really depends on that particular keyfile, and not on the profile/UUID. That is why we write it to the [.nmmeta] section of the keyfile and not to the .nmmeta file (which is per-UUID). This patch only adds the backend to write and load the setting from disk. It's not yet used.
* settings: refactor handling of storages with meta-data/tombstonesThomas Haller2019-07-254-120/+195
| | | | | | | | | | | Currently, meta-data has a very narrow use: as tombstones. Later, we will need to store additional per UUID meta-data. For example, when a profile becomes unsaved, we may need to remember the original filename. Refactor the code for that. This is for the most part just renaming and slightly different handling of the fields.
* settings/trivial: rename NMS_KEYFILE_FILETYPE_NMLOADED to ↵Thomas Haller2019-07-252-4/+4
| | | | | | NMS_KEYFILE_FILETYPE_NMMETA This name is better suited for the file with extension ".nmmeta".
* settings/trivial: rename NM_SETTINGS_CONNECTION_PERSIST_MODE_DISK to ↵Thomas Haller2019-07-253-9/+9
| | | | | | | NM_SETTINGS_CONNECTION_PERSIST_MODE_TO_DISK NM_SETTINGS_CONNECTION_PERSIST_MODE_DISK really directly corresponds to NM_SETTINGS_UPDATE2_FLAG_TO_DISK. Rename, so that this is better reflected.
* core,libnm: add AddConnection2() D-Bus API to block autoconnect from the startThomas Haller2019-07-254-22/+144
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It should be possible to add a profile with autoconnect blocked form the start. Update2() has a %NM_SETTINGS_UPDATE2_FLAG_BLOCK_AUTOCONNECT flag to block autoconnect, and so we need something similar when adding a connection. As the existing AddConnection() and AddConnectionUnsaved() API is not extensible, add AddConnection2() that has flags and room for additional arguments. Then add and implement the new flag %NM_SETTINGS_ADD_CONNECTION2_FLAG_BLOCK_AUTOCONNECT for AddConnection2(). Note that libnm's nm_client_add_connection2() API can completely replace the existing nm_client_add_connection_async() call. In particular, it will automatically prefer to call the D-Bus methods AddConnection() and AddConnectionUnsaved(), in order to work with server versions older than 1.20. The purpose of this is that when upgrading the package, the running NetworkManager might still be older than the installed libnm. Anyway, so since nm_client_add_connection2_finish() also has a result output, the caller needs to decide whether he cares about that result. Hence it has an argument ignore_out_result, which allows to fallback to the old API. One might argue that a caller who doesn't care about the output results while still wanting to be backward compatible, should itself choose to call nm_client_add_connection_async() or nm_client_add_connection2(). But instead, it's more convenient if the new function can fully replace the old one, so that the caller does not need to switch which start/finish method to call. https://bugzilla.redhat.com/show_bug.cgi?id=1677068
* settings: add NM_SETTINGS_UPDATE2_FLAG_NO_REAPPLY to prevent runtime changes ↵Thomas Haller2019-07-252-5/+11
| | | | | | | | | | | | | | | | | | | | when updating connection profile When modifying a connection profile that happens to be active on a device, then most of the changes don't take effect immediately. Only after a full re-activation or reapply (nmcli device reapply) does the configuration of the active device change (the "applied-connection"). With two execptions: "connection.zone" and "connection.metered" take effect immediately. I think this is historic, but also to facilitate firewall-cmd to modify a profile and change the zone right away. Anyway, I think it should be possible to modify a profile without changes to the runtime. Add a flag to prevent reapplying these properties right away. https://bugzilla.redhat.com/show_bug.cgi?id=1677070
* device: move check for no-auto-default to "nm-settings.c"Thomas Haller2019-07-251-1/+5
| | | | | | | | | | | | | nm_config_set_no_auto_default_for_device() is called by NMSettings, so it makes sense that also NMSettings checks whether the device is blocked. Of course, there is little difference in practice. The only downside is that most device types don't implement new_default_connection(). So the previous form performed the cheaper check first. On the other hand, we do expect to have profiles for the devices anyway.
* ifcfg-rh: don't allow globbing for unhandled device specsThomas Haller2019-07-252-2/+2
| | | | | | | | | | With plain "interface-name:$IFNAME" globbing is enabled. So this behaves wrong if there are special characters like '*' or '?'. Also, it behaves wrong if the first character of the interface name happens to be '='. Make an explicit match.
* core: add and use NM_MATCH_SPEC_*_TAG defines instead of plain stringsThomas Haller2019-07-252-4/+5
| | | | | | The define is better, because then we can grep for all the occurances where they are used. The plain text like "mac:" is not at all unique in our source-tree.
* settings: add more trace logging for auto-default (default wired) connectionsThomas Haller2019-07-171-0/+11
| | | | | Automatically creating profiles is suprising. Add more logging to understand what's happening.
* settings: write tombstones when deleting connection with duplicate files on diskThomas Haller2019-07-171-4/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Create such duplicate files: UUID=0df1bac3-1131-42d4-8893-4492d5424d11 rm -f /etc/NetworkManager/system-connections/x[12] rm -f /{etc,run}/NetworkManager/system-connections/"$UUID".nmmeta printf -v C "[connection]\nuuid=$UUID\ntype=ethernet\nautoconnect=false" echo "$C" > /etc/NetworkManager/system-connections/x1 echo "$C" > /etc/NetworkManager/system-connections/x2 chmod 600 /etc/NetworkManager/system-connections/x[12] touch /etc/NetworkManager/system-connections/x2 ls -l --full-time /etc/NetworkManager/system-connections/x[12] /{etc,run}/NetworkManager/system-connections/"$UUID".nmmeta 2>/dev/null nmcli connection reload nmcli -f all connection show | grep $UUID Now, we have x2 file loaded, and x1 is shadowed. When we delete x2, we probably don't want to delete the hidden x1 file. What previously happend was that when calling nmcli connection delete $UUID the command would hang because the profile wasn't really deleted: <trace> [1563355597.3671] keyfile: commit: deleted "/etc/NetworkManager/system-connections/x2", profile 0df1bac3-1131-42d4-8893-4492d5424d11 (deleted from disk) <trace> [1563355597.3672] settings: storage[0df1bac3-1131-42d4-8893-4492d5424d11,91e13003dd84928f/keyfile]: change event for dropping profile (file "/etc/NetworkManager/system-connections/x2") <trace> [1563355597.3672] settings: update[0df1bac3-1131-42d4-8893-4492d5424d11]: updating connection "x1" (2b798d30d43b0daf/keyfile) <debug> [1563355597.3674] ++ connection 'update connection' (0x55a167693ee0/NMSimpleConnection/"802-3-ethernet" < 0x55a16762e580/NMSimpleConnection/"802-3-ethernet") [/org/freedesktop/NetworkManager/Settings/41]: <debug> [1563355597.3675] ++ connection [ 0x55a16782a400 < 0x55a16762c350 ] <debug> [1563355597.3675] ++ connection.id = 'x1' < 'x2' <info> [1563355597.3680] audit: op="connection-delete" uuid="0df1bac3-1131-42d4-8893-4492d5424d11" name="x1" pid=32077 uid=0 result="success" instead, we need to write a tombstone: <trace> [1563359300.2910] keyfile: commit: deleted "/etc/NetworkManager/system-connections/x2", profile 0df1bac3-1131-42d4-8893-4492d5424d11 (deleted from disk) <trace> [1563359300.2911] settings: storage[0df1bac3-1131-42d4-8893-4492d5424d11,0c12620295ac7f83/keyfile]: change event for dropping profile (file "/etc/NetworkManager/system-connections/> <trace> [1563359300.2912] keyfile: commit: writing nmmeta symlink "/etc/NetworkManager/system-connections/0df1bac3-1131-42d4-8893-4492d5424d11.nmmeta" (pointing to "/dev/null") succeeded <trace> [1563359300.2912] settings: storage[0df1bac3-1131-42d4-8893-4492d5424d11,02a430e6ee52358d/keyfile]: change event for hiding profile (file "/etc/NetworkManager/system-connections/0d> <trace> [1563359300.2912] settings: update[0df1bac3-1131-42d4-8893-4492d5424d11]: delete connection "x2" (02a430e6ee52358d/keyfile) <debug> [1563359300.2914] Deleting secrets for connection /org/freedesktop/NetworkManager/Settings (x2) <trace> [1563359300.2915] dbus-object[13d79ec95177f9eb]: unexport: "/org/freedesktop/NetworkManager/Settings/54" <trace> [1563359300.2916] settings-connection[13d79ec95177f9eb,0df1bac3-1131-42d4-8893-4492d5424d11]: update settings-connection flags to none (was visible) <info> [1563359300.2917] audit: op="connection-delete" uuid="0df1bac3-1131-42d4-8893-4492d5424d11" name="x2" pid=22572 uid=0 result="success" <debug> [1563359300.2918] settings-connection[13d79ec95177f9eb,0df1bac3-1131-42d4-8893-4492d5424d11]: disposing and of course after a `nmcli connection reload` the profile stays hidden: <trace> [1563359412.0355] settings: storage[0df1bac3-1131-42d4-8893-4492d5424d11,e45535721abb092a/keyfile]: change event with connection "x1" (file "/etc/NetworkManager/system-connections/x1") <trace> [1563359412.0355] settings: storage[0df1bac3-1131-42d4-8893-4492d5424d11,02a430e6ee52358d/keyfile]: change event for hiding profile (file "/etc/NetworkManager/system-connections/0df1bac3-1131-42d4-8893-4492d5424d11.nmmeta")
View Lorry Controller Status