arsa - archiving/deleting old Red Hat Satellite actions

Latest response

Hi folks,

I just developed a little Python script for archiving and deleting old Red Hat Satellite actions.

As you might know everything you trigger using the WebUI is registered as an action - if you're maintaining a bigger system landscape you might end up in a long list of completed/archived actions after a couple of days. I'm not very familiar with the database design of Red Hat Satellite but I think it's basically a good idea to clean this stuff up sometimes.

I couldn't find a "delete all actions" button in the WebUI and so I decided to create a tiny script for this after reading the Spacewalk API

The script is called arsa (archive Spacewalk actions) and is also compatible with Spacewalk and SUSE Manager.
It can be downloaded on GitHub.

Authentication information can be provided in multiple ways. By default the script prompts for username and password.

If you need to automate this you can assign two shell variables:
- SPACEWALK_LOGIN - a username
- SPACEWALK_PASSWORD - the appropriate password

Another (and more secure) possibility is to create an "authfile" and pass this file to the script (-a / --authfile). This file needs to have two lines containing the username (first line) and the password (second line). You will also have to set the file permissions to 0600.

Per default the script uses localhost as hostname for logging in. You can also change this behaviour (-s / --server).

Some examples:

Listing all completed actions (login information are prompted):

$ ./arsa.py -l
Username: mylogin
Password: 
things I'd like to clean (completed):
-------------------------------------
action #1494 ('Remote Command on mymachine.localdomain.loc.')

Removing all completed and archived actions (login information are provided using shell variables):

$ SATELLITE_LOGIN=mylogin SATELLITE_PASSWORD=mypass ./arsa.py -r
Archving action #1494 ('Remote Command on mymachine.localdomain.loc.')...
Deleting action #1494 ('Remote Command on mymachine.localdomain.loc.')...
Deleting action #1493 ('Remote Command on myothermachine.localdomain.loc.')...

Additional parameters can be found in the integrated help:

$ ./arsa.py -h
Usage: arsa.py [options]

arsa.py is used to archive completed actions and remove archived actions on
Spacewalk, Red Hat Satellite and SUSE Manager. Login credentials are assigned
using the following shell variables:
SATELLITE_LOGIN  username                 SATELLITE_PASSWORD  password
It is also possible to create an authfile (permissions 0600) for usage with
this script. The first line needs to contain the username, the second line
should consist of the appropriate password. If you're not defining variables
or an authfile you will be prompted to enter your login information.
Checkout the GitHub page for updates: https://github.com/stdevel/arsa

Options:
  --version             show program's version number and exit
  -h, --help            show this help message and exit
  -a FILE, --authfile=FILE
                        defines an auth file to use instead of shell variables
  -s SERVER, --server=SERVER
                        defines the server to use
  -q, --quiet           don't print status messages to stdout
  -d, --debug           enable debugging outputs
  -r, --remove          archives completed actions and removes all archived
                        actions
  -l, --list-only       only lists actions that would be archived

Maybe this helps somebody here - I use this script inside a cronjob to regularly clean-up old actions.

Best regards,
Christian!

Responses

Thanks Christian! I haven't tested it out but it looks like it would be helpful. Shared it on the Red Hat Support Facebook and Twitter accounts so hopefully somebody can give it a try and provide some feedback.

Hi David!

Thanks for the feedback and sharing this page. :)

Best regards,
Christian!

Hi Christian, thanks for creating/posting this - For my use, I'm going to modify it so that the script will prompt for the password/userid (don't want that in my history).

Thanks!
Remmele

Hi Remmele!

That's a brilliant idea. Thanks for sharing this.

I'd also like to catch that up on GitHub. I think that's a good feature others would also like to see in the script.

So, how are you implementing this? I was just thinking about how to improve the way of authentification. I think another option would be to create a "password file" with permissions 0600 that it used by the script (and only used if the permissions are 0600). What do you think?

Best regards,
Christian!

Hi Christian,

I use Perl and have it prompt for the userid/password in the script. I really avoid having the userid/password for the satellite server in a bare file. There is a method to cite a file with a perl module I've seen (will post link very soon here)
In the meantime, check out these other discussions where there is some info on this:

other api discussions (not complete)
https://access.redhat.com/site/discussions/683433
https://access.redhat.com/site/discussions/698403
https://access.redhat.com/site/discussions/450023
https://access.redhat.com/site/discussions/688563
https://access.redhat.com/site/discussions/783503

I believe there's more,

Thanks for posting that Christian!

Kind Regards,
Remmele

Christian, this link has both a python and perl example that prompts for your password...

Hi Remmele,

thanks for sharing this, this looks interesting! I'm going to have a look at it - just opened an issue on GitHub for that: Idea: prompt user for login information if no shell variables given · Issue #1 · stdevel/arsa

Best regards,
Christian.

Just added two additional methods for authentication.

By default the script prompts for username and password. Another possibility is to create an "authfile" which has two lines including the username (first line) and password (second line). This authfile needs to have the permissions 0600.

It is also possible to store the login information in shell variables like before.

The updated script is available on GitHub.

Best regards,
Christian.

Hello Christian,

Thanks for this, worked 100% clearing our about 39,000 Completed Actions log!
A nice enhancement would be the ability to clear out "Failed Actions" log too.

Thanks again for sharing.
Regards
johnny

Hey Johny,
sorry for the late answer - that's a brilliant idea!
I'm currently implementing this feature - see this issue on GitHub: GitHub

I will let you know once it's availble.

I thought I would throw mine in to the discussion... (I am not very capable with Python).
I needed to group the actions and do them in chunks - we had over 150,000 events to purge. I had not figured out what the magic number of maximum events I could put in one group though.

#!/usr/bin/env python
import xmlrpclib
import time

SATELLITE_URL = "http://rhnsat01.company.com/rpc/api"
SATELLITE_LOGIN = "satadmin"
SATELLITE_PASSWORD = "ThisIsNotMyPassword"

client = xmlrpclib.Server(SATELLITE_URL, verbose=0)
delete = 1

key = client.auth.login(SATELLITE_LOGIN, SATELLITE_PASSWORD)

###############################
# CHANGE THINGS AFTER THIS LINE
#

## Delete all Failed Actions
x = "Deleting all Failed Actions"
print(x)
failed_list = client.schedule.listFailedActions(key)
action_ids=[]
for action in failed_list:
    action_ids.append(action['id'])

archive_result=client.schedule.archiveActions(key,action_ids)

## Archive all Completed Actions
## Generate an Array of size (max_num_ids) and purge it
x = "Archiving all Completed Actions"
print(x)
counter = 0
max_num_ids = 1 
archived_list = client.schedule.listCompletedActions(key)
action_ids=[]
for action in archived_list:
    print action.get('id')
    action_ids.append(action['id'])
    counter = counter + 1
    if counter == max_num_ids:
        del_result=client.schedule.archiveActions(key,action_ids)
        time.sleep(.5)
        action_ids=[]
        counter = 0

## Delete all Archived Actions
## Generate an Array of size (max_num_ids) and purge it
x = "Deleting all Completed Actions"
print(x)
counter = 0
max_num_ids = 100 
archived_list = client.schedule.listArchivedActions(key)
action_ids=[]
## Traverse Array in reverse [::-1]
#for action in archived_list[::-1]:
## Traverse Array in forward [:]
for action in archived_list:
    print action.get('id')
    action_ids.append(action['id'])
    counter = counter + 1
    if delete == 1:
        if counter == max_num_ids:
          del_result=client.schedule.deleteActions(key,action_ids)
          time.sleep(.5)
          action_ids=[]
          counter = 0

##
## CHANGE THINGS BEFORE THIS LINE
###############################
client.auth.logout(key)

Hey James!

Thanks for the hint - I also spotted this a couple of days ago when I had a look at Spacewalk 2.2. I'm currently implementing this - see this issue: GitHub

Glad I'm not the only one that ran in to that particular situation. I would be curious to know what a sustainable "stream rate" would be via the API, or what causes the limitation(s).
I am currently running a cleanup with groups of 100 with a .1 delay and it's running clean.

My successful 39,000 "one-time" cleanup was against RHN Satellite release 5.5.0. So it still uses the Oracle DB backend.

Hi everyone,

I implemented a function to also include failed actions and fixed the issue when removing a big amount of actions. Thank you very much for your ideas, Johnny Vergeer and James Radtke!

I successfully tested it on a Spacewalk 2.2 and Red Hat Satellite 5.6 installation.

As usual you can find the script on GitHub

Close

Welcome! Check out the Getting Started with Red Hat page for quick tours and guides for common tasks.