1. 23 Sep, 2019 1 commit
    • Thomas Haller's avatar
      bluetooth: refactor BlueZ handling and let NMBluezManager cache ObjectManager data · 4154d961
      Thomas Haller authored
      This is a complete refactoring of the bluetooth code.
      
      Now that BlueZ 4 support was dropped, the separation of NMBluezManager
      and NMBluez5Manager makes no sense. They should be merged.
      
      At that point, notice that BlueZ 5's D-Bus API is fully centered around
      D-Bus's ObjectManager interface. Using that interface, we basically only
      call GetManagedObjects() once and register to InterfacesAdded,
      InterfacesRemoved and PropertiesChanged signals. There is no need to
      fetch individual properties ever.
      
      Note how NMBluezDevice used to query the D-Bus properties itself by
      creating a GDBusProxy. This is redundant, because when using the ObjectManager
      interfaces, we have all information already.
      
      Instead, let NMBluezManager basically become the client-side cache of
      all of BlueZ's ObjectManager interface. NMBluezDevice was mostly concerned
      about caching the D-Bus interface's state, tracking suitable profiles
      (pan_connection), and moderate between bluez and NMDeviceBt.
      These tasks don't get simpler by moving them to a seprate file. Let them
      also be handled by NMBluezManager.
      
      I mean, just look how it was previously: NMBluez5Manager registers to
      ObjectManager interface and sees a device appearing. It creates a
      NMBluezDevice object and registers to its "initialized" and
      "notify:usable" signal. In the meantime, NMBluezDevice fetches the
      relevant information from D-Bus (although it was already present in the
      data provided by the ObjectManager) and eventually emits these usable
      and initialized signals.
      Then, NMBlue5Manager emits a "bdaddr-added" signal, for which NMBluezManager
      creates the NMDeviceBt instance. NMBluezManager, NMBluez5Manager and
      NMBluezDevice are strongly cooperating to the point that it is simpler
      to merge them.
      
      This is not mere refactoring. This patch aims to make everything
      asynchronously and always cancellable. Also, it aims to fix races
      and inconsistencies of the state.
      
      - Registering to a NAP server now waits for the response and delays
        activation of the NMDeviceBridge accordingly.
      
      - For NAP connections we now watch the bnep0 interface in platform, and tear
        down the device when it goes away. Bluez doesn't send us a notification
        on D-Bus in that case.
      
      - Rework establishing a DUN connection. It no longer uses blocking
        connect() and does not block until rfcomm device appears. It's
        all async now. It also watches the rfcomm file descriptor for
        POLLERR/POLLHUP to notice disconnect.
      
      - drop nm_device_factory_emit_component_added() and instead let
        NMDeviceBt directly register to the WWan factory's "added" signal.
      4154d961
  2. 03 Sep, 2019 2 commits
  3. 15 Aug, 2019 2 commits
  4. 12 Aug, 2019 1 commit
  5. 15 Jul, 2019 1 commit
  6. 10 Jul, 2019 1 commit
  7. 29 Jun, 2019 1 commit
  8. 20 Jun, 2019 1 commit
    • Thomas Haller's avatar
      settings: drop ibft settings plugin · 74641be8
      Thomas Haller authored
      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
      74641be8
  9. 11 Jun, 2019 1 commit
    • Thomas Haller's avatar
      all: drop emacs file variables from source files · c0e075c9
      Thomas Haller authored
      We no longer add these. If you use Emacs, configure it yourself.
      
      Also, due to our "smart-tab" usage the editor anyway does a subpar
      job handling our tabs. However, on the upside every user can choose
      whatever tab-width he/she prefers. If "smart-tabs" are used properly
      (like we do), every tab-width will work.
      
      No manual changes, just ran commands:
      
          F=($(git grep -l -e '-\*-'))
          sed '1 { /\/\* *-\*-  *[mM]ode.*\*\/$/d }'     -i "${F[@]}"
          sed '1,4 { /^\(#\|--\|dnl\) *-\*- [mM]ode/d }' -i "${F[@]}"
      
      Check remaining lines with:
      
          git grep -e '-\*-'
      
      The ultimate purpose of this is to cleanup our files and eventually use
      SPDX license identifiers. For that, first get rid of the boilerplate lines.
      c0e075c9
  10. 28 May, 2019 2 commits
  11. 27 May, 2019 1 commit
  12. 23 May, 2019 2 commits
    • Thomas Haller's avatar
      libnm: rework team handling of JSON config · 13f6f3a4
      Thomas Haller authored
      Completely refactor the team/JSON handling in libnm's NMSettingTeam and
      NMSettingTeamPort.
      
      - team handling was added as rh#1398925. The goal is to have a more
        convenient way to set properties than constructing JSON. This requires
        libnm to implement the hard task of parsing JSON (and exposing well-understood
        properties) and generating JSON (based on these "artificial" properties).
        But not only libnm. In particular nmcli and the D-Bus API must make this
        "simpler" API accessible.
      
      - since NMSettingTeam and NMSettingTeamPort are conceptually the same,
        add "libnm-core/nm-team-utils.h" and NMTeamSetting that tries to
        handle the similar code side-by-sdie.
        The setting classes now just delegate for everything to NMTeamSetting.
      
      - Previously, there was a very fuzzy understanding of the provided
        JSON config. Tighten that up, when setting a JSON config it
        regenerates/parses all other properties and tries to make the
        best of it. When modifying any abstraction property, the entire
        JSON config gets regenerated. In particular, don't try to merge
        existing JSON config with the new fields. If the user uses the
        abstraction API, then the entire JSON gets replaced.
      
        For example note that nm_setting_team_add_link_watcher() would not
        be reflected in the JSON config (a bug). That only accidentally worked
        because client would serializing the changed link watcher to
        GVariant/D-Bus, then NetworkManager would set it via g_object_set(),
        which would renerate the JSON, and finally persist it to disk. But
        as far as libnm is concerned, nm_setting_team_add_link_watcher() would
        bring the settings instance in an inconsistent state where JSON and
        the link watcher property disagree. Setting any property must
        immediately update both the JSON and the abstraction API.
      
      - when constucting a team setting from D-Bus, we would previously parse
        both "config" and abstraction properties. That is wrong. Since our
        settings plugins only support JSON, all information must be present
        in the JSON config anyway. So, when "config" is present, only the JSON
        must be parsed. In the best case, the other information is redudant and
        contributes nothing. In the worse case, they information differs
        (which might happen if the client version differs from the server
        version). As the settings plugin only supports JSON, it's wrong to
        consider redundant, differing information from D-Bus.
      
      - we now only convert string to JSON or back when needed. Previously,
        setting a property resulted in parsing several JSON multiple times
        (per property). All operations should now scale well and be reasonably
        efficient.
      
      - also the property-changed signals are now handled correctly. Since
        NMTeamSetting knows the current state of all attributes, it can emit
        the exact property changed signals for what changed.
      
      - we no longer use libjansson to generate the JSON. JSON is supposed
        to be a machine readable exchange format, hence a major goal is
        to be easily handled by applications. While parsing JSON is not so
        trivial, writing a well-known set of values to JSON is.
        The advantage is that when you build libnm without libjansson support,
        then we still can convert the artificial properties to JSON.
      
      - Requiring libjansson in libnm is a burden, because most of the time
        it is not needed (as most users don't create team configurations). With
        this change we only require it to parse the team settings (no longer to
        write them). It should be reasonably simple to use a more minimalistic
        JSON parser that is sufficient for us, so that we can get rid of the
        libjansson dependency (for libnm). This also avoids the pain that we have
        due to the symbol collision of libjansson and libjson-glib.
      
      https://bugzilla.redhat.com/show_bug.cgi?id=1691619
      13f6f3a4
    • Thomas Haller's avatar
      ifcfg-rh: don't check for errors reading team settings in ifcfg-rh · d31622a6
      Thomas Haller authored
      We have nm_setting_verify() for a purpose.
      
      The checks that ifcfg-rh reader does are either
      
        - redundant (and thus unnecessary)
      
        - wrong (and thus we cannot read valid settings)
      
        - should belong to libnm's nm_setting_verify().
      
      NMSettingTeam/NMSettingTeamPort are already very libraral and don't do
      almost any strict validation. Previously, ifcfg reader would be even more
      liberal. If there is totally invalid data in the profile, reading the profile
      should fail.
      d31622a6
  13. 15 May, 2019 2 commits
  14. 04 May, 2019 1 commit
  15. 01 May, 2019 2 commits
  16. 25 Apr, 2019 1 commit
  17. 20 Apr, 2019 2 commits
  18. 18 Apr, 2019 2 commits
    • Thomas Haller's avatar
      shared: move most of "shared/nm-utils" to "shared/nm-glib-aux" · d984b2ce
      Thomas Haller authored
      From the files under "shared/nm-utils" we build an internal library
      that provides glib-based helper utilities.
      
      Move the files of that basic library to a new subdirectory
      "shared/nm-glib-aux" and rename the helper library "libnm-core-base.la"
      to "libnm-glib-aux.la".
      
      Reasons:
      
       - the name "utils" is overused in our code-base. Everything's an
         "utils". Give this thing a more distinct name.
      
       - there were additional files under "shared/nm-utils", which are not
         part of this internal library "libnm-utils-base.la". All the files
         that are part of this library should be together in the same
         directory, but files that are not, should not be there.
      
       - the new name should better convey what this library is and what is isn't:
         it's a set of utilities and helper functions that extend glib with
         funcitonality that we commonly need.
      
      There are still some files left under "shared/nm-utils". They have less
      a unifying propose to be in their own directory, so I leave them there
      for now. But at least they are separate from "shared/nm-glib-aux",
      which has a very clear purpose.
      
      (cherry picked from commit 80db06f7)
      d984b2ce
    • Thomas Haller's avatar
      shared: move most of "shared/nm-utils" to "shared/nm-glib-aux" · 80db06f7
      Thomas Haller authored
      From the files under "shared/nm-utils" we build an internal library
      that provides glib-based helper utilities.
      
      Move the files of that basic library to a new subdirectory
      "shared/nm-glib-aux" and rename the helper library "libnm-core-base.la"
      to "libnm-glib-aux.la".
      
      Reasons:
      
       - the name "utils" is overused in our code-base. Everything's an
         "utils". Give this thing a more distinct name.
      
       - there were additional files under "shared/nm-utils", which are not
         part of this internal library "libnm-utils-base.la". All the files
         that are part of this library should be together in the same
         directory, but files that are not, should not be there.
      
       - the new name should better convey what this library is and what is isn't:
         it's a set of utilities and helper functions that extend glib with
         funcitonality that we commonly need.
      
      There are still some files left under "shared/nm-utils". They have less
      a unifying propose to be in their own directory, so I leave them there
      for now. But at least they are separate from "shared/nm-glib-aux",
      which has a very clear purpose.
      80db06f7
  19. 17 Apr, 2019 2 commits
  20. 16 Apr, 2019 1 commit
    • Lubomir Rintel's avatar
      all: goodbye libnm-glib · 5801f89f
      Lubomir Rintel authored
      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
      5801f89f
  21. 15 Apr, 2019 2 commits
  22. 12 Apr, 2019 1 commit
  23. 06 Apr, 2019 1 commit
  24. 03 Apr, 2019 1 commit
  25. 02 Apr, 2019 1 commit
  26. 19 Mar, 2019 1 commit
    • Lubomir Rintel's avatar
      all: goodbye libnm-glib · 1de8383a
      Lubomir Rintel authored
      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
      1de8383a
  27. 26 Feb, 2019 2 commits
  28. 25 Feb, 2019 2 commits