Remove the virtual :interface-name properties and their getters, and
use property overrides to do backward-compat handling when
serializing/deserializing.
Now when constructing an NMConnection from a hash, if the virtual
property is set and the NMSettingConnection property isn't, then the
override for NMSettingConnection:interface-name will set that property
to the value of the virtual interface-name. And when converting an
NMConnection to a hash, the overrides for the virtual properties will
return the value of NMSettingConnection:interface-name.
Simplify the use of _nm_register_setting() by having it splice
together various symbol names itself rather than requiring them to be
specified explicitly, and extend it to also ensure that the type's
corresponding error type is registered (allowing one to find it via
g_type_from_name() if necessary).
Add a method to determine if a connection applies to a virtual device.
Perhaps eventually the logic should be spread across the NMSetting
classes, but for now it's better off having it in NMConnection than
once in NMManager and once in nmcli.
The virtual :interface-name properties (eg,
NMDeviceBond:interface-name) are deprecated in favor of
NMSettingConnection:interface-name, and nm_connection_verify() ensures
that their values are kept in sync. So (a) there is no need to set
those properties when we can just set
NMSettingConnection:interface-name instead, and (b) we can replace any
calls to the setting-specific get_interface_name() methods with
nm_connection_get_interface_name() or
nm_setting_connection_get_interface_name().
Since we enforce the fact that bond, bridge, team, and vlan
interface-name properties match NMSettingConnection:interface-name,
nm_connection_get_virtual_iface_name() can be replaced with
nm_connection_get_interface_name() basically everywhere.
The one place this doesn't work is with InfiniBand partitions (where
get_virtual_iface_name() was actually computing the name), but for the
most part we only need to care about the interface names of InfiniBand
partitions in places where we also already need to do some other
InfiniBand-specific handling as well, so we can use an
InfiniBand-specific method
(nm_setting_infiniband_get_virtual_interface_name()) to get it.
(Also, while updating nm_device_get_virtual_device_description(), fix
it to handle InfiniBand partitions too.)
Drop the NMSetting properties that were marked deprecated in
libnm-util in 0.9.10, but use nm_setting_class_add_dbus_property() to
deal with them appropriately when serializing/deserializing.
Add _nm_setting_class_add_dbus_only_property(), for declaring
properties that appear in the D-Bus serialization, but which don't
correspond to GObject properties.
Since some property overrides will require examining settings other
than the setting that they are on (eg, the value of
802-11-wireless.security depends on whether an
NMSettingWirelessSecurity setting is present, and
NMSettingConnection:interface-name might sometimes be set from, eg,
bond.interface-name), we also update _nm_setting_to_dbus() to take the
full NMConnection as an argument, and _nm_setting_new_from_dbus() to
take the full connection hash.
Additionally, with some deprecated properties, we'll want to validate
them on construction, but we don't need to keep the value around after
that. So allow _nm_setting_new_from_dbus() to return a verification
error directly, so we don't need to store the value until the verify()
call.
On failure, nm_connection_replace_settings() would leave the
connection in an undefined state. Fix it so that either (a) the
settings are replaced and the resulting connection is valid and we
return TRUE, or (b) the connection is untouched and we return FALSE
and an error. (And add a test case for this.)
Reorganize _nm_setting_new_from_dbus() to create an empty NMSetting
first and then set each of its properties, rather than passing all of
the properties to g_object_newv(). We don't need to pass them at
construct time since no NMSetting properties are CONSTRUCT_ONLY, and
organizing the function this way is a prereq for some later
functionality (being able to run code when a property *isn't* present
in the hash).
Rename nm_connection_to_hash() to nm_connection_to_dbus(), and
nm_connection_new_from_hash() to nm_connection_new_from_dbus(). In
addition to clarifying that this is specifically the D-Bus
serialization format, these names will also work better in the
GDBus-based future where the serialization format is GVariant, not
GHashTable.
Also, move NMSettingHashFlags to nm-connection.h, and rename it
NMConnectionSerializationFlags.
Make nm_setting_to_hash() and nm_setting_new_from_hash() private, and
remove the public nm_setting_update_secrets() wrapper around the
existing private _nm_setting_update_secrets().
These functions should really only be called from the corresponding
NMConnection-level methods, and in particular, with certain
compatibility properties in the future, we will need to consider the
entire connection all at once when setting properties, so it won't
make sense to serialize/deserialize a single setting in isolation.
g_object_class_list_properties() can't return NULL if called
correctly.
Also remove two failed attempts to use g_value_transform():
nm_setting_new_from_hash() was transforming src_value to its own type
(rather than to param_spec->value_type, which was presumably
intended), so it was a no-op (in addition to being unnecessary anyway,
since GObject will attempt to transform the value internally if
needed). And update_one_secret() was calling g_value_transform() on an
uninitialized GValue, so it would have always hit a
g_return_val_if_fail() in g_value_transform() if that code was ever
reached (which apparently it wasn't).
generate-plugin-docs.pl was assuming that it was being run out of
srcdir, and so failed in srcdir!=builddir builds (such as "make
distcheck"). Fix that.
Also, update .gitignore
In the specific case that triggered this bug, both eth0 and eth0.123
existed and were configured before NM started, and a valid saved connection
existed for eth0.123. eth0 was ordered before eth0.123 in the Platform's
link list. When the end of add_devices() was reached for eth0 and
system_create_virtual_devices() was called, NM created an NMDevice for
the pre-existing eth0.123 link due to the saved connection, and
ignored the existing configuration because system_create_virtual_device()
re-calls add_device() with generate_con = FALSE.
Instead, we should allow system_create_virtual_device() to call add_device()
with generate_con = TRUE if the interface existed before NM created it. We
only want to skip connection assumption if the device was actually just
created by NM, in which case it cannot have any configuration to assume.
This didn't previously matter because BT/WWAN/WiFi/ADSL can't easily
assume existing connections due to the external helpers involved, but
when we converted Team support to a plugin we now want to allow this.
Instead of handling iBFT (iSCSI Boot Firmware Table) in the ifcfg-rh plugin,
create a new plugin for it. This allows all distributions to use iBFT
configuration, and makes both iBFT handling and ifcfg-rh less complicated.
The plugin (like the old ifcfg-rh code) creates read-only connections backed
by the data exported by iscsiadm. The plugin does not support adding new
connections or modifying existing connections (since the iBFT data is
read-only anyway). Instead, users should change their iBFT data through
the normal firmware interfaces.
Unmanaged devices can be configured through NetworkManager.conf and the
normal 'keyfile' mechanisms.
(In the future, we'll read this data directly from the kernel's
/sys/firmware/ibft/ethernetX directory instead of iscsiadm, since the
kernel has all the information we need and that's where iscsiadm gets
it from anyway.)
https://bugzilla.gnome.org/show_bug.cgi?id=734009
Even if we never receive an RA, if there are manually-specified or external
addresses, consider IPv6 to complete successfully. No reason to fail IPv6
if we have IP configuration already, but RA doesn't respond. If RA shows
up again, we're still listening for it and will apply the config at that
time.
Reporter left SLAAC enabled (because it's default and requires being
explicitly turned off) and added manual IPv6 address. They expected that
address to be assigned very soon after starting the connection, but it was
not assigned.
This happened because NM waits for RA before assigning any IPv6 configuration,
including the manually specified addresses. In the reporters case, there was
no IPv6 router on the network, so NM waited indefinitely for a router
advertisement and never applied any IPv6 configuration.
It seems reasonable to apply any IPv6 configuration we have available, when
we have it. We already apply RA configuration before starting DHCP, and
apply DHCP configuration if/when we get that.
The IPv4 pre-commit hook was called right before the config was
committed, while the IPv6 one was called before commit in only
one case (from nm_device_activate_ip6_config_commit). The IPv4
behavior is the intended behavior.
Note that this doesn't have any actual effect yet, since nothing
actually implements the IPv6 pre-commit hook
The module is used for building man pages by generate-plugin-docs.pl script.
1c2174a libnm-util: generate-plugin-docs.pl script for extracting plugin docs
man/nm-settings-keyfile.xml is generated via an XSLT stylesheet applied to
libnm-util/nm-keyfile-docs.xml. Then a manual page is generated from the XML.
The scripts extracts plugin description from document comments for particular
properties and builds a XML file out of the data. The XML file can be used
later for generating manual pages or other documentation.
Unfortunately, gtk-doc won't allow descriptions that would be separated from
the main gtk-doc stuff. But it is still useful to have plugin description bits
co-located with property definitions. We use our home-grown comments and parse
them ourself. Afterall it's not that bad, and in addition it brings us a
freedom in shaping the comments to our needs.
by disconnecting signal handlers in dispose().
Commit 6a19e68a moved nm_connection_clear_secrets() from plugins' finalize() to
NMSettingsConnection's dispose(). But clearing secrets emits "changed" signal
which cause changed_cb() to be called and emit_updated() scheduled. And
emit_updated() was called later after finalize() on released object.
The crash can be invoked by having two keyfile connection files with the same
uuid in them.
Backtrace:
(NetworkManager:12262): GLib-GObject-WARNING **: attempt to retrieve private data for invalid type 'NMSettingsConnection'
Program received signal SIGSEGV, Segmentation fault.
emit_updated (self=0xf38dd0 [NMSettingConnection]) at settings/nm-settings-connection.c:401
401 NM_SETTINGS_CONNECTION_GET_PRIVATE (self)->updated_idle_id = 0;
(gdb) bt
#0 emit_updated (self=0xf38dd0 [NMSettingConnection]) at settings/nm-settings-connection.c:401
#1 0x0000003c49647825 in g_main_dispatch (context=0x785970) at gmain.c:2539
#2 g_main_context_dispatch (context=context@entry=0x785970) at gmain.c:3075
#3 0x0000003c49647b58 in g_main_context_iterate (context=0x785970, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3146
#4 0x0000003c49647f52 in g_main_loop_run (loop=0x7857c0) at gmain.c:3340
#5 0x000000000042d4e9 in main (argc=1, argv=0x7fffffffe508) at main.c:679
When you first click "Add" in an address list, it adds a new field,
and the "Add" button becomes insensitive (because the new field is
empty, and thus not valid). But if you then clicked "Remove", "Add"
stayed insensitive. Fix that.
When switching to and fro old branches, you end up with
the (now removed) libgsystem submodule. As `git clean -fd`
refuses to remove git-repositories, this is especially annoying.
Tell git to ignore it.
Signed-off-by: Thomas Haller <thaller@redhat.com>
This wpa_supplicant option is not named "private_key_passwd2". Looks
like this regressed in e5ed391f28.
Signed-off-by: Geoffrey Thomas <gthomas@mokafive.com>
