Product SiteDocumentation Site

ZCP 7.1 (build 41322)

Zarafa Archiver

The Zarafa Archiver Manual

엮음 7.1

The Zarafa Team

법적 공지

Copyright © 2013 Zarafa BV.
The text of and illustrations in this document are licensed by Zarafa BV under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at the creativecommons.org website. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Red Hat®, Red Hat Enterprise Linux®, Fedora® and RHCE® are trademarks of Red Hat, Inc., registered in the United States and other countries.
Ubuntu® and Canonical® are registered trademarks of Canonical Ltd.
Debian® is a registered trademark of Software in the Public Interest, Inc.
SUSE® and eDirectory® are registered trademarks of Novell, Inc.
Microsoft® Windows®, Microsoft Office Outlook®, Microsoft Exchange® and Microsoft Active Directory® are registered trademarks of Microsoft Corporation in the United States and/or other countries.
The Trademark BlackBerry® is owned by Research In Motion Limited and is registered in the United States and may be pending or registered in other countries. Zarafa BV is not endorsed, sponsored, affiliated with or otherwise authorized by Research In Motion Limited.
All trademarks are the property of their respective owners.
Disclaimer: Although all documentation is written and compiled with care, Zarafa is not responsible for direct actions or consequences derived from using this documentation, including unclear instructions or missing information not contained in these documents.
초록
The Zarafa Collaboration Platform (ZCP) combines the usability of Outlook with the stability and flexibility of a Linux server. It features a rich web-interface, the Zarafa WebAccess, and provides brilliant integration options with all sorts of clients including all most popular mobile platforms.
Most components of ZCP are open source, licensed under the AGPLv3, can therefore be downloaded freely as ZCP's Community Edition.
Several closed source components exist, most notably:
  • the Zarafa Windows Client providing Outlook integration,
  • the Zarafa BES Integration providing Blackberry Enterprise Server connectivity,
  • the Zarafa ADS Plugin providing Active Directory integration, and
  • the Zarafa Backup Tools.
These components, together with several advanced features for large setups and hosters, are only available in combination with a support contract as part of ZCP's Commercial Editions.
Alternatively there is a wide selection of hosted ZCP offerings available.
This document, the Administrator Manual, describes how to install, upgrade, configure and maintain ZCP on your Linux server. In addition various advanced configurations and integration options are discussed.
1. Introduction
2. Conventions
3. Installing
3.1. Requirements
3.1.1. Software Requirements
3.1.2. Required Packages
3.2. Installation
3.2.1. Default installation location
3.2.2. Activate Archiver subscription
3.3. Basic Configuration
3.3.1. Connection Parameters
3.3.2. MySQL Settings
4. Configure the archive policies
4.1. Stubbing only mode
4.2. Hybrid mode
4.3. Archive only mode
5. Archive Management
5.1. Automatic
5.1.1. Using OpenLDAP
5.1.2. Using Active Directory
5.1.3. Listing attached archives
5.1.4. Detaching an archive
5.1.5. Listing users that have an archive attached
5.1.6. See details of archive store
5.1.7. Unhooking an archive store
5.1.8. Hooking an archive store
5.1.9. Removing an archive store
6. Running the Archiver
6.1. Perform archiving task
6.1.1. From the command-line
6.2. Perform cleanup task
6.2.1. From the command-line
7. Client Features
8. Zarafa Archiver Extras
8.1. Installation
8.2. The Tools
8.2.1. Zarafa Archiver ACL Sync
8.2.2. Zarafa Archiver ACL Set
8.2.3. Zarafa Archiver Restore

1장. Introduction

The Zarafa Archiver product provides a way to minimize mailbox sizes by moving older messages to slower and thus cheaper storage. The slow storage consists of one or more additional Zarafa servers who’s sole task is to store archived messages.
The archive Zarafa servers have exactly the same storage architecture as a normal Zarafa server, all MAPI properties are stored in a MySQL database and all attachments are stored compressed on disk.
An archive mailbox can be enabled per user and the user will automatically get access to the archive mailbox from clients.
Once a message is archived, it can be deleted from the original store. Optionally a stub to the archived message can be created that allows a user to see the archived message and open it as if it were a normal message.
The Zarafa Archiver uses the Zarafa’s multi-server technology to access archive stores in a seamless way.
Zarafa Archiver is an additional product and is not a standard component of the Zarafa Collaboration Platform. Subscriptions of Zarafa Archiver can only be used with the Zarafa Professional or Enterprise edition, where both editions provide 20 archive users for free.

2장. Conventions

Before starting to install and deploy the Zarafa Archiver it’s strongly advised to read this chapter to understand the terminology.
  • Primary Server
    The primary server is the server with the best performance and best IO subsystem, that contains the stores on which users normally work.

    참고

    Although the term Primary Server suggests that there’s only one primary server, multiple primary servers can exist in a multi-server environment. In this document no distinction will be made between a single-server or multi-server environment unless explicitly stated.
  • Archive Server
    The archive server is the server, with a slower IO subsystem normally, that contains the archives for the stores that reside on the primary server.

    참고

    An archive server is just another zarafa-server with the sole purpose of providing storage for one or more archive stores. In a multi-server environment this server will be just another node in the cluster.

    참고

    Unlike primary servers, there’s no need for a multi-server environment to have a multi-archive server setup.
  • Primary Store
    The primary store is the store that resides on the primary server and on which a user normally works.
  • Archive Store
    The archive store is the store that resides on the archive server and which is used for storing the archived messages from the primary store.
  • zarafa-archiver
    The Archiver is the application that performs the actual archiving job. The zarafa-archiver is typically started from a daily or weekly cronjob. It can be installed on any Zarafa server to connect to the primary or archive server using SSL authentication.
  • Stubbed Message
    A stubbed message is a message in the primary store that acts as a placeholder for the archived message. These messages occupy virtually no space, but allow a user to see that a message was once there. On top of that it acts as an entry point to the archived version of that message.
  • Single Instances
    The Zarafa Collaboration Platform uses single instance storage whenever possible to minimize storage requirements when data is stored more than once. The Zarafa Archiver makes use of this technology by remembering which instances it copied to an archive server and referencing that instance whenever possible.

3장. Installing

3.1. Requirements
3.1.1. Software Requirements
3.1.2. Required Packages
3.2. Installation
3.2.1. Default installation location
3.2.2. Activate Archiver subscription
3.3. Basic Configuration
3.3.1. Connection Parameters
3.3.2. MySQL Settings

3.1. Requirements

To deploy the Zarafa Archiver at least two servers are required: one primary Zarafa server and one Zarafa Archive server. A Zarafa Archiver subscription is required to be able to run a multi-server setup. The multi-server technology is used to connect archives to users automatically.

참고

A multi-server setup requires a central LDAP or Active Directory. It’s not possible to use multi-server with the DB or unix user plugin.

3.1.1. Software Requirements

  • ZCP 7.0.4+
  • Multi-server Zarafa setup with LDAP or ADS
  • Valid ZCP Professional or Enterprise subscription
  • Zarafa Archiver subscription

3.1.2. Required Packages

The following Zarafa packages are required to install on a primary node:
  • zarafa-client
  • zarafa-server
  • zarafa-licensed (with Zarafa Archiver subscription)
  • zarafa-spooler
  • zarafa-dagent (for LMTP only)
  • zarafa-multiserver
  • zarafa-search or zarafa-indexer
  • zarafa-utils
The following Zarafa packages are required to install on an archive node:
  • zarafa-client
  • zarafa-server
  • zarafa-utils
  • zarafa-multiserver
  • zarafa-licensed (with Zarafa Archiver subscription)

3.2. Installation

The Zarafa Archiver software can be found on the Zarafa Portal as an additional download. The Zarafa Archiver download will include the following two packages:
  • zarafa-archiver containing the Archive controller and configuration files
  • zarafa-archiver-extra containing additional utilities for archiving setups:
    See 8장. Zarafa Archiver Extras for more details.

3.2.1. Default installation location

The zarafa-archiver packages can be installed on any node in the multi-server setup. However, it’s recommended to install the packages on the archive node.

3.2.1.1. RPM based distributions

Use the following command to install the zarafa-archiver and zarafa-archiver-extra package on RPM based distributions: 
rpm -Uvh zarafa-archiver_<version>_<platform>.rpm zarafa-archiver-extra_<version>_<platform>.rpm
Replace <version> with the correct version and <platform> with the required target platform (i386, i586, x86_64).

3.2.1.2. DEB based distributions

On Debian based distributions use: 
dpkg -i zarafa-archiver_<version>_<platform>.deb zarafa-archiver-extra_<version>_<platform>.deb
Replace <version> with the correct version and <platform> with the required target platform (i386, x86_64).

3.2.2. Activate Archiver subscription

To use the Archiver subscription on every node, the Archiver subscription has to be placed in the /etc/zarafa/license directory of all your servers. Execute the following commands on every node to use the archive subscription: 
echo 'Archiver code' > /etc/zarafa/license/archiverbase
/etc/init.d/zarafa-licensed restart
Additional Archiver CALs can be added in the /etc/zarafa/license directory, like normal ZCP CALs.

중요

The Archiver subscription must be placed on all server nodes, otherwise de-stubbing will not work.

3.3. Basic Configuration

The configuration of the Archive Controller is placed in /etc/zarafa/archiver.cfg.

3.3.1. Connection Parameters

As with all Zarafa components, zarafa-archiver needs to know where to connect to and how to authenticate. This is configured using the server_socket, sslkey_file and sslkey_pass settings.
For instance: 
server_socket   = file:///var/run/zarafa
sslkey_file     = /etc/zarafa/ssl/client.pem
sslkey_pass     = secret
For more information about creating and configuring SSL certificates, see http://doc.zarafa.com/7.1/Administrator_Manual/en-US/html-single/index.html#_creating_ssl_certificates.

3.3.2. MySQL Settings

zarafa-archiver uses one central MySQL database for managing deduplication of archived attachments. The MySQL settings can be configured like this: 
mysql_host      = localhost
mysql_port      = 3306
mysql_user      = zarafa
mysql_password  = password
mysql_socket    =
mysql_database  = zarafa-archiver
The MySQL database needs to be accessible over the network from the primary server. Use the following mysql commands to enable these privileges: 
mysql>  GRANT ALL PRIVILEGES ON zarafa-archiver.* TO 'zarafa'@'<ip-address_primary_node>' IDENTIFIED BY 'password';
mysql>  FLUSH PRIVILEGES;

4장. Configure the archive policies

4.1. Stubbing only mode
4.2. Hybrid mode
4.3. Archive only mode
The Archiver policy is defined the /etc/zarafa/archiver.cfg file. Three different modes for running the Archiver are available:
  • Stubbing only mode
  • Hybrid mode
  • Archive only mode
In stubbing only mode all emails can be accessed from the primary store of the user. Depending on the age of the message the email will be opened on the primary server or the stub will open the item directly in the users' archive mailbox. In this case the user doesn’t directly access his/her archive mailbox to view emails.
In hybrid mode the user can access emails both via stubs and directly in the archive mailbox. All emails which are between 3 months and 1 year old can be accessed by opening the stub in the primary mailbox. Emails older than 1 year can only be accessed via the archive mailbox.
In archive only mode no stubbing will be used. Emails older than the configured time will be moved to the archive mailbox and are no longer accessible from the primary mailbox.
표 4.1. Archiver modes
Setting Stubbing only Hybrid Archive only
Writable archive
No
No
Yes
Archiving enabled
Yes
Yes
Yes
Stubbing enabled
Yes
Yes
No
Automatic deletes in primary store
-
Yes
Yes
Purge in archive store
-
Yes
Yes

4.1. Stubbing only mode

For a stubbing only setup the following settings need to be configured in /etc/zarafa/archiver.cfg. 
archive_enable                  = yes
archive_after                   = 90

stub_enable                     = yes
stub_after                      = 90
stub_unread                     = no

delete_enable                   = no
delete_after                    = 0

purge_enable                    = no
purge_after                     = 0

cleanup_action                  = delete
cleanup_follow_purge_after      = no

enable_auto_attach              = yes
auto_attach_writable            = no
The archive_enable = yes setting enables the archive operation, which is essentially the copying from the primary node to the archive node. The archive_after = 90 setting causes the archive operation to be performed 90 days after the message was delivered.
The stub_enable = yes setting enables the stub operation, which is the operation on the message in the primary store where the body and the attachments are removed and a reference to the archive store is created. The stub_after = 90 setting causes the message to be stubbed immediately after the archive operation. Unread emails will not be stubbed automatically even when they are older than the configured lifetime.
The delete_enable and purge_enable will be disabled as a user will not access his archive mailbox directly in this mode.
The cleanup_action will make sure archived messages will be automatically removed from the archive mailbox when they are deleted in the primary mailbox of the user.
The auto attach option will make sure the user automatically gets an archive mailbox, when the archive server option is enabled in Active Directory or OpenLDAP. The user will always get read-only permissions, so users can delete messages from the archive mailbox only. This is required to make sure the stubs in the primary mailbox will always point to a existing message.

4.2. Hybrid mode

For a hybrid setup the following settings need to be configured in /etc/zarafa/archiver.cfg. 
archive_enable                  = yes
archive_after                   = 90

stub_enable                     = yes
stub_after                      = 90
stub_unread                     = no

delete_enable                   = yes
delete_after                    = 365

purge_enable                    = yes
purge_after                     = 3650

cleanup_action                  = store
cleanup_follow_purge_after      = yes

enable_auto_attach              = yes
auto_attach_writable            = no
In the hybrid mode the emails will be archived and stubbed after 90 days. Messages can be accessed by opening the stub in the primary mailbox or in the archive mailbox. For items older than 1 year the stub will be removed and the item can only be read from the archive mailbox.
To prevent the archive from growing forever, items will be removed after 10 years.
The cleanup_action setting will keep track of deleted stubs and move the item in the archive mailbox to a special folder "Deleted".
As the stubbing feature is used in the hybrid mode, the archive mailbox will be read-only.

4.3. Archive only mode

For an archive only setup the following settings need to be configured in /etc/zarafa/archiver.cfg. 
archive_enable                  = yes
archive_after                   = 365

stub_enable                     = no

delete_enable                   = yes
delete_after                    = 365

purge_enable                    = yes
purge_after                     = 3650

cleanup_action                  = store
cleanup_follow_purge_after      = yes

enable_auto_attach              = yes
auto_attach_writable            = yes
In archive only mode emails will only exist in the primary mailbox or in the archive mailbox. The stubbing option is disabled in this scenario.
To move items to the archive mailbox the delete_enable is set to yes and the number of days is configured. In this example, items older than 1 year are deleted from the primary mailbox and can only be accessed from the archive mailbox. To clean up the archive mailbox, items will be completely removed after 10 years.
As stubbing is not used in this mode, the archives can be set writable so users can cleanup their archive mailbox themselves.

5장. Archive Management

5.1. Automatic
5.1.1. Using OpenLDAP
5.1.2. Using Active Directory
5.1.3. Listing attached archives
5.1.4. Detaching an archive
5.1.5. Listing users that have an archive attached
5.1.6. See details of archive store
5.1.7. Unhooking an archive store
5.1.8. Hooking an archive store
5.1.9. Removing an archive store

5.1. Automatic

The zarafa-archiver can attach archive stores automatically based on user attributes stored in LDAP or in Active Directory. When using this way of attaching stores, zarafa-archiver will create genuine archive stores on the server and attaches the user stores to these archive stores based on the information found in LDAP or in Active Directory.
When using this method of attaching and detaching, Outlook and Webaccess will load the archive stores and all opened shared stores automatically.
To use this feature the enable_auto_attach setting must preferably be set to yes in /etc/zarafa/archiver.cfg: 
enable_auto_attach = yes
Alternatively zarafa-archiver can be run periodically to perform the auto-attach operation: 
zarafa-archiver --auto-attach

5.1.1. Using OpenLDAP

To add an archive store to a user through LDAP, the zarafaUserArchiveStores attribute has to be modified. This is a multi value attribute, which needs to be set to the server name or server names of the servers that contain an archive store for the user.
A typical ldif could look like this: 
dn: uid=user,ou=users,dc=example,dc=com
objectClass: inetOrgPerson
objectClass: organizationalPerson
objectClass: person
objectClass: top
objectClass: zarafa-user
objectClass: posixAccount
cn: User
gidNumber: 0
homeDirectory: /bin/false
sn: User
uid: user
uidNumber: 1000
givenName: User
mail: user@server.com
userPassword:: e1NTSEF9VzlXV0U3N1NEcW54UkJ3SFJkQUYvVkhrUj
zarafaAccount: 1
zarafaUserServer: userServer
zarafaUserArchiveServers: archiveServer

참고

The archive store won’t be created or attached until the next run of zarafa-archiver -A with enable_auto_attach = yes or zarafa-archiver --auto-attach.

5.1.2. Using Active Directory

To add an archive store to a user in Active Directory, one has to open the user in the Active Directory Users and Computers window and select the Zarafa Features tab.
ADS Features tab
그림 5.1. ADS Features tab

Next, select the Archiver feature and click Properties. This will pop up the dialog in which the server names of the servers on which an archive store should exist for the selected user or users.
Select archive servers
그림 5.2. ADS Select archive servers

참고

The archive store won’t be created or attached until the next run of zarafa-archiver -A with enable_auto_attach = yes or zarafa-archiver --auto-attach.

5.1.3. Listing attached archives

To see which archive stores are attached to a user’s primary store execute the following command: 
zarafa-archiver -u <user name> --list
This will output a list of attached archives. Each line contains the name of the archive store, the name of the folder that acts as root for the archive and the access rights the owner has for the archive store.
The store name will equal the name that was passed when the archive was attached. The archive folder name will be one of three things. It will be the full name of the user if no name was specified when the archive was attached. If a name was specified, the archive folder will be that name. Or if the archive was attached in a one-to-one configuration, it will be Root Folder.
The access rights will be Read Only when the archive was attached without write permissions. If it was attached with write access it will be Read Write. If the permissions were manually changed since the archive was attached, the rights field will display the configured role for the rights or all the rights if no matching role exists.

5.1.4. Detaching an archive

To detach an archive mailbox of a user, the archive server has to be removed in the Zarafa feature tab.

참고

When detaching an archive that already contained archived and stubbed messages, the stubbed messages can still be opened.

5.1.5. Listing users that have an archive attached

To see which users have an archive attached execute the following command: 
zarafa-archiver --list-archiveusers

5.1.6. See details of archive store

The details of an archive store can be obtained in two ways:
  • By requesting the details of the user owning the archive: 
> zarafa-admin --details user1
Username:           user1
Fullname:           User 1
Emailaddress:       user1@cluster.sio2
Active:             yes
Administrator:      no
Address book:       Visible
Auto-accept meeting req:no
Home server:        cnode-1
Last logon:         12/09/2011 03:41:32 PM
Last logoff:        12/09/2011 03:41:32 PM
Mapped properties:
    PR_GIVEN_NAME           User
    PR_SURNAME              One
    PR_EC_ENABLED_FEATURES  pop3
    PR_EC_DISABLED_FEATURES imap
    PR_EC_ARCHIVE_SERVERS   cnode-2
Attached archives:  1
    Root Folder in Archive - User 1 [Read Only]
Quota overrides:    no
Warning level:      unlimited
Soft level:         unlimited
Hard level:         unlimited
Current store size: 14.86 MiB
Groups (1):
    Everyone

Archive details on node 'cnode-2':
Current store size: 114.68 MiB
All attached archive details are appended at the end.
  • By explicitly requesting the archive details on a specific node: 
> zarafa-admin --details user1 --type archive --node cnode-2
Current store size: 114.68 MiB

중요

The node on which the archive is stored must be specified in order to find the archive.
These methods only apply to genuine archive stores. Details of regular stores that are manually attached as archives can be obtained by obtaining the details of the user owning that store: 
> zarafa-admin --details archive
Username:           archive
Fullname:           Archive Store
Emailaddress:       archive@cluster.sio2
Active:             no
Administrator:      no
Address book:       Hidden
Auto-accept meeting req:no
Home server:        cnode-2
Last logon:         12/09/2011 03:41:32 PM
Last logoff:        12/09/2011 03:41:32 PM
Mapped properties:
    PR_GIVEN_NAME           Archive
    PR_SURNAME              Archive
    PR_EC_ENABLED_FEATURES  pop3
    PR_EC_DISABLED_FEATURES imap
Quota overrides:    no
Warning level:      unlimited
Soft level:         unlimited
Hard level:         unlimited
Current store size: 114.68 MiB
Groups (1):
    Everyone

5.1.7. Unhooking an archive store

An archive store can be unhooked the same way as a regular store, but with the addition of the type and node arguments: 
> zarafa-admin --unhook-store user1 --type archive --node cnode-2
Store unhooked.

5.1.8. Hooking an archive store

An archive store can be hooked the same way as a regular store, but with the addition of the type and node arguments: 
> zarafa-admin --list-orphans --node cnode-2
Stores without users:
    Store guid                          Guessed username    Last login      Store size  Store type
    -----------------------------------------------------------------------------------------------
    F1A6BFCD67604B0FB733F746F1D00A91    user1               <unknown>       0           archive
> zarafa-admin --hook-store F1A6BFCD67604B0FB733F746F1D00A91 -u user1 --type archive --node cnode-2
Store hooked.

5.1.9. Removing an archive store

An archive store can be removed the same way as a regular store, but with the addition of the type and node arguments: 
> zarafa-admin --unhook-store user1 --type archive --node cnode-2
Store unhooked.
> zarafa-admin --list-orphans --node cnode-2
Stores without users:
    Store guid                          Guessed username    Last login      Store size  Store type
    -----------------------------------------------------------------------------------------------
    F1A6BFCD67604B0FB733F746F1D00A91    user1               <unknown>       0           archive
> zarafa-admin --remove-store F1A6BFCD67604B0FB733F746F1D00A91 --node cnode-2
Store removed.

6장. Running the Archiver

6.1. Perform archiving task
6.1.1. From the command-line
6.2. Perform cleanup task
6.2.1. From the command-line

6.1. Perform archiving task

Archiving can be done for all users, all users on one primary server or on a per-user basis.

6.1.1. From the command-line

The following command performs one archive run for all users: 
zarafa-archiver -A
Passing the --local-only option to zarafa-archiver causes it to only archive the primary stores that live on the server to which zarafa-archiver is connected. This is the server on which zarafa-archiver is executed unless otherwise configured in the configuration file. 
zarafa-archiver -A --local-only
It’s also possible to explicitly specify which users primary store to archive: 
zarafa-archiver -u <user name> -A
It’s recommended to perform the Archiver run every night. This can be done by adding the following line to /etc/crontab. 
0 1 * * * root [ -x /usr/bin/zarafa-archiver ] && /usr/bin/zarafa-archiver -A

6.2. Perform cleanup task

To keep the archive in sync with the primary store when items are deleted in the primary store, the archiver needs to be started in cleanup mode. This is a separate operation because it’s a time consuming operation. It’s therefore recommended to run cleanup less often than the archive operation.

6.2.1. From the command-line

The following command performs a cleanup for all users: 
zarafa-archiver -C
Passing the --local-only option to zarafa-archiver causes it to only cleanup the archives of users who have a store on the server to which zarafa-archiver is connected. This is the server on which zarafa-archiver is executed unless otherwise configured in the configuration file. 
zarafa-archiver -C --local-only
It’s also possible to explicitly specify which users archive to cleanup: 
zarafa-archiver -u <user name> -C
It’s recommended to perform the cleanup run once a week. This can be done by adding the following line to /etc/crontab. 
0 3 * * 0 root [ -x /usr/bin/zarafa-archiver ] && /usr/bin/zarafa-archiver -C
This will clean up all archives every sunday at 3:00 am.

7장. Client Features

To allow a user to browse and search in his archive or in the archives of shared stores, the archives are automatically added in Outlook and in WebAccess.
Outlook Hierarchy with Archives
그림 7.1. Outlook Hierarchy with Archives

Webaccess Hierarchy with Archives
그림 7.2. Webaccess Hierarchy with Archives

8장. Zarafa Archiver Extras

8.1. Installation
8.2. The Tools
8.2.1. Zarafa Archiver ACL Sync
8.2.2. Zarafa Archiver ACL Set
8.2.3. Zarafa Archiver Restore
The Zarafa Archiver Extras package contains additional tools to enhance the basic Zarafa Archiver functionality.

8.1. Installation

The Zarafa Archiver Extras can be found in the zarafa-archiver-extra package.

8.2. The Tools

8.2.1. Zarafa Archiver ACL Sync

8.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 archive stores. However, no user will ever get more rights on a store or folder than the owner of the archive has. So if 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 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.

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

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.
The za-aclset should be executed from a cronjob to synchronise the rights between the Primary store and the archive store on a regular basis.

8.2.3. Zarafa Archiver Restore

8.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 restored messages are sanitized, allowing them to be properly re-archived 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.