Bug 50891 - up2date produces an 'Not Implimented Error'
up2date produces an 'Not Implimented Error'
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: up2date (Show other bugs)
4.0
i386 Linux
high Severity high
: ---
: ---
Assigned To: Adrian Likins
Jay Turner
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-08-04 10:54 EDT by Chris Chabot
Modified: 2015-01-07 18:50 EST (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-09-06 14:34:32 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)

  None (edit)
Description Chris Chabot 2001-08-04 10:54:16 EDT
When running up2date, it provides me with the folowing error: (up2date -u)


# up2date -u

Retrieving list of all available packages...
There was a fatal error communicating with the server.  The message was:
501: "Not Implemented" while attempting to get 
$RHN/redhat-linux-i386-7.1.93/listPackages/20010802044353

I have attempted to clear all my system registrations, re-register the
system, but the error remains the same. 

btw. Is there an alternative method to download updates?
Comment 1 Mihai Ibanescu 2001-08-06 16:33:13 EDT
Could you send us a copy of your /etc/sysconfig/rhn/up2date?
It looks like a configuration problem, as far as I can tell given the error report.
Thanks.
Comment 2 Chris Chabot 2001-08-07 05:17:35 EDT
My /etc/sysconfig/rhn/up2date :

# Automatically generated Red Hat Update Agent config file, do not edit.
# Format: 1.0
noSSLServerURL[comment]=Remote server URL without SSL
noSSLServerURL=http://beta.rhns.redhat.com/XMLRPC

debug[comment]=Whether or not debugging is enabled
debug=0

noReplaceConfig[comment]=When selected, no packages that would change
configuration data are automatically installed
noReplaceConfig=1

retrieveOnly[comment]=Retrieve packages only
retrieveOnly=0

keepAfterInstall[comment]=Keep packages on disk after installation
keepAfterInstall=0

systemIdPath[comment]=Location of system id
systemIdPath=/etc/sysconfig/rhn/systemid

serverURL[comment]=Remote server URL
serverURL=https://beta.rhns.redhat.com/XMLRPC

pkgSkipList[comment]=A list of package names, optionally including wildcards, to
skip
pkgSkipList=kernel*;

adminAddress[comment]=List of e-mail addresses for update agent to communicate
with when run in batch mode
adminAddress=root@localhost;

storageDir[comment]=Where to store packages and other data when they are
retrieved
storageDir=/var/spool/up2date
fileSkipList[comment]=A list of file names, optionally including wildcards, to
skip
fileSkipList=;

removeSkipList[comment]=A list of package names, optionally including wildcards
that up2date will not remove
removeSkipList=kernel*;

enableProxy[comment]=Use a HTTP Proxy
enableProxy=0

retrieveSource[comment]=Retrieve source RPM along with binary package
retrieveSource=0

versionOverride[comment]=Override the automatically determined system version
versionOverride=

httpProxy[comment]=HTTP proxy in host:port format, e.g. squid.redhat.com:3128
httpProxy=

useGPG[comment]=Use GPG to verify package integrity
useGPG=1

noBootLoader[comment]=To disable modification of the boot loader (lilo, silo,
etc)
noBootLoader=0

networkRetries[comment]=Number of attempts to make at network connections before
giving up
networkRetries=5
Comment 3 Chris Chabot 2001-08-07 05:22:54 EDT
Ps, when i now try to run up2date, i get the following results ...
~the plot thickens~ 

# up2date -u
Error communicating with server.  The message was:
Internal Server Error
Comment 4 Jay Turner 2001-08-07 07:28:14 EDT
OK, the internal server error that you got was because we were going a cold
backup of the database that machine talks to.  As for the other errors, in
parsing through the error_logs, the only thing that I can see are several
anonymous request made against the site . . . any chance that you will have an
anonymous certificate on that machine that you are trying to run up2date on?
Comment 5 Chris Chabot 2001-08-08 17:45:45 EDT
To make sure i wasnt the anonymous request made against the site, i :

 - Removed my /etc/sysconfig/rhn/systemid (+.save)
 - Removed ALL systems from my rhns profile 
 - Re-registered my system, checked to see if it was listed and entitiled. It
was, version + info matched, and is entitiled (all on beta.rhns.redhat.com
ofcource).
  - Ran up2date -u, got the folowing (same) error:

# up2date -u

Retrieving list of all available packages...
There was a fatal error communicating with the server.  The message was:
501: "Not Implemented" while attempting to get 
$RHN/redhat-linux-i386-7.1.93/listPackages/20010802044353


(must admit i completely fail to see how this could fail, while up2date on all
my other boxes here is functioning, and i presume up2date does function for
other people in this public beta :P)

Comment 6 Chris Chabot 2001-08-08 17:57:11 EDT
Ok, i located the problem. On my firewall (rh linux 7.0 + 2.4 kernel + iptables)
i run a transparent Squid proxy

(basic: $IPTABLES -A PREROUTING -p tcp --dport 80 -t nat -j DNAT --to
192.168.0.3:3128), ie transparently redirect all HTTP requests thru the Squid proxy.

When i disable this feature, up2date functions again (!)

I personaly fail to see why this would upset xml-rpc (i presumed thats what
up2date uses), but its nice to know where its comming from :)

Will this be addressable or is this a permanent 'feature' ? Since many of my
server parks use the same style setups (transparent reverse proxies), and so do
many of the net-gateways i setup from clients, this could be a bit of a downner :)
Comment 7 Adrian Likins 2001-08-08 18:09:13 EDT
uhmm, hmm. Do you redirect ssl connections as well? 

As far as I know, the current version should be using a pretty standard
http 1.1 setup, so I'm not sure how this proxy arrangement effects that. 

Sounds like squid is returning the 501? Have to admit, I dont really
understand this setup, so dont really have a good idea if it's a "feature"
or a "bug". 

Is squid configured to disallow POSTs? Hows it setup to handle ssl connections?
Most of the traffic should be done via ssl, so that may be an issue. Also,
does the squid setup do any sort of header munging?

Kind of grasping at straws at the moment ;->
Comment 8 Chris Chabot 2001-08-08 18:23:23 EDT
> uhmm, hmm. Do you redirect ssl connections as well? 

No, (as shown in the IPTABLES line) i only redirect port 80 to the Squid proxy..
SSL mangling is beyond the point of fun :)

The Squid config is prety standard (Standard rh 7.0 config actualy, only changes
are done to allow the transparent proxy, and to restrict access to it so only
local network can reach it.

The Squid proxy wont affect any HTTPS connections, since its configured to only
do port 80 redirects, however it does do some header-modification for normal
HTTP requests (Check modified date, cache-flags etc from the server.. all the
normal proxy stuff), so in that, i can see it could affect the communications.
However it doesnt disallow POST's or anything @ all .. no site or functionality
on the net has given me problems yet :)

If i set the proxy server option in up2date-config, it does seem to work though!
(set entry to 192.168.0.3:3128, where the port 80 trafic is redirected to).

So this could function as a good work around for people with transparent proxies
(take the transparent out of the transparent-proxy :))


Comment 9 Chris Chabot 2001-08-08 18:27:49 EDT
FYI: short list of details on setting up transparent proxy using squid /
iptables can be found in the netfilter FAQ :
http://netfilter.samba.org/netfilter-faq-3.html#ss3.12

(the great thing of doing it this way is that clients dont need to be configured
to use the proxy, saves a lot of admin'ing)
Comment 10 Michael Young 2001-08-13 12:48:41 EDT
See bug 51641 - I thought it was a separate problem when I submitted it, but I
now think it may have the same cause as this bug.
Comment 11 Adrian Likins 2001-08-13 14:38:27 EDT
#51641 sounds like the root cause of this. the http gets will probabaly
fail in this case, where the xmlrpc will continue to function. Basically,
the http get stuff is slightly broken with regard to proxys. I'll 
probabaly just change the GETs (ie, rhnHTTPlib) to use the same proxy
handling code as xmlrpclib.

Havent dived in deep yet, but I'm pretty sure this is the cause (if not,
it's wrong anyway... ;-> )

Comment 12 Adrian Likins 2001-08-16 21:50:51 EDT
I belive we have a fix for this now.

Try grabbing the packages from:
http://people.redhat.com/jturner/software.html

and letting me know if this fixes the issue.
Comment 13 Chris Chabot 2001-08-16 22:50:00 EDT
Yes, this fixed it for me! 

I'm behind a transparent squid proxy server, so it would seem higly logical that
it should fix the problem for 'normal' squid users as well.

thnx !
Comment 14 Michael Young 2001-08-17 05:24:41 EDT
There are still problems for non-transparent proxy users. I get the following
when I try up2date -l

...
Retrieving list of all available packages...
Traceback (innermost last):
  File "/usr/sbin/up2date", line 1017, in ?
    main()
  File "/usr/sbin/up2date", line 365, in main
    sys.exit(batchRun(argObj.getLong("list"), pkgNames, fullUpdate))
  File "/usr/sbin/up2date", line 900, in batchRun
    printCallback, percentCallback)
  File "/usr/sbin/up2date", line 813, in runInteractive
    progressCallback = percentCallback)
  File "/usr/share/rhn/up2date_client/up2date.py", line 1371, in
getUpdatedPackageList
    pkgList = getAvailablePackageList(msgCallback,progressCallback)
  File "/usr/share/rhn/up2date_client/up2date.py", line 637, in
getAvailablePackageList
    progressCallback = progressCallback )
  File "/usr/share/rhn/up2date_client/up2date.py", line 284, in doCall
    ret = apply(method, args, kwargs)
  File "/usr/share/rhn/up2date_client/rpmSource.py", line 128, in listPackages
    channelList = source.listPackages(channel, version, msgCallback,
progressCallback)
  File "/usr/share/rhn/up2date_client/rpmSource.py", line 503, in listPackages
    size,fd = self.s.listPackages(channel, version)
  File "/usr/lib/python1.5/site-packages/xmlrpclib.py", line 683, in __call__
    return self.__send(self.__name, args)
  File "/usr/share/rhn/up2date_client/rhnHTTPlib.py", line 257, in __request
    self.__protocol)
  File "/usr/share/rhn/up2date_client/rhnHTTPlib.py", line 122, in request
    h.putrequest("GET", "%s/%s" % (handler, req))
  File "/usr/lib/python1.5/httplib.py", line 98, in putrequest
    self.send(str)
  File "/usr/lib/python1.5/httplib.py", line 86, in send
    self.sock.send(str)
AttributeError: sock
Comment 15 Mihai Ibanescu 2001-08-17 11:06:58 EDT
I think this comes from a busted python-xmlrpc library, that we have fixed
lately (but not sure if it made it into Roswell). Could you please send the
output of

rpm -q python-xmlrpc

Thanks.
Comment 16 Michael Young 2001-08-17 11:34:05 EDT
Roswell has python-xmlrpc-1.4.5-0.7.x
Comment 17 Mihai Ibanescu 2001-08-17 14:20:19 EDT
Okay, go to http://people.redhat.com/jturner/software.html and grab the latest
python-xmlrpc (1.4.7). This should fix the latest reported problem.
Comment 18 Michael Young 2001-08-20 04:56:00 EDT
That seems to work, though up2date -l prints a lot of hashes and then doesn't
find any packages to download, despite what the web interface to
beta.rhns.redhat.com says.
However I think this is a server issue - eg. the downloaded file
/var/spool/up2date/redhat-linux-i386-7.1.93.20010816062823 lists the alchemist
version as 1.0.8-2 (the version on the roswell discs) whereas the web interface
says that a version 1.0.13-1 is available. Incidentally, there is a minor bug in
the python-xmlrpc-1.4.7-1 package mentioned above, in that the documentation is
in /usr/doc rather than /usr/share/doc .
Comment 19 Mihai Ibanescu 2001-08-20 11:24:56 EDT
Okay, the package versions should be fixed now (the database was out of sync
with the ftp site).

About the python-xmlrpc bug you mentioned: it's because the package was compiled
for Red Hat 6.x which uses /usr/doc instead of /usr/share/doc. The solution to
install that package was really interim. We'll provide a 7.x version of
python-xmlrpc.
Comment 20 Michael Young 2001-08-20 12:33:13 EDT
Yes, downloading and installing packages does now work.
Comment 21 Jay Turner 2001-08-20 13:35:24 EDT
Good, closing out this issue now.
Comment 22 Tommy McNeely 2001-08-20 14:56:52 EDT
Could sombody summarize what needs to be done to fix this? just download that
version of xmlrpc?

I am behind a tranpearant webcache that I have no control over. Maybe there is a
way we could hi port 8080 or 81 or something... just a little change to the
/etc/sysconfig/rhn files??

Tommy
Comment 23 Tommy McNeely 2001-08-20 15:20:34 EDT
[root@kyle tommy]# rpm -q up2date up2date-gnome python-xmlrpc
up2date-2.6.0-7.x.31
up2date-gnome-2.6.0-7.x.31
python-xmlrpc-1.4.7-1
[root@kyle tommy]# up2date --nox --list

For this beta release of Red Hat Linux, the up2date program has been
configured to point to a different Red Hat Network server.  This server
(beta.rhns.redhat.com) can be used to obtain updated packages for the
duration of this Red Hat Linux beta test ONLY.  After the beta test has been
completed, this Red Hat Network server will no longer be available for use.


Retrieving list of all available packages...
Traceback (innermost last):
  File "/usr/sbin/up2date", line 1017, in ?
    main()
  File "/usr/sbin/up2date", line 365, in main
    sys.exit(batchRun(argObj.getLong("list"), pkgNames, fullUpdate))
  File "/usr/sbin/up2date", line 900, in batchRun
    printCallback, percentCallback)
  File "/usr/sbin/up2date", line 813, in runInteractive
    progressCallback = percentCallback)
  File "/usr/share/rhn/up2date_client/up2date.py", line 1371, in
getUpdatedPackageList
    pkgList = getAvailablePackageList(msgCallback,progressCallback)
  File "/usr/share/rhn/up2date_client/up2date.py", line 638, in
getAvailablePackageList
    tmp_args,tmp_method = xmlrpclib.loads(blip)
  File "/usr/lib/python1.5/site-packages/xmlrpclib.py", line 529, in loads
    return u.close(), u.getmethodname()
  File "/usr/lib/python1.5/site-packages/xmlrpclib.py", line 358, in close
    raise ResponseError()
xmlrpclib.ResponseError: <xmlrpclib.ResponseError instance at 81d9d18>
[root@kyle tommy]# 


(I supposed I am missing something?)

Tommy
Comment 24 Damian Christey 2001-09-05 11:03:52 EDT
You're not the only one. See bug 51860.
Comment 25 Jay Turner 2001-09-05 12:48:59 EDT
Tommy, try grabbing python-xmlrpc-1.4.8-3 from
people.redhat.com/jturner/software.html and see if that helps you out.
Comment 26 Tommy McNeely 2001-09-06 14:34:28 EDT
Actually.. it turns out that I got that error when the site was LOCKED DOWN for
the ROSWELL2 release. Since it has been unlocked, I can update both at home
(behind unknows transperant webcache) and at work (behind ICKY netscape proxy
server). I have that version on my machines now (it must be from up2date).

Thanks,
Tommy
Comment 27 Jay Turner 2001-09-10 15:33:00 EDT
Closing this out as it appears that the updated packages resolve the problem.

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