summaryrefslogtreecommitdiff
path: root/NEWS
Commit message (Collapse)AuthorAgeFilesLines
* release: bump version to 1.23.1-dev after 1.22.0 release1.23.1-devThomas Haller2019-12-171-0/+10
|\ | | | | | | | | | | | | | | | | | | After 1.22.0 is released, merge it back into master so that 1.22.0 is part of the history of master. That means, $ git log --first-parent master will also traverse 1.22.0 and 1.22-rc*. Also bump the micro version to 1.23.1-dev to indicate that this is after 1.22.0 is out.
* | NEWS: updateThomas Haller2019-12-171-4/+3
|/
* NEWS: updateThomas Haller2019-11-291-7/+18
|
* cloud-setup: add tool for automatic IP configuration in cloudThomas Haller2019-11-281-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | This is a tool for automatically configuring networking in a cloud environment. Currently it only supports IPv4 on EC2, but it's intended for extending to other cloud providers (Azure). See [1] and [2] for how to configure secondary IP addresses on EC2. This is what the tool currently aims to do (but in the future it might do more). [1] https://aws.amazon.com/premiumsupport/knowledge-center/ec2-ubuntu-secondary-network-interface/ It is inspired by SuSE's cloud-netconfig ([1], [2]) and ec2-net-utils package on Amazon Linux ([3], [4]). [1] https://www.suse.com/c/multi-nic-cloud-netconfig-ec2-azure/ [2] https://github.com/SUSE-Enceladus/cloud-netconfig [3] https://github.com/aws/ec2-net-utils [4] https://github.com/lorengordon/ec2-net-utils.git It is also intended to work without configuration. The main point is that you boot an image with NetworkManager and nm-cloud-setup enabled, and it just works.
* all: add support for "scope" attribute for IPv4 routesThomas Haller2019-11-281-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | - systemd-networkd and initscripts both support it. - it seems suggested to configure routes with scope "link" on AWS. - the scope is only supported for IPv4 routes. Kernel ignores the attribute for IPv6 routes. - we don't support the aliases like "link" or "global". Instead only the numeric value is supported. This is different from systemd-networkd, which accepts names like "global" and "link", but no numerical values. I think restricting ourself only to the aliases unnecessarily limits what is possible on netlink. The alternative would be to allow aliases and numbers both, but that causes multiple ways to define something and has thus downsides. So, only numeric values. - when setting rtm_scope to RT_SCOPE_NOWHERE (0, the default), kernel will coerce that to RT_SCOPE_LINK. This ambiguity of nowhere vs. link is a problem, but we don't do anything about it. - The other problem is, that when deleting a route with scope RT_SCOPE_NOWHERE, this acts as a wild care and removes the first route that matches (given the other route attributes). That means, NetworkManager has no meaningful way to delete a route with scope zero, there is always the danger that we might delete the wrong route. But this is nothing new to this patch. The problem existed already previously, except that NetworkManager could only add routes with scope nowhere (i.e. link).
* libnm: refactor caching of D-Bus objects in NMClientThomas Haller2019-11-251-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | No longer use GDBusObjectMangaerClient and gdbus-codegen generated classes for the NMClient cache. Instead, use GDBusConnection directly and a custom implementation (NMLDBusObject) for caching D-Bus' ObjectManager data. CHANGES ------- - This is a complete rework. I think the previous implementation was difficult to understand. There were unfixed bugs and nobody understood the code well enough to fix them. Maybe somebody out there understood the code, but I certainly did not. At least nobody provided patches to fix those issues. I do believe that this implementation is more straightforward and easier to understand. It removes a lot of layers of code. Whether this claim of simplicity is true, each reader must decide for himself/herself. Note that it is still fairly complex. - There was a lingering performance issue with large number of D-Bus objects. The patch tries hard that the implementation scales well. Of course, when we cache N objects that have N-to-M references to other, we still are fundamentally O(N*M) for runtime and memory consumption (with M being the number of references between objects). But each part should behave efficiently and well. - Play well with GMainContext. libnm code (NMClient) is generally not thread safe. However, it should work to use multiple instances in parallel, as long as each access to a NMClient is through the caller's GMainContext. This follows glib's style and effectively allows to use NMClient in a multi threaded scenario. This implies to stick to a main context upon construction and ensure that callbacks are only invoked when iterating that context. Also, NMClient itself shall never iterate the caller's context. This also means, libnm must never use g_idle_add() or g_timeout_add(), as those enqueue sources in the g_main_context_default() context. - Get ordering of messages right. All events are consistently enqueued in a GMainContext and processed strictly in order. For example, previously "nm-object.c" tried to combine signals and emit them on an idle handler. That is wrong, signals must be emitted in the right order and when they happen. Note that when using GInitable's synchronous initialization to initialize the NMClient instance, NMClient internally still operates fully asynchronously. In that case NMClient has an internal main context. - NMClient takes over most of the functionality. When using D-Bus' ObjectManager interface, one needs to handle basically the entire state of the D-Bus interface. That cannot be separated well into distinct parts, and even if you try, you just end up having closely related code in different source files. Spreading related code does not make it easier to understand, on the contrary. That means, NMClient is inherently complex as it contains most of the logic. I think that is not avoidable, but it's not as bad as it sounds. - NMClient processes D-Bus messages and state changes in separate steps. First NMClient unpacks the message (e.g. _dbus_handle_properties_changed()) and keeps track of the changed data. Then we update the GObject instances (_dbus_handle_obj_changed_dbus()) without emitting any signals yet. Finally, we emit all signals and notifications that were collected (_dbus_handle_changes_commit()). Note that for example during the initial GetManagedObjects() reply, NMClient receive a large amount of state at once. But we first apply all the changes to our GObject instances before emitting any signals. The result is that signals are always emitted in a moment when the cache is consistent. The unavoidable downside is that when you receive a property changed signal, possibly many other properties changed already and more signals are about to be emitted. - NMDeviceWifi no longer modifies the content of the cache from client side during poke_wireless_devices_with_rf_status(). The content of the cache should be determined by D-Bus alone and follow what NetworkManager service exposes. Local modifications should be avoided. - This aims to bring no API/ABI change, though it does of course bring various subtle changes in behavior. Those should be all for the better, but the goal is not to break any existing clients. This does change internal (albeit externally visible) API, like dropping NM_OBJECT_DBUS_OBJECT_MANAGER property and NMObject no longer implementing GInitableIface and GAsyncInitableIface. - Some uses of gdbus-codegen classes remain in NMVpnPluginOld, NMVpnServicePlugin and NMSecretAgentOld. These are independent of NMClient/NMObject and should be reworked separately. - While we no longer use generated classes from gdbus-codegen, we don't need more glue code than before. Also before we constructed NMPropertiesInfo and a had large amount of code to propagate properties from NMDBus* to NMObject. That got completely reworked, but did not fundamentally change. You still need about the same effort to create the NMLDBusMetaIface. Not using generated bindings did not make anything worse (which tells about the usefulness of generated code, at least in the way it was used). - NMLDBusMetaIface and other meta data is static and immutable. This avoids copying them around. Also, macros like NML_DBUS_META_PROPERTY_INIT_U() have compile time checks to ensure the property types matches. It's pretty hard to misuse them because it won't compile. - The meta data now explicitly encodes the expected D-Bus types and makes sure never to accept wrong data. That would only matter when the server (accidentally or intentionally) exposes unexpected types on D-Bus. I don't think that was previously ensured in all cases. For example, demarshal_generic() only cared about the GObject property type, it didn't know the expected D-Bus type. - Previously GDBusObjectManager would sometimes emit warnings (g_log()). Those probably indicated real bugs. In any case, it prevented us from running CI with G_DEBUG=fatal-warnings, because there would be just too many unrelated crashes. Now we log debug messages that can be enabled with "LIBNM_CLIENT_DEBUG=trace". Some of these messages can also be turned into g_warning()/g_critical() by setting LIBNM_CLIENT_DEBUG=warning,error. Together with G_DEBUG=fatal-warnings, this turns them into assertions. Note that such "assertion failures" might also happen because of a server bug (or change). Thus these are not common assertions that indicate a bug in libnm and are thus not armed unless explicitly requested. In our CI we should now always run with LIBNM_CLIENT_DEBUG=warning,error and G_DEBUG=fatal-warnings and to catch bugs. Note that currently NetworkManager has bugs in this regard, so enabling this will result in assertion failures. That should be fixed first. - Note that this changes the order in which we emit "notify:devices" and "device-added" signals. I think it makes the most sense to emit first "device-removed", then "notify:devices", and finally "device-added" signals. This changes behavior for commit 52ae28f6e5bf ('libnm: queue added/removed signals and suppress uninitialized notifications'), but I don't think that users should actually rely on the order. Still, the new order makes the most sense to me. - In NetworkManager, profiles can be invisible to the user by setting "connection.permissions". Such profiles would be hidden by NMClient's nm_client_get_connections() and their "connection-added"/"connection-removed" signals. Note that NMActiveConnection's nm_active_connection_get_connection() and NMDevice's nm_device_get_available_connections() still exposes such hidden NMRemoteConnection instances. This behavior was preserved. NUMBERS ------- I compared 3 versions of libnm. [1] 962297f9085d, current tip of nm-1-20 branch [2] 4fad8c7c642e, current master, immediate parent of this patch [3] this patch All tests were done on Fedora 31, x86_64, gcc 9.2.1-1.fc31. The libraries were build with $ ./contrib/fedora/rpm/build_clean.sh -g -w test -W debug Note that RPM build already stripped the library. --- N1) File size of libnm.so.0.1.0 in bytes. There currently seems to be a issue on Fedora 31 generating wrong ELF notes. Usually, libnm is smaller but in these tests it had large (and bogus) ELF notes. Anyway, the point is to show the relative sizes, so it doesn't matter). [1] 4075552 (102.7%) [2] 3969624 (100.0%) [3] 3705208 ( 93.3%) --- N2) `size /usr/lib64/libnm.so.0.1.0`: text data bss dec hex filename [1] 1314569 (102.0%) 69980 ( 94.8%) 10632 ( 80.4%) 1395181 (101.4%) 1549ed /usr/lib64/libnm.so.0.1.0 [2] 1288410 (100.0%) 73796 (100.0%) 13224 (100.0%) 1375430 (100.0%) 14fcc6 /usr/lib64/libnm.so.0.1.0 [3] 1229066 ( 95.4%) 65248 ( 88.4%) 13400 (101.3%) 1307714 ( 95.1%) 13f442 /usr/lib64/libnm.so.0.1.0 --- N3) Performance test with test-client.py. With checkout of [2], run ``` prepare_checkout() { rm -rf /tmp/nm-test && \ git checkout -B test 4fad8c7c642e && \ git clean -fdx && \ ./autogen.sh --prefix=/tmp/nm-test && \ make -j 5 install && \ make -j 5 check-local-clients-tests-test-client } prepare_test() { NM_TEST_REGENERATE=1 NM_TEST_CLIENT_BUILDDIR="/data/src/NetworkManager" NM_TEST_CLIENT_NMCLI_PATH=/usr/bin/nmcli python3 ./clients/tests/test-client.py -v } do_test() { for i in {1..10}; do NM_TEST_CLIENT_BUILDDIR="/data/src/NetworkManager" NM_TEST_CLIENT_NMCLI_PATH=/usr/bin/nmcli python3 ./clients/tests/test-client.py -v || return -1 done echo "done!" } prepare_checkout prepare_test time do_test ``` [1] real 2m14.497s (101.3%) user 5m26.651s (100.3%) sys 1m40.453s (101.4%) [2] real 2m12.800s (100.0%) user 5m25.619s (100.0%) sys 1m39.065s (100.0%) [3] real 1m54.915s ( 86.5%) user 4m18.585s ( 79.4%) sys 1m32.066s ( 92.9%) --- N4) Performance. Run NetworkManager from build [2] and setup a large number of profiles (551 profiles and 515 devices, mostly unrealized). This setup is already at the edge of what NetworkManager currently can handle. Of course, that is a different issue. Here we just check how long plain `nmcli` takes on the system. ``` do_cleanup() { for UUID in $(nmcli -g NAME,UUID connection show | sed -n 's/^xx-c-.*:\([^:]\+\)$/\1/p'); do nmcli connection delete uuid "$UUID" done for DEVICE in $(nmcli -g DEVICE device status | grep '^xx-i-'); do nmcli device delete "$DEVICE" done } do_setup() { do_cleanup for i in {1..30}; do nmcli connection add type bond autoconnect no con-name xx-c-bond-$i ifname xx-i-bond-$i ipv4.method disabled ipv6.method ignore for j in $(seq $i 30); do nmcli connection add type vlan autoconnect no con-name xx-c-vlan-$i-$j vlan.id $j ifname xx-i-vlan-$i-$j vlan.parent xx-i-bond-$i ipv4.method disabled ipv6.method ignore done done systemctl restart NetworkManager.service sleep 5 } do_test() { perf stat -r 50 -B nmcli 1>/dev/null } do_test ``` [1] Performance counter stats for 'nmcli' (50 runs): 456.33 msec task-clock:u # 1.093 CPUs utilized ( +- 0.44% ) 0 context-switches:u # 0.000 K/sec 0 cpu-migrations:u # 0.000 K/sec 5,900 page-faults:u # 0.013 M/sec ( +- 0.02% ) 1,408,675,453 cycles:u # 3.087 GHz ( +- 0.48% ) 1,594,741,060 instructions:u # 1.13 insn per cycle ( +- 0.02% ) 368,744,018 branches:u # 808.061 M/sec ( +- 0.02% ) 4,566,058 branch-misses:u # 1.24% of all branches ( +- 0.76% ) 0.41761 +- 0.00282 seconds time elapsed ( +- 0.68% ) [2] Performance counter stats for 'nmcli' (50 runs): 477.99 msec task-clock:u # 1.088 CPUs utilized ( +- 0.36% ) 0 context-switches:u # 0.000 K/sec 0 cpu-migrations:u # 0.000 K/sec 5,948 page-faults:u # 0.012 M/sec ( +- 0.03% ) 1,471,133,482 cycles:u # 3.078 GHz ( +- 0.36% ) 1,655,275,369 instructions:u # 1.13 insn per cycle ( +- 0.02% ) 382,595,152 branches:u # 800.433 M/sec ( +- 0.02% ) 4,746,070 branch-misses:u # 1.24% of all branches ( +- 0.49% ) 0.43923 +- 0.00242 seconds time elapsed ( +- 0.55% ) [3] Performance counter stats for 'nmcli' (50 runs): 352.36 msec task-clock:u # 1.027 CPUs utilized ( +- 0.32% ) 0 context-switches:u # 0.000 K/sec 0 cpu-migrations:u # 0.000 K/sec 4,790 page-faults:u # 0.014 M/sec ( +- 0.26% ) 1,092,341,186 cycles:u # 3.100 GHz ( +- 0.26% ) 1,209,045,283 instructions:u # 1.11 insn per cycle ( +- 0.02% ) 281,708,462 branches:u # 799.499 M/sec ( +- 0.01% ) 3,101,031 branch-misses:u # 1.10% of all branches ( +- 0.61% ) 0.34296 +- 0.00120 seconds time elapsed ( +- 0.35% ) --- N5) same setup as N4), but run `PAGER= /bin/time -v nmcli`: [1] Command being timed: "nmcli" User time (seconds): 0.42 System time (seconds): 0.04 Percent of CPU this job got: 107% Elapsed (wall clock) time (h:mm:ss or m:ss): 0:00.43 Average shared text size (kbytes): 0 Average unshared data size (kbytes): 0 Average stack size (kbytes): 0 Average total size (kbytes): 0 Maximum resident set size (kbytes): 34456 Average resident set size (kbytes): 0 Major (requiring I/O) page faults: 0 Minor (reclaiming a frame) page faults: 6128 Voluntary context switches: 1298 Involuntary context switches: 1106 Swaps: 0 File system inputs: 0 File system outputs: 0 Socket messages sent: 0 Socket messages received: 0 Signals delivered: 0 Page size (bytes): 4096 Exit status: 0 [2] Command being timed: "nmcli" User time (seconds): 0.44 System time (seconds): 0.04 Percent of CPU this job got: 108% Elapsed (wall clock) time (h:mm:ss or m:ss): 0:00.44 Average shared text size (kbytes): 0 Average unshared data size (kbytes): 0 Average stack size (kbytes): 0 Average total size (kbytes): 0 Maximum resident set size (kbytes): 34452 Average resident set size (kbytes): 0 Major (requiring I/O) page faults: 0 Minor (reclaiming a frame) page faults: 6169 Voluntary context switches: 1849 Involuntary context switches: 142 Swaps: 0 File system inputs: 0 File system outputs: 0 Socket messages sent: 0 Socket messages received: 0 Signals delivered: 0 Page size (bytes): 4096 Exit status: 0 [3] Command being timed: "nmcli" User time (seconds): 0.32 System time (seconds): 0.02 Percent of CPU this job got: 102% Elapsed (wall clock) time (h:mm:ss or m:ss): 0:00.34 Average shared text size (kbytes): 0 Average unshared data size (kbytes): 0 Average stack size (kbytes): 0 Average total size (kbytes): 0 Maximum resident set size (kbytes): 29196 Average resident set size (kbytes): 0 Major (requiring I/O) page faults: 0 Minor (reclaiming a frame) page faults: 5059 Voluntary context switches: 919 Involuntary context switches: 685 Swaps: 0 File system inputs: 0 File system outputs: 0 Socket messages sent: 0 Socket messages received: 0 Signals delivered: 0 Page size (bytes): 4096 Exit status: 0 --- N6) same setup as N4), but run `nmcli monitor` and look at `ps aux` for the RSS size. USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND [1] me 1492900 21.0 0.2 461348 33248 pts/10 Sl+ 15:02 0:00 nmcli monitor [2] me 1490721 5.0 0.2 461496 33548 pts/10 Sl+ 15:00 0:00 nmcli monitor [3] me 1495801 16.5 0.1 459476 28692 pts/10 Sl+ 15:04 0:00 nmcli monitor
* dhcp: switch IPv4 "internal" DHCP client to use "nettools" backend instead ↵Thomas Haller2019-11-231-0/+2
| | | | | | | | | | | | | | | | | | | | | | | of "systemd" Previously, our "internal" DHCPv4 client is based on a fork of systemd code. This manner of maintaining the fork is problematic. The solution is to use a proper library: n-dhcp4 from the nettools project. We already have these two as undocumented plugins available, by setting either "dhcp=systemd" or "dhcp=nettools". This is only for testing. Users are only supposed to use the "internal" plugin. Up until now, the "internal" DHCPv4 plugin was based on "systemd" code. Change that to use "nettools" instead. Possibly this breaks something, and we need to fix it. But do this early so we have time to test the nettools plugin and identify issues. For the user, this change should be entirely transparant. https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/302
* libnm: retire deprecated WiMAX NMObject typesThomas Haller2019-10-231-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | WiMAX is deprecated since NetworkManager 1.2.0. Note that also NetworkManager on server side no longer supports this type, hence the server's D-Bus API will never expose devices of this type. Note that NMDeviceWimax and NMWimaxNsp are NMObject types. That means, they are instantiated by NMClient to represent information on the D-Bus interface. As NetworkManager no longer exposes WiMAX devices, such devices are never created. Note that it makes no sense that a user would directly instantiate NMObject types, because they only work together with NMClient. Don't drop the related symbols and definitions from libnm, so that there is no API/ABI change (as far as building and linking is concerned). But make the types defunctional (which of course is a behavioral API change). Calling the API now triggers a g_return_*() warning. Also belatedly mark the WimaxNsp API as deprecated. It should have been done in 1.2. Note that here we deprecate the API and retire it at the same time. Optimally, we would have deprecated it a few releases ago, before retiring it. However, marking something for deprecation is anyway no excuse for anything. I mean, removing or retiring API is usually painful, regardless whether it was marked for deprecation or not. In this case, there is no possibility that a libnm user gets hold on a NMDeviceWimax or NMWimaxNsp instance, because NMClient simply no longer instantiates them. Hence, this change should not affect any user in practice. https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/316
* libnm: hide GObject structs from public API and embed private dataThomas Haller2019-10-221-0/+3
| | | | | | | | | | | | | | | | | | | | These types are all subclasses of NMObject. These instances are commonly created by NMClient itself. It makes no sense that a user would instantiate the type. Much less does it make sense to subclass them. Hide the object and class structures from public API. This is an API and ABI break, but of something that is very likely unused. This is mainly done to embed the private structure in the object itself. This has benefits for performance and debugability. But most importantly, we can obtain a static offset where to access the private data. That means, we can use the information to access the data pointer generically, as we will need later. This is not done for the internal types NMManager, NMRemoteSettings, and NMDnsManager. These types will be dropped later.
* device: don't delay startup complete for pending-actions "autoconf", "dhcp4" ↵Thomas Haller2019-10-141-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | and "dhcp6" These "pending-actions" only have one purpose: to mark the device as busy and thereby delay "startup complete" to be reached. That in turn delays "NetworkManager-wait-online" service. Of course, "NetworkManager-wait-online" waits for some form of readiness and is not extensively configurable (e.g. you cannot exclude devices from being waited). However, the intent is to wait that all devices are "settled". That means among others, that the timeouts waiting for carrier and Wi-Fi scan results passed, and devices either don't have a connection profile to autoactivate, or they autoactivated profiles and are in state "connected". A major point here is that the device is considered ready, once it reaches the state "connected". Note that if you configure both IPv4 and IPv6 addressing modes, than "ipv4.may-fail=yes" and "ipv6.may-fail=yes" means, that the device is considered fully activated once one address family completes. Again, this is not very configurable, but by setting "ipv6.may-fail=no", you can require that the device has indeed IPv6 addressing completed. Now, the determining factor for declaring "startup complete" is whether the device is in state "connected". That may or may not mean that DHCPv4, autoconf or DHCPv6 completed, as it depends on a overall state of the device. So, it is wrong to have distinct pending actions for these operations. Remove them. This fixes that we wrongly would wait too long before declaring startup complete. But it is also a change in behavior.
* NEWS: mention removal of BlueZ 4 supportThomas Haller2019-08-121-0/+2
|
* NEWS: update header for future 1.22 releaseThomas Haller2019-08-101-3/+12
| | | | Also, mark 1.20 as stable.
* NEWS: updateThomas Haller2019-08-061-14/+20
|
* NEWS: updateThomas Haller2019-07-291-0/+7
|
* devices/wifi: support Mesh modeLubomir Rintel2019-07-291-0/+1
| | | | | This puts together the bits from previous commits and actually allows for activating a mode=mesh connection.
* NEWS: updateThomas Haller2019-07-261-1/+23
|
* NEWS: add news entries with changes from 1.18.2Thomas Haller2019-07-261-0/+19
|
* settings: drop ibft settings pluginth/drop-ibft-settings-pluginThomas Haller2019-06-201-0/+2
| | | | | | | | | | | | | | | The functionality of the ibft settings plugin is now handled by nm-initrd-generator. There is no need for it anymore, drop it. Note that ibft called iscsiadm, which requires CAP_SYS_ADMIN to work ([1]). We really want to drop this capability, so the current solution of a settings plugin (as it is implemented) is wrong. The solution instead is nm-initrd-generator. Also, on Fedora the ibft was disabled and probably on most other distributions as well. This was only used on RHEL. [1] https://bugzilla.redhat.com/show_bug.cgi?id=1371201#c7
* NEWS: updateThomas Haller2019-06-111-0/+3
|
* settings: drop deprecated NetworkManager.conf option ↵Thomas Haller2019-05-281-0/+4
| | | | | | | | | | | | | | | "main.monitor-connection-files" It's deprecated and off by default for a long time. It is bad to automatically reload connection profiles. For example, ifcfg files may consist of multiple files, there is no guarantee that we pick up the connection when it's fully written. Just don't do this anymore. Users should use D-Bus API or `nmcli connection reload` or `nmcli connection load $FILENAME` to reload profiles from disk.
* NEWS: updateLubomir Rintel2019-05-031-0/+2
|
* build: default to internal DHCP clientLubomir Rintel2019-04-161-0/+4
| | | | | | | Meson builds already seem to default this and RHEL & Fedora switched already. Everyone else also should. https://github.com/NetworkManager/NetworkManager/pull/345
* all: goodbye libnm-glibLubomir Rintel2019-04-161-0/+3
| | | | | | | | | | | | | | | | | | | | | | | This removes libnm-glib, libnm-glib-vpn, and libnm-util for good. The it has been replaced with libnm since NetworkManager 1.0, disabled by default since 1.12 and no up-to-date distributions ship it for years now. Removing the libraries allows us to: * Remove the horrible hacks that were in place to deal with accidental use of both the new and old library in a single process. * Relief the translators of maintenance burden of similar yet different strings. * Get rid of known bad code without chances of ever getting fixed (libnm-glib/nm-object.c and libnm-glib/nm-object-cache.c) * Generally lower the footprint of the releases and our workspace If there are some really really legacy users; they can just build libnm-glib and friends from the NetworkManager-1.16 distribution. The D-Bus API is stable and old libnm-glib will keep working forever. https://github.com/NetworkManager/NetworkManager/pull/308
* release: update NEWSThomas Haller2019-04-131-3/+10
|
* release: update NEWSThomas Haller2019-04-131-0/+6
|
* Revert "all: goodbye libnm-glib"Lubomir Rintel2019-04-031-3/+0
| | | | | | We need this for a little little longer :( This reverts commit 1de8383ad9fdfc8f552117e5d109bdfa7005634b.
* all: goodbye libnm-glibLubomir Rintel2019-03-191-0/+3
| | | | | | | | | | | | | | | | | | | | | | | This removes libnm-glib, libnm-glib-vpn, and libnm-util for good. The it has been replaced with libnm since NetworkManager 1.0, disabled by default since 1.12 and no up-to-date distributions ship it for years now. Removing the libraries allows us to: * Remove the horrible hacks that were in place to deal with accidental use of both the new and old library in a single process. * Relief the translators of maintenance burden of similar yet different strings. * Get rid of known bad code without chances of ever getting fixed (libnm-glib/nm-object.c and libnm-glib/nm-object-cache.c) * Generally lower the footprint of the releases and our workspace If there are some really really legacy users; they can just build libnm-glib and friends from the NetworkManager-1.16 distribution. The D-Bus API is stable and old libnm-glib will keep working forever. https://github.com/NetworkManager/NetworkManager/pull/308
* release: bump version to 1.17.1-dev after 1.16.0 release1.17.1-devThomas Haller2019-03-151-0/+10
|\ | | | | | | | | | | | | | | | | | | After 1.16.0 is released, merge it back into master so that 1.16.0 is part of the history of master. That means, $ git log --first-parent master will also traverse 1.16.0 and 1.16-rc*. Also bump the micro version to 1.17.1-dev to indicate that this is after 1.16.0 is out.
| * all: codespell fixesLubomir Rintel2019-03-111-4/+4
| | | | | | | | | | Codespel run with the same arguments as described in commit 58510ed56679 ('docs: misc. typos pt2').
| * release: update NEWSThomas Haller2019-02-231-3/+10
| |
* | release: update NEWSThomas Haller2019-03-151-4/+1
| |
* | all: codespell fixesLubomir Rintel2019-03-111-4/+4
| | | | | | | | | | | | | | Codespel run with the same arguments as described in commit 58510ed56679 ('docs: misc. typos pt2'). (cherry picked from commit bf0c4e6ac2855088e3962693886bb6ab71856f7b)
* | release: update NEWSThomas Haller2019-02-231-0/+4
|/
* release: update NEWSThomas Haller2019-02-231-0/+20
|
* release: update NEWS with entires from 1.14.6Thomas Haller2019-02-231-5/+40
|
* release: update NEWSth/wireguard-pt3Thomas Haller2019-02-221-0/+3
|
* release: update NEWSThomas Haller2019-02-151-0/+3
|
* NEWS: Add an entry for Wi-Fi P2PBenjamin Berg2019-01-281-0/+1
|
* NEWS: Add an entry for NMKeepAlive and DBus client bindingBenjamin Berg2019-01-281-0/+1
|
* all: say Wi-Fi instead of "wifi" or "WiFi"Lubomir Rintel2018-11-291-14/+14
| | | | | | | | Correct the spelling across the *entire* tree, including translations, comments, etc. It's easier that way. Even the places where it's not exposed to the user, such as tests, so that we learn how is it spelled correctly.
* doc,all: fix spelling of Open vSwitch (instead of OpenVSwitch)Thomas Haller2018-11-281-2/+2
| | | | | | Also affects documentation and translated strings. Reported-by: Flavio Leitner <fbl@redhat.com>
* release: update NEWSThomas Haller2018-10-171-0/+27
|
* docs: misc. typos pt2luz.paz2018-09-171-6/+6
| | | | | | | | | | | | | | | | | | | | | Remainder of typos found using `codespell -q 3 --skip="./shared,./src/systemd,*.po" -I ../NetworkManager-word-whitelist.txt` whereby whitelist consists of: ``` ans busses cace cna conexant crasher iff liftime creat nd sav technik uint ``` https://github.com/NetworkManager/NetworkManager/pull/205
* release: update NEWSThomas Haller2018-09-141-6/+5
|
* release: update NEWSThomas Haller2018-09-071-0/+10
|
* release: update NEWSThomas Haller2018-08-131-0/+3
|
* core: implement connection.multi-connect to activate profiles multiple timesThomas Haller2018-08-081-0/+2
| | | | | | | | Make use of the new property, and implement it. See previous commits for the reasons why. https://bugzilla.redhat.com/show_bug.cgi?id=1555012
* libnm: fix missing symbols in libnm ABIThomas Haller2018-06-301-1/+11
| | | | | Also backport the ABI to 1.12.2 (and thus, don't bother initially adding the API as libnm_1_14_0).
* release: bump version to 1.13.1-dev after 1.12.0 release1.13.1-devThomas Haller2018-06-291-0/+7
|\ | | | | | | | | | | | | | | | | | | After 1.12.0 is released, merge it back into master so that 1.12.0 is part of the history of master. That means, $ git log --first-parent master will also traverse 1.12.0 and 1.12-rc*. Also bump the micro version to 1.13.1-dev to indicate that this is after 1.12.0 is out.
| * NEWS: add an entry for WPAN & 6LowPAN supportlr/6lowpanLubomir Rintel2018-06-261-0/+7
| |