Pain with newest up2date RPM's

[Justin Clift]

Hi guys,

Either way, with everything I'm seeing here from the command line it's 
indicating that up2date (cli version) isn't even using the proxy settings.

If I specify things with the --proxy --proxyUser and --proxyPassword 
command line options, I get the exact same error message from up2date as 
if I don't... even if I purposely alter the proxy settings to point to a 
host that doesn't have a proxy on it.

Alternatively, using Mozilla (that does correctly use our proxy), I can 
read the file that up2date is trying to get to, with no problems.

Having a central configuration file is nice and all... but it doesn't 
matter if the program itself doesn't work.

:-(

Regards and best wishes,

Justin Clift


Panu Matilainen wrote:
> On Wed, 5 Nov 2003, Daniel Veillard wrote:
> 
> 
>>On Wed, Nov 05, 2003 at 01:25:20PM +0200, Panu Matilainen wrote:
>>
>>>On Wed, 5 Nov 2003, Daniel Veillard wrote:
>>>Would be a major lobbying effort to get every (relevant) internet-aware 
>>>program to agree using a single proxy configuration location + format of 
>>>course.. but would be well worth the effort I think. Ok Gnome2 has a 
>>>common place to speficy it but that's "hidden" in gconf instead of a plain 
>>>old textfile making it not-so-nice for things like wget etc. 
>>
>>  the historical way has been the http_proxy environment variable.
> 
> 
> Sure, most commandline (and many other programs as well) support 
> http_proxy, but then there are gazillion of things which don't, and 
> for autoproxy configuration there's no similar thing so you end up parsing 
> your autoproxy config into /etc/profile.d/proxy.sh & the like.. Of course 
> whether an application supports autoproxy configuration is an different 
> issue entirely.
> 
> 
>>>>I will investigate the proxy setting interface since I saw a bugzilla
>>>>bug about this.
>>>
>>>Since up2date and rhn-applet are so closely related (at least seemingly so 
>>>to the user) it'd be nice if at least those would share the settings..
>>
>>  we are trying to solve the issue. But one program runs as root,
>>the other under the user account, there have been security issues which
>>historically led to have separate file,
> 
> 
> /etc/sysconfig/rhn/up2date might've well been non-world readable if memory 
> serves, if that's what you mean. 
> 
> 	- Panu -
> 
> 
> --
> fedora-test-list mailing list
> fedora-test-list at redhat.com
> http://www.redhat.com/mailman/listinfo/fedora-test-list


-- 
Snowmen fall from Heaven unassembled.