NM09 branch

Lukáš Tinkl ltinkl at redhat.com
Wed May 25 13:02:00 CEST 2011


Dne St 25. května 2011 02:29:40 jste napsal(a): > Em Tuesday 24 May 2011, 
Lamarque Vieira Souza escreveu:
> > Em Thursday 19 May 2011, Ilia Kats escreveu:
> > > Hey,
> > > 
> > > thanks a lot for this. Just one question: could you get it to save
> > > secrets (I haven't compiled your source, just used it as reference)?
> > > Somehow I get the feeling that the SaveSecrets method isn't called at
> > > all when the connection is created. All kDebug which is in this method
> > > and also other methods from different classes that are called by
> > > SaveSecrets doesn't produce output at all. Also, I had a crash when
> > > calling methods from another class, which is used by both GetSecrets
> > > and SaveSecrets (the crash is fixed now), and kded crashed only when
> > > trying to edit the connection (GetSecrets got called), but not when
> > > the connection was created.
> > > 
> > > Or am I misunderstanding something? My understanding is that we pass
> > > the complete connection with secrets and secret flags to NM when
> > > creating the connection, and NM will then call SaveSecrets on the
> > > secret agent. Or do we have to call it ourselves?
> 
> 	I think we should call SaveSecret when creating a connection, but then we
> have a problem: Plasma NM is divided into four process: the kded module,
> the plasmoid (in plasma-desktop process), the kcm module and
> networkmanagement_configshell. Connections are created in the last two, but
> the agent run on behalf of the kded module. The kcm module and
> networkmanagementconfig_shell must call the kded module to save secrets. To
> make things worse NM guys deciced that the agent should not have a name on
> the bus, so we cannot call it directly. We can add another DBus interface
> in the kded module just to call the agent. This way we can avoid the
> secrets double saving problem in kcm module.
> 
> 	What seems to be happening is that after creating the connection the
> secrets are not being saved in the kwallet by us and neither by NM (by
> calling SaveSecrets). When activating the connection NM calls GetSecrets
> and that failed because the agent does not have the secrets. When we
> update the connection in kcm module NM finally calls SaveSecrets passing
> the secrets as parameters and the kded module saves them. We could also
> call updateConnection after creating it :-) That works, I have just tested
> it.

I just tested it, everything works fine, except activating a VPN connection. 
Furthermore, I'm getting a "No agent..." error message when trying to edit any 
connection. Strange thing is that those connections that contain a password 
display it correctly; I think that's because NM itself saves the pass.

In the VPN case, my guess is that we are not using the correct data type 
consistently for the data/secrets maps. They both have to be QStringMap, not 
QVariantMap/Map; in fact the whole connection is a QVariantMapMap but the last 
level is a QVariant of type QStringMap :) Tricky stuff, see:
https://bitbucket.org/caybro/knm9/src/ac430c8136dd/backend/NMSecretAgent.cpp
and
https://bitbucket.org/caybro/knm9/src/ac430c8136dd/backend/authdialogs/vpncauthdlg.cpp

Anyway thanks for all the hard work.
-- 
Lukáš Tinkl <ltinkl at redhat.com>
Software Engineer - Base Operating Systems Brno
KDE developer <lukas at kde.org>
Red Hat Inc.                               http://cz.redhat.com


More information about the kde-networkmanager mailing list