1. 12 Feb, 2019 2 commits
  2. 14 Jan, 2019 2 commits
    • Beniamino Galvani's avatar
      dns: fail the plugin when the rate limiter hits · e4563665
      Beniamino Galvani authored
      If the child is respawning too fast, consider the plugin failed so
      that upstream servers are written to resolv.conf until the plugin gets
      restarted after the delay.
      e4563665
    • Beniamino Galvani's avatar
      dns: fix updating resolv.conf after dnsmasq process dies · f2a20127
      Beniamino Galvani authored
      When the dnsmasq process dies, two events are generated:
      
      (1) a NM_DNS_PLUGIN_FAILED signal in nm-dns-dnsmasq.c:name_owner_changed()
      (2) a NM_DNS_PLUGIN_CHILD_QUIT signal in nm-dns-plugin.c:from watch_cb()
      
      Event (1) is handled by updating resolv.conf with upstream servers,
      (2) by restarting the child process.
      
      The order in which the two signals are received is not deterministic,
      so when (1) comes after (2) the manager leaves upstream servers in
      resolv.conf even if a dnsmasq instance is running.
      
      When dnsmasq disappears from D-Bus and we know that the process is not
      running, we should not emit a FAILED signal because the disappearing
      is caused by the process termination, and that event is already
      handled by the manager.
      
      #105
      f2a20127
  3. 11 Dec, 2018 2 commits
  4. 13 Nov, 2018 1 commit
    • Thomas Haller's avatar
      all: cleanup GChecksum handling · eb9f950a
      Thomas Haller authored
      - prefer nm_auto_free_checksum over explicit free.
      - use nm_utils_checksum_get_digest*().
      - prefer defines for digest length.
      - assume g_checksum_new() cannot fail.
      eb9f950a
  5. 12 Nov, 2018 4 commits
  6. 12 Oct, 2018 1 commit
  7. 27 Sep, 2018 1 commit
  8. 26 Sep, 2018 2 commits
  9. 24 Sep, 2018 1 commit
    • Lubomir Rintel's avatar
      dns: allow loading nm-dns-systemd-resolve alongside other DNS plugins · d4eb4cb4
      Lubomir Rintel authored
      Even when the system resolver is configured to something else that
      systemd-resolved, it still is a good idea to keep systemd-resolved up to
      date. If not anything else, it does a good job at doing per-interface
      resolving for connectivity checks.
      
      If for whatever reasons don't want NetworkManager to push the DNS data
      it discovers to systemd-resolved, the functionality can be disabled
      with:
      
        [main]
        systemd-resolved=false
      d4eb4cb4
  10. 21 Sep, 2018 4 commits
    • Thomas Haller's avatar
      dns: fix creating resolv.conf content · 511709c5
      Thomas Haller authored
      g_string_new_len() allocates the buffer with length
      bytes. Maybe it should be obvious (wasn't to me), but
      if a init argument is given, that is taken as containing
      length bytes.
      
      So,
      
          str = g_string_new_len (init, len);
      
      is more like
      
          str = g_string_new_len (NULL, len);
          g_string_append_len (str, init, len);
      
      and not (how I wrongly thought)
      
          str = g_string_new_len (NULL, len);
          g_string_append (str, init);
      
      Fixes: 95b006c2
      511709c5
    • Thomas Haller's avatar
      dns: always write "/var/run/NetworkManager/resolv.conf" · cddb9132
      Thomas Haller authored
      Previously, if "main.rc-manager" was set to "unmanaged"
      and "/etc/resolv.conf" was symlink to our internal file
      "/var/run/NetworkManager/resolv.conf", NM would not rewrite
      the file, in an attempt to honor the requirement of NetworkManager
      not changing resolv.conf.
      
      No longer special case this. I think it was wrong and inconsistent.
      If the user specifies rc-manager unmanaged, he also should manage
      /etc/resolv.conf accordingly. And if the user decided to symlink
      it to our internal file, that is fine. It should not stop NM from
      updating that file.
      
      Also, this was the only cases, where NM would not write our internal
      resolv.conf (errors aside). It was inconsitent, and also not documented
      behavior. Instead, it is documented that `man NetworkManager.conf`:
      
        Regardless of this setting, NetworkManager will always write
        resolv.conf to its runtime state directory
        /var/run/NetworkManager/resolv.conf.
      cddb9132
    • Thomas Haller's avatar
      dns: write original DNS servers to /var/run/NetworkManager/no-stub-resolv.conf · 0dc673f0
      Thomas Haller authored
      When a DNS plugin is enabled (like "main.dns=dnsmasq" or "main.dns=systemd-resolved"),
      the name servers announced to the rc-manager are coerced to be 127.0.0.1
      or 127.0.0.53.
      
      Depending on the "main.rc-manager" setting, also "/etc/resolv.conf"
      contains only this coerced name server to the local caching service.
      The same is true for "/var/run/NetworkManager/resolv.conf" file, which
      contains what we would write to "/etc/resolv.conf" (depending on
      the "main.rc-manager" configuration).
      
      Write a new file "/var/run/NetworkManager/no-stub-resolv.conf", which contains
      the original name servers, uncoerced. Like "/var/run/NetworkManager/resolv.conf",
      this file is always written.
      
      The effect is, when one enables "main.dns=systemd-resolved", then there
      is still a file "no-stub-resolv.conf" with the same content as with
      "main.dns=default".
      
      The no-stub-resolv.conf may be a possible solution, when a user wants
      NetworkManager to update systemd-resolved, but still have a regular
      /etc/resolv.conf [1]. For that, the user could configure
      
          [main]
          dns=systemd-resolved
          rc-manager=unmanaged
      
      and symlink "/etc/resolv.conf" to "/var/run/NetworkManager/no-stub-resolv.conf".
      This is not necessarily the only solution for the problem and does not preclude
      options for updating systemd-resolved in combination with other DNS plugins.
      
      [1] #20
      0dc673f0
    • Thomas Haller's avatar
  11. 18 Sep, 2018 1 commit
  12. 13 Sep, 2018 4 commits
  13. 06 Sep, 2018 2 commits
    • Beniamino Galvani's avatar
      core: nm-ip4-config: consider dns-related differences as relevant · 6169cd57
      Beniamino Galvani authored
      The DNS manager reacts to NM_DEVICE_IP4_CONFIG_CHANGED events, which
      are generated when there is a relevant change to an IP4 configuration.
      
      Until now, changes to the mdns,llmnr properties were not
      considered relevant (and neither minor, this is already a bug).
      
      Promote them to relevant so that the DNS manager is notified and will
      rewrite the DNS configuration when one of this properties changes.
      
      Note that the DNS priority should be considered relevant and added
      into the checksum as well, but is a problem right now because in the
      DNS manager we rely on the fact that an empty configuration (i.e. just
      created) has a zero checksum. This is needed to avoid rewriting
      resolv.conf when there is no change. The DNS priority initial value
      depends on the connection type (VPN or not), so it's a bit difficult
      to add it to checksum maintaining the assumption of checksum(empty)=0.
      This should be improved in the future.
      6169cd57
    • Beniamino Galvani's avatar
      core: add support for connection.llmnr · bc7efc75
      Beniamino Galvani authored
      bc7efc75
  14. 11 Jul, 2018 1 commit
    • Thomas Haller's avatar
      all: don't use gchar/gshort/gint/glong but C types · e1c7a2b5
      Thomas Haller authored
      We commonly don't use the glib typedefs for char/short/int/long,
      but their C types directly.
      
          $ git grep '\<g\(char\|short\|int\|long\|float\|double\)\>' | wc -l
          587
          $ git grep '\<\(char\|short\|int\|long\|float\|double\)\>' | wc -l
          21114
      
      One could argue that using the glib typedefs is preferable in
      public API (of our glib based libnm library) or where it clearly
      is related to glib, like during
      
        g_object_set (obj, PROPERTY, (gint) value, NULL);
      
      However, that argument does not seem strong, because in practice we don't
      follow that argument today, and seldomly use the glib typedefs.
      Also, the style guide for this would be hard to formalize, because
      "using them where clearly related to a glib" is a very loose suggestion.
      
      Also note that glib typedefs will always just be typedefs of the
      underlying C types. There is no danger of glib changing the meaning
      of these typedefs (because that would be a major API break of glib).
      
      A simple style guide is instead: don't use these typedefs.
      
      No manual actions, I only ran the bash script:
      
        FILES=($(git ls-files '*.[hc]'))
        sed -i \
            -e 's/\<g\(char\|short\|int\|long\|float\|double\)\>\( [^ ]\)/\1\2/g' \
            -e 's/\<g\(char\|short\|int\|long\|float\|double\)\>  /\1   /g' \
            -e 's/\<g\(char\|short\|int\|long\|float\|double\)\>/\1/g' \
            "${FILES[@]}"
      e1c7a2b5
  15. 05 Jun, 2018 1 commit
    • Thomas Haller's avatar
      dns: change main.rc-manager=file behavior to always follow symlink · 644aa42f
      Thomas Haller authored
      With "main.rc-manager=file", if /etc/resolv.conf is a symlink, NetworkManager
      would follow the symlink and update the file instead.
      
      However, note that realpath() only returns a target, if the file actually
      exists. That means, if /etc/resolv.conf is a dangling symlink, NetworkManager
      would replace the symlink with a file.
      
      This was the only case in which NetworkManager would every change a symlink
      resolv.conf to a file. I think this is undesired behavior.
      
      This is a change in long established behavior. Although note that there were several
      changes regarding rc-manager settings in the past. See for example commit [1] and [2].
      
      Now, first still try using realpath() as before. Only if that fails, try
      to resolve /etc/resolv.conf as a symlink with readlink().
      
      Following the dangling symlink is likely not a problem for the user, it
      probably is even desired. The part that most likely can cause problems
      is if the destination file is not writable. That happens for example, if
      the destination's parent directories are missing. In this case, NetworkManager
      will now fail to write resolv.conf and log a warning. This has the potential of
      breaking existing setups, but it really is a mis-configuration from the user's
      side.
      
      This fixes for example the problem, if the user configures
      /etc/resolv.conf as symlink to /tmp/my-resolv.conf. At boot, the file
      would not exist, and NetworkManager would previously always replace the
      link with a plain file. Instead, it should follow the symlink and create
      the file.
      
      [1] 718fd224
      [2] 15177a34
      
      https://github.com/NetworkManager/NetworkManager/pull/127
      644aa42f
  16. 01 Jun, 2018 2 commits
  17. 26 May, 2018 1 commit
  18. 14 May, 2018 4 commits
  19. 30 Apr, 2018 1 commit
  20. 04 Apr, 2018 1 commit
  21. 27 Mar, 2018 2 commits
    • Thomas Haller's avatar
      all: use nm_utils_hash_keys_to_array() · e49a3293
      Thomas Haller authored
      e49a3293
    • Thomas Haller's avatar
      config: cleanup fields in NMGlobalDnsConfig · cd48bc74
      Thomas Haller authored
      - consistently set options, searches, domains fields to %NULL,
        if there are no values.
      
      - in nm_global_dns_config_update_checksum(), ensure that we uniquely
        hash values. E.g. a config with "searches[a], options=[b]" should
        hash differently from "searches=[ab], options=[]".
      
      - in nm_global_dns_config_to_dbus(), reuse the sorted domain list.
        We already have it, and it guarantees a consistent ordering of
        fields.
      
      - in global_dns_domain_from_dbus(), fix memleaks if D-Bus strdict
        contains duplicate entries.
      cd48bc74