Description of problem: when pushing a huge number of package rhnpush fails with <type 'exceptions.TypeError'> : 'NoneType' object is unsubscriptable Version-Release number of selected component (if applicable): bug seen on Spacewalk 1.6 / RHEL6.2 also reproduced on nightly with rhnpush-5.5.40-1.el6.noarch spacewalk-backend-1.7.19-1.el6.noarch How reproducible: always, but takes about hour to reproduce Steps to Reproduce: 1. download packages from EPEL6 to local directory, e.g. rpm -Uvh http://download.fedora.redhat.com/pub/epel/6/i386/epel-release-6-5.noarch.rpm reposync -r epel -p /tmp/epel/ 2. create a channel for epel6 packages, e.g. spacewalk-common-channels -v -k unlimited -u admin -p nimda -a i386,x86_64 'centos[56]*' 'spacewalk*' 'epel6*' 3. time rhnpush -vv -u admin -p <adminpwd> -c epel6-centos6-x86_64 --dir /tmp/epel/ Actual results: Package /tmp/epel/epel/libdmtx-devel-0.7.2-3.el6.x86_64.rpm Not Found on RHN Server -- U ploading Uploading package /tmp/epel/epel/libdmtx-devel-0.7.2-3.el6.x86_64.rpm Using POST request While running 'packages.channelPackageSubscriptionBySession': caught <type 'exceptions.TypeError'> : 'NoneType' object is unsubscriptable There are about 5000 packages pushed but they aren't in the channel (you can see them in Manage Software Packages > Packages in no channel). Expected results: no error, packages pushed Additional info: /var/log/httpd/error_log: [Thu Feb 16 06:07:31 2012] [error] Time: Thu Feb 16 06:07:31 2012 [Thu Feb 16 06:07:31 2012] [error] Exception type <type 'exceptions.TypeError'> [Thu Feb 16 06:07:31 2012] [error] Exception while handling function packages.channelPac kageSubscriptionBySession [Thu Feb 16 06:07:31 2012] [error] Request object information: [Thu Feb 16 06:07:31 2012] [error] URI: /APP [Thu Feb 16 06:07:31 2012] [error] Remote Host: localhost [Thu Feb 16 06:07:31 2012] [error] Server Name: localhost:443 [Thu Feb 16 06:07:31 2012] [error] Headers passed in: [Thu Feb 16 06:07:31 2012] [error] \tAccept-Encoding: identity [Thu Feb 16 06:07:31 2012] [error] \tCONTENT_LENGTH: 432866 [Thu Feb 16 06:07:31 2012] [error] \tCONTENT_TYPE: application/binary [Thu Feb 16 06:07:31 2012] [error] \tContent-Encoding: x-gzip [Thu Feb 16 06:07:31 2012] [error] \tContent-Transfer-Encoding: binary [Thu Feb 16 06:07:31 2012] [error] \tDOCUMENT_ROOT: /var/www/html [Thu Feb 16 06:07:31 2012] [error] \tGATEWAY_INTERFACE: CGI/1.1 [Thu Feb 16 06:07:31 2012] [error] \tHTTPS: 1 [Thu Feb 16 06:07:31 2012] [error] \tHTTP_ACCEPT_ENCODING: identity [Thu Feb 16 06:07:31 2012] [error] \tHTTP_CONTENT_ENCODING: x-gzip [Thu Feb 16 06:07:31 2012] [error] \tHTTP_CONTENT_TRANSFER_ENCODING: binary [Thu Feb 16 06:07:31 2012] [error] \tHTTP_HOST: localhost [Thu Feb 16 06:07:31 2012] [error] \tHTTP_USER_AGENT: rhn.rpclib.py/$Revision$ [Thu Feb 16 06:07:31 2012] [error] \tHTTP_X_CLIENT_VERSION: 1 [Thu Feb 16 06:07:31 2012] [error] \tHTTP_X_INFO: RPC Processor (C) Red Hat, Inc (version $Revision$) [Thu Feb 16 06:07:31 2012] [error] \tHTTP_X_RHN_TRANSPORT_CAPABILITY: follow-redirects=3 [Thu Feb 16 06:07:31 2012] [error] \tHTTP_X_TRANSPORT_INFO: Extended Capabilities Transport (C) Red Hat, Inc (version $Revision$) [Thu Feb 16 06:07:31 2012] [error] \tHost: localhost [Thu Feb 16 06:07:31 2012] [error] \tPATH_INFO: [Thu Feb 16 06:07:31 2012] [error] \tQUERY_STRING: [Thu Feb 16 06:07:31 2012] [error] \tREMOTE_ADDR: ::1 [Thu Feb 16 06:07:31 2012] [error] \tREMOTE_PORT: 36381 [Thu Feb 16 06:07:31 2012] [error] \tREQUEST_METHOD: POST [Thu Feb 16 06:07:31 2012] [error] \tREQUEST_URI: /APP [Thu Feb 16 06:07:31 2012] [error] \tSCRIPT_FILENAME: /usr/share/rhn/wsgi/app.py [Thu Feb 16 06:07:31 2012] [error] \tSCRIPT_NAME: /APP [Thu Feb 16 06:07:31 2012] [error] \tSCRIPT_URI: https://localhost/APP [Thu Feb 16 06:07:31 2012] [error] \tSCRIPT_URL: /APP [Thu Feb 16 06:07:31 2012] [error] \tSERVER_ADDR: ::1 [Thu Feb 16 06:07:31 2012] [error] \tSERVER_ADMIN: root@localhost [Thu Feb 16 06:07:31 2012] [error] \tSERVER_NAME: localhost [Thu Feb 16 06:07:31 2012] [error] \tSERVER_PORT: 443 [Thu Feb 16 06:07:31 2012] [error] \tSERVER_PROTOCOL: HTTP/1.1 [Thu Feb 16 06:07:31 2012] [error] \tSERVER_SIGNATURE: <address>Apache Server at localhost Port 443</address> [Thu Feb 16 06:07:31 2012] [error] [Thu Feb 16 06:07:31 2012] [error] \tSERVER_SOFTWARE: Apache [Thu Feb 16 06:07:31 2012] [error] \tUser-Agent: rhn.rpclib.py/$Revision$ [Thu Feb 16 06:07:31 2012] [error] \tX-Client-Version: 1 [Thu Feb 16 06:07:31 2012] [error] \tX-Info: RPC Processor (C) Red Hat, Inc (version $Revision$) [Thu Feb 16 06:07:31 2012] [error] \tX-RHN-Transport-Capability: follow-redirects=3 [Thu Feb 16 06:07:31 2012] [error] \tX-Transport-Info: Extended Capabilities Transport (C) Red Hat, Inc (version $Revision$) [Thu Feb 16 06:07:31 2012] [error] \tmod_wsgi.application_group: smqa-r210-03.lab.eng.brq.redhat.com|/app [Thu Feb 16 06:07:31 2012] [error] \tmod_wsgi.callable_object: application [Thu Feb 16 06:07:31 2012] [error] \tmod_wsgi.handler_script: [Thu Feb 16 06:07:31 2012] [error] \tmod_wsgi.input_chunked: 0 [Thu Feb 16 06:07:31 2012] [error] \tmod_wsgi.listener_host: [Thu Feb 16 06:07:31 2012] [error] \tmod_wsgi.listener_port: 443 [Thu Feb 16 06:07:31 2012] [error] \tmod_wsgi.process_group: [Thu Feb 16 06:07:31 2012] [error] \tmod_wsgi.request_handler: wsgi-script [Thu Feb 16 06:07:31 2012] [error] \tmod_wsgi.script_reloading: 1 [Thu Feb 16 06:07:31 2012] [error] \tmod_wsgi.version: (3, 2) [Thu Feb 16 06:07:31 2012] [error] \twsgi.errors: <mod_wsgi.Log object at 0x7f2b75d80c70> [Thu Feb 16 06:07:31 2012] [error] \twsgi.file_wrapper: <built-in method file_wrapper of mod_wsgi.Adapter object at 0x7f2b75c4e918> [Thu Feb 16 06:07:31 2012] [error] \twsgi.input: <mod_wsgi.Input object at 0x7f2b75d80bb0> [Thu Feb 16 06:07:31 2012] [error] \twsgi.multiprocess: True [Thu Feb 16 06:07:31 2012] [error] \twsgi.multithread: False [Thu Feb 16 06:07:31 2012] [error] \twsgi.run_once: False [Thu Feb 16 06:07:31 2012] [error] \twsgi.url_scheme: https [Thu Feb 16 06:07:31 2012] [error] \twsgi.version: (1, 1) [Thu Feb 16 06:07:31 2012] [error] Extra information about this error: [Thu Feb 16 06:07:31 2012] [error] Response sent back to the caller: [Thu Feb 16 06:07:31 2012] [error] While running 'packages.channelPackageSubscriptionBySession': caught [Thu Feb 16 06:07:31 2012] [error] <type 'exceptions.TypeError'> : 'NoneType' object is unsubscriptable [Thu Feb 16 06:07:31 2012] [error] [Thu Feb 16 06:07:31 2012] [error] Exception Handler Information [Thu Feb 16 06:07:31 2012] [error] Traceback (most recent call last): [Thu Feb 16 06:07:31 2012] [error] File "/usr/lib/python2.6/site-packages/spacewalk/server/apacheRequest.py", line 122, in call_function [Thu Feb 16 06:07:31 2012] [error] response = apply(func, params) [Thu Feb 16 06:07:31 2012] [error] File "/usr/share/rhn/server/handlers/app/packages.py", line 260, in channelPackageSubscriptionBySession [Thu Feb 16 06:07:31 2012] [error] return self._channelPackageSubscription(authobj, info) [Thu Feb 16 06:07:31 2012] [error] File "/usr/share/rhn/server/handlers/app/packages.py", line 332, in _channelPackageSubscription [Thu Feb 16 06:07:31 2012] [error] package['checksum_type'] = row['checksum_type'] [Thu Feb 16 06:07:31 2012] [error] TypeError: 'NoneType' object is unsubscriptable
Obviously, not ideal. Is this a regression of behavior?
I didn't checked. Frankly rhnpush-ing 5k packages is weird ;) spacewalk-repo-sync is better tool in that case. I've set low prio here.
Michael, too right, but some of us do it :-) I have only experienced this issue when pushing large amounts of RPMs locally on the spacewalk / satellite server (which is more than likely resource starved). Depending on the amount of memory in the server, I've seen this error happen at 1100, 2000 and 3000 RPMs as I rebooted & added memory. I solved this problem by not pushing all RPMs (say more than 1-2k) at once with one command; rather processing them one by one or in groups at a time with the shell. For example, when pushing the RPMs locally, run it in a shell for loop: $ for RPM in /mnt/to/rpms/*.rpm; do rhnpush --server localhost -u **** -p **** --channel centos-61 $RPM; done It takes slightly longer to push them all, but it works successfully every time regardless of how much (or little) memory I've given the server. What's interesting is that I've never experienced this issue when pushing them from a remote system regardless of memory configuration (such as a workstation or build system). Hope that helps.
is this with Oracle or PostgreSQL backend?
I've seen this issue with both Oracle XE and Postgresql; however, it does happen more in Postgresql (at least the package count where this happens is smaller than the Oracle XE backend).
I believe this is a symptom of CVE-2012-1145. Fixed in Spacewalk master, bd7ad3667f2388ae9929d1dfc03c49545e17384c. Tagged as spacewalk-backend-1.8.9-1.
Moving ON_QA. Packages that address this bugzilla should now be available in yum repos at http://yum.spacewalkproject.org/nightly/
Spacewalk 1.8 has been released: https://fedorahosted.org/spacewalk/wiki/ReleaseNotes18