8.2. The tools

8.2.1. Zarafa Archiver ACL Sync

8.2.1.1. Description

za-aclsync synchronises 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, those other users will need at least read-permissions on this persons archive as well, so that they can read stubbed messages or access the archive directly. These permissions cannot be set by the owner of the archive when the archive was attached without write privileges. Even when another user has write permissions, it’s a nuisance to set all the permissions twice, or possibly more often when multiple archives are attached.

Note that no user will ever get more rights on a store or folder than the owner of the archive. When the archive was attached without write permissions, no user will get write permissions on the archive stores. For every archived folder in an archived store za-aclsync will first determine the rights of the owner of the archive. After that 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.

8.2.1.2. Usage

za-aclsync [options] [users]

options:
-h serverpath           : Host to connect to.
-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.

8.2.2. Zarafa Archiver ACL Set

8.2.2.1. Description

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

When an archive is attached to a store, the owner of the store gets read-only or read/write permissions on the archive, depending on the configuration file or command line options used at the time of attaching. Also when an archive is attached to a store of a non-active user it’s impossible to set permissions for that non-active user.

In the first case it may be desirable to change the permissions at a later time because of company policy changes or because the original setting was wrong. In the second case, when the user is converted to an active user, permissions need to be reset because the owner won’t have any permissions on his archive.

8.2.2.2. Usage

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

options:
-h | --host         Host to connect to. 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.

Za-aclset should be executed on a regular basis from a cronjob to synchronise the rights between the primary store and the archive store .

8.2.3. Zarafa Archiver Restore

8.2.3.1. Description

za-restore is a utility that restores archived messages from an archive. Use za-restore to destub all stubbed messages and restore all messages that were deleted after archiving. Do not drag and drop messages back from an archive to a main store in Outlook or Webaccess. Using za-restore ensures that restored messages are sanitised, so that they can be re-archived properly later.

8.2.3.2. Usage

Usage: za-restore [OPTIONS] user
OPTIONS:
  -h | --host           : Host to connect to. 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       : Specify log file.
  --detach              : Detach the selected or all archive stores before
                          starting the restore procedure. This avoids the
                          Archiver from rearchiving 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.

8.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.