summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2022-10-03all: drop nm_uuid_generate_from_strings_v3()Thomas Haller7-50/+40
For new uses of nm_uuid_generate_from_strings() we should generate version5 UUIDs and we should use unique namespace UUID arguments. The namespace UUID was so far replaced by always passing a special prefix as first string. It seems nicer to use a namespace instead. Version3 UUIDs should not be used for new applications. Hence, nm_uuid_generate_from_strings_v3() is no longer a desirable way to generate UUIDs, so drop the wrapper.
2022-10-03libnm-core/tests: drop duplicate tests _check_uuid_v3() (2)Thomas Haller1-18/+0
The previous commits show that the behavior is the same. We can not drop these checks.
2022-10-03libnm-core/tests: drop duplicate tests _check_uuid_v3()Thomas Haller1-36/+3
As the unit test shows, the behavior is the same.
2022-10-03glib-aux: implement nm_uuid_generate_from_strings_legacy() in terms of ↵Thomas Haller2-42/+2
nm_uuid_generate_from_strings() As the unit tests show, the behavior is the same.
2022-10-03glib-aux: avoid leaking secrets in memory during ↵Thomas Haller1-1/+1
nm_uuid_generate_from_strings_strv() Some snake oil, but this is a low level function and we don't know whether the caller doesn't try to hash secret information. Just clear the buffer after use.
2022-10-03glib: add nm_uuid_generate_from_strings() helperThomas Haller3-0/+260
nm_uuid_generate_from_strings() accepts a uuid_type and type_arg parameter, so that we can use it to generate version 5 UUIDs. This is a more flexible variant of nm_uuid_generate_from_strings_v3(), which will be used to replace it. With the right parameters, the new function behaves the same as nm_uuid_generate_from_strings_v3().
2022-10-03libnm/tests: drop redundant argument in test codeThomas Haller1-16/+19
2022-10-03glib-aux: rename nm_uuid_generate_from_strings() to ↵Thomas Haller7-35/+35
nm_uuid_generate_from_strings_v3() nm_uuid_generate_from_strings() uses variant3 UUIDs based on MD5. We shouldn't use that in the future. We will add a replacement, so rename this function so that the "good" name is free again. Of course, code that uses this function currently relies on that the behavior doesn't change. We cannot just drop it entirely, but will replace it by something that gives the same result. Rename.
2022-10-03glib-aux: add code comment to NM_UUID_INIT()Thomas Haller1-0/+3
`NM_UUID_INIT(00, 09, 01, ...)` would look as if the values are octal numbers. That is not the case. The macro mangles them, so that the look like the UUID in string form "000901...". This is a bit odd. Maybe more confusing than helpful. Or maybe helpful?
2022-10-03libnm: merge branch 'th/libnm-connection-get-private'Thomas Haller3-47/+58
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1400
2022-10-03libnm: move optimized NM_IS_{SIMPLE,}CONNECTION() to internal headerThomas Haller2-27/+26
We already redefine those checks to optimize for NMSimpleConnection. Which, in particular when libnm-core is used by the daemon, is the only implementation of the NMConnection interface. Move those to the private header file. No need to keep it private to "nm-connection.c".
2022-10-03libnm: rework lookup of private data for NMConnection of NMSimpleConnectionThomas Haller3-20/+32
NMConnection is an interface, and as such has no data itself. In practice, there are only two implementations of this interface, NMSimpleConnection and NMRemoteConnection. The latter only exists in libnm, not the daemon. Thus, lookup of the private data is already optimized for NMSimpleConnection instances via _nm_simple_connection_private_offset. Use the same mechanism also for NMSimpleConnection itself.
2022-10-03build: merge branch 'th/build-gettext-update-po'Thomas Haller3-5/+18
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1405
2022-10-03build: don't "update-po" during make distThomas Haller3-4/+17
Instead, hack gettext's Makefile. gettext has an issue with parallel make. See [1] and [2]. Reproduce with: git reset --hard && git clean -fdx && NOCONFIGURE=yes ./autogen.sh && ./configure --enable-gtk-doc --enable-introspection && make -j distcheck V=1 We worked around this by setting "DIST_DEPENDS_ON_UPDATE_PO = yes", however that (obviously) results in regenerating source files during dist. "Source files" in the sense that the po files are commited to git and get distributed in the release. Doing this is very ugly. In particular it's ugly, because `make -C po update-po` is not reproducible and the output depends on the current time (*had one job*). Otherwise, we could just regenerate the files before doing a release. This means, running "release.sh" script ends up with a dirty tree afterwards. Also, the distributed po files are not the ones from the source tree when we did the release. Also, since "release.sh rc1" does two distributions (once for the rc1 and once for the next devel snapshot), the commit for the second distribution will have a large diff for the po files. This reverts commit 978d8eb69923 ('po: make dist depend on update-po') and hacks around the problem. [1] https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1094#note_1435313 [2] https://lists.gnu.org/archive/html/bug-gettext/2022-06/msg00022.html https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1405
2022-10-03gitlab: fail if "run-test.sh" with dirty working treeThomas Haller1-1/+1
2022-10-03contrib: discourage g_type_class_add_private() via "checkpatch.pl"Thomas Haller1-0/+1
Our GObject structs should be internal API. In which case, we should embed the private data in the struct themselves (`_priv`) and use the _NM_GET_PRIVATE() macro. The advantage is better debugability because following G_TYPE_INSTANCE_GET_PRIVATE() in the debugger is very cumbersome. Another (less relevant) advantage is better performance. Thus, warn about uses of g_type_class_add_private() and G_TYPE_INSTANCE_GET_PRIVATE(). Note that if the struct and is in a header file (which is usually only necessary when subclassing the type), then the private data should be an opaque pointer `_priv` instead, and we should use the _NM_GET_PRIVATE_PTR() macro. In that case, the use of g_type_class_add_private() and G_TYPE_INSTANCE_GET_PRIVATE() is correct and the warning is false. But this is only a warning, for the unusual case where we have deep object hierarchies. https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1396
2022-10-03man/NetworkManager-wait-online.service: clean upMarc Muehlfeld1-123/+96
I rewrote the man page to make it clearer and easier to understand. Additionally, I fixed some typos and grammar issues. https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1390
2022-10-03nmcli: don't print warning in `nmcli connection import` about duplicate ↵Thomas Haller1-8/+3
parameters It seems uncommon that a command line tool warns about duplicate paramters. Usually, the latter just overwrites the former. That is also useful so that you can have for example an alias that sets a default type nmcli_import="nmcli connection import type keyfile" but still call it like nmcli_import file $FILE type openvpn This is a change in behavior. Not only stop we printing a warning, we will now prefer the latter argument. Previously, the first was honored. This change in behavior is a problem, but such uses were warned against in the past, and hopefully nobody did this or relied on this.
2022-10-03po: add missing files to POTFILES.inBeniamino Galvani1-0/+2
Fixes: 9b396f7cc8a7 ('nmtui: add MACsec support') Fixes: 7b067be5804b ('nmtui: introduce Nmt8021xFields')
2022-09-30bond,bridge,team: use uuid for con.master when generating connectionlr/master-uuidLubomir Rintel3-12/+15
If we're generating a connection for an externally configured slave, refer the master by the UUID instead of the device name. This doesn't matter most of the time. However, on a checkpoint restore we need to make sure that a connection that is unambiguously the original master is up. Otherwise it could happen that a different connection was activated on the same master device and the slaves being restored don't agree on which master connection to bring up. I can't think of any thing that would rely on this but I've been wrong about more serious things before. Fixes-test: @libnm_snapshot_reattach_unmanaged_ports_to_bridge https://bugzilla.redhat.com/show_bug.cgi?id=2125615
2022-09-30device: assert we're not waiting on a nil masterLubomir Rintel1-0/+2
If we're notified of a master appearing, make sure there's actually an ifindex we're waiting for. Triger an assertion failure if that is not the case, cause that's pretty messed up.
2022-09-30device: fix recheck slave logicLubomir Rintel1-13/+16
Since commit a1de6810df46 ('device: don't ignore external slave removals') we don't leave device_recheck_slave_status() on un-eslaving (that is plink->master = 0) early enough. This results in hooking of NM_MANAGER_DEVICE_IFINDEX_CHANGED even when we're not actually waiting for any master device to come up, accompanied by a messed up log entry: device[3fa7cfc200be4e84] (portXc): enslaved to unknown device 0 (??) We also log nonsense when we see any device's link being removed: device[a9a4b65bde851bcf] (br0): ifindex: set ifindex 0 (old-l3cfg: 05c6a4409f84d9d2) device[45d34e95fb71cce0] (portXa): master br0 with ifindex 0 appeared We don't do further damage afterwards, so this is purely a cosmetic annoyance.
2022-09-30checkpoint: move a log message a little lowerLubomir Rintel1-1/+1
It's happier there.
2022-09-29core: merge branch 'th/mlag-bonding-slb' (part 2)Thomas Haller5-12/+57
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1385
2022-09-29firewall: introduce helper function for add/flush/delete nft table commandThomas Haller1-2/+9
2022-09-29firewall: fail from nm_firewall_nft_call() on non-zero exit codeThomas Haller1-1/+10
2022-09-29device: allow resetting the devip state via nm_device_devip_set_state()Thomas Haller2-2/+6
There is no reason to disallow resetting the state.
2022-09-29glib-aux: add NM_UTILS_ERROR_COMMAND_FAILED error codeThomas Haller1-0/+2
2022-09-29glib-aux: add nm_utils_get_process_exit_status_desc_buf() helperThomas Haller2-7/+30
2022-09-29device: merge branch 'th/mlag-bonding-slb' (part 1)Thomas Haller2-23/+25
Small spin-off from merge request with minor cleanups. Merge early. https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1385
2022-09-29core: obfuscate pointer value in logging in "nm-active-connection.c"Thomas Haller1-16/+16
2022-09-29device: downgrade warning level for logging in nm_device_queue_state()Thomas Haller1-1/+1
This is something that does happen. Is that a bug? If so, this should not be a warning message but an assertion failure. If it's not a bug, then this does not warrant warning level, because the user wouldn't know what to do about this and it's something that occasionally happens. Granted, the state handling in NMDevice is complex, that it's unclear whether this indicates a problem or not. In any case, having a warning does only confuse the user.
2022-09-29device: simplify resource management in nm_device_master_release_slave()Thomas Haller1-6/+8
2022-09-29veth: drop iface peer check during create_and_realize()Fernando Fernandez Mancera1-2/+2
When fetching the parent device, if the system is slow, NetworkManager can hit a race condition where the property is still NULL. In that case, NetworkManager should create the veth link. Checking that the peer device exists, it is type NM_DEVICE_TYPE_VETH and it have a parent device is enough to know that we can skip the link creation. https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1399 https://bugzilla.redhat.com/show_bug.cgi?id=2129829 Fixes: 4655b7c30846 ('veth: fix veth activation on booting')
2022-09-29glib-aux: fix nm_str_buf_finalize() for cloning bufferThomas Haller2-1/+14
NMStrBuf can also contains NUL characters. We thus cannot use g_strndup(), which uses strncpy() and truncates at the first NUL. Fixes: 13d25f9d0b2f ('glib-aux: add support for starting with stack-allocated buffer in NMStrBuf')
2022-09-28NEWS: updateThomas Haller1-0/+2
2022-09-28contrib: add entries to bash_history for nm-in-container.sh scriptThomas Haller1-0/+1
2022-09-28contrib: add entries to bash_history for nm-in-container.sh scriptThomas Haller1-3/+10
2022-09-28all: merge branch 'th/array-find-bsearch'Thomas Haller16-173/+162
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1397
2022-09-28std-aux/trivial: fix typo in code commentThomas Haller1-1/+1
2022-09-28glib-aux: swap arguments for nm_array_find_bsearch()Thomas Haller13-16/+16
Have "len" before "elem_size". That is consistent with g_qsort_with_data() and bsearch(), and is also what I would expect. Note that the previous commit just renamed the function. If a user of the new, changed API gets backported to an older branch, we will get a compilation error and note that the arguments need to be adjusted.
2022-09-28glib-aux: rename nm_utils_array_find_binary_search() to nm_array_bsearch()Thomas Haller15-171/+160
The "nm_utils_" prefix is just too verbose. Drop it. Also, Posix has a bsearch function. As this function is similar, rename it. Note that currently the arguments are provided in differnt order from bsearch(). That will be partly addressed next. That is the main reason for the rename. The next commit will swap the arguments, so do a rename first to get a compilation error when backporting a patch that uses the changed API.
2022-09-28cli: merge branch 'th/cli-select-by-uuid'Thomas Haller1-1/+22
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1393
2022-09-28nmcli: allow selecting profiles by partial UUIDThomas Haller1-0/+6
For convenience, allow also to match the UUID by prefix -- if the "uuid" selector is used. Note that still, there must be only one candidate found. The "uuid" selector guarantees to find a unique connection. $ nmcli -f connection.uuid,connection.id connection show uuid eb43d80c
2022-09-28nmcli: ensure profiles matching by "uuid","path" selector are uniqueThomas Haller1-1/+16
The "connection.uuid" and the D-Bus path are supposed to be unique on D-Bus. Anything else indicates to a bug somewhere. Still, with `nmcli connection $operation [uuid|path] $arg ...` ensure that the result is always unique. In practice, this should make no difference. In the case of an unexpected duplicate, it seems better to fail and uphold the guarantee that these selectors give unique results. Also, next we will accept matching prefixes of the UUID. While partial match will then be supported, it should still be unique. That is, the "uuid" specifier should always only yield one result. While this patch should make not difference in practice today (albeit enforcing something that should be valid), it will make a difference then.
2022-09-28Revert "device: restart DHCP when the MAC changes"Beniamino Galvani1-6/+3
The commit causes problems with bridges. When a new port is attached the MAC of the bridge possibly changes and if we restart DHCP the bridge will get a different IP address. Revert the change until a better solution to the original problem is found. This reverts commit 905adabdba033bbfc33013d0ad203bd444131dc5. https://bugzilla.redhat.com/show_bug.cgi?id=2124443 https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1401
2022-09-28nmtui: merge branch 'bg/nmtui-8021x'Beniamino Galvani18-82/+1241
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1314
2022-09-28NEWS: updateBeniamino Galvani1-0/+2
2022-09-28nmtui: add MACsec supportBeniamino Galvani7-0/+239
2022-09-28nmtui: ethernet: support wired 802.1X authenticationBeniamino Galvani2-16/+85
generated by cgit v1.2.3 (git 2.39.1) at 2024-05-24 21:58:16 +0000