1. 29 Jul, 2019 7 commits
  2. 27 Jul, 2019 2 commits
  3. 26 Jul, 2019 5 commits
    • Thomas Haller's avatar
      systemd: merge branch systemd into master · f6d7af9c
      Thomas Haller authored
      f6d7af9c
    • Thomas Haller's avatar
      systemd: update code from upstream (2019-07-26) · 6a325673
      Thomas Haller authored
      This is a direct dump from systemd git.
      
      ======
      
      SYSTEMD_DIR=../systemd
      COMMIT=608807c163921b0dfbaf646b3ec19fc9b71e6451
      
      (
        cd "$SYSTEMD_DIR"
        git checkout "$COMMIT"
        git reset --hard
        git clean -fdx
      )
      
      git ls-files -z :/src/systemd/src/ \
                      :/shared/systemd/src/ \
                      :/shared/nm-utils/unaligned.h | \
        xargs -0 rm -f
      
      nm_copy_sd_shared() {
          mkdir -p "./shared/systemd/$(dirname "$1")"
          cp "$SYSTEMD_DIR/$1" "./shared/systemd/$1"
      }
      
      nm_copy_sd_core() {
          mkdir -p "./src/systemd/$(dirname "$1")"
          cp "$SYSTEMD_DIR/$1" "./src/systemd/$1"
      }
      
      nm_copy_sd_nmutils() {
          mkdir -p "./shared/nm-utils/"
          cp "$SYSTEMD_DIR/$1" "./shared/nm-utils/${1##*/}"
      }
      
      nm_copy_sd_core "src/libsystemd-network/arp-util.c"
      nm_copy_sd_core "src/libsystemd-network/arp-util.h"
      nm_copy_sd_core "src/libsystemd-network/dhcp-identifier.c"
      nm_copy_sd_core "src/libsystemd-network/dhcp-identifier.h"
      nm_copy_sd_core "src/libsystemd-network/dhcp-internal.h"
      nm_copy_sd_core "src/libsystemd-network/dhcp-lease-internal.h"
      nm_copy_sd_core "src/libsystemd-network/dhcp-network.c"
      nm_copy_sd_core "src/libsystemd-network/dhcp-option.c"
      nm_copy_sd_core "src/libsystemd-network/dhcp-packet.c"
      nm_copy_sd_core "src/libsystemd-network/dhcp-protocol.h"
      nm_copy_sd_core "src/libsystemd-network/dhcp6-internal.h"
      nm_copy_sd_core "src/libsystemd-network/dhcp6-lease-internal.h"
      nm_copy_sd_core "src/libsystemd-network/dhcp6-network.c"
      nm_copy_sd_core "src/libsystemd-network/dhcp6-option.c"
      nm_copy_sd_core "src/libsystemd-network/dhcp6-protocol.h"
      nm_copy_sd_core "src/libsystemd-network/lldp-internal.h"
      nm_copy_sd_core "src/libsystemd-network/lldp-neighbor.c"
      nm_copy_sd_core "src/libsystemd-network/lldp-neighbor.h"
      nm_copy_sd_core "src/libsystemd-network/lldp-network.c"
      nm_copy_sd_core "src/libsystemd-network/lldp-network.h"
      nm_copy_sd_core "src/libsystemd-network/network-internal.c"
      nm_copy_sd_core "src/libsystemd-network/network-internal.h"
      nm_copy_sd_core "src/libsystemd-network/sd-dhcp-client.c"
      nm_copy_sd_core "src/libsystemd-network/sd-dhcp-lease.c"
      nm_copy_sd_core "src/libsystemd-network/sd-dhcp6-client.c"
      nm_copy_sd_core "src/libsystemd-network/sd-dhcp6-lease.c"
      nm_copy_sd_core "src/libsystemd-network/sd-ipv4acd.c"
      nm_copy_sd_core "src/libsystemd-network/sd-ipv4ll.c"
      nm_copy_sd_core "src/libsystemd-network/sd-lldp.c"
      nm_copy_sd_core "src/libsystemd/sd-event/event-source.h"
      nm_copy_sd_core "src/libsystemd/sd-event/event-util.c"
      nm_copy_sd_core "src/libsystemd/sd-event/event-util.h"
      nm_copy_sd_core "src/libsystemd/sd-event/sd-event.c"
      nm_copy_sd_core "src/libsystemd/sd-id128/id128-util.c"
      nm_copy_sd_core "src/libsystemd/sd-id128/id128-util.h"
      nm_copy_sd_core "src/libsystemd/sd-id128/sd-id128.c"
      nm_copy_sd_core "src/systemd/_sd-common.h"
      nm_copy_sd_core "src/systemd/sd-dhcp-client.h"
      nm_copy_sd_core "src/systemd/sd-dhcp-lease.h"
      nm_copy_sd_core "src/systemd/sd-dhcp6-client.h"
      nm_copy_sd_core "src/systemd/sd-dhcp6-lease.h"
      nm_copy_sd_core "src/systemd/sd-event.h"
      nm_copy_sd_core "src/systemd/sd-id128.h"
      nm_copy_sd_core "src/systemd/sd-ipv4acd.h"
      nm_copy_sd_core "src/systemd/sd-ipv4ll.h"
      nm_copy_sd_core "src/systemd/sd-lldp.h"
      nm_copy_sd_core "src/systemd/sd-ndisc.h"
      nm_copy_sd_nmutils "src/basic/unaligned.h"
      nm_copy_sd_shared "src/basic/alloc-util.c"
      nm_copy_sd_shared "src/basic/alloc-util.h"
      nm_copy_sd_shared "src/basic/async.h"
      nm_copy_sd_shared "src/basic/env-file.c"
      nm_copy_sd_shared "src/basic/env-file.h"
      nm_copy_sd_shared "src/basic/env-util.c"
      nm_copy_sd_shared "src/basic/env-util.h"
      nm_copy_sd_shared "src/basic/errno-util.h"
      nm_copy_sd_shared "src/basic/escape.c"
      nm_copy_sd_shared "src/basic/escape.h"
      nm_copy_sd_shared "src/basic/ether-addr-util.c"
      nm_copy_sd_shared "src/basic/ether-addr-util.h"
      nm_copy_sd_shared "src/basic/extract-word.c"
      nm_copy_sd_shared "src/basic/extract-word.h"
      nm_copy_sd_shared "src/basic/fd-util.c"
      nm_copy_sd_shared "src/basic/fd-util.h"
      nm_copy_sd_shared "src/basic/fileio.c"
      nm_copy_sd_shared "src/basic/fileio.h"
      nm_copy_sd_shared "src/basic/format-util.c"
      nm_copy_sd_shared "src/basic/format-util.h"
      nm_copy_sd_shared "src/basic/fs-util.c"
      nm_copy_sd_shared "src/basic/fs-util.h"
      nm_copy_sd_shared "src/basic/hash-funcs.c"
      nm_copy_sd_shared "src/basic/hash-funcs.h"
      nm_copy_sd_shared "src/basic/hashmap.c"
      nm_copy_sd_shared "src/basic/hashmap.h"
      nm_copy_sd_shared "src/basic/hexdecoct.c"
      nm_copy_sd_shared "src/basic/hexdecoct.h"
      nm_copy_sd_shared "src/basic/hostname-util.c"
      nm_copy_sd_shared "src/basic/hostname-util.h"
      nm_copy_sd_shared "src/basic/in-addr-util.c"
      nm_copy_sd_shared "src/basic/in-addr-util.h"
      nm_copy_sd_shared "src/basic/io-util.c"
      nm_copy_sd_shared "src/basic/io-util.h"
      nm_copy_sd_shared "src/basic/list.h"
      nm_copy_sd_shared "src/basic/log.h"
      nm_copy_sd_shared "src/basic/macro.h"
      nm_copy_sd_shared "src/basic/memory-util.c"
      nm_copy_sd_shared "src/basic/memory-util.h"
      nm_copy_sd_shared "src/basic/mempool.c"
      nm_copy_sd_shared "src/basic/mempool.h"
      nm_copy_sd_shared "src/basic/missing_fcntl.h"
      nm_copy_sd_shared "src/basic/missing_socket.h"
      nm_copy_sd_shared "src/basic/missing_stat.h"
      nm_copy_sd_shared "src/basic/missing_type.h"
      nm_copy_sd_shared "src/basic/parse-util.c"
      nm_copy_sd_shared "src/basic/parse-util.h"
      nm_copy_sd_shared "src/basic/path-util.c"
      nm_copy_sd_shared "src/basic/path-util.h"
      nm_copy_sd_shared "src/basic/prioq.c"
      nm_copy_sd_shared "src/basic/prioq.h"
      nm_copy_sd_shared "src/basic/process-util.c"
      nm_copy_sd_shared "src/basic/process-util.h"
      nm_copy_sd_shared "src/basic/random-util.c"
      nm_copy_sd_shared "src/basic/random-util.h"
      nm_copy_sd_shared "src/basic/set.h"
      nm_copy_sd_shared "src/basic/signal-util.h"
      nm_copy_sd_shared "src/basic/siphash24.h"
      nm_copy_sd_shared "src/basic/socket-util.c"
      nm_copy_sd_shared "src/basic/socket-util.h"
      nm_copy_sd_shared "src/basic/sort-util.h"
      nm_copy_sd_shared "src/basic/sparse-endian.h"
      nm_copy_sd_shared "src/basic/stat-util.c"
      nm_copy_sd_shared "src/basic/stat-util.h"
      nm_copy_sd_shared "src/basic/stdio-util.h"
      nm_copy_sd_shared "src/basic/string-table.c"
      nm_copy_sd_shared "src/basic/string-table.h"
      nm_copy_sd_shared "src/basic/string-util.c"
      nm_copy_sd_shared "src/basic/string-util.h"
      nm_copy_sd_shared "src/basic/strv.c"
      nm_copy_sd_shared "src/basic/strv.h"
      nm_copy_sd_shared "src/basic/strxcpyx.c"
      nm_copy_sd_shared "src/basic/strxcpyx.h"
      nm_copy_sd_shared "src/basic/time-util.c"
      nm_copy_sd_shared "src/basic/time-util.h"
      nm_copy_sd_shared "src/basic/tmpfile-util.c"
      nm_copy_sd_shared "src/basic/tmpfile-util.h"
      nm_copy_sd_shared "src/basic/umask-util.h"
      nm_copy_sd_shared "src/basic/utf8.c"
      nm_copy_sd_shared "src/basic/utf8.h"
      nm_copy_sd_shared "src/basic/util.c"
      nm_copy_sd_shared "src/basic/util.h"
      nm_copy_sd_shared "src/shared/dns-domain.c"
      nm_copy_sd_shared "src/shared/dns-domain.h"
      6a325673
    • Thomas Haller's avatar
      NEWS: update · ad50a445
      Thomas Haller authored
      ad50a445
    • Thomas Haller's avatar
      3d818d98
    • Thomas Haller's avatar
      7bd16e85
  4. 25 Jul, 2019 26 commits
    • Thomas Haller's avatar
      settings: fix priority for settings-storages for tombstones · df252a62
      Thomas Haller authored
      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.
      df252a62
    • Thomas Haller's avatar
      settings: no longer honor read-only flag to prevent modifying connection profiles · 8d3ead72
      Thomas Haller authored
      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).
      8d3ead72
    • Thomas Haller's avatar
      iwd: don't mark generated profiles as read-only · ce44e120
      Thomas Haller authored
      First of all, the generated profile also gets generated as keyfile to
      /run, thereby it looses the read-only flag (because this flag gets lost
      when storing the profile to keyfile).
      
      Second, I don't think we should artificially limit the capabilities
      of the generated profile. If the user chooses to modify/delete it, so
      just allow it.
      ce44e120
    • Thomas Haller's avatar
      settings: track profiles on disk that are shadowed by in-memory connections · 9eddf9fb
      Thomas Haller authored
      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.
      9eddf9fb
    • Thomas Haller's avatar
      settings: avoid adding a profile that would be hidden by an existing profile · c3bf51a9
      Thomas Haller authored
      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.
      c3bf51a9
    • Thomas Haller's avatar
    • Thomas Haller's avatar
      settings: refactor call to nm_settings_plugin_update_connection() in "nm-settings.c" · ea9627b9
      Thomas Haller authored
      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.
      ea9627b9
    • Thomas Haller's avatar
    • Thomas Haller's avatar
      settings: support storing "shadowed-storage" to .nmmeta files · 064544cc
      Thomas Haller authored
      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.
      064544cc
    • Thomas Haller's avatar
      settings: support storing "shadowed-storage" to [.nmmeta] section for keyfiles in /run · e3b5b1e6
      Thomas Haller authored
      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.
      e3b5b1e6
    • Thomas Haller's avatar
      settings: refactor handling of storages with meta-data/tombstones · aade7e53
      Thomas Haller authored
      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.
      aade7e53
    • Thomas Haller's avatar
      settings/trivial: rename NMS_KEYFILE_FILETYPE_NMLOADED to NMS_KEYFILE_FILETYPE_NMMETA · c7e2fe7d
      Thomas Haller authored
      This name is better suited for the file with extension ".nmmeta".
      c7e2fe7d
    • Thomas Haller's avatar
      settings/trivial: rename NM_SETTINGS_CONNECTION_PERSIST_MODE_DISK to... · e32d80ea
      Thomas Haller authored
      settings/trivial: rename NM_SETTINGS_CONNECTION_PERSIST_MODE_DISK to 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.
      e32d80ea
    • Thomas Haller's avatar
      examples: add examples/python/gi/nm-update2.py example script · 10353a99
      Thomas Haller authored
      This is useful for manually testing Update2() D-Bus API.
      10353a99
    • Thomas Haller's avatar
    • Thomas Haller's avatar
      examples: add examples/python/gi/nm-add-connection2.py example script · 360d26e2
      Thomas Haller authored
      This is useful for manually testing AddConnection2() D-Bus API.
      360d26e2
    • Thomas Haller's avatar
      cli: use nm_client_add_connection2() API from nmcli · 64c17871
      Thomas Haller authored
      Make use of the new API. Note that AddConnection2() covers all
      functionality of AddConnection() and AddConnectionUnsaved(). Let's
      only use one API for all.
      
      There is a minor downside to this patch: now nmcli requires
      libnm 1.20 API. Note that libnm's nm_client_add_connection2()
      makes an effort to avoid AddConnection2() under the hood to
      still work against older server versions. So, you can use nmcli
      with libnm 1.20 to talk to older versions of NetworkManager.
      
      But with this change nmcli strictly requires libnm 1.20. I think that is
      sensible because commonly nmcli requires a libnm version that is as new
      as itself.
      Also, the value of allowing nmcli to talk to older NetworkManager
      versions is during package upgrade (where the daemon might not be
      restarted). This is much less concern w.r.t. to updating the nmcli/libnm
      combo, which is commonly packaged together.
      64c17871
    • Thomas Haller's avatar
      core,libnm: add AddConnection2() D-Bus API to block autoconnect from the start · 22c8721f
      Thomas Haller authored
      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
      22c8721f
    • Thomas Haller's avatar
      settings: add NM_SETTINGS_UPDATE2_FLAG_NO_REAPPLY to prevent runtime changes... · 0aa323fb
      Thomas Haller authored
      settings: add NM_SETTINGS_UPDATE2_FLAG_NO_REAPPLY to prevent runtime changes 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
      0aa323fb
    • Thomas Haller's avatar
      shared: add nm_g_slice_free() helper · dcdbe984
      Thomas Haller authored
      How odd that such a macro does not exist yet. It seems like
      the majorities of calls to g_slice_free() could be replaced
      by this.
      dcdbe984
    • Thomas Haller's avatar
    • Lubomir Rintel's avatar
      12d9ef4c
    • Lubomir Rintel's avatar
    • Lubomir Rintel's avatar
    • Lubomir Rintel's avatar
      6cf390eb
    • Lubomir Rintel's avatar
      merge: branch 'lr/wpa-ft' · 3cfe3c0e
      Lubomir Rintel authored
      !6
      3cfe3c0e