Description of problem: using API call schedule.failSystemAction you can overwrite system events history listSystemEvents: [(28, '<script>alert()</script>'), (29, '<script>alert()</script>'), (31, 'Update Succeeded'), (32, 'Error while executing packages action: empty transaction [[6]]')] after call schedule.failSystemAction(key, SID, 31, "error message") listSystemEvents: [(28, '<script>alert()</script>'), (29, '<script>alert()</script>'), (31, 'error message'), (32, 'Error while executing packages action: empty transaction [[6]]')] reproducer script: import sys import xmlrpclib client = xmlrpclib.Server('http://localhost/rpc/api') key = client.auth.login('admin', 'password') SID=int(sys.argv[1]) AID=int(sys.argv[2]) print [(x['id'], x['result_msg']) for x in client.system.listSystemEvents(key, SID)] print client.schedule.failSystemAction(key, SID, AID, "error message") print [(x['id'], x['result_msg']) for x in client.system.listSystemEvents(key, SID)] Version-Release number of selected component (if applicable): spacewalk-java-2.5.14-83.el6sat.noarch How reproducible: always
I think the API call should be able to fail only non-completed/pending actions.
fixed in spacewalk.git(master): eaca1a56fa26653d1ce815c0caf2327fb9ca4801
One more commit to allow failing actions even in Picked Up state, so that it may solve 'hanging events. spacewalk a9d8c569c023908b88340b6138f6a52221aabc4b
Reproduced on spacewalk-java-2.5.14-89.el6sat using the reproducer from the initial report. I was able to manually fail already performed actions. Updated to spacewalk-java-2.5.14-91.el6sat, attempting to fail already performed action ended with the following error: >> client.schedule.failSystemAction(key,1000010001,11) --------------------------------------------------------------------------- Fault Traceback (most recent call last) <ipython-input-59-c21e59321751> in <module>() ----> 1 client.schedule.failSystemAction(key,1000010001,11) /usr/lib64/python2.7/xmlrpclib.pyc in __call__(self, *args) 1241 return _Method(self.__send, "%s.%s" % (self.__name, name)) 1242 def __call__(self, *args): -> 1243 return self.__send(self.__name, args) 1244 1245 ## /usr/lib64/python2.7/xmlrpclib.pyc in __request(self, methodname, params) 1600 self.__handler, 1601 request, -> 1602 verbose=self.__verbose 1603 ) 1604 /usr/lib64/python2.7/xmlrpclib.pyc in request(self, host, handler, request_body, verbose) 1281 for i in (0, 1): 1282 try: -> 1283 return self.single_request(host, handler, request_body, verbose) 1284 except socket.error, e: 1285 if i or e.errno not in (errno.ECONNRESET, errno.ECONNABORTED, errno.EPIPE): /usr/lib64/python2.7/xmlrpclib.pyc in single_request(self, host, handler, request_body, verbose) 1314 if response.status == 200: 1315 self.verbose = verbose -> 1316 return self.parse_response(response) 1317 except Fault: 1318 raise /usr/lib64/python2.7/xmlrpclib.pyc in parse_response(self, response) 1491 p.close() 1492 -> 1493 return u.close() 1494 1495 ## /usr/lib64/python2.7/xmlrpclib.pyc in close(self) 798 raise ResponseError() 799 if self._type == "fault": --> 800 raise Fault(**self._stack[0]) 801 return tuple(self._stack) 802 Fault: <Fault -1: 'redstone.xmlrpc.XmlRpcFault: unhandled internal exception: Action 11 must be in Pending state on server 1000010001'> It is still possible to manually fail a queued action, and once failed, it can't be failed again (correct). VERIFIED
Re-verified using reproducer from OP, but with both versions of failSystemAction API call, with spacewalk-java-2.5.14-95. It is indeed not possible to fail a completed or failed action: xmlrpclib.Fault: <Fault -1: 'redstone.xmlrpc.XmlRpcFault: unhandled internal exception: Action 546 must be in Pending state on server 1000010091'> The error message only speaks about Pending state but it seems correct as this is how all the failable states are described in WebUI.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2017:2645