11.2. The Tools

11.2.1. Zarafa Archiver ACL Sync

11.2.1.1. Description

za-aclsync Synchronizes archive ACL settings with those of the primary store.

When a user has set permissions for other users or groups on his or her store or folders, the other users will need at least read-permissions on this persons archive as well in order to read stubbed messages or access the archive directly. These permissions can not be set by the owner of the archive if the archive was attached without write privileges. Even if the user has write permissions, it’s a nuisance to have to set all the permissions twice (or more if multiple archives are attached).

za-aclsync can be used to propagate the ACL settings from the primary store to the archives. However, no user will ever get more right on a store or folder than the owner of the archive. So if the archive was attached without write permissions, no user will get write permissions on the archive.

For every archived folder in an archived store za-aclsync will first determine the rights for the owner of the archive. Then it will get all the entries from the ACL of the current folder except those of the owner. Each right will be masked with the rights of the owner before being added to the ACL of the archive folder.

11.2.1.2. Usage

za-aclsync [options] [users]

options:
-h serverpath           : Host to connect with.
-s sslkey_file          : SSL key file for authentication.
-p sslkey_pass          : Password for the SSL key file.

users is a space separated list of users for which to synchronize the ACL settings. If no user is specified all users will be processed.

11.2.2. Zarafa Archiver ACL Set

11.2.2.1. Description

za-aclset sets or updates the permissions on an archive store for the owner of that store.

When an archive is attached to a store, the owner of the store get read-only or read/write permissions on the archive based on the configuration or command line options passed at the time of attaching. Also when an archive is attached to a store of a non-active user, no permissions for that non-active user are set because that’s not possible.

In the first case it can be desirable to change the permissions at a later time because of company policy changes or because the original setting was just wrong.

In the second case, if the user is converted to an active user, it’s required to reset the permissions because the owner won’t have any permissions on his archive.

11.2.2.2. Usage

za-aclset [OPTIONS] [users...]

options:
-h | --host         Host to connect with. Default: file:///var/run/zarafa
                    Three formats are allowed for this option:

                      UNIX socket : file://<path to the UNIX socket>
                             HTTP : http://<host or IP>:<port>/zarafa
                      Secure HTTP : https://<host or IP>:<port>/zarafa

-s | --sslkey-file  SSL key file for authentication.
-p | --sslkey-pass  Password for the SSL key file.
-w |                Grant write permissions on the archive.
--writable <y|n>    Enable or disable write permissions.
--help              Show this help message.

users is a space separated list of users for which to synchronize the ACL settings. If no user is specified all users will be processed.

11.2.3. Zarafa Archiver Restore

11.2.3.1. Description

za-restore can be used to repopulate a primary store to a state where no archive is required to read any message. In a less cryptic way this means that all stubbed messages are destubbed and all messages that were deleted after archiving are restored.

The advantage of using za-restore over dragging the messages back from the archive in Outlook or Webaccess is that the restores messages are sanitized, allowing them to be properly re-archived later.

11.2.3.2. Usage

Usage: za-restore [OPTIONS] user
OPTIONS:
  -h | --host           : Host to connect with. Default: file:///var/run/zarafa
  -s | --sslkey_file    : SSL key file for authentication.
  -p | --sslkey_pass    : Password for the SSL key file.
  -l | --log-file       : Select log file.
  --detach              : Detach the selected or all archive stores before
                          starting the restore procedure. This avoids the
                          archiver from re archiving restored messages.
  --unhook              : Unhook the selected or all archive stores once
                          the restore process has completed. This implies
                          --detach and only works on archive stores.
  --remove              : Remove the selected or all archive stores once
                          the restore process has completed. This implies
                          --unhook and only works on archive stores.
  --select-source       : Select the source archive(s) by providing a comma
                          separated list of archive indexes. The indexes specify
                          which archives to restore from. The --detach, --unhook
                          and --remove options only apply to the selected
                          archives.
                          The archive indexes can be obtained by listing the
                          attached archives for a user: zarafa-archiver -u
                          <user> -l.
  -v | --verbose        : Increase console loglevel. Can be specified multiple
                          times.
  -q | --quiet          : Decrease console loglevel. Can be specified multiple
                          times.
  -N | --dry-run        : Don't actually modify anything.
  --help                : Show this help message.

11.2.3.3. Example

The following example will completely restore the store of john_doe and detaches and unhooks all archive stores while logging to /tmp/john_doe_restore.log

> za-restore --unhook -s /etc/zarafa/ssl/archiver.pem -p password \
  -l /tmp/john_doe_restore.log john_doe

Note that no host is specified, causing za-restore to connect to file:///var/run/zarafa. The sslkey_file and sslkey_pass are specified in order to connect to the other nodes in the cluster.