Convenience function to replace settings in one conneciton with settings
from another, without having to go through the nm_connection_to_hash()
steps, which are just inefficient and kinda pointless.
The setting names used when inserting a setting into the hash
table are const since they are derived from GObject internals,
so there's no need to strdup them.
Add a "need_carrier" argument to nm_device_is_available(), to allow
distinguishing between "device is not available", "device is fully
available", and "device is available except for not having carrier".
Adjust various parts of NMDevice and NMManager to allow for the
possibility of activating a connection with :carrier-detect = "no" on
a device with no carrier, and to avoid auto-disconnecting devices with
:carrier-detect = "on-activate".
https://bugzilla.gnome.org/show_bug.cgi?id=688284
24cda2bc broke the ability to set NMConnection:path back to NULL after
it had been set, as part of a hack to try to make
NMRemoteConnection:dbus-path work. Fix that by moving the hack
entirely into NMRemoteConnection.
https://bugzilla.gnome.org/show_bug.cgi?id=693829
In order to resolve NMRemoteConnection-valued properties, NMObject
needs to be able to create NMRemoteConnections. But NMObject assumes
that all the objects it will be creating have "dbus-connection" and
"dbus-path" properties. So add those properties to NMRemoteConnection,
aliasing the existing "bus" and "path" properties (and ensure that
whichever version gets set, we keep that value, rather than letting it
get overwritten by the NULL default value of the other one).
https://bugzilla.gnome.org/show_bug.cgi?id=693669
Make setting type registration less icky; instead of having the
connection register all the settings, have the settings themselves
register that information at library load time. Putting this sort
of thing in G_DEFINE_TYPE_WITH_CODE is apparently more standard
than the home-rolled stuff we had before. Also document the
priority stuff so when adding new settings, people know what
priority to use.
(cleanups by jklimes)
Rather than generating enum classes by hand (and complaining in each
file that "this should really be standard"), use glib-mkenums.
Unfortunately, we need a very new version of glib-mkenums in order to
deal with NM's naming conventions and to fix a few other bugs, so just
import that into the source tree temporarily.
Also, to simplify the use of glib-mkenums, import Makefile.glib from
https://bugzilla.gnome.org/654395.
To avoid having to run glib-mkenums for every subdirectory of src/,
add a new "generated" directory, and put the generated enums files
there.
Finally, use Makefile.glib for marshallers too, and generate separate
ones for libnm-glib and NetworkManager.
Some connection types such as bonding, bridging and VLAN require
specific virtual kernel interfaces identified by name to be auto
connected to the connection.
The function nm_connection_get_virtual_iface_name() returns the name
of the kernel interface if the connection type requires this
functionatlity.
Each connection base type settings class can implement the function
get_virtual_iface_name() if the connection needs to be auto connected
to a specific kernel interface.
Signed-off-by: Thomas Graf <tgraf@redhat.com>
Introduced a new TYPE=bond for ifcfg-rh configuration files.
Alternatively BONDING_MASTER=yes can be specified instead of
setting the type explicitely to maintain backwards compatibility
with existing configuration files.
Bonding device files require a DEVICE= line to be present which
specifies the virtual bonding interface in the kernel. We do not
allow auto-generation of the name in order to keep confusion to
a minimum when reusing existing bonding interfaces.
The BONDING_OPTS= parameter can be used to specify various bonding
related options, such as:
- mode
- miimon
- updelay
- downdelay
- arp_interval
- arp_ip_target
By default, the NMSettingBond class uses a miimon value of 100 which
seems like a sensible default value for 99% of all configurations.
If this is not suitable, an arp_ip_target needs to be specified
manually.
A writer is not yet implemented.
Changes v2:
- renamed DeviceName property to InterfaceName
- moved code to validate device name to dev_valid_name() for future use
Signed-off-by: Thomas Graf <tgraf@redhat.com>
Adds a helper nm_connection_is_type(connection, type) which returns TRUE
if a connection is of specified type.
Signed-off-by: Thomas Graf <tgraf@redhat.com>
What we want to do here is keep separate caches of system and
agent secrets. For system secrets, we cache them because NM
periodically clears secrets using nm_connection_clear_secrets() to
ensure they don't stay around in memory, and that transient secrets
get requested again when they are needed. For agent secrets, we
only want them during activation, but a connection read from disk
will not include agent secrets becuase by definition they aren't
stored in system settings along with the connection. Thus we need
to keep the agent/transient secrets somewhere for the duration of
the activation to ensure they don't get deleted.
This removes the copy-back hack in update_auth_cb() which copied
agent/transient secrets back into the connection over top of the
transient secrets that had been copied back in
nm_settings_connection_replace_settings(). No reason to copy
them twice if we keep an agent/transient secrets hash and do
the right thing with it.
The core problem was that the Update would trigger a write to
disk to save the connection's new settings, which called
nm_settings_connection_replace_settings(). Which saved existing
transient (agent/unsaved) secrets, replaced settings with the
new ones from Update(), then copied back the old transient
secrets. This was to ensure that changes triggered from getting
agent secrets during activation (which might write the connection
out to disk if new system secrets were provided, which triggered
an inotify read-back of the connection, which blew away the
transient secrets just returned from the agent) didn't blow away
transient secrets. Unfortunately that fix was too general.
As a quick hack for now, copy the new secrets and re-apply them
after nm_connection_replace_settings() has run. We'll do the
actual fix later, but it's more involved and needs more testing
so we don't want to apply it this close to release.
Unfortunately, GObject Introspection can no longer describe deeper
types, like those inside nested hash tables, which NM uses extensively
for the NMConnection type and other places. So we have to remove
those descriptions. But this moves us back into compliance with
GOI annotation formats.
By 'base type' I mean a hardware-related type that can actually be used
to activate the connection, like wifi, wired, gsm, cdma, wimax, bluetooth,
etc, but not ipv4, ipv6, 8021x, etc.
It's easier to be able to pass both a whole hashed connection, or just
a hashed setting to the function, and have it figure out what needs
to be updated based on the given setting_name.
Add some testcases to make sure that all works correctly too.
The first-level hash table key should be the setting name itself,
not the GType name of the setting's GObject. There's probably a
better way to do this to reduce that confusion.
Simplifies code internally, and makes it easier for clients as well in
some cases where they want to control what ends up in the resulting
hash and what does not.
Add the necessary annotations (the mininum required, that is those
on return values. NULL parameters or container types may require
more), and the Autotools stuff to get a NetworkManager GIR for
libnm-util and a NMClient for libnm-glib.
