RT 5.0.7 Documentation

RT::Shredder

NAME

RT::Shredder - Permanently wipeout data from RT

SYNOPSIS

CLI

  rt-shredder --force --plugin 'Tickets=query,Queue="General" and Status="deleted"'

DESCRIPTION

RT::Shredder is extension to RT which allows you to permanently wipeout data from the RT database. Shredder supports the wiping of almost all RT objects (Tickets, Transactions, Attachments, Users...).

"Delete" vs "Wipeout"

RT uses the term "delete" to mean "deactivate". To avoid confusion, RT::Shredder uses the term "Wipeout" to mean "permanently erase" (or what most people would think of as "delete").

Why do you want this?

Normally in RT, "deleting" an item simply deactivates it and makes it invisible from view. This is done to retain full history and auditability of your tickets. For most RT users this is fine and they have no need of RT::Shredder.

But in some large and heavily used RT instances the database can get clogged up with junk, particularly spam. This can slow down searches and bloat the size of the database. For these users, RT::Shredder allows them to completely clear the database of this unwanted junk.

An additional use of Shredder is to obliterate sensitive information (passwords, credit card numbers, ...) which might have made their way into RT.

Command line tools (CLI)

rt-shredder is a program which allows you to wipe objects from command line or with system tasks scheduler (cron, for example). See also 'rt-shredder --help'.

Web based interface (WebUI)

Shredder's WebUI integrates into RT's WebUI. You can find it in the Admin->Tools->Shredder tab. The interface is similar to the CLI and gives you the same functionality. You can find 'Shredder' link at the bottom of tickets search results, so you could wipeout tickets in the way similar to the bulk update.

DATA STORAGE AND BACKUPS

Shredder allows you to store data you wiped in files as scripts with SQL commands.

Restoring from backup

Should you wipeout something you did not intend to the objects can be restored by using the storage files. These files are a simple set of SQL commands to re-insert your objects into the RT database.

1) Locate the appropriate shredder SQL dump file. In the WebUI, when you use shredder, the path to the dump file is displayed. It also gives the option to download the dump file after each wipeout. Or it can be found in your $ShredderStoragePath.

2) Load the shredder SQL dump into your RT database. The details will be different for each database and RT configuration, consult your database manual and RT config. For example, in MySQL...

    mysql -u your_rt_user -p your_rt_database < /path/to/rt/var/data/shredder/dump.sql

That's it.i This will restore everything you'd deleted during a shredding session when the file had been created.

CONFIGURATION

$DependenciesLimit

Shredder stops with an error if the object has more than $DependenciesLimit dependencies. For example: a ticket has 1000 transactions or a transaction has 1000 attachments. This is protection from bugs in shredder from wiping out your whole database, but sometimes when you have big mail loops you may hit it.

Defaults to 1000. To change this (for example, to 10000) add the following to your RT_SiteConfig.pm:

    Set( $DependenciesLimit, 10_000 );>

$ShredderStoragePath

Directory containing Shredder backup dumps; defaults to /opt/rt5/var/data/RT-Shredder (assuming an /opt/rt5 installation).

To change this (for example, to /some/backup/path) add the following to your RT_SiteConfig.pm:

    Set( $ShredderStoragePath, "/some/backup/path" );>

Be sure to specify an absolute path.

Database Indexes

We have found that the following indexes significantly speed up shredding on most databases. However they are intended to be deployed only for the duration of your shredding, as they may have an adverse effect on the performance of ordinary RT operations.

    CREATE INDEX SHREDDER_CGM1 ON CachedGroupMembers(MemberId, GroupId, Disabled);
    CREATE INDEX SHREDDER_CGM2 ON CachedGroupMembers(ImmediateParentId,MemberId);
    CREATE INDEX SHREDDER_CGM3 on CachedGroupMembers (Via, Id);

    CREATE UNIQUE INDEX SHREDDER_GM1 ON GroupMembers(MemberId, GroupId);

    CREATE INDEX SHREDDER_TXN1 ON Transactions(ReferenceType, OldReference);
    CREATE INDEX SHREDDER_TXN2 ON Transactions(ReferenceType, NewReference);
    CREATE INDEX SHREDDER_TXN3 ON Transactions(Type, OldValue);
    CREATE INDEX SHREDDER_TXN4 ON Transactions(Type, NewValue);

    CREATE INDEX SHREDDER_ATTACHMENTS1 ON Attachments(Creator);

    CREATE INDEX SHREDDER_LINKS1 ON Links(Target);

    CREATE INDEX SHREDDER_ACL1 ON ACL(ObjectType, ObjectId);

    CREATE INDEX SHREDDER_OCFV1 ON ObjectCustomFieldValues(ObjectType, ObjectId);

INFORMATION FOR DEVELOPERS

General API

RT::Shredder is an extension to RT which adds shredder methods to RT objects and classes. The API is not well documented yet, but you can find usage examples in rt-shredder and the lib/t/regression/shredder/*.t test files.

However, here is a small example that do the same action as in CLI example from "SYNOPSIS":

  use RT::Shredder;
  RT::Shredder::Init( force => 1 );
  my $deleted = RT::Tickets->new( RT->SystemUser );
  $deleted->{'allow_deleted_search'} = 1;
  $deleted->LimitQueue( VALUE => 'general' );
  $deleted->LimitStatus( VALUE => 'deleted' );
  while( my $t = $deleted->Next ) {
      $t->Wipeout;
  }

RT::Shredder class' API

RT::Shredder implements interfaces to objects cache, actions on the objects in the cache and backups storage.

GENERIC

Init

    RT::Shredder::Init( %default_options );

RT::Shredder::Init() should be called before creating an RT::Shredder object. It iniitalizes RT and loads the RT configuration.

%default_options are passed to every <RT::Shredder-new>> call.

new

  my $shredder = RT::Shredder->new(%options);

Construct a new RT::Shredder object.

There currently are no %options.

CastObjectsToRecords( Objects => undef )

Cast objects to the RT::Record objects or its ancestors. Objects can be passed as SCALAR (format <class>-<id>), ARRAY, RT::Record ancestors or RT::SearchBuilder ancestor.

Most methods that takes Objects argument use this method to cast argument value to list of records.

Returns an array of records.

For example:

    my @objs = $shredder->CastObjectsToRecords(
        Objects => [             # ARRAY reference
            'RT::Attachment-10', # SCALAR or SCALAR reference
            $tickets,            # RT::Tickets object (isa RT::SearchBuilder)
            $user,               # RT::User object (isa RT::Record)
        ],
    );

OBJECTS CACHE

PutObjects( Objects => undef )

Puts objects into cache.

Returns array of the cache entries.

See CastObjectsToRecords method for supported types of the Objects argument.

PutObject( Object => undef )

Puts record object into cache and returns its cache entry.

NOTE that this method support only RT::Record object or its ancestor objects, if you want put multiple objects or objects represented by different classes then use PutObjects method instead.

GetObject, GetState, GetRecord( String => ''| Object => '' )

Returns record object from cache, cache entry state or cache entry accordingly.

All three methods takes String (format <class>-<id>) or Object argument. String argument has more priority than Object so if it's not empty then methods leave Object argument unchecked.

You can read about possible states and their meanings in RT::Shredder::Constants docs.

Dependencies resolvers

PutResolver, GetResolvers and ApplyResolvers

TODO: These methods have no documentation.

Data storage and backups

GetFileName( FileName => '<ISO DATETIME>-XXXX.sql', FromStorage => 1 )

Takes desired FileName and flag FromStorage then translate file name to absolute path by next rules:

* Default value of the FileName option is <ISO DATETIME>-XXXX.sql;

* if FileName has XXXX (exactly four uppercase X letters) then it would be changed with digits from 0000 to 9999 range, with first one free value;

* if FileName has %T then it would be replaced with the current date and time in the YYYY-MM-DDTHH:MM:SS format. Note that using %t may still generate not unique names, using XXXX recommended.

* if FromStorage argument is true (default behaviour) then result path would always be relative to StoragePath;

* if FromStorage argument is false then result would be relative to the current dir unless it's already absolute path.

Returns an absolute path of the file.

Examples: # file from storage with default name format my $fname = $shredder->GetFileName;

    # file from storage with custom name format
    my $fname = $shredder->GetFileName( FileName => 'shredder-XXXX.backup' );

    # file with path relative to the current dir
    my $fname = $shredder->GetFileName(
        FromStorage => 0,
        FileName => 'backups/shredder.sql',
    );

    # file with absolute path
    my $fname = $shredder->GetFileName(
        FromStorage => 0,
        FileName => '/var/backups/shredder-XXXX.sql'
    );

StoragePath

Returns an absolute path to the storage dir. See "$ShredderStoragePath".

See also description of the "GetFileName" method.

SEE ALSO

rt-shredder, rt-validator

← Back to index