1. 16 Jul, 2019 1 commit
    • Thomas Haller's avatar
      settings: rework tracking settings connections and settings plugins · d35d3c46
      Thomas Haller authored
      Completely rework how settings plugin handle connections and how
      NMSettings tracks the list of connections.
      
      Previously, settings plugins would return objects of (a subtype of) type
      NMSettingsConnection. The NMSettingsConnection was tightly coupled with
      the settings plugin. That has a lot of downsides.
      
      Change that. When changing this basic relation how settings connections
      are tracked, everything falls appart. That's why this is a huge change.
      Also, since I have to largely rewrite the settings plugins, I also
      added support for multiple keyfile directories, handle in-memory
      connections only by keyfile plugin and (partly) use copy-on-write NMConnection
      instances. I don't want to spend effort rewriting large parts while
      preserving the old way, that anyway should change. E.g. while rewriting ifcfg-rh,
      I don't want to let it handle in-memory connections because that's not right
      long-term.
      
      --
      
      If the settings plugins themself create subtypes of NMSettingsConnection
      instances, then a lot of knowledge about tracking connections moves
      to the plugins.
      Just try to follow the code what happend during nm_settings_add_connection().
      Note how the logic is spread out:
       - nm_settings_add_connection() calls plugin's add_connection()
       - add_connection() creates a NMSettingsConnection subtype
       - the plugin has to know that it's called during add-connection and
         not emit NM_SETTINGS_PLUGIN_CONNECTION_ADDED signal
       - NMSettings calls claim_connection() which hocks up the new
         NMSettingsConnection instance and configures the instance
         (like calling nm_settings_connection_added()).
      This summary does not sound like a lot, but try to follow that code. The logic
      is all over the place.
      
      Instead, settings plugins should have a very simple API for adding, modifying,
      deleting, loading and reloading connections. All the plugin does is to return a
      NMSettingsStorage handle. The storage instance is a handle to identify a profile
      in storage (e.g. a particular file). The settings plugin is free to subtype
      NMSettingsStorage, but it's not necessary.
      There are no more events raised, and the settings plugin implements the small
      API in a straightforward manner.
      NMSettings now drives all of this. Even NMSettingsConnection has now
      very little concern about how it's tracked and delegates only to NMSettings.
      
      This should make settings plugins simpler. Currently settings plugins
      are so cumbersome to implement, that we avoid having them. It should not be
      like that and it should be easy, beneficial and lightweight to create a new
      settings plugin.
      
      Note also how the settings plugins no longer care about duplicate UUIDs.
      Duplicated UUIDs are a fact of life and NMSettings must handle them. No
      need to overly concern settings plugins with that.
      
      --
      
      NMSettingsConnection is exposed directly on D-Bus (being a subtype of
      NMDBusObject) but it was also a GObject type provided by the settings
      plugin. Hence, it was not possible to migrate a profile from one plugin to
      another.
      However that would be useful when one profile does not support a
      connection type (like ifcfg-rh not supporting VPN). Currently such
      migration is not implemented except for migrating them to/from keyfile's
      run directory. The problem is that migrating profiles in general is
      complicated but in some cases it is important to do.
      
      For example checkpoint rollback should recreate the profile in the right
      settings plugin, not just add it to persistent storage. This is not yet
      properly implemented.
      
      --
      
      Previously, both keyfile and ifcfg-rh plugin implemented in-memory (unsaved)
      profiles, while ifupdown plugin cannot handle them. That meant duplication of code
      and a ifupdown profile could not be modified or made unsaved.
      This is now unified and only keyfile plugin handles in-memory profiles (bgo #744711).
      Also, NMSettings is aware of such profiles and treats them specially.
      In particular, NMSettings drives the migration between persistent and non-persistent
      storage.
      
      Note that a settings plugins may create truly generated, in-memory profiles.
      The settings plugin is free to generate and persist the profiles in any way it
      wishes. But the concept of "unsaved" profiles is now something explicitly handled
      by keyfile plugin. Also, these "unsaved" keyfile profiles are persisted to file system
      too, to the /run directory. This is great for two reasons: first of all, all
      profiles from keyfile storage in fact have a backing file -- even the
      unsaved ones. It also means you can create "unsaved" profiles in /run
      and load them with `nmcli connection load`, meaning there is a file
      based API for creating unsaved profiles.
      The other advantage is that these profiles now survive restarting
      NetworkManager. It's paramount that restarting the daemon is as
      non-disruptive as possible. Persisting unsaved files to /run improves
      here significantly.
      
      --
      
      In the past, NMSettingsConnection also implemented NMConnection interface.
      That was already changed a while ago and instead users call now
      nm_settings_connection_get_connection() to delegate to a
      NMSimpleConnection. What however still happened was that the NMConnection
      instance gets never swapped but instead the instance was modified with
      nm_connection_replace_settings_from_connection(), clear-secrets, etc.
      Change that and treat the NMConnection instance immutable. Instead of modifying
      it, reference/clone a new instance. This changes that previously when somebody
      wanted to keep a reference to an NMConnection, then the profile would be cloned.
      Now, it is supposed to be safe to reference the instance directly and everybody
      must ensure not to modify the instance. nmtst_connection_assert_unchanging()
      should help with that.
      The point is that the settings plugins may keep references to the
      NMConnection instance, and so does the NMSettingsConnection. We want
      to avoid cloning the instances as long as they are the same.
      Likewise, the device's applied connection can now also be referenced
      instead of cloning it. This is not yet done, and possibly there are
      further improvements possible.
      
      --
      
      Also implement multiple keyfile directores /usr/lib, /etc, /run (rh #1674545,
      bgo #772414).
      
      It was always the case that multiple files could provide the same UUID
      (both in case of keyfile and ifcfg-rh). For keyfile plugin, if a profile in
      read-only storage in /usr/lib gets modified, then it gets actually stored in
      /etc (or /run, if the profile is unsaved).
      
      --
      
      While at it, make /etc/network/interfaces profiles for ifupdown plugin reloadable.
      
      --
      
      https://bugzilla.gnome.org/show_bug.cgi?id=772414
      https://bugzilla.gnome.org/show_bug.cgi?id=744711
      https://bugzilla.redhat.com/show_bug.cgi?id=1674545
      d35d3c46
  2. 13 Jun, 2019 1 commit
  3. 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
  4. 06 Sep, 2018 3 commits
    • Thomas Haller's avatar
      settings: cleanup loading settings plugins · 0ea810fa
      Thomas Haller authored
      Drop the unnecessary @list argument and various cleanups.
      0ea810fa
    • Thomas Haller's avatar
      settings: make NMSettingsPlugin a regular GObject instance and not an interface · 657b0714
      Thomas Haller authored
      NMSettingsPlugin was a glib interface, not a regular GObject
      instance. Accordingly, settings plugins would implement this interface
      instead of subclassing a parent type.
      
      Refactor the code, and make NMSettingsPlugin a GObject type. Plugins
      are now required to subclass this type.
      
      Glib interfaces are more cumbersome than helpful. At least, unless
      there is a good reason for using them.
      
      Our settings plugins are all internal API and are entirely under
      our control. It also means, this change is fine, as there are no
      implementations outside of this source tree.
      
      Using interfaces do would allow more flexibility in implementing the
      settings plugin.
      For example, the plugin would be able to derive from any other GObject
      type, like NMKimchiRefrigerator. But why would we even? Let's not add monster
      classes that implement house appliances beside NMSettingsPluginInterface.
      The settings plugin should have one purpose only: being a settings plugin.
      Hence, requiring it to subclass NMSettingsPlugin is more than resonable. We
      don't need interfaces for this.
      
      Now that NMSettingsPlugin is a regular object instance, it may also have
      state, and potentially could provide common functionality for the plugin
      implementation -- if that turns out to be useful. Arguably, an interface can
      have state too, for example by attaching the state somewhere else (like
      NMConnection does). But let's just say no.
      
      On a minor note, this also avoids some tiny overhead that comes with
      glib interfaces.
      657b0714
    • Thomas Haller's avatar
      settings: rename NMSettingsPluginInterface.init() to initialize() · 194e7f8d
      Thomas Haller authored
      The virtual function init() naturally leads to calling the wrapper
      function nm_settings_plugin_init(). However, such ${TYPE}_init() functions
      are generated by G_DEFINE_TYPE().
      
      Rename to avoid the naming conflict, which will matter next, when the
      interface will be converted to a regular GObject class.
      
      Note that while these are settings plugin, there is no public
      or stable API which we need to preserve.
      194e7f8d
  5. 31 May, 2018 1 commit
  6. 30 Apr, 2018 1 commit
  7. 09 Mar, 2017 1 commit
    • Thomas Haller's avatar
      include: use double-quotes to include our own headers · 831286df
      Thomas Haller authored
      In practice, this should only matter when there are multiple
      header files with the same name. That is something we try
      to avoid already, by giving headers a distinct name.
      
      When building NetworkManager itself, we clearly want to use
      double-quotes for including our own headers.
      But we also want to do that in our public headers. For example:
      
        ./a.c
          #include <stdio.h>
          #include <nm-1.h>
          void main() {
              printf ("INCLUDED %s/nm-2.h\n", SYMB);
          }
      
        ./1/nm-1.h
          #include <nm-2.h>
      
        ./1/nm-2.h
          #define SYMB "1"
      
        ./2/nm-2.h
          #define SYMB "2"
      
      $ cc -I./2 -I./1 ./a.c
      $ ./a.out
      INCLUDED 2/nm-2.h
      
      Exceptions to this are
        - headers in "shared/nm-utils" that include <NetworkManager.h>. These
          headers are copied into projects and hence used like headers owned by
          those projects.
        - examples/C
      831286df
  8. 17 Aug, 2016 2 commits
    • Thomas Haller's avatar
      all: cleanup includes in header files · 0bdcab10
      Thomas Haller authored
      - don't include "nm-default.h" in header files. Every source file must
        include as first header "nm-default.h", thus our headers get the
        default include already implicitly.
      
      - we don't support compiling NetworkManager itself with a C++ compiler. Remove
        G_BEGIN_DECLS/G_END_DECLS from internal headers. We do however support
        users of libnm to use C++, thus they stay in public headers.
      
      (cherry picked from commit f19aff89)
      0bdcab10
    • Thomas Haller's avatar
      all: cleanup includes in header files · f19aff89
      Thomas Haller authored
      - don't include "nm-default.h" in header files. Every source file must
        include as first header "nm-default.h", thus our headers get the
        default include already implicitly.
      
      - we don't support compiling NetworkManager itself with a C++ compiler. Remove
        G_BEGIN_DECLS/G_END_DECLS from internal headers. We do however support
        users of libnm to use C++, thus they stay in public headers.
      f19aff89
  9. 10 Sep, 2015 3 commits
    • Dan Winship's avatar
      core: fix interface type names · 8e9f7820
      Dan Winship authored
      A GObject interface, like a class, has two different C types
      associated with it; the type of the "class" struct (eg, GObjectClass,
      GFileIface), and the type of instances of that class/interface (eg,
      GObject, GFile).
      
      NetworkManager was doing this wrong though, and using the same C type
      to point to both the interface's class struct and to instances of the
      interface. This ends up not actually breaking anything, since for
      interface types, the instance type is a non-dereferenceable dummy type
      anyway. But it's wrong, since if, eg, NMDeviceFactory is a struct type
      containing members "start", "device_added", etc, then you should not
      be using an NMDeviceFactory* to point to an object that does not
      contain those members.
      
      Fix this by splitting NMDeviceFactory into NMDeviceFactoryInterface
      and NMDeviceFactory; by splitting NMConnectionProvider into
      NMConnectionProviderInterface and NMConnectionProvider; and by
      splitting NMSettingsPlugin into NMSettingsPluginInterface and
      NMSettingsPlugin; and then use the right types in the right places.
      
      As a bonus, this also lets us now use G_DEFINE_INTERFACE.
      8e9f7820
    • Dan Winship's avatar
      settings: remove some NMSettingsPlugin cruft · b3d56e48
      Dan Winship authored
      b3d56e48
    • Dan Winship's avatar
      settings: trivial: rename NMSystemConfigInterface to NMSettingsPlugin · dfb77e3b
      Dan Winship authored
      Since there have not been separate system and user settings services
      since 0.8, the "system" in NMSystemConfigInterface is kind of
      meaningless. Rename it to NMSettingsPlugin, which describes what it
      does better.
      
      This is just:
      
          git mv src/settings/nm-system-config-interface.h src/settings/nm-settings-plugin.h
          git mv src/settings/nm-system-config-interface.c src/settings/nm-settings-plugin.c
          perl -pi -e 's/SystemConfigInterface/SettingsPlugin/g;' \
                   -e 's/system_config_interface/settings_plugin/g;' \
                   -e 's/system-config-interface/settings-plugin/g;' \
                   -e 's/SYSTEM_CONFIG_INTERFACE/SETTINGS_PLUGIN/g;' \
                   -e 's/sc_plugin/settings_plugin/g;' \
                   -e 's/SC_PLUGIN/SETTINGS_PLUGIN/g;' \
                   -e 's/SC_IS_PLUGIN/SETTINGS_IS_PLUGIN/g;' \
                   -e 's/SC_TYPE_PLUGIN/SETTINGS_TYPE_PLUGIN/g;' \
                   -e 's/SCPlugin/SettingsPlugin/g;' \
                   -e 's/nm_system_config_factory/nm_settings_plugin_factory/g;' \
               $(find src/settings -type f)
      
      (followed by some whitespace fixups in nm-settings-plugin.c, and a
      Makefile.am fix for the rename)
      dfb77e3b
  10. 05 Aug, 2015 1 commit
  11. 24 Jul, 2015 1 commit
    • Dan Winship's avatar
      all: rename nm-glib-compat.h to nm-glib.h, use everywhere · 3452ee2a
      Dan Winship authored
      Rather than randomly including one or more of <glib.h>,
      <glib-object.h>, and <gio/gio.h> everywhere (and forgetting to include
      "nm-glib-compat.h" most of the time), rename nm-glib-compat.h to
      nm-glib.h, include <gio/gio.h> from there, and then change all .c
      files in NM to include "nm-glib.h" rather than including the glib
      headers directly.
      
      (Public headers files still have to include the real glib headers,
      since nm-glib.h isn't installed...)
      
      Also, remove glib includes from header files that are already
      including a base object header file (which must itself already include
      the glib headers).
      3452ee2a
  12. 12 Jun, 2015 1 commit
  13. 16 Aug, 2014 1 commit
    • Dan Winship's avatar
      all: fix up multiple-include-guard defines · c81fb49a
      Dan Winship authored
      Previously, src/nm-ip4-config.h, libnm/nm-ip4-config.h, and
      libnm-glib/nm-ip4-config.h all used "NM_IP4_CONFIG_H" as an include
      guard, which meant that nm-test-utils.h could not tell which of them
      was being included (and so, eg, if you tried to include
      nm-ip4-config.h in a libnm test, it would fail to compile because
      nm-test-utils.h was referring to symbols in src/nm-ip4-config.h).
      
      Fix this by changing the include guards in the non-API-stable parts of
      the tree:
      
        - libnm-glib/nm-ip4-config.h remains   NM_IP4_CONFIG_H
        - libnm/nm-ip4-config.h now uses     __NM_IP4_CONFIG_H__
        - src/nm-ip4-config.h now uses       __NETWORKMANAGER_IP4_CONFIG_H__
      
      And likewise for all other headers.
      
      The two non-"nm"-prefixed headers, libnm/NetworkManager.h and
      src/NetworkManagerUtils.h are now __NETWORKMANAGER_H__ and
      __NETWORKMANAGER_UTILS_H__ respectively, which, while not entirely
      consistent with the general scheme, do still mostly make sense in
      isolation.
      c81fb49a
  14. 23 Jul, 2014 1 commit
    • Dan Winship's avatar
      core: fill in nm-types.h, clean out other headers · b28f6526
      Dan Winship authored
      Clean up some of the cross-includes between headers (which made it so
      that, eg, if you included NetworkManagerUtils.h in a test program, you
      would need to build the test with -I$(top_srcdir)/src/platform, and if
      you included nm-device.h you'd need $(POLKIT_CFLAGS)) by moving all
      GObject struct definitions for src/ and src/settings/ into nm-types.h
      (which already existed to solve the NMDevice/NMActRequest circular
      references).
      
      Update various .c files to explicitly include the headers they used to
      get implicitly, and remove some now-unnecessary -I options from
      Makefiles.
      b28f6526
  15. 23 Apr, 2014 1 commit
  16. 15 Nov, 2013 1 commit
  17. 01 Nov, 2013 1 commit
    • Dan Winship's avatar
      settings: add unrecognized-specs, implement in ifcfg-rh · e2137076
      Dan Winship authored
      In Fedora, OVS ports are now identified in ifcfg files as
      "TYPE=OVSPort", which NM doesn't recognize, and so it would ignore
      those ifcfg files. Unfortunately, this meant that if auto-default
      wasn't disabled, and there was no other configuration defined for the
      device, then NM would create an NMDefaultWiredConnection for it and
      screw things up.
      
      So, add an "unrecognized-specs" settings plugin property, which allows
      a plugin to indicate to NetworkManager that it knows of some
      non-NetworkManager-supported connection defined for a device. This
      will suppress default-wired connection creation for that device,
      similar to the "no-auto-default" config file option, but determined by
      the plugin instead of by manual configuration. Devices listed in
      unrecognized-specs may still be managed by NetworkManager, unless they
      are also listed in unmanaged-specs.
      
      https://bugzilla.redhat.com/show_bug.cgi?id=1022256
      e2137076
  18. 17 Oct, 2013 1 commit
  19. 14 Jun, 2013 1 commit
    • Dan Winship's avatar
      core: add monitor-connection-files=false and ReloadConnections · 1f818510
      Dan Winship authored
      Add a "monitor-connection-files" config option, which can be set to
      "false" to disable automatic reloading of connections on file change.
      
      To go with this, add a new ReloadConnections method on
      o.fd.NM.Settings that can be used to manually reload connections, and
      add an nm-cli command to call it.
      1f818510
  20. 28 May, 2013 1 commit
    • Dan Williams's avatar
      settings: implement ability to add connections without saving them to disk · 8a79fb1d
      Dan Williams authored
      We don't always want to immediately write new connections to disk, to
      facilitate "runtime" or "temporary" connections where an interface's
      runtime config isn't backed by on-disk config.  Also, just because
      an interface's configuration is changed doesn't necessarily mean
      that new configuration should be written to disk either.
      
      Add D-Bus methods for adding new connections and for updating existing
      connections that don't immediately save the connection to disk.
      
      Also add infrastructure to indicate to plugins that the new connection
      shouldn't be immediately saved if the connection was added with the
      new method.
      8a79fb1d
  21. 03 Apr, 2013 1 commit
  22. 16 Nov, 2011 1 commit
  23. 01 Feb, 2011 2 commits
  24. 26 Jan, 2011 1 commit
  25. 29 Oct, 2010 1 commit
  26. 28 Oct, 2010 1 commit
  27. 07 Aug, 2010 1 commit
    • Daniel Gnoutcheff's avatar
      remove nm-settings-connection-interface · 7f8dc06d
      Daniel Gnoutcheff authored
      NMSettingsConnectionInterface was created to allow the daemon and NM
      clients to have common code that handled both system and user
      connections. It's no longer needed now that user settings services are
      gone.
      
      This concludes the flattening of libnm-glib.
      7f8dc06d
  28. 18 Jun, 2010 1 commit
  29. 27 May, 2010 1 commit
  30. 26 May, 2010 1 commit
  31. 23 Jul, 2009 1 commit
    • Dan Williams's avatar
      libnm-glib: implement new settings interfaces · 0d69dfe3
      Dan Williams authored
      The old NMExportedConnection was used for both client and server-side classes,
      which was a mistake and made the code very complicated to follow.  Additionally,
      all PolicyKit operations were synchronous, and PK operations can block for a
      long time (ie for user input) before returning, so they need to be async.  But
      NMExportedConnection and NMSysconfigConnection didn't allow for async PK ops
      at all.
      
      Use this opportunity to clean up the mess and create GInterfaces that both
      server and client objects implement, so that the connection editor and applet
      can operate on generic objects like they did before (using the interfaces) but
      can perform specific operations (like async PK verification of callers) depending
      on whether they are local or remote or whatever.
      0d69dfe3
  32. 11 Jun, 2009 1 commit
  33. 03 Nov, 2008 1 commit
  34. 18 Sep, 2008 1 commit
    • Dan Williams's avatar
      2008-09-18 Dan Williams <dcbw@redhat.com> · 9d5a2291
      Dan Williams authored
      	Implement support for honoring configured and automatic hostnames, and for
      	setting the configured hostname.
      
      	* introspection/nm-ip4-config.xml
      	  src/nm-ip4-config.c
      	  src/nm-ip4-config.h
      	  src/dhcp-manager/nm-dhcp-manager.c
      		- Remove useless hostname property; it's not really part of the IPv4
      			config
      
      	* introspection/nm-settings-system.xml
      	  libnm-glib/nm-dbus-settings-system.c
      	  libnm-glib/nm-dbus-settings-system.h
      		- Add SetHostname() call to system settings D-Bus interface
      		- Add Hostname property to system settings D-Bus interface
      		- (nm_dbus_settings_system_save_hostname,
      		   nm_dbus_settings_system_get_hostname): implement
      
      	* src/nm-device.c
      	  src/nm-device.h
      		- (nm_device_get_dhcp4_config): implement
      
      	* src/nm-manager.c
      	  src/nm-manager.h
      		- Fetch and track system settings service hostname changes, and proxy
      			the changes via a GObject property of the manager
      
      	* system-settings/src/nm-system-config-interface.c
      	  system-settings/src/nm-system-config-interface.h
      		- Replace nm_system_config_interface_supports_add() with a capabilities
      			bitfield
      
      	* system-settings/src/nm-system-config-error.c
      	  system-settings/src/nm-system-config-error.h
      		- Add additional errors
      
      	* system-settings/src/dbus-settings.c
      	  system-settings/src/dbus-settings.h
      		- (get_property, nm_sysconfig_settings_class_init): add hostname
      			property; first plugin returning a hostname wins
      		- (impl_settings_add_connection): use plugin capabilities instead of
      			nm_system_config_interface_supports_add()
      		- (impl_settings_save_hostname): implement hostname saving
      
      	* src/NetworkManagerPolicy.c
      		- (lookup_thread_run_cb, lookup_thread_worker, lookup_thread_new,
      		   lookup_thread_die): implement an asynchronous hostname lookup thread
      			which given an IPv4 address tries to look up the hostname for that
      			address with reverse DNS
      		- (get_best_device): split out best device code from
      			update_routing_and_dns()
      		- (update_etc_hosts): update /etc/hosts with the machine's new hostname
      			to preserve the 127.0.0.1 reverse mapping that so many things require
      		- (set_system_hostname): set a given hostname
      		- (update_system_hostname): implement hostname policy; a configured
      			hostname (from the system settings service) is used if available,
      			otherwise an automatically determined hostname from DHCP, VPN, etc.
      			If there was no automatically determined hostname, reverse DNS of
      			the best device's IP address will be used, and as a last resort the
      			hostname 'localhost.localdomain' is set.
      		- (update_routing_and_dns): use get_best_device(); update the system
      			hostname when the network config changes
      		- (hostname_changed): update system hostname if the system settings
      			service signals a hostname change
      		- (nm_policy_new): list for system settings service hostname changes
      		- (nm_policy_destroy): ensure that an in-progress hostname lookup thread
      			gets told to die
      
      	* system-settings/plugins/keyfile/plugin.c
      	  system-settings/plugins/ifcfg-suse/plugin.c
      		- (get_property, sc_plugin_ifcfg_class_init): implement hostname and
      			capabilities properties
      
      	* system-settings/plugins/ifcfg-fedora/shvar.c
      		- (svOpenFile): re-enable R/W access of ifcfg files since the plugin
      			writes out /etc/sysconfig/network now
      
      	* system-settings/plugins/ifcfg-fedora/plugin.c
      		- (plugin_get_hostname): get hostname from /etc/sysconfig/network
      		- (plugin_set_hostname): save hostname to /etc/sysconfig/network
      		- (sc_network_changed_cb): handle changes to /etc/sysconfig/network
      		- (sc_plugin_ifcfg_init): monitor /etc/sysconfig/network for changes
      		- (get_property, set_property, sc_plugin_ifcfg_class_init): implement
      			hostname get/set and capabilities get
      
      
      
      git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@4077 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
      9d5a2291