nm_connection_dump is mainly used for printf debugging, so
no need about being overly critical about not accepting NULL.
Just don't dump anything.
Signed-off-by: Thomas Haller <thaller@redhat.com>
When settings are NULL or empty in impl_manager_add_and_activate_connection(),
the connection is created and completed by nm_utils_complete_generic() or
nm_device_complete_connection().
Also, do not assert in nm_connection_is_type(). Returning FALSE there is
sufficient.
Related commit a878cd8145
Use the new NMConnection 'changed' signal to mark connections
as dirty/unsaved, and reset that when they get flushed to disk.
Previously, the 'Updated' signal was emitted only when the
connection was changed and flushed to disk, but now we have
more granular needs, and the signal is emitted whenever the
connection actually *is* changed, regardless of whether its
flushed to disk or not.
4d326182 changed connection hashing slightly such that now base type settings
are always returned even if they are empty. Unfortunately a bunch of code in
the settings hashed connections with the ONLY_SECRETS flag and then checked
whether the returned hash was NULL or not to determine whether there were
any secrets, and then called nm_connection_update_secrets() with the hash.
nm_connection_update_secrets() would fail in the case where a setting
name was given, but the passed-in secrets hash did not contain any secrets
for the requested setting. Instead, the function should return success
to match the semantics of passing in an entire connection hash which may
not have any secrets either.
When 'connection' and 'new_connection' arguments are the same object make the
function no-op and simply return true. Otherwise 'connection's settings are
removed, making it invalid.
Signed-off-by: Jiří Klimeš <jklimes@redhat.com>
The various need_secrets() implementation do allocate a fresh GPtrArray, but
add static strings to them without dup'ing. Thus callers must _not_ free the
array elements, only the array itself. Adjust documentation and annotations
accordingly.
Also adjust the corresponding comment in the goi-list-connections.py example.
https://bugzilla.gnome.org/show_bug.cgi?id=698175
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.
