NAME

serial2plain - Convert abuse reports from serialized to plain format

SYNOPSIS

    serial2plain [-h] [-o path] path ...

DESCRIPTION

serial2plain recurses through the paths given in the command line, looking for abuse reports stored by Mail::Abuse::Processor::Store in serialized mode. Any reports found, will be "stripped", that is, all the data structures accompaining the abuse reports will be removed, leaving only the text of the abuse report and its original headers.

The resulting stripped report will be placed in an equivalent location under the path specified in the mandatory -o option. Access times and file ownership will be preserved, so as not to break existing expiration schemes.

As is, this tool is helpful for migrating from a scenario employing the serialized storage mode, to the plain storage mode, thus saving space.

Note that this process losses information. All the recovered incidents and other meta-data accompanying the abuse report will be discarded in the process. Usually, you'll want to insure that this information is being kept elsewhere, such as in a database through the use of modules such as Mail::Abuse::Processor::ArchiveDBI.

-h

Causes this documentation to be produced.

-o path

Specifies where to place the stripped abuse reports. The required paths will be created if they does not exist.

HISTORY

  $Log: serial2plain,v $
  Revision 1.1  2005/12/02 21:31:52  lem
  Added initial version of serial2plain. This version is useful for
  migrating existing abuse report repositories. You can invoke it as in

    $ cd old-rep
    $ serial2plain -o new-rep .

  And the abuse reports will be happily transferred. Some preliminary
  benchmarks suggest very significant space savings by using the
  plain-gz format instead of the serialized format, although this will
  change from installation to installation.

LICENSE AND WARRANTY

This code and all accompanying software comes with NO WARRANTY. You use it at your own risk.

This code and all accompanying software can be used freely under the same terms as Perl itself.

AUTHOR

Luis E. Muñoz <luismunoz@cpan.org>

SEE ALSO

perl(1), Mail::Abuse.