nm_connection_provider_get_connections returns an internally kept
constant list to simplify handling for the users. Do not cache this
list in a static variable, instead put it in a private field.
Signed-off-by: Thomas Haller <thaller@redhat.com>
Plugin owns the object and callers must reference it if they wish to use it outside
of the function they called "add" from. Likewise, callers of the ConnectionProvider's
add_connection method must also reference the returned object if they wish to
continue using it.
ifcfg-rh had the rule that if an ifcfg file had no BOOTPROTO and no
IPv4 addresses, then it should be treated as method=auto for
compatibility. But in fact, current ifup treats it as method=disabled,
so we should too.
https://bugzilla.gnome.org/show_bug.cgi?id=708875
Make sure that all connections returned from NMSettings or created via
AddAndActivateConnection have an NMSettingIP4Config and an
NMSettingIP6Config, with non-NULL methods, and get rid of
now-unnecessary checks for those.
Also move the slaves-can't-have-IP-config checks into the
platform-independent code as well. This also gets rid of spurious
"ignoring IP4/IP6 configuration" warnings in ifcfg-rh when reading a
slave ifcfg file.
Partly based on a patch from Pavel.
https://bugzilla.gnome.org/show_bug.cgi?id=708875
connection_from_file() requires the 'error' parameter. Not passing a
valid 'error' parameter causes the function to fail and return NULL,
which mean that commit_changes() would always re-write the connection
instead of ignoring commits where nothing has actually changed.
connection_from_file() no longer requires the unmanaged, keyfile,
or routefile parameters, so remove them.
This method returns true, if the connections are already loaded (and the
connection_loaded signal already emited).
Signed-off-by: Thomas Haller <thaller@redhat.com>
The problem is that there is only a single variable in ifcfg file holding dns
domains - DOMAIN. Thus NetworkManager writes both IPv4 and IPv6 dns-search into
it. While reading there is no way to distinguish between IPv4 and IPv6 values,
so the DOMAIN value is read and only put into IPv4 dns-search.
But, when IPv4 is disabled or invalid, the domains got lost. So in such case
we put DOMAIN variable into IPv6 instead.
https://bugzilla.redhat.com/show_bug.cgi?id=1004866
Routes without gateway are legal and should be treated as a device route
(direct route).
https://bugzilla.gnome.org/show_bug.cgi?id=697525
The original patch was written by Scott Shambarger <scott-gnome@shambarger.net>.
This is a modified version of the patch.
Signed-off-by: Thomas Haller <thaller@redhat.com>
Reported-by: Scott Shambarger <scott-gnome@shambarger.net>
Since Debian 7 (Wheezy) / Ubuntu 11.04 (Natty Narwhal) ifupdown supports
the source stanza to source in other configuration files from
/etc/network/interfaces.
Add support to the ifupdown plugin to include configuration files via
source.
Patch did not apply cleanly and was slightly modified by Thomas Haller.
https://bugzilla.gnome.org/show_bug.cgi?id=707276
Signed-off-by: Thomas Haller <thaller@redhat.com>
Reviewed-by: Sebastian Harl <tokkee@debian.org>
Old clients might expect 802-11-wireless.security being set for secured Wi-Fi
connections. So to be on a safer side, we set the property in D-Bus GetSettings()
result.
This fixes a glib assertion:
"dbus_g_proxy_cancel_call: assertion `pending != NULL' failed"
Backtrace:
#0 0x00007f962dad9e0d in g_logv () from /lib64/libglib-2.0.so.0
#1 0x00007f962dad9ff2 in g_log () from /lib64/libglib-2.0.so.0
#2 0x00000000004a84bd in nm_secret_agent_cancel_secrets (self=0x213b300, call=0x1) at settings/nm-secret-agent.c:331
#3 0x00000000004a4068 in request_free (req=0x216a490) at settings/nm-agent-manager.c:479
#4 0x00007f962dac25fa in g_hash_table_remove_internal () from /lib64/libglib-2.0.so.0
Signed-off-by: Thomas Haller <thaller@redhat.com>
This also slighly changes the behaviour for writing IPV6_DEFAULTGW.
- IPV6_DEFAULTGW will be written after IPV6ADDR and
IPV6ADDR_SECONDARY.
- Before, if there were no IPv6 addresse present, the IPV6_DEFAULTGW
might not have been cleared. Now IPV6_DEFAULTGW is always written
(or unset as in the case of gateway ::).
https://bugzilla.redhat.com/show_bug.cgi?id=997759
Signed-off-by: Thomas Haller <thaller@redhat.com>
Unfortunately, $(AM_CPPFLAGS) gets overridden by per-target _CPPFLAGS
variables, which $(INCLUDES) did not, so this requires some additional
changes.
In most places, I have just gotten rid of the per-target _CPPFLAGS
variables; in directories with a single target, the per-target
variable is unnecessary, and in directories with multiple targets, the
per-target variable is often undesirable, since it forces some files
to be compiled twice, even though there ends up being no difference
between the two files.
If BOOTPROTO is set to "none", user states that no ipv4 setting should
be set. So respect that.
Introduce helper is_any_ip4_address_defined() along the way to make the
code more readable.
Signed-off-by: Jiri Pirko <jiri@resnulli.us>
In nm_keyfile_plugin_connection_from_file(), disable the "bad owner"
check.
As root you can read all files anyway, or if necessary even chown them,
and for
other users the standard file permissions will do a fine job.
This fixes running "make check" as root.
https://bugzilla.gnome.org/show_bug.cgi?id=701112
Plugins that could save connections to disk previously depended on inotify
events from the kernel to know when to signal connection removal; that is
in response to a 'delete' request they would unlink the backing filesystem
resources, get the inotify signal, and cause NM_SETTINGS_CONNECTION_REMOVED
to be emitted.
Unsaved connections don't have any backing resources, so they would never
get the signal emitted, and NMSettings would never forget about them.
Also, when monitor-connection-files=false in the configuration, obviously
the inotify signals will never come in because they aren't set up.
Given that we can no longer rely on inotify, it's best to just explicitly
send out the NM_SETTINGS_CONNECTION_REMOVED signal whenever a connection
is deleted via the D-Bus interface or internally.
The initscripts do this:
MATCH='^.+\.[0-9]{1,4}$'
if [[ "${DEVICE}" =~ $MATCH ]]; then
VID=$(echo "${DEVICE}" | LC_ALL=C sed 's/^.*\.\([0-9]\+\)/\1/')
PHYSDEV=${DEVICE%.*}
fi
MATCH='^vlan[0-9]{1,4}?'
if [[ "${DEVICE}" =~ $MATCH ]]; then
VID=$(echo "${DEVICE}" | LC_ALL=C sed 's/^vlan0*//')
# PHYSDEV should be set in ifcfg-vlan* file
if test -z "$PHYSDEV"; then
net_log $"PHYSDEV should be set for device ${DEVICE}"
exit 1
fi
fi
which means that if the VLAN name starts with "vlan" then
PHYSDEV must be set, otherwise the parent interface cannot
be determined.
Since PHYSDEV, if set, reflects the explicit intentions of the
user instead of assuming the name from DEVICE, make PHYSDEV
take precedence over determining the parent interface from
heuristics.
If the agent has dropped off the bus then its proxy may already
be destroyed, so we'll get warnings when trying to make method
calls using it. Track proxy destruction and warn if we try to
use a destroyed proxy.
Turns out this function is useless, because it's only called when the
agent has dropped off the bus or when the whole request is being
freed. If the agent has dropped off the bus then there's no point
in asking it to cancel the request because there's nothing to ask.
So we can collapse request_cancel() into request_free().
If all agents can handle VPN hints, then we'll try to use
ConnectInteractive() to let the VPN plugin ask for secrets
interactively via the SecretsRequired signal. These hints
are then passed to agents during the connection process if
the plugin needs more secrets or different secrets, and when
the new secrets are returned, they are passed back to the VPN
plugin.
If at least one agent does not have the VPN hints capability,
we can't use ConnectInteractive(), but fall back to the old
Connect call, because that agent won't be able to send the
hints to the VPN plugin's authentication dialog, and thus
we won't get back the secrets the VPN plugin is looking for.
So, for interactive secrets to work correctly, you need:
1) A VPN plugin updated for interactive secrets requests
2) NM updated for interactive secrets requests
3) all agents to set the VPN_HINTS capability when
registering with NetworkManager and to pass hints
along to the VPN authentication dialog
4) a VPN authentication dialog updated to look for hints
and only return secrets corresponding to the hints
requested by the plugin
