[packagekit] Setting the proxy

Daniel Nicoletti dantti85-pk at yahoo.com.br
Fri Jul 17 05:39:27 PDT 2009


Hmmm I have thought about that some time ago,
and what I did (and actually the current KPackageKIT code is like):

setProxy(http, ftp)
do the task, like install, refresh.. update

so always right before the task I set the proxy, the disadvantages
happens when concurrent use of packagekitd which might end up
with the other user proxy.

I think this is the same case of setLocale()

In the end it might be a good idea to track sessions
on packagekitd so Locale, proxy and maybe others to
come don't get lost.

Ah another thing that I remembered was:
What if the user change it's proxy?
Maybe setting it every time in the GUI
(and maybe ignoring the call on packagekitd
if is the same as the last one) AND 
tracking the session might be the best plan.

Daniel.



----- Mensagem original ----
De: Richard Hughes <hughsient at gmail.com>
Para: PackageKit users and developers list <packagekit at lists.freedesktop.org>
Enviadas: Sexta-feira, 17 de Julho de 2009 8:46:57
Assunto: [packagekit] Setting the proxy

I've been debugging a problem with using different sessions, and using
a network proxy.

The issues are threefold:

* The session proxy setting is only set when the session process is
started, or when the gconf keys change
* The packagekitd does not save the proxies when it times out,
therefore, on next auto-start it's as if a proxy has never been set
* The proxy is systemwide, not tracked per-session

So, how to fix this properly... The key issue is that the SetProxy()
method is on the main interface, and not the transaction interface.
This means that if we have multiple sessions with different proxies,
then the proxy used is the last one set, which isn't ideal at all.

So, we have two solutions:

1. Track the session in packagekitd when the proxy gets set, and use
ConlsoleKit to get the session when we get the transaction method, and
choose the proxy based on that.

2. Break the API and move the SetProxy method to the transaction
interface, and then set the proxy on each method call. This fixes
things, but requires every application using PackageKit to also query
the proxy settings, which could quickly become tiresome, and also ties
us to a GConf dep in an otherwise GLib library.

The first has the disadvantage of calling into ConsoleKit for every
method, which adds some delay.
The second has the disadvantage of breaking API, and requiring normal
applications to track the proxy, or adding a GConf dep to the
PkControl instance.

I have chosen option 1 as this avoids breaking API and also doesn't
require clients to track the session proxy.

For the 0.4.x clients, I've patched GpkWatch (the part of
gpk-update-icon that sets the proxy) to re-set the proxy when
packagekitd re-appears on the bus. That should fix things in the
single user login case, but will suffer the over-write problem
mentioned earlier. I've spent yesterday evening writing up a plan of
action, and this
morning coding it up in PackageKit git master.

The implementation notes are here:
http://cgit.freedesktop.org/packagekit/plain/docs/setting-the-proxy.txt and the
security implication notes are here:
http://cgit.freedesktop.org/packagekit/plain/docs/security.txt

So, basically, using a proxy server using git head nor works reliably,
but before it was flaky. No client code has to change for kpackagekit
or packagekit-qt. I would appreciate some testing if you use a proxy,
or any code review. One thing I'm still not sure about is sending the
proxy username and password across the system DBus unencrypted, but I
figure for HTTP proxies it's sent over the network unencrypted anyway,
so this isn't a big deal. Ideas welcome.

Richard.
_______________________________________________
PackageKit mailing list
PackageKit at lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/packagekit



      ____________________________________________________________________________________
Veja quais são os assuntos do momento no Yahoo! +Buscados
http://br.maisbuscados.yahoo.com



More information about the PackageKit mailing list