We'll want to use NMActiveConnection more in the manager and also fold
the PendingActivation functionality into it. All this functionality
applies to the VPN connections too, so it makes sense to have it all
in the base class instead of both NMActRequest and NMVPNConnection.
Allows agents to provide different behavior depending on whether the
secrets request was initiated by a user (eg by picking a connection
from a UI menu or by 'nmcli con up') or was automatically started by
NetworkManager.
See https://bugzilla.gnome.org/show_bug.cgi?id=660293
Commit 217c5bf6ac fixed processing of unix
signals: signals are blocked in all threads and a dedicated thread handles the
signals using sigwait().
However, the commit forgot that child processes inherit signal mask as well.
That is why we have to unblock signals for child processes we spawn from NM, so
that they can receive signals.
We already have the master device kept in the active connection, so
we can just use that instead of having the Policy determine and set
it manually. This also should allow slaves to auto-activate their
master connections if the master is able to activate.
Track a master active connection and emit wait/ready/fail when
it changes state. This signal is intended for devices to
delay their activation until a master device is ready.
They are the basic class that tracks active connections, and we're
going to use them for connection dependencies. So use the fact that
both NMVPNConnection and NMActRequest have the same base class
instead of using object paths.
That was always the goal, but never got there. This time we need it
for real to abstract handling of dependent connections so bite the
bullet and make it happen.
Adds a new "master" property to NMActiveConnection containing the path
of the master NMDevice if the connection has a master.
Signed-off-by: Thomas Graf <tgraf@redhat.com>
A convenience so that clients which might key certain operations off
which connections are active (checking work mail only when on VPN for
example) can more easily get which connections are active. This would
allow those apps to store the UUID (which they would already be doing)
and not have to create a Connection proxy and then get the connection
properties just to retrieve the UUID of the connection. Instead they
can now get it from GetAll of the ActiveConnection object, which they
would already be doing.
It's the thing that owns the secrets anyway, and it simplifies things to
have the secrets handling there instead of half in NMActRequest and
half in NMManager. It also means we can get rid of the ugly signals
that NMSettingsConnection had to emit to get agent's secrets, and
we can consolidate the requests for the persistent secrets that the
NMSettingsConnection owned into NMSettingsConnection itself instead
of also in NMAgentManager.
Since the NMActRequest and the NMVPNConnection classes already tracked
the underlying NMSettingsConnection representing the activation, its
trivial to just have them ask the NMSettingsConnection for secrets
instead of talking to the NMAgentManager. Thus, only the
NMSettingsConnection now has to know about the agent manager, and it
presents a cleaner interface to other objects further up the chain,
instead of having bits of the secrets request splattered around the
activation request, the VPN connection, the NMManager, etc.
When a user makes an explicit request for secrets via GetSecrets
or activates a device, don't ask other users' agents for secrets.
Restrict secrets request to agents owned by the user that made the
initial activate or GetSecrets request.
Automatic activations still request secrets from any available agent.
Due to limitations in dbus-glib, where one GObject cannot have more
than one introspection XML object attached to it, we used to include
more than one <interface> in the VPNConnection object introspection
XML. This was suboptimal for two reasons:
1) it duplicated the Connection.Active introspection XML which
made it harder for clients to use the introspection data in a
dynamic fashion, besides looking ugly in the docs
2) not many other programs use this feature of dbus-glib, which
means it didn't get a lot of testing, and broke, which sucks
for NM.
To fix this issue, create a base class for NMVpnConnection that
handles the Connection.Active API, and make NMVpnConnection itself
handle just the VPN pieces that it layers on top. This makes
dbus-glib happy because we aren't using two <interface> blocks
in the same introspection XML, and it makes the NM code more
robust because we can re-use the existing Connection.Active
introspection XML in the NMVpnConnectionBase class.
Filter registered agents for each secrets request to ensure that the
connection for which secrets are requested is visible to that agent,
and add that agent to the queue. Ask each agent in the queue until
one returns usable secrets. Ensure that if new agents register
or existing agents quit during the secrets request, that the queue
is updated accordingly, and ensure that an agent that's already
been asked for secrets, unregisters, and re-registers before the
secrets request is comple, isn't asked for secrets twice.
Instead of a bizare mechanism of signals back to the manager
object that used to be required because of the user/system settings
split, let each place that needs secrets request those secrets
itself. This flattens the secrets request process a ton and
the code flow significantly.
Previously the get secrets flow was something like this:
nm_act_request_get_secrets ()
nm_secrets_provider_interface_get_secrets ()
emits manager-get-secrets signal
provider_get_secerts ()
system_get_secrets ()
system_get_secrets_idle_cb ()
nm_sysconfig_connection_get_secrets ()
system_get_secrets_reply_cb ()
nm_secrets_provider_interface_get_secrets_result ()
signal failure or success
now instead we do something like this:
nm_agent_manager_get_secrets ()
nm_agent_manager_get_secrets ()
request_start_secrets ()
nm_sysconfig_connection_get_secrets ()
return failure or success to callback
Remove all references to connection scope and user-settings services
from the various internal APIs of the daemon. The external DBus API
remains unchanged, albeit in stub form for scope stuff.
Commit 715ddd2045 broke sharing because
sometimes a multi-argument string gets passed in rule->rule. Revert
most of that commit. A bunch of cleanups by dcbw too.
Mark activation requests that contain connections to be assumed,
and use that to short-circuit various parts of the activation
process by not touching various device attributes, since they
are already set up. Also ensure the device is not deactivated
when it initially becomes managed, because that would kill the
connection we are about to assume.
The only thing that doesn't work yet is the system-settings service's
"auto eth" connections for ethernet devices that don't have an existing
connection. Might also have issues with unmanaged devices that can't
provide a MAC address until they are brought up, but we'll see.
Do connection sharing in a cleaner manner; all required iptables rules
are now stored in the activation request and pertain only to the device
which is being shared to other computers.
* src/nm-activation-request.c
src/nm-activation-request.h
- (nm_act_request_add_share_rule): new function; add a sharing rule to
the activation request which will get torn down automatically when
the activation request dies
- (nm_act_request_set_shared): push sharing rules to iptables when sharing
is started, and tear them down when sharing is stopped
* src/nm-device.c
- (start_sharing): start up sharing by doing the required iptables magic
- (share_init): poke the right bits of the kernel and load the right
modules for NAT
- (nm_device_activate_stage5_ip_config_commit): start NAT-ing this
connection if it's a 'shared' connection
* src/NetworkManagerPolicy.c
- Remove all sharing stuff; done in the device code itself
git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@3969 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
* src/nm-activation-request.c
src/vpn-manager/nm-vpn-connection.c
- Correct GetSecrets D-Bus pending call usage; the GetSecrets call
itself should be attached to the activation request or the VPN
connection, not the NMConnection object, since the call is not
expected to live as long as the NMConnection itself
git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@3880 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
Modify the NMDevice::state-changed signal to include the previous state
and reason. Enables the applet to provide more information why device
activation failed.
git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@3819 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
* introspection/nm-active-connection.xml
introspection/nm-vpn-connection.xml
libnm-glib/nm-active-connection.c
src/nm-activation-request.c
src/nm-active-connection.h
src/vpn-manager/nm-vpn-connection.c
- Remove "SharedServiceName" and "SharedConnection" bits from the D-Bus
and libnm-glib API since sharing didn't get implemented that way
git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@3797 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
Fix mobile broadband username/password issues. NM was never requesting
mobile broadband secrets, nor was it passing back the username and password
if it had them.
* marshallers/nm-marshal.list
- Add some new types for activation request objects
* src/nm-activation-request.c
src/nm-activation-request.h
- (get_secrets_cb): pass the caller type in the signal
- (nm_act_request_request_connection_secrets): take a caller type, so
that GetSecrets() reply handlers know who asked for the secrets in
the first place; use secret hints too so the settings service can
figure out exactly what NM wants (ie, PIN or the PPP password)
* src/ppp-manager/nm-ppp-manager.c
src/ppp-manager/nm-ppp-manager.h
- (impl_ppp_manager_need_secrets): nm_connection_need_secrets() won't
detect needed secrets when the secret could be blank, like GSM/CDMA
passwords. So always ask for secrets, and send a hint as to what
secret we really want.
- (nm_ppp_manager_update_secrets): make function more generic by making
the device specific class figure out the username and password, and
accept an error argument to return back over D-Bus
* src/nm-device-wifi.c
- (link_timeout_cb, handle_auth_or_fail): update for changes to
nm_act_request_request_connection_secrets()
- (real_connection_secrets_updated): update for 'caller' changes
* src/nm-device.c
src/nm-device.h
- (connection_secrets_updated_cb, connection_secrets_failed_cb): update
for 'caller' changes
* src/nm-device-ethernet.c
- (real_connection_secrets_updated): update for 'caller' changes and
move logic for getting PPPoE username and password here before
calling nm_ppp_manager_update_secrets()
- (link_timeout_cb, handle_auth_or_fail): update for changes to
nm_act_request_request_connection_secrets()
* src/nm-cdma-device.c
- (real_connection_secrets_updated): pass username and password back
to the PPP manager when required
* src/nm-gsm-device.c
- (enter_pin): send the required secret name to the settings service
- (real_connection_secrets_updated): pass username and password back
to the PPP manager when required
git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@3794 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
Add a GError argument to nm_connection_verify() and nm_setting_verify(),
and add error enums to each NMSetting subclass. Each NMSetting subclass now
returns a descriptive GError when verification fails.
git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@3751 4912f4e0-d625-0410-9fb7-b9a5a253dbdc