Bug 604317 - DBUS packagekitd not proxy-aware makes packaging system proxy-incompatible
DBUS packagekitd not proxy-aware makes packaging system proxy-incompatible
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: PackageKit (Show other bugs)
13
All Linux
low Severity medium
: ---
: ---
Assigned To: Richard Hughes
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-06-15 16:28 EDT by David Carlson
Modified: 2010-07-07 06:34 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-07-07 06:34:56 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
packagekitd with clean environment (62.10 KB, text/plain)
2010-06-16 09:52 EDT, David Carlson
no flags Details
packagekitd with forced proxy & tsocks (150.47 KB, text/plain)
2010-06-16 09:55 EDT, David Carlson
no flags Details
PackageKit.conf (9.82 KB, application/octet-stream)
2010-06-16 09:58 EDT, David Carlson
no flags Details
system call trace of yum from "clean" packagekitd (14.12 KB, application/octet-stream)
2010-06-16 09:59 EDT, David Carlson
no flags Details
packagekitd after being sent a correct SetProxy call (54.32 KB, text/plain)
2010-06-16 10:20 EDT, David Carlson
no flags Details

  None (edit)
Description David Carlson 2010-06-15 16:28:18 EDT
Description of problem:
packagekitd does not honor a proxy when opening urls


Version-Release number of selected component (if applicable):
PackageKit-0.6.4-1.fc13.x86_64 (will check latest released too)

How reproducible:
System inside proxy-only network

Steps to Reproduce:
1. Use a network with proxy access only
2. Log in and watch packagekitd sweat and block access to packaging system
  
Actual results:
No access to packaging system (without killing packagekitd).  pkcon hangs, so does any automatic action.

Expected results:
Packaging system working

Additional info:

I'm in a corporate environment where we have a simple web proxy (as well as a socks proxy) and other outgoing traffic is blocked.  I've added ProxyHTTP and ProxyFTP to /etc/PackageKit/PackageKit.conf and yum honors them.

However, whenever I'm trying to use the packaging system I have to kill packagekitd.  It blocks trying to query for automatic updates (which obviously don't work).  It blocked installing an automatic printer driver too.

I've forced the proxy environment variables onto packagekitd by a wrapper script (yes, SELinux is off) which I changed the packagekitd profile to point at:

. /etc/profile.d/proxy.sh
exec /usr/sbin/packagekitd

It doesn't help at all.  I might try tsocks too which should work.
Comment 1 Richard Hughes 2010-06-16 09:01:11 EDT
(In reply to comment #0)
> I'm in a corporate environment where we have a simple web proxy (as well as a
> socks proxy) and other outgoing traffic is blocked.  I've added ProxyHTTP and
> ProxyFTP to /etc/PackageKit/PackageKit.conf and yum honors them.

yum never looks at /etc/PackageKit/PackageKit.conf, that's only used by the daemon if there is no session proxy being set.

> It doesn't help at all.  I might try tsocks too which should work.    

PackageKit doesn't support SOCKS, or a .pac file, as the underlying backend (yum) also doesn't. You need to stick to http and ftp proxies.

It would be helpful to know the output from the daemon, and to make sure your session proxy settings are not being used. Can you do (as root):

killall packagekitd
/usr/sbin/packagekitd --verbose

And then try to get the daemon to block when downloading files. Then please attach the debug output as an attachment to this bug. Thanks.
Comment 2 David Carlson 2010-06-16 09:52:27 EDT
Created attachment 424456 [details]
packagekitd with clean environment

packagekitd with a clean environment (started with env -i).  The event is plugging in a printer, which causes the whole thing to hang.

an strace of the yum process will be attached which shows it's not talking to any proxies.
Comment 3 David Carlson 2010-06-16 09:55:56 EDT
Created attachment 424460 [details]
packagekitd with forced proxy & tsocks

packagekitd started with a forced environment:

LD_PRELOAD=libtsocks.so (which should in theory take over connect() )
PROXY=http://<proxy>:80
HTTPPROXY=http://<proxy>:80
http_proxy=http://<proxy>:80

A printer is plugged in and still hangs.
Comment 4 David Carlson 2010-06-16 09:58:22 EDT
Created attachment 424463 [details]
PackageKit.conf

PackageKit configuration.  

also of note I have NetworkManager off / network on because this is an always-connected workstation (which I wish was configurable at install/firstboot time).
Comment 5 David Carlson 2010-06-16 09:59:26 EDT
Created attachment 424465 [details]
system call trace of yum from "clean" packagekitd

trace from the yum process that's spawned when the printer is attached.
Comment 6 David Carlson 2010-06-16 10:20:47 EDT
Created attachment 424481 [details]
packagekitd after being sent a correct SetProxy call

I did this:

>>> import dbus
>>> sbus = dbus.SystemBus()
>>> pk_control = dbus.Interface( sbus.get_object('org.freedesktop.PackageKit', '/org/freedesktop/PackageKit', False), 'org.freedesktop.PackageKit' )
>>> pk_control.SetProxy('webproxy:80', 'webproxy:80')

Still hangs...
Comment 7 Richard Hughes 2010-06-16 11:06:58 EDT
(In reply to comment #3)
> Created an attachment (id=424460) [details]
> packagekitd with forced proxy & tsocks
> 
> packagekitd started with a forced environment:
> 
> LD_PRELOAD=libtsocks.so (which should in theory take over connect() )
> PROXY=http://<proxy>:80
> HTTPPROXY=http://<proxy>:80
> http_proxy=http://<proxy>:80

That's not going to work, as packagekitd does clearenv in the startup sequence. You could argue that's an antifeature in this case, and I might agree with you.

> I did this:
> >>> pk_control.SetProxy('webproxy:80', 'webproxy:80')

 - SetProxy method called: webproxy:80, webproxy:80
TI:09:17:01	FI:pk-dbus.c	FN:pk_dbus_get_session,198
 - failed to get session for 22717: Unable to lookup session information for process '22717'

You need to stick a mainloop or something in your test script, as PackageKit checks the owner, and if it's a short script the process that sent the SetProxy request might no longer be alive.

(In reply to comment #5)
> Created an attachment (id=424465) [details]
> system call trace of yum from "clean" packagekitd
> trace from the yum process that's spawned when the printer is attached.    

This shows the session sends a proxy of NULL, NULL for the two proxies. Ensure the proxy is set in the GNOME Network Proxy capplet.

Richard.
Comment 8 David Carlson 2010-06-16 11:49:43 EDT
Sort of solved.

GNOME was using a (my custom-made) PAC file that, for obvious reasons, didn't populate SetProxy(http_proxy, ftp_proxy).  Once I set it to a defined proxy for the whole protocol and bounced packagekitd it worked.

Although I'd argue that it is counterintuitive that /etc/packagekitd/PackageKit.conf does not effectively control the behavior of packagekitd, especially when a PAC file is set in GNOME.  The PAC file is actually required, so I'll have to switch between the two or something.
Comment 9 Richard Hughes 2010-06-18 11:22:35 EDT
Sure, you could argue that the proxy set in /etc/packagekitd/PackageKit.conf should overwrite your session settings, it's not exactly clear.

Could you send a mail to the packagekit mailing list, and we'll add some code and a new config option to support this. Thanks.
Comment 10 Richard Hughes 2010-07-07 06:34:56 EDT
commit b106454dfbd27056c891a42ea25172ebdbb2d656
Author: Richard Hughes <richard@hughsie.com>
Date:   Wed Jul 7 11:32:39 2010 +0100

    If either of ProxyHTTP are set in PackageKit.conf then silently ignore the user proxy setting. Fixes rh#604317

Note You need to log in before you can comment on or make changes to this bug.