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?
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.
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
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
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?
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)
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 :)
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 ;->
> 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 :))
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)
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.
#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... ;-> )
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.
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 !
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
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.
Roswell has python-xmlrpc-1.4.5-0.7.x
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.
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 .
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.
Yes, downloading and installing packages does now work.
Good, closing out this issue now.
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
[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
You're not the only one. See bug 51860.
Tommy, try grabbing python-xmlrpc-1.4.8-3 from people.redhat.com/jturner/software.html and see if that helps you out.
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
Closing this out as it appears that the updated packages resolve the problem.