これまでのバージョンからのアップグレード/移行で、Zimbraの新規機能であるモバイル同期モジュールの有効化を予定している場合は、重要な情報である "Things to Know Before Upgrading"インストールガイド を必ず一読するようにしてください。

License

CC BY-SA Synacor, Inc., 2019

© 2019 by Synacor, Inc. Zimbra Collaboration Administrator Guide

本書はクリエイティブ・コモンズの表示+継承4.0国際ライセンスの適用対象です(Synacor社との間に別途ライセンス合意がある場合を除く)。次のサイトからこのライセンスを閲覧できます。 https://creativecommons.org/licenses/by-sa/4.0

あるいは、Creative Commons, PO Box 1866, Mountain View, CA 94042, USA.宛てに連絡してください。

Synacor, Inc., 2016
40 La Riviere Drive, Suite 300
Buffalo, New York 14202

はじめに

Zimbra Collaboration は電子メール、アドレス帳、カレンダー、タスクおよびウェブドキュメント編集の機能をすべて兼ね備えた、メッセージングとコラボレーションのソリューションです。

対象読者

本ガイドは、Zimbra Collaborationのサーバー環境のインストール、保守、サポートを担当するシステム管理者向けに作成しています。

本ガイドの適切な利用には、次の知識やスキルが必要です。

  • 関連する技術や知識

  • Linuxオペレーティングシテム、およびオープンソースのコンセプトに関する知識

  • メールシステム管理に関する運用知識

サードパーティ製のコンポーネントについて

バックアップ管理、ユーザー認証、オペレーティングシステムおよびデータベース管理に関し、Zimbra Collaborationは標準規格やオープンソースの推進を可能な範囲において遵守します。ただし、「製品の概略」章で紹介している、正規のテストで証明された使用方法に限り、サポートします。本ガイドに参考程度に記載している箇所はありますが、Zimbra Collaborationでは、他のサードパーティ製のツールのサポートや認証はいたしません。

サポートと連絡情報

www.zimbra.com から、オープンソースメッセージングのベストソリューションのコミュニティーに参加できます。皆様からのフィードバックや製品への要望をお待ちしております。

  • Zimbra Collaboration の購入に関しては、sales@zimbra.comまでご連絡ください。

  • ネットワーク版をご利用のお客様に対するサポートに関しては、support@zimbra.comまでご連絡ください。

  • Zimbra のフォーラム から、インストールや設定についての問題解決に関する情報を確認できます。

  • Zimbra のフォーラムに参加すると、 Zimbra Collaboration に関する情報を他のユーザーと共有できます。

製品関連の詳細については、以下からご覧ください。

製品に対する疑問やご希望される機能追加については、Zimbraのフォーラムに投稿し、お知らせください。

製品のライフサイクル

以下に Zimbra コンポーネントの製品ライフサイクルについて詳細を案内します。

コンポーネントのサポート終了について

コンポーネント サポート終了の詳細

IMAPD

IMAPD は Zimbra 8.8.5 にベータ版の機能として提供しましたが、安定した状態として提供しておりません。本機能の提供を終了いたしました。

Exchange用のZCS移管ウイザード

このツールはPSTファイルのインポートでのみサポートしており、テクニカルガイダンスとして2010年12月31日までサポートします。 なお、すべてのアカウント移管の代替案として、 Audriga社の移管ソリューション の利用を推奨しております。

Domino用のZCS移管ウイザード

サポート終了

ZCSのアカウント移管

Zimbra管理コンソールのGUIでのZCSアカウント移管のサポートが終了しており、テクニカルガイダンスが2019年1月17日となっております。

エンタプライズのモジュール

Zimbraのクラシック HSM, クラシック Backup, およびクラシック Mobile のサポートが終了しており、次回の Zimbra 8.8 のリリースから削除する予定です。 ネットワーク版のNGモジュール、またはZSPへ移管していない場合、お早めに移管いただくことを推奨しております。

Zimbra デスクトップ

デスクトップクライアントのサポートが終了しており、テクニカルガイダンスが2019年10月1日までとなっております。

Zimbra タッチクライアント

サポート終了

Zimbra モバイルクライアント

サポート終了

HTML クライアント

サポート終了しており、テクニカルガイダンスが2022年7月1日までとなっております。

製品の概略

本章ではZimbraコンポーネントのシステム概要を説明します。

インフラの概要

Zimbra Collaboration のアーキテクチャは既知のオープンソース技術と業界標準に基づいたプロトコルから構成されています。そして、単体あるいは複数サーバーで構成された環境で稼動可能なクライアントインターフェースやサーバーコンポーネントによって、高い利便性と拡張性を実現しています。

Architectural Overview

Zimbra Collaboration のアーキテクチャの主な特性

主な特性 コンポーネンツ/説明

オープンソース技術

Linux®, Jetty, Postfix, MariaDB, OpenLDAP®

業界基準のオープンプロトコル

SMTP, LMTP, SOAP, XML, IMAP, POP

現代の技術をいかした設計

HTML5, Javascript, XML, Java

スケーラビリティ

Zimbraの各メールボックスサーバーには、メールボックスアカウントと紐づくメッセージおよびインデックスが格納されます。Zimbraのプラットフォームは、縦横無尽に拡張することができます (システムリソース追加、サーバー追加)。

ブラウザでのクライアント画面

一般的なウェブプラットフォームから、簡単かつ直感的にZimbra Collaboration機能を利用することができます。

ブラウザでの管理コンソール

メール、カレンダー、共有機能

Zimbra Collaboration は革新的なメッセージングとコラボレーションのアプリケーションであり、ブラウザベースのウェブクライアントからアクセス可能な最先端のソリューションを提供しています。

  • 直観的なメッセージ管理、検索機能、タグ機能、共有機能

  • 公開、非公開あるいは共有可能なカレンダー

  • 非公開あるいは共有可能なアドレス帳や配信リスト

  • 非公開あるいは共有可能なタスクリスト

Zimbra のコンポーネント

Zimbraのアーキテクチャは、業界標準のプロトコルを利用したオープンソース技術で構成されています。サードパーティー製のソフトウェア一覧にあるサードパーティー製のソフトウェアはZimbraのソフトウェアにバンドルされているので、Zimbraのインストール処理時に自動インストールされます。これらのコンポーネントはZimbraで使用できるように検証・設定されています。

Table 1. サードパーティー製のソフトウェア一覧
サードパーティーコンポーネント 説明

Jetty

Zimbraソフトウェアが起動するウェブアプリケーションサーバー

Postfix

適したZimbraサーバーへメールメッセージを転送するオープンソースのメール転送エージェント (MTA)

Open LDAP ソフトウェア

Zimbra のシステム設定とZimbraのグローバルアドレス帳を格納し、ユーザー認証を行う、Lightweight Directory Access Protocol (LDAP) のオープンソース実装。ZimbraはActive Directoryなどの外部LDAPディレクトリより提供しているGALやユーザー認証サービスでも利用できます。

MariaDB

データベースソフトウェア

Lucene

オープンソースのテクストと検索エンジン

特定の添付ファイルの種類をHTMLへ変換するサードパーティソース

アンチウイルスとアンチスパム

オープンソース部分では以下が含まれています。

  • ClamAV: アンチウイルスのスキャナー

  • SpamAssassin: 迷惑メールを判断するメールフィルター

  • Amavisd-new : MTAと複数のコンテンツフィルターのインターフェース

Apache JSieve

メール用フィルターを管理

LibreOffice

ハイファイなドキュメントプレビュー

Zimbra のアプリケーションパッケージ

Zimbra Collaboration には、アプリケーションパッケージ一覧にあるアプリケーションパッケージが含まれています。

Table 2. アプリケーションパッケージ一覧
パッケージ 説明

Zimbra Core

ライブラリ、ユーティリティ、監視ツール、基準の設定ファイル。 Zimbra-core内にある zmconfigd は自動的に有効にされ、全てのシステムで起動します。

Zimbra Store

(Jettyを含む) メールボックスサーバー用コンポーネント。Zimbraメールボックスサーバーには以下のコンポーネントが含まれます。

  • データストア — MariaDBのデータベース。

  • メッセージストア — メールメッセージおよび添付ファイルすべての保存先。

  • インデックスストア — インデックスと検索技術はLuceneで提供しています。インデックスファイルは各メールボックスに保持されます。

  • ウェブアプリケーションサービス — Jettyウェブアプリケーションサーバーがいずれかのストアサーバー上でウェブアプリケーションを実行します。1つ以上のウェブアプリケーションサービスを提供します。

Zimbra LDAP

Zimbra Collaboration はオープンソースのLDAPディレクトリサーバーである、 OpenLDAP® のソフトウェアを使用しています。ユーザー認証やZimbraのグローバルアドレス帳、そして設定の属性は、OpenLDAPより提供されるサービスです。なお、ZimbraのGALやユーザー認証は、Active Directoryなどの外部LDAPディレクトリでも運用できます。

Zimbra MTA

Postfixはオープンソースのメール通信エージェント (MTA) です。PostfixではSMTPよりメールを受信し、ローカルメール通信プロトコル (LMTP) を利用してメッセージを適したZimbraメールボックスサーバーへとルートします。 また、ZimbraのMTAにはアンチウイルスとアンチスパムのコンポーネントも含まれています。

Zimbra Proxy

Zimbra プロキシはIMAP[S]/POP[S]/HTTP[S]のクライアントリクエストを内部 ZCS サービスへ配信する高パフォーマンスなプロキシサービスです。このパッケージは通常、MTAサーバーまたは独自サーバーにインストールされます。Zimbra-proxyパッケージがインストールされるとプロキシ機能がデフォルトで有効化されます。Zimbraプロキシをインストールすることを強く推奨しますし、分散されたウェブアプリケーションサーバーを使用する場合は必要です。

Zimbra Memcached

ZimbraプロキシをインストールするとMemcachedが自動的に選択されます。プロキシを使用する場合は最低1つのサーバーでzimbramemcachedを実行する必要があります。1つ以上のZimbraプロキシを備えた単一のMemcachedサーバーを使用することもできます。分散されたウェブアプリケーションサーバーを使用する場合、zimbra-memcachedが必要です。

Zimbra SNMP (任意)

サーバー監視のためZimbra SNMPをインストールする場合、このパッケージを各Zimbraサーバーにインストールする必要があります。

Zimbra Logger (任意)

使用する場合は、1つのメールボックスサーバーにのみインストールし、同時にメールボックスサーバーとしてインストールしなければなりません。このZimbraロガーにより、syslogの記録・取得用ツールがインストールされます。ロガーをインストールしないと、管理コンソールに サーバー統計 は表示されません。

Zimbra Spell (任意)

AspellのオープンソーススペルチェックをZimbraウェブクライアントに使用しています。Zimbra-Spellをインストールする場合、Zimbra-Apacheパッケージもインストールされます。

Zimbra Apache

このZimbra Apacheパッケージは、Zimbra Spell、またはZimbra Convertdのインストール中にインストールされます。

Zimbra Convertd

このパッケージはZimbraストアサーバーにインストールします。Zimbra CollaborationのシステムにはZimbra-Convertdパッケージは1つのみ必要です。デフォルトでは1つのZimbra-Convertdが各Zimbraストアサーバーにインストールされます。Zimbra- Convertdをインストールすると、Zimbra-Apacheのパッケージもインストールされます。

Zimbra Archiving (任意)

アーカイブとディスカバリー機能によりZimbra Collaborationが送受信したメッセージをすべて格納・検索することができます。このパッケージはメールボックスのクロス検索機能を含んでおり、使用中のメールボックスおよびアーカイブされたメールボックスの両方に対してメッセージ検索が可能です。 備考:アーカイブとディスカバリー機能を使用するとメールボックス利用ライセンスの追加につながる恐れがあります。Zimbra アーカイブとディスカバリー機能に関する詳細はZimbraの営業部までご連絡ください。

メールの流れ — マルチサーバー設定

各環境の設定内容は、変数の数値によって変わ変化します。例えば、メールボックス数、メールボックス容量、パフォーマンス要件、既存のネットワークインフラ、ITポリシー、セキュリティ方針、スパムフィルターリング要件などです。一般的にどの環境でも、発生するトラフィックやユーザー接続は下図に示すとおり、共通しています。ネットワーク内で数値の部分を設定するという方法でも可能です。

Mail Flow - Multi-Server Configuration

図の順番の説明をします。

  1. インターネットメールを受信したら、迷惑メールのフィルターリングのため、ファイアウォールとロードバランサーを通してからEdge MTAへ送ります。

  2. フィルターされたメールが2番目のロードバランサーへ届きます。

  3. 外部ユーザーがメッセージングサーバーへ接続した場合も、ファイアウォールと2つのロードバランサーを通ります。

  4. 受信されたインターネットメールは、いずれかのZimbra Collaboration のMTAサーバーへと向かい、迷惑メールとウイルスのフィルターリングを通過します。

  5. 対象のZimbra Collaboration MTAサーバーは宛先のディレクトリ情報をZimbra CollaborationのLDAPレプリカのサーバーに検索しにいきます。

  6. Zimbra Collaboration のLDAPサーバーからユーザー情報を取得後、MTAサーバーは適したZimbra Collaboration メールボックスサーバーへメールを通信します。

  7. 内部のエンドユーザーから接続される場合は、Zimbra Collaboration サーバーのいずれかに直接接続し、Zimbra Collaboration LDAPからユーザー情報を取得します。必要に応じてリダイレクトされます。

  8. マウントしたディスクに対してZimbra Collaborationサーバーのバックアップをとることも可能です。

Zimbra システムディレクトリのツリー

以下の表はZimbraのインストールパッケージで作成されるメインディレクトリの一覧です。(親である) /opt/zimbra 配下にインストールする場合、Zimbra CollaborationではどのZimbra Collaborationサーバーでもディレクトリ構成は同じになります。

この表にないディレクトリは、Zimbraのコアとなるソフトウェアや、その他サードパーティ製のツールに必要とされるライブラリです。
Table 3. /opt/zimbra 配下のシステムディレクトリツリー
ファイル 説明

backup/

完全バックアップと増分バックアップのデータを保存

bin/

コマンドラインのユーティリティにて記載されているユーティリティを含むZimbra Collaboration のアプリケーションファイル

cdpolicyd

ポリシーのファンクション、スロットル機能

clamav/

ウイルスや迷惑メールを制御するClam AVのアプリケーションファイル

conf/

設定の情報

contrib/

通信に使用するサードパーティ製のスクリプト

convertd/

変換のサービス

cyrus-sasl/

SASL AUTH のdaemon (デーモン)

data/

LDAP、mailboxd、postfix、amavisd、clamavなどのデータディレクトリを含みます。

db/

データストア

docs/

SOAPやその他の技術に関するtxtファイル

extensions-extra/

様々な認証方法に関するサーバーの拡張

extensions-network-extra/

様々なネットワーク認証方法に関するサーバーの拡張

httpd/

Apacheのウェブサーバーを含みます。Aspellとconvertdを別々のプロセスとして使用します。

index/

インデックスのストア

java/

Javaのアプリケーションファイル

jetty/

mailboxdアプリケーションサーバーインスタンス。このディレクトリの webapps/Zimbra/skins 配下にZimbra UIのテーマファイルが入っています。

lib/

ライブラリ

libexec/

内部で使用する実行ファイル

log/

Zimbra Collaboration サーバープリケーションのローカルログ

logger/

ログサービスが使用するRRDとSQLite のデータファイル

mariadb/

MariaDB のデータベースファイル

net-snmp/

統計収集に使用

openldap/

OpenLDAPのサーバーインストール。ZCSが使用できるようにあらかじめ設定されています。

postfix/

Postfixのサーバーインストール。Zimbra Collaborationが使用できるようにあらかじめ設定されています。

redolog/

Zimbra Collaboration サーバーでの最新の実行ログ

snmp/

SNMPのモニターファイル

ssl/

証明書

store/

メッセージストア

zimbramon/

コントロールのスクリプトやPerlモジュール

zimlets/

Zimbraと一緒にインストールするZimletのZipファイル

zimlets-deployed/

Zimbraのウェブクライアントで使用可能なZimlet

zimlets-network/

ネットワーク版のZimbraと一緒にインストールするZimletのZipファイル

zmstat/

mailboxd の統計。csvファイルとして保存されます。

Zimbraウェブクライアント

ユーザーはZimbra機能を使用する際に、様々なウェブクライアントからログインすることができます。ウェブクライアントではメール、カレンダー、アドレス帳、タスク等の機能を利用できます。

Table 4. Zimbraウェブクライアント
クライアントのタイプ 説明

アドバンス ウェブクライアント

Ajaxが動作可能で、ウェブコラボレーションの全機能を利用できます。高速なネットワーク回線および比較的新しいブラウザで快適に動作します。

標準 ウェブクライアント

低速インターネット回線やメールボックスをHTMLベースで使用したいユーザーに向いています。

モバイル HTML クライアント

標準 ウェブクライアント使用中にZimbraへのモバイルアクセスを行います。

Zimbraへのログイン時、ログイン画面で標準ウェブクライアントへ変更するメニューを使用しない限り、アドバンス ウェブクライアントが表示されます。ZWCは画面解像度が800x600であることを検知すると、自動で標準ウェブクライアントにリダイレクトします。ユーザーはこの場合もアドバンス ウェブクライアントを選択できますが、見やすい画面表示のための、標準ウェブクライアントを推奨するメッセージが表示されます。

ウェブサービスとデスクトップクライアント

Zimbra Collaborationへの接続は、ウェブブラウザやモバイルデバイスの他に、Exchangeウェブサービス (EWS) などのウェブサービスや、MAPIを使ったMicrosoft Outlook Zimbraコネクタのようなデスクトップクライアントからも可能です。以下をサポートします。

  • Exchange ウェブサービス (EWS) Mac端末でMicrosoft Outlookを利用する際の Zimbra Collaboration とExchangeサーバーとのクライアント通信を可能にします。EWSのクライアント通信を有効化する方法は、提供サービスの章を参照してください。EWSはライセンス対象のアドオン機能です。

  • Messaging Application Programming Interface (MAPI) Microsoft Outlook 2013/2010/2007/2003との同期が可能です。全てを委譲でき、オフラインアクセスも可能で、S/MIMEもサポートしています。Windows端末でMicrosoft Outlookを利用する際は、Zimbra Collaborationへの接続にOutlook用のZimbraコネクタを使用してください。MAPI (Microsoft Outlook)コネクタを有効化する方法は、提供サービスの章を参照してください。

  • サポート対象:全てのPOP3、IMAP4、CalDAVクライアント、CardDAVクライアント

オフラインモード

Zimbraのオフラインモードではネットワーク接続がない場合にも Zimbraウェブクライアント(ZWC)を使用してデータにアクセスすることができます。

例えば、サーバー接続がない場合やサーバー接続が切断された場合は、ZWCが自動的に“オフラインモード”へ切り替えます。サーバー接続が復元されると、自動で“オンラインモード”に切り替えます。

オフラインモードでは、通常のブラウザキャッシングを考慮したキャッシュ機能のあるHTML5を使用します。

セキュリティ対策

情報インフラを守るための最善策のひとつは、セキュリティ対策を複数組み合わせて使用し、システム全体のセキュリティを向上させることです。以下に記載したこうした対策は、防御用のメカニズムとしてZimbra Collaboration のプラットフォームに実装されています。

セキュリティ関連のニュースや注意など、最新の情報や詳細は、 Zimbra WikiSecurity Center からご覧ください。

認証とアクセス管理

ユーザー認証管理を目的としてシステムに搭載した機能を下の表にまとめました。

Table 5. 認証とアクセス管理機能
機能 説明

ライフサイクル管理

Zimbra Collaborationのユーザー管理関連の登録・読込・更新・削除の全機能にLDAPディレクトリを使用します。 LDAP利用は任意ですが、Zimbra Collaboration専用の属性はすべて、従来のLDAPディレクトリにて格納・管理されます。

1要素認証

システムへのアクセスに必要とされる、ユーザーの登録済みユーザー名とパスワードのペアです。 この認証情報はソルト付ハッシュにてユーザー用ストアに登録されています。入力されたパスワードと比較して、承認 (一致) か不承認 (不一致) かを判断します。外部ディレクトリ (LDAPまたはActive Directory) を使用したい場合は、その外部LDAPディレクトリにログイン情報を格納することもできます。詳しくはZimbra LDAP サービスをご覧ください。

2要素認証

2層のセキュリティ認証です。管理コンソールから、ZCSと連携しているモバイル端末にパスコード生成を行う (Enabled) か行わないか (Disabled) を設定します。ユーザーまたはCOSアカウントに対して生成を行うを設定した場合は、クライアントサービスへの接続に、生成されたパスコードの使用が必要となります。詳しくは2要素認証について2要素認証をご覧ください。

アクセス権認証

ユーザーカウントは、様々な属性や権限レベル、ルールによって、実行可能な機能や閲覧可能なデータについて定義されています。管理コンソールの管理者は、各業務をサポートする目的でグループの作成や、アクセス権限の割り当てができます。

情報セキュリティとプライバシー

データ保全を目的としてシステムに搭載した機能を下の表にまとめました。

Table 6. 情報セキュリティとプライバシー機能
主旨 説明

セキュリティ・統一性・プライバシーの管理

Zimbra Collaboration は (公的信用のある認証局 (CA) から与えられた) S/MIME 認証の使用ならびに、内部PKI (公開鍵基盤) 、ドメインキー認証メール (DKIM) 、DMARC (Domain-based Message Authentication) 、Amavisd-new (受信、送信用DMARCポリシーを管理するためにMTAで稼働している) の利用をサポートしています。

暗号化メソッド

In-transit

後述のプロトコルに加え、TLSを利用して、サービスとエンドポイントを安全につなぎます: SMTP, LMTP+STARTTLS, HTTPS, IMAPS/IMAP+STARTTLS, POP3S/POP3+STARTTLS

At-rest

エンドtoエンドの暗号であるS/MIMEを使用して、秘密鍵による復号が行われるまで、Zimbra Collaboration メッセージストアにあるデータは暗号化されています。

Anti-virus とAnti-spam

従来のZimbra Collaboration 機能とサードパーティ製プラグイン (Amavisd-new, ClamAV, Spam Assassin) にて、マルウェアとスパムの対策を行っています。

システムログ

(SNMPトリガーで生成される) Zimbra Collaboration のシステムログを、データの登録に使用できます。例えばユーザーや管理者のアクティビティ、ログイン失敗、クエリ遅延、メールボックスでのアクティビティ、モバイルシンクアクティビティ、エラー関連のデータなどです。システムのセキュリティやコンプライアンスの要件に応じ、イベントやアラート、トラップを、ログ管理とイベント修正システムへ転送して、通知およびポリシーを一元化できます。

Table 7. セキュリティデータ
機能 説明

インシデント対応

管理者は、悪意のあるアクションや不慮の行動に対し、リモートでのデバイズワイピングやアカウント凍結を行うことができます。

アーカイブとディスカバリ

この任意の機能により、管理者は、アーカイブメールボックスと現行メールボックスのアーカイブや保存ポリシーの適用対象とする特定のユーザーのメールメッセージを選択できます。

ライセンス

アカウントの作成にはZimbraライセンスが必要です。Zimbraのライセンスの購入、更新、変更時は、その最新のライセンス情報にてZimbraサーバーを更新します。

ライセンスの種類

Zimbra Collaboration のライセンス機能により管理者は、配備予定のライセンスを見た目に分かりやすく制御できます。なお、以下のライセンスされた機能の監視や管理は可能となっています。

ライセンス上限 以下の上限を設定

アカウント上限

作成可能アカウント数と作成済みアカウント数が表示されます。

MAPIアカウント上限

Microsoft Outlook(ZCO)用Zimbraコネクタを使用できるアカウント数。

Exchange ウェブサービス(EWS) のアカウント上限

Exchangeサーバーへの接続にEWSを使用できるアカウント数。EWSはライセンス対象のアドオン機能です。

ハイファイなドキュメントプレビュー

ハイファイなドキュメントプレビューを使用できるアカウント数。LibreOfficeをインストールする必要があります。

アーカイブ用アカウント上限

作成可能アーカイブ用アカウント数。アーカイブ機能をインストールする必要があります。

提供しているライセンスの種類

Zimbra Collaborationの試用版を無料で入手できます。本番環境にインストール後は、サブスクリプションまたはパーペチャルの購入が必要なります。

ライセンスの種類 目的

試用版

無料。Zimbraのウェブサイト(https://www.zimbra.com) から入手できる試用版。最大50ユーザーの作成が可能。最大60日間有効。

試用延長版

無料。最大50ユーザーの作成が可能。期間延長可。Zimbra営業部より入手できます。sales@zimbra.com または1-972-407-0688までご連絡ください。

サブスクリプション

有料。特定のZimbra Collaboration システムに適用可。購入したZimbraアカウント数、使用開始日および有効期限がライセンスファイル内に暗号化されています。

パーペチャル

有料。サブスクリプションと同様、特定のZCSシステムシステムに適用可。購入したZimbraアカウント数、使用開始日および有効期限2099年12月31日がライセンスファイル内に暗号化されています。サポート契約を更新する場合、新しいパーペチャルライセンスは発行されませんが、システムにあるお客様のアカウントレコードはサポート終了日にて新たに更新されます。

アカウント種類でのライセンス影響

以下にZimbra Collaboration のアカウント種類とライセンスへの影響を説明します。

ライセンスのアカウント種類 目的

システムアカウント

システムアカウントはZimbra Collaborationで使用する特別なアカウントです。迷惑メール(スパムとハム)フィルターリング用アカウント、ウイルス付きメール隔離用アカウント、ドメインにGALを設定するGALsync用アカウントなどがあります。削除しないようにご注意ください!システムアカウントはライセンスのアカウント数には含まれません。

管理者アカウント

管理者アカウントと管理権限委譲アカウント。ライセンスのアカウントとしてカウントされます。

ユーザーアカウント

ユーザーアカウントはライセンスのアカウント上限数にカウントされます。アカウントを削除すると、この変更がライセンスのアカウント上限数に反映されます。

エイリアスアカウント

非該当

配布リスト

リソースアカウント

ライセンスのアクティベーション

ネットワーク版の環境はすべて、ライセンスをアクティベーションする必要があります。新しい環境の場合はライセンス発行日から10日間のアクティベーション猶予期間があります。管理コンソールから実施可能です。

管理コンソール:

ホーム > 設定 > グローバル設定 > ライセンス にアクセスし、画面の右上 ギア アイコンの ライセンスのアクティベーション を選択します。

Zimbra Collaborationのアップグレード時は、ネットワーク版の機能を継続するためにただちにアクティベーションする必要があります。

ライセンスのアクティベーションについて

Zimbra Collaboration サーバーが外部インターネットへの接続があり、かつ、Zimbraライセンスサーバーに繋がる場合、ライセンスは自動でアクティベーションされます。ライセンスが自動でアクティベーションされない場合は、 手動でのライセンスのアクティベーションについてを参照してください。

手動でのライセンスのアクティベーションについて

Zimbraライセンスサーバーへ外部接続ができないシステムの場合、 Zimbraのサポートポータルを利用すると、マニュアル操作でライセンスをアクティベーションすることができます。Zimbraのホームページ(www.zimbra.com)へアクセスし、Support をクリックすると、Zimbraのテクニカルサポートページが表示されます。Zimbra Collaboration Suport をクリックすると、サポートポータルページが表示されます。メールアドレスとパスワードを入力してログインします。

サポートポータルにアクセスできない場合は、sales@zimbra.com までお問い合わせください。

ライセンスがインストールまたはアクティベートされていない場合

Zimbra Collaboration サーバーライセンスのインストールまたはアクティベーションに失敗した場合のZimbra Collaborationサーバーへの影響は次のとおりです。

ライセンス状態 説明・影響

インストールされていない

Zimbra Collaboration はシングルユーザーモードに切り替わり、全機能が1ユーザーの利用に制限されます。

無効

Zimbra Collaboration はシングルユーザーモードへと切り替わります。

アクティベートしていない

ライセンスのアクティベーション猶予期間は10日間です。何かしらの理由によりライセンスがアクティベーションされない場合、 猶予期間後、Zimbra Collaboration はシングルユーザーモードへと切り替わります。

開始が未来日

Zimbra Collaboration はシングルユーザーモードです。

猶予期間中

ライセンス満了日が過ぎ、30日の更新猶予期間中です。ライセンス契約していた機能はまだすべて有効ですが、ライセンスの更新警告メッセージを管理者が確認する可能性があります。

満了

ライセンス満了日が過ぎ、30日の更新猶予期間も経過しています。 Zimbra Collaboration サーバーはオープンソース版の機能へと切り替わります。

ライセンスを入手する

ZimbraのホームページにあるDownloadsから無料の試用版ライセンスを入手できます。試用延長版ライセンスやサブスクリプション、パーペチャルの入手については、Zimbraの営業部 sales@zimbra.com までお問い合わせください。

購入したZimbra Collaboration システムにのみサブスクリプションやパーペチャルのインストールが可能です。お客様のZimbra Collaboration 環境にに必要なZimbraライセンスは1つです。このライセンスには作成可能なアカウント数の上限を設定します。

購入したアカウント数、使用中アカウント数、満了日などの現ライセンス情報は ホーム > 設定 > グローバル設定 > ライセンス から確認できます。

ライセンスを管理する

管理コンソールの グローバル設定 ページにある ライセンスを更新 ウィザードを使用して、新しいライセンスのアップロードとインストールができます。ライセンスのアクティベーション を使用すると、インストールされているライセンスがアクティベーションされます。

ホーム > 設定 > グローバル設定 > ライセンス から、現ライセンス情報を確認できます。ライセンスID、利用開始日、満了日、購入アカウント数および使用可能アカウント数が表示されます。

ライセンス情報

アカウントを作成するには、 Zimbra Collaboration のライセンスが必要です。ライセンスの購入、更新、変更時は、その最新のライセンス情報にてZimbraサーバーを更新する必要があります。管理コンソールのグローバル設定ページにある ライセンスを更新ウィザード から、新しいライセンスのアップロードとインストールができます。 ライセンスのアクティベーション を使用すると、インストールされているライセンスがアクティベーションされます。

ホーム > 設定 > グローバル設定 > ライセンス で遷移したライセンス情報ページには、ライセンスID、利用開始日、満了日、購入アカウント数および使用可能アカウント数が表示されます。

使用中のアカウント数が購入したアカウント数に達すると、アカウントの新規作成ができなくなります。作成可能なアカウント数を追加で購入するか、既存の(使用していない)アカウントを削除することで、アカウントの新規作成が可能となります。作成可能なアカウント数を追加で購入する場合は、Zimbraの営業部までご連絡ください。

Zimbraのネットワーク版の機能を中断せずに継続使用する場合、ライセンスの満了日より30日間前に更新する必要があります。なお、ライセンスが満了されるまでの30日間は管理コンソールにログインするとリマインド用通知メッセージが表示されます。

ライセンスの満期

Zimbra Collaboration のネットワーク版のライセンスが満了した場合、管理コンソールおよびすべてのユーザーのウェブクライアントにて、ライセンスが満了された警告メッセージが表示されます。ライセンスの満了から30日間の猶予期間が発生します。猶予期間内では警告メッセージが表示されますが、すべての機能は継続して使用できます。

猶予期間を過ぎるとオープンソース版の機能へ自動的に切り替わります。ライセンスの満了後は、以下の重要な機能が使用できなくなります。

  • バックアップと復元

  • Exchangeウェブサービス(EWS) — EWSは別売りのライセンス機能です

  • ハイファイなドキュメントプレビュー

  • Outlook用のZimbraコネクタ

  • S/MIME

ライセンス契約したユーザー数の上限に達した場合、アカウントの作成も削除もできなくなります。

ライセンスの更新予定がない場合は、Zimbra Collaborationの無料オープンソース版(FOSS)へアップグレードすることにより、アカウントの新規作成と既存アカウントの削除が可能となります。その場合、Zimbra Collaborationのネットワーク版と同じバージョンのFOSS版を選択してから、最新のFOSS版へ更新されることをお勧めします。

更新

使用中のアカウント数が購入したアカウント数に達すると、アカウントの新規作成ができなくなります。作成可能なアカウント数を追加で購入するか、既存の(使用していない)アカウントを削除することで、アカウントの新規作成が可能となります。作成可能なアカウント数を追加で購入する場合は、Zimbraの営業部までご連絡ください。

Zimbraのネットワーク版の機能を中断せずに継続使用する場合、ライセンスの満了日より30日間前に更新する必要があります。なお、ライセンスが満了されるまでの30日間は管理コンソールにログインするとリマインド用通知メッセージが表示されます。

ライセンスを更新する

Zimbraのライセンスの更新、変更時は、その最新のライセンス情報にて Zimbra Collaboration メールボックスサーバーを更新してください。管理コンソールから、あるいはコマンドラインでzmlicenseコマンドを使用することで、ライセンスの更新が可能です。

zmlicense
管理コンソール:

ホーム > 設定 > グローバル設定 > ライセンス

ライセンスの更新

  1. 管理コンソールへ接続するパソコンにZimbraのライセンスを保存します。

  2. 管理コンソールにログイン後、 ホーム > 設定 > グローバル設定 > ライセンス に遷移し、画面の右上 ギア アイコンにある ライセンスを更新 をクリックします。 ライセンス インストール ウィザードが開きます。

  3. 保存したライセンスファイルをブラウザで選択し、次へ をクリックすると、ライセンスファイルがサーバーへアップロードされます。

  4. インストール をクリックします。アップロードしたライセンスがサーバーにインストールされます。

  5. ギア アイコンにある ライセンスのアクティベーション をクリックします。Zimbra Collaborationのアップグレード時は、ネットワーク版の機能を継続するためにただちにアクティベーションする必要があります。

ライセンスの情報が自動で更新されます。キャッシュされたアカウントライセンスの数は各メールボックスサーバーにて自動リフレッシュされます。

Zimbraのメールボックスサーバー

Zimbraのメールボックスサーバーは、メッセージ、連絡先、カレンダー、添付ファイルなど、メールボックスのすべてのコンテンツを管理するサーバーです。

Zimbraのメールボックスサーバーではバックアップとログファイルを専用のボリュームに保持します。各サーバーがアクセスできるのは、自身のサーバー内にあるストレージボリュームのみです。他のサーバーへの読み込み、書き込み、閲覧はできません。

メールボックスのサーバーについて

アカウントは1メールボックスサーバー内に設定され、各アカウントに紐づくメールボックスには、メッセージ、添付ファイル、カレンダー、連絡先、そのアカウントのコラボレーションファイルが入っています。

各Zimbraメールボックスサーバーには、そのサーバーに存在するメールボックス用に、メッセージストア、データストア、インデックスストアがスタンドアロンの状態で存在します。ここからは、各ストアとディレクトリの場所についての概要を説明します。

メッセージストア

メッセージ本文と添付ファイルを含めたメッセージの内容は全て、MIMEフォーマットにてメッセージストアに保存されます。

デフォルトでは、メッセージストアはメールボックスサーバー内 /opt/zimbra/store 配下に格納されます。各メールボックスは、その内部メールボックスIDにちなんだ固有のディレクトリを持っています。メールボックスIDは、システム全体ではなく個々のサーバー内でのみ、一意です。

受信者が複数であるメッセージの場合、メッセージ保存領域に格納されるのは1件です。UNIXシステム内のユーザーごとの固有メールボックスディレクトリには、この実ファイルへのハードリンクが格納されます。

Zimbra Collaboration がインストールされると、各メールボックスサーバーにインデックスボリュームとメッセージボリュームが1つずつ設定されます。メールボックスはそれぞれ、現在のインデックスボリューム内のディレクトリに固定で割り当てられます。新たに配信あるいは作成されたメッセージは、現在のメッセージボリュームに保存されます。

メールストレージ管理として階層型ストレージ管理(HSM)ポリシーを実装することで、比較的古いメッセージのストレージボリュームを設定できます。詳細は 設定を管理するを参照してください。

データストア

データストアとはSQLデータベースの1つで、内部メールボックスIDとユーザーアカウントとがリンク付けされているところです。スレッド、メッセージの保存先を示すポインター、タグなど、メッセージのメタデータはすべてファイルシステムに格納されます。SQLデータベースファイルは /opt/zimbra/db にあります。

各アカウント(メールボックス)は、1サーバーにしか入りません。そのサーバーに存在するメールボックスのデータを格納するデータストアがスタンドアロンの状態で存在します。

  • データストアは、メールボックスIDとユーザーのLDAPアカウントをマッピングします。Zimbra Collaboration データベース内の第一識別子はZCSメールボックスIDであり、ユーザー名やアカウント名ではありません。メールボックスIDはシングルメールボックスサーバー内では一意です。

  • ユーザーのタグ定義、フォルダ、連絡先、カレンダーの予定、タスク、ブリーフケースのフォルダ、フィルターのルールなどのメタデータは、データストアデータベースに格納されています。

  • メッセージの閲覧状況、関連タグなどのメッセージ関連情報は、データストアデータベースに格納されています。

インデックスストア

インデックスや検索の技術は、Apache Luceneを用いて提供しています。メッセージを受信した際に、メッセージ内容と添付ファイルは自動でインデックスされます。インデックスファイルは各アカウントに紐づき、/opt/zimbra/index 配下に保存されます。

トークン化とインデックスのプロセスを管理者やユーザーが設定することはできません。

Index Store

プロセスの説明

  1. Zimbra のMTAは、受信したメッセージをそのアカウントのメールボックスが存在しているメールボックスサーバーにルートします。

  2. そのメールボックスサーバーは、メッセージのヘッダーや本文、添付ファイル(PDFファイルやMicrosoft Wordドキュメントなど)を解析し、単語をトークン化します。

  3. インデックスファイル作成のため、メールボックスサーバーは、トークン化した情報をLuceneへ渡します。

トークン化とは単語単位でのインデックスです。電話番号、メールアドレス、ドメイン名などの代表的なパターンは、上の図のようにトークン化されます。

ウェブアプリケーションサーバー

Jettyウェブアプリケーションサーバーはどのストアサーバー上でもウェブアプリケーション(webapps)を実行し、単体または複数のウェブアプリケーションサービスを利用できるようにします。

メールストアサービス

メールストアサービスにより、メールボックス/アカウントのデータへのバックエンドアクセスが可能です。 メールストアのウェブアプリケーションには以下が含まれます。

  • メールストア(メールサーバー) = /opt/zimbra/jetty/webapps/service

  • Zimlets = /opt/zimbra/jetty/webapps/zimlet

ユーザーインターフェースサービス

ユーザーインターフェースサービスでは、メールボックスのアカウントデータと管理コンソールへのフロントエンドユーザーインターフェースのアクセスを提供します。以下を含みます。

  • Zimbraウェブクライアント = /opt/zimbra/jetty/webapps/zimbra

  • Zimbra管理コンソール = /opt/zimbra/jetty/webapps/zimbraAdmin

  • Zimlet = /opt/zimbra/jetty/webapps/zimlet

ウェブアプリケーションサーバースプリット

ウェブアプリケーションサーバースプリット機能により、メールストアのサービス(メールサーバー)とユーザーインターフェースのサービス(ウェブクライアントサーバー)を分けることも可能です。

例えば、html/cssページなどの固定UIコンテンツを提供する「zimbra, zimbraAdmin」というウェブアプリケーションをウェブクライアントサーバーで実行し、すべてのSOAPリクエストを処理する「service」というウェブアプリケーションをメールサーバーで実行します。この2つのサーバーはスプリットモードで動いています。

ウェブアプリケーションサーバースプリット機能には以下のメリットがあります。

  • ウェブクライアントとメールサーバーを分割することでカスタマイズのプロセスが簡単になり、メールサーバーを再起動せずに新しくカスタマイズしたUIや更新したUIを提供できるようになります。つまり、ダウンタイムが発生しません。

  • ZimbraウェブクライアントやZimbra管理コンソールをカスタマイズする場合、メールサーバーを停止させずに、ウェブクライアントサーバーをオフラインにしてカスタマイズやメンテナンスを行なうことができます。

  • ウェブクライアントは、メールボックスのアカウントとは全く関係がありません。つまり、どのウェブクライアントサーバーでも、アカウントのリクエストを処理できます。

ウェブアプリケーションサーバースプリットのインストールと設定方法

ウェブアプリケーションサーバースプリットのインストールと設定方法に関しては Zimbra Collaboration Multi-Server Installation Guide を参照してください。

メールボックスのサーバーをバックアップする

Zimbra Collaborationには、Zimbra Collaborationサーバーごとに設定可能なバックアップマネージャーがあり、バックアップと復元の両機能を実施できます。バックアッププロセスの実行のためにZimbra Collaborationサーバーを停止する必要はありません。バックアップマネージャーを使用してシングルユーザーのメールボックスを復元できます。1ユーザーのメールボックスが破損した時に、システム全体を復元する必要はありません。完全バックアップと増分バックアップは /opt/zimbra/backup に保存されます。詳細は バックアップと復元を参照してください。

Zimbraの各メールバックスサーバーは、最後の増分バックアップ以降にメッセージストアサーバーで処理された、現在のトランザクションとアーカイブのトランザクションの入ったRedoログを生成します。サーバー復元時、バックアップファイルを完全に復元し終わったら、アーカイブのRedoログと使用中の現在のRedoログに保存されているRedoログをすべてリプレイし、システムが落ちた地点まで戻します。

メールボックスのサーバーログ

Zimbra Collaboration のシステム環境は、1つまたは複数のメールボックスサーバーとサードパーティ製のコンポーネントで構成されています。いずれのコンポーネントからもログデータが出力される可能性はあります。ローカルのログは /opt/zimbra/log に保存されます。

Zimbra Collaborationログメッセージを選択すると、SNMPトラップが生成されます。SNMP監視ソフトウェアを用いれば、これをキャプチャできます。詳細については ZCS サーバーの監視を参照してください。

システムログ、Redoログ、バックアップしたセッションを別々のディスクに保存することにより、ディスク破損時における復旧不可能なデータロスのリスクを最小限に留めるようにしてください。

IMAP

Zimbra Collaboration はデフォルトでインストールされる内部の IMAP サーバが含まれており、zimbra-mailboxd のプロセスの一部となっております。(Zimbra Mailbox Server)

一般的な IMAP 設定オプション

以下のグローバルとサーバ側の設定では IMAP サービスの管理やチューニングが可能となっております。

  • zimbraImapServerEnabled. TRUE に設定した場合、内部の IMAP サーバが有効化されます。FALSE に設定した場合、内部の IMAP サーバが無効化されます。デフォルトの設定は TRUE です。

  • zimbraImapSSLServerEnabled. TRUE に設定した場合、内部の IMAP SSL サーバが有効化されます。FALSE に設定した場合、内部の IMAP SSL サーバが無効化されます。デフォルトの設定は TRUE です。

  • zimbraImapBindAddress (サーバ側での設定のみ). 内部の IMAP サーバプロセスがリッスンするインターフェースのアドレスを指定します。値が空の場合、すべてのインターフェースへバインドします。

  • zimbraImapBindPort. 内部の IMAP サーバプロセスがリッスンするポート番号を指定します。デフォルトの値は 7143 です。

  • zimbraImapSSLBindAddress (サーバ側での設定のみ). 内部の IMAP SSL サーバプロセスがリッスンするインターフェースのアドレスを指定します。値が空の場合、すべてのインターフェースへバインドします。

  • zimbraImapSSLBindPort. 内部の IMAP SSL サーバプロセスがリッスンするポート番号を指定します。デフォルトの値は 7993 です。

  • zimbraImapNumThreads. IMAP ハンドラのスレッドプールに使用可能なスレッド数を指定します。デフォルトでは Zimbra Collaboration が IMAP NIO を使用しておりますので、各 IMAP ハンドラスレッドが複数のコネクションを処理できます。デフォルト値の 200 では最大 10,000 アクティブ IMAP クライアントを同時に処理できます。

  • zimbraImapCleartextLoginEnabled. 非 SSL/TLS コネクションで cleartext のログインを許可するかどうかを指定します。デフォルトの設定は FALSE です。

  • zimbraImapProxyBindPort. IMAP プロキシサーバがリッスンするポート番号を指定します。デフォルト設定は 143 です。詳細については Zimbra Proxy Components をご参照ください。

  • zimbraImapSSLProxyBindPort. IMAP SSL プロキシサーバがリッスンするポート番号を指定します。デフォルト設定は 993 です。詳細については Zimbra Proxy Components をご参照ください。

  • zimbraImapMaxRequestSize. 実際のデータを除いた IMAP リクエストの最大サイズをバイト数で指定します。注意: この設定は IMAP LOGIN リクエストには適用されません。IMAP LOGIN のリクエストは IMAP プロキシ (Zimbra Proxy Components) で処理しており、最大 256 文字に制限しております。

  • zimbraImapInactiveSessionCacheMaxDiskSize. 削除する非アクティブの IMAP キャッシュの最大ディスクサイズをバイト数で指定します。デフォルトの設定は 10GB です。Ehcache の内部仕様により、実際に使用するディスクサイズが上限を大きく超えてしまいますので、この上限は完全な上限ではありません。

  • zimbraImapInactiveSessionEhcacheSize. 削除する非アクティブの IMAP キャッシュの最大ヒープサイズをバイト数で指定します。デフォルトの設定は 1MB です。Ehcache の内部仕様により、実際に使用するディスクサイズが上限を大きく超えてしまいますので、この上限は完全な上限ではありません。

  • zimbraImapActiveSessionEhcacheMaxDiskSize. アクティブな IMAP キャッシュに使用できる最大ディスクサイズをバイト数で指定します。デフォルトの設定は 100GB です。Ehcache の内部仕様により、実際に使用するディスクサイズが上限を大きく超えてしまいますので、この上限は完全な上限ではありません。

Zimbra LDAP サービス

LDAPディレクトリサービスは、Zimbraサービスの利用が許されているユーザー情報およびデバイスが集積したレポジトリを提供します。Zimbra LDAPデータに使用される集積レポジトリには、OpenLDAPのディレクトリサーバーを使用しています。

Zimbra Collaboration はMicrosoft Active Directoryサーバーとの統合もサポートしています。特殊なディレクトリを実装する場合の詳細は、サポートまで連絡してください。

LDAPサーバーは、ZCS のインストール時にインストールされます。個々のサーバーが、処理パラメーターを特定する属性の入ったLDAPエントリを保持しています。また、各属性が特定されていないサーバーには、グローバル設定オブジェクトによりデフォルトが設定されます。

LDAP属性のサブセットはZimbraの管理コンソールやzmprovのコマンドラインで設定可能です。

LDAPのトラフィックの流れ

LDAPディレクトリのトラフィック図は、Zimbra LDAPのディレクトリサーバーと他のZimbra Collaborationサーバー間のネットワークトラフィックを示しています。 ZimbraのMTAとZimbra Collaborationのメールボックスサーバーは、ディレクトリサーバーにあるLDAPデータベースに対して読み込みと書き込みを行います。

Zimbraのクライアントは、LDAPへ接続するZimbraサーバー経由で接続します。

LDAP Traffic Flow

LDAP のディレクトリ階層

LDAPのディレクトリ階層はツリー状で、メールブランチと設定ブランチの2種類に分かれています。メールブランチはドメインで構成されています。ドメインに属するエントリ、例えばアカウント、グループ、エイリアスなどは、ディレクトリ内ではドメインDN配下に登録されます。設定ブランチにはドメインの一部ではない管理システムエントリが含まれています。設定ブランチのエントリには、システム管理のアカウント、グローバル設定、グローバル権限、COS、サーバー、MIMEタイプ、Zimletなどがあります。

Zimbra LDAP階層図です。各エントリ(オブジェクト)タイプには特定の関連オブジェクトクラスがあります。

LDAP Directory Hierarchy

LDAPディレクトリのエントリは、属性の集合でできており、グローバルで一意の名前(dn)を持っています。エントリに使用する属性は、そのエントリに関わるオブジェクトクラスによって決まります。オブジェクトクラス属性の値によって、そのエントリが従うべきスキーマルールが決まります。

エントリの種類を決めるオブジェクトクラスを構造のオブジェクトクラスと言い、変更ができません。それ以外のオブジェクトクラスを予備のオブジェクトクラスと言い、エントリの追加や削除が可能です。

LDAPで使用する予備のオブジェクトクラスは、既存のオブジェクトクラスを組み合わせることができます。例えば、 構造のオブジェクトクラス inetOrgPerson と予備のオブジェクトクラス zimbraAccount を持つエントリは、アカウントになります。 構造のオブジェクトクラス zimbraServer を持つエントリは、Zimbraシステム内の1つまたは複数のZimbraパッケージがインストールされているサーバーになります。

Zimbra Collaboration LDAPのスキーマ

各LDAP実装の中心には、スキーマを使用して構成したデータベースがあります。

ZimbraのLDAPスキーマは、OpenLDAPソフトウェアに含まれている一般的なスキーマを継承しています。既存のディレクトリ環境と共存するように設計されています。

Zimbra Collaboration 専用に作成した属性とオブジェクトクラスはすべて “zimbra”で始まります。例えばオブジェクトクラス zimbraAccount や 属性 zimbraAttachmentsBlocked などです。
OpenLDAP実装には、以下のスキーマファイルが含まれています。

  • core.schema

  • cosine.schema

  • inetorgperson.schema

  • zimbra.schema

  • amavisd.schema

  • dyngroup.schema

  • nis.schema

Zimbraのスキーマを変更することはできません。

Zimbra Collaboration のオブジェクト

オブジェクト 詳細 オブジェクトのクラス

アカウント

Zimbraのメールボックスサーバーにある、ログイン可能なアカウントのことです。アカウントエントリはユーザーアカウントもしくは管理者アカウントです。オブジェクトクラス名は zimbraAccount です。このオブジェクトクラスは zimbraMailRecipient のオブジェクトクラスを継承します。 全てのアカウントには次のプロパティがあります。
 - user@example.domain形式の名前
 - 変更されず、再利用されない一意のID
 - 属性
属性にはユーザーが(プリファレンスから)変更できるものと管理者のみ変更できるものがあります。 すべてのユーザーアカウントはドメインに紐づくため、アカウントの作成以前にドメインを作成する必要があります。

zimbraAccount

提供サービス (COS)

アカウントが持つデフォルト属性。使用できる機能、使用できない機能が定義されています。COSにより、機能やデフォルトのプリファレンス設定、メールボックス割り当て容量、メッセージの保持期限、パスワード制限、添付ファイルブロック設定、新規アカウントの作成用のサーバープールを制御します。

zimbraCOS

ドメイン

example.comexample.org のような、電子メールを使用可能にさせるドメインのことです。ドメインに属するユーザーへメッセージが配信されるよりも前に、ドメインが存在している必要があります。

zimbraDomain

配布リスト

メーリングリストとも言います。リストのアドレスへ1通、メールを送信すると、リストのメンバー全員へメッセージが届きます。

zimbraDistributionList

ダイナミックグループ

配布リストと類似しています。差異は、ダイナミックグループのメンバーはLDAP検索によって動的に計算されるという点です。LDAP検索フィルターはダイナミックグループエントリの属性内に定義されています。

配布リストもダイナミックグループもどちらも、委任された管理者のフレームワーク内で、被譲与者またはターゲットとして使用することができます。

zimbraGroup

サーバー

Zimbraシステム内の1つまたは複数のZimbraパッケージがインストールされているサーバーのことです。属性は、サーバーの設定情報で、サーバーで実行中のサービスを示したりします。

zimbraServer

グローバル設定

サーバーやドメインというオブジェクト用のデフォルト値を指定します。他のオブジェクト用の属性が設定されていない場合、その属性の値はグローバル設定から継承されます。グローバル設定値は必要なものなので、Zimbraコアパッケージの一環として、インストール中に設定されます。これがシステムのデフォルト設定の値になります。

zimbraGlobalConfig

エイリアス

アカウント、配布リスト、またはダイナミックグループのエイリアスのことです。 zimbraAliasTarget 属性はこのエイリアスエントリのターゲットエントリを指します。

zimbraAlias

Zimlet

Zimbra内にインストール・設定されているZimletを定義します。

zimbraZimletEntry

カレンダーのリソース

会議で指定することのできる機器や会議室のようなカレンダーリソースを定義します。カレンダーリソースとは、 zimbraCalendarResource オブジェクトクラスにさらに追加の属性を持つアカウントです。

zimbraCalendarResource

Identity

ユーザーのペルソナのことです。ペルソナには、ユーザーの識別情報、例えば、表示名、送信メールに使用する署名エントリのリンクが入っています。ユーザーは複数のペルソナを作成できます。IdentityエントリはDITにあるユーザーのLDAPエントリの直下に作成されます。

zimbraIdentity

データソース

ユーザーの外部メールソースを指します。データソースの例としては、POP3やIMAPがあります。データソースにはPOP3/IMAPのサーバー名、ポート、ユーザーの外部メールアカウントのパスワードが保存してあります。データソースには、表示名や外部アカウントの代わりに送信されるアウトバウンドメールに使用する署名へのリンクなどを含むペルソナ情報も格納されます。データソースのエントリはDIT内のユーザーのLDAPエントリの下に作成されます。

zimbraDataSource

署名

ユーザーの署名を指します。ユーザーは複数の署名を作成することができます。署名のエントリはDIT内のユーザーのLDAPエントリの下に作成されます。

zimbraSignature

アカウントの認証について

内外のLDAPおよび外部Active Directoryが、サポート対象の認証のメカニズムです。認証方式はドメインごとに設定します。 zimbraAuthMech 属性が設定されていない場合、デフォルトでは内部認証を使用します。

内部認証方式はOpenLDAPサーバーで動いているZimbraスキーマを使用します。

zimbraAuthFallbackToLocal 属性を有効にしていると、外部認証が失敗した場合にローカル認証へフォールバックできます。デフォルトはFALSEです。

内部認証のメカニズム

内部認証方式はOpenLDAPサーバーで動いているZimbraスキーマを使用します。OpenLDAPに格納されているアカウントの場合、ユーザーパスワードのsalted-SHA1 (SSHA)ダイジェストが属性 userPassword に格納されます。ログイン時に入力したパスワードはSSHAダイジェストに演算された後、格納されている値と比較されます。

外部LDAPと外部Active Directoryの認証メカニズム

メール環境が、Zimbra以外のLDAPサーバーやMicrosoft Active Directoryを認証用に使用していて、Zimbra LDAPサーバーをZimbra Collaboration 関連のトランザクション用に使用している場合は、外部LDAPと外部Active Directoryの認証を利用することができます。ただし、OpenLDAPと外部LDAPサーバーの両方にユーザーが存在していなければなりません。

外部認証方法では、入力されたユーザー名とパスワードを使用して、指定のLDAP認証サーバーへのバインドを試行します。バインドが成功した場合は、接続は終了し、パスワードが認証されたことになります。

属性 zimbraAuthLdapURLzimbraAuthLdapBindDn が外部認証には必要です。

  • zimbraAuthLdapURL 属性の ldap://ldapserver:port/ は、外部ディレクトリサーバのIPアドレスまたはホスト名と、portでポート番号を表します。ポート番号の代わりに正式なホスト名を使用することもできます。

    ldap://server1:3268
    ldap://exch1.acme.com

    SSL接続の場合、 ldap: の代わりに ldaps: を使用します。サーバーが使用するSSL証明書は信頼済みの証明書として設定する必要があります。

  • 属性 zimbraAuthLdapBindDn には外部ディレクトリサーバーへバインドする際に使用するDNを指定します。

    認証のプロセスの始まりでは、ユーザー名は user@example.com の形式です。

    外部ディレクトリ内では、ユーザー名を有効なLDAPバインド DN (Distinguished Name:識別名)へ変換する必要がある場合があります。Active Directoryの場合、バインドの DN は別のドメインの可能性もあります。

カスタム認証

所有しているユーザーデータベースに外部認証を統合させるカスタム認証を実装できます。認証リクエストがくると、Zimbraはドメインに指定された認証メカニズムをチェックします。この認証メカニズムがカスタムに設定されている場合、Zimbraは登録されているカスタム認証ハンドラを実行して、そのユーザーを認証します。

カスタム認証のセットアップには、ドメインをカスタム認証に設定し、カスタム認証ハンドラを登録してください。

ドメインをカスタム認証に設定

ドメインをカスタム認証にするには、ドメインの属性 zimbraAuthMech に custom:{登録したカスタム認証ハンドラ名} を設定します。

下の例では、sampleの名の下に、カスタム認証が登録されています。

Example 1. ドメインをカスタム認証に設定する
zmprov modifydomain {domain|id} zimbraAuthMech custom:sample
カスタム認証ハンドラを登録する

カスタム認証ハンドラを登録するには下記を実行し、

ZimbraCustomAuth.register( handlerName, handler )

拡張のinitメソッドに追加します。

  • クラス: com.zimbra.cs.account.ldap.ZimbraCustomAuth

  • メソッド: public synchronized static void register (String handlerName, ZimbraCustomAuth handler)

    属性の説明:

    • handlerName の名の下に、このカスタム認証ハンドラがZimbraの認証インフラへ登録されます。この名前はドメインのzimbraAuthMech属性にも設定します。

    • handler というオブジェクト上で、認証方法は、このカスタム認証ハンドラの場合に実行されます。オブジェクトは ZimbraCustomAuth (またはサブクラス)のインスタンスである必要があります。

Example 2. カスタム認証ハンドラを登録する
public class SampleExtensionCustomAuth implements ZimbraExtension {

  public void init() throws ServiceException {
  /*
   * Zimbra の認証インフラへ登録。
   * custom:sample はドメインの属性zimbraAuthMech に設定してください。
   *    */
   ZimbraCustomAuth.register("sample", new SampleCustomAuth());
  }
...
}
カスタムの認証方法について

認証リクエストがくると、指定されたドメインがカスタム認証に設定されている場合、認証用フレームワークは ZimbraCustomAuth.register() のhandlerパラメーターとして渡されたインスタンス ZimbraCustomAuth 上で認証方法を実行します。

認証すべき最初のもの(プリンシパル)用のアカウントオブジェクトとユーザーが入力したクリアテキストのパスワードは ZimbraCustomAuth.authenticate() へ渡されます。

アカウントのオブジェクトからすべてのアカウント属性を取得できます。

Kerberos5 の認証方法

Kerberos5 の認証メカニズムでは、外部のKerberosサーバーに対して、ユーザー認証します。

  1. kerberos5 を、このドメインの属性 zimbraAuthMech として設定します。

  2. Kerberosデータベース内でこのドメインのユーザーが作成されている Kerberos5 Realm を、このドメインの属性 zimbraAuthKerberos5Realm として設定します。 ユーザーがパスワードを使用してログインしたときに、そのドメインの属性 zimbraAuthMechkerberos5 に設定されていたら、サーバーは {メールアドレスのローカル部分}@{zimbraAuthKerberos5Realmの値} でKerberos5プリンシパルを構成させたものをkerberos5サーバーへの認証に使います。

個人のアカウント向けにKerberos5を指定するには、アカウントの zimbraForeignPrincipalkerberos5:{kerberos5-principal} として設定します。
例: kerberos5:user1@MYREALM.COM.

グローバルアドレスリスト(GAL)について

グローバルアドレスリスト(GAL)はユーザーの社内ディレクトリで、通常、組織内で有効で、メールシステム内の全ユーザーが利用することができます。Zimbra Collaborationでは社内のユーザーアドレスを検索する際に、この社内ディレクトリを使用します。

Zimbra Collaborationのドメインごとに、GALを下記の利用に設定できます。

  • 外部のLDAPサーバー

  • Zimbra Collaborationの内部LDAPサーバー

  • GAL検索の外部LDAPサーバーおよびZimbra Collaboration LDAP

Zimbra CollaborationのウェブクライアントはGALを検索できます。ユーザーが名前を検索すると、名前がLDAPの検索フィルターへと変換されます。下記例の %s はユーザーが検索中の名前です。

Example 3. GALを検索する
(|(cn = %s*)(sn=%s*)(gn=%s*)(mail=%s*))
  (zimbraMailDeliveryAddress = %s*)
  (zimbraMailAlias=%s*)
  (zimbraMailAddress = %s*)

Zimbra Collaboration上でのGAL 属性

以下の ZCSの連絡先属性へマップされたLDAP属性 の表は、一般的なGALの検索属性とZimbra Collaborationの連絡先情報をマッピングしています。

LDAP属性はGALエントリ項目にマッピングされます。例えば、LDAP属性 displayNamecn は、GALのエントリ項目 fullName へマップできます。このマッピングは zimbraGaILdapAttrMap 属性に設定されています。

Table 8. ZCSの連絡先属性へマップされた属性
デフォルトのLDAP属性 Zimbra Collaboration の連絡先属性 説明

co

workCountry

会社の国

company

Company

会社名

givenName/gn

firstName

sn

lastName

cn

fullName

フルネーム

initials

initials

名前のイニシャル

l

workCity

会社の市

street, streetaddress

workStreet

会社の住所

postalCode

workPostalCode

会社の郵便番号

telephoneNumber

workPhone

会社の電話番号

mobile

mobile

携帯番号

pager

pager

ポケベルの番号

facisimileTelephoneNumber

faxNumber

ファックスの番号

st

workState

会社の州

title

jobTitle

職種

mail

email

メールアドレス

thumbnailPhoto

サムネイルの画像

objectClass

Zimbra Collaboration GAL の検索条件

GALは各ドメイン単位で設定します。属性を設定する場合、管理コンソールのGAL設定ウィザードを使用できます。

属性を変更する方法

GAL属性への追加、変更、削除はZimbraの管理コンソールから、または zmprov コマンドで実施します。

ユーザーがZimbraのウェブクライアントのオプションやプリフレンスを変更すると、アカウント関連属性も変更されます。

LDAPのキャッシュをフラッシュする

ZimbraLDAPサーバーで以下のタイプのエンティティを変更した場合、変更の反映にLDAPキャッシュのフラッシュが必要となる場合があります。

  • テーマ

  • 地域

  • アカウント

  • グループ

  • COS

  • ドメイン

  • グローバル設定

  • サーバー

  • Zimletの設定

テーマや地域のキャッシュをフラッシュする

ZCS のテーマ(スキン)のプロパティファイルや地域のリソースファイルを追加したり変更したりする場合、新しい内容の反映のために、キャッシュをフラッシュする必要があります。

スキンをフラッシュ
zmprov flushCache skin
地域をフラッシュ
zmprov flushCache locale

アカウント、グループ、COS、ドメインおよびサーバーをフラッシュする

アカウントやCOS、グループ、ドメイン、サーバーの属性を変更した場合、変更を行ったサーバーには直ちに変更が反映されます。他のサーバーの場合、属性がキャッシュされていると、一定期間経過した後に自動でLDAP情報が更新されます。

ZCS でのデフォルト設定ではサーバーの定期アップデートは15分ごとです。キャッシュする期間はローカル設定キーで設定します。

アップデート時間の設定変更
zmlocalconfig ldap_cache_<object>_maxage
即座に変更を反映
zmprov flushCache {account|cos|domain|group|server|...} [name|id]...

タイプに沿ったIDや名称を指定しない場合、キャッシュにある、そのタイプの全エントリがフラッシュされ、キャッシュは更新されます。

サーバー属性によっては、キャッシュをフラッシュしたあとでも、再起動が必要なものもあります。例えば、バインドポートやプロセススレッド数などです。

グローバル設定をフラッシュする

グローバル設定属性を変更した場合、変更を行ったサーバーには直ちに変更が反映されます。他のメールボックスサーバーの場合、キャッシュをフラッシュするかサーバーを再起動しなければ変更は反映されません。グローバル設定属性のLDAPエントリに有効期間はありません。

グローバル設定属性のなかには、サーバーが再起動したときにだけ読み込まれるものもあります。こうした属性への変更は、キャッシュをフラッシュしたとしてもサーバーが再起動されるまでは有効になりません。グローバル設定や、グローバル設定を継承したサーバー設定のなかにも、サーバー起動時のみに読み込まれるものがあります。例えば、ポートやプロセススレッド数です。こうした属性の変更により、サーバー再起動が必要となります。

全てのサーバーにおいて、グローバル設定の変更をフラッシュする場合

  1. ローカルサーバーの設定を変更します。

    zmprov mcf zimbraImapClearTextLoginEnabled TRUE

    ローカル設定キーである zimbra_zmprov_default_soap_serverzimbra_admin_service_port により判別されるサーバー経由でこの変更を実行します。

  2. その他全サーバーのグローバル設定のキャッシュをフラッシュするには、各サーバーで zmprov flushCache を実行する必要があります(または zmprov flushCache -a を使用します)。

    例:

    zmprov -s server2 flushCache config
    zmprov -s server3 flushCache config
  3. サーバー再起動が必要かどうかを確認します。

    zmprov desc -a <attributename>

    再起動が必要な場合、requiresRestart が返されます。

Zimbraのメール送信エージェント

ZimbraのMTA (Mail Transfer Agent: メール送信エージェント) は、SMTP経由でメールを受信し、ローカルメールの配信プロトコル (LMTP) を利用して、各メッセージを適当なZimbraメールボックスにルートします。

MTAパラメーターの設定は、管理コンソールとCLIの両方で実施可能ですが、CLIのほうが確実な結果を得られます。

Zimbra MTAサーバーには、以下のプログラムが備わっています。

MTA サーバプログラム 目的/説明

Postfix MTA

メールのルートとリレー、添付ファイルのブロック。

Clam Anti-Virus

メールのメッセージ本文や添付ファイルのウイルススキャン。

Spam Assassin

迷惑メール (スパム) メッセージを判別。

Amavisd-New

PostfixとClamAV/SpamAssassin間のインターフェース。

Zimbra Milter Server

配布リストへ送信可能なアドレスを制限、配布リストからの送信メッセージに Reply-toX-Zimbra-DL のヘッダーを追加。

Zimbra policy server

バックスキャター迷惑メールからのエイリアスドメインの保護を支援。

Cluebringer

レート制限のようなアクションの強制実行に使用するポリシーdaemon/cbpolicyd。詳細は次を参照してください。 https://wiki.zimbra.com/wiki/Postfix_Policyd

Opendkim

送信メールへ署名するように設定されている場合に署名。詳細は次を参照してください。 https://wiki.zimbra.com/wiki/Configuring_for_DKIM_Signing

Zimbra Collaborationの設定では、メールの転送と配信は別物です。PostfixはMTA (転送の役割) として、Zimbraのメールサーバーはメール配信エージェント (MDA:配信の役割) として機能します。

MTAの設定はLDAPに格納されます。zmconfigd処理がLDAPのディレクトリを2分ごとにポーリングし、変更点をPostfixの設定ファイルに反映します。

メール受信のルートの概要

Zimbraメールボックスサーバーは、Zimbra MTAサーバーからメッセージを受け取り、事前に作成されている全フィルターに、そのメッセージを通します。

MTAサーバーはSMTPからメールを受け取ると、LMTPを使用して各メッセージを適当なメールボックスサーバーにルートします。メッセージが届くと、全ての要素を検索できるように、その内容をインデックスします。

Zimbra のMTA 配置

メールのルートやリレー、添付ファイルの管理のため、ZCSにはプリコンパイルしたPostfixが備わっています。PostfixはSMTP経由でインバウンドのメッセージを受け取ると、ウイルス対策と迷惑メール対策のフィルターリングを行い、LMTP経由でメッセージをZCSサーバーに渡します。

Postfixには、アウトバウンドメッセージを転送する役割もあります。Zimbraは、Zimbraウェブクライアントで作成したメッセージをPostfix経由で送信します。同一サーバーにいる他のユーザーへ送信するメッセージも同様です。

Zimbra MTA Deployment
Edge MTAは、メールのあらゆるEdgeセキュリティソリューションになり得ます。既に、 機能ソリューション、例えばフィルターリングなどは、配置済みかもしれません。フィルターリングの中にはEdge MTAとZimbra MTA間で重複するものもあります。

Postfix の設定ファイル

ZimbraのPostfixファイル — main.cf と master.cf — はZCS で使用できるように修正してあります。

  • main.cf — LDAPテーブルを追加しています。Zimbra MTAの zmconfigd がZimbra LDAPからデータを取得し、Postfixの設定ファイルを変更します。

  • master.cf — Amavisd-Newを使えるように変更しています。

Postfix設定ファイルを編集してもアップグレード時に自動で上書きされてしまうため、正確に文書化しておく必要があります。可能であれば、Zimbraの定義済みパラメーターを使用して、必要となる設定内容の変更を実装してみてください。

SMTP 認証について

SMTP認証では、許可されたメール送信元だけが外部ネットワークからZimbra MTAへメッセージ送信することができます。SMTPクライアントのメッセージ送信時はユーザーIDとパスワードがMTAへ送信されます。

MTAは、そのLDAPアカウントに関する認証情報をチェックして、そのユーザーがメール配信を許可されているかどうかを確認できます。

ユーザー認証はZimbra LDAPのディレクトリサーバーから、あるいは実装されている場合はMicrosoft Active Directoryのサーバーから、実行されます。

SMTPの制限

外部のSMTPクライアントが標準ではないアクションや許可されていない行動をした場合にPostfixがそのメッセージを受け付けないように設定することができます。制限を設けることで、迷惑メール送信者に対処します。デフォルトでは完全修飾ドメイン名で接続しないクライアントが制限されます。DNSベースの制限も可能です。

制限の影響を理解してから設定するようにしてください。精度なメールシステムを使用していない人からのメッセージを受け入れるために、チェック機能を妥協しなければならない状況もあります。

外部サーバー宛のメッセージを別サーバーへ送信する

外部サーバー宛のメッセージを別のSMTPサーバーへ送信するようにPostfixを設定できます。通常、リレーやスマートホストなどと言われます。

よくあるリレーホストのユースケースは、全メールを特定のホストからリレーさせる必要のあるISPの場合や、フィルターリング用SMTPプロキシサーバーがある場合です。

リレーホストの設定を、ウェブメールのMTA設定と混合させないでください。リレーホストとは、Postfixが外部サーバー宛のメールをリレーするためのMTAです。ウェブメールのMTAは、作成したメッセージのためにZimbraサーバーが使用するものであり、 MTAパッケージのPostfixサーバー用ロケーションにあります。

管理コンソールにて、外部配信のためのリレーMTAを設定できます。

管理コンソール:

ホーム > 設定 > グローバル設定 > MTA → ネットワーク

リレーホストを設定する際、メールの送信ループが発生しないように注意してください。
MTA Settings

ウイルス対策と迷惑メール対策の保護

Amavisd-Newのユーティリティは、Zimbra MTA とClam Anti-Virus (ClamAV)やSpamAssassinスキャナー間のインタフェースです。

ウイルス対策の保護

Clam AntiVirusは、ZCSサーバーごとに使用可能なウイルス対策ソフトです。

このソフトは、ウイルスが含まれていると判別されたメッセージを検疫用メールボックスへ移動するように設定されています。デフォルトでは、Zimbra MTAはClamAVのウイルス対策の更新を2時間ごとにチェックします。

管理コンソールからウイルス対策の設定を変更できます。

管理コンソール:

Home > 設定 > グローバル設定 > AS/AV → ウィルス対策設定

Anti-Virus Protection
ClamAVのウェブサイトからHTTP経由で更新を取得します。
送信するメールの添付ファイルをスキャンする

Zimbraウェブクライアントを使用して送信されるメッセージの添付ファイルに対し、リアルタイムスキャンを実施できます。スキャンが有効な場合、ファイルがメールに添付されると、メッセージの送信前にClamAVによってスキャンされます。ClamAVがウイルスを検出すると、メッセージへのファイル添付がブロックされます。デフォルトでは、シングルノード環境の場合にスキャンが有効化されています。

シングルノード環境でスキャンを有効化するには、以下を実行します。

zmprov mcf zimbraAttachmentsScanURL clam://localhost:3310/
zmprov mcf zimbraAttachmentsScanEnabled TRUE

マルチノード環境でスキャンを有効化する場合

  1. ClamAVスキャンを処理するMTAノードを指定してください。

  2. 以下を実行し、有効化してください。

    zmprov ms <mta_server> zimbraClamAVBindAddress <mta_server>
    zmprov mcf zimbraAttachmentsScanURL clam://<mta_server>:3310/
    zmprov mcf zimbraAttachmentsScanEnabled TRUE

迷惑メール対策の保護

Zimbraは迷惑メールの判別に、Berkeley DBのデータベースまたはMariaDBのデータベースに保存している学習データを使ってSpamAssassinを利用します。更に、メールサーバーのオーバーロードを防止するPostscreen機能の利用も可能です。これらについては以下のトピックスに記載しています。

SpamAssassinを利用した迷惑メール対策

以下のトピックスにガイドラインが記載されています。

SpamAssassinのカスタマイズ方法についての詳細は https://wiki.zimbra.com/wiki/Anti-spam_strategies を参照してください。

SpamAssassinのスコアを管理する: SpamAssassinは、事前定義されているルールとBayesのデータベースを使用して、メッセージを数字でスコア付けします。Zimbraは、20を100%としたSpamAssassinのスコアをベースとしてメッセージの 迷惑度 をパーセント値で決定します。33%-75%のメッセージは迷惑メールと判断してユーザーの迷惑メールフォルダへ配信します。75%以上のメッセージは深刻な迷惑メールと判断して自動削除します。

管理コンソールから迷惑メールのしきい値と件名のプレフィックスを変更できます。

管理コンソール:

Home > 設定 > グローバル設定 > AS/AV → 迷惑メールチェック設定

Spam Assassin Settings

デフォルトでは、迷惑メールの学習にBerkeley DBのデータベースを使用しています。MariaDBのデータベースも使用可能です。

MTAサーバーにMariaDBのメソッドを使用する場合

zmlocalconfig -e antispam_mariadb_enabled=TRUE

これが有効なとき、Berkeley DBのデータベースは使用できません。

スパムフィルターに学習させる: ユーザーがインプットするスパム(迷惑)あるいはハム(迷惑ではない)の判別内容によって、迷惑メール対策フィルターの効果に違いがでます。ユーザーが迷惑メールのフォルダへメッセージを移動したり、迷惑メールのフォルダから通常のフォルダへメッセージを移動することにより、SpamAssassinフィルターは学習します。ユーザーが移動したメッセージのコピーは適宜、スパム学習用メールボックスに自動送信されます。

インストール時、スパム/ハムのクリーンアップフィルターは最初のMTAのみに設定されます。ZCSのスパム学習ツール(zmtrainsa)は自動的にメッセージを収集し、スパムフィルターに学習させます。 zmtrainsa スクリプトは、スパム学習用メールボックスを毎日空にします。

新しいZCS環境では、スパム/ハムの学習を当初インストールされているMTAに制限しています。このMTAをアンインストールまたは移動した場合、別のMTAに対してスパム/ハム学習を有効化する必要があります。この設定を行なわない場合、新しいMTAで zmtrainsa --cleanup を正常に実行することはできません。

新しいMTAサーバーにて以下のコマンドを実行し、設定します。

zmlocalconfig -e zmtrainsa_cleanup_host=TRUE

迷惑メールや迷惑ではないメールによく含まれる文字や単語、トークンを最初に迷惑メールフィルターに学習させて迅速にデータベースを構築したい場合、メッセージをmessage/rfc822添付としてマニュアル操作で迷惑メールボックスや非迷惑メールボックスに転送します。 zmtrainsa の実行で、転送されたメッセージを利用して、迷惑メールフィルターに学習させます。スコアの精度を上げるには、サンプルメッセージをたくさん登録するようにしてください。迷惑メールの判断には、最低約200通の迷惑メッセージと200通の非迷惑メッセージが必要とされています。

SpamAssassinのsa-updateツールはSpamAssassinの一部です。このツールでSA organizationのSpamAssassinルールを更新します。このツールは /opt/zimbra/common/bin にインストールされます。

迷惑メールの最終処理を設定する: 次の属性を利用しAmavisを設定することで、迷惑メールの最終処理を管理できます。

zimbraAmavisFinalSpamDestiny

この属性のデフォルトは D_DISCARD です (宛先へ配信せずに削除する処理です) 。

以下のコマンドで設定します。

zmprov mcf "zimbraAmavisFinalSpamDestiny" D_PASS
zmprov ms serverhostname.com D_PASS
Table 9. 設定可能な属性値
説明

D_PASS

宛先へ配信されます。受信者の迷惑メールフォルダに格納されることになります (ただし、迷惑メールフォルダを使用不可にしているサイトもあります) 。

D_BOUNCE

送信者へ送り返されます。この設定の場合backscatterを作成できるため("送信者" が実際にメールを送信した人物でない)、推奨しません。

D_REJECT

メールを拒否します。この設定はbackscatterの機会が縮小します。

  • 有効な送信者の場合、MTAは送信者にメール拒否について知らせます。

  • 無効な送信者の場合、関連MTAがメールを削除します (つまり、なりすましメール)。

D_DISCARD

メールは何ごともなく削除されます(配信されません)。

信頼できるネットワークを設定する: ZCSの設定では、ローカルネットワークのリレーのみ許可します。ただし、リレーメールを許された信頼できるネットワークを設定することが可能です。信頼できるMTAネットワークはグローバル設定として設定しますが、サーバー設定でも設定できます。サーバー設定はグローバル設定をオーバーライドします。

管理コンソールから信頼できるMTAネットワークをグローバル設定として設定する方法

管理コンソール:

ホーム > 設定 > グローバル設定 > MTA → ネットワーク

MTA Trusted Networks

サーバーベースで信頼できるMTAネットワークを設定する場合は、まず、グローバル設定として信頼できるMTAネットワークが設定済みであることを確認します。

管理コンソール:

ホーム > 設定 > サーバー → サーバー名 → MTA → ネットワーク

MTA Trusted Networks

複数のネットワークを記載する場合、カンマ空白 で区切ります。長い行が続く場合、下記例のように次の行を空白で開始します。

127.0.0.0/8, 168.100.189.0/24
127.0.0.0/8 168.100.189.0/24 10.0.0.0/8 [::1]/128 [fe80::%eth0]/64

Milter サーバーを有効にする: Milterサーバーを有効にして、配布リストに送信できるアドレスを制限することができます。また、Reply-ToX-Zimbra-DL を配布リストから送信するメッセージヘッダーに追加することができます。管理コンソールからグローバルまたは特定のサーバーに対して、設定することが可能です。

MTAが起動しているサーバーにのみMilterサーバーを有効化してください。

グローバルにMilterサーバーを有効にする場合、管理コンソールからMilterサーバーを有効にします。

管理コンソール:

Home > 設定 > グローバル設定 > MTA → Milter サーバー

MTA Milter Server

特定のMilterサーバーを有効にし、個々のサーバーにMilterのバインドアドレスを設定するには、管理コンソールを使用します。

管理コンソール:

Home > 設定 > サーバー → サーバー名 → MTA → Milter サーバー

MTA Milter Server
PostScreenを利用した迷惑メール対策

ZimbraのPostscreenは、サーバーのオーバーロードを防ぐためにZimbra Collaborationの迷惑メール対策の一環としてバージョン8.7より追加されています。意図的に、PostscreenをSMTPプロキシとはしていません。Postscreenの目的は、Postfix SMTPサーバー処理からスパムボットを遠ざけながら、正当なトラフィックのためにオーバーヘッドを最小化することです。シングルPostscreen処理では、複数のインバウンドSMTP接続を処理し、どのクライアントをPost-fix SMTPサーバー処理へ繋ぐかを決定します。スパムボットを追いやることで、Postscreenは正当な送信元のためにSMTPサーバー処理を開放でき、また、サーバーのオーバーロード状態が始まる兆候を遅らせることができます。

通常の配備では、PostscreenがTCPポート25でMXサービスを実施し、MUAクライアントがクライアント認証の必要なTCPポート587のサブミッションサービスからメールを送ります。他の方法として、Postscreenではない専用の “port 25” サーバーをセットアップすることも可能です。MXサービスを使わずにこの専用サーバーで送信サービスとクライアント認証を行ないます。

Postscreenは、エンドユーザークライアント(電子メールクライアント)のメールを受け取るSMTPポートで使用するべきではありません。

Zimbra Collaboration Postscreen は数々のテストを通った実績を持つ送信元暫定ホワイトリストを保有しています。送信元IPアドレスがホワイトリストに存在する場合、Postscreenは即座にその接続をPostfix SMTPサーバー処理へ渡します。こうすることで、正当なメールの場合のオーバーヘッドを最小化します。

Postscreenサービスを利用する通常のシナリオでは、ロード中のメールに、正当と思われるメールと潜在的に悪意のあるメールエンティティ(ボットやゾンビなど)が混在していることを想定するのが妥当です。この概念を次の図で表します。 望まないエンティティは赤色で、正当と思われるメールは緑色で示しています。

Postscreen

Postscreenは基本チェックを行い、明らかにボットやゾンビと分かる接続を拒否します。暫定ホワイトリストに掲載されていない接続の場合はそのメールをローカルの迷惑メール対策ソフトとウィルス対策ソフトに回して、受け入れるか拒否するかを決めさせます。悪意のない接続の場合はPostscreenセキュリティで受け入れた後にSMTPデーモンと直接会話させて、迷惑メール対策・ウィルス対策チェックによるメールスキャンを(通常どおり)行います。デフォルトでは、ボットもゾンビも全て拒否されます。

Postscreen処理のパラメーター設定にはZimbra CLI属性を使用します。ignore、enforce、dropを含む Postscreen属性 については次のガイドラインを利用してください。

  • ignore — この結果を無視します。他のテストを完了させることができます。このテストは後続のクライアント接続で繰り返されます。メールをブロックせずにテストし、統計を収集するのに有効なため、これがデフォルト設定です。

  • enforce — 他のテストを完了します。550 SMTPを返してメール配信を拒否し、hello/sender/recipient情報のログをとります。このテストは後続のクライアント接続で繰り返されます。

  • drop — 521 SMTPを返し、即座に接続が落とされます。このテストは後続のクライアント接続で繰り返されます。

Postscreen属性:

Postscreenのコマンドを使用するには zmprov mcf プロンプトへ遷移します(バージョン8.7以降)。 Postscreenの有効化 ではこうした属性の使用例を確認できます。

  • zimbraMtaPostscreenAccessList — デフォルト = permit_mynetworks

    Postconfのpostscreen_access_listというリモートSMTPクライアントIPアドレス分の恒久ホワイト/ブラックリストを設定します。リモートSMTPクライアントが接続するとすぐにPostscreen(8)はこのリストを検索します。カンマ(もしくは空白)で区切られたコマンドリスト(上位または下位のケース)またはルックアップテーブル(配列)を指定してください。この検索はコマンドが該当の送信元IPアドレスを見つけた時点で終了します。

  • zimbraMtaPostscreenBareNewlineAction — デフォルト = ignore

    リモートSMTPクライアントが “生の改行コード” 、つまり、前にCRをつけずにLFのみを送信した場合にPostscreen(8)がとるアクション。ignore、enforce、dropのいずれかになります。

  • zimbraMtaPostscreenBareNewlineEnable — デフォルト = no

    postscreen(8)サーバーでの “生の改行コード” のSMTPプロトコルテストを有効または無効にします。このテストは代償が大きいです。リモートSMTPクライアントはこのテストを通過した後、実際のPostfix SMTPサーバーと会話できるようになる前に接続を閉じる必要があるためです。

  • zimbraMtaPostscreenBareNewlineTTL — デフォルト = 30d

    “生の改行コード” のSMTPプロトコルテストの成功結果をpostscreen(8)が利用できる期間。この間、その送信元IPアドレスはこのテストの対象外となります。デフォルト設定は長くしてあります。リモートクライアントはこのテストを通過した後、実際のPostfix SMTPサーバーと会話できるようになる前に接続を閉じる必要があるためです。 0以外の時間を指定してください(整数の値+時間単位を特定する1文字)。
    時間単位:s(秒)、m(分)、h(時)、d(日)、w(週)。

  • zimbraMtaPostscreenBlacklistAction — デフォルト = ignore

    postscreen_access_list パラメーターを使用し、そのリモートSMTPが恒久ブラックリストに掲載されていると分かったときにPostscreen(8)がとるアクション。ignore、enforce、dropのいずれかになります。

  • zimbraMtaPostscreenCacheCleanupInterval — デフォルト = 12h

    postscreen(8)に許されているキャッシュクリーンアップ処理実行間隔。キャッシュクリーンアップはキャッシュデータベースに対するロードが増加するため、頻繁に実行するべきではありません。この機能を使用するには、キャッシュデータベースが delete(削除) and sequence(継続) 操作をサポートしている必要があります。キャッシュクリーンアップを無効にするには0時間を指定します。

    各キャシュクリーンアップの実行後、postscreen(8) デーモンは、保持・ドロップされたエントリ数をログに出力します。 postfixのリロード 後、あるいは postfixの停止 後、もしくは $max_idle 時間(アイドルタイム制限)内にリクエストがなかった場合に、デーモンは停止し、クリーンアップの実行は partial としてログに記録されます。
    時間単位:s(秒)、m(分)、h(時)、d(日)、w(週)。

  • zimbraMtaPostscreenCacheRetentionTime — デフォルト = 7d

    期限切れのエントリが暫定ホワイトリストから削除される前にpostscreen(8)がキャッシュできる期間。これにより、1時間前にキャッシュエントリから消えた送信元をその理由だけで NEW と記録することを防ぐことができます。また、かつて厳しいプロトコルテストを通過しながらも再訪していない送信元の情報でキャッシュがいっぱいになることを防げます。
    時間単位:s(秒)、m(分)、h(時)、d(日)、w(週)。

  • zimbraMtaPostscreenCommandCountLimit — デフォルト = 20

    postscreen(8)に搭載されているSMTPプロトコルエンジンに対し、SMTPセッションごとのコマンド総数上限を設定します。このSMTPエンジンはメール配信しようとする試みを全て一気に延期あるいは拒否するため、ジャンクコマンドとエラーコマンドに対する制限を他に設ける必要はありません。

  • zimbraMtaPostscreenDnsblAction — デフォルト = ignore

    リモートSMTPクライアントのcombined DNSBLスコアがしきい値以上の場合にPostscreen(8)がとるアクション(このスコアはパラメーター postscreen_dnsbl_sitespostscreen_dnsbl_threshold で定義されています)。ignore、enforce、dropのいずれかになります。

  • zimbraMtaPostscreenDnsblSites

    DNSのホワイト・ブラックリストのオプションリストで、要素にはドメイン、フィルター、重さがあります。リストが空でないときdnsblog(8)デーモンはリモートSMTPクライアントのIPアドレスを使用してこれらのドメインを問い合わせます。そして、postscreen(8)は各送信元のDNSBLスコアをエラー以外の応答で更新します。

    メールを拒否する場合、PostscreenはDNSBL domainnameを返します。DNSBLのドメインネームにある “パスワード” 情報を隠すには、 postscreen_dnsbl_reply_map 機能を使用してください。

    送信元のスコアが postscreen_dnsbl_threshold で特定されたしきい値以上の場合、postscreen(8)はそのリモートSMTPクライアントとの接続を切ることができます。

    カンマまたは空白で区切られた、 domain=filter*重さ のリストを指定してください。

    • =filter が指定されていない場合、postscreen(8)はエラーでないDNSBL応答を使用することになります。それ以外の場合、フィルターと一致するDNSBL応答のみ使用します。このフィルターは d.d.d.d 形式で、各dは数字もしくは [] で囲まれたパターンです。[] には “;” で仕切られた数値や、数値..数値の範囲が入っています。

    • 重さ が指定されていない場合、postscreen(8)はリモートSMTPクライアントのDNSBLスコアに1を加算します。それ以外の場合、重さは整数である必要があり、また、postscreen(8)はそのリモートSMTPクライアントのDNSBLスコアに指定された重さを加算します。ホワイトリストにしたい場合、マイナスの数値を指定してください

    • postscreen_dnsbl_sites エントリ1件についてDNSBL応答が複数あるとき、postscreen(8)が重さを適用するのは1度だけです。

    例:

    example.comを信頼度の高いブロックリストとして使用し、また、example.net とexample.orgの両方が合致する場合のみブロックする

    postscreen_dnsbl_threshold = 2
    postscreen_dnsbl_sites = example.com*2, example.net, example.org

    127.0.0.4を含むDNSBL応答だけをフィルターする

    postscreen_dnsbl_sites = example.com=127.0.0.4
  • zimbraMtaPostscreenDnsblThreshold — デフォルト = 1

    postscreen_dnsbl_sitesパラメーターで定義されたcombined DNSBLスコアに基づき、リモートSMTPクライアントのブロック下限値を全体に定義する値。

  • zimbraMtaPostscreenDnsblTTL — デフォルト = 1h

    DNSベースの評価テストを通過したことのある送信元IPアドレスの再テストが必要となるまでに、かつての成功結果をpostscreen(8)が利用できる期間。

    0以外の時間を指定してください(整数の値+時間単位を特定する1文字)。 

    時間単位:s(秒)、m(分)、h(時)、d(日)、w(週)。

  • zimbraMtaPostscreenDnsblWhitelistThreshold — デフォルト = 0

    リモートSMTPクライア ントが postscreen_dnsbl_sites パラメーターで定義されているcombined DNSBLスコアに基づいて "220 greeting" プロトコルテスト の "前後" のテストをスキップできるようにします。

    この機能を有効にするにはマイナス値を指定します。送信元が他のテストに失敗せずにpostscreen_dnsbl_whitelist_thresholdを通過すると、保留中あるいは無効のテスト全てに完了済みフラグがつけられ、postscreen_dnsbl_ttl と等しいTTLが設定されます。テストがすでに完了していて、そのTTLが postscreen_dnsbl_ttl より短ければ、その値でTTL が更新されます。

  • zimbraMtaPostscreenGreetAction — デフォルト = ignore

    postscreen_greet_wait パラメーターで指定された期間中、応答を待たずにリモートSMTPクライアントが会話を始めた場合にPostscreen(8)がとるアクション。ignore、enforce、dropのいずれかになります。

  • zimbraMtaPostscreenGreetTTL — デフォルト = 1d

    PREGREETテストの成功結果をpostscreen(8)が利用できる期間。この間、この送信元IPアドレスはテスト対象外となります。デフォルト設定は比較的短くしてあります。正当な送信元が実際のPostfix SMTPサーバーと即座に会話できるようにするためです。

    0以外の時間を指定してください(整数の値+時間単位を特定する1文字)。
    時間単位:s(秒)、m(分)、h(時)、d(日)、w(週)。

  • zimbraMtaPostscreenNonSmtpCommandAction — デフォルト = drop

    postscreen_forbidden_ commandsパラメーターで指定された期間中にリモートSMTPクライアントがSMTP以外のコマンドを送信した場合にPostscreen(8)がとるアクション。ignore、enforce、dropのいずれかになります。

  • zimbraMtaPostscreenNonSmtpCommandEnable — デフォルト = no

    postscreen(8)サーバーでの“non_smtp_command”のテストを有効または無効にします。クライアントはこのテストを通過した後、実際のPostfix SMTPサーバーと会話できるようになる前に接続を閉じる必要があるため、代償の大きいテストです。

  • zimbraMtaPostscreenNonSmtpCommandTTL — デフォルト = 30d

    “non_smtp_command” SMTPプロトコルテストの成功結果をpostscreen(8)が利用できる期間。この間、その送信元IPアドレスはこのテストの対象外となります。実際のPostfix SMTPサーバーと会話できるようになる前に接続を閉じる必要があるためデフォルト設定は長くしてあります

    0以外の時間を指定してください(整数の値+時間単位を特定する1文字)。
    時間単位:s(秒)、m(分)、h(時)、d(日)、w(週)。

  • zimbraMtaPostscreenPipeliningAction — デフォルト = enforce

    リモートSMTPクライアントがコマンドを1件送信しサーバー応答を待つ代わりに、複数のコマンドを送信してきた場合にpostscreen(8)がとるアクション。ignore、enforce、dropのいずれかになります。

  • zimbraMtaPostscreenPipeliningEnable — デフォルト = no

    postscreen(8)サーバーでの “pipelining” SMTPプロトコルテストを有効または無効にします。送信元はこのテストを通過した後、実際のPostfix SMTPサーバーと会話できるようになる前に接続を閉じる必要があるため、代償の大きいテストです。

  • zimbraMtaPostscreenPipeliningTTL — デフォルト = 30d

    “pipelining” SMTPプロトコルテストの成功結果をpostscreen(8)が利用できる期間。この間、その送信元IPアドレスはこのテストの対象外となります。送信元はこのテストを通過した後、実際のPostfix SMTPサーバーと会話できるようになる前に接続を閉じる必要があるため、デフォルト設定は長めにしてあります。

    0以外の時間を指定してください(整数の値+時間単位を特定する1文字)。
    時間単位:s(秒)、m(分)、h(時)、d(日)、w(週)。

  • zimbraMtaPostscreenWatchdogTimeout — デフォルト = 10s

    内蔵されているウォッチドッグタイマーによる停止前に、postscreen(8)処理がリモートSMTPクライアントのコマンドへの応答、あるいはキャッシュ処理の実行に許されている期間。安全のためのこのメカニズムを使用することで、Postfix内のバグあるいはシステムソフトによってpostscreen(8)が無反応となることを防止します。失敗の警告や不必要なキャッシュ破壊を避けるため、この制限時間を10秒以下に設定しないようにしてください。

    0以外の時間を指定してください(整数の値+時間単位を特定する1文字)。
    時間単位:s(秒)、m(分)、h(時)、d(日)、w(週)。

  • zimbraMtaPostscreenWhitelistInterfaces

    ローカルpostscreen(8)サーバーIPアドレスリスト。ホワイトリストに掲載されていないリモートSMTPクライアントは、ここからpostscreen(8)の暫定ホワイトリストステータスを取得できます。クライアントがPostfix SMTPサーバー処理に伝達できるようになるにはこのステータスが必要です。デフォルトでは、送信元はどのローカルpostscreen(8)サーバーIPアドレス上のpostscreen(8)ホワイトリストステータスでも取得することができます。

    postscreen(8)がプライマリMXアドレスとバックアップMXアドレスの両方に応答するような場合、クライアントがプライマリMXアドレスに接続した場合にのみ暫定ホワイトリストステータスを渡すように postscreen_whitelist_interfaces パラメーターを設定することも可能です。 クライアントがホワイトリストに掲載されると、そのクライアントはどのアドレスのPostfix STMPサーバーにも話しかけることができるようになります。このため、バックアップMXアドレスにしか接続しないクライアントが、ホワイトリストに載ることはありませんし、Postfix SMTPサーバー処理と会話できることもありません。

    ネットワークアドレスリストやネットワーク/ネットマスクパターンリストをカンマ区切りや空白区切りで指定します。ネットマスクは、ホストアドレスのネットワークパート部のビット番号を特定します。次行を空白から開始することで、長い行を継続することができます。

    /file/name あるいは type:table のパターンの特定も可能です。 /file/name というパターンを内容に替えます。 type:table のルックアップ(配列)テーブルはテーブルエントリがルックアップ文字列に一致する場合に、一致します(ルックアップ結果は無視されします)。

    このリストでは左から右にマッチング検索を行い、最初に一致したところで検索が停止します。 !のパターン を指定して、アドレスやネットワークブロックをそのリストから除外します。

    IPv6 アドレスの情報を postscreen_whitelist_interfaces 値の [] 内および /file/name にて特定したファイル内に指定する必要があります。IP version 6 アドレスには、文字 “:” が含まれているため、こうしない限り type:table のパターンと混在します。

    例:

    /etc/postfix/main.cf:
    
    # バックアップIPアドレスへホワイトリスト接続をしないでください。
    postscreen_whitelist_interfaces = !168.100.189.8, static:all
  • zimbraMtaPostscreenDnsblMinTTL — デフォルト = 60s

    DNSベースの評価テストを通過したことのある送信元IPアドレスの再テストが必要となるまでに、かつての成功結果をpostscreen(8)が利用できる期間の下限。DNSの応答が更に大きいTTL値を特定していて、その値がpostscreen_dnsbl_max_ttlの値よりも大きくない限り、使用されることになります。

    0以外の時間を指定してください(整数の値+時間単位を特定する1文字)。
    時間単位:s(秒)、m(分)、h(時)、d(日)、w(週)。

  • zimbraMtaPostscreenDnsblMaxTTL — デフォルト = postscreen dnsbl ttl

    DNSベースの評価テストを通過したことのある送信元IPアドレスの再テストが必要となるまでに、かつての成功結果をpostscreen(8)が利用できる期間の上限。DNSの応答が更に短いTTL値を特定していて、その値がpostscreen_dnsbl_min_ttlの値よりも小さくない限り、使用されることになります。

    0以外の時間を指定してください(整数の値+時間単位を特定する1文字)。
    時間単位:s(秒)、m(分)、h(時)、d(日)、w(週)。

    注意点として、このデフォルト設定は、3.1よりも前のPostscreenバージョンにも適用されます。

Postscreenの有効化:

このセクションでは、中から上レベルでPostscreen保護を行なう場合に当てはまるグローバル設定の例を記載します。

Example 4. Postscreenのグローバル設定
zmprov mcf zimbraMtaPostscreenAccessList permit_mynetworks
zmprov mcf zimbraMtaPostscreenBareNewlineAction ignore
zmprov mcf zimbraMtaPostscreenBareNewlineEnable no
zmprov mcf zimbraMtaPostscreenBareNewlineTTL 30d
zmprov mcf zimbraMtaPostscreenBlacklistAction ignore
zmprov mcf zimbraMtaPostscreenCacheCleanupInterval 12h
zmprov mcf zimbraMtaPostscreenCacheRetentionTime 7d
zmprov mcf zimbraMtaPostscreenCommandCountLimit 20
zmprov mcf zimbraMtaPostscreenDnsblAction enforce
zmprov mcf \
  zimbraMtaPostscreenDnsblSites 'b.barracudacentral.org=127.0.0.2_7' \
  zimbraMtaPostscreenDnsblSites 'dnsbl.inps.de=127.0.0.2*7' \
  zimbraMtaPostscreenDnsblSites 'zen.spamhaus.org=127.0.0.[10;11]*8' \
  zimbraMtaPostscreenDnsblSites 'zen.spamhaus.org=127.0.0.[4..7]*6' \
  zimbraMtaPostscreenDnsblSites 'zen.spamhaus.org=127.0.0.3*4' \
  zimbraMtaPostscreenDnsblSites 'zen.spamhaus.org=127.0.0.2*3' \
  zimbraMtaPostscreenDnsblSites 'list.dnswl.org=127.0.[0..255].0*-2' \
  zimbraMtaPostscreenDnsblSites 'list.dnswl.org=127.0.[0..255].1*-3' \
  zimbraMtaPostscreenDnsblSites 'list.dnswl.org=127.0.[0..255].2*-4' \
  zimbraMtaPostscreenDnsblSites 'list.dnswl.org=127.0.[0..255].3*-5' \
  zimbraMtaPostscreenDnsblSites 'bl.mailspike.net=127.0.0.2*5' \
  zimbraMtaPostscreenDnsblSites 'bl.mailspike.net=127.0.0.[10;11;12]*4' \
  zimbraMtaPostscreenDnsblSites 'wl.mailspike.net=127.0.0.[18;19;20]*-2' \
  zimbraMtaPostscreenDnsblSites 'dnsbl.sorbs.net=127.0.0.10*8' \
  zimbraMtaPostscreenDnsblSites 'dnsbl.sorbs.net=127.0.0.5*6' \
  zimbraMtaPostscreenDnsblSites 'dnsbl.sorbs.net=127.0.0.7*3' \
  zimbraMtaPostscreenDnsblSites 'dnsbl.sorbs.net=127.0.0.8*2' \
  zimbraMtaPostscreenDnsblSites 'dnsbl.sorbs.net=127.0.0.6*2' \
  zimbraMtaPostscreenDnsblSites 'dnsbl.sorbs.net=127.0.0.9*2'
zmprov mcf zimbraMtaPostscreenDnsblTTL 5m
zmprov mcf zimbraMtaPostscreenDnsblThreshold 8
zmprov mcf zimbraMtaPostscreenDnsblTimeout 10s
zmprov mcf zimbraMtaPostscreenDnsblWhitelistThreshold 0
zmprov mcf zimbraMtaPostscreenGreetAction enforce
zmprov mcf zimbraMtaPostscreenGreetTTL 1d
zmprov mcf zimbraMtaPostscreenNonSmtpCommandAction drop
zmprov mcf zimbraMtaPostscreenNonSmtpCommandEnable no
zmprov mcf zimbraMtaPostscreenNonSmtpCommandTTL 30d
zmprov mcf zimbraMtaPostscreenPipeliningAction enforce
zmprov mcf zimbraMtaPostscreenPipeliningEnable no
zmprov mcf zimbraMtaPostscreenPipeliningTTL 30d
zmprov mcf zimbraMtaPostscreenWatchdogTimeout 10s
zmprov mcf zimbraMtaPostscreenWhitelistInterfaces static:all

Postscreenのテスト:

テストでは、何のアクションもとらずに結果を表示するPostscreenを使用します。テストシナリオでは、何のアクションもとらずメール接続のログをとるようにPostscreenに指示します。結果が問題なければ、必要に応じてメールを実行またはドロップを行なうための値をPostscreenに設定します。

  1. DNSベースのブラックホールリスト(DNSBL)を設定します。

  2. PostscreenをIgnore(無視)に設定します。

テストセッション中にPostscreenから550エラーの結果が返ってきた場合の実例

Mar 1 02:03:26 edge01 postfix/postscreen[23154]: DNSBL rank 28 for [112.90.37.251]:20438

Mar 1 02:03:26 edge01 postfix/postscreen[23154]: CONNECT from [10.210.0.161]:58010 to [10.210.0.174]:25

Mar 1 02:03:26 edge01 postfix/postscreen[23154]: WHITELISTED [10.210.0.161]:58010

Mar 1 02:03:27 edge01 postfix/postscreen[23154]: NOQUEUE: reject: RCPT from [112.90.37.251]:20438: 550 5.7.1 Service unavailable; client [112.90.37.251] blocked using zen.spamhaus.org; from=<hfxdgdsggfvfg@gmail.com>, to=<support@zimbra.com>, proto=ESMTP, helo=<gmail.com>

Mar 1 02:03:27 edge01 postfix/postscreen[23154]: DISCONNECT [112.90.37.251]:20438

メールの送受信について

Zimbra MTAは受信メッセージと送信メッセージを配信します。送信メッセージの場合、Zimbra MTAが受信者のあて先を決定します。あて先がローカルサーバーの場合、Zimbraサーバーへメッセージを配信します。あて先サーバーがリモートメールサーバーの場合、Zimbra MTAは伝達方式を確立し、リモートホストへメッセージを転送します。受信するメッセージの場合、MTAはリモートのメールサーバーから接続のリクエストを許可してローカルユーザー宛てのメッセージを受け取る必要があります。

MTAのメール送受信には、AレコードとMXレコードをDNS内に設定する必要があります。メール送信するにはMTAはDNSを利用して、ホスト名やメールのルート情報を解読します。メール受信するには、メッセージを正常にメールサーバーへ転送するためにMXレコードを正しく設定しておく必要があります。

DNSを有効にしない場合は、リレーホストを設定する必要があります。

メッセージのキュー

Zimbra MTAがメール受信すると、配信管理のため、次の複数のキューにメールをルートします:受信 (incoming)、 アクティブ(active)、遅延 (deferred)、 保持(hold)、そして破損(corrupt)。

Message Queues

受信 メッセージキューには新たに受信したメッセージが入ります。メッセージごとの一意のファイル名で識別されます。アクティブメッセージキューに空き容量がある場合、メッセージはアクティブメッセージキューへ移動します。問題がない場合、メッセージはこの受信メッセージキューを即座に通過します。

アクティブ メッセージキューには送信待ちメッセージが入ります。アクティブキューに一度に入れられるメッセージ数はMTAに設定されています。このキューから別のキューへメッセージを移動する前に、ウイルス対策と迷惑メール対策のフィルターで処理します。

配信できないメッセージは 遅延 キューに置かれます。配信失敗の理由は遅延キューのファイルに記載されます。このキューはメッセージ再配信のために定期的にスキャンされます。指定されている再配信数を超えると、メッセージ送信は失敗し、送信元へバウンスされます。メッセージの配信ができなかった旨を送信元に通知するオプションもあります。

保持 メッセージキューには処理できなかったメッセージが入ります。管理者が移動させるまで、メッセージはこのキューに留まります。このキューにあるメッセージに対する定期送信は試行されません。

破損 キューには読み込み不可能な壊れたメッセージが入ります。

メールキューの配信関連の問題を管理コンソールにて監視できます。詳細については ZCSサーバーの監視 をご参照ください。

Zimbra プロキシサーバー

Zimbraプロキシは、IMAP/POP3やHTTP クライアントリクエストのバックエンドサーバーへのリバースプロキシに使用されるPOP3/IMAP/HTTP プロキシとして設定することのできる、高性能なプロキシサーバーです。

Zimbra Collaborationのインストール中にZimbraのプロキシパッケージのインストール・設定をします。このパッケージはメールボックスサーバー、MTAサーバー、または独立したサーバーにインストールできます。Zimbraプロキシのパッケージがインストールされると、プロキシ機能が有効になります。通常、特に編集は必要ありません。

Zimbraプロキシを使用する利点

以下の項目はZimbraプロキシを使用するメリットです。

  • Zimbraプロキシによるメールボックスサーバーへのアクセスの中央化

  • ロードバランス

  • セキュリティ

  • 認証

  • SSLの停止化

  • キャッシュ

  • ロギングと監視の中央化

  • URLの再発行

  • サーバー名による制御の徹底 (任意)

詳細について、Wikiページ Zimbra_Proxy_Guide を参照してください。

プロキシのコンポーネント

Zimbraプロキシの仕組みで素早く安定したスケーラブルなHTTP/POP/IMAPプロキシを提供します。Zimbraプロキシのコンポーネントは以下となります。

コンポーネント 説明

Nginx

すべてのHTTP/POP/IMAPリクエストを処理する、高パフォーマンスのHTTP/IMAP/POP3プロキシサーバーです。

Memcached

配布されるメモリオブジェクトを高パフォーマンスでキャッシュするシステムです。パフォーマンスを向上させるため、この中にルート情報をキャッシュします。

Zimbra Proxyルート検索ハンドラ

ZCS メールボックスサーバーにあるサーブレットです。ユーザーアカウントのルート情報のクエリを処理します。ルート情報には、ユーザーアカウントが入っているサーバーとポート番号があります。

プロキシ構成と運用の流れ

ここでは、Zimbraプロキシの構成とフローを説明します。

  1. エンドクライアントがHTTP/HTTPS/POP/IMAPのポートを使用してZimbraプロキシへ接続します。

  2. Zimbra Collaboration プロキシが外からの接続を受信すると、Nginxコンポーネントがルート検索ハンドラコンポーネントへHTTPリクエストを送信します。

    Proxy Architecture

  3. Zimbra Collaboration プロキシのルート検索ハンドラがアクセスされているアカウントのルート情報を確認し、Nginxへ返します。

  4. Memcachedコンポーネントは、設定された期間内にこのルート情報を保存します (デフォルトは1時間) 。Nginxは、このデフォルトの保存期間中はルート検索ハンドラへ問い合わせせずに、このルート情報を利用します。

  5. Nginxはルート情報を使用して、Zimbra Collaborationのメールボックスに接続します。

  6. Zimbra CollaborationプロキシはZimbra Collaborationメールボックスに接続してウェブ/メールのプロキシセッションを開始します。エンドクライアントはZimbra Collaborationメールボックスへ直接接続しているかのように動作します。

Zimbraプロキシ設定の変更

Zimbraプロキシが設定されていると、Zimbraプロキシの設定は必要に応じてZimbra CollaborationのLDAP設定やLocalconfigから代理のキーワードを使用します。

Zimbraプロキシの設定完了後に変更が必要となった場合、ZimbraのLDAP属性やLocalconfig属性を編集します。その後、変更を反映したZimbraのプロキシ設定を生成するためにzmconfigdを実行します。Zimbraプロキシの設定ファイルは /opt/zimbra/conf/nginx.conf にあります。このNginx.confファイルには基本設定ファイル、memcache設定ファイル、メール設定ファイル、ウェブ設定ファイルが含まれています。

Zimbraプロキシに対するよくある変更は、IMAP/POP設定の当初デフォルト設定からの変更です。

  • 当初デフォルト設定からのHTTP リバースプロキシ設定変更。

  • KerberosのGSSAPI認証。この場合、Zimbraプロキシのパスワードを含む、KerberosのKeytabファイルのありかをマニュアル操作で指定します。

Zimbra プロキシ

Zimbraのプロキシにより、エンドユーザーはMicrosoft Outlook、Mozilla Thunderbirdなどのクライアントや他のPOP/IMAPエンドクライアント製品を使用して、Zimbra Collaborationアカウントにアクセスすることができます。エンドユーザーはPOP3、IMAP、POP3S (セキュアPOP3) 、IMAPS (セキュアIMAP) を使用して接続します。

プロキシによって例えば、ユーザーはimap.example.comをユーザーのIMAPサーバーとして入力できます。imap.example.comで起動するこのプロキシがユーザーのIMAPトラフィックを分析し、ユーザーのメールボックスのあるバックエンドのメールボックスサーバーを探し当ててユーザーのIMAPクライアントからの接続を正しいメールボックスサーバーへと導きます。

POPとIMAPのZimbra プロキシポート

以下のポートはZimbraプロキシまたはZimbraメールボックス(プロキシが設定されていない場合)のいずれかで使用されています。これらのポートで起動中の他のサービスがある場合はそのサービスを停止します。

エンドクライアントはZimbraプロキシのポートを使用して、直接Zimbraプロキシに接続します。ZimbraプロキシはZimbraメールボックスのポートを使用して、Zimbraメールボックスまたはルート検索ハンドラに接続します。

Table 10. プロキシポート
Zimbraプロキシポート (ZCS外部) ポート

HTTP

80

HTTPS

443

POP3

110

POP3S (セキュアPOP3)

995

IMAP

143

IMAPS (セキュアIMAP)

993

Zimbraメールボックスポート( ZCS内部)

ポート

ルート検索ハンドラ

7072

HTTP バックエンド (プロキシが設定されている場合)

8080

HTTPSバックエンド (プロキシが設定されている場合)

8443

POP3バックエンド (プロキシが設定されている場合)

7110

POP3Sバックエンド (プロキシが設定されている場合)

7995

IMAPバックエンド (プロキシが設定されている場合)

7143

IMAPSバックエンド (プロキシが設定されている場合)

7993

サーバー名による制御の徹底

Zimbraのプロキシには、クライアントが渡す Host のヘッダーに入れられる値を厳しく制限できる機能があります。

この機能は、 新規インストール の場合には デフォルトで有効 ですが、これまでのバージョンからの アップグレード の場合はインストール中に切り替えない限り 無効 です。

zimbraReverseProxyStrictServerNameEnabled の真偽値を設定してプロキシサーバーを再起動することでも、同機能を実現することができます。

  • TRUE - サーバー名による制御は有効

  • FALSE - サーバー名による制御は無効

zmprov mcf zimbraReverseProxyStrictServerNameEnabled TRUE

サーバー名による制御機能が有効な場合、ドメインレベルで設定アイテム zimbraVirtualHostNamezimbraVirtualIPAddress を使用することで、許容されるサーバー名を追加で指定することができます。

zmprov md example.com zimbraVirtualHostName mail.example.com zimbraVirtualIPAddress 1.2.3.4
ドメインごとに必要なバーチャルIPアドレスは1つだけですが1つ以上でも問題ありません。

HTTPプロキシのインストール後にIMAPとPOPプロキシを設定する方法

IMAPプロキシはZimbra Collaborationでインストールされ、インストール中の設定メニューからセットアップされます。HTTPプロキシを設定するには、プロキシを指定したプロキシノードにインストールする必要があります。この他の設定は基本的に必要ありません。

HTTPプロキシのインストールが完了しており、メールボックスサーバーとプロキシノードをセットアップした後に、IMAP/POPプロキシをセットアップする必要がある場合。

リモートホストに対し実行するには、zmproxyconfig -r コマンドを実行します。 これにはそのサーバーがLDAPマスター内で適切に設定されている必要があります。
独立プロキシノードのIMAP/POPプロキシを設定する

独立したプロキシサーバーを使用している環境の場合、本項の記述を参照してください。

  1. プロキシを使用する各ZimbraメールボックスサーバーでIMAP/POPプロキシを有効化します。

    /opt/zimbra/libexec/zmproxyconfig -e -m -H mailbox.node.service.hostname

    これにより以下が設定されます。

    ポート属性 設定

    zimbraImapBindPort

    7143

    zimbraImapProxyBindPort

    143

    zimbraImapSSLBindPort

    7993

    zimbraImapSSLProxyBindPort

    993

    zimbraPop3BindPort

    7110

    zimbraPop3ProxyBindPort

    110

    zimbraPop3SSLBindPort

    7995

    zimbraPop3SSLProxyBindPort

    995

    zimbralmapCleartextLoginEnabled

    TRUE

    zimbraReverseProxyLookupTarget

    TRUE

    zimbraPop3CleartextLoginEnabled

    TRUE

  2. プロキシとメールボックスのサーバーでサービスを再起動します。

    zmcontrol restart

プロキシノードを設定する

プロキシサービスがインストールされている各プロキシノードで、ウェブ用にプロキシを有効化します。

/opt/zimbra/libexec/zmproxyconfig -e -m -H proxy.node.service.hostname

これにより以下が設定されます。

ポート属性 設定

zimbraImapBindPort

7143

zimbraImapProxyBindPort

143

zimbraImapSSLBindPort

7993

zimbraImapSSLProxyBindPort

993

zimbraPop3BindPort

7110

zimbraPop3ProxyBindPort

110

zimbraPop3SSLBindPort

7995

zimbraPop3SSLProxyBindPort

995

zimbraReverseProxyMailEnabled

TRUE

シングルノードを設定する

ZimbraプロキシがZimbra Collaborationと同一サーバーにインストールされている環境の場合、本項の記述を参照してください。

  1. ウェブ用にプロキシを有効化します。

    /opt/zimbra/libexec/zmproxyconfig -e -m -H mailbox.node.service.hostname

    これにより以下が設定されます。

    ポート属性 設定

    zimbraImapBindPort

    7143

    zimbraImapProxyBindPort

    143

    zimbraImapSSLBindPort

    7993

    zimbraImapSSLProxyBindPort

    993

    zimbraPop3BindPort

    7110

    zimbraPop3ProxyBindPort

    110

    zimbraPop3SSLBindPort

    7995

    zimbraPop3SSLProxyBindPort

    995

    zimbraImapCleartextLoginEnabled

    TRUE

    zimbraReverseProxyLookupTarget

    TRUE

    zimbraPop3CleartextLoginEnabled

    TRUE

    zimbraReverseProxyMailEnabled

    TRUE

  2. プロキシとメールボックスのサーバーでサービスを再起動します。

    zmcontrol restart

Zimbra HTTPプロキシを設定する

Zimbraプロキシは、HTTPリクエストのバックエンドサーバーへのリバースプロキシを行なうことが可能です。

例えば、ユーザーはウェブブラウザから https://mail.example.com のプロキシサーバーへ接続します。mbs1.example.comにメールボックスがあるユーザーからの接続は、mail.example.com上で起動しているプロキシによってmbs1.example.comに渡されます。プロキシはRESTやCalDAVのクライアント、OutlookのZimbraコネクター、およびZimbraの NG モバイル同期のデバイスをサポートしています。

HTTPリバースプロキシは下記のとおり、リクエストをルートします。

  • リクエスト中のURLからユーザー名を判別できる場合、そのリクエストは、URLから判明したユーザーのバックエンドメールボックスサーバーへルートされます。このメカニズムにより、REST、CalDAV、Zimbraモバイルシンクがサポートされています。

  • リクエストに認証トークンのCookie(ZM_AUTH_TOKEN)が含まれている場合、そのリクエストは、認証されたユーザーのバックエンドメールボックスサーバーへルートされます。

  • 上記の方法が失敗した場合、IPハッシュの方法が使用されます。これにより、リクエストを処理、あるいは必要な内部のプロキシにてリクエストを処理できるため、バックエンドメールボックスサーバー中でそのリクエストはロードバランスされます。

HTTPプロキシを設定する方法

HTTPプロキシを設定するには、Zimbraプロキシを指定したプロキシノードにインストールする必要があります。

リモートホストに対し実行するには、/opt/zimbra/libexec/zmproxyconfig -r コマンドを実行します。 ただし、これにはそのサーバーがLDAPマスター内で適切に設定されている必要があります。
HTTPプロキシを独立したプロキシノードとして設定する

独立したプロキシサーバーを使用している環境の場合、本項の記述を参照してください。

  1. プロキシを使用する各ZimbraメールボックスサーバーでIMAP/POPプロキシを有効化します。

    /opt/zimbra/libexec/zmproxyconfig -e -w -H mailbox.node.service.hostname

    これにより以下が設定されます。

    属性 設定

    zimbraMailReferMode

    reverse-proxied

    zimbraMailPort

    8080 (ポートの衝突回避のため)

    zimbraMailSSLPort

    8443 (ポートの衝突回避のため)

    zimbraReverseProxyLookupTarget

    TRUE

    zimbraMailMode

    HTTP

  2. プロキシとメールボックスのサーバーでサービスを再起動します。

    zmcontrol restart
  3. 各ドメインについて、REST URL、メール、ブリーフケースのフォルダに使用する公開サービスホスト名を設定します。

    zmprov modifyDomain <domain.com> zimbraPublicServiceHostname <hostname.domain.com>

プロキシノードを設定する

プロキシサービスがインストールされている各プロキシノードで、ウェブ用にプロキシを有効化します。

/opt/zimbra/libexec/zmproxyconfig -e -w -H proxy.node.service.hostname

これにより以下が設定されます。

属性 設定

zimbraMailReferMode

reverse-proxied プロキシサーバーのメールモードを設定する場合、コマンドに-xのオプションを追加し、次の中から希望のモードを指定します: http, https, both, redirect, mixed

zimbraMailProxyPort

80 (ポートの衝突回避のため)

zimbraMailSSLProxyPort

443 (ポートの衝突回避のため)

zimbraReverseProxyHttpEnabled

TRUE (ウェブプロキシが有効であることを示す)

zimbraReverseProxyMailMode

HTTP (デフォルト)

プロキシサーバーのメールモードを設定する場合、コマンドに -x のオプションを追加し、次の中から希望のモードを指定します: http, https, both, redirect, mixed

HTTPプロキシのシングルノードを設定する

ZimbraプロキシがZCS と同一サーバーにインストールされている環境の場合、本項の記述を参照してください。

  1. プロキシする各Zimbraメールボックスサーバーにウェブのプロキシを有効化します。

    /opt/zimbra/libexec/zmproxyconfig -e -w -H mailbox.node.service.hostname

    これにより以下が設定されます。

    属性 設定

    zimbraMailReferMode

    reverse-proxied

    zimbraMailPort

    8080 (ポートの衝突回避のため)

    zimbraMailSSLPort

    8443 (ポートの衝突回避のため)

    zimbraReverseProxyLookupTarget

    TRUE

    zimbraMailMode

    HTTP (唯一サポートされているモード)

    zimbraMailProxyPort

    80 (ポートの衝突回避のため)

    zimbraMailSSLProxyPort

    443 (ポートの衝突回避のため)

    zimbraReverseProxyHttpEnabled

    TRUE (ウェブプロキシが有効であることを示す)

    zimbraReverseProxyMailMode

    HTTP (default)

    プロキシサーバーのメールモードを設定する場合、コマンドに -x のオプションを追加し、次の中から希望のモードを指定します: http, https, both, redirect, mixed

  2. プロキシとメールボックスのサーバーでサービスを再起動します。

    zmcontrol restart

    各ドメインについて、REST URL、メール、ブリーフケースのフォルダに使用する公開サービスホスト名を設定します。

    zmprov modifyDomain <domain.com> zimbraPublicServiceHostname <hostname.domain.com>

プロキシがアップストリーム接続にクリアテキストを使用する設定

プロキシがアップストリーム接続にクリアテキストを使用するように設定する場合、 zimbraReverseProxySSLToUpstreamEnabled にFALSEを設定します。

この属性のデフォルトはTRUEです。初期インストールの状態、アップストリームのコミュニケーションはSSL配信がデフォルトです。

REST URL の生成

REST URL用に以下の属性のホスト名、サービスプロトコル、サービスポートをグローバルレベルあるいはドメインレベルで設定します。

  • zimbraPublicServiceHostname

  • zimbraPublicServiceProtocol

  • zimbraPublicServicePort

REST URLを生成する場合

  • domain.zimbraPublicServiceHostname が設定されている場合、 zimbraPublicServiceProtocol + zimbraPublicServiceHostname + zimbraPublicServicePort を使用します。

  • 上記以外の場合はサーバー (アカウントのホームサーバー) の属性にフォールバックします。

    • プロトコルは server.zimbraMailMode より計算されます。

    • ホスト名は server.zimbraServiceHostname です。

  • ポートはプロトコルより計算されます。

zimbraMailReferMode について - 以前のバージョンでは、ユーザーがログインしたサーバー上にユーザーのメールボックスが存在していなかった場合、 zimbra_auth_always_send_refer というlocalconfig変数がバックエンドサーバーのアクションを指定しました。ユーザーが間違ったバックエンドホストへログインしている場合はデフォルト値であるFALSEでによりユーザーをリダイレクトしました。

マルチサーバーの ZCS環境で、分かりやすいランディングページの作成のためにロードバランスされた名称が必要だったときは、ユーザーを常にリダイレクトする必要があったはずです。この場合は、 zimbra_auth_always_send_refer をTRUEに設定していました。

現在は、完全なリバースプロキシを使用しているため、ユーザーをリダイレクトする必要がありません。Nginxのリバースプロキシにて、localconfig変数 zimbraMailReferMode を使用しています。

プロキシの信頼済みIPアドレスを設定する

プロキシがZCSで設定されている場合、各プロキシサーバーのIPアドレスをLDAP属性 zimbraMailTrustedIP 属性内に設定することでそれらプロキシのIPアドレスを信頼できるものとし、ユーザーがプロキシ経由でログインできるようにしておかなければなりません。 プロキシIPアドレスはメッセージヘッダー情報 X-Forwarded-For に記載されます。 X-Forwarded-For ヘッダーは、自動でLocalconfigヘッダー属性 zimbra_http_originating_ip_header に追加されます。ユーザーログイン時、このIPアドレスとユーザーのアドレスは、Zimbraのメールボックスログに記録されます。

この属性内に各々のプロキシIPアドレスを記載してください。例:プロキシサーバーが2つの場合

zmprov mcf +zimbraMailTrustedIP {nginx-1のIP } +zimbraMailTrustedIP {nginx-2のIP }

localconfigにX-Forwarded-Forが正しく追加されたことを確認するには、以下のコマンドを実行します。

zmlocalconfig | grep -i http

正常に追加されている場合、次のように表示されます。

zimbra_http originating_ip_header = X-Forwarded-For

Kerberos認証用にZimbraプロキシを設定する

Kerberos5認証機能を利用中の環境で、IMAPとPOPプロキシ向けに設定したい場合、本項の記述を参照してください。

Kerberos5認証機能が正しく設定されていることを確認してください。詳細はZimbra LDAP サービスを参照してください。
  1. 各プロキシノードで、サーバー属性zimbraReverseProxyDefaultRealにその該当プロキシサーバーのrealm名を設定します。例:

    zmprov ms [DNS name.isp.net] zimbraReverseProxyDefaultRealm [ISP.NET]
  2. メールクライアントが接続するプロキシIPアドレスごとに、メールサーバーのGSSAPI認証用設定が必要です。各プロキシIPアドレスの各プロキシノードで以下を実行します。

    zmprov mcf +zimbraReverseProxyAdminIPAddress [IP address]
  3. 各プロキシサーバーで以下を実行します。

    zmprov ms [proxyexample.net] zimbraReverseProxyImapSaslGssapiEnabled TRUE
    
    zmprov ms proxyl.isp.net zimbraReverseProxyPop3SaslGssapiEnabled TRUE
  4. プロキシサーバーを再起動します。

    zmproxyctl restart

Zimbra管理コンソール

Zimbraの管理コンソールは、Zimbraサーバーとユーザーアカウントの一括管理を可能とするブラウザベースのユーザーインターフェースです。

管理者のアカウントについて

管理コンソールにログインすると、許可されているタスクがナビゲーションペインに一覧表示されます。許可されているタスクは、管理担当者の権限に基づいています。

Zimbra Collaborationを管理する管理者アカウントは2種類あります。

  • システム管理者(グローバル管理者) サーバー、グローバル設定、ドメイン、アカウントの管理に必要な全ての権限を有し、他の管理者のアカウントを作成することもできます。Zimbraインストール時、自動でシステム管理者アカウントが1つ作成されます。追加でシステム管理者アカウントを作成することも可能です。管理者のタスクは、管理コンソールまたはコマンドラインから実行できます。

  • 委任された管理者 管理コンソールから行なう様々な管理タスクの実施に必要な権限を、システム管理者からカスタマイズで付与される管理担当者です。詳細は 管理権限の委任を参照してください。

管理コンソールへログインする

  1. 通常の環境で管理コンソールを起動するには、下記のURLパターンを利用します。

    パラメーター 説明

    server.domain.com

    Zimbraサーバー名 または IPアドレス

    7071

    デフォルトHTTPリッスンポート

  2. ログイン画面にて、admin@domain.com 形式での完全な管理者アドレスと Zimbra Collaborationのサーバーインストール中に設定したパスワードを入力します。

    管理コンソール

管理者のパスワードを変更する

管理コンソールあるいはCLIからいつでもパスワードを変更できます。

管理コンソールの、パスワード変更 画面から、新規パスワードの文字列を入力し、そのユーザーパスワード修正用ポリシーを定義します。

管理コンソール:

ホーム > 管理 > アカウント

ユーザーアカウント をダブルクリック または 画面右上の ギア アイコンから、ポップアップメニューで パスワードを変更 を選択します。

Change Password
zmprov sp adminname@domain.com password

ログインページとログアウトページをカスタマイズする

ログインとログアウトという異なる2つのページをグローバルレベルまたはドメインレベルで設定できます。

ログインが認証されないときや期限切れ認証のときに、管理者をリダイレクトさせるURLを指定

グローバル設定:

zmprov mcf zimbraAdminConsoleLoginURL <https://example.com>

ドメイン設定:

zmprov md <domain> zimbraAdminConsoleLoginURL <https://example.com>

ログアウトするときに管理者をリダイレクトさせるURLを指定

グローバル設定:

zmprov mcf zimbraAdminConsoleLogoutURL <https://example.com>

ドメイン設定:

zmprov md <domain> zimbraAdminConsoleLogoutURL <https://example.com>

タスクを管理する

ZCSタスクのほとんど、例えばアカウント作成、提供サービス作成、サーバーステータス監視、ドメイン管理、バックアップスケジューリング、セッション管理などは、管理コンソールから管理できます。

その他の設定や保守タスク、例えば、サービスの開始や停止、ローカルサーバー設定の管理などの場合、管理コンソールからは実施できないため、コマンドラインを利用する必要があります。

管理コンソールから、特定の機能に紐づく属性を表示する必要がある場合、現在表示されている設定ページのテキストラベルをクリックして、ポップアップにその情報を表示させることができます。こうしたポップアップには、下記の様にガイドテキストも表示されます。

管理コンソールでの属性表示

属性ポップアップの表示のため、項目のラベルをクリック

Viewing Attributes

表示中の属性ポップアップにて項目についてのガイドを表示するため、More をクリック

Viewing Attributes

UIの案内

Zimbra Collaboration の管理コンソールは、設定や監視ツール、ログイン権限に基づいた表示が素早く案内できるように構成されています。また、様々な ヘルプ やオンスクリーンガイドに簡単にアクセスすることも可能です。

管理コンソールにログインすると表示される ホーム にはステータス情報と本書で説明したオプションが表示されます。オプションを選択して、その設定に遷移することも可能です。

管理コンソール
  1. 前のページあるいは次のページへ遷移

  2. 現在の位置/パス

  3. 検索

  4. 検索のリフレッシュ

  5. 現在のユーザーとログアウトオプション

  6. ヘルプ

  7. ギアアイコン

  8. ステータスペイン

  9. 表示ペイン

  10. ナビゲーションペイン

ナビゲーションペイン内と表示ペイン内の表示およびオプションは、選択された内容に沿って更新されます。他のUI部分?? 矢印ボタン、検索項目、画面リフレッシュ、現在の位置/パス、現在のログイン、ヘルプ?? は、常に表示されています。

ギアアイコン ギアアイコン を特定の画面に表示させて、画面上の機能に紐づいている機能に即座にアクセスできるようにしています。ギアアイコンについての詳細はギアアイコンを使うを参照してください。

ホームナビゲーションペイン

ホーム ナビゲーションペインにあるオプションは、カテゴリー別に ホーム ディレクトリ配下で定義されています。 設定ページへの導線となるオプションもあれば、レポートを含むページへ遷移するオプションもあります。選択したオプションに従って表示されます。

画面右側のイラストは、ナビゲーションペインにある現在サポート中のオプションの拡張ビューです。

階層内の現在位置は、その時に表示されているページ上部のバーに必ず表示されるため、現在の表示画面から遷移する方法は、下記のとおり複数あります。

  • 前ページあるいは次ページへの遷移には、右矢印または左矢印をクリック。

  • 特定のUIへの遷移には、ホームのドロップダウンからオプションを1つ選択。

  • 特定のオプションへの直接遷移には、ナビゲーションペインにある階層をクリック。

ナビゲーションペインのオプションは下記トピックで説明されています。

ホームのUI

ホーム 画面がデフォルトのログイン時の表示です。ホーム ナビゲーションペインと ホーム ページがあります。このページには、システムステータスのスナップショットが表示され、不可欠なタスクにクイックアクセスできるリンクもあります。

Home UI
  1. 前ページまたは次ページへ遷移

  2. 検索

  3. 検索のリフレッシュ

  4. 現在のユーザーとログアウトオプション

  5. ヘルプ

  6. システムステータス

  7. ステータスペイン

  8. クイックスタート

  9. ナビゲーションペイン

Table 11. ホームのUI
項目 説明

要約

現在実行中かつ表示中の Zimbra Collaboration のバージョンと、このセッションに紐付き、検出されているサーバー数、アカウント、ドメイン、提供サービス(COS)を表示。

メンテナンス

直近のソフトウェアバックアップを表示。

ランタイム

サービス、アクティブなセッション、キュー長を表示。

1 開始

 {product-name}
処理の起動に欠かせないステップを表示。このUIの機能へのクイックリンクもあります。
  1. ライセンスのインストール

  2. バックアップの設定

  3. 証明書をインストール

  4. デフォルトの提供サービスを設定

2 ドメインを設定

Collaboratorの管理対象のドメインを確立するために必要なステップを表示。各ステップに対象UI機能へのクイックリンクがあります。

  1. ドメインを作成

  2. GALを設定

  3. 認証を設定

3 アカウントの追加

Collaboratorでの管理用アカウントを作成するステップを表示。各ステップに対象UI機能へのクイックリンクがあります。

  1. アカウントを追加

  2. アカウントを管理

  3. 移行と共存

監視のUI

監視 画面には 監視 ナビゲーションペインと 監視 ページがあります。ページには、Collaboratorが監視したサーバーに関する様々な情報が一覧表示されます。

監視のUI
  1. 前ページまたは次ページへ遷移

  2. 検索

  3. 検索のリフレッシュ

  4. 現在のユーザーとログアウトオプション

  5. ヘルプ

  6. ステータスペイン

  7. ナビゲーションペイン

監視ナビゲーションペインと監視ページ

監視 のページにあるオプションを使用して、様々な方法 ― ダイナミックチャートや表 ― で、個々あるいはシステム全体で見たサーバーやサービスを表示します。

ダイナミックチャートの表示には、Adobe Flash Playerがアクティブである必要があります。
Table 12. 監視のUI
オプション 説明

サーバーステータス

サーバーステータス Collaboratorが監視した、サーバーごとのサービスと時間

高度な統計

高度な統計向けのシステム全体の情報ページ。ページにある次の選択項目のパラメーターを使用すると、新しいチャートをセットアップできます: サーバー、グループ、開始、終了、カウンタ

高度な統計のページには、下記のオプションもあります。

  • グラフ設定を非表示

  • グラフを更新

  • グラフを削除

メッセージ数

メッセージ数向けのシステム全体の情報ページ。 過去48時間、30日、60日、365日の件数を図に表します。この情報は、SMTPまたはLMTPを使用した、メッセージ受信者数に基づいています。各図の下に件数ごとの時間間隔が提示されます。

メッセージボリューム

メッセージボリューム向けのシステム全体の情報ページ。SMTPまたはLMTPを使用した、メッセージ受信者数およびそれに紐づくメッセージボリュームを表す図が表示されます。過去48時間、30日、60日、365日の件数です。各図の下に件数ごとの時間間隔が提示されます。

迷惑メール対策/ウィルス対策

迷惑メール対策/ウィルス対策向けのシステム全体の情報ページ。

アクティビティ

過去48時間、30日、60日、365日に渡り、AS/ACシステムによって処理された固有メッセージの数を示します。各図の下に件数ごとの時間間隔が提示されます。

サーバー統計

選択したサービスホストの統計にアクセスします。ホストの情報は下記のとおり閲覧できます。

  • サービスホスト名の上にカーソルをあてて停止すると、ライセンス情報のポップアップが表示されます。

    License

  • サービスホスト名を右クリックしてポップアップにある 表示 ボタンを選択すると、統計ページに遷移します。サービスホスト名のダブルクリックでも統計ページにアクセスできます。

    View

サーバー統計ナビゲーションペインには、選択したサーバーの下記情報を表示させるオプションもあります。: ディスク、セッション、メールボックスの割り当て容量、メッセージ数、メッセージボリューム、迷惑メール対策/ウィルス対策アクティビティ

メールキュー

各ページタブから検知されたメールキューの遅延、受信、アクティブ、保持、破損に関する統計件数が表示されます。各タブページには要約フィルター情報とメッセージの詳細情報があります。

管理のUI

管理 画面には 管理 ナビゲーションペインと 管理 ページがあります。ページにはCollaboratorで現在管理しているアカウント、エイリアス、配布リスト、リソースというカテゴリーで表を見ることができます。

管理のUI
  1. 前ページまたは次ページへ遷移

  2. 設定

  3. 検索のリフレッシュ

  4. 現在のユーザーとログアウトオプション

  5. ヘルプ

  6. ギアアイコン

  7. ステータスペイン

  8. ナビゲーションペイン

Table 13. 管理のUI
オプション 説明

アカウント (数)

Collaboratorが管理しているアカウントの表。下記の操作が可能です。

  • ポップアップ表示からID情報を表示: アカウントの行にカーソルをあてて停止します。

  • 表の行を右クリックするかギアアイコンを使用して、次の機能にアクセスします: 削除, 編集, パスワードを変更, 新しい管理者, メールを表示, 新規, セッションを無効にする, 権限を表示, 許可を設定, メールボックスを移動, メールを検索

エイリアス (数)

Collaboratorが管理しているエイリアスの表。各エイリアスは、全てのメールを特定のアカウントへ転送するメールアドレスです。

下記の操作が可能です。

  • ポップアップ表示からID情報を表示: エイリアスの行にカーソルをあてて停止します。

  • 表の行を右クリックするかギアアイコンを使用して、次の機能にアクセスします: 削除, 編集, 新しい管理者, メールを表示, エイリアスの 移動, 新規, セッションを無効にする, 権限を表示, 許可を設定, メールボックスを移動, メールを検索

配布リスト (数)

Collaboratorが管理している配布リストの表。配布リストとは、ある共通メールアドレス1つを使用した、メールアドレスのグループリストです。配布リストへの送信は、そのリストに含まれる全員のアドレスへの送信です。 To: の宛て先の行には、この配布リストのアドレスが表示されます。

下記の操作が可能です。

  • ポップアップ表示からID情報を表示: 配布リストの行にカーソルをあてて停止します。

  • 表の行を右クリックするかギアアイコンを使用して、次の機能にアクセスします: 削除, 編集, 新しい管理者, メールを表示, 新規, 権限を表示, 許可を設定, メールを検索

リソース (数)

Collaboratorが管理しているリソースの表。リソースとは、ミーティングで予定される可能性のある場所または機器のことです。

下記の操作が可能です。

  • ポップアップ表示からID情報を表示: リソースの行にカーソルをあてて停止します。

  • 表の行を右クリックするかギアアイコンを使用して、次の機能にアクセスします: 削除, 編集, 新しい管理者, メールを表示, 新規, 権限を表示, 許可を設定, メールを検索

設定のUI

設定 画面には 設定 ナビゲーションペインと 設定 ページがあります。個々のコンポーネントやグローバルコンポーネントの設定が可能です。

Configure UI
  1. 前ページまたは次ページへ遷移

  2. 検索

  3. 検索のリフレッシュ

  4. ヘルプ

  5. ギアアイコン

  6. ステータスペイン

  7. ナビゲーションペイン

Table 14. 設定のUI
オプション 説明

提供サービス

管理コンソールから管理する提供サービス(COS)を表示します。

  • 表内の行をダブルクリックし、選択したCOSの設定画面へアクセスします。

    あるいは

  • 表内の行を右クリック、またはギアアイコンを使用して、次の機能へアクセスします: 新規, 削除, 編集, 複製

ドメイン

管理コンソールから管理するドメインを表示します。

  • 表内の行をダブルクリックし、選択したドメインの設定画面へアクセスします。

    あるいは

  • 表内の行を右クリック、またはギアアイコンを使用して、次の機能へアクセスします: 新規, 削除, 編集, GALを設定, 認証を設定, アカウントを表示, ドメインエイリアスを追加, 許可を設定

サーバー

管理コンソールから管理するサーバーを表示します。

  • 表内の行をダブルクリックし、選択したサーバーの設定画面へアクセスします。

    あるいは

  • 表内の行を右クリック、またはギアアイコンを使用して、次の機能へアクセスします: 編集, キャッシュをフラッシュ, プロキシを有効にする, プロキシを無効にする

グローバル設定

Zimbra Collaborationのグローバルパラメーターの設定に使用するツールへアクセスできます。

ギアアイコン: 保存, ダウンロード, ライセンスを更新, ライセンスのアクティベーション, 手動によるライセンスのアクティベーション

Zimlet

管理コンソールから管理するZimletを表示します。

  • 表内の行をダブルクリックし、選択したZimletの設定画面へアクセスします。

    あるいは

  • 表内の行を右クリック、またはギアアイコンを使用して、次の機能へアクセスします: 配備, 配備解除, ステータスの切り替え

管理拡張機能

管理コンソールから管理する管理拡張機能を表示します。

  • 表内の行をダブルクリックし、選択した管理拡張機能の設定画面へアクセスします。

    あるいは

  • 表内の行を右クリック、またはギアアイコンを使用して、次の機能へアクセスします: 配備, 配備解除

証明書

管理コンソールから管理する証明書を表示します。

  • 表内の行をダブルクリックし、選択した証明書についての全般情報画面へアクセスします。

    あるいは

  • 表内の行を右クリック、またはギアアイコンを使用して、次の機能へアクセスします: 証明書をインストール, 証明書を表示

権限

管理コンソールから管理する様々な権限を表示します。

  • 表内の行をダブルクリックし、選択した権限についての全般情報画面へアクセスします。

    あるいは

  • 表内の行を右クリック、またはギアアイコンを使用して、次の機能へアクセスします: 表示

グローバルACL

管理コンソールから管理するグローバルアクセスコントロールリストを表示します。

  • 表内の行をダブルクリックし、選択したグローバルACLの編集画面へアクセスします。

    あるいは

  • 表内の行を右クリック、またはギアアイコンを使用して、次の機能へアクセスします: 追加, 削除, 編集

グローバル設定のUI

グローバル設定により、サーバー、アカウント、COS、ドメインのデフォルト値をグローバルに定義します。ほかの設定で値やパラメーターが明確に定義されていない場合、このデフォルト値とパラメーターが適用されます。

グローバル設定のデフォルトは、インストール中に設定されます。この設定はいつでも管理コンソールから変更できます。

Table 15. グローバル設定のUI
オプション 説明

全般情報

  • 取得できるGAL検索結果の最大件数を設定します。

  • デフォルトドメインを定義します。

  • リモートデータソースのコンテンツを一度に実行できるスレッド数を設定します。

詳細は 全般情報の設定を参照してください。

添付ファイル

  • 特定の拡張子を持つファイルが添付されたメールを拒否するルールを有効にします。

  • 添付ファイルを読み込まないようにします。

  • 閲覧用に添付をHTML形式に変換します。

詳細は 添付の設定を参照してください。

MTA

  • 認証を有効にします。

  • メッセージの最大サイズを設定します。

  • プロトコルチェックとDNSチェックを有効または無効にします。

  • X-Originating-IPをメッセージのヘッダーに追加します。

詳細は MTA設定を参照してください。

IMAP

IMAPサービスを有効にします。この設定変更は、サーバーを再起動するまで反映されません。

POP

POPS3 サービスを有効にします。この設定変更は、サーバーを再起動するまで反映されません。

AS/AV

迷惑メールチェックとウィルス対策のルールを設定します。迷惑メールチェックの設定は、サーバーを再起動するまで反映されません。

テーマ

  • 既存テーマのカラースキームをカスタマイズします。

  • テーマにロゴを追加します。

テーマ設定を変更するには、サーバー設定のツールバーにある“キャッシュをフラッシュ”ボタンを使用して、サーバーテーマのキャッシュをフラッシュする必要があります。

詳細は テーマ色やロゴ管理を参照してください。

詳細設定

  • 外部のゲストとの共有ブリーフケースフォルダにログイン時、認証要求ダイアログに社名として最初に表示する表示名を設定します。

  • アカウントメール検証の正規表現ルールを追加します。

保持ポリシー

ユーザーのフォルダにあるアイテムの保持と廃棄の時間軸でのしきい値を設定します。保持ポリシーと廃棄ポリシーはグローバル設定として設定することもできます。グローバル設定から継承する代わりにCOSレベルのポリシーを設定することもできます。

Proxy

Webプロキシとメールプロキシのパラメーターを設定します。詳細プロキシパラメーター用のツールもあります。

S/MIME

(Secure Multipurpose Internet Mail Extensions): S/MIMEタブでLDAPの設定を行ないます (S/MIME機能が有効にされている場合)。ユーザーはプライベートキーの取得にLDAPサーバーを使用します。

ACL

(Access Control List): ACE(Access Control Entry)設定画面に遷移して、委任された管理者の管理権限を選択したターゲットに追加、編集、削除します。

Backup/Restore

基準のバックアップやオートグループ化のバックアップのバックアップパラメーターを設定します。 詳細はバックアップと復元をご覧ください。

HSM

(hierarchical storage management): メッセージをセカンダリボリュームに移動させる前の経過期間を設定します。

ライセンス

  • Zimbraライセンスを更新・インストールします。

  • 現在のライセンス情報を表示します。

ツールおよび移行のUI

ツールおよび移行 画面には ツールおよび移行 ナビゲーションペインがあり、システムのソフトウェアの管理機能やシステムバックアップ/リストア機能にアクセスできます。管理者はこのページから特定のウィザードにアクセスしたり、ツールをダウンロードしたりすることができます。

Tools and Migration UI
  1. 前ページまたは次ページへ遷移

  2. 検索

  3. 検索のリフレッシュ

  4. 現在のユーザーとログアウトオプション

  5. ヘルプ

  6. ステータスペイン

  7. ナビゲーションペイン

Table 16. ツールおよび移行
オプション 説明

ダウンロード

ダウンロード可能なzipパッケージのあるZimbraユーティリティへアクセスします。多様なプラットホームに向けた移行ウィザードやOutlookコネクタが含まれており、一般的な管理用途や個々のエンドユーザーとの同期に使えます。詳細は ダウンロード可能なウィザードとコネクタ に記載しています。

ソフトウェア更新

お使いのシステムにZimbraサーバー更新が必要かどうかをチェックします。また、ポーリングやソフトウェア更新に必要な連絡先メール情報を表示します。

詳細は Zimbra Collaboration のソフトウェア更新を確認する を参照してください。

アカウント移行

システムで検知されたアカウント移行の詳細を表示します。インポートの合計数と各ステータスが一覧で表示されます。一覧にあるアカウント移行の各オーナー名も表示されます。 Zimbraサーバーからアカウントを移行する を参照してください。

クライアントのアップロード

システムにアップロードする対象ソフトウェアの最新版を閲覧するページです。画像を選択後、アップロード ボタンを使用して、ソフトウェアアップロードを処理します。

Backups

直近のシステムバックアップに基づく現在の空き容量と総容量 (MB) の概要ビューにアクセスします。このナビゲーションペインで管理者を特定し、その管理者に関連したバックアップ履歴を閲覧することもできます。この履歴には、ラベルと開始時間、終了時間が表示されます。また、各バックアップ結果やバックアップ対象のディレクトリパスが表示されます。詳細は、バックアップと復元 を参照してください。

ダウンロード可能なウィザードとコネクタ

ツールおよび移行 画面の ダウンロード オプションを利用して本項記載のツールを取得します。

Table 17. ツールおよび移行

Exchange/PST用の ZCS 移行ウィザード (32 ビット)
Exchange/PST用のZCS 移行ウィザード (64 ビット)

Microsoft ExchangeもしくはPSTファイルからZimbra Collaboration サーバーへ、メールカレンダーと連絡先をサーバー TO サーバーで移行するzipファイルを取得します。

このパッケージはPSTファイルのインポートのみサポートしており、テクニカルガイダンスのサポートのみが2020年12月31日まで提供しています。 なお、すべてのアカウント移行の代替案として、 audriga社の移行ソリューション の利用を推奨しております。

Domino用ZCS 移行ウィザード

このパッケージのサポートが終了しております。 なお、すべてのアカウント移行の代替案として、 audriga社の移行ソリューション の利用を推奨しております。

レガシーExchange用 ZCS 移行ウィザード

このパッケージのサポートが終了しております。 なお、すべてのアカウント移行の代替案として、 audriga社の移行ソリューション の利用を推奨しております。

Outlook MSI Customizer 用Zimbraコネクタ

標準のZCO MSIをカスタマイズに使用する機能の備わったテキストファイルです。サーバー名、ポート、組織専用の変数をカスタマイズできます。

Outlook Branding MSI用Zimbraコネクタ

標準のZCO MSIをカスタマイズするにはWindowsのVisual Basic Script Edition (VBScriptのスクリプトファイル)を取得します。カスタマイズにより、Zimbra製品の全インスタンスの名称およびロゴが入れ替わります。

Table 18. エンドユーザーツールおよび移行

Outlook用Zimbra コネクタ (32 ビット)
Outlook用Zimbra コネクタ (64 ビット) (ユーザー案内)

ユーザーのWindows システムにインストールするWindows Installer Package zipファイルを取得します。このアプリで、ユーザーのOutlookが ZCS サーバーのカレンダー、連絡先、メールと同期できます。

(レガシー)Microsoft Outlook PSTインポートツール

このパッケージのサポートが終了しております。 PST インポートする場合、一般的な移行ウイザードを使用してください。

(レガシー)Microsoft Exchange の移行ウイザード

このパッケージのサポートが終了しております。 なお、すべてのアカウント移行の代替案として、 audriga社の移行ソリューション の利用を推奨しております。

一般的な移行ウイザード

このツールでMicrosoft ExchangeサーバとOutlook PSTファイルにあるデータをZimbraサーバへインポートします。

このパッケージはPSTファイルのインポートのみサポートしております。 なお、すべてのアカウント移行の代替案として、 audriga社の移行ソリューション の利用を推奨しております。

検索のUI

検索 画面には、管理コンソールのヘッダーにある検索項目で実施されたクエリの 検索 結果を表示します。

  • 検索のクエリを入力せずにこのページを開くと、デフォルトで全検索が行なわれ、コンテンツペインにアカウント、ドメイン、配布リストが表示されます。

  • オートコンプリーション機能によって、名前の一部を入力後表示される 一致した文字列一覧から、検索可能な名称を選択することができます。

  • ZimbraのメールボックスIDの数値を使用して、アカウント検索することもできます。ただし、メールボックスIDによる検索の場合、検索時にIDの全文字列を入力する必要があります。

Search UI
  1. 前ページまたは次ページへ遷移

  2. 検索オプション

  3. 検索

  4. 検索のリフレッシュ

  5. 現在のユーザーとログアウトオプション

  6. ヘルプ

  7. ギアアイコン

  8. ステータスペイン

  9. 検索ナビゲーションペイン

Table 19. 検索のUI
オプション 説明

すべての結果

全検索結果の件数および表を表示します。

アカウント

アカウントに対するクエリ結果の件数および表を表示します。

ドメイン

ドメインに対するクエリ結果の件数および表を表示します。

配布リスト

配布リストに対するクエリ結果の件数および表を表示します。

基本属性

姓、名、表示名、あるいはアカウントのID番号によってユーザーを検索します。管理者や委任された管理者のみの検索も可能です。

ステータス

次のステータスによってアカウントを検索します: アクティブ、閉鎖、ロック、ロックアウト、保留、メンテナンス

最終ログイン時刻

最終ログイン時刻によってアカウントを検索します。検索対象とするデータの範囲を指定できます。

外部メールアドレス

外部メールアドレスによってアカウントを検索します。

提供サービス

提供サービスによってオブジェクトを検索したり、提供サービスのないオブジェクトを検索します。

サーバー

選択したサーバーのアカウントを検索します。

ドメイン

選択したドメインのアカウントを検索します。

保存済み検索

このセクションにはデフォルトで、事前に定義された共通検索クエリがあります。オリジナルのクエリを作成して保存することも可能です。クエリ文を入力後、検索を保存 ボタンをクリックして名付けた検索は、保存済み検索セクションに追加されます。

簡単な検索のセットアップ

  1. 検索タイプを決定するため、検索 項目にあるドロップダウンリスト内の次の選択肢から1つを選びます: アカウント, 配布リスト, エイリアス, リソース, ドメイン, 提供サービス, 全ての種類のオブジェクト

    アカウントの場合は、表示名、姓、名、メールアドレスの始まりの部分、エイリアス、配布先アドレス、メールボックスIDから検索することができます。

  2. 検索 項目に検索用文字列を入力します。

    部分検索も可能ですが、メールボックスIDでの検索の場合はIDの全文字列を入力する必要があります。

  3. 検索 をクリックします。

    入力条件に基づいた検索結果が検索ページに表示されます。

  4. 検索 > すべての結果 のナビゲーションペインに検索結果の合計数が表示されます。

ヘルプセンターのUI

ヘルプセンター からオンラインヘルプとドキュメントを参照します。ヘルプセンター 画面にはアクセス可能なリンクがいくつもあります。コミュニティフォーラムへアクセスしたり、移行に関するよくある質問への回答を閲覧したりすることもできます。

Help Center UI
  1. 前ページまたは次ページへ遷移

  2. 検索

  3. 検索のリフレッシュ

  4. 現在のユーザーとログアウトオプション

  5. ヘルプ

  6. ステータスペイン

  7. ナビゲーションペイン

Collaboratorの表ツール

通常、ナビゲーションペインからカテゴリーを選択すると、そのカテゴリーに関連する全ての管理対象オブジェクトが表形式で表示されます。表内の項目名付きの列内に設定されるメールアドレス、表示名、ステータス、最終ログイン、説明 (設定されている場合) 等の情報を閲覧することができます。

各エントリに関する追加情報や各エントリに設定を行なうためのアクセスが必要であれば、対象行でアクションを実行することができます。

行でのアクション 結果

カーソルをあてる

(アカウントの行から取得した)右の例のように、選択したIDの詳細を表示します。

Tools

右クリック

選択行のポップアップメニューにアクセスします。右の例のとおり、共通の表からでも行によってポップアップメニューが異なる場合があります。

アカウントとエイリアス (左) : 配布リストとリソース (右) :

Tools

通知メッセージボックス

グローバル管理者は、管理コンソールに表示する通知メッセージ (MOTD: Message of the Day) を作成することができます。

管理者が管理コンソールへログインする度に、設定しておいた通知メッセージが画面左上に下記例のように表示されます。

Message of the Day

通知メッセージを閉じたり、置き換えたり、削除したりすることができます。

通知メッセージを閉じる

メッセージの表示を閉じるには、メッセージ内の Close ボタンをクリックします。

通知メッセージを作成する

表示したい通知メッセージを1件もしくは複数件作成するには、本項のガイドに沿って、属性 zimbraAdminConsoleLoginMessage を使用します。

コマンド入力を使用してメッセージを作成する場合は、表示したいメッセージをダブルクォーテーションマークで括ってください。

グローバル、または特定のドメインへの通知メッセージを作成

zmprov md <domain> zimbraAdminConsoleLoginMessage "message to display"

複数のメッセージを表示

zmprov md <domain> +zimbraAdminConsoleLoginMessage "second message to display"

通知メッセージを削除する

通知メッセージを1件もしくは複数件削除するには、本項のガイドに沿って、属性 zimbraAdminConsoleLoginMessage を使用します。

コマンド入力を使用してメッセージを削除する場合は、個別または複数の削除についての下記ガイドを参照してください。
  • 属性の前にマイナス(-)を付け、削除したい通知メッセージごとにダブルクォーテーションマークで括ってください。

  • すべての通知メッセージを削除する場合、シングルクォーテーションマークを記載してください。

特定の通知メッセージを削除

zmprov md <domain> -zimbraAdminConsoleLoginMessage "message to display"

すべての通知メッセージを削除

zmprov md <domain> zimbraAdminConsoleLoginMessage ''

参考:機能について

管理コンソールから使用できる下記トピックの機能概要を説明します。

GUIのロードマップ

管理コンソール UIの概要は下記イラストになります。

管理コンソール UIの概要図
High-level View of Administration Console UI

ナビゲーションペインの項目を選択し処理を実行するには、ギアアイコンを利用する方法と、項目のポップアップメニューを利用する方法があります。

ギアアイコンを利用する

表示されている選択可能なアイテムに ギア アイコンが使用できる場合、ページ右上にこのアイコンが配置されます。

The Gear Icon

実行できるオプションを確認するには、ナビゲーションペインやビューページにある項目を1つ選択し、ハイライトさせます。ハイライトされている項目に対し実行できないオプションは、ギアアイコンメニューで強調表示されません。つまり強調表示されたオプションは実行できます。下図は、全く同じ画面でナビゲーションペインの項目をハイライトさせたときと、ビューページの行エントリをハイライトさせたときの、ギアアイコンのオプション例です。

The Gear Icon

次の表は、ギアアイコンから開始できる機能と、それにより内容が変化するギアアイコンメニューの概要です。

Table 20. ギアアイコン 操作
ナビゲーションペインの項目 選択肢 オプション Gear Icon

ホーム モニター

サーバー統計

表示

メールキュー

フラッシュ

管理

アカウント

新規, 新しい管理者, 編集, 削除, パスワードを変更, セッションを無効にする, メールを表示, メールボックスを移動, 権限を表示, 許可を設定

エイリアス

新規, 新しい管理者, 編集, 削除, エイリアスを移動, セッションを無効にする, メールを表示, メールボックスを移動, 権限を表示, 許可を設定

配布リスト

新規, 新しい管理者, 編集, 削除, メールを表示, 権限を表示, 許可を設定

リソース

新規, 新しい管理者, 編集, 削除, メールを表示, 権限を表示, 許可を設定

設定

提供サービス

新規, 削除, 編集, 複製

ドメイン

新規, 削除, 編集, GALを設定, 認証を設定, アカウントを表示, ドメインエイリアスを追加, 許可を設定

サーバー

編集, キャッシュをフラッシュ, プロキシを有効にする, プロキシを無効にする

グローバル設定

保存, ダウンロード, ライセンスを更新, ライセンスのアクティベーション, 手動によるライセンスのアクティベーション

Zimlet

配備, 配備解除, ステータスの切り替え

管理拡張機能

配備, 配備解除

証明書

証明書をインストール, 証明書を表示

ボイス/チャットサービス

新規, 削除, 編集, セッションIDの生成

権限

表示

グローバル ACL

追加, 削除, 編集

ツールおよび移行

ソフトウェア更新

保存, 今すぐチェック

アカウント移行

タスクの削除, 最新の情報に更新, 移行ウィザード

バックアップ

表示, バックアップ, 復元, 設定, リフレッシュ

検索

すべての結果

削除, 編集, パスワードを変更, メールを表示, エイリアスを移動, セッションを無効にする, メールボックスを移動, ダウンロード

アカウント

ドメイン

配布リスト

項目のポップアップメニューを利用する

項目のポップアップメニューを利用して、その項目の処理を実行する方法もあります。

ナビゲーションペインにポップアップメニューはありません。

下記の例は、ビューページで特定したエントリから表示されるポップアップ内容を表します。

Example 5. ポップアップのオプション内容
Popup options

コンテナ

管理コンソールでは、広範囲にわたる設定オプション内容を論理的にグループ分けしたコンテナに入れています。コンテナ内の設定オプションは 管理コンソール UIの概要図 にて一覧化されています。
デフォルトでは、ページ内の全てのコンテナが開いています (広がっています) 。各コンテナの左上にある開閉ボタンをクリックしコンテナを閉じる (見えなくする) ことで、ビューページ内にスペースを確保することも可能です。

Containers

Zimbra PST 移管ウィザード

Zimbra PST 移管ウィザードでは、Microsoft Outlook のパーソナルフォルダー (PST) ファイルを Zimbra Collaboration (ZCS) へ移管することが可能です。

このツールは2つのモードで運用することが可能です:

  • GUI 型の移管ウィザード

  • コマンドライン型の移管ツール

移管ウィザードのGUIについて

Zimbra PST 移管ウィザードでは、分かりやすいインターフェースでユーザー様が`PST`ファイルを Zimbra Collaborationサーバへ移管することが可能です。

このツールは4つのフェーズがあります。

ソース

Zimbra Collaboration サーバへ移管する PST ファイルを特定し、選択する。

移管先

Zimbra Collaboration サーバへのログイン情報を入力する。

オプション

移管するフィルダー、アイテム、などのオプションを指定する。

結果

移管の進歩状況、エラー、および警告を含め、移管のステータスを閲覧する。

ソースの詳細

  1. Source をクリックします。

  2. PST File の横にある …​ をクリックし、ファイルのブラウザ画面を開きます。

  3. Zimbra Collaboration サーバへ移管する PST ファイルを選択します。

  4. ログの詳細レベルを選択します。ログは %temp%/ZimbraMigration のフォルダーへ記録し、移管の問題が発生した場合に調査するために利用します。問題が発生した場合、サポートはこれらのログファイルを依頼する場合がございます。ツールを検証する場合、ログレベルを Verbose に指定することを推奨しています。

    ご注意ください:ディスクスペースを保護するため、ログファイルは自動的に7日間後に削除しますので、移管してから7日間後でのサポートが必要である場合、ログのバックアップを取得してください。移管中では、Results ページに Open Log File をクリックすることでログファイルを開くことが可能です。

  5. Next をクリックします。

移動先の詳細

PST ファイルを移管するため、管理者が Zimbra Collaboration サーバ上でアカウントを作成し、移管ツールのアプリケーションと以下の情報を提供します。

  1. Destination にて、以下の詳細を記入します。

    Hostname

    Zimbra サーバのドメイン名

    Port

    一般艇に、非セキュアの接続の場合、サーバが運用するポート番号は 80 ですが、セキュア接続のポート番号は 443 となります。

    Use Secure Connection

    ZCS へのSSLセキュアコミュニケーションのオプションを選択します。

    Username

    ZCS アカウントのメールアドレスを \名前@ドメイン の形式で移入します。

    Password

    ZCS アカウントのパスワードを記入します。

  2. Next をクリックします。

移管オプションについて

  1. Item Types にて、インポートするアイテムを選択します。

  2. Sent, Deleted Items (trash), および Junk (Spam) のフォルダーも移管する場合、Additional Folders を選択します。

  3. Filters: 不要な PST アイテムを移管しないため、以下のフィルターオプションを活用します。

    • Migrate On or After: このオプションで指定した日時より前のメッセージを移管しないことがでいます。ツールは指定した日時より前のメッセージを無視します。

    • Maximum message size: メッセージサイズがメッセージの本文と添付ファイルを含めています。この値を空にした場合、Zimbra Collaboration サーバの最大メッセージサイズ設定を活用します。

      • こちらのオプションにサイズを指定した場合、グローバル MTA 設定の最大メッセージサイズより大きく設定できません。デフォルトの最大メッセージサイズは 0 (サイズ上限はないことを示す) です。

        ご注意:最大サイズを 0 に設定しても、Zimbra Collaboration サーバの上限を無視することができません。

        Skip these folders, and their children (separate with a comma)

        移管を無視するフォルダー(サブフォルダーを含め)をコンマ区切りで記入します。

        Skip previously migrated items

        以前に移管したアイテムを再度に移管しない場合、このオプションを活用します。

        ご注意:最大メッセージサイズの値を管理コンソールの 設定グローバル設定MTA 画面での確認、および変更することが可能です。

  4. Save をクリックしますと、設定情報をファイルとして保存し、移管ツールを再度に事項した場合に ソースの詳細 のページで Load ボタンで読み込むことが可能です。

  5. Back をクリックしますと、ソースの詳細 または 移動先の詳細 に詳細を変更することが可能です。

  6. Migrate をクリックしますと移管のプロセスが開始ます。

移管の結果を閲覧する場合

結果ページでは、進歩状況、エラー、および警告を含め、PST ファイルの移管状況を確認することが可能です。

結果のログを閲覧する場合、アカウントをダブルクリックします。新しいタブにアカウントのログ情報が表示されます。

Account

移管のステータスを表示します。プログレスバーで移管の進歩状況、およびステータスメッセージを示しています。Min/Avg/Max は該当アカウントにアイテムの移管に対する最低、平均、および最大時間(ミリ秒単位)です。Read/Write ではソースからデータの読み込み対Zimbra Collaboration サーバでのデータ書き込み時間を示します。これらのデータにて、ネットワーク/サーバのボトルネックを特定するために役立ちます。例えば、90%:10% が指定して場合、ソースがボトルネックであることを示します。

  • Accountsにてアカウント名をダブルクリックしますと、追加のタブでフォルダー毎の移管状況、およびフォルダー毎でのボトルネック統計情報を確認できます。X をクリックすると開いているタブをクローズします。

Open Log File

PST ファイル移管に関連しているログファイルを開きます。ログファイルは %temp%\ZimbraMigration\Logs\*.log で保存してます。各移管は複数のログファイルを発行します。*migrate.log は全体的な移管セッションデータを含まれています。*migrate-SUMMARY.log は移管セッションから重要なイベントの要約を含まれています。また、移管する際に、各アカウントに対するログファイルが作成します: *migrate [ソースアカウント名][移管先アカウント名].log

Stop

Stopをクリックしますと移管を中断します。再開する場合、前の画面へ戻り、Migrate ボタンを再度にクリックします。

Exit

Exitをクリックしますと移管ツールを終了します。

移管ウィザードのCLIについて

Zimbra PST 移管ウィザードはコマンドラインのインターフェースも提供しており、1つのコマンドで複数のオプションを運用することで、ユーザー様が`PST`ファイルを Zimbra Collaborationサーバへ移管することが可能です。

コマンドを実施するため、設定ファイル (XML) と PST ファイルが必要となります。

設定ファイルを作成する方法

  1. Zimbra Collaboration を起動します。

  2. ソース情報 を指定します。

  3. 移管先の情報 を指定します。

  4. 現在の移管に対する オプション を選択します。

    ご注意:こちらで指定したオプションはコマンドラインのツールで指定したオプションで上書きすることが可能です。

  5. 完了した場合、Save をクリックし、上記の設定を XML ファイルとして保存します。

ツールを実施する方法

構文

ZimbraMigrationConsole ConfigxmlFile=<XMLファイルの保存先> [arg1] [arg2] …​

事例

ZimbraMigrationConsole ConfigxmlFile=../Config.xml Calendar=true Contacts=true

事例の結果

移管ツールは指定した XML ファイルと PST ファイルからのカレンダーと連絡先を移管します。

ご注意:ツールではXMLファイルを作成する際に オプション を選択した際に同様なオプションを指定することが可能です。利用可能のオプションを確認する場合、ツールを -help のオプションで実行してください。

要注意:コマンドラインのツールで指定したオプションは設定ファイルに指定したオプションを上書きします。

コマンドが正常に完了しましたら、コンソール上に移管のステータスが表示されます。

設定を管理する

ZCS コンポーネントは、ソフトウェアの初回インストール時に設定されます。インストール後は本章で説明するように管理コンソールやCLIから、コンポーネントを管理することができます。

管理コンソールの使用方法等に関する ヘルプ は、管理コンソール内で提供しています。CLIからしか実行できないタスクは、Zimbra CLI コマンド でコマンドラインのユティリティの使用方法についての説明を参照してください。

グローバル設定

グローバル設定はZimbraサーバー内の全てのアカウントに適用されます。グローバル設定はインストール中にあらかじめ設定されます。管理コンソールから設定を変更することもできます。

グローバル設定での設定内容は、デフォルト値としてサーバー、アカウント、提供サービス、ドメインのレベルに継承されます。こうしたレベルで属性が設定された場合、その設定はグローバル設定にオーバーライドします。

管理コンソール:

グローバル設定を設定するには次のように遷移します。
ホーム > 設定 > グローバル設定

設定済みのグローバル設定

  • デフォルトドメイン

  • GAL検索結果の最大件数。デフォルト値は100。

  • 添付ファイルのユーザーへの表示方法と添付ファイルの拡張子制限。

  • 認証プロセスの設定、外部配信用リレーMTA、DNS検索、プロトコルチェック。

  • 迷惑メールチェックの制御と受信メッセージをチェックするための迷惑メール対策のオプション。

  • Zimbra Collaborationサーバーとサードパーティ製のサーバーに渡る、Free/Busyのスケジューリング。

  • テーマのカスタマイズ: 配色の修正とロゴの追加。

  • 外部ゲストによる共有ブリーフケースへのアクセス時、表示される会社名の設定。

  • バックアップのデフォルトディレクトリとバックアップの通知情報。

  • セカンダリストレージ領域へのメール移動のためのグローバルHSMスケジュール。

  • 現在のZimbra ライセンス情報の表示、ライセンスの更新、作成済みアカウント数の表示。

全般情報の設定

管理コンソール:

ホーム > 設定 > グローバル設定

インストール・有効化されているサーバーのグローバルパラメーターの閲覧と設定は、 全般情報 ページから行ないます。

サーバーで定義した設定は、この全般情報ページで設定した内容をオーバーライドします。

General Information

  1. 要件に合うようにパラメーターを修正します。

  2. ギア アイコンから 保存 を選択します。

Table 21. 全般情報のパラメーター
オプション 詳細

GAL検索で取得できる結果の最大件数

ユーザー検索で返されるGAL検索結果の最大件数。ドメインでも設定できる値です。ドメインでの設定は、グローバル設定にオーバーライドします。
デフォルト値は100。

デフォルトドメイン

ユーザーがログインした際、アカウント認証で対象となるドメイン。

同時に実行できる予定済みタスクの最大数

外部データソースから取得するデータのスレッド数。

  • この値を低く設定しすぎると、充分な頻度での外部ソースからのメール受信ができなくなります。

  • この値を高く設定しすぎると、メールのダウンロードにサーバー負荷がかかり、主要である内部リクエストを正常に処理できなくなる恐れがあります。
    デフォルト値は20。

メールボックス削除のスリープ時間間隔

メールボックス削除のたびに"停止"するべき時間間隔です。メッセージ削除スケジュールを0に設定すると、メッセージは削除されません。そのため、メール、ゴミ箱、迷惑メールの保持期間を指定していたとしても、メッセージは削除されません。
デフォルトでは、1分毎のメッセージ削除がスケジュールされています。

デスクトップからアップロードされるファイルの最大サイズ (KB)

ブリーフケースにアップロードできる最大のファイルサイズです。

送信できる1件あたりのメッセージと添付ファイルの最大サイズは、 ホーム > 設定 > グローバル設定 > MTA ページの メッセージ セクションで設定します。

管理者ヘルプURL
委任された管理者のヘルプURL

Zimbra Collaboration のヘルプを使用するには、管理コンソールのヘルプにあるリンクのURLを使用します。

添付の設定

添付ファイルの処理ルールを設定する

グローバル設定の添付ファイル設定にて、メッセージの添付ファイルに関するグローバルルールを指定できます。提供サービスおよび各アカウントにてルールを設定することも可能です。グローバル設定に添付ファイルのルールを設定すると、提供サービス設定やアカウント設定に優先してグローバル設定が適用されます。

管理コンソール:

ホーム > 設定 > グローバル設定 > 添付ファイル

Attachment Rules
この画面に関する詳細は 拡張子から添付ファイルをブロックする を参照してください。

Table 22. グローバル設定詳細
オプション 詳細

提供サービスの設定にかかわらず、添付ファイルを表示しない

ユーザーは添付ファイルをいっさい閲覧できません。添付ファイルからのウイルス発生防止用にこのグローバル設定を利用することも可能です。いっさいの添付ファイルが開けないからです。

提供サービスの設定にかかわらず、添付ファイルをHTML形式で表示

添付ファイルの閲覧はHTMLでのみ可能です。 提供サービスに他の設定をした場合も、このグローバル設定が提供サービス設定にオーバーライドします。

提供サービスの設定に従って表示

添付ファイルの表示方法は、提供サービスで設定したルールに従います。

ブロックされている拡張子の通知を受信者に送信

拡張子から添付ファイルをブロックする

添付ファイルに特定の拡張子を伴うメッセージを拒否することもできます。 一般的な拡張子 から承認しない拡張子を選択します。リストにない拡張子を追加することも可能です。こうした拡張子が添付ファイルに含まれているメッセージはすべて拒否されます。デフォルトでは、差出人と宛先にメッセージがブロックされた旨が通知されます。

メッセージがブロックされた際の通知を宛先に送信したくない場合、このオプションを無効にします。

管理コンソール:

ホーム > 設定 > グローバル設定 > 添付ファイル

MTA設定

MTAページのオプションを使用して、認証の有効/無効、リレーホスト名、メッセージの最大サイズ、DNS検索の有効化、プロトコルチェック、DNSチェックを設定します。

管理コンソール:

ホーム > 設定 > グローバル設定 > MTA

MTA Configuration

Table 23. MTAページのオプション
オプション 詳細

認証

  • 認証 を有効にする:有効にしておく必要があります。モバイルSMTP認証ユーザーをサポートして、そのユーザーたちのメールクライアントがZimbra のMTAと会話できるようにします。

  • TLS認証のみ :すべてのSMTP認証にTransaction Level Security(処理レベルのセキュリティ)の使用を強制します。パスワードがそのままで通信されることを回避するためです。

ネットワーク

  • ウェブメールMTAホスト名とウェブメールMTAポート : メール送信用にウェブサーバーが接続するMTA。デフォルトポート番号は25です。

  • 外部配信用のリレーMTA : リレーホスト名。これは、Postfixが外部メールをリレーするZimbraのMTAです。

  • 受信SMTPホスト名: MXレコードが、スパムリレーや外部のZimbra以外のサーバーを指している場合、そのサーバー名を入力します。このチェックは、ドメインのMX設定を属性zimbraInboundSmtpHostnameと比較します。この属性が設定されていない場合、ドメインのMXをzimbraSmtpHostnameと比較チェックします。

  • 信頼できるMTAネットワーク : メールをリレーしてよい信頼できるネットワークを設定します。複数のネットワークアドレスはカンマや空白で区切ります。

  • DNS が有効な場合、Zimbra のMTAは、あて先ドメインのMXレコード検索用の明示的なDNSクエリーを実行します。このオプションを使用しない場合、外部配信用のリレーMTA項目に、リレーホストを入力してください。

  • ドメイン管理者が管理コンソールからMXレコードを確認できるようにする : 有効な場合、ドメイン管理者はドメインのMXレコードをチェックできます。

Milter サーバー

  • Milterサーバーを有効にする : 有効な場合、配布リストへメール送信可能なユーザーに対するルールをMilterが強制できます。

アーカイブ機能の設定

  • アーカイブ機能をインストールした場合、ここで設定を有効化できます。

メッセージ

  • メッセージの最大サイズ(KB) : 送信できる1件あたりのメッセージと添付ファイルの最大サイズを設定できます。

    ブリーフケースにアップロードできるファイルの最大サイズの設定を設定するには、全般情報ページに遷移します。
  • メッセージにX-Originating-IPを追加X-Originating-IP ヘッダー情報で、サーバー転送されているメールメッセージの最初の送信元IPが特定できます。

ポリシーサービスの確認

  • zimbraMtaRestriction (疑わしいSMTPクライアントを拒否するためのチェック条件)をカスタマイズします。

プロトコルチェック

  • 迷惑メール対策のため、迷惑メール(UCE)を拒否します。

DNSチェック

  • 不明なクライアントIPアドレスや、不明な応答ホスト名、不明な送信者ドメインの場合にメッセージを拒否します。

  • RBLリスト : メール宛先のその他の制限を入力します。

RBL (リアルタイムブラックホールリスト) は、Zimbraのコマンドラインから有効/無効にできます。

グローバルのIMAPとPOP設定

グローバルアクセスの有効化は、IMAPページとPOPページから行ないます。

管理コンソール:

ホーム > 設定 > グローバル設定 > IMAP
ホーム > 設定 > グローバル設定 > POP

IMAPやPOPの設定を変更した場合、その反映にZimbra Collaborationを再起動する必要があります。

IMAP/POP3のポーリング間隔は提供サービスの詳細設定から指定できます。デフォルトはポーリング間隔なしです。

IMAP/POPのプロキシがセットアップされていたら、そのポート番号が正しく設定されていることを確認してください。

POP3のおかげで、ユーザーはZimbraサーバーに保存されているメッセージの検索と、新着メッセージのローカルコンピュータへのダウンロードができます。プリファレンス > メール ページにあるユーザーのPOP設定により、メッセージのダウンロード方法と保存方法が決まります。

ドメインの設定を管理する

ドメインはインストール中に1つ作成されます。インストール完了後にドメイン追加ができます。管理コンソールから以下のドメイン管理機能を使用できます。

  • グローバルのアドレス帳(GAL)

  • 認証

  • ユーザーログイン時のデフォルトドメインを確立するための、そのドメイン用の仮想ホスト

  • 共有等で使用される、REST URL用のパブリックサービスホスト名

  • そのドメイン内で作成可能な最大アカウント数

  • Microsoft Exchangeで利用するFree/Busyのインターオペラビリティ設定

  • ドメインのSSL証明書

ドメインは名称変更できるので、この場合、アカウント、配布リスト、エイリアス、リソースのアドレスの全てが新しいドメイン名に切り替わります。CLIユーティリティを使用してドメイン名称を変更します。詳細は ドメイン名を変更するを参照してください。

ドメイン設定はグローバル設定をオーバーライドします。

ドメインの全般情報を設定する

本項で説明するオプションの設定は、新しいドメイン ウィザードから行ないます。

管理コンソール:

ホーム > 2 ドメインを設定 > 1 ドメインを作成…​

Create Domain

Table 24. 新しいドメイン — 全般情報
オプション 詳細

ドメイン名 *
パブリックサーバーホスト名

REST URLのホスト名を入力します。この値はよくファイル共有で使用されます。詳細は以下の 公開サービスのホスト名を設定するを参照してください。

パブリックサービスのポート

ドロップダウンから、HTTP、HTTPSのいずれかを選択します。

パブリックサービスのポート

受信SMTPホスト名

ドメインのMXレコードが、スパムリレーや外部のZimbra以外のサーバーを指している場合、そのサーバー名を入力します。

説明

デフォルトの提供サービス

ドメインに作成されたアカウントに他の提供サービスが設定されていなければ、(そのドメインの)デフォルトの提供サービスが自動で適用されます。

ステータス

ドメインスのテータスは、通常の状態だとアクティブです。ユーザーはログインでき、メールは配信されます。このステータスを変更すると、そのドメインのアカウントのステータスにも影響が及ぶ可能性があります。ドメインのステータスは、 ドメイン > 全般情報 ページに表示されます。ドメインのステータス値は以下のとおりです。

  • アクティブ : 通常、ドメインのステータスは「アクティブ」です。アカウントを作成でき、メールは配信されます。

    アカウントのステータス設定がドメインのステータス設定と異なる場合、アカウントのステータスがドメインのステータスをオーバーライドします。
  • 閉鎖 : ドメインのステータスが「閉鎖」のとき、ドメインのアカウントはログインできず、メッセージは送信元へバウンスされます。閉鎖ステータスは個々のアカウントのステータス設定をオーバーライドします。

  • ロック :ドメインのステータスが「ロック」のとき、ドメインのアカウントはログインできませんが、メール配信はまだ続きます。アカウントのステータスが「メンテナンス」または「閉鎖」の場合、アカウントのステータスがドメインのステータスをオーバーライドします。

  • メンテナンス : ドメインのステータスが「メンテナンス」のとき、ドメインのアカウントはログインできず、メールはMTAのキューに留まります。アカウントのステータスが「閉鎖」の場合、アカウントのステータスはドメインのステータスをオーバーライドします。

  • 保留 : ドメインのステータスが「保留」のとき、ドメインのアカウントはログインできず、メールはMTAのキューに留まり、アカウントも配布リストも作成、削除、変更できません。アカウントのステータスが「閉鎖」の場合、アカウントのステータスがドメインステータスの設定をオーバーライドします。

公開サービスのホスト名を設定する

REST URL用のパブリックサービスホスト名をドメインごとに設定できます。REST URLは、メールフォルダ、ブリーフケースフォルダ、タスクリスト、アドレス帳、カレンダーの共有時に使用されます。

ユーザーがZimbra Collaboration フォルダを共有したとき、デフォルトでは次のように、Zimbraサーバーホスト名とZimbraサービスホスト名からURLが作成されます。 https://server.domain.com/service/home/username/sharedfolder

作成される属性

  • ホスト名:server.zimbraServiceHostname。

  • プロトコル:server.zimbraMailMode から決定されます。

  • ポート番号:プロトコルから算出されます。

パブリックサービスホスト名を設定すると、その名称が次のようにサーバー名とサービス名の代わりに使用されます。 https://publicservicename.domain.com/home/username/sharedfolder

使用される属性

  • zimbraPublicServiceHostname

  • zimbraPublicServiceProtocol

  • zimbraPublicServicePort

他のFQDNのDNS情報にて、Zimbraサーバーへ内部と外部で転送するように設定すると、パブリックサービスホストとして使用することができます。

グローバルアドレス帳(GAL)モードの設定

グローバルアドレス帳(GAL)は企業全体のユーザーリストのことで、メールシステムにいる全てのユーザーが、GALを参照できます。GALはメールシステムでよく使われる機能であり、ユーザーが正確なメールアドレスを覚えていなくても姓や名から他のユーザーを検索できるようにします。

GALはドメイン単位で設定されます。各ドメインのGALモード設定によって、GAL検索の対象を指定します。

グローバルアドレス帳(GAL)の定義は、ドメイン設定で GALモード設定 ツールから行ないます。

管理コンソール:

ホーム > 2 ドメインを設定 > 1 ドメインを作成…​ → GALモード設定

GAL Mode Settings

Table 25. 新しいドメイン — GALモード設定
オプション 説明

GALモード

  • 内部 : ZimbraのLDAPサーバーがディレクトリ検索に使用されます。

  • 外部 : 外部のディレクトリサーバーがGAL検索に使用されます。GAL用に外部LDAPホストを複数、設定できます。(設定、メール配信など)他のディレクトリサービスはZimbraのLDAPを使用します。外部GALモードを設定する場合、別の検索設定と同期設定を設定することができます。別の検索設定を利用する場合とは例えば、LDAPの検索を最適化するためにLDAPキャッシュサーバーをセットアップしている環境であるものの、ユーザーがGALに同期できるようにしたい場合などです。

  • 両方 : 内部と外部のディレクトリサーバーを両方がGAL検索に使用されます。

GAL検索で取得できる結果の最大件数

ユーザー検索で返されるGAL検索結果の最大件数。この値が定義されていない場合、グローバル設定で定義された値が使用されます。 デフォルト値は100。

GAL同期アカウント名*

読み取り専用。GAL同期名と紐づくドメインが表示されます。

内部GALのデータソース名

読み取り専用。内部GAL名が表示されます。

内部GALのポーリング間隔

GAL同期アカウントがLDAPサーバーと同期する頻度を日数、時間、分、秒数のいずれかで定義します。LDAPサーバーとの最初の同期時、LDAPにある全てのGAL内容がGAL同期アカウントのアドレス帳に登録されます。その後の同期は、新規作成、修正、あるいは削除された連絡先情報が更新されます。

GAL同期アカウントで、GALのアクセス速度を向上させる

GAL同期アカウントは、内部GALや外部GALの作成時、そのドメインに作成されます。複数のメールボックスサーバーを使用している環境では、メールボックスサーバーごとにGAL同期アカウントを作成することができます。GAL同期アカウントの利用により、GAL内の名称へのオートコンプリート機能が速くなります。

GAL同期アカウントがサーバーに作成されると、GALリクエストはドメインのGAL同期アカウントではなくサーバーのGAL同期アカウントを直接使用します。GalSyncResponseには、GAL同期アカウントIDと現在の変更番号を暗号化するトークンが含まれています。クライアントはこれを保存し、次回のGalSyncRequestで使用します。ユーザーは当初の同期で使用したGAL同期アカウントを使って、GAL同期を実行します。何らかの理由でGAL同期アカウントを使用できない場合は従来のLDAPベースの検索が行なわれます。

GAL同期アカウントはシステムアカウントのため、Zimbraライセンスを利用しません。

GAL同期アカウントの設定時にGALデータソースを定義します。データソースの連絡先情報がGAL同期アカウントのアドレス帳に同期されます。GALモードが*両方* の場合はアカウント内にLDAPのデータソース分、アドレス帳が作成されます。

GAL同期のGALポーリング間隔で、GAL同期アカウントがLDAPサーバーと同期する頻度が決まります。同期の間隔は日数、時間、分、秒数のいずれかです。ポーリング間隔はデータソースごとに設定します。

GAL同期アカウントがLDAPのディレクトリと同期すると、LDAPにある全てのGAL連絡先情報がそのGAL同期アカウントのアドレス帳に追加されます。同期中、アドレス帳は、新規作成、修正、あるいは削除された連絡先情報で更新されます。アドレス帳を直接修正しないでください。LDAPとGALのそのアドレス帳との同期で、直接アドレス帳に修正していた内容は削除されます。

GAL同期アカウントは管理コンソールから作成します。CLIでのこの機能は zmgsautil になります。

GAL同期アカウントを追加作成する

ZCSが複数のメールサーバーで構成されている場合、各メールサーバーにGAL同期アカウントをもう一つ追加することができます。

管理コンソール:

ホーム > 設定 > ドメイン

  1. もう一つGAL同期アカウントを追加したいドメインをダブルクリックします。

  2. 画面の右上にある ギア アイコンをクリックし、GALを設定 をクリックします。

  3. GALアカウントを追加 をクリックします。

  4. GAL同期アカウント名項目に、このアカウントの名称を入力します。デフォルト名は利用しないでください。

  5. このアカウントを適用するメールボックスサーバーを選択します。

  6. GALデータソース名 を入力します。GALモード が 「両方」の場合、内部GALと外部GALのデータソース名を両方入力します。

  7. GAL同期アカウント更新のため、LDAPサーバーと同期すべき頻度を GALのポーリング間隔 に設定します。

  8. 完了 をクリックします。

GAL同期アカウント名を変更する

GAL同期アカウントのデフォルトアカウント名は galsync です。GALモードの設定時に別の名称を指定できます。GAL同期アカウント作成が完了した後のアカウント変更はデータ同期が失敗する要因となるため実施できません。

アカウント名を変更するには、既存のGAL同期アカウントを削除し、そのドメインの新しいGALを作成します。

管理コンソール:

ホーム > 設定 > ドメイン

  1. GAL同期アカウント名を変更したいドメインをダブルクリックします。

  2. 画面の右上にある ギア アイコンの GALを設定 をクリックしてウィザードを開いたら、GALモードを「内部」に変更します。他の項目は変更しないでください。完了 をクリックします。

  3. 管理コンソールの 管理 > アカウントに遷移してドメインのアカウントペインを開き、ドメインのGAL同期アカウントを削除します。

  4. 設定 > ドメイン に再度遷移して 「GALを設定」 をクリックします。GAL同期アカウント名項目にお好みの名称を入力します。他のGAL設定項目の入力が終わったら、 完了 をクリックします。ドメインのアカウントペインに新しいGAL同期アカウントが表示されます。

認証モード

認証とは、ディレクトリサーバーへアクセスするユーザーやサーバーを識別し、ユーザーログイン時に入力されたユーザー名とパスワード情報に基づき正当なユーザーにはアクセスを認めるプロセスのことです。

認証方法はドメイン単位で設定します。

管理コンソール:

ホーム > 2 ドメインを設定 > 1 ドメインを作成…​ → 認証モード

Table 26. 新しいドメイン — 認証モード
オプション 説明

認証メカニズム

  • 内部 : 内部の認証方法は、そのドメインの認証にZimbraディレクトリサーバーを使用します。内部を選択したらそれで設定完了です。

  • 外部LDAP : ディレクトリサーバーへのバインド操作で渡されるユーザー名とパスワードが認証情報です。外部サーバーへバインドするには、LDAP URLとLDAPフィルターの指定とDNパスワードの設定が必要です。

  • 外部Active Directory : Active Directory サーバーへ渡されるユーザー名とパスワードが認証情報です。Active Directory のドメイン名とURLを指定する必要があります。

仮想ホストの使用

仮想ホストにより、サーバーに複数のドメイン名をホストすることができます。一般的なドメイン設定は変わりません。

仮想ホストを作成すると、それがユーザーログイン時のデフォルトドメイン名に使用されます。Zimbraウェブクライアントユーザーは、ユーザー名に含まれるドメイン名を入力せずにログインできるようになります。

管理コンソール:

ホーム > 2 ドメインを設定 > 1 ドメインを作成…​ → 仮想ホスト

Table 27. 新しいドメイン — 仮想ホスト
オプション 説明

仮想ホストを追加

ドメインの仮想ホストを識別するための英数字。仮想ホストにはAレコードを使用した有効なDNS設定が必要です。ドメインから仮想ホストを削除するには、ウィザード画面のホスト名の横にある 削除 ボタンをクリックします。

Zimbraのウェブクライアントのログインページを開くには、仮想ホスト名をURLとして入力します。例: https://mail.company.com.

Zimbraのログイン画面が表示されたら、ユーザー名とパスワードのみ入力します。認証リクエストが該当の仮想ホスト名のドメインを検索します。仮想ホストが見つかれば、そのドメインへの認証が完了します。

アカウント制限の設定

各ドメイン内で作成可能な最大アカウント数を制限することができます。作成可能な最大アカウント数はドメイン作成時に設定できます。ドメイン設定を編集して、この数を設定したり修正したりできます。

管理コンソールの 設定 > ドメイン > アカウント制限 ページから、この設定が可能です。このページを設定しない場合、ドメイン内アカウント数に上限はありません。

リソース、スパム、ハムのアカウントはこの数に数えません。

Zimbra Collaboration のライセンスによって定められている最大アカウント数を超えることはできません。

ドメインに複数の提供サービス(COS)がある場合、設定可能な提供サービスを選択すること、そしてその提供サービスに紐付けられるドメインアカウント数を設定することが可能です。これは、ドメインのアカウント制限ページで設定します。使用中の提供サービスアカウントタイプ数はトラッキングされます。全ての提供サービスのアカウント上限が、そのドメインの最大アカウント数を上回るようにはできません。

提供サービスに紐付けられるドメインアカウント数はトラッキングされます。アカウントの全般情報ページにて、紐付けた数とその残数が確認できます。

ドメイン名を変更する

ドメイン名の変更時は、実際に新しいドメインを作成して、その新しいドメインにすべてのアカウントを移してから、旧ドメインを削除します。すべてのアカウント、エイリアス、配布リスト、リソースのアドレスは、新しいドメイン名に変更されます。LDAPを更新すると、この変更が反映されます。

ドメイン名変更前の作業

  • 新しいドメイン名向けにDNSにMXレコードが作成されていることを確認します。

  • 完全に機能する、そのドメインのバックアップがあることを確認します。

ドメイン名変更後の作業

  • 旧ドメイン名が設定されている外部リファレンスを新しいドメイン名に更新します。これにはバックアップ完了通知など管理者のメールボックスへ送信された自動生成メールが含まれることもあります。直ちに新ドメイン名のフルバックアップを実行します。

zmprov -l rd [旧ドメイン名] [新しいドメイン名]
ドメイン名の変更プロセス

zmprov コマンドの実行により、ドメイン名変更プロセスが以下の流れで進みます。

  1. 旧ドメイン名のステータスは内部ステータス「シャットダウン」に変わり、ドメインのメールステータスは「保留」に変わります。ユーザーはログインできず、メールはMTAのキューに留まり、アカウントもカレンダーのリソースも配布リストも作成、削除、変更できません。

  2. 新しいドメインは、内部ステータス「シャットダウン」で、メールステータスは「保留」で作成されます。

  3. アカウント、カレンダーのリソース、配布リスト、エイリアス、リソースはすべて新しいドメインにコピーされます。

  4. LDAPを更新して、新しいドメインアドレスを反映します。

  5. 旧ドメインが削除されます。

  6. 新しいドメインのステータスを「アクティブ」に変更します。新しいドメインでのメッセージの受信が可能となります。

ドメインのエイリアスを追加する

ドメインのエイリアスにて、複数のドメイン名を1つのドメインアドレスへ転送することができます。例えば、使用中のドメイン名がdomain.comでも、ユーザーに@example.comのアドレスを持たせたい場合、domain.comのエイリアスドメインとしてexample.comを作成することができます。user@example.com へメール送信することは、user@domain.com にメール送信することと同じになります。

ドメインエイリアスはプライマリドメイン名と同じ、ドメイン名です。エイリアスを追加する前に、ドメインを所有し、かつ、その所有権を立証する必要があります。
管理コンソール:

ホーム > 設定 > ドメイン をアクセスし、右上の ギア アイコンより ドメインエイリアスを追加 をクリックします。

ドメインの警告サポートの有効化

警告はドメイン単位で設定します。アップグレード時はそれまでの運用を継続できるように、グローバル警告が各ドメインにあるドメイン専用の警告に自動変換されます。

各ドメインの警告サポートは以下の手順で有効化できます。

  1. 新しいドメイン(例:example.com)とアカウント(例:user2@example.com )を作成します。

    $ zmprov cd example.com cb9a4846-6df1-4c18-8044-4c1d4c21ccc5
    $ zmprov ca user2@example.com test123 95d4caf4-c474-4397-83da-aa21de792b6a
    $ zmprov -l gaa user1@example.com user2@example.com
  2. 警告の使用を有効化します。

    $ zmprov mcf zimbraDomainMandatoryMailSignatureEnabled TRUE
    $ zmprov gcf zimbraDomainMandatoryMailSignatureEnabled
    zimbraDomainMandatoryMailSignatureEnabled: TRUE
  3. 新しいドメインに警告を追加します。

    $ zmprov md example.com
    zimbraAmavisDomainDisclaimerText "text disclamer"
    zimbraAmavisDomainDisclaimerHTML "HTML disclaimer"
    
    $ zmprov gd example.com zimbraAmavisDomainDisclaimerText zimbraAmavisDomainDisclaimerHTML
    # name example.com
    zimbraAmavisDomainDisclaimerHTML: HTML disclaimer
    zimbraAmavisDomainDisclaimerText: text disclamer
    
    $ zmprov gd eng.example.com
    # name eng.example.com
    zimbraAmavisDomainDisclaimerText
    zimbraAmavisDomainDisclaimerHTML
    1. 最初のMTAにて以下を実行します。

      /opt/zimbra/libexec/zmaltermimeconfig -e example.com
      
      Enabled disclaimers for domain: example.comm
      Generating disclaimers for domain example.com.
    2. 残り全ての追加MTAにて以下を実行します。

      /opt/zimbra/libexec/zmaltermimeconfig
      • テストとして、アカウント(例:user2@example.com)から、HTML形式とテキスト形式でメール送信します。

      • 検証として、HTMLの警告メールとテキストの警告メールが正しく受信されていることを確認します。

      • ドメインexample.comを無効化する場合

        1. Zimbraユーザーで最初のMTAにて以下を実行します。

          /opt/zimbra/libexec/zmaltermimeconfig -d example.com
        2. 残りの全MTAにて以下を実行します。

          /opt/zimbra/libexec/zmaltermimeconfig

内部ドメインメールの警告を無効化する

ドメインの内部ユーザー間で送受信するメールに警告を追加しないように設定できます。

attachedzimbraAmavisOutboundDisclaimersOnlyTRUE にします。

上位互換性の保持のため、この属性はデフォルトで FALSE です。

警告の機能を無効化する

関連する属性を FALSE に設定することで、警告のサポートを完全に無効化できます。

zmprov mcf zimbraDomainMandatoryMailSignatureEnabled FALSE

ドメインにあるZimlet

ドメインの Zimlet ページに、サーバーに配備されているZimletがすべて表示されます。ドメインユーザーに全てのZimletを利用させたいわけではない場合、ドメインで使用できるZimletをリストから選択します。ドメインのZimletページで設定した値は、提供サービスやアカウントで設定されている値をオーバーライドします。

サーバーの設定を管理する

ZimbraのサーバーはZimbraのサービスパッケージが最低1つインストールされているマシンです。インストールする際、Zimbraのサーバーは自動的にLDAPサーバーへ登録されます。

管理コンソールから、Zimbraソフトを設定している全サーバーのステータスを閲覧することも既存のサーバーレコードの編集や削除することも可能です。サーバーをLDAPに直接追加することはできません。インストール時に新しいホストを登録するように設計されているZimbra Collaboration インストール用プログラムを使用して新規サーバーを追加する必要があります。

管理コンソールから、特定のサーバーに遷移したサーバー設定画面で閲覧できる情報。

  • 全般情報: サービスのホスト名、LMTP表示名、バインドアドレス、同時に実行できる予定済みタスクの最大スレッド数。

  • サービス:有効なサービスのリスト。 リスト内のサービスを有効/無効に設定できます。

  • MTA:サーバーの認証方法の有効/無効、グローバル設定と異なるウェブ メールのMTAホスト名、外部配信用のリレーMTAホスト名の指定、サーバーに対するMilterサーバーの有効/無効、Milterのバインドアドレスの指定。 必要に応じて、DNS参照の有効/無効も設定できます。

  • IMAP/POP: サーバーにPOPやIMAPの有効/無効、使用するポート番号の指定。IMAP/POPのプロキシを使用している場合、ポート番号が正常であることも確認できます。

  • ボリューム:インデックスとメッセージストアのボリューム設定およびHSMポリシーの管理。

  • IPアドレスのバインド:サーバーが複数のIPアドレスを使用している場合、IPアドレスのバインドにより、バインド先のインターフェースを指定できます。

  • プロキシ:プロキシを設定している場合、サーバーでの設定。

  • バックアップ/復元:サーバーのバックアップと復元設定。 サーバーのバックアップと復元を設定すると、グローバル設定のバックアップと復元の設定をオーバーライドします。

サーバーは、こうした値がサーバー設定で設定されていない場合、グローバル設定の値を継承します。グローバル設定から継承できる設定には、MTA、SMTP、IMAP、POP、ウィルス対策、迷惑メール対策の設定があります。

サーバーの全般情報

全般情報ページには以下の設定情報があります。

  • サーバー表示名と説明

  • サービスホスト名

  • LMTP表示名、バインドアドレス、同時に実行できる予定済みタスクの最大スレッド数。デフォルトは20スレッドです。

  • メールボックス削除間のスリープ時間:サーバーはメッセージの削除期間をスケジュール管理しています。メールボックスからメッセージの削除のスリープ期間は、グローバル設定、またはサーバー設定の全般情報で設定します。デフォルトでは、メールボックス削除を1分ごとに実行します。

リバースプロキシをインストールした場合、プロキシサーバーとバックエンドのメールボックスサーバー間の通信はすべて平文で行う必要があります。逆引きプロキシの参照ターゲットサーバ を有効にすると、以下のパラメーターの値が自動的に設定されます。

zimbraImapCleartextLoginEnabled TRUE
zimbraReverseProxyLookupTarget TRUE
zimbraPop3CleartextLoginEnabled TRUE

「備考」項目に、設定のメモなどを自由に追加・保存することができます。

サーバーのMTA設定

管理コンソール:

ホーム > 設定 > サーバー → サーバー名 → MTA

MTA ページでは以下の設定を表示します。

  • 認証:

    ユーザーが認証できるように、SMTPのクライアント認証を有効にします。認証されたユーザーまたは信頼済みのネットワークのみ、メールのリレーが許可されます。TLS認証が有効な場合、パスワードがそのまま渡されないように、すべてのSMTP認証でTransport Layer Security (SSLの後継)が強制されます。

  • ネットワーク: ウェブメールMTAホスト名、ウェブメールMTAタイムアウト、外部配信用のリレーMTA、信頼できるMTAネットワークID、サーバーのDNS参照を有効にする機能があります。

  • Milter サーバー

    Milterサーバーを有効にする にチェックが入っている場合、Milterサーバーは配布リストへ送信できる差出人を制限します。

IPアドレスのバインドを設定する

サーバーに複数のIPアドレスを使用している場合、IPアドレスのバインドを使用して特定のサーバーにバインドしたい専用IPアドレスを指定できます。

管理コンソール:

ホーム > 設定 > サーバー → サーバー → IPアドレスのバインド

Table 28. IPアドレスのバインド
オプション 詳細

ウェブクライアントサーバーのIPアドレス

HTTPサーバーが待機するインターフェースアドレス

ウェブクライアントサーバーのSSL IPアドレス

HTTPSサーバーが待機するインターフェースアドレス

ウェブクライアントサーバーのSSL Client Cert認証 IPアドレス

クライアント証明書を受け入れるHTTPSサーバーが待機するインターフェースアドレス

管理コンソールサーバーのIPアドレス

HTTPSサーバーが待機する管理コンソールインターフェースアドレス

ZCSでSSLの証明書を管理する

証明書とは、様々なホスト、クライアント、サーバー間でセキュアな通信のために使用するデジタル証明です。証明書はサイトの所有者を証明するために使います。

使用可能な証明書は自己署名証明書と商業用の証明書の2種類です。

  • 自己署名証明書 :自己署名証明書は、発行した作成者自身が署名する認証用証明書。

    証明書のインストールウィザードを使用すると、自己署名の証明書を発行できます。自己署名の証明書を使用して有効期限を変更したい場合に役に立ちます。通常、自己署名証明書はテストに使用します。
    デフォルトは1825日間(5年間)です。

  • 商業用の証明書 認証局(CA)が発行する証明書で、証明書に含まれている公開鍵は企業(サーバー)の所有者であることを証明します。

Zimbra Collaborationインストール時に自己署名証明書は自動インストールされるため、テストに使うことができます。Zimbra Collaborationサーバーを本番環境で使用する際は、商業用の証明書をインストールする必要があります。

自己証明の環境にあるZCOユーザーの場合、クライアントのWindows証明書ストアへルートCAの証明書を追加しなければ警告メッセージが表示されます。 Zimbra WikiZCO Connection Security を参照ください。

証明書をインストールする

証明書署名リクエスト(CSR)を発行するには、専用のフォームにドメイン、会社、国についての詳細を入力し、RSAの秘密キーでCSRを発行します。発行したファイルをコンピュータへ保存し、ご利用の認証局へ送信します。

商業署名入りの証明書を入手するには、管理コンソールにあるZimbraの証明書ウィザードを使用して、RSAの秘密キーと証明書署名リクエスト(CSR)を発行します。

管理コンソール:

ホーム > 1 開始 > 3. 証明書をインストール

証明書に設定するパラメーターは、下記のガイドを参照してください。

Table 29. 証明書のインストール
オプション 詳細

共通名 (CN)

ウェブサイトへのセキュアなアクセスに使用されるドメイン正式名です。 任意の共通名を使用する予定はありますか? サーバーにある単一ドメインに複数のサブドメインを一つの証明書で管理したい場合、このチェックボックスをオンにします。アスタリスク (*) が共通名フィールドに追加されます。

国名 (C)

証明書に会社の所在地として表示したい国名。

都道府県/州 (ST)

証明書に会社の所在地として表示したい都道府県/州名。

市区町村 (L)

証明書に会社の所在地として表示したい市区町村名。

組織名 (O)

社名

組織のユニット (OU)

ユニット名(あてはまる場合)

サブジェクト代替名 (SAN)

SAN(サブジェクト代替名)を使用するなら有効なドメイン名の入力が必要です。SANを使用中、ドメイン名はまず共通名と比較され、その後SANに対してマッチング検索されます。複数のSANを作ることもできます。代替名がこの項目に入力されていると、クライアントは共通名を飛ばしてサーバー名がSANのいずれかとマッチするべく検索します。

Zimbraサーバーで発行したCSRをローカルのコンピュータへダウンロードし、VeriSignやGoDaddyのような認証局へ提出します。認証局よりデジタル署名の証明書が発行されます。

認証局より証明書を受信後したら証明書インストールウィザードを再度使用し、Zimbra Collaborationへインストールします。インストール後、サーバーを再起動して証明書を有効にします。

インストール済みの証明書を確認する

現在配備されている証明書の詳細の閲覧が可能です。詳細には証明書の件名、発行者、有効日数、サブジェクト代替名が含まれます。

管理コンソール:

ホーム > 設定 > 証明書 → zmhostname

証明書には、Zimbra のLDAP、MTA、プロキシなどの様々なZimbraサービスが表示されます。

有効の証明書を維持する

証明書が失効するとZCSシステムが正常に動作しなくなる恐れがあるため、クライアントや環境の継続利用に向けて、ZCSにインストールされているSSL証明書の有効状態を保つことが重要です。配備したSSL証明書の有効日数などの情報はZCS管理コンソールから確認できます。証明書を定期的に確認して、失効日を把握し、有効状態を保つことを推奨します。

ドメインにSSLの証明書をインストールする

Zimbra CollaborationサーバーのドメインごとにSSL証明書をインストールできます。複数のドメインをサポートするには、ZimbraプロキシをZimbra Collaboration インストールし、正常に設定する必要があります。ドメインごとに、仮想ホスト名が仮想ドメイン名で、仮想IPアドレスがIPアドレスで設定されます。

ドメインごとに商業署名入りの証明書を発行する必要があります。証明書に含まれる公開鍵により、そのドメインに属することを証明します。

Zimbraプロキシ仮想ホスト名とIPアドレスの設定

zmprov md <domain> +zimbraVirtualHostName {domain.example.com} +zimbraVirtualIPAddress {1.2.3.4}
仮想ドメイン名は、Aレコードを使用した有効なDNS構成が必要です。

ドメインの証明書の編集方法

管理コンソール:

ホーム > 1 開始 > 3. 証明書をインストール

ドメイン用に発行された、署名入りの商業用の証明書と秘密キーのファイルを、選択したドメインの ドメインの証明書 セクションにコピーします。

Certificate Domain Load

  1. 最初はドメインの証明書から、次にルート証明書と中間証明書を降順でコピーします。これにより、証明書のチェーン全体を認証させることができます。

  2. 証明書を保存する前に、秘密キーのパスワードを全て削除します。

    パスワードの削除方法は、商用の証明書の提供元に確認してください。

  3. アップロード をクリックします。

    ドメイン証明書は以下に配備されます。 /opt/zimbra/conf/domaincerts

メッセージをDKIMで認証する

Domain Keys Identified Mail (DKIM) はメール受信者が検証できる方法でメッセージ配信することの責任を、配信する会社に持たせる、ドメインレベルでの認証メカニズムです。DKIMを配置している会社は、送信元サイトもしくは中間サイトです。メッセージ配信が信頼できるかものかどうかは、送信元の会社の評価がベースとなって判断されます。

外部へ送信するメッセージに DKIM電子署名を追加することで、そのメッセージを自組織のドメイン名と関連づけることができます。DKIM署名 は ZCSでホストされているドメインであれば、いくつでも有効にできます。この機能の利用のために全ドメインを DKIM署名を有効化する必要はありません。

以下を使用してDKIM のメールの認証メカニズムを定義します。

  • ドメイン名の識別子

  • 公開鍵の暗号化

  • DNSベースの公開鍵の配信サービス

DKIM 署名はメッセージのヘッダー項目に追加されます。以下はヘッダー情報の一例です。

DKIM-Signature a=rsa-sha1; q=dns;
     d=example.com;
     i=user@eng.example.com;
     s=jun2005.eng; c=relaxed/simple;
     t=1117574938; x=1118006938;
     h=from:to:subject:date;
     b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZVoG4ZHRNiYzR

迷惑メール、スプーフィング、フィッシングなどの詐欺行為を制限するプログラムの一環として、DKIM署名を検証できる受信者が署名者に関する情報を利用することができます。

Zimbra CollaborationにDKIM署名を設定する

外部送信メールのDKIM署名はドメインレベルで行われます。

DKIM 署名を設定するには、コマンドラインでzmdkimkeyutilを実行し、DKIMキーとSelector(公開鍵)を生成します。発行したSelectorをDNSサーバーへ追加します。

  1. サーバーにログインし、ZCSユーザーとして以下のコマンドを実行します。

    /opt/zimbra/libexec/zmdkimkeyutil -a -d <example.com>

    DNSサーバーへの追加が必要な、そのドメインの公開DNSレコード情報が表示されます。公開鍵のDNSレコードは、DNSサーバーへ追加する必要のある、そのドメインのDNS TXTレコードとして表示されます。

    任意: コマンドラインに -b <####> のように -b を加えると、発行する公開キーのビット数を指定できます。 -b を付けない場合、デフォルト設定は2048ビットです。

    DKIM Data added to LDAP for domain example.com with selector B534F5FC-EAF5-11E1-A25D-54A9B1B23156
    
    Public signature to enter into DNS:
    B534F5FC-EAF5-11E1-A25D-54A9B1B23156._domainkey IN TXT
    "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC+ycHjGL/mJXEVlRZnxZL/VqaN/Jk9VllvIOTkKgwLSFtVsKC69kVaUDDjb3zkpJ6qpswjjOCO+0eGJZFA4aB4BQjFBHbl97vgNnpJq1sV3QzRfHrN8X/gdhvfKSIwSDFFl3DHewKDWNcCzBkNf5wHt5ujeavz2XogL8HfeL0bTwIDAQA B" ; ----- DKIM B534F5FC-EAF5-11E1-A25D-54A9B1B23156 for example.com

    発行されたDKIMデータは、LDAPサーバーにドメインのLDAPとして保存されます。

  2. ドメインのプロバイダーにて、ドメインのDNSのDKIMのTXTレコードを更新します。

  3. DNSサーバーを再起動し、DNSレコードがサーバーから正常に返答していることを確認します。

  4. 公開鍵が秘密鍵と一致するかどうかを確認するには、 -d, -s, -x についての 識別子 テーブルの説明を参照してください。

    /opt/zimbra/common/sbin/opendkim-testkey -d <example.com> -s <0E9F184A-9577-11E1-AD0E-2A2FBBAC6BCB> -x /opt/zimbra/conf/opendkim.conf
    Table 30. 識別子
    パラメーター 説明

    -d

    ドメイン名

    -s

    Selector

    -x

    設定ファイル名

ドメインのDKIMデータを更新する

DKIMキーの更新時、新しいTXTレコードを使用してDNSサーバーをリロードする必要があります。

以前のキーで署名されたメールを継続して検証できるように、以前のテキストレコードを一定期間、DNSに保存しておくことを推奨します。

ZCS サーバーにログインし、zimbra ユーザーとして以下のコマンドを実行します。

/opt/zimbra/libexec/zmdkimkeyutil -u -d <example.com>

任意: コマンドラインに -b <####> のように -b を使用すると、発行する公開キーに使用するビット数を指定できます。 -b を追加しない場合は、公開キーの基準ビット数は2048ビットです。

  1. ドメインのプロバイダーにて、ドメインのDNSのDKIMのTXTレコードを更新します。

  2. DNSサーバーをリロードし、サーバーがDNSレコードを返していることを確認します。

  3. 公開鍵が秘密鍵と一致することを検証します。識別子テーブルの説明を参照してください。

    /opt/zimbra/common/sbin/opendkim-testkey -d <example.com> -s <0E9F184A-9577-11E1-AD0E-2A2FBBAC6BCB> -x /opt/zimbra/conf/opendkim.conf

ZCSからDKIM署名を削除する

DKIM署名をZCSから削除すると、DKIMのデータがLDAPから削除されます。新規作成したメッセージにはドメイン署名が追加されなくなります。ドメインのDKIMを削除した場合、推奨することとして、以前のテキストレコードをDNS内に一定期間残して、以前のキーで署名されたメールを引き続き検証できるようにします。 削除するには以下のコマンドを実行します。

/opt/zimbra/libexec/zmdkimkeyutil -r -d example.com

ドメインのDKIMデータを取得する

ドメイン、Selector、秘密キー、公開署名、アイデンティティに関する、保存済みのDKIM情報を確認するには、以下のコマンドを実行します。

/opt/zimbra/libexec/zmdkimkeyutil -q -d example.com

迷惑メール対策の設定を管理する

ZCS ではSpamAssassinを使用して迷惑メールを処理しています。SpamAssassinは事前に定義されたルールとBayesのデータベースを使用して、メッセージを評価します。メッセージが迷惑メールかどうかはメッセージ評価のパーセントから判断します。33%~75%でタグ付けされたメッセージは迷惑メールと判断され、ユーザーの迷惑メールのフォルダへ配信されます。75%以上でタグ付けされたメッセージはユーザーへ配信せず、削除されます。

迷惑メール対策の設定は変更できます。

管理コンソール:

ホーム > 設定 > グローバル設定 > AS/AV

Anti-Spam Settings

  1. 迷惑メール対策の項目に要件に合うパラメーターを入力します。

  2. ギア アイコンから 保存 を選択し、設定した内容を適用します。

    Table 31. 迷惑メール対策
    オプション 説明

    削除しきい値

    迷惑メールと判断され、配信されない値。
    デフォルト値は75%

    タグ付けしきい値

    迷惑メールと判断され、迷惑メールフォルダに配信される値。
    デフォルト値は33%

    件名のプレフィックス

    スパムとしてタグ付けされたメッセージの件名に追加する文字列。

メッセージが迷惑メールとしてタグ付けされた場合、そのメッセージは受信者の迷惑メールフォルダへ配信されます。迷惑メールフォルダに格納された未読メッセージ数の確認や、迷惑メールフォルダを開いて迷惑メールとしてタグ付けされたメッセージをレビューすることができます。迷惑メールの学習フィルターを有効にしている場合、メッセージを迷惑メールのフォルダに追加または削除すると、この操作が迷惑メールのフィルターを学習させることになります。

また、SpamAssassinにおけるRBL (Real time black-hole lists) をZimbra のコマンドラインから有効または無効にすることができます。

迷惑メール対策の学習フィルター

迷惑メールの自動学習フィルターはデフォルトで有効にしています。次の2つのフィードバック用メールボックスが学習フィルター用に自動作成されます。

  • 迷惑メール(スパム)を学習ユーザー: 迷惑メールとしてタグ付けされなかったが、迷惑メールとすべきメッセージを学習する。

  • 迷惑メールではない(ハム)を学習するユーザー: 迷惑メールとしてタグ付けされたものの、そうすべきでなかったメッセージを学習する。

こうした学習アカウントに対して、メールボックス容量制限と添付ファイルのインデックスは無効にされています。無効にすることで、メールボックスの容量がいっぱいになってメッセージがバウンスされることを防ぎます。

何を迷惑メールと捕らえるかによって、迷惑フィルターの良好さは変わります。ユーザーがメッセージを迷惑メールのフォルダへ移動したり、迷惑メールのフォルダから別のフォルダへメッセージを移動することは、メッセージを迷惑メールとして新たにタグ付けすることになり、それがSpamAssassinフィルターの学習になります。こうしてタグ付けされたメッセージは、適切な迷惑メール学習メールボックスへと送信されます。

ZCSがインストールされたとき、最初のMTAにのみ迷惑メールのスパム/ハムをクリーンアップするフィルターが構成されます。 ZCS迷惑メールの学習ツール(zmtrainsa)は、自動的にスパムとハムのメッセージを収集し、迷惑メールフィルターを学習します。なお、zmtrainsa のスクリプトはcrontabのジョブとして設定し、メッセージをSpamAssassinへ配信し、迷惑メッセージの内容および迷惑メッセージではない内容からキーワードなどを収集し、迷惑フィルターを学習させます。zmtrainsaのスクリプト は毎日に実行し、学習が終了するとスパムとハムのメールボックスを空にします。

新たにインストールした ZCSでは、 最初にインストールされたMTAへのスパム/ハム学習に制限されます。このMTAをアンインストール、あるいは移動した場合、別のMTAでスパム/ハム学習を有効にする必要がでてきます。 `zmtrainsa --cleanup`を実行するために、ホストでこれを有効化しているはずだからです。

新しいMTAサーバー上で設定するには以下のコマンドを実行します。

zmlocalconfig -e zmtrainsa_cleanup_host=TRUE

スパムの学習メールボックスを無効にする

ZCS の既定設定では、全てのユーザーでメッセージを迷惑メールフォルダに移動することによって迷惑メールのフィルター学習に利用されます。

ユーザーに迷惑メールのフィルター学習をさせたくない場合、この機能を無効化できます。

  1. グローバル設定の ZimbraSpamIsSpamAccountZimbraSpamIsNotSpamAccount を編集します。

  2. 指定した属性からメールアドレスを空欄(削除)に設定します。

    zmprov mcf ZimbraSpamIsSpamAccount ''
    zmprov mcf ZimbraSpamIsNotSpamAccount ''

上記の属性が空欄時、迷惑メールあるいは迷惑メールではないとしてタグ付けしたメッセージは、迷惑メールの学習用メールボックスにコピーされません。

スパムフィルターを手動で学習する

迷惑と非迷惑のトークン、キーワード、文字、短い文字列を迷惑メールのフィルターにあらかじめ学習させたい場合、メッセージをマニュアル操作でmessage/rfc822の添付ファイルとして迷惑メールと非迷惑メールの学習メールボックスに転送します。

zmtrainsa の実行時、こうしたメッセージが迷惑メールのフィルター学習に使用されます。精度の高いスコアを達成するために、サンプルメッセージが充分であることを確認してください。メッセージを迷惑メールとしてタグ付けするための判断には、迷惑メールと非迷惑メッセージがそれぞれ最低でも200通必要です。

エイリアスのドメインへのバックスキャッタスパムメッセージ受信を防ぐ

バックスキャッタの迷惑メッセージを減らす目的で、エイリアスドメイン宛の RCPT To: の内容を検証するZimbra アクセスポリシーデーモンを実行するサービスを実行することができます。

ドメインエイリアスの作成の詳細は、 Zimbra wikiManaging Domainsの記事を参照してください。
  1. Postfixのローカル設定キーを指定します。

    zmlocalconfig -e postfix_enable_smtpd_policyd=yes
  2. MTAの制約を定義します。

    zmprov mcf +zimbraMtaRestriction "check_policy_service unix:private/policy"

postfix_policy_time_limit キーを設定している理由は、デフォルトでは、Postfix spawn(8)デーモンはPostfixの子プロセスを開始の1000秒後に自動でKILLするためです。これは、SMTPクライアントがSMTPプロセスと接続している限り実行し続け得るポリシーデーモンにとっては短い時間です。

Postfixのポリシーデーモンを無効にする

SMTPDポリシーを無効にします。

zmlocalconfig -e postfix_enable_smtpd_policyd=no
管理コンソール:

ホーム > 設定 > グローバル設定 > MTA

ポリシーの制約を定義します。メール受信者のRBLリストとRHSBLのリストのオン・オフをこのMTAページで切り替えることができます。

プロトコルチェックで、以下3つのRBLを有効にできます。

  • tname

  • クライアントは、完全修飾ドメイン形式 (FQDN) のホスト名で接続グリーティングしなければならない - reject_non_fqdn_hostname

  • 差出人のアドレスは、完全修飾ドメイン形式(FQDN)を使用しなければならない - reject_non_fqdn_sender

  • グリーディングでのホスト名がRFCに反する - reject_invalid_host

zmprov mcf -zimbraMtaRestriction "check_policy_service unix:private/policy"

以下のRBLの設定も可能です。

  • reject_rbl_client cbl.abuseat.org

  • reject_rbl_client bl.spamcop.net

  • reject_rbl_client dnsbl.sorbs.net

  • reject_rbl_client sbl.spamhaus.org

受信者制限の一環として、 reject_rbl_client <rbl hostname> オプションも使用可能です。

管理コンソール:

ホーム > 設定 > グローバル設定 > MTA → DNS チェック

MTA設定にあるDNSツールを使用して、制限リストを定義します。

DNS Checks

最新のRBLリストは Comparison of DNS blacklists(DNSブラックリストの比較) の記事を参照してください。

コマンドラインでRBLを追加する

  1. 現在設定されているRBLを確認します。

    zmprov gacf zimbraMtaRestriction
  2. 新しいRBLタイプを追加します:1つのコマンドに、既存のRBLと新しいRBLを入力します。単語が分かれるRBL名は、入力時にクォーテションで括ってください。

    zmprov mcf zimbraMtaRestriction [RBL type]
Example 6. 例:全ての制限を追加する場合:
zmprov mcf \
 zimbraMtaRestriction reject_invalid_hostname \
 zimbraMtaRestriction reject_non-fqdn_hostname \
 zimbraMtaRestriction reject_non_fqdn_sender \
 zimbraMtaRestriction "reject_rbl_client cbl.abuseat.org" \
 zimbraMtaRestriction "reject_rbl_client bl.spamcop.net" \
 zimbraMtaRestriction "reject_rbl_client dnsbl.sorbs.net" \
 zimbraMtaRestriction "reject_rbl_client sbl.spamhaus.org"

ホワイトリストと迷惑メールとしてタグ付けされたメッセージに関するグローバルルール

ZCSでメッセージを受け取る前段階でサードパーティ製アプリケーションの迷惑フィルターを使用している場合、サードパーティの仕様で迷惑メッセージとしてタグ付けされたメッセージは全て迷惑メールのフォルダへ送信されるというのが、ZCSのグローバルルールです。メッセージの宛先がホワイトリストに登録されていても、迷惑メッセージとしてタグ付けされた場合は迷惑メールのフォルダへ移動されます。

ホワイトリストとして識別したメッセージを迷惑メールのフォルダへ送信したくない場合、 ユーザーのメールボックスに送信するために、 zimbraSpamWhitelistHeaderzimbraSpamWhitelistHeaderValue を設定する必要があります。このグローバルルールは、ZCSのMTA迷惑メールフィルタールールとは無関係です。メッセージは依然としてユーザーのフィルタールールを通過します。

ホワイトリストのヘッダーを検索

zmprov mcf zimbraSpamWhitelistHeader <X-Whitelist-Flag>

値を設定

zmprov mcf zimbraSpamWhitelistHeaderValue <value_of_third-party_white-lists_messages>

ウイルス対策の設定

Zimbraがインストールされている各サーバーで、ウイルス対策機能は有効です。ウイルス対策機能は、ウィルスがあると判別されたメッセージを隔離用メールボックスに送信するように設定されています。受信者にはメール通知にて、ウイルスによりメッセージが隔離されたことが知らせます。隔離されたメッセージの保持期間は7日間です。

管理コンソールから、システム内でフィルタリング対象としたい迷惑メールを指定することができます。

管理コンソール:

ホーム > 設定 > グローバル設定 > AS/AV

AS/AV

  1. ウイルス対策の項目に、要件に合うパラメーターを入力します。

  2. ギア アイコンから 保存 を選択します。

Table 32. ウイルス対策
オプション 説明

定義更新頻度

Zimbra MTAはデフォルトで、ClamAVのウィルス対策の更新を2時間おきにチェックします。この頻度は1時間から24時間の間で設定可能です。

暗号化されたアーカイブをブロック

パスワードで保護されたzipファイルなど、暗号化されたアーカイブはブロックされます。

受信者に通知を送信

ウイルス隔離のため、メッセージ配信が中止されたことをメールで警告します。

Zimbra Collaboration インストール中に、警告の通知先となる管理者メールアドレスを設定します。デフォルトは、管理者アカウントがウイルス対策の警告メッセージを受け取るように設定されています。ウイルスが発見されると、このメールアドレスへ自動的に通知されます。

更新はHTTP通信経由でClamAVのウェブサイトから取得します。

ZimbraのFree/Busyカレンダー予約機能

Free/Busy機能では、効率的な会議のスケジューリングのために、ユーザーが互いのカレンダーを確認できます。ZCSとMicrosoft ExchangeのサーバーをまたいでFree/Busy機能のセットアップができます。

ZCSがMicrosoft Exchange 2003、2007、2010版のサーバーへユーザーのFree/Busyスケジュールを問い合わせることができ、さらに、ZCSユーザーのFree/BusyスケジュールをExchangeサーバーに展開することも可能です。

Free/Busyのインターオペラビリティを確立するには、Exchangeのシステムを以下のExchangeセットアップ条件に記載されているとおりに設定し、そして、Zimbra Collaborationのグローバル設定、ドメイン設定、提供サービス設定、アカウント設定を設定する必要があります。Zimbra Collaborationの設定は管理コンソールから行なうのが最も簡単です。

Exchange 2003/2007/2010でのセットアップ条件

Free/Busy機能のセットアップには、以下が必要です。

  • システムに一つのActive Directory (AD)が存在する、またはグローバルカタログが使用可能であること。

  • Zimbra Collaborationサーバーが最低1つのExchangeサーバーのIIS用HTTP(S)ポートに接続可能であること。

  • Exchange公開フォルダへのウェブUIがIISで取得可能であること。(http://server/public/)

  • Zimbra Collaboration のユーザーが、Active Directory内で、メールドメインごとに同一の管理グループを使用して、連絡先として登録されること。これは、ExchangeへのFree/Busyレプリカ運用を行なうZCS の場合にのみ必要です。

  • Zimbra Collaboration からExchangeへのFree/Busyレプリカ運用を行なう場合、すべてのZimbra Collaboration ユーザーのアカウント属性の zimbraForeignPrincipal にExchangeユーザーのメールアドレスがプロビジョンされること。

Zimbra CollaborationにFree/Busyを設定する

Free/Busyのインターオペラビリティを管理コンソールで設定するには、グローバル設定、ドメイン、提供サービス、アカウントの設定を以下のように設定する必要があります。

  • グローバルまたはドメイン単位でExchangeサーバーの設定を設定します。

    • Microsoft Exchange サーバーURL:Exchange へのウェブ UI

    • Microsoft Exchange 認証スキーマ: ベーシック または フォーム

      • ベーシックは、HTTPベーシック認証を経由したExchangeへの認証です。

      • フォームは、HTMLフォームに基づく認証としたExchangeへの認証です。

    • Microsoft Exchange サーバータイプ: WebDav または ews

      • Exchange 2003や2007にFree/Busyを使用する場合、WebDAVを選択します。

      • Exchange 2010、SP1にFree/Busyを使用する場合、ews (Exchange Web Service) を選択します。

  • Microsoft Exchangeユーザー名とパスワードを入れます。Microsoft公開フォルダにアクセスできる、Active Directory内のアカウント名とパスワードです。RESTやWebDAVインタフェースで、Exchangeサーバーを認証するのに使用します。

  • グローバル設定のFree/Busyイントラページ、ドメインのFree/Busyイントラページ、あるいは提供サービス(COS)の詳細設定ページから、Exchange用に legacyExchangeDN 属性で使用される oou 値を追加します。グローバル設定から追加すると、Exchangeに接続するアカウントすべてに適用されます。

  • アカウントのFree/Busyインターオプページから、アカウントの外部プリンシパルメールアドレスを設定します。これにより、Zimbra CollaborationアカウントとAD内の該当オブジェクトとのマッピングがセットアップされます。

これらの設定をExchangeサーバーで確認するには、Exchange のADSI Editツールを使用し、 o= , ou= , cn= 設定の legacyExchangeDN 属性を検索します。

Zimbra Collaboration と Zimbra Collaboration 間のFree/Busyインターオペラビリティ

ZCS サーバー間に、Free/Busyインターオペラビリティをセットアップできます。Free/Busyのインターオペラビリティは各サーバーに設定します。

各サーバーは ZCS 8.0.x 以降を使用している必要があります。
  1. サーバーのホスト名とポートを入力します。

    zmprov mcf zimbraFreebusyExternalZimbraURL http[s]://[user:pass@]host:port

    user:pass を指定しない場合、サーバーは名無しでfree/busyを検索します。

  2. サーバーを再起動します。

    zmcontrol restart
  3. 全てのサーバーに上記の手順1と2を実行します。

S/MIMEを設定する

S/MIMEはセキュアなメールメッセージを送信するためのスタンダードの1つです。S/MIMEのメッセージは、認証とメッセージの暗号化にデジタル署名を使用します。

現在S/MIME機能は、2種類の方法で実現可能です。

  1. クライアントマシンにJava 1.6 SEがデプロイされている必要のある、古いクライアントベースのソリューション。

  2. クライアントマシンにJavaの必要のない、新しいサーバーベースのソリューション。サーバーは全ての暗号化処理を行ないます(推奨)。

クライアントベースのソリューションを使用して、S/MIME機能が利用できるようにセットアップする

前提条件
  • ユーザーがS/MIMEを利用するには、PKI証明書と秘密キーがなければなりません。利用しているWindowsやApple Mac端末内の証明書ストアへ秘密キーをインストールする必要があります。Firefoxブラウザを使用する場合はブラウザの証明書ストアへインストールします。証明書のインストール方法は、コンピュータやブラウザの該当資料を参照してください。

  • S/MIMEが利用できるブラウザ

    • Mozilla Firefox 4 以降

    • Internet Explorer 8, 9

    • Chrome 12 以降

  • S/MIMEを利用するには、端末にJava 1.6 SEがデプロイされていなければなりません。されてない場合、催促のエラーが表示されます。

S/MIME のライセンス

S/MIMEの機能を有効にする ZCS ライセンスが必要です。

S/MIMEの機能を有効にする
管理コンソール:

ホーム > 設定 > 提供サービス → COS名 → 機能
ホーム > 管理 > アカウント → アカウント名 → 機能

S/MIME機能は、提供サービス(COS)、または各アカウントの機能ページにて有効にすることが出来ます。

  1. 編集したい 提供サービスまたはアカウントを選択します。

  2. 「機能」タブにある S/MIMEを有効にする にチェックを入れます。

  3. 画面の右上の 保存 をクリックします。

S/MIMEの証明書をインポートする

ユーザーが宛先の公開鍵証明書を次の場所に保存している場合、そのユーザーは暗号化したメッセージをその宛先に送信できます。

  • ユーザーのアドレス帳にある宛先の連絡先情報

  • 使用しているOSやブラウザのキーストア

  • 外部LDAPのディレクトリ

証明書をLDAPディレクトリに公開して、GALから証明書が検索・取得できるようにします。S/MIMEの証明書のフォーマットは、X.509 Base64エンコードDERを使用します。

証明書を検索できるように外部LDAPを設定する

証明書を保管するために外部LDAPを利用する場合、クライアントではなく外部LDAPに対して証明書の検索・取得をするように、Zimbra サーバーを設定することができます。

管理コンソール:

ホーム > 設定 > グローバル設定 > S/MIME
ホーム > 設定 > ドメイン → ドメイン名 → S/MIME

外部LDAPのサーバー設定は、 設定→グローバル設定→S/MIME設定→ドメイン→S/MIME の遷移先で、設定できます。

グローバル設定は、ドメイン設定にオーバーライドします。
  1. 「設定→グローバル設定」ページを編集、または「設定→ドメイン」で編集したいドメインを選択します。 S/MIME タブを開きます。

  2. 設定名 に、外部LDAPサーバーを識別するための名称を入力します。 例) companyLDAP_1

  3. LDAP URL に、LDAPサーバーのURLを入力します。 例) ldap://host.domain:3268

  4. DNを使って外部サーバーへバインドする場合、 S/MIME LDAPバインドDN にバインドDNを入力します。 例) administrator@domain

    匿名バインドを使用する場合、バインドDN項目とバインドパスワード項目を空白のままにします。

  5. S/MIME LDAP検索ベース 項目に、証明書を探すために検索される、LDAPサーバーの特定のブランチを入力します。

    例) ou=Common Users, DC=host, DC=domain

    あるいは、検索ベースのDNが自動で見つかるように、 検索ベースを自動的に検索 にチェックを入れます。これには、S/MIME LDAP検索ベース項目を空にしておく必要があります。

  6. S/MIME LDAPフィルター 項目に、検索用フィルターテンプレートを入力します。このフィルターテンプレートには、次の変換用変数を入れることができます。

    • %n - @ を含む検索キー(または、@を何も指定しなかったら@を含まない検索キー。)

    • %u - @を取り除いた検索キー(例えば、mail=%n)

  7. S/MIME LDAP属性 項目に、ユーザーのS/MIME証明書を入れる外部LDAPサーバー内の属性を入力します。属性が複数の場合はカンマで区切ります。

    例) "userSMIMECertificate, UserCertificate"

  8. 画面右上の 保存 をクリックします。

他の外部LDAPサーバーを追加する場合、 設定を追加 をクリックします。

サーバーベースのソリューションを使用して、S/MIME機能の利用をセットアップする

前提条件

クライアントベースのS/MIMEソリューションと同様。ただし、クライアントマシンにJavaは必要ありません。秘密キーをクライアントマシンのローカル/ブラウザの証明書ストアに格納する必要もありません。

S/MIMEのライセンス

クライアントベースのS/MIMEソリューションと同様。

S/MIMEの機能を有効にする

クライアントベースのS/MIMEソリューションと同様。

S/MIMEの証明書をインポートする

クライアントベースのS/MIMEソリューションと同様。ただし、宛先の公開鍵証明書をローカルOSやブラウザのキーストアに保存する必要はありません。この証明書は、前回のS/MIMEバージョンで明記されている、他の場所全てに公開することができます。

サーバーベースのS/MIMEソリューションのサポートのために入力されるLDAP属性の一覧
  1. zimbraSmimeOCSPEnabled

    • ユーザーと公開証明書の検証時、サーバーが使用します。

    • TRUEの場合、証明書の検証中に失効チェックが行なわれます。

    • FALSEの場合、証明書の検証中に失効チェックは行なわれません。

  2. zimbraSmimePublicCertificateExtensions

    • サポートされている、公開証明書ファイルの拡張子。カンマ区切り。

    • サポートされている、userCertificate LDAP 属性の形式一覧が入ります。

    • デフォルト値: cer,crt,der,spc,p7b,p7r,sst,sto,pem

    • Zimbraウェブクライアントは、サーバーからアップロードされた公開証明書について、このサポートされた形式/拡張子を検索します。

  3. zimbraSmimeUserCertificateExtensions

    • サポートされている、公開証明書ファイルの拡張子。カンマ区切り。

    • サポートされている、userSmimeCertificate LDAP 属性の形式一覧が入ります。

    • デフォルト値: p12,pfx

    • Zimbraウェブクライアントは、サーバーからアップロードされたユーザー証明書について、このサポートされた形式/拡張子を検索します。

S/MIMEのメールボックス トラストストアにCA証明書を追加する処理

S/MIMEは、localconfig.xml内で定義されているメールボックス トラストストアパスとパスワードを使用します。

キー名称は次のとおりです。

  • mailboxd_truststore

  • mailboxd_truststore_password

mailboxd_truststoreキーがlocalconfig.xml内に定義されていない場合、デフォルトで、mailboxd_truststoreの値は以下になります。

  • <zimbra_java_home>/jre/lib/security/cacerts

メールボックス トラストストアにCA証明書は、下記コマンドを実行してインポートできます。

keytool -import -alias -keystore <mailboxd_truststore path> -trustcacerts -file <CA_Cert>

容量管理

保存容量ボリュームの管理

ボリュームページから、Zimbraのメールボックスサーバー内のストレージボリュームを管理できます。 Zimbra Collaboration インストール時、各メールボックスサーバーにインデックスボリュームとメッセージボリュームが1つずつ設定されます。 新規ボリュームの追加、ボリューム種類の設定、圧縮のしきい値の設定が可能です。

「Blobを圧縮」が有効の場合、使用中ディスク容量は減りますが、サーバーのメモリー需要は増加します。
インデックスボリューム

Zimbraの各メールボックスサーバーに「現在のインデックスボリューム」が設定されています。各メールボックスは「現在のインデックスボリューム」にある恒久ディレクトリに割り当てられます。アカウントの割り当て先ボリュームの変更はできません。

ボリューム容量がいっぱいになったら、新しい「現在のインデックスボリューム」を作成して、新規のアカウントに備えることができます。新規ボリュームの追加、ボリューム種類の設定、圧縮のしきい値の設定が可能です。

「現在の」インデックスボリュームとしてタグ付けされていないボリュームも、割り当てされたアカウントについて継続使用されています。メールボックスからインデックスボリュームとして参照されるボリュームを削除することはできません。

メッセージボリューム

新規メッセージの作成時や配信時に、メッセージは現在のメッセージボリュームに保存されます。メッセージボリュームは複数作成できますが、新規メッセージが格納される「現在のボリューム」は1つしか設定できません。ボリューム容量がいっぱいになったら、新しい「現在の」メッセージボリュームを設定できます。「現在の」メッセージボリュームはすべての新規メッセージを受け取ります。新規メッセージが以前のボリュームに保存されることはありません。

「現在の」ボリュームを削除することはできませんし、メッセージが参照しているボリュームを削除することもできません。

階層型ストレージ管理を設置する (*)

*Zimbra 8.8 より、本機能は2つの異なるバージョンを提供しています。Zimbra 8.8 はスタンダード版と新世代(NG)版を提供しています。Zimbra 8.7 またはそれ以前のバージョンは、スタンダード版のみを提供しています。以下にスタンダード版の詳細を記載しています。Zimbra 8.8 で本機能の NG版を利用する方法につきましては、本ガイドの NG版専用チャプターをご参照ください。

階層型ストレージ管理(HSM:Hierarchical Storage Management) では、古いメッセージ用のストレージボリュームを設定できます。HSMとは、データの経過年数に基づいて、プライマリボリュームから現在のセカンダリボリュームに古いデータを移動させる処理です。

ディスク利用を管理するために、グローバルなHSMポリシーやメールボックスサーバーごとのHSMポリシーを設定します。個々のサーバーに設定されたポリシーはグローバルポリシーとして設定されたポリシーにオーバーライドします。

メールのメッセージやその他のアカウント内アイテムは、HSMポリシーに基づいて、プライマリボリュームからセカンダリボリュームに移されます。ユーザーが移動されたメッセージやアイテムを開くとき、何ら変わりはないため、移動に気づくことはありません。

デフォルトのグローバルHSMポリシーでは30日以上経過したメッセージとドキュメントファイルをセカンダリボリュームへ移します。タスク、予定、連絡先も移動する選択をすることもできます。日数、月数、週数、時間、分で指定した経過期間を過ぎたアイテムを移動するスケジュールも設定できます。

移動するアイテムを選択できる上、検索クエリー言語を使用したHSMポリシーの追加も可能です。

例えば、迷惑メールとしてタグ付けされたメッセージすべてを現在のセカンダリボリュームへ移動する場合、message:in:junk before:-[x] days をポリシーに追加します。

検索文字列をデフォルトのポリシーに追加することも、新しいポリシーを作成することもできます。
HSMのセッションをスケジューリングする

セカンダリボリュームにメッセージを移動するセッションは、サーバーOSのcronテーブルにスケジューリングされています。管理コンソールからサーバーを選択後、ボリュームページにて、新しいHSMセッションをマニュアル操作で開始したり、HSMセッションを監視したり、実行中のHSMセッションを強制終了したりできます。

サーバーの ギア アイコンメニューからHSMセッションをマニュアル操作で開始することができます。

マニュアルでセッションを強制終了し、処理を再起動すると、HSMセッションがHSMの経過ポリシー条件に一致するエントリをプライマリストアから検索します。前回実行時に移動されたエントリはすでにプライマリストアに存在していないため、対象外になります。

HSMジョブを特定のバッチサイズになるように設定することができます。 zimbraHsmBatchSize の属性は、HSMのシングルオペレーションで移動できる最大アイテム件数をグローバルに、あるいはサーバーごとに設定できます。 デフォルトのバッチサイズは10,000です。上限を超える場合、すべての対象アイテムが移動されるまで、HSM処理が繰り返されます。

グローバルなバッチサイズの変更

zmprov mcf zimbraHsmBatchSize <num>

サーバーに対するバッチサイズの修正

zmprov ms `zmhostname` zimbraHsmBatchSize <num>

メール保持ポリシーの管理

ユーザーアカウントのメールメッセージ、ゴミ箱、迷惑メールフォルダに対する保持ポリシーを設定できます。基本となるメール保持ポリシーは、提供サービスや個々のアカウントの設定で、メールメッセージ、ゴミ箱、迷惑メールの保持期間を設定することです。

ユーザーがアカウントにある受信トレイやその他のメールフォルダに保持ポリシーを利用することも可能です。ユーザーも独自の保持ポリシーを作成できます。

Zimbra では、ゴミ箱から削除されたメッセージを保存しておくゴミ箱フォルダ機能を有効にできます。有効なとき、メールの保持期間ルールや廃棄ポリシーに基づく保持期間を過ぎたメッセージが、サーバー内のゴミ箱フォルダへ移されます。ユーザーは 完全に削除されるまでにゴミ箱内に保持される有効期間 で設定されたしきい値までであれば、ゴミ箱フォルダから削除したメッセージを復元できます。

ゴミ箱フォルダ機能が無効な場合は、メールの保持期間が過ぎるとメッセージはサーバーから完全に削除されます。

メッセージの削除を禁止するための訴訟ホールド(Legal Hold)をアカウントに設定することも可能です。

メッセージの有効期間

提供サービスや個々のアカウントの設定で、アカウントのフォルダ、ゴミ箱、迷惑メールフォルダからメールメッセージを自動削除する時期を設定できます。

Table 33. メール有効期間オプション
機能 詳細

メールメッセージの有効期間

RSSフォルダのデータも含め、フォルダ内のメッセージが自動的に消去されるまでの日数。
デフォルトは 0。
最低日数は30日です。

ゴミ箱のメッセージの有効期間

ゴミ箱へ移動したメッセージが完全に削除されるまでの日数。
デフォルトは30日です。

迷惑メールメッセージの有効期間

迷惑メールフォルダへ移動したメッセージが完全に削除されるまでの日数。
デフォルトは30日です。

メールメッセージの完全削除

基準の設定では、サーバーが1分ごとに有効期限を切れたメッセージを自動的に削除します。メールボックス削除のスリープ時間間隔を変更することができます。

メールボックス削除のスリープ時間間隔を分単位でグローバルに定義することが可能です。

管理コンソール:

ホーム > 設定 > グローバル設定 > 全般情報

Purge Interval

例えば、メールボックス削除のスリープ時間間隔を1分に設定している場合、サーバーはMailbox1から期限切れのメッセージを削除後、Mailbox2の期限切れのメッセージを削除するまでに1分間待機します。

メールボックス削除のスリープ時間間隔を「0」に設定していると、メール、ゴミ箱、迷惑メールのメッセージ有効期限が設定されていても、メッセージは自動削除されません。

ユーザーはメッセージ保持設定を閲覧できないため、メッセージの自動削除ポリシーを設定したら、ユーザーにお知らせください。

メッセージの保持ポリシーと廃棄ポリシーを設定する

保持ポリシーや廃棄ポリシーは、グローバル設定あるいは提供サービスの設定として設定することができます。ユーザーはこうしたポリシーを自分のアカウント内のフォルダに自由に選択・適用できます。 ユーザー独自の保持ポリシーや削除ポリシーを作成することも可能です。ユーザーはフォルダのプロパティの編集ダイアログから、管理者がセットアップしたポリシーの有効化や独自のポリシーの作成を行なうことができます。

グローバルな保持ポリシー

システムワイドな保持ポリシーや廃棄ポリシーを管理コンソールから管理できます。

保持ポリシーページを使用して、グローバルな保持ポリシーや廃棄ポリシーを管理します。

管理コンソール:

ホーム > 設定 > グローバル設定 > 保持ポリシー

Global Retention Policy

提供サービス用の保持ポリシー

選択した提供サービスの保持ポリシーページを使用して、その提供サービスの保持ポリシーや廃棄ポリシーを管理します。

管理コンソール:

ホーム > 設定 > 提供サービス → 提供サービス名 → 保持ポリシー

COS Retention Policy

提供サービス用の保持や廃棄ポリシーを使用する場合、 グローバル設定で定義されたポリシーを引き継がずにCOSレベルのポリシーを有効化します。 のチェックボックスがオンである必要があります。

保持ポリシーは、フォルダへ強制的に自動適用されません。フォルダの保持ポリシーの期限を超えていないアイテムをマニュアル操作で削除する場合、以下の警告メッセージが表示されます。
フォルダの保持期間内にあるメッセージを削除しています。 メッセージを削除しますか?

廃棄ポリシーのメッセージ有効期限が切れると、アイテムはアカウントから削除されます。このとき、ユーザーのゴミ箱フォルダには移されません。ゴミ箱フォルダ機能が有効であれば、サーバー内のゴミ箱フォルダへ移されます。そうでなければ、メッセージはサーバーから完全に削除されます。

メッセージの有効期間が保持/廃棄ポリシーと共に機能する方法

メッセージの有効期限がゼロ(0)以外の値であれば、フォルダに適用している保持ポリシーや廃棄ポリシーに加え、以下の設定が適用されます。

メッセージ有効期間が120日に設定されているとき

  • フォルダAに360日間のカスタム廃棄ポリシーがあるとき、120日間後にフォルダAのメッセージが削除されます。

  • フォルダBに90日間のカスタム廃棄ポリシーがあるとき、90日間後にフォルダBのメッセージが削除されます。

  • フォルダCに150日間のカスタム保持ポリシーがあるとき、120日間後にフォルダCのメッセージが削除されます。

ゴミ箱フォルダを管理する

ゴミ箱フォルダ機能が有効であれば、メッセージ、ゴミ箱、または迷惑メールの有効期間が切れると、メッセージはサーバー内のゴミ箱フォルダに移されます。ユーザーはZCS上のゴミ箱を右クリックし、 削除された項目を復元 を選択することで、X日の間に削除したメッセージを復元することができます。このしきい値は エンドユーザーがゴミ箱の内容を表示できる有効期間 の設定に基づいています。

完全に削除されるまでにゴミ箱内に保持される有効期間 で、ゴミ箱フォルダのメッセージ保持期間を設定します。保持期間より古いゴミ箱フォルダ内のアイテムは、完全に削除され、復元できません。

管理者は、ゴミ箱フォルダの中身(迷惑メールを含む)にアクセスでき、メッセージの保持期間が切れる前に強制削除することもできます。

ゴミ箱フォルダにあるアイテムを検索する
zmmailbox -z -m <user@example.com> search --dumpster -l <#> --types <message,contact,document> <search-field>

「Search-field」は、期間 'before:mm/dd/yyyy and after:mm/dd/yyyy' でも、特定の人物へのメール 'to: Joe' または特定の人物から 'from: Joe' のメールでも可能です。

ゴミ箱フォルダからアイテムを削除する

ゴミ箱フォルダにあるアイテムは、CLIや管理コンソールから削除できます。

zmmailbox -z -m <user@example.com> -A dumpsterDeleteItem <item-ids>
管理コンソール:

ホーム > 設定 > 提供サービス → 提供サービス名 → 機能 → 全般的な機能

  1. ゴミ箱フォルダ にチェックを入れて、有効にします。

  2. エンドユーザーがゴミ箱の内容を表示できる有効期間 を設定するには、提供サービス名の 詳細設定タイムアウトポリシーセクション に遷移します。

  3. 完全に削除されるまでにゴミ箱内に保持される有効期間 を設定するには、提供サービス名の 詳細設定メール保持ポリシー セクションに遷移します。

アカウントに訴訟ホールドを設定する

ゴミ箱フォルダ機能が有効であれば、ユーザーアカウント内のアイテムをすべて保管する訴訟ホールド(Legal Hold)の設定が可能です。

ゴミ箱フォルダ機能を有効にしたとき、 ゴミ箱フォルダの完全な削除が可能 となる機能も自動で有効化されます。 無効にすることで、ユーザーのゴミ箱フォルダのアイテムを削除する機能が停止します。提供サービスや個々のアカウントの設定で、この値を設定できます。 ゴミ箱フォルダの完全な削除が可能 が有効なとき、アカウント内のフォルダに設定した全ての削除ポリシーが無視されます。

訴訟ホールドの設定

管理コンソール:

ホーム > 設定 > 提供サービス → 提供サービス名 → 機能
ホーム > 管理 > アカウント → アカウント名 → 機能

機能 ページにある ゴミ箱フォルダの完全な削除が可能 のチェックをはずします。

管理拡張機能のカスタムモジュール

開発者は、Zimbraの管理コンソールのUIにカスタムモジュールを追加作成することができます。新規ビューの作成や、新しいデータオブジェクト管理の追加、あるいは既存のアイテムを新しいプロパティで拡張したり、既存ビューをカスタマイズすることも可能です。

管理コンソールUIのカスタムモジュール作成方法についての全般情報や最新情報は、Zimbra Wiki Extending_Admin_UIを参照してください。

管理コンソールUIに現在取り込まれているZimbra拡張機能は全て、閲覧のみ可として、コンテンツペインに一覧表示されています。

モジュールを作成した本人だけが削除することができます(「管理拡張機能のモジュールを削除する」を参照してください)。

新しい管理コンソールUIモジュールを配備する

管理コンソール:

ホーム > 設定 > 管理拡張機能

管理コンソールのアクセスに使用する端末に、モジュールのZipファイルを保存します。

  1. ギア アイコンから 配備 を選択して、Zimletまたは拡張機能をアップロードおよび配備 ダイアログを表示します。

  2. アップロードするカスタムモジュールのZipファイルを選択します。

  3. 配備 ボタンをクリックします。

    ファイルがアップロードされると即座に拡張機能がサーバーに配備されます。

管理拡張機能のモジュールを削除する

管理拡張機能を削除することで、選択したモジュールとその関連ファイルが全て削除されます。元のZipファイルは削除されません。

管理コンソール:

ホーム > 設定 > 管理拡張機能

下記手順で、管理拡張機能のカスタムモジュールを削除します。

  1. 削除したいモジュールを選択し、ギア アイコンから 配備解除 を選びます。確認用のメッセージダイアログが表示されます。

  2. はい をクリックすると、処理が実行されます。

Ephemeral Data(エフェメラルデータ)

Zimbra Collaborationの通常オペレーションにてLDAPに格納されるエフェメラルデータには主に3つあります。

  • 最終ログインタイムスタンプ (zimbraLastLogonTimestamp)

  • 認証トークン (zimbraAuthTokens)

  • CSRFトークン (zimbraCsrfTokenData)

ユーザー数が少ないメールシステムでは、このようなエフェメラルデータのストレージをLDAPサーバで行えることが可能です。 ただし、大量のアクティブユーザー様のメールシステムでは、短時間に残るデータストレージがLDAPをオーバーロードしてしまう可能性があります。 そのため、このようなエフェメラルデータを外部のサーバへ保管することを推奨しております。

注意:外部ストレージサーバーのインストールおよび管理方法は本書では言及しません。

エフェメラルデータのストレージ場所の設定は次のLDAP属性で行います。

属性

フォーマット

説明

zimbraEphemeralBackendURL

[backend name]:[params]

エフェメラルデータバックエンドURL設定

現在サポートされているエフェメラルデータの2つのバックエンド

バックエンド

フォーマット

説明

LDAP

ldap://default

デフォルト設定

SSDB

ssdb:127.0.0.1:8888

SSDBサーバーとポート

高頻度の認証リクエストは、エフェメラルデータのストレージバックエンドに高負荷を発生させます。以下の Zimbra Wiki ページにて、認証リクエストの負荷テストの結果をご参照ください。

運用中の Zimbra Collaboration に SSDB の利用へ変更する方法

すでに稼働中の Zimbra Collaboration 環境にて、 エフェメラルデータのストレージ用に LDAP ではなく SSDB を利用するには、次のように設定します。

  1. SSDB をインストールし、それに設定されているIPアドレスとポート番号をメモします。このデータを次の手順で使用する必要があるためです。詳細は、 SSDB インストールと設定 を参照してください。

  2. コマンド /opt/zimbra/bin/zmmigrateattrs を使って、既存のエフェメラルデータを SSDB へ移行します。

  3. Zimbra Collaboration が SSDB を使用するように設定します。

移行手順

  1. 環境にあるマシンのいずれかからコマンドプロンプトを立ち上げます。

  1. zmmigrateattrs ユーティリティを使用して、既存のエフェメラルデータを SSDB バックエンドに移行します。

sudo su - zimbra
/opt/zimbra/bin/zmmigrateattrs ssdb:<ip address|hostname>:port #該当サーバーの値に変更してください。

IPアドレスもしくはホスト名を移行先URLのホスト部分として使用する場合があるかもしれません。いずれにせよ、そこからクラスタ内のすべてのマシンの適切なIPアドレスが導かれる必要があります。入力されたSSDBアドレスから、稼働しているバックエンドが導けない場合、移行処理は終了します。

  1. SSDB を使用するように Zimbra Collaboration を設定します。

sudo su - zimbra
zmprov mcf zimbraEphemeralBackendURL ssdb:<ip address|hostname>:port #該当サーバーの値に変更してください。

2.と同様、ホストとポートから、稼働しているSSDBバックエンドが導かれる必要があります。導けない場合、zimbraEphemeralBackendURL の値は変更されません。

移行の詳細

移行情報

コマンド zmmigrateattrs --status を実行すると、最新の移行処理についての情報が表示されます。移行が現在進行中の場合、このコマンドを別のターミナルウィンドウから実行する必要があるかもしれません。これにより、下記の3種類の情報が出力されます。

  1. 移行のステータス: IN_PROGRESS(進行中)、COMPLETED(完了)、FAILED(失敗)のいずれか。

  2. 移行先として機能するSSDBバックエンドのURL。

  3. 移行処理が開始された時点のタイムスタンプ。

移行情報はコマンド zmmigrateattrs --clear によりリセット可能です。リセットは、このステータスがシステムの真の状態を反映していない場合にのみ実行するようにしてください。

一時的なバックエンドのURLを変更する

zimbraEphemeralBackendURL の値が修正されると、 Zimbra Collaboration は把握できる最後の移行のステータスをチェックします。その後のシナリオは下記のとおりいくつかに分かれます。

  1. 移行が完了しており、URLが新しく入力された値と一致する場合、 zimbraEphemeralBackendURL はこの新しい値に変更されて、移行情報はリセットされます。これが想定するユースケースです。

  2. 移行が現在進行中の場合、zimbraEphemeralBackendURL は更新されません。

  3. 移行情報がない、移行が失敗している、新しいURLが移行のURLと不一致、のいずれかにあたる場合、zimbraEphemeralBackendURL は更新されますが、データが移行された保証はないことを伝える警告がログに記録されます。

エフェメラルデータを転送する

移行処理中と、バックエンドURLが変更されるまでの間は、LDAPと SSDB の両方に新しいエフェメラルデータを格納します。これにより、この2つのバックエンドを同期させないようにしています。移行先URLと一致するように zimbraEphemeralBackendURL の新しい値が更新されると、移行情報はリセットされ、転送のメカニズムは停止します。この値が不一致の場合、移行情報はリセットされず、転送は続きます。留意すべきこととして、最初の移行からURL変更までに開きがある場合でも、移行の実行は一回のみ必要です。対象のバックエンドはオフラインになるまで最新状態を維持します。しかし、移行終了からバックエンドURL変更までの間に SSDB がオフラインになった場合、移行を再実行する必要があります。

こうしたシナリオは下図にて表すことができます。

(左図:移行中と移行後)
(中央:バックエンドポイントを移行のURLに変更後)
(右図:バックエンドポイントを異なるURLに変更後) ephemeral data migration

高度な移行のオプション

zmmigrateattrs ツールに、移行に関するオプションをいくつか加えることができますが、充分に注意してお使いください。

  • -r または --dry-run オプションにて、実際の移行を行わなくてもアカウントごとの変更内容がコンソールに出力されます。

  • -n または --num-threads オプションにて、移行に使用されるスレッド数を指定します。このオプションを使わない場合は、同期(逐次)移行となります。

  • -a または --account オプションにて、カンマ区切りで指定したアカウント一覧を移行することができます。このオプションはテストまたはデバック時にのみ使用するようにしてください。

  • -d または --debug オプションにて、ログのデバッグが可能となります。

パラメーターに属性名をきちんと明示して渡さない限りは、前述の例のとおり、エフェメラルデータのすべての属性に対して移行が行われることになります。

移行に関する制約

エフェメラルデータの移行は一方通行のプロセスです。 zmmigrateattrs スクリプトでは、データを SSDB からLDAPに戻すことはできませんし、異なる SSDB インスタンス間でデータ移行することもできません。すなわち、移行後に zimbraEphemeralBackendURL の値がLDAPに戻されたとしても、以前の認証データは接続不可になり、ユーザーセッションもすべて無効になります。新規 SSDB バックエンドへの移行が必要な場合は、事前にデータを新しいロケーションに複製してから、 zimbraEphemeralBackendURL の値を変更する必要があります。

これには1つ例外があります。 SSDB へ切り替えた直後は最小のデータ損失でバックエンドをLDAPへ安全に戻すことが可能です。この理由は、移行中は元の値がLDAPに保持されるためです。バックエンドを SSDB に切り替えると、切り替え時点のエフェメラルデータのスナップショットがLDAP内に残ります。移行のユーティリティは今のところ、領域を空けるためにこのデータを削除するという方法を採っていません。このため、バックエンドを戻すことは可能です。最初に変更してから戻すまでの時間が長くなるほど、LDAPのスナップショットはエフェメラルデータの真の状態から遠ざかることになります。

zmprovへの変更

マルチバリューのエフェメラルデータの格納方法の変更に伴い、属性 zimbraAuthTokenszimbraCsrfTokenDatazmprov ga <account> の一環として返されることはなくなります。 zimbraLastLogonTimestamp の値は従来どおり返ってきますが、 -l フラグが使われない場合だけです。 -l フラグを付加した場合、サーバーにアクセスを制限するのはLDAP内の属性のみだからです。こうした属性を zmprov ma <account> を使って修正することはエフェメラルデータのバックエンドに関係なく、引き続き可能です。修正を実施するには、次のように、与えられた属性値がそのLDAPフォーマットと一致していなければなりません。
認証トークンの場合 tokenId|expiration|serverVersion
CSRFトークンの場合 data:crumb:expiration

移行のCSV出力

zmmigrateattrs を実行するたびに、ディレクトリ /opt/zimbra/data/tmp/ 内にCSVファイルが作成されます。このファイルには移行されたアカウントごとの移行情報が含まれます。 例えば移行された属性の数などです。この数はゼロになることもあります。あるアカウントの全てのエフェメラルデータがすでに移行先ストアに存在するなどの場合です。

移行が失敗した場合、同一ディレクトリ内にエラーの詳細のみをレポートする切り出しCSVファイルが作成されます。ファイル名称は実行終了時で記録されます。

アカウント削除の実施

エフェメラルデータ削除の動きはSSDBバックエンドとLDAPバックエンドの場合で少々異なります。SSDBがバックエンドの場合、アカウント削除によって、最終ログインタイムスタンプ zimbraLastLogonTimestamp 属性はSSDBから消されることになります。しかし、認証トークン zimbraAuthTokens とCSRFトークン zimbraCsrfTokenData はそのトークンのライフタイムが経過するまでSSDB内に残ります(デフォルトでは2日間)。これに対して、LDAPのエフェメラルデータの場合は、アカウント削除処理の一部として、即座に一掃されます。

SSDB インストールと設定

インストール方法について

Zimbra Collaboration のパッケージには SSDB サーバーが含まれておらず、Zimbra Collaboration のインストールおよび構成ツールでは SSDB の設定を変更できません。最新版の SSDB をインストールする場合、SSDB の開発コミュニティに公開されている手順をご参照ください: SSDB Installation Documentation 現時点では、Zimbra Collaboration は SSDB 1.9.5 でのみ運用確認を行っております。 なお、SSDB 1.9.5 をインストールする際にhttp://ssdb.io/docs/install.html[SSDB installation instructions] のインストール手順を参照する場合、 master.zip ではなく、 stable-1.9.5.zip をダウンロードします。

設定オプションの概要

本章では、SSDB で使用可能なオプションについて次の観点から説明します。

  • マスター・スレーブ間レプリカ (複製) による高い可用性

  • マスター・マスター間レプリカ (複製) による高い可用性

  • マスターサーバーの複数利用 (マルチマスター) による高い可用性をもつ拡張機能

本書は、本件に関する精緻な説明するものではありません。また、本書の記載時点では、zimbraEphemeralBackendURL および移行用属性を変更を行なう前に、システム管理者による SSDB および関連パッケージのインストール・設定が完了していなければなりません。

SSDBRedis クライアントとの互換性があり、また現在、Zimbra Collaboration は Reis 互換クライアントを SSDB との通信に利用しています。このため、ここに記載するコンセプトの多くは、Reis バックエンドで適用できます。

マスター・スレーブ間レプリカによる高い可用性

通常処理

本書で説明するマスター・スレーブ間レプリカの実装方法では、 Keepalived を使って、設定済みバーチャルIPアドレスを保持します。このバーチャルIPアドレスは、通常状況下であれば、マスターである SSDB インスタンスにバインドされています。

ssdb master slave normal

フェールオーバー

Keepalived がマスターのインスタンスでの障害を検知すると、バーチャルIPアドレスはバックアップする側へとバインドされなおされます。これにより、バックアップ側インスタンスはマスターに昇格します。

ssdb master slave failover

マスター・マスター間レプリカによる高い可用性

マスター・スレーブ間レプリカと違う点は、両 SSDB インスタンスともにオンラインであり、かつ、アクセス可能であることです。片方の変更内容を、もう片方のインスタンスがレプリケーション (複製) します。後述するセットアップ例では、フロントエンドに HAProxy を使用します。商用の場合、プロキシサービス自体の可用性が高いものを使用する必要があることをご留意ください。

ssdb master master

マルチサーバー設定による拡張機能

通常、SSDBRedis も、単一インスタンス内にキー・スペース全体が入っています。しかし、 twemproxy サービスなどを利用して、複数のインスタンスをフロンドエンド化することも可能です。これは、ハッシュ化のモードを多数サポートしているため、特定のキーに紐づくデータがいつも同じサーバーに格納されるように実現できます。これにより、非常に大きな環境で拡張させることができます。

個々の SSDB インスタンスをマスター・スレーブペアに設定することで、高い可用性と拡張機能の双方を実現できます。

ssdb multi master

マスター・スレーブ間レプリカ

SSDB の可用性を高くする方法の1つは、マスター・スレーブ間レプリカにセットアップして、マスターのインスタンスが停止した場合にバックアップ側の SSDB インスタンスが自動で引き継ぐシステムを設定することです。本書では、この目的を遂行するための一技術を記載します。

概要

SSDB を2つのサーバーにインストールします。1つはマスターに指定、もう1つはスレーブつまりバックアップに指定したものとして設定します。そして定期的に後者がマスターサーバーでの変更内容をレプリケーションするように設定します。

Keepalived も両サーバーにインストールしてください。各 Keepalived インスタンスが互いを監視するようになります。マスターサーバーが停止した場合、 Keepalived がその障害を検知し、スレーブつまりバックアップサーバーをマスターサーバーへと昇格させます。 Keepalived は、現マスターサーバーがどちらであろうとその現マスターサーバーにバインドされている バーチャルIPアドレス を保持しています。

Keepalived で保持されているバーチャルIPアドレスが zimbraEphemeralBackendURL にバインドされるように、Zimbra Collaborationを設定します。

Zimbra Collaboration と SSDB マスター・スレーブ設定 両方 のインストールおよび設定が完了したら、 Ephemeral Data章にある手順に従い、zimbraEphemeralBackendURL を更新してください。

以下に記した例は、 Ubuntu 16.04 が稼動しているサーバー上にて実施されました。

必要パッケージ

前提条件

ご利用中のLinuxディストリビューションに適用できる手順に従い、 SSDBKeepalived を2つのサーバーにインストールするようにしてください。

設定

次の設定手順は、 SSDB/var/lib/ssdb にインストールされていること、そして、同一ディレクトリ内にすべての SSDB 設定ファイルがあることを前提にしています。また、内部のホストアドレスが 192.168.56/24 のネットワーク上にあるものとして記載します。

  • 192.168.56.111 - 当初、マスターである SSDB サーバーのIPアドレス

  • 192.168.56.112 - 当初、スレーブである SSDB サーバーのIPアドレス

  • 192.168.56.120 - Keepalived が保持することになるバーチャルIPアドレス

指定 (当初) マスターのSSDB設定

このマシンのIPアドレスは 192.168.56.111 です。

/var/lib/ssdb/ssdb_master.conf

後述の枠内に記載されている、キーとなる設定項目は次のとおりです。

  • server/ip - 有効なIPアドレスすべてをバインド

  • server/port - 標準の SSDB ポートをバインド

  • server/deny, server/allow - localhost および内部 (ホスト) アドレスに対する SSDB アクセスを制限

マスター・スレーブ間レプリカに関する設定項目のみ以下、記載します。

# ssdb-server config
# インデントはタブで!

# このファイルへのパス、ディレクトリが存在すること。
work_dir = ./var
pidfile = ./var/ssdb.pid

server:
        ip: 0.0.0.0
        port: 8888
        deny: all
        allow: 127.0.0.1
        allow: 192.168.56

replication:
        binlog: yes
        #  sync (同期) のスピード。*MB/sまで。 -1:無制限
        sync_speed: -1
        slaveof:
                # sync|mirror, デフォルトはsyncです
                #type: sync

/var/lib/ssdb/ssdb_slave.conf

後述の枠内に記載されている、キーとなる設定項目は次のとおりです。

  • server/ip - localhost をバインド

  • server/port - standard SSDB ポートをバインド

  • slaveof/type - sync

  • slaveof/host - 192.168.56.112 はもう片方の SSDB サーバー

  • slaveof/port - 8888 - 標準の SSDB ポート

繰り返しますが、マスター・スレーブ間レプリカに関する設定項目のみ以下、記載します。

# ssdb-server config

# このファイルへのパス、ディレクトリが存在すること。
work_dir = ./var_slave
pidfile = ./var_slave/ssdb.pid

server:
        ip: 127.0.0.1
        port: 8888

replication:
        binlog: yes
        #  sync (同期) のスピード。*MB/sまで。 -1:無制限
        sync_speed: -1
        slaveof:
                # sync|mirror, デフォルトはsyncです
                type: sync
                # host: <hostname>  SSDB 1.9.2 以上で利用可能。
                ip: 192.168.56.112
                port: 8888
指定 (当初) スレーブのSSDB設定

このマシンのIPアドレスは 192.168.56.112 です。

ssdb_master.conf ファイルは、対応する指定マスターサーバーと同じです。

ssdb_slave.conf ファイルは、対応する指定マスターサーバーとほぼ同じです。次のアイテムのみ異なります。

  • slaveof/ip (または host) - 192.168.56.111 はもう片方の SSDB サーバーです。

指定 (当初) マスターのKeepalived設定

/etc/keepalived/keepalived.conf

特記すべき、キーとなる設定項目は次になります。

  • state - 指定 (当初) マスターサーバーでもバックアップサーバーでも、Stateには BACKUP を設定。この場合、どちらのサーバーが当初 MASTER 状態かを決めるのに priority を使用します。

  • nopreempt - マスターサーバーが停止してバックアップサーバーがマスターサーバーへと昇格した場合、自動でオンラインに立ち上がるはずの元のマスターを、この設定ファイルの命令により、その役目を復活させないようにします。元のマスターはすでに最新の内容ではないからです。この場合、立ち上がった後は、バックアップモードで保たれることとなり、新たにマスターとなったサーバーから情報をレプリケーションするようになります。 注意: 停止したマスタを立ち上げるのにマニュアル操作が必要となる場合もあります。

  • interface - この例では enp0s8 がインターフェース識別子で、このために virtual_ipaddress が定義されることとなります。 環境に適した値を選別してください。

  • priority - 当初の指定マスターサーバーのpriorityの値は、当初の指定バックアップサーバーのpriorityの値よりも高くなければなりません。

  • advert_int - 本書の例としてはデフォルト値1秒を設定しました。 Keepalived 1.2.21 以上をご利用になる場合は、小数点以下を指定することができます。例 0.1 (秒)。これを使って Keepalived がマスターサーバーの停止を更に迅速に検知できるようにします。

  • notify - state 変更時に呼ばれるスクリプトのパスです。このスクリプトの全容は後述します。

  • virtual_ipaddress - Keepalived が保持するバーチャルIPアドレスです。

vrrp_instance VRRP1 {
        state BACKUP
        nopreempt
        interface enp0s8
        virtual_router_id 41
        priority 200
		advert_int 1
        notify /var/lib/ssdb/notify.sh

        authentication {
                auth_type PASS
                auth_pass 1234
        }
        virtual_ipaddress {
                192.168.56.120 dev enp0s8 label enp0s8:vip
        }
}

/var/lib/ssdb/notify.sh

以下はStateが変更されているときに Keepalived が呼ぶスクリプトです。ただし、USER に指定する値は、SSDB 処理のオーナーであるユーザー名にしてください。

#!/bin/bash
# rootで実行すること。

ENDSTATE=$3
NAME=$2
TYPE=$1

LOG=/var/log/keepalived-state-transition.log
LOG_ERROR=0
LOG_WARNING=1
LOG_INFO=2
LOG_DEBUG=3
LOG_LEVEL=$LOG_INFO

KPCFG=/etc/keepalived/keepalived.conf
USER=<SSDB-user-name>
PREFIX=/var/lib/ssdb


function log {
    lvl=$1
    msg="$2"
    if [ $lvl -le $LOG_LEVEL ]
    then
        now=$(date)
        echo "$now [$lvl] $msg" >> $LOG
    fi
}

function log_error {
    log $LOG_ERROR "$1"
}
function log_warning {
    log $LOG_WARNING "$1"
}
function log_info {
    log $LOG_INFO "$1"
}
function log_debug {
    log $LOG_DEBUG "$1"
}

function backup {
    log_info "Transitioning to BACKUP state"
    runuser -l $USER -c "${PREFIX}/ssdb-server ${PREFIX}/ssdb.conf -s stop"
    runuser -l $USER -c "cp ${PREFIX}/ssdb_slave.conf ${PREFIX}/ssdb.conf"
    runuser -l $USER -c "${PREFIX}/ssdb-server -d ${PREFIX}/ssdb.conf"

}

function fault {
    log_error "keepalived is in FAULT state"
}

function master {
    log_info "Transitioning to MASTER state"
    runuser -l $USER -c "${PREFIX}/ssdb-server ${PREFIX}/ssdb.conf -s stop"
    runuser -l $USER -c "cp ${PREFIX}/ssdb_master.conf ${PREFIX}/ssdb.conf"
    runuser -l $USER -c "${PREFIX}/ssdb-server -d ${PREFIX}/ssdb.conf"
}


case $ENDSTATE in
    "BACKUP") # Perform action for transition to BACKUP state
        backup
        exit 0
        ;;
    "FAULT")  # Perform action for transition to FAULT state
        fault
        exit 0
        ;;
    "MASTER") # Perform action for transition to MASTER state
        master
        exit 0
        ;;
    *)    echo "Unknown state ${ENDSTATE} for VRRP ${TYPE} ${NAME}"
        exit 1
        ;;
esac
指定 (当初) バックアップのKeepalived設定

/etc/keepalived/keepalived.conf

このファイルはマスターノードにあるファイルとほとんど同じですが、以下が異なります。

  • priority - 当初プライオリティはマスターノードより低くします。

  • nopreempt オプションはありません。一度、元のマスターサーバーの停止によりバックアップサーバーがマスターサーバーとなった場合は、元のサーバーがMASTERステータスに戻る前に、システムに対して人的介入ができるようにしておく必要があるためです。

vrrp_instance VRRP1 {
        state BACKUP
        interface enp0s8
        virtual_router_id 41
        priority 100
        advert_int 1
        notify /var/lib/ssdb/notify.sh

        authentication {
                auth_type PASS
                auth_pass 1234
        }
        virtual_ipaddress {
                192.168.56.120 dev enp0s8 label enp0s8:vip
        }
}

バックアップサーバーの /var/lib/ssdb/notify.sh はマスターと同じです。

マスター・マスター間レプリカ

概要

SSDB の可用性を高くするもう1つの方法は、マスター・マスター間レプリカにセットアップして、2つの SSDB サーバーの前段に、Redis プロトコルを読み解くプロキシを設定することです。このプロキシは、両サーバーの状態を監視して、停止したサーバーをその稼動状態からはずす役目があります 。

2つの SSDB サーバーの前段に単一の HAProxy インスタンスを使った簡単な例を以下説明します。

必要パッケージ

  • SSDB 1.9.2 以上のバージョンを想定した例を以下に示します。

  • HAProxy

前提条件

ご利用中のLinuxディストリビューションに適用できる手順に従い、 SSDB を2つのサーバーにインストールしてください。HAProxy を更に別のサーバーにインストールしてください。 KeepalivedHAProxy サーバープールの可用性を高くするのに役立ちます。

設定

プライマリマスターサーバーのSSDB設定

注意:

  • マスター・マスター間レプリカに関する設定項目のみ以下、記載します。

# ssdb-server config
## ssdb-server config インデントはタブで!

# このファイルへのパス、ディレクトリが存在すること。
work_dir = ./var
pidfile = ./var/ssdb.pid

server:
        ip: 0.0.0.0
        port: 8888
        deny: all
        allow: 127.0.0.1
        # e.g., 192.168.56
        allow: <ip-address-prefix>


replication:
        binlog: yes
        #  sync (同期) のスピード。*MB/sまで。 -1:無制限
        sync_speed: -1
        slaveof:
                id: svc_2
                type: mirror
                host: <hostname-of-other-master>
                port: 8888
セカンダリマスターサーバーのSSDB設定

注意:

  • マスター・マスター間レプリカに関する設定項目のみ以下、記載します。

# ssdb-server config
# インデントはタブで!

# このファイルへのパス、ディレクトリが存在すること。
work_dir = ./var
pidfile = ./var/ssdb.pid

server:
        ip: 0.0.0.0
        port: 8888
        deny: all
        allow: 127.0.0.1
        # e.g., 192.168.56
        allow: <ip-address-prefix>


replication:
        binlog: yes
        #  sync (同期) のスピード。*MB/sまで。 -1:無制限
        sync_speed: -1
        slaveof:
                id: svc_1
                type: mirror
                host: <hostname-of-other-master>
                port: 8888
HAProxy 設定

注意:

  • SSDB に関する設定のみ以下、記載します。

  • SSDBRedis というネットワークプロトコルをサポートしています。 Redis クライアントを使用して、SSDB サーバーに接続し、そこで操作することができます。これがZimbra Collaboration が行っていることです。

defaults REDIS
        mode tcp
        timeout connect  4s
        timeout server  30s
        timeout client  30s

frontend ft_redis
        bind <published-ip-address>:8888 name redis
        default_backend bk_redis

backend bk_redis
        option tcp-check
        server R1 <first-master-ip-address>:8888 check inter 1s
        server R2 <second-master-ip-address>:8888 check inter 1s

マルチサーバーでの拡張機能・レプリケーション

概要

本書では、マスターサーバー複数設定の詳細説明はいたしません。要するに、前述の手順どおり、個別 SSDB マスター・スレーブペアを複数、インストール・設定することになります。各ペアは、サブセットとしてのキー・スペース全体を持つ役割があります。

マスター・マスター間設定のように、 SSDB サーバープールの全ペアの前段に、Redis プロトコルを読み解くプロキシサーバーが存在します。また、特定のキーに関連する全てのリクエストが、必ず同じマスター・スレーブペアにルーティングされるために存在しているそのデータキーを、終始ハッシュ可能にしていなくてはなりません。

こうした製品の1つに Twitter から出ている twemproxy があります。

LDAP 属性

SSDB バックエンドは、SSDB サーバーに対するアクセス管理にリソースプールを利用します。つまり、エフェメラルデータ操作を行うスレッドは、まず、このプールでリソースを獲得します。このため、そのプールの設定管理用LDAP属性を以下2つ紹介します。

zimbraSSDBResourcePoolSize は、プールのサイズを制御します。これにより、エフェメラルAPI操作を同時に行なうことのできるクライアントスレッド数を決定します。デフォルトでは0が設定されており、この場合、プールサイズに上限はありません。

zimbraSSDBResourcePoolTimeout は、スレッドが例外をスローする前にリソースを待機する時間を制御します。デフォルトは0であり、この場合、時間切れはありません。プールサイズが0の場合、この属性による影響はありません。なぜなら、エフェメラルデータの操作を行なうのにスレッドがリソースの開放を待つ必要がないからです。

プールサイズが有限な場合、タイムアウトの値をゼロ以外にすることを推奨します。そうでないと、一度 SSDB 接続が切れたときに再度確立したあとも永久にmailboxdスレッドがブロックされ続ける原因となるからです。一般的に、リソースプールはメールボックスがリソースに困らないようなサイズにしておくべきです。

Zimbra Collaboration の運用負荷と合わせるように SSDB をチューニングする

SSDB サーバへ直接に影響する Zimbra Collaboration の運用負荷は認証リクエストの頻度と Zimbra Collaboration ウェブクライアントと第三者 SOAP クライアントで送信される SOAP リクエストの頻度となります。各認証リクエストは SSDB に 2つか3つの書き込み作業を発生させます。書き込み作業では、zimbraLastLogonTimestamp, zimbraAuthTokens, および zimbraCsrfTokenData の値を更新します。なお、zimbraCsrfTokenData は Zimbra Collaboration ウェブクライアント、などで CSRF を有効化している SOAP クライアントを利用する場合のみで更新されます。各認証された SOAP リクエストは SSDB に2つの読み込み作業を発生させます。

最小推奨の SSDB システム条件

最小のシステム条件として、SSDB サーバに 2GB RAM と 1つの CPU を推奨しております。SSDB サーバに監視と設定の管理ツール、などの追加ツールを実行する予定がある場合、メモリとCPUコアの増加をご検討ください。詳細につきましては、 Zimbra and SSDB Authentication Load Tests をご参照ください。

おわりに

エフェメラルデータのストレージ要件が単一インスタンス内で収まるような環境の場合は、シンプルなマスター・スレーブ間レプリケーションがいちばん簡単に実装できますし、リソースも最小限で済みます。マスター・マスター間レプリカの場合は、両マスターサーバー間でリクエストのロードバランスをとることができますが、双方が定期的にもう片方をレプリケーションしなければなりません。このため、整合性を保つという追加タスクが SSDB に課されます。

アカウントの提供サービスについて

アカウントに指定される提供サービス(COS)によって、ユーザーアカウントのデフォルト設定や各機能が使用可か不可かが決まります。各アカウントは、提供サービスが1つ指定されます。提供サービスにより、メールボックスの割り当て容量、メッセージの有効期限、パスワード制限、添付ファイルのブロック、サーバープールの使用量を制御します。

提供サービスはグローバルオブジェクトであるため、特定のドメインやドメインのセットに限定されることはありません。

管理コンソールから、提供サービスを作成、編集できます。

管理コンソール:

ホーム > 設定 > 提供サービス → 提供サービス名

提供サービスでアカウントの利用方法を管理する

Zimbra Collaboration のインストール時、デフォルト提供サービスが自動作成されます。管理者は、デフォルト提供サービスの修正や提供サービスの新規作成を実施できます。

提供サービスの画面から管理できる機能

  • アクセス可能な機能やプリファレンス

  • 使用可能なテーマやZimlet

  • 添付ファイル制限、割り当て容量、パスワードのログインポリシーなどの詳細設定

  • ウェブクライアントのバージョン(アドバンスドとスタンダードのクライアント)

  • ウェブサービスとデスクトップクライアント(EWS、MAPIなど)

  • オフラインモード

  • 保持ポリシー

例えば、メールボックスの割り当て容量無制限、メッセージ自動削除なし、全機能が有効の、提供サービスを経営者用に作成することができます。もう1つ、従業員用に提供サービスを作成し、そのメールボックスの割り当て容量を設定、60日以降の古いメッセージを自動削除を設定、メール以外の機能を無効にすることができます。特定の提供サービスでアカウントをグルーピングすることによって、アカウントの機能をいっぺんに更新・変更できます。このように、提供サービスの変更時、その提供サービスを指定されているアカウント全てが変更されます。

新規アカウント作成時に提供サービスを指定しないときや、ユーザーに指定していた提供サービスがなくなったとき、デフォルト提供サービスが自動で指定されます。

提供サービスを1つ作成し、それをあるドメインに作られた全アカウントのデフォルト提供サービスとして設定することができます。複数の提供サービスを作成し、そのうちどれをドメインが使用できるかを限定することも可能です。アカウントの作成時、そのドメインに決まった提供サービスがなく、管理者が提供サービスを指定しないとき、デフォルト 提供サービスが自動で指定されます。

提供サービスの設定は、グローバル設定やユーザー設定にオーバーライドされる場合があります。以下はその例です。

  • 送信済み フォルダに保存される送信メッセージを、別のフォルダに保存されるように、ユーザーのプリファレンスで変更できるかどうか。

  • グローバル設定として設定した添付ファイル制限は、提供サービスの設定にオーバーライドできます。

アカウントに指定した提供サービスのなかには、IMAPクライアントに適用されないものもあります。

機能やプリファレンスを選択する

提供サービスで使用できる機能はすべて、 機能 ページに表示されます。このページから、提供サービスに含めたい機能を選択したり、選択から外したりできます。

アカウントレベルでの設定変更は、そのアカウントの提供サービスでのルールをオーバーライドします。

プリファレンス ページで、メッセージの保存や閲覧の初期プリファレンスを設定できます。また、ZWCの表示に特定のロケールを選択することも可能です。ロケールを指定していない場合、ブラウザのロケールがデフォルトです。

機能やプリファレンスの詳細は、アカウントのカスタマイズ を参照してください。

プリファレンスを無効にする

デフォルトでは、プリファレンスは有効で、ユーザーはアカウントに設定されているデフォルト プリファレンスを変更できます。

管理者はプリファレンスを無効にすることができます。この場合、ユーザーのメールボックスのプリファレンスが非表示になるため、ユーザーはアカウントにセットアップされた機能のデフォルト設定を変更することができません。

デフォルトのタイムゾーンを設定する

アカウントのプリファレンスに表示されるデフォルトタイムゾーンは、標準版のウェブクライアントで受信するメッセージとカレンダー予定の、日付・時間のローカライズに使われます。

標準版のウェブクライアントを使用する場合、コンピュータのタイムゾーンはメッセージ受信日時やカレンダーの予定日時に使用されません。 プリファレンス > カレンダーオプション でのタイムゾーン設定が使用されます。

アドバンスド版のウェブクライアントの使用中は、コンピュータのタイムゾーンで受信メッセージやカレンダー予定のタイムスタンプが決まります。プリファレンスの 全般 にあるタイムゾーン設定は使われません。

アドバンスドと標準版のウェブクライアントは、メッセージの時間表示に同じタイムゾーンソースを使用していないため、複数のクライアントに表示されるメッセージのタイムスタンプが異なっていると気づく場合があります。この現象を回避するには、ウェブクライアントのタイムゾーンとコンピュータのタイムゾーンを一致させるます。

サーバープールを使用する

複数のメールボックスサーバーで構成している環境の場合、新規アカウントのメールボックスサーバーへの割り当てに、提供サービスが使われます。提供サービスの設定時、サーバープールへ追加すべきサーバーを選択します。各サーバープール内で、ランダムなアルゴリズムにより、新規メールボックスが有効サーバーに割り当てられます。

新規アカウントウィザードからの新規アカウント作成時、特定のメールボックスサーバーにアカウントを設定できます。 自動 からチェックを外し、サーバー項目にメールサーバーを入力します。

アカウントの割り当て容量を設定する

アカウントの割り当て容量とは、アカウントに許されているストレージサイズの上限です。メッセージ、アドレス帳、カレンダー、タスク、ブリーフケースのファイルが割り当て容量にカウントされます。アカウントの割り当て容量は、管理コンソールから提供サービスや個々のアカウントの設定で、設定できます。

割り当て容量の制限を「0」に設定した場合、アカウントに容量の制限はありません。

アカウントの割り当て容量の使用状況を確認する

ドメインの全アカウントの割り当て容量を確認します。

管理コンソール:

ホーム > 設定 > ドメイン → ドメイン名 → メールボックスの割り当て容量

割り当て容量の制限が近いことをユーザーに通知する

メールボックスの割り当て容量の制限に近づいている旨をユーザーは受け取ることができます。容量のパーセントと警告文は修正可能です。その提供サービスの 割り当て容量 コンテナへ遷移します。

管理コンソール:

ホーム > 設定 > 提供サービス → 提供サービス名 → 詳細設定 → 割り当て容量

表示/設定されたしきい値に達すると、割り当て容量を警告する通知がユーザーに送信されます。

ドメインの割り当て容量を設定する

ドメインのメールボックスの割り当て容量の上限を設定できます。ドメインのメールボックス割り当て容量のデフォルトは無制限です。ドメインの割り当て容量とは、ドメイン内の全メールボックスで使用できる最大ストレージ容量です。

総割り当て容量も設定可能です。ドメイン内全てのアカウント割り当て容量の合計が総容量を超えても構いません。

総割り当て容量に達したときに送受信するメッセージを管理する、総割り当て容量ポリシーを設定できます。このポリシーには下記のオプションがあります。

  • 送受信の許可(通常どおりメッセージの送受信を継続許可する)

  • 送信のブロック(メッセージの送信を許可しない)

  • 送受信のブロック(メッセージの送受信を許可しない)

設定された総割り当て容量の警告パーセントに達すると、警告メールが自動送信されます。日次で実行されるCron tabのジョブによりドメイン総割り当て容量パーセントがチェックされ、パーセントを超える場合は割り当て容量警告メールが送信されます。

ドメイン割り当て容量の設定時、アカウントの有効割り当て容量は、ドメイン設定またはアカウントの設定の下限値です。

ドメイン割り当て容量を設定するには、そのドメインの ドメイン割り当て容量設定 コンテナに遷移します。

管理コンソール:

ホーム > 設定 > ドメイン → ドメイン名 → 詳細設定 → ドメイン割り当て容量設定

容量超過時の管理

管理者は、メールボックス制限容量超過時におけるメッセージ配信管理を設定できます。デフォルトでは、MTAが一時的に据え置き用のキューにメッセージを送信します。メールボックスに充分な容量が戻ると、メッセージが配信されます。このときの動作を、メッセージを据え置き用のキューへ送信せずに送信者へ送り返すという方法と、超過した場合もメッセージをメールボックスへ送信するという方法に変更することができます。

メッセージを据え置き用のキューへ送信せずに、送信者へ送り返します。

zmprov mcf zimbraLmtpPermanentFailureWhenOverQuota TRUE

超過した場合もメッセージをメールボックスへ送信します。

zmprov mc {cos-name} zimbraMailAllowReceiveButNotSendWhenOverQuota TRUE

この属性がTRUEのとき、容量制限を超過したメールボックスでも、新規メールとカレンダー招待を受けとることができます。この迂回策はメッセージにのみ対応しています。その他のメールアイテムは依然として容量制限に左右されます。

パスワードを管理する

内部認証を使用しているとき、アカウントのツールバーから簡単にパスワード変更ができます。新規パスワードをユーザーに伝える必要があります。

Microsoft Active Directory (AD)をユーザー認証に使用時、提供サービスの「パスワードを変更」オプションを無効にする必要があります。ZimbraはADパスワードポリシーを管理しません。

管理者が作成したパスワードをユーザーに変更させたいなら、アカウントの 初回ログイン時にパスワードを変更させる オプションを有効にします。ユーザーの次回ログイン時、パスワード変更が必須となります。

パスワードの制約は提供サービスレベルまたはアカウントレベルで設定できます。強力なパスワードの作成やパスワードの定期的な変更をユーザーに要求したり、不正パスワードの入力時にアカウントをロックアウトするパラメーターを設定したりできます。

特定のパスワード変更ページを使用する

Zimbra Collaborationの認証が外部認証として設定されているなら、ユーザーのパスワード変更時、パスワード変更 ページへ転送するように設定できます。このURLはグローバル設定またはドメイン単位で設定できます。

パスワード変更ページのURLを zimbraChangePasswordURL 属性に設定します。

ZWCの プリファレンス > 全般 にある パスワードを変更 ボタンがこのURLへリンクします。また、パスワードが期限切れの時、このページに遷移されます。

ドメインのパスワードを修正します。

zmprov md example.com zimbraChangePasswordURL https://auth.example.com

パスワードのポリシーを設定する

ドメインの内部認証を設定しているなら、強力なパスワード作成をユーザーに要求してシンプルなパスワードによるディレクトリハーベスティング攻撃 (DHA) を防ぐことができます。設定されているログイン失敗回数の上限に達したら、アカウントからユーザーをロックアウトさせられます。

提供サービスの パスワード コンテナからパスワードポリシーを設定します。

管理コンソール:

ホーム > 設定 > 提供サービス → 提供サービス名 → 詳細設定 → パスワード

使用できるパスワード設定の一覧です。

Table 34. パスワードオプション
パスワードオプション 説明

パスワードの最小長/最大長

パスワードの最小と最大の長さを指定します。 デフォルトの設定では最小が6と最大が64文字です。

パスワードの最短/最長有効期間 (日)

パスワードの有効期限を設定します。最短から最長の間であれば、ユーザーはいつでもパスワードを変更できます。最長の有効期間を超えるとパスワードの変更が必要になります。

以下の設定で、強力なパスワードの作成をユーザーに要求できます。

大文字の最小数

A-Z の大文字

小文字の最小数

a-zの小文字

句読記号の最小数

アルファベットや数字以外の記号、例えば !, $, #, &, %

数字の最小数

10進数の数字 0 - 9

数字または句読点の最小値

英数値以外と数値との組み合わせ

固有パスワード履歴の最小数

一度使用したパスワードが再度使用可能となるまでの一意の新規パスワード数

パスワードの最短有効期間 (日)

パスワード変更までの最短日数

パスワードの最長有効期間 (日)

パスワード変更までの最長日数

ユーザーがパスワードを変更しないようにする

ユーザーはパスワードを変更できません。認証が外部なら、このオプションを有効にする必要があります。

初回ログイン時にパスワードを変更させる

ユーザーの初回サインイン時、パスワード変更が要求されます。

パスワードを変更

有効にした場合、パスワードの有効期限以内であればいつでもユーザーはアカウントのプレファレンスタブからパスワード変更ができます。

ログインポリシーを管理する

アカウントが一定期間ロックアウトされるまでのログイン失敗許容回数の上限を設定できます。こうしたポリシーの利用により、パスワード攻撃を防ぐことができます。

ユーザーログインポリシーを設定するには、その提供サービスの ログイン失敗ポリシー コンテナを使用します。

管理コンソール:

ホーム > 設定 > 提供サービス → 提供サービス名 → 詳細設定 → ログインポリシーのオプション

Table 35. ログインポリシーのオプション
ログインポリシーのオプション 説明

ログイン失敗のロックアウトを有効にする

「ログイン失敗時のロックアウト」機能を有効します。これ以降の設定が可能になります。

許可される連続ログイン失敗の回数

アカウントがロックアウトされるまでのログイン失敗許容回数。デフォルトは10。0のとき、アカウントはロックアウトされません。

アカウントをロックアウトする時間

アカウントがロックアウトされる期間。0のとき、正しいパスワードが入力されるまでロックアウトは解除されません。あるいは管理者がアカウントのステータスを変更し、新規パスワードを作成すると解除されます。デフォルトは1時間。

アカウントをロックするためにログインの失敗が発生しなければならない時間枠

ログイン失敗連続回数がログから消されるまでの期間。0のとき、ログイン失敗連続回数に関係なくユーザーは認証を試し続けることができます。デフォルトは1時間。

2要素認証について

2要素認証 (FA) 機能 (バージョン8.7で搭載) により、システムへアクセスされる際の認証レイヤーが増えるため、提供サービスやユーザーアカウントに適用するセキュリティポリシーを更に追加することができます。管理コンソールから、ユーザーのメールボックスに対する2FA機能の適用有無を管理します。

2 Factor Authentication

詳細は、 2要素認証 を参照してください。

セッションがタイムアウトするポリシーを設定する

管理者は複数の条件を用いてユーザーセッションの許容時間を設定できます。

セッションのタイムアウトポリシーを設定するには、特定の提供サービスの タイムアウトポリシー コンテナを使用します。

管理コンソール:

ホーム > Configure> 提供サービス → 提供サービス名 → 詳細設定 → タイムアウトポリシー

Table 36. セッションタイムアウトポリシーオプション
セッションタイムアウトポリシーオプション 説明

管理コンソール認証トークンの有効期間

管理者の認証トークンをブラウザのCookieに保存します。認証トークンの期限が切れるまで、管理者はログイン入力せずに管理コンソールを開くことができます。デフォルトは12時間。

認証トークンの有効期間

ZWC認証トークンをブラウザのCookieに保存します。認証トークンの期限が切れるまで、管理者はログイン入力せずにZWCを開くことができます。デフォルトは2日間。期限が過ぎるとログイン画面が表示され、処理の継続にログインが必要となります。

セッションのアイドルタイムアウト

アクティビティがなくてもユーザーセッションがアクティブでありつづける期間。アクティビティには、クリック可能なマウス操作、フォルダ内閲覧、ボタンクリックなどがあります。デフォルトは無制限。

管理コンソールのセッションを無効にするリンクから、ユーザーのウェブクライアントセッションを期限切れにすることができます。これにより、即座に現行セッションが無効になります。

defaultExternal提供サービスを管理する

defaultExternal提供サービスは、ZCS 登録ユーザーからのカレンダー共有やブリーフケースアイテム共有の招待を外部ユーザーが承諾したときに作成される外部仮想アカウントに指定されます。

仮想アカウントはサーバーに登録されないものの、外部ユーザーはZWCにログインでき、共有アイテムを閲覧するための表示名やパスワードを設定できます。閲覧できるのは、アクセスが許可されているフォルダのみです。

defaultExternalの提供サービスには、次の一般機能が設定されています。 パスワードを変更、UIテーマを変更、HTML作成、エクスポート、検索。主な機能は一切設定されていません。

アカウントのカスタマイズ

本章では、提供サービスや個々のアカウントの設定で、アカウントに対して設定できる機能とユーザープリファレンスについて説明します。

メールボックス機能はZimbraのウェブクライアントユーザーであれば有効です。IMAPやPOPクライアトの利用時、こうした機能が使用できない可能性があります。

メッセージングと情報共有のアプリ

提供サービスの設定やアカウントへの提供サービス設定により、アカウント機能のデフォルト設定と、アカウントグループに適用される制約が決まります。個々のアカウントに別の設定ができ、変更した設定はすべて、提供サービスの設定にオーバーライドします。提供サービスの更新時、提供サービスにオーバーライドする設定のあるアカウントには、その更新は反映されません。

メールのメッセージング機能

使用できるメールメッセージ機能はシステム管理者によって設定・管理されます。ユーザーはその使用できる機能のほとんどについて、プリファレンスから管理することができます。

デフォルトでは、ユーザー自身がプリファレンスを管理できますが、ユーザー側でアカウントのプリファレンスを修正できないように制御することもできます。現在サポートされているZWCのメールメッセージ機能を、 メール機能の表にまとめて記載します。

Table 37. メール機能
メールメッセージ機能 説明

メール

メールのアプリを有効にする。デフォルトで有効です。

管理コンソールの参照先: 提供サービス名 > 機能 → 主な機能 コンテナ

スレッド

メッセージを共通のスレッドとしてグループ化することができます。デフォルトではReferencesヘッダー項目によりメッセージをスレッド化します。Referencesヘッダーが存在しない場合、件名を使用します。

デフォルトを変更するには、提供サービスまたは個々のアカウントの zimbraMailThreadingAlgorithm を編集します。 詳細は スレッドのデフォルト値を変更する を参照してください。

この機能が有効なとき、スレッド表示はデフォルトのビューです。提供サービスのプレファレンスでデフォルトビューを変更できます。ユーザーからもデフォルト変更が可能です。

管理コンソールの参照先: 提供サービス名 > 機能 → メールの機能 コンテナ

HTML 作成

メッセージを作成する際に、HTMLの編集機能を利用できます。また、デフォルトのフォント設定をプリファレンスとして指定できます。

管理コンソールの参照先: 提供サービス名 > プリファレンス → メールを作成 コンテナ

下書きとして自動保存する間隔

下書きを自動保存する頻度。デフォルトでは30秒ごとに自動保存されます。ユーザーはこの頻度を変更できませんが、下書き自動保存機能を無効化することはできます。

管理コンソールの参照先: 提供サービス名 > プリファレンス → メールを作成 コンテナ

後でメールを送信

有効なとき、ユーザーは後からメッセージ送信する 後で送信 オプションを選択できます。ユーザーは送信する日時を設定できます。メッセージは下書きフォルダに保存されます。

管理コンソールの参照先: 提供サービス名 > 機能 → メールの機能 コンテナ

メッセージの優先度

有効なとき、ユーザーはメッセージの優先度を設定できます。受信者は、メッセージの優先度を表す高低フラグをZWCから確認できます。

管理コンソールの参照先: 提供サービス名 > 機能 → メールの機能 コンテナ

添付ファイルのインデックス作成を有効にする

添付ファイルがインデックスされます。インデックスされた添付ファイルは検索対象にできます。

管理コンソールの参照先: 提供サービス名 > 詳細設定 → 添付ファイル設定 コンテナ

任意のアドレスへのメール転送を許可

システム管理者は、ユーザーの利用できるデフォルトでの転送先アドレスを指定できます。ユーザーは、アカウントのプリファレンスタブから、この転送先アドレスを変更できます。

ユーザーに表示されない転送先アドレスも指定することができます。アカウントに送信されるメッセージのコピーは、指定された転送先アドレスに即座に転送されます。

管理コンソールの参照先: 提供サービス名 > 機能 → メールの機能 コンテナ

不在メッセージ

ユーザーは、受け取ったメッセージに対して自動返信するメッセージを作成できます。送信者が送信したメッセージの数にかかわらず、デフォルトでは7日間に1度だけ各送信者に自動返信を行います。この設定は、提供サービスのプリファレンスページにある 社内不在時のキャッシュ有効期間 から変更できます。

管理コンソールの参照先: 提供サービス名 > 機能 → メールの機能 コンテナ

新着メール通知用のアドレスを有効にする

ユーザーは、新着メッセージを知らせるアドレスを指定することができます。ユーザーはアカウントのプリファレンスからこの機能を有効・無効にしたり、アドレスを指定したりできます。

通知メッセージのテンプレート例の変更は 通知メールのテンプレートを カスタマイズ を参照してください。

管理コンソールの参照先: 提供サービス名 > 機能 → メールの機能 コンテナ

ペルソナ

有効なとき、別のルールを管理するアカウント名を追加作成できます。そのペルソナアカウントから送信するメッセージの差出人名にアカウントのエイリアスを選択したり、そのペルソナアカウント用の署名を設定したりできます。要件に応じて、作成できるペルソナ数を設定できます。最小値は0で、デフォルトは20です(zimbraIdentityMaxNumEntries)。

管理コンソールの参照先: 提供サービス名 > 機能 → メールの機能 コンテナ

メール署名の最大長

1つの署名内に使用できる最大文字数です。デフォルトは2014文字です。

ユーザーが作成できる署名の数は zimbraSignatureMaxNumEntries 内に設定されています。

管理コンソールの参照先: 提供サービス名 > プリファレンス → メールを作成 コンテナ

高度な検索

ユーザーは、日時、ドメイン、ステータス、タグ、サイズ、添付ファイル、Zimlet、フォルダによる、複雑な検索条件を作成することができます。

管理コンソールの参照先: 提供サービス名 > 機能 → 検索の機能 コンテナ

保存済み検索

ユーザーは、作成または実行していた検索条件を保存できます。

管理コンソールの参照先: 提供サービス名 > 機能 → 検索の機能 コンテナ

初回メール検索

有効なとき、デフォルトの検索メールボックスを変更できます。

管理コンソールの参照先: 提供サービス名 > 機能 → 全般的な機能 コンテナ

外部POPアクセス

有効なとき、ユーザーは、ZWCアカウントから直接、自身のPOPアカウントのメールメッセージを取得できます。ユーザーは、アカウント設定に、外部アカウントアドレスを追加します。

管理コンソールの参照先: 提供サービス名 > 機能 → メールの機能 コンテナ

外部IMAPアクセス

有効なとき、ユーザーは、ZWCアカウントから直接、自身のIMAPアカウントのメールメッセージを取得できます。ユーザーは、アカウント設定に、外部アカウントアドレスを追加します。

管理コンソールの参照先: 提供サービス名 > 機能 → メールの機能 コンテナ

アカウントのエイリアス

システム管理者は、アカウントのエイリアスを作成できます。ユーザーはこの変更ができません。

メールフィルター

ユーザーは、送受信メッセージとカレンダー予約に適用するルールや該当のアクションを定義できます。受信メールメッセージがフィルタールールの条件に合う場合、そのルールに紐づく該当のアクションが行なわれます。

受信メッセージへの迷惑メールチェックが実行完了した後に、ユーザーのメールフィルターが実行されます。 迷惑メールとして判断されたメッセージは迷惑メールフォルダに移されます。迷惑メールチェック中に誤って迷惑メールとして判断されないように、ユーザーは、プリファレンスメールフォルダから迷惑メールホワイトリストを作成して、これを防ぐことができます。 管理コンソールの参照先: 提供サービス名 > 機能 → メールの機能 コンテナ

フラグ付け

ユーザーは、フラグを作成して、メッセージや連絡先、ブリーフケースフォルダ内のファイルにそれを指定することができます。

管理コンソールの参照先: 提供サービス名 > 機能 → メールの機能 コンテナ

キーボードショートカットを有効にする

メールボックス内でキーボードのショートカットを利用できます。 プリファレンスのショートカットフォルダから、使用できるショートカット一覧を確認できます。

管理コンソールの参照先: 提供サービス名 > プリファレンス → 全般オプション コンテナ

グローバルアドレスリストアクセス

ユーザーはメールメッセージに使う名称を検索するために会社のディレクトリにアクセスできます。

管理コンソールの参照先: 提供サービス名 > 機能 → 全般的な機能 コンテナ

GALのオートコンプリート

有効なとき、ユーザーがメール作成時にヘッダー何文字か入力すると、GALに存在する名称が利用ランクに応じて表示されます。詳細は オートコンプリートで表示する名前のランク を参照してください。

管理コンソールの参照先: 提供サービス名 > 機能 → 全般的な機能 コンテナ

アドバンスド(AJAX)クライアントによるオフラインのサポート

有効なとき、Zimbraウェブクライアントを使用中のユーザーは、ネットワークに接続せずに、オフラインモードを利用したデータアクセスが可能です。詳細は「製品の概略」章のオフラインモードを参照してください。

管理コンソールの参照先: 提供サービス名 > 機能 → 全般的な機能 コンテナ

IMAP アクセス

IMAPプロトコルを使用中のユーザーは、サードパーティのアプリケーションを利用してメールボックスにアクセスできます。

提供サービスや各アカウントの 詳細設定 ページにある データソース > IMAP のポーリング間隔セクションからポーリング間隔を設定できます。デフォルトでは、ポーリング間隔は設定されていません。

管理コンソールの参照先: 提供サービス名 > 機能 → メールの機能 コンテナ

POP3 アクセス

POPプロトコルを使用中のユーザーは、サードパーティのアプリケーションを利用してメールボックスにアクセスできます。POPメールメッセージを取得するとき、メッセージと添付ファイルはZimbraサーバーに保存されます。
ユーザーの プリファレンス > メール にて、

  • メッセージダウンロード方法

  • ごみメールを含めるか否か。ごみメッセージは、受信箱にダウンロードされます。

  • POPアカウントメッセージの削除方法

提供サービスや各アカウントの 詳細設定 ページにある データソース > POP3 のポーリング間隔セクションからポーリング間隔を設定できます。デフォルトでは、ポーリング間隔は設定されていません。

管理コンソールの参照先: 提供サービス名 > 機能 → メールの機能 コンテナ

オートコンプリートで表示する名前のランク

オートコンプリートの機能は、呼ばれた頻度の最も高い名称を上から順にリストアップします。ユーザーは、上位にリストアップ表示させたくない連絡先については 無視 をクリックすることで、連絡先名称をランク付けし直すことができます。

ユーザーが管理するメールプリファレンス

本項で説明するほとんどのプリファレンスのデフォルト動作は、管理コンソールの提供サービスまたは各アカウントのプリファレンスから設定できます。ユーザーは、アカウントのプリファレンスメールページから、下記のメールプリファレンスを修正すること ができます。

  • ウェブクライアントが新着メッセージをチェックする分単位の頻度。

  • メールメッセージの警告通知を設定・変更します。警告方法として、音を鳴らす、メール新着にタブをハイライトさせる、ブラウザをフラッシュする、からセットアップできます。

  • Zimbra Collaborationの使用言語を設定します。ZCSに複数のロケールがインストールされている場合、ブラウザの言語とは異なるロケールを選択することができます。

  • 送信メッセージのコピーを送信済みフォルダに保存するか否か。

  • 転送メッセージのコピーを保存するかメールボックスから削除するか。

  • メッセージの新規作成を別ウィンドウで行なうか否か。

  • HTMLを含むメッセージをHTMLで表示するかプレインテキストで表示するか。

  • 必要時に閲覧済み確認を送信するか否か。

  • 出力されるメッセージのフォントサイズを変更します。デフォルトは12ptです。

  • ユーザーは、プリファレンスメールフォルダから、受信メッセージのフィルタリングに使用するホワイトリストとブラックリストの独自の迷惑メールオプションをセットアップできます。各リストのデフォルトの最大アドレス数はそれぞれ100です。この値は、提供サービスや各アカウントごとに、コマンドラインの zmprov を使用して変更可能です。 属性は、zimbraMailWhitelistMaxNumEntrieszimbraMailBlacklistMaxNumEntries です。

  • ユーザーは、 プリファレンス署名 ページから、次のメールプリファレンスを修正できます。

    • 送信メッセージに自動署名を付けるか否か。

    • 返信するメッセージや転送するメッセージの作成方法のプリファレンス。

インポートやエクスポートを使用したユーザーデータの保存

ユーザーは、プリファレンスインポート/エクスポート ページから、メールメッセージ、連絡先、カレンダー、タスクを含むすべてのアカウントデータをエクスポートできます。アカウント内の特定のアイテムをエクスポートして、パソコン内や他の場所にそのデータを保存することができます。

アカウントデータは、アカウントの復元のためにインポート可能なtar-gzip (tgz)のアーカイブファイルとして保存されます。連絡先は .csvファイルとして保存され、カレンダーの予定は .icsファイルとして保存されます。コピーされたデータでもアカウントからは削除されません。

エクスポートしたアカウントデータファイルは、WinRARなどのアーカイブ処理ソフトを使用して、閲覧できます。同ページからすべてのファイルがアカウントにインポートできます。

インポート/エクスポートの機能を 提供サービス や各 アカウント機能 ページから、無効にすることができます。

RSSのポーリング間隔の設定

ユーザーは、RSSの提供とフィードの公開をしているウェブサイトを定期的に読み込んだり、その更新情報を直接メールボックスに受信したりできます。フィードは最大50個返されます。なお、RSSフィードで受信したデータ量は、ユーザーのアカウント容量にカウントされます。

デフォルトは、RSSデータの12時間毎の更新です。ユーザーは、RSSフィードフォルダを右クリックして、新しいフィードをマニュアル操作で更新できます。

RSSのポーリング間隔は、管理コンソールの提供サービスまたは各アカウントの 詳細設定 ページにある データソース > RSSのポーリング間隔 から変更できます。

連絡先リスト機能

Zimbraの連絡先リストでユーザーは、連絡先リストを複数作成したり、メール送受信時、自動で連絡先の名称を追加することができます。連絡先を連絡先リストにインポートすることができます。

ユーザーがメールフォルダ、連絡先リスト、カレンダー予定を共有するには、全般的な機能設定コンテナにある 共有 を有効にする必要があります。

ホーム > 設定 > 提供サービス → 提供サービス名 → 機能 → 全般的な機能設定

Table 38. 連絡先リストの機能
機能名 説明 提供サービス/アカウントタブ

連絡先

ユーザーはパーソナルな連絡先リストが作成できます。デフォルトで、連絡先リストとメッセージ送信済み連絡先リストが作成されます。

機能

フォルダの最大許容連絡先数

全連絡先リストに入れられる連絡先の最大数です、0は無制限を表します。

詳細設定

ユーザーは自身のアカウントの プリファレンス連絡先ページ から連絡先リストのプリファレンスを修正できます。

デフォルト動作の設定

管理コンソール:

ホーム > 設定 > 提供サービス → 提供サービス名 → プリファレンス
ホーム > 管理 > アカウント → アカウント名 → プリファレンス

  • 連絡先の自動追加を有効にする: 新たなアドレスへのメッセージ送信時、送信済みリストにその連絡先が自動追加されます。

  • 連絡先を選択する場合、グローバルアクセスリストを使用する。

  • アドレスをオートコンプリートするときにGALを使用: 宛先などの入力時、GALのアドレスや名前もオートコンプリート対象として検索します。

カレンダー機能

Zimbraカレンダーでユーザーは、予定や会議のスケジューリング、繰り返しイベントの登録、複数カレンダーの作成、他ユーザーとのカレンダー共有、委任された管理者による自身のカレンダーへのアクセスを行なうことができます。外部カレンダーの定期的な読み込みとZimbraウェブクライアントからのカレンダー情報の閲覧ができます。カレンダーにある予定を検索することもできます。

ユーザーがカレンダー、連絡先リスト、ブリーフケースのファイルを共有するには、全般的な機能設定コンテナにある 共有 を有効にする必要があります。

管理コンソール:

ホーム > 設定 > 提供サービス → 提供サービス名 → 機能 → 全般的な機能

Table 39. カレンダー機能
カレンダー機能 説明 提供サービス/アカウントタブ

カレンダー

ユーザーは、カレンダーの維持、会議のスケジューリング、自身のカレンダーへのアクセスの委任、複数のパーソナルカレンダーの作成、などが可能です。

機能

グループカレンダー

グループカレンダーが無効の場合、個人的な予定の作成と会議への参加承諾だけが可能です。参加者、スケジュール、リソース検索タブは表示されません。

機能

ネストされたカレンダー

メール、連絡先、カレンダーフォルダと同様、カレンダーをZCSのフォルダ内にネストすることができます。管理者はCLIを利用してネストされたカレンダーリストを作成できます。移行時、ネストされたカレンダーグルーピングをインポートすることができます。 下記例を参照してください。

タイムゾーン

カレンダーのスケジューリングに使用するタイムゾーンを設定します。ドメイン管理者は、管理コンソールのアカウントにある全般情報ページでこの設定をします。

プリファレンス

以下のアドレスにカレンダー招待を転送

ユーザーのカレンダー招待の転送先アドレスを指定できます。ユーザーも、プリファレンスカレンダーフォルダーから、転送先アドレスを指定することができます。
招待が転送されるアカウントからその招待に返信するには、共有カレンダーに対する管理権限が必要です。

各アカウントの転送設定

<カレンダー名>フォルダ配下に、新たなカレンダーを作成します。

zmmailbox -z -m user1 cf -V appointment "/カレンダー名/サブカレンダー名"

カレンダーの予定に関する問題のトラブルシューティング

zmcalchk コマンドを使用して、同じ会議について、複数ユーザーのカレンダー同士をチェックし、矛盾があればメッセージを通知します。

予定が一致していないときにもこのコマンドを使用して、予定の所有者や全参加者に通知することができます。

リモートカレンダーの更新間隔の変更

リモートカレンダーはデフォルトで12時間ごとに更新されます。この頻度は管理コンソールから修正できます。

管理コンソールからカレンダーの更新間隔を修正するには、提供サービスや各アカウントの 詳細設定 ページから、データソース > カレンダーのポーリング間隔 項目に遷移します。

参加者による予定編集の無効化

参加者が自身のカレンダー予定に対して行なった変更は、他のユーザーには共有されません。予定の所有者が変更した場合、その変更によって、編集後の参加者の予定が上書きされます。システム管理者は、提供サービスの属性 zimbraPrefCalendarApptAllowAtendeeEdit を変更して、参加者が本人のカレンダー予定を編集できないようにできます。

zmprov mc <cosname> zimbraPrefCalendarApptAllowAtendeeEdit FALSE

その他のカレンダーのプリファレンスを設定

ユーザーはカレンダープリファレンス表のカレンダープリファレンスを修正できます。デフォルト動作は提供サービスやアカウントのプリファレンスページで設定可能です。

カレンダープリファレンス 説明

タイムゾーン

ユーザーのプリファレンスに表示されるタイムゾーン。詳細は デフォルトのタイムゾーンを設定するを参照してください。提供サービスでタイムゾーンを設定した場合、ドメインに設定したタイムゾーンは無視されます。

予定のリマインダーを表示する時間(分)

会議前にリマインダーを通知を送信する時間を分単位で設定します。

最初のカレンダービュー

デフォルトのビューを設定します。日、週、週平日、月、予定、リストで設定可能です。

週の最初の曜日

仕事を開始する曜日を設定します。

デフォルトの予定表示

パブリックかプライベートかの設定ができます。新規予定ページでのデフォルト表示オプションです。

デフォルト設定はパブリック、予定の詳細は他のユーザーから閲覧可能です。

デフォルトがプライベートのとき、全ての受信カレンダー招待がプライベートとしてユーザーのカレンダーにマークされ、詳細は非表示とされます。

CalDAVインターフェイス用に共有カレンダーのiCal委任モデルを使用

CalDAVのプロトコルを使用して、Apple iCalをユーザーのカレンダーにアクセスするように設定できます。有効なとき、共有カレンダーがユーザーのiCalアカウントの委任タブに表示されるため、ユーザーはカレンダーへのアクセスを委任することができます。

自動ポーリングについては、提供サービスまたは各アカウントの 詳細設定 ページ内の データソース > CalDAVのポーリング間隔 項目からポーリング間隔を設定できます。

期限切れリマインダーを有効にする

ユーザーがZWCへログインすると、過去2週間分の削除されていないリマインダーがポップアップで表示されます。無効のとき、Zimbra Collaborationは古いリマインダーを自動削除します。

新着カレンダーイベントのためのToaster通知を有効にする

新しいカレンダーイベントの受信時、ZWCにポップアップを表示します。

キャンセルメールを作成者に送信することを許可

ユーザーが予定日時に参加できない予定に招待された時、 新しい時間を提案 のボタンをクリックし、別の日時を選択・提案できます。予定の所有者は、その提案日時をメールで受け取ります。

PUBLISHメソッドを使って招待を自動追加

カレンダー招待メールは、そのカレンダーオブジェクト内に method=REQUEST を含んでいなければなりませんが、なかには誤って method=PUBLISH を使用しているサードパーティ製メールクライアントもあります。 こうしたメールはデフォルトでは処理されません。このオプションを有効にし、ルールを緩めることができます。

転送された招待をカレンダーに自動追加

ユーザーに転送された招待が、転送受信者のカレンダーに自動追加されます。

予定のリマインダー時にブラウザのタイトルを点滅

予定のリマインダーがポップアップすると、ユーザーがそのポップアップを閉じるまでブラウザが点滅します。

可聴予定通知を有効にする

予定のリマインダーがポップアップすると、ユーザーはコンピュータが鳴らす音で気づかされます。ユーザーは、QuickTimeまたはWindows Mediaをインストールしている必要があります。

招待を拒否されたユーザーからの招待を自動拒否

ユーザーは、カレンダーの招待を送ってくる相手を設定することができます。有効なとき、ユーザーを招待する権限のない者に対しては、それを知らせる自動返信メッセージが送られます。

招待時に予定を自動追加

有効なとき、ユーザーのデフォルトカレンダーに予定が自動追加され、拒否した予定はZWCのカレンダーにグレーアウトされて表示されます。

モバイルデバイスから予定を閲覧した場合、拒否した予定がグレーアウトで表示されないため、その招待が削除されたことが分からない可能性ががあります。

委任アクセスを通じて行われた変更を通知

カレンダーへのアクセスを委任しているユーザーには、予定が委任アクセス権限で変更されたことが通知されます。

常にミニカレンダーを表示

カレンダーのビューにミニカレンダーが自動表示されます。

新しい予定を作成するときに簡易追加ダイアログを使用

有効なとき、カレンダー上でのダブルクリックまたはドラッグ時、簡易追加ダイアログが表示されます。

予定ビューにタイムゾーンリストを表示

有効なとき、タイムゾーンのリストが予定ダイアログに表示されるため、使用するタイムゾーンを予定作成中に変更することができます。

Zimbraのタスクのセットアップ

Zimbraのタスクでユーザーは、タスクのToDoリストを作成して、完了までの管理ができます。

ユーザーによるタスクリストの共有には、機能ページで 共有 を有効にする必要があります。タスクリストの共有は、個人、グループ、パブリックに対して実施可能です。

タスクの機能の有効化/無効化

 管理コンソール:

ホーム > 設定 > 提供サービス → 提供サービス名 → 機能
ホーム > 管理 > アカウント → アカウント名 → 機能

ZimbraのウェブクライアントのUIテーマ

ZimbraウェブクライアントのUIの見え方を変更できます。ZCSにはZimbraテーマが多数備わっており、また、他にもユーザーがテーマを作成できます。システム管理者は、デフォルトとするテーマの設定や、ユーザーが使い勝手を良くするためのカスタマイズで選択できるテーマの指定ができます。テーマ開発の詳細は、 テーマ色やロゴ管理 を参照してください。

次のテーマを使用する際のオプションは、提供サービスまたは各アカウントから設定できます。

  • ユーザーを特定のテーマに限定する

    機能のページで UIテーマを変更 のチェックを外します。ZWCのテーマは、テーマページの 現在のUIテーマ にリストアップされているテーマのみです。

  • ユーザーはZimbraにインストールしたテーマを自由に設定する

    UIテーマを変更 が有効なとき、ユーザーは、使用できるテーマのリストのどのテーマへもアクセスできます。

2要素認証

2要素認証(2FA)機能によって、システム内の特定のユーザー、全ユーザー、特定のメールボックス、あるいは全ての重要なメールボックスに適用しうる、セキュリティの二次要件を設定することができます。2FAは、ユーザーアカウントや提供サービスに設定できます。

新しいユーザーアカウントの2FA

新しいアカウントのセットアップ画面には、他の 詳細設定 に並んで2FAの設定があります。

管理コンソール:

ホーム → 3 アカウントの追加 → 1. アカウントの追加
 — 次へ詳細設定 まで進み、2要素認証 までスクロールダウンします。

New Account Two Factor Authentication

パラメーターに関する説明は、 2要素認証パラメーター を参照してください。

既存のユーザーアカウントの2FA

既存アカウントの場合、詳細設定 オプションから2FAを適用できます。

管理コンソール:

ホーム > 管理 > アカウント

次の手順で、アカウントの設定にある 2要素認証 コンテナに編集モードで遷移します。

  1. アカウント一覧から アカウント名 を選択します。

  2. 画面右上 ギア アイコンから 編集 を選択します。

     —  このアカウントの 全般情報 が表示されている状態になります。

  3. 画面の左パネルから 詳細設定 を選択します。

  4. 画面中央にある 2要素認証 コンテナまでスクロールダウンします。

Edit Account Two Factor Authentication

パラメーターに関する説明は、 2要素認証パラメーター を参照してください。

提供サービスの2FA

提供サービスの2FA設定に使用できるパラメーターは、他の詳細設定機能と同じところにあります。

提供サービスに2FAを適用するには、パラメーターを設定する 2要素認証 コンテナを使用します。

管理コンソール:

ホーム > 設定 > 提供サービス → 提供サービス名 → 詳細設定 → 2要素認証

Class of Service Two Factor Authentication

パラメーターに関する説明は、 2要素認証パラメーター を参照してください。

Table 40. 2要素認証パラメーター
パラメーター 説明

2要素認証を有効にする

選択したCOSアカウントに対する本機能の有効(チェック有り)または無効(チェック外し)を設定します。

2段階認証が必要

選択したCOSアカウントに対して、本機能の利用を必須とするなら有効(チェック入り)に、それ以外は無効(チェックなし)にします。

生成するワンタイムコードの数

アカウントがシステムへのアクセスを試行する時に表示/入力されうる、最大6桁まで指定されるパスコードの値。初回ログイン認証が通ったアカウントには、パスコードが存在します。

各パスコードの寿命は15秒です。

アプリケーションパスコードを有効にする

2要素認証をサポートしていない古いアプリケーションには、例外的なコードを生成できます。

その他のアカウント設定

共有を有効にする

共有機能が有効なとき、ユーザーは、メールメッセージ、カレンダー、連絡先リスト、タスクリスト、ブリーフケースを含む、すべてのフォルダを共有できます。

ユーザーは、与えるアクセスの権限をタイプで指定します。ユーザーは、完全な管理者アクセスのある内部ユーザーや、フォルダ内容の閲覧にパスワードを要する外部ユーザーとの共有が、フォルダ内容が閲覧できるURLがあれば誰でもアクセスできる公開アクセスと同様に、実施できます。

内部ユーザーがメールフォルダを共有したとき、共有フォルダのコピーが共有相手の概要ペインにあるフォルダリストに追加されます。ユーザーは、ZWCのプリファレンス共有ページから、自身の共有フォルダを管理できます。

SMSでの通知設定

ZWCの プリファレンス→通知 ページでユーザーは、タスクやカレンダーにある予定のリマインダーをモバイルデバイスで受け取るように、メールアドレスやSMSへの通知を設定することができます。SMSでの通知は、デフォルトでは無効です。

SMSでの通知は、ドメイン、提供サービス、各アカウントごとに設定できます。提供サービスで設定したSMS通知は、ドメインでの設定にオーバーライドします。管理コンソールでは、ドメイン、提供サービス、各アカウントにある機能ページで設定します。

SMS通知のセットアップ時、ユーザーは、地域とキャリアを選択します。SMS/メールのゲートウェイのリストは ZmSMS.properties に入っています。このリストをカスタマイズして、リストにないSMS/メールのゲートウェイを追加できます。

添付ファイルの閲覧設定

添付ファイルの閲覧ルールは、グローバル設定、提供サービスの設定、特定のアカウントの設定として、設定できます。グローバル設定は、提供サービスやアカウントの設定にオーバーライドします。以下の4つのオプションが使用できます。

Table 41. 添付ファイルの閲覧機能
機能名 説明 提供サービス/アカウントタブ

ウェブメールで添付ファイルを表示させない

添付ファイルを閲覧できません。これはグローバル設定でも適用可能です。

詳細設定

HTML形式でのみ表示可能

受信した添付ファイルの形式を問わず、HTML形式として開きます。

詳細設定

元の形式でのみ表示可能

コンピュータに登録されていない専用のアプリケーションを必要とする添付ファイルの場合、開けないことがあります。

詳細設定

HTML形式あるいは元の形式で表示可能

ユーザーは、添付ファイルを元の形式で開くか、HTML形式で開くかを選択できます。

詳細設定

ユーザーが外部サイトへ移るときに警告メッセージを表示する

ユーザーは、アカウントからログアウトする前に、ブラウザにある戻る矢印や進む矢印、ブラウザを閉じる、をクリックすることができます。

  • このプリファレンスが有効な場合、ユーザーがアカウントから外部へ移るときに確認プロンプトが表示されます。

  • このプリファレンスが無効な場合、確認プロンプトは表示されません。

ウェブクライアントのチェックボックスを有効にする

バッチ操作用のリストビューにメール、連絡先、ボイスメールの項目を選択するためのチェックボックス表示 が有効な場合、ユーザーがコンテンツペインにあるメッセージ、連絡先、タスクリストを閲覧するときに、各アイテムにチェックボックスが追加されます。ユーザーは、アイテムを選択したのち、選択したその全アイテムに一括でアクションを実行することができます。アクションとは例えば、既読/未読、特定のフォルダへの移動、フォルダへのドラッグ&ドロップ、削除、タグを付ける、などです。

プリファレンスのインポート/エクスポート

ユーザーはプリファレンスの「インポート/エクスポート」ページから、メールメッセージ、連絡先、カレンダー、タスク、ブリーフケースフォルダを含むすべてのアカウントデータをエクスポートできます。アカウント内の特定のアイテムをエクスポートして、パソコン内や他の場所にそのデータを保存できます。アカウントデータは、アカウントの復元のためにインポート可能なtar-gzip (tgz)のアーカイブファイルとして保存されます。連絡先は .csvファイルとして保存され、カレンダーの予定は .icsファイルとして保存されます。コピーされたデータでもアカウントからは削除されません。エクスポートしたアカウントデータファイルは、WinRARなどのアーカイブ処理ソフトを使用して、閲覧できます。同ページからすべてのファイルがアカウントにインポートできます。

ユーザーに「インポート/エクスポート」の機能を使用させたくない場合、提供サービスや各アカウントの機能ページから、無効にすることができます。

スペルチェック辞書への単語登録

ZWCユーザーが、ZWCのスペルチェック中にスペルエラーとしてマークされる単語や略語を頻繁に使用している場合、システム管理者は、提供サービスやドメインの属性 zimbraPrefSpellIgnoreWord に、スペルチェック時に対象外とする単語を追加更新できます。

ドメインに対象外とする単語を設定

zmprov md example.com +zimbraPrefSpellIgnoreWord <word> +zimbraPrefSpellIgnoreWord <word2>

Zimbra の階層制度アドレス帳 (Hierarchical Address Book、HAB)

HAB について

ご注意ください: ZCS 8.8.15 の初期リリースでは階層制度アドレス帳 (Hierarchical Address Book、HAB)は英語でのみサポートしています。今後のパッチリリースに他の言語のサポートを提供する予定となっております。

階層制度のアドレス帳 (HAB) ではユーザー様がアドレス帳に部署の単位で宛先を検索することが可能となります。ほとんどの場合、ユーザー様はデフォルトのグローバルアドレス帳(GAL)のデフォルト単位のみをアクセスできますので、部署の詳細、同じ名前の人の区別、などを簡単に特定できない状況です。HABを実際のビジネス単位へカスタマイズすることで、ユーザー様に内部の宛先をより効率的に検索することが可能となります。

階層制度アドレス帳の運用について

階層制度アドレス帳 (HAB) では、ルート会社(例えば Zimbra)がトップレベルとなります。そのトップレベルの下に複数の子レベルを追加し、異なる部署や課、などを自由に指定することができます。以下の図では、以下の仕様の Zimbra 用の HAB の事例を紹介しています。

  • トップレベルはルート会社を示している、つまり Zimbra です。

  • 子レベルに Zimbra の異なるビジネス課を示している、つまり管理課, エンジニア課, カスタマーサポート課, および営業部です。

  • さらなる子レベルに各管理課, エンジニア課, カスタマーサポート課, および営業部に別れている部署やチームを示しています。

HABHierarchy
Figure 1. 階層制度の事例

年功序列

年功序列 は階層制度にさらなるカスタマイズできるレベルとなります。HABを作成する際、このパラメータで特定のユーザーや部署を各レベル内で年功序列のランクを与えることが可能です。このランクでは、HABが表示する宛先の人物やグループの順番を指定されます。年功序列が高いほど、リストの順番が他のユーザーやグループの先に表示されます。例えば:

  • 副社長を 100

  • 本部のオペレーションマネジャーを 50

  • ビジネスの管理者を 25

年功序列 のパラメータが設定していない、またはほかのユーザーアカウントと一致している場合、HABの基準順番はアルファベット順となります。

階層制度アドレス帳の設定方法について

organizational unit (OU) を作成する

操作コマンド
zmprov createHABOrgUnit <OUのドメイン名> <OU名>
使用例

organizational unitとして_ZimbraOU_を作成します。

zmprov createHABOrgUnit example.com ZimbraOU

この OU にグループを作成する

各部署にグループを作成し、メールアドレスを関連させる必要があります。

操作コマンド
zmprov createHABGroup <グループ名> <OU名> <グループのメールアドレス>
使用例

以下のコマンドでは、階層制度の事例 を参考し、8 の HAB グループを作成します。

zmprov createHABGroup Zimbra ZimbraOU zimbra@example.com
zmprov createHABGroup CorporateOffice ZimbraOU CorpOffice@example.com
zmprov createHABGroup Engineering ZimbraOU eng@example.com
zmprov createHABGroup ProdSupport ZimbraOU prodsupport@example.com
zmprov createHABGroup SalesAndMarketing ZimbraOU sales-mark@example.com
zmprov createHABGroup HumanResources ZimbraOU hr@example.com
zmprov createHABGroup Accounts ZimbraOU accounts@example.com
zmprov createHABGroup Administration ZimbraOU administration@example.com

階層制度を作成する

階層制度を作成するため、(Zimbra のグループ以外に)各グループ親のグループを関連する必要があります。

操作コマンド
zmprov addHABGroupMember ParentGroupEmailAddress ChildGroupEmailAddress
使用例

以下のコマンドでは、階層制度の事例 の階層制度を参考し、Zimbra のグループがルートのグループであるため、7 の HAB グループに親グループを指定します。

以下では、Human Resources, Accounts, および Administration の親グループを Corporate Office に指定し、Corporate Office, Engineering, Product Support, および Sales & Marketing の親グループを Zimbra に指定します。

zmprov addHABGroupMember CorpOffice@example.com hr@example.com
zmprov addHABGroupMember CorpOffice@example.com accounts@example.com
zmprov addHABGroupMember CorpOffice@example.com administration@example.com
zmprov addHABGroupMember zimbra@example.com CorpOffice@example.com
zmprov addHABGroupMember zimbra@example.com eng@example.com
zmprov addHABGroupMember zimbra@example.com prodsupport@example.com
zmprov addHABGroupMember zimbra@example.com sales-mark@example.com

Zimbra ID を取得する

zimbraId は各メールアドレスに関連している一意的に指定されている認識IDです。このパラメータでは ユーザーをグループに閲覧すること および グループがルートとして指定する ことができます。

要注意:以下の事例、および他の事例にも、zimbraId を代表するために仮の値 (xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx) を使用しています。

操作コマンド
zmprov gdl <グループのメールアドレス> zimbraId
使用例
zmprov gdl zimbra@example.com zimbraId
使用例のサンプル出力
# distributionList zimbra@example.com memberCount=4
zimbraId: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
詳細

ルートのグループとして指定するグループのメールアドレスは zimbra@example.com です。

グループへユーザーを追加する

以下の事例では、他のユーザーへ影響を与えずに CorporateOffice のグループへ Jane DoeJohn Smith のユーザーを追加します。

操作コマンド
zmprov addHABGroupMember <グループのメールアドレス> <ユーザーのメールアドレス>
使用例
zmprov addHABGroupMember hr@example.com jane.doe@example.com
zmprov addHABGroupMember accounts@example.com john.smith@example.com

年功序列を設定する

HAB でグループが表示する順番を指定します。年功序列が高いグループが他のグループより先表示されます。

操作コマンド
zmprov modifyHABGroupSeniority <zimbra ID> <年功序列>
使用例

グループ名とアルファベット順を問わず、Engineering のグループを CorporateOffice の上に表示させるため、 Zimbra ID を取得し、SeniorityIndexNumber に指定する年功序列の重要性を特定し、以下のコマンドを実行します。

CorporateOffice に年功序列を 90 に指定する

zmprov modifyHABGroupSeniority xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx 90

Engineering に年功序列を 100 に指定する

zmprov modifyHABGroupSeniority xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx 100

要注意:グループに年功序列を指定しますと、そのグループにあるユーザーにも 年功序列 が設定されます。

HAB のルート会社を指定する

階層制度を作成するために1つのグループをルートのグループとして指定し、他のグループがそのグループの子グループとして指定する必要があります。なお、以下のコマンドでは、 zimbra@example.com をルートとして指定します。

操作コマンド
zmprov md <ドメイン名> zimbraHierarchicalAddressBookRoot <ルートとして指定するグループの ZimbraID>
使用例
zmprov md 'example.com' zimbraHierarchicalAddressBookRoot xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
使用例のサンプル出力
# distributionList zimbra@example.com memberCount=4
zimbraId: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

正常に設定されたことを確認する方法

  1. Zimbra のウェブクライアントへログインします。

  2. 新しいメッセージ をクリックします。

  3. メールの 作成 ウィンドウにて、宛先 のボタンをクリックします。

  4. アドレスを選択 のウインドウにて、右上から 名前の表示元 ドロップダウンメニューをクリックします。

  5. 階層制度アドレス帳 を選択します。

  6. 左側のリストに階層制度アドレス帳が表示されます。

    HABStructure zimbra
  7. グループをクリックしますと、そのグループにあるユーザーを閲覧し、メールの宛先として選択することが可能です。

部門名 (Organizational Unit, OU) の管理

部門名 (OU)をリストする

ドメインに複数の部門名を含まれる場合があります。このコマンドで指定したドメインにあるすべての部門名をリストします。

構文
zmprov listHABOrgUnit <OUのドメイン名>
使用例

example.com のドメインにあるすべての OU リストを表示します。

zmprov listHABOrgUnit example.com ZimbraOU

部門名 (OU) の名前を更新する

このコマンドで指定したドメインにある特定の OU の名前を更新します。

構文
zmprov renameHABOrgUnit <OUのドメイン名> <OU名> <新しいOU名>
使用例

ZimbraOU の名前を ZMXOU へ更新します。

zmprov renameHABOrgUnit example.com ZimbraOU ZMXOU

部門名 (OU) を削除する

このコマンドで指定したドメインにある特定の OU を削除します。

構文
zmprov renameHABOrgUnit <OUのドメイン名> <OU名>
使用例

ZimbraOU を削除します。

zmprov renameHABOrgUnit example.com ZimbraOU

ユーザーアカウントのプロビジョニング

アカウントがプロビジョニングされると、システム管理者はメールボックスを作成し、当初のメールアドレスを設定し、Zimbra Collaborationのアプリケーションおよび機能を使用するために提供サービスを適用します。

アカウントを1つずつ設定することも、別サーバーから複数の既存アカウントを移行することもできます。

ユーザーアカウントを作成する

ユーザーアカウントを追加する前に、使用する機能やアクセス権限を決める必要があります。対象の機能を持つ提供サービスをアカウント作成時に設定することも可能ですし、機能をアカウントに個別設定することも可能です。詳細は アカウントの提供サービスについて を参照してください。

アカウントへ設定した提供サービスに適切な機能が備わっている場合、アカウントに個別設定を追加で行なう必要はありません。 アカウントを作成するとZimbraのLDAPサーバーに適切な情報が設定されます。ユーザーが最初にログインしたとき、あるいはユーザーアカウント宛にメッセージが配信されたとき、メールボックスサーバー上にそのメールボックスが作成されます。

標準のアカウントを作成します。

管理コンソール:

ホーム → 3 アカウントの追加 → 1. アカウントを追加

  1. アカウント名 セクションにて、必要最低限の情報であるアカウント名と姓を入力します。

    デフォルト提供サービスが自動適用されます。

  2. 完了 をクリックし、アカウントを作成します。

続けて、個々のアカウントの特性や機能を設定することができます。アカウントに対する変更内容は提供サービスにオーバーライドします。

既存のアカウントの移行およびアカウントメールのインポート

Zimbra 管理コンソールのUI上での ZCS アカウント移行がサポート終了しており、2019年12月17日までテクニカルガイダンス期間となります。 なお、すべてのアカウント移行の代替案として、 audriga社の移行ソリューション の利用を推奨しております。

管理コンソールからアカウント移行用ウィザードを使用して、一度に複数のアカウントをプロビジョニングすることができます。一般IMAPサーバーや別のZCS サーバーからアカウントをインポートできます。

7.2以降のZCSに存在するアカウントのみZCS 8へ移行できます。

また、カスタム作成したXMLファイルからプロビジョニング対象のアカウント名をインポートすることも可能です。

移行用ウィザードで、アカウントのプロビジョニングとデータのインポートを一度に実行できます。または、1回目のウィザードでアカウントのプロビジョニング、2回目でそのアカウントにデータをインポートできます。

既存のLDAPディレクトリやXMLファイルからアカウントレコードを取得する場合、新たに作成するアカウント用パスワードの要件を設定しておく必要があります。選択肢には、アカウントごとにランダムなパスワードを自動生成する方法と全アカウントに同一パスワードを設定する方法があります。また、初回ログイン時にユーザーにパスワードを変更させることもできます。

プロビジョニングが完了すると、このウィザードが新規アカウント一覧の.csvファイルを作成します。このファイルに生成されたパスワードも含まれています。今後の参照用にダウンロードしておくことを推奨します。ただし、ファイルは安全な場所に格納してください。プロビジョニングしたアカウントのパスワード情報が含まれているからです。

スプリットされたドメイン環境を使用している場合、ウィザードにSMTPのホストとポートを設定できます。スプリットされたドメイン環境に関する詳細は以下のWiki記事を参照ください。 https://wiki.zimbra.com/wiki/Split_Domain

Zimbraサーバーからアカウントを移行する

ZCS 7.2.0以降に依存しているアカウントをZCS 8へ移行できます。

管理コンソール:

ホーム → 3 アカウントの追加 → 3. 移行と共存

  1. メールサーバーの種類 にて、 Zimbra Collaboration を選択します。

  2. アカウントをプロビジョニングしている場合、アカウントレコードをインポートしますかはい を選択します。メールのデータを今回インポートしない場合、メールをインポートしますかいいえ を選択します。

  3. 次へ をクリックします。

  4. 概要のページに 別のZimbra LDAPディレクトリからインポート が選択されていることを確認します。 次へ をクリックします。

  5. 一括提供オプション のページでパスワードをランダムに設定するか、固定のパスワードを設定するかを選択します。

    Table 42. 一括提供の機能
    一括提供の機能 説明

    各アカウントにランダムパスワードを生成

    ランダムパスワードの生成を選択した場合、パスワードの長さを設定する必要があります。パスワードは6から64文字まで設定可能です。

    デフォルトは8文字です。

    ランダムパスワードの生成を使用する場合、ユーザーへパスワードを伝えるためにアカウントとパスワードが発行される*.csvファイルをダウンロードする必要があります。

    すべての新規アカウントに同じパスワードを使用

    すべての新規アカウントに同様のパスワードを使用するを選択した場合、使用するパスワードを入力します。

    初回ログイン後にパスワードの変更をユーザーに要求

    ユーザーの初回ログイン時にパスワード変更を強制するようになるため、このオプションの使用を推奨します。

    SMTPホスト / SMTPポート

    スプリットのドメイン環境の場合、SMTPのホスト名とポートを指定します。

  6. 次へ をクリックします。

  7. ディレクトリ接続 のページでサーバーへ接続する情報を入力します。

    Table 43. ディレクトリ接続のオプション
    ないドメインを自動的に作成 詳細

    ないドメインを自動的に作成

    このオプションを有効にすると、アカウントのインポート時、アカウントのドメインが存在しない場合にドメインを作成します。

    このオプションを有効にしない場合、サーバーに存在しないドメインのアカウントは作成されません。無効にすると、事前に作成した特定のドメインのアカウントのみを簡単にインポートできます。

    取得する最大レコード数

    一度にインポートできる最大のアカウント数を指定します。基準は無制限 (0) となっています。

    サーバー名、LDAP URL、ポートおよびSSLを使用

    • LDAP URLは ldap://<ldapdirectory.example.com> の形で入力します。

    • デフォルトのポートは389ですが、変更できます。

    • SSLを使用している場合、チェックします。

    バインドDN

    Zimbraの設定はデフォルトで以下となります。 uid=zimbra,cn=admins,cn=zimbra

    バインドパスワード

    サーバーのパスワードを入力します。

    LDAPフィルター

    LDAP検索フィルターを指定します。インポートしたいアカウント情報の種類の検索条件を定義できます。デフォルトのフィルター (objectclass=zimbraAccount) では、メールアドレス、アカウントIDおよびアカウントの属性が含まれています。

    LDAP検索ベース

    LDAP全体に検索するサブセクションを指定します。

  8. 次へ をクリックします。

    アカウント移行のウィザード は指定したディレクトリサーバーへ接続し、確認したドメイン数、アカウント数、そしてZCS上で既に存在しているアカウント数を取得し、レポートとして表示します。また、指定したパスワードのオプションも表示します。

  9. 発行したレポートの確認後、次へ をクリックします。 アカウントは Zimbra Collaboration のサーバーにプロビジョニングされます。

  10. プロビジョニングされたアカウントとパスワードが記載されている.csvファイルをダウンロードします。なお、ウィザードを終了すると、発行した.csvファイルが自動的に削除されるため、再ダウンロードおよび再発行することができません。ご注意ください。

一般IMAPサーバーからアカウントを移行する

以下の手順にて、IMAPよりZimbraサーバーへアカウントをプロビジョニングできます。

管理コンソール:

ホーム → 3 アカウントの追加 → 3. 移行と共存

  1. メールサーバーの種類 にて、一般IMAPサーバー を選択します。

  2. アカウントをプロビジョニングしている場合、「アカウントレコードをインポートしますか」に はい を選択します。メールのデータを今回インポートしない場合、「メールをインポートしますか」に いいえ を選択します。

  3. 次へ をクリックします。

  4. 概要 のページで「別のZimbra LDAPディレクトリからインポート」が選択されていることを確認します。 次へ をクリックします。

  5. 一括提供オプション のページでパスワードをランダムに設定するか、固定のパスワードを設定するかを選択します。

    Table 44. 一括提供の機能
    一括提供の機能 説明

    各アカウントにランダムパスワードを生成

    ランダムパスワードの生成を選択した場合、パスワードの長さを設定する必要があります。パスワードは6から64文字まで設定可能です。

    デフォルトは8文字です。

    ランダムパスワードの生成を使用するを選択した場合、ユーザーへパスワードを伝えるためにアカウントとパスワードが発行される*.csvファイルをダウンロードする必要があります。

    すべての新規アカウントに同じパスワードを使用

    すべての新規アカウントに同様のパスワードを使用する場合、使用するパスワードを入力します。

    初回ログイン後にパスワードの変更をユーザーに要求

    ユーザーの初回ログイン時にパスワード変更を強制するようになるため、このオプションの使用を推奨します。

    SMTPホスト / SMTPポート

    スプリットされたドメイン環境の場合、SMTPのホスト名とポートを指定します。

  6. 次へ をクリックします。

  7. ディレクトリ接続 のページにサーバーへ接続する情報を入力します。

    Table 45. ディレクトリ接続のオプション
    ディレクトリ接続のオプション 説明

    ないドメインを自動的に作成

    このオプションを有効にすると、アカウントのインポート時、アカウントのドメインが存在しない場合にドメインを作成します。

    このオプションを有効にしない場合、サーバーに存在していないドメインのアカウントは作成されません。無効にすると、事前に作成した特定のドメインのアカウントのみを簡単にインポートできます。

    取得する最大レコード数

    一度にインポートできる最大のアカウント数を指定します。デフォルトは無制限 (0) となっています。

    サーバー名, LDAP URL, ポート, およびSSLを使用

    • LDAP URL は ldap://<ldapdirectory.example.com> The

    • デフォルトのポートは389ですが、変更できます。

    • SSLを使用している場合、チェックします。

    バインドDN

    サーバーのバインドDNを指定します。 uid=zimbra,cn=admins,cn=zimbra

    バインドパスワード

    サーバーのパスワードを入力します。

    LDAP フィルター

    LDAP検索フィルターを指定します。インポートしたいアカウントの情報の種類の検索条件を定義できます。デフォルトのフィルター (objectclass=zimbraAccount) では、メールアドレス、アカウントID、アカウント属性が含まれています。 フィルターを自由に変更できます。

    LDAP 検索ベース

    LDAP全体に検索するサブセクションを指定します。

  8. 次へ をクリックします。

    移行のウィザードは指定したディレクトリサーバーへ接続し、確認したドメイン数、アカウント数、そして ZCS上で既に存在しているアカウント数を取得し、レポートとして表示します。また、指定したパスワードのオプションも表示します。

  9. 発行したレポートの確認後、 次へ をクリックします。 アカウントはZimbra Collaborationのサーバーにプロビジョニングされます。

  10. プロビジョニングされたアカウントとパスワードが記載されている.csvファイルをダウンロードします。なお、ウィザードを終了すると、発行した.csvファイルが自動的に削除されますので、再ダウンロードおよび再発行することができません。ご注意ください。

XMLファイルからアカウントを移行する

インポートするアカウントの情報をXMLファイルに保存し、XMLファイルをZimbraへアップロードすることで、アカウントをプロビジョニングできます。

管理コンソール:

ホーム → 3 アカウントの追加 → 3. 移行と共存

  1. メールサーバーの種類 にて、元のサーバーの種類を選択します。

  2. アカウントをプロビジョニングしている場合、「アカウントレコードをインポートしますか」に はい を選択します。メールのデータを今回インポートしない場合、「メールをインポートしますか」に いいえ を選択します。

  3. 次へ をクリックします。

  4. 概要 のページに XMLファイルからインポート を選択し 次へ をクリックします。

  5. XMLファイルの横にある 参照 ボタンをクリックし、XMLファイルを選択します。次へ をクリックするとアップロードします。

  6. オプションを確認のページにて、XMLファイルに確認したドメイン数、アカウント数、そしてZCS上で既に依存しているアカウント数をレポートとして表示します。また、指定したパスワードのオプションも表示します。

  7. 内容に問題がない場合、次へ をクリックします。内容が正常ではない場合、XMLファイルを修正してから進みます。

    次へ をクリックした場合、XMLファイルに確認したアカウントはZimbra Collaborationサーバーへプロビジョニングされます。

  8. プロビジョニングされたアカウントとパスワードが記載している.csvファイルをダウンロードします。なお、ウィザードを終了すると、発行した.csvファイルが自動的に削除されますので、再ダウンロードおよび再発行することができません。ご注意ください。

特定のアカウントへメールをインポートする

メールのインポートをしたいアカウントリストを指定する場合、アカウントを選択するか、XMLファイルでアカウントを選択することで、指定できます。

この手順の作業を行なう前に、アカウントはZCS サーバー上にプロビジョニングされていなければなりません。
管理コンソール:

ホーム → 3 アカウントの追加 → 3. 移行と共存

  1. メールサーバーの種類 にて、元のサーバーの種類を選択します。

  2. アカウントレコードをインポートしますかいいえ を選択します。

  3. メールをインポートしますかはい を選択します。

  4. 次へ をクリックします。

  5. インポートのオプション のページで、メールをインポートするアカウントを指定する方法を選択します。

  6. 次へ をクリックします。

    インポートするアカウントを選択する場合、手順7へ進みます。 XMLファイルでアカウントを指定する場合、手順9へ進みます。

  7. インポートするアカウントを選択する場合、検索ボックスで追加するアカウントを検索します。ドメイン、またはユーザー名で検索できます。検索するテキストを入力せずに「検索」をクリックすると、すべてのアカウントが結果に表示されます。

    メールデータをインポートするアカウントを左から選択し、「追加」のボタンをクリックし、右の データインポートのためのアカウント リストへ移動します。

  8. 次へ をクリックします。

  9. XMLファイルでアカウントを指定する場合、「参照」より使用するXMLファイルを選択します。

  10. 次へ をクリックします。

  11. IMAP接続の詳細ページにて、エクスポートするサーバーのIMAPへ接続するための情報を記載します。IMAPのホスト名、ポートおよび管理者のログイン情報が必要となります。IMAPサーバーの情報入力を完了します。

  12. 次へ をクリックします。

  13. オプションの確認ページにて、データのインポート詳細を確認します。問題がない場合、次へ をクリックし、データのインポートを開始します。

XMLファイルの例

アカウントのプロビジョニングやデータのインポートで使用するXMLファイルの例を以下に紹介しています。XMLファイルを作成する際にご参照ください。

Example 7. アカウントのプロビジョニングにXMLファイルを使用する

メールデータをインポートせずに、複数のアカウントをプロビジョニングする場合、以下のようなXMLファイルを使用します。

<?xml version="1.0" encoding="UTF-8"?>
<ZCSImport>
<ImportUsers>
<User>
<sn>Sample</sn>
<givenName>Sam</givenName>
<displayName>Sam Sample</displayName>
<RemoteEmailAddress>ssample@example.com</RemoteEmailAddress>
<password>test123</password>
<zimbraPasswordMustChange>TRUE</zimbraPasswordMustChange>
</User>
<User>
<sn>Zackry</sn>
<givenName>Zak</givenName>
<displayName>Zak Zackry</displayName>
<RemoteEmailAddress>zzackry@example.com</RemoteEmailAddress>
<password>test123</password>
<zimbraPasswordMustChange>TRUE</zimbraPasswordMustChange>
</User>
</ImportUsers>
</ZCSImport>
Example 8. 外部にホストしているドメインからアカウントのプロビジョニングにXMLファイルを使用する

以下の例では、メールデータをインポートせずに、外部にホストしているドメインのアカウントを複数、プロビジョニングします。

下記例の場合、新しく作成したアカウントの zimbraMailTransport の属性に ZCSサーバーの替わりに、指定している外部のSMTPサーバーが設定されます。

<?xml version="1.0" encoding="UTF-8"?>
<ZCSImport>
<SMTPHost>smtp.example.com</SMTPHost>
<SMTPPort>25</SMTPPort>
<ImportUsers>
<User>
<sn>Sample</sn>
<givenName>Sam</givenName>
<displayName>Sam Sample</displayName>
<RemoteEmailAddress>sam@example.com</RemoteEmailAddress>
</User>
<User>
<sn>Zackry</sn>
<givenName>Zak</givenName>
<displayName>Zak Zackry</displayName>
<RemoteEmailAddress>zzackry@example.com</RemoteEmailAddress>
</User>
</ImportUsers>
</ZCSImport>
Example 9. メールのインポートにXMLファイルを使用する

以下の例では、ZCSでアカウントをプロビジョニングせずに、IMAP通信でGmailのアカウントからメールデータをインポートします。メールデータをインポートする前に、アカウントがZCSにプロビジョニングされている必要があります。

<?xml version="1.0" encoding="UTF-8"?>
<ZCSImport>
<IMAPHost>imap.gmail.com</IMAPHost>
<IMAPPort>993</IMAPPort>
<ConnectionType>ssl</ConnectionType>
<UseAdminLogin>0</UseAdminLogin>
<ImportUsers>
<User>
<sn>Sample</sn>
<givenName>Sam</givenName>
<displayName>Sam Sample</displayName>
<RemoteEmailAddress>sam@example.com</RemoteEmailAddress>
<RemoteIMAPLogin>sam@example.com</RemoteIMAPLogin>
<remoteIMAPPassword>test123</remoteIMAPPassword>
</User>
</ImportUsers>
</ZCSImport>

外部LDAPから新しいアカウントを自動的にプロビジョニングする

外部LDAPからの新しいアカウントの自動プロビジョニングは、CLIで対応します。本項で、サポートしているCLI属性と自動プロビジョニング方法について説明します。

概要

ZCSのドメインに、外部LDAP認証、preauth、SPNEGOのような外部LDAPの認証方法を設定している場合、ZCSにユーザーアカウントを自動作成できます。プライマリのメールアドレスやデフォルトのアカウント属性は外部のディレクトリよりマッピングされます。外部ディレクトリのデータからのアカウントの新規作成方法や作成タイミングを設定できます。

下記3つのモードが自動プロビジョニング設定でサポートされています。

モード 説明

Eagerモード

ZCS は外部のディレクトリを定期的に確認し、新規アカウントを自動作成します。新規ユーザーの確認のために外部ディレクトリをポーリングする頻度、各回における処理可能な最大ユーザー数、特定のサーバーでアカウントの自動プロビジョニング対象としてスケジューリングするドメインを管理できます。

概要: Eagerモードの自動プロビジョニングを設定する

Lazyモード

ユーザーの初回ログイン時、自動プロビジョニングをサポートしている認証方法の1つでZWCにログインしたときにそのユーザーがZCSディレクトリに存在しなければ、そのユーザーのためにZCS内に新規アカウントが自動作成されます。

概要: Lazyモードの自動プロビジョニングを設定する

Manualモード

自動プロビジョニングは実行されません。代わりに、管理者がマニュアル操作で、設定されている外部自動プロビジョニングLDAPソースを検索し、その検索結果から1つエントリを選択し、その外部エントリのために該当のZimbraアカウントを作成します。

Guidelines are provided in Manuralモードの自動プロビジョニングを設定する

自動でアカウント作成する際、アカウント名 (@の左にある部分) は外部ディレクトリに存在するユーザー属性よりマッピング (取得) されます。これは zimbraAutoProvAccountNameMap 内に定義します。また、姓、名、電話番号、住所、など、他のアカウント情報は zimbraAutoProvAttrMap に指定された属性にて、外部ディレクトリからマッピング (取得) されます。Zimbraの属性へマッピングすべき属性を決めるため、外部ディレクトリの属性をレビューすることができます。

自動作成したアカウントへの提供サービスの設定はマニュアル操作で作成したアカウントと同じように決定します。

  • ドメインに特定の提供サービスを設定している場合、新規作成したアカウントにはその提供サービスが設定されます。

  • ドメインに特定の提供サービスを設定していない場合、 ZCS のデフォルト提供サービスが設定されます。

アカウントが自動作成された場合、サーバーから ようこそ のメッセージが自動で受信されるように設定できます。ドメイン AutoProvNotification 属性にてメッセージの件名や本文を管理します。

自動プロビジョニングの属性

本項では、外部LDAPディレクトリから新規アカウントの自動プロビジョニングを設定するときに使用できる zmprov コマンドを紹介します。

zimbraAutoProvMode

EAGER、LAZY、MANUALから自動プロビジョニングで使用するモードを設定します。1つのドメインでモードを複数、有効化できます。

zimbraAutoProvAuthMech

LDAP, PREAUTH, KRB5, SPNEGOのいずれかから認証方法を設定します。LAZYモードの場合に有効です。 ユーザーが指定した外部認証方法で認証された後、ユーザーのアカウントがZimbraのディレクトリに存在していない場合、アカウントがZimbraのディレクトリに自動作成されます。

zimbraAutoProvLdapURL

自動プロビジョニングで使用する外部LDAPソースのLDAP URLを設定します。

zimbraAutoProvLdapStartTlsEnabled

自動プロビジョニングで外部LDAPサーバーにアクセスする際、StartTLSのプロトコルを使用するか否かです。デフォルトの設定はFALSEです。

zimbraAutoProvLdapAdminBindDn

自動プロビジョニングで使用するLDAP検索のバインドDNを設定します。

zimbraAutoProvLdapAdminBindPassword

自動プロビジョニングで使用するLDAP検索の管理バインドパスワードを設定します。

zimbraAutoProvLdapSearchBase

自動プロビジョニングで zimbraAutoProvLdapSearchFilter と共に使用するLDAP検索ベースを設定します。
設定されていないとき、LDAPのルートDSEが使用されます。

zimbraAutoProvLdapSearchFilter

自動プロビジョニングで使用するLDAP検索フィルターのテンプレートを定義します。LAZYモードの場合、 zimbraAutoProvLdapSearchFilter または zimbraAutoProvLdapBindDn を設定する必要があります。

2つとも設定されている場合、 zimbraAutoProvLdapSearchFilter が優先されます。詳細は プレースホルダー を参照してください。

zimbraAutoProvLdapBindDn

自動プロビジョニングで使用するLDAP外部フィルターのテンプレートを指定します。LAZYモードの場合、 zimbraAutoProvLdapSearchFilter または zimbraAutoProvLdapBindDn を設定する必要があります。

2つとも設定している場合、 zimbraAutoProvLdapSearchFilter が優先して適用されます。詳細は プレースホルダー を参照してください。

zimbraAutoProvAccountNameMap

アカウント名のローカル部分を含む外部ディレクトリ内の属性名を定義します。この名前は、Zimbraアカウントの作成に使用されます。指定されていないとき、アカウント名のローカル部分は、Zimbraへの認証に使用された最初のユーザー名になります。

zimbraAutoProvAttrMap

外部エントリの属性値から ZCS のアカウント属性へマッピングするための属性を定義します。値は {外部属性}={zimbra属性} 形式にします。設定されていないとき、外部ディレクトリの属性は ZCS アカウントへ取り込まれません。

誤ったマッピング設定は、アカウント作成が失敗する原因となります。下記は不正なマッピング条件の例です。

  • 無効な外部ソース属性名

  • 無効なzimbra属性名

  • 外部ソース属性には複数の値があるが、Zimbra属性の値は1つのみ

  • 構文の違反 (例えば、外部ソース属性のStringだが、Zimbra属性がInteger型など)

zimbraAutoProvNotificationFromAddress

新規アカウントが受信する「ようこそ」メッセージの 差出人 を定義します。設定されていないとき、メール通知は新規作成されたアカウントに送信されません。

zimbraAutoProvNotificationSubject

ユーザーの自動プロビジョニング時にユーザーに送信される通知メッセージの件名の作成に使われるテンプレート。

使用可能な変数: ${ACCOUNT_ADDRESS}, ${ACCOUNT_DISPLAY_NAME}

zimbraAutoProvNotificationBody

ユーザーの自動プロビジョニング時にユーザーに送信される通知メッセージの本文の作成に使われるテンプレート。

使用可能な変数: ${ACCOUNT_ADDRESS}, ${ACCOUNT_DISPLAY_NAME}

zimbraAutoProvListenerClass

自動プロビジョニングのリスナーのクラス名を定義するドメイン設定。使用するクラスは com.zimbra.cs.account.Account.AutoProvisionListener のインターフェースを実装している必要があります。各アカウントがZimbraに自動作成された後、独立したリスナーが呼ばれます。サーバーの拡張としてリスナーをプラグインすると、外部LDAPディレクトリでアカウントの自動プロビジョニング状況を更新するなどのタスク管理が可能になります。

EAGERプロビジョニングの各インターバルで、ZCS は zimbraAutoProvLdapSearchFilter の値に基づきLDAP検索を実行します。検索結果のエントリはこのバッチでの自動プロビジョニング候補です。 zimbraAutoProvLdapSearchFilter には、ZCSの既存アカウントがヒットしない条件を設定しておく必要があります。設定されていないとき、同じアカウントが何度も作成されます。 ZCSでアカウントの自動プロビジョニングが完了すると、 com.zimbra.cs.account.Account.AutoProvisionListener.postCreate (Domain domain, Account acct, String external DN) が自動プロビジョニングのフレームワークから呼ばれます。顧客は、AutoProvisionListenerのインターフェースをZCSのサーバー拡張に実装して、 AutoProvisionListener.postCreate() を呼ばせるようにします。このpostCreateを実装すると、例えば、ZCSにプロビジョニングされたばかりのアカウントに、外部ディレクトリ属性を設定できます。この属性は、 zimbraAutoProvLdapSearchFilter に条件として設定できるため、このエントリは次のインターバルのLDAP検索結果に返ってこなくなります。

zimbraAutoProvBatchSize

EAGER自動プロビジョニングの各インターバルで処理される最大アカウント数を定義するドメイン設定 | グローバル設定。

zimbraAutoProvScheduledDomains

サーバーでのEAGER自動プロビジョニングが予定されているドメインをリストアップするサーバー属性。予定のドメインの zimbraAutoProvMode は EAGERモードが有効である必要があります。EAGER自動プロビジョニングについて、1つのサーバー上でドメインを複数、スケジュールできます。また、EAGER自動プロビジョニングについて、複数のサーバー上で1つのドメインをスケジュールできます。

zimbraAutoProvPollingInterval

EAGERモード中の、アカウントのポーリングとプロビジョニングのインターバルを定義するドメイン設定|グローバル設定。 zimbraAutoProvBatchSizezimbraAutoProvScheduledDomains に設定されたドメイン数にも影響されるため、実際のインターバルはこの定義より長くなる可能性があります。

各インターバル中、自動プロビジョニングのスレッドは zimbraAutoProvScheduledDomains 内のドメインをすべて確認し、 domain.zimbraAutoProvBatchSize の値になるまで新規アカウントを自動作成します。この処理時間が zimbraAutoProvPollingInterval よりも長くなると、zimbraAutoProvPollingInterval になる前に、次のインターバルがすぐに起動されます。

  • サーバーが起動した時点でこの値が「0」の場合、自動プロビジョニングのスレッドは開始しません。

  • サーバーが実行中にこの値を「0」に変更した場合、自動プロビジョニングのスレッドが終了します。

  • サーバーが実行中にこの値を「0」から他の値に変更すると、自動プロビジョニングのスレッドが開始します。

プレースホルダー

Table 46. 自動プロビジョニング属性で利用するプレースホルダー
タグ 説明 結果

%/n

ユーザー名と@ 記号

user1@example.com を返します。

%u

@記号なしのユーザー名

user1 を返します。

%d

ドメイン

example.com を返します。

%D

DCとしてのドメイン

example,dc=com を返します。

Eagerモードの自動プロビジョニングを設定する

Eagerモードの場合、ZCS は自動プロビジョニングのため外部のディレクトリのアカウントを定期的に確認します。外部ディレクトリを確認するインターバル、各インターバルで処理可能な最大ユーザー数、自動プロビジョニング対象のサーバーやドメインを管理できます。

  1. ZCS のサーバーへログインし、Zimbraユーザーに切り替えます。

    zmprov
  2. EAGERモードを有効化します。

    md <example.com> zimbraAutoProvMode EAGER
  3. 各インターバルで処理可能な最大アカウント数を設定します。

    md <example.com> zimbraAutoProvBatchSize <#>
  4. アカウントのポーリングとプロビジョニングのインターバルを設定します。自動プロビジョニングのスレッドを起動するため、この値は「0」以外の値に設定する必要があります。デフォルトは15分です。

    ms <server.com> zimbraAutoProvPollingInterval <x minutes>
  5. 自動プロビジョニング対象のドメインを設定します。サーバーに複数のドメインを設定できます。

    また、対象ドメインは複数サーバーに設定できます。

    ms <server.com> +zimbraAutoProvScheduledDomains <domain1.com> \
      +zimbraAutoProvScheduledDomains <domain2.com>
  6. 外部LDAPの詳細を設定します。

    1. LDAP URLを設定します。

      md <example.com> zimbraAutoProvLdapURL "ldap://xxx.xxx.xxx.xxx:<port>"

      一般的にLDAPはポート389を使用します。

    2. (任意) StartTLSを有効化します。

      md <example.com> zimbraAutoProvLdapStartTlsEnabled TRUE
    3. 自動プロビジョニング用のLDAP管理者バインドDNを設定します。

      md <example.com> zimbraAutoProvLdapAdminBindDn "cn=admin, dc=autoprov, dc=company, dc=com"
    4. 自動プロビジョニング用のLDAP管理者の検索バインドパスワードを設定します。

      md <example.com> zimbraAutoProvLdapAdminBindPassword <password>
    5. 自動プロビジョニング対象のユーザーを検索する際のテンプレートを設定します。

      検索フィルター使用例

      md <example.com> zimbraAutoProvLdapSearchFilter "(uid=<%placeholder>)"

      サポート対象のプレースホルダーについては プレースホルダー を参照してください。

    6. 自動プロビジョニングのLDAP検索ベースを設定します。

      これは、ディレクトリ内のLDAP検索の開始地点です。zimbraAutoProvLdapSearchFilter で、と共に使用されます。設定されていないとき、LDAPディレクトリのルートである rootDSE が開始地点です。

      md <example.com> zimbraAutoProvLdapSearchBase "dc=autoprov,dc=company,dc=com"
      md <example.com> zimbraAutoProvLdapBindDn <"placeholder1">

      サポート対象のプレースホルダーについてはプレースホルダー を参照してください。

  7. (任意) 外部ディレクトリにて、アカウント名のローカル部分が依存する属性を指定します。新規アカウントを作成する際に、アカウント名のローカル部分が ZCS アカウント名として使用されます。なお、アカウント名のローカル部分を指定していない場合、 ZCSへ認証したユーザー名をローカル名として使用します。

    md <example.com> zimbraAutoProvAccountNameMap <value>
  8. (任意) 外部エントリの属性値から ZCS のアカウント属性へマッピングします。セットアップされていないとき、外部ディレクトリの属性は ZCS アカウントへ取り込まれません。値は {外部属性}={zimbra属性} 形式にします。

    誤ったマッピング設定は、アカウント作成が失敗する原因となります。

    外部エントリの値「sn」をZimbraアカウントの「displayName」にマッピングし、外部エントリの「description」の値を ZCS アカウントの「description」にマッピングします。

    md <example.com> +zimbraAutoProvAttrMap sn=displayName +zimbraAutoProvAttrMap description=description
  9. (任意) 新規作成アカウントに「ようこそ」のメッセージを送信したいとき、メッセージの 差出人 を設定します。

    md <example.com> zimbraAutoProvNotificationFromAddress <name@example.com>
  10. zmprovを抜けます。

    exit

Lazyモードの自動プロビジョニングを設定する

LDAP、preauth、Kerberos 5およびSpnegoの外部認証にユーザーが認証した場合、Lazy モードの自動プロビジョニングが新規アカウントを作成します。

  1. ZCSのサーバーへログインし、Zimbraユーザーに切り替え、コマンドプロンプトでzmprovを入力します。

  2. LAZYモードを有効化します。

    md <example.com> zimbraAutoProvMode LAZY
  3. LAZYモードが使用する外部認証方法LDAP, PREAUTH, KRB5, SPNEGOを指定します。複数の認証方法を指定できます。

    md <example.com> zimbraAutoProvAuthMech <type> +zimbraAutoProvAuthMech <type2>
  4. 外部LDAPの詳細を設定します。

    1. LDAP URLを設定します。

      md <example.com> zimbraAutoProvLdapURL "ldap://xxx.xxx.xxx.xxx:<port>"

      一般的にLDAPはポート389を使用します。

    2. (任意) StartTLSを有効化します。

      md <example.com> zimbraAutoProvLdapStartTlsEnabled TRUE
    3. 自動プロビジョニング用のLDAP管理者バインドDNを設定します。なお、 cn=<LDAPadmin_name>, dc=autoprov, dc=<company_name>, dc=<com> のフォーマットを使用する必要があります。

      md <example.com> zimbraAutoProvLdapAdminBindDn <"bindDN">

      例: "cn=admin, dc=autoprov, dc=company, dc=com"

    4. 自動プロビジョニング用のLDAP管理者の検索バインドパスワードを設定します。

      md <example.com> zimbraAutoProvLdapAdminBindPassword <password>
    5. (任意) 自動プロビジョニング対象のユーザーを検索する際のテンプレートを設定します。

      検索フィルター使用例

      md <example.com> zimbraAutoProvLdapSearchFilter <"placeholder">

      サポート対象のプレースホルダーについては プレースホルダー を参照してください。

      LAZYモードにzimbraAutoProvLdapSearchFilter、またはzimbraAutoProvLdapBindDnを設定する必要があります。
    6. 自動プロビジョニングのLDAP検索ベースを設定します。zimbraAutoProvLdapSearchFilter と共に、LDAPの検索を開始する場所を指定します。なお、この値を設定しない場合、LDAPディレクトリのルートである rootDSE が自動的に使用します。

      md <example.com> zimbraAutoProvLdapSearchBase <"location">

      <”location”>の例: "dc=autoprov,dc=company,dc-com"

    7. (任意) アカウントのプロビジョニングで使用するLDAP外部DNテンプレートを設定します。

      md <example.com> zimbraAutoProvLdapBindDn "uid=%<placeholder1>, %<placeholder2>"

      サポート対象のプレースホルダーについてはプレースホルダー を参照してください。

  5. (任意) 外部エントリのアカウント名のローカル部分が依存する属性を指定します。新規アカウントを作成する際に、アカウント名のローカル部分がZCSアカウント名として使用されます。なお、アカウント名のローカル部分が指定されていない場合、ZCSへ認証したユーザー名をローカル名として使用します。

    md <example.com> zimbraAutoProvAccountNameMap <value>
  6. (任意) 外部エントリの属性値から ZCS のアカウント属性へマッピングします。セットアップされていないとき、外部ディレクトリの属性は ZCS アカウントへ取り込まれません。値は {外部属性}={zimbra属性} 形式にします。

    外部エントリの値 sn をZimbraアカウントの displayName にマッピングし、外部エントリの「description」の値を ZCS アカウントの「description」にマッピングします。

    md <example.com> +zimbraAutoProvAttrMap sn=displayName +zimbraAutoProvAttrMap description=description
  7. (任意) 新規に作成したアカウントへ ようこそ のメッセージを送信希望の場合、メッセージの 差出人 を設定します。

    md <example.com> zimbraAutoProvNotificationFromAddress <name@example.com>
  8. zmprovを抜けます。
    exit

Manuralモードの自動プロビジョニングを設定する

外部LDAPサーバーとの自動プロビジョニングを無効にするには、Manualモード設定を使用します。

  1. ZCSサーバーへログインし、Zimbraユーザーに切り替え、コマンドプロンプトでzmprovを入力します。

  2. Manualモードを有効化します。

    md <example.com> zimbraAutoProvMode MANUAL

リソースを管理する

「リソース」とは、会議などに予約できる場所や機器のことです。 各会議室や、場所を固定しない機器 (視聴覚の機器、など) は、リソースアカウントとしてセットアップします。管理コンソールの 管理 > リソース にて、 Zimbra Collaborationに設定しているリソースアカウントを管理できます。

ユーザーアカウントのカレンダー機能で、リソースをカレンダーに予約できます。リソースアカウントは、利用可・不可に基づき、予約依頼を自動で許可・拒否します。

管理者はリソースのメールボックスを定期的に監視する必要はありません。リソースのメールボックス内容は、メールの削除ポリシーにより、自動削除されます。

リソースウィザードを使用して、リソース設定を行ないます。以下のリソース詳細をアカウントに設定できます。

  • リソースの種類:場所または機器

  • 予定のポリシー

  • カレンダー招待のコピーを転送するメールアドレス

  • リソースの説明

  • 問題が発生した際に対応可能の連絡先情報

  • 場所の情報:ビル名、住所、部屋名、収容人数など

  • リソースの自動返信メッセージや署名のカスタマイズ

リソースアカウントを作成するとLDAPサーバーにディレクトリのアカウントが作成されます。

リソースを予約するには、リソース機器や場所を会議に招待します。リソースの選択時、リソースの説明、連絡先、空き状況を閲覧できます。

会議の招待が送信されると、リソースアカウントにメールが送信されます。予定ポリシーに従い、リソースが空いていれば、リソースのカレンダーに会議が自動追加されてそのリソースは予約済みに表示されます。

リソースの予定ポリシーを設定する

リソースの予定ポリシーでは、リソースカレンダーの維持方法を設定できます。以下の予定ポリシーを使用できます。

  • 繰り返し予約を自動拒否 — リソースが1度に1つの会議にしかスケジューリングできないとき、この値は有効です。このリソースに繰り返し予約を入れることはできません。

  • 使用可能な場合には自動的に受け入れ、競合する場合には自動的に拒否する — このオプションが選択されているとき、リソースが予約済みでない限り、自動で依頼が許可されます。リソースの空き時間が閲覧可能です。自動拒否のルールを編集して、競合する予約を許可できます。

  • 手動で受け入れ、競合する場合には自動的に拒否する — このオプションが選択されているとき、競合する予約は全て、リソースアカウントに自動で拒否されます。競合していない予約依頼は、リソースカレンダーに仮予約としてマークされるため、マニュアル操作での許可が必要となります。これをセットアップするなら、招待をマニュアル操作で許可できるアカウントに招待のコピーが転送されるように設定する必要あります。自動拒否のルールを編集して、競合する予約を許可できます。

  • 常に自動的に受け入れる — リソースアカウントは予約された予定を自動的に許可します。この場合、リソースの空き状況は反映されないため、複数の会議が同じ時間帯にそのリソースを予約する可能性があります。リソースは常に招待を受け入れるため、社外でよく会議に使う場所を参加者への招待に含めたい場合に使用することを推奨します。

  • 自動的に受け入れない、自動的に拒否しない — リソースアカウントはマニュアル操作で管理されます。委任されたユーザーがリソースアカウントにログインし、すべての依頼をマニュアル操作で許可・拒否する必要があります。

競合のルール — 管理者は、競合する場合には自動的に拒否するように設定されているアカウントに、しきい値をセットアップできます。部分的に許される繰り返し予定の全体に対するパーセンテージや、競合数として、設定します。

競合の最大許容数競合の最大許容パーセント は、依頼された繰り返し予定日全て、使用できない場合も繰り返し予定がスケジューリングできるように設定されます。

競合があったとしても、競合の最大許容数または競合の最大許容パーセントのいずれかに達するまで、リソースは予約を許可します。部分予約が機能できるように、両項目に0以外の値を設定しておく必要があります。

リソースアカウントを管理する

リソースアカウントとしてログインすると、リソースのプリファレンスを設定できます。 リソースアカウントのプリファレンス > カレンダー から、ユーザーによるリソースカレンダー管理を設定できます。リソース管理には、次のオプションがあります。

  • 招待の転送先。アカウントのプロビジョニング時に転送先アドレスがセットアップされていた場合、管理者はそのアドレスを変更できます。

  • リソースを使用できるユーザー。アクセス許可セクションの招待のところから、 内部ユーザーのみが自分を予定の招待できるようにする を選択し、適切なユーザーメールアドレスをこのリストに追加してください。

リソースカレンダーを特定のユーザーに共有して管理者権限を付与することができます。管理者として委任されたユーザーは、そのカレンダーに対する全ての管理者権限を持つことになります。招待について、閲覧、編集、追加、削除、許可、拒否ができます。

ユーザーアカウントの管理

ユーザーアカウントのステータス

管理コンソール:

ホーム > 管理 > アカウント

アカウントのステータスにより、ユーザーのログインとメール受信の可否が決まります。このステータスは、管理コンソールの 管理 ペインに表示されます。

Table 47. ステータス - ユーザーアカウント
ステータス 説明

アクティブ

メールボックスアカウントの通常の状態です。メールは配信され、ユーザーはクライアントインタフェースにログインできます。

メンテナンス

ログイン不可で、このアカウント宛のメールは全てMTAのキューに並びます。

バックアップ中やアカウントのインポート/エクスポート/復元時、このステータスがアカウントに自動設定されることをご注意ください。

保留

新規作成されたアカウントで、まだアクティブになる準備が終わっていないとき。保留中、ログイン不可で、メールはバウンスされます。

ロック

ログイン不可で、メールはこのアカウントに継続配信されます。メールアカウントが危険にさらされている(未認証エンティティが使用)と思わしき場合、管理者はこのロックステータスを設定できます。

閉鎖

ログイン不可で、メールはバウンスされます。サーバーから削除せずに、削除済みアカウントとする場合にこのステータスが使用されます。閉鎖によるアカウントライセンスへの影響はありません。

ロックアウト

不正なパスワードでのログイン試行時、自動でセットされるステータスです。ロックアウトは、マニュアルでは管理者でも設定できません。設定で許容されているログイン試行回数を超えた場合にセットされます。ロックアウトの期間も設定可能です。

管理者はロックアウトのステータスをいつでも解除できます。

アカウントを削除する

管理コンソール:

ホーム > 管理 > アカウント

管理コンソールからアカウントを削除できます。これにより、アカウントはサーバーから消去され、メッセージストアにあるメッセージが削除され、ライセンスの使用中アカウント数が変更されます。

アカウント削除前に、アカウントの完全バックアップを実行してアカウント情報を保存してください。バックアップの詳細は バックアップと復元 の章を参照してください。

アカウントのメールボックスを閲覧する

すべてのフォルダ、カレンダー予定およびタグを含めて、特定のアカウントのメールボックス内容をすべて管理コンソールから閲覧できます。

管理コンソール:

ホーム > 管理 > アカウント → アカウント名

アカウント名 を選択後、ギア アイコンから メールを表示 を選択します。対象ユーザーのZWCアカウントが別ウィンドウで開かれます。

この機能では、管理者とユーザーは同一アカウントに同時にログインできるため、困っているユーザーのアカウントに直接アクセスし、サポートすることができます。

アカウントにアクセスするメールを表示アクションは全て audit.log に記録されます。

電子メールのエイリアスを使用する

メールのエイリアスは、特定のメールアカウントに全メールをリダイレクトするメールアドレスです。エイリアスはメールアカウントではありません。各アカウントにいくつでもエイリアスを設定できます。

管理→エイリアスペインからエイリアスを選択時、設定されているエイリアスが全て内容ペインに表示されます。エイリアスの作成、特定のエイリアスのアカウント情報の閲覧、エイリアスの対象アカウントの変更、エイリアスの削除ができます。

配布リストを管理する

配布リストとは、メールアドレスの集合が共通メールアドレス内にリストアップされたものです。配布リストへの送信時、そのリスト内の全員にメッセージを送信していることになります。あて先項目には配布リストのメールアドレスが表示されます。個々の受信者のアドレスが閲覧されることはありません。

メンバーリストを管理する管理者が必要な配布リストの作成や、リストのメンバーを自動で追加・削除するダイナミック配布リストの作成ができます。ダイナミック配布リストの詳細は、 ダイナミック配布リストを使用する を参照してください。

ユーザーがメンバーになっている配布リストは、管理→アカウント→メンバーページから確認できます。Zimbraユーザーのメールアドレスが配布リストに追加されると、その配布リスト名がユーザーこのアカウントのメンバーページに反映されます。配布リストの削除時、このアカウントのメンバーページからその配布リスト名が消去されます。

配布リストの購読ポリシーを管理する

配布リストのメンバー管理のための購読ポリシーをセットアップできます。リストのオーナーは配布リストのプロパティページから、購読ポリシーを管理できます。

オプション 詳細

新しい購読の要求

  • 自動的に受け入れる — 誰でも購読メンバーになれます。

  • リストのオーナーの承認が必要 —  ユーザーが購読するためには、配布リストのオーナーにメッセージを送信し、オーナーはそのメールの依頼に答えます。

  • 自動的に拒否する — 誰も配布リストに追加できません。

購読解除の要求

  • 自動的に受け入れる —  誰でもリストから除名できます。

  • リストのオーナーの承認が必要 — ユーザーが配布リストからリストから除名されるには、配布リストのオーナーにメッセージを送信します。オーナーは除名のメール依頼を承認する必要があります。

  • 自動的に拒否する — ユーザーはリストから除名できません。

配布リストのオーナーが使用できる管理オプション

配布リストにオーナーを登録すると、オーバーはZWCの自身のアカウントのアドレス帳、配布リストフォルダから管理することができます。リストのオーナーは、リストの編集のために、配布リストを右クリックして グループを編集 を選択できます。

メンバーの追加・削除のほか、オーナーが設定できる配布リストのプロパティに次のようなものがあります。

  • グローバルアドレスリストに表示されないように、配布リストをプライベートとしてマーク

  • リストへメッセージ送信できるユーザーを管理

  • メンバーの購読ポリシーの設定

  • 他のオーナーの追加

配布リストを作成する

配布リストの作成は、本項の手順を参考にしてください。

管理コンソール:

ホーム > 管理 > 配布リスト

  1. 画面の右上にある ギア アイコンから 新規 をクリックします。

  2. メンバー ページで、配布リストの名前を入力します。スペースは使用できません。他の項目は任意です。

  3. 右側の「このリストにメンバーを追加」から、配布リストに追加するメンバーを検索します。追加するメンバーを選択して、 選択項目を追加 をクリックします。ページに表示されたアドレス全てを追加したいなら、 このページを追加 をクリックします。会社のリストに存在しないメンバーを追加したいなら、 または下にアドレスを入力 項目にメールアドレスを正確に入力します。

  4. 次へ をクリックし、配布リストの プロパティ ページに進みます。

    Table 48. 配布リストプロパティオプション
    配布リストプロパティオプション 詳細

    メール受信可

    デフォルトで有効です。配布リストがメッセージを受信すべきでないなら、このオプションを無効にします。

    GALに表示しない

    このオプションを有効にすると配布リストがグローバルアドレスリスト(GAL)に表示されません。このオプションを利用して、配布リストのメールアドレスの存在を知るユーザーを制限できます。

    メールサーバー

    デフォルトで「自動」が設定されます。特定のメールサーバーを指定する場合、「自動」を無効にし、一覧からサーバーを特定します。

    ダイナミックグループ

    このチェックボックスを有効にすると メンバーURL 項目が表示されます。ダイナミック配布リストを作成します。詳細は以下の ダイナミック配布リストを使用する を参照してください。

    新しい購読の要求

    以下のいずれかを選択します。

    • 自動的に受け入れる

    • リストのオーナーの承認が必要

    • 自動的に拒否する

    購読解除の要求

    以下のいずれかを選択します。

    • 自動的に受け入れる

    • リストのオーナーの承認が必要

    • 自動的に拒否する

  5. メンバー ページで、配布リストを直接メンバーとするか間接メンバーとするかを選択します。

  6. 配布リストにエイリアスを追加すべきなら、作成します。

  7. 配布リストを他のユーザーにも管理させるなら、オーナー ページから、対象者のメールアドレスを入力します。

  8. 配布リストが受信するメッセージの返信方法を設定します。

  9. 完了 をクリックします。配布リストが有効になり、URLが作成されます。

配布リストへのアクセスを管理する

配布リストの作成後は、配布リストのメンバーを閲覧できるユーザーや配布リストへメッセージ送信できるユーザーを管理できます。デフォルトでは、全ユーザーに全配布リストへのアクセス権があります。本章では、CLIから行なう配布リストへのアクセス管理について説明します。

配布リストにアクセスできるユーザーを制限するには、ドメインの個々のユーザーにアクセス権を与えます。あるいは、ドメインのユーザーにだけ配布リストへのアクセスを許可したいなら、ドメインに対するアクセス権を与えることができます。ドメインにアクセス権を与えると、ドメインにある全配布リストがその権限を継承します。

個々の配布リストに対する権限を付与すると、配布リストへのアクセスが認められる特定のユーザーを設定することができます。

配布リストへのアクセス制限はコマンドラインの zmprov grantRight (grr) コマンドで実行可能です。

権限付与についての詳細は、 管理権限の委任を参照してください。
配布リストのメンバーを閲覧できるユーザー

デフォルトでは、全ユーザーが配布リストのメンバーのメールアドレスを閲覧できます。配布リストのメールアドレスに、「+」が吹き出し表示されます。クリックして、配布リストを展開することができます。配布リスト内のメールアドレスが一覧表示されます。ユーザーは、この展開されたリストから、個々のアドレスを選択できます。

個別のユーザーやドメインに、配布リスト内のメールアドレス閲覧を制限します。

  • 個別のユーザー

    zmprov grr domain <ドメイン名> usr <アドレス@ドメイン> viewDistList
  • ドメイン内全ユーザー

    zmprov grr domain <ドメイン名> dom <example.com> viewDistList
  • 配布リストに権限を付与し、特定のユーザーにリストを閲覧させる

    zmprov grr dl <dll_name@example.com> usr <アドレス@ドメイン>
配布リストへメッセージ送信できるユーザー

デフォルトでは、すべてのユーザーがすべての配布リストにメッセージ送信できます。誰が配布リストにメッセージを送れるかを定義するために、ドメインや配布リストに権限を付与できます。使用する権限のない配布リストにメッセージを送信しようとすると、あて先の配布リストへメッセージを送信する権限がない旨を伝えるメッセージが送信されます。

ホーム > 設定 > グローバル設定 > MTA にある Milterサーバー は有効でなければなりません。

個別のユーザーやドメインに、配布リストへのメッセージ送信を制限します。

  • ドメイン内のあるユーザーのみにすべての配布リストへのメッセージ送信を許可。

    zmprov grr domain <ドメイン名> usr <アドレス@ドメイン> sendToDistList
  • ドメイン内の全ユーザーにすべての配布リストへのメッセージ送信を許可。

    zmprov grr domain <ドメイン名> dom <example.com> sendToDistList

ユーザータイプによる、個々の配布リストへのアクセス許可とその解除の方法です。

  • 特定の内部ユーザーにアクセスを許可。

    zmprov grr dl <dlname@example.com> usr <username@example.com> sendToDistList

    アクセス許可を解除。

    zmprov rvr dl <dlname@example.com> usr <username@example.com> sendToDistList
  • 配布リストのメンバーのみにアクセスを許可。

    zmprov grr dl <dlname@example.com> grp <dlname2@example.com> sendToDistList

    アクセス許可を解除。

    zmprov rvr dl <dlname@example.com> grp <dlname2@example.com> sendToDistList
  • ドメイン内の全ユーザーのみにアクセスを許可。

    zmprov grr dl <dlname@example.com> dom <example.com> sendToDistList

    アクセス許可を解除。

    zmprov rvr dl <dlname@example.com> dom <example.com> sendToDistList
  • 外部ドメイン内の全ユーザーのみにアクセスを許可。

    zmprov grr dl <dlname@example.com> edom <example.com> sendToDistList

    アクセス許可を解除。

    zmprov rvr dl <dlname@example.com> edom <example.com> sendToDistList
  • すべての内部ユーザーのみにアクセスを許可。

    zmprov grr dl <dlname@example.com> all sendToDistList

    アクセス許可を解除。

    zmprov rvr dl <dlname@example.com> all sendToDistList
  • すべてのパブリック電子メールアドレスにアクセスを許可。

    zmprov grr dl <dlname@example.com> pub sendToDistList

    アクセス許可を解除。

    zmprov rvr dl <dlname@example.com> pub sendToDistList
  • 特定の外部メールアドレスにアクセスを許可。

    zmprov grr dl <dlname@example.com> gst <someone@foo.com> "" sendToDistList

    アクセス許可を解除。

    zmprov rvr dl <dlname@example.com> gst <someone@foo.com> "" sendToDistList
Active Directoryのアカウントによる配布リストのメンバーの閲覧を有効にする

Active Directory配布リストのメンバーをメッセージやアドレス帳から確認には、Active DirectoryのGALグループハンドラを、Active Directoryごとに、ZCSのGalSyncアカウント内に設定する必要があります。

本項の手順で、Active DirectoryごとのGalSyncアカウントを更新します。この設定を行なうには、GalSyncアカウント名とそのGALSyncアカウント内の全データソースを認識している必要があります。

  1. GalSyncアカウントのZimbraIDを表示します。

    zmprov gd {ドメイン名} zimbraGalAccountId

    アカウント名の検索

    zmprov ga {GAL同期アカウントのzimbraId} name
  2. GalSyncアカウントのデータソースを表示します。

    zmprov gds {ドメインのGAL同期アカウント名}
  3. Active Directoryのグループハンドラを有効にします。

    zmprov mds {ドメインのGalSyncアカウント名} {ADのデータソース名} \
     zimbraGalLdapGroupHandlerClass com.zimbra.cs.gal.ADGalGroupHandler

ダイナミック配布リストを使用する

ダイナミック配布リストは、メンバーを自動的に管理します。ユーザーは、リストに自動で追加・削除されます。ダイナミック配布リスト作成時、メンバーURLが指定されます。このメンバーURLは、含まれているはずのメンバーの識別に使用されます。このメンバーURLは、管理コンソールの配布リストのプロパティページで閲覧できます。

ダイナミック配布リストは、管理コンソールまたはコマンドラインから作成できます。URL内には、ダイナミック配布リストに追加されるユーザータイプの判別用に、特有のオブジェクトクラスを指定します。例えば、ダイナミック配布リストを、オブジェクトクラス = zimbraAccountで設定したとします。すると、新規アカウントの作成やアカウントの削除時、このダイナミック配布リストは更新されます。

すべてのモバイル、POP/IMAPのユーザーにダイナミック配布リストを作成できます。

配布リストのフィルタールールも変更することができます。配布リストを編集すると、新しいルールに従って、参加するメンバーが更新されます。

ダイナミック配布リストを使用する

ダイナミック配布リストは前述のとおり、管理コンソールまたはCLIから作成できます。

管理コンソール:

ホーム > 管理 > 配布リスト

  1. 右上の ギア アイコンより、 新規 をクリックします。

  2. メンバー ページから、ダイナミック配布リストの名前を入力します。スペースは使用できません。リストにメンバーを追加しないでください。

  3. 次へ をクリックし、プロパティ ページで設定します。

    Table 49. ダイナミック配布リストのオプション
    オプション 説明

    メール受信可

    デフォルトで有効です。配布リストがメッセージを受信すべきでないなら、このオプションを無効にします。

    GALに表示しない

    このオプションを有効にすると配布リストがグローバルアドレスリスト(GAL)に表示されません。このオプションを利用して、配布リストのメールアドレスの存在を知るユーザーを制限できます。

    メールサーバー

    デフォルトで 自動 が設定されます。特定のメールサーバーを指定する場合、 自動 を無効にし、一覧からサーバーを特定します。

    ダイナミックグループ

    このチェックボックスを有効にします。

    権限管理で使用可能

    このチェックボックスを無効にします。

    メンバーURL

    メンバーURLはLDAP URLのフィルターの一種で、リストに追加・削除するユーザータイプを決めます。

    このリストのURLを入力します。コマンドでは ldap://??sub? がURLです。 様々なダイナミック配布リストの作成のため、フィルターの組み合わせを自由にメンバーURLに追加します。

    Example 10. すべてのユーザー、GALアカウント、スパム/ハムのリスト
    ldap:///??sub?(objectClass=zimbraAccount)
    Example 11. 委任された管理者のリスト
    ldap:///??sub?(&(objectClass=zimbraAccount)(zimbraIsDelegatedAdminAccount=TRUE))
    Example 12. アクティブなアカウントすべて
    ldap:///??sub?(&(objectClass=zimbraAccount)(ZimbraAccountStatus=active))
    Example 13. 役職が「Manager」のユーザーすべて

    役職はアカウントの 連絡先情報の役職 から取得します。 この例ではこの項目にManagerが設定されています。

    ldap:///??sub?(&(objectClass=zimbraAccount)(title=Manager))

    新しい購読の要求

    自動的に拒否する を選択します。

    購読解除の要求

    自動的に拒否する を選択します。

  4. ダイナミック配布リストにエイリアスを追加すべきなら、作成します。

  5. ダイナミック配布リストを他のユーザーにも管理させるなら、オーナー ページから、対象者のメールアドレスを入力します。

  6. 返信先メールアドレスをセットアップしたいなら、ここに入力します。配布リストへの返信は全て、このメールアドレスに送信されます。

  7. 完了 をクリックします。ダイナミック配布リストが作成されます。

指定したフィルターに基づき、リストにユーザーが自動追加されます。管理者がユーザーを追加・削除するとリストは更新されます。

元は管理コンソールで作成されたダイナミック配布リストをCLIを使用して編集するには、そのダイナミック配布リストの zimbraIsACLGroup を必ず FALSE にする必要があります。

CLIの zmprov コマンドでダイナミック配布リストを管理できます。コマンドでは ldap:///??sub? がURLです。様々なダイナミック配布リストの作成のため、フィルターの組み合わせを自由にメンバーURLに追加します。

  1. すべての新規・既存アカウントのダイナミック配布リストを作成します。

    すべてのユーザー、GALアカウント名、スパム/ハムのアカウント名が含まれます。ユーザーアカウントの削除時、自動的にリストから削除されます。

    zmprov cddl <all@domain.com> zimbraIsACLGroup FALSE \
      memberURL 'ldap:///??sub?(objectClass=zimbraAccount)'
  2. 提供サービスを作成し、ユーザーに指定します。

    提供サービスを作成します。特定の条件、例えば「全マネージャー」など、に基づき、作成した提供サービスをユーザーに指定すると、その提供サービス用のダイナミック配布リストを簡単に修正することができます。

    Example 14. 特定の提供サービスにアクティブアカウントがあるユーザーが全員入っているダイナミック配布リスト
    zmprov cddl <allusers@domain.com>  zimbraIsACLGroup FALSE \
      memberURL 'ldap:///??sub?(&(objectClass-zimbraAccount) (zimbraCOSId=513e02e-9abc-4acf-863a-6dccf38252e3) (zimbraAccountStatus=active))'
    Example 15. 役職に基づいてユーザーが全員入っているダイナミック配布リスト

    この実行には、アカウントの連絡先情報に 役職 が設定されていなければなりません。この例は役職に「Manager」が設定されています。

    zmprov cddl <allmanagers@domain.com> zimbraIsACLGroup FALSE' \
      memberURL ldap:///??sub?(&(objectClass-zimbraAccount) (zimbraCOSId=513e02e-9abc-4acf-863a-6dccf38252e3) (title=Manager))'
    Example 16. 委任された管理者全員のダイナミック配布リスト
    zmprov cddl <alldelegatedadmins@domain.com> zimbraIsACLGroup FALSE \
      memberURL 'ldap:///??sub?(&(objectClass-zimbraAccount) (zimbraCOSId=513e02e-9abc-4acf-863a-6dccf38252e3) (zimbraIsDelegatedADminAccount=TRUE))'

メールボックスを移動する

メールボックスは、同じLDAPサーバーを共有するZimbraサーバー間で移動できます。

メールボックスの移動は管理コンソールやCLIコマンドから実行できます。 zmmboxmove を使用すれば、サーバーを停止せずに、サーバー間のメールボックス移動ができます。

移動先のサーバーが、メールボックス移動プロセスを管理します。移動はバックグランドで動作するため、アカウントは、ほぼ全てのデータが移動し終わるまで、アクティブモードのままです。アカウントは、最終データ移動のわずかな間、ロックされますが、すぐにアクティブモードに戻ります。

メールボックス移動プロセスは以下の手順で実行されます。

  • メールボックスブロブが移動先のサーバーに移されます。

  • 内容がほぼ移されると、アカウントはメンテナンスモードに切り替わります。

  • データベーステーブル、インデックスディレクトリ、変更されたブロブ全てが移されます。

  • アカウントはアクティブモードに戻されます。

メールボックスが移動先サーバーに移動後、元サーバーにまだコピーがありますが、ステータスは閉鎖です。ユーザーはログイン不可、メールは配信されません。旧メールボックスの削除前に、データが完全に新メールボックスへ移されていることを確認してください。

  • メールボックスを新サーバーに移動。

    zmmboxmove -a <アドレス@ドメイン> --from <旧サーバー> --to <新サーバー>
  • 旧サーバーからメールボックスを削除。

    zmpurgeoldmbox -a <アドレス@ドメイン> -s <旧サーバー>

メールボックスを移動するグローバル設定のオプション

メールボックス移動に関するグローバル設定のオプションとして、メールボックス移動時、検索インデックス、ブロブ、HSMブロブを除外するように設定できます。以下の設定オプションを、移動元サーバーあるいは移動先サーバーで設定できます。

  • zimbraMailboxMoveSkipSearchIndex — 検索インデックスデータを含めない場合、移動後にメールボックスを再インデックスしないといけません。

  • zimbraMailboxMoveSkipBlobs — メールボックスに紐づくブロブは、プライマリとセカンダリボリューム(HSM)込みで、除外されます。

  • zimbraMailboxMoveSkipHsmBlobs — 移動中のメールボックスのためのHSMブロブが既に存在するとき、有用です。 zimbraMailboxMoveSkipBlobs が設定されていないものHSMボリュームにあるブロブをスキップしたい場合にこのオプションを設定してください。

管理権限の委任 (*)

*Zimbra 8.8 より、本機能は2つの異なるバージョンを提供しています。Zimbra 8.8 ではスタンダード版と新世代(NG)版を提供しています。Zimbra 8.7 またはそれ以前のバージョンでは、スタンダード版のみを提供しています。以下にスタンダード版の詳細を記載しています。Zimbra 8.8 で本機能の NG版を利用する方法につきましては、本ガイドの NG版専用チャプターをご参照ください。

グローバル管理者(システム管理者)は、様々な「委任された管理者」の役割を作成できます。

「委任された管理者」の役割には、配布リストの管理や、ユーザーが忘れたパスワードのリセットのように単純なものから、ドメインに対するドメイン管理者まで、様々な権限があります。

よく使用される2つの管理の役割である、ドメイン管理者と配布リスト管理者は既に定義されています。これら既存の役割の場合、管理者を追加するために必要な設定は他にありません。

管理者権限を付与するターゲット種類

管理権限の委任には、ターゲット上でのアクセス制御を制限するための定義を行なうことと、管理者がターゲットでタスクを実行するための権限を付与することがあります。

「ターゲット」とは、権限付与の対象とされる Zimbra Collaboration のオブジェクトです。各ターゲットは「ターゲット種類」に紐づきます。「ターゲット種類」は、ターゲット上でのアクセス制御エントリのタイプを識別します。

ターゲットに「ターゲット種類」を選択するときは、以下を参考にしてください。

  • ターゲットについて。どの特定のターゲットに権限を付与しますか? 例えば、ターゲット種類に「ドメイン」を選択した場合、どのドメインを指していますか?特定のドメイン名を指定してください(ターゲット名=example.com)。そのターゲットにアクセス制御エントリ(ACE)が付与されます。ACEは、そのターゲットエントリのLDAPデータに保存されます。

  • 付与したい権限は、選択したターゲット種類に適していますか?権限は、関連するターゲット種類にしか適用できません。例えば、アカウント作成は、ターゲット種類「ドメイン」にしか適用できませんし、パスワード設定は、ターゲット種類「アカウント」「カレンダーリソース」にしか適用できません。ターゲットに適用できない権限がターゲット上に付与されると、その権限は無視されます。

  • 権限を定義するときは、付与される権限が機能するターゲットスコープを考慮する必要があります。例えば、パスワード設定は、ターゲット種類「アカウント」「カレンダーリソース」にしか適用できませんが、この権限がターゲット種類「ドメイン」の権限リストに含まれると、ドメイン内のすべてのアカウントとカレンダーリソースで機能することになります。

Table 50. 権限のターゲット
ターゲット種類 ターゲットスコープの説明

アカウント

アカウントエントリ(特定のユーザー)

カレンダーリソース

カレンダーリソースエントリ

COS

提供サービスエントリ

配布リスト

配布リストとその配布リスト配下の全配布リスト。

アカウントとカレンダーリソースに適用できる権限の場合は、この配布リストの直接のメンバーまたは間接のメンバーである、すべてのアカウントとカレンダーリソースもスコープ内。

ドメイン

特定のドメインが該当します。サブドメインは対象外。

サブドメインの場合、ターゲットとして明確にタグ付けされている必要があります。

ドメインがターゲットのとき、権限は、ドメイン内のすべてのアカウント、カレンダーリソース、配布リストについて付与されます。

設定

グローバル設定専用の権限

グローバルACL

ターゲット種類内の全エントリについての管理者権限。例えば、ドメインでのアカウント作成権限であるグローバルACLに、ACEを追加できます。

この権限が付与されている「委任された管理者」のアカウントは、システム内の全ドメインでアカウント作成ができます。

サーバー

サーバーエントリ

Zimlet

Zimletエントリ

権限

権限とは、「委任された管理者」が、名づけられているターゲット上で実施可能・不可能な機能のことです。権限には、システム定義権限と属性権限があります。

システム定義権限

システム定義権限の種類

  • Presetの権限 (初期設定の権限)。例えば、 createAccount はアカウントの作成で、 renameDomain はドメインのリネームです。

    Presetの権限は固定のターゲット種類に紐づきます。例えば、createAccount はドメイン上のみの権限、renameAccount はアカウント上での権限、getServer はサーバー上での権限です。

    管理者がターゲット上でアクションを実行するのに必要な設定は他にありません。

    Presetの権限には、複数ターゲットへのアクセスを伴うものもあります。被譲与者は、関連する全てのターゲット上で、適当な権限が必要です。例えば、アカウントのエイリアス作成には、アカウントにエイリアスを追加する権限と、ドメインにエイリアスを作成する権限がなければなりません。

属性権限

属性権限の付与により、「委任された管理者」/管理グループは、ターゲット上での特定の属性を編集・閲覧が可能(または不可能)になります。

属性権限の種類

  • Attribute (setAttrs) の権限で、ドメイン管理者は、属性値の閲覧・編集ができます。例えば、 modifyAccount の権限で、ドメイン管理者はそのアカウントのすべての属性を編集できます。

  • Get attribute rights (getAttrs) の権限で、ドメイン管理者は属性値の閲覧ができます。例えば、getAccount の権限は、ユーザーアカウントのすべての属性値を表示します。

権限が付与されている属性の場合、ターゲット上に設定されています。また、読み込み(get)や書き込み(set)という権限の種類も特定されています。

属性権限は、権限の許可と拒否が設定されている、複数の属性の組み合わせで付与されている場合があります。これにより、許可の属性を拒否にすることができます。

Comboの権限

どんなターゲット種類でもComboの権限に指定でき、presetの権限と属性権限の両方をComboの権限に入れることができます。Comboの権限を利用して、即座に複数の属性をターゲット上で付与できます。

拒否の権限

権限には、許可と拒否があります。拒否の権限とは、被譲与者への付与が否定されている権限です。

  • 管理グループに拒否の権限が設定されると、そのグループ内のすべての管理者は、その権限が設定されているターゲットとサブターゲット上でのその権限が否定されます。

  • ある管理者が管理グループに属していてもいなくても、その管理者に拒否の権限が設定されると、その管理者は、その権限が設定されているターゲットとサブターゲット上でのその権限が否定されます。

ある管理グループに、Domain1上でのアカウント作成権限も含む、ドメイン管理者権限が付与されています。この管理グループに属するAdminAに、アカウント作成権限を除いたドメイン管理者の全権限を持たせたいとします。その場合、ターゲットDomain1上での 拒否の createAccount 権限をAdminAに付与します。

同じレベルでの付与では、拒否の権限が常に優先されます。例えば、あるドメイン上でのアカウント閲覧権限が許可されているAdminGroup1。対して、同じドメイン上でのアカウント閲覧権限が拒否されているAdminGroup2。AdminAは両方のグループのメンバーです。このとき、AdminAはこのドメイン内のどのアカウントも閲覧できません。拒否の権限が優先されるからです。

異なるレベルでの付与では、最も細かい権限が優先されます。例えば、User1もメンバーであるGroupDistributionList1内のアカウント閲覧の拒否の権限が、AdminAに付与されています。また、直接User1のアカウント上で、アカウント閲覧の許可の権限が、AdminAに付与されています。このとき、AdminAはUser1のアカウントを閲覧できます。「ターゲット」アカウント上での付与は、配布リスト上での付与に比べて細かいからです。

権限リストの使用

システム権限とその説明は、管理コンソールの権限フォルダの概要ペインにリストアップされています。この権限フォルダを利用すれば、どのシステム定義権限を「委任された管理者」に付与するかを定義できます。このフォルダには、権限名、紐づくターゲット種類、権限の種類、簡易説明が表示されます。

ページ上の権限を選択・クリックすると、別ページに詳細が表示されます。

  • Comboの権限では、Comboの権限に紐づく権限がリストアップされます。

  • 他の種類の権限では、権限に紐づく属性がリストアップされます。

zmprov のコマンドを使用してcomboの権限を確認できます。

  • Comboの権限の直接のサブ権限を確認します。

    zmprov gr adminConsoleDLRights
  • Comboの第2レベルのサブ権限を確認します。

    zmprov gr adminConsoleDLRights -e

システム定義権限のリストを閲覧する

zmprov コマンドを使用して特定のトピック用のシステム定義権限を確認できます:

Table 51. zmprovを使用してコンボの権限を表示
表示対象 使用する zmprov コマンド

アカウント

zmprov gar -t account

カレンダーリソース

zmprov gar -t calresource

提供サービス(COS)

zmprov gar -t cos

配布リスト [1]


1. アカウントやカレンダーリソース向けの権限はすべて、「ターゲット」配布リスト上でも付与できます。配布リスト上でこうした権限が付与されると、そのACEは、その配布リストの直接のメンバーまたは間接のメンバーである、全アカウントと全カレンダーリソースに、その権限を適用します。

zmprov gar -t dl

ドメイン

zmprov gar -t domain

グローバル設定 [2]


2. アカウントやカレンダーリソース、そして配布リスト向けの権限はすべて、「ターゲット」ドメイン上でも付与できます。ドメイン上で権限が付与されると、そのACEは、そのドメイン内の直接のメンバーまたは間接のメンバーである、全アカウントと全カレンダーリソース、全配布リストに、その権限を適用します。

zmprov gar -t config

グローバル付与 [3]


3. グローバルを除く全ターゲット向けの全権限を「ターゲット」グローバルで付与できます。グローバル付与エントリ上で権限が付与されると、そのACEはシステム上の全エントリにその権限を適用します。例えば(ドメイン向けの権限である)createAccountをグローバル付与エントリ上でAdminAに付与すると、AdminAはそのシステム上の全ドメインでアカウント作成ができます。

zmprov gar -t global

サーバー

zmprov gar -t server

Zimlet

zmprov gar -t zimlet

管理権限の委任を実行する

「委任された管理者」アカウントの作成と権限の付与は、その管理者の役割と、その管理者が管理することになるターゲットに指定する権限を定義してから実施します。

「委任された管理者」を更に効果的に管理するには、管理グループを作成して、そのグループに個々の管理者アカウントを追加します。管理グループにより、アクセス制御を役割ベースで作成できます。同じまたはほぼ同じ役割のある管理者たちを1つの管理グループにまとめられます。

管理権限は、下記のいずれの方法からでも委任できます。

  • 管理ウィザードを使用して、管理者または管理グループを作成し、そのアカウントに権限を付与します。

  • 既存の管理者アカウントに権限を付与します。既存の「委任された管理者」アカウントまたは管理グループのアカウントに、新規・既存の権限を追加・修正します。

  • ターゲットのACLページから直接、権限を追加・編集・削除します。

管理者と管理グループ

管理者と管理グループのアカウントは管理コンソールで作成します。

管理ウィザードの使用目的

  1. 管理グループあるいは管理者アカウントを作成します。

    1. 管理グループ は、管理グループを有効化した配布リスト(DL)です。この有効化が「委任された管理者」のDLであるというフラグです。管理グループの管理者を作成して、権限と管理ビューを設定した後に、その管理者のユーザーアカウントを管理グループに追加します。

    2. 管理者アカウント は、アカウント上の管理者を有効化したユーザーアカウントです。

  2. アカウントの管理ビューを設定します。ビューは「直接割り当てられた管理ビュー」一覧から選択します。管理ビューとは、「委任された管理者」の管理コンソールへのログイン時に表示される項目のことです。

    「直接割り当てられた管理ビュー」とは、管理者アカウント上に設定されているビューです。「継承した管理ビュー」とは、アカウントが所属する管理グループ上に設定されているビューです。

  3. 許可を設定します。 「デフォルトの許可を設定」画面の権限一覧は、「直接割り当てられた管理ビュー」カラムで選択した項目の表示に必要です。これら権限を承認して新しい権限を追加するなら「次へ」、権限を設定したくないならページを「スキップ」、権限を承認してウィザードを閉じるなら 完了 を選びます。

管理者アカウントや管理グループへ権限を付与する

システム管理者は、管理者や管理グループに付与されている権限を、アカウントのツールバーにある「許可を設定」のリンクから管理できます。管理にあるアカウントのアドレスのツールバーで 許可を設定 をクリックすると、直接許可のリストと継承許可のリストが内容ペインに表示されます。既存の管理者アカウント上で、権限の追加・編集・削除ができます。

ターゲットにACLを付与する

特定の被譲与者や特定の権限をターゲット上で追加したいとき、直接、ターゲットを編集できます。ターゲットごとにACLページという、許可されたACL一覧のページがあります。ターゲットの権限の追加・編集・削除ができます。管理者アカウント(被譲与者)は、この変更の反映のため、更新されます。

権限の取り消し

グローバル管理者(システム管理者)は、管理者に付与された権限を取り消せます。

管理コンソール:

ホーム > 管理 > アカウント

対象としたい管理者のアカウント開き、ギアアイコンの 許可を設定 をクリックします。

  1. 取消対象の 権限 をクリックし、削除 をクリックします。

  2. 確認画面で はい をクリックします。

「委任された管理者」が権限を取り消しできるのは、その権限がオプション 他の管理者に権限を与えることが可能 を有効にして作成された場合です。

付与された管理権限を一時的に取り消す

「委任された管理者」アカウントの権限を一時的に取り消す場合、対象の管理者のアカウントで、全般情報にある「管理者」のチェックを外す編集をします。ACLはアカウントから削除されません。

管理者へ付与された権限を閲覧する

管理者アカウントや管理グループのアカウントからギアアイコンの「権限を表示」を選択すると、付与されている権限、特定のターゲットに紐づく読み込み可の属性とその書き込み可の属性が表示されます。様々なターゲット向けの権限を確認するには、各タブをクリックします。

定義済みの委任管理の役割

以下の定義済み「委任された管理グループ」は自動で作成されます。これらグループに管理者アカウントを割り当てることができます。

ドメインの管理グループ

zimbradomainadmins という「委任された管理」グループは、アカウント、エイリアス、配布リスト、リソースについて、Zimbra Collaboration のドメインの管理のサポートに必要な全ての権限を付与します。

「委任された管理グループ」zimbradomainadmins に入っている管理者は、アカウントの作成と、アカウント容量・エイリアス・配布リスト・リソースアカウントの設定を含めたアカウント管理ができます。

ドメイン管理者が管理コンソールにログインすると、彼らによる管理が認められている機能しかナビゲーションペインに表示されません。

Zimbraウェブクライアントから管理コンソールへのリンクを作成する

ドメイン管理者の場合、すべてのタスクは管理コンソール上で行われます。ログインを容易にするため、「委任された管理者」アカウントの作成時に、彼らのZWCアカウントに管理コンソールへのリンクを設置できます。

管理コンソールへのリンクは zmprov のコマンドで作成します。

zmprov md {server.example.com} zimbraWebClientAdminReference {https://server.example.com:7071/}

配布リストの管理グループ

zimbradladmin という「委任された管理グループ」は、管理コンソールへのログインと配布リストの管理に必要となる全ての権限を 付与します。

この管理グループに入っている管理者が実施できること

  • アカウントリストの閲覧

  • 配布リストの新規作成、配布リストの削除

  • 配布リスト内メンバーの追加・編集・削除

「委任された管理者」の役割を作成する

複数ドメインの管理

一人のドメイン管理者に複数のドメインを管理させるには、個々のドメインを管理する権限を管理者アカウントあるいは管理グループに付与します。

例えば、 ドメイン domainexample1.com と ドメイン domainexample2.com を domanadministrator1@example.com に管理させるには、管理されるドメインの1つに新たな管理者アカウントを作成します。

  1. 管理するドメインの1つに(domainexample1.com)管理者アカウントを作成します。

  2. ドメイン管理者がドメインの管理に必要となるビューを選択します。ビューが選択されているとき、こうしたビューに紐づく権限が自動的に「デフォルトの許可を設定」画面に表示されます。

  3. 選択したビューに紐づく許可とは違う許可が必要であれば、このドメインの「追加の許可を設定」します。

  4. 管理されるもう一つのドメイン(domainexample2.com)に以下を追加します。

    • 「追加の許可を設定」画面にて、 追加 をクリックします。

    • ターゲット種類に、 domain を選択します。

    • ターゲット名に、対象ドメイン名(domainexample2.com)を入力します。

    • 権限の種類に、システム定義権限を選択します。

    • 権限名に、adminConsoleAccountRightsを入力します。 肯定的権限ですか(許可) のオプションが選択していることを確認します。

    • 追加/その他 をクリックします。

    • 権限名が空白の ACEを追加 画面が再表示されます。adminConsoleDLRights を入力し、 追加/その他 をクリックします。

    • 上記の手順を次の権限名について繰り返します。

      • adminConsoleAliasRights

      • adminConsoleResourceRights

      • adminConsoleSavedSearchRights

      • adminConsoleDomainRights

    • 上記の権限をすべて追加したら、 追加/完了 をクリックします。 追加の許可を設定 画面に、「ターゲット」ドメインに紐づくこれらの権限が表示されます。管理されるドメインを他にも追加するなら、 追加/その他 をクリックし、手順4から繰り返します。それ以外の場合、 完了 をクリックします。

配布リストの管理

配布リストを管理するユーザーを割り当てるには、配布リストの作成とその管理グループの有効化、ビューの選択、配布リストの権限付与、そのリストへのユーザー追加、そのユーザーの管理者設定、が必要です。

  1. 新規に配布リストを作成します。

    • 管理グループ のオプションにチェックを入れます。

    • 配布リストを管理するユーザーをメンバーとして追加します。

    • 管理者の 管理ビュー ページへ遷移し、 管理者が配布リストを閲覧できるように 配布リストビュー にチェックを入れます。

    • 右上の 保存 をクリックします。

  2. 管理者の 許可を設定 ページを開き、以下の権限を追加します。

    Table 52. 権限
    権限名 ターゲット種類 ターゲット 権限の種類

    以下の権限名を持つ役割で、管理者は配布リストを管理できます。

    listDistributionList

    dl

    DLのメールアドレス

    SD Right

    addDistributionListAlias

    dl

    DLのメールアドレス

    SD Right

    addDistributionListMember

    dl

    DLのメールアドレス

    SD Right

    modifyDistributionList

    dl

    DLのメールアドレス

    SD Right

    getDistributionListMembership

    dl

    DLのメールアドレス

    SD Right

    removeDistributionListMember

    dl

    DLのメールアドレス

    SD Right

    このドメイン権限で、ユーザーのアカウントリストが表示されます。管理者が配布リストに追加するアカウントは、このアカウントリストから選択できます。

    listAccount

    domain

    配布リストのメールアドレス

    SD Right

パスワードを変更する

パスワード変更のみの「委任された管理者」を作成するには、管理者あるいは管理グループを作成し、管理ビューを選択し、Combo権限「setAccountPassword」を付与します。

  1. 以下のビューを選択します。

    • アカウントリストビュー パスワードを変更するアカウントの選択ができます。

    • エイリアスリストビュー アカウント名の代わりにエイリアスを使用しているユーザーを検索できます。

  2. 「許可の設定」ページには、選択してある管理ビュー向けの権限が推奨で表示されます。パスワード変更権限の場合、これら権限は設定しません。 スキップ を選択します。 追加 をクリックして下記権限を追加します。

    権限名 ターゲット種類 ターゲット 権限の種類

    setAccountPassword

    domain

    ドメイン名

    SD Right

“メールを表示”へのアクセス権限

“メールを表示”へのアクセス権限は、アカウント、ドメイン、配布リスト上で付与できます。

権限名 ターゲット種類 ターゲット 権限の種類

adminLoginAs

account, domain, dl

アカウント名、ドメイン名、または配布リストのメールアドレス

SD Right [4]


4. ターゲット上での“メールを表示”権限を否定するには、 否定的権限(拒否) を選択します。

管理者からドメインや配布リストにいるアカウントを閲覧できないようにするには、そのアカウントに 否定的権限(拒否) を設定します。

ユーザーに割り当てられている提供サービスの管理

ユーザーに割り当てられている提供サービス(COS)の閲覧と変更ができるように、ドメイン管理者の役割を拡大できます。ドメインのCOSを管理する権限を登録するには、以下の権限をドメイン管理者アカウントあるいはドメイン管理グループに追加します。

システム定義権限をドメインにある各COSに追加します。

Table 53. 提供サービスのシステム定義権限
権限名 ターゲット種類 ターゲット 権限の種類

listCos

cos

COS name

SD Right

getCos

cos

COS name

SD Right

assignCos

cos

COS name

SD Right

このドメイン権限で、ユーザーアカウントの全般情報に提供サービス情報が表示されます。

zimbraCOSId

domain

ドメイン名

Attribute Right
Verb: Write
AR Target: account

メールボックスのクロス検索の管理

以下の権限名を持つ役割で、アカウントの現在およびアーカイブ内のメール検索を実行する「委任された管理者」の役割を作成します。管理者はメールボックスのクロス検索リクエストの作成・中止・削除・パージ・ステータス確認もできます。

この機能を使用するには、アーカイブとディスカバリ機能がインストールされていなければなりません。
権限名 ターゲット種類 ターゲット 権限の種類

adminConsoleCrossMailboxSearchRights

(combo)

メールボックスのクロス検索が実行されるサーバー名

SD Right

全機能の利用のため、この役割にはアカウント作成機能も含まれています。管理者が検索結果を受け取るターゲットメールボックスを作成できるようにするためです。この役割にアカウント作成機能を持たせたくない場合は、以下の否定的権限も付与します。

権限名 ターゲット種類 ターゲット 権限の種類

CreateAccount

domain

ドメイン名

SD Right [5]


5. ターゲット上でのアカウント作成権限を否定するには、 否定的権限(拒否) を選択します。

メールボックスのクロス検索結果の入ったターゲットメールボックスを管理者に閲覧させたい場合、そのメールボックスだけを閲覧できる権限を付与します。

権限名 ターゲット種類 ターゲット 権限の種類

adminLoginAs

account

メールボックスのクロス検索のターゲットアカウント名

SD Right [6]


6. ターゲット上での“メールを表示”権限を否定するには、 否定的権限(拒否) を選択します。

Zimletを管理する

以下の権限名を持つ役割で、Zimletの作成・配備・閲覧ができる「委任された管理者」の役割を作成できます。

権限名 ターゲット種類 ターゲット 権限の種類

adminConsoleZimletRights

server, domain

サーバ名またはドメイン名

SD Right

adminConsoleAccountsZimletsTabRights

server, domain

サーバ名またはドメイン名

SD Right

リソースを管理する

以下の権限名を持つ役割で「委任された管理者」はリソース作成・管理ができます。

権限名 ターゲット種類 ターゲット 権限の種類

adminConsoleResourceRights

combo

サーバ名、またはドメイン名

SD Right

保存された検索へのアクセス

以下の権限名を持つ役割で「委任された管理者」は管理コンソールのナビゲーションペインにある検索セクションに保存された全ての検索クエリにアクセスできます。

権限名 ターゲット種類 ターゲット 権限の種類

adminConsoleSavedSearchRights

combo

サーバ名、またはドメイン名

SD Right

サーバーのステータスページへのアクセス

以下の権限名を持つ役割で「委任された管理者」はサーバーのステータスページを閲覧できます。この権限の付与だけでなく、管理ビューの グローバルサーバーステータスビュー も選択する必要があります。

権限名 ターゲット種類 ターゲット 権限の種類

adminConsoleServerStatusRights

global

SD Right

グローバル管理者アカウントとして設定されているアカウントにはACLを付与できません。グローバル管理者アカウントは、自動的にZCS上の全権限を保持しています。グローバル管理者アカウントにACLが追加されたとしても、無視されます。「委任された管理者」アカウントがグローバル管理者アカウントへと変更されたら、そのアカウントに紐付いているACLはすべて無視されることになります。

ZCS サーバーの監視

Zimbra Collaboration (ZCS) では、Zimbraサーバーの状態、使用容量、メールのフローの監視のため、以下の機能を提供しています。

  • Zimbra のLoggerパッケージでサーバーの統計やステータスの収集・表示と日次夜間レポートを発行します。

  • メールボックスの割り当て容量監視

  • MTAのメールキュー監視

  • ログファイル

また、特定のエラーメッセージでSNMPトラップを作成し、SNMPのツールで監視することができます。

システム全体のヘルスチェックはこのドキュメントの範囲対象外です。

Zimbra Logger

LoggerにはSyslogの情報収集とレポート作成のツールが含まれています。Loggerのインストールは任意ですが、インストールしていない場合、サーバーの統計やステータス情報は収集されません。

複数の Zimbra Collaboration サーバーをご利用の環境では、Loggerは一つのメールボックスサーバーのみで有効にします。このサーバーはサーバー監視のホストとなります。監視ホストは他のZimbra Collaborationサーバーのステータスをすべて確認し、Zimbraの管理コンソール上に情報を表示します。リアルタイムでサービスのステータス、MTA、迷惑メール対策/ウイルス対策トラフィック、パフォーマンスの統計を表示できます。また、Loggerは日次で、毎日のメッセージ数、平均到達遅延、発生したエラーなどのメール運用状況レポートを作成します。

マルチサーバーの環境では、各サーバーにsyslog設定ファイルをセットアップし、管理コンソール上でサーバー統計が表示できるようにしてください。加えて、Loggerのホストを有効にする必要があります。 Zimbra Collaboration のインストール時にこの設定をしていない場合、今すぐ実行してください。

サーバー統計を有効にする

サーバーの統計を有効にすると、過去の48時間、30日間、60日間、1年間の間に処理したメッセージ分の、インバウンドのメッセージボリューム、インバウンドのメッセージ数、迷惑メール対策/ウイルス対策アクティビティ、ディスクの使用容量を、システム全体やサーバー単位で確認できます。

  1. 各サーバーでRootユーザーにて /opt/zimbra/libexec/zmsyslogsetup を実行します。サーバー統計の収集ができるようにSyslog設定ファイルが更新されます。

  2. Loggerの監視ホストでは、リモートマシンのsyslogメッセージを受けとるために syslog を有効化します。 詳細は https://wiki.zimbra.com/wiki/Configuring-Logger-Host を確認してください。

上記の手順はシングルサーバーの環境では必要ありません。

サーバーステータスを監視する

管理コンソール:

ホーム > 監視

Server Status のページに、すべてのサーバーとサービス、それらのステータス、最後にチェックされたサーバーステータスがリストアップされます。サーバーには、MTA、LDAP、メールボックスサーバーが含まれています。サービスにはMTA、LDAP、メールボックス、SNMP、迷惑メール対策、ウイルス対策、スペルチェック、Loggerが含まれています。

停止しているサーバーを始動するには zmcontrol のCLIコマンドを使用します。管理コンソールからもサービスの開始と停止ができます。

サーバーのサービスの有効化/無効化

管理コンソール:

ホーム > 設定 > サーバー → サーバー名

サーバーのサービスは サーバー → サーバー名 ページで有効化/無効化します。ナビゲーションペインの サービス をクリックし、有効化/無効化するサービスを選択します。

サーバーのパフォーマンス統計

LoggerのパッケージをZimbraのメールボックスサーバーへインストールした場合、サーバー統計には、メッセージ数、メッセージボリューム、迷惑メール対策/ウイルス対策のアクティビティが棒グラフで表示されます。過去の48時間、30日間、60日間、365日間の情報を表示します。

ナビゲーションペインで各サーバー統計を選択すると、すべてのメールボックスサーバーを統合した統計が表示されます。「サーバー統計」にて、特定のサーバーをダブルクリックすると、そのサーバーの関連統計のみ、閲覧できます。また、サーバー固有の情報としてディスクの使用容量、セッション情報、メールボックスの割り当て容量も閲覧できます。

システム全体の情報は次のとおりです。

  • メッセージ数 — メッセージのトランザクション数。トランザクションとは、ユーザーごとの(Postfixによる)メッセージSMTP受信または(mailboxdによる)LMTP配信です。例えば、メッセージ1件が3人へ送信されるとき、トランザクション数は6です。PostfixへのSMTPが3回、mailboxdへのLMTPが3回です。メッセージ数は6回ごとに増分します。

  • メッセージボリューム — 1時間単位と1日間単位で処理したバイトサイズを表示します。グラフは全体のインバウンドデータをバイト単位で表示します。

  • 迷惑メール対策/ウイルス対策アクティビティ — 迷惑メールやウイルスがあるかどうかを検査したメッセージ数と、迷惑メールとしてタグ付けされたまたはウイルスが感染していると判断されたメッセージ数が表示されます。AS/AVの合計は、スキャンされたメッセージごとに1つ増えます。メッセージ1件が3人へ送信されるとき、AS/AVではメッセージ1件しか処理されません。

    メッセージ数と迷惑メール対策/ウイルス対策アクティビティのグラフは、以下の理由によりメッセージ数が異なります。

    • システム構成によってはアウトバウンドメッセージのチェックが必要とされないため、Amavisdのフィルターを通過しない可能性があります。

    • メッセージの宛先へ配信される前に、メッセージはAmavisdで迷惑メールやウイルスがスキャンされています。メッセージ数はメッセージを実際に受信者が受信した件数を表します。

サーバー固有の情報には以下も含まれます。

  • ディスク — 選択したサーバーの使用中のディスク容量と空のディスク容量が表示されます。直近の1時間、1日、1か月、1年間の情報が表示されます。

  • セッション — アクティブなウェブクライアント、管理者、IMAPのセッション情報が表示されます。オープンされているアクティブセッション、ログインユーザー、セッションが作成された日時、セッションが最後にアクセスされた日時を確認できます。

  • メールボックスの割り当て容量 — 各アカウントの情報が、メールボックスサイズの降順に表示されます。詳細は メールボックスの割り当て容量を監視する を参照してください。

Loggerのメールレポートを設定する

Loggerは、メールのアクティビティについてのレポートを毎日23:30に発行し、管理者のメールアドレスへ送信します。

レポートに含まれるアカウント数を設定できます。デフォルトは、送信者アカウントが25、受信者アカウントが25です。

  • 受信アカウントの最大数を変更します。

    zmlocalconfig -e zimbra_mtareport_max_recipients=<数字>
  • 送信アカウントの最大数を変更します。

    zmlocalconfig -e zimbra_mtareport_max_senders=<数字>

ディスク容量の通知を設定する

定期的にディスクの使用容量を確認し、ディスクの空き容量が少ない際にはサービスの継続維持のための対策をとることが重要です。ディスク空き容量が少なくなると、管理者アカウントに警告メールメッセージが自動送信されます。デフォルトの設定では、ディスク使用率85%で警告メッセージが、ディスク使用率95%で重要な警告メッセージが送信されます。

この条件は変更可能です。zmlocalconfig を使用し、警告メッセージのためのディスクのしきい値を変更します。

  • 警告のメッセージ

    zmdisklog_warn_threshold
  • 重要な警告メッセージ

    zmdisklog_critical_threshold

zmcontrolでのサービス起動時にこのしきい値を超えていると、サービスの開始前に警告が表示されます。ディスクをクリーンアップして、空き容量を増やしてください。

サーバーの監視

Zimbra Collaboration サーバーでは、複数のパフォーマンス用統計を収集しているため、問題や負荷の障害のトラブルシューティングに役立ちます。

管理コンソール:

ホーム > 監視 > 高度な統計

高度な統計 のページにて、CPU, IO, mailboxd, MTAのキュー、MariaDBなどのコンポーネントについての統計情報に基づく様々な図表を高度なグラフのオプションで生成できます。

高度な統計グラフを表示するには、グループ項目から1つ選択し、カウンターリストから表示する情報を特定します。

幅広いデータから情報を取得できます。

  • cpu.csv — CPUの使用率。このグループは、CPU使用をトラッキングし続けるカウンターを含みます(iowait, idle, system, user, time等)。 CPU情報はサーバーレベルやプロセスレベルでトラッキングできます。

  • df.csv — ディスクの使用率。ディスクパーティションごとにトラッキングされます。

  • fd.csv — ファイル記述子のカウント。システムファイルの記述子の使用超過時間をトラッキングし続けます。主に「ファイル記述子が足りない」エラーをトラッキングするための機能です。

  • mailboxd.csv — Zimbra Collaboration サーバーとJVMの統計。Mailboxdの統計がほぼ全てです。役に立つカウンター値にはheap_used, heap_free, imap_conn, soap_sessions, pop_conn, db_conn_count があります。

  • mtaqueue.csv —  Postfixのキュー。メッセージ数とバイト単位でのサイズにによって、メールのキューサイズを計算します。

  • proc.csv — Zimbraプロセスのプロセス統計です。例えば、mailboxd/java, MariaDB, OpenLDAP など。

  • soap.csv — SOAPリクエストのプロセス時間。

  • threads.csv — JVMのスレッドカウント。接頭語が一致しているスレッド数を数えます。

  • vm.csv — (vmstatコマンドからの)Linux VMの統計。

  • io-x.csvio.csv — iostat(1) のコマンド (io-x.csviostat -x) からのストアデータ。

DoSのフィルター条件を設定する

過剰な負荷をかけるリクエストはdenial-of-serviceフィルター (DoSFilter) により制限されます。DoSFilterでは、短時間に大量のリクエストを送信しているクライアントを抑制します。

なお、DosFilter は HTTP と HTTPS リクエストにのみ適用されますので、他のプロトコル、たとえば POP3、IMAP、および SMTP には適用されません。ご利用の環境に合わせて設定を変更できます。ZCSではデフォルトでDoSFilterは有効です。DoSFilterの無効化は推奨しません。連続でのログイン失敗を回避する詳細につきましては、 ログインポリシーを管理する をご参照ください。

False Positiveを判断する

時折、Zimbra Connector for Outlook (ZCO)、モバイルActiveSyncのクライアント、あるいはzmprovコマンドを何か 実行することで、DoSFilterが起動されることがあります。そうすると、Zimbraのメールボックスサービスは使用できなくなります。DoSFilterが適用されたかどうかを以下のログから確認できます。

  • /opt/zimbra/log/sync.log

Example 17. DoSFilterを表示している sync.log のエントリ
2013-01-15 15:52:20,426 WARN [qtp1635701107-91:https://x.x.x.x/
Microsoft-Server-ActiveSync?User=zsupport2&DeviceId=Appl5ddddd3NR&DeviceType=iPhone&Cmd=FolderSync][name=zsupport2@domain.com;mid=64;ip=10.1.2.3;Cmd=FolderSync;DeviceID=Appl5K0113UN3NR;Version=12.1;] sync - Service exception com.zimbra.common.service.ServiceException: error while proxying request to target server: HTTP/1.1 503 Service Unavailable
ExceptionId:qtp1635701107-91:https://10.10.0.54:443/Microsoft-Server-ActiveSync?User=zsupport2&DeviceId=Appl5K0113UN3NR&DeviceType=iPhone&Cmd=FolderSync:1358286740426:c5ca7f36bb0a038f Code:service.PROXY_ERROR Arg:(url, STR,"http://mail.domain.com:80/service/soap/SyncRequest"
  • /opt/zimbra/log/zmmailboxd.out

Example 18. DoSFilterを表示している zmmailboxd.out のエントリ
2013-01-15 15:57:32.537:WARN:oejs.DoSFilter:DOS ALERT:ip=127.0.1.1,session=null,user=null

DOSFilterの設定をカスタマイズする

以下の属性を使用して、zmprovでDoSFilterを設定します。これらの属性は、グローバル設定またはサーバー設定として設定できます。サーバーに設定すると、サーバー設定がグローバル設定をオーバーライドします。

設定は変更できますが、デフォルトの設定を推奨します。

属性 説明

DoSFilterの延長期間
zimbraHttpDosFilterDelay-Millis

レート制限を超えたリクエストに与えられる延長期間です。デフォルトの値は-1です。

  • -1 = リクエストを拒否する。

  • 0 = 延長期間なし(直ちに処理)。

  • その他の値 = 延長期間。単位はミリ秒(ms)。

zmprov mcf zimbraHttpDosFilterDelayMillis {x}

1秒間にリクエストできる最大DoSFilter 数
zimbraHttpDosFilterMaxRequestsPerSec

一つの接続の1秒あたりの最大リクエスト数です。この値以外のリクエストは抑制されます。デフォルトの値は30で最小値は1です。

zmprov mcf zimbraHttpDosFilterMaxRequestsPerSec {x}

DoSFilter IP アドレスのホワイトリスト
zmprov mcf zimbraHttpThrottleSafeIPs {x.x.x.x,192.168.x.x}

DoSFilterの適用時、無視されるIPアドレス。デフォルトの値はありませんが、以下のループバックIPはデフォルトでホワイトリストに記載されています。

  • 127.0.0.1

  • ::1

IPアドレスはカンマで区切ります。

zmprov mcf zimbraHttpThrottleSafeIPs {addresses}

上記属性の変更後は、メールボックスサーバーの再起動が必要です。

zmmailboxdctl restart

ZCS 8.0.3 以降のバージョンでのチューニング課題

  • ZCS メンバーサーバー —  シングルのマスターLDAPで管理しているZCSサーバーは自動的にIPアドレスでホワイトリストに記載されます。こうしたホストは GetAllServersRequest から分かります。 zmprov gas として入力してください。

  • 外部プロビジョンのホスト/SOAP API — 外部プロビジョンのホストをIPホワイトリストに追加して、DoSFilterが特定のリクエストを確実にブロックしないようにできます。例えば、メールボックスの再インデックスは、1秒間に複数のリクエストを発生させてDoSFilterを起動させる恐れがあります。

メールキューを使用する

Zimbra MTAのメール受信時、配信管理のため、メールを次のキューに回しします:受信、アクティブ、遅延、保持、破損。

受信 のキューは受信した新着メールを保持します。各メッセージは固有のファイル名で識別されます。アクティブのキューに空きがあると、アクティブキューに移されます。通常動作では、メッセージはこのキューから即座に他のキューに移されます。

アクティブ キューは、送信できる状態のメッセージを保持します。MTAは、アクティブキューに一度に保持できる最大メッセージ数を設定しています。ここから、メッセージはウイルス対策と迷惑メール対策のフィルターに回され、戻ってきてから、他のキューに移されます。

配信できなかったメッセージは 遅延 キューに置かれます。配信失敗の理由は遅延キュー内のファイルに記録されます。このキューは、メッセージ再送信のために頻繁にスキャンされます。設定された最大配信試行回数を超えるとメッセージの送信が失敗します。メッセージは元の送信者にバウンスされます。デフォルトのバウンスキュー保持期間は5日間です。

保持 キューには、処理できなかったメッセージが置かれます。メッセージは、管理者が移動するまでこのキューに留まります。保持キューにあるメッセージが配信試行されることはありません。

破損 キューには、破損して読み込みできないメッセージが格納されます。

バウンスキュー保持期間を変更する

  • MTAサーバーのバウンスキュー保持期間は5日間に設定されています。このデフォルトのキュー保持期間設定を変更します。

    zmlocalconfig -e bounce_queue_lifetime={#}
  • 恒久的にメッセージを送信者へ返送して、最初に遅延キューに移動することはしません。

    zmlocalconfig -e zimbraLmtpPermanentFailureWhenOverQuota=TRUE

バウンスされたメッセージを送信者に通知する

バウンスキュー保持期間でメッセージを送信者に返送する前に、送信者は、送信メッセージが配信されずに遅延キューにある旨の通知を受け取ることができます。

以下の属性を設定して、送信者に警告メッセージを送信する設定をします。

  • まだキューにあるメッセージのヘッダーに、送信者が受け取るまでの期間を設定します。

    zmlocalconfig -c postfix_delay_warning_time=0h
  • MTAが配信しなかったメッセージのヘッダーに、Postmaster通知の受信者を設定します。

    zmlocalconfig -c postfix_bounce_notice_recipient=postmaster
  • Postmasterに報告されるエラークラスのリストを設定します。

    zmlocalconfig -c postfix_notify_classes=resource,software
こうしたPostfix属性を変更することによる影響の詳細は、Postfixのドキュメントを参照してください。

メールキューを管理コンソールから監視して、配信問題を確認できます。

メールキューを閲覧する

管理コンソール:

ホーム > 監視 > メールキュー

メール配信で問題が生じている場合、管理コンソールの メールキュー ページからメールキューを閲覧し、メール配信問題を改善できるかどうかを検討することができます。メールキューを開くと、その時点での遅延、受信、アクティブ、保持、破損のキュー内容を閲覧できます。メッセージ数、配信元、配信先も閲覧できます。

キューごとの要約ペインで受信者のドメイン、起点IP、送信者のドメイン、受信者アドレス、送信者アドレスによる要約を確認できます。遅延のキューではエラーのタイプからも確認できます。要約の項目を選択すると、メッセージペインで、メッセージのエンベロープ情報の詳細を確認できます。

メッセージペインでは、要約ペインで選択した検索フィルター結果であるメッセージの詳細なエンベロープ情報が表示されます。

以下のメールボックスキューの動作は、キューにあるすべてのメッセージに適用されます。

  • 保持 で、一時的に配信停止したいメッセージを選択します。受信、アクティブ、遅延、破損のメッセージを、この保持キューに移動できます。管理者がマニュアルで別のキューに移さない限り、保待キューに留まります。

  • 解放 で、保持キューにあるメッセージをすべて解放します。こうしたメッセージは遅延キューに移されます。

  • キューへの再配置 で、閲覧中のキューにあるメッセージをすべて再配置します。メッセージの再配置は、設定の問題で遅延していたメッセージを、その問題が修正された後に送信するために使うことができます。メッセージは再度判定されるため、これまでのペナルティはリセットされます。

  • 削除 で、閲覧中のキューにあるメッセージをすべて削除します。

Zimbra MTA、PostfixキューファイルIDは再利用されます。メッセージの再配置や削除では、キューIDではなく、メッセージのエンベロープ情報をメモしてください。メールキューのリフレッシュ時、キューIDが別のメッセージに再利用されることが起こり得ます。

メッセージキューをフラッシュする

サーバーのすべてのメッセージは、フラッシュできます。メールキューのツールバーからフラッシュをクリックすると、配信はただちに、遅延キュー、受信キュー、アクティブキューにある全メッセージについて実行されます。

メールボックスの割り当て容量を監視する

メールボックスの割り当て容量は、ユーザーアカウントにある、メールメッセージ、添付ファイル、カレンダー予定、タスクに適用されます。この上限に達すると、全メールメッセージは拒否されます。ユーザーは、アカウントからメールを削除して、ゴミ箱を空にすることも含めて、容量を下回らせる必要があります。あるいは、管理者が上限を引き上げるという選択肢もあります。

割り当て容量を閲覧する

管理コンソールの サーバー統計 から、個々のアカウントのメールボックスの割り当て容量を確認できます。メールボックスの割り当て容量ページでは、アカウントごとのメールボックスのサイズと使用中の容量を簡単に確認できます。

管理コンソール:

ホーム > 監視 > サーバー統計

  1. 統計を確認したい サーバー名 を選択します。

  2. ナビゲーションペインにて、メールボックスの割り当て容量 を選択します。メールボックスの割り当て容量ページに以下の情報が表示されます。

    • 割り当て容量のカラムは、アカウントに割り当てられているメールボックスの容量を表します。割り当て容量は提供サービスまたは各アカウントに設定できます。

    • メールボックスのサイズのカラムは、現在使用中のディスク容量を表します。

    • 使用中の割り当て容量のカラムは、使用されている容量の割合を表します。

割り当て容量を増減させる

提供サービスまたは各アカウントから、容量のしきい値を設定できます。設定すると、到達時、メールボックスの割り当て容量が上限に近い旨を知らせる警告メッセージがユーザーに自動送信されます。

管理コンソール:

ホーム > 設定 > 提供サービス → 提供サービス名 → 詳細設定
ホーム > 管理 > アカウント → アカウント名 → 詳細設定

  1. 「割り当て容量」のセクションまでスクロールダウンします。

  2. 割り当て容量設定を変更します。

  3. 保存 をクリックします。

MobileSyncの統計を閲覧する

管理コンソールの監視セクションにある MobileSync統計 ページには、Zimbra Collaborationのシステム上で現在接続中のActiveSync端末数が表示されます。

認証の失敗を監視する

辞書攻撃や分散攻撃を防ぐために、zmauditwatch を設定できます。このスクリプトでは、更に高度な攻撃を検出しようとしています。そのため、認証の失敗が起きている場所とその頻度を、Zimbraメールボックスサーバーの全アカウントについて確認します。そして、管理者のメールボックスに警告通知を送信します。

認証の失敗の確認タイプ

  • IP/アカウントのハッシュ確認 — デフォルトでは、IP/アカウントの組み合わせで60秒以内に10回、認証が失敗したら警告メールを送信します。

  • アカウント確認 — デフォルトでは、IPアドレスを問わず60秒以内に15回、認証が失敗したら警告メールを送信します。この確認では、特定のアカウントへのハイジャックベースの分散攻撃を検出しようとしています。

  • IP確認 — デフォルトでは、あるアカウントを問わず60秒以内に20回、認証が失敗したら警告メールを送信します。この確認では、複数アカウントをまたいだ特定のホストベースの攻撃を検出しようとしています。

  • 完全な認証失敗の確認 — デフォルトでは、IPアドレスとアカウントを問わず、60秒以内に1000回、認証が失敗したら警告メールを送信します。デフォルトは、メールボックスサーバーにあるアクティブアカウントの1%になるように、修正する必要があります。

メール警告のトリガーとなるデフォルト値は、以下のzmlocalconfigパラメーターで変更します。

  • IP/アカウントハッシュ値は、zimbra_swatch_ipacct_threshold を変更します。

  • アカウント確認には、 zimbra_swatch_acct_threshold を変更します。

  • IP確認には、 zimbra_swatch_ip_threshold を変更します。

  • 完全な認証失敗の確認には、 zimbra_swatch_total_threshold を変更します。

zimbra_swatch_notice_user には、警告を受け取る必要のあるメールアドレスを設定します。

ログファイルを閲覧する

Zimbra Collaboration の動作やエラーは、syslogデーモン経由で統合されたシステムログとローカルファイルシステム上のZimbra専用ログファイルに記録されます。以下のログファイルがプライマリログです。調査やトラブルシューティングに使用されます。 Zimbra Collaboration の動作が記録されるローカルログは /opt/zimbra/log ディレクトリにあります。

  • audit.log — このログには、ユーザーと管理者の、認証アクティビティ情報とログインの失敗が入ります。加えて、設定の変更をトラッキングできるように管理者によるアクティビティも入ります。

  • clamd.log — このログには、ウイルス対策アプリclamdのアクティビティが入ります。

  • freshclam.log — このログには、clamdのウイルス定義更新に関するログ情報が入ります。

  • mailbox.log — このログは、mailboxdのlog4jサーバーログで、メールボックスサーバーのログが入ります。これには、メールボックスストア、LMTPサーバー、IMAPとPOPサーバー、Indexサーバーが含まれます。

  • myslow.log — このスロークエリーログには、実行に long_query_time 以上の秒数がかかった、メールボックスサーバーの全SQL文が入ります。

    long_query_time/opt/zimbra/conf/my.cnf 内に定義されています。
  • spamtrain.log — このログには、cronから定期的にスケジュールされた zmtrainsa の実行中の出力が入ります。

  • sync.log — このログには、Zimbra Collaboration のモバイルシンク動作についての情報が入ります。

その他のログ

  • /opt/zimbra/jetty/logs/ — ここにJetty固有のアクティビティが記録されます。

  • /opt/zimbra/db/data/<hostname>.err — メッセージストアデータベースのエラーログです。

  • /opt/zimbra/logger/db/data/<hostname>.err — Loggerデータベースのエラーログです。

システムのsyslogに記録されるZimbra Collaboration のアクティビティ

  • /var/log/zimbra.log — Zimbraのsyslogで、Zimbra MTA(Postfix、amavisd、迷惑メール対策、ウイルス対策)、Logger、認証(cyrussasl)、ディレクトリ(OpenLDAP)のアクティビティの詳細が分かります。デフォルトでは、LDAPのアクティビティは zimbra.log にログ出力されます。

Syslog

Zimbra Collaboration は、システムのsyslogデーモンを修正して、メールとローカルsyslogファシリティのデータを /var/log/zimbra.log に取得するようにしています。この修正により、syslogdが、Zimbra Collaboration コンポーネントであるPostfix、Amavis、ClamAV、mailboxd、zmconfigd、Loggerから、 データを取得できます。SNMPモジュールはログファイルのデータを使用して、致命的なエラー用のトラップを作成します。zmloggerデーモンも、このファイルにあるデータを集めて、管理コンソールから Zimbra Collaboration の使用率の統計を提供できるようにしています。

デフォルトでは、mailboxdは出力内容を /opt/zimbra/log/mailbox.log にはくように設定されています。mailboxdがcentralizedsyslogdインフラを利用できるように、グローバルに、またはサーバーで下記を実行します。

zmprov mcf zimbraLogToSysLog TRUE

log4jを使用し、ログ情報をカスタムに設定する

Zimbra Collaboration サーバーは、ログマネージャーに log4j のJavaログパッケージを使用しています。デフォルトでは、 log4j にローカルシステムへログ出力させるように設定しています。他の場所に直接出力するように log4j を設定できます。log4j の利用について詳細は、log4j のウェブサイト Log4j website を確認してください。

ZCSは、log4jの変更をチェックしません。全アカウントのLoggerを削除し、 /opt/zimbra/conf/log4j.properties 内にリロードするには、 zmprov resetAllLoggers コマンドを使用します。

ログの詳細レベル

デフォルトのログレベルは、INFO、WARNING、ERROR、FATALで作成されるログを含めるように設定されています。問題が発生し始めたら、DEBUGやTRACEのレベルを有効にできます。

ログのレベルを変更するには、log4j のプロパティ、 log4j.propertieslog4j.logger.zimbra を編集します。

DEBUGを有効にする場合、特定のカテゴリをデバッグすることもできます。例えば、POP動作に関するデッバグ情報を確認するには、 logger.zimbra.pop=DEBUG を使用します。

log4j 内にあらかじめ定義されているカテゴリ:

zimbra.account

アカウントの操作

zimbra.acl

ACLの操作

zimbra.backup

バックアップと復元

zimbra.cache

Inmemoryのキャッシュ操作

zimbra.calendar

カレンダーの操作

zimbra.dav

DAVの操作

zimbra.dbconn

データベースの接続トレース

zimbra.extensions

サーバー拡張のローディング

zimbra.filter

メールのフィルターリング

zimbra.gal

GALの操作

zimbra.imap

IMAPプロトコルの操作

zimbra.index

Indexの操作

zimbra.io

ファイルシステムの操作

zimbra.ldap

LDAPの操作

zimbra.lmtp

LMTPの操作(受信メール)

zimbra.mailbox

基本的なメールボックス操作

zimbra.misc

その他

zimbra.op

メールボックス状態の変更

zimbra.pop

POPプロトコルの操作

zimbra.redolog

Redoログの操作

zimbra.security

セキュリティイベント

zimbra.session

ユーザーのセッショントラッキング

zimbra.smtp

SMTPの操作(送信メール)

zimbra.soap

SOAPプロトコルの操作

zimbra.sqltrace

SQLのトレース

zimbra.store

メールストアのディスク操作

zimbra.sync

シンククライアントの操作

zimbra.system

スタットアップ/シャットダウン等のシステムメッセージ

zimbra.wiki

Wikiの操作

zimbra.zimlet

Zimletの操作

ログレベルへの変更は直ちに適用されます。
Table 54. ログイベント
レベル ローカル? Syslog SNMPトラップ 使用時

FATAL

Y

Y

Y

アプリケーションを停止するか大多数のユーザーに影響が及ぶほどのかなり深刻なエラーイベントが指定されます。例えば、MariaDBのデータベースに接続できない等。

ERROR

Y

Y

N

アプリケーションが継続実行できるか特定のユーザーのみに影響があるようなエラーイベントが指定されます。例えば、シングルメールボックスのインデックスの破損や、メールボックスからメッセージを削除できない等。

WARN

Y

N

N

潜在的な問題になりそうな状況であるものの回復が可能または無視しても良いものが指定されます。例えば、ユーザーログインの失敗等。

INFO

Y

N

N

アプリケーションの進捗や基本的なトランザクションレベルのロギングを知らせる情報メッセージが指定されます。例えば、サーバーの起動、メールボックスの作成・削除、アカウント作成等。

DEBUG

Y

N

N

お客様が問題をデバッグするのに一般的に役立つようなイベント。

※ いくつかの重要でないメッセージ、例えばサービスの開始メッセージ、はトラップを作成します。

プロトコルトレース

プロトコルのトレースは以下のログカテゴリで使用できます。

zimbra.smtp
zimbra.lmtp
zimbra.soap
zimbra.imap
zimbra.imap-client
zimbra.pop
zimbra.pop-client

mailbox.logを確認する

mailbox.log ファイルには、メールボックスサーバー上で実行されたアクション、例えば、認証セッション、LMTP、POP3、IMAP、Indexサーバーを含めて、全アクションが入ります。 mailbox.log を確認して、サーバーの健康状態のチェックや、問題の識別に役立てます。

mailbox.log は、有効・無効なログイン試行、アカウントのアクティビティ、例えば、メールオープン、アイテムの削除や作成、新着メッセージのインデックス化等と、サーバーの開始・停止などのサーバーのアクティビティを記録します。メールサーバー上のアクティビティの進捗は、INFOとして記録されます。期待したアクティビティ結果にならずエラーが発生した場合、エクセプションがログに記録されます。

シングルアカウントに、ログオプションをセットアップして、1ユーザー分のアカウントアクティビティをトレースできます。これにより、無関係のアカウント分のログメッセージで、mailbox.logがいっぱいにならずに済みます。 詳細は、コマンドラインのユティリティにある zmprov のその他のセクションを参照してください。

ログのパターン

デフォルト設定では、 mailbox.log のログメッセージは以下の Log4j パターンを使用しています:

%d %-5p [%t] [%z] %c{1} - %m%n

このパターンではデータが6ブロックとなります:

  • 日時 (実例: 2018-01-22 19:23:07,100)

  • ログレベル (実例: INFO)

  • スレッド名 (実例: [qtp1043351526-547:https:https://localhost:7071/service/admin/soap/DeleteAccountRequest], [Index-9], など)

  • Zimbra Collaboration の関連

  • コンポーネント名 (実例: soap, mailbox, mbxmgr, など)

  • ログメッセージ 注意: ログメッセージが複数行で記録される場合があります。ログメッセージに例外が含まれている場合、スタックトレースは必ずエラーメッセージの下に新しい行で記録されます。

Log4j パターンの詳細につきましては、 Log4j PatternLayout documentation をご参照ください。

mailbox.log のスレッド名

内部コンポーネントを特定するため、mailbox.log のスレッド名には特定のプレフィックスが付けられます。ほとんどのスレッドは次の条件で指定されます: "{スレッドのプレフィックス}-{スレッド番号}" または "{スレッドのプレフィックス}-{スレッド番号}:{url}".

なお、Zimbra Collaboration にはこれらの {スレッドプレフィックス} 値を使用しております: btpool, pool, LmtpServer, ImapServer,ImapSSLServer, Pop3Server, Pop3SSLServer, ScheduledTask, Timer, AnonymousIoService, CloudRoutingReaderThread, GC, SocketAcceptor, Thread, qtp.

qtp のプレフィックスとなるスレッドは Jetty の QueuedThreadPool により発行しており、異なるネーム条件があります: "qtp{ハッシュコード}-{スレッド番号}:{url}" {ハッシュコード} はスレッドのオーナーとなる QueuedThreadPool のインスタンスのハッシュコード値となります。(詳細につきましては Java プラットフォームのドキュメンテーションから Object::hashCode をご参照ください)

スレッド名の {スレッド番号} の数はスレッドファクトリ毎に一つずつ増加していきます。mailboxd プロセスが停止、または再起動された場合、スレッド番号がリセットされます。

以下の事例のように、SOAPリクエストを処理するスレッドの記録するログメッセージは、スレッド名に送信したリクエストのURLを {url} に記録する場合が多いです。

Mailbox Log Entry for SOAP

Zimbra Collaboration の既知のバグにより、以下の事例のようにスレッド名の {url} 部分に、プロトコルを特定できるプロトコル情報が重複して含まれる場合があります。

[qtp1043351526-547:https:https://localhost:7071/service/admin/soap/DeleteAccountRequest]

  • mailbox.log で Zimbra Collaboration の関連*

ログパターンの [%z] セクションが Zimbra Collaboration の関連性を表しており、`key=value`で属性と値のペアを「;」の文字で区切っています。値に「;」文字が含まれている場合、「;;」として記入されます。たとえば、browser UserAgent のストリングは「;」の文字がよく使われています。実例: "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.100 Safari/537.36" mailbox.log ではこの UserAgent のストリングは以下のように表示されます:

ua value with double semi-colon

現在、以下の属性と値のペアがサポートされており、異なる順番や組み合わせでログメッセージに記録される場合があります。

  • ip — リクエストする TCP/IP クライアントの IP アドレス

  • oip — 送信元の IP アドレス。NGINX のプロキシ経由でリクエストを送信した場合、この値はクライアントアプリのIPアドレスが含まれますが、ip の属性値はプロキシサーバの IP アドレスとなります。

  • cid — 順番に増加するサーバのコネクションID - 特定のコネクションを監視する場合に役立ちます。

  • id — ターゲットアカウントの ID

  • name — ターゲットアカウントの名前 (メールアドレス)

  • aid — 認証されたアカウント ID。認証したアカウントとターゲットアカウントが異なる場合にのみ表示されます。

  • aname — 認証されたアカウント名。認証したアカウントとターゲットアカウントが異なる場合にのみ表示されます。

  • mid — リクエストしたメールボックスの ID。リクエストが mailbox と関連する場合のみ表示されます。

  • ua  — クライアントのアプリケーション名 (ユーザーエージェントのこと)

  • via — リクエストのプロキシチェインにあるIPアドレスとユーザーエージェントのリスト

  • soapId — 特定の SOAP リクエストによるプロキシホップを監視するための ID

  • msgid — 処理中のメッセージの Message-ID ヘッダー値

  • ds — 処理中のデータソース名

  • port — クライアントが接続されたサーバポート番号

  • oport — リクエストが送信された元ポート番号

  • oproto — リクエスト元のプロトコル。これはユーザーの代理で SOAP リクエストを送信する内部コンポーネントによって行える場合があります。(例:MTA)

以下の事例では、2017年10月25日の00:28にて、IP アドレス 222.173.186.17 を持つ POP3 クライアントが Zimbra Collaboration サーバへ接続し、リクエストが IP 10.1.1.136 を持つローカルプロキシサーバ経由で送信されたことを示しています:

Mailbox Log Entry for POP

以下の事例では、AquaMail のモバイルアプリを使用する user1@mydomain.comIMAP STATUS リクエストが失敗したことを示しています。ユーザー端末の IP アドレスは 72.83.144.255 (oip に記録しており) となっています。リクエストが Zimbra Collaboration nginx proxy から IMAP サーバへ送信され、プロキシの IP アドレスが 10.4.4.138ip および via に記録されている) となっています。

Mailbox Log Entry for IMAP

以下の事例では、LMTP サーバにメッセージ送信を示しています。このログメッセージの IP アドレスはローカルネットワークで実行している Zimbra Collaboration MTA のものとなります。

Mailbox Log Entry for LMTP

以下の事例では、test@mydomain.net のメールボックスからメッセージ ID 462 を削除している MailboxPurge スレッドの処理を示しています。このログメッセージは外部のリクエストではなく、内部プロセスで行うため、ログメッセージに ip, oip, port および via の値が含まれていません。

Mailbox Log Entry for Purge

ハンドラーエクセプションとスタックトレース

アクティビティの進行中にエラーが発生したとき、「handler exception(ハンドラーエクセプション)」がログレコードの最後に追加され、通常のフローを中断したプロセスの実行中に起きたイベントを、管理者に知らせます。何らかのエラーが検出されたというサインです。

Example 19. ハンドラーエクセプション
007-06-25 00:00:10,379 INFO [btpool0-1064] [name=nriers@example.com;mid=228;ip=10.2.3.4;ua=zimbra Desktop/0.38;] SoapEngine - handler exception

時折、スタックトレースが、エクセプションの通知後に表示される場合があります。スタックトレースは、Zimbraの mailboxd サービスにあるスレッドと監視の情報をレポートします。この情報がデバッグに役に立ちます。トレースには、エラーが発生した場所が表れるからです。たいていは、スタックの最後の数件のエントリが問題の原因を示します。 caused by descriptor がログの行に含まれているなら、これが根本原因です。エラーは「501 bad address syntax」のせいで発生しました。

Example 20. スタックトレース
com.example.cs.mailbox.MailServiceException: Invalid address: Jon R
at com.example.cs.mailbox.MailServiceException.internal_SEND_FAILURE (MailServiceException.java:412)
at com.example.cs.mailbox.MailServiceException.SEND_ABORTED_ADDRESS_FAILURE MailServiceException.java:416)
...
at org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:442)

Caused by: com.example.cs.mailbox.MailSender$SafeSendFailedException: 501 Bad address syntax; chained exception is: com.sun.mail.smtp.SMTPAddressFailedException: 501 Bad address syntax
at com.sun.mail.smtp.SMTPTransport.rcptTo(SMTPTransport.java:1196)
at com.sun.mail.smtp.SMTPTransport.sendMessage(SMTPTransport.java:584)
at javax.mail.Transport.send0(Transport.java:169)
at javax.mail.Transport.send(Transport.java:98)
at com.example.cs.mailbox.MailSender.sendMessage(MailSender.java:409)
at com.example.cs.mailbox.MailSender.sendMimeMessage(MailSender.java:262)
... 30 more
Mailbox ログファイル

mailbox.log ファイルは毎日ローテーションされます。Mailboxのログファイルは /opt/zimbra/log に保存されます。これまでの mailbox.log ファイル名には、そのファイルの作成日が付加されます。日付のないログファイルが現在のログファイルです。これらログファイルは、バックアップや削除が可能です。

メールの問題をトラブルシューティングする

エラーのため、mailbox.log を確認するには、問題が起こっているメールアドレスやサービス名を検索します。また、WARNやERRORのログレベルを確認し、エラーメッセージの内容を確認します。エラーを探すときは、レコードを確認し、問題が記録される前に起こったイベントをトレースします。

システムのクラッシュ

システムクラッシュ時、スタートアップのメッセージを調べ、その後スタートアップメッセージ日付より前にあるエラーを探します。以下の例では2007年6月17日に発生したメモリ不足のエラーを示しています。

Example 21. スタートアップメッセージ
2007-06-25 01:56:18,725 INFO [main] [] soap - Servlet SoapServlet starting up

スタートアップメッセージの前にあるエラーを探します。

Example 22. エラーメッセージ
2007-06-17 20:11:34,194 FATAL [btpool0-3335] [name=samd@example.com;aname=abcadmin@example.com;mid=142;ip=10.3.4.5;ua=zimbraConnectorForBES/5.0.207;] system - handler exception java.lang.OutOfMemoryError: PermGen space
メール配信の問題

"LmtpServer" のサービスを調べます。以下の例では、スタックトレースのレポートに caused by として、受信者のアドレスが拒否されたことが説明されています。アドレスは正確でなければならないからです。

Example 23. メール送信エラー
2007-06-25 10:47:43,008 INFO [LmtpServer-250]
[name=bigen@example.com;mid=30;msgid=<1291804360.35481182793659172.JavaMail.root@example.com>;] lmtp - rejecting message bigen@example.com: exception occurred
com.zimbra.cs.mailbox.MailServiceException: redirect to too failed
at com.zimbra.cs.mailbox.MailServiceException.internal_SEND_FAILURE (MailServiceException.java:412)
at com.zimbra.cs.mailbox.MailServiceException.SEND_FAILURE(MailServiceException.java:424)
at com.zimbra.cs.filter.zimbraMailAdapter.executeActions(zimbraMailAdapter.java:286)
at org.apache.jsieve.SieveFactory.evaluate(SieveFactory.java:151)
at com.zimbra.cs.filter.RuleManager.applyRules(RuleManager.java:177)
at com.zimbra.cs.lmtpserver.zimbraLmtpBackend.deliverMessageToLocalMailboxes(zimbraLmtpBackend.java:325)
at com.zimbra.cs.lmtpserver.zimbraLmtpBackend.deliver(zimbraLmtpBackend.java:140)
at com.zimbra.cs.lmtpserver.LmtpHandler.doDATA(LmtpHandler.java:441)
at com.zimbra.cs.lmtpserver.LmtpHandler.processCommand(LmtpHandler.java:205)
at com.zimbra.cs.tcpserver.ProtocolHandler.processConnection(ProtocolHandler.java:231)
at com.zimbra.cs.tcpserver.ProtocolHandler.run(ProtocolHandler.java:198)
at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Thread.java:619)

Caused by:
com.zimbra.cs.mailbox.MailSender$SafeSendFailedException: 504 <too>: Recipient address rejected: need fully-qualified address ;
chained exception is: com.sun.mail.smtp.SMTPAddressFailedException: 504 <too>: Recipient address rejected: need fully-qualified address
at com.sun.mail.smtp.SMTPTransport.rcptTo(SMTPTransport.java:1196)
at com.sun.mail.smtp.SMTPTransport.sendMessage(SMTPTransport.java:584)
at javax.mail.Transport.send0(Transport.java:169)
at javax.mail.Transport.send(Transport.java:120)
at com.zimbra.cs.filter.zimbraMailAdapter.executeActions(zimbraMailAdapter.java:281)
... 10 more
アカウントエラー - ログインのエラー

mailbox.log は、IMAP、POP3、ZWC上で試行された成功ログイン・失敗ログインをすべて記録します。ログインエラーを探すなら、 "Auth" の検索から始めます。以下の例は、IPアドレス10.4.5.6から誰かが、Zimbraウェブクライアントに管理者としてログインを試みたこと、Windows OS上でFirefoxを使用したことが分かります。ログインは却下されました。そのアカウントが管理者アカウントではなかったためです。

Example 24. アカウントエラー - ログインのエラー
2007-06-25 09:16:11,483 INFO [btpool0-251] [ip=10.4.5.6;ua=zimbraWebClient - FFX.X (Win);] SoapEngine - handler exception
com.zimbra.common.service.ServiceException: permission denied: not an admin account
at com.zimbra.common.service.ServiceException.PERM_DENIED(ServiceException.java:205)
at com.zimbra.cs.service.admin.Auth.handle(Auth.java:103)
アカウントエラー - IMAP・POP関連

IMAPやPOPの問題のためにログを探しているなら、 "ImapServer/Pop3Server" を調べます。以下の例は、sires@example.comの接続試行しようとして起こった致命的なIMAPサーバーエラーを表しています。

Example 25. アカウントエラー - IMAPエラー
mailbox.log.2007-06-19:2007-06-19 15:33:56,832 FATAL [ImapServer-2444] [name=sires@example.com;ip=127.0.0.1;] system - Fatal error occurred while handling connection

メッセージのヘッダーを読む

各メッセージには、送信元からあて先までの、メールの道のりを表すヘッダーが含まれています。この情報は、メッセージに問題があるときにメッセージのルートをトレースするのに使用します。ZimbraのメッセージヘッダーはZimbraのウェブクライアントのメッセージ表示で閲覧できます。メッセージを右クリックして、 元のメッセージを表示 を選択します。

以下の内容がメッセージヘッダーに含まれています。

  • Date — メッセージが送信された日時です。時間を指定するとき、メッセージ検索対象の開始と終了を入力して期間を指定できます。

  • From — 送信者の名前とメールアドレス。

  • To — 受信者の名前とメールアドレス。プライマリ受信者を示します。

  • Message-ID — メールのルートのトレースに使用する一意の番号。

  • In-Reply-To — 返信で返されるメッセージのメッセージIDです。関連メッセージのリンクに使用されます。

  • Received: from — メッセージを送信したホスト名とIPアドレス。MTAからLMTPへのReceived: from情報と、ローカルホストからのReceived: from情報が表示されます。

破損したメールボックスのインデックスを修正する

メールメッセージと添付ファイルは、メールボックスへ追加される前に自動的にインデックス化されます。各メールボックスには紐づくインデックスファイルがあります。このインデックスファイルは、メールボックスからの検索結果を取得するのに必要です。

メールボックスのインデックスファイルが破損した場合や誤って削除された場合、管理コンソールからメッセージを再インデックスすることが可能です。

インデックス破損時、アカウント上でテキスト検索が失敗してもエラーにならないことがあります。インデックス破損の判別をするのにテキスト検索失敗のレポートは、あてにできません。破損インデックスについて、メッセージのインデックスのログを監視する必要があります。サーバーが破損インデックスを検知すると、メッセージが、WARNのログレベルでZimbraのmailbox.logにログ出力されます。ログメッセージは Possibly corrupt index で始まります。このメッセージが表示されたら、管理者が問題を修正する必要があります。問題の修正とは、メールボックスの再インデックスである場合が多いです。

メールボックスの内容の再インデックスに必要な時間は、メールボックス内のメッセージ数によります。再インデックスが実行中もユーザーはメールボックスにアクセスできますが、インデックスされていないメッセージは検索結果に返せないため、検索結果が不完全である可能性があります。

インデックスが破損しているかどうか確認する

特定のメールボックスのインデックスに対するサニティーチェックには、コマンド zmprov verifyIndex を実行します。

zmprov verifyIndex <user@example.com>

問題が検知されると、失敗ステータスが返されるので、インデックスに対する修復を行ないます。

破損されたインデックスを修正・再インデックスする

コマンド reIndexMailbox を使用して、インデックスの修正と再インデックスをします。

zmprov reIndexMailbox <user@example.com> start

started のステータスが返されます。

SNMPの監視と設定

SNMPの監視ツール

サーバー監視用ソフトウェアを実装して、システムログ、CPUとディスク使用容量、その他ランタイム情報を監視したいことがあるかもしれません。

Zimbra Collaboration はSNMPトラップの作成のために、swatchを使用してsyslogの出力を監視します。

SNMPの設定

Zimbra Collaboration には、SNMP監視のインストールパッケージが含まれています。このパッケージは、Zimbra Collaboration設定の部分をなす、各サーバー(Zimbra Collaboration、OpenLDAP、Postfix)で実行する必要があります。

トラップの送信先とするべき宛先ホストは、SNMP設定だけです。

SNMPトラップを作成するエラー

サービスの停止あるいは起動時、 Zimbra Collaboration エラーメッセージがSNMPのトラップを作成します。サードバーティ製のSNMP監視ソフトウェアを使用してそのメッセージを取得し、選択したメッセージをpagerや他の警告システムに転送することができます。

MariaDBを確認する

MariaDBのデータベース健康の検証するためのチェックが毎週、自動で行なわれます。このチェックに約1時間かかります。エラーが見つかると、管理者のアカウントにレポートが送信されます。MariaDBのチェックを実行するレポート名は zmbintegrityreport で、Crontabは週に一度このレポートを実行するように自動設定されます。

MariaDBデータベースのチェック時、このレポートの実行でI/Oを膨大に消費する可能性があります。通常の場合は問題になりませんが、運用に影響が出るようであれば、zmbintegrityreportの実行頻度を変更できます。詳細は ZCS Contrab Jobsを参照してください。

Zimbra Collaborationのソフトウェア更新を確認する

Zimbra Collaborationをインストールすると、Zimbra Collaborationのソフトウェア更新機能は、日に1度最新のZimbra Collaborationバージョンを確認するように自動設定されます。更新があると、管理コンソールの サーバー更新 に設定されているメールアドレスに通知メッセージが送信されます。

Zimbra Collaborationが更新を確認した日時は 更新 のタブに保存され、管理者がZimbra Collaborationバージョンを更新するまでメール通知が継続的に発送されます。更新のメール通知を受信したくない場合、 更新の入手が可能になったときに通知メールを送信 のオプションを無効にします。

以下の内容も設定可能です。

  • 更新をチェックするサーバー — 利用できるサーバーのリストが表示されますが、サーバーは一つだけ設定できます。選択されたサーバーは更新を確認し、www.zimbra.comからの更新レスポンスはLDAPに保存されます。

  • 更新をチェックする間隔 — デフォルトは日に1度です。頻度の間隔は時間、分、秒単位で変更できます。バージョン更新の確認タスクはcron jobに設定されます。頻度の間隔が2時間未満の場合、crontabファイルを直接、修正する必要があります。

  • 更新URL — バージョン更新を確認するためにサーバーが接続するURLのアドレスです。Zimbra Collaborationサーバーがアップデートを確認する場合、バージョン、プラットフォーム、ビルド番号をZimbraへ送信します。通常このURLは変更されません。

  • 更新の通知を受ける場合、更新の入手が可能になったときに通知メールを送信 のオプションを有効にし、送信先と送信元のアドレスを入力します。デフォルトのアドレスは管理者のアドレスです。

  • 汎用的なメールが作成されます。メールの件名と内容は変更できます。

  • サーバーが指定されたURLをポーリングすると、その応答が表示されます。

Outlook用Zimbraコネクタを更新する

Outlook用Zimbraコネクタ(ZCO)のmsiファイルは、管理コンソールにあるZimbraユーティリティのダウンロードページから入手できます。ZCS バージョンが新しくなる前にZCOの新バージョンがリリースされると、管理コンソールから新しいほうのZCOのmsiファイルをZCSサーバーにアップロードできます。アップロードしたファイルは /opt/zimbra/jetty/webapps/zimbra/downloads にアップロードされます。

管理コンソール:

ホーム > ツール、移行 > クライアントのアップロード

  1. アクセス可能なコンピュータに、管理コンソールの クライアントのアップロード ページから新しいZCOのファイルをダウンロードします。

  2. 参照 のボタンをクリックし、アップロードするZCOファイルを選択します。

  3. ZCSを再起動します。

    zmcontrol restart

    または下記を実行します。

    /opt/zimbra/libexec/zmupdatedownload

downloads/index.html のファイルは、最新のZCOクライアントバージョンで更新されます。この新しいファイルは管理コンソールの ホーム > ツール、移行 > ダウンロード のページからダウンロードできます。

サーバーを再起動しないと、ZimbraユーティリティのダウンロードページにあるZCOのダウンロードリンクは、新しいダウンロード対象バージョンを選択しません。

Zimbra Collaboration より送信される通知や警告

サービスステータス変更の通知

サービスの停止あるいは再開時、この通知が送信されます。

サーバー開始の通知メッセージ
件名: Service <サービス名> started on <Zimbraホスト名>

本文: Service status change: <Zimbraホスト名> <サービス名> changed from stopped to running
サーバー停止の通知メッセージ
件名: Service <サービス名> stopped on <Zimbraホスト名>

本文: Service status change: <Zimbraホスト名> <サービス名> changed from running to stopped
ディスク利用状況の通知

ディスク空き容量が少なくなった場合、管理者のアカウントに警告が通知されます。デフォルトでは、ディスクの使用容量が85%に達した場合、注意の警告が送信され、ディスクの使用容量が95%に達した場合、重大な警告が送信されます。

件名: Disk <ボリューム名> at ##% on <Zimbraホスト名>

本文: Disk warning: <Zimbraホスト名> <ボリューム名> on device <デバイス名> at ##%

mysqldが重複のプロセスに実行している際の通知

データベースの破損の原因になりそうなケースを検出するmysqldのプロセスが実行中かどうかを確認するスクリプトが実行されます。1つ以上のmysqldプロセスが実行中だとわかると、メールが作成されます。

件名: ZCS: Duplicate mysqld processes detected!

本文: PID:$pid PPID:$ppid PGRP:$pgrp

CMD: $cmdline

More then $maxcnt mysqld processes are running Parent processes
include: $procs This should be investigated immediately as it may lead to
database corruption

SSL証明書期限切れの通知

毎月初日にリポートが実行され、来たる30日以内に有効期限が満了する証明書を警告します。

件名: ZCS: SSL Certificates approaching expiration!

本文: The Administration Console and CLI Certificate Tools guide provides
instructions on how to replace you self-signed or commercial certificate.

https://wiki.zimbra.com/index.php?title=Administration_Console_and_CLI_Certificate_Tools SSL Certificate expiration checked with $0 on <Zimbraホスト名>.

Daily report (日報)の通知

loggerパッケージがインストールされると、日次のメールレポートがcrontabに自動スケジュールされます。このレポートは毎日管理者のメールボックスに送信されます。

件名: Daily mail report for <日>

<日次のレポートデータ>

データベースの統合性チェック通知

crontabに自動スケジュールされるzmdbintegityreportを週次ベースで実行することで、MariaDBデータベースをチェックします。レポートは自動的に管理者のメールボックスに送信されます。

件名: Database Integrity check report for <Zimbraホスト名>

本文: Generating report can't run $cmd: $!

Database errors found.

$cmd --password=XXXXXXXX

<cmd output>

No errors found

command failed $!

バックアップの完了通知

実行するバックアップタイプの設定時、そのバックアップセッション結果の通知メッセージの受信もセットアップできます。

件名: ZCS BackupReport:SUCCESS

本文: Server: <サーバー名>

Type: incremental

Status: completed

Started: Fri, 2012/07/13 01:00:05.488 PDT

Ended: Fri, 2012/07/13 01:10:09.842 PDT

Redo log sequence range: 2 ..  2

Number of accounts: 500

バックアップと復元 (*)

*Zimbra 8.8 より、本機能は2つの異なるバージョンを提供しています。

Zimbra 8.8 ではスタンダード版と新世代(NG)版を提供しています。Zimbra 8.7 またはそれ以前のバージョンでは、スタンダード版のみを提供しています。以下にスタンダード版の詳細を記載しています。Zimbra 8.8 で本機能の NG版を利用する方法につきましては、本ガイドの NG版専用チャプターをご参照ください。

スタンダード版のバックアップ(クラシックバックアップ)のサポートが終了しており、Zimbra 8.8.12 以降のリリースから削除する予定です。 新しいネットワーク版の NG モジュール、または ZSP へ移管していない環境はお早めに移管いただくよう、推奨しております。

Zimbra Collaboration には、各 Zimbra Collaboration サーバーに設定可能なバックアップマネージャーが備わっており、バックアップと復元の両方を実施できます。バックアップ処理の実行のために Zimbra Collaboration サーバーを停止する必要はありません。

本章では、データのバックアップと復元方法、そして、 Zimbra Collaboration メールボックスサーバーのバックアップと復元のために使用するCLIツールについて説明します。加え、障害復旧に関する情報と一般ガイドも記載します。

メールボックスサーバーのバックアップ

Zimbra Collaboration には、各 Zimbra Collaboration サーバーに設定可能なバックアップマネージャーが備わっており、バックアップと復元の両方を実施できます。バックアップ処理の実行のために Zimbra Collaboration サーバーを停止する必要はありません。シングルユーザーのメールボックス破損時、バックアップマネージャーを使用すれば、全システムの復元を行なわずにそのユーザーのみ復元することができます。完全・増分バックアップは /opt/zimbra/backup に保存されます。

Redoログ

各Zimbraメールボックスサーバーは、redoログを作成します。このログに、最終増分バックアップ時以降メッセージストアサーバーで処理された現在およびアーカイブのトランザクションを格納します。

サーバー復元時、バックアップファイルが完全に復元されてから、すべてのアーカイブにあるredoログと現在のRedoログが再実行されて、システムの不具合が発生する直前まで戻されます。

使用中のredoログファイルが100MBに達すると、そのRedoログはアーカイブディレクトリに移ります。そしてサーバーは新しいredoログを使用し始めます。前回のredoログのコミットされなかったトランザクションはすべて維持されています。クラッシュ時、サーバーを再起動すると、現在のRedoログ が読み込みこまれ、コミットされなかったトランザクションが再適用されます。

増分バックアップ実行時、redoログはアーカイブからバックアップディレクトリに移されます。

バックアップ方法

バックアップ方法には2種類あります。

  • 標準バックアップ は、平日以外に完全バックアップを実行するエンタープライズ企業の環境に適しています。

  • オートグループバックアップ は、一度の全アカウントの完全バックアップ完了までの時間が非常にかかるような大規模な Zimbra Collaboration 環境の場合に推奨します。

標準バックアップ

標準バックアップ方法は、完全バックアップを毎週、増分バックアップを毎日実行します。完全バックアップ処理は、メールボックスの復元に必要な全情報をバックアップします。これには、LDAPディレクトリサーバー情報、データベース、インデックスディレクトリ、各メールボックスのメッセージディレクトリも含まれます。

共有メッセージのバックアップ時、すでにバックアップ内にそのメッセージ用ファイルが存在する場合、そのことがこのアイテムにフラグ付けされるため再度内容がコピーされることはありません。

増分バックアップは、前回の増分バックアップ以降更新されたLDAPデータをバックアップし、全Redoログを収集します。あるメールボックスに完全バックアップがないと分かると増分バックアップ処理がそのメールボックスの完全バックアップを行ないます。

増分バックアップは、Redoログをバックアップのディレクトリに移します。Redoログとは、実行されたアクションごとの記録です。これには、配信された全メッセージの完全コピーや、タグ、連絡先、スレッドなどのメタデータの完全コピーが入ります。

これらのバックアップファイルを使用して、メールボックスサーバーを丸ごと復元、あるいはメールボックスを個別に復元してアカウントとメッセージデータを完全に復元することができます。

LDAPディレクトリは、完全バックアップや増分バックアップの処理の一環としてバックアップされます。アカウント、ドメイン、サーバー、提供サービス、その他のデータなどすべてがバックアップされます。

各メールボックスサーバーは、処理した全トランザクションが記録されるRedoログを作成します。予期せぬシャットダウンが発生すると、以下のようにRedoログを使用します。

  • コミットされないままのトランザクションを確実に残さないように、スタートアップで最新のRedoログを読み込み、コミットされなかったトランザクションを全て再実行し完了させます。

  • サーバー不具合時、直近の完全バックアップ後の書き込みデータを復旧します。

サーバー復元時、バックアップファイルが完全に復元されてから、すべてのアーカイブにあるredoログと現在のRedoログが再実行されて、システムの不具合が発生する直前まで戻されます。

Zimbra MTAのデータはサーバーに短時間しか残らないため、バックアップされません。

また、mailboxdの jetty/etc/*.xml などのカスタム設定もバックアップされません。

バックアップ通知

完全・増分バックアップの実行時、バックアップレポートが管理者アカウントに送信されます。レポートには、バックアップの成功・失敗、バックアップの開始時間・終了時間、バックアップしたアカウント数、Redoログのシーケンス範囲が記されます。

バックアップが失敗すると、エラー情報も追記されます。

オートグループバックアップ

オートグループバックアップ方法は、異なるメールボックスグループの完全バックアップをスケジューリングして個々にバックアップします。オートグループ方法は、全アカウントのバックアップが完了するまでに時間のかかる大規模な Zimbra Collaboration 環境を対象にして設計しています。オートグループバックアップは、完全・増分バックアップを機能的に組み合わせているため、増分バックアップの実行は不要です。各オートグループのセッションが該当のメールボックスグループに完全バックアップを行ないます。オートグループバックアップはCLIでスケジュールして自動実行されるため、マニュアル操作でのオートグループバックアップ実行は推奨しません。

バックアップファイルのディレクトリ構成

バックアップ先は、バックアップターゲットとして知られます。バックアップシステムの場合、メールサーバーのファイルシステムにあるパスがこれにあたります。Zimbraのデフォルトのバックアップディレクトリは /opt/zimbra/backup です。

標準バックアッププロセスで作成されるバックアップのディレクトリ構成の詳細は 標準バックアップのディレクトリ構成に記載されています。同一のターゲットエリアに定期的にスケジュールしたバックアップ先を設定・実行しても、以前のバックアップセッションは上書きされません。

ファイル accounts.xml に全バックアップの組み合わせで全アカウントがリストアップされています。アカウントごとにアカウントID、メールアドレス、そのアカウントの直近の完全バックアップ用ラベルがあります。バックアップのセッションを他の場所へ保存する場合、最新のaccounts.xmlもそこに保存する必要があります。アカウントの復元中、accounts.xmlを使用して、そのアカウントの直近の完全バックアップを参照します。accounts.xmlがないなら、復元する元となるバックアップのラベルを指定する必要があります。

Redoログのディレクトリは /opt/zimbra/redolog/redo.log です。現在のRedoログのファイルサイズが100MBに達すると、その現在のログファイルはアーカイブディレクトリ /opt/zimbra/redolog/archive に移ります。そしてサーバーは新しいredoログを使用し始めます。前回のredoログのコミットされなかったトランザクションはすべて維持されます。クラッシュ時、サーバーを再起動すると、現在のRedoログ が読み込みこまれ、コミットされなかったトランザクションが再適用されます。

Redoの操作は短時間で行なう必要があるため、コピー・削除ではなくディレクトリ移動が実施されます。ソースとターゲットのパスが同じファイルシステムのボリュームに存在するときのみ、ディレクトリを移動できます。つまり、RedoログとRedoログのアーカイブは同じファイルシステムのボリュームになければなりません。アーカイブファイルはRedoログのファイルシステムのサブディレクトリだからです。

増分とオートグループの全バックアップセッションはRedoログと同一のディレクトリに保存します。全Redoログが同一バックアップターゲットで見つかる必要があります。通常の完全バックアップセッションは、別のターゲットディレクトリを使用できます。

Table 55. 基準バックアップのディレクトリ構成

/opt/zimbra/backup

バックアップのデフォルトルートディレクトリです。

accounts.xml/

すべてのアカウント、そのアカウントのメールアドレスファイル・Zimbra ID・直近の完全バックアップラベルがリストアップされています。accounts.xmlは、メールアドレス、そのメールアドレスと現在のZimbra IDとのマッピング、各アカウントの直近のバックアップ情報を管理しています。

sessions/

バックアップセッションのルートディレクトリ。

full-<timestamp>/

完全バックアップのディレクトリ。セッションのタイムスタンプは、ミリ秒を含めたバックアップの開始時間 (GMT) 。サマータイムに対応するためにローカル時間ではなくGMTを使用しています。

session.xml

完全・増分バックアップセッションのバックアップラベルについてのメタデータ、例えば開始時間、完了時間等。

shared_blobs/

バックアップデータ内のアカウント間で共有しているメッセージファイルが入ります。

sys/

グローバルのデータベーステーブルとlocalconfig。

db_schema.xml

グローバルテーブルのデータベーススキーマ情報。各テーブルのダンプファイルは.csv形式のフォーマットです。

localconfig.xml

バックアップ時の /opt/zimbra/conf/localconfig.xml コピー。

<table name>.dat

データベーステーブルのデータダンプ。

LDAP/ldap.bak

LDAPのダンプ。

accounts/

各アカウントのデータはこのサブディレクトリに保存されます。

<…​/zimbraId>/

各アカウントのルートディレクトリ。

meta.xml

アカウントのバックアップに関するメタデータ。

ldap.xml

アカウントのLDAP情報、エイリアス、アイデンティティ、データソース、配布リストなどを含みます。

ldap_latest.xml

このファイルが存在する場合、直近の増分バックアップのldap.xmlへリンクします。

db/

アカウント固有のデータベースのテーブルダンプ。

db_schema.xml

このアカウントのテーブル用のデータベーススキーマ情報。

<table name>.dat

データベーステーブルのデータダンプ。

blobs/

ブロブファイルが入ります。

index/

Luceneのインデックスファイルが入ります。

incr-<timestamp>

増分バックアップのディレクトリ。完全バックアップディレクトリのスキーマと類似していて、これらのメタファイルが含まれます。

session.xml

sys/db_schema.xml

accounts/…​/<zimbraID>/ldap.xml

incr-<timestamp>accounts/…​/<zimbraId>/db/db_schema.xml は入りません。 増分バックアップの場合、アカウントのテーブルをダンプしないからです。

オートグループバックアップの場合、ディレクトリ構成により、完全バックアップセッションへのRedoログファイルが保存されます。増分バックアップのセッションはありません。

管理コンソールでのバックアップと復元

管理コンソールから直接実行できるバックアップと復元の操作が多数あります。左側のナビゲーションペインから 監視 > バックアップ を選択すると全サーバーがリストアップされます。

管理コンソールでバックアップを設定する

バックアップは、管理コンソールからグローバル設定は特定のサーバーの設定として、設定できます。サーバー設定はグローバル設定にオーバーライドします。

グローバル設定の場合、バックアップ結果を受信するメールアドレスが設定できます。デフォルトではその管理者のアカウントに通知を送信します。

オートグループの場合、バックアップの分割グループの数を設定します。

標準バックアップがデフォルトで、自動スケジュールされます。他の変更を付け足す必要はありませんが、オートグループバックアップの実行時はマニュアル操作でのバックアップスケジュール設定が必要です。これにはCLIにアクセスし、 オートグループバックアップをスケジュールする にある手順に従って zmschedulebackup -D を実行し、オートグループバックアップのデフォルトスケジュールを設定します。

オートグループバックアップのスロットルオプション : オートグループバックアップ方法は、一度もバックアップが実行されていないメールボックスを次回予定されたバックアップで自動バックアップします。これは、大規模メールボックス移行・メジャーアップグレードの直後など、全メールボックスの完全バックアップが必要なときは最善ではありません。Throttle automatic backups を有効にすると日次バックアップでのメールボックス数がT/Nに制限されます。N日以内に全メールボックスをバックアップするという制約は守れない一方で、オフ時間帯にバックアップを完了できます。

一度でも全メールボックスがバックアップされたら、スロットルを無効化します。

zmprov mcf zimbraBackupAutoGroupedThrottled TRUE

CLIからのバックアップと復元

Zimbraのバックアップと復元プロセスはCLIコマンドから実行できます。

以下のユティリティを使用して、バックアップのスケジュール作成、完全・増分バックアップ実行、メールサーバーの復元、またはLDAPの復元ができます。

  • zmschedulebackup — このコマンドで完全・増分バックアップのスケジュールや、古いバックアップファイルの削除ができます。

  • zmbackup — このコマンドでZimbra Collaboration メールボックスサーバーの完全・増分バックアップを実行します。このコマンドは、ライブのサーバー上でmailboxdプロセスやメールボックスサーバーの起動中に実行します。このコマンドは、不要となった古いバックアップをマニュアルで削除できるオプションがあります。

  • zmbackupabort —  実行中の完全バックアップを強制的に停止するコマンド。

  • zmbackupabort -r — 実行中の復元を強制的に停止するコマンド。

  • zmbackupquery — 実行中や完了しているバックアップ情報を、ラベルや実行日時を含めて返します。

  • zmrestore — Zimbra Collaboration メールサーバーの完全・増分の復元を実行します。

  • zmrestoreoffline — mailboxdのプロセスが停止している状態で Zimbra Collaboration メールサーバーを復元します。

  • zmrestoreldap — アカウント、ドメイン、サーバー、提供サービスなどのデータを含む、LDAPのディレクトリサーバーを完全に復元します。

こうしたコマンドごとの使用方法や詳細はZimbra CLIコマンド コマンドラインのユティリティ を参照してください。

標準の方法でバックアップする

バックアップ開始時、バックアップするサーバー上でコマンドを実行することも、ターゲットサーバーを指定しリモートから実行することも、または管理コンソールでバックアップを実行することもできます。

標準バックアップをスケジュールする

Zimbra Collaboration がインストールされたときに自動で、完全・増分バックアップの標準の方法でのバックアップスケジュールがCrontabに追加されています。デフォルトスケジュールは、完全バックアップが毎週土曜の午前1時に実行されます。増分バックアップは日曜から金曜の午前1時に実行されます。

デフォルトで、1か月より前のバックアップが深夜0時に削除されます。

バックアップスケジュールを zmschedulebackup コマンドを使用して変更できます。

下記のとおり項目を指定します。項目はスペースで区切ります。

  • 分 — 0 から 59

  • 時間 — 0 から 23

  • 月の日 — 1 から 31

  • 月 — 1 から 12

  • 曜日 — 0 から 7 (または英語名。0と7は日曜日を意味します。)

使用しない値には、アスタリスクを入力します。

Example 26. zmschedulebackup オプションの例
  • 既存の完全・増分バックアップ、バックアップの削除スケジュールをすべて変更します。 -R を使用すると、バックアップのスケジュールがすべて変更されます。スケジューリングするバックアップのセッションを自動削除したいなら、このコマンドの使用時にその削除スケジュールも忘れずにセットしてください。以下は、既存のスケジュールを次のように変更する例です。
    日曜午前1時に完全バックアップを実行、月曜から土曜の午前1時に増分バックアップを実行、毎日正午に古いバックアップを削除。

    zmschedulebackup -R f "0 1 * * 7" i "0 1 * * 1-6" d 1m "0 0 * * *"
  • 現在のスケジュールに完全バックアップを追加します。以下は、木曜の朝1時の完全バックアップを追加する例です。

    zmschedulebackup -A f "0 1 * * 4"
  • バックアップスケジュールを確認します。スケジュールが返されます。

    zmschedulebackup -q
  • スケジュールのコマンドをテキストファイルに保存します。再インストールやアップグレード後、同じスケジュールを簡単に再作成できます。

    zmschedulebackup -s
デフォルトスケジュールに戻すには、以下のコマンドを実行します。 zmschedulebackup -D
デフォルトの標準バックアップのスケジュール

デフォルトのバックアップスケジュールが以下のように表示されます。

Example 27. デフォルトのバックアップスケジュール
0 1 * * 6 /opt/zimbra/bin/zmbackup -f - all
0 1* * 0-5 /opt/zimbra/bin/zmbackup -i
0 0 * * * /opt/zimbra/bin/zmbackup -del 1m

読みかた

完全バックアップを毎週土曜の午前1時に実行します。
0 1 * * * 6 /opt/zimbra/bin/zmbackup -f - all
増分バックアップを日曜から金曜の午前1時に実行します。
0 1* * 0-5 /opt/zimbra/bin/zmbackup -i
作成から1ヶ月経過したバックアップセッションを深夜に自動削除します。
0 0 * * * /opt/zimbra/bin/zmbackup -del 1m
crontableの読みかた

各crontabエントリには、下記6項目がこの順番で入ります。

項目

1

2

3

4

5

6

0

1

*

*

6

/opt/zimbra/bin/zmbackup -f -all

  1. 分 (0-59)

  2. 時間 (0-23)

  3. 月の日 (1-31)

  4. 月 (1-12 または英語名)

  5. 曜日 (0-7 または英語名。0と7は日曜日を意味します。)

  6. 実行する文字列

アスタリスクはワイルドカードとして機能し、項目の全ての候補値に該当します。
管理コンソール:

ホーム > 設定 > グローバル設定 > バックアップ/復元

管理コンソールから、メール通知の受信者の追加や受信者のアドレス変更ができます。

完全バックアップのプロセス

完全バックアップのプロセスは以下の順でメールボックス、データベース、インデックス、LDAPディレクトリをバックアップします。

  1. システムテーブルや localconfig.xml のファイルを含む、グローバルなシステムデータをバックアップします。

  2. バックアップターゲットとなるアカウントごとに、そのLDAPエントリのバックアップを繰り返します。

  3. アカウントのメールボックスをメンテナンスモードへ設定し、一時的にメール配信とユーザーからのアクセスを停止します。

  4. メールボックスをバックアップします。

    1. そのメールボックスの関わる全データのMariaDBダンプを作成します。

    2. そのメールボックスのメッセージディレクトリをバックアップします。

    3. そのメールボックスのインデックスディレクトリをバックアップします。

  5. アカウントのメールボックスをアクティブモードへ戻し、次のアカウントに進みます。

  6. LDAPディレクトリをバックアップします。

完全バックアップは通常、非同期で実行されます。完全バックアップの開始時、実行中のバックアップのプロセスラベルが直ちに表示されます。バックアップはバックグラウンドで継続します。バックアップの実行ステータスは、 zmbackupquery のコマンドでいつでも確認できます。

バックアップファイルは圧縮なしのzipファイルとして保存されます。デフォルトのZipオプションの変更は コマンドラインのユティリティ のzmbackupを参照してください。

増分バックアップのプロセス

増分バックアップはCLIコマンドの zmbackup で実行します。増分バックアップのプロセスを以下に説明します。

  1. システムテーブルや localconfig.xml のファイルを含む、グローバルなシステムデータをバックアップします。

  2. バックアップターゲットとなるアカウントごとに、そのLDAPエントリのバックアップを繰り返します。

  3. 直近のバックアップ以降に作成されたアーカイブRedoログをディレクトリ <バックアップターゲット>/redologs に移します。

    増分バックアップ実行で1時間未満のアーカイブログはバックアップへコピーされ、削除されません。こうしたRedologは、バックアップ後1時間経過したら削除されます。この間隔はlocalconfigキー backup_archived_redolog_keep_time で指定します。デフォルトは3600秒です。

    アカウントに完全バックアップがないとき、バックアッププロセスは増分バックアップの実行が指定されていてもこのアカウントの完全バックアップを行ないます。

  4. LDAPディレクトリをバックアップします。

マニュアル操作でバックアップを実行する

コマンドzmbackupを使用して、次のバックアップ操作を実行します。

  • server1 の全メールボックスをマニュアルでバックアップします。

zmbackup -f -s server1.domain.com -a all
  • 直近の完全バックアップ以降の server1 の全メールボックスをマニュアルで増分バックアップします。

zmbackup -i -s server1.domain.com -a all
  • server1user1 のメールボックスのみマニュアルで完全バックアップします。

zmbackup -f -s server1.domain.com -a user1@domain.com
バックアップのセッションを削除する

バックアップセッションは、ラベルまたは日時によって削除できます。

  • ラベルによる削除は、指定したセッションとそれ以前のセッションをすべて削除します。

  • 日時による削除は、指定した日時より前のバックアップセッションをすべて削除します。

例えば zmbackup -del 7d は今日より7日以前のバックアップをすべて削除します。日(d)、月(m)、または年(y)を指定できます。

特定のバックアップを検索する

個々の完全・増分バックアップがバックアップセッションです。

各バックアップセッションは日時でラベル付けされます。例えば、full20070712.155951.123のラベルは、このバックアップが2007年7月12日の3:59:51.123に作成されたことを表します。

セッションのラベルにはローカル時間ではなくGMTの時間を使用しています。サマータイムを導入している環境でのバックアップ実行時間を正常にするためです。

zmbackupquery コマンドで完全バックアップセッションを検索できます。

  • 特定の完全バックアップセッションを確認します。

zmbackupquery -lb full-20070712.155951.123
  • 指定日以降の完全バックアップセッションを確認します。

zmbackupquery --type full --from "2007/01/01 12:45:45"
  • バックアップディレクトリにあるすべての完全バックアップセッションを確認します。

zmbackupquery --type full
  • 特定の時間の範囲でアカウント復元に適した時を確認します。

zmbackupquery -a user1@example.com --type full --from "2007/07/05 12:01:15" --to "2007/07/12 17:01:45"
バックアップ中にサーバークラッシュ (アボートではない)が原因でバックアップのセッションが遮断されると、中断されたバックアップセッションが一時セッションとして保存されます。一時セッションは <バックアップターゲット>/sessions_tmp のディレクトリに保存されます。rmコマンドを使用し、ディレクトリを削除できます。

完全バックアップを実行中に停止する

  1. バックアップをアボートするためにはバックアップのセッションラベルが必要です。 zmbackup を最初に起動した際にラベルが表示されます。完全バックアップのラベルが不明な場合、 zmbackupquery を使用してラベルを確認します。

  2. 実行中のバックアップを zmbackupabort のCLIコマンドで強制的に終了することができます。バックアップは直ちに停止し、部分的に成功したバックアップとなります。

    • ラベル名を把握している場合、バックアップを停止します。

zmbackupabort -lb full-20070712.155951.123 -s server1
  • ラベル名が不明の場合、バックアップを停止します。

zmbackupquery
zmbackupabort -s server1 -lb full-20070712.155951.123

オートグループ方法でバックアップする

オートグループバックアップ方法は、管理コンソールまたはCLIから設定します。

管理コンソール:

ホーム > 設定 > グローバル設定 > バックアップ/復元 または
ホーム > 設定 > サーバー → サーバー名 → バックアップ/復元

CLIからオートグループバックアップを設定する

特定のサーバーにだけオートグループ方法を使用したくない場合、グローバル設定でバックアップ方法を設定してから、この設定をオーバーライドするサーバー設定で個別に設定します。

オートグループバックアップを設定するにはzmprovを使用し、LDAPの属性を編集します。

zmprov mcf <ldap_attribute> <引数>

zmprov ms を使用して、サーバーレベルで属性を設定できます。

以下のLDAP属性を編集します。

  • zimbraBackupMode —  Auto-Grouped に設定します。デフォルトはStandardです。

  • zimbraBackupAutoGroupedInterval — グループにバックアップセッションを実行する日数または週数を指定します。デフォルトは1日 (1d) です。バックアップ期間は1日以上です。xd (例えば、1d、など) やxw (例えば、1w、など) で入力できます。

  • zimbraBackupAutoGroupedNumGroups — メールボックス全体をグループ分割するグループ数です。デフォルトは7グループです。

オートグループバックアップをスケジュールする

オートグループバックアップスケジュールを設定する必要があります。

zimbraBackupAutoGroupedInterval の設定をベースとした、オートグループバックアップ用のデフォルトスケジュールを設定するには、 zmschedulebackup -D を実行します。

各インターバルで1つのグループがバックアップされます。オートグループバックアップは、サーバーのメールボックス数の変更に合わせて調整します。各バックアップセッションが以下をバックアップします。

  • 一度もバックアップされたことのないメールボックスをすべてバックアップします。新たにプロビジョンされた メールボックスがこれに該当します。

  • スケジュールされたバックアップ期間内にバックアップされなかったメールボックスをすべてバックアップします。例えば、6日後にバックアップするようにスケジュールされていれば、過去5日以内のバックアップされていないメールボックスがバックアップされます。

  • メールボックスが比較的多いとき古いものから順にバックアップします。日次オートグループバックアップの負荷分散のためです。

    例えば、オートグループの期間を日次 (1d) 、グループ数を7に設定すると、初回オートグループバックアップの実行で、全アカウントがバックアップされます。初回バックアップの後、オートグループが再度次の日に実行されます。今回は、新たにプロビジョンされたアカウントと、全アカウントの1/7相当のアカウントがバックアップされます。バックアップ日付が最古のアカウントからバックアップされます。このバックアップは、新たにプロビジョンされたアカウントと、バックアップ中の全アカウントの1/7相当のアカウントが7日間かけてバックアップされます。

共有メッセージのバックアップ時、すでにバックアップ内にそのメッセージ用ファイルが存在する場合、そのことがこのアイテムにフラグ付けされるため再度内容がコピーされることはありません。

バックアップファイルは圧縮なしのzipファイルとして保存されます。デフォルトのZipオプションの変更は コマンドラインのユティリティ のzmbackupを参照してください。

これらのバックアップファイルを使用して Zimbra Collaboration システム全体、または個々のメールボックスのみを復元し、アカウントとメッセージデータの完全な復元ができます。アーカイブRedoログは完全バックアップの一部としてバックアップのセッションに移されます。サーバーがオートグループバックアップから復元されているなら、Redoログが再実行されて、システムの不具合が発生する直前まで戻されます。

バックアップのオプション

バックアッププロセスの設定で、バックアップ内容の選択やMariaDBデータベースのバックアップが可能です。

バックアップに含まれる内容のオプション

以下のバックアップオプションで、完全バックアップのセッション中に検索のインデックス、ブロブ、HSMブロブをバックアップしないように設定できます。

  • zimbraBackupSkipSearchIndex — デフォルトは FALSE です。TRUE のとき、検索インデックスはバックアップされません。検索インデックスのないバックアップからのメールボックス復元後は、メールボックスを再インデックスする必要があります。

  • zimbraBackupSkipBlobs — デフォルトは FALSE です。 TRUE のとき、ブロブはバックアップされません。ブロブがフォールトトレランス対応のストレージにあるときにデータベースデータだけを早急にバックアップするのに役立ちます。この設定は、プライマリーとセカンダリ (HSM) ボリュームにある全ブロブに適用します。

  • zimbraBackupSkipHsmBlobs — デフォルトは FALSE です。 TRUE のとき、HSMボリュームにあるブロブはバックアップされません。 zimbraBackupSkipBlobsFALSE で、HSMボリュームにあるブロブをスキップしたい場合は、これを有効にします。

MariaDBデータベースをバックアップする

Zimbra Collaboration のバックアップ設定で、mysqldumpを実行してバックアップのセッション中にMariaDBデータベースをバックアップできます。これが有効なとき、完全バックアップ、増分バックアップ、オートグループバックアップごとにmysqldump が実行されます。

mysqldumpとは、MariaDBデータベースのある時点のバックアップです。ダンプファイル作成後のデータ変更がバイナリログに記録されます。ある地点に復元するには、バイナリロギングが有効化されていなければなりません。詳細は以下のZimbraのWiki記事、MariaDB Backup and Restore を参照してください。 https://wiki.zimbra.com/wiki/MySQL_Backup_and_Restore

MariaDBのダンプファイルはgzipされ、バックアップのターゲットディレクトリに移されます。ディレクトリを指定していない場合は /opt/zimbra/backup に移されます。

これらのファイルは非常に大きくなる可能性があります。そのため、MariaDBデータベースバックアップファイルごとに、そのMariaDBデータベースの実容量の3倍以上のディスク容量を用意する必要があります。

  • バックアップ時にmysqldump を自動実行させるには、以下を入力します。

zmlocalconfig edit mysql_backup_retention=<N>

N の値は保管するMariaDBのデータベースバックアップの数です。

MariaDBデータベースを復元する方法については、Zimbraサポートへご相談ください。

バックアップ用のディスク容量を管理する

ターゲットのディスクに十分な空の容量が存在しないと、バックアップセッションは失敗します。このセッション中にバックアップされたデータはすべて破棄・削除されます。

バックアップの完了に十分な容量がない可能性があるとき、通知を受け取るように設定できます。

属性 zimbraBackupMinFreeSpace を設定すると、通知によってバックアップセッションの実行が管理しやすくなります。

バックアップセッションの実行前、zimbraBackupMinFreeSpace 属性の値に、バックアップターゲットディスクに必要な空き容量を設定します。属性に設定された値よりもディスクの空き容量が小さいとき、バックアップセッションは実行されません。それを通知するメッセージが管理者に送信されます。

MariaDBデータベースもバックアップする場合、myslqdump のファイルサイズの格納に確実に足る値を設定する必要があります。

この属性の値は、ディスク全体のパーセント (25%など) またはバイト数 (300MB, 50GBなど) で設定できます。デフォルト値は0です。これは、チェックが無効かつバックアップが常に開始可能ということでます。

この属性はグローバルに、またはサーバーごとに設定できます。

  • グローバル設定

zmprov mcf zimbraBackupMinFreeSpace <value>
  • サーバー設定

zmprov ms <zmhostname> zimbraBackupMinFreeSpace <value>

設定した値の空容量さえあれば、バックアップのセッションは実行します。その値より実際のバックアップファイル大きいと、バックアップのセッションは失敗します。バックアップファイルのサイズを監視して、設定した値よりもバックアップ容量が必要な場合は修正する必要があります。

データの復元

以下の3つの復元方法を実行できます。

  • Zimbra Collaboration メールボックスサーバーが起動中にメールボックスを復元する場合、zmrestore コマンドを使用します。

  • zmrestoreoffline — メールサーバーがオフラインの際にメールサーバーを復元する場合、zmrestoreoffline コマンドを使用します。このコマンドはディザスタリカバリに使用します。

  • zmrestoreldap — LDAPディレクトリサーバーの内容を復元する場合、zmrestoreldap を使用します。

復元プロセスではすべてのアカウント、または特定のアカウントを指定することができます。

復元のプロセス

プロセス zmrestore が以下の手順でメールボックス、データベース、インデックス、そしてLDAPのディレクトリを復元します。

  1. リストア対象として指定されたアカウント、または all を指定した場合にバックアップされているすべてのアカウントを取得します。

  2. 各メールボックスに以下の手順を実行します。

    1. 既存データをクリアするため、サーバーに存在するメールボックスを削除します。

    2. 直近の完全バックアップから、対象のメールボックス分にあたるMariaDBデータ、インデックスデータおよびメッセージディレクトリを復元します。

    3. すべての増分バックアップにあるRedoログを直近の完全バックアップから復元したデータに適用します。

    4. メールボックスサーバーのRedoログのアーカイブから、対象のメールボックス分にあたるRedoログを適用します。

    5. 現在のRedoログを適用します。

アカウントの割り当て容量を超えても、アカウントは復元されます。ユーザーが割り当て容量に関するアクションを次回実行した際に、そのユーザーは割り当て容量を超えている旨の警告を受信します。
Microsoft OutlookのZimbraコネクターを利用しているユーザーについて、Zimbraサーバーが復元されたらOutlookクライアントで初回の同期を実行する必要があります。

Example 28. server1 にあるすべてのアカウントを完全に復元する。

直近の完全バックアップとその後に実行された増分バックアップを含みます。

zmrestore -a all
Example 29. server1にある特定のアカウントの復元を実行する。
zmrestore -a account@company.com
Example 30. 特定の時間内に復元する (PIT)。

以下のオプションはRedoログの適用状況に影響します。これらのオプションを1つも指定しない場合、完全バックアップ以降のすべてのRedoログが適用されます。

下記にある、特定の時間内での復元オプションを実行した場合、復元したアカウントの完全バックアップを即座に取得し、アカウントに今後起こりうる問題を防ぐことを推奨します。

以下のオプションを含めた復元は特定の時間内での復元となります。

  • -restoreToTime <引数> - 指定した時間までRedoログを適用する。

  • -restoreToIncrLabel <引数> - 指定した増分バックアップを含む、指定した増分バックアップまでのRedoを適用する。

  • -restoreToRedoSeq <引数> - 指定したRedoログシーケンスを含む、指定したシーケンスまでのRedoログを適用する。

  • -br - バックアップに存在するRedoログのみを適用し、システムのアーカイブRedoログや現在のRedoログを適用しない。

  • -rf - 完全バックアップのみを復元する。増分バックアップは含まれません。

Example 31. 復元するまでの特定の時間、増分バックアップのラベル、またはRedoログシーケンスを指定する。

複数の時間を指定した場合、一番早い時間で復元を終了します。

zmrestore -a account@company.com-restoreToTime <引数>

<timearg> を指定する形式は以下のどちらかを使用します。

  • "YYYY/MM/DD hh:mm:ss"

  • YYYYMMDD.hhmmss

Example 32. すべてのアカウントに直近の完全バックアップまでの増分復元を実行し、その後の増分バックアップを除外する。
zmrestore -rf --a all
Example 33. 特定のアカウントにメールボックスとLDAPデータを復元する。
zmrestore -ra -a account@company.com
Example 34. 新しいターゲットアカウントへ復元する。

プレフィックスが元のアカウント名に追加されます。

zmrestore -ca -a account@company.com -pre restore

上記の実例の結果として、restoreaccount@company.comへデータが復元されます。

Example 35. データベース (db) と localconfig.xml のシステムテーブルを復元する。
zmrestore -sys
Example 36. エラーが発生した場合に復元のプロセスが継続して実行されるように --contineOnError (-c)をコマンドに追加します。
zmrestore -a all -c

-c を指定した場合、復元のプロセスが完了後、復元できなかったアカウントが表示されます。

Example 37. 特定のアカウントを復元する。

削除されたアカウントを復元するためにも使用できます。

zmrestore -a account@company.com
Example 38. 削除されたアカウントを復元しないために以下のオプションを追加します。
zmrestore -a account@company.com -skipDeletedAccounts
Example 39. メールボックスを復元するものの、Redoログ再実行で行なわれたすべての削除操作を除外する。

メールボックスが復元されると、削除済みのメッセージが格納されることになります。POPを使用するユーザーがサーバーからメッセージを削除する場合、このオプションが役に立ちます。

zmrestore -a account@company.com --skipDeletes
最新の時間をリクエストする場合、バックアップのラベル (-lb)を指定しない。ラベルを指定しない場合、リクエストした時間より前の、直近の完全バックアップが自動的に開始時点として使用されます。

復元のプロセスを停止する

コマンド zmbackupabort -r で実行中の復元プロセスを強制的に停止できます。復元のプロセスで復元中のアカウントの復元が完了した後に停止します。コマンドには、復元できなかったアカウントが表示されます。

復元を強制的に停止するには以下のコマンドを実行します。

zmbackupabort -r

メールサーバーがダウン中にメールボックスを復元する

mailboxdのサーバーが起動していない状態でのみオフラインの復元プロセスを実行できます。基本的にオフラインの復元は以下の条件で実行します。

  • Zimbraサーバーの特定の機能が破損し、サーバーが起動できない状態である。例えば、LDAPやデータベースのデータが破損している。

  • ディザスタにより、サーバーにZimbraのソフトウェアを再インストールする必要がある。

Redoログのシーケンス順番を守るため、 Zimbra Collaboration のメールボックスストアを起動する前にオフラインの復元を実行する必要があります。

ディザスタリカバリでZimbraのソフトウェアが再インストールされた場合、バックアップファイルから復元する前にmailboxdを起動すると、メールサーバーがメッセージの送受信などのアクティビティを開始し、処理中のRedoログに次々にログが出力されます。ディザスタ前のデータがサーバーに復元されていないため、Redoログのシーケンスが不正になります。一度mailboxdを起動してしまうと、障害前のデータを正常に復元することができなくなります。

オフラインの復元プロセスは以下の手順でデータを復元します。

  1. 指定した復元対象のアカウントを取得します。CLIから特定のメールボックスアドレスを指定していない場合、指定のメールホストのすべてのメールボックスをZimbra LDAPのディレクトリサーバーから取得します。

  2. メールボックスごとに以下の手順を繰り返します。

    1. 既存のデータをクリアするため、サーバーにメールボックスを削除する。

    2. メールボックスの直近の完全バックアップからMariaDBデータ、インデックスのディレクトリおよびメッセージディレクトリを復元する。

    3. 直近の完全バックアップ以降のすべての増分バックアップにあるRedoログを復元したデータに適用します。

    4. メールボックスサーバーのRedoログのアーカイブエリアから、そのメールボックスの対象となるRedoログを全て適用します。

    5. 現在のRedoログを適用します。

すべてのアカウントを復元する
  1. mailboxdを停止した状態でserver1にあるすべてのアカウントを復元します。

    zmrestoreoffline -a all
  2. オフラインの復元が完了したら、mailboxdを起動します。

    zmcontrol startup

起動中のシステムに特定のアカウントを復元する

コマンド zmrestore で1つか複数の特定アカウントを復元できます。ユーザーのメールボックスが破損している場合、直近の完全・増分バックアップからユーザーを復元したい場合があります。

  1. 復元対象の各アカウントをメンテナンスモードへ切り替えます。

    zmprov ma <アカウント名> zimbraAccountStatus maintenance

    メンテナンスモードへ切り替えると復元中のメールの送受信が一時的に拒否されます。送受信を一時的に拒否しないと復元のプロセスでメッセージが上書きされることになります。

  2. アカウントに zmrestore のコマンドを実行します。

    zmrestore -a account@abc.com
  3. 復元が完了したアカウントをアクティブモードへ戻します。

    zmprov ma <アカウント名> zimbraAccountStatus active
復元したユーザーアカウントに対して、復元後に適用された提供サービスが存在しない場合、自動的にデフォルトの提供サービスがそのアカウントに適用されます。

復元からアイテムを無視する

完全バックアップから復元する場合、検索インデックスとブロブを除外することが可能です。

  • 検索インデックス — 検索インデックスのデータを復元しない場合、復元後にメールボックスを再インデックスする必要があります。

    zmrestore -a <all|account> --exclude-search-index
  • Blobs — 復元するメールボックスのブロブが既に存在する場合に役立ちます。

    zmrestore <all or account>|--exclude-blobs
  • HSM-blobs — 復元するアカウントのHSMブロブが既に存在する場合に役立ちます。

    zmrestore <all or account> --exclude-hsm-blobs

LDAPサーバーを復元する

ディザスタリカバリによりシステム全体を復元する必要がある場合、LDAPのディレクトリサーバーを最初に復元する必要があります。

コマンド zmrestoreldap を使用すると提供サービス (COS) 、配布リスト、などを含めたグローバルのLDAPデータを復元します。すべてのスキーマを再作成するLDAPサーバーを完全に復元することも、特定のアカウントのみを復元することも可能です。復元するセッションを指定します。復元するLDAPサーバー上で復元のコマンドを実行する必要があります。

Example 40. LDAPのセッションラベルを確認する
zmrestoreldap -lbs
Example 41. LDAPのディレクトリサーバーを完全に復元する
zmrestoreldap -lb full20061130135236
Example 42. 特定のアカウントのLDAPデータを復元する
zmrestoreldap -lb full20061130135236 -a tac@abc.com jane@abc.com

一般的な障害復旧の手順

複数マシンを利用する環境における、一般的なディザスタのシナリオとして、メールボックスのストアサーバーを以下のように復旧します。

準備

  1. メールボックスのストアサーバーを触る前にLDAPのディレクトリサーバーを直近の安定した状態へ復元します。

  2. メールボックスを復元中はユーザーのログインやメール配信を停止する必要があるため、すべてのメールボックスをメンテナンスモードへ切り替えます。

  3. メールボックスのストアサーバーが起動中であれば、停止します。

復元

  1. 必要であれば、メールボックスサーバーに Zimbra Collaboration のソフトウェアを再インストールします。

  2. メールボックスを復元します。

  3. Zimbra Collaboration サーバーを起動します。

  4. すべての Zimbra Collaboration メールボックスをアクティブモードへ戻します。

  5. サーバーの完全バックアップを実行します。

クラッシュ復帰のサーバー起動

システムが予定せずに停止し、スタートアップで再起動されると、サーバーはRedoログを確認して、コミットされなかったトランザクションを見つけると自動的に再実行します。Redoログの再実行により、システムが安定した状態になります。

Zimbra Collaborationサーバーを復元する

完全な機械故障が発生した場合、以下の手順で新しいサーバーへ復元します。

新しいサーバーにインストールする Zimbra Collaboration のバージョンは古いサーバーのバージョンと 完全に一致する必要があります 。サーバーは別のOSを利用することが可能です。

新しいサーバーのハードウェアは Zimbra Collaboration のシングルサーバーインストールガイドに記載されている条件を満たす必要があります。なお、新しいOSをインストールする際に必要なOSの設定変更はインストールガイドに詳細に記載されています。

新しいサーバーへ復元するには以下の操作を実行します。

  1. 新しいサーバーを準備する。

  2. 古いサーバーのIPアドレスへのクライアントアクセスをファイアウォールのルールで拒否する。

  3. 古いサーバーに使用されたボリュームをマウントする。

  4. ZCSの初期設定で作成されるMariaDBデータを削除する。

  5. バックアップファイルを新しいサーバーへコピーする。

  6. zmrestoreldap でグローバルLDAPデータを復元する。

  7. zmrestoreoffine でアカウントデータをバックアップセッションから復元する。

  8. 新しいバックアップの設定を行い、実行する。

古いサーバーの状況

ディザスタリカバリにおける2つシナリオの1つは、サーバーが機械故障により Zimbra Collaboration のファイルへアクセスすることが不可能なこと、もう1つは Zimbra Collaboration は正常に起動しているもののサーバーのハードウェアを取り替える必要があることです。

サーバーが起動していない場合

  1. サーバーのIPアドレスへのクライアントアクセスをファイアウォールのルールで拒否する。

  2. 使用可能な最終 Zimbra Collaboration バックアップセッションを用意する。

サーバーが起動している場合、新しいサーバーへ移動するための準備

  1. サーバーのIPアドレスへのクライアントアクセスをファイアウォールのルールで拒否する。

  2. 古いサーバーの完全バックアップを実行する、またはバックアップが最新である場合、直近のデータを取得するために増分バックアップを実行する。

  3. zmcontrol stop を実行し、Zimbra Collaborationを停止します。最終状態へ復元するためには、増分バックアップが完了後に新しいメールを受信してはなりません。

  4. 古いサーバーのホスト名とIPアドレスを別のものに変更する。 サーバーをオフラインにしない。

ZCS を新しいサーバーへインストールする

実行する前に新しいサーバーに正しいIPアドレスとホスト名が設定されていること、そして、Zimbra Collaborationがインストール済みで、ドメイン、ホスト名、パスワード、などが前回のサーバーと一致していることを確認します。サーバーの準備に関する詳細はZimbra Collaborationインストールガイドを参照してください。Zimbra Collaborationをインストールする前に古いサーバーから、管理者の名前とパスワード、LDAP、Amavis、Postfixのパスワード、迷惑メールと非迷惑メールのトレーニングのユーザーアカウント名、ドメイン名、グローバルドキュメントのアカウント名、などの必要な情報を確認することを推奨します。

新しいサーバーのマシン時間も古いサーバーと一致する必要があります。古いホスト名とMX DNSレコードが新しいサーバーへ解決されることを確認します。
  1. Zimbra Collaboration のファイルを新しいサーバーへコピーします。新しいサーバーにライセンスが存在しない場合、Zimbra Collaborationのインストールを正常に完了できません。

  2. ./install.sh を実行し、インストールガイドの手順にしたがってZimbra Collaborationをインストールします。古いサーバーのドメイン名、ホスト名およびパスワードを一致するように設定します。Zimbra Collaborationのインストール中に以下の設定を元サーバーの設定に一致させる必要があります。

    1. Zimbra LDAP Server —  Domain to create 、 古いサーバーのデフォルトドメインと同じものを設定します。

    2. Zimbra Mailbox Server — 管理者のアカウントが自動的に作成されます。

      • Admin user to create が、元サーバーの管理者ユーザーと一致することを確認します。

      • 管理者のパスワードには、古いサーバーと同じものを設定します。

      • LDAPのパスワードには、古いサーバーと同じものを設定します。

      • PostfixとAmavisのユーザーパスワードには、古いサーバーと同じものを設定します。

      • Spam training userNon-spam (HAM) training user のアカウント名は、古いサーバーの迷惑メールトレーニングアカウント名と一致させます。

      • Global Document Account — このアカウント名は自動的に作成され、デフォルトの名前は通常wikiです。変更した場合、Global Document Accountの名前を古いサーバーに使用した名前と一致させます。

    3. 新しいサーバーの他の設定を元サーバーの設定と一致させます。

    4. メインメニューにて、デフォルトのバックアップスケジュールを設定し、「設定完了後にサーバーを自動的に起動する」を NO に設定します。

新しいサーバーへバックアップを復元する
  1. 新しいサーバーを停止します。

    zmcontrol stop
  2. 古いサーバーに追加のストレージボリュームを設定した場合、その追加ボリュームをマウントします。

  3. MariaDBのデータを削除し、空のデータディレクトリを初期化する。これを実行しないとzmrestoreoffline実行時にエラーが発生します。zimbraのユーザーで以下のコマンドを実行します。

    rm -rf /opt/zimbra/db/data/* /opt/zimbra/libexec/zmmyinit

    MariaDBのサービスが立ち上がりました。

  4. 古いサーバーの /backup ディレクトリ、またはアーカイブの場所からすべてのバックアップファイルを /opt/zimbra/backup へコピーします。

  5. LDAPを復元します。

    zmrestoreldap -lb <latest_label>

    大量のアカウントを復元する場合、復元が完了する前にセッションが切れないようにするため、nohupなどのUNIXコマンドを使用することを推奨します。

    復元するLDAPセッションのラベルを検索するには zmrestoreldap -lbs を実行します。
  6. `zmrestoreoffline`を実行する前に、以下のサービスが起動していることを確認します。

    • mysqld (MariaDB)

    • slapd (OpenLDAP)

      zmcontrol start
  7. `zmrestoreoffline`を実行する前に、以下のサービスが停止していることを確認します。

    • mailboxd

      zmmailboxdctl stop
  8. 現時点でいくつかの Zimbra Collaboration サービスが起動しているため、 zmconvertctl start を実行します。 zmrestoreoffline を実行する前に実行する必要があります。

  9. バックアップディレクトリのLDAPのパスワードを新しいサーバーのLDAP設定へ同期させます。

    zmlocalconfig -f -e zimbra_ldap_password=<password>
  10. mailboxd を停止した後、オフラインの復元を開始します。

    zmmailboxdctl stop
    zmrestoreoffline -sys -a all -c -br

    この時点でもnohupのようなコマンド実行が考えられます。状況を監視するため、以下で確認できます。

    tail /opt/zimbra/log/mailbox.log
    コマンドラインに -c を使用することで、オフラインの復元中に多少のアカウントにエラーが発生してもアカウントの復元が継続的に実行されます。
  11. 現時点でいくつかのZimbra Collaborationサービスが実行中であるため、zmcontrol stop ですべてのサービスを停止します。

  12. 古いバックアップのセッションが無効となりますので、削除します。

    rm -rf /opt/zimbra/redolog/* /opt/zimbra/backup/*
  13. Zimbra Collaborationを起動します。

    zmcontrol start
  14. 完全バックアップを実行します。

    zmbackup -f -a all
  15. ファイアウォールのルールを解除し、新しいサーバーへのクライアントアクセスを許可します。

異なる障害からの復元シナリオ

復元手順はほとんどのサーバー障害で、ほぼ同じです。障害が発生した場合、ディザスタリカバリの項を確認して処理を理解し、その後、それぞれの障害について以下の手順に従います。

LDAPが破損した場合の復元
  1. LDAPサーバーを再インストールする。 Zimbra Collaboration インストールガイドを参照してください。

  2. 復元するLDAPセッションのラベルを確認する。LDAPサーバーにすべてのアカウント、ドメイン、サーバー、COS、などを復元するために zmrestoreldap - lb <ラベル名> をオプションなしで実行します。

  3. すべてのアカウントがアクティブモードであることを確認する。アクティブではない場合、以下のコマンドを実行します。

    zmprov ma zimbraAccountStatus active
破損されたパーティションの交換後の復元
  1. パーティションが壊れた場合、壊れているディスクを交換します。

  2. 直近の完全バックアップファイルと増分バックアップファイルを復元するには以下を実行します。

    zmrestore -a all

    プロセス zmrestore では、指定したメールボックスのホストにある、バックアップ日以降のすべてのメールボックスを取得し、各メールボックスを直近の安定した状態へ復元します。

破損、または読み込み不可のRedoログからの復元

Redoログが読み込み不可となった場合、mailboxdのサービスは停止され、再起動できなくなります。この現象が発生した場合、処理を続ける前にハードウェアとソフトウェアを検査し、問題の原因を特定する必要があります。

最新のRedoログがない場合、Zimbraのメールボックスサーバーを最新の状態へ戻すことはできません。Zimbraのメールボックスのデータを、最後にアーカイブしたRedoログの状態へ復元することができます。Zimbraのメールボックスサーバーが復元されたら、今後のトランザクションを記録する新しいRedoログが生成されます。

開始する前に、mailboxdのサービスは停止され、すべてのアカウントがメンテナンスモードへ切り替えられている状態でなければなりません。
  1. すべてのアカウントをメンテナンスモードへ切り替えます。

    zmprov md <domain> zimbraDomainStatus maintenance
  2. mailboxdのサービスが停止している状態で、以下のコマンドを実行します。

    zmrestoreoffline

    オフラインの復元プロセスが始まり、バックアップから、指定したメールホストにあるすべてのメールボックスのリストを取得します。

    次にオフラインの復元が各メールボックスに以下を実行します。

    • サーバーからメールボックスを削除します。

    • バックアップのデータから直近の完全バックアップを復元します。

    • 直近の完全バックアップより保存した増分バックアップをメールボックスに古い順番に復元します。バックアップデータのRedoログの再適用を含みます。

    • アーカイブにあるすべてのRedoログを適用します。

    現在のトランザクション用のRedoログが使用不可であるため、メールボックスサーバーは、最後にアーカイブされたRedoログの状態へと復元されます。

  3. オフラインの復元が完了したら、 ZCS を起動します。

    zmcontrol startup
  4. Zimbraのメールボックスサーバーが起動したら、Zimbraサーバーの完全バックアップを実行します。最新のRedoログが使用不可であるため、最新のデータをバックアップするために完全バックアップを直ちに実行する必要があります。

Zimbraの復元後、ローカル設定ファイルを変更する

/opt/zimbra/conf にある localconfig.xml には、Zimbraの重要なパスやパスワードを含む、コアなZimbraサーバー設定が保存されています。このファイルは、完全・増分バックアップにバックアップされます。完全や増分の復元を実行した後、バックアップされた localconfig.xml ファイル名が localconfig.xml.restore へ変更され、 /opt/zimbra/conf へコピーされます。

直近のバックアップ以降に変更を行なった場合、localconfig.xmlを復元したファイルにて上書きする必要がある場合があります。これらのファイルを比べて、localconfig.xml .restore のファイルに最新の設定情報が含まれている場合、localconfig.xml を削除し、localconfig.xml.restore ファイル名を localconfig.xml へ変更します。

スナップショットでのバックアップと復元

Zimbraのバックアップと復元機能を使用せずに、ストレージのレイヤで提供しているスナップショット機能を使ってサーバーをバックアップ、復元することができます。スナップショットを使用することで、スタンドバイのサイトを用意し、プライマリのサイトに障害が発生した場合にユーザーをスタンドバイのサイトへ転送することができます。

スナップショットはすべてのデータボリューム分を取得し、スタンドバイのサイトへ定期的に通信されます。スナップショットでバックアップされるデータのボリュームにはMariaDB、ブロブ、LuceneのインデックスおよびRedoログが含まれます。

プライマリのサイトがダウンした場合、zmplayredoのコマンドを使用して、スナップショットに整合性を持たせ、データの変更を再度適用します。これによりボリューム間でのデータ損失を最小限にします。

以下の4つのデータボリュームがあります。

  • MariaDB

  • Blob

  • Luceneのインデックス

  • Redoログ

スナップショットのセットは毎時取得され、リモートのスタンドバイサイトへ通信されます。ただし、すべてのスナップショットは同時に取得されないため、各スナップショットに1秒から1分間の差が発生する可能性があります。また、Redoログのスナップショットはより高い頻度で取得することも可能です。一般的な取得シーケンスは以下のようになります。

8:00:00 - mysqlのスナップショット実行
8:00:01 - ブロブのスナップショット実行
8:00:02 - インデックスのスナップショット実行
8:00:03 - redoログのスナップショット実行
8:05:00 - リモートサイトへスナップショットのセット通信完了
...
8:15:00 - redoログのスナップショット実行
8:15:05 - リモートサイトへredoログのスナップショット通信完了
...
8:30:00 - redoログのスナップショット実行
8:30:05 - リモートサイトへredoログのスナップショット通信完了
...
8:35:00 - プライマリサイトでの障害発生

リモートサイトでは8:00からいくつかのデータのスナップショットがあり、その後Redoログのスナップショットが続きます。ユーザーをスタンドバイのサイトへ転送したら、最新の情報がすべてそこで確認できるように、全情報を統合させる必要があります。

コマンド zmplayredo を実行し、8:00:00以降の変更を適用できます。

zmplayredo --fromTime "2008/10/17 08:00:00:000"

すべてのデータが現在の時間まで復元され、スタンドバイのサイトが起動できる状態となります。8:30:00から8:35:00のデータが損失されますが、復元のプロセスが実行されているときの想定範囲内です。

エフェメラルデータについての留意点

ZCS8.8時点では、エフェメラルデータがバックアッププロセスの一環としてバックアップされることはありません。認証トークンがエフェメラル属性であり、つまり、削除後復元されたアカウントに対してアクセスするクライアントは、再認証が必要になります。バックアップの前に作成された認証トークンは使用できなくなります。

SSDBバックエンドを使用したバックアップ

SSDB内でのエフェメラルデータのバックアップについて

SSDBがエフェメラルバックエンドとして使用される場合、エフェメラル属性は一切、バックアップに含まれません。

注意:本セクションでは、SSDBサーバのインストールや管理に関する詳細を案内しておりません。SSDBサーバの運用詳細につきましては SSDB インストールと設定をご参照ください。

SSDBを利用している場合、保管したデータを以下の方法でバックアップします。

ssdb-dump -h localhost -p 8888 -o /tmp/ephemeral-backup-<日時>

注意:マスター/スレーブの設定で運用している場合、`ssdb-dump`は マスター で実行する必要があります。

バックアップの事例
ssdb-dump - SSDB backup command
Copyright (c) 2012-2015 ssdb.io

recv begin...
received 1 entry(s)
received 10 entry(s)
received 100 entry(s)
received 1000 entry(s)
received 10000 entry(s)
received 100000 entry(s)
received 200000 entry(s)
received 300000 entry(s)
received 400000 entry(s)
received 400021 entry(s)
recv end

total dumped 400021 entry(s)
                               Compactions
Level  Files Size(MB) Time(sec) Read(MB) Write(MB)
--------------------------------------------------
  2        1        7         0        0         7

compacting data...
                               Compactions
Level  Files Size(MB) Time(sec) Read(MB) Write(MB)
--------------------------------------------------
  2        2       10         0        0        10

backup has been made to folder: /tmp/ephemeral-backup-<date>
SSDB へエフェメラルデータをリストアする方法

SSDBサーバのバックアップからのみ、エフェメラルデータをSSDBへリストアする事が可能です。

なお、リストア方法は以下のいずれかとなります。

  • 運用中のサーバへインポートする

  • 既存データを上書きする

運用中のサーバへインポートする場合

SSDBソフトウェアで提供している`leveldb-import`コマンドを使用することで、 運用中のSSDBサーバへ`ssdb-dump`で作成したバックアップデータをインポートできます。

leveldb-import localhost 8888 /tmp/ephemeral-backup-<日時>/data
既存データを上書きする場合

SSDBサーバを停止します。 `ssdb-dump`コマンドでバックアップしたディレクトリを新しいディレクトリへコピーします。 `ssdb.conf`の設定ファイルを更新し、`work_dir`をコピーした新しいディレクトリに設定します。 SSDBサーバを起動し、以前のログインが正常に行えるか確認します。

LDAPバックエンドを使用したバックアップ

エフェメラルバックエンドがLDAPの場合、認証トークンもCSRFトークンもバックアップに含まれません。ただし、最後にログインしたタイムスタンプは含まれます。アカウントの復元で、管理コンソールの "最終ログイン"値には適切な値が復元されます。

アーカイブとディスカバリ

Zimbraアーカイブとディスカバリーはオプションの機能で、 Zimbra Collaboration 送受信したメッセージをアーカイブし、メールボックスをまたいで検索することができます。

アーカイブ機能のインストールにより、 ZCS のディスカバリーツール (クロスメールボックス検索とも呼ばれます) もインストールされます。Zimbra MTA上でアーカイブを有効にするための属性値が設定されます。

アーカイブはアカウント単位で設定します。各アカウントのアーカイブを有効にするには、アカウント単位のZimbraのアーカイブライセンスが必要となります。アカウントのアーカイブを有効にした場合、そのアカウントについてMTAで受信と送信したメッセージのコピーが転送され、事前設定されたアーカイブメールボックスへ配信されます。アーカイブのプロセスはアカウントユーザーへ影響することはありません。

ディスカバリーの機能では、ライブとアーカイブメールボックスを横断したメッセージ検索と、指定したメールボックスに検索結果のメッセージをコピーすることができます。

アーカイブのやり方について

ユーザーがメッセージを送受信した際、メッセージは、常にPostfixのMTAを経由してルーティングされます。PostfixのMTAでは配信中のメッセージに対し特定のアクションを実行するソフトウェアの使用を許可しています。アーカイブがメッセージの送信者、または受信者に対して有効な場合、ZimbraアーカイブがMTA hookとAmavisd-newの機能を用いてメッセージのコピーを生成します。

受信者か送信者にアーカイブが有効であるかどうか のチェックはSMTPのスタンダードエンベロープ上で実行され、FromやTo/CCのヘッダーでは実行されません。エンベロープ上でチェックが行なわれるため、BCCのコピーや配布リストへ送信したメッセージも取得されます。

Example 43. アーカイブが有効であるメッセージの送信

例えば、ユーザーAがユーザーBへメッセージを送信し、このときユーザーBのアーカイブが有効な場合、MTAは2つのメッセージを配信します。1つはユーザーBのメールボックス、そしてもう1つはユーザーBのアーカイブメールボックスです。ユーザーBのメールボックスで受信したメッセージは以下のように普通の見え方で受信されます。

Received: from localhost (localhost.localdomain [127.0.0.1])…
From: userA@example.com
To:userB@example.com
Subject: New License Key
Message-ID: <015f01c717fe$70f042d1$b1d6f61d@thom>
Date: Mon, 04 Nov 2008 23:48:18 -0000

Hi B,

Can you send me the license key for the software again?

Thanks, A

ユーザーBのアーカイブメールボックスで受信したメッセージには追加の X-Envelope-FromX-Envelope-To のヘッダーが追加されます。これらのヘッダーは、メッセージが送信した実際のメールアドレス、そして受信したメールアドレスを示しています。

Received: from localhost (localhost.localdomain [127.0.0.1])…
From: userA@example.com
To:userB@example.com
Subject: New License Key
Message-ID: <015f01c717fe$70f042d1$b1d6f61d@thom>
X-Envelope-From: userA@example.com
X-Envelope-To: userB@example.com
Date: Mon, 04 Nov 2008 23:48:18 -0000

Hi B,

Can you send me the license key for the software again?

Thanks, A

Zimbraアーカイブでは、 Zimbra Collaboration 内部で管理されるアーカイブアカウントを作成したり、サードパーティのアーカイブシステムへのメッセージ送信するためのSMTP転送を利用して、サードバーティアーカイブシステムと共に動作するように設定したりすることもできます。サードパーティのアーカイブの場合、 Zimbra Collaboration は転送エージェントとして動作するように設定されます。

ディスカバリー方法

アーカイブとディスカバリーのディスカバリー機能を使用して、ライブ* とアーカイブのメールボックス内でメッセージと添付ファイルを検索します。ディスカバリーのツールを管理コンソールから実行して、指定したメールボックスへ検索結果をコピーすることができます。

* ライブ のメールボックスはシステム上にある、アーカイブアカウントとシステムアカウント以外のアカウントです。

送信や受信したメッセージを日付、送信先、宛先、Cc、件名、キーワードおよび添付ファイルで検索できます。また、名前、日付と時間の期間範囲、配布リストおよびエイリアスで検索するクエリを作成することも可能です。

検索結果はターゲットメールボックスへ保存されます。様々なメールボックスを作成したり、検索のターゲットメールボックス内に個々のフォルダを作成したりして、検索結果の構成を管理することができます。ターゲットメールボックスへコピーされたメッセージには、 X-zimbra-Source のヘッダー情報が各メッセージヘッダーへ追加されています。このヘッダーラベルにはアカウントID、アカウント名およびアカウントが存在しているサーバー名が含まれます。

検索結果はターゲットメールボックスへログインすることで確認できます。

アーカイブパッケージのインストール

アーカイブのパッケージは、既存のシングルサーバー環境、またはマルチサーバー環境へインストールできます。

メールボックスサーバーとMTAサーバーが同一ノードに存在する場合、アーカイブ機能を一つのプロセスとして設定し、有効化します。メールボックスとMTAサーバーが別々のノードに存在する場合、zimbra-archiveのパッケージをまず最低一つのメールボックスサーバーにインストールし、環境内の各MTAにてアーカイブコンポーネントを有効化します。

シングルサーバー環境へアーカイブをインストールする

以下のシナリオではLDAP、MTA、メールストアおよびアーカイブのサーバーが同一のノードに存在しています。

  1. Zimbra Collaboration Single Server Installationガイドを参照し、SSHで Zimbra Collaboration サーバーへ接続します。サーバーに root としてログインし、アップグレードを ./install.sh のコマンドで開始します。

  2. ライセンス同意確認を承認して、 Yes を入力し、アップグレードを開始します。

  3. インストール対象パッケージが表示される際、zimbra-archivingに対して Yes を入力します。

アップグレード処理が開始し、アーカイブのパッケージがインストールされます。ディスカバリー機能もインストールされ、使用可能となります。

アーカイブを有効化する場合、 zimbra ユーザーへ切り替えし、MTAサーバーでアーカイブ機能を有効化します。

zmprov ms <Zimbraホスト名> +zimbraServiceEnabled archiving

サーバーを再起動します。

zmcontrol restart

マルチサーバー環境にアーカイブをインストールする

以下のアップグレードシナリオでは Zimbra Collaboration環境に新しいアーカイブ専用のサーバーを追加します。

インストールを開始する前に、以下の情報を記録します。アーカイブサーバーをインストールする際に以下の情報が必要です。 zmlocalconfig -s のコマンドより以下の情報を確認できます。

LDAP 管理者パスワード _____________________
LDAP ホスト名       _____________________
LDAP ポート           _____________________

マルチサーバーのパッケージのインストールガイドの詳細については、 Zimbra Collaboration Multi-Server Installation guideを参照してください。

  1. アーカイブを設定するメールボックスサーバーをSSHで接続します。サーバーに root としてログインし、Zimbraのソフトウェアを展開します。アップグレードを ./install.sh のコマンドで開始します。

  2. y を入力し、 Enter キーを押すと、以下のパッケージがインストールされます。

    • zimbra-store

    • zimbra-archiving

      パッケージ zimbra-core はデフォルトでインストールされます。

  3. y を入力し、 Enter キーを押すと、 システムの修正が開始します。

  4. メインメニューでインストールするZimbraコンポーネントのデフォルト内容が表示されます。メニューを展開するには x を入力し、 Enter キーを押します。

  5. Common Configuration メニューを選択し、LDAPのホスト名、パスワードおよびポートを設定します。

  6. zimbra-store のメニューを選択し、管理者パスワードとライセンスファイルの場所を設定します。

Multi-server InstallationガイドのInstalling Zimbra Mailbox Server手順に従って、インストールを完了します。

この時点で、ディスカバリー機能はインストールされており、使用可能です。

管理コンソールからアーカイブを管理する

アーカイブ機能をインストール後、管理コンソールでアーカイブの設定と管理が可能です。

アーカイブを有効化する

管理コンソール:

ホーム > 設定 > グローバル設 > MTA へ遷移し、 アーカイビング設定 から、 アーカイブを有効にする のオプションをチェックします。

コマンドラインで ZCS を再起動します。

zmcontrol restart

専用のアーカイブ提供サービスを作成する

提供サービスの属性値を設定することで、メールボックス機能、割り当て容量、パスワードの設定や、迷惑メールとウイルス検査の有効・無効化、GALからアーカイブアカウントを隠すなどができます。

管理コンソール:

ホーム > 設定 > 提供サービス へ遷移し、 ギア アイコンから 新規 をクリックします。

  1. アーカイブ用の提供サービスとして 機能プリファレンス を設定します。

  2. 専用のアーカイブサーバーをご利用の場合、サーバープールのページでアーカイブサーバーをリストから選択解除します。専用アーカイブサーバーのあるマルチサーバー環境にて、そのアーカイブサーバーがランダムに新規アカウントに割り当てられないように、COSサーバープールからこのサーバーを外す必要があります。

    サーバーをサーバープールから外す上記ステップは、シングルサーバー構成の場合、行いません。アーカイブのメールボックスを同様の設定で簡単に作成できるため、専用のアーカイブ提供サービスを作成することを推奨しています。
  3. 必要に応じて、詳細設定 のオプションを設定します。

  4. アーカイビング のページで アーカイビングを有効にする にチェックを入れて、提供サービスをアーカイブの提供サービスとして設定します。

  5. アーカイブアカウントの命名規則の形式を変更したい場合、 2箇所のテンプレートフィールドを変更します。詳細について、以下の アーカイブアカウントの名前を設定する を参照してください。

  6. 終了 のボタンをクリックします。

アーカイブアカウントの名前を設定する

属性値でアーカイブアカウントの命名規則を作成・管理することができます。管理する属性値は提供サービス、または各アカウントで設定します。管理コンソールの提供サービス、または各アカウントのアーカイブページに属性値の変更が可能です。

  • アカウントの日時テンプレート :命名規則のテンプレートに使用する日時フォーマットを設定します。デフォルトは yyyyMMdd です。アカウント名に日時を追加することで、システムからバックアップに古いデータを移動するのが容易になります。

  • アカウント名のテンプレート :アーカイブメールボックス名が作成される方法を設定する。デフォルトの値は ${USER} ${DATE}@${DOMAIN}.archive です。

そのため、アーカイブのアカウントは、以下の例のようになります。

user-20070510@example.com.archive

デフォルトの値を変更する場合、有効なメールアドレスを作成するための文字列の形式を守る必要があります。アーカイブのスプーフィングを発生させないための対策として、すべてのアーカイブアカウントにドメインの後に .archive を追加することを推奨しています。

属性 zimbraArchiveAccountDateTemplate をベースとしたテンプレートが設定されると zmconfigarchive が実行される際に amavisArchiveQuarantineAccount が新しいテンプレート名へと更新されます。

アーカイブサーバーを管理する

サーバープロセス amavisd-new はアカウントのアーカイブおよびウイルスと迷惑メールの対策プロセスを管理します。 コマンド zmarchivectl でアカウントアーカイブ機能が管理しているamavisd-newのサーバープロセスの起動、停止、再起動、またはステータスを確認できます。アーカイブ、ウイルス対策、迷惑メール対策は同一のサーバープロセスを共有しているため、アーカイブ機能の開始や停止を行なう際は注意が必要です。共有しているプロセスへのアクションを起こす場合、環境内で有効な他の機能への影響が出る可能性があります。

ウイルスと迷惑メール対策を有効のままでアーカイブのみを無効にする場合、CLIや管理コンソールから個々のサービスを無効化します。

ユーザーのメールボックスにアーカイブを設定する

アカウントのアーカイブ機能には4つの属性が関連しています。2つはメールボックスを設定し、残りの2つはテンプレート属性でアーカイブアカウント名の作成に使用します。

メールボックスにアーカイブを設定する場合、ユーザーのメールボックスに2つの属性を設定します。1つの属性はアーカイブを有効化し、もう1つはメッセージがアーカイブされる場所を指定します。

  • 現在のアーカイブ — 現在のアーカイブアドレス。アーカイブは単一のアカウントに対するものです。設定していない場合、アーカイブは無効です。

  • アーカイブしているアカウント — このメールボックスがアーカイブされていた全ての過去と現在のアーカイブアドレス。指定されたアカウントに対してアーカイブされていた全てのアカウントが含まれます。

メールボックスをアーカイブする

アーカイブのメールボックスを特定の提供サービスに紐付けることができます。アーカイブされたメールをサードパーティに転送することも可能です。

アーカイブを有効にしているアカウントはZimbraライセンスのアーカイブアカウント数にカウントされます。アーカイブメールボックスはユーザーアカウントと共に管理コンソールで一覧表示されます。ライセンス情報を確認するには、 管理コンソールの以下のページを参照してください。
ホーム > 設定 > グローバル設定 > ライセンス

アーカイブのメールボックスを作成し、提供サービスを適用する

アーカイブアカウントはZimbraのアーカイブ命名テンプレートをベースにして作成されます。

  • アーカイブアカウントに属性 — zimbraIsSystemResource — が追加され、TRUEへ設定されます。

  • アーカイブアカウントが管理コンソールに表示されます。

  • アーカイブを有効にしているメールボックスへメッセージを受信した場合、メッセージのコピーがアーカイブのメールボックスへ送信されます。

ユーザー zimbra としてサーバーへログオンし、 以下のように zmarchiveconfig コマンドを実行します。

zmarchiveconfig enable <account@example.com> archive-cos <archive>

提供サービスとパスワードが設定されていないアーカイブのメールボックスを作成する

アーカイブアカウントに提供サービスを設定していない場合、以下の設定がデフォルトで設定されます。

  • メールボックスの割り当て容量が0、つまり無制限に設定されます。

  • ウイルスと迷惑メールの検査が無効化されます。

  • アーカイブアカウントがGALに表示されないように "GALに隠す"が有効化されます。

ユーザー zimbra としてサーバーへログオンし、 以下のように zmarchiveconfig コマンドを実行します。

zmarchiveconfig enable <user@example.com>

サードパーティのアーカイブサーバーへアーカイブを転送する

アーカイブアカウントが Zimbra Collaboration で管理されていない場合、パスワード、提供サービス、その他の属性を設定する必要はありません。

ユーザー zimbra としてサーバーへログオンし、 以下のように zmarchiveconfig コマンドを実行します。

zmarchiveconfig enable <account@example.com> \
 archive-address account-archive@offsite.com \
 archive-create false

複数のメールボックスを検索する

アーカイブとディスカバリー機能がインストールされている場合、管理コンソールやコマンドラインで、メールボックスをまたいで検索することが可能です。

複数メールボックス検索をするためにアーカイブのメールボックスを設定する必要はありませんが、アーカイブのパッケージをインストールする必要はあります。

管理権限の委任をすることで、権限を委任された管理者は管理コンソールからメールボックスの検索を実行することができます。

管理コンソールから複数のメールボックスを検索する

アーカイブのパッケージが追加されたら、ディスカバリーツールの メール検索 が、ナビゲーションペインの ツールおよび移行 のメニューへ追加されます。クロスメールボックスの検索を設定する場合、以下の情報を設定します。

管理コンソール:

ホーム > ツールおよび移行 > メール検索 へ遷移し、 ギア アイコンから 新規 を選択。

  • サーバー名 :検索するサーバー名。

  • ターゲットメールボックスとフォルダ :ターゲットメールボックスとフォルダが自動的に作成されます。このメールボックスはすべての検索結果に使用できます。また、各検索に新しいフォルダを作成したり、各検索に新しいターゲットメールボックスを作成することができます。

    ターゲットメールボックスは他のメールボックスと変わらず、提供サービスやアカウントごとに、機能とプリファレンスを指定できます。ターゲットメールボックスは管理コンソールのアカウントリストで確認できます。ターゲットメールボックスのアカウントに名前をつけて、クロスメールボックス検索用ターゲットメールボックスを識別したい場合、アクセスを管理するために特定の提供サービスを設定することを推奨しています。

  • 検索結果で返答するメッセージ数を制限する :デフォルトは500件の検索結果です。

  • 検索が完了したときにメール通知を送信することが可能です。メール通知の件名には検索のタスクIDとステータスが含まれ、また、ヒットしたメッセージ数、検索結果からのアドレスや使用した検索クエリなど、メッセージ本文に含む情報を指定できます。

  • 検索するメールボックスを選択します。 検索するアカウントを選択する をチェックした場合、検索するアカウントのアドレスを選択します。

  • 検索クエリを作成する : アウトバウンドとインバウンドのメールを日時、送信者、宛先、Cc、件名、キーワードおよび添付ファイルにて検索できます。詳細検索では名前、日時の期間、配布リストおよびエイリアスによるクエリも作成できます。

    アーカイブメッセージを検索する際、 envfromenvto のクエリでエンベロープアドレスを検索します。

検索の実行時、メールボックス検索内容のペインに検索結果のリストやステータスが表示されます。更新 をクリックするとページの情報を更新できます。

検索タスクはサーバーのメモリを使用するため、検索完了後は削除することを推奨しています。サーバーが再起動されると過去の検索が自動的に削除されます。

管理コンソールでディスカバリー機能を使用すると、このツールが管理者によって作成されたターゲットメールボックスにメッセージをコピーします。メッセージがサーバー容量を使用しますので、サーバーのサイズが増加します。そのため、検索結果でコピーされたメッセージの必要性がなくなったら、削除することを推奨しています。

情報についての法的要請

法律傍受の機能では、対象アカウントにある送受信したメッセージと下書きに保存されたメッセージをコピーして、指定の “shadow” のメールアドレスへ送信します。

法律傍受はメッセージの全文、またはヘッダーのみを送信するように設定できます。対象アカウントがメッセージを送信、受信、または下書き保存した際、転送するメッセージを添付ファイルとした傍受のメッセージが自動的に作成され、指定のメールアドレスへコピーを送信されます。

法律傍受の設定

法律傍受の機能は提供サービス、または特定のアカウントへ設定できます。この機能は zmprov を使用して、CLIで設定します。

法律傍受を設定するにはターゲットアカウント、または提供サービスの — zimbraInterceptAddress — 機能を有効化することのみです。

また、メッセージの本文をコピーせず、ヘッダー情報のみを送信する場合、zimbraInterceptSendHeadersOnly 属性を有効化します。

法律傍受を設定する

傍受したメッセージの送信先傍受用アドレスを指定します。

  • 提供サービスで傍受を有効にする場合

    zmprov mc <cosname> zimbraInterceptAddress <account@intercept.example.com>
  • アカウントに対し、傍受を有効にする場合

    zmprov ma <アカウント名@ドメイン> zimbraInterceptAddress <account@intercept.example.com>

デフォルトの傍受メッセージのテンプレートや送信先アドレス(postmaster@<domain>)を使用する予定であれば、法律傍受のセットアップは完了です。

メッセージのヘッダーを転送するように法律傍受を設定する

アカウントからメッセージ全文をコピーせず、ヘッダー情報のみを転送する場合

zmprov ma <アカウント名@ドメイン> zimbraInterceptSendHeadersOnly TRUE

傍受のカバーメールメッセージを編集する

転送するメッセージを添付ファイルとした傍受のメッセージが自動的に作成されます。デフォルトのメッセージには以下の内容が含まれています。

  • 送信元 のアドレスは “<Postmaster@<address.com>”

  • 件名は “Intercept message for <アカウント名@ドメイン> <傍受されたメッセージ件名>”

  • メッセージ “Intercept message for <アカウント名@ドメイン>. Operation=<メッセージの種類>, folder=<フォルダ名>, folder ID=<#>”

このカーバーメッセージをカスタマイズすることができます。以下のパラメーターを使用し、メールメッセージの内容を変更できます。

ACCOUNT_DOMAIN

傍受されるアカウントのドメイン

ACCOUNT_ADDRESS

傍受されるアカウントのアドレス

MESSAGE_SUBJECT

傍受されるメッセージの件名

OPERATION

ユーザーが実行しているオペレーション「メッセージの追加」、「メッセージの送信」、または「下書きの保存」

FOLDER_NAME

メッセージが保存されたフォルダ名

FOLDER_ID

メッセージが保存されたフォルダのID

NEWLINE

マルチラインのメッセージ本文のフォーマットに使用する

差出人、件名のテキスト、メッセージ本文のテキストを変更するには以下の手順を実施します。

  • 差出人 を変更する場合

    zmprov ma <アカウント名@ドメイン> zimbraInterceptFrom '<newname@example.com>'
  • 件名 のテキストを変更する場合

    zmprov ma <アカウント名@ドメイン> zimbraInterceptSubject \
     '<Intercepted message subject text> parameter <text> parameter'
  • メッセージ本文 のテキストを変更する場合

    zmprov ma <アカウント名@ドメイン> zimbraInterceptBody \
     '<Intercepted message text> parameter <text> parameter'
アカウントごとに編集する場合、zmprov mc {cosname} …​ を使用します。

法的証拠開示用のメールボックスのスナップショット作成機能

REST URLフォーマットを用いて、ユーザーのメールボックスにある特定のメールメッセージや添付ファイルを検索し、ヒットしたメッセージをzipファイルにしてお使いのコンピュータに保存することができます。取得したzipファイルを法的要請をしている強制執行機関へ転送することができます。

メールメッセージは、件名からファイル名が設定された、.emlファイルです。添付ファイルは送受信したフォーマットで保存されます。

メールボックスのスナップショットZipファイルを作成する

ZCS の管理コンソールへログインする必要があります。アカウントごとにクエリを作成します。

  1. ブラウザで管理コンソールのアドレスに 7071/ の後に、以下を入力します。

    home/<ユーザー名>?fmt=zip&query=<検索キーワード>

    例:

    Address Bar

    上記の例では、検索クエリで user1 のアカウントに対して2008年6月13日以降のすべてのメッセージの添付ファイルを依頼しています。

    ZCS内の検索に使われる検索の操作はどれも使用できます。例えば、フォルダ名(in:フォルダ名)や送信者名(from:<送信者>)などで検索可能です。また、複数の検索クエリを繋げることもできます。キーワードの実例についてはWikiページにある検索のヒントを参照してください。 https://wiki.zimbra.com/wiki/Search_Tips

  2. キーボードの Enter を押し、zipファイルを生成します。ページから離れるかどうかの 確認 ダイアログが表示されます。

  3. OK をクリックします。

  4. zipファイルを保存する場所を指定します。zipファイルの送信準備が完了します。

テーマ色やロゴ管理

個々の Zimbra Collaboration テーマをカスタマイズしなくても、Zimbraウェブクライアントのベーステーマで使うベース色とロゴを変更することができます。これはCLI、または管理コンソールで実行できます。

Zimbraウェブクライアントのテーマ色とロゴを変更する方法

テーマのベース色とカスタムロゴはグローバル、またはドメインごとに設定することができます。

  • グローバル設定を変更した場合、変更がすべてのサーバーにあるすべてのテーマに適用されます。

  • ドメインの設定を変更した場合、ドメインにあるテーマのベース色とロゴが変更されます。

テーマのベース色やロゴがグローバル設定とドメイン設定で異なる場合、ドメインに設定した内容が優先的に適用されます。

マルチドメインの Zimbra Collaboration 環境でロゴとベース色をカスタマイズする場合、仮想ホストをベース色として設定しなければなりません。ブラウザから送信されるホストヘッダーに基づき、ロゴの属性が表示されます。
Zimbra Collaborationには複数のZimbraテーマが含まれています。Lemongrass, Hot Rod, Waves などのいくつかのテーマでは、ベース色を修正しても画像や色コードが変更されないように設計されているものもあります。こうしたテーマをユーザーのテーマプリファレンスから無効化することもできます。

ベースのテーマ色のカスタマイズ

ZWCのテーマの以下のベース色を変更できます。

  • クライアントのプライマリ背景色。

    この色はページの背景色となります。様々な色がボタンや内容の背景、ペイン、タブ、選択のハイライトに使用されます。以下の画像では背景色がロゴとともに表示され、様々な背景色がログインエリアに表示されています。

  • セカンダリー色はツールバーに使用する色です。

  • 選択色は選択したアイテムの色です。例えばメッセージやオーバービューペインにあるアイテムです。

  • 前景色は表示するテキストの色です。デフォルトの色は黒です。テキストの色は通常、変更する必要のないものです。

ZWCロゴを交換する場合

Zimbraのロゴを会社のロゴにグローバル、またはドメインごとに変更できます。

ロゴ変更のライセンスポリシーについて
Zimbraの公式ライセンスではZimbraウェブクライアント内のZimbraロゴの削除を認めていません。ネットワークエディションのお客様のみがZimbraウェブクライアントのロゴを交換することができます。このため、ネットワークエディションのお客様のみ以下の手順を参照してください。ライセンスの詳細については以下のページを参照してください。 https://www.zimbra.com/license/
交換する画像

以下のZimbraロゴファイルを変更できます。カスタムのロゴ画像ファイルを正常に表示するため、以下に指定している解像度にする必要があります。画像のファイルは別のサーバーまたは Zimbra Collaboration がアップグレードした際にも上書きされないようなディレクトリに保存することができます。

  • ZWCと Zimbra Collaboration の管理コンソールでログインとスプラッシュ画面に表示するロゴ。この画像の解像度は300×30にする必要があります。

  • ZWCアプリケーションと管理コンソールの左上に表示するロゴ。この画像の解像度は170×5にする必要があります。

  • 会社のロゴをクリックした際にリンクする会社のURLアドレス。

交換できない画像

詳細検索のツールバーに表示されるZimbraアイコンおよびURLのブラウザアドレスバーに表示されるfavicon.icoは、現時点では変更することができません。

管理コンソールによるテーマ色とロゴ画像の変更について

管理コンソールのグローバル設定とドメイン設定にあるテーマページは、色のスキーマをカスタマイズしたり、会社のロゴとロゴURLを追加するなどの設定が可能です。Zimbraウェブクライアントと管理コンソールページに使用する会社ロゴをサーバーにアップロードしてください。

ベースのテーマ色を変更する

事前設定された色のテーブルのポップアップから選択するか、6桁の16進カラーコードを入力して、次のカテゴリのテーマ色に合う色を設定できます。

  • テーマの前景色:テキストの色です。

  • テーマの背景色:クライアントのプライマリ背景色です。

  • テーマの補色:ツールバーやメニューペインの選択ヘッダーの色です。

  • テーマの選択色:選択したアイテムの色、例えばメッセージ、右クリック、またはドロップダウンのメニュー選択肢です。

テーマ設定の変更にはサーバーのテーマキャッシュのフラッシュが必要です。 ホーム > 設定 > サーバー へ遷移し、サーバーリストを表示してください。対象のサーバーを右クリックして表示されるメニューから キャッシュのフラッシュ を選択します。

テーマに合う色の設定には、テーマのロゴをカスタマイズ コンテナを利用します。

管理コンソール:

ホーム > 設定 > グローバル設定 > テーマ または
ホーム > 設定 > ドメイン → ドメイン名 → テーマ

  1. 修正するテーマカテゴリの項目をクリックし、ポップアップ表示された色のテーブルを使用して希望の色を決定します。

    色を直接クリックし、選択しても、入力項目に16進カラーコードを入力してもかまいません。いずれにしても選んだ色が項目に表示されます。

    色の指定をやめたい場合、テーマのすべての色をリセット ボタンをクリックし、選択した内容を消去します。

  2. このページを離れると、設定を保存するかどうかが質問されます。

    はい (保存) または いいえ (選択した内容を消去)をクリックします。

ロゴを追加する

グローバルに、またはドメイン単位で、該当のテーマページから Zimbra Collaborationロゴを会社ロゴに変更することができます。ロゴは 交換する画像 セクションに記載されているサイズと同じでないと、正常に表示されません。画像のファイルは別のサーバーまたはZimbra Collaboration がアップグレードした際にも上書きされないようなディレクトリに保存します。

グローバル設定 >テーマテーマのロゴをカスタマイズ セクションから設定を行なう場合、画像が正常に表示されるためにはこのセクションの前項目を入力しなければなりません。

なお、詳細検索のツールバーに表示されるZimletアイコンおよびURLのブラウザアドレスに表示されるfavicon.icoは変更することができません。

テーマに合うロゴの設定には、テーマのロゴをカスタマイズ コンテナを利用します。

管理コンソール:

ホーム > 設定 > グローバル設定 > テーマ または
ホーム > 設定 > ドメイン → ドメイン → テーマ

Table 56. ロゴの設定
オプション 説明

テーマのロゴURL

ロゴからリンクされる会社のウェブアドレス

テーマのアプリケーションロゴバナーURL

ZWCと管理コンソールのログインとスプラッシュ画面で表示される会社ロゴ。解像度は正確に450×100でなければなりません。

アプリケーションロゴバナーのプレビュー(200×35)

ZWCアプリと管理コンソールの左上の会社ロゴ。解像度は正確に200×35でなければなりません。

テーマのログインロゴバナーURL

ログインロゴバナーのプレビュー(440×60)

テーマ色とロゴの変更にCLIを使用する

ZWCテーマのベース色とロゴ変更にはzmprovコマンドを使用します。次の属性はグローバル設定あるいはドメイン設定のいずれかで設定します。カラーコードは十六進法の6数字で入力します。

Table 57. 色の属性
属性 説明

zimbraSkinBackgroundColor

クライアントで表示するプライマリ背景色の16進カラーコード。

zimbraSkinSecondaryColor

ツールバーと選択されたタブ色の16進カラーコード。

zimbraSkinSelectionColor

選択したアイテムの16進カラーコード。

zimbraSkinForegroundColor

テキスト色の16進カラーコード。デフォルトが黒のため、この属性は通常、変更する必要はありません。

テーマのベース色を変更する方法

始める前に変更する属性に設定する16進カラーコードを用意します。変更するコマンドは以下となります。

グローバル設定を変更する場合
zmprov modifyConfig <属性名> [“#6進カラーコード”]
ドメインの設定を変更する場合
zmprov modifyDomain <ドメイン名> <属性名> [“#6進カラーコード”]

ドメインの編集

以下の例ではベースの色を変更します。

  • 背景色 = サンゴ色, #FF7F50

  • セカンダリー色 = 空色, #ADEAEA

  • 選択色 = 黄色, #FFFF00

    1. スキンカラーを指定します。zimbra ユーザーでログインし、ドメイン修正のために zmprov を使用します。

      zmprov modifyDomain example.com \
       zimbraSkinBackgroundColor "#FF7F50" \
       zimbraSkinSecondaryColor "#ADEAEA" \
       zimbraSkinSelectionColor "#FFFF00"

      # の記号を使うには、クォーテーションマーク "" が必要です。

    2. 変更した内容を適用するため、zmmailboxdctlコマンドを使用し、メールボックスを再起動します。

      zmmailboxdctl restart

      ウェブクライアントをリロードすると、指定したドメインの Zimbra Collaboration テーマ は上記で変更した色で表示されます。

ロゴの追加方法

会社のロゴURL情報や画像は以下の属性で管理しています。

Table 58. ロゴの設定
属性 説明

zimbraSkinLogoURL

zimbraSkinLogoURL ― ロゴ画像クリックで遷移させたい会社のウェブアドレス。

zimbraSkinLogoLoginBanner

ZWCと Zimbra Collaboration 管理コンソールのログインとスプラッシュ画面に使用するロゴの画像ファイル名。

zimbraSkinLogoAppBanner

ZWCと管理コンソール画面の左上に表示するロゴの画像ファイル名。

ドメインにロゴを追加する方法について

ロゴファイルを Zimbra Collaboration サーバーに保存する場合、 /opt/zimbra/jetty/webapps/zimbra のサブディレクトリに格納する必要があります。

ロゴが他のマシンにある場合、ロゴを特定する正確なURLを入力してください。

本項のステップで、ドメインに表示されるロゴを更新します。

  1. URLを変更します。

    zmprov modifyDomain zimbraSkinLogoURL https://url.example.com/
  2. ロゴ表示を修正します。

    ロゴ画面とスプラッシュ画面に表示されるロゴを変更します。

    zmprov modifyDomain zimbraSkinLogoLoginBanner /zimbra/loginlogo.png

    ZWCのメインページに表示されるロゴを変更します。

    zmprov modifyDomain zimbraSkinLogoAppBanner /zimbra/applogo.png
  3. メールボックスを停止・起動します。

    zmcontrol restart
ZWCのロゴ修正は、現在サポート対象外 です。

Zimlets

Zimletを使用することで、Zimbraウェブクライアントに ZCS とサードパーティの製品を合体し、ユーザー環境を強化できます。Zimletではユーザーが受け取ったサードパーティからのメールメッセージにより、その情報を閲覧したりやり取りを行なうことが可能です。Zimbraの提供サービスを編集することで、ZWCのオーバービューペインからユーザーはZimletを利用できるようになります。

ZCS にはいくつか前もって設定されたZimletが含まれています。また、独自のZimletを作成することやZimbraウェブサイトのZimlet Galleryからダウンロードすることも可能です。

ZCSに含まれた設定済みZimletを有効にすると、ユーザーは以下の機能を使用できます。

  • 日付や時刻上にマウスを合わせて、カレンダー内の内容を確認する。

  • 名前やメールアドレス上にマウスを合わせて、名前に関する詳細情報をアドレスブック内から参照する。

  • 電話番号を右クリックし、ソフトウェア電話で発信する。

  • 日付を右クリックし、会議やイベント予定を新規で作成する。

  • 名前、住所、電話番号を右クリックし、連絡先リストの情報を更新する。

独自Zimletの作成に関する詳細はZimbra WikiのZimbra Developmentページを参照してください。

管理コンソールでZimletを管理する

Zimbraの管理コンソールから以下のZimlet管理タスクを使用できます。

  • Zimletを配備する。配備により、LDAPサーバーにZimletのエントリが作成され、サーバーにZimletのファイルがインストール・有効化され、デフォルト提供サービスでZimletが利用できるようになります。

  • 提供サービスやアカウントごとにZimletの使用可・不可を設定する。

  • Zimletを強制する。

  • Zimletを無効化する。Zimletはサーバーに残りますが、使用されません。

  • Zimletの配備を解除する。配備を解除すると、Zimletが提供サービスやZimletのリストから削除されますが、サーバーからはZimletのアンインストールはされません。

管理コンソール上ではZimletをアンインストールすることができません。

カスタムZimletを配備する

ZimbraウェブサイトのZimlet GalleryからカスタムのZimletをダウンロードし、配備できます。Zimletが配備されたら、デフォルト提供サービスの全ユーザーは直ちに使用できるようになります。Zimletが別の提供サービスへ直接に配備されていない場合、その提供サービスにこのZimletがリストアップされますが有効化はされていません。

管理コンソール:

ホーム > 設定 > Zimlets へ遷移。ギア メニューから配備をクリックします。

  1. 配備したいZimletを選択し、配備 をクリックします。

    Zimletがサーバーへ配備されます。Zimletの配備されるサーバー名と配備状況を表示する画面が表示されます。

  2. 完了 をクリックします。

    Zimletが有効であることをZimletのページで確認できます。

Zimletを有効、無効、または必須にする

Zimletの有効、無効、または必須を設定できます。また、トグル機能でインストール済みのZimletが対象のユーザーに利用可能かどうかを選択できます。

管理コンソール:

ホーム > 設定 > 提供サービス → 提供サービス名 → Zimlet

Table 59. Zimletの操作ステータス設定
設定 説明

必須

Zimletがユーザーのアカウントで必ず有効。必須のZimletはユーザーのZimletページに表示されません。

無効

対象の提供サービスのユーザーに対し、即座にZimletを無効化します。

有効

配備されたZimletがすべて有効化されます。

ユーザーはアカウントの プリファレンス> Zimlet のページにて、任意のZimletを自由に有効化・無効化できます。Zimletを必須に設定した場合、ユーザー側では無効化できません。

Zimletの配備を解除する

Zimletの配備を解除した場合、すべての提供サービスから削除したあとにLDAPから削除されます。

管理コンソール:

ホーム > 設定 > Zimlets

  1. 配備を解除する Zimlet を選択します。

  2. 画面の右上 ギア メニューから 配備解除 を選択します。

  3. はい をクリックし、Zimletの配備を解除します。

Zimletにプロキシに許可したドメインを追加する

プロキシ許可ドメインによって、どの外部ドメインがZimlet経由でアクセス可能かを設定できます。 ZCSに含まれているZimletに関しては、プロキシ許可ドメインは既に設定されています。他のZimletをダウンロードし配備した場合、追加プロキシドメイン名を追加することもできます。

管理コンソール:

ホーム > 設定 > 提供サービス

  1. 編集する 提供サービス名 を選択します。

  2. 詳細設定 ページにて、プロキシ許可ドメイン の設定属性へスクロールダウンします。

  3. ドメインを追加する場合、ドメインを追加 のボタンをクリックします。

  4. ドメイン入力が完了したら、画面の右上の 保存 をクリックします。

Zimletのアップグレード

カスタムZimletをアップグレードする場合、Zimletの配備と同様の手順を使用します。なお、新しいZimletのzipファイル名は既存Zimletのzipファイル名と同じである必要があります。

管理コンソール:

ホーム > 設定 > Zimlet へ遷移し、ギア メニューから 配備 をクリックします。

  1. アップグレード完了後にアップグレードしたZimletを提供するため、 Zimletキャッシュをフラッシュ をチェックします。

  2. アップグレードする Zimlet名 を選択し、配備 をクリックします。

  3. 完了 をクリックします。

コマンドラインでZimletを管理する

次のZimlet管理タスクは、CLIから実行することができます。

Zimletを配備する

Zimletを配備すると、デフォルト提供サービスに指定されている全ユーザーへ直ちに有効化されます。Zimletを別の提供サービスへ配備しない場合、その提供サービスのZimletのリストには表示されますが、有効化はされません。

デプロイ前の提供サービスの修正も含めた、CLIからのZimlet配備手順は以下のとおりです。

  1. Zimletを選択し、ZimletのzipファイルをZimbraサーバーの /tmp フォルダへコピーします。

  2. サーバーへZimbraユーザーとしてログインします。 su - zimbra

  3. 以下のコマンドでZimletを配備します。

    zmzimletctl deploy /tmp/<zimlet>.zip

Zimletにプロキシに許可したドメインを追加する

Zimletを配備する際、Zimletで情報を正常に得るために呼ばれることになるドメインアドレスを、対象の提供サービスの属性 zimbraProxyAllowedDomains に設定する必要があります。

以下のコマンドでこの属性 zimbraProxyAllowedDomains を設定できます。

zmprov mc <COSname> +zimbraProxyAllowedDomains '*.example.com'

ドメイン名 example.com の前に * を追加する必要があります。 .

このZimletを有効化した全ての提供サービスに設定する必要があります。

Zimletを配備し、提供サービスへのアクセスを許可する

Zimletをデフォルト提供サービス以外の提供サービスへ配備する場合

  1. Zimbraユーザーとしてログインします。su - zimbra

  2. Gallery からのZimletのファイルを /tmp のフォルダへコピーします。

  3. デフォルト提供サービスへZimletを配備します。

    zmzimletctl deploy /tmp/<zimlet>.zip
  4. 他の提供サービスへ配備する場合、以下のコマンドを実行します。

    zmzimletctl acl <zimletname> <cosname1> grant

    上記のコマンドで cosname1 へのアクセスを許可します。同時に複数の提供サービスへ許可することも可能です。

    zmzimletctl acl <zimletname> <cosname1> grant <cosname2> grant
  5. Zimletにプロキシ許可ドメインを使用する場合、以下のコマンドを各提供サービスで実行し、適切なドメインの許可を追加します。

    zmprov mc <COSname1> +zimbraProxyAllowedDomains '*.example.com'
    zmprov mc <COSname2> +zimbraProxyAllowedDomains '*.example.com'

Zimletのリストを表示する

zmzimletctl を実行すると現在インストールされているZimletのリストが表示されます。

zmzimletctl listZimlets all

サーバーおよびLDAPにインストールされているZimlet、そして各提供サービスで使用可能なZimletがリストに表示されます。

Zimletの設定を変更する

Zimletによっては、配備後に追加の設定が必要になる場合もあります。

Zimbraの設定テンプレートを使用することで、設定テンプレートを変更して、それから新しい設定ファイルをZimbraサーバーへインストールすることが可能です。

Zimlet設定を変更するには:

  1. 以下のコマンドで設定テンプレートを抽出します。

    zmzimletctl getConfigTemplate <zimlet.zip>
  2. テンプレートに対して必要な編集を行ないます。必要な属性のみを編集するように注意してください。編集を完了後、ファイルを保存します。

    複数のカスタムZimletをご利用の場合、LDAPの設定を更新する前に config_template.xml を別のファイル名して、上書きされないようにしてください。
  3. zmzimletctlコマンドでLDAPの設定を更新します。なお、設定テンプレートのファイル名を変更した場合、config_template.xmlを新しいファイル名に入れ替えてください。

    zmzimletctl configure config_template.xml

Zimletのアップグレード

カスタマイズしたZimletのアップグレードは、Zimletを新しく配備する手順と同様に実行します。

新しいZimlet zipファイルは、既存のZimlet zipファイルと区別しやすい名称にしてください。

Zimletのアップグレード手順

  1. Zimletのzipファイルを /opt/zimbra/zimlets-extra のディレクトリへコピーして、古いバージョンに上書きします。

  2. 以下のコマンドでZimletを配備します。

    zmzimletctl deploy <zimlet.zip file name>

    Zimletが /opt/zimbra/zimlets-deployed のディレクトリへコピーされます。Zimletに.jspのファイルが含まれていた場合、その.jspファイルも /opt/zimbra/jetty/webapps/zimlet/<zimletnamefolder> にコピーされます。

  3. 新しいバージョンを適用するため、キャッシュをフラッシュします。

    zmprov flushCache zimlet

ZimbraのウェブサイトにあるZimlet GalleryからZimletをダウンロードし配備できます。 https://www.zimbra.org/extend/ へ遷移し、Zimbra Gallery セクションのExtensionへスクロールしてください。

カスタムなZimletの開発

カスタムのZimlet設計に関する詳細については、Zimbra WikiのZimlet Developer Guideを参照してください。 https://wiki.zimbra.com.

ボイスサービスの利用について

Unified Communications(UC)は様々なモードの通信サービスを統合したものです。これによりユーザーはボイスメールで受信したものをClick-to-Callのような別のサービスで返信することが可能になります。

Zimbraではリアルタイムのボイス、電話、およびオンライン状態に含まれている通信サービスを非リアルタイムの電子メールやボイスメールのサービスと連携して機能しています。Zimbra Collaboration Server(ZCS)のボイスサービス機能には、ビジュアルボイスメール、Click-to-Call、およびオンライン状態(Ciscoのみ)のサービスが含まれています。また、ZCSはCiscoやMitelのサーバーをサードパーティ製のボイスサーバー(UCサーバー)として使用し、ZCSとZimbraウェブクライアント(ZWC)の通話を仲介します。

注記: UCシステム管理者はUCサーバーのドキュメンテーションを参照し、UCサーバーの設定や管理をする必要がございます。

ボイスサービスは管理コンソールから有効化することができます。ユーザーはZWCのボイスタブからボイスサービス機能を使用します。

ユーザーがZWCアカウント上でボイスサービスへログインする際、UCサーバーへログインされます。初期のユーザーセットアップ完了後、ボイスサービスがシームレスとなり、アカウントに他の項目の設定は必要ありません。

ボイスサービス機能は以下を含みます。

  • Visual Voice Mail: ボイスタブより、ユーザーがボイスメールを簡単に閲覧や傍聴、および発信者の名前、時間情報とメッセージの長さの詳細も確認できます。ユーザーは、メッセージの発信者への折り返し電話、メッセージを電子メールでの転送や返信、メッセージの保存や削除、および新規ボイスメッセージの受信通知などを設定することができます。サポートされているオーディオ形式にはWAVとMP3が含まれています。

  • Click-to-Call: ZWCアカウントから電話発信を可能にする機能。ユーザーはメール本文中の電話番号をハイライトし、クリックすることでの電話発信、またはアドレス帳から連絡先の電話番号を選択で電話発信できます。ユーザーが登録された物理的な電話機、または仮想の電話機を経由し、宛先への通話が実行されます。Click-to-Callでは電話機から番号を入力する必要がなくなります。

  • Click-to-Chat: (Ciscoクライアントのみ)CiscoのJabberクライアントとZCSを使用し、連絡先とチャットする機能。なお、連絡先のIMアドレスが既に連絡先情報として保存されている必要があります。連絡先の情報にアクセスし、IMのリンクをクリックすることで、チャットが開始します。

  • Presence: (Ciscoクライアントのみ)ユーザーや連絡先が連絡可能な状態にあるかリアルタイムで表示する機能。CiscoのJabberを使用する場合、ユーザーのオンライン状態は手動、または自動で設定することができます。例えば、ユーザーが電話の通話を受けている場合、オンライン状態は自動的に「on a call」へ設定されます。設定可能なオンライン状態は available (連絡可能)、 away (離席)、on a call: (通話中)、または do not disturb (多忙)となります。

設定手順について

ボイスサービスの作成には、以下の設定手順を実行してください。

  1. 適切なサーバーURLへアクセスします。詳細については「サードパーティのUnified Communicationsサーバーに利用について」 を参照ください。

  2. ボイスサービスを作成します。詳細については「ボイス/チャットサービスの作成」 を参照ください。

  3. ボイスサービスとボイス機能を有効化します。詳細については「ボイス/チャットのサービスを有効にする」 を参照ください。ボイス機能を有効化にするとZWC上にボイスのタブが表示されます。

  4. ご利用のベンダーサーバーに対して、適切なZimletを有効化します。詳細については 「ボイス/チャットのZimletを有効にする」 を参照ください。

ボイスサービスの利用条件

ZCSボイスサービスを使用するために以下の条件が必要です。

  • ボイスサービスのライセンス: ボイスサービスの機能が含まれているZCSのライセンスが必要です。適切なライセンスを取得するには ライセンス のチャプターを参照ください。

  • Unified Communications Server(統合コミュニケーションのサーバー): Cisco、およびMitelのサードパーティ製Unified Communicationsサーバーの必要条件は以下に記載しています。以下の「サードパーティのUnified Communicationsサーバーに利用について」に詳細が記載されている通り、UCサーバーからのURLはZCSのボイスサービスの設定に使用されます。

    • Ciscoについて:

      • Cisco Unity Connection (UC) 8.5以降が必要 Cisco UCがボイスサービス設定に使用するボイスURLを生成します。

      • Cisco Unified Communications Manager (CUCM) 7.1(3): Click-to-Call機能を使用するため、Web Dial サービスを有効化する必要があります。Cisco CUCMがボイスサービス設定で使用される通話URLを生成します。

      • Cisco Unified Presence Server (CUPS) 8.0: Cisco CUPS を使用するためにPresence Webサービスを有効化にし、オンライン状態を監視するアプリケーションのユーザーも作成する必要があります。Cisco Communications Manager (CUCM) > User Managementにて設定できます。Cisco CUPSはボイスサービス設定で使用されるオンライン状態のURLを生成します。

      • UCでの統合にCisco Jabber のクライアントが提供されます。

    • Mitelについて:

      • Mitel Unified Communicator Advanced (Mitel UCA) 5.0.23.0 リリース以降が必要です。 Mitel UCAがボイスサービス設定に使用されるURLを生成します。

  • ZCS Zimlets: Voice Preferences Zimlet, Cisco Click2Call Zimlet や Mitel Click2Call Zimlet

サードパーティのUnified Communicationsサーバーに利用について

ZCSボイスサービスはサードパーティ製のUnified Communications(UC)サーバーを経由し、ZCSとUCサーバー間の通話をブリッジします。UCサーバーのドメイン情報は許可されたプロキシーのドメインとしてZCSの管理コンソールへ追加されます。そのため、Click-To-Callやオンライン状態の機能、などにて、Zimletがボイスサービスの設定に使用される場合、UCサーバーへリクエストすることが 可能されます。UCサーバーがボイスサービスを設定する際、以下のURLを使用します。

CiscoのURLについて

  • ボイスのURL: ボイスURLはCisco UCサーバーのURLです。例として、「 https://xx.xx.xxx.xx 」のようなURLになります。ZCSサーバーはこのURLを使用し、Cisco UCサーバーからユーザーのボイスメールをユーザーの代理で取得します。

  • 通話のURL: 通話のURLはCisco CUCMサーバーのURLです。例として、https://xx.xx.xxx.xx/webdialer/services/WebdialerSoapService70 のようなURLになります。ZCSのCisco Click2Call ZimletがこのURLを使用し、通話をCisco CUCMサーバーへ仲介します。

  • オンライン状態のURL: オンライン状態のURLはCisco CUPSサーバーのURLであり、セッションIDを生成するために使用されます。例として、 http://xx.xx.xxx.xx:8082/presence-service/users のようなURLになります。ZCSのEmail ZimletがこのURLを使用し、連絡先のオンライン情報をCisco CUPSのサーバーへFetchのリクエストを送信します。

注記: アプリケーションのユーザー名とパスワードはCisco Unified Presence Server(CUPS)で作成できます。

MitelのURLについて

  • ボイスのURL: ボイスのURLはMitelサーバーのURLです。例として、「 https://xx.xx.xxx.xx 」のようなURLになります。ZCSサーバーはこのURLを使用し、Mitel Voiceサーバーにユーザーのボイスメールをユーザーの代理で取得します。

  • 通話のURL: 通話のURLはMitelサーバーのURLです。例として、https://xx.xx.xxx.xx/webdialer/services/WebdialerSoapService70 のようなURLになります。ZCSのMitel Click2Call ZimletがこのURLを使用し、通話をMitelサーバーへ仲介します。

  • ユーザーのURL: ユーザーのURLはMitelサーバーのURLです。ZCSはユーザー確認や認証でこのURLを使用します。

ボイス/チャットサービスの作成

ZCSでボイス/チャットサービスを作成する際、ZCSとサードパーティ製のUCサーバーへの仲介が有効化されます。サービスはドメイン、提供サービス(COS)、また特定のユーザーに作成されます。

  1. ZCS管理コンソールにて、 ホーム>設定>ボイス/チャットサービス のページを開きます。

  2. 画面右上のギアアイコンより 、新規 をクリックします。

  3. ボイス/チャットベンダーの選択ページにて、ドロップダウンメニューからご利用のベンダーを選択します。

  4. *OK*のボタンをクリックします。

  5. ドメイン、COS、または特定のユーザーへボイスサービスを追加するため、 表示名 を設定します。

  6. 利用希望のボイスサービスに適切なURLを追加します。

  7. OK のボタンをクリックします。

オンライン状態を設定する(Ciscoのみ)

オンライン状態を設定する場合、オンライン状態のセッションIDを作成する必要があります。

  1. ZCS管理コンソールにて、 設定>ボイス/チャットサービス のページを開きます。

  2. オンライン状態のセッションIDを発行するボイスサービスを選択します。

  3. 画面右上のギアアイコンより セッションIDの生成 をクリックします。

  4. オンライン状態のユーザー名 、および オンライン状態のパスワード を入力します。これらの情報はオンライン状態のサーバーが使用し、ZCSとUCサーバーにボイスの接続を認証します。これによりZCSはユーザーのオンライン状態を取得することができます。

  5. OK のボタンをクリックします。オンライン状態のセッションIDが発行され、 オンライン状態のセッションID として表示されます。

ボイス/チャットのサービスを有効にする

ドメイン、COS、またはユーザーへ使用可能なボイス/チャットのサービスを作成したら、ボイス/チャットのサービスを有効にする必要があります。COSとユーザーアカウントについて、ZWCにボイスのタブを表示するためのボイス機能も有効にします。

ドメインにボイス/チャットのサービスを有効にする

ドメイン>全般情報のページにて、ドメインにボイス/チャットのサービスをサービスを有効にします。

  1. 管理コンソールで 設定>ドメイン のページを開きます。

  2. ボイスサービスを有効にするドメインを選択します。

  3. 画面右上のギアアイコンより 編集 をクリックします。

  4. ボイスおよびチャット の項目にて、作成したボイスサービスの表示名をドロップダウンメニューより選択します。

  5. 画面右上に 保存 をクリックします。

COSにボイス/チャットのサービスを有効にする

COSのボイス/チャットのサービスについて、ボイス/チャットのサービスを有効にしてから、ボイス機能を有効にします。

  1. 管理コンソールで 設定>提供サービス のページを開きます。

  2. ボイスサービスを使用するCOSを選択します。

  3. 右上のギアアイコンより 編集 をクリックします。

  4. 全般情報のページにて、 ボイスおよびチャット にて作成されたボイスサービスの表示名をドロップダウンメニューから選択します。(画面右上の保存をクリックします)

  5. 左メニューより、 機能 をクリックします。

  6. 機能のページにて、 ボイス/チャット機能ボイス機能の有効化 へチェックを追加します。このオプションが有効の場合、ZWC上でボイスのタブが表示されます。

  7. 画面の右上に 保存 をクリックします。

ユーザーアカウントにボイス/チャットのサービスを有効にする

ユーザーアカウントのボイス/チャットのサービスについて、ボイス/チャットのサービスを有効にしてから、ボイス機能を有効にします。

  1. 管理コンソールにて、 ホーム>管理>アカウント のページを開きます。

  2. ボイスサービスを有効にするアカウントを選択します。

  3. 右上のギアアイコンより 編集 をクリックします。

  4. 全般情報のページにて、 ボイスおよびチャット までスクロールします。

  5. ボイス/チャットサービス のドロップダウンメニューから、作成したボイスサービスの表示名を選択します。

  6. チャット/ボイスのユーザー名 を追加します。これはサードパーティ製のUCサーバーにあるユーザーアカウント名となります。ユーザー名を追加しない場合、デフォルトのユーザー名が自動的に使用されます。例えば、「 user1@domain.com 」のユーザーの場合、デフォルトのボイスユーザー名は「 user1 」になります。

  7. ボイス/チャットサービス のドロップダウンメニューから、作成したボイスサービスの表示名を選択します。

  8. 左メニューより、 機能 をクリックします。

  9. 機能ページにて、ボイス/チャット機能までスクロールし、 ボイス機能の有効化 にチェックを追加します。これによりZWC上でボイスのタブが表示されます。

  10. 右上の 保存 をクリックします。

ボイス/チャットのZimletを有効にする

ボイスサービスを設定する際に、サービスの有効化やUCサーバーへのリクエストを送信するために専用のZimletが使用されます。ボイスのプリファレンスZimletでユーザーインターフェースにボイスのページを追加し、ベンダー専用のClick2Call ZimletでClick to Callの機能を提供します。

  1. 管理コンソールにて、 ホーム>設定>Zimlet のページを開きます。

  2. ボイスのプリファレンスZimletを有効にします。

    • 右ペインで ボイスのプリファレンス Zimletを選択します。

    • 画面右上のギアアイコンより 配備 をクリックします。

  3. ベンダー専用のClick2Call Zimletを有効にします。

    • ご利用のベンダーサーバーに対する適切なZimletを選択します:

  4. Ciscoをご利用の場合、 Cisco Click2Call のZimletを選択します。

  5. Mitelをご利用の場合、Mitel Click2Call のZimletを選択します。

    • 画面右上のギアアイコンより 配備 をクリックします。

Zimletの配備を解除する場合、Zimletを選択し、画面右上のギアアイコンより 配備解除 をクリックするか、 ステータスの切り替え で無効化できます。

Backup Next Generation NG

Real Time Scan

Real Time Scannerとは

Real Time Scannerは、Backup NGの革新的な機能です。システム内で発生した全てのイベントは即時、ZimbraのRedoLogに記録され、登録されます。つまり、アカウントをいつでも前の状態に戻すことができるため、全タイプの復元を秒刻みの精度で実現することができます。

機能

Real Time Scannerは、RedoLogが提供する情報フローに追随する形でメールサーバーの全イベントをほぼリアルタイムで読み込んでいます。そして、アイテム作成やメタデータ更新などの同様の操作をそのデータ構造内に「複製」します。どのデータもバックアップで上書きされることがないため、各アイテムは個々の履歴を持つことができます。

Real Time Scannerの管理

Real Time Scannerを有効にする
管理拡張機能から
  • バックアップNGタブを選択します。

  • Real Time Scannerの下にある 有効 ボタンを押下します。

注意: Real Time Scannerを初めて有効にする場合や停止した後に再び有効にする場合は即時のフルスキャンが必要です。Real Time Scannerの下にある有効ボタンをクリックするとフルスキャンを促す警告メッセージが表示されます。

CLIから

CLIからReal Time Scanを有効にするには次のとおり、Backup NGモジュールのプロパティ ZxBackup_RealTimeScannertrue に設定します。

zxsuite backup setProperty ZxBackup_RealTimeScanner TRUE
Real Time Scannerを無効にする
管理拡張機能から
  • バックアップNGタブを選択します。

  • Real Time Scannerの下にある 無効 ボタンを押下します。

CLIから

CLIからReal Time Scanを無効にするには次のとおり、Backup NGモジュールのプロパティ ZxBackup_RealTimeScannerfalse に設定します。

zxsuite backup setProperty ZxBackup_RealTimeScanner FALSE
Real Time Scannerの無効が必要な場面

Real Time Scannerの無効が必要となる場面は唯一、複数のドメインの外部復元を実施している間だけです。サーバーに高い負荷をかけないための安全策として実施します。インポート後は、再度Real Time Scannerを有効にし、指示されたとおりにSmartScanを実行してください。

制約とSafety Scan

Real Time Scannerでデータを復元する際の主な制約

  • 空にされたフォルダ - 右クリックで開くメニューにある フォルダを空にする ボタンをユーザーが使用するとき。

この場合、Backup NGはReal Time Scanで保存されたメタデータを読み込むことでのアイテムステータス判別ができません。この結果、復元前の対象アカウントに対するアカウントスキャンが開始されます。

アカウントスキャンは不整合データを修正し、メールボックスのバックアップメタデータをきれいにします。

ブロブなしのバックアップ方法

新しい機能として、アイテムのブロブをバックアップせずに他のアイテム関連データをバックアップするブロブなしのバックアップ方法を提供しています。 この方法はご利用中のストレージソリューションにある内部バックアップやデータ重複する詳細なストレージ機能を活用し、バックアップモジュールのディスク容量と復元速度を最高化します。

ブロブなしのバックアップを利用するための必要条件

ブロブなしのバックアップ方法を利用するため、以下の条件を達成する必要があります。

  • サーバが Zimbra 8.8.15 とそれ以降のバージョンを運用していること

  • 「独立している」第三者のボリュームが存在しないこと:ブロブなしのバックアップはローカルのボリューム、または合体した第三者のボリュームでのみ互換性があります。

なお、ブロブなしバックアップ方法は異なるストレージ環境で運用可能であり、ストレージのベンダー様を問わずに、上記の条件を達しているサーバやインフラに有効化することが可能です。

ブロブなしのバックアップ方法仕組みについて

ブロブなしのバックアップはデフォルトのバックアップと同様に動作します。RealTimeスキャンがアイテムの変更をバックアップし、SmartScanがドメイン/提供サービス/アカウントの情報をバックアップします。ただし、ブロブなしのバックアップでは、バックアップファイルに「blob」のアイテムが含まれず、すべてのメタデータと通信履歴のみが保管されます。

なお、ブロブなしのバックアップを有効化した後、機能の有効化がサーバ全体のブロブ処理に影響しますので、ターゲットボリュームやHSMポリシーを問わず、ブロブファイルのバックアップが行わなくなることをご注意いただく必要がございます。

ブロブなしのバックアップファイルからデータを復元する方法

現在、ブロブなしのバックアップは「Raw Restore」のオプションでのみご利用いただけます。今後のリリースに、ブロブなしのデータセットへ他の復元オプションを追加することが予定しております。

ブロブなしのバックアップ方法を有効化する方法

グローバル設定、またはサーバ設定にて、backupBloblessMode の NG 属性値でブロブなしのバックアップ方法を有効化することが可能です。

zxsuite config global set attribute backupBloblessMode value true
zxsuite config server set mail.example.com attribute backupBloblessMode value true

SmartScan

SmartScanとは

SmartScanは、バックアップシステムの健康状態のための主要な一貫性チェックです。 スマート である理由は、前回のSmartScan以降に変更されたアカウントだけを処理対象とするためです。これにより、システムパフォーマンスを向上させ、スキャン時間を大幅に短縮することができます。

デフォルトでは、SmartScanの実行は毎夜予定されています(管理拡張機能のバックアップNGタブ内 Scanオペレーションを定期実行させる がオンの場合)。週に一度、ユーザーが設定した曜日に、SmartScanと合わせて行なわれるパージにより、保持期間の過ぎた削除済みアイテムがBackup NGのデータストアからクリアされます。

機能

Backup NGエンジンは、Zimbraデータストア内の全アイテムをスキャンし、前回のSmartScan以降に更新されたアイテムを検索します。そして古いエントリを更新し、バックアップに存在しないアイテムを作成します。同時に、バックアップ内に存在するもののZimbraデータストアに存在しないアイテムには削除フラグを付けます。

その後、バックアップ内のドメインやアカウント、提供サービス、そしてサーバー設定が全LDAPデータおよび設定のダンプと同じになるように、バックアップ内にある設定のメタデータが全て更新されます。

SmartScanの実行タイミング

  • Backup NGモジュールが開始されるとき。

  • 日次。ただし、管理拡張機能の“Scanオペレーションを定期実行させる”がオンの場合のみ。

  • 以前無効にしたReal Time Scannerを管理拡張機能から再び有効にする場合。

SmartScanの実行

管理拡張機能から開始する

管理拡張機能から開始する方法

  • 管理拡張機能を開きます。

  • バックアップNGタブをクリックします(有効なライセンスがあること)。

  • Run Smartscan 実行ボタンをクリックします。

CLIから開始する

CLIからフルスキャンを開始するには doSmartScan コマンドを使用します。

構文:
   zxsuite backup doSmartScan [attr1 value1 [attr2 value2...


パラメーターリスト

名前                データ型
notifications(O)    Email Address[,..]

(M) == 必須パラメーター, (O) == 任意のパラメーター

使用例:

zxsuite backup dosmartscan notifications user1@example.com,user2@example.com
SmartScanを実施し、通知をuser1@example.comとuser2@example.comに送信します。
スキャン実行状態の確認

CLIから実行中のスキャンの状態を確認するには monitor コマンドを使用します。

構文:
   zxsuite backup monitor {operation_uuid} [attr1 value1 [attr2 value2...


パラメーターリスト

名前                 データ型
operation_uuid(M)    Uiid
operation_host(O)    String

(M) == 必須パラメーター, (O) == 任意のパラメーター

パージ

バックアップパージとは

バックアップパージはクリーンアップ処理です。データバックアップ保持期間ポリシー で定義されている保持期間を過ぎた削除済みアイテムを全て、バックアップパスから削除します。

機能

パージエンジンは、全削除済みアイテムのメタデータをスキャンして、最終更新(削除)日時が保持期間を過ぎているアイテムを全て削除します。

アイテムBLOB が1つまたはそれ以上の有効なメタデータファイルから参照されている場合、Backup NGに含まれる重複排除機能のため、そのBLOB自体は削除されません。

Backup NGのバックアップ対象であるSPostfixのカスタマイズも、バックアップパスのパージポリシーに準拠します。管理拡張機能の バックアップNG タブ内 古いカスタマイズをパージ のチェックを外せば、これを変更することができます。

バックアップパージの実行タイミング

  • 週次。ただし、管理拡張機能の“Scanオペレーションを定期実行させる”がオンの場合のみ。

  • 管理コンソールまたはCLIからマニュアル操作で開始した場合。

無期限保持

データバックアップ保持期間ポリシー0 に設定された場合、無期限を意味するため、バックアップパージは即座に終了します。保持期間を過ぎる削除済みアイテムがなくなるためです。

バックアップパージの実行

管理拡張機能からバックアップパージを開始する

管理拡張機能からバックアップパージ開始する方法

  • バックアップNGタブをクリックします(有効なライセンスがあること)。

  • 画面右上にある Purge実行 ボタンをクリックします。

CLIからバックアップパージを開始する

CLIからフルスキャンを開始するには doPurge コマンドを使用します。

構文:
   zxsuite backup doPurge [attr1 value1 [attr2 value2...


パラメーターリスト

名前              データ型
purgeDays(O)      String
backup_path(O)    Path

(M) == 必須パラメーター, (O) == 任意のパラメーター

使用例:

zxsuite backup dopurge purgeDays 30 backup_path /opt/zimbra/backup/backup_name
バックアップパージ実行状態の確認

CLIから実行中のパージ状態を確認するには monitor コマンドを使用します。

構文:
   zxsuite backup monitor {operation_uuid} [attr1 value1 [attr2 value2...


パラメーターリスト

名前                 データ型
operation_uuid(M)    Uiid
operation_host(O)    String

(M) == 必須パラメーター, (O) == 任意のパラメーター

外部バックアップ

外部バックアップとは

外部バックアップは、Backup NGのバックアップタイプの一つです。メールシステムのスナップショットを作成し、ディザスタリカバリ時や移行時の使用に備えます。エクスポートされたデータは重複排除され、圧縮されます。ディスク利用率や転送時間、I/Oを最適化するためです。

機能

Backup NGエンジンは、Zimbraデータストアの全データをスキャンし、選択されたフォルダへその(重複排除済みかつ圧縮済み)全アイテムを保存します。

フォルダ権限

バックアップ先フォルダに対する読み書き権限が zimbra ユーザーにあることを確認してください。

下記コマンドを使用して、エクスポート用ディレクトリを作成できます。

mkdir /opt/zimbra/backup/yourdestfolder

chown -R zimbra:zimbra /opt/zimbra/backup/yourdestfolder

移行準備

エラーのリスクを最小限に留めるため、移行前に次の保守手順を実施してください。

  • コマンド /opt/zimbra/libexec/zmfixperms --verbose --extended を使用して、Zimbraの権限をダブルチェックします(rootで実行)。

  • 全メールボックスを再インデックス化します。

  • zxsuite hsm doCheckBlobs ユーティリティにて、BLOBの整合性をチェックします。

外部バックアップの実行

管理拡張機能から

管理拡張機能から外部バックアップを開始する方法

  • バックアップNGタブをクリックします。

  • インポート/エクスポート の下にある エクスポートバックアップ ボタンをクリックし、エクスポートウィザードを開きます。

  • エクスポート先パスをテキストボックスに入力し、次へを押下します。システムはそのエクスポート先のフォルダが空かどうか、'zimbra’ユーザーに読み書き権限があるかどうかをチェックします。

  • エクスポートしたいドメインを選択し、次へを押下します。

  • 選択したドメインが全てオペレーション概要に表示されていることを確認します。処理が完了した際に通知を送るあて先のメールアドレスを追加で入力できます。ただし、管理者アカウントと操作を開始した管理者にはデフォルトで通知されます。

CLIからの場合

CLIから外部バックアップを開始するには doExport コマンドを使用します。

構文:
   zxsuite backup doExport {destination_path} [attr1 value1 [attr2 value2...


パラメーターリスト

名前                   データ型                初期値
destination_path(M)    Path
domains(O)             Domain Name[,..]      all
notifications(O)       Email Address[,..]

(M) == 必須パラメーター, (O) == 任意のパラメーター

使用例:

zxsuite backup doexport /opt/zimbra/backup/ domains example.com notifications john@example.com
example.comのバックアップを/opt/zimbra/backup/へ送り、john@example.comに通知します。

予約スクリプト

NGのCLIを使用して外部バックアップ処理を予約することができます。社内あるいは法的な理由から、日次・週次・月次バックアップを継続取得する際に便利です。

新アカウントへの復元

新アカウントへの復元とは

新アカウントへの復元処理では、処理時点のメールボックスの内容およびプリファレンスを新たに作成したアカウントに即座に復元します。 元アカウントが変更されることはありません。このため、メールボックス全体をロールバックすることなく、1件以上の削除済みアイテムをユーザーのアカウントに復元できます。このタイプの復元を行なう際はセキュリティの観点から、GALから新しく作成したアカウントを隠すかどうかを選択することもできます。

機能

新アカウントへの復元処理が開始されると、新しいアカウント(復元先アカウント)が作成されます。選択されている元アカウントにその時点で存在するアイテムは、フォルダ構成やそのユーザーのデータも含め全てが復元先アカウントに再作成されます。HSMポリシーを適用する のチェックがオンでない限り、復元されるアイテムは全て現在のプライマリストアに登録されます。

新しいアカウントにデータを復元した場合、共有アイテムの整合性は保たれていません。元の共有ルールが、復元先アカウントのIDではなく、元アカウントのIDを参照しているためです。

管理拡張機能から新アカウントへの復元処理を実行する

新アカウントへの復元処理を行なう方法は2つあります。

アカウントリストから

Zimbra管理コンソールの アカウント タブから行なう復元処理の場合、サーバー内に現在存在しているユーザーに対し、処理を行なうことができます。
削除済みユーザーを復元する必要がある場合は、管理拡張機能から復元処理を行なってください。

  • 管理コンソール画面左ウィンドウから アカウント を選択してアカウントリストを表示します。

  • リストが表示されたら復元対象となる(元)アカウントをクリックにて選択します。

  • 上部メニューバーのギアアイコンを押下して 復元 ボタンをクリックします。

  • 復元方法に 新アカウントへの復元 を選択し、新しい(復元先)アカウントの名称をテキストボックスに入力します。GALから新しいアカウントを隠すどうかを選択できます。選択し終わったら、次へ を押下します。

  • 復元の日付を選択します。年月日はミニカレンダーから選択できます。時間はドロップダウンメニューで選択します。分と秒はテキストボックスに入力します。全て設定し終わったら、次へ を押下します。

  • これまで選択・入力した内容がオペレーション概要に表示されていることを確認します。処理が完了した際に通知を送るあて先のメールアドレスを追加で入力できます。ただし、管理者アカウントと操作を開始した管理者にはデフォルトで通知されます。

完了 をクリックすると復元処理が開始します。

CLIから新アカウントへの復元を実行

CLIから新アカウントへの復元を開始するにはdoRestoreOnNewAccountコマンドを使用します。

構文:
   zxsuite backup doRestoreOnNewAccount {source_account} {destination_account} {"dd/MM/yyyy HH:mm:ss"|last} [attr1 value1 [attr2 value2...

パラメーターリスト

名前                       データ型                期待値
source_account(M)          Account Name
destination_account(M)     Account Name/ID
date(M)                    Date                  `dd/MM/yyyy HH:mm:ss`|last
restore_chat_buddies(O)    Boolean               true|false
notifications(O)           Email Address[,..]

(M) == 必須パラメーター, (O) == 任意のパラメーター

使用例:

zxsuite backup dorestoreonnewaccount John NewJohn `28/09/2012 10:15:10`
Johnのアカウントを、新しいアカウントNewJohnに復元します。

削除取り消しによる復元

削除取り消しによる復元とは

削除取り消しによる復元は、Backup NGの復元タイプの一つです。管理者はメールボックスから一定期間内に削除されたアイテムを全て復元して、そのメールボックス内の専用のZimbraフォルダに格納することができます。

機能

削除取り消しによる復元処理は、バックアップデータストアから 削除 フラグ付きアイテムを検索し、検索したアイテムを対象メールボックス内の専用フォルダに復元します。 警告:ユーザーの快適な操作性を目的として、全ての復元済アイテムからIMAP 削除済 フラグを外してZimbraウェブクライアント上に表示しています。

削除取り消しによる復元の実行

管理コンソールから
  • 管理コンソール画面左ウィンドウから アカウント を選択してアカウントリストを表示します。

  • リストが表示されたら復元対象となる(元)アカウントをクリックにて選択します。

  • 上部メニューバーのギアアイコンを押下して 復元 ボタンをクリックします。

  • 復元方法に 削除取り消し を選択し、次へ を押下します。

  • 復元の日付を選択します。年月日はミニカレンダーから選択できます。時間はドロップダウンメニューで選択します。分と秒はテキストボックスに入力します。全て設定し終わったら、次へ を押下します。

  • これまで選択・入力した内容がオペレーション概要に表示されていることを確認します。処理が完了した際に通知を送るあて先のメールアドレスを追加で入力できます。ただし、管理者アカウントと操作を開始した管理者にはデフォルトで通知されます。

  • 完了 をクリックすると復元処理が開始します。

CLIから

CLIから削除取り消しを開始するには doUndelete コマンドを使用します。

構文:
   zxsuite backup doUndelete {account} {"dd/MM/yyyy HH:mm:ss"|first} {"dd/MM/yyyy HH:mm:ss"|last} [attr1 value1 [attr2 value2...

パラメーターリスト

名前                データ型                期待値
account(M)          Account Name
start_date(M)       Date                  `dd/MM/yyyy HH:mm:ss`|first
end_date(M)         Date                  `dd/MM/yyyy HH:mm:ss`|last
notifications(O)    Email Address[,..]

(M) == 必須パラメーター, (O) == 任意のパラメーター

使用例:

zxsuite backup doundelete John `08/10/2012 10:15:00` last
Johnのアカウントで2012/08/10 10:15:00からこれまでに作成され存在している全アイテムについて、削除取り消し処理を実行します。

外部復元

外部復元とは

外部復元は、Backup NGの復元タイプの一つです。

機能

外部復元は、外部のバックアップに格納されているデータ、メタデータ、設定データの全てを現在のZimbraサーバーに追加します。

下記にインポート手順のワークフローを示します。

フェーズ1

  • ''処理の開始'' 通知

  • サーバーバックアップデータの読み込み

  • 空ドメインの作成

  • 必要な提供サービス(COS)の作成(インポート対象アカウントで正常に使用されているもののみ)

  • 空DLの作成

  • 空アカウントの作成

  • 全アカウントの属性の復元

  • 全ドメインの属性の復元

  • 全DLの属性と共有情報の復元

  • ''フェーズ1 フィードバック'' 通知

フェーズ2

  • 全アイテムの復元

フェーズ3

  • 全マウントポイントとデータソースの復元

  • 全体フィードバック込みの ''処理の完了'' 通知

開始前の準備

復元先サーバーのBackup NGが初期化済みの場合、メモリ使用およびI/Oパフォーマンスの向上のため、Real Time Scannerを無効にしてください。

移行に使用するディスクスペースとI/Oのオーバーヘッドの削減のため、インポート中はアドバンストユーザーはZimbraのRedoLogを無効化または調整するという選択肢もあります。

インポート前に現在のプライマリボリュームを圧縮することでディスクスペースを更に削減することも可能です。移行後に圧縮済プライマリボリュームを使用したくない場合は、新しいプライマリボリュームを圧縮なしで作成し、それを 現在の プライマリボリュームとして設定した後、古いボリュームを セカンダリ に切り替えることもできます。この一連の作業はHSM NGモジュールで実施可能です。

外部復元の実行

管理コンソールから
  • バックアップNGタブをクリックします。

  • インポート/エクスポート の下にある インポートバックアップ ボタンをクリックし、インポートウィザードを開きます。

  • インポート元パスをテキストボックスに入力し、次へを押下します。システムはインポート元フォルダに有効なバックアップが入っているかどうか、'zimbra’ユーザーに読み書き権限があるかどうかをチェックします。

  • インポートしたいドメインを選択し、次へを押下します。

  • インポートしたいアカウントを選択し、次へを押下します。

  • これまで選択・入力した内容が全てオペレーション概要に表示されていることを確認します。処理が完了した際に通知を送るあて先のメールアドレスを追加で入力できます。ただし、管理者アカウントと操作を開始した管理者にはデフォルトで通知されます。

CLIから

CLIから外部バックアップを開始するには doExternalRestore コマンドを使用します。

構文:
   zxsuite backup doExternalRestore {source_path} [attr1 value1 [attr2 value2...

パラメーターリスト

名前                          データ型               期待値              初期値
source_path(M)                Path
accounts(O)                   Account Name[,..]                       all
domains(O)                    Domain Name[,..]                        all
filter_deleted(O)             Boolean              true|false         true
skip_system_accounts(O)       Boolean              true|false         true
skip_aliases(O)               Boolean              true|false         false
skip_distribution_lists(O)    Boolean              true|false         false
provisioning_only(O)          Boolean              true|false         false
skip_coses(O)                 Boolean              true|false         false
notifications(O)              Email Address

(M) == 必須パラメーター, (O) == 任意のパラメーター

使用例:

zxsuite backup doexternalrestore /opt/zimbra/backup/restorePath/ accounts john@example.com,jack@example.com domains example.com filter_deleted false skip_system_accounts false
/opt/zimbra/backup/restorePath/にあるバックアップから、全システムアカウントを含むexample.comドメインの復元と、アカウントjohn@example.comおよびアカウントjack@example.comの復元を行ないます。

マルチスレッドによる復元の高速化

concurrent_accounts パラメーターを使用すると同時に複数アカウントの復元ができ、結果的に復元処理を高速化できます。 管理コンソールにこの機能はありません。

同時復元するアカウント数の影響でリソース消費量がすぐに上昇するということはありませんが、リソース量は必要です。このため、同時に復元するアカウント数は少数から始め、お使いのサーバーのパフォーマンス性能を考慮しながら徐々に増加するようにしてください。
使用例:

zxsuite backup doExternalRestore /tmp/external1 domains example0.com,example1.com concurrent_accounts 5

/tmp/external1にあるバックアップからシステムアカウントを除くドメインexample0.comとドメインexample1.com ドメインの復元を5アカウント同時に行ないます。

復元後:メッセージの重複排除

外部復元処理の実行後は、HSM NGモジュールを使用してボリューム全体の重複排除を行なうことを強く推奨します。アカウントを順次インポートする際、従来の自動重複排除機能が十分に処理されない場合があるためです。

削除済みアカウントの復元

削除済みアカウントの復元とは

削除済みアカウント復元処理では、メールボックス削除時点のメールボックスの内容とプリファレンスを新たに作成したアカウントに復元します。

機能

削除済みアカウント復元処理が開始されると、新しいアカウント(復元先アカウント)が作成されます。削除時点で元アカウントに存在していたアイテムはフォルダ構成やそのユーザーのデータも含めて全て、復元先アカウントに再作成されます。 HSMポリシーを適用する のチェックがオンでない限り、復元されたアイテムは全て現在のプライマリストアに登録されます。

新たに作成したアカウントにデータを復元した場合、共有アイテムの整合性は保たれていません。元の共有ルールが、復元先アカウントのIDではなく、元アカウントのIDを参照しているためです。
バックアップNGタブから
  • 管理コンソール画面左ウィンドウからバックアップを選択して、バックアップNG タブを表示します。

  • 上部バーにある 削除済みアカウントの復元 ボタンをクリックします。

  • 復元の日付を選択します。年月日はミニカレンダーから選択できます。時間はドロップダウンメニューで選択します。分と秒はテキストボックスに入力します。全て設定し終わったら、次へ を押下します。

  • リストが表示されたら復元対象となる(元)アカウントをクリックにて選択します。

  • 新しい(復元先)アカウントの名称をテキストボックスに入力します。GALから新しいアカウントを隠すどうかを選択できます。選択し終わったら、次へ を押下します。

  • これまで選択・入力した内容がオペレーション概要に表示されていることを確認します。処理が完了した際に通知を送るあて先のメールアドレスを追加で入力できます。ただし、管理者アカウントと操作を開始した管理者にはデフォルトで通知されます。

  • 完了 をクリックすると復元処理が開始します。

アイテムの復元

アイテムの復元とは

アイテムの復元は、Backup NGの復元タイプの一つです。

機能

単一アイテムをバックアップからそのオーナーアカウントに復元します。どのタイプのアイテムもこの方法で復元することができます。

アイテムの復元の実行

管理拡張機能から

アイテム復元機能は、CLIからのみ使用できます。

CLIから

CLIからアイテムの復元を開始するには doItemRestore コマンドを使用します。

構文:
   zxsuite backup doItemRestore {account_name} {item_id} [attr1 value1 [attr2 value2...

パラメーターリスト

名前                 データ型
account_name(M)      Account Name
item_id(M)           Integer
restore_folder(O)    String

(M) == 必須パラメーター, (O) == 任意のパラメーター

使用例:

zxsuite backup doitemrestore john@example.com 4784
メールボックスjohn@example.comに、アイテム4784を復元します。
itemID取得方法

itemID とはメールボックス内アイテムを特定できる一意のコードであり、アイテム関連 メタデータ の一つです。

ほかの全てのメタデータ同様、該当アカウントの items ディレクトリ内のファイル [backup path]/accounts/[accountID]/items/[last 2 digits of itemID]/[itemID] に格納されています。

例:

アカウント4a217bb3-6861-4c9f-80f8-f345ae2897b5のアイテム2057 の場合、デフォルトのバックアップパスは下記になります。
/opt/zimbra/backup/ng/accounts/4a217bb3-6861-4c9f-80f8-f345ae2897b5/items/57/2057

メタデータは平文テキストファイルに入っているため、 grepfind などのツールを使って内容を検索することができます。ファイル内のメタデータを更に読みやすく表示するにはコマンド zxsuite backup getItem を使用します。

構文:
   zxsuite backup getItem {account} {item} [attr1 value1 [attr2 value2...

パラメーターリスト

名前              データ型             期待値          初期値
account(M)        Account Name/ID
item(M)           Integer
backup_path(O)    Path                                          /opt/zimbra/backup/ng/
dump_blob(O)      Boolean            true|false                 false
date(O)           Date               dd/mm/yyyy hh:mm:ss|all    last

(M) == 必須パラメーター, (O) == 任意のパラメーター

使用例:

zxsuite backup getitem a7300a00-56ec-46c3-9773-c6ef7c4f3636 1
アカウントa7300a00-56ec-46c3-9773-c6ef7c4f3636に紐づくIDが1のアイテムを表示します。

コマンドgetItem の場合、パラメーターが必要です。

構文:
   zxsuite backup getItem {account} {item} [attr1 value1 [attr2 value2...

パラメーターリスト

名前              データ型             期待値          初期値
account(M)        Account Name/ID
item(M)           Integer
backup_path(O)    Path                                          /opt/zimbra/backup/ng/
dump_blob(O)      Boolean            true|false                 false
date(O)           Date               dd/mm/yyyy hh:mm:ss|all    last

(M) == 必須パラメーター, (O) == 任意のパラメーター

使用例:

zxsuite backup getitem a7300a00-56ec-46c3-9773-c6ef7c4f3636 1
アカウントa7300a00-56ec-46c3-9773-c6ef7c4f3636に紐づくID=1のアイテムを表示します。

''実際の''例

ユーザーが、あるアイテムをゴミ箱に入れたとします。

2013-07-18 15:22:01,495 INFO [btpool0-4361://localhost/service/soap/MsgActionRequest [name=user@domain.com;mid=2538;oip=258.236.789.647;ua=zclient/7.2.4_GA_2900;] mailop - moving Message (id=339) to Folder Trash (id=3)

そして、そのゴミ箱を空にしたとします。

2013-07-18 15:25:08,962 INFO [btpool0-4364://localhost/service/soap/FolderActionRequest] [name=user@domain.com;mid=2538;oip=258.236.789.647;ua=zclient/7.2.4_GA_2900;] mailbox - Emptying 9 items from /Trash, removeSubfolders=true.

ユーザーはその後、その削除したアイテムの復元を管理者に依頼します。管理者はそのメールアドレスおよびitemIDを確認し、zimbra ユーザーにて以下を実行することでこのアイテムを復元します。

zxsuite backup doItemRestore user@domain.com 339

Raw Restore

「Raw Restore」のオペレーションはスタンダード、およびブロブなしのバックアップ方法で利用いただける新しいDR用の復元オペレーションです。 復元用のバックアップのインポート方法と異なり、Raw Restoreはもっと深いレベルで稼働し、復元するデータに元のIDを保管し、すべてのメタデータを復元します。

Raw Restore はソースサーバの集中型ストレージ設定を復元します。 この操作により、集中型ストレージに保存したデータが直ちに利用できる状態になります。 なお、ローカルや第三者の独自ボリュームをご利用の場合、アイテムBLOBをプライマリストレージから移動するか、Blobレストアのオペレーションでバックアップから復元することが可能です。

Raw Restore とバックアップのインポートの違いについて

バックアップのインポート Raw Restore

ソースサーバのバージョンを問わず、全 Zimbra バージョンで利用可能

ソースサーバの Zimbra バージョンとパッチレベルに一致する必要があります

設定を復元しません

集中型ストレージの設定を復元します

Blobなしのバックアップパスをサポートしない

Blobなしのバックアップパスで利用するために設計しており、通常のバックアップパスにも利用できます

アイテムBLOBを復元します

アイテムBLOBを復元しません

復元したオブジェクトは新たに作成します

復元したオブジェクトは元のIDを保護します

実際に復元する内容
  • 集中型ストレージの設定

  • ドメイン

  • 提供サービス

  • 配布リスト

  • ユーザー様のメールボックス

  • メールボックスの設定

  • アイテムのメタデータ

実際に復元しない内容
  • アイテムのBlob

Raw Restoreを実施する方法

Raw Restore は zxsuite の CLI ツールでのみ実行することが可能です。

[zimbra@mail ~]$ zxsuite backup doRawRestore
障害復旧を行う

構文:
   zxsuite backup doRawRestore {source_path} [attr1 value1 [attr2 value2...]]


パラメータリスト

パラメータ名             種類                  期待する値         デフォルト値
source_path(M)           ストリング
notifications(O)         メールアドレス[,..]
skipProvisioning(O)      Boolean               true|false         false
deleteWhenConflict(O)    Boolean               true|false         false

(M) == 必要なパラメータ, (O) == 任意パラメータ

使用例:

zxsuite backup doRawRestore /my/backup/path notifications user1@example.com,user2@example.com skipProvisioning false deleteWhenConflict false
上記のコマンドで Raw restoreを実施し、プロビジョンイングを復元せず、同じアイテムの ID のメールボックスがある場合は削除しない。また、完了した際に通知メールを user1@example.com と user2@example.com へ送信します。
この障害復旧オペレーションではBlobの復元が行いませんので、必要におじて doRestoreBlobsを活用ください。

使用するシナリオについて

シングルサーバのインフラを復元する場合

  1. 新規サーバを設定します(Zimbra をインストールし、グローバルとサーバ設定を行います)。

  2. 元サーバと同様なローカル、または第三者の独自ボリュームを手動に作成します。

  3. Raw Restore でドメイン、提供サービスのメールボックス、およびアイテムのメタデータを復元します(この手順が完了するまでメールボックスをアクセスできません)。

  4. 元のバックアップがBlobなしで行えなかった場合、アイテムの BLOB を復元するために、zxsuite backup doRestoreBlobs を全ボリュームに実施します。

マルチサーバ環境で1つのメールボックスノードを復元する場合

  1. 環境に新しいメールボックスノードを追加します。

  2. 元サーバと同様なローカル、または第三者の独自ボリュームを手動に作成します。

  3. skipProvisioning true パラメータで Raw Restore を実行し、アイテムのメタデータを復元します(この手順が完了するまでメールボックスをアクセスできません)。

  4. 元のバックアップがBlobなしで行えなかった場合、アイテムの BLOB を復元するために、zxsuite backup doRestoreBlobs を全ボリュームに実施します。

マルチサーバ環境で複数のメールボックスサーバを復元する場合

  1. 新しい「空状態」の環境を作成します(すべてのサーバと機能を用意し、グローバルとサーバ設定を行います)。

  2. デフォルトの admin, gal, ham, および spam アカウントを削除します。

  3. すべてのメールボックスサーバにて、元サーバと同様なローカル、または第三者の独自ボリュームを手動に作成します。

  4. 最初のメールボックスサーバにて、Raw Restore でドメイン、提供サービスのメールボックス、およびアイテムのメタデータを復元します(この手順が完了するまでメールボックスをアクセスできません)。

  5. 他のメールボックスサーバにて、skipProvisioning true パラメータで Raw Restore を実行し、アイテムのメタデータを復元します。

  6. 手順4と5が完了しましたら、元のバックアップがBlobなしで行えなかった場合、アイテムの BLOB を復元するために、zxsuite backup doRestoreBlobs を全ボリュームに実施します。

ディザスタリカバリ

ディザスタ

悪化要因

下記のうち1つ以上当てはまる場合、発生している問題を ディザスタ として分類します。

  • (/や/opt/zimbra/などの)重要なファイルシステムで1つ以上のハードウェア障害が起きている。

  • 重要なファイルシステムの内容が内部要因もしくは外部要因により、使用できなくなっている(不注意による rm* の使用や外部からの侵入など)。

  • Zimbraサービスをホストしている物理マシンあるいは仮想化インフラに関するハードウェア障害が起きている。

  • ソフトウェアまたはOSのアップデート/アップグレードにおいて重大な障害が起きている。

機会を最小減に抑えるには

ディザスタの発生機会を最小減に抑えるための提案を以下に記します。

  • 重要なファイルシステムは必ず複数のデバイスに保存する(/や/opt/zimbra/やNGのバックアップパス)。

  • サーバーに監視/アラートシステムを導入し、問題を即座に検知できるようにする。

  • 緻密な更新計画・移行計画を立てる。

リカバリ

リカバリ方法

システムのリカバリは2つのステップに分かれます。

  • 基盤システムのリカバリ(OSインストールおよび設定、Zimbraインストールおよび基本設定)。

  • データリカバリ(ドメイン設定、ユーザー設定、提供サービス(COS)、メールボックスの内容を含む使用可能な最新のデータをZimbraサーバーに再インポート)。

リカバリに際し、Backup NGができること

インポートバックアップ 機能を使用すれば、2つ目のステップのリカバリを簡単かつ安全に実現できます。

旧サーバーのバックアップパスをインポート元パスに指定した場合、Zimbraの基本環境を旧サーバーで最後に使用できていたときの状態にまで復元することができます。

これは単にディザスタリカバリで考えられるシナリオの1つでしかありません。より高度なシナリオや技術に関しては、Zimbra Wikiに記載されています。

リカバリ処理
  • 新サーバーにZimbraをインストールし、サーバー設定とグローバル設定を行ないます。

  • 新サーバーにNetwork NGモジュールをインストールします。

  • 旧サーバーのバックアップフォルダを新サーバーにマウントします。これができない場合は使用可能な最新の外部バックアップもしくは最新コピーのいずれかを使用してください。 次のCLIコマンドを使用すると新サーバーで外部復元が始まります。

  • 次のCLIコマンドを使用すると新サーバーで外部復元が始まります。

zxsuite backup doExternalRestore /path/to/the/old/store

  • 外部復元処理はドメイン、アカウント、配布リストを即座に作成します。この、復元の第一段階の終了後(Network NGモジュールの通知を確認してください)すぐに、ユーザーが利用できるようなシステム状態になっています。メールやメールボックス内のほかのアイテムは、この後で復元されることになります。

設定

サーバー設定とグローバル設定はバックアップされますが、復元については自動では行なわれません。Zimbraと上流で統合しているBackup NGの場合、異なるOS/Zimbraバージョン/ネットワーキング/ストレージでセットアップされたサーバーにも制約なくデータを復元できます。ただし、Network NGモジュールの実行が可能な最低限のZimbraバージョンでなければなりません。

旧サーバーの完全なコピーを作成する場合も、旧サーバー設定をコピー後に新しい環境でその設定を調整する場合も、Backup NGの便利なコマンド getServerConfig が使用できます。

zimbra@test:~$ zxsuite backup getServerConfig
command getServerConfig requires more parameters


構文:
   zxsuite backup getServerConfig {standard|customizations} [attr1 value1 [attr2 value2...


パラメーターリスト


名前              データ型             期待値                                 初期値
type(M)           Multiple choice    standard|customizations
date(O)           String             `dd/MM/yyyy HH:mm:ss`|"last"|"all"
backup_path(O)    Path                                                     /opt/zimbra/backup/ng/
file(O)           String             Path to backup file
query(O)          String             section/id/key
verbose(O)        String                                                   false
colors(O)         String                                                   false


(M) == 必須パラメーター, (O) == 任意のパラメーター


使用例:


zxsuite backup getserverconfig standard date last
サーバー設定とグローバル設定の最新のバックアップデータを表示します。
zxsuite backup getserverconfig standard file /path/to/backup/file
現在のサーバーバックアップの代わりにバックアップファイルの内容を表示します。
zxsuite backup getserverconfig standard date last query zimlets/com_zimbra_ymemoticons colors true verbose true
com_zimbra_ymemoticons zimletの全設定を色鮮やかな出力でわかりやすく表示します。

なお、下記にて最新のバックアップ設定が表示されます。

zxsuite backup getServerConfig standard backup_path /your/backup/path/ date last query / | less

引数 query を変更することで、特定の設定を表示させることができます。以下、例。

zimbra@test:~$ zxsuite backup getServerConfig standard date last backup_path /opt/zimbra/backup/ng/ query serverConfig/zimbraMailMode/test.domain.com


config date_______________________________________________________________________________________________28/02/2014 04:01:14 CET
test.domain.com____________________________________________________________________________________________________________both

ディレクトリ {zimbrahome}/conf/ と {zimbrahome}/postfix/conf/ もバックアップされます。

zimbra@test:~$ zxsuite backup getServerConfig customizations date last verbose true
ATTENTION: These files contain the directories {zimbraHome}/conf/ and {zimbraHome}/postfix/conf/ compressed into a single archive.
           Restore can only be performed manually. Do it only if you know what you're doing.




        archives


                filename                                                    customizations_28_02_14#04_01_14.tar.gz
                path                                                        /opt/zimbra/backup/ng/server/
                modify date                                                 28/02/2014 04:01:14 CET

VMとスナップショット

近年急速な進化を遂げた仮想化によるソリューションの到来により、ZCSのようなサーバーソリューションの配備に今や最もよく利用されている手法がVM(仮想マシン)です。

ほとんどのハイパーバーザーに、カスタマイズ可能なスナップショット機能とスナップショットベースのVMバックアップシステムが備わっています。 ディザスタの際は、Backup NGの 外部復元 機能にてサーバーのバックアップパスをインポート元パスに指定することで、最新のスナップショットへのロールバックおよび失ったデータのインポートを行なうことが可能です。

前回のVM状態からディザスタリカバリを行なう

スナップショットベースのVMバックアップシステムでは、有効状態にあるVMを 凍結した コピーの保持とその状態へのロールバックが可能です。データ整合性を確実に100%にするには電源オフ状態にあるVMのスナップショットコピーを取得することが望ましいですが、必須ではありません。

こうしたシステムを利用してロールバック時に失ったデータをインポートするには、バックアップパスがスナップショットの一部でないこと(例:VMWare ESX/iでvdiskをIndependent Persistentに設定することで発生)、変更されないことが必須の条件です。

Backup NGを使用して以前のマシン状態からディザスタリカバリを行なうには、下記を実施する必要があります。

  • ユーザーからのアクセスも送受信メールの配信もない、孤立したネットワーク上の別の(クローン)VMに、使用可能な最新のバックアップを復元します。

  • クローンの電源をオンにし、Zimbraの開始を待ちます。

  • Backup NGのReal Time Scannerを無効にします。

  • 改ざんされていないバックアップパスが入った仮想ディスクにそのクローンを接続、(別のパスに)リンクさせます。

  • バックアップパスをインポート元パスに指定し、外部復元処理を開始します。

上記によりディザスタリカバリが迅速に行なわれ、バックアップパス内の全アイテムの解析および失ったアイテムのインポートが実行されます。この手順は必要に応じて何度も繰り返すことが可能ですが、この実行中はユーザーからのアクセスもメール配信も停止します。

復元が完了したら、どの機能も問題なく利用できること、ユーザーからのアクセスおよびメール配信が復元されることを確認してください。

その後

他にすべきこと

万が一、ディザスタよりも前のコンテンツを復元する必要がある場合は、新しいバックアップパスを初期化し、その古いコンテンツをそこに格納してください。

復元できないアイテム

全アイテムが復元されているかどうかをチェックする方法

チェックはとても簡単です。復元処理が完了したあと適切に 処理完了 通知を受けとっていることを確認するだけです。管理拡張機能の 通知 タブでもこの内容を確認できます。なお、管理拡張機能の コア セクションに Notification E-Mail recipient address(メールで通知するアドレス) として指定したメールアドレス宛にも通知メールは送信されます。通知タブのskipped itemsセクションには復元されていないアイテム一覧がアカウントごとに記載されます。

通知タブの skipped items セクションには復元されていないアイテム一覧がアカウントごとに記載されます。

  [...]
  - stats -
  Restored Items: 15233
  Skipped Items:  125
  Unrestored Items: 10

  - unrestored items -
  account: account1@domain.com
  unrestored items: 1255,1369

  account: account2@domain.com
  unrestored items: 49965

  account: account14@domain.com
  unrestored items: 856,13339,45200, 45655
  [...]
Skipped Items と Unrestored Items
  • Skipped item (スキップされたアイテム): 現在の復元処理あるいは以前の復元処理で、すでに復元されているアイテムです。

  • Unrestored item(復元されていないアイテム): 復元処理中の問題により、復元されなかったアイテムです。

アイテムが復元されなかった理由

様々な要因が考えられますが、よくある理由は以下のとおりです。

  • 読み込みエラー: I/O例外または権限問題のため、アイテムの生データまたはメタデータファイルが読み込めない。

  • 壊れたアイテム: アイテムの生データまたはメタデータファイルの読み込みはできるが、内容が壊れている。

  • 無効なアイテム: アイテムの生データまたはメタデータファイルの読み込みができ、内容も正常だが、Zimbraがこのアイテムの登録を拒否する。

復元されていないアイテムの見分け方

見分ける方法は2つあります。1つはCLIから、もう1つはZimbraウェブクライアントからです。前者はバックアップ/インポートパス内のアイテム検索に有用です。後者は対象サーバー内アイテムの閲覧に使用できます。

復元できないアイテムをCLIから見分ける

CLIの getItem コマンドを使って、バックアップパス/外部バックアップから全情報を抽出し、アイテムとその関連メタデータを表示することができます。

このコマンドの構文は下記のとおりです。

   zxsuite backup getItem {account} {item} [attr1 value1 [attr2 value2...

パラメーターリスト

名前               データ型             期待値                     初期値
account(M)        Account Name/ID
item(M)           Integer
backup_path(O)    Path                                          /opt/zimbra/backup/ng/
dump_blob(O)      Boolean            true|false                 false
date(O)           Date               dd/mm/yyyy hh:mm:ss|all    last

(M) == 必須パラメーター, (O) == 任意のパラメーター

account2@domain.com に紐づくitemID= 49965 のアイテムの生データとメタデータ情報をBLOBの全ダンプも込みで抽出するコマンドは、以下になります。

zxsuite backup getItem account2@domain.com 49965 dump_blob true

復元できないアイテムをZimbraウェブクライアントから見分ける

処理完了 の通知にあるunrestored items (復元されていないアイテム) のカンマ区切りの一覧は、Zimbra ウェブクライアントからアイテム検索を行なう際の検索引数に流用できます。

以下、その手順です。

  • 対象サーバーのZimbra管理コンソールにログインします。

  • メールを表示 機能を使って、復元されていないアイテムが存在するアカウントにアクセスします。

  • 検索ボックスに、item: の後に続けて、itemIDのカンマ区切りの一覧を入力します。


item: 856,13339,45200,45655

検索は検索を実施したタブ内でのみ機能します。このため メール タブの検索結果が0件だった場合、 連絡先 タブ、 カレンダー タブ、 タスク タブ、 ブリーフケース タブでも同様に検索してみてください。

復元されていないアイテムを復元する方法

復元されていないアイテムは、そのアイテム自体あるいは現Zimbraのセットアップに問題があることをはっきりと示すサインです。もし1度復元に失敗していたとしても、アイテムを復元できる可能性はあります。

次の項では、復元できないアイテムに対処する際に役立つヒントをいくつか紹介します。

読み込みエラーのために復元できないアイテムの場合

アイテムの復元が不可能となりうる読み込みエラーの場合、下記にて明確に区別してください。

  • ハード エラー: 復元不可能なデータ損失の要因となるハードエラー障害およびその他の 壊滅的な エラー。

  • ソフト エラー: 権限誤りやファイルシステムエラー、RAID問題(例:壊れたRAID1ミラーリング)など、壊滅的ではない エラー。

ハードエラーの場合、ほぼ対処のしようがありませんが、ソフトエラーの場合は次のガイドに沿って、回避または緩和することが可能です。

  • システムファイルチェックを実行。

  • RAIDディスクセットアップを使用中の場合、(RAIDレベルに合わせて)起こりうる問題をひととおりチェック。

  • バックアップ/インポートパス、そのサブフォルダ、フォルダ内のファイル全てにに対し、zimbraユーザーに読み書き権限があること。

  • ネットワーク共有をしているファイルシステムのリンク品質をチェック。品質が低い場合、rsyncを使用したデータ転送を行なうことを検討してください。

  • バックアップ・インポートパスのリモートでのマウントにSSHfsを使用している場合、マウントのコマンドをrootで実行していること、そして -o allow_other オプションを使用していることを確認してください。

壊れたアイテムとして判別されたために復元できないアイテムの場合

復元されていないアイテムのカテゴリーの中で、救済できる可能性 が最も低いカテゴリーです。

アイテムの壊れ具合によっては、前の状態またはオブジェクトの生データに復元できる可能性はあります(メールの場合のみ)。状態の確認に、CLIの getItem コマンドを実行します。

   zxsuite backup getItem {account} {item} [attr1 value1 [attr2 value2...

パラメーターリスト

名前               データ型             期待値                      初期値
account(M)        Account Name/ID
item(M)           Integer
backup_path(O)    Path                                          /opt/zimbra/backup/ng/
dump_blob(O)      Boolean            true|false                 false
date(O)           Date               dd/mm/yyyy hh:mm:ss|all    last

(M) == 必須パラメーター, (O) == 任意のパラメーター

backup_path パラメーターにはインポートパスを、 date パラメーターには all を設定すると、その壊れたアイテム分の使用可能状態が全て表示されます。

zimbra@test:~$ zxsuite backup getItem admin@example.com 24700 backup_path /mnt/import/ date all
       itemStates
               start_date                                                  12/07/2013 16:35:44
               type                                                        message
               deleted                                                     true
               blob path /mnt/import/items/c0/c0,gUlvzQfE21z6YRXJnNkKL85PrRHw0KMQUqo,pMmQ=
               start_date                                                  12/07/2013 17:04:33
               type                                                        message
               deleted                                                     true
               blob path /mnt/import/items/c0/c0,gUlvzQfE21z6YRXJnNkKL85PrRHw0KMQUqo,pMmQ=
               start_date                                                  15/07/2013 10:03:26
               type                                                        message
               deleted                                                     true
               blob path /mnt/import/items/c0/c0,gUlvzQfE21z6YRXJnNkKL85PrRHw0KMQUqo,pMmQ=

アイテムがメールであれば、次の手順で標準の.eml形式のファイルに復元することができます。

  • 最新の有効な状態を表します。

/mnt/import/items/c0/c0,gUlvzQfE21z6YRXJnNkKL85PrRHw0KMQUqo,pMmQ=
              start_date                                                  15/07/2013 10:03:26
              type                                                        message
              deleted                                                     true
              blob path /mnt/import/items/c0/c0,gUlvzQfE21z6YRXJnNkKL85PrRHw0KMQUqo,pMmQ=
  • blob path を表します。

blob path /mnt/import/items/c0/c0,gUlvzQfE21z6YRXJnNkKL85PrRHw0KMQUqo,pMmQ=

  • gzipを使ってBLOBファイルを.eml形式のファイルに解凍します。

zimbra@test:~$ gunzip -c /mnt/import/items/c0/c0,gUlvzQfE21z6YRXJnNkKL85PrRHw0KMQUqo,pMmQ= > /tmp/restored.eml

zimbra@test:~$ cat /tmp/restored.eml

Return-Path: zimbra@test.example.com

Received: from test.example.com (LHLO test.example.com) (192.168.1.123)
by test.example.com with LMTP; Fri, 12 Jul 2013 16:35:43 +0200 (CEST)

Received: by test.example.com (Postfix, from userid 1001) id 4F34A120CC4;
Fri, 12 Jul 2013 16:35:43 +0200 (CEST)
To: admin@example.com
From: admin@example.com
Subject: Service mailboxd started on test.example.com
Message-Id: <20130712143543.4F34A120CC4@test.example.com>
Date: Fri, 12 Jul 2013 16:35:43 +0200 (CEST)

Jul 12 16:35:42 test zmconfigd[14198]: Service status change: test.example.com mailboxd changed from stopped to running
  • 完了です。これ以後はお好きなクライアントを使用して、該当のメールボックスにこのeml形式のファイルをインポートします。

無効なアイテムとして判別されたために復元できないアイテムの場合

無効 なアイテムとして判別されたために復元できないアイテムの場合 形式上問題はないのにZimbra LMTP Validatorにより登録拒否されるのが、無効なアイテムとして判別されたアイテムです。これは、Zimbraの旧バージョンで作成したアイテムをそれよりも新しいバージョンにインポートする際によく起こります。非常に頻繁に検証のルールが更新されるため、Zimbraのある特定のバージョンで有効だと判別されたメッセージであっても、それより新しいバージョンでも有効と判断されるとは限りません。

インポート中に復元できなかったアイテムが大量発生した場合、一時的にLMTP Validatorを無効にしてから再度インポートすることを検討してもよいかもしれません。これは次のように実施します。

  • ZimbraのLMTP Validatorを無効にするにはzimbraユーザーで下記コマンドを実行します。

zmlocalconfig -e zimbra_lmtp_validate_messages=false

  • インポートが完了したら、LMTP Validatorの実行を有効にします。

zmlocalconfig -e zimbra_lmtp_validate_messages=true

これは苦肉の策です。LMTP validatorに無効と判断されたアイテムは、表示やモバイルシンクのエラー要因となりうるため、自身の責任の範囲内で使用するようにしてください。

doCoherencyCheck

一貫性チェックとは

一貫性チェックは 、SmartScanが実施するチェックよりも更に深くバックアップパスのチェックを行ないます。

SmartScanは 増分 を対象とするため、前回のSmartScan以降に修正されたアイテムのみチェックしますが、一貫性チェックはバックアップパスにあるメタデータおよびBLOBを全てチェックします。

SmartScanは壊れたメタデータやBLOBを検知することを目的とし設計されています。

機能

一貫性チェックは、バックアップパスに存在する全てのメタデータおよびその関連するBLOBの統合性を検証します。つまり、あらゆるエラーを発見できるようにしています。このため、 fixBackup オプションにてチェックを行い、オーファン(孤立している)または壊れたメタデータ/BLOBをバックアップパス内専用ディレクトリに移動します。

一貫性チェックを実施するタイミング

  • 定期的な正常稼動の確認時(3ヶ月ごとまたは半年ごとなど)。

  • システム障害の後。

  • バックアップパスの入っているファイルシステムまたはストレージデバイスに何らかの問題が発生した後。

SmartScanが壊れたアイテム候補を検知した場合、自動で一貫性チェックが開始します。

一貫性チェックはI/O消費が高いため、必ずオフピークの時間帯にのみ実施するようにしてください。

一貫性チェックの実行

管理拡張機能からチェックを開始する場合

管理拡張機能には一貫性チェック機能がありません。

CLIからチェックを開始する場合

CLIから一貫性チェックを開始するには doCoherencyCheck を使用します。

構文:
   zxsuite backup doCoherencyCheck {backup_path} [attr1 value1 [attr2 value2...


パラメーターリスト

名前                 データ型                  期待値             初期値
backup_path(M)      Path
accounts(O)         Account Name/ID[,..]                       all
checkZimbra(O)      Boolean                 true|false         false
fixBackup(O)        Boolean                 true|false         false
notifications(O)    Email Address[,..]

(M) == 必須パラメーター, (O) == 任意のパラメーター

使用例:

zxsuite backup docoherencycheck /opt/zimbra/backup/ng/ accounts jack@exmaple.com,john@exmaple.com
JackとJohnのアカウントについて/opt/zimbra/backup/ng/の一貫性チェックを行ないます。
zxsuite backup docoherencycheck /opt/zimbra/backup/ng/ fixBackup true
/opt/zimbra/backup/ng/の一貫性チェックを行ない、メタデータから参照されていないBlobファイルと壊れたバックアップファイルをバックアップの外へ移動します。
チェック実行状況の確認

実行中のスキャンの状態をCLIから確認するには monitor コマンドを使用します。

構文:
   zxsuite backup monitor {operation_uuid} [attr1 value1 [attr2 value2...


パラメーターリスト

名前                  データ型
operation_uuid(M)    Uiid
operation_host(O)    String

(M) == 必須パラメーター, (O) == 任意のパラメーター

Backup NGデータストアの追加バックアップとオフサイトバックアップ

誰が見張りを見張るのか。

バックアップシステムを保持することは、すばらしく安全なデータ損失対策です。一方、できうる限りで最高レベルの信頼性を実現するためには、各バックアップシステムは広義の バックアップ対策 の一部でなければなりません。本当の意味でのバックアップ対策が実施されない場合は見当違いのセキュリティ対策となるため、実際には世界最高のバックアップシステムであっても、別方向から破綻します。

バックアップ対策を練り上げることは容易ではありませんし、ときとして バックアップしたデータを失ったらどうしよう などという疑問の前に、立ちふさがることになります。これを回避できるかどうかは結局、バックアップの作成方法と管理状況次第となります。バックアップデータを全て損失する可能性が高いのは、RAID1+0設定を利用した専用のSAN上にバックアップデータを格納している場合よりも、単一のSATA IIディスクにデータとバックアップの両方を格納している場合と言えるでしょう。

ここでは、Backup NGデータストアのバックアップ作成およびそれをオフサイトへ格納することによるバックアップ対策向上のベストプラクティスを提案します。

Backup NGデータストアの追加バックアップを作成する

  • 原子性: トランザクションが終了した場合にのみ、コミットとディスクへ書き込みが行なわれる。

  • 一貫性: コミットされたトランザクションはすべて有効であり、無効なトランザクションの場合は、コミットもディスクへの書き込みもされない。

  • 独立性: 全てのトランザクションは順次実行され、同一アイテムに対して同時に1つ以上のトランザクションが発生しない。

  • 永続性: 一度コミットされたトランザクションは、 (電源切れやハードウェア障害などの) トラブルがあっても変わらない。

このため、非常に簡単にバックアップを作成できます。最善 (かつ最も容易) な作成方法は、 rsync を使用することです。指定するオプションやパラメーターは様々な要素、例えば同期対象のデータ量や利用中のストレージによって異なりますが、トランスポートにリモートシェルを利用する代わりにrsyncデーモンに接続したほうが、データ転送が著しく高速化します。

Backup NGデータストアの追加バックアップをrsyncで作成するときにZimbraやReal Time Scannerを停止させる必要はありません。またこの同期はいつでも停止可能な上、その後必要に応じて再実行することもできます。

Backup NGデータストアのバックアップをオフサイトに格納する

前項で記載したとおり、Backup NGデータストアのバックアップは簡単に作成できる上、rsyncを利用することで、バックアップをリモート地点にへ容易に格納できます。

こうしたセットアップの際にバックアップ対策を最適にするベストプラクティスを下記のとおり推奨します。

  • rsyncバックアップをスケジューリングする際は、次のrsyncインスタンスまでの間隔を充分にとり、必ず転送が完了するようにしてください。

  • --deleteオプションを使用してください。元サーバーで削除されているファイルがバックアップ先サーバーでも削除されるようになるため不整合を防ぐことができます。

    • --delete オプションを使用したためにかなり時間がかかるようになったと感じた場合は2つのrsyncインスタンスをスケジューリングするようにしてください。1つは --delete オプション付きで週次パージ後に実行されるもの、もう1つはこのオプションを付けないものです。

  • 転送はBackup NGのバックアップパスから開始し、必ずフォルダツリー全体が再帰的に転送されるようにしてください。サーバー設定のバックアップおよびマップファイルも転送対象です。

  • バックアップ先ファイルシステムをcase sensitive(大文字・小文字を区別するよう)にしてください(Backup NGのバックアップパスと同様)。

  • リモート地点から直接、復元しようとしている場合、使用するサーバーのzimbraユーザーには転送対象データに対する読み書き権限があることを確認してください。

  • 転送速度がお使いのストレージのスループットよりもかなり速い場合、処理が遅くなることを想定するようにしてください(逆も同様)。

追加/オフサイトのバックアップに関するFAQ

rsyncの代わりとして、Backup NGの エクスポートバックアップ 機能を使わないほうがよいのはなぜでしょうか。

主な理由を下記に示します。

  • エクスポートバックアップ は移行目的で設計されています。移行の最後で スナップショット をエクスポートするため、増分対応できるようには設計されていません。毎回エクスポートバックアップを実行するたびに、前回実施したときと同じだけの時間がかかりますが、rsyncは時間効率がかなり良いです。

  • Backup NGの処理である以上、エクスポートバックアップ処理の実行中に開始された処理はすべて、エクスポートバックアップが完了するまで、キューに並びます。

  • エクスポートバックアップ 処理は、rsyncよりもシステムリソースへの影響が大きいです。

  • 万が一エクスポートバックアップ処理を停止することになった場合は、スクラッチからスタートする必要があります。再実行はできません。

ディザスタリカバリでオフサイトバックアップを使用してもよいですか?

はい。ただし、バックアップパスがまだ利用可能な状態であれば、バックアップパスを使用するほうが好ましいです。アイテムと設定の全てが、利用できる最新の状態に復元されるためです。ただし、もしバックアップパスが損なわれているようであれば、追加/オフサイトバックアップを使用することができます。

バックアップコピーが入っているサーバー上で復元に使用してもよいですか?

はい。ただし、外部復元 処理では実行しないでください。アイテムやフォルダ名が同一であるためです。

バックアップパスのコピーから非常に類似しているサーバーへデータ復元する最適な手順は下記のとおりです。

  • Real Time Scannerを停止。

  • バックアップパスを、データ復元に使用したいコピーに変更。

  • 新アカウントへの復元処理 または 削除済みアカウントの復元処理 のいずれかを実行。

  • 復元処理が完了したら、バックアップパスを元に戻す。

  • Real Time Scannerを開始。SmartScanがバックアップデータ更新をトリガー。

Active-Standbyインフラの作成に使用してもよいですか?

よくありません。外部復元処理 では削除が一切行なわれないためです。外部復元処理を何回か実行すると、メールボックスは不要な内容でいっぱいになります。元のメールボックスでは削除されているアイテムでも、スタンバイ サーバー では削除されないためです。

外部復元処理 は、その処理が始まると同時にアカウントが利用できるように設計されています。このため復元中も、メールの送受信が可能です。

システムの追加/オフサイトバックアップを行なう方法は他にありますか?

もちろんあります。本書で紹介したよりも良好な方法もあることでしょう。ここでは主なケースに当てはまるガイドを記載するに留めています。

マルチストア関連情報

マルチストア環境におけるBackup NG

マルチストア環境でのコマンド実行

新しいNetwork管理拡張機能では、簡単なマルチサーバー管理を実現できます。あるサーバーのZimbra管理コンソールにログインしてバックアップNGタブから別のサーバーを選択し、その別サーバーのバックアップ処理を全て実行することが可能です。

別サーバーのバックアップ処理を全て実行することが可能です。

  • マルチストア環境の場合、新アカウントへの復元処理 では、必ずその元のアカウントのメールボックスサーバー内に新しいアカウントが作成されます。

  • 全ての処理においてそのログは、処理を開始させたサーバーではなく、対象サーバー内に記録されます。

  • 処理を行なう対象サーバーを間違えて選択した場合、Zimbraが自動で正しいサーバーにその処理のリクエストを移します。

バックアップと復元

マルチストア環境でのバックアップと復元は、シングルストア環境と全く同等に機能します。

管理拡張機能から別々に多様なサーバーを設定・管理することになりますが、特定の処理、例えばライブでのフルスキャンや全てのオペレーションの停止は、 zxsuite CLI の --hostname all_servers オプションを使用して、全メールストアに“拡める”ことができます。このことはBackup NGの設定にもあてはまります(詳細はWikiページのCLIを参照してください)。

バックアップ処理と復元処理は下記のように管理されます。

  • SmartScanは、管理拡張機能からはシングルサーバーに対して、CLIからは複数サーバーに対して実行可能です。

  • 復元は、Zimbra管理コンソールの アカウント タブ、管理拡張機能のBackup NGメニューの各サーバータブ、CLIから開始可能です。方法による相違点は下記のとおりです。

処理実施箇所: オプション

アカウントタブ

選択したアカウントの復元を、該当サーバー内で自動で開始します。

サーバータブ

選択したサーバーを復元させる権限のあるアカウントであれば、復元「元」に指定できます。

CLI

どのサーバーのどのアカウントも復元可能ですが、サーバーが自動選択されることはありません

エクスポートとインポート

マルチストア環境で実行される際に最も違いのある機能はエクスポートとインポートです。

基本的なシナリオを以下、記します。

シングルストアからエクスポートし、マルチストアへインポートする

シングルドメインの複数アカウントを別のストアへインポートすると、他のサーバー内メールボックスと共有中のアイテムとの整合性が全て失われます。

CLIからコマンドを利用して、別のサーバーへインポートしたアカウント分の共有を修正することができます。

マルチストアからエクスポートし、シングルストアまたはマルチストアへインポートする

ここでは2通りのシナリオを紹介します。

  • ミラー インポート: インポート元とインポート先のメールストア数が同一、かつ、各エクスポートが別のシングルサーバーにインポートされる場合。他のサーバー内メールボックスと共有中のアイテムとの整合性が全て失われます。CLI コマンド doCheckSharesdoFixShares を利用して、共有の整合性のチェックと修正が可能です(下記コマンドを参照ください)。

  • 混合 インポート: インポート元とインポート先のサーバー数が同一もしくは異なる。そして、ドメインあるいはアカウントがマニュアル操作により別のマルチサーバーにインポートされる場合。他のサーバー内メールボックスと共有中のアイテムのと整合性が全て失われます。CLI コマンド doCheckSharesdoFixShares を使用して、共有の整合性をチェック・修正することができます(下記コマンドを参照ください)。

コマンド doCheckSharesdoFixShares

doCheckShares は、ローカルアカウントにある全ての共有情報を解析して、エラーがあればレポートします。

zimbra@test:~$ zxsuite help backup doCheckShares

構文:
   zxsuite backup doCheckShares


使用例:

zxsuite backup doCheckShares
Check all shares on local accounts

doFixShares は、移行により全ての共有情報の不整合を修正します。

zimbra@test:~$ zxsuite help backup doFixShares

構文:
   zxsuite backup doFixShares {import_idmap_file}


パラメーターリスト

名前                     データ型
import_idmap_file(M)    String

(M) == 必須パラメーター, (O) == 任意のパラメーター

使用例:

zxsuite backup doFixShares idmap_file
Fixes the shares' consistency after an import according to the
mapping contained in the /opt/zimbra/backup/ng/idmap_file

処理キューとキュー管理

Backup NGの処理キュー

Backup NGの各処理は開始後、FIFOキューに並びます。スケジュールとマニュアル操作のどちらからでも平等です。ある処理が(完了または終了により)キューから外れるとすぐその次の処理が実行されます。

次の処理はキューシステムの影響を受けます。

  • 外部バックアップ

  • 全ての復元処理

  • Smartscan

Backup NGの設定に対する変更は、キューには入らず即座に適用されます。

処理キューの管理

管理コンソールから
キューを表示する

処理キューを表示するには、管理拡張機能の 通知 タブへ遷移し、 オペレーションキュー ボタンをクリックします。

管理拡張機能ではBackup NGとHSM NG両方の処理キューを1つのビューに表示しています。これは単に設計上のものであり、この2つのキューは独立しています。すなわち、Backup NGの処理とHSM NGの処理が同時に実行していることもあります。
キューを空にする

現行処理を停止してBackup NGの処理キューを空にするには、管理拡張機能の バックアップNG タブにある、全てのBackupオペレーションを停止 ボタンをクリックします。

CLIから
キューを表示する

Backup NGの処理キューを表示させるには、コマンド getAllOperations を使用します。

zimbra@server:~$ zxsuite help backup getAllOperations

構文:
   zxsuite backup getAllOperations [attr1 value1 [attr2 value2...


パラメーターリスト

名前           データ型     期待値             初期値
verbose(O)    Boolean    true|false         false

(M) == 必須パラメーター, (O) == 任意のパラメーター

使用例:

zxsuite backup getAllOperations
実行中またはキューにある処理を全て表示します。
キューを空にする

Backup NGの現行処理を停止してキューを空にするには、コマンド doStopAllOperations を使用します。

zimbra@mail:~$ zxsuite help backup doStopAllOperations

構文:
   zxsuite backup doStopAllOperations


使用例:

zxsuite backup doStopAllOperations
全ての実行中処理を停止します。
キューから処理を1件外す

現行処理を停止、または、キューから特定の処理を外すにはコマンド doStopOperation を使用します。

zimbra@mail:~$ zxsuite help backup doStopOperation

構文:
   zxsuite backup doStopOperation {operation_uuid}


パラメーターリスト

名前                  データ型
operation_uuid(M)    Uiid

(M) == 必須パラメーター, (O) == 任意のパラメーター

使用例:

zxsuite backup doStopOperation 30ed9eb9-eb28-4ca6-b65e-9940654b8601
ID=30ed9eb9-eb28-4ca6-b65e-9940654b8601の処理を停止します。

提供サービス (COS) レベルのバックアップ管理

提供サービスレベルのバックアップ管理とは

提供サービスレベルのバックアップ管理では、ストレージ利用を抑える目的で、提供サービス(COS)全体に対するBackup NG機能を全て、無効にすることができます。

提供サービス(COS)レベルのバックアップ管理機能

提供サービスに対するBackup NGモジュールを無効にするとどうなるか
  • COS内のアカウントは全て、Real Time Scannerの対象外になります。

  • TCOS内のアカウントが、エクスポートバックアップ機能でエクスポート対象となることはありません。

  • COS内のアカウントは、バックアップシステムでは 削除済み として扱われることになります。つまり、データ保持期限が過ぎたら、こうしたアカウントにおける全データが、バックアップストアからパージされることになります。提供サービスに対するバックアップを再度有効化すると、これはリセットされます。

バックアップが有効か無効か に関する情報の保存方法

提供サービスに対するバックアップを無効にすると、提供サービスの 備考 項目に ${ZxBackup_Disabled} という指標が加わります。

備考項目が編集可かつ利用可である限り、この指標を変更または削除すれば、提供サービスに対するバックアップを再び有効にすることができます。

BackupNGを利用した増分移行

概要説明

  • 本書では、Backup NGを利用した増分移行の実施方法を説明します。

  • 商用環境の移行向けに特化して設計しています。また、その際に、システム停止時間を最短化することと、ユーザーにとって透過性のあるものを目指して設計しています。

  • 正しく計画し、正しく実行された場合は、システム停止に陥ることはありません。また、ユーザーへの影響も限りなくゼロに近づきます。

  • 本書に記載のCLIコマンドは特に記載がない限り、すべてzimbraユーザーで実行する必要があります。

移行対象

  • メールとメールフォルダ

  • 連絡先と連絡先リスト

  • 予定とカレンダー

  • タスクとタスクリスト

  • ファイルとブリーフケース

  • 共有情報

  • ユーザーのプリファレンス

  • ユーザー設定

  • 提供サービス(COS)の設定

  • ドメイン設定

移行対象外

  • サーバー設定(参照用に移行されますが復元はされません)

  • グローバル設定(参照用に移行されますが復元はされません)

  • カスタマイズ内容(Postfix, Jetty等)

  • 処理中に移動または削除されたアイテムは、移行先サーバーにて移動も削除もされません。

  • 処理中に変更されたプリファレンス(パスワード等)は、各インポートでリセットされます。

増分移行は、サーバーtoサーバーのミラーリングをセットアップするためには設計されていません。元サーバーをミラーしたコピーを複数インポートにて作成しても、ミラーしたコピー は作成されません。インポート処理では削除が一切行なわれないからです。

移行前チェック

サーバー
  • 移行元サーバー:Backup NGまたはZimbra Suite Plusが起動しているZimbraサーバーであれば、移行元とすることができます。

  • 移行先サーバー:Backup NGまたはZimbra Suite Plusが起動しているZimbraサーバーであれば、移行先とすることができます。

ストレージ
  • 移行元サーバー:移行元サーバー上でBackup NGが現在有効でない場合、/opt/zimbra/store/ のフォルダサイズと 同等の 、空ディスク容量があることを確認してください(通常、エクスポートされるサイズはオリジナルのサイズの70パーセントまで削減されます。エクスポートされるデータはgzipアルゴリズムを使って圧縮され、また、全てのzimbraアイテムは重複排除されれるためです)。

  • 移行先サーバー: /opt/zimbra/store/ のフォルダサイズと、移行元サーバーにある エクスポート フォルダサイズを合算したサイズよりも大きな空ディスク容量があることを確認してください。

データ転送

データの転送方法は様々ですが、rsyncによる手段を推奨します。速度と利便性の観点で妥当であるためです。

主要なデータ転送は、まだ移行元サーバーが稼働中かつ機能している間に行なわれます。ただし、転送はネットワーク経由で実行されるため、事前に緻密な転送計画を作成してください。そうすることで、移行前に 全データ を転送しておくことができます。

データ転送の代替案

要求に沿うのであれば、リモートマウントからドライブの物理的な移動まで、転送手段は何でもかまいません。

Never underestimate the bandwidth of a station wagon full of tapes hurtling down the highway.
--Tanenbaum, Andrew S. (1996). Computer Networks. New Jersey: Prentice-Hall. p. 83. ISBN 0-13-349945-6.

DNS

実際の DNS上のMXレコードのTTLの値を300に設定してください。移行元サーバーと移行先サーバー間の切り替えが早くなります。

セットアップ

手順1:一貫性チェック

データ関連の問題が発生しないように、移行元サーバーにて下記チェックを実行してください。

エラーが見つかった場合は修正してください。

全てのメールボックスを再インデックス化することも推奨します。

手順2:Network NGモジュールのセットアップ

両サーバーともに下記を実行して、Real Time Scannerを無効にしてください。

zxsuite backup setProperty ZxBackup_RealTimeScanner false
データエクスポートには、専用のデバイスを使用することを強く推奨します。エクスポートのパフォーマンスを向上させるためと、稼働中のシステムのパフォーマンスに対する影響を抑えるためです。

デバイスを、パス /opt/zimbra/backup/ にリンクさせてください。zimbraユーザーにはこのパスに対する読み書き権限がなければなりません。

手順3:データのエクスポート (SmartScan)

移行元サーバー上で下記を実行して、SmartScanを実行してください。

zxsuite backup doSmartScan

全データがデフォルトのバックアップパス (/opt/zimbra/backup/ng/) にエクスポートされることになります。

虎の巻:単一ドメインのエクスポート

全てのドメインを移行するのではなく、1つまたは複数のドメインだけを移行することもできます。その場合は、SmartScanの 代わりに、次のコマンドを実行します。

zxsuite backup doExport /path/to/export/folder/ domains yourdomain.com,yourdomain2.com[..]

留意すべきこととして、SmartScan での方法で開始した場合は、移行中ずっとその方法で貫かなければなりません。そしてもし、単一ドメイン での方法で開始した場合は、移行中ずっとその方法で貫く必要があります。この2つの方法は混在させられません。

管理拡張機能からデータのエクスポート (SmartScan)

管理拡張機能からデータのエクスポートを行なうこともできます。

手順4:データの同期

エクスポートしたデータを移行先サーバーへ移動するとき、移行先サーバーにある移動先フォルダが、Backup NGのバックアップパスでないことを確認してください。移行先サーバーでBackup NGをすでに使用中、または使用予定がある場合、障害の要因になりかねません。

(rsync以外の方法でデータ転送を行なう場合は、この手順を飛ばしてかまいません)

rsync を使って、/opt/zimbra/backup/ng/に格納されているデータを、移行先サーバーにあるディレクトリへとコピーしてください (対象フォルダに対する読み書き権限がzimbraユーザーにあることを確認してください) 。 screentmux などのターミナルマルチプレクサを使用してください。この処理は、ネットワーク速度や対象データの量によっては、かなりの長時間がかかるかもしれません。

[以下コマンドをRootで実行します]
rsync -avH /opt/zimbra/backup/ng/ root@desinationserver:/path/for/the/data/
その他同期方法

提案した方法は、帯域幅の広い環境の場合に最良であるものの、最初の同期には、大量のデータが対象となりえます。Rsyncでの方法が遅いと感じる場合には、デバイス (もしくは仮想環境で実行中であればそのおおもとのディスクファイル) の物理的な移動を検討することになるかもしれません。

ディスクを移動した後、リモートで、移行元サーバーへリンクを戻すことができます (例えば、SSHFS) 。なぜなら移行時に行なわれる、追加の同期では、比較にならないほど少量のデータが対象となるからです。また、この場合は、移行元サーバー上のデバイスを/opt/zimbra/backup/ng/として再リンクさせ、そこに、全ての必要な権限を付与しておいてください。

手順5:初回インポート

エクスポートしたデータ全てを移行先サーバーへインポートします。

zxsuite backup doExternalRestore /path/for/the/data/

Network NGが移行先サーバーへデータをインポートします。

''注意: この手順後は、編集も削除もしないこと''

管理拡張機能からの初回インポート

管理拡張機能を使用してデータのインポートをするという選択肢もあります。管理拡張機能からのインポート中、インポートされているアカウントリストのシステムアカウント (GalSync、Ham、Spam、Quarantineなど) は全て削除されることに留意してください。

手順5(別案):大規模移行時の初回インポート (精通しているユーザーのみ)

ここからは、エクスポート・インポートに何時間もあるいは何日もかかるような巨大インフラの移行を予定している管理者が移行を行なうための別案を紹介します。

全データを移行先サーバーへインポートする代わりに、プロビジョニングのみ のインポートを実行することで、ドメイン、提供サービス、アカウントのみ、移行先サーバーに作成し、メールボックスの全内容を移行対象外とすることができます。

zxsuite backup doExternalRestore /path/for/the/data/ provisioning_only TRUE

上記コマンドを実行後、メールフローを新サーバーへと切り替えます。切り替えが完了したら、実際の インポートを開始します。

zxsuite backup doExternalRestore /path/for/the/data/

システムユーザーの接続先が、移行先サーバーになります。移行先サーバーでは、古いメールの復元中ですが、新しいメールは配信されることになります。

このアプローチにはメリットとデメリットがあります。

メリット

  • アイテムは一度しかインポートされず、その後も修正や削除がされないため、標準の 増分移行に比べると、この方法は不整合を減らすことになります。

  • 移行元サーバーでの影響を抑えるオプションがあります (例:移行元サーバーを急いで閉鎖する場合には都合が良いです) 。

デメリット

  • 処理のタイミングによっては、システムユーザーへの影響が高まります。ユーザーがメールボックスを使用している間も、アイテムは復元中だからです。

  • 稼働中のシステムでインポートを行なうため、速度低下が気になるかもしれません。

これまでの状況

この時点で、ほとんどのデータが移行先サーバーへインポートされました。移行元サーバーはまだ稼働中で、機能しています。これから、実際の移行の準備をします。

移行

手順6:移行前チェック

メールフローを切り替える前に、必ず、移行先サーバーにおける稼動準備が整っていることを確認してください(ファイヤーフォール、DNS設定、セキュリティシステムなど)。

手順7:切り替え

この手順の終わりには、移行先サーバーが稼動し、機能するようになります。

  • 手順3、手順4、手順5を繰り返します(新しいデータのみエクスポート・同期される)。

  • メールフローを新サーバーへ切り替えます。

  • 移行元サーバーにメールが一切届かなくなったら、手順3、手順4、手順5を繰り返します。

移行先サーバーは、現在稼動中で、機能しています。

手順8:移行後のチェック

次のコマンドを実行して、共有の不整合をチェックします。

zxsuite backup doCheckShares

不整合が見つかった場合は次のコマンドを実行します。これにより1つめの引数に使用したインポートマップファイルを解析し、不整合な共有をすべて修正します。

zxsuite backup doFixShares

マップファイルは、移行先サーバーのバックアップパス内にある map_[source_serverID] です。

手順9:Galsync

Zimbra管理コンソールから、インポートした全てのGalSyncアカウントを削除します。その後必要に応じて、インポートした全てのドメインについてGalSyncアカウントを新たに作成します。そして、次のコマンドを使用して、全てのGalSyncアカウントを再同期化します。

zmgsautil forceSync -a galsync.randomstring@domain.com -n [resourcename]

手順10:メッセージの重複排除

移行後はHSM NGモジュールを使って、ボリューム重複排除を実行することを強く推奨します。

今後

  • 新サーバーにあるBackup NGを初期化し、全てのデータに問題がないことを確認します。

増分移行に関するFAQ

Q: 増分移行を行なうには、有効なライセンスが必要でしょうか。

はい。試用版または購入版、いずれかのライセンスが必要です。

Q: 移行対象となるものは何ですか。

サーバー設定を除き、下記を含めた全てが移行対象です。

  • ユーザーのデータ

  • ユーザーのプリファレンス

  • 提供サービスの設定

  • ドメイン設定

Q: 共有は破棄されますか? 既存の共有は全て再設定する必要がありますか?

いいえ、そのようなことありません。

Q: エクスポートデータのサーバー間での転送はどのように行なえばよいでしょうか。

自身の求めているものに沿うのであれば、転送手段は何でもかまいません。何を求めているのか、それだけは整理しておく必要はあります。

迅速なデータ移動をお望みですか? その場合、USBディスクをサーバー間で物理的に移動する手段は適していないかもしれません。

信頼性のおける手段でのデータ移動をお望みですか? その場合、お使いのインターネット回線が不安定なときは、エクスポートフォルダをSSHFS経由で移行先サーバーへリンクさせる手段は適していないかもしれません。

Mobile NG

提供サービス (COS) のMobile NG同期を有効にする

ある提供サービス(COS)全ユーザー分のMobile NGを有効にすると、その提供サービス(COS)の全ユーザーにMobile NGの全モバイル機能の利用権限が付与されます。

ある提供サービス(COS)全ユーザー分のMobile NGを有効にする

管理コンソールから

管理コンソールから、ある提供サービス(COS)全ユーザー分のMobile NGを無効にする方法

  • Zimbra管理コンソールを開きます。

  • 編集したい提供サービス(COS)をダブルクリックします (左側パネル: 設定 → 提供サービス)。

  • モバイルタブをクリックします。

  • この提供サービス(COS)について同期を有効にする チェックボックスをオンにします。

Zimbra CLIから

CLIから、ある提供サービス(COS)全ユーザー分のMobile NGを有効にする方法

  • 'zimbra' ユーザーにて次のコマンドを実行します: zmprov mc COSName zimbraFeatureMobileSyncEnabled TRUE

提供サービス(COS)の全ユーザーに対するMobile NGを無効にする

管理コンソールから

管理コンソールから、ある提供サービス(COS)全ユーザー分のMobile NGを無効にする方法

  • Zimbra管理コンソールを開きます。

  • 編集したい提供サービス(COS)をダブルクリックします (左側パネル: 設定 → 提供サービス) 。

  • モバイルタブをクリックし、この提供サービス(COS)について同期を有効にする チェックボックスをオフにします。

Zimbra CLIから

CLIから、ある提供サービス(COS)全ユーザー分のMobile NGを無効にする方法

  • 'zimbra' ユーザーにて次のコマンドを実行します。: zmprov mc COSName zimbraFeatureMobileSyncEnabled FALSE

設定優先度に関する注意事項

提供サービス(COS)レベルの設定は、ユーザーレベルの設定にオーバーライドされます。

シングルユーザーのMobile NGを有効にする

シングルユーザーのMobile NGを有効にすると、そのシングルユーザーに、Mobile NGの全モバイル機能の利用権限が付与されます。

シングルユーザーのMobile NGを有効にする方法

Zimbra管理コンソールから

管理コンソールから、シングルユーザーのMobile NGを有効にする方法

  • Zimbra管理コンソールを開きます。

  • 編集したいユーザーをダブルクリックします (左側パネル: 管理 → アカウント)。

  • モバイルタブをクリックします。

  • このアカウントに対して同期を有効にする チェックボックスをオンにします。

Zimbra CLIから

Zimbra CLIから、シングルユーザーのMobile NGを有効にする方法

  • 'zimbra' ユーザーにて次のコマンドを実行します。: zmprov ma user@domain.tld zimbraFeatureMobileSyncEnabled TRUE

シングルユーザーのMobile NGを無効にする方法

Zimbra管理コンソールから

管理コンソールから、シングルユーザーのMobile NGを無効にする方法

  • Zimbra管理コンソールを開きます。

  • 編集したいユーザーをダブルクリックします (左側パネル: 管理 → アカウント)。

  • モバイルタブをクリックし、このアカウントに対して同期を有効にする チェックボックスをオフにします。

ZimbraCLIから

Zimbra CLIから、シングルユーザーのMobile NGを無効にする方法

  • 'zimbra’ユーザーにて次のコマンドを実行します: zmprov ma user@domain.tld zimbraFeatureMobileSyncEnabled FALSE

設定の優先度についての注意事項

ユーザーレベルの設定は、提供サービス(COS)レベルの設定にオーバーライドします。

モバイルパスワード機能

モバイルパスワード機能の利用

システム管理者と委任された管理者は モバイルパスワード機能 を使用して、アカウントがExchange ActiveSync認証でのみ使用するパスワードを別途設定することができます。

この機能の主な利点

  • 一度設定すれば記憶する必要もなく、また、他のパスワードポリシーを考える必要もない、安全なパスワード利用が徹底されます。つまり、モバイルデバイスとZimbraとの間で同期のとれているアカウントのモバイルパスワード (各モバイルデバイスに保存済) をZimbraから変更しても、その変更後のパスワードを各モバイルデバイスで再設定し直す必要はありません。

  • デバイス/クライアントに対して、認証されていないアクセスがあった場合、実際のパスワードを表示しないようにします。

Webmail、POP3、IMAP、SMTPからのログインの場合に モバイルパスワード が有効になることはありませんし、モバイルからのログインの場合にアカウント用パスワードが有効になることもありません。

メールボックスにモバイルパスワードを設定する方法

モバイルパスワードの設定は下記のとおり簡単に行なうことができます。

  • Zimbra管理コンソールに入ります。

  • モバイルパスワードを設定するユーザーを選んで右クリックした後、編集 を選択します。

  • ユーザー設定の モバイル タブにある 有効モバイルパスワード チェックボックスをオンにします。

  • パスワードを モバイルパスワード 項目に入力し、再度同じものを モバイルパスワードの確認 項目に入力します。また、ランダムパスワードボタンを生成 をクリックして、ランダムなモバイルパスワードを生成することも可能です。

  • 保存します。

プロビジョニングとしても知られるモバイルデバイスマネジメント

モバイルデバイスマネジメント

モバイルデバイスマネジメント モバイルデバイスマネジメント (MDM。プロビジョニングとしても知られる) により、管理者は1台以上のモバイルデバイスに適用するルールおよびセキュリティ設定をOTAで定義することができます。定義内容はPINポリシーから全デバイスのリモートワイプなどの 一時 コマンド、また、承認された/ブロックされたアプリケーション一覧まで、多岐に渡ります。

これにより管理者は、法人モバイルデバイスの不適切またはリスクの伴う利用をさせないような制限や条件等を効果的に設定することができます。

また、MDMは 私的デバイスの活用 というコーポレートポリシーに役立ちます。セキュリティ侵害のリスクを最小限に抑えながら、ユーザーに個人のモバイルデバイスを法人サーバーへ接続させることができます。

クライアントで利用できるプロビジョニング機能

すべてのクライアント上ですべてのプロビジョニング機能を利用できるわけではありません。 WikipediaにExchange ActiveSyncクライアント同士の比較が掲載されています。

Network NGとMDM

Network NGでは、Exchange ActiveSyncプロトコルバージョン14+を使った高度なMDM機能を実現します。

提供サービス(COS)レベルおよびメールボックスレベルでモバイルポリシーの利用可否を設定できます。 即時一括 またはユーザーベースでのカスタマイズのいずれも両レベルで設定可能です。モバイル タブにあるモバイル管理オプションを使用して各々設定します。

プロビジョニングオプション

利用できるプロビジョニングオプションは次のとおりです。

  • モバイルデバイス管理を有効にする: 現ユーザー/提供サービスについてモバイルポリシーの利用を有効または無効にします。

  • サポートしていないデバイスのアクセスを許可: プロビジョニングをサポートしていないデバイスと同期させることをユーザーに許可します。

  • ポリシーが部分的に有効なデバイスも使用可能: 適用対象ポリシーを1件以上サポートしていないデバイスと同期させることをユーザーに許可します。

デフォルトでは、NG MobileSyncにおいてMDMは無効です。有効にするには、 NetworkモジュールNG → モバイル → 詳細設定より、オプション “モバイルデバイス管理を有効にする” にチェックを入れます。
強制執行ポリシー

モバイルデバイス 一覧の真下にある下記グループの強制執行ポリシーを利用できます。

  • 同期設定: 同期化の日付間隔や条件を設定します。

  • デバイス設定: カメラ、Wi-Fi、リムーバブルストレージ、Bluetoothなどのデバイス利用を有効または無効にします。

  • デバイスセキュリティ設定: パスワードの適用やパスワードに関する最低要件を定義します。

  • デバイスアプリケーション: ブラウザ、POP/IMAPクライアント、署名されていないアプリケーションなど、標準 のデバイスアプリケーションを有効または無効にします。

加えて、下記2つのリストを使ってアプリケーションのホワイトリスト/ブラックリストも管理することができます。

  • 承認されたアプリケーション: 変更された承認アプリケーション一覧

  • ブロックされたアプリケーション: 変更されたブロック対象アプリケーション一覧

モバイルパスワード

モバイルパスワード機能は、概念としては似ていますが、モバイルデバイスマネジメント (MDM) には含まれせん。モバイルパスワード機能は、EASプロトコルの全バージョンで使用可能です。

SyncStates

Mobile NG とSyncState

SyncState (Synchronization Status (同期化状態) の略語) とはサーバーに保存される、サーバー・モバイルデバイス間の同期に関する情報のことです。Mobile NGとデバイス間の接続は、次の手順で確立します。

  • 1. デバイスはローカルフォルダとサーバー内フォルダとの同期をとるため、folderSync処理を要求します。

    ローカルフォルダ1つにつき、1件のSyncKeyを送信します (ただし、デバイスとサーバー間の接続が初めてである場合、0に設定されたSyncKeyが1件のみ送信します) 。   

  • 2. サーバーは存在するフォルダを一覧で返します。

    サーバーはフォルダ1つにつき、1件のSyncKeyを送信します。

  • 3. その後デバイスは対象となる全アイテムの同期をとるため、itemSync処理を要求します。

    サーバーは同期されたアイテムをSyncStateに格納します。

  • 4. itemSync処理の完了後、デバイスは接続を存続させるため、'ping’コマンドを送信します。

    同期されたアカウントに変更がない限り、手順4が繰り返されます。

メールボックスで新しいアイテムが作成されるたび、あるいは既存アイテムが修正されるたびに、サーバーはデバイスにそのことを知らせます。これによりアクティブな接続 (pingコマンドを送信して存続させた接続) が閉じられ、再び手順3と手順4が繰り返されます。

SyncStateは、手順2で保存されたSyncKeyと手順3で保存されたitemIDが組み合わさったものです。一意のuserID/deviceIDペアごとにサーバーに保存されます。

Sync Request (同期要求)

同期要求は、Mobile NGまたはクライアントから開始される実際の同期処理です。1回の同期要求で、前回の要求以降メールボックスで発生した全ての変更がデバイスに同期されます。逆もまた同様です。

次の場合に同期要求が発生します。

  • SyncStateが変わったとき。

  • クライアント側で同期が強制されたとき。

  • 既存の ping の期限が切れてデバイスから新しいpingが送信されたとき(この期限はクライアント側で定義します)。

SyncStateの管理

管理拡張機能から

Mobile NGの管理拡張機能では、下記2つのオプションを使って、同期しているモバイルデバイスのSyncStateを管理します。

  • デバイスリセット: シングルアカウントに対し、デバイスのSyncStateをリセットします。デバイスが次にサーバーに接続したタイミングで全同期が強制実行されます。

  • デバイスをワイプ: 全デバイスのSyncStateおよび履歴をサーバーから削除します。今後モバイルデバイスを使用しない場合、あるいは同じ会社の別の従業員にそのモバイルデバイスを渡す場合に有用な機能です。

CLIから

CLIでは同期しているモバイルデバイスのSyncStateの管理に下記コマンドのいずれかを使用します。

doRemoveDeviceコマンド
構文:
   zxsuite mobile doRemoveDevice {account} {device_id}

パラメーターリスト

名前            データ型
account(M)      Account Name
device_id(M)    String

(M) == 必須パラメーター, (O) == 任意のパラメーター

使用例:

zxsuite mobile doRemoveDevice john@example.com Appl79032X2WA4S
JohnのAppl79032X2WA4SデバイスのSyncStateを削除します。
doResetAccountコマンド
構文:
   zxsuite mobile doResetAccount {account}

パラメーターリスト

名前          データ型
account(M)    Account Name

(M) == 必須パラメーター, (O) == 任意のパラメーター

使用例:

zxsuite mobile doResetAccount john@example.com
Johnのアカウントの全デバイス状態をリセットします。
doResetDeviceコマンド
構文:
   zxsuite mobile doResetDevice {account} [attr1 value1 [attr2 value2...

パラメーターリスト

名前            データ型          初期値
account(M)      Account Name
device_id(O)    String          all

(M) == 必須パラメーター, (O) == 任意のパラメーター

使用例:

zxsuite mobile doResetDevice john@example.com Appl79032X2WA4S
JohnのAppl79032X2WA4Sというデバイスの SyncStateをリセットします。

高度な設定

Mobile NGパフォーマンスチューニング

システムのパフォーマンスにあわせてMobile NGをチューニングすることができます。下記3通りのオプションがあります。

パフォーマンスチューニング設定

使用可能な設定
  • 通知レイテンシ (ZxMobile_NotificationsLatency): サーバー上でイベントが発生してからモバイルデバイスにその通知が届くまでの秒数。

  • インスタント通知を使う (ZxMobile_UseInstantNotficiations): インスタント通知の有効化/無効化。有効な場合、通知レイテンシをオーバーライドします。

  • 最大Pingハートビート (ZxMobile_MaxPingHeartbeat): 'ping’コマンド間の最長間隔。

上記設定は全て管理拡張機能から編集できます。あるいはCLIから setProperty コマンドを使用します。

パフォーマンスチューニング設定を編集する場合

初期値はよくある状況に合わせて設定しておかなくてはなりません。下記問題に1つ以上あてはまる場合は、該当の解決方法を実施するようにしてください。

問題 解決方法

システム負荷が高い

インスタント通知を使うを無効にする

インスタント通知を使うを無効にした後のシステム負荷が高い

通知レイテンシの値を増やす

モバイルユーザーがネットワーク利用が多いと感じている

インスタント通知を使うを無効にし、通知レイテンシの値を調整しながら上げる

デバイスは接続できるが、セッションが頻繁に途切れる

ネットワーク設定に沿いながら最大Pingハートビートを調整する

サーバーtoデバイスのアイテム同期が極めて遅い

通知レイテンシの値を下げ、インスタント通知を使うを有効にする

共有フォルダ

共有フォルダ機能の利用 (モバイル使用)

ユーザーはNetwork NGを使用して、自身がオーナーでないフォルダをモバイルデバイスと同期させることができます。これはExchange ActiveSyncプロトコルから利用できる全タイプのアイテムで可能です。つまりメールフォルダ、共有連絡先リスト、共有カレンダーや共有タスクリストのいずれもモバイルデバイスと同期させることができます。

ご利用中のクライアントによって、モバイルデバイスで実現できる機能が異なる場合があります。

すべてのクライアントがExchange ActiveSyncを利用した連絡先リスト、カレンダー、タスクリストにおける同期を複数サポートしているわけではありません。

共有フォルダをモバイルデバイスと同期させる方法

比較的上流で同期制御を行なえるように、モバイルデバイスと同期する共有フォルダをユーザー自身で選ぶことができます。

フォルダのモバイルシンクを有効にする

次のようにして、共有フォルダのモバイルシンクを有効にします。

  • Zimbraウェブクライアントにログインします。

  • 同期させたい共有フォルダを右クリックします。

  • Folder Sync Settings をドロップダウンメニューから選択します。

  • Enable synchronization for this folder チェックボックスをオンにします。

  • OKを押下します。

この新フォルダはこのアカウントで接続した全モバイルデバイスと同期するようになります。

条件

共有フォルダの同期には以下の条件があります。

  • a full account share(アカウントごと共有) を参照しているマウントポイントを同期させることはできません。

  • 共有フォルダのサブフォルダと同期することはできません。許可した場合にフォルダツリーが不完全になるためです。

  • Exchange ActiveSyncプロトコルは、リソース閲覧のみの概念を想定していません。このため、閲覧のみの共有を同期させることはできません。閲覧のみのフォルダを同期させると、サーバー・クライアント間に深刻な不整合を生み出し、エラーが多発する要因となります。

EASフィルター

EASプロトコルでは、同期に使用されるプロトコルバージョンが初回ハンドシェイク中に定義され、以降変えられることはありません。サーバーが使用可能な全プロトコルバージョンを一覧表示し、クライアントがその一覧から1つ選択します。

EASフィルターという手法で、ユーザーやクライアントのサブセットで使用できるEASバージョンを制限しています。確実に適切なバージョンが使われるようにするためです。

EASフィルターは複数セットアップすることができ、順次、検証されることになります (下記コマンド getAllEASFiltersdoMoveEASFilte を参照してください) 。

EASフィルターの構造

EASフィルターは下記、5つのパートでできています。

  • タイプ: フィルタールールの種類を定義します。

  • パラメーター: フィルターリング用の識別子 (例: デバイスのブランドやメールアドレス)。

  • モード: ソフトウェアが利用可能バージョンに制限をつけるか、固定のバージョン一覧を提示するかを定義します。

  • EASバージョン: フィルターを適用させるプロトコルバージョンが入ります。

  • ブロッキング 真偽値: 現フィルターが正常に一致した場合にその後、他のフィルターを実行するかどうかを定義します。

EASフィルターの管理

EASフィルターは、CLIから以下4つの専用コマンドを利用して管理します。

zxsuite mobile getAllEASFilters

このコマンドで、既存のフィルターすべてを一覧表示します。

出力例:

        filters

                ID                                                          0
                mode                                                        fixed
                rule                                                        [type = or; rules = [[type = contains; rule = outlook/] OR [type = contains; rule = microsoft.outlook]]
                easversions                                                 14.0
                blocking                                                    true

                ID                                                          1
                mode                                                        limit
                rule                                                        [type = contains; rule = samsung]
                easversions                                                 2.5
                blocking                                                    false

                ID                                                          2
                mode                                                        limit
                rule                                                        [type = always]
                easversions                                                 14.1
                blocking                                                    false
zxsuite mobile doAddEASFilter

このコマンドで、新規EASフィルターを登録します。

zxsuite mobile doAddEASFilter

構文:
   zxsuite mobile doAddEASFilter {and|or|regex|contains|account} {text|people@example.com|account=example@ff.com,contains=android} {add|subtract|fixed|limit} {easversions} [attr1 value1 [attr2 value2...]]

パラメーターリスト

名前              データ型               期待値
type(M)           Multiple choice    and|or|regex|contains|account
parameter(M)      String             text|people@example.com|account=example@ff.com,contains=android
mode(M)           Multiple choice    add|subtract|fixed|limit
easversions(M)    String[,..]
blocking(O)       Boolean            true|false

(M) == 必須パラメーター, (O) == 任意のパラメーター

使用例:

zxsuite mobile doAddEASFilter contains android fixed 2.5,12.0,14.1
ユーザーエージェント名に文字列「android」が含まれる場合に適用するプロトコルフィルターをEASバージョンプールを2.5、12.0、14.1に制限して登録します。

zxsuite mobile doAddEASFilter and account=user@example.com,contains=android fixed 14.1 blocking true
user@example.com.の場合のみ、ユーザーエージェント名に文字列「android」含まれる場合に適用するプロトコルフィルターをEASバージョンプールを14.1に制限して登録します。
'ブロッキング'の指令があるため、この後、他のEASフィルターが実行されることはありません。
zxsuite mobile doDeleteEASFilter

このコマンドで、既存のEASフィルターを削除します。

zxsuite mobile doDeleteEASFilter
コマンドdoDeleteEASFilterにはパラメーターが必要です。

構文:
   zxsuite mobile doDeleteEASFilter {id}

パラメーターリスト

名前     データ型
id(M)    Integer

(M) == 必須パラメーター, (O) == 任意のパラメーター

使用例:

zxsuite mobile doDeleteEASFilter 2
ID=2のフィルターを削除します。
フィルター一覧の表示にはコマンドzxsuite mobile getAllEASFiltersを使用します。
zxsuite mobile doMoveEASFilter

このコマンドを使用して、EASフィルターをフィルターキュー内の別の位置に移動させます。

zxsuite mobile doMoveEASFilter
コマンドdoMoveEASFilterにはパラメーターが必要です。

構文:
   zxsuite mobile doMoveEASFilter {from} {to}

パラメーターリスト

名前       データ型
from(M)    Integer
to(M)      Integer

(M) == 必須パラメーター, (O) == 任意のパラメーター

使用例:

zxsuite mobile doMoveEASFilter 0 5
ID=0のフィルターを5の位置へと移動します。
フィルター一覧の表示にはコマンドzxsuite mobile getAllEASFiltersを使用します。

モバイルアカウントロガー

モバイルアカウントロガーとは、ユーザーのEASログ全体を専用ログファイルに出力する専用のロガーで、sync.log とは別の詳細さが備わっています。迅速なトラブルシューティングに役立ちます。

アカウントロガーを作成する際は、次のパラメーターを指定してください。

  • 対象 アカウント

  • ログレベル (詳細度)

  • 専用 ログファイル

  • ロガーの実行中、全デバイスでアカウント同期を適用するための ウィンドウサイズ

アカウントロガーは、mailboxdが停止あるいは再開したときに自動削除され、mailboxdクラッシュ時は、通常継続不可能です。Logファイルに影響はありません。

アカウントロガー管理

アカウントロガーはCLIから下記コマンドを用いて管理します。他の方法はありません。

zxsuite mobile doAddAccountLogger
zxsuite mobile doAddAccountLogger
コマンドdoAddAccountLoggerにはパラメーターが必要です。

構文:
   zxsuite mobile doAddAccountLogger {account} {debug|info|warn|err|crit} {log_file} [attr1 value1 [attr2 value2...]]

パラメーターリスト

名前              データ型               期待値
account(M)        Account Name
log_level(M)      Multiple choice    debug|info|warn|err|crit
log_file(M)       Path
window_size(O)    Integer            a value > 0

(M) == 必須パラメーター, (O) == 任意のパラメーター

使用例:

zxsuite mobile doaddaccountlogger john@example.com info /tmp/john_logger
Johnのアカウント向けinfoのアカウントロガーを/tmp/john_loggerファイル配下に作成します。

zxsuite mobile doaddaccountlogger john@example.com info /tmp/john_logger window_size 1
ウィンドウサイズを1に設定した、Johnのアカウント向けinfoのアカウントロガーを/tmp/john_loggerファイル配下に作成します。
zxsuite mobile doRemoveLogger
zxsuite mobile doRemoveLogger
コマンドdoRemoveLoggerにはパラメーターが必要です。

構文:
   zxsuite mobile doRemoveLogger {logger_id|"all_loggers"}

パラメーターリスト

名前            データ型               期待値
logger_id(M)    Multiple choice    logger_id|"all_loggers"

(M) == 必須パラメーター, (O) == 任意のパラメーター

使用例:

zxsuite mobile doremovelogger 5
ID = 5のアカウントロガーを削除します。
zxsuite mobile getAccountLoggers

出力例:

zxsuite mobile getAccountLoggers

        loggers

                id                                                          7
                level                                                       DEBUG
                name                                                        AccountLogger
                description                                                 Logging account user@domain.com using level debug, log file /tmp/user.log
                remove command                                              zxsuite mobile doRemoveLogger 7

HSM NG

階層型データストレージ管理

階層型データストレージ管理の技術

HSMとは、定義されたポリシーに従って複数ストア間でデータを移動させるという、データストレージの技術です。

このHSM技術の主な利用方法は、 比較的古い データを高速で高価なストレージデバイスから低速で安価なストレージデバイスに移動することであり、下記が前提となっています。

  • 高速ストレージはコストがかかる。

  • 低速ストレージのほうがコストが低い。

  • 古い データへのアクセスはあるが、新しい データに比べると頻度が少ない。

HSM技術の利点は明確で、全体のストレージコストを下げることです。高価なストレージに置く必要があるのはごく一部のデータだけであるため、ユーザーエクスペリエンスの包括的な向上を図るためです。

ストア、ボリューム、ポリシーについて

HSMの利用には、関連用語の正確な理解が必要です。

  • プライマリストア: 高速かつ高価な ストア。全データの最初の保存先。

  • セカンダリストア: 低速かつ安価な ストア。 比較的古い データの移動先。

Zimbraのストア

基本: ストアのタイプとその利用方法

Zimbraには下記 タイプのストアがあります。

  • インデックスストア: インデックス化や検索機能のためにApache Luceneで使用する、データ関連情報を格納するストア。

  • データストア: MySqlデータベースで構築されているZimbraの全てのデータを格納するストア。

データストアは、複数のストアを保持できます。ただし、現在(の)(Zimbraで現在使用中という意味)として設定できるのは、プライマリデータストア、セカンダリデータストアで1つずつのみです。

プライマリストアとセカンダリストア

Zimbraのデータストアはプライマリデータストアまたはセカンダリデータストアのいずれかになります。

データは定義されたポリシーに従って 現在の プライマリデータストアと 現在の セカンダリデータストアの間を移動します。

HSM NG: ストア間のアイテム移動

HSM NGモジュールの主な機能は、定義されたHSMポリシーを適用することです。

下記3つの方法で、移動をトリガーできます。

  • 管理拡張機能にある HSMポリシーを適用する ボタンをクリック。

  • CLIから doMoveBlobs 処理を開始。

  • 管理拡張機能からポリシーをスケジューリングし、その自動開始を待機。

移動が始まると、下記の処理が実行されます。

  • HSM NGはプライマリストアをスキャンし、定義済のポリシーに合うアイテムを検索します。

  • 手順1の検索結果アイテムのBlobを全て、セカンダリストアにコピーします。

  • この移動の反映のため、コピー済アイテムに関するデータベースのエントリを更新します。

  • 手順2と手順3が正常終了した場合(この場合のみ)、プライマリストアから古いBlobを削除します。

この移動処理は ステートフルな(前の状態に依存する)性質です。つまり、各手順は前処理が正常終了した場合にのみ実行されます。このため、移動処理中にデータを失う恐れはありません。

doMoveBlobs

HSM NGのdoMoveBlobs処理

doMoveBlobsはHSM NGモジュールの要です。

該当のHSMポリシーに従って現在のプライマリストアと現在のセカンダリストアの間でアイテムを移動させます。

トランザクションを使用したアルゴリズムでこの移動を実行します。処理中にエラーが発生するとロールバックが実施され、データ移動が帳消しになります。

HSM NGが移動対象のアイテムを検知したら、下記を順に実行します。

  • Blobのコピーを現在のセカンダリストアに作成します。

  • アイテムの新しい位置をZimbraに通知するためにZimbraデータベースを更新します。

  • 現在のプライマリストアから元のBlobを削除します。

移動対象

設定されたHSMポリシーに適合する全アイテムを移動します。

例:

以下のポリシーの場合

message,document:before:-20day
message:before:-10day has:attachment

20日以上経過した全メールと全ドキュメントに加え、10日以上経過した添付ファイルのあるメールを全て移動します。

ポリシーの順番

あるポリシーが複数の条件で構成される場合、その条件は指定された順に実行されます。HSM NGは、現在のプライマリストア内の全アイテムに対し、最初の条件に適合するかどうかを判断し、それが終わってから次の条件に移り全アイテムに対する判断を繰り返します。

つまり例えば、以下のポリシーの場合

message,document:before:-20day (20日以上経過した全メールと全ドキュメント)
message:before:-10day has:attachment (10日以上経過した添付付きメール)
message:before:-10day has:attachment (10日以上経過した添付付きメール)
message,document:before:-20day (20日以上経過した全メールと全ドキュメント)

1日あたり合計1,000件のメール送受信があり、そのうち100件に1つ以上の添付ファイルがあるサンプルサーバーに対して上記ポリシーを適用すると、両結果は最終的に同じになります。しかしおそらく、2つ目のポリシーの実行時間のほうがやや(あるいはかなり)長くなります(サーバー内のメール数およびサイズにより、長さは異なります)。

この理由として、1つ目のポリシーの1つ目の条件(message,document:before:-20day )で全アイテムを判断した結果、大多数が現在のセカンダリストアに移動されるため、2つ目の条件でループ対象となるアイテムが少ししか残らないからです。

同じように message:before:-10day has:attachment を1つ目の条件とした場合には、2つ目の条件でループ対象となるアイテムが先ほどよりも多く残ります。

これは例でしかなく、全てのケースに当てはまるわけではありません。しかしこの考え方はHSMポリシーを慎重に計画する際の参考になります。

doMoveBlobs処理を実行する(HSMポリシーを適用する)

HSMポリシーを適用する と、定義済みHSMポリシーに従って現在のプライマリストアと現在のセカンダリストア間でアイテムを移動する doMoveBlobs 処理が実行されます。

HSM NGでは下記3つの方法で実行できます。

  • 管理拡張機能から実行。

  • CLIから実行。

  • スケジューリングにより実行。

管理コンソールからHSMポリシーを適用する

管理拡張機能からHSMポリシーを適用する方法

  • Zimbra管理コンソールにログインします。

  • 管理拡張機能にある HSM NG をクリックします。

  • HSMポリシー を適用するボタンをクリックします。

CLIからHSMポリシーを適用する

CLIからHSMポリシーを適用するには’zimbra’ユーザーにて以下のコマンドを実施します。

?zxsuite?hsm?doMoveBlobs

スケジューリングにてHSMポリシーを適用する

doMoveBlobs 処理をスケジューリングにより実行する方法

  • Zimbra管理コンソールにログインします。

  • 管理拡張機能にある HSM NG をクリックします。

  • Enable HSM Session scheduling (HSMセッションを定期実行させる)チェックボックスをオンにします。

  • HSM Session scheduled for (定期実行HSMセッション)から処理実行時間を選択します。

doMoveBlobsの統計情報

ディスク容量の節約に関する情報や処理パフォーマンスなど様々な情報が、管理拡張機能のHSM NGタブ内セカンダリボリュームリストの下にあるStatsボタンから確認できます。

ボリューム管理

プライマリとセカンダリのボリュームをローカルストレージ、またはサポート対象の第三者ストレージソリューションに作成することが可能です。

Zimbraのボリューム

ボリュームとは、ファイルシステム内で物理的に分けられたエンティティ (パス) です。Zimbra Blobを格納します。この分割には関連するプロパティが全て使われます。

ボリュームのプロパティ

Zimbraのボリュームは全て、下記プロパティにより定義されます。

  • 名称: ボリュームの一意の識別子。

  • パス: データの保存先となるパス。zimbraユーザーはこのパスに対する読み書き権限が必要です。

  • 圧縮: ボリュームのファイル圧縮を有効または無効にする。

  • 圧縮のしきい値: 圧縮のトリガーとなるファイルサイズ最小値。圧縮が有効であっても、このしきい値を下回るファイルは圧縮されません。

  • 現在: 現在の ボリュームは、データ到着時 (現在のプライマリボリューム) またはHSMポリシー適用時 (現在のセカンダリボリューム) の書き込み先となるボリューム。

HSM NGを使用したボリューム管理

新規ボリュームの作成
管理拡張機能から

管理拡張機能のHSM NGタブから新しいボリュームを作成する方法

  • 作成したいボリュームのタイプに応じ、ボリューム管理 セクションにある該当の 追加 ボタンをクリックします。

  • ボリュームタイプにローカル、あるいはS3 Bucketを選択します。

  • 新しいボリューム名を入力します。

  • 新しいボリュームのパスを入力します。

  • 新しいボリュームでデータを圧縮したい場合、 圧縮するチェックボック をオンにします。

  • 圧縮のしきい値を入力します。

  • S3 Bucketを使用中の場合は複数のバケット情報を保存することができます。

  • OK ボタンを押下すると新しいボリュームが作成されます。処理が正常に行なわれなかった場合はエラー情報を通知します。

管理Zimletでボリュームを編集する場合

管理Zimletからボリュームを編集する場合、既存のボリュームを選択し、適切の「編集」ボタンをクリックします。

管理Zimletでボリュームを削除する場合

管理Zimletでボリュームを削除する場合、既存のボリュームを選択し、適切の「削除」ボタンをクリックします。 なお、【空】のボリュームのみを削除することが可能です。

CLI での HSM NG ボリューム管理

ご注意:8.8.9 のリリースにより、すべてのボリューム作成とアップデートコマンドが更新されており、`storeType`のオプションが必要となっています。

storeType のオプションが必要となっており、最初に設定し、以前にリストした AmazonS3互換サービス上のボリューム 値から1つの値のみを利用します。 なお、選択した storeType により、コマンドで利用できるオプションが異なります。

FileBlob (ローカル)

zxsuite のコマンドを更新し、新しい FileBlob zimbra ボリュームを作られます:

# ボリュームを追加する場合、以下のコマンドを zimbra ユーザーとして実行します。
zxsuite hsm doCreateVolume FileBlob name secondary /path/to/store
# ボリュームを削除する場合は以下のコマンドを活用します。
zxsuite hsm doDeleteVolume name
# 「現在」のボリュームとして指定する場合は以下のコマンドを活用します。
zxsuite hsm doUpdateVolume FileBlob name current_volume true

zxsuite hsm doCreateVolume FileBlob

構文:
   zxsuite hsm doCreateVolume FileBlob {volume_name} {primary|secondary|index} {volume_path} [attr1 value1 [attr2 value2...

パラメーターリスト

名前                              データ型               期待値                    初期値
volume_name(M)                    String
volume_type(M)                    複数選択肢    primary|secondary|index
volume_path(M)                    Path
volume_compressed(O)              Boolean            true|false                 false
compression_threshold_bytes(O)    Long                                          4096

(M) == 必須パラメーター, (O) == 任意のパラメーター

使用例:

zxsuite hsm doCreateVolume FileBlob volumeName secondary /path/to/store volume_compressed true compression_threshold_bytes 4096

zxsuite hsm doUpdateVolume FileBlob

構文:
    zxsuite hsm doUpdateVolume FileBlob {current_volume_name} [attr1 value1 [attr2 value2...]]

パラメーターリスト

名前                              データ型               期待値                    初期値
current_volume_name(M)          String
volume_type(O)                  String              primary|secondary|index
volume_name(O)                  String
volume_path(O)                  Path
current_volume(O)               Boolean             true|false                  false
volume_compressed(O)            String
compression_threshold(O)        String

(M) == 必須パラメーター, (O) == 任意のパラメーター
S3 (Amazon および明確にサポートしていないS3と互換性があるソリューション)
# 以下のコマンドでボリュームを追加します。以下のコマンドはzimbraユーザーとして実行します。
zxsuite hsm doCreateVolume S3 name secondary bucket_name bucket access_key accessKey secret secretString region EU_WEST_1
# 以下のコマンドでボリュームを削除します。
zxsuite hsm doDeleteVolume name
# 以下のコマンドでボリュームを「現在」のボリュームとして指定します。
zxsuite hsm doUpdateVolume S3 name current_volume true

zxsuite hsm doCreateVolume S3

構文:
    zxsuite hsm doCreateVolume S3 {Name of the zimbra store} {primary|secondary} [attr1 value1 [attr2 value2...]]

パラメーターリスト

名前                              データ型               期待値
volume_name(M)                  String              Zimbra ストア名
volume_type(M)                  複数選択肢          primary|secondary
bucket_name(O)                  String              Amazon AWS バケット
access_key(O)                   String              サービスのユーザー名
secret(O)                       String              サービスのパスワード
server_prefix(O)                String              すべてのオブジェクトキーに使用するサーバIDのプレフィックス
bucket_configuration_id(O)      String              既存しているS3サービスの認証情報のUUID
                                                    (zxsuite config global get attribute s3BucketConfigurations)
region(O)                       String              Amazon AWS 地域
url(O)                          String              S3 API と互換性があるサービスURL (例えば: s3api.service.com)
prefix(O)                       String              blobs キーへ追加するプレフィックス
use_infrequent_access(O)        Boolean             true|false
infrequent_access_threshold(O)  String

(M) == 必須パラメーター, (O) == 任意のパラメーター

使用例:

S3 AWS Bucketの場合:
    zxsuite hsm doCreateVolume S3 volumeName primary bucket_name bucket access_key accessKey secret secretKey prefix objectKeysPrefix region EU_WEST_1 user_infrequent_access TRUE infrequent_access_threshold 4096

S3 と互換性があるオブジェクトストレージの場合:
    zxsuite hsm doCreateVolume S3 volumeName primary bucket_name bucket access_key accessKey secret secretKey url http://host/service

既存のBucket設定を使用する場合:
    zxsuite hsm doCreateVolume S3 volumeName primary bucket_configuration_id 316813fb-d3ef-4775-b5c8-f7d236fc629c

zxsuite hsm doUpdateVolume S3

構文:
    zxsuite hsm doUpdateVolume S3 {current_volume_name} [attr1 value1 [attr2 value2...]]

パラメーターリスト

名前                              データ型               期待値                    初期値
current_volume_name(M)          String
volume_name(O)                  String
volume_type(O)                  String              primary|secondary
server_prefix(O)                String              すべてのオブジェクトキーに使用するサーバIDのプレフィックス
bucket_configuration_id(O)      String              既存しているS3サービスの認証情報のUUID
                                                    (zxsuite config global get attribute s3BucketConfigurations)
use_infrequent_access(O)        Boolean             true|false
infrequent_access_threshold(O)  String
current_volume(O)               Boolean             true|false                  false

(M) == 必須パラメーター, (O) == 任意のパラメーター
Scality (S3 と互換性があるオブジェクトストレージ)
# 以下のコマンドでボリュームを追加します。以下のコマンドはzimbraユーザーとして実行します。
zxsuite hsm doCreateVolume ScalityS3 name secondary bucket_name mybucket access_key accessKey1 secret verySecretKey1 url http://{IP_ADDRESS}:{PORT}
# 以下のコマンドでボリュームを削除します。
zxsuite hsm doDeleteVolume name
# 以下のコマンドでボリュームを「現在」のボリュームとして指定します。
zxsuite hsm doUpdateVolume ScalityS3 name current_volume true

zxsuite hsm doCreateVolume ScalityS3

構文:
    zxsuite hsm doCreateVolume ScalityS3 {volume_name} {primary|secondary} [attr1 value1 [attr2 value2...]]

パラメーターリスト

名前                              データ型               期待値
volume_name(M)                  String
volume_type(M)                  複数選択肢          primary|secondary
bucket_name(O)                  String              Bucket名
url(O)                          String              S3 API と互換性があるサービスURL (例えば: s3api.service.com)
access_key(O)                   String              サービスのユーザー名
secret(O)                       String              サービスのパスワード
server_prefix(O)                String              すべてのオブジェクトキーに使用するサーバIDのプレフィックス
bucket_configuration_id(O)      String              既存しているS3サービスの認証情報のUUID
                                                    (zxsuite config global get attribute s3BucketConfigurations)
prefix(O)                       String              blobs キーへ追加するプレフィックス

(M) == 必須パラメーター, (O) == 任意のパラメーター

使用例:

zxsuite hsm doCreateVolume ScalityS3 volumeName primary bucket_name bucket url http://host/service access_key accessKey secret secretKet
zxsuite hsm doCreateVolume ScalityS3 volumeName primary bucket_configuration_id uuid

zxsuite hsm doUpdateVolume ScalityS3

構文:
    zxsuite hsm doUpdateVolume ScalityS3 {current_volume_name} [attr1 value1 [attr2 value2...]]

パラメーターリスト

名前                              データ型               期待値                    初期値
current_volume_name(M)          String
volume_name(O)                  String
volume_type(O)                  String              primary|secondary
server_prefix(O)                String              すべてのオブジェクトキーに使用するサーバIDのプレフィックス
bucket_configuration_id(O)      String              既存しているS3サービスの認証情報のUUID
                                                    (zxsuite config global get attribute s3BucketConfigurations)
current_volume(O)               Boolean             true|false                  false

(M) == 必須パラメーター, (O) == 任意のパラメーター
EMC (S3 と互換性があるオブジェクトストレージ)
# 以下のコマンドでボリュームを追加します。以下のコマンドはzimbraユーザーとして実行します。
zxsuite hsm docreatevolume EMC name secondary bucket_name bucket access_key ACCESSKEY secret SECRET url https://url.of.storage
# 以下のコマンドでボリュームを削除します。
zxsuite hsm doDeleteVolume name
# 以下のコマンドでボリュームを「現在」のボリュームとして指定します。
zxsuite hsm doUpdateVolume EMC name current_volume true

zxsuite hsm doCreateVolume EMC

構文:
    zxsuite hsm doCreateVolume EMC {volume_name} {primary|secondary} [attr1 value1 [attr2 value2...]]

パラメーターリスト

名前                              データ型               期待値
volume_name(M)                  String
volume_type(M)                  複数選択肢          primary|secondary
bucket_name(O)                  String              Bucket名
url(O)                          String              S3 API と互換性があるサービスURL (例えば: s3api.service.com)
access_key(O)                   String              サービスのユーザー名
secret(O)                       String              サービスのパスワード
server_prefix(O)                String              すべてのオブジェクトキーに使用するサーバIDのプレフィックス
bucket_configuration_id(O)      String              既存しているS3サービスの認証情報のUUID
                                                    (zxsuite config global get attribute s3BucketConfigurations)
prefix(O)                       String              blobs キーへ追加するプレフィックス

(M) == 必須パラメーター, (O) == 任意のパラメーター

使用例:

zxsuite hsm doCreateVolume EMC volumeName primary bucket_name bucket url http://host/service access_key accessKey secret secretKet
zxsuite hsm doCreateVolume EMC volumeName primary bucket_configuration_id uuid

zxsuite hsm doUpdateVolume EMC

構文:
    zxsuite hsm doUpdateVolume EMC {current_volume_name} [attr1 value1 [attr2 value2...]]

パラメーターリスト

名前                              データ型               期待値                    初期値
current_volume_name(M)          String
volume_name(O)                  String
volume_type(O)                  String              primary|secondary
server_prefix(O)                String              すべてのオブジェクトキーに使用するサーバIDのプレフィックス
bucket_configuration_id(O)      String              既存しているS3サービスの認証情報のUUID
                                                    (zxsuite config global get attribute s3BucketConfigurations)
current_volume(O)               Boolean             true|false                  false

(M) == 必須パラメーター, (O) == 任意のパラメーター
OpenIO
# 以下のコマンドでボリュームを追加します。以下のコマンドはzimbraユーザーとして実行します。
zxsuite hsm doCreateVolume OpenIO name secondary http://{IP_ADDRESS} ZeXtras OPENIO
# 以下のコマンドでボリュームを削除します。
zxsuite hsm doDeleteVolume name
# 以下のコマンドでボリュームを「現在」のボリュームとして指定します。
zxsuite hsm doUpdateVolume OpenIO name current_volume true

zxsuite hsm doCreateVolume OpenIO

構文:
    zxsuite hsm doCreateVolume OpenIO {volume_name} {primary|secondary} {url} {account} {namespace} [attr1 value1 [attr2 value2...]]

パラメーターリスト

名前                              データ型               期待値
volume_name(M)                  String
volume_type(M)                  複数選択肢            primary|secondary
url(M)                          String
account(M)                      String
namespace(M)                    String
proxy_port(O)                   Integer
account_port(O)                 Integer

(M) == 必須パラメーター, (O) == 任意のパラメーター

使用例:

zxsuite hsm doCreateVolume OpenIO volumeName primary http://host/service

accountName namespaceString proxy_port 6006 account_port 6009

構文:
zxsuite hsm doUpdateVolume OpenIO {current_volume_name} [attr1 value1
[attr2 value2...]]
パラメーターリスト

名前                              データ型               期待値                    初期値
current_volume_name(M)          String
volume_name(O)                  String
volume_type(O)                  String              primary|secondary
url(O)                          String
account(O)                      String
namespace(O)                    String
proxy_port(O)                   Integer
account_port(O)                 Integer
current_volume(O)               Boolean             true|false                  false

(M) == 必須パラメーター, (O) == 任意のパラメーター
Swift
# 以下のコマンドでボリュームを追加します。以下のコマンドはzimbraユーザーとして実行します。
zxsuite hsm doCreateVolume Swift name secondary http://{IP_ADDRESS}:8080/auth/v1.0/ user:username password maxDeleteObjectsCount 100
# 以下のコマンドでボリュームを削除します。
zxsuite hsm doDeleteVolume name
# 以下のコマンドでボリュームを「現在」のボリュームとして指定します。
zxsuite hsm doUpdateVolume Swift name current_volume true

zxsuite hsm doCreateVolume Swift

構文:
    zxsuite hsm doCreateVolume Swift {volume_name} {primary|secondary} {url} {username} {password} [attr1 value1 [attr2 value2...]]

パラメーターリスト

名前                              データ型               期待値                    初期値
volume_name(O)              String
volume_type(O)              String      primary|secondary
url(O)                      String
username(O)                 String
password(O)                 String
maxDeleteObjectsCount(O)    Integer     特定のバルク削除リクエストのオブジェクト数
                                                                    500

(M) == 必須パラメーター, (O) == 任意のパラメーター

使用例:

zxsuite hsm doCreateVolume Swift volumeName primary http://host/service accountName password max_delete_objects_count 100

zxsuite hsm doUpdateVolume Swift

構文:
    zxsuite hsm doUpdateVolume Swift {current_volume_name} [attr1 value1 [attr2 value2...]]

パラメーターリスト

名前                              データ型               期待値                    初期値
current_volume_name(M)      String
volume_name(O)              String
volume_type(O)              String      primary|secondary
url(O)                      String
username(O)                 String
password(O)                 String
maxDeleteObjectsCount(O)    Integer     特定のバルク削除リクエストのオブジェクト数
                                                                    500
current_volume(O)           Boolean     true|false                  false

(M) == 必須パラメーター, (O) == 任意のパラメーター
Cloudian (S3互換オブジェクトストア)
# 以下のコマンドでボリュームを追加します。以下のコマンドはzimbraユーザーとして実行します。
zxsuite hsm doCreateVolume Cloudian name secondary bucket_name bucket access_key ACCESSKEY secret SECRET url https://url.of.storage
# 以下のコマンドでボリュームを削除します。
zxsuite hsm doDeleteVolume name
# 以下のコマンドでボリュームを「現在」のボリュームとして指定します。
zxsuite hsm doUpdateVolume Cloudian name current_volume true

zxsuite hsm doCreateVolume Cloudian

構文:
    zxsuite hsm doCreateVolume Cloudian {volume_name} {primary|secondary} [attr1 value1 [attr2 value2...]]

パラメーターリスト

名前                              データ型               期待値
volume_name(M)                  String
volume_type(M)                  複数選択肢          primary|secondary
bucket_name(O)                  String              Bucket名
url(O)                          String              S3 API と互換性があるサービスURL (例えば: s3api.service.com)
access_key(O)                   String              サービスのユーザー名
secret(O)                       String              サービスのパスワード
server_prefix(O)                String              すべてのオブジェクトキーに使用するサーバIDのプレフィックス
bucket_configuration_id(O)      String              既存しているS3サービスの認証情報のUUID
                                                    (zxsuite config global get attribute s3BucketConfigurations)
prefix(O)                       String              blobs キーへ追加するプレフィックス

(M) == 必須パラメーター, (O) == 任意のパラメーター

使用例:

zxsuite hsm doCreateVolume Cloudian volumeName primary bucket_name bucket url http://host/service access_key accessKey secret secretKet
zxsuite hsm doCreateVolume Cloudian volumeName primary bucket_configuration_id uuid

zxsuite hsm doUpdateVolume Cloudian

構文:
    zxsuite hsm doUpdateVolume Cloudian {current_volume_name} [attr1 value1 [attr2 value2...]]

パラメーターリスト

名前                              データ型               期待値                    初期値
current_volume_name(M)          String
volume_name(O)                  String
volume_type(O)                  String              primary|secondary
server_prefix(O)                String              すべてのオブジェクトキーに使用するサーバIDのプレフィックス
bucket_configuration_id(O)      String              既存しているS3サービスの認証情報のUUID
                                                    (zxsuite config global get attribute s3BucketConfigurations)
current_volume(O)               Boolean             true|false                  false

(M) == 必須パラメーター, (O) == 任意のパラメーター
Volume Deletion

zxsuite hsm doDeleteVolume

構文:
    zxsuite hsm doDeleteVolume {volume_name}

パラメーターリスト

名前                              データ型
volume_name(M)                  String

(M) == 必須パラメーター, (O) == 任意のパラメーター

使用例:

zxsuite hsm dodeletevolume hsm
Deletes volume with name hsm
すべてのデータを特定のボリュームから別のボリュームへ移動する場合
構文:
    zxsuite hsm doVolumeToVolumeMove {source_volume_name} {destination_volume_name}

パラメーターリスト

名前                              データ型
source_volume_name(M)           String
destination_volume_name(M)      String

(M) == 必須パラメーター, (O) == 任意のパラメーター

使用例:

zxsuite hsm doVolumeToVolumeMove sourceVolume destVolume

上記のコマンドでsourceVolumeの内容をすべてdestVolumeへ移動します。

集中型ストレージについて

集中型ストレージの機能では、S3 バケットを運用し、複数のサーバから同時に受信するデータを同一のディレクトリ構成を共有し、ホストすることが可能です。これはディレクトリ構成がサーバとボリュームに関連してる一般的な「独立」ボリュームと異なるデータ提供方法となります。

この機能により、大きいマルチストア環境でのデータ管理が向上し、メールボックスの移動速度も速くなります。

集中型ストレージを有効化する方法

  1. zxsuite hsm doCreateVolume コマンドで集中型ストレージのボリュームを作成します。

    1. FileBlob以外、すべてのボリューム種類に互換性があります。

    2. 集中型ストレージとして利用するため、centralized TRUE のフラグを指定する必要があります。

    3. ストレージ種類により、コマンドに使用する適切な構文が異なります。

  2. 集中型ストレージのボリュームを作成後、zxsuite doCreateVolume Centralized のコマンドを他のメールボックスサーバに実施し、集中型ストレージのボリューム設定を最初のサーバからコピーし、ボリュームのリストへ追加します。

    1. コマンドの完全なる構文は zxsuite hsm doCreateVolume Centralized {サーバ名} {ボリューム名}

集中型ストレージの構成について

ストレージ構成について 集中型ストレージのボリュームにデータがプレインの状態で保存します。ボリュームのメインディレクトリにはボリュームへ接続している各サーバに空のディレクトリがありますと、各メールボックスのディレクトリも同じレベルで含まれています。

以下の実例では、2つのサーバ、3aa2d376-1c59-4b5a-94f6-101602fa69c6 と 595a4409-6aa1-413f-9f45-3ef0f1e560f5 が集中型ストレージへ接続しており、合計3つのメールボックスが保管しています。実際にメールボックスがホストしているサーバはデータを保管しているストレージと関連していないことをご確認ください。

_
|- 3aa2d376-1c59-4b5a-94f6-101602fa69c6/
|- 595a4409-6aa1-413f-9f45-3ef0f1e560f5/
|- ff46e039-28e3-4343-9d66-92adc60e60c9/
\
 |-- 357-104.msg
 |-- 368-115.msg
 |-- 369-116.msg
 |-- 373-120.msg
 |-- 374-121.msg
 |-- 375-122.msg
 |-- 376-123.msg
 |-- 383-130.msg
|- 4c022592-f67d-439c-9ff9-e3d48a8c801b/
\
 |-- 315-63.msg
 |-- 339-87.msg
 |-- 857-607.msg
 |-- 858-608.msg
 |-- 859-609.msg
 |-- 861-611.msg
 |-- 862-612.msg
 |-- 863-613.msg
 |-- 864-614.msg
 |-- 865-615.msg
 |-- 866-616.msg
 |-- 867-617.msg
 |-- 868-618.msg
|- dafd5569-4114-4268-9201-14f4a895a3d5/
\
 |-- 357-104.msg
 |-- 368-115.msg
 |-- 369-116.msg
 |-- 373-120.msg
 |-- 374-121.msg
 |-- 375-122.msg
 |-- 376-123.msg
 |-- 383-130.msg
 |-- 384-131.msg

ポリシー管理

ポリシーとは

HSMポリシーとは、マニュアル操作またはスケジューリングでHSM NGの doMoveBlobs 処理をトリガーする際、どのアイテムをプライマリストアからセカンダリストアに移動させるかを定義したルールです。

ポリシーには、全タイプのアイテムに適用するシングルルール (シンプル ポリシー) もあれば1つまたはそれ以上のタイプのアイテムに適用する複数ルール (互換 ポリシー) もあります。また、 Zimbraの search syntaxを利用して、サブルールを追加で定義することも可能です。

ポリシーの例

ポリシーの例をいくつか紹介します。HSM NGモジュールでのポリシー作成方法については後述を参照してください。

  • 30日以上経過した全アイテムを移動。

  • 15日以上経過したメールおよび30日以上経過した、その他の全てのタイプのアイテムを移動。

  • 15日以上経過したカレンダーアイテム、20日以降経過したブリーフケースアイテム、“アーカイブ”フォルダにあるメールをすべて移動。

ポリシーを定義する

管理拡張機能にあるHSM NGタブやCLIからポリシーを定義できます。ともにキーワード検索で使うキーワードを指定できます。

管理拡張機能から

管理拡張機能からポリシーを定義する方法

  • Zimbra管理コンソールにログインします。

  • 管理拡張機能にある HSM NG をクリックします。

  • ストレージ管理ポリシーセクションにある 追加 ボタンをクリックします。

  • 移動するアイテム の一覧からアイテムのタイプを選択します。

  • 古いアイテムを移動 項目には、経過日数を入力します。

  • 任意: 追加オプション 項目には、キーワード検索用のキーワードを追加します。

  • を複数追加して、ポリシーの粒度を高めることができます。最初の のポリシーの適用が完了したあと、順に次の のポリシーが判断・実行されることになります。

CLIから

CLIで使用できるポリシー管理用のコマンドは2つあります。

  • setHsmPolicy

  • +setHsmPolicy

zxsuite hsm setHsmPolicy {policy}

このコマンドは現在のポリシーをリセットし、ポリシー パラメーターで指定したポリシーを新たに作成します。

ポリシー パラメーターは次の構文で指定する必要があります。

itemType1[,itemType2,itemtype3,etc]:query

zxsuite hsm +setHsmPolicy {policy}

このコマンドは ポリシー パラメーターで指定したクエリを現在のHSMポリシーに追加します。

ポリシー パラメーターは次の構文で指定する必要があります。

itemType1[,itemType2,itemtype3,etc]:query

AmazonS3互換サービス上のセカンダリボリューム

HSM NGとS3バケット

今ではHSM NGで作成するセカンダリボリュームをS3バケットにホストさせることが可能になったため、データの大部分を安全かつ堅固なクラウドストレージへ効率的に移動させることができます。

S3互換サービス

Amazon S3 APIを利用するHSM NGのストレージサービスは全て、設定後すぐに機能するようでなければなりません。このため、以下のプラットフォームのみが公式なサポート対象のプラットホームとしています。

  • FileBlob (スタンダードのローカルボリューム)

  • Amazon S3

  • EMC

  • OpenIO

  • Swift

  • Scality S3

  • Cloudian

  • Custom S3 (サポート対象外のS3等のソリューション)

プライマリボリュームと「Incoming」のディレクトリについて

メールボックスサーバにリモートの プライマリストア を作成するため、そのサーバにローカルの「Incoming」ディレクトリを用意する必要があります。なお、デフォルトのディレクトリは /opt/zimbra/incoming となりますが、以下のコマンドで現在の設定の確認、および更新することが可能です。

zxsuite config server get $(zmhostname) attribute incomingPath
zxsuite config server set $(zmhostname) attribute incomingPath value /path/to/dir
ローカルキャッシュ

この機能にはアイテムのキャッシュ用のローカルディレクトリが必要です。このディレクトリは zimbra ユーザーで読み書き可能でなければなりません。

マニュアル操作でローカルディレクトリを作成し、そのパスをZimbra管理コンソール管理拡張機能の HSM NG セクションで入力する必要があります。

このローカルキャッシュディレクトリを作成しなければ、S3互換デバイス・サービス上にセカンダリボリュームを作成することはできません。

キャッシュディレクトリが正常に設定されない場合、アイテム検索が失敗します。つまり、S3ボリューム上に保存されているアイテムにユーザーがアクセスしようとしても、そのようなBLOBは存在しません というエラーが返されることになります。

ローカルボリューム

ローカルボリューム(つまり FileBlob type)がマウントポイントの行き先を問わず、システム上でホストするマウントポイントを自由に利用できます。詳細が設定は以下のプロパティで管理しています。

  • Name: ボリュームを特定できる名前

  • Path: データが保存するパス。zimbra ユーザーはこのパスへの書き込みと読み込みパミッションを与える必要があります。

  • Compression: ボリュームにファイルの圧縮を有効化、または無効化します。

  • Compression Threshold: ファイル圧縮が行える最低のファイルサイズを指定します。

    ご注意:ファイル圧縮を有効化しても、受信したファイルがこの値に指定した最低サイズより小さい場合、ファイル圧縮がそのファイルへ適用されません。

現在のボリューム

データの受信時(現在のプライマリ、またはHSMポリシーの適用が行う(現在のセカンダリ)際に、現在のボリューム へデータが書き込みます)。 「現在」として指定したいないボリュームは特定の手動オペレーション(例えば、ボリュームから別のボリュームへの移動)以外に書き込みが発生しません。

バケットのセットアップ

HSM NGのためにS3側で何か特別な設定をする必要はないため、ボリューム用のバケットのセットアップは簡単です。専用ユーザー、バケット、アクセスポリシーの作成は必須ではありませんが、円滑な管理のため作成されることを強く推奨します。

以下は、S3上でのセカンダリボリューム設置を開始する際に必要なものです。

  • S3 Bucket。使用するバケットの名前とリージョンを確認しておく必要があります。

  • ユーザーのアクセスキーとシークレットアクセスキー。

  • バケットに対するフル権限をユーザーに与える際のポリシー。

Bucket の管理

Zimbra 管理コンソールにBucketの管理UIが提供しています。これを活用することで、S3等のストレージに新しいボリュームを作成する際に詳細を毎回手動に入力せずに、よく使うBucketの情報を保存し、自動的に追加させることが可能です。

Bucket管理のUIは以下の方法でアクセスできます。

  • Zimbra 管理コンソールをアクセスします。

  • メニューから「設定」をクリックします。

  • 「グローバル設定」をクリックします。

  • S3 Buckets のメニューを選択します。

システムへ追加したBucketは以下の種類の新規ボリュームを作成する際に利用することが可能です: Amazon S3, Cloudian, EMC, Scality S3, Custom S3

Bucket パスと名前について

Bucketに保存したファイルは指定したパスへ保存し、自由にカスタマイズできますので、マルチサーバ環境で複数のセカンダリボリュームでもBucketの内容を簡単に確認できることが可能です。

/Bucket Name/Destination Path/[Volume Prefix-]serverID/

  • Bucket NameDestination Path はボリュームに関連していなく、保存先のパスにボリューム上限がありません。

  • しかしながら、Volume Prefix は各ボリュームに関連し、Bucket上で異なるボリュームを特定できる指定となります。

HSM NG でボリュームを作成する

Zimbra 管理コンソール上で HSM NG の新しいボリュームを作成する場合、以下の手順をご参照ください。

  • Zimbra 管理コンソールでNG管理画面のHSMメニューをアクセスします。

  • プライマリボリューム、またはセカンダリボリュームに「追加」のボタンをクリックします。

  • 利用可能のストレージ類より使用するボリュームの種類を選択します。

  • 必要な情報を入力し、ボリュームを作成します。

    ご注意ください:各ボリュームの種類には異なる情報を入力する必要がありますので、ストレージプロバイダー様まで必要な詳細情報をご確認ください。

HSM NG でボリュームを編集する

Zimbra 管理コンソールで HSM NG のボリュームを編集する場合、以下の手順をご参照ください。

  • Zimbra 管理コンソールでNG管理画面のHSMメニューをアクセスします。

  • ボリューム名をクリックします。

  • 「編集」のボタンをクリックします。

  • 編集が完了しましたら、「保存」のボタンをクリックします。

HSM NG でボリュームを削除する

Zimbra 管理コンソールで HSM NG のボリュームを削除する場合、以下の手順をご参照ください。

  • Zimbra 管理コンソールでNG管理画面のHSMメニューをアクセスします。

  • ボリューム名をクリックします。

  • 「削除」のボタンをクリックします。

注意: 空のボリュームのみを削除することが可能です。

Amazon S3に関するヒント

バケット

Amazon S3にセカンダリのZimbraボリュームを格納するにあたってのバケット要件は特にありません。しかし、円滑な管理のため、専用バケットの作成および静的ウェブサイトホスティングの無効化を推奨します。

ユーザー

アクセスキーとシークレットアクセスキーを取得するには、Programmatic Access ユーザーが必要です。円滑な管理のため、AmazonのIAM (AWS Identity and Access Management) サービスで専用ユーザーの作成を推奨します。

権限の管理

AmazonのIAMサービスから、ユーザーに対するアクセスポリシーを設定することができます。アクセスキーとシークレットアクセスキーのユーザーには、バケットとその内容に対する適当な権限がなければなりません。円滑な管理のため、下記例のようにフル権限を付与することを推奨します。

{
    `Version`: `[LATEST API VERSION]`,
    `Statement`: [
        {
            `Sid`: `[AUTOMATICALLY GENERATED]`,
            `Effect`: `Allow`,
            `Action`: [
                `s3:*`
            ],
            `Resource`: [
                `[BUCKET ARN]/*`,
                `[BUCKET ARN]`
            ]
        }
    ]
}

警告 - 上記は有効な設定ポリシーではありません。検証対象外であるため、上記をユーザー設定にコピー&ペーストしないでください。

最小限の権限のみを付与したい場合、Action セクションを下記のとおり変更してください。

"Action": [
                `s3:PutObject`,
                `s3:GetObject`,
                `s3:DeleteObject`,
                `s3:AbortMultipartUpload`
              ],

バケットのARNは、Amazonの標準命名規約に則り、 arn:partition:service:region:account-id:resource のように表現されます。このトピックについての詳細は、Amazonの公式ドキュメントを確認してください。

バケットのパスと命名

ファイルは、緻密に定義されたパスに従ってバケットに格納されます。バケット内容を分かりやすくするために、パスを自由にカスタマイズできます (セカンダリボリュームが複数あるマルチサーバー環境の場合も同様) 。

/Bucket Name/Destination Path/serverID/

バケットの名前Destination Path はボリュームに紐づいていません。同じDestination path 配下にボリュームを好きなだけ配置することができます。

一方、Volume Prefix は、各ボリュームに特化しているため、バケット内に複数あるボリュームを瞬時に区別したり、識別するのに役立ちます。

低頻度アクセスのストレージクラス

HSM NGは、 Amazon S3 標準―低頻度アクセス のストレージクラスと互換性があります。 低頻度アクセス のしきい値 を超える全てのファイルをこのストレージクラスに格納することになります。

低頻度アクセスについての詳細情報は、公式の official Amazon S3 ドキュメント を確認してください。

Intelligent Tiering のストレージクラスについて

HSM NG は Amazon S3 - Intelligent Tiering のストレージクラスとの互換性があります。 ボリュームにオプションが有効化している限り、適切な Intelligent Tiering フラグがすべてのファイルへ追加されます。

なお、Intelligent Tiering の機能の詳細に関しまして、https://aws.amazon.com/about-aws/whats-new/2018/11/s3-intelligent-tiering/[Amazon S3 のドキュメンテーション] をご参照ください。

アイテムの重複排除

アイテムの重複排除とは

アイテムの重複排除とは、一度しか参照しない同じアイテムのコピーをいくつも保存する代わりに、1つだけ保存したコピーを何度も参照することでディスク容量を節約する技術です。

マイナーな改善のようですが、実際に使用すると、とてつもない違いを生みます。

Zimbraのアイテム重複排除

Zimbraで実施しているアイテム重複排除は、現在のプライマリボリュームに新たなアイテムを格納するときに実行されます。

作成中アイテムの Message ID をキャッシュ済みアイテムの一覧と比較します。一致した場合、そのメッセージの新規BLOBを作成する代わりに、該当のキャッシュ済みメッセージのBLOBへのリンクを作成します。

この重複排除キャッシュは下記の属性を利用して、Zimbra内で管理されます。

zimbraPrefDedupeMessagesSentToSelf

セルフtoセルフメッセージの場合の重複排除動作の設定に使用します。

<attr id="144" name="zimbraPrefDedupeMessagesSentToSelf" type="enum" value="dedupeNone,secondCopyifOnToOrCC,dedupeAll" cardinality="single"
optionalIn="account,cos" flags="accountInherited,domainAdminModifiable">
  <defaultCOSValue>dedupeNone</defaultCOSValue>
  <desc>dedupeNone|secondCopyIfOnToOrCC|moveSentMessageToInbox|dedupeAll</desc>
</attr>

zimbraMessageIdDedupeCacheSize

キャッシュ済みMessage IDの数。

<attr id="334" name="zimbraMessageIdDedupeCacheSize" type="integer" cardinality="single" optionalIn="globalConfig" min="0">
  <globalConfigValue>3000</globalConfigValue>
  <desc>
    Number of Message-Id header values to keep in the LMTP dedupe cache.
    Subsequent attempts to deliver a message with a matching Message-Id
    to the same mailbox will be ignored.  A value of 0 disables deduping.
  </desc>
</attr>

zimbraPrefMessageIdDedupingEnabled

アカウントレベルあるいは提供サービスレベルでの重複排除管理。

<attr id="1198" name="zimbraPrefMessageIdDedupingEnabled" type="boolean" cardinality="single" optionalIn="account,cos" flags="accountInherited"
 since="8.0.0">
  <defaultCOSValue>TRUE</defaultCOSValue>
  <desc>
    Account-level switch that enables message deduping.  See zimbraMessageIdDedupeCacheSize for more details.
  </desc>
</attr>

zimbraMessageIdDedupeCacheTimeout

重複排除キャッシュにある各エントリのタイムアウト。

<attr id="1340" name="zimbraMessageIdDedupeCacheTimeout" type="duration" cardinality="single" optionalIn="globalConfig" since="7.1.4">
  <globalConfigValue>0</globalConfigValue>
  <desc>
    Timeout for a Message-Id entry in the LMTP dedupe cache. A value of 0 indicates no timeout.
    zimbraMessageIdDedupeCacheSize limit is ignored when this is set to a non-zero value.
  </desc>
</attr>

(バージョンの古いZimbraでは別の属性を使用しているか、上記の属性が含まれていない可能性があります)

アイテムの重複排除とHSM NG

HSM NGには、重複アイテム検索・重複排除するためにボリューム解析を行なう doDeduplicate 処理という機能が備わっています。

これにより、ディスク容量の更なる節約になります。Zimbraの自動重複排除で対象となるキャッシュは限定されていますが、HSM NGの重複排除は、キャッシュやタイミングに関係なく、同じメールに対して複数存在するコピーの検索・対処も行なうからです。

移行後あるいは大きなデータのインポート後はストレージ利用の最適化のため、doDeduplicate 処理を実行されることを強く推奨します。

ボリューム重複排除の実行
管理拡張機能から

管理拡張機能からボリュームの重複排除を実行するには、HSM NG タブをクリックし、重複排除を行ないたいボリュームを選択後、ボリュームの 重複排除 ボタンを押下します。

CLIから

CLIからボリュームの重複排除を実行するには、doDeduplicate コマンドを利用します。

zimbra@mailserver:~$ zxsuite hsm doDeduplicate

command doDeduplicate requires more parameters

構文:
   zxsuite hsm doDeduplicate {volume_name} [attr1 value1 [attr2 value2...

パラメーターリスト

名前              データ型           期待値           初期値
volume_name(M)    String[,..]
dry_run(O)        Boolean        true|false         false

(M) == 必須パラメーター, (O) == 任意のパラメーター

使用例:

zxsuite hsm dodeduplicate secondvolume
Starts a deduplication on volume secondvolume

使用可能なボリューム全てを一覧表示するには、コマンド `zxsuite hsm getAllVolumes` を使用します。

doDeduplicate Stats

doDeduplicate 処理は、 monitor コマンドの対象です。 zxsuite hsm monitor [operationID] コマンドを実行して、このコマンドの統計情報を確認できます。

出力例

Current Pass (Digest Prefix):  63/64
 Checked Mailboxes:             148/148
 Deduplicated/duplicated Blobs: 64868/137089
 Already Deduplicated Blobs:    71178
 Skipped Blobs:                 0
 Invalid Digests:               0
 Total Space Saved:             21.88 GB
  • Current Pass (Digest Prefix) 現在のパス (ダイジェストのプレフィックス) : doDeduplicate コマンドは、BLOBSダイジェスト (名称) の先頭文字を使ってダイジェストをグループ単位で解析します。

  • Checked Mailboxes チェック済メールボックス: 解析された現行パス内メールボックス数。

  • Deduplicated/duplicated Blobs 重複排除/重複Blobs : 現行処理で重複排除されたBLOB数/ボリュームにある合計重複アイテム数。

  • Already Deduplicated Blobs 重複排除済のBlobs : ボリュームにある重複排除済blob数 (以前の実行時に重複排除された重複排除済blobs) 。

  • Skipped Blobs スキップされたBlobs : 解析されなかったBLOB。主な原因は読み込みエラーもしくはファイルが見付からない。

  • Invalid Digests : 不正なダイジェストを持つBLOB (そのファイルの実際のダイジェストとは異なる名前) 。

  • Total Space Saved 総節約量 : doDeduplicate処理により空いたディスク容量。

出力例から次のことが分かります。

  • 最後のメールボックス内最後から2番目のパスに対する実行です。

  • 137089件の重複BLOBが検索され、そのうち71178が以前の実行で重複排除済です。

  • 現行処理で64868件のBLOBが重複排除され、総節約量は21.88GBでした。

高度なボリューム処理

HSM NG: 見えない利点

HSM NGは一見、HSMに特化したものに見えますが、HSMに直接関連しないボリューム関連ツールとしての機能があります。

ボリューム管理における暗黙のリスクのため、ツール機能はCLIからのみ実施可能です。

表面上のボリューム処理

下記のボリューム処理を使用できます。

doCheckBlobs: 1つまたは複数のボリュームに対してBLOBの一貫性チェックを実行します。

doDeduplicate: ボリュームに対してアイテムの重複排除を開始します。

doVolumeToVolumeMove: あるボリュームから別のボリュームに全アイテムを移動します。

getVolumeStats: ボリュームサイズやそこに格納されているアイテム/blobの個数についての情報を表示します。

ボリューム処理分析

doCheckBlobs

使用方法

zimbra@mail:~$ zxsuite hsm doCheckBlobs

コマンドdoCheckBlobsにはパラメーターが必要です。

構文:
   zxsuite hsm doCheckBlobs {start} [attr1 value1 [attr2 value2...

パラメーターリスト

名前                           データ型            期待値            初期値
action(M)                      String          start
volume_ids(O)                  Integer[,..]    1,3
mailbox_ids(O)                 Integer[,..]    2,9,27
missing_blobs_crosscheck(O)    Boolean         true|false         true
traced(O)                      Boolean         true|false         false

(M) == 必須パラメーター, (O) == 任意のパラメーター

使用例:

zxsuite hsm doCheckBlobs start: 全メッセージボリュームに対してBLOBの一貫性チェックを実行します。

zxsuite hsm doCheckBlobs start volume_ids 1,3: ボリューム1と3に対してBLOBの一貫性チェックを実行します。

zxsuite hsm doCheckBlobs start mailbox_ids 2,9,27: メールボックス2、9、27に対してBLOBの一貫性チェックを実行します。

zxsuite hsm doCheckBlobs start missing_blobs_crosscheck false: BLOBの一貫性チェックを実行します。他のボリュームはチェック対象外。

zxsuite hsm doCheckBlobs start traced true: BLOBの一貫性チェックを実行します。正常だったアイテムも含めて、ログを取得します。

説明とヒント

doCheckBlobs処理を使って、ボリュームとメールボックスに対するBLOBの一貫性チェックを実行できます。アイテムのBLOBファイルが検索・アクセスできないため、あるいはBLOBの内容自体に問題があるために起こる、表示エラーや破損エラーの際に有用です。

特に、下記チェックが実施されます。

  • DB-to-BLOB の一貫性: Zimbra DBにある全てのアイテムのエントリに対し、適切なBLOBファイルが存在しているかをチェックします。

  • BLOB-to-DB の一貫性: ボリューム/メールボックスにある全てのBLOBファイルに対し、適切なDBデータが存在しているかをチェックします。

  • ファイル名の一貫性: 各BLOBのファイル名がその内容と一貫性のある名前かどうかをチェックします (BLOBはそのファイルのSHAハッシュにちなんで名づけられるため) 。

  • サイズの一貫性: ボリューム/メールボックスにある全てのBLOBファイルに対し、そのBLOBファイルのサイズが (DBに格納されている) 想定サイズと比べて妥当かどうかをチェックします。

HSM NGを使用するすべてのインフラで、旧 zmblobchk コマンドの代わりに zxsuite hsm doCheckBlobs が使用されるようになりました。
doDeduplicate

使用方法

zimbra@mail:~$ zxsuite hsm doDeduplicate

コマンドdoDeduplicateにはパラメーターが必要です。

構文:
   zxsuite hsm doDeduplicate {volume_name} [attr1 value1 [attr2 value2...

パラメーターリスト

名前              データ型           期待値            初期値
volume_name(M)    String[,..]
dry_run(O)        Boolean        true|false         false

(M) == 必須パラメーター, (O) == 任意のパラメーター

使用例:

zxsuite hsm dodeduplicate secondvolume
ボリュームsecondvolumeに対する重複排除を開始します。
doVolumeToVolumeMove

使用方法

zimbra@mail:~$ zxsuite hsm doVolumeToVolumeMove

コマンドdoVolumeToVolumeMoveにはパラメーターが必要です。

構文:
   zxsuite hsm doVolumeToVolumeMove {source_volume_name} {destination_volume_name}

パラメーターリスト

名前                          データ型
source_volume_name(M)         String
destination_volume_name(M)    String

(M) == 必須パラメーター, (O) == 任意のパラメーター

使用例:

zxsuite hsm doVolumeToVolumeMove sourceVolume destVolume
sourceVolume全体をdestVolumeに移動します。

説明とヒント

このコマンドは、ボリュームの使用を止めなくてはならない全ての場面、例えば下記のような場面で、非常に有用です。

  • 古いハードウェアの廃棄: 物理サーバーにある古いディスクを取り除きたい場合、別の/新しいディスクに新規ボリュームを作成して、そこにデータを移動します。

  • 些細な誤り の修正: 間違えて誤った場所に新規ボリュームを作成した場合、他のボリュームにそのデータを移動します。

  • ボリュームの集中化: ボリュームを好きなように集中化・移動させます。例えば、ストレージインフラを再設計した場合やZimbraボリュームを整理している場合です。

getVolumeStats

使用方法

zimbra@mail:~$ zxsuite hsm getVolumeStats

コマンドgetVolumeStatsにはパラメーターが必要です。

構文:
   zxsuite hsm getVolumeStats {volume_id} [attr1 value1 [attr2 value2...

パラメーターリスト

名前                   データ型       期待値            初期値
volume_id(M)           Integer
show_volume_size(O)    Boolean    true|false         false
show_blob_num(O)       Boolean    true|false         false

(M) == 必須パラメーター, (O) == 任意のパラメーター

使用例:

**注意** オプションshow_volume_sizeとshow_blob_numはIOインテンシブであるため、初期値では無効です。

zxsuite hsm getVolumeStats 2
ID=2であるボリュームの統計情報を表示します。

説明とヒント

このコマンドはボリュームについて下記情報を表示します。

名称 説明

id

ボリュームのID

name

ボリュームの名称

path

ボリュームのパス

compressed

圧縮の有効・無効

threshold

圧縮のしきい値 (バイト単位)

lastMoveOutcome

直近のdoMoveBlobs処理の終了ステータス

lastMoveTimestamp

直近のdoMoveBlobs処理の終了時間

lastMoveDuration

直近のdoMoveBlobs処理の実行時間

lastItemMovedCount

直近のdoMoveBlobs処理中に現在のセカンダリボリュームに移動したアイテム数

bytesSaved

直近のdoMoveBlobs処理中に重複排除と圧縮のおかげで空いたディスク容量

bytesSavedLast

重複排除と圧縮のおかげで空いたディスク総容量

オプション show_volume_sizeshow_blob_num により、次のデータが追加出力されます。

オプション 名称 説明

show_volume_size

totSize

そのボリュームで使われたディスク総容量

show_blob_num

blobNumber

そのボリューム内BLOBファイル数

メールストア間でのメールボックス移動

doMailboxMove コマンドを使用して、あるドメインまたはメールボックスサーバーにあるシングルメールボックスあるいは全アカウントを同じZimbraインフラ内の別の場所へ移動することができます。

HSM NGモジュールがインストールされていて有効な場合、このコマンドは旧 zmmboxmove コマンドと zmmailboxmove コマンドに代わり使用されます。従来のコマンドを使用してもエラーが返され、データ移動は行なわれません。

使用方法

構文:
   zxsuite hsm doMailboxMove {an account name: john@example.com or a domain name: example.com} {destinationHost} [attr1 value1 [attr2 value2...]]

パラメーターリスト

名前                  データ型               期待値                                                          初期値
name(M)               String             アカウント名なら: john@example.com ドメインなら: example.com
destinationHost(M)    String
sourceHost(O)         String             nameパラメーターにドメインを指定した場合に使用
stage(O)              複数選択肢           blobs|db|chat_db|ldap|backup|reindex|delete|all                          all
compress(O)           Boolean            true|false                                                               true
checkDigest(O)        Boolean            falseの場合、ダイジェスト計算とチェックは実施されない                               true
overwrite(O)          Boolean            true|false                                                               false
threads(O)            Integer                                                                                     10
hsm(O)                Boolean            true|false                                                               true
notifications(O)      Email Address

(M) == 必須パラメーター, (O) == 任意のパラメーター

使用例:

zxsuite HSM NG domailboxmove john@example.com mail2.example.com
アカウントjohn@example.comのメールボックスをmail2.example.comのホストに移動します。

パラメーター

  • sourceHost: nameパラメーターにドメインを指定した場合にのみ使用。このホストからコマンドを実行したかのように動作します。

  • stage: 一度にシングルステージのみ実施可能です。テスト目的のためや、完了済みのステージを再実行しないためです。

  • compress: trueの場合、ネットワーク経由で送信する直前のblobsを圧縮します。

  • checkDigest: trueの場合、blobごとにダイジェストチェックを行います (ダイジェストはアイテムのDBエントリから取得します) 。

  • overwrite: falseの場合かつダイジェストチェック結果が正常な場合にblobファイルが上書きされることはありません。

  • threads: 重いステージで使用されるスレッド数。

  • hsm: trueの場合、メールボックスが正常に移動された後にHSM 処理が実行されます。

doMailboxMoveの詳細説明

  • ドメイン移動の場合、現サーバーからアカウントごとに順次移動します。

  • メールボックスは、移動されるときにメンテナンスモードへと設定されます。そして、全メールが移動されたあと (ldapステージのあと) 、元のステータスへと更新されます。

  • 移動中のアイテムに関する書き込みエラーが5%以上であるとカウントされると、処理は停止されます。 留意すべきこととして、現メールボックスはメンテナンスモード状態に留まる可能性があります。

  • 移動先サーバーで使用できる容量が不足していたり、ユーザーが移動先ホストに属しているだけの場合、シングルメールボックス移動は開始されません。

  • 全てのデータは下流レベルで移動され、メールボックスIDなど些細なことを除き、データが変更されることはありません。

  • 処理は blobs|db|chat_db|ldap|backup|reindex|delete の7つのステージで構成されています。 メールボックス単位です。

    • blobs: 全てのblobが移動元サーバーから移動先サーバーにコピーされます。

    • db: 全てのチャットDB情報が移動元サーバーから移動先サーバーにコピーされます。

    • chat_db: 全てのチャットDB情報が移動元サーバーから移動先サーバーにコピーされます。

    • ldap: zimbraMailHostのldap属性が更新され、全アカウントのキャッシュがフラッシュされます。

    • backup: 全てのバックアップエントリが移動元サーバーから移動先サーバーにコピーされます。

    • reindex: メールボックスの再インデックスが開始されます。

    • delete: 全てのblobとDBエントリが移動元サーバーから削除され、バックアップアイテムも削除済としてマークされます。

  • 全てのステージは順に実行されます。単一ステージが指定された場合、メールボックスは、処理中ずっとメンテナンスモードのままです。正常終了時に、元ステータスへと更新されます。

  • 最初、全てのblobアイテムが移動先サーバーのプライマリボリュームに格納されます。

  • 再インデックスのステージが完了すると、移動先サーバーでHSM処理が新たに実行されます。ただし、指定がない場合に限ります。

  • 全てのボリュームの圧縮オプションが実行されます。

  • MailboxMove処理は、移動元サーバーで他の処理が実行中でない場合にのみ実行可能です。

  • HSMオプションでは現在のHSMポリシーを適用します。各メールボックスが正常に移動された後、実行されます。実行により、アイテムが移動されることになります。

HSM NG による添付のインデックス化

インデックスの機能

添付されたコンテンツをインデックス化するため、インデックス化エンジンがHSM NGに新規追加されました。

インデックス化エンジンは、元々Zimbraに備わっているエンジンと連動して機能します。メインであるZimbraのインデックス化処理がアイテムの内容を解析。オブジェクトのMIME部分に基づきアイテムを複数パートに分割します。その後、Zimbraは 旧知の 内容、つまり平文のインデックス化処理を行い、その他残り全ての内容を処理するHSM NGハンドラにデータストリームを引渡します。

解析済み内容のインデックス化処理を高速化するインデックス化キャッシュ機能がインデックス化エンジンに搭載されています。10KBを超すデータストリームは、デフォルトでキャッシュされ、キャッシュにはエントリ10,000件が保持されます。一方、小さいデータストリームはキャッシュされません。大きなデータストリームの場合にしかキャッシュの利点がないからです。

インデックスの形式

Web
拡張子 パーサ (解析担当) 内容のタイプ

asp

HtmlParser

application/x-asp

htm

HtmlParser

application/xhtml+xml

html

HtmlParser

application/xhtml+xml, text/html

shtml

HtmlParser

application/xhtml+xml

xhtml

HtmlParser

application/xhtml+xml

ドキュメント
拡張子 パーサ (解析担当) 内容のタイプ

rtf

RTFParser

application/rtf

pdf

PDFParser

application/pdf

pub

OfficeParser

application/x-mspublisher

xls

OfficeParser

application/vnd.ms-excel

xlt

OfficeParser

application/vnd.ms-excel

xlw

OfficeParser

application/vnd.ms-excel

ppt

OfficeParser

application/vnd.ms-powerpoint

pps

OfficeParser

application/vnd.ms-powerpoint

mpp

OfficeParser

application/vnd.ms-project

doc

OfficeParser

application/msword

dot

OfficeParser

application/msword

msg

OfficeParser

application/vnd.ms-outlook

vsd

OfficeParser

application/vnd.visio

vst

OfficeParser

application/vnd.visio

vss

OfficeParser

application/vnd.visio

vsw

OfficeParser

application/vnd.visio

xlsm

OOXMLParser

application/vnd.ms-excel.sheet.macroenabled.12

pptm

OOXMLParser

application/vnd.ms-powerpoint.presentation.macroenabled.12

xltx

OOXMLParser

application/vnd.openxmlformats-officedocument.spreadsheetml.template

docx

OOXMLParser

application/vnd.openxmlformats-officedocument.wordprocessingml.document

potx

OOXMLParser

application/vnd.openxmlformats-officedocument.presentationml.template

xlsx

OOXMLParser

application/vnd.openxmlformats-officedocument.spreadsheetml.sheet

pptx

OOXMLParser

application/vnd.openxmlformats-officedocument.presentationml.presentation

xlam

OOXMLParser

application/vnd.ms-excel.addin.macroenabled.12

docm

OOXMLParser

application/vnd.ms-word.document.macroenabled.12

xltm

OOXMLParser

application/vnd.ms-excel.template.macroenabled.12

dotx

OOXMLParser

application/vnd.openxmlformats-officedocument.wordprocessingml.template

ppsm

OOXMLParser

application/vnd.ms-powerpoint.slideshow.macroenabled.12

ppam

OOXMLParser

application/vnd.ms-powerpoint.addin.macroenabled.12

dotm

OOXMLParser

application/vnd.ms-word.template.macroenabled.12

ppsx

OOXMLParser

application/vnd.openxmlformats-officedocument.presentationml.slideshow

odt

OpenDocumentParser

application/vnd.oasis.opendocument.text

ods

OpenDocumentParser

application/vnd.oasis.opendocument.spreadsheet

odp

OpenDocumentParser

application/vnd.oasis.opendocument.presentation

odg

OpenDocumentParser

application/vnd.oasis.opendocument.graphics

odc

OpenDocumentParser

application/vnd.oasis.opendocument.chart

odf

OpenDocumentParser

application/vnd.oasis.opendocument.formula

odi

OpenDocumentParser

application/vnd.oasis.opendocument.image

odm

OpenDocumentParser

application/vnd.oasis.opendocument.text-master

ott

OpenDocumentParser

application/vnd.oasis.opendocument.text-template

ots

OpenDocumentParser

application/vnd.oasis.opendocument.spreadsheet-template

otp

OpenDocumentParser

application/vnd.oasis.opendocument.presentation-template

otg

OpenDocumentParser

application/vnd.oasis.opendocument.graphics-template

otc

OpenDocumentParser

application/vnd.oasis.opendocument.chart-template

otf

OpenDocumentParser

application/vnd.oasis.opendocument.formula-template

oti

OpenDocumentParser

application/vnd.oasis.opendocument.image-template

oth

OpenDocumentParser

application/vnd.oasis.opendocument.text-web

sxw

OpenDocumentParser

application/vnd.sun.xml.writer

パッケージとアーカイブ
拡張子 パーサ (解析担当) 内容のタイプ

z

CompressorParser

application/x-compress

bz

CompressorParser

application/x-bzip

boz

CompressorParser

application/x-bzip2

bz2

CompressorParser

application/x-bzip2

gz

CompressorParser

application/gzip

gz

CompressorParser

application/x-gzip

gzip

CompressorParser

application/x-gzip

xz

CompressorParser

application/x-xz

tar

PackageParser

application/x-tar

jar

PackageParser

application/java-archive

7z

PackageParser

application/x-7z-compressed

cpio

PackageParser

application/x-cpio

zip

PackageParser

application/zip

rar

RarParser

application/x-rar-compressed

txt

TXTParser

text/plain

パーサ (解析担当) の制御

CLIコマンド zxsuite config を使って、関連する値の truefalse を変更することで、パーサのオン・オフを切り替えることができます。

属性 パーサ (解析担当)

pdfParsingEnabled

PDFParser

odfParsingEnabled

OpenDocumentParser

archivesParsingEnabled

CompressorParser, PackageParser, RarParser

microsoftParsingEnabled

OfficeParser, OOXMLParser, OldExcelParser

rtfParsingEnabled

RTFParser

例: PDFの解析実行を無効にするには次を実行します。 zxsuite config server set server.domain.com attribute pdfParsingEnabled value false

デフォルトでは全てのパーサがアクティブです。

ABQ サービス

Zimbra Collaboration 8.8.15 で追加された: "Allow/Block/Quarantine" で追加された機能は、サーバへ接続するモバイルデバイスの個別アクセス管理が可能です。これは「事前型」のセキュリティ機能であるため、サーバへ初めて接続した際に稼働し、許可されているデバイスのみに同期を行えるように設計しています。この機能では完全の管理者は運用中のシステムネットワーク上ですべてのモバイルデバイスを監視できます。 現時点では、CLI のツールのみを提供しており、ウェブ上の GUI をリリースする予定です。

コンポネントの詳細について

ABQ 機能では3つのメインコンポネントが含まれています:

  • デバイスの管理リスト

  • 認証するエンジン

  • CLIツールのセット

デバイスの管理リスト

"ABQリスト"と呼ばれるデバイスの管理リストには NG の設定エンジンで許可しているデバイスの情報が保管しています。 CLI でデバイスの "Device ID" を取得することで、別の CLI コマンドでデバイス管理リストへそのデバイスを追加することが可能です。

また、さらなるアクセス制限として、特定デバイスにサーバと同期できるアカウントに制限することも可能です。

注意:モジュールの起動時では、デバイス管理リストが空であれば、Zimbra サーバが以前から認識しているモバイルデバイスはすべて Allowed としてインポートします。

認証エンジン

認証エンジンはデバイスをデバイス管理リストに確認し、適切の ABQ ステータスを設定します。

各ルールは Device ID で特定するデバイスから接続するすべてのアカウントへ適用します。device_id/account_id または device_id/accountName 等のルールである場合、そのデバイスにある特定のアカウントへのみ適用します。

CLI ツール

CLI ツールで管理者がデバイス管理リスト、およびデバイスの同期ステータスを直接に操作し、以下のような活動が可能です。

  • デバイス管理リストを閲覧する

  • Quarantined と Blocked のデバイスを閲覧する

  • デバイス管理リストへデバイスを追加する

  • デバイスのステータスを "Quarantine" から "Allowed" や "Blocked" へ移動する

  • デバイスの同期ステータスを変更する

管理者が ABQ を有効化している環境にデバイスのステータスを変更する際、指定した新しいステータスにより、デバイスがサーバとすべてのフォルダー同期を強制的に再実行する場合がありますので、ユーザーは直ちに発生した現象を説明するdummy virtual mailboxへ誘導されるか、再同期が必要となる実際のメールボックスへ誘導されます。

ABQ モード

ABQ 機能はサーバとの同期を開始するすべてのモバイルデバイスに起動し、4つのモードとして稼働するように設定できます: "Permissive", "Interactive", "Strict” および "Disabled"。 この属性値はクラスタ内にグローバルの設定となります。

"Permissive" モードについて:

認証エンジンが無効化しておりますので、ユーザー認証とアカウントステータスの確認が完了後、同期が開始します。特定デバイスのアクセスを拒否することが可能ですが、アクセス拒否を指定していないデバイスはすべて同期可能の状態です。

"Interactive" モードについて:

ユーザー認証とアカウントステータスの確認が完了後、デバイス管理システムはデバイスから送信する "Device ID" を許可しているデバイスリストに確認します。

  • デバイス/アカウントの組み合わせが「許可」のリストにあれば、同期が開始します。

  • デバイス/アカウントの組み合わせがデバイスのリストに指定していないが、デバイスが「許可」のリストにあれば、同期が開始します。

  • デバイスが「許可」のリストに指定したいない場合、同期が保留され、ユーザーに "Quarantine" 状態の通知メールが送信し、接続が "Quarantine" のステータスに変わります。

管理者が定時的に通知を受信することが可能です。なお、通知メールでは新しい Quarantine されたデバイスのみが報告されます。 通知の詳細を確認した上、管理者が適切の CLI ツールを活用し、各デバイスへの同期を許可か拒否することが可能です。

"Strict" モードについて:

ユーザー認証とアカウントステータスの確認が完了後、デバイス管理システムはデバイスから送信する "Device ID" を許可しているデバイスリストに確認します。

  • デバイス/アカウントの組み合わせ、またはデバイスのみが「許可」のリストにあれば、同期が開始します。

  • デバイスが「許可」のリストに指定したいない場合、同期が完全に拒否され、ユーザーに "Blocked" 状態の通知メールが送信します。

"Disabled" モードについて:

ABQ が無効化しており、確認が行わず、ポリシーが適用されません。

ABQ モード管理

現在のモードは以下のコマンドで確認できます:

zxsuite config global get attribute abqMode

ABQモードは以下のコマンドで変更することが可能です:

zxsuite config global set attribute abqMode value [Permissive|Interactive|Strict|Disabled]

ダミーデータ

この機能は「ダミーメール」と「ダミーメールボックス」を活用し、デバイスにアクセス許可を得るために同期を一旦保留する(Interactiveモード)、または "blocked" 状態をお知らせする(Permissiveモード、Interactiveモード、およびStrictモード)。

ダミーメールボックスは「受信トレイ」のフォルダーのみを持つ仮想メールボックスであり、デバイスがQuarantine、またはBlockedのステータスでのみデバイスへ同期します。該当のダミーメールボックスに含まれているダミーメールのメッセージは事前に指定した通知メッセージであり、ユーザー様にデバイスのステータスを知らせするためのものです。現時点では、これらのメッセージのカスタマイズができない状態であり、今後の更新で異なる言語へ翻訳される予定です。デバイスの ABQ ステータスが変更する度、デバイスの同期ステートがリセットされます。

エンドユーザー様に発生していることを明確に通知でいるように設計しております。この仕様がなければ、同期が理由なしで失敗するのみなので、エンドユーザー様が原因と特定できず、サポートのヘルプデスクへの依頼が増加することを想定していました。

通知

管理者が NG モジュール属性値の abqNotificationsInterval にて、リ秒単位で Quarantine となったデバイスの通知を受信することが可能です。

現在の設定は以下のコマンドで確認できます。

zxsuite config global get attribute abqNotificationsInterval

以下のコマンドで設定を更新することが可能です。

zxsuite config global set attribute abqNotificationsInterval value [delay in milliseconds]

デフォルトでは、abqNotificationsInterval が「0」となっていますので、通知の送受信が行いません。

ABQ サービスのステータスについて

ABQ サービスのステータスは以下のコマンドで確認できます。

zxsuite mobile getServices

Mobile NG モジュールのデフォルトサービス管理で本サービスの停止や起動することが可能です。

zxsuite mobile doStartService abq
zxsuite mobile doStopService abq

なお、モードがDisabledの場合、ABQサービスが自動的に開始せず、デバイスの同期は常に許可します。

ABQ CLI

利用可能の ABQ CLI コマンドのリストは以下のコマンドで確認することが可能です。

$ zxsuite mobile abq

Allow/Block/Quarantine mobile devices management
モバイルデバイス管理 許可/ブロック/隔離

    list                    - デバイスのリスト
                              zxsuite mobile ABQ list [attr1 value1 [attr2 value2...] ]

    add                     - デバイスの追加/インポート
                              zxsuite mobile ABQ add [attr1 value1 [attr2 value2...] ]

    allow                   - 隔離されたデバイスの同期を許可します。
                              zxsuite mobile ABQ allow {device_id}

    block                   - 隔離されたデバイスの同期を拒否します。
                              zxsuite mobile ABQ block {device_id}

    set                     - デバイスの同期状態を設定します。
                              zxsuite mobile ABQ set {device_id} {Allowed|Blocked|Quarantined}

    delete                  - ABQからデバイスを削除します。
                              zxsuite mobile ABQ delete {device_id}

    setNotificationInterval - 新しく隔離されたデバイスの通知間隔を設定します。
                              zxsuite mobile ABQ setNotificationInterval {45m|6h|1d|0}

ABQ "list" コマンドについて

すべてのデバイスの ABQ ステータスを表示します。"status" のオプションを活用することで、指定したステータスのデバイスのみを表示させることも可能です。

$ zxsuite mobile abq list
デバイスをリスト表示します。

構文:
   zxsuite mobile ABQ list [attr1 value1 [attr2 value2...] ]


パラメーターリスト

名前        タイプ    期待値
status(O)   String  Allowed|Blocked|Quarantined

(M) == 必須パラメーター, (O) == 任意のパラメーター

実例:

[zimbra@mail ~]$ zxsuite mobile abq list

        devices

                device_id   androidc133785981
                status      Quarantined

                device_id   androidc1024711770
                status      Blocked

                device_id   SAMSUNG1239862958
                status      Allowed

ABQ "import" コマンドについて

このコマンドはファイルから device ID のリストをインポートし、必ず2つのパラメータを指定する必要があります: 改行でDevice IDを区切ったリストのインプットファイル、およびインポートしたデバイスに指定するステータスです。

[zimbra@mail ~]$ zxsuite mobile abq import
importコマンドは、より多くのパラメータを必要とします。

構文:
    zxsuite mobile ABQ import {Path to file} {Allowed|Blocked|Quarantined}

パラメーターリスト

名前            タイプ        期待値
input_file(M)   String      Path to file
status(M)       String      Allowed|Blocked|Quarantined

(M) == 必須パラメーター, (O) == 任意のパラメーター

使用例:

zxsuite mobile ABQ import /path/to/file Allowed

実例:

[zimbra@mail ~]$ zxsuite mobile abq import /tmp/list Allowed
3 devices added

[zimbra@mail ~]$ cat /tmp/list
androidc133785981
androidc1024711770
SAMSUNG1239862958/user@domain.com

上記の実例では、androidc133785981androidc1024711770 のデバイスはアカウントを問わずに同期が許可しておりますが、SAMSUNG1239862958 のデバイスでは user@domain.com のアカウントのみに同期が許可していることを示しています。

ABQ "allow" コマンドについて

このコマンドは Quarantined デバイスへのみ使用するコマンドであり、デバイスステータスを Allowed へ変更します。

$ zxsuite mobile abq allow
隔離されたデバイスの同期を許可します。

構文:
   zxsuite mobile ABQ allow {device_id} [attr1 value1 [attr2 value2...]]

パラメーターリスト

名前            タイプ      期待値
device_id(M)    String
account(O)      String    27ee8dd9-d813-4ca7-a988-580df0027a58|user1@example.com


(M) == 必須パラメーター, (O) == 任意のパラメーター

ABQ "block" コマンドについて

このコマンドは Quarantined デバイスへのみ使用するコマンドであり、デバイスステータスを Blocked へ変更します。

$ zxsuite mobile abq block
隔離されたデバイスの同期を拒否します。

構文:
   zxsuite mobile ABQ block {device_id} [attr1 value1 [attr2 value2...]]

パラメーターリスト

名前            タイプ      期待値
device_id(M)    String
account(O)      String    27ee8dd9-d813-4ca7-a988-580df0027a58|user1@example.com

(M) == 必須パラメーター, (O) == 任意のパラメーター

ABQ "set" コマンドについて

特定デバイス(既存のデバイス、または不明のデバイス)に任意のステータスを設定します。

$ zxsuite mobile abq set
デバイスの同期状態を設定します。

構文:
   zxsuite mobile ABQ set {device_id} {Allowed|Blocked|Quarantined} [attr1 value1 [attr2 value2...]]

パラメーターリスト

名前            タイプ      期待値
device_id(M)    String
status(M)       String    Allowed|Blocked|Quarantined
account(O)      String    27ee8dd9-d813-4ca7-a988-580df0027a58|user1@example.com

(M) == 必須パラメーター, (O) == 任意のパラメーター

ABQ "delete" コマンドについて

デバイスをすべてのリストから削除します。

$ zxsuite help mobile abq delete
ABQからデバイスを削除します。

構文:
   zxsuite mobile ABQ delete {device_id} [attr1 value1 [attr2 value2...]]

パラメーターリスト

名前            タイプ      期待値
device_id(M)    String
account(O)      String    27ee8dd9-d813-4ca7-a988-580df0027a58|user1@example.com

(M) == 必須パラメーター, (O) == 任意のパラメーター

ABQ "setNotificationInterval" コマンドについて

新しく Quarantine されたデバイスの通知期間を設定する。

$ zxsuite mobile abq setNotificationInterval
setNotificationIntervalコマンドは、より多くのパラメーターを必要とします。

構文:
    zxsuite mobile ABQ setNotificationInterval {45m|6h|1d}

パラメーターリスト

名前            タイプ        期待値
interval(M)     String      45m|6h|1d

(M) == 必須パラメーター, (O) == 任意のパラメーター

使用例:

新しく隔離されたデバイスを45分毎に通知します。
    zxsuite mobile abq setNotificationInterval 45m
新しく隔離されたデバイスを6時間毎に通知します。
    zxsuite mobile abq setNotificationInterval 6h
新しく隔離されたデバイスを毎日に通知します。
    zxsuite mobile abq setNotificationInterval 1d
新しく隔離されたデバイスの通知を無効にします。
    zxsuite mobile abq setNotificationInterval 0

管理NG

委任管理のプロビジョニング

委任管理のプロビジョニングとは

委任管理のプロビジョニングとは、ユーザーへドメイン管理の権限を付与したり、またその編集や取消を行なうことのできる処理全般を指します。

全ての委任管理のプロビジョニング処理は、下記にて実施することができます。

  • 管理拡張機能の管理NGタブから。

  • CLIから zimbraユーザー にて該当の zxsuite コマンドを実行。

委任管理の権限をユーザーへ付与する

管理拡張機能から

管理拡張機能の管理NGタブ内、委任された管理者 セクションにある 追加 ボタンをクリックします。

下記情報の入力が促されます。

  • アカウント: 委任管理の権限を付与したいメールアドレス

  • ドメイン: 委任された管理者による管理の対象となるドメイン

  • 委任された認証: チェックがオンのとき、委任された管理者は選択されたドメインの全メールボックスの メールを表示 機能を利用できます。

  • 権限の制限: 委任された管理者が対象ユーザーアカウントの機能タブの内容を編集できるかどうかを定義します。

  • 機能を編集: 委任された管理者が対象ユーザーアカウントの 機能 タブの内容を編集できるかどうかを定義します。

権限の制限 の値より、 ドメイン単位での割り当て使用量 が小さい場合、 権限の制限 は無効になります。
ディスク容量と容量制限はギガバイト単位(gb)、メガバイト単位 (mb)、キロバイト単位(kb)のいずれも入力可能です。
CLIから

委任管理の権限をユーザーへ付与するには、 doAddDelegationSettings コマンドを使用します。

構文:
   zxsuite admin doAddDelegationSettings {account} {domain} [attr1 value1 [attr2 value2...]]

パラメーターリスト

名前             データ型       期待値            初期値
account(M)       String
domain(M)        String
viewMail(O)      Boolean    true|false         false
editFeatures(O)  Boolean    true|false         false
adminQuota(O)    String                        -1

(M) == 必須パラメーター, (O) == 任意のパラメーター

使用例:


zxsuite admin doAddDelegationSettings john@example.com example.com viewMail true adminQuota -1
ドメインexample.comの委任された管理者としてJohnを追加。このドメインのメールを表示する権限あり。また、ユーザーに容量を割り当てられる権限なし。

zxsuite admin doAddDelegationSettings john@example.com example.com adminQuota 0
ドメインexample.comの委任された管理者としてJohnを追加。ユーザーに無制限の容量を割り当てられる権限あり。

zxsuite admin doAddDelegationSettings john@example.com example.com adminQuota 10gb
ドメインexample.comの委任された管理者としてJohnを追加。各ユーザーに10GBまでは容量を割り当てられる権限あり。

既存の委任管理の権限を編集する

管理拡張機能から

管理拡張機能の管理NGタブ内、委任された管理者 の一覧から1件選択し、編集 ボタンをクリックします。

対象の行のダブルクリックにより、編集することも可能です。

CLIから

既存の委任管理の権限を編集するには、 doEditDelegationSettings コマンドを使用します。

構文:
   zxsuite admin doEditDelegationSettings {account} {domain} [attr1 value1 [attr2 value2...]]

パラメーターリスト

名前             データ型       期待値
account(M)       String
domain(M)        String
viewMail(O)      Boolean    true|false
editFeatures(O)  Boolean    true|false
adminQuota(O)    String

(M) == 必須パラメーター, (O) == 任意のパラメーター

使用例:

zxsuite admin doEditDelegationSettings john@example.com example.com viewMail true adminQuota -1
ドメインexample.comの委任された管理者としてのJohnの権限を編集。このドメインのメールを表示する権限をありにし、ユーザーに容量を割り当てられる権限をなしにする。

zxsuite admin doEditDelegationSettings john@example.com example.com adminQuota 0
ドメインexample.comの委任された管理者としてのJohnの権限を編集。ユーザーに無制限の容量を割り当てられる権限をありにする。

zxsuite admin doEditDelegationSettings john@example.com example.com adminQuota 10gb
ドメインexample.comの委任された管理者としてのJohnの権限を編集。各ユーザーに10GBまでは容量を割り当てられる権限をありにする。

委任管理の権限を取り消す

管理拡張機能から

管理拡張機能の管理NGタブ内、委任された管理者 の一覧から1件選択し、削除 ボタンをクリックします。

CLIから

委任管理の権限を取り消すには、 doRemoveDelegationSettings コマンドを使用します。

構文:
   zxsuite admin doRemoveDelegationSettings {account} {domain}

パラメーターリスト

名前          データ型
account(M)    String
domain(M)     String

(M) == 必須パラメーター, (O) == 任意のパラメーター

使用例:

zxsuite admin doRemoveDelegationSettings john@example.com example.com
Johnはドメインexample.coの管理者ではなくなる。

容量管理

容量管理とは

管理NGでは、システム管理者が 権限の制限ドメイン単位での割り当て使用量 という2種類の容量制限を設定できます。

どちらも必須ではありません。つまり、設定されていない場合、委任された管理者は任意の容量をユーザーに与えることも、容量制限のないドメインにすることもできます。

権限の制限

権限の制限 とは、委任された管理者のプロパティのひとつです。

このプロパティの値は、委任された管理者がユーザーに与えることのできるメールボックス容量の制限値を示しています。委任された管理者の設定からこの値の入力・変更を行ないます。

このプロパティの値には、下記3つの選択肢があります。

  • なし : 委任された管理者は、メールボックスに関する容量属性を編集できません。

  • カスタム : 委任された管理者は、指定された値までであれば付与できます。この値はドメイン/提供サービス(COS)の容量設定にオーバーライドします。

  • 無制限 : 委任された管理者はメールボックスに対する容量を制限なく付与できます。これはドメイン/提供サービス(COS)の容量設定にオーバーライドします。

ドメイン単位での割り当て使用量

ドメイン単位での割り当て使用量 とは、管理者のタイプに関わらず 、そのドメインのメールボックスに与えることのできる容量の制限値を示すプロパティです。

メールボックスに対する容量を制限なく付与することは、ドメイン単位での割り当て使用量にオーバーライドします。

権限の制限 vs ドメイン単位での割り当て使用量

権限の制限ドメイン単位での割り当て使用量 は、制限ベースで互いに排他です。

つまり、以下のシナリオが起こりえます。

  • システム管理者が、許可されたドメイン単位での割り当て使用量よりも大きな容量をユーザーに付与。

  • 委任された管理者が、許可されたドメイン単位での割り当て使用量よりも大きな容量をユーザーに付与。

  • 委任された管理者の権限の制限の値が、許可されているドメイン単位での割り当て使用量よりも低い。

このシナリオをひとつずつ検証してみます。

システム管理者が、許可されたドメイン単位での割り当て使用量よりも大きな容量をユーザーに付与

ドメイン単位での割り当て使用量は管理者ではなくドメインに適用されるため、ユーザーが使用できる最大容量は、 ドメイン単位での割り当て使用量 の設定で許可されている容量制限値となります。

委任された管理者が、許可されたドメイン単位での割り当て使用量よりも大きな容量をユーザーに付与

委任された管理者の権限の制限の値のほうが許可されているドメイン単位での割り当て使用量より大きい場合、ユーザーが使用できる最大容量は、 ドメイン単位での割り当て使用量 の設定で許可されている容量制限値となります。

委任された管理者の権限の制限の値が、許されているドメイン単位での割り当て使用量よりも小さい

許可されたドメイン単位での割り当て使用量のほうが大きい場合、委任された管理者がユーザーに付与できる最大容量は、委任された管理者の権限の制限として定義されている容量制限値です。権限の制限のないシステム管理者の場合は、ドメイン単位での割り当て使用量で許可された範囲内で付与できます。

ドメイン制限

ドメイン制限の管理とは(ドメイン設定 とも言います)

ドメイン制限の管理は、管理NGモジュールの一機能です。システム管理者は、管理者のタイプに関わらず遵守しなければならないドメインレベル制限を設定することができます。

ドメイン制限を破るには、ドメイン制限自体を変更するしかありません。

ドメイン制限

  • グローバルアカウント制限: このドメインで作成可能な最大アカウント数。

  • ドメイン単位での割り当て使用量: 管理者のタイプに関わらず、そのドメインのメールボックスに付与可能な容量の制限値。

  • 提供サービス(COS)制限:ドメインのユーザーが使用できる提供サービスと、提供サービス(COS)の最大ユーザー数(アカウント制限)を定義します。

ドメイン制限の編集

管理拡張機能から

管理拡張機能の管理NGタブ内 ドメイン設定 の一覧には、Zimbraインフラにある全ドメインが表示されます。

ドメイン制限を編集するには、 ドメイン設定 の一覧から1件選択し、 編集 ボタンをクリックします。

CLIから

CLIからドメイン制限を編集するには、 setDomainSettings コマンドを使用します。

構文:
   zxsuite admin setDomainSettings {domain} [attr1 value1 [attr2 value2...

パラメーターリスト

名前                       データ型       期待値                   初期値
domain(M)                  String
account_limit(O)           Integer                                       設定変更しないこと。
domain_account_quota(O)    String                                        設定変更しないこと。
cos_limits(O)              String     cosname1:limit1,cosname2:limit2    設定変更しないこと。

(M) == 必須パラメーター, (O) == 任意のパラメーター

使用例:


zxsuite admin setDomainSettings example.com account_limit 100 domain_account_quota 100mb cos_limits cos1:30,cos2:80

ドメインexample.comのグローバルアカウント制限には100アカウント、
ドメイン単位での割り当て使用量の制限値には100メガバイト、提供サービス(COS)のアカウント制限としてcos1には30、cos2には80を設定します。

Note: 提供サービス(COS)のアカウント制限に-1を設定すると、制限はなくなります。

ドメイン制限のリセット

管理拡張機能から

管理拡張機能の管理NGタブ内 ドメイン設定 の一覧には、Zimbraのインフラにある全ドメインが表示されます。

ドメイン制限をリセットするには、 ドメイン設定 の一覧から1件選択し、リセット ボタンをクリックします。その後表示される確認用ポップアップ画面で OK をクリックします。

CLIから

CLIからドメイン制限をリセットするには、 resetDomainSettings コマンドを使用します。

構文:
   zxsuite admin resetDomainSettings {domain}

パラメーターリスト

名前         データ型
domain(M)    String

(M) == 必須パラメーター, (O) == 任意のパラメーター

委任された管理者としてZimbraを管理する

委任された管理者としてZimbra管理コンソールにアクセスする

Zimbra管理コンソールにアクセスするには、ウェブブラウザからメールサーバーポート7071に接続し、自身のZimbra認証を使用してログインします。

委任された管理者ができること・できないことの一覧

参照用に以下、委任された管理者が管理NGモジュールでできること・できないことを表に記します。

できること できないこと

委任管理権限を持つドメインに属するアカウント一覧の閲覧

他のドメインに属するアカウント一覧の閲覧

委任管理権限を持つドメインに属するユーザーアカウントの編集

他のドメインに属するユーザーアカウントの編集

委任管理権限を持つドメインに属するエイリアス、配布リスト、リソースの編集

他のドメインに属するエイリアス、配布リスト、リソースの編集

システム管理者アカウントの編集

システム管理権限あるいは委任管理権限を他のユーザーへ付与

委任管理権限を持つドメインのアカウントを作成

他のドメインのアカウント作成

対象アカウントのドメインで使用できる提供サービス(COS)を選択

対象サーバーで使用できる提供サービス(COS)を任意で設定

提供サービス(COS)の設定

サーバー本来の機能を妨げる可能性のあるドメイン設定の編集

サーバー設定の閲覧・編集

グローバル設定の閲覧・編集

委任された管理者としてログインした場合のZimbra管理コンソール使用概要
  • 管理:

    • アカウント: 委任管理権限を持つドメインに属するアカウントの管理

    • エイリアス: 委任管理権限を持つドメインに属するアカウントエイリアスの管理

    • 配布リスト: 委任管理権限を持つドメインに属する配布リストの管理

    • リソース:委任管理権限を持つドメインに属するリソースの管理

  • 設定: 委任管理権限を持つドメインの設定の閲覧

  • 検索: 高度な検索の実行

  • Network NG

    • モバイルタブ: 委任管理権限を持つドメインに属するクライアント・モバイルデバイス間の同期管理

    • 管理タブ: 委任管理権限を持つドメインに属する委任された管理者の一覧と容量利用に関する情報の閲覧

  • キーワード検索機能バー: 簡易検索の実行

  • [ユーザー名]: Zimbra管理コンソールからのログアウト

委任された管理者のログ閲覧

委任された管理者のログ閲覧とは

システム管理者は全管理者のアクティビティ情報を検索ベースでグラフィックなログブラウザから簡単にトラッキングすることができます。

管理NGのログブラウザ

管理NGのログブラウザは、管理拡張機能の管理NGタブにある ログ閲覧 ボタンからアクセスできます。ボタンクリックで開く ログ閲覧 用ポップアップ画面にて、表示させたいログを絞込むことができます。

使用可能なフィルター

  • 基本 フィルター

    • 管理者: あるドメイン管理者の操作ログのみを表示させるフィルター

    • アクション: 特定のアクションのログのみを表示させるフィルター。対象アクションについては後述を参照してください。

  • 高度な フィルター

    • クライアントIP: 指定したIPアドレスからの操作ログのみを表示させるフィルター

    • ログイン表示: このチェックボックスをオンにすると、ドメイン管理者がZimbraウェブクライアントにログインした時間も表示されます。

    • 結果: すべて、成功、失敗のいずれかのログのみを表示させるフィルター

    • スタートエンド: この期間のログのみを表示させるフィルター(デフォルト:当日)

詳細 ボタンをクリックすると、選択したフィルターの結果がログブラウザに表示されます。

アクション フィルター

管理者が実行可能な全操作が アクション フィルターのドロップダウンに入っています。

管理者の操作をトラッキングし、トラブルシューティングを行なうには下記の操作が重要です。

  • Auth: 全てのZWC認証

  • DelegateAuth: 全ての委任認証。 メールを表示 ボタンからの操作と zmmailbox コマンド -z オプションの実行が対象になります。

  • CreateAccount: 全てのアカウント作成

  • DeleteAccount: 全てのアカウント削除

  • Set Password: 全てのメールボックスパスワード変更

  • RemoveAccountAlias:全てのエイリアス削除

  • DeleteDistributionList: 全ての配布リスト削除

レポートと情報

管理NGの月間レポート

システム管理者は管理NGモジュールに備わった 月間レポート 機能を利用して、委任された管理者による操作や対象月のドメイン状態をトラッキングすることができます。 月間レポートシステムの詳細 各月初日に、管理NGログの集積データに基づくレポートが管理NGモジュールによって自動生成されます。

月間レポートシステムの詳細

各月初日に、管理NGログの集積データに基づくレポートが管理NGモジュールによって自動生成されます。

この月間レポートには下記の情報が掲載されます。

グローバルレポート

最初のログアクション

管理者が今月最初に操作したときのタイムスタンプ

最後のログアクション

管理者が今月最後に操作したときのタイムスタンプ

管理者最終ログイン

管理者が最後にログインしたときのタイムスタンプ

最も活動的だった管理者

ログに記録された操作数が最も多い管理者名

最もよく使われたIPアドレス

管理者のログインで最も使用されたIPアドレス

アカウント総数

メールボックス総数

作成アカウント総数

月間で作成されたメールボックス数

削除アカウント総数

月間で削除されたメールボックス数

作成ドメイン総数

月間で作成されたドメイン数

作成配布リスト総数

月間で作成された配布リスト数

削除配布リスト総数

月間で削除された配布リスト数

ドメインレポート

ドメイン

このデータの参照先ドメイン名

管理者最終ログイン

管理者が最後にログインしたときのタイムスタンプ

アカウント/最大アカウント数

現在のアカウント数と最大アカウント数

現在のドメインサイズ

ドメインの全メールボックスで使用中の総容量

最大ドメイン容量

全メールボックスの最大容量合計 (無制限 のメールボックスは除く)

制限なしアカウント

制限のないメールボックス数

制限なしアカウント容量

制限のない全メールボックスで使用中の総容量

ドメイン内システムリソース

ドメイン内のシステムリソースアカウント数

ドメインごとの“カレンダーリソース”アカウント

ドメインのカレンダーリソースアカウント数

成功したドメインアクション

このドメインで管理者が成功した操作回数

失敗したドメインアクション

このドメインで管理者が失敗した操作回数

管理者レポート

管理者

このデータの参照先管理者名

成功したログイン

管理コンソールへのログイン成功回数

失敗したログイン

管理コンソールへのログイン失敗回数

“メールを表示” アクション

この管理者の メールを表示 機能月間使用回数

最終ログイン

この管理者が管理コンソールへ最後にログインしたときのタイムスタンプ

最もよく使われたIPアドレス

この管理者のログインで最も使用されたIPアドレス

アクション数合計

この管理者が月間で実施した操作回数

作成したアカウント数

この管理者が月間で作成したアカウント数

削除したアカウント数

この管理者が月間で削除したアカウント数

月間レポートへのアクセス方法

管理拡張機能から

月間レポート へのアクセス方法

  • システム管理者としてZimbra管理コンソールにログインします。

  • 管理拡張機能の管理NGタブ画面右上にある、月間レポート ボタンをクリックします。

  • 表示させたい月を選択し、レポートを表示 ボタンをクリックします。

CLIから

CLIから月間レポートを表示するには、getMonthlyReport コマンドを使用します。

zxsuite admin getMonthlyReport [attr1 value1 [attr2 value2...

パラメーターリスト

名前        データ型       期待値            初期値
month(O)    String     mm/yyyy            12/2012
local(O)    Boolean    true|false         false

(M) == 必須パラメーター, (O) == 任意のパラメーター

使用例:

zxsuite admin getMonthlyReport
前月の月間レポートを表示します。

zxsuite admin getMonthlyReport month 11/2012
2012年11月の月間レポートを表示します。
部分レポート

当月分の部分レポートを作成するには、doMonthlyReport コマンドを使用します。

zxsuite admin doMonthlyReport [attr1 value1 [attr2 value2...

パラメーターリスト

名前         データ型     期待値              初期値
month(O)    String     mm/yyyy            12/2012
force(O)    Boolean    true|false         false

(M) == 必須パラメーター, (O) == 任意のパラメーター

使用例:

zxsuite admin doMonthlyReport
前月の月間レポートを生成し、それを現在の管理NGのログパスに保存します。

zxsuite admin doMonthlyReport month 01/2013
当月の部分月間レポートを生成しますが、ディスクへの保存はしません。

** 備考**

このコマンドは月に一度自動実行され、前月分のレポートファイルを作成します。既存のレポートファイルを上書きするには、パラメーター'force'をtrueに設定してください

管理NGのログパス

管理NGモジュールでは、全ての月間レポートは、月間レポート生成に使用するログや 管理ログ閲覧 機能で使用するログと共に /opt/zimbra/conf/ ディレクトリ内のパスに格納されます (デフォルトは /opt/zimbra/conf/zextras/zxadmin/)。 このパスはZimbraのアップデート中に削除されることがないため、デフォルトパスになっています。

管理NGのログパスの構造と内容

管理NGのログパスは、下記ファイルを格納するフラットなディレクトリです。

  • 1件以上の YYYY_MM ファイル。各ファイルには、ファイル名と同じ年月のログが格納されています。

  • 0件以上の YYYY_MM.report ファイル。各ファイルには、ファイル名と同じ年月の月間レポートが格納されています。

  • 0件以上の YYYY_MM.X ファイル。各ファイルには、ファイル名と同じ年月のログが格納されています。このファイルは管理NGのログパスを変更したときに作成されます。

管理NGのログパスの変更
管理NGのログパスを変更する前に、この項を精読するようにしてください。手順を誤るとログを損失し、 月間レポート管理ログ表示 への信頼を落とす要因になります。

管理NGのログパスを安全に変更するには、下記手順に従ってください。

  • ログの格納先となるフォルダを作成します。

    • このフォルダのオーナーを zimbra:zimbra にします。

    • zimbra ユーザーはこのフォルダに対する読み書き権限が必要です。

    • このフォルダは空でなければなりません。

  • システム管理者にてZimbra管理コンソールにログインします。

  • 管理拡張機能の管理NGタブを開きます。

  • 基本モジュール設定 のセクションにて、管理ログパスの付近にある変更ボタンをクリックします。

  • 新しいパスを入力し、パス変更 をクリックします。

  • エラーが表示されたら、旧ログパスの全内容を移動します。

    • 旧ログパス内に、 .report ファイルと .X ファイルしか表示されなくなりますが正常な結果です。現在のログファイルは部分的なものであることを知らせるため、拡張子が .1 になります。それ以前の .X ファイルの拡張子はそれぞれ1つ増分されます。

設定リセット

管理NGの設定リセットとは

管理NGの設定リセットとは、システム管理者がサーバーから一切の委任権限を完全にワイプできる機能です。

これは管理NGモジュールの設定をクリーンアップする ロールバック 機能ではありません。設定リセットの対象は管理NGとZimbra両方の委任権限になります。

管理NGの設定リセットを使用すると、サーバーにある全ての委任権限が完全にワイプされ、環境は初期状態に戻されます。管理委任設定のみがワイプされるため、他のデータへの影響はありません。
管理設定リセットのクリア対象

下記の設定が管理設定リセットでクリアされます。

  • サーバーにある全アカウントの isDelegatedAdmin アカウントプロパティ

  • 下記についての全てのアクセス制御エントリと全てのアクセス制御リスト

    • ユーザー

    • ドメイン

    • 提供サービス

    • ローカル設定

    • サーバー設定

    • Zimlet

管理設定リセットを利用する場面

管理設定リセットは下記場合を除き、利用しないでください。

  • 他に仕方のない状況のため、完全リセットする場合

    • 不正なアクセス制御エントリまたはアクセス制御リストの設定が1件以上存在するせいでZimbra管理コンソールが不安定または不適切に表示される(ブランクページが表示される、1件以上のUI項目が表示されないなどの)場合に、最終手段として管理設定リセットを使用してください。

  • 管理NGモジュールの使用をやめる場合

    • アクティブなNetwork NGライセンスがない場合にも、リセット機能は使用できます。留意すべきこととして、マニュアル操作で設定した委任設定が全てワイプされます。

管理設定リセットの使用方法

本当に 管理委任設定のリセットを実行したい場合は、下記CLIコマンドを実行するだけで済みます。

zxsuite core doDeleteAllDelegatedRights

コマンドの誤使用を避けるため、確認用文字の入力が促されます。

NGモジュールのCLI

Network NG モジュールのCLI

zxsuite - Network NG モジュールのコマンドラインインターフェース

基本的な利用方法

Network NGの各モジュール(Coreも含む)は、zxsuite コマンドに各サブセットを持っています。 zxsuite コマンドは全て、下記構文にて呼び出されます。

:: zxsuite [--host|--offline] [--json] [--progress] [--sync] {module} {action} [options]

利用可能なスイッチ

  • --host [hostname|ip] - コマンドの対象ホストを指定します。ローカルホストの場合はブランク。コマンドを全サーバーに適用する場合、all_serversを指定します。

  • --offline - Zimbraサービスが開始していない場合に指定します。一部のコマンドでは機能しません。

  • --json - コマンドの出力をJSONフォーマットにします。スクリプティングに便利です。

  • --progress - 操作のフィードバックを直接、STDOUT(標準出力)に出力します。Ctrl+Cで出力を停止できます。処理自体は停止されません。

  • --sync - コマンドをシンクロナスモードで実行し、オペレーションの実行が終了まで待ち、オペレーションの結果として以下のコードを終了に返答します。

    • 0 - 成功

    • 1 - 失敗

    • 2 - 停止している

    • 3 - 削除された

    • 4 - 中断された

オンラインヘルプ: 各コマンドごとのオンラインヘルプは zxsuite help {module} [command] にて確認できます。 このcommand部分を省略すると、利用できるコマンドが一覧表示されます。

Core CLI

基本的な利用方法

zxsuite core {action} [options]

Core コマンド

:: getVersion - Network NGモジュールのバージョンを表示

zxsuite core getVersion

:: getProperty - 設定用プロパティを取得

zxsuite core getProperty [attr1 value1 [attr2 value2…​

:: setProperty - 設定用プロパティを設定

zxsuite core setProperty {property_name} {property_value}

:: getLicenseInfo - Network NGモジュールのライセンス情報を表示

zxsuite core getLicenseInfo core getLicenseInfo

:: doUploadLicense - Network NGモジュールのライセンスをアップロード

zxsuite core doUploadLicense {license_path}

:: doLicenseChecks - Network NGモジュールのライセンスをチェック

zxsuite core doLicenseChecks

:: getAccountStats - 入力されたアカウント名またはIDの統計情報を表示

zxsuite core getAccountStats {account}

:: getNotification - Network NGの通知を表示

zxsuite core getNotification [attr1 value1 [attr2 value2…​

:: doDeleteAllDelegatedRights - 管理NGとZimbraの両方の管理委任設定を削除

zxsuite core doDeleteAllDelegatedRights {confirmation string}

更新のCLI

基本的な利用方法

zxsuite update {action} [options]

更新のコマンド

:: doCheckUpdate - 更新情報をフェッチ

zxsuite update doCheckUpdate

:: doStartService - 入力されたサービスを開始

zxsuite update doStartService {service_name}

:: doStopService - 入力されたサービスを停止

zxsuite update doStopService {service_name}

:: download - [BETA]Network NGを使用できる最新の更新バージョンに更新。mailboxdの次回再開時にこのバージョンがロードされます。

zxsuite update download

:: enable - [BETA] Enable Network NGの自動更新機能を有効化

zxsuite update enable

:: getServices - このモジュールに対する全サービスの現ステータスを表示

zxsuite update getServices

:: info - Network NG の更新に関する情報

zxsuite update info

:: start - [BETA] 新しいNetwork NGバージョンをロード

zxsuite update start [attr1 value1 [attr2 value2…​

バックアップNGの CLI

基本的な利用方法

zxsuite backup {action} [options]

バックアップNGのコマンド

:: getProperty - 設定用プロパティを取得

zxsuite backup getProperty [attr1 value1 [attr2 value2…​

:: setProperty - 設定用プロパティを設定

zxsuite backup setProperty {property_name} {property_value}

:: doSmartScan - Smart Scanの実行

zxsuite backup doSmartScan [attr1 value1 [attr2 value2…​

:: doAccountScan - 単一アカウントに対するフルスキャンの実行

zxsuite backup doAccountScan {account} [attr1 value1 [attr2 value2…​

:: doExport - ドメインによる制限のあるエクスポートを実行

zxsuite backup doExport {destination_path} [attr1 value1 [attr2 value2…​

:: doRestoreOnNewAccount - 新アカウントへの復元を実行

zxsuite backup doRestoreOnNewAccount {source_account} {destination_account} {dd/MM/yyyy HH:mm:ss|last} [attr1 value1 [attr2 value2…​

:: doEnableDisableCOS - 指定した提供サービスに対するバックアップ機能を有効化

zxsuite backup doEnableDisableCOS {cos_name} {enable|disable}

:: doUndelete - 削除取り消しによる復元を実行

zxsuite backup doUndelete {account} dd/MM/yyyy HH:mm:ss|first} dd/MM/yyyy HH:mm:ss|last} [attr1 value1 [attr2 value2…​

:: doItemSearch - アイテムの検索

zxsuite backup doItemSearch {account} [attr1 value1 [attr2 value2…​

:: doItemRestore - 単一アイテムの復元を実行

zxsuite backup doItemRestore {account_name} {item_id}

:: doExternalRestore -外部復元の実行

zxsuite backup doExternalRestore {source_path} [attr1 value1 [attr2 value2…​

:: doStopOperation - 実行中の単一処理を停止

zxsuite backup doStopOperation {operation_uuid}

:: doStopAllOperations - 実行中の処理を全て停止し、処理キューを空にする

zxsuite backup doStopAllOperations

:: doCheckShares - ローカルアカウントにある共有を全てチェック

zxsuite backup doCheckShares

:: doFixShares - ローカルアカウントにある全共有の修正を試行

zxsuite backup doFixShares {import_idmap_file}

:: doFixOrphans - 親のないダイジェストファイルを削除

zxsuite backup doFixOrphans [attr1 value1 [attr2 value2…​

:: doCoherencyCheck - バックアップの一貫性をチェック

zxsuite backup doCoherencyCheck {backup_path} [attr1 value1 [attr2 value2…​

:: getAccountInfo - あるアカウントの情報を表示

zxsuite backup getAccountInfo {account} [attr1 value1 [attr2 value2…​

:: getBackupInfo - バックアップシステムの情報を表示

zxsuite backup getBackupInfo [attr1 value1 [attr2 value2…​

:: getMap - バイナリのマップオブジェクトを解読可能な表にて表示

zxsuite backup getMap {file_path}

:: getItem - アイテムを解読可能な形式にて表示

zxsuite backup getItem {account} {item} [attr1 value1 [attr2 value2…​

:: getAvailableAccounts - 復元可能なアカウントを全て表示

zxsuite backup getAvailableAccounts [attr1 value1 [attr2 value2…​

:: getAvailableDomains - 復元可能なドメインを全て表示

zxsuite backup getAvailableDomains {dd/MM/yyyy HH:mm:ss|last} {backup_path}

:: getServerConfig - 保存されているサーバー設定を一覧表示

zxsuite backup getServerConfig dd/MM/yyyy HH:mm:ss|last|all} {standard|customizations} [attr1 value1 [attr2 value2…​

:: getCOSBackupStatus - 全ての提供サービスのバックアップステータスを表示

zxsuite backup getCOSBackupStatus [attr1 value1 [attr2 value2…​

:: getAllOperations - 実行中およびキューにある処理を全て表示

zxsuite backup getAllOperations

:: monitor - 実行中の処理を監視

zxsuite backup monitor {operation_uuid} [attr1 value1 [attr2 value2…​

:: getServices - 全モジュールサービスの現ステータスを表示

zxsuite backup getServices

:: doBackupLDAP - LDAPをバックアップ

zxsuite backup doBackupLDAP

:: doRestartService - 指定されたサービスを再起動

zxsuite backup doRestartService {service_name}

:: doRestoreBlobs - 壊れたzimbra blobの復元を試みる"restore blobs"処理を開始

zxsuite backup doRestoreBlobs {volume_id} [attr1 value1 [attr2 value2…​]]

モバイル NGの CLI

基本的な利用方法

zxsuite mobile {action} [options]

モバイルNGのコマンド

:: getProperty - 設定用プロパティを取得

zxsuite mobile getProperty [attr1 value1 [attr2 value2…​

:: setProperty - 設定用プロパティを設定

zxsuite mobile setProperty {property_name} {property_value}

:: getDeviceList - 入力したアカウント用のデバイスを全て取得

zxsuite mobile getDeviceList {account}

:: getDeviceInfo - 入力したデバイスに関する情報を表示

zxsuite mobile getDeviceInfo {account} {device_id}

:: doResetAccount - 入力したアカウント用のデバイス状態を全てリセット

zxsuite mobile doResetAccount {account}

:: doResetDevice - シングルアカウント用デバイスのSyncState (同期状態) をリセット

zxsuite mobile doResetDevice {account} [attr1 value1 [attr2 value2…​

:: getAllSessions - 保存された全てのモバイルセッションに関する情報を返す

zxsuite mobile getAllSessions

:: getActiveSessions - アクティブなモバイルセッションを全て返す

zxsuite mobile getActiveSessions

:: doRemoveDevice - デバイスのSyncState (同期状態) と履歴を全てサーバーから削除

zxsuite mobile doRemoveDevice {account} {device_id}

:: getAccountLoggers - 全てのアカウントロガーに関する情報を返す

zxsuite mobile getAccountLoggers

:: doRemoveLogger - アカウントロガーを削除

zxsuite mobile doRemoveLogger {logger_id|all_loggers}

:: doAddAccountLogger - アカウントロガーを追加

zxsuite mobile doAddAccountLogger {account} {debug|info|warn|err|crit} {log_file}

HSM NGのCLI

基本的な利用方法

zxsuite powerstore {action} [options]

HSM NGのコマンド

:: +setHsmPolicy - HSMにポリシーを1件追加

zxsuite powerstore +setHsmPolicy {hsm_policy}

:: addS3Store - S3と互換性のあるストアを追加

zxsuite powerstore addS3Store {Name of the zimbra store} [attr1 value1 [attr2 value2…​

:: doCheckBlobs - doCheckBlobs処理を開始

zxsuite powerstore doCheckBlobs {start} [attr1 value1 [attr2 value2…​

:: doCreateVolume - サーバー上にボリュームを作成

zxsuite powerstore doCreateVolume {primary|secondary|index} {volume_name} {volume_path} {true|false} {compression_threshold_bytes}

:: doDeduplicate - 重複排除処理を開始

zxsuite powerstore doDeduplicate {volume_name} [attr1 value1 [attr2 value2…​

:: doDeleteVolume - サーバー上の特定のボリュームを削除

zxsuite powerstore doDeleteVolume {volume_id}

:: doMoveBlobs - doMoveBlob処理を開始

zxsuite powerstore doMoveBlobs [attr1 value1 [attr2 value2…​

:: doRemoveHsmPolicy - HSMからポリシーを削除

zxsuite powerstore doRemoveHsmPolicy {hsm_policy}

:: doRestartService - 入力したサービスを再開

zxsuite powerstore doRestartService {service_name}

:: doStartService - 入力したサービスを開始

zxsuite powerstore doStartService {service_name}

:: doStopAllOperations - 実行中の処理を全て停止し、処理キューを空にする

zxsuite powerstore doStopAllOperations

:: doStopOperation - 実行中の単一処理を停止

zxsuite powerstore doStopOperation {operation_uuid}

:: doStopService - 入力したサービスを停止

zxsuite powerstore doStopService {service_name}

:: doUpdateVolume - サーバー上の特定のボリュームを更新

zxsuite powerstore doUpdateVolume {volume_id} [attr1 value1 [attr2 value2…​

:: doVolumeToVolumeMove - doMoveVolumeBlobs処理を開始

zxsuite powerstore doVolumeToVolumeMove {source_volume_name} {destination_volume_name}

:: getAllOperations - 実行中およびキューにある処理を全て表示

zxsuite powerstore getAllOperations [attr1 value1 [attr2 value2…​

:: getAllVolumes - サーバーに存在する全ボリュームを出力

zxsuite powerstore getAllVolumes

:: getHsmPolicy - 全ポリシーを出力

zxsuite powerstore getHsmPolicy

:: getProperty - 設定用プロパティを取得

zxsuite powerstore getProperty [attr1 value1 [attr2 value2…​

:: getServices - このモジュールに対する全サービスの現ステータスを表示

zxsuite powerstore getServices

:: getVolumeStats - ボリュームに格納されているblobの数、アイテム数、占有率を表示

zxsuite powerstore getVolumeStats {volume_id} [attr1 value1 [attr2 value2…​

:: monitor - 実行中の処理を監視

zxsuite powerstore monitor {operation_uuid} [attr1 value1 [attr2 value2…​

:: setHSMPolicy - デフォルトのHSMポリシーを設定

zxsuite powerstore setHSMPolicy {hsm_policy}

:: setProperty - 設定用プロパティを設定

zxsuite powerstore setProperty {property_name} {property_value}

:: testS3Connection - S3バケットに対するテスト接続

zxsuite powerstore testS3Connection {s3BucketConfigurationUuid}

管理NGの CLI

基本的な利用方法

zxsuite admin {action} [options]

管理NGのコマンド

:: getDelegationSettings - 委任された管理者、各ドメインの特性、「メールを表示」 の属性、管理者の割り当て可能容量を表示。

zxsuite admin getDelegationSettings [attr1 value1 [attr2 value2…​

:: doEditDelegationSettings

zxsuite admin doEditDelegationSettings {account} {domain} [attr1 value1 [attr2 value2…​

:: doAddDelegationSettings

zxsuite admin doAddDelegationSettings {account} {domain} [attr1 value1 [attr2 value2…​

:: doRemoveDelegationSettings

zxsuite admin doRemoveDelegationSettings {account} {domain}

:: getDomainSettings - 全ドメイン名、アカウント制限、ドメイン単位でのアカウント割り当て使用量を表示

zxsuite admin getDomainSettings

:: setDomainSettings - ドメイン単位でのアカウント割り当て使用量とアカウント制限を設定

zxsuite admin setDomainSettings {domain} [attr1 value1 [attr2 value2…​

:: resetDomainSettings -グローバルアカウント制限、提供サービスごとのアカウント制限、ドメイン単位でのアカウント割り当て使用量の、選択したドメインに対するリセットを実行

zxsuite admin resetDomainSettings {domain}

:: doShowAdminActivity - 管理者が操作した記録を表示

zxsuite admin doShowAdminActivity [attr1 value1 [attr2 value2…​

:: doEnableDisableAdminLogging - 管理者の操作をログに残すことの有効化・無効化

zxsuite admin doEnableDisableAdminLogging {enable|disable}

:: setProperty - 設定用プロパティを設定

zxsuite admin setProperty {property_name} {property_value}

:: getProperty - -設定用プロパティを取得

zxsuite admin getProperty [attr1 value1 [attr2 value2…​

:: doMonthlyReport - 指定した月間の管理者の操作に関するレポートを作成

zxsuite admin doMonthlyReport [attr1 value1 [attr2 value2…​

:: getMonthlyReport - 指定した月間の管理者の操作に関するレポートを表示

zxsuite admin getMonthlyReport [attr1 value1 [attr2 value2…​

:: doSetZimletRights - 委任された管理者全員に対する管理拡張機能の権限を修正

zxsuite admin doSetZimletRights

:: getAllOperations - 実行中およびキューにある処理を全て表示

zxsuite admin getAllOperations

:: doStopAllOperations - 実行中の処理を全て停止し、処理キューを空にする

zxsuite admin doStopAllOperations

:: doStopOperation - 実行中の単一処理を停止

zxsuite admin doStopOperation {operation_uuid}

:: monitor - -実行中の処理を監視

zxsuite admin monitor {operation_uuid} [attr1 value1 [attr2 value2…​

Backup NGを利用したZimbra8.8.0への増分移行

概要説明

  • 本書では、Backup NGを利用した増分移行の実施方法を説明します。

  • 商用環境の移行を目的とし、システム停止時間を最短化すること、そしてユーザーにとって透過性のあるものを目指し設計しています。

    • 正確な計画に従い、正しく実行されれば、システムが停止することはありません。ユーザーへの影響も限りなくゼロに近づきます。

  • 移行元のサーバーは、Zextras Suiteまたは Zimbra Suite Plusでなければなりません。

    • Zimbra8.8のいずれかからサポートされているZimbraバージョンからの移行を本書の対象としています。

  • 特に指定がない限り、本書に記載のCLIコマンドはzimbraユーザーで実行してください。

移行対象

  • メールとメールフォルダ

  • 連絡先と連絡先リスト

  • 予定とカレンダー

  • タスクとタスクリスト

  • 文書とブリーフケース

  • 共有情報

  • ユーザーのプリファレンス

  • ユーザー設定

  • 提供サービスの設定

  • ドメイン設定

移行対象外

  • サーバー設定 (参照用に移行されますが復元はされません)

  • グローバル設定 (参照用に移行されますが復元はされません)

  • カスタマイズ内容 (Postfix, Jetty等)

  • 処理中に移動または削除されたアイテムは、移行先サーバーでの移動・削除はされません。

  • 処理中に変更されたプリファレンス (パスワード等) は、各インポート先でリセットされます。

増分移行は、サーバーtoサーバーのミラーリングのセットアップ用には設計されていません。複数インポートを利用して元サーバーをミラーしたコピーを作成しようとしても、ミラーの コピーは作成されません。インポート処理では削除が行なわれないからです。

元データ

移行元サーバーのデータは、Zextras Suiteまたは Zimbra Suite Plusから取得します。

ソフトウェアのインストール

Zextras Suiteまたは Zimbra Suite Plusを取得したら、次のインストール処理に従ってください。

  • rootユーザーが所有しているサーバー内ディレクトリにパッケージをコピーします。

  • tar zxf を使用してパッケージを展開します。

  • zextras_suite-[version] または zimbra_suite_plus-[version] という名称で新たに作成されたディレクトリ内に移動します。

  • rootにて、インストール用スクリプト ./install.sh all を実行します。

  • インストールウィザードに従い、ソフトウェアEULAを受け入れ、CoreとZimletコンポーネントをインストールします。

  • インストールが完了したら、本書に沿って処理を進めます。

Zextras Suiteまたは Zimbra Suite Plusをインストールするにはmailboxdサービスの再開が必要です。これはインストール中に実行されます。

移行前チェック

サーバー

  • 移行元サーバー: Backup NGまたはZimbra Suite Plusが実行中のZimbraサーバーであれば、移行元とすることができます。

  • 移行先サーバー: Backup NGまたはZimbra Suite Plusが実行中のZimbraサーバーであれば、移行先とすることができます。

ストレージ

  • 移行元サーバー:移行元サーバー上でBackup NGが現在有効でない場合、 /opt/zimbra/store/ のフォルダサイズと同等の空ディスク容量があることを確認してください (エクスポートされるサイズは通常、オリジナルサイズの70パーセントまで縮小化されます。gzipアルゴリズムを使ってエクスポートデータが圧縮されるためと全zimbraアイテムが重複排除されるためです) 。

  • 移行先サーバー: /opt/zimbra/store/ のフォルダサイズと移行元サーバーにある export フォルダサイズを合算したサイズよりも大きな空ディスク容量があることを確認してください。

データ転送

データの転送方法は様々ですが、rsyncによる手段を推奨します。速度と利便性の観点で妥当であるためです。

データ転送の大部分は移行元サーバーがまだ実行中・機能中の間に実行されます。しかしながら、転送はネットワーク経由であるため、あらかじめ緻密に計画してください。そうすれば、移行前に 全てのデータ を転送し終えることができます。

データ転送の代替案

転送手段は必要であればリモートリンクからドライブの物理的な移動まで、何でもかまいません。

ハイウェイでは速度が落ちるテープでいっぱいの
ステーションワゴンの帯域幅を決して少なく見積もることのないようにしてください。
--Tanenbaum, Andrew S. (1996). Computer Networks. New Jersey: Prentice-Hall. 
p. 83. ISBN 0-13-349945-6.

DNS

実際のDNS上のMXレコードのTTLの値を300に設定してください。こうすることで、移行元サーバーと移行先サーバー間の切り替えが早くなります。

移行のセットアップ

手順1: 一貫性チェック

データ関連の問題を回避するため、移行元サーバーで下記のチェックを実行してください。

  • zmblobchk: ZimbraのメタデータとBLOB間の一貫性をチェックします。

  • zmdbintegrityreport: Zimbraのデータベースの完全性をチェックします。

エラーが見つかった場合は、Zimbraの公式ドキュメントにある記載に従い修正してください。

また、全てのメールボックスの再インデックス化を実行することを推奨します。

手順2: Network NG のセットアップ

両サーバーで下記を実行し、Real Time Scannerを無効にしてください

zxsuite backup setProperty ZxBackup_RealTimeScanner false
データエクスポートのための専用デバイスの使用を強く推奨します。エクスポートのパフォーマンスの向上のためとシステムのパフォーマンスへの影響を抑えるためです。

デバイスをパス /opt/zimbra/backup/ にリンクさせてください。また、zimbraユーザーにはこのパスに対する読み書き権限がなければなりません。

手順3: データのエクスポート (SmartScan)

移行元サーバー上で下記コマンドを実行して、SmartScanを実行してください。

zxsuite backup doSmartScan

デフォルトのバックアップパス (/opt/zimbra/backup/ng/) に全データがエクスポートされることになります。

ヒント: 単一ドメインのエクスポート

全ドメインではなく、1つまたは複数のドメインだけを移行することもできます。その場合は、SmartScanの 代わりに 次のコマンドを実行します。

zxsuite backup doExport /path/to/export/folder/ domains yourdomain.com,yourdomain2.com[..]

留意すべきこととして、 SmartScan で開始した場合はずっと SmartScan で、 単一ドメイン での方法で開始した場合は、ずっと 単一ドメイン での方法で移行を続ける必要があります。この2つの方法は混在できません。

管理拡張機能からデータのエクスポート (SmartScan)

下記のとおり、管理拡張機能からデータエクスポートを実行することもできます。

手順4: データの同期

エクスポートしたデータを移行先サーバーへ移動するとき、移行先サーバーにある移動先フォルダがBackup NGのバックアップパスでないことを確認してください。移行先サーバーでBackup NGをすでに使用中、または使用予定がある場合、障害の要因になりかねません。

(rsync以外の方法でデータ転送を行なう場合は、以下手順をスキップしてかまいません。)

rsync を使用して /opt/zimbra/backup/ng/ 内のデータを移行先サーバーのディレクトリへコピーしてください (zimbraユーザーに対象フォルダへの読み書き権限があることを確認してください) 。 screentmux などのターミナルマルチプレクサを使用してください。この処理のコマンドは、ネットワーク速度や対象データの量によっては、かなりの長時間がかかるかもしれません。

[run this command as Root]
rsync -avH /opt/zimbra/backup/ng/ root@desinationserver:/path/for/the/data/
その他の同期方法

これまで提案してきた方法は、帯域幅の広い環境の場合は最良です。一方で、大量のデータが初回同期の対象となる可能性があります。rsyncによる手段が遅いと感じる場合は、デバイス (仮想環境で実行中ならそのおおもとのディスクファイル) の物理的な移動を検討することになるかもしれません。

ディスク移動後はリンクをリモートで移行元サーバーに戻すことができます (例:SSHFS) 。移行の一環である「追加同期」で対象となるデータは少量だからです。なおこの場合、移行元サーバーのデバイスを/opt/zimbra/backup/ng/として再リンクさせ、そこに必要となる全ての権限を付与しておいてください。

手順5: 初回インポート

エクスポートした全データを移行先サーバーへインポートします。

zxsuite backup doExternalRestore /path/for/the/data/

Network NGが移行先サーバーへデータをインポートしている間、安心してお待ちください。

''警告: この手順後はバックアップパスを編集・削除しないでください''

管理拡張機能からの初回インポート

管理拡張機能を使用してデータのインポートをするという選択肢もあります。管理拡張機能からインポート中、インポートされるアカウントリストから全てのシステムアカウント (GalSync、Ham、Spam、Quarantineなど) が削除されることを確認してください。

手順5(別案): 大規模移行時の初回インポート

ここからは、エクスポート・インポートに何時間もあるいは何日もかかるような巨大インフラを移行する管理者向けの別案を紹介します。

全データを移行先サーバーへインポートするのではなく、 プロビジョニングのみ インポートすることで、ドメインや提供サービス、アカウントだけ移行先サーバーに作成し、メールボックスの全内容を移行対象外とすることができます。

zxsuite backup doExternalRestore /path/for/the/data/ provisioning_only TRUE

上記コマンドを実行後、メールフローを新サーバーに切り替えます。切り替えが完了したら、実際の インポートを開始します。

zxsuite backup doExternalRestore /path/for/the/data/

こうすることでシステムユーザーの接続先が移行先サーバーに変わります。古いメールの復元が進行中の移行先サーバーに、新しいメールが配信されるようになります。

このアプローチにはメリットとデメリットがあります。

メリット

  • アイテムのインポートは一度だけ、かつ、その後修正・削除はされないため、標準の 増分移行に比べると、不整合になる割合が減少します。

  • 移行元サーバーへの影響を減らすオプションがあります (例:移行元サーバーを急いで閉鎖する場合、都合が良いです) 。

デメリット

  • 処理のタイミングによっては、システムユーザーへの影響度が高まります。ユーザーがメールボックスを使用している間にもアイテムは復元中だからです。

  • 稼働中のシステムでインポートを行なうため、速度低下が気になるかもしれません。

これまでの状況

この時点で、ほとんどのデータが移行先サーバーへインポートされました。移行元サーバーはまだ稼働中で、機能しています。これから、実際の移行を準備します。

移行

手順6: 移行前チェック

メールフローを切り替える前に、必ず、移行先サーバーにおける稼動準備が整っていることを確認してください (ファイヤーフォール、DNS設定、セキュリティシステムなど) 。

手順7: 切り替え

ついに切り替えの瞬間です。この手順が終わる頃、移行先サーバーが稼動し機能しています。

  • 手順3、手順4、手順5を繰り返します (新しいデータのみエクスポート・同期化される) 。

  • メールフローを新サーバーへ切り替えます。

  • 移行元サーバーにメールが一切届かなくなったら、手順3、手順4、手順5を繰り返します。

移行先サーバーは、現在稼動し機能しています。

手順8: 移行後のチェック

次のコマンドを実行して、共有の不整合をチェックします。

zxsuite backup doCheckShares

不整合が見つかった場合は下記コマンドを実行します。このコマンドで、1つめの引数に使用したインポートマップファイルをパージし、不整合な共有をすべて修正します。

zxsuite backup doFixShares

マップファイルは、移行先サーバーのバックアップパス内にある map_[source_serverID] です。

手順9: Galsync

Zimbra管理コンソールから、インポートした全てのGalSyncアカウントを削除します。その後必要に応じて、インポートした全てのドメインのGalSyncアカウントを新規に作成します。そして、次のコマンドを使用して、全てのGalSyncアカウントを再同期化します。

zmgsautil forceSync -a galsync.randomstring@domain.com -n [resourcename]

手順10: メッセージの重複排除

移行後はHSM NGモジュールを使って、ボリューム重複排除を実行することを強く推奨します。

その後

  • 新サーバーのBackup NGを初期化し、全データに問題がないことを確認します。

増分移行に関するFAQ

Q: 増分移行を行なうには、有効なライセンスが必要でしょうか。

はい。試用版または購入版、いずれかのライセンスが必要です。

Q: 移行対象となるものは何ですか。

サーバー設定を除いた全てが対象となり、サーバー設定には次のものが含まれます。

  • ユーザーのデータ

  • ユーザーのプリファレンス

  • 提供サービスの設定

  • ドメイン設定

Q: 共有は破棄されますか? 既存の共有は全て再設定する必要がありますか?

いいえ、そのようなことありません。

Q: エクスポートデータのサーバー間での転送はどのように行なえばよいでしょうか。

転送手段は必要性に沿うものであれば、何でもかまいません。何を求めているのか、それだけは整理しておく必要はあります。

迅速なデータ移動が必要な場合、サーバー間でのUSBディスクの物理移動という手段は適していないかもしれません。

信頼性のおける手段でのデータ移動が必要な場合、お使いのインターネット回線が不安定ならSSHFS経由でエクスポートフォルダを移行先サーバーにリンクさせる手段は適していないかもしれません。

Zimbra Chat

本書について

本書は、システム管理者を対象に記載しています。本書の目的は、プロダクトアーキテクチャについての深い見解によりトラブルシューティングを簡潔にすること、同時に、安定したカスタマイズに必要な知識を提供することです。

概要

Zimbra Chatは、バージョン8.7.6以降のZimbraにベータ版ソフトウェアとして含まれています。そしてバージョン8.8.0で安定版となりました。Zimbra Chatは、Zimbraアカウント間での文字によるチャット機能であるため、シンプルかつダイレクトです。ZimletとZimbraの拡張機能で構成されています。

Zimbraの拡張機能はXMPPクライアントをあてているため、ユーザーはZimbraのウェブクライアントでZimletを使用する代わりに標準のXMPPクライアントを使ってチャットすることもできます。この2つの手段を同時に使用することもできます。

一般的なアーキテクチャ

Zimbra Chat はZimbra用に設計されています。そしてXMPPサーバーを実装したZimbraサーバー拡張機能として稼動しながら、クライアント間での共有イベントを全て処理します。Zimbra Chatサーバー拡張機能ではChat Zimletとの連携に、XMPPとカスタムプロトコルを使用しています。

このサーバー拡張機能は、シングルユーザーの複数セッションを処理できます。セッション数に制限はありません。セッションごとに配信キューがあります。つまり、各セッションが全てのイベントを保持しており、それらをそのユーザーの別のセッションとして把握しています。

種類 (XMPPあるいはChat Zimlet) によってセッションが制限されることはありません。ユーザーはセッション間の衝突を気にすることなく、ZimbraウェブクライアントとXMPPクライアントの両方を同時に使用することができます。

コンポーネント

Zimbra Chatには、2つのパートがあります。

  • Chat Zimlet

  • Chat 拡張機能

Zimbra Chat拡張機能はChat Zimletがなくても正常に機能します。Chat ZimletはChat拡張機能といっしょに動作することを前提とし、設計・作成されています。

Zimlet

Chat ZimletはChatを行なうクライアントコンポーネントです。他のZimlet同様、Zimbraウェブクライアント上で稼動し、管理されます。加えて、Zimbraウェブクライアントに完全に統合されており、同じグラフィックライブラリを使用しています。ZimletはChat拡張機能がなければ動作しません。Zimletと拡張機能はイベントの送受信に特殊なプロトコルを使用しているためです。Zimbraウェブクライアントのサポート対象であるバージョンと全てのブラウザで、Chat Zimletもサポートされます。

機能

  • Zimbraウェブクライアントと統合。

  • 仲間の一覧を管理します。ユーザーは、仲間を追加・編集・削除することができます。

  • チャットルームごとに別のパネルが開きます。

  • ユーザー個人の状態を管理します。

  • 仲間の一覧にいるユーザーとの平文送受信を行ないます。

  • 仲間の一覧にいるユーザーにオンライン状態を送信します。

  • 仲間の一覧にいるユーザーのオンライン状態を表示します。

  • 会話での絵文字 (顔文字) に対応します。絵文字は無料で http://emojione.com/ から提供されています。

  • チャットの全内容をメールとして送信します。

  • チャット履歴内の会話を検索します (拡張機能のオプションが有効である場合。設定項目を参照してください) 。

  • メッセージ受信時、通知をデスクトップに表示します。

拡張機能

Zimbra Chat拡張機能は、Zimbra Chatの要です。接続中のクライアント間でのイベント管理を行なう、完全なチャットサーバーです。

Zimbraのmailboxdサービスとの統合にZALを使用しています。

この拡張機能は、下記2種類の接続に対応可能です。

  • Chat Zimletから受け取るSOAP接続。ZimbraのSOAPインフラを使用します。

  • 互換性のあるクライアントからのXMPP接続。

機能

  • 複数セッションからのイベントを処理します。

  • Chat Zimlet クライアントからのSOAP接続を処理します。

  • 互換性のあるクライアントからパブリックポート経由で受け取るXMPPを処理します (平文とSSL) 接続 (設定項目を参照してください) 。

  • 各会話のチャット履歴をそのユーザーのメールボックス内、専用チャットフォルダに格納します (オプションが有効な場合のみ。設定項目を参照してください) 。

  • ユーザー間の関係をZimbraデータベースに格納します。

インストール

バージョン8.8.0以降、Zimbra Chatは、全Zimbraパッケージと共にZimbraパッケージとして搭載されることになりました。

専用のインストールプロセスは必要ありません。

システムのインストール中またはアップグレード中にZimbra Chatパッケージをインストールしなかった場合、パッケージインストールに関する一般ドキュメントを参照しながらインストールを行なってください。

アップグレード

Zimbra Chatは他の全てのZimbraプラットホームと一緒にアップグレードされます。

専用のアップグレードプロセスは必要ありません。

トラブルシューティング

本項には、管理者が問題を発見し解決できるようなヒントを記載します。解決策が見つからない場合、管理者は問題を報告するプロセスに従って、ガイドを受けることが可能です。

エラーの探索

このプロセスは、原因の特定、解決策の確定、あるいは報告を正確に行なうには、欠かせないプロセスです。

Chat Zimletのエラー

Chat Zimletのソースコード内のエラーを特定するには、まず、Zimbraウェブクライアントをデベロッパーモードにしてください。これにはZimbra環境のブラウザのURLに ?dev=1 を追加します。URLに dev=1 を追加することで、Zimletを含むウェブクライアント全体と全てのソース (省略なし) がZimbraにロードされます。
Zimbraウェブクライアントをロードしている間にデベロッパーツールのブラウザを開きます。

デベロッパーツールのブラウザにあるコンソールに、Chat Zimletのログが表示されます。エラーが発生すると、それがコンソールに出力されます。

エラーがコンソールに出力されていないにもかかわらず動きが不正な場合はデベロッパーツール内にあるオプション 例外ブレイクポイント を有効にします。これによりエラー発生時、そのエラーが起こったポイントとなる行で実行が停止します。

エラー発生時は、該当ファイル、該当行、そしてそのエラーに関するあらゆる詳細を送付してください。その際、適切な窓口を通してエスカレーションをするようにしてください。

エラーが検知されない場合、Chat拡張機能のエラー項を参照してください。

Chat拡張機能のエラー

Chat拡張機能がスローした例外は mailbox.log に出力されます。例外有無のチェックは、本書内の該当の章を参照してください。 FAQに例外に対する解決策が記載されていない場合、その例外情報全体をそえて、適切な窓口を通してエスカレーションしてください。

FAQに例外に対する解決策が記載されていない場合、その例外情報全体をそえて、適切な窓口を通してエスカレーションしてください。

ツール

Google Chromeのデベロッパーツール

Zimbraウェブクライアントで予期せぬ動きがあった場合、Google Chromeのデベロッパーツールを使用して、その原因を探ります。

Google Chromeのデベロッパーツールを開くには

  • メインメニューを開きます。

  • その他のツールというメニューオプションを探します。

  • デベロッパーツールを選択します。

すると新たに、タブがたくさん付いたパネルが表示されます。タブには次のものがあります。

  • Console : サーバーコンソールのようなもの。ログ情報はこのタブに表示されます。JS Runtimeでの操作が可能です。

  • Network : ネットワーク処理が表示されます。メールボックスへの要求、そしてメールボックスからの応答を見たい場合に使用できます。

Firefoxのデベロッパーツール

Firefoxのデベロッパーツールを開くには、メインメニューを開いた後、開発ツール ボタンをクリックします。

すると新たに、タブがたくさん付いたパネルが表示されます。タブには次のものがあります。

  • Console : サーバーコンソールのようなもの。ログ情報はこのタブに表示されます。JS Runtimeでの操作が可能です。

  • Network : ネットワーク処理が表示されます。メールボックスへの要求、そしてメールボックスからの応答を見たい場合に使用できます。

システム情報の収集

トラブルシューティングプロセスの一環として、システム情報の収集は欠かせません。この項には、管理者が (「問題のエスカレーション方法」の項に記載されているように) 問題を正確に報告するに際し、必要かつ有用なシステム情報を収集できるようなヒントを記載します。

Zimbraのバージョン

Zimbraのバージョンを確認するには下記コマンドを入力します。

# zimbraユーザーとして
zmcontrol -v

拡張機能とZimletのバージョン

拡張機能とZimletのバージョンを確認するには下記コマンドを入力します。

# zimbraユーザーとして
java -cp /opt/zimbra/lib/ext/openchat/openchat.jar com.zextras.lib.OpenChat

配備したZimletの一覧

配備したZimletの一覧を確認するには下記コマンドを入力します。

# zimbraユーザーとして
zmzimletctl listZimlets

ユーザーが使用できるZimletの一覧

そのユーザーが使用できるZimletの一覧を確認するには下記コマンドを入力します。

# zimbraユーザーとして
zmprov getAccount user@domain.tld zimbraZimletAvailableZimlets

Zimletのユーザープリファレンスの一覧

ユーザーが利用できるZimletのプリファレンスの一覧を確認するには下記コマンドを入力します。

# zimbraユーザーとして
zmprov getAccount user@domain.tld zimbraZimletUserProperties

F.A.Q.

Chat Zimletに関する問題

ユーザーがログインしてもChat Zimletが機能しません。JavaScriptのエラーがいくつか出ています。どうすればよいでしょうか。

この場合、原因はキャッシュ関連の問題であることが多いです。下記コマンドで全キャッシュをリフレッシュしてください。

# zimbraユーザーとして
zmprov flushCache -a zimlet com_zextras_chat_open

まだ問題が続くようであれば、エスカレーションしてください。

ログインしてもChat Zimletが開始しません。サーバーが利用できないというポップアップが表示されます。どうすればよいでしょうか。

委任されたアクセス機能を使用してそのユーザーにログインした場合、Chat Zimletは開始しません (例:管理コンソールからのメールを表示ボタン) 。そのユーザーのプラバシーを保護するためです。

Chat拡張機能が mailbox.log に正しくロードされているかどうかを確認してください ( mailbox.log の見方は本書の該当項目を参照してください) 。

Zimbra拡張機能のロードはmailboxd のスタートアップ時、下記の行で実行されています。

xxxx-xx-xx xx:xx:xx,xxx INFO  [main] [] mailbox - OpenChat starting ...
xxxx-xx-xx xx:xx:xx,xxx INFO  [main] [] extensions - OpenChat started

まだ問題が続くようであれば、レポートに例外を記載の上、報告してください。

他のZimletでサイドバー表示を利用している場合、チャットの仲間が一覧で見られません。どうすればよいでしょうか。

Chat Zimletが使用しているコンテナは、他のZimletでも使えるものです。このコンテナの使用状況を検出して衝突を回避するようにしています。

このため、Chat Zimletは内部 ブラックリスト を使用します。互換性のない他のZimletを検知したときにドックモードへ切り替えてサイドバーモードを無効にするためです。

ただ、内部ブラックリストに掲載されていないZimletがサイドバー用コンテナを使用していると、この検出は失敗に終わる恐れがあります。

まだ問題が続くようであれば、衝突Zimletの名称を記載し、報告してください。

他のZimletがサイドバーを使用していたためにサイドバーモードから抜け出せなくなっている場合、下記コマンドでZimletのユーザー設定をリセットすれば、ドックモードに変えられます。

# zimbraユーザーとして
# 対象の zimletのユーザープリファレンスをリセット。
zmprov modifyAccount user@example.com \
    -zimbraZimletUserProperties "com_zextras_chat_open:zxchat_pref_dockmode:FALSE"
zmprov modifyAccount user@example.com \
    -zimbraZimletUserProperties "com_zextras_chat_open:zxchat_pref_dockmode:TRUE"
# zimletのユーザープリファレンスをドックモードに変更。
zmprov modifyAccount user@example.com \
    +zimbraZimletUserProperties "com_zextras_chat_open:zxchat_pref_dockmode:TRUE"

上記が終わったら、この修正を反映するため、Zimbraウェブクライアントをリロードします。

まだ問題が続くようであれば、報告してください。

Chat拡張機能に関する問題

2つのサーバー間でサーバーtoサーバーのメッセージ配信ができません。どうすればよいでしょうか。

2つのメールボックス間の接続に問題があるからかもしれません。両サーバーのポート 5269 が開いているかどうか、そして相互にサーバー接続できるかどうかを検証してください。

サーバーのポートが開いているかどうかは、Telnetクライアントを使用してポート 5269 へ接続し、確認します。

全て正常に機能しているようであれば、両サーバーの mailbox.log を開き、イベントを送信してみてください (例:テキストメッセージ1件) 。例外が表示された場合、そのエラーのヒントとなるものがないかどうかを確認してください。特に意味のあるような例外ではなかった場合、その例外を報告書に記載の上、問題を報告してください。

問題のエスカレーション方法

問題を発見しても修正できなかった際、報告には下記の情報が必要です。

  • 問題の詳細説明:期待していることと実際に起きていること。

  • 問題を再現するのに必要な手順の詳細説明。

  • インストール内容と環境についての詳細説明 (本書の「システム情報の収集」項を参照してください) 。

    • サーバー情報:CPU、RAM、サーバー数およびサーバーごとの下記情報

      • Zimbraのバージョン

      • Chatのバージョン

      • インストール済Zimletの一覧

    • クライアント情報

      • ブラウザ名とバージョン

      • サーバーとクライアント間で使用中の接続

      • クライアントのスキン (テーマ)

      • クライアントの言語

      • 対象のユーザーが利用できるZimletの一覧

  • 問題に関するログ全て

    • mailbox.log

      ユーザーのプライバシーを保護するため、個人情報は削除してもかまいません。

高度なトピック

サイジング

Zimbra Chatのストレス試験は実施中です。

2万ユーザーが使用しているZimbra環境において、負荷が約7%上昇したことが確認されています。

Zimbra Chat拡張機能の履歴がいちばん負荷の大きい機能です。メッセージ送信ではmimeのメッセージを作成するか更新するかのどちらかです。つまり、ほんの少しのキロバイト数が読まれるか書かれるかして、データベースのクエリがいくつか実行されるだけです。

大規模に配備する場合、履歴機能の無効化を推奨します。この設定を編集するには 設定項目を参照してください。

設定項目

Chat拡張機能は、ZimbraのCLIから簡単に設定できます。設定は全てLDAPに格納されます。

アカウントの設定を修正するには、下記コマンドを実行します。

# zimbraユーザーとして
zmprov modifyAccount account@example.tld {propertyName} {value}
zimbraChatServiceEnabled

[boolean], 初期値: true

Chatサービスを有効化。
以下に適用可能
* グローバル
* サーバー
zimbraChatHistoryEnabled

[boolean], 初期値: true, 適用にはmailboxの再開が必要。

チャットフォルダ内のチャット履歴の書き込みを有効化。
以下に適用可能
* 提供サービス
* アカウント
zimbraChatConversationAuditEnabled

[boolean], 初期値: false

チャットの会話用の専用ログを有効化。
以下に適用可能
* グローバル
* ドメイン
zimbraChatXmppSslPortEnabled

[boolean], 初期値: false, 適用にはmailboxの再開が必要。

XMPPレガシーSSLポートを有効化。
以下に適用可能
* グローバル
* サーバー
zimbraChatAllowUnencryptedPassword

[boolean], 初期値: false

XMPP経由の暗号なしパスワードログインを許可。
以下に適用可能
* グローバル
* サーバー
zimbraChatXmppPort

[port], 初期値: 5222, 適用にはmailboxの再開が必要。

XMPPの標準ポート。通常StartTLSと共に使用。
以下に適用可能
* グローバル
* サーバー
zimbraChatXmppSslPort

[port], 初期値: 5223, r適用にはmailboxの再開が必要。

XMPPレガシーSSLポート。
以下に適用可能
* グローバル
* サーバー
zimbraChatAllowDlMemberAddAsFriend

[boolean], 任意。

配信リストの全メンバーを仲間として互いに登録。
以下に適用可能
*  配信リスト

ログ

mailbox.log

Mailboxログは、標準のLog4jのログです。以下、mailbox.log のサンプル行です。

xxxx-xx-xx xx:xx:xx,xxx INFO  [qtp1912962767-310:https://123.123.123.123:8443/service/soap/ModifyPropertiesRequest] [name=user@example.com;mid=6;ip=172.17.0.2;ua=ZimbraWebClient - GC58 (Linux)/8.6.0_GA_1153;] soap - ModifyPropertiesRequest elapsed=4
xxxx-xx-xx xx:xx:xx,xxx INFO  [qtp1912962767-310:https://123.123.123.123:8443/service/soap/ZxChatRequest] [] extensions - user@example.com changed status to AVAILABLE
xxxx-xx-xx xx:xx:xx,xxx INFO  [qtp1912962767-310:https://123.123.123.123:8443/service/soap/ZxChatRequest] [] soap - ZxChatRequest elapsed=24

各行は次の要素から構成されています。

xxxx-xx-xx xx:xx:xx,xxx

対象行のタイムスタンプ

INFO

対象行の種類

qtp…ModifyPropertiesRequest

ログの行へ書き込み要求したスレッドについての情報。通常はそのログの行をトリガーしたハンドラ。

name=…

ユーザーのセッションについての情報

soap -

ログの行のソース

ModifyPropertiesRequest elapsed=4

ログの行の内容

zmmailboxd.out

Mailboxログは、標準のLog4jのログです。下記は zmmailboxd.out のサンプル行です。

xxxx-xx-xx xx:xx:xx.xxx:INFO:oejs.SetUIDListener:main: Opened ServerConnector@397fbdb{HTTP/1.1}{0.0.0.0:8080}
xxxx-xx-xx xx:xx:xx.xxx:INFO:oejs.SetUIDListener:main: Opened ServerConnector@36ebc363{SSL-http/1.1}{0.0.0.0:8443}
xxxx-xx-xx xx:xx:xx.xxx:INFO:oejs.SetUIDListener:main: Opened ServerConnector@54d9d12d{SSL-http/1.1}{0.0.0.0:7071}

Zimbra Connect

Zimbra Connect について

ご注意ください: ZCS 8.8.15 の初期リリースでは Zimbra Connect の UI は英語、フランス語、およびロシア語でのみ提供しておりますが、今後のパッチリリースに他の言語のサポートを提供する予定となっております。

Zimbra Collaboration 8.8.15 に追加されました Zimbra Connect では、グループと法人のメッセージ機能、ファイル共有、スクリーン共有、およびカジュアルのビデオチャット機能が含まれているビジネス用のインスタントメッセージプラットフォームを Zimbra ウェブクライアントへ追加することが可能です。

Zimbra Talk V2との違いについて

Zimbra Connect と Zimbra Talk V2 について、主に以下の違いがございます。

Table 60. バックエンド
Zimbra Talk V2 Zimbra Connect

XMPPをサポートする

XMPP をサポートしない

専用の API セットがない

専用の API セットとクライアントプロトコールを提供する

クライアント/サーバのコミュニケーションが SOAP でベースしている

クライアント/サーバのコミュニケーションは WebSockets でベースしている

Table 61. フロントエンド
Zimbra Talk V2 Zimbra Connect

友達のリストへ登録したユーザーと交流する

GAL によりユーザーと交流する

友達リストにベースした単純UI

履歴にベースした単純UI

重い、使いにくいUI

低い、使いやすいUI

スペースの設定がスペース自体で指定する

スペースの設定がスペースの"general"チャネルで指定する

ユーザー単位でベースしたビデオとオーディオフィードの管理:ユーザー毎で他のユーザーのビデオやオーディオフィードを自由に停止し、自分自身で受信する内容をカスタマイズできる

ホストにベースしたビデオとオーディオフィードの管理:ホストが特定の参加者のビデオやオーディオを停止し、全参加者へ影響します。ユーザー毎にフィードを独自に停止することが継続に可能です。

Table 62. 機能
Zimbra Talk V2 Zimbra Connect

ファイル共有はチャット、グループ、よおびチャネルで可能

Zimbra 8.8.15p2 によりファイル共有はチャット、グループ、およびチャネルで可能となる予定です

インスタントミーティングは利用可能

Zimbra 8.8.15p2 によりインスタントミーティングは利用可能の予定です

フロントエンド側の機能について

Zimbra Connect に以下のフロントエンド側の機能が含まれています。

  • メッセージ通信と既読状況の報告

  • 1対1のインスタントメッセージ

  • グループのメッセージ

  • 法人のメッセージ(スペースやチャネル)

  • グループのビデオコール

  • チャネルに無制限の参加者のビデオコール

  • ファイル共有

  • スクリーン共有

  • 顔文字

バックエンド側の機能について

Zimbra Connect は以下のバックエンド側の機能が含まれています。

  • COS とユーザーでの機能有効化

  • 内部の TURN サーバ互換性

  • コアのインストール必要がありません。パッケージマネージャでのZimletインストール

  • 設定が必要ない

  • サーバ負荷を回避するため、ピアツーピアの WebRTC プロトコール

  • 専用の audit ログファイル

ライセンスについて

Zimbra Connect はユーザー毎にライセンスしています。ライセンスの詳細は他の Zimbra ネットワーク版の機能と同様に、ネットワーク版のラインセスファイルに記録しております。グローバルの管理者がラインセスのユーザー上限まで、詳細の機能を有効化することが可能であり、「advanced」のユーザー様のみがライセンスの上限にカウントされます。

Zimbra Chat と Zimbra Connect

Zimbra Chat と Zimbra Connect の互換性はなく、同時に運用することができません。そのため、これらの製品が同じ Zimbra ネットワーク版の環境で同時にインストールすることができません。Zimbra Connect パッケージをインストールする際に Zimbra Chat Zimlet が自動的にアンインストールされます。ただし、Zimbra Connect の基準モードでは Zimbra Chat と同一の機能を提供しており、「advanced」の Zimbra Connect 機能を提供していないユーザー様は無制限で基準モードのチャット機能を利用いただけます。「advanced」のユーザー様はすべての機能を他の「advanced」ユーザ様と利用いただき、基準モードの basic ユーザー様と1対1のインスタントメッセージを利用できます。基準モードの basic ユーザー様は全ユーザーへの1対1のインスタントメッセージのみを利用いただけます。

デフォルトでは、すべてのユーザー様は基準の Basic ユーザーとして登録し、Zimbra の管理者がユーザーに Advanced 機能を任意で有効化することが可能です。

Zimbra Connect Zimlet のインストール方法

Zimbra Connect Zimlet は Zimbra のリポジトリに提供しており、OSのパッケージマネジャーで簡単にインストールとアップグレードすることが可能です。

Red Hat と CentOS で Zimbra Connect Zimlet のインストール手順

Red Hat と CentOS では、以下のコマンドで Zimlet をインストールします。

yum install zimbra-connect

Ubuntu で Zimbra Connect Zimlet のインストール手順

Ubuntu では、以下のコマンドで Zimlet をインストールします。

apt-get install zimbra-connect

Zimlet をインストールしますと、サーバから Zimbra Chat のコンポーネントが自動的に削除します。

Zimbra Talk から Zimbra Connect へ移管する方法

理論的に、Zimbra Talk と Zimbra Connect のコアコンポーネントとZimletが異なるため、同じサーバで同時に運用することは可能ですが、データベースが共通するため、同時に利用することを推奨しておりません。また、Zimbra Connect を正常に運用するため、データベースのデータをTalk形式からConnect形式へ移管する必要もあります。

Talk データを Connect へ移管するため、`doImportChannels`コマンドを活用します。

[zimbra@mailserver ~]$ zxsuite connect doImportChannels

構文:
   zxsuite connect doImportChannels [attr1 value1 [attr2 value2...]]


パラメータリスト

パラメータ名                           種類       期待した値
delete_destination_before_import(O)    Boolean    true|false

(M) == 必要のパラメータ, (O) == 任意のパラメータ

このオペレーションは複数回に実施することが可能ですが、操作自体が一方通行であり、巻き戻すことができませんので、ユーザーがConnectへ切り替えましたら(Talk Zimletを無効化し、Connect Zimletを有効化した後)、ConnectのデータをTalkへ戻せることができません。

Zimbra Connect の管理について

Zimbra Connect の機能は zxsuite config のコマンドラインツールで有効化と無効化することが可能です。

  • Zimbra Connect の ≪Advanced≫ 機能を有効化する場合

    • 属性値: teamChatEnabled

    • 設定可能のレベル: COS, account

  • チャットの履歴を有効化、または無効化する場合

    • 属性値: historyEnabled

    • 設定可能のレベル: global, server, COS, account

  • ビデオチャットを有効化、または無効化する場合

    • 属性値: videoChatEnabled

    • 設定可能のレベル: global, server, COS, account

ブラウザーの互換性について

Zimbra Connect の機能は Zimbra ウェブクライアントをサポートしているブラウザですべて提供していますが、多少のクライアント側の制限がございます。

ブラウザ クイックアクセスサイドバー Connectのタブ ビデオチャット スクリーン共有

Internet Explorer 11+

×

×

Microsoft Edge

×

×

Mozilla Firefox

Google Chrome

〇 (拡張のインストールが必要)

Safari

×

Google Chrome をご利用の場合、スクリーン共有の機能を利用いただくため、"Zextras Companion" の拡張をインストールする必要があります。なお、本拡張はChrome ウェブストアで提供しています。

Firefox をご利用の場合、スクリーン共有の機能を利用いただくために最低にバージョン 66 をインストールする必要があります。

UI について

Zimbra Connect の UI が PREACT で開発し、Zimbra ウェブクライアントと完全に関連されています。2つのクライアント側コンポーネントが含まれています、クイックアクセスサイドバーと完全な機能を提供しているConnectのタブです。

クイックアクセスサイドバーは Zimbra Chat と同様の機能を運用しており、簡単に1対1のインスタントメッセージ、またはグループの会話が可能です。ファイル共有やビデオチャット、などの Advanced Zimbra Connect 機能について、Zimbra Connect の Advanced 機能が有効化したユーザーアカウントにのみ クイックアクセスサイドバーで利用いただけます。

Connect タブは完全なる Zimbra Connect UI であり、すべての法人インスタントメッセージの機能、例えばスペースとチャネルを提供しています。 タブ自体はBasicとAdvancedのユーザーに提供していますが、Advancedユーザーにのみ法人機能が提供します。

クイックアクセスサイドバーについて

クイックアクセスサイドバーではユーザーが最近に交流した人物、グループ、およびチャネルを表示し、簡単のチャット画面をすぐに開けることが可能です。

この機能は "Basic" と "Advanced" ユーザーへ提供しており、"Advanced" ユーザーにのみ高度が機能も提供しています。

connect_quick_chat_1.png connect_quickaccess_sidebar_1.png

Connectのタブ

Connectのタブは他の機能タブ(例えばメールやカレンダーのタブ)と同様に完全なる機能の利用が可能です。

connect_home_1.jpg

インスタントメッセージと法人コミュニケーションについて

1対1チャット

1対1チャットはクイックアクセスサイドバー、またはConnectのタブから開始することが可能です:

  • クイックアクセスサイドバーの場合、(チャット履歴により)チャット可能の相手を選択し、新しいチャットをすぐに開始します。

connect_new_chat_2.png

  • Connectタブの場合、"New" をクリックし、"New Chat" でGALからチャット希望の人物を選択します。

connect_new_chat_1.png

最近の1対1チャットは Connect タブの "Conversations"、およびクイックアクセスサイドバー (丸いアイコン) に表示されます。

グループについて

グループでは、複数の人(5人まで)を同時にコミュニケーションを取れることが可能です。グループは特定のスペースへ関連していない、継続に残るものです。ユーザーは友達リストから他のユーザーへグループの招待を送信し、グループを作成することが可能です。また、グループのメンバーは同じ方法でグループへ他のユーザーへ参加を招待することができます。全ユーザーがグループを脱落した場合、グループが消えます。

グループの機能について
  • グループに参加しているユーザーが許可しているユーザー上限まで他のユーザーへグループの招待を送信できます。

  • グループに参加しているユーザーが他のユーザーとチャットすることがでいます。グループに参加している全員がそのグループへ送信したメッセージを閲覧できます。

  • グループに参加しているユーザーが他のグループのユーザーへファイル送信が可能です。グループで送信したファイルがそのグループに参加している全員にアクセスが可能です。

  • グループに参加しているユーザーが他のユーザーとのビデオチャットを開始することが可能です。また、他のグループのユーザーもグループのビデオチャットへ参加することが可能です。

グローバル管理者は管理コンソールのグローバル設定にて、Zimbra Connect の設定で最大のグループメンバー数を指定することが可能です。

グループのUIについてGroups UI

最近のグループチャットは Connect タブの "Conversations"、およびクイックアクセスサイドバー (丸い四角アイコン) に表示されます。

  • 新しいグループを作成する方法

    新しいグループを作成する場合、Connect タブの "New" ボタンをクリックし、"New Group" を選択します。

    connect_create_new_group_1.jpg

    その後、グループの件名を記入し、グループへ招待する人物を選択し、"Create" をクリックします。

    connect_create_new_group_2.jpg

  • グループへ参加者を招待する

    グループへ人物を招待する場合、グループの詳細情報を開き、追加するユーザーを選択し、"Save" をクリックします。

    connect_add_user_to_group_1.jpg

  • グループのビデオチャットを開始する方法

    グループチャットを開始する場合、グループチャット画面のカメラアイコンをクリックします。

    connect_group_start_videochat_1.jpg

    グループにあるメンバーはこのカメラアイコンをクリックすることで、実施中のビデオチャットへ参加することが可能です。

  • グループを脱落する方法

    グループから脱落する場合、グループの詳細情報に "Leave Group" をクリックします。

    connect_leave_group_1.png

    その後、警告メッセージの下に "Yes" をクリックします。

    connect_leave_group_2.png

スペースについて

スペースは無制限のチャネルを持つことができるテーマのコンテナです。 基本的に、スペースはコミュニティセンターや道の駅みたいが場所で、ユーザーが特定の場所(チャネル)で異なるトピックをチャットできます。

スペースの機能
  • 各スペースは特定の名前とトピックがあります。 スペースの設定にて、スペース名、およびトピックを自由に変更することが可能です。

  • メンバーはスペースをいつでも脱落できます。

  • スペースの管理者が新しいチャネルの作成、およびスペースへメンバーを招待することが可能です。

スペースのUIについて

スペースは Connect タブの専用セクションに含まれており、以下のスペース関連の機能へアクセスできます。

  • スペースの作成

    スペースを作成する場合、Connect タブの "New" ボタンをクリックし、 "New Space" をクリックします。

    connect_new_space_1.jpg

    その後、スペースの名前とトピックを記入し、招待するユーザーを選択し、"Save" をクリックします。

    connect_new_space_2.jpg

  • スペースから脱落する方法

    スペースから脱落する場合、スペースのGeneralチャネル情報にて、"Leave Space" をクリックします。

参加者はスペースからいつでも脱落することができますが、他のスペースの管理者が存在する場合のみ、スペースの管理者がスペースから脱落することが可能です。

スペースを脱落した場合、再度にスペースへ参加するために改めて招待する必要があります。以前はスペース管理者のユーザーは通常の参加者として追加しますので、管理者の権限を改めて設定する必要もあります。

スペースの設定について

スペースの設定が General チャネルの情報で指定しています。

スペースの作成者が最初のスペースの管理者となり、参加者にクラウンのアイコンをクリックすることで、他のユーザーへ管理者の権限を与えることが可能です。

connect_space_acls_1.png

スペースの管理者はスペース内に新しいメンバーへの招待、新しいチャネルの作成、メンバーの削除、およびチャネルの削除が可能です。通常の参加者はメンバーの招待やチャネルの作成、などはできません。

チャネルについて

チャネルはスペース内にあるトピックを指定した場所です。チャネルにはユーザー数の上限がなく、ユーザーが参加しているスペースにあるチャネルを自由に参加できるので、グループと違って、参加するために招待される必要がありません。

新しいスペースが作成する度、"General" のチャネルが自動的に作成され、ユーザーがスペースを参加した際に自動的に "General" へも参加します。

チャネルの機能
  • チャネルのユーザーは他のチャネルのユーザーとチャットできます。チャネルへ送信したメッセージはそのチャネルの全メンバーが閲覧します。

  • チャネルのユーザーが他のチャネルのユーザーとビデオチャットを開始することが可能です。他のチャネルのメンバーはチャネルに実施中のビデオチャットへ参加することが可能です。

チャネルのUI

チャネルはConnectタブにあるスペースに囲まれており、以下のチャネル関連の機能を管理できます。

  • チャネルの作成

    新しいチャネルを作成する場合、"New"ボタンをクリックし、"New Channel"をクリックします。

    connect_new_channel_1.png

    その後、以下を指定します:

    1. チャネルを追加するスペース名 (必須)

    2. チャネル名 (必須)

    3. チャネルのトピック (任意)

      最後に、"Save" をクリックし、チャネルを作成します。

  • チャネルへ参加する方法

    チャネルへ参加する場合、チャネルのレベルをクリックし、"Join Channel" をクリックします。

  • チャネルのビデオチャットを開始する方法

    チャネルのビデオチャットを開始する場合、チャネルのチャット画面にカメラのアイコンをクリックします。

    connect_group_start_videochat_1.jpg

    チャネルのメンバーは同一のボタンをクリックすることで、実施中のビデオチャットへ参加することが可能です。

  • チャネルから脱落する方法

    チャネルか脱落する場合、チャネルの詳細情報に赤いの "Leave Channel" をクリックします。

    connect_leave_channel_1.png

通常のユーザーとスペースの管理者がチャネルの脱落や参加を自由に実施することが可能です。

ビデオチャットについて

ビデオチャットの機能はマンツーマンのチャット、グループ、およびチャネルに提供しておりますので、ウェブカメラとヘッドセットで複数人がリアルタイムでコミュニケーション、またはコンピュータの画面を他の参加者へ共有することが可能です。

この機能は WebRTC プロトコールにペースしております。このプロトコールではピアツーピアの通信を自動的に調整する技術を活用し、サーバに高負荷を起こせずに、クライアントが直接に他の参加者とコミュニケーションを成立し、利用可能のネットワーク速度によりコールの品質が自動的に調整されます。最大の品質はビデオとオーディオのFull HDまで可能です。なお、ビデオチャットを初めて開始した場合、ユーザはブラウザにカメラとマイクロフォンへのアクセスを許可する必要があります。

ビデオチャットのUIについて

connect_group_videochat.png

ビデオチャットのUIは主に3つの部分に別れています。

  • 中央がメインのビデオストリームを上に表示し、セカンダリのビデオストリームを下に表示します。 表示するビデオストリームの数は画面の解像度、およびウインドウサイズにより異なります。

  • 左側にグループ、またはチャネルのインスタントメッセージチャットが表示します。 このチャットは常に表示し、通常に利用できます。チャットの履歴もグループやチャネルのチャット履歴へ保管します。

  • 左下にユーザーのビデオフィードと管理オプション(ビデオの無効化、マイクロフォンのミュート、および画面の共有)

ビデオストリームの左下にある "Hang up" ボタンをクリックすることで、ユーザーは実施中のビデオチャットから切断することが可能です。 ビデオチャットが実施中である場合、グループやチャネルのユーザーはグループ名やチャネル名の下に "Call in progress" のメッセージが表示し、チャットのカメラのアイコンをクリックすることで参加することが可能です。

ビデオストリームの管理

ビデオストリームはピア間の接続順番により、「最初に接続した順位」のベースとして表示します。

各参加者は自信のオーディオやビデオのストリームを自由に停止することが可能です。

画面の共有

connect_videochat_screensharing_1.png

画面の共有ボタンをクリックしますと、完全の画面、または特定のウインドウのみを共有するオプションがユーザーに要求します。 選択した後、ユーザーのウェブカメラのビデオストリームが画面の共有ストリームへ入り変えます。

プレゼンス

プレゼンスが Zimbra Connect で自動的に管理します。ユーザーがログインした際、Connect タブを選択している状態と問わず、そのユーザーが オンライン として表示します。

ユーザーのプレゼンス機能として、すべてのメッセージが複数の確認チェックマークとして表示されます: connect_message_delivered_1.png

  • 0 チェックマークの場合、メッセージがまだサーバへ送信したいない状態を示します

  • 1 チェックマークの場合、メッセージがサーバへ送信している状態を示します

  • 2 チェックマークの場合、メッセージが全ユーザーに確認されたことを示します

既読していないメッセージ

1対1のチャット、およびグループやチャネルのチャットに既読していないメッセージ数が右側で表示されます。

connect_unread_messages_1.png

チャットの履歴

各1対1のチャット、およびグループとチャネルのチャット履歴は同じウインドウで閲覧できます(つまり、チャネルの履歴を確認する場合、そのチャネルを開きます)。また、オフラインのユーザーへ送信したメッセージは該当の1対1チャット、グループ、またはチャネルに表示されます。

STUN/TURN サーバについて

WebRTC はピアツーピアのプロトコールであるため、コネクションを成立するために、ビデオチャットにある全ユーザーはお互いのクライアントへ接続する必要があります。

ネットワークのNATルールやサービスプロバイダーのポリシーにより、お互いのクライアントへ接続することは不可能である場合、TURNサーバを運用することで各ピアに適切なコミュニケーションを成立することが可能となります。 Zimbra Connect では、TURNサーバのURL、およびログイン情報を Zimlet 設定に登録することで、STUN/TURNのサーバを利用することが可能です。

Zimbra Connect に TURN サーバを利用するように設定する方法

CLI の zxsuite connect iceServer コマンドで専用の TURN 設定ツールを提供しています。

zimbra@mailserver:~$ zxsuite connect iceServer

ビデオコールでコネクションを成立するための ice サーバのリストを編集する。
グローバル(デフォルト)、提供サービス、またはアカウント単位で設定することが可能です。

  add                      - グローバル(デフォルト)、提供サービス、またはアカウント単位で新しい ice サーバを追加する
                             zxsuite connect iceServer add {turn:turn.example.com:3478?transport=udp} [attr1 value1 [attr2 value2...]]

  remove                   - グローバル(デフォルト)、提供サービス、またはアカウント単位で特定の ice サーバを削除する
                             zxsuite connect iceServer remove {turn:turn.example.com:3478?transport=udp} [attr1 value1 [attr2 value2...]]

  get                      - グローバル(デフォルト)、提供サービス、またはアカウント単位で設定している ice サーバを返答する
                             zxsuite connect iceServer get [attr1 value1 [attr2 value2...]]

"add" のサブコマンドで新しい TURN サーバを追加します。

構文:
   zxsuite connect iceServer add {turn:turn.example.com:3478?transport=udp} [attr1 value1 [attr2 value2...]]

パラメータのリスト

名前             種類          期待する値
url(M)           String    turn:turn.example.com:3478?transport=udp
username(O)      String    myuser
credential(O)    String    mysecretkey
account(O)       String    user@example.com
cos(O)           String    default

(M) == 必要のパラメータ, (O) == 任意のパラメータ

実例:

zxsuite connect iceserver add turn:turn.example.com credential mysecret username myuser
zxsuite connect iceserver add turn:turn.example.com credential mysecret username myuser account testaccount@example.com

特定のユーザー、または提供サービスのみを専用に処理するため、複数の TURN サーバを追加することが可能です。(上記のコマンドに `user`や`cos`の任意パラメータで指定します)

TURN サーバ側では、ZimbraユーザーとTURNユーザーの一対一マッピングが必要ないため、設定を分かりやすくするため、専用のユーザーアカウントと秘密鍵のみを用意することを推奨しています。

Zimbra Open Drive

Zimbra Open Drive は Zimbra を第三者の製品とサービスへ関連させるクライアントです。

注意:8.8.11 以前のバージョンでは、Zimbra Open Drive は Zimbra Drive として提供しました。

現在、Zimbra Open Drive で動作するものは下記のとおりです。

  • Nextcloud

  • ownCloud

Zimbra Open Drive上のデータがZimbraサーバーおよびその他Zimbra製品に置かれることはありません。同様にこのデータがZimbraおよび他の組み込まれたサービスで管理されることはありません。このため、Zimbraサポートは、NextcloudおよびownCloudサーバーに関する問題はサポートしません。

本書について

本書は、システム管理者を対象に記載しています。本書の目的は、プロダクトアーキテクチャについての深い見解と、安定したカスタマイズに必要な知識を提供することです。

Zimbra Open Driveは、バージョン8.7.6以降のZimbraにベータ版ソフトウェアとして含まれています。そしてバージョン8.8.0では安定版となっています。Zimbra Open DriveはZimbra Collaboration SuiteにZimbraパッケージとして搭載されています。このため、Zimbraのインストールプロセス中にZimbra Open Driveをインストールすることができます。

サポート対象環境での製品の インストール および 設定 については、インストールの章と設定の章にそれぞれ記載します。
アップグレードのプロセスと互換性についての情報は、アップグレード の章に記載します。
Zimbra Open Driveの アンインストール 手順は、アンインストールの章で説明します。高度なトピックス、例えばソースからのソフトウェアのビルド方法などは、高度なトピックス の章に記載します。

バックアップ、アーカイビング、アクセスセキュリティ、ユーザー管理について、Zimbraでは管理しません。
サードパーティ製品における、障害、データとアクセスのセキュリティ、ストレージ管理、データのアーカイブビングについて、ZimbraあるいはZimbraのソフトウェアでは管理しません。また、このことは、Zimbraの "Maintenance & Support Terms and Conditions" にある2.4(a)項「保守とサポート条件」にて規定されているとおり、Zimbraサポート契約の範囲ではありません。

概要

一般的なアーキテクチャ

Zimbra Open Driveの目的は、Zimbraのエンドユーザーがクラウドサービスへ接続すること、そして、外部からZimbraへ接続することです。

Zimbra Open Driveは3つのパートで構成されています。Zimbra拡張機能、Zimlet、そしてCloud Appです。この3つで、外部ストレージサービスと認証のメカニズムをZimbraウェブインターフェースに融合します。Zimbraの各アカウントは、外部ストレージサービスのアカウントとリンクすることになります。

コンポーネント

Zimbra Open Driveには、次のコンポーネントがあります。

  1. Zimbra Open Drive拡張機能

  2. Zimlet

  3. Cloud App

全てのコンポーネントは必須で、それぞれ慎重に設定する必要があります。ただし、インストールや設定でのエラーが原因でZimbraが利用できなくなることはありません。

拡張機能

Zimbra Open Drive拡張機能は、mailboxdコンポーネント内にインストールされます。この拡張機能は、認証サービスやZimletへの必要動作を行ないながら、Zimbra Open Drive ZimletとCloud Appとの間で役割を果たします。

Zimlet

Zimbra Open Drive Zimletによって、ユーザー用Zimbraインターフェースに新しい ドライブ タブが追加されます (プリファレンスタブの手前) 。Zimletを使って、ユーザーはリンクされたクラウド内での検索が行なえます。
Zimletのコンポーネントは、 com_zextras_drive_open.zip というパッケージに格納されています。このZimlet名は com_zextras_drive_open です。

Cloud App

クラウドストレージの外部サービスがZimbra Open Drive拡張機能と連携するには、専用のAPIを使っている特定のアプリが必要です。Zimbra Open Driveでは、サポートしているサービスごとのアプリを提供します。

Nextcloud/ownCloud

Nextcloud/ownCloudアプリは、NextcloudとownCloudのための特別なアプリケーションです。Zimbraの資格情報を使ってownCloudとNextcloud内の認証を行ないます。また、NextcloudとownCloudからZimbra拡張機能に合うバージョンを抽出する互換レイヤーを提供します。

インストール

本項には、管理者がマニュアル操作でZimbra Open Driveをインストールするための手順を記載します。

要件

  • OSにアクセスするためのRootレベル

  • 外部クラウドのサポート対象サービスへの管理者権限でのアクセス (参照 Cloud App )
    以下がサポート対象のバージョンです。

    • Nextcloud 9, 10, 11

    • ownCloud 9.0, 9.1, 10

Zimbraパッケージでのインストール

本項には、Zimbra Open Driveの拡張機能およびZimbra Open Drive Zimletのインストール方法を記載します。

Zimbra Open Driveの拡張機能とZimbra Open Drive Zimletは共に公式のZimbraインストーラーを利用してインストールします。Zimbraインストーラーでは以下の確認用の質問が表示されます。

Use Zimbra's package repository [Y] Yes
...
Install zimbra-drive [Y] Yes
インストール済のZimbraの場合

Zimbraインストール中、Zimbraのレポジトリは該当のソースリストに追加されます。このため下記コマンドを使ってZimbra Open Driveをインストールすることができます。

# rootユーザーにて。apt-getが利用可能な場合。
apt-get update
apt-get install zimbra-drive
# rootユーザーにて。yumが利用可能な場合。
yum update
yum install zimbra-drive

上記終了後、Zimletの配備用コマンドとmailboxの再開を下記のとおり実行することで、Zimbra Open Drive拡張機能が有効になります。

# zimbraユーザーにて
zmzimletctl deploy /opt/zimbra/zimlets/com_zextras_drive_open.zip
zmmailboxd  restart

Cloud Appのインストール

特定のサポート対象であるZimbra Open Drive Cloud Appをインストールする手順を説明します。

アーカイブ zimbradrive.tar.gz で現在サポート対象としているクラウドサービスは、Nextcloud とownCloudです。

Nextcloud/ownCloud

以下、Nextcloud とownCloudに必要な共通のインストール手順です。
プレースホルダ PATHTOCLOUD はサーバー上のNextcloud/ownCloudサービスのパスです。

  1. zimbradrive.tar.gz を Nextcloud/ownCloud ドライブにコピーします。
    scp zimbradrive.tar.gz root@cloud:/tmp

  2. Nextcloud/ownCloud サーバーにて、 zimbradrive.tar.gzPATHTOCLOUD/apps に展開します。
    tar -xvzf zimbradrive.tar.gz -C PATHTOCLOUD/apps

  3. 展開したフォルダ PATHTOCLOUD/apps/zimbradrive の権限を Nextcloud/ownCloudのユーザーオーナー(例: www-data)にて変更します。
    chown -R www-data:www-data PATHTOCLOUD/apps/zimbradrive/

  4. Nextcloud/ownCloud の管理用インターフェースあるいはコマンドにてZimbra Open Drive Appを有効にします。
    sudo -u www-data php PATHTOCLOUD/occ app:enable zimbradrive

この時点は、Nextcloud/ownCloud Zimbra Open Drive Appがインストール済みで、これから設定が必要な段階です。

サーバーの設定が正しくないとApacheウェブサーバー上でZimbra Open Driveが機能しません。これについては、Nextcloud マニュアル内の Apache Web Server Configuration に関する手引き Nextcloud installation を参照してください。 またはownCloud マニュアル内の手引き ownCloud installationを参照してください。

設定

Zimbra Open Driveの設定は、Zimbra側とクラウド側に分かれます。Zimbra Open Drive Zimletは標準のZimlet設定以外の設定は不要です。このため、Zimbra側はZimbra Open Drive拡張機能の設定だけが必要となります。クラウド側の設定は、後述で各サポート対象クラウドサービスごとに説明します。クラウドサービスは独立しているため、使用したいクラウドサービスの設定を行うだけでよいです。

Zimbra拡張機能の設定

Zimbra拡張機能のセットアップには、ペアになるクラウドサービスのURLが必要です。このURLをドメイン属性 zimbraDriveOwnCloudURL 内に設定しなければなりません。また、同一ドメインに属するユーザーは全員、同じこのURLでなければなりません。別のドメインの場合には、別のクラウドサービスのURLでかまいません。
クラウドサービスのURLを設定するコマンドは次のとおりです。

# zimbraユーザーにて
zmprov md domainExample.com zimbraDriveOwnCloudURL CLOUD_URL

クラウドサービスのURL (CLOUD_URL) は次の形式でなければなりません。 protocol://cloudHost/path

  • protocol: http または https

  • cloudHost: 対象のクラウドサービスのサーバーホスト名

  • path: 対象のクラウドサービスのサーバー内パス

各クラウドサービスには個々のエントリポイントがあります。
Nextcloud/ownCloudの場合、このURLは index.php protocol://cloudHost/path/index.php を対象としていなければなりません。

Cloud Appの設定

Nextcloud/ownCloud

全てが正常に設定されたら、Zimbraのエンドユーザーは、自身のZimbraのユーザーアカウントとペアになるプライベートなアカウントをクラウドサービス内に作成します。新たに作成したこのクラウドアカウントは、Zimbraのユーザー資格情報を継承し、また、Nextcloud/ownCloudのインターフェース内ユーザーリストに表示されることになります。ただし、Zimbra Open Drive Appが有効化されるまで、このアカウントはアクティブにはなりません。

NextcloudとownCloudには共に、以下の設定項目があります。Nextcloud/ownCloud管理パネルの左サイドバー内に、新たな項目 Zimbra Open Drive が表示され、下記の項目のある設定ビューが開きます。

  • (チェックボックス) Enable Zimbra authentication back end
    (チェック付き必須) チェックがオンのとき、Zimbra Open Drive App のクラスをNextcloud/ownCloudに使用させる役割を果たすconfig.php内に、設定が追加されます。チェックがオフの場合、この設定は削除されます。

  • (チェックボックス) Allow Zimbra’s users to log in
    (チェック付き必須) ユーザーがNextcloud/ownCloudの利用に自身のZimbraの資格情報を使えるようにします。

  • (入力項目) Zimbra Server
    (必須) ZimbraウェブメールのホストまたはIP。

  • (入力項目) Zimbra Port
    (必須) Zimbraウェブメールのポート。

  • (チェックボックス) Use SSL
    ZimbraウェブメールのポートがSSL認証を使用している場合、オンにします。

  • (チェックボックス) Enable certification verification
    Zimbraが信頼できない証明を使用している場合に限り、無効にします。

  • (入力項目) Domain Preauth Key
    Zimbraエンドユーザーは、Zimbra Open Driveへアクセスし、プライベートアカウントを作成すると、以降Zimbraの資格情報を使用してNextcloud/ownCloudへログインできるようになります。Nextcloud/ownCloudのウェブインターフェースのアプリメニュー内ZimbraアイコンからZimbraウェブメールタブを開くことができます。ログインは不要です。
    この機能はDomain Preauth Keyがコピーされている場合に限り、使用できます。Zimbra Domain Preauth Keyの表示にはZimbraで下記コマンドを実行します。
    # zimbraユーザーにて
    zmprov getDomain example.com zimbraPreAuthKey
    # 応答が空であれば、以下のコマンドで作成できます。
    zmprov generateDomainPreAuthKey domainExample.com

アップグレード

本項には、管理者がマニュアル操作でZimbra Open Driveをアップグレードするための手順を記載します。各コンポーネントのバージョンに注意を払うことが重要です。各コンポーネントが同じバージョンを持つ場合に限り、互換性が保証されるからです。
Zimbra Open Drive Zimletと拡張機能は、Zimbraのアップグレードと一緒にアップグレードすることができます。しかし、Zimbra Open Drive Appはマニュアル操作での更新が必要です。

Zimbra拡張機能とZimletのアップグレード

Zimbraをアップグレードするときに、Zimbra Open Driveも直接そのinstallationからインストールすることができます。下記のようにapt-getやyumを使って、Zimbraと同じメジャーバージョン、マイナーバージョンにZimbra Open Driveをアップグレードし続けることができます。

# rootユーザーにて。apt-getが利用できる場合。
apt-get update; apt-get install zimbra-drive
# rootユーザーにて。yumが利用できる場合。
yum update; yum install zimbra-drive

Cloud Appのアップグレード

Zimbra Open Drive Zimletや拡張機能とは異なり、Zimbra Open Drive Cloudアプリの場合はバージョンが変更される度にマニュアル操作でアップグレードを行う必要があります。

Nextcloud/ownCloudにあるZimbra Open Drive Appをアップグレードするには、ファイルを入れ替える必要があります。この手順ですが、インストール([Nextcloud/ownCloud])の際に次のとおり実施します。

  1. zimbradrive.tar.gz を Nextcloud/ownCloud ドライブにコピーします。
    scp zimbradrive.tar.gz root@cloud:/tmp

  2. Nextcloud/ownCloud サーバーにて、 zimbradrive.tar.gzPATHTOCLOUD/apps に抽出します。
    tar -xvzf zimbradrive.tar.gz -C PATHTOCLOUD/apps/apps

  3. 抽出したフォルダ PATHTOCLOUD/apps/zimbradrive の権限を Nextcloud/ownCloudのユーザーオーナー(例: www-data)にて変更します。
    chown -R www-data:www-data PATHTOCLOUD/apps/zimbradrive/

バージョン0.0.1からのアップグレード中である場合は、以降使用しないテーブルとなるoc_zimbradrive_usersを削除します。Mysqlで次のコマンドを実行します。
DROP TABLE oc_zimbradrive_users;

アンインストール

本項には、管理者がマニュアル操作にてZimbra Open Driveのアンインストールとシステムのクリーンアップを行なうための手順を記載します。

Zimbra Open Driveパッケージの無効化

Zimbra Open Drive拡張機能とZimbra Open Drive Zimletは、Zimbraのパッケージとしてインストールされているためアンインストールが想定されていません。Zimbra Open Driveの無効化は、対象のユーザー、ドメイン、あるいは提供サービスのZimbra Open Drive Zimletを無効にすることで実施します。

Cloud Appの削除

Nextcloud/ownCloud

Nextcloud/ownCloud Appの削除は2つの手順で行います。クリーンアップとアプリのアンインストールです。

クリーンアップの手順では、Zimbraユーザーの全データをNextcloud/ownCloudから削除します。後戻りすることはできません。この手順の 必要条件 は、Zimbra Open Driveがインストールされていて、有効であることです。
ただし、このクリーンアップ作業はスキップすることができます。Zimbra Open Drive Appのアンインストールは、Zimbraユーザーのデータ削除を行なわなくても実施できるからです。

クリーンアップ

クリーンアップを開始する前に、Zimbraユーザーによるアクセスを無効化しておくことを推奨します。これには、設定項目 Allow Zimbra’s users to log in のチェックをオフにします。

下記コマンドにより、Zimbra Open Drive Appで作成したユーザーが削除され、Zimbraユーザーへの参照が格納されているテーブルがクリーンアップされます (mysql_pwdocc_db の内容を正しく変更してから実行してください)。

cd /var/www/cloud           # OCCのパスへ遷移
mysql_pwd='password'        # データベースのパスワード
occ_db='cloud'              # Nextcloud / ownCloudのデータベース名

# ownCloudの場合
user_id_column='user_id'    # ownCloudのoc_accountsテーブルのカラム名
# Nextcloudの場合
user_id_column='uid'        #  oc_accounts of Nextcloudのoc_accountsテーブルのカラム名

mysql -u root --password="${mysql_pwd}" "${occ_db}" -N -s \
    -e 'SELECT uid FROM oc_group_user WHERE gid = "zimbra"' \
    | while read uid; do \
        sudo -u www-data php ./occ user:delete "${uid}"; \
        mysql -u root --password="${mysql_pwd}" "${occ_db}" \
            -e "DELETE FROM oc_accounts WHERE ${user_id_column} = '${uid}' LIMIT 1"; \
      done

アプリのアンインストール

Zimbra Open Drive Appは、Nextcloud / ownCloudの管理用インターフェースから削除することができます。Enable Zimbra authentication back end のチェックをオフにすると、設定が復元されるはずです。その後、有効なアプリ タブでZimbra Open Drive Appを無効にし、無効なアプリ タブからアンストールしなければなりません。

上記手順によって、Zimbra Open Drive Appフォルダ (PATHTOCLOUD/apps/zimbradrive) は削除されます。ただ、全ユーザーのファイルはまだクラウドサービスのドライブに残っている状態です。事前にクリーンアップされなかった設定およびファイルは全て、Zimbra Open Drive Appの再インストールで検索対象となります。

高度なトピックス

ソースからのビルド

本項ではZimbra Open Driveコンポーネントをビルドする手順を説明します。公式のZimbra Open Driveソースレポジトリは GitHub.com/ZeXtras/zimbra-drive にホストされています。

構築システムは相対パスを使用します。次の例は作業用パスを仮に /tmp/ としていますが、自由に変えてかまいません。

# ビルドに使用する予定のフォルダをクリーンアップ
rm -rf /tmp/ZimbraDrive && cd /tmp/

# ソースレポジトリのクローン作成
git clone --recursive git@github.com:ZeXtras/ZimbraDrive.git

# ソースフォルダへ移動
cd ZimbraDrive

# Zimbraリリースの該当ブランチをチェックアウト (仮にZimbra 8.8.0とした場合)
git checkout release/8.8.0

# パッケージ全体をビルド。対象のZimbraが設定されます。 (数分かかる場合があります) 。
make clean && make ZAL_ZIMBRA_VERSION=8.8.0

最終成果物 zimbra_drive.tgz がフォルダ /tmp/zimbradrive/dist に格納されることになりす。

dist フォルダ:

アーカイブzimbra_drive.tgzにZimbra Open Driveの全コンポーネントが入っています。

マニュアル操作でのインストール

マニュアル操作でのインストールはサポート対象外です。

Zimbra Open Drive Zimletと拡張機能は、Zimbraのインストール中にインストールします。インストールされたZimbraパッケージに対する修正は、Zimbraアップグレード時の障害を誘発する可能性があります。

拡張機能

zimbradrive-extension.jar ファイルと zal.jar ファイルは適切な場所にコピーしなければなりません。また、拡張機能をロードするにはmailboxを再開する必要があります。

# rootとして実行
mkdir -p /opt/zimbra/lib/ext/zimbradrive
cp zimbradrive-extension.jar /opt/zimbra/lib/ext/zimbradrive/
cp zal.jar /opt/zimbra/lib/ext/zimbradrive/

# zimbraとして実行
mailboxdctl restart

拡張機能が正しく開始した場合に限り、全て正常に実行されています。最後にmailboxを再開したとき、次の文字列が ZIMBRA_HOME/log/mailbox.log に記録されているはずです。

Initialized extension Zimbra Abstraction Layer for: zimbradrive
Zimlet

次のコマンドでZimbra Open Drive Zimletを配備します。

# zimbraとして実行
zmzimletctl deploy com_zextras_drive_open.zip

Zimletは‘default‘ の提供サービスに対してはデフォルトで有効です。必要に応じてどの提供サービスに対しても管理コンソールからZimletを有効にできます。

マニュアル操作でのアップグレード

マニュアル操作でのアップグレードはサポート対象外です。

Zimbra Open Drive Zimletと拡張機能は、Zimbraのアップグレード中にアップグレードします。インストールされたZimbraパッケージに対する修正は、Zimbraアップグレード時の障害を誘発する可能性があります。

拡張機能

/opt/zimbra/lib/ext/zimbradrive/ にある zimbra-extension.jarzal.jar ファイルを入れ替え、mailboxを再開することで、Zimbra Open Drive拡張機能のアップグレードが可能です。

# rootとして実行
cp zimbradrive-extension.jar /opt/zimbra/lib/ext/zimbradrive/
cp zal.jar /opt/zimbra/lib/ext/zimbradrive/

# zimbraとして実行
mailboxdctl restart

Zimlet

Zimbra Open Drive Zimletは、最新バージョンを配備し、キャッシュをフラッシュすることで、アップグレードが可能です。

# zimbraとして実行
zmzimletctl deploy com_zextras_drive_open.zip
zmprov fc zimlet

マニュアル操作でのアンインストール

マニュアル操作でのアンインストールはサポート対象外です。

アンインストールではなく、Zimbra Open Driveを無効することを検討してください (参照 Zimbra Open Driveパッケージの無効化)。インストールされたZimbraパッケージに対する修正は、Zimbraアップグレード時の障害を誘発する可能性があります。

Zimbra Open Drive ZimletとZimbra Open Drive拡張機能のアンインストール処理をマニュアル操作で行なうには、Zimletを配備解除し、zimbraから拡張機能フォルダを消去する必要があります。

Zimbra Open Drive Zimletを削除

# zimbraとして実行
zmzimletctl undeploy com_zextras_drive_open

TZimbra Open Drive 拡張機能を削除

# rootとして実行
rm -rf /opt/zimbra/lib/ext/zimbradrive/

# zimbraとして実行
zmmailboxdctl restart

最後に、必須ではありませんが、下記コマンドによりドメイン属性をクリーンアップします。
zmprov md domainExample.com zimbraDriveOwnCloudURL

問題の報告方法

問題発見時、Zimbraサポートは下記の情報が必要です。

  • 問題の詳細説明: 期待していることと実際に起きていること。

  • 問題を再現するのに必要な手順の詳細説明。

  • インストール内容と環境についての詳細説明。

    • クラウド情報

    • サーバー情報: CPU、RAM、サーバー数およびサーバーごとの下記情報

      • Zimbraのバージョン

      • Zimbra Open Driveのバージョン

      • インストール済Zimletの一覧

    • クライアント情報

      • ブラウザ名とバージョン

      • サーバーとクライアント間で使用中の接続

      • クライアントのスキン (テーマ)

      • クライアントの言語

      • 対象のユーザーが利用できるZimletの一覧

  • 問題に関するログ全て

    • mailbox.log

ユーザーのプライバシーを保護するため、個人情報は削除してもかまいません。

システム情報の収集

本項には、管理者が問題をエスカレーションする際に必要となる有用なシステム情報を収集できるようなヒントを記載します。

Zimbraのバージョン

Zimbraのバージョンを確認するには下記コマンドを入力します。

# zimbraユーザーにて
zmcontrol -v
配備したZimletの一覧

配備したZimletの一覧を確認するには下記コマンドを入力します。

# zimbraユーザーにて
zmzimletctl listZimlets
ユーザーが使用できるZimletの一覧

そのユーザーが使用できるZimletの一覧を確認するには下記コマンドを入力します。

# zimbraユーザーにて
zmprov getAccount user@domain.tld zimbraZimletAvailableZimlets
Zimletのユーザープリファレンスの一覧

ユーザーが利用できるZimletのプリファレンスの一覧を確認するには下記コマンドを入力します。

# zimbraユーザーにて
zmprov getAccount user@domain.tld zimbraZimletUserProperties
拡張機能とZimletのバージョン

拡張機能とZimletのバージョンを確認するには下記コマンドを入力します。

# zimbraユーザーにて
java -cp /opt/zimbra/lib/ext/zimbradrive/zimbradrive-extension.jar \
    com.zextras.lib.ZimbraDrive

Zimbra Drive

要約

Zimbra Drive v2 は Zimbra ウェブクライアントに関連させた完全なるファイルストレージシステムを提供している新しい Zimbra コンポーネントです。Zimbra Drive v2 は以前のブリーフケース機能の入り変えとなります。

機能

フロントエンド

  • ファイルのアップロード、管理、およびダウンロード

  • ファイルを自由に作成できるフォルダー構成で管理する

  • ファイルのプレビュー

  • ファイルを簡単にアクセスできるために「優先」としてマークする

  • ファイルへカスタムのメモ(説明や詳細)を追加する

  • 内部ユーザーへファイルを共有する

  • 外部ユーザー(NYI)へファイルを共有する

  • Zimbra Docs と共通する

  • ファイルの検索

  • フォルダーにベースした移動

  • 早い "stateful" 移動

バックエンド

  • 専用の Zimbra ボリュームにファイルを保存できるオプション

  • zxsuite drive の CLI

ブリーフケースと Drive の違いについて

ファイルストレージ、移動、共有、および削除について、Zimbra Drive v2 は通常のメールボックス運用の動作と異なります。以下に各機能の詳細に具体的の機能、および異なる動作の詳細を確認ください。

Drive V2 UI

Zimbra Drive V2 UI
  1. アイテムを簡単にアクセスできるオプション;

  2. 現在開いているフォルダー(パス内の移動も可能);

  3. 選択したアイテムの詳細を表示する;

  4. 新しいアイテム(フォルダー、ドキュメント)の作成、アップロード、および検索の機能;

  5. フォルダーのリスト;

  6. ファイルのリスト;

機能の詳細

アップロードとダウンロード

Drive v2 へファイルをアップロードする場合、ファイルリストの上にある「Upload」ボタンをクリックするか、Drive の画面にファイルをドラグ&ドロップします。

Upload a file

Drive v2 からファイルをダウンロードする場合、ファイルを右クリックし、「Download」をクリックします。

Download a file

また、ファイルやフォルダーを右クリックし、「Rename」のオプションでファイル名やフォルダー名を変更することも可能です。

移動

ブリーフケースのアイテムはメールボックスのフォルダーとアイテムに関連していましたが、Drive v2 は異なる専用の内部フォルダー形式と移動を用意しています。Drive v2 のフォルダー移動はメールボックスと同様なフォルダーツリーではなく、UI 上の移動メニューで親のフォルダーを選択し、ファイルリストから移動するフォルダーをダブルクリックします。

Navigate through folders and files

フォルダーにベースした移動以外に、左側に「簡単アクセス」のメニューも提供してますので、以下のようなアイテムを簡単にアクセスできます。 ? "Starred" ? ファイルやフォルダーの右クリックで「Star」を追加したアイテムが表示します; ? "Recently Edited" ? 最近に編集したアイテムが表示します。最近に編集したアイテム順で表示します; ? "Shared with me" ? 他のユーザーから共有されたアイテム ? "Shared by me" ? 他のユーザーへ共有したアイテム ? "Trash" ? 削除したアイテム

フォルダー作成

Drive v2 でフォルダーを作成するため、ファイルリストの上に「New」のボタンをクリックし、「Folder」を選択します。

Create a new folder

共有

メールボックスのアイテム管理と別れているため、Drive v2 のファイルとフォルダーを個別に共有することが可能です。 共有する際に設定できる権限は "Visualize"(読み込み専用), "Edit"(書き込み) および "Edit and Share" (書き込みと共有)? なお、Edit と Edit and Share の権限には読み込みの権限がデフォルトで含まれています。

ファイルやフォルダーを共有する場合、共有するアイテムを右クリックし、「Edit Shares」をクリックします。共有先ユーザーのメールアドレスと共有の権限を指定した後、 (+) ボタンをクリックしますと共有のリストへ追加されます。

Share an item (folder or file)

共有の権限を変更、または削除する場合、「Edit Shares」の画面にて、更新するユーザーの権限ドロップダウンメニューに新しい権限を選択するか、ゴミ箱のアイコンでそのユーザーへの共有権限を削除します。

Edit an existing share

なお、Drive v2 の共有権限は「ポジティブ向け」のみなので、アイテムの親に設定した権限より低い権限で共有することができません。例えば、フォルダーに "Edit" の権限が指定している場合、そのフォルダー内のファイルを同じユーザーへ "Visualize" の権限を設定できません。

アイテムの削除

アイテムを削除した場合、Drive v2 のアイテムが他のアイテムと同様に Zimbra の込み箱に入らず、削除対象としてマークされるのみです。 ファイルやフォルダーに削除対象としてマークする場合、右クリックし、「Mark for Deletion」をクリックします。

Mark an item for deletion

削除対象としてマークしたアイテムはファイルリストの下にファイル名に線を引いた状態で表示されます。この状態で右クリックして、「Delete Permanently」をクリックするとファイルを完全に削除されます。また、右クリックのメニューから「Restore」をクリックしますと、ファイルに削除対象のマークが消え、ファイル名に引いた線が消えます。

Restore or permanently delete a file

なお、「Edit」および「Edit and Share」の権限を持つユーザーはアイテムを削除対象としてマークすることが可能ですが、そのアイテムの持ち主のみはアイテムを完全に削除することが可能です。

削除対象としてマークしたアイテムをアクセスできませんので、ユーザーが削除対処のアイテムをアクセスする場合、ポップアップの警告メッセージでアイテムを復元するか、アクセスをあきらめてファイルを削除対象のままに残すように要求します。

詳細情報を表示する

Drive v2 にあるファイルやフォルダーに関する詳細な情報、可能な操作アクション、および互換性があるファイル(画像、PDF、など)のプレビューを特定の詳細情報画面で表示することが可能です。

詳細情報の画面を表示する場合、ファイルやアイテムを選択し、右上の「i」ボタンをクリックします。

Open the InfoBox

詳細情報の画面が画面の右側に表示されます。

The InfoBox

この詳細情報の画面では以下の内容が含まれています。

  • 選択したファイルのファイル名

  • ファイルのプレビュー(非対応の形式のファイルである場合、ファイルのアイコンが表示する)

  • 右クリックのメニューで利用するアクション

  • 設定している共有の詳細情報

  • ファイルの作成や編集に関する情報

  • カスタマイズかのうの「Description」でメモや説明を任意で保存する情報

テクニカル詳細

ファイルのストレージ

ブリーフケースのファイルはメールボックスのストレージでメールメッセージと同様な方法として保存していますが、Drive v2 はノードにベースした専用のフォルダー構成を提供しています。そのため、Drive v2 のフォルダーはメールオックスとして表示しない(つまり、zmmailbox getAllFolders のコマンドで出力しない)。Drive v2 のメタデータが専用の HSQL データベースで保管しており、すべてのファイル(ファイルのバージョンとファイルプレビューを含め)がボリュームのルートにある専用のフォルダーへ保管します。重複ファイルの対策として、ファイル名はIDでベースした方式からハッシュにベースした方式に変わっており、ファイルの圧縮がボリュームの基準設定に従います。

つまり、 ビリーフケースでは、ファイルのパスは /opt/zimbra/store/0/[mID]/msg/0/[itemid]-[revision].msg Drive v2 では、ファイルのパスは /opt/zimbra/store/drive/[hash]-[revision].[extension]

ボリューム

現時点では、Drive v2 のファイルは現在のプライマリボリュームで保存します。

Zimbra Docs との関連 Zimbra Docs の Zimlet がインストールしている場合、ドキュメントに関する特定の追加オプションがファイルリストの上にある`New`ボタンから利用いただけます。

Create documents with Zimbra Docs

また、互換性があるファイルを右クリックしますと、"Open with Docs" のオプションも表示します。

Open files stored in Drive with Docs

また、Zimbra Docs により、互換性があるドキュメントの形式のプレビューを表示させることも可能です。

Zimbra Drive バックアップと HSM について

バックアップ NG

Drive V2 ファイルがバックアップ NG のバックアップ対象であり、RealTime スキャンとSmartScanが Drive のファイルを認識しておりますので、特定のアクションでこれらのファイルをバックアップさせる必要はございません。

新規アカウントへ復元と外部リストアのモードにもDrive v2 のファイルを復元しますが、削除したアイテムの戻し、など、他の復元モードで Drive v2 のファイルが復元されません。

HSM NG

Drive v2 は現在のプライマリボリューム以外のボリュームへデータを保存することが可能であり、HSMのポリシーで Drive v2 のファイルを現在のセカンダリボリューム以外でも移動することが可能であるため、Drive v2 ファイルのストレージ管理は完全に分解されている状態です。

HSM ポリシーが適用した場合、Drive v2 のファイルが "document" のアイテム類で処理されます。

本設定はサーバレベルで適用しますので、異なるメールボックスサーバは異なるボリュームを運用することが可能です。

Drive のプライマリボリュームを設定する方法

Drive のプライマリボリュームを設定する場合、まずは zxsuite hsm getAllVolumes のコマンドでターゲットボリュームの volumeID を確認します。

volumeID を確認しましたら、以下のコマンドを実行します。

zxsuite config server set `zmhostname` attribute driveStore value [volumeID]

(上記の [volumeID] は最初のコマンドで返答した volumeID となります)

Drive のセカンダリボリュームを設定する方法

Drive のセカンダリボリュームを設定する場合、 zxsuite hsm getAllVolumes のコマンドでターゲットボリュームの volumeID を確認し、以下のコマンドを実行します。

zxsuite config server set `zmhostname` attribute driveSecondaryStore value [volumeID]

ブリーフケースからの移管

専用の doImport CLI コマンドにて、ブリーフケースのデータが Drive v2 へ移管することが可能です。

zimbra@test:~$ zxsuite drive doImport

構文:
   zxsuite drive doImport {john@example.com,test.com[,...]} [attr1 value1 [attr2 value2...]]

このコマンドでは移管するメールボックス、またはドメインのターゲットをコンマで区切ったリストを受け付けることが可能であり、同じコマンドに異なるターゲット類を指定することも可能です。

以下の属性値で移管をカスタマイズすることが可能です。

属性 方式 期待値 デフォルト値 詳細

targets(M)

String[,..]

john@example.com,test.com[,…​]

移管するターゲットのコンマ区切ったリスト

dryRun(O)

Boolean

true か false

false

検証用の実行を行い、実際のデータへ影響しない

allVersions(O)

Boolean

true か false

false

すべてのファイルに各バージョンを移管する

deleteSources(O)

Boolean

true か false

false

移管が完了したファイルをブリーフケースから削除する

overwrite(O)

Boolean

true か false

false

既存ファイルを上書きする

showIgnoredAccounts(O)

Boolean

true か false

false

ignoreQuota(O)

Boolean

true か false

false

移管する際にメールボックスのクォータを無視する

Zimbra Docs

紹介

Zimbra Docs は大きくカスタマイズした LibreOffice のオンラインパッケージにベースした機能であり、Zimbra ウェブクライアント上でドキュメント、スプレッドシート、およびプレゼンテーションの共通編集を提供しています。

コンポーネント

Zimbra Docs サーバについて

Zimbra Docs サーバがサービスの中心となります。ドキュメントを開く際に、本サービスが LibreOffice のエンジンで該当のドキュメントをホストし、クライアントへすべての変更がリアルタイムで、ドキュメントのイメージよりレスポンスが送信されます。

要注意:このコンポネントは Ubuntu 16.04 LTS, Ubuntu 18.04 LTS, または Red Hat/CentOS 7 の専用ノード(または複数の専用ノード)へインストールする必要があります。

Zimbra Docs 拡張について

Zimbra Docs 拡張にすべてのサービスを運用されます。主のタスクは以下となります。

  • ドキュメントが開く Docs サーバを特定する

  • ドキュメントを開く際にクライアントを適切に誘導する

  • Docs サーバの代わりに、システムストレージにドキュメントの読み込みと書き込みを行う

  • 管理用のウェブソケット経由で各 Docs サーバへ接続し、各サーバの有効性と使用中のリソースを監視する

  • ユーザー様の同時接続を同じドキュメントがホストしているサーバへ誘導する(ドキュメント共通)

Zimbra Docs 拡張は NG Core と共に、NG モジュールのパッケージに含まれています。

Zimbra Docs Zimletについて

Zimbra Docs Zimlet はブリーフケースと添付ファイルの関連を管理します。具体的に、デスクトップクライアントと同様なパフォーマンス、および最低限のバンド幅使用を使用するため、シンのウェブクライアントがウェブクライアントでサーバへ接続し、ドキュメントのレンダーし、クライアントへの変更のみを送信します。

プレビューしているドキュメント、および添付ファイルが読み取り専用の状態で、より簡単なインターフェースとして表示されますが、編集する際に完全なインターフェースへ切り替えます。

Zimbra Docs Zimlet の主のタスクは以下となります。

  • ZWC の「作成」ボタンに適切な Docs 機能へ変換する

  • プレビュー機能に Docs を利用するように変換する

  • ドキュメントのプレビューを許可する

ドキュメントの管理流れについて

ユーザ様が新しいドキュメントを作成した際、以下のような流れが行います。

  1. Zimlet が拡張に新しい空ドキュメントを作成するように依頼します。

  2. 拡張がドキュメントを作成し、クライアントへドキュメントのIDを返信します。

  3. Zimlet が新しい Zimbra タブを開き、'/service/extension/wopi-proxy' へ転送する iframe が開きます。

  4. 拡張にクライアントのリクエストを受信し、要求したドキュメントに新しトークンを作成し、新しい URL を返信します。

  5. 新しい URL が /docs/[docs-node-id]/[token] へ転送し、nginx により指定した Docs サーバのノードへプロキシされます。

  6. Docs サーバが Javascript でウェブアプリケーションを返答します。

  7. ウェブアプリケーションがウェブソケットの接続を開き、nginx をけいゆうします。

  8. Docs サーバがウェブソケットの接続とトークンを受信し、指定したメールボックスの URL (メールノックスの URL が許可しているノードであることを認証されます)へ read wopi のコマンドを送信します。

  9. 拡張がトークンを認証し、適切の情報やコンテンツを返信します。

  10. Docs サーバのノードがドキュメントをパースし、レンダーしたものをクライアントへ返信します。

  11. ドキュメントが開き、編集が可能の状態です。

ドキュメントを開く
                                  Docs へ誘導
    +------------------------+             +----------------------+
    |     Zimbra Proxy       |             |    メールボックス      |
    |                        +------------->                      |
    |      Nginx             |             |   Zimbra Docs 拡張    |
    +------------------------+             +----------------------+
                      |                        |              ^
                      |                        |              |
                      |                        |             WOPI:
                      |                   管理のウェブ    ドキュメントの
                      |                   ソケット      読み込み/書き込み
                      |                        |              |
                      |                        |              |
                      |                        |              |
                      |                    +---v----------------+
                      |                    |                    |
                      +-------------------->   Docs サーバ       |
            クライアントをロードし             |                    |
       クライアントのウェブソケットを開く        +--------------------+

ネットワークのポートについて

すべてのメールボックスサーバはポート 8443 (HTTPS バックエンド) で直接にコミュニケーションを行う必要がありますので、どちらのサーバ側でこのポートを開く必要があります。

また、Docs サーバは拡張をポート9091でコミュニケーションを行いますので、すべてのメールボックスとプロキシサーバからポート9091へのインバウンドトラフィックを許可する必要があります。Docs サーバもマスター LDAP サーバとプロキシサーバへ直接にコミュニケーションする必要もあります。

インストールと設定について

Docs のノードについて

zimbra-docs tgz のスタンドアロンインストーラをダウンロードし、root ユーザーでパッケージを展開した後、install.sh のスクリプトを実施します。

スクリプトは Zimbra Docs のパッケージをインストールした後、マスター LDAP、URL、ユーザー名とパスワードを要求します。これらの情報を元に、LDAPへ’docs' のサービスのみがインストールと有効化している新しいサーバを追加します。各 Docs サーバは各ノードで閲覧することが可能であり、/opt/zimbra/conf/docs/loolwsd.xml の設定を書き込むため LDAP を読み込みます。

設定が完了しましたら、他の設定を実施する必要はありません。

メールボックスのノードについて

Zimbra Docs 拡張は既に NG モジュールに含まれていますが、com_zextras_docs の Zimlet をサーバへデプロイし、Zimbra Docs の機能を提供するユーザやCOSへ有効化する必要があります。

com_zextras_docs Zimlet は Zimbra のリポジトリで提供しておりますので、apt-get install zimbra-docs で簡単にダウンロードとデプロイすることが可能です。

なお、Zimlet がデプロイし、有効化した後、Mailboxd側でさらなる設定の適用はありません。

プロキシノードについて

Zimbra Docs サーバを追加する度に、プロキシの設定を再発行する必要があります。設定を再発行する場合、zimbra ユーザーとして、/opt/zimbra/libexec/zmproxyconfgen のコマンドを実施した後、zmproxyctl restart のコマンドでプロキシサービスを再起動します、

上記を実施後、新しい Docs ノードが LDAP から読み取りますので、手動での設定は不要です。

ライセンスについて

Zimbra Docs はネットワーク版のライセンスにあるユーザー数の上限と同様に利用いただけます。

なお、スタンドアロンのインストーラは MPLv2 ライセンスで提供しておりますが、拡張と Zimlet は著作権のある別のライセンスで提供しています。

削除方法

ソフトウェアをアンインストールする前に、LDAP からノードを削除する必要があります。Docs ノード上で以下のコマンドで削除できます。

zdocs remove-local-server

また、全 zimbra ノードで以下の zmrov コマンドでも削除することが可能です。

zmprov deleteServer {servername}

コマンドの詳細について

Zimbra Docs サーバ CLI - zdocs

Docs サーバでの zdocs コマンド (root ユーザーの /usr/local/bin/zdocs) が lool 設定の発行(既に cron にある)、LDAP から Docs サーバの追加/削除、設定の確認、およびサービスの管理が可能です。

zdocs コマンド
usage: zdocs [-h] [--auto-restart] [--ldap-dn LDAP_DN] [--ldap-pass LDAP_PASS]
             [--ldap-url LDAP_URL] [--hostname HOSTNAME] [--debug][--cron]

{genkey,write-local-server,remove-local-server,generate-config,ldap-write-config,ldap-test,start,stop,restart,status,setup}

Manage Zimbra Docs service.

Available commands:
  genkey                Generate a private key needed for authentication between docs and mailbox servers.
  write-local-server    Add or update in LDAP the necessary server entry for this server in order to be reachable from other servers.
  remove-local-server   Remove local server entry in LDAP.
  generate-config       Populate the config template with ldap values and write a new configuration file.
  ldap-write-config     Write new configuration about the ldap access needed to generate the docs configuration file.
  ldap-test             Check the ldap connection.
  start                 Start the service.
  stop                  Stop the service.
  restart               Restart the service.
  status                Print service status.
  setup                 Start the initial setup.

positional arguments:
{genkey,write-local-server,remove-local-server,generate-config,ldap-write-config,ldap-test,start,stop,restart,status,setup}                                   Command to execute

optional arguments:
  -h, --help            show this help message and exit
  --auto-restart        Automatically restart the service if configuration is changed (to be used with generate-config)
  --ldap-dn LDAP_DN     Ldap dn (distinguish name) to bind to (to be used with ldap-test and ldap-settings)
  --ldap-pass LDAP_PASS Ldap password used of the DN (to be used with ldap-test and ldap-settings)
  --ldap-url LDAP_URL   Ldap url completed with schema (ex.: ldaps://ldap.example.com, to be used with ldap-test and ldap-settings)
  --hostname HOSTNAME   Hostname of this server (to be used with add-local-server)
  --debug               Show complete errors when things go bad.
  --cron                Start in cron mode, avoid any output unless there is an error (to be used with generate-config).

examples:
#regenerate the config and restart the server if config changed
  zdocs --auto-restart generate-config
#restart the service
  zdocs restart
#check ldap connection availability using current settings
  zdocs ldap-test
#check ldap connection using custom settings
  zdocs --ldap-url ldaps://ldap.example.com/ --ldap-dn 'uid=zimbra,cn=admins,cn=zimbra' --ldap-pass password ldap-test
#change the ldap connection settings
  zdocs --ldap-url ldap://ldap2.example.com/ --ldap-dn 'uid=zimbra,cn=admins,cn=zimbra' --ldap-pass password
ldap-write-config
#add the local server
  zdocs write-local-server
#add the local server with a custom hostname in LDAP, this command should be already invoked during setup.
  zdocs --hostname myhostname write-local-server
#remove the local server from LDAP, useful when destroying the server, you can also use 'zmprov deleteServer' from a mailbox server.
  zdocs remove-local-server

Zimbra Docs 拡張 CLI - zxsuite docs

メールボックスサーバ上では、zxsuite docs のコマンドを利用いただけます。このコマンドではDocs サービスのステータス確認と管理、設定を強制的に再読み込み、およびDocsサーバのステータスを確認することが可能です。

zxsuite docs
zxsuite docs

Commands regarding docs module

  doReloadConfig           - reload docs configuration from ldap, which
would happen once a minute.
                             zxsuite docs doReloadConfig

  doRestartService         - restart a given service
                             zxsuite docs doRestartService
{service_name}

  doStartService           - start a given service
                             zxsuite docs doStartService {service_name}

  doStopService            - stop a given service
                             zxsuite docs doStopService {service_name}

  getServices              - show current status of all services for
this module
                             zxsuite docs getServices

  status                   - show zimbra docs servers status with their
resource usage (if connected).
                             zxsuite docs status

トラブルシューティング

ドキュメントを開く際に何も起こらない / 拡張が 503 で返答してしまう

本現象について、メールボックスサーバとDocsサーバの接続問題が発生している可能性が高いです。mailbox.log を確認し、接続失敗の原因が記録されているか、調査してください。接続エラーがない場合、Docsノードに`zdocs status`のコマンドでDocsサーバの状況を確認ください。

メールボックスは各Docsサーバにすべての接続と切断をログに記録します。

Docsの代わりに404のエラーコードが表示する

プロキシの設定を再発行し、プロキシサービスを再起動する必要があります。

Docsが開きますが、期待してドキュメントではなく、“this is embarrassing…​”のメッセージが表示する

ドキュメントの読み込みと書き込みを実施するために、Docsサーバがメールボックスサーバへ正常に接続できない場合に発生します。サーバ名の名前解決を確認し、DocsサーバがZimbraの証明書管理の機能が含まれていませんので、mailboxdのSSL証明書が正常であることも確認してください。

Appendix A: コマンドラインのユティリティ

コマンドラインインターフェース (CLI) ではZimbra Collaboration機能の作成、編集および削除することができます。管理コンソールは Zimbra Collaboration機能の作成、編集および削除することができます。管理コンソールはZimbra Collaborationの管理に使用するメインツールですが、CLIからしか変更できない機能も存在しています。

CLIのユティリティでは以下を実行できます。

  • アカウントのプロビジョニング

  • バックアップと復元

  • サービスの停止と起動

  • メールボックスの移動

  • クロスメールボックスの検索

  • 自己署名した証明書のインストール

  • ローカル設定

基本的にアカウントの管理は管理コンソールで行うべきです。

ツール情報全般

Zimbra Collaborationのコマンドラインのユティリティは基準のUNIX構文に従っています。コマンドを使用する際、以下のガイドラインを参照してください。

  • CLIコマンドはZimbraユーザーとして実行します、つまり
    su - zimbra

  • 実際のCLIコマンドは小文字・大文字を区別しています。小文字で入力する必要があります。

  • コマンドを入力後、キーボードの Enter キーを押します。

  • CLIコマンドの後に -h を入力しますとコマンドの使用方法を返します。

    例: zmprov -h では zmprov のユティリティに関連しているオプションをすべてリストします。

  • 各オペレーションはコマンドラインのオプションで実行します。ほとんどのオプションに正式名と略式名が存在します。例えば、以下の2つのコマンドは同じ操作です。

    zmprov createAccount joe@domain.com test123
    
    zmprov ca joe@domain.com test123

コマンドの構文

各ツールの構文を表示する際、以下のルールで必要、オプション、そして代理値を示します。

  • {属性値} のようなブラケットは必要な情報

  • [属性値] のようなブラケットはオプションの値や情報

  • {a|b|c} または [a|b|c] のように、複数のオプションがパイプ | で分けられている場合、 "a" または "b" または "c" という意味です。

  • 属性値に空スペースが含まれている場合、値をクォーテーションマークで囲います。

コマンドラインユティリティの場所

管理者のコマンドラインツールは Zimbra Collaboration サーバーの /opt/zimbra/bin ディレクトリに存在します。

Zimbra CLI コマンド

CLI

以下のテーブルに /opt/zimbra/bin のCLIコマンドをリストアップします。

CLI 説明

antispam-mysqladmin

迷惑メールのSQLサーバー管理ユーティリティ

antispam-mysql

迷惑メールのSQLクライアント

antispam-mysql.server

迷惑メールのSQLインスタンスの開始/停止

ldap

ZimbraLDAPの起動、停止、またはステータス確認

ldapsearch

LDAPサーバー上で検索を実施

logmysqladmin

Logger SQLインスタンスへmysqladminコマンドを送信する

mysql

メールボックスSQLインスタンスへの双方向コマンドラインを入力

mysql.server

メールボックスSQLインスタンスの起動/停止

mysqladmin

メールボックスSQLインスタンスへ管理者コマンドを送信する

postconf

Postfix設定の閲覧、または編集する

postfix

Postfixの起動、停止、リロード、フラッシュ、確認、アップグレード設定

qshape

Postfixのキューを時間と送信/受信者ドメインに関して検査する

zmaccts

アカウントをリストし、ドメインにあるアカウントのステータスを示す

zmamavisdctl

Amavis-D Newの起動、停止、再起動、またはステータス確認

zmantispamctl

迷惑メール対策サービスの起動、停止、リロード、ステータス確認

zmantivirusctl

ウイルス対策サービスの起動、停止、リロード、ステータス確認

zmantispamdbpasswd

迷惑メール対策のSQLデータベースのパスワード変更

zmapachectl

Apacheサービス(スペルチェック使用)の起動、停止、リロード、ステータス確認

zmarchiveconfig

アーカイブ機能の閲覧、編集、または設定のためのコマンド

zmarchivectl

アーカイブ機能の起動、停止、リロード、ステータス確認

zmarchivesearch

アカウントにアーカイブを検索する

zmauditswatchctl

auditswatchの起動、停止、再起動、リロード、ステータス確認

zmbackup

指定メールホストに完全と増分バックアップを実施する

zmbackupabort

実行中のバックアップを強制的に停止する

zmbackupquery

特定の完全バックアップを検索する

zmblobchk

Zimbraブロブストアの整合性をチェックする

zmcalchk

Zimbraカレンダー内の予定と参加者の整合性をチェックする

zmcbpolicydctl

Cluebringer policydが有効の場合、サービスの起動、停止および再起動

zmconfigdctl

MTA設定のデーモンを起動、停止、終了(kill)、再起動、ステータス確認

zmcertmgr

自己署名と商用署名の証明書を管理する

zmclamdctl

ClamAVの起動、停止、ステータス確認

zmcleaniplanetics

iPlanetICSカレンダーファイルをクリーンする

zmcontrol

Zimbraサーバーの起動、停止、再起動、ステータス確認。また、インストールされているZimbraバージョンの確認も可能

zmconvertctl

コンバージョンサーバーの起動、停止、変換されている添付ファイルのコンバージョン/インデックス状況を確認

zmdevicesstats

各サーバーの一意のActiveSyncデバイス(端末)ID

zmgdcutil

(デバイス(端末)数の取得) 特定のサーバーを指定せず、システム上にあるすべてのデバイスを返す

zmdumpenv

サーバー環境の一般情報を表示する

zmgsautil

グローバルアドレスブック(GAL)同期コマンドユーティリティ。GAL syncアカウントの作成と削除およびマニュアル操作での同期を実行する

zmhostname

Zimbraサーバーのホスト名を取得する

zmhsm

HSMセッションの起動、停止、ステータス確認

zmitemdatafile

ZCS がRESTのインポート/エクスポートに使用するtgzファイルの展開と圧縮する

zmjava

Zimbra固有の環境設定でJavaを実行する

zmjavaext

拡張ベースのjarを含め、Zimbra固有の環境設定とJavaを実行する

zmldappasswd

LDAPパスワードを変更する

zmlicense

Zimbraのライセンス閲覧とインストール

zmlmtpinject

テストのツール

zmlocalconfig

Zimbraサーバーのローカル設定の取得、または編集

zmloggerctl

ZimbraのLoggerサービス起動、停止、リロード、ステータス確認

zmloggerhostmap

zmhostnameへDNSホスト名をマニュアル操作でマッピングする

zmlogswatchctl

ログを監視しているswatchの起動、停止、ステータス確認

zmmailbox

メールボックスの管理タスク実行

zmmailboxdctl

メールボックス機能(zmmailboxd)の起動、停止、リロード、ステータス確認

zmmboxsearch

メッセージと添付ファイルを複数のメールボックスに対して検索する(クロスメールボックス検索)

zmmboxmove

7.1.3以降。指定したメールボックスを別のZimbraサーバーへ移動する

zmmboxmovequery

7.1.3以降。サーバーで実行中のメールボックスの移動をクエリする

zmpurgeoldmbox

7.1.3以降。メールボックス移動後、古いサーバーからメールボックスをパージする

zmmemcachedctl

memcachedサーバーの起動、停止、再起動

zmmetadump

アイテムのメタデータを人が読めるフォーマットへダンプするサポートツール

zmmilterctl

ZimbraのMilterサーバーが有効の場合、起動、停止、再起動

zmmtaconfigdctl

ZCS 7.0より、このコマンドは使用しません。zmconfigdctl を使用してください。

zmmtactl

MTAの起動、停止、ステータス確認

zmmypasswd

SQLパスワードを変更する

zmmysqlstatus

メールボックスのSQLプロセスのステータス確認

zmnginxconf

リバースプロキシ設定を返すコマンドラインユティリティ

zmnginxctl

Zimbraのリバースプロキシの起動、停止、再起動

zmplayredo

定期的に保存されたスナップショットよりデータを復元する。スナップショットを使用してスタンドバイサイトへ情報をバックアップ・復元するユーザーは、このコマンドを使用します

zmprov

アカウント、ドメイン、配布リスト、エイリアスの作成を含む、Zimbra LDAP内でのすべてのプロビジョニングタスクを実行する

zmproxyconfgen

nginxのプロキシ設定を発行する

zmproxyctl

IMAPのプロキシサービスの起動、停止、再起動、ステータス確認

zmproxypurge

1つ以上のmemcachedサーバーからPOP/IMAPのルート情報をパージする

zmpython

ZimbraのJavaライブラリへアクセス可能なPythonスクリプトの実行機能。ZCSのクラスパスを設定し、Jython interpreterを起動する

zmredodump

デバッグのためにRedoログの内容をダンプするサポートツール

zmrestore

指定したメールホストに完全、または増分の復元を実行する

zmrestoreldap

LDAPのバックアップからアカウントを復元する

zmrestoreoffline

Zimbraサーバー(つまりmailboxdのプロセス)がオフラインの時に完全な復元を実行する

zmsaslauthdctl

saslauthd(認証)の起動、停止、ステータス確認

zmschedulebackup

バックアップをスケジュールし、Cronテーブルにコマンドを追加する

zmshutil

他のzmスクリプト用に使用しているため、使用禁止

zmskindeploy

スキンを配備する

zmsoap

SOAPフォーマットでメール、アカウントおよび管理情報を出力する

zmspellctl

スペルチェックサーバーの起動、停止、ステータス確認

zmsshkeygen

ZimbraのSSH暗号化キーを発行する

zmstat-chart

ディレクトリに収集したzmstatデータからチャートを生成する

zmstat-chart-config

管理コンソールにチャートを生成するためのコンフィグXML情報を出力する

zmstatctl

zmstatのデータ収集プロセスの起動、停止、ステータス確認、またはログのローテーション

zmstorectl

Zimbraストアサービス(zmmailboxd, MariaDB)の起動、停止、ステータス確認

zmswatchctl

モニタリングで使用するswatchプロセスの起動、停止、ステータス確認

zmsyncreverseproxy

モバイルシンク用リバースプロキシの実行

zmthrdump

スレッドダンプを開始し、データをタイムスタンプ付きのファイルに保存する

zmtlsctl

ウェブサーバーモードをHTTP、HTTPS、混合の、いずれかのコミュニケーションプロトコルへと設定する

zmtrainsa

メッセージが迷惑メールかどうかを迷惑メール対策フィルターに学習させる

zmtzupdate

コマンドラインでタイムゾーンの変更を処理できる方法を提供する

zmupdateauthkeys

zmsshkeygen で生成したssh暗号化キーを取得する

zmvolume

Zimbraメールボックスサーバーのストレージボリュームを管理する

zmzimletctl

Zimletの配備と設定

CLI に非ASCII文字を使用する場合

CLIに非ASCII文字を使用している場合、文字が正常に表示されるように、CLIコマンドを実行する前に、この設定を希望するUTF-8バージョンへと変更する必要があります。変更するには、以下のコマンドを使用します。

export LC_All=<UTF_locale>

ZimbraユーザーのデフォルトロケールはLANG=Cです。ZCSサービスを起動するためにこの設定が必要です。デフォルトのLANG=Cを変更するとamavisd-newに関するパフォーマンス問題の可能性があります。

zmprov (プロビジョニング)

ツール zmprov はアカウント、エイリアス、ドメイン、提供サービス、配布リストおよびカレンダーリソースの作成を含めたZimbra LDAPのプロビジョニングタスクをすべて実行します。各操作はコマンドラインの正式名と省略名で実行します。

コマンド使用の構文は zmprov [コマンド] [属性値]

影響のある属性値だけを編集し、変更していない値の再入力が必要なくなるように、編集の構文ではプレフィックスの "+" や "-" も含めることが出来ます。

  • + を使用し、既存の値を変更せず、特定の属性に新しいインスタンスを追加します。

  • - を使用し、属性から特定のインスタンスを削除します。

以下の事例ではuser 1に"blue"の値を zimbraZimletUserProperties の属性へ追加し、他の値は変更しません。

zmprov ma user1 +zimbraZimletUserProperties "com_company_testing:favoriteColor:blue"

zmprovを使用できるタスクは zmprov -h でリストアップできます。タスクエリアは次のセクションに分かれています。

正式名 略式名 構文、実例、備考

--help

-h

使用方法を表示する

--file

-f

インプットのストリームとしてファイルを使用する

--server

-s

{ホスト}[:{ポート}] サーバーホスト名とオプションのポート

--ldap

-l

SOAPの代わりにLDAPでプロビジョンする

--logpropertyfile

-L

log4jのプロパティファイル、-l と同時使用時のみ有効

--account {名前}

-a

認証するためのアカウント名

--password {パスワード}

-p

アカウントのパスワード

--passfile {ファイル}

-P

ファイルからパスワードを読み込む

--zadmin

-z

認証用の管理者アカウントとパスワードをlocalconfigからのZimbra管理者名とパスワードを使用する

--authtoken {認証トークン}

-y

コマンドラインで認証のトークンストリング(JSONフォーマット形式必須)を使用する

--authtokenfile {認証トークンのファイル}

-Y

コマンドラインで認証のトークンストリング(JSONフォーマット形式必須)をファイルから読み込む

--verbose

-v

詳細(verbose)モード(完全な例外スタックトレースをダンプする)

--debug

-d

デバッグモード(SOAPメッセージをダンプする)

--master

-m

LDAPのマスターを使用する。 -l を同時に使用する場合のみ有効

--replace

-r

localconfigキーである zmprov_saveguarded_attrs に設定された、セーフガードなマルチバリューの属性を書き替えることを許可する

コマンドは以下のトピックス内に簡略的に分類分けされています。

アカウントプロビジョニングコマンド
Table 63. zmprov — アカウントプロビジョニングコマンド
コマンド 構文 例/備考

addAccountAlias (aaa)

{name@domain | id | adminName} {alias@domain}

checkPasswordStrength (cps)

{name@doman | id} {password}

zmprov cps joe@domain.com test123

このコマンドはパスワードの古さや履歴を確認しません

createAccount (ca)

{name@domain} {password} [attr1 value1]…​

zmprov ca joe@domain.com test123 displayName JSmith

createDataSource (cds)

{name@domain} {ds-type} {ds-name} zimbraDataSourceEnabled {TRUE | FALSE} zimbraDataSourceFolderId {folder-id} [attr1 value1 [attr2 value2]…​]

createIdentity (cid)

{name@domain} {identity-name} [attr1 value1 [attr2 value2]…​]

createSignature (csig)

{name@domain} {signature-name} [attr1 value1 [attr2 value2]…​]

deleteAccount (da)

{name@domain | id | adminName}

zmprov da joe@domain.com

deleteDataSource (dds)

{name@domain | id} {ds-name | ds-id}

deleteIdentity (did)

{name@domain | id} {identity-name}

deleteSignature (dsig)

{name@domain | id} {signature-name}

getAccount (ga)

{name@domain | id | adminName}

zmprov ga joe@domain.com

getAccountMembership (gam)

{name@domain | id}

getAllAccounts (gaa)

[-v] [domain]

Must include -l/--ldap zmprov -l gaa zmprov -l gaa -v domain.com

getAllAdminAccounts (gaaa)

zmprov gaaa

getDataSources (gds)

{name@domain | id} [arg1 [arg2]…​]

getIdentities (gid)

{name@domain | id} [arg1 [arg2]…​]

getSignatures (gsig)

{name@domain | id} [arg1 [arg2]…​]

modifyAccount (ma)

{name@domain | id | adminName} [attr1 value1]…​

zmprov ma joe@domain.com zimbraAccountStatus maintenance

modifyDataSource (mds)

{name@domain | id} {ds-name | ds-id} [attr1 value1 [attr2 value2]…​]

modifyIdentity (mid)

{name@domain | id} {identity-name} [attr1 value1 [attr2 value 2]…​]

modifySignature (msig)

{name@domain | id} {signature-name | signature-id} [attr1 value1 [attr2 value2]…​]

removeAccountAlias (raa)

{name@domain | id | adminName} {alias@domain}

renameAccount (ra)

{name@domain | id} {newname@domain}

アカウント名の変更後は、そのアカウントに対する完全バックアップを実行することを推奨します。

zmbackup -f -s <servername.com> -a <newaccountname@servername.com>

setAccountCOS (sac)

{name@domain | id | adminName} {cos-name | cos-id}

zmprov sac joe@domain.com FieldTechnician

setPassword (sp)

{name@domain | id | adminName} {password}

zmprov sp joe@domain.com test321

パスワードにはアクセント付きの文字を使用できません。使用できない文字の例: a, e, i, u, u, n
カレンダーリソースプロビジョニングコマンド
Table 64. zmprov — カレンダーリソースプロビジョニングコマンド
コマンド 構文

createCalendarResource (ccr)

{name@domain} [attr1 value1 [attr2 value2]…​]

deleteCalendarResource (dcr)

{name@domain | id}

getAllCalendarResources (gacr)

[-v] [domain]

getCalendarResource (gcr)

{name@domain | id}

modifyCalendarResource (mcr)

{name@domain | id} [attr1 value1 {attr2 value2]…​]

purgeAccountCalendarCache (pacc)

{name@domain} […​]

renameCalendarResource (rcr)

{name@domain | id} {newName@domain}

フリービジーコマンド
Table 65. zmprov — フリービジーコマンド
コマンド 構文

getAllFbp (gafbp)

[-v]

getFreebusyQueueInfo (gfbqi)

[{provider-name}]

pushFreebusy (pfb)

{domain | account-id} [account-id…​]

pushFreebusyDomain (pfbd)

{domain}

purgeFreebusyQueue (pfbg)

[{provider-name}]

ドメインプロビジョニングコマンド
Table 66. zmprov — ドメインプロビジョニングコマンド
コマンド 構文 例/備考

countAccount (cta)

{domain | id}

各COS、COS IDおよびCOSに設定しているアカウント数をリストアップします

createAliasDomain (cad)

{alias-ドメイン名} {local-ドメイン名 | id} [attr1 value1 [attr2 value2]…​]

createDomain (cd)

{domain} [attr1 value1]…​

zmprov cd mktng.domain.com zimbraAuthMech zimbra

deleteDomain (dd)

{domain | id}

zmprov dd mktng.domain.com

getDomain (gd)

{domain | id}

zmprov gd mktng.domain.com

getDomainInfo (gdi)

name | id | virtualHostname {value} [attr1 [attr2]…​]

getAllDomains (gad)

[-v]

modifyDomain (md)

{domain | id} [attr1 value1]…​

zmprov md domain.com zimbraGalMaxResults 500

zimbraDomainRenameInfo をマニュアル操作で編集しないでください。ドメイン名を変更した際に自動的に更新されます。

renameDomain (rd)

{domain | id} {newDomain}

renameDomainzmprov -l/--ldap と共にしか使用できません。
提供サービスプロビジョニングコマンド
Table 67. zmprov — 提供サービスプロビジョニングコマンド
コマンド 構文 例/備考

copyCos (cpc)

{src-cos-name | id} {dest-cos-name}

createCos (cc)

{} [attr1 value1]…​

zmprov cc Executive zimbraAttachmentsBlocked FALSE zimbraAuthTokenLifetime 60m zimbraMailQuota 100M zimbraMailMessageLifetime 0

deleteCos (dc)

{name | id}

zmprov dc Executive

getCos (gc)

{name | id}

zmprov gc Executive

getAllCos (gac)

[-v]

zmprov gac -v

modifyCos (mc)

{name | id} [attr1 value1]…​

zmprov mc Executive zimbraAttachmentsBlocked TRUE

renameCos (rc)

{name | id} {newName}

zmprov rc Executive Business

サーバープロビジョニングコマンド
Table 68. zmprov — サーバープロビジョニングコマンド
コマンド 構文 例/備考

createServer (cs)

{} [attr1 value1]…​

deleteServer (ds)

{name | id}

zmprov ds domain.com

getServer (gs)

{name | id}

zmprov gs domain.com

getAllServers (gas)

[-v]

zmprov gas

modifyServer (ms)

{name | id} [attr1 value1]…​

zmprov ms domain.com zimbraVirusDefinitionsUpdateFrequency 2h

getAllMtaAuthURLs (gamau)

saslauthd.confのMTA認証に使用するべきサーバーをsaslauthd.confへ追加するために使用します

getAllMemcachedServers (gamcs)

memcachedサーバーをリストアップします(nginx使用)

設定プロビジョニングコマンド
Table 69. zmprov — 設定プロビジョニングコマンド
コマンド 構文 例/備考

getAllConfig (gacf)

[-v]

すべてのLDAP設定が表示されます

getConfig (gcf)

{name}

modifyConfig (mcf)

attr1 value1

LDAP設定を変更します

createXMPPComponent (csc)

{short-name} {domain} {server} {classname} {category} {type} [attr1 value1 [attr2 value2]…​]

deleteXMPPComponent (dxc)

{xmpp-component-name}

getXMPPComponent (gxc)

{name@domain} [attr1 [attr2]…​]

modifyXMPPComponent (mxc)

{name@domain} [attr1 value1 [attr2 value2]…​]

配布リストプロビジョニングコマンド
Table 70. zmprov — 配布リストプロビジョニングコマンド
コマンド 構文 例/備考

createDistributionList (cdl)

{list@domain}

addDistributionListMember (adlm)

{list@domain | id} {member@domain}

removeDistributionListMember (rdlm)

{list@domain | id}

getAlldistributionLists (gadl)

[-v]

getDistributionListmembership (gdlm)

{name@domain | id}

ダイナミックグループをネストすることはできないため gdlm はダイナミックグループに使用できません

getDistributionList (gdl)

{list@domain | id}

zmprov gdl list@domain.com

modifyDistributionList (mdl)

{list@domain | id} attr1 value1 [attr2 value2]…​

zmprov md list@domain.com

deleteDistributionList (ddl)

{list@domain | id}

addDistributionListAlias (adla)

{list@domain | id} {alias@domain}

removeDistributionListAlias (rdla)

{list@domain | id} {alias@domain}

renameDistributionList (rdl)

{list@domain | id} {newName@domain}

メールボックスコマンド
Table 71. zmprov — メールボックスコマンド
コマンド 構文 例/備考

getMailboxInfo (gmi)

{account}

getQuotaUsage (gqu)

{server}

recalculateMailboxCounts (rmc)

{name@domain | id}

未読メッセージカウントと割り当て容量の使用率がメールボックスの実際データと一致しない場合、このコマンドを使用することでメールボックス割り当て容量の使用率と未読メッセージ数を再計算できます。

メールボックス割り当て容量の使用率とメッセージカウントの再計算は、オフピークの時間帯に、一度に一つのメールボックスに対して実行されるようにスケジュールすることを推奨します。

reIndexMailbox (rim)

{name@domain | id} {start | status | cancel} [type | id]…​

compactIndexMailbox (cim)

{name@domain | id} {start | status}

verifyIndex (vi)

{name@domain | id}

getIndexStats (gis)

{name@domain | id}

selectMailbox (sm)

{アカウント名} [{zmmailbox commands}]

unlockMailbox (ulm)

{name@domain | id} [hostname]

メールボックスを移動しようとして失敗した後にメールボックスを解除する際、そのホスト名をパラメーターに指定するだけです。

その他のプロビジョニングコマンド
Table 72. zmprov — その他のプロビジョニングコマンド
コマンド 構文 例/備考

countObjects (cto)

{type} [-d {domain | id}]

countObjectszmprov -l/--ldap でのみ使用可能です。

createBulkAccounts (cabulk)

{domain} {namemask} {作成アカウント数}

describe (desc)

[[-v] [-ni] [{entry-type}]] | [-a {attribute-name}]

全ての属性名を出力します (アカウント、ドメイン、提供サービス、サーバーなど)

flushCache (fc)

[-a] {acl | locale | skin | uistrings | license | all | account | config | glo | balgrant | cos | domain | galgroup | group | mime | server | zimlet | <extension-cache-type>} [name1 | id1 [name2 | i d2]…​]

特定のタイプのLDAP エントリキャッシュをフラッシュします。 参照: Zimbra LDAP サービス

generateDomainPreAuth Key (gdpak)

{domain | id}

事前認証キーを作成し、信用できるサードパーティをシングルサインオンできるようにします。 GenerateDomainPreAuth とともに使用します。

generateDomainPreAuth (gdpa)

{domain | id} {} {name | id | foreignPrincipal} {timestamp | 0} {expires | 0}

比較用にpreAuthの値を生成します。

syncGal (syg)

{domain} [{token}]

getAccountLogger (gal)

[-s /--server hostname] {name@domain | id}

ログコマンド
Table 73. zmprov — ログコマンド
コマンド 構文 例/備考

addAccountLogger (aal)

{name@domain | id} {logging-category} {debug | info | warn | error}

指定したアカウントにカスタムのログレベルを設定します。

getAccountLoggers (gal)

[-s/--server hostname] {name@domain | id} {logging-category} {debug | info | warn | error}

getAllAccountLoggers (gaal)

[-s/--server hostname]

各カスタムログレベルのアカウントを返します。

removeAccountLogger (ral)

[-s/ --server hostname] {name@domain | id} {logging-category}

名前@ドメインを指定した場合、そのアカウントのカスタムのログレベルを削除します。それ以外の場合、すべてのアカウントからカスタムのログレベルを削除します。

resetAllLoggers (rlog)

[-s/--server hostname]

すべてのアカウントのログレベルを削除し、 /opt/zimbra/conf/log4j.properties をリロードします

ログレベルのカテゴリ一覧は zmprov ログのカテゴリ をご覧ください。

検索コマンド
Table 74. zmprov — 検索コマンド
コマンド 構文 例/備考

searchGAL (sg)

{domain} {}

zmprov sg joe

autoCompleteGal (acg)

{domain} {}

searchAccounts (sa)

[-v] {ldap-query} [limit] [offset] [sortBy {attribute}] [sortAscending 0 | 1] [domain {domain}]

searchCalendarResources (scr)

[-v] domain {attr op value} [attr op value]…​

共有プロビジョニングコマンド
Table 75. zmprov — 共有プロビジョニングコマンド
コマンド 構文 例/備考

getShareInfo (gsi)

{owner-name | owner-id}

ユニファイド・コミュニケーションサービスコマンド
Table 76. zmprov — ユニファイド・コミュニケーションサービスコマンド
コマンド 構文 例/備考

createUCService (cucs)

{} [attr1 value1 [attr2 value2]…​]

deleteUCService (ducs)

{name | id}

getAllUCServices (gaucs)

[-v]

getUCService (gucs)

[-e] {name | id} [attr1 [attr2]…​]

modifyUCService (mucs)

{name | id} [attr1 value1 [attr2 value2]…​]

renameUCService (rucs)

{name | id} {newName}

IMAP/POPプロキシコマンド
Table 77. zmprov — IMAP/POPプロキシコマンド
コマンド 例/備考

getAllReverseProxyURLs (garpu)

リバースプロキシ参照に使用するサーバーをnginx.confへ追加するために使用します。

getAllReverseProxy Backends (garpb)

zimbraReverseProxyLookupTarget=TRUE を持つサーバーの一覧を応答します。

基本的にプロキシからの検索リクエストを受けられる状態のメールボックスサーバーです。

getAllReverseProxyDomains (garpd)

ZimbraSSLCertificate zimbraVirtualHostname および zimbraVirtualIPAddress を設定したドメインのリストを返します。これでプロキシがカスタム/ドメイン証明を提供できるドメインリストを設定できます。

zmprov の例
Example 44. 新規アカウントとパスワードを作成し、デフォルトCOSに割り合てる
zmprov ca <アカウント@ドメイン> <パスワード>
Example 45. 新規アカウントとパスワードを作成し、特定のCOSに割り合てる

この場合、COSのIDが必要となります。COSのIDの確認方法

zmprov gc <提供サービス名>

zmprov ca <アカウント@ドメイン> <パスワード> zimbraCOS <提供サービスのID番号>
Example 46. 新規アカウントを作成し、内部で認証しないパスワードを指定する
zmprov ca <アカウント@ドメイン> ''

空のシングルクォートが必要で、ローカルパスワードが存在しないことを示します。

Example 47. バッチプロセスで複数のアカウントを作成可能

詳細については ユーザーアカウントのプロビジョニング を参照してください。

Example 48. バルクプロビジョニング

詳細については、 Bulk_Provisioning を参照してください。

Example 49. アカウントにエイリアスを追加する
zmprov aaa <アカウント@ドメイン> <エイリアス@ドメイン>
Example 50. 配布リストを作成する
zmprov cdl <配布リスト名@ドメイン>

配布リストのIDが返答されます。

Example 51. 配布リストへメンバーを追加する
zmprov adlm <配布リスト名@ドメイン> <メンバー@ドメイン>
管理コンソールでは複数メンバーを同時に追加できます。
Example 52. 管理者のパスワードを変更する

パスワードを変更するアドレスを入力することで、このコマンドで他のアカウントのパスワード変更も可能です。

zmprov sp <管理アカウント@ドメイン> <パスワード>
Example 53. Zimbra LDAPに対して認証を行なうドメインを作成する
zmprov cd <ドメイン名> zimbraAuthMech zimbra
Example 54. デフォルトドメインを設定する
zmprov mcf zimbraDefaultDomain <ドメイン名>
Example 55. すべてのCOSと属性値をリストアップする
zmprov gac -v
Example 56. ドメイン内のすべてのユーザーアカウントをリストアップする (domain.com)
zmprov gaa domain.com
Example 57. すべてのユーザーアカウントと設定をリストアップする
zmprov gaa -v domain.com
Example 58. シングルサーバー上のLoggerを有効にする
zmprov ms <サーバー名> +zimbraServiceEnabled logger

そしてLoggerを起動するためにzmloggerctl startを実行します。

Example 59. マルチバリューの属性に特定の値が設定されているかどうかを確認する
zmprov gs <サーバー名> 属性=値

例えば、zmprov gs example.com zimbraServiceEnabled=ldap を実行しますとLdapのサービスが有効かどうかが確認できます。

Example 60. パージ期間を変更する

パージ期間を変更する場合、 zimbraMailPurgeSleepInterval で、次のメールボックスに移動するまでサーバーが「スリープ」しておく必要がある時間を指定します。

zmprov ms <サーバー名> zimbraMailPurgeSleepInterval <Xm>

X はメールボックスのパージが実行されるまでの時間、 m は分を表します。 <xh> で時間でも使用できます。

Example 61. 通知メールのテンプレートを カスタマイズ

例61:通知メールのテンプレートを zimbraNewMailNotification でカスタマイズできます。別のメールボックスでメールを受信したことを通知するデフォルトメールは、Postmasterより送信されます。このテンプレートを変更するには受信するメールボックスアカウントを編集します。編集できる変数は次のとおりです。

  • ${SENDER_ADDRESS}

  • ${RECIPIENT_ADDRESS}

  • ${RECIPIENT_DOMAIN}

  • ${NOTIFICATION_ADDRESSS}

  • ${SUBJECT}

  • ${NEWLINE}

上記のどの変数でもメールの 件名送信元本文 に表示させるかを特定できます。 以下の例では name@domain.com で受信する通知メールの本文を変更しています。また、zmprov mcを使用して、提供サービス内のテンプレートも変更できます。コマンドは1行でまとめて入力します。

zmprov ma <アカウント@ドメイン> zimbraNewMailNotificationBody 'Important message from ${SENDER_ADDRESS}.${NEWLINE}Subject:${SUBJECT}'
Example 62. SMS通知をCOS、アカウント、またはドメインで有効化する
zmprov mc <default> zimbingaFeatureCalendarReminderDeviceEmailEnabled TRUE
zmprov ma <アカウント名> zimbraFeatureCalendarReminderDeviceEmailEnabled TRUE
zmprov md <ドメイン名> zimbraFeatureCalendarReminderDeviceEmailEnabled TRUE
Example 63. アクティビティストリーム機能を提供サービス、またはアカウントに対し有効化する
zmprov mc <default> zimbraFeaturePriorityInboxEnabled TRUE
zmprov ma <アカウント名> zimbraFeaturePriorityInboxEnabled TRUE
CLIからオートグループのバックアップを設定する

グローバル設定にバックアップ方法を設定すると、特定のサーバーにオートグループのバックアップ方法を使用したくない場合に、サーバーごとの設定をオーバーライドできます。

オートグループのバックアップをセットアップする場合、zmprov CLIを使用してLDAPの属性値を変更します。コマンドを以下の構文で入力します。

zmprov mcf <LDAPの属性> <値>

また、zmprov ms を使用してサーバーレベルの属性値も設定できます。

以下のLDAP属性値が変更されます。

  • zimbraBackupMode —  Auto-Grouped に設定します。デフォルトは Standard です。

  • zimbraBackupAutoGroupedInterval — 各グループにバックアップのセッションを実行する日数か週数を設定します。デフォルトは1日です。バックアップの期間は1日以上(xd)または1週以上(xw)を設定できます。

  • zimbraBackupAutoGroupedNumGroups — メールボックスを振り分けるグループ数です。デフォルトは7グループです。

スレッドのデフォルト値を変更する

メッセージを共通のスレッドとしてグループ化することができます。デフォルトではReferencesヘッダー項目によりメッセージをスレッド化します。Referencesヘッダーが存在しない場合、件名を使用します。、提供サービスまたは個々のアカウントごとに、デフォルトのオプションを変更できます。

zmprov mc [提供サービス名] zimbraMailThreadingAlgorithm [type]

使用可能なtypeは以下です。

  • none — スレッド化が実行されません。

  • subject — メッセージは件名のみでスレッド化されます。

  • strict — スレッドのメッセージヘッダー(References, In-Reply-To, Message-ID, およびResent-Message-ID) のみスレッド化されます。件名の確認は行いません。

  • references — "strict" とほぼ同様のロジックですが、メッセージをスレッド化している際に、Thread-Indexヘッダーが標準と異なる場合も考慮しています。つまり、ReferencesとIn-Reply-Toヘッダーのない返信メッセージについては、件名をベースとしたスレッド化にフォールバックします。

  • subjrefs — "references" と同様のロジックですが、件名が変更されるとスレッドは2つに分割されます。

破損したインデックスを検出する

zmprov verifyIndex で指定したメールボックスのインデックスの正常チェックを行います。標準出力へ診断情報を書き込みます。問題が検出された場合、失敗のステータスが返されます。

verifyIndex は、実行中にインデックスをロックし、インデックスにあるすべてのバイトを確認します。そのため、Cronジョブのような定期ベースでの実行は推奨しません。システムの診断が必要となった場合にのみ、zmprov verifyIndexのコマンドを使用すべきです。

zmprov verifyIndex <アカウント名@ドメイン>

verifyIndex でインデックスが破損されていると返した場合、reIndexMailbox (rim) を実行することでメールボックスのインデックスを修正できます。

zmprov rim <アカウント名@ドメイン> start
Table 78. zmprov — ログのカテゴリ

zimbra.account

アカウントのオペレーション

zimbra.acl

ACLオペレーション

zimbra.backup

バックアップと復元

zimbra.cache

Inmemoryのキャッシュオペレーション

zimbra.calendar

カレンダーのオペレーション

zimbra.dav

DAVのオペレーション

zimbra.dbconn

データベース接続のトレース

zimbra.extensions

サーバー拡張のロード

zimbra.filter

メールフィルター

zimbra.gal

GALのオペレーション

zimbra.imap

IMAPプロトコルのオペレーション

zimbra.index

インデックスのオペレーション

zimbra.io

ファイルシステムのオペレーション

zimbra.ldap

LDAPのオペレーション

zimbra.lmtp

LMTPのオペレーション(受信メール)

zimbra.mailbox

通常のメールボックスのオペレーション

zimbra.misc

その他

zimbra.op

メールボックスのステータス変更

zimbra.pop

POPプロトコルのオペレーション

zimbra.redolog

Redoログのオペレーション

zimbra.security

セキュリティイベント

zimbra.session

ユーザーセッションのトレッキング

zimbra.smtp

SMTPのオペレーション(送信メール)

zimbra.soap

SOAPプロトコル

zimbra.sqltrace

SQLトレース

zimbra.store

メールストアのディスクオペレーション

zimbra.sync

同期クライアントのオペレーション

zimbra.system

スタートアップ/シャットダウンなどのシステムメッセージ

zimbra.wiki

Wikiのオペレーション

zimbra.zimlet

Zimletのオペレーション

zmaccts

このコマンドですべてのアカウントと、それぞれのステータス、作成された日時および最終ログインされた日時をリストアップします。ドメインの要約ではアカウント合計数とステータスが表示されます。

構文
zmaccts

zmarchiveconfig

アーカイブのメールボックスを設定するコマンドです。略式のコマンド、または正式名のコマンドを使用して、同じ機能を実行できます。

構文
zmarchiveconfig [値] [コマンド] [コマンドの値]...
説明
正式名 略式名 説明

--help

-h

コマンドで使用できるオプションを表示します

--server

-s

(ホスト名)[:(ポート)] サーバーのホスト名とオプションのポート番号を表示します

--account

-a

(アカウント名) 認証するアカウント名を返します

--ldap

-l

LDAP経由でアーカイブをプロビジョンする

--password

-p

(パスワード) 認証アカウントのパスワードを返します

--passfile

-P

(ファイル) ファイルからパスワードを読み込みます

--zadmin

-z

Zimbraの管理者/パスワードをローカルから使用する

--debug

-d

デバッグモードへ切り替えます(SOAPメッセージをダンプする)

“cmd”で使用可能なアクション

enable <アカウント>

[archive-address <aaddr> [archive-cos <cos>] [archive-create <TRUE/FALSE>] [archive-password <pa [zimbraAccountAttrName <archive-attr-value]+

disable <アカウント>

zmarchivectl

Zimbraアカウントのアーカイブの起動、停止、リロード、またはステータスを確認するコマンドです。

構文
zmarchivectl start|stop|reload|status

zmarchivesearch

アカウントアーカイブに対して検索を行なうコマンドです。特定の条件に一致するアーカイブを検索し、ディレクトリへコピーを保存できます。

構文
zmarchivesearch {-m <ユーザー@ドメイン>} {-q <クエリのストリング>} [-o <offset>] [-l <制限>] [-d <アウトプットのディレクトリ>]
説明
正式名 略式名 説明

--dir

-d

<値>メッセージを書き込むディレクトリです。指定していない場合、ヘッダーのみ取得します。ファイル名は以下のフォーマットで生成されます。 RESULTNUM_ACCOUNT-ID_MAILITEMID

--help

-h

ヘルプメッセージを表示します。

--limit

-l

<値> 返す結果数を制限する。デフォルトは25です。

--mbox

-m

<値> 検索するアーカイブアカウント名

--offset

-o

<値> 結果リストが開始するところを指定する。デフォルトは0です。

--query

-q

<値> アーカイブ検索のクエリストリング

--server

-s

<値> メールサーバーのホスト名。localhostはデフォルトです。

--verbose

-v

検索中にステータスメッセージのプリントを許可する。

Example 64. 特定のサーバーに対してアーカイブを検索し、アーカイブのコピーを指定されたディレクトリへ保存します。
zmarchivesearch -m user1@yourdomain.com -q "in:sent" -o 0 -l 30 -d /var/tmp

zmbackup

指定したメールホストの完全バックアップと増分バックアップを実行するツールです。

この機能には略式名と正式名のオプションがあります。略式名のオプションはシングルのダッシュ(-)で始まり、正式名のオプションはダブルダッシュ(--)で始まります。例えば、-f--fullBackup と同じオプションです。

構文

-f, -i, または -del を指定する必要があります。

zmbackup {-f | -i | del} {-a <値>} [オプション]
説明
正式名 略式名 説明

--account

-a

<値> 複数のアカウントメールアドレスを空のスペースで区切るか、あるいはallにてすべてのアカウントを指定します。オートグループのバックアップの場合、このオプションは指定しません。システムは毎晩のバックアップ対象アカウントを把握しているからです。

--debug

-d

デバッグのため、診断を表示する。

--delete

-del

<値> 指定したラベル、日時(YYYY/MM/DD[-hh:mm:ss])以前のバックアップ、または特定期間 (nn(d | m | y])のバックアップを削除する。

--excludeBlobs

完全バックアップからブロブを除外する。指定していない場合、サーバーの設定を使用する。

--excludeHsmBlobs

完全バックアップからHSMボリュームのブロブを除外する。指定していない場合、サーバーの設定を使用する。

--excludeSearchIndex

完全バックアップから検索のインデックスを除外する。指定していない場合、サーバーの設定を使用する。

--fullBackup

-f

完全バックアップを開始する。オートグループのバックアップの場合、このオプションは、前回の完全バックアップから追加されたRedoログをコピーします(増分のバックアップの主な動作)。

--help

-h

このコマンドの使用オプションを表示する。

--incrementalBackup

-i

増分バックアップを開始する。オートグループバックアップの場合、このオプションを使用できません。

--includeBlobs

完全バックアップにブロブを含む。指定していない場合、サーバーの設定を使用します。

--includeHsmBlobs

完全バックアップにHSMボリュームのブロブを含む。指定していない場合、サーバー設定を使用します。

--includeSearchIndex

完全バックアップに検索インデックスを含む。指定していない場合、サーバーの設定を使用します。

--noZip

ブロブをzipファイルよりも、独自ファイルとしてバックアップします。

--server

-s

<値> メールサーバーのホスト名。フォーマットはプレインのホスト名、またはserver.domain.comの名です。デフォルトはlocalhostの名です。

--sync

-sync

完全のバックアップを同期的に実行します。

--target

-t

<値> ターゲットのバックアップ保存場所を指定します。デフォルトは`/opt/zimbra/backup`です。

--zip

-z

圧縮したzipファイルへブロブをバックアップします。 --zipStore が指定されている場合、無視されます。

--zipStore

圧縮していないzipファイルへブロブをバックアップします。(デフォルト)

以下の例ではサーバー (-s) は server1.domain.com`です。保存ターゲットはデフォルトのディレクトリ(/opt/zimbra/backup`)の場合、(-t)を指定する必要はありません。

Example 65. server1 のすべてのメールボックスに対し完全バックアップを実行する
zmbackup -f -a all -s server1.domain.com
Example 66. server1 の最新の完全バックアップ以降増分のバックアップをすべてのメールボックスに対し実行する
zmbackup -i -a all -s server1.domain.com
Example 67. server1user1 のメールボックスのみを完全にバックアップする。
zmbackup -f -a user1@domain.com -s server1
アカウントを指定している場合、ホスト名にはフルドメイン名である必要はありません。
Example 68. server1 の*user1* のメールボックスへ増分のバックアップを実行する。
zmbackup -i -a user1@domain.com -s server1

zmblobchk

Zimbraのブロブストア (/opt/zimbra/store)の整合性チェックを実行するコマンドです。データベースのメタデータのマッチングをせずにファイルをチェックし、メモを保存します。ファイルのサイズ情報が正常であることもチェックします。

構文
zmblobchk [オプション] start

意図しないブロブチェックの実行を回避するため、Startのコマンドが必要です。IDの値はカンマで区切ります。

説明
正式名 略式名 説明

--export-dir

<パス> データベースのエクスポートファイル用のターゲットディレクトリ

--help

-h

ヘルプのメッセージを表示する。

--mailboxes

-m

<メールボックスのID> チェックするメールボックスを指定する。指定していない場合、すべてのメールボックスをチェックする。

--missing-blob-delete-item

ブロブが存在していない場合、そのアイテムを削除する。

--no-export

エクスポートせずにアイテムを削除する。

--skip-size-check

ブロブのサイズチェックを実行しない。

--unexpected-blob-list

<パス> 予期せぬブロブのパスをファイルに記録する。

--verbose

-v

詳細のアウトプット、エラーにスタックトレースを表示する。

--volumes

<ボリュームID> チェックするボリュームを指定する。指定していない場合、すべてのボリュームをチェックする。

zmcalchk

Zimbraカレンダーの予定の整合性チェックを実行し、不整合の場合はメール通知を送信します。例えば、カレンダーのイベントにすべての参加者と管理者がイベントの開始/終了時や会議の繰り返し予定を承諾しているかどうかを確認します。

time-specsの詳細については`zmmailbox help appointment` の出力内容を参考にしてください。

構文
zmcalchk [-d] [-n <種類>] <ユーザー名> <開始のtime-spec> <終了のtime-spec>
説明
略式名 説明

-d

デバッグ情報を表示

-m

確認する最大の参加者数を指定する。デフォルトは50です。

-n

-n none | user | organizer | attendee | all

予定に同期していない場合、特定のユーザーへ通知メッセージを送信する。

zmschedulebackup

バックアップをスケジュールし、Cronテーブルへコマンドを追加するコマンドです。

以下はデフォルトのスケジュールです。

  • 毎週土曜日で01:00に完全バックアップ実施 (0 1 * * 6)

  • 毎週日曜日から金曜日に01:00に増分のバックアップ実施 (0 1 * * 0-5)

各crontabエントリは、空のスペースで区切られた5項目から成るシングルラインです。 各項目は以下のフォーマットを使用します。

  • 分 — 0 から 59

  • 時 — 0 から 23

  • 日 — 1 から 31

  • 月 — 1 から 12

  • 曜日 — 0 から 7 (0 または 7 は日曜日、または曜日名を使用する)

使用しない期間にアスタリスク (*) を入力します。

このコマンドにより、自動的にスケジュールがcrontabへ書き込まれます。

構文
zmschedulebackup {-q|-s|-A|-R|-F|-D}[f|i|d|] ["スケジュール内容"]
説明
正式名 略式名 説明

help

-h

このコマンドで使用できるオプションを表示します。

query

-q

デフォルトのコマンド。 現在のZimbraバックアップスケジュールを表示します。

save

-s

スケジュールを保存します。 スケジュールコマンドをテキストファイルなどへ保存することで、システムを復元した際にバックアップのスケジュールを早く再生成できるようになります。

flush

-F

現在のスケジュールを削除し、スケジュールされているバックアップをすべてキャンセルします。

append

-A

現在のスケジュールへ指定したバックアップを追加します。

replace

-R

現在のスケジュールを指定したスケジュールで上書きします。

default

-D

現在のスケジュールをデフォルトのスケジュールで上書きします。

zmbackupへ転送されるオプション

no compression

-n

ブロブをzipファイルよりも独自ファイルとしてバックアップします。

compress

-z

ブロブを圧縮したzipファイルにバックアップします。 --zipStore を指定した場合、無視されます。

--zipStore

ブロブを圧縮せずにzipファイルへバックアップします。

target

-t

完全バックアップを保存するターゲット場所を指定します。デフォルトは /opt/zimbra/backup です。

増分のバックアップを保存するターゲット場所は指定できません。スケジュールした増分のバックアップにターゲット (-t) 場所のオプションを追加した場合、無視されます。

account

-a

特定のアカウント。 デフォルトはすべてのアカウント。

--mail-report

レポートを管理者へ送信します。

--server

メールサーバーのホスト名。 localhostはデフォルト。

--sync

完全バックアップを同期的に実行します。

--excludeBlobs

完全バックアップからブロブを除外します。指定していない場合、サーバーの設定を使用します。

--includeBlobs

完全バックアップにブロブを含む。指定していない場合、サーバーの設定を使用します。

--excludeHsmBlobs

完全バックアップからHSMボリュームのブロブを除外します。 指定していない場合、サーバーの設定を使用します。

--includeHsmBlobs

完全バックアップにHSMボリュームのブロブを含みます。指定していない場合、サーバーの設定を使用します。

--excludeSearchIndex

完全バックアップから検索インデックスを除外します。指定していない場合、サーバーの設定を使用します。

--includeSearchIndex

完全バックアップに検索インデックスを含みます。指定していない場合、サーバーの設定を使用します。

Cron schedule — バックアップの種類: <i | f | d 値>

incremental backup

i

<時間指定> 増分バックアップ

オートグループのバックアップモードの場合、増分のバックアップは使用されません。

full backup

f

完全バックアップ

delete

d <値>

バックアップを削除する。 <値>n(d | m | y)

バックアップのスケジュール例
Example 69. デフォルトの完全と増分のバックアップをスケジュールする
zmschedulebackup -D
Example 70. 現在のスケジュールを新しいスケジュールにて上書きする
zmschedulebackup -R f ["スケジュール内容"]
Example 71. 現在のスケジュールに新しい完全バックアップを追加する
zmschedulebackup -A f ["スケジュール内容"]
Example 72. 現在のスケジュールに新しい増分バックアップを追加する
zmschedulebackup -A i ["スケジュール内容"]
Example 73. 現在のスケジュールを表示する
zmschedulebackup -q
Example 74. スケジュールを1行で表示する

1行のコマンドとしてスケジュールを表示します。これをテキストファイルへコピー・保存しておき、アプリケーションの復元が必要な場合に使用できるようにします。

zmschedulebackup -s

zmbackupabort

バックアッププロセスを強制的に停止するコマンドです。停止する前にバックアップのラベルを確認する必要があります。バックアップ実施後にラベルが表示されます。ラベルが不明な場合、zmbackupqueryを使用して確認することができます。

復元プロセスを停止するには

実行中の復元を zmbackupabort -r にて強制的に停止することができます。復元中のアカウントの復元が完了したら、復元のプロセスが停止します。コマンドは復元していないアカウントを返します。

構文
zmbackupabort [オプション]
説明
正式名 略式名 説明

--debug

-d

デバッグ用の診断を表示します。

--help

-h

このコマンドで使用できるオプションを表示します。

--label

-lb

<値> 停止するバックアップのラベル。

ラベル名を調べるため、zmbackupqueryを使用できます。

--restore

-r

実行中の復元を強制的に停止します。

--server

-s

<値> メールサーバーのホスト名。使用形式はプレインのホスト名、またはserver.domain.comの名前。デフォルトはlocalhostの名前です。

--target

-t

<値> バックアップを保存するターゲット場所を指定します。

デフォルトは /opt/zimbra/backup です。

zmbackupquery

zmbackupquery で完全バックアップのセットを検索します。このコマンドで、特定の完全バックアップセット、特定の日時以降の完全バックアップのセット、またはバックアップディレクトリにあるすべてのバックアップのセットを検索できます。

あるアカウントの特定の時間の最適な完全バックアップを確認するには、以下のようなコマンドを実行します。

zmbackupquery -a <アカウントのメールアドレス> --type full --to <復元する日時>
構文
zmbackupquery [オプション]
説明
正式名 略式名 説明

--account

-a

<値> 複数のアカウントメールアドレスを空のスペースで区切るか、あるいはallですべてのアカウントを指定します。

--debug

-d

デバッグのために診断情報を表示します。

--help

-h

このコマンドで使用できるオプションを表示します。

--from

<値> 指定した日時以降のバックアップをリストアップします。

--label

-lb

<値> クエリする完全バックアップのセッションラベル。ラベルの例: backup200507121559510

--server

-s

<値> メールサーバーのホスト名。プレインなホスト名、またはserver.domain.nameを使用します。デフォルトはlocalhostの名前です。

--target

-t

<値> バックアップの保存先の場所を指定します。 (デフォルトは /opt/zimbra/backup)

--to

<値> 指定した日時以前のバックアップをリストアップします。

--type

<値> クエリするバックアップの種類、 "full" または "incremental"。指定していない場合、両方をクエリします。

--verbose

-v

詳細なステータス情報を返します。

日時を以下のフォーマットで指定します。

2008/12/16 12:19:23

2008/12/16 12:19:23 257

2008/12/16 12:19:23.257

2008/12/16-12:19:23-257

2008/12/16-12:19:23

20081216.121923.257

20081216.121923

20081216121923257

20081216121923

年、月、日、時、分、秒、とオプションでミリ秒を指定します。

月/日/時/分/秒は0を付けて必ず2桁の数字を使用します、ミリ秒は3桁の数字です。

時は24時間形式を指定します。時間はローカルのタイムゾーンとなります。

zmrestore

指定したメールホストに対して、完全と増分の復元を実行するツールです。特定のアカウントを指定するか、アカウントを指定していない場合、バックアップにあるすべてのアカウントが復元されます。また、特定の時間まで復元することができます。

この機能には、略式名と正式名のオプションがあります。略式名のオプションはシングルダッシュ(-)で始まり、正式名のオプションはダブルダッシュ(--)で始まります。例えば、 -rf--restorefullBackupOnly と同じオプションです。

構文
zmrestore [オプション]
説明
正式名 略式名 説明

--account

-a

<値> アカウントのメールアドレスを指定します。空スペースでアカウントを区切る、またはallですべてのアカウントを復元します。

--backedupRedologs

-br

バックアップされたRedoログのみを実行し、アーカイブや現在のRedoログを無視します。

--continueOnError

-c

エラーが発生した際に他のアカウントの復元を続けます。

--createAccount

-ca

アカウントにプレフィックスを追加した新しいターゲットアカウントへの復元します。

(-pre のオプションを使用しているコマンドのみ有効)

--debug

-d

デバッグのため、診断情報を表示します。

--excludeBlobs

ブロブを復元しません(HSMも)。

--excludeHsmBlobs

HSMブロブを復元しません。

--excludeSearchIndex

検索インデックスを復元しません。

--help

-h

このコマンドで使用できるオプションを表示します。

--label

-lb

<値> 復元する完全バックアップのレベル。指定していない場合、最新の完全バックアップへ復元します。

--prefix

-pre

<値> 元アカウント名に追加するプレフィックス。

--restoreAccount

-ra

ディレクトリサービスへアカウントを復元します。

--restoreToIncrLabel

<値> 指定した増分バックアップまで以前のRedoログをすべて適用します。

--restoreToRedoSeq

<値> 指定したRedoログシーケンスまで適用します。

--restoreToTime

<値> 指定した時間までRedoログを適用します。

--restorefullBackupOnly

-rf

完全バックアップまで復元し、そのバックアップ以降の増分バックアップを適用しません。

--server

-s

<値> メールサーバーのホスト名。プレインホスト名、またはserver.domain.comを使用します。デフォルトはlocalhostの名前です。

--skipDeletes

Trueの場合、Redoログの適用で削除のアクションを適用しません。

--skipDeletedAccounts

指定したアカウントが削除された、またはバックアップ時に存在しなかったアカウントを復元しません (このオプションは必ず -a all のオプションで使用します)。

--systemData

-sys

グローバルテーブルとローカル設定を復元します。

--target

-t

<値> バックアップを保存しているターゲットを指定します。デフォルトは /opt/zimbra/backup です。

Example 75. server1 のすべてのアカウントを完全に復元します。

最新の完全バックアップと増分バックアップ以降について、server1 のすべてのアカウントを完全に復元します。

zmrestore -a all -s server1.domain.com
Example 76. server1 に最新の完全バックアップまで復元します。

server1 の全アカウントについて最新の完全バックアップまで復元し、それ以降の増分バックアップを実行しません。

zmrestore -rf -a all -s server1.domain.com
Example 77. ターゲットアカウントのバックアップのデータから新しいアカウントを作成します。

新しいアカウント名はnew_user1@domain.comとなります。

zmrestore -a user1@domain.com -ca -pre new_

zmrestoreoffline (オフラインの復元)

zmrestoreoffline を実行するための条件は以下となります。

  • mailboxd が起動していない

  • SQL データベースが起動している

  • LDAP ディレクトリサーバが起動している

実行条件

構文
zmrestoreoffline [オプション]
説明
正式名 略式名 説明

--account

-a

<値> アカウントのメールアドレスを指定します。空のスペースでアカウントを区切るか、またはallですべてのアカウントを復元します。このオプションは 必須 です。

--backedupRedologsOnly

-br

バックアップに保存したRedoログのみを実行し、アーカイブや現在のRedoログを除外します。

--continueOnError

-c

エラーが発生しても他のアカウントの復元を続けます。

--createAccount

-ca

アカウントをプレフィックスが追加した新しいターゲットアカウントへ復元します。

--debug

-d

デバッグのため、診断情報を表示します。

--help

-h

このコマンドで使用できるオプションを表示します。

--ignoreRedoErrors

Trueの場合、Redoログの再適用中のすべてのエラーを無視します。

--label

-lb

<値> 復元する完全バックアップのラベル。指定していない場合、最新の完全バックアップへ復元します。

--prefix

-pre

<プレフィックス> 元アカウント名に追加するプレフィックス。

--restoreAccount

-ra

ディレクトリサービスのアカウントを復元します。

--restoreToIncrLabel

<値> 以前のRedoログを指定した増分バックアップまで適用します。

--restoreToRedoSeq

<値> 指定したRedoログシーケンスまで適用します。

--restoreToTime

<値> 指定した時間までRedoログを適用します。

--restoreFullBackupOnly

-rf

完全バックアップまで復元し、そのバックアップ以降の増分バックアップは適用しません。

--server

-s

<値> メールサーバーのホスト名。プレインホスト名、またはserver.domain.comを使用します。デフォルトはlocalhostの名前です。-s を指定する場合、ローカルホストでなければなりません。

--skipDeletedAccounts

-skipDeletedAccounts

指定したアカウントが削除された、またはバックアップ時に存在しなかったアカウントを復元しません (このオプションは必ず -a all のオプションで使用します)。

--systemData

-sys

グローバルテーブルとローカル設定を復元します。

--target

-t

<値> バックアップを保存しているターゲットを指定します。デフォルトは /opt/zimbra/backup です。

zmrestoreoffline を実行する前に、LDAPのディレクトリサーバーが起動中である必要があります。

Example 78. server1 のすべてのアカウントを完全に復元する

server1 の完全バックアップおよびその後に発生した増分バックアップを使用し、すべてのアカウントを完全に復元します。

zmrestoreoffline -s server1.domain.com

zmrestoreldap

LDAPのバックアップからアカウントを復元するツールです。

構文
zmrestoreldap {-lb <値>} {-t <値>} [オプション]
説明
略式名 説明

-lb

<値> 復元の元に使用するセッションラベル。例えば full200612291821113

-t

<値> バックアップの保存ターゲット場所を指定します。デフォルトは /opt/zimbra/backup です。

-lbs

バックアップにあるすべてのセッションラベルをリストアップします。

-l

ファイルにあるアカウントをリストアップします。

-a

<値> 指定したアカウントを復元します。 アカウント名を空のスペースで区切ります。

zmcontrol (サービスの起動/停止/再起動)

サービスを起動、停止、または再起動するコマンドです。インストールしている Zimbra Collaboration のバージョンの確認も可能です。

構文
zmcontrol [ -v -h ] command [値]
説明
正式名 略式名 説明

-v

ZCS のソフトウェアバージョンを表示します。

-h

このコマンドで使用できるオプションを表示します。

-H

ホスト名 (localhost)

“cmd”で使用可能なアクション

maintenance

メンテナンスモードへ切り替えます。

restart

ホストにあるサービスとマネージャーをすべて再起動します。

shutdown

ホストにあるサービスとマネージャーをすべて停止します。マネージャーが停止している場合、ステータスのクエリができません。

start

ホストにあるサービスとマネージャーをすべて起動します。

startup

ホストにあるサービスとマネージャーをすべて起動します。

status

ホストのサービスステータスを返します。

stop

すべてのサービスを停止しますがマネージャーは継続して動作します。

zmmboxsearch (クロスメールボックス検索)

複数のメールボックスを検索するには zmmboxsearch のCLIコマンドを使用します。特定の条件に一致するメッセージや添付ファイルを複数のメールボックスに対して検索し、特定のディレクトリへメッセージのコピーを保存できます。

構文
zmmboxsearch {-m <値>} {-q <値>} [-o <値>] [-l <値>] [-d <値>] [オプション]
説明
正式名 略式名 説明

--dir

-d

<値> メッセージを書き込むディレクトリ。指定していない場合、ヘッダーのみが取得されます。ファイル名は以下のフォーマットで生成されます。 RESULTNUM_ACCOUNT-ID_MAILITEMID (結果番号_アカウントID_メールのアイテムID)

--help

-h

ヘルプ情報を表示します。

--limit

-l

検索結果に返すアイテム数の制限を指定します。 デフォルトは25です。

--mbox

-m

<値> カンマ区切りリストで検索するメールボックス。 リストにUID、メールアドレス、/サーバー/メールボックスID または *

--offset

-o

<値> 結果の開始時点を指定します。デ フォルトは0です。

--query

-q

<値> 検索のクエリストリング

--server

-s

<値> メールサーバーのホスト名。デフォルトはlocalhostです。

--verbose

-v

検索中にステータスメッセージを表示します。

以下の例では指定したサーバーにある2つのメールボックスの受信トレイを検索し、メッセージのコピーを指定したディレクトリへ保存します。

Example 79. クロスメールボックス検索
zmmboxsearch -m user1@yourdomain.com,user2@yourdomain.com -q "in:inbox" -d /var/tmp

zmmboxmove

メールボックスの移動にzmmboxmoveのCLIコマンドを使用します。移動先のサーバーは移動のプロセスを全体的に管理します。 zmmboxmove のコマンドを使用することで、アカウントのロックアウト期間を飛躍的に短縮させることができます。

zmmboxmove のCLIコマンドではZimbraサーバー同士でメールボックスを移動できます。同じLDAPサーバーを使用しているZimbraサーバー間でメールボックスを移動できます。ファイルは全て新しいサーバーへコピーされ、LDAPは更新されます。メールボックスが新しいサーバーへ移動完了した後、元のサーバーにコピーが残されますが、元のメールボックスはクローズのステータスになります。元のメールボックスへのログインはできませんし、メールは配信されません。管理者は、すべてのメールボックス内容が正常に移動されたことを確認した上で元のメールボックスを削除するようにしてください。

構文
zmmboxmove -a <email> --from <src> --to <dest> [--sync]
説明
正式名 略式名 説明

--account

-a

<値> 移動するアカウントのメールアドレス。

--help

-h

このコマンドで使用できるオプションを表示します。

--from

-f

<値> メールサーバーのホスト名。 --account に指定したメールボックスが存在するサーバーを記載する必要があります。

--to

-t

<値> 移動先のサーバー。

--sync

-sync

同期的に実行します。

zmmboxmovequery

サーバーの転入と転出、両方向含め、実行中のメールボックス移動をCLIコマンドの zmmboxmovequery で検索します。

構文
zmmboxmovequery -a <アカウント@ドメイン> [-s <クエリするサーバー>]

zmpurgeoldmbox

メールボックス移動が完了後、 zmpurgeoldmbox のCLIコマンドで元のサーバーから元のメールボックスを削除します。

構文
zmpurgeoldmbox -a <アカウント@ドメイン> [-s <削除するサーバー>]
説明
正式名 略式名 説明

--account

-a

<値> 削除するアカウントのメールアドレス。

--help

-h

このコマンドで使用できるオプションを表示します。

--server

-s

<値> メールサーバーのホスト名。アカウントが元々に存在したサーバー名を記載する必要があります。

zmgsautil

zmgsautil のCLIコマンドでGAL Syncアカウントの作成、削除およびLDAPデータをGAL Syncアカウントへ強制的に同期することができます。

ドメインにGALを設定したとき、GAL Syncのアカウントが自動で作成されます。アカウント作成と、完全の同期を実行するポーリング期間は、管理コンソールで管理します。

GAL Syncアカウントの属性値や設定を確認する場合、アカウントに対して zmprov gds を実行します。

正式名 説明

createAccount

GAL Syncアカウントを作成します。これは管理コンソールで実行するようにしてください。

"server" パラメーターが必要です。

-a {アカウント名} -n {データソース名} --domain {ドメイン名} -t zimbra|ldap -s {サーバー} [-f {フォルダ名}] [-p {ポーリング期間}]

addDataSource

サーバーにデータソースを設定している際、 /Contacts 以外のフォルダ名を指定する必要があります。データソースフォルダ名は一意でなければなりません。

-a {アカウント名} -n {データソース名} --domain {ドメイン名} -t zimbra|ldap [-f {フォルダ名}] [-p {ポーリング期間}]

deleteAccount

GAL Syncアカウントと、LDAPサーバーへの参照を削除します。アカウントは管理コンソールから削除することも可能です。

deleteAccount [-a {Galsyncアカウント名}|-i {アカウントID}]

trickleSync

最新と更新した連絡先データのみを同期します。

[-a {Galsyncアカウント名}|-i {アカウントID}]
[-d {データソースID}] [-n {データソース名}]

上記のデータソースIDはLDAPのデータソースIDです。 上記のデータソース名は、GAL Syncアカウント内にLDAPとの同期のために作成した連絡先リスト(フォルダ)です。

trickleSyncを実行するようにCron jobを設定できます。

fullSync

すべてのLDAP連絡先データを同期します。管理コンソールにも設定できます。

[-a {Galsyncアカウント名}|-i {アカウントID}]
[-d {データソースID}] [-n {データソース名}]

forceSync

フィルター、属性値のマッピング、またはLDAPのサーバー属性に変更があれば、このオプションでGALを完全にリロードします。

[-a {Galsyncアカウント名}|-i {アカウントID}]
[-d {データソースID}] [-n {データソース名}]

zmldappasswd

CLIコマンドの zmldappasswd を使って、ローカルサーバー上のLDAPのパスワードを変更できます。マルチサーバーの環境ではこのコマンドはLDAPのマスターサーバーでのみ実行します。

このコマンドをオプションと共に使用することで、他のパスワードを変更できます。

セキュリティと監査のため、以下のパスワードはZCSで生成されます。

  • LDAP Admin password 管理用のマスターLDAPパスワード。

  • LDAP Root password 内部のLDAP動作に使用します。

  • LDAP Postfix password LDAPサーバーへPostfixユーザーを識別させるために使用するパスワードであり、MTAサーバー上に設定されています。これは、LDAPのマスターサーバー上のパスワードと一致させる必要があります。

  • LDAP Amavis password LDAPサーバーへAmavisユーザーを識別させるために使用するパスワードであり、MTAサーバー上に設定されています。これは、LDAPのマスターサーバー上のパスワードと一致させる必要があります。

  • LDAP Replication password LDAPサーバーへLDAPのレプリカユーザーを識別させるために使用するパスワードであり、LDAPのマスターサーバー上のパスワードと一致させる必要があります。

構文
zmldappasswd [-h] [-r] [-p] [-l] 新しいパスワード
説明
Name 構文, 例, 備考

-h

ヘルプを表示します。

-a

ldap_amavis-password を変更します。

-b

ldap_bes_searcher_password を変更します。

-l

ldap_replication_password を変更します。

-p

ldap_postfix_password を変更します。

-n

ldap_nginx_password を変更します。

-r

ldap_root_passwd を変更します。

-c

レプリカの設定データベース内のパスワードを更新します。 -1 を使用する必要があります。加えて、マスター上のパスワードを変更した後に、レプリカ上で実行する必要があります。

a, l, p, r のいずれかのみ指定可。オプションを含めない場合、zimbra_ldap_password が変更されます。

zmlocalconfig

このコマンドでZimbraサーバーのローカル設定の編集、または閲覧ができます。zmlocalconfig -i を使用することで、管理者が設定可能な属性値を確認できます。

構文
zmlocalconfig [オプション]

ローカル設定を確認する場合 zmlocalconfig を実行します。

説明
正式名 略式名 説明

--config

-c

<値> 設定が保存されているファイル。

--default

-d

[値] にリストアップされているキーのデフォルト値を表示します。

--edit

-e

設定ファイルを編集し、指定したキーと属性値を変更します。 [値] は「キー=値」のフォーマットです。

--force

-f

変更することが危険な可能性のあるキーの値を編集します。

--help

-h

このツールで使用できるヘルプを表示します。

--info

-i

サポートしているプロパティをリストアップします。

--format

-m

<値> 値を以下のフォーマットで表示します。
プレイン (デフォルト), xml, シェル, nokey

--changed

-n

[値] にリストアップされているキーのなかで、デフォルトの値が変更されている値を表示します。

--path

-p

使用する設定ファイルを表示します。

--quiet

-q

ログを記録しません。

--random

-r

編集のオプションに使用します。指定した属性はランダムのパスワードストリングへ設定されます。

--show

-s

パスワードのストリングを強制的に表示します。

--unset

-u

設定のキーを削除します。元からのデフォルト値があるキーの場合、値が空のストリングへ設定されます。

--expand

-x

値を展開します。

--zimbraAmavisMaxServers

Amavisdの同時実行数を管理します (デフォルト 10)。

--zimbraClamAVMaxThreads

ClamAVの同時実行数を管理します (デフォルト 10)。

zmmailbox

メールボックスの管理に zmmailbox のツールを使用します。管理者がアカウントと共に新しいメールボックスのプロビジョニング、メールボックス問題のデバッグおよび移行を行なうのに役立つコマンドです。

zmprov コマンド内で zmmailbox のコマンドを実行できます。zmprov 内で selectMailbox を実行しますと、指定したメールボックスへ zmmailbox コマンドを実行できます。exitを実行するまで自由に zmmailbox のコマンドを実行できます。exitにより zmprov へ返されます。アカウントを作成する際に、特定のフォルダ、タグおよび保存された検索を、同時に作成したいときに便利です。

構文
zmmailbox [値] [コマンド] [コマンドの値]...
説明
略式名 正式名 構文、実例、備考

-h

--help

使用方法を表示します。

-f

--file

インプットストリームとしてファイルを使用します。

-u

--url

http[s]://{ホスト}[:{ポート}] サーバーのホスト名とオプションのポートです。-z/-a の場合は管理のポートを使用する必要があります。

-a

--account

認証するアカウント名。

-z

--zadmin

ローカル設定にあるZimbra管理名とパスワードを管理/パスワードに使用します。

-y

--authtoken {認証トークン}

コマンドラインで認証トークンのストリング(JSONのフォーマットが必要)を使用します。

-Y

--authtoken {認証トークンのファイル}

コマンドラインで認証トークンのストリング(JSONのフォーマットが必要)をファイルから使用します。

-m

--mailbox {}

開くメールボックスを指定します。他のオプションを指定していない場合、認証アカウントとターゲットアカウントの両方の役目を使用できます。

--auth {}

認証するアカウント名を指定します。--admin-priv を使用していない限り、デフォルト --mailbox のアカウントです。

-A

--admin-priv

管理者の権限でリクエストを実行します。

-p

--password {パスワード}

管理者アカウントのパスワード、またはメールボックス。

-P

--passfile {ファイル}

ファイルからパスワードを読み込みます。

-t

--timeout

タイムアウト(秒)。

-v

--verbose

詳細のモード(スタックトレースに例外の全ての情報をダンプします)。

-d

--debug

デバッグモード(SOAPメッセージをダンプします)。

様々なメールボックスで使用できる特定のCLIツールもあります。CLIのヘルプには以下の使用方法の詳細が記載してあります。

zmmailbox help admin

管理に関するコマンドのヘルプ

zmmailbox help commands

すべての zmmailbox コマンドのヘルプ

zmmailbox help appointment

予定に関連しているコマンドのヘルプ

zmmailbox help contact

連絡先に関連しているコマンドのヘルプ(連絡先リスト)

zmmailbox help conversation

スレッドに関連しているコマンドのヘルプ

zmmailbox help filter

フィルターに関連しているコマンドのヘルプ

zmmailbox help folder

フォルダに関連しているコマンドのヘルプ

zmmailbox help item

アイテムに関連しているコマンドのヘルプ

zmmailbox help message

メッセージに関連しているコマンドのヘルプ

zmmailbox help misc

その他のコマンドに関連しているコマンドのヘルプ

zmmailbox help right

権限に関連しているコマンドのヘルプ

zmmailbox help search

検索に関連しているコマンドのヘルプ

zmmailbox help tag

タグに関連しているコマンドのヘルプ

Example 80. フォルダとタグの作成

アカウントを作成した際、特定なタグやフォルダを先に生成したい場合があります。zmprov の中で selectMailbox(sm) を実行すると zmmailbox にアクセスできます。

$ zmprov
prov> ca user10@domain.example.com test123
9a993516-aa49-4fa5-bc0d-f740a474f7a8
prov> sm user10@domain.example.com
mailbox: user10@domain.example.com, size: 0 B, messages: 0, unread: 0
mbox user10@domain.example.com> createFolder /Archive
257
mbox user10@domain.example.com> createTag TODO
64
mbox user10@domain.example.com> createSearchFolder /unread "is:unread"
258
mbox user10@domain.example.com> exit
prov>
Example 81. アカウントのメールボックスサイズを確認する
zmmailbox -z-m アカウント@ドメイン gms
Example 82. 管理の認証トークンを使用し、メールボックスへリクエストを送信する

emptyDumpster のコマンドを使用している場合に管理の認証トークンが必要です。 --admin-priv を使用しますと、代理認証せずにターゲットメールボックスを使用します。

zmmailbox -z --admin-priv -m foo@example.com emptyDumpster
Example 83. 指定したメールボックスのコマンドに --admin-priv を使用する
zmmailbox -z
mbox> sm --admin-priv アカウント@ドメイン
Example 84. 代表の管理ユーザーとして認証する

認証しますと別のユーザーのメールボックスへログインできます。認証するユーザーは委任された管理者であり、ターゲットのメールボックスに adminLoginAs の権限が与えられている必要があります。認証のオプションは非管理者の認証トークンを使用します。認証するアカウントを指定するには --auth のオプションを使用し、認証するアカウントを指定します。以下の例ではユーザーbarでログインし、fooのメールボックスを開きます。

$ zmmailbox --auth bar@example.com -p password -m foo@example.com
Example 85. アカウントのメールボックスサイズを確認する
zmmailbox -z -m アカウント@ドメイン gms
Example 86. メールボックス内容をzipファイルにバックアップする

個々のメールボックスを zmmailbox を使用してバックアップする場合、zip、またはtgzファイルとしてファイルを保存できます。各フォーマットへの保存するデフォルト設定は、以下のように情報によって異なります

ファイル TGZ ZIP

ブリーフケース

X

X

カレンダー

X

スレッド

X

連絡先

X

X

削除済みメッセージ

X

X

送信した連絡先

X

受信トレイ

X

X

送信済み

X

X

送信済みメッセージ

X

X

タスク

X

すべてのメールボックス内容をzipファイルに含む場合、以下のようにメタデータを有効化する必要があります。

zmmailbox -z -m アカウント@ドメイン gru "?fmt=zip&meta=1" > <ファイル名.zip>

zmtlsctl

ウェブサーバーの zimbraMailMode をHTTP、HTTPS、Mixed、Both、またはRedirectのコミュニケーションのプロトコルへ設定するコマンドです。 デフォルトの設定はHTTPSです。

zmtlsctl の設定がZCOの セキュア接続設定 へも影響します。自己証明の環境にあるZCOユーザーについて、クライアントのWindows証明書ストアへルートCAの証明書を追加しないと警告メッセージが表示されます。Zimbraの ZCO Connection Security Wiki記事を参照してください。
  • HTTP : HTTPのみアクセス可能。例えば http://zimbra.domain.com

  • HTTPS : HTTPS のみアクセス可能(デフォルト)。例えば https://zimbra.domain.com であり、 http:// への接続は拒否されます。

  • Mixed(混合) : ユーザーがhttp://へ接続した際、ログインのみがhttps://へ切り替え、通常のセッションはhttp://へ戻されます。ユーザーがhttps://へ接続した際、https://から切り替わることはありません。

  • Both(両方) : ユーザーはhttp://、またはhttps://をどちらへもアクセス可能であり、セッションで最初にアクセスしたモードからは切り替わりません。

  • Redirect(リダイレクト) : ユーザーがhttp://へ接続した際、Mixedモードと同様にhttps://へ切り替わりますが、セッションが継続されている間はhttps://のままです。

すべてのモードではバックエンドの管理トラフィックにSSLの暗号化を使用しています。

HTTP/ポート80にリスナーが存在しないこと、HTTPでクライアントのアプリケーションが認証されないことおよびクライアントのアプリケーションと交換するデータが暗号化されること、については zimbraMailModeHTTPS の場合のみ可能です。

モードの変更を適用するためには、Mailboxd の停止と再起動が必要です。

HTTPSへスイッチする場合は、ZCSのインストール中に/opt/zimbra/ssl/zimbra/server/server.crt で生成された自己署名済み証明書を使用します。ZCOユーザーの場合、CAの証明書をサーバーへ配備していないと、セキュアZCOのプロファイルが証明書信用ダイアログを表示します。詳細についてはZimbraの ZCO Connection Security Wiki記事を参照してください。
構文
zmtlsctl [モード]

モード = http, https, mixed, both, redirect

実行する手順
  1. zmtlsctl [モード] を入力し、キーボードの ENTER キーを押します。

  2. zmmailboxdctl stop を入力し、キーボードの ENTER キーを押します。

  3. mailboxdの停止が完了しましたら、 zmmailboxdctl start を入力し、 ENTER キーを押します。

リダイレクト使用の制限について
  • 多くのクライアントアプリは、サーバーへの最初のHTTPリクエストに認証のリクエストも送信します(「ブラインド認証」)。つまり、クライアントのアプリケーションをHTTPSへ転送される前に、この認証のリクエストがわかりやすい/暗号化されていない状態で送信されてしまいます。

  • Redirectモードは、man-in-the-middleの攻撃や、意図的、非意図的に無効なサーバーへのリダイレクトを起こす可能性があります。あるいは、ユーザーがサーバー名を間違えて入力した場合に、そのサーバーに対して証明書ベースでの確認が行えない場合があります。

  • 多くのクライアントのアプリケーションではユーザーがリダイレクトされたかどうかを認識できない場合があります(例えば、ActiveSync)。そのため、認証のリクエストが暗号化されていない場合でも、ユーザーはHTTPを使用し続けることになります。

zmhsm

HSMセッションの起動、停止(アボート)およびステータスを確認できるコマンドです。メッセージがストレージボリュームへ移動されるしきい値は管理コンソールの サーバー > ボリューム ページから設定します。

構文
zmhsm {abort|start|status} {サーバー} <名前>
説明
正式名 略式名 説明

--abort

-a

現在のHSMセッションを強制的に停止します。処理中のメールボックスのメッセージが アボート を実行前に移動されていなかった場合、そのメールボックスのメッセージはプライマリボリュームから移動されません。セカンダリーボリュームへ移動されたメッセージがプライマリボリュームへ戻されることはありません。

--help

-h

ツールで使用できるオプションのヘルプを表示します。

--server

-s

<値> メールサーバーのホスト名。デフォルトは [値]

--start

-t

HSMプロセスをマニュアル操作で起動します。

--status

-u

前回のHSMセッションのステータスを表示します。

zmlicense

zmlicense ライセンスの確認とインストールを行なうコマンドです。また、管理コンソールの グローバル設定 > ライセンス のページから、ライセンスの確認とインストールを行なうことができます。

構文
zmlicense [オプション]
説明
正式名 略式名 説明

--check

-c

有効なライセンスがインストールされているか確認します。

--help

-h

ツールで使用できるオプションのヘルプを表示します。

--install

-i

<値> 指定したライセンスファイルをインストールします。

--ldap

-l

LDAPサーバーのみにインストールします。

--print

-p

ライセンス情報を表示します。

zmmetadump

アイテムのメタデータを人が読めるような内容へダンプするサポートツールです。

構文
zmmetadump -m <メールボックスID/メールアドレス> -i <アイテムID>

または

zmmetadump -f <暗号化したメタデータが含まれているファイル>

zmmypasswd

zimbra_mysql_password を変更するコマンドです。 --root のオプションを使用した場合、mysql_root_passwd が変更されます。両方のユースケースでは新しいパスワードにてMariaDBを更新します。ルートのパスワードをオーバーライドするため権限テーブルを一時的にスキップしてMariaDBサーバーを開始する方法の詳細についてはMariaDBのドキュメントを参照してください。

変更の適用には、再起動が必要です。
構文
zmmypasswd [--root] <新しいパスワード>

zmplayredo

バックアップと復元の運用としてストレージレイヤのスナップショット機能を使用している場合、このコマンドでバックアップデータを復元できます。バックアップしたデータが現在の状態まで復元されるため、復元のプロセス中のデータ損失を防ぐことができます。

構文
zmplayredo <オプション>
説明
正式名 略式名 説明

--fromSeq

<値> 指定したRedoログのシーケンスからスナップショットを再適用します。

--fromTime

<値> 指定した時間からスナップショットを適用します。

--help

-h

コマンドのヘルプ情報を表示します。

--logfiles

<値> 指定したログファイルを順番に再実行します。

--mailboxId

<値> 指定したメールボックスにスナップショットを適用します。

--queueCapacity

<値> 各再実行スレッドのキューの許容量に制限を指定します。デフォルトは100です。

--stopOnError

エラーが発生した際、適用を停止します。

--threads

<値> 平行のRedoスレッドを指定します。デフォルトは50です。

--toSeq

<値> 指定したRedoログシーケンスまでスナップショットを再適用します。

--toTime

<値> 指定した時間までスナップショットを適用します。

時間はローカルのタイムゾーンで指定します。年、月、日、時、分、秒、そしてオプションのミリ秒を指定します。月/日/時/分/秒について、0を加えて2桁の数字で指定し、ミリ秒は3桁の数字で指定します。時は24時間形式を使用します。

zmproxyconfgen

nginxのプロキシ設定ファイルを生成する。LDAPの設定を読み込み、テンプレートの変数を上書きし、最終のnginx設定を生成します。

構文
ProxyConfGen [オプション]
説明
正式名 略式名 説明

--config

-c

<値> 設定の値をオーバーライドします。 <値>名称=値 です。有効な属性名を確認するには -d-D を使用します。

--defaults

-d

デフォルトの変数マップを返します。

--definitions

-D

LDAPの情報を読み込み、オーバーライドを適用した属性値のマップを返します。

--help

-h

ヘルプの情報を表示します。

--include-dir

-i

<値> 設定ファイルが書き込まれるディレクトリのパス($workdir/conf に関連)を返します。

--dry-run

-n

設定を書き込ませず、実行した場合に書き込むファイルを返します。

--prefix

-p

<値> 設定ファイルのプレフィックスを返します。デフォルトは nginx.conf です。

--template-prefix

-P

<値> テンプレートファイルのプレフィックスを返します。デフォルトは $prefix です。

--server

-s

<値> 有効なサーバーオブジェクトを指定します。指定したサーバーの属性をベースとした設定が生成されます。デフォルトではグローバル設定の値に基づき、設定が生成されます。

--templatedir

-t

<値> プロキシのテンプレートディレクトリを指定する。デフォルトは $workdir/conf/nginx/templates です。

--verbose

-v

詳細なデータを返します。

--workdir

-w

<値> プロキシのワークディレクトリを指定します。デフォルトは /opt/zimbra です。

zmproxypurge

1つか複数のmemcachedサーバーからPOP/IMAPのプロキシルート情報をパージします。使用可能のmemcachedサーバーは zmprov gamcs オプションで出力されます。必要に応じてサーバーのポートを指定することもできます。

構文
ProxyPurgeUtil [-v] [-i] -a アカウント [-L アカウントのリスト] [キャッシュ1] [キャッシュ2]...]
説明
正式名 略式名 説明

--help

-h

このツールで使用できるオプションのヘルプを示します。

--verbose

-v

詳細なデータを表示します。

--info

-i

アカウントのルート情報を表示します。

--account

-a

アカウント名を表示します。

--list

-L

アカウントのリストを含むファイルを表示します。1行につき1アカウント。

--output

-o

詳細ルート情報で返すフォーマットを指定します。デフォルトで以下の情報が表示します。

  • キャッシュサーバー

  • アカウント名

  • ルート情報

cacheN

(オプションのコマンド) サーバー:ポートの形式で、他のmemcacheサーバーを指定します。

zmredodump

デバッグ用に使用されるこのコマンドは、Redoログファイルの内容をダンプします。ユーザーが問題をデバッグしている際、特定のオプションと共に zmredodump を実行するように、Zimbraサポートから要請されることもあります。

すべてのRedoログファイルで複数ログファイル/ディレクトリを指定することが可能であり、各ディレクトリのRedoログは昇順にソートされ、処理されます。

構文
zmredodump [オプション] <redolog ファイル/ディレクトリ> [...]
説明
正式名 略式名 説明

--help

-h

ヘルプメッセージを表示します。

-m

カンマまたは空スペース区切りでメールボックスのIDを指定します。空スペースを区切りとしている場合、すべてのメールボックスIDのリストをクォーテーションで囲む必要があります。

すべてのRedoログファイルの内容をダンプする場合、このオプションを使用しないでください。

--no-offset

各Redoログダンプにファイルのオフセットとサイズを表示しない場合に指定します。

--quiet

-q

クワイエットモードを有効にします。ログのファイル名とエラーのみを返したい場合に使用する。最小限の出力内容でRedoログの整合性を確認するために使用します。

--show-blob

ブロブの内容を表示します。指定したアイテムのブロブの開始は <START OF BLOB> と終了は <END OF BLOB> で示します。

zmskindeploy

簡単にZWCへスキンを配備するコマンドです。このツールにより、スキンの配備の処理、すべてのZWCユーザーへのスキン有効化、そして、新しいスキン使用のためのサーバー再起動を行ないます。

構文
zmskindeploy <スキンのディレクトリ、またはzipファイルへのパス>

zmsoap

メール、アカウントおよび管理情報をSOAPのフォーマットで返します。

構文
zmsoap [オプション] {path1} [path2]...
説明
正式名 略式名 説明

--help

-h

使用方法の情報を返します。

--mailbox

-m

<アカウント名> メールボックスのアカウント名をします。メールとアカウントのリクエストはこのアカウントへ送信されます。-a-z を指定していない場合、この属性値は認証にも使用されます。

--target

<アカウント名> リクエストが送信されるターゲットのアカウントをします。非管理者のセッションのみに使用します。

--admin name

-a

<アカウント名> 認証する管理アカウント名をします。

--zadmin

-z

認証するZimbra管理者名とパスワードをします。

--password

-p

<パスワード> アカウントのパスワードをします。

--passfile

-P

<パスワード> ファイルからパスワードを読み込みます。

--element

-e

<パスワード> ルートのエレメントパスをします。指定した場合、スラッシュ(/) で始まらないパス値はこのエレメントに関連します。

--type

-t

<種類> SOAPのリクエスト種類をします。 mail, account, または admin を返します。

--url

-u

<http[s]://…​> サーバーのホスト名とオプションのポート値をします。

--verbose

-v

SOAPリクエストと他のステータス情報をします。

path

<[パス]…​> エレメントまたは属性パスと値を表示します。おおまかには次のXPathの構文に従います。 [/]エレメント1[/エレメント2][/@属性][=値]

zmstat-chart

CPU、IO、mailboxd、MTAキュー、MariaDBの統計情報を収集し、csvデータファイルに対し、スクリプトを実行し、その利用詳細をさまざまなチャートにて表示します。CSVファイルは /opt/zimbra/zmstat/ に保存されます。 パフォーマンスチャートのデータを収集するため、zmstatを有効化する必要があります。

パフォーマンスチャート用データの収集のため、zmstatを有効化する方法

  1. 以下のコマンドを実行します。 zmprov ms {ホスト名} zimbraServerEnable stats

  2. 以下のコマンドでサーバーを再起動します。

    zmcontrol stop
    zmcontrol start
構文
zmstat-chart -s <値> -d <値> [オプション]
説明
正式名 略式名 説明

--aggregate-end-at

<値> 指定した場合、総計の計算は指定したタイムスタンプで終了します。フォーマットは MM/dd/yyyy HH:mm:ss

--aggregate-start-at

<値> 指定した場合、総計の計算は指定したタイムスタンプから開始します。フォーマットは MM/dd/yyyy HH:mm:ss

--end-at

<値> 指定した場合、指定したタイムスタンプの後のサンプルは無視されます。フォーマットは MM/dd/yyyy HH:mm:ss

--start-at

<値> 指定した場合、指定したタイムスタンプの前のサンプルは無視されます。

--title

<値> チャートに表示するタイトルを指定します。デフォルトはsrcdirの最終ディレクトリ名です。

--no-summary

要約のデータ生成が含まれません。

--conf

-c

<値> 設定XMLファイルを使用しチャートを生成します。

--destdir

-d

<値> 生成したチャートファイルの保存先。

--srcdir

csvファイルが存在するディレクトリ(複数可能)を指定します。CSVファイルは zmstat/ の下の日付ごとのディレクトリへ移動します。

zmstat-chart-config

LDAPノード、実行しているプロセスなどサーバー設定を考慮して、テンプレートから /opt/zimbra/conf/zmstat-chart.xml を生成します。

zmstatctl

zmstat のデータ収集プロセスの管理スクリプトです。監視プロセスの開始と停止、ステータスの確認やログのローテーションを実行します。

構文
zmstatctl start|stop|status|rotate

zmthrdump

ZCS サーバープロセスにスレッドダンプを実行し、アウトプットファイルを返します。また、スレッドダンプをファイルに保存したり、ログファイルにタイムスタンプを追加するオプションもあります。

構文
zmthrdump [-h] [-i] [-t <タイムアウトの秒間>] [-p <pidのファイル>] [-f <ファイル>] [-o <アウトプットファイル>]
説明
略式名 説明

-h

ヘルプメッセージを表示します。

-i

LOGFILEにSIGQUITを実行する前にタイムスタンプを追加します。

-p

SIGQUITを送信するためにPIDファイルを指定します。デフォルト値は zmmailboxd_java.pid です。

-f

スレッドダンプのアウトプットを保存するLOGFILEを指定します。デフォルトは zmmailbox.out です。

-o

スレッドダンプのアウトプットファイルを指定します。デフォルトはstdoutです。

-t

プロセスが無反応の状態になった場合に停止するまでのタイムアウト(秒間)値を指定します。デフォルトは30秒です。

zmtrainsa

迷惑メール対策のフィルターを学習させるためのコマンドです。このコマンドは自動的に毎晩実行され、ユーザーがメールボックス内で迷惑または迷惑ではないとしてフラグしたメッセージをSpamAssassinのフィルターに学習させます。SpamAssassinの SpamAssassin’s sa-update toolはSpamAssassinに含まれています。このツールはSpamAssassin社のSpamAssassinによるルールをアップデートします。ツールは /opt/zimbra/common/bin にインストールされます。

zmtrainsa のコマンドはマニュアル操作でユーザーのフォルダを迷惑メールのトレーニング用メールボックスへ転送することができます。あるアカウントに対してマニュアル操作で zmtrainsa を実行した場合、迷惑メール(spam)のデフォルトフォルダはJunkです。迷惑メールではない(ham)のデフォルトフォルダは受信トレイです。

構文
zmtrainsa <ユーザー> <spam|ham> [フォルダ名]

zmtzupdate

特定のユーザー、または全ユーザーに既存の予定のタイムゾーンの変更をアップデートします。このコマンドを実行するためには、.icsのルールファイルを事前に作成する必要があります。ルールファイルには、タイムゾーンと変更するタイムゾーンを一致させる定義のルールが一通り含まれています。このコマンドに関する詳細な情報は以下のWikiページを参照してください。 https://wiki.zimbra.com/wiki/Changing_ZCS_Time_Zones

構文
zmtzupdate --rulefile <ルールファイル> -a <"all" または特定のメールアドレスのリスト> [--sync] [--after <タイムスタンプ>]
説明
正式名* 略式名 説明

--account

-a

<値> 空スペースで区切ったアカウントのメールアドレスリストです。"all"を使用するとすべてのアカウントを更新します。

--after

<値> この項目に指定した日時以降の予定を更新します。デフォルトのカットオフ時間は2008 年1月1日です。

--help

-h

ヘルプ情報を表示します。

--rulefile

タイムゾーン定義を更新する.ics XMLファイルを指定します。

--server

-s

<値> メールサーバーのホスト名を指定します。デフォルトはlocalhostです。

--sync

指定した場合、サーバーが依頼したアカウントの処理がすべて完了するまで zmtzupdate のコマンドがブロックします。デフォルト値はnoです。

zmvolume

CLIからストレージのボリュームを管理するコマンドです。ボリュームは管理コンソールの サーバー > ボリューム ページより簡単に管理できます。

構文
zmvolume {-a|-d|-l|-e|-dc|-sc} [オプション]
説明
正式名 略式名 説明

--add

-a

ボリュームを追加します。

--compress

-c

<値> BLOBを圧縮します。 "true" または "false"。

--compressionThreshold

-ct

圧縮のしきい値。 デフォルトは4KB。

--delete

-d

ボリュームを削除します。

--displayCurrent

-dc

現在のボリュームを表示します。

--edit

-e

ボリュームを編集します。

--help

-h

このツールで使用できるオプションのヘルプを示します。

--id

-id

<値> ボリュームID。

--list

-l

ボリュームをリストアップします。

--name

-n

<値> ボリューム名。

--path

-p

<値> ルートパス。

--server

-s

<値> メールサーバーのホスト名。 デフォルトはlocalhost。

--setCurrent

-sc

現在のボリュームを設定します。

--type

-t

<値> ボリューム種類 (primaryMessage, secondaryMessage, または index)。

--turnOffSecondary

-ts

セカンダリーメッセージボリュームを無効化します。

zmzimletctl

Zimletの管理やサーバーにあるZimletをすべてリストアップするコマンドです。詳細については Zimletsを参照してください。ほとんどのZimletの配備はZimbraの管理コンソールから処理できます。

構文
zmzimletctl [-l] {コマンド} [<zimlet.zip>|<config.xml>|<zimlet>]
説明
正式名 説明

deploy

<zimlet.zip> LDAPサーバーにZimletのエントリを作成し、サーバーにZimletファイルをインストールし、デフォルトの提供サービスへアクセス許可を与え、Zimletを有効にします。

undeploy

<zimlet> ZimbraサーバーからZimletをアンインストールします。

install

<zimlet.zip> ホストにZimletファイルをインストールします。

ldapDeploy

<zimlet> ZimletエントリをLDAPへ追加します。

enable

<zimlet> Zimletを有効化します。

disable

<zimlet> Zimletを無効化します。

acl

<zimlet> <提供サービス1> {grant | deny} | [<提供サービス2> {grant|deny}…​]

提供サービスへgrant|denyのアクセス許可を与えます。

listAcls

<zimlet名> ZimletのACLをリストします。

listZimlets

サーバーにあるすべてのZimletの詳細をリストアップします。

getConfigTemplate

<zimlet.zip> Zimlet.zipファイルから設定のテンプレートを取得します。

configure

<config.xml> 設定をインストールします。

listPriority

現在のZimlet優先度を表示します(0は高い、9は低い)。

setPriority

<zimlet> Zimletの優先度を設定します。

zmproxyconfig

Zimbraプロキシを管理できるコマンド。Zimbraプロキシをインストール後に設定を変更する必要がある場合にのみ、使用するようにしてください。詳細については Zimbra Proxy Serverを参照してください。

ZCS 6.0まではこのコマンドは zmproxyinit と呼ばれていました。
構文
/opt/zimbra/libexec/zmproxyconfig [-h] [-o] [-m] [-w] [-d [-r] [-s] [-a w1:w2:w3:w4] [-i p1:p2:p3:p4] [-p p1:p2:p3:p4] [-x メールモード]] [-e [-a w1:w2:w3:w4] [-i p1:p2:p3:p4] [-p p1:p2:p3:p4] [-x メールモード]] [-f] -H ホスト名
説明
略式名 説明

-h

ヘルプメッセージを表示します。

-H

プロキシを有効/無効にするサーバーのホスト名。

-a

使用するウェブポートのコロン区切りリスト。フォーマット: HTTP-STORE:HTTP-PROXY:HTTPS-STORE:HTTPS-PROXY (例: 8080:80:8443:443)

-d

プロキシを無効化します。

-e

プロキシを有効化します。

-f

memcachedポート、検索クエリおよびPOP/IMAPスロットリングの完全リセット。

-i

使用するIMAPポートのコロン区切りリスト。フォーマット: IMAP-STORE:IMAP-PROXY:IMAPS-STORE:IMAPS-PROXY (例: 7143:143:7993:993)

-m

メールプロキシの部分を切り替えます。

-o

有効化されているチェックをオーバーライドします。

-p

使用するPOPポートのコロン区切りリスト。フォーマット: POP-STORE:POP-PROXY:POPS-STORE:POPS-PROXY (例: 7110:110:7995:995)

-r

リモートホストへ実行します。サーバーがLDAPマスターで正常に設定している必要があります。

-s

無効にした際、CleartextをFALSE (セキュアモード) に設定します。

-t

ストアサーバーに対して、リバースプロキシ検索のターゲットを無効化します。-d が存在する場合のみ有効なオプションです。サーバーのプロキシ機能がすべて停止することを目的としている前提であるかどうかを確認してください。

-w

ウェブプロキシの部分を切り替えます。

-x

無効にした際に使用する zimbraMailMode (デフォルトはHTTP)。

hostname は編集するサーバーの zimbra_server_hostname LC key 値です。

必要なオプションは -f のみ、または -f-d-e です。

以下に注意してください

  • -d-e には -m-w のいずれかまたは両方が必要

  • -i または -p には -m が必要

  • -a には -w が必要

  • ストアの場合 -x-w-d が必要

  • プロキシの場合 -x-w が必要

オプションとして指定していない場合、 -a, -i, -p, -x のデフォルト値は以下となります。

-a

有効な場合のデフォルト: 8080:80:8443:443

無効な場合のデフォルト: 80:0:443:0

-i

有効な場合のデフォルト: 7143:143:7993:993

無効な場合のデフォルト: 143:7143:993:7993

-p

有効な場合のデフォルト: 7110:110:7995:995

無効な場合のデフォルト: 110:7110:995:7995

-x

ストアが無効な場合のデフォルト: http

プロキシが有効/無効な場合のデフォルト: http

zmsyncreverseproxy

zmsyncreverseproxyのコマンドでプロキシのモバイルシンクHTTP通信用のソースと転送サーバー&ポートを予約します。詳細モードが有効な場合、同期のリクエストと返答をデコードし、ログへ記録します。

構文
zmsyncreverseproxy [-v] [-d] [-L log4j.properties] -p <ポート番号> -fs <転送サーバー> -fp <転送ポート> [-sv 同期バージョン]
説明
正式名 Short 説明

--help

-h

ヘルプ内容を表示します。

--verbose

-v

詳細モード、完全な例外スタックトレースをダンプします。

--debug

-d

デバッグモード、デコードされた同期メッセージをダンプします。

--port

-p

サービスが監視するポート。

--forwardserver

-fs

リクエストの転送先サーバー。

--forwardport

-fp

リクエストの転送先サーバーのポート番号。

--syncversions

-sv

サポートしているActive Syncバージョン。

--logpropertyfile

-L

log4j のプロパティファイル、-lでの使用のみ有効です。

Appendix B: SPNEGOのシングルサインオンの設定方法

SPNEGOプロトコルをZCS に設定することで、Zimbraウェブクライアント (ZWC) 、またはOutlook用のZimbraコネクター (ZCO) でのシングルサインオン認証が利用できます。ZCOの設定方法については ZCOにシングルサインオンのオプションを設定する を参照ください。

ZWCからユーザーがActive Directory経由でイントラネットへログインした際、Zimbraへの再認証なしでZWCのメールボックスへアクセスできます。

ZCS サーバーを、ZWCへログインするユーザーをSPNEGO保護の下、URLへリダイレクトするように設定します。SPNEGO経由でサーバーがKerberosの認証を依頼し、ユーザーがZWCのメールボックスへリダイレクトされます。ユーザーがログアウトした場合、起動ボタンを表示するURLへリダイレクトされます。起動 のボタンをクリックしますとZWCのログイン画面へ転送されます。

インターネット上でユーザーがZWCアカウントへログインするとZWCのログインページが表示されるため、ユーザーはログインするためにZWCのパスワードを入力する必要があります。
SPNEGO SSOがドメインにて有効な場合、ブラウザを正常に設定する必要があります。 ブラウザを設定する を参照ください。正常に設定していないブラウザの場合はユーザー/パスワードの画面が表示されます。そして、ユーザーが正しいADのドメインユーザー名とパスワードを入力するとZimbraメールボックスへ正常に移動するか「401 Unauthorized」のエラーが表示されます。

設定方法

  1. KerberosのKeytabファイルを作成します。

    • Active Directoryのサービスアカウントを作成します。このアカウントはKerberosのKeytabファイルを発行するために使用します。

    • Active DirectoryサービスアカウントにサービスのPrincipal Names (SPN)ディレクトリ属性のサービスを追加します。

    • Keytabファイルを作成します。

  2. ZCS サーバーにSPNEGOプロトコルを設定・有効化します。

  3. ブラウザを設定します。

KerberosのKeytabファイルを作成する

ZCS メールストアのサーバーごとに、Active Directoryサービスアカウントがドメイン内に作成されます。

  1. Active Directoryのサービスアカウントを作成します。このアカウントはZimbraサーバーへ追加されるKerberosのKeytabファイルを生成するために使用します。

    1. Active Directoryに遷移し、 スタート > プログラム > 管理ツール > Active Directoryユーザーとコンピュータ のコンソールを起動します。

    2. サービスアカウントを作成するため、ADのドメイン名をクリックし、展開した内容から ユーザー を右クリックし、新規 > ユーザー をクリックします。新しいオブジェクト - ユーザーの画面になります。

      • 名前: ACサービスアカウントのユーザー表示名を入力します。 この名前に ZCS メールボックスサーバー名を使用することを推奨しています。 例: mail1

      • ユーザーログイン名: LDAP の zimbraSpnegoAuthTargetName サーバー属性に設定する名前です。記載してください。例: HTTP/mail1.example.com

      • ユーザーログイン名 (Windows2000以前): setspnktpass コマンドにある -mapUser 属性に使用します。
        Example: mail1

      • 次へ をクリックします。

    3. パスワードを入力・確認します。このパスワードは以下に設定する ktpass コマンドの -pass {AD-user-password} パラメーターに使用します。

    4. パスワードの有効期限がないパスワード変更ができません のオプションを有効にし、次へ をクリックします。

    5. 完了 をクリックし、ユーザーを作成します。サービスアカウント名がユーザーのディレクトリに表示されます。

  2. setspn のコマンドで、サービスのPrincipal Names (SPN)としてメールボックスのサーバー名をユーザーアカウントにマッピングします。SPNはクライアントとサーバーに存在する特定のサービスの間での、相互認証プロセスに使用します。

    1. コマンドプロンプトから以下を実行します。 setspn -a {userlogonname} {serviceaccountname}

      Example 87. サービスのPrincipal Names (SPN)としてメールボックスのサーバー名をユーザーアカウントにマッピング
      setspn -a HTTP/mail1.example.com mail1
    2. SPNが登録されていることを認証するために以下を実行します。 C:\>setspn -l {accountname}
      登録されているSPNのリストが表示します。

  3. KerberosドメインにサインインするためのKeytabファイルを作成します。WindowsサーバーツールキットのKtpassツールを使用して、Kerberos keytabを作成します。

    KerberosのKeytabファイルには、ユーザーパスワードに類似しているキーのリストが含まれています。作成したKeytabファイルに対するアクセス制限や監視制限を行なってください。

    作成するには以下のコマンドを使用します。

    ktpass -out {keytab-file-to-produce} -princ {Service-Principal-Name}@\{the-kerberos-realm} -mapUser {AD-user} -mapOp set -pass {AD-user-password} -crypto RC4-HMAC-NT -pType KRB5_NT_PRINCIPAL

    ktpass -out

    キーがこのアウトプットファイルへ書き込まれます。 ディレクトリの場所とKeytabファイル名を入力します。Keytabファイル名は jetty.keytab
    例: C:\Temp\spengo\jetty.keytab

    -princ

    これはプリンシパル名です。
    Microsoft Windows Active Directory ドメインコントローラ設定の 手順2 に使用したプリンシパル名を入力します。
    例: HTTP/mail1.example.com@COMPANY.COM

    -mapUser

    ユーザーアカウントに -princ の値をマッピングします。 Microsoft Windows Active Directory ドメインコントローラ設定の 手順1b で設定した ユーザーログイン名 (Windows2000以前) のADサービスアカウントのユーザー名を入力します。

    -mapOp

    マッピングを設定します。このパラメーターの値は set です。

    -pass

    使用するパスワードです。

    Microsoft Windows Active Directory ドメインコントローラ設定の 手順1c で設定した ユーザーログイン名 (Windows2000以前) のパスワードを入力します。

    -crypto

    使用する暗号化システムです。
    RC4-HMAC-NT を入力します。

    -pType

    KRB5_NT_PRINCIPAL を入力します。
    ツールキットから警告メッセージを避けるために上記の値を使用します。

    Example 88. jetty.keytabファイル作成のため ktpass を使用する。
    ktpass -out C: \Temp\spengo\jetty.keytab -princ HTTP/mail1.example.com@COMPANY.COM -mapUser mail1 -mapOp set - pass password123 -crypto RC4-HMAC-NT -pType KRB5_NT_PRINCIPAL

    以下のような例でコマンドを確認できます。

    Targeting domain controller: …
    
        Using legacy password setting method
        Successfully mappeped HTTP/mail1.example.com to mail1.
        Key created.
        Output keytab to c:\Temp\spengo\jetty.keytab:
        Keytab version: 0x502
    
        keysize 71 HTTP HTTP/mail1.example.com@COMPANY.COM ptype 1 (KRB5_NT_PRINCIPAL) vno3 etype 0x17 (RC4-HMAC) keylength 16 (0xc383f6a25f1e195d5aef495c980c2bfe)
  4. ZimbraサーバーへKeytabファイル (jetty.keytab) を転送します。手順3で作成したファイルを以下のZimbraサーバーのディレクトリへコピーします。 /opt/zimbra/data/mailboxd/spnego/jetty.keytab

jetty.keytab のファイル名を変更しないでください。数多くの設定ファイルがこのファイル名を使用しています。

手順1-4を繰り返し、各ZimbraメールストアのサーバーにKeytabファイル (jetty.keytab) を作成します。

ZCSを設定する

各Zimbraサーバーやグローバル設定にSPNEGOの属性を設定し、ドメインのプリ認証を設定します。Zimbraサーバーを変更するにはzmprovのCLIを使用します。

ZCS 環境ごとに1つのKerberos REALMのみ、サポートされます。
  1. zmprov mcf のコマンドで以下のグローバル設定の属性を編集します。

    zimbraSpnegoAuthEnabled TRUEに設定します。

    zimbraSpnegoAuthErrorURL

    ユーザーがSPNEGOの認証に失敗した際にリダイレクトされるURLです。 /zimbra/?ignoreLoginURL=1 に設定しますと通常のZimbraログインページへリダイレクトするため、そこでユーザーはZimbraのユーザー名とパスワードを入力する必要があります。

    zimbraSpnegoAuthRealm

    ドメインコントローラにあるKerberos realmです。

    Active Directoryにあるドメイン名です。 (COMPANY.COM)

    グローバル設定の属性を変更するには以下のコマンドを実行します。

    1. zmprov mcf zimbraSpnegoAuthEnabled TRUE

    2. zmprov mcf zimbraSpnegoAuthErrorURL '/zimbra/?ignoreLoginURL=1'

    3. zmprov mcf zimbraSpnegoAuthRealm <COMPANY.COM>

  2. 各Zimbraサーバーにて、zmprov ms のコマンドで以下のグローバル設定を編集します。

    zimbraSpnegoAuthTargetName

    手順1bのユーザーログイン名です。

    zimbraSpnegoAuthPrincipal

    zimbraSpnegoAuthTargetName に設定したユーザーログイン名とグローバル設定の zimbraSpnegoAuthRealm に設定したアドレスを入力します。 + 形式: + zimbraSpnegoAuthTargetName@zimbraSpnegoAuthRealm

    例: HTTP/mail1.example.com@COMPANY.COM

    サーバーのグローバル設定の属性を編集するには以下のコマンドを実行します。

    1. zmprov ms mail1.example.com zimbraSpnegoAuthTargetName HTTP/mail1.example.com

    2. zmprov ms mail1.example.com zimbraSpnegoAuthPrincipal HTTP/mail1.example.com@COMPANY.COM

  3. ドメインに以下の内容が設定されます。

    • Kerberos Realm

    • 仮想ホスト

    • ウェブクライアントのログインURLとUA

    • ウェブクライアントのログアウトURLとUA

      1. ドメインにKerberos Realmを設定します。グローバル設定の属性 zimbraSpnegoAuthRealm に設定したRealmです。
        形式:

        zmprov md {domain} zimbraAuthKerberos5Realm {kerberosrealm}

      2. ドメインに仮想ホストを設定します。ZimbraウェブクライアントUIの閲覧に使用できるホスト名が、Virtual-hostname-* です。
        形式:

        zmprov md {domain} +zimbraVirtualHostname {virtual-hostname-1} +zimbraVirtualHostname {virtual-hostname-2}
        ...
      3. ドメインのログインURLとして許可するウェブクライアントURLとUAを設定します。

        • ログインURLを設定します。また、Zimbraの認証トークンの期限が切れた場合にユーザーがログインURLへリダイレクトされます。
          形式:

          zmprov md {domain} zimbraWebClientLoginURL '../service/spnego'

        • サポートしているプラットフォームとブラウザのみを有効にする。

          zimbraWebClientLoginURLAllowedUA はマルチバリューの属性で、値は、正規表現です。設定されていない場合、すべてのUAを許可します。複数の値が設定されている場合、UAが設定されている値のいずれかに一致している限り、アクセスが許可されます。

          zmprov md {domain} +zimbraWebClientLoginURLAllowedUA {UA-regex-1} +zimbraWebClientLoginURLAllowedUA {UA-regex-2} ...

          例えば、 Windows上のFirefox, Internet Explorer, Chrome,Safarと、Apple Mac上のSafariに zimbraWebClientLoginURL を 有効にする場合、以下のコマンドを実行します。

          zmprov md {domain} +zimbraWebClientLoginURLAllowedUA '._Windows._Firefox/3.*'
          zmprov md {domain} +zimbraWebClientLoginURLAllowedUA '._MSIE._Windows.*'
          zmprov md {domain} +zimbraWebClientLoginURLAllowedUA '._Windows._Chrome.*'
          zmprov md {domain} +zimbraWebClientLoginURLAllowedUA '._Windows._Safari.*'
          zmprov md {domain} +zimbraWebClientLoginURLAllowedUA '._Macintosh._Safari.*'
      4. ドメインのログアウトURLとして許可するウェブクライアントURLとUAを設定します。

        • ログアウトURLを設定します。ユーザーがログアウトのリンクをクリックした際にリダイレクトするURLです。

          zmprov md {domain} zimbraWebClientLogoutURL '../?sso=1'
        • サポートしているプラットフォームとブラウザのみを有効にする。 zimbraWebClientLogoutURLAllowedUA はマルチバリューの属性で、値は正規表現です。設定されていない場合、すべてのUAを許可します。複数の値が設定されている場合、UAが設定されている値のいずれかに一致している限り、アクセスが許可されます。

          zmprov md {domain} +zimbraWebClientLogoutURLAllowedUA {UA-regex-1} +zimbraWebClientLogoutURLAllowedUA {UA-regex-2} ...

          例えば、 Windows上のFirefox, Internet Explorer, Chrome,Safarと、Apple Mac上のSafariに zimbraWebClientLogoutURL を 有効にする場合、以下のコマンドを実行します。

          zmprov md {domain} +zimbraWebClientLogoutURLAllowedUA '._Windows._Firefox/3.*'
          zmprov md {domain} +zimbraWebClientLogoutURLAllowedUA '._MSIE._Windows.*'
          zmprov md {domain} +zimbraWebClientLogoutURLAllowedUA '._Windows._Chrome.*'
          zmprov md {domain} +zimbraWebClientLogoutURLAllowedUA '._Windows._Safari.*'

ブラウザを設定する

SPNEGO SSO機能がドメインで有効な場合、ユーザーのブラウザを正常に設定する必要があります。正常に設定されていないとブラウザによっては、実際の動作が変化する原因になります。

以下のブラウザをサポートしています。

  • Windows のコンピュータの場合:Internet Explorer 10.0 以降、Edge、Firefox 52 以降、Chrome, Safari

  • Apple Mac のコンピュータ: Safari

    1. WindowsでのFirefoxの設定について

      1. Firefoxのアドレスバーに about:config を入力しアクセスします。 警告 — 動作保証対象外になります! が表示されます。

      2. 細心の注意を払って使用する のボタンをクリックします。

      3. 検索ボックスに network.n を入力します。URLを信頼済みドメインやURLをカンマ区切りのリストで入力します。

        network.negotiate-auth.delegation-uris をダブルクリックし、 http://,https:// を追加します。

        network.negotiate-auth.trusted-uris をダブルクリックし、 http://,https:// を追加します。

        または、特定のURLを設定する場合

        network.negotiate-auth.delegation-uris をダブルクリックし、URLを追加します。 例えば: http://mail1.example.com,https:// mail2.example.com

        network.negotiate-auth.trusted-uris をダブルクリックし、URLを追加します。例えば: http://mail1.example.com,https:// mail2.example.com

    2. WindowsにInternet Explorer, Chrome, およびSafariの設定について

      1. これらのブラウザは ツール > インターネットオプション > セキュリティ > ローカルイントラネット >サイト をアクセスします。サイトの画面にすべての属性にチェックが入れていることを確認します。

      2. 詳細設定 をクリックします。 http:// および https:// のドメインサーバー (ホスト名) URLを追加します。

      3. OK をクリックし、ファイルをクローズします。

      4. ツール > インターネットオプション > 詳細設定 > セキュリティ をアクセスします。 統合Windows認証を使用する にチェックを入れます。

      5. OK をクリックし、ブラウザを閉じます。

    3. MacのSafariについて、特定の設定は必要ありません。

環境をテストする

  1. Windows、またはApple Macのコンピュータでドメインユーザーとしてコンピュータへログオンします。

    ドメインユーザーのチケットがコンピュータに保存されます。SPNEGO対応のブラウザがトークンを取得し、認証のヘッダー内にてZimbraサーバーへ送信します。

  2. Zimbraウェブクライアントのログインページへアクセスします。ユーザー名とパスワードを入力せずにZWCの受信トレイが開くはずです。

    SPNEGO認証が失敗した場合、ユーザーがエラーのURLへリダイレクトされます。

トラブルシューティングのセットアップ

以下の条件を満たすことを確認します。

  • ブラウザはイントラネットのゾーン内にある。

  • ユーザーがサーバーをIPアドレスではなく、ホスト名でアクセスしている。

  • Internet Explorer内の「統合Windows認証を使用する」のオプションが有効であり、Firefox内でホストが信頼済みとして設定されている。

  • サーバーが特定のブラウザに依存しない。

  • クライアントのKerberosシステムはドメインコントローラに認証されている。

  • ブラウザが「401 Unauthorized」のエラーを表示する場合、ブラウザが401に応答する認証のリクエストを正常に送信していないか、GSS-API/SPNEGOスキーマを使用していない認証を送信したと考えられます。

    ブラウザの設定を確認し、サポートされているブラウザ、またはプラットフォームであるようにしてください。

  • zimbraSpnegoAuthErrorURL で指定されたエラーURLへリダイレクトされた場合、SPNEGOの認証シーケンスが正常に機能していないということです。

    ネットワークのトレースを取得し、ブラウザが401に応答する認証ヘッダーを送信していることを確認します。また、NegotiateがNTLMではなく、GSS-API/SPNEGOを使っていることを確認します (Wiresharkのようなネットワークパケット解読プログラムを使用してください) 。

    ブラウザが正しいNegotiateを送信していることを確認した上で正常に機能しない場合、以下のデバッグ情報を有効化し、Zimbraのログを確認します。

    • localconfigキーの spnego_java_options に以下を追加します。

      “-DDEBUG=true -Dsun.security.spnego.debug=all”

    • log4j に以下を追加します。

      log4j.logger.org.mortbay.log=DEBUG

    この後、メールボックスサーバーを再起動します。

    デバッグのsnoop.jspにアクセス可能かどうかを確認します。 http://{server}:{port}/spnego/snoop.jsp

    デバッグの出力内容がzmmailboxd.outとmailbox.logに記録されます。

    • この時点で考えられる原因の1つがJettyサーバーのクロックずれです。この場合、zmmailboxd.out 内で確認できます。クロックのずれを修正し再度試してください。

Kerberos認証にSPNEGO認証を設定する

ドメイン上でKerberos認証とSPNEGOは共存できます。よくある事例として、ユーザーがSPNEGOで認証できない場合、元のZimbra LDAPへ認証せずにKerberosを使用してユーザーのプリンシパル/パスワードをKDCにて認証します。

SPNEGO認証が失敗した場合、ブラウザが正常に設定されているならZimbraのログインページへリダイレクトされます。ユーザーはZimbraのユーザー名とパスワードを入力して、マニュアル操作でログインすることができます。ドメイン属性の zimbraAuthMech がパスワード認証の方法を管理します。 zimbraAuthMech が「Kerberos5」に設定されている場合、ユーザーが入力するユーザー名は、有効なZimbraユーザーかどうかを識別するに使用されます。 (ユーザーはZimbra LDAPにプロビジョンされているはずであるため) その後、ZimbraからユーザーはKerberosプリンシパルへマッピングされ、Kerberosプリンシパル+パスワードがKDCにて認証されます。このKDCは、Active Directoryのドメインコントローラとして (SPNEGO認証用に) 実行しているKDCである場合も、そうでない場合もあります。

各Microsoft Active DirectoryのドメインコントローラはKerberos KDCとして動作します。SPNEGO認証の場合、KDCはメールボックスサーバーから依頼されません。JettyのKeytabファイルに沿い、認証のHttpヘッダーから送信されるKerberosトークンは、ユーザーを識別・認証することができます。

Kerberos認証の場合 (zimbraAuthMech*="kerberos5")、メールボックスサーバーがプリンシパル+パスワードを検証するためにKDCへ依頼する必要があります。JavaのKerberosクライアント (つまりZimbraメールボックスサーバー) の場合、デフォルトのRealmとそのRealm 用KDCは、Kerberosの設定ファイルに指定されています。この設定ファイルの場所はJVM引数 java.security.krb5.conf で指定されます。指定されていない場合、デフォルトの場所は /etc/krb5.conf となります。Zimbra内でSPNEGOを有効化した場合、メールボックスサーバーの java.security.krb5.conf/opt/zimbra/jetty/etc/krb5.ini に設定されます。このため、Kerberos認証の設定設定に有効なファイルです。

メールボックスサーバーが再起動するたび、 /opt/zimbra/jetty/etc/krb5.ini.in から /opt/zimbra/jetty/etc/krb5.ini は再度書き込みされます。そのため、設定を変更するには /opt/zimbra/jetty/etc/krb5.ini ではなく、 /opt/zimbra/jetty/etc/krb5.ini.in ファイルを編集する必要があります。

[realms] セクションにて、kdcとadmin_serverはSPNEGO認証用には設定されませんが、Kerberos認証で必要になります。

設定する場合

  1. /opt/zimbra/jetty/etc/krb5.ini.in を編集します。

  2. 既存の内容

[realms]
%%zimbraSpnegoAuthRealm%% = {
default_domain = %%zimbraSpnegoAuthRealm%%
}

上記を以下の内容にて上書きします。

%%zimbraSpnegoAuthRealm%% = {
             kdc = YOUR-KDC
             admin_server = YOUR-ADMIN-SERVER
             default_domain = %%zimbraSpnegoAuthRealm%%
}
  1. YOUR-KDCとYOUR-ADMIN-SERVERには、Kerberos認証が起動しているKDC/admin_serverのホスト名を入れてください。

  2. ファイルを保存し、メールボックスサーバーを再起動します。

絶対条件としてはSPNEGOとKerberos認証のRealmを一致させる必要があります。SPNEGO認証の場合、認証ヘッダーのKerberosプリンシパルは一意のZimbraアカウントにマッピングします。Kerberos認証の場合、Zimbraアカウントは一意のKerberosプリンシパルにマッピングします。(ドメイン属性の zimbraAuthKerberos5Realm により) このマッピングは双方で同じです。

ZCOにシングルサインオンのオプションを設定する

SSOのオプションを使用するには、SPNEGOをZCSサーバーに設定する必要があります。

シングルサインオンのオプションは特定のサーバーのみに使用できます。ZCOのプロファイル内で使用しているサーバー名がSPNEGOの設定と一致する必要があります。インストール前に、サーバー名が .msi ファイルへ組み込まれていることを確認してください。

シングルサインオンのオプションを .msi のカスタムスクリプトに設定する場合

  1. サーバー名にSPNEGOに設定するサーバー名を設定します。 -sn <spnegoserver.example.com>

  2. パスワードルールを設定します。 -pw 0

cscript ZmCustomizeMsi.js <path/msi-filename> -sn <spnegoserver.example.com> -pw 0

Appendix C: ZCS Crontab ジョブ

Crontabを使用して、Zimbraサーバーで定期実行するコマンドをスケジューリングします。

Crontabの読み方

rontabファイルの各エントリは6つの項目で構成されており、以下のように分、時、日、月、曜日、コマンドという順で指定します。

各項目は空のスペース、またはタブで区切ります。

項目 説明

0 から 59

0 から 23

1 から 31

1 から 12

曜日

0 から 7 (0 または 7 が日曜日、1は月曜日など、 または英語名)

コマンド

ジョブで実行する正確なコマンド文です。

アスタリスク (*) を使う場合、その項目で利用可能な全ての値という意味です。例えば、時の項目にアスタリスクを使った場合、「毎時」の意味になります。

ZCS Cron ジョブ

サーバーにZimbraユーザーでログオンし、crontab - l を実行するとZCSのcrontabを閲覧できます。

スケジューリングされたジョブ

ZCSには以下のcronジョブがスケジュールされています。

ログのプルーニング (剪定)

ログのプルーニングにて /opt/zimbra/log から8日間経過したログを削除します。このジョブは朝の2:30AMに実行されます。

ステータスのログ

zmstatuslogzmcontrol status を呼び出し、syslogにデータを出力します。

これは主にLoggerがデータを読み取り、管理コンソールのステータスを最新に更新するためです。ステータスログは2分ごとに実行されます。

バックアップ

完全と増分のバックアップは、 zmschedulebackup のコマンドで設定されたスケジュールどおりに実行されます。デフォルトの設定では完全バックアップは毎週土曜朝の1:00AMにスケジュールされています。増分のバックアップは日曜から金曜の朝1:00AMにスケジュールされています。

また、デフォルトでは、1か月経過したバックアップは毎月1日の12:00AMに削除されます。

crontab.store のジョブ

ログのプルーニング (剪定)

ログのプルーニングにて、 /opt/zimbra/mailboxd/logs から8日間経過したログを削除します。このジョブは朝の2:30AMに実行されます。

Quarantineディレクトリのクリーンアップ

ウイルスや迷惑メールとして識別されたメールは直ちに削除はされず、隔離されます。7日間経過したメッセージは毎朝1:00AMに削除されます。

テーブルのメンテナンス

データベース内の全テーブルに対して ANALYZE TABLE 文を実行し、すべてのインデックスの統計を更新します。これにより、SQLクエリオプティマイザがSQL文の実行時に適切なインデック取り出せるようにします。このスクリプトは日曜朝1:30AMに実行されます。

データベースの不整合を報告する

zmdbintegrityreport を毎週実行し、SQL のデータベースのデータ破壊をチェックします。破壊が確認されたら管理者へ通知します。この実行中は、I/O消費が膨大になる可能性があります。問題であると判断した場合は、ZCSのcrontabを編集して zmdbintegrityreport が起動する頻度を変更することもできます。このレポートは日曜日の23:00に実行されます。

大規模な環境の場合、以下のコマンドでこの機能を無効化できます。

zmlocalconfig -e zmdbintegrityreport_disabled=TRUE

無効化する場合、通常スケジュールのメンテナンス中やZCSのアップグレード実行前に、マニュアル操作にてこの統合レポートを実行することを推奨します。

データ破壊を防ぐために複数のmysqldを監視する

データ破壊が発生しうるケースを検出するためのmysqldプロセスが実行中かどうかを確認するスクリプトを実行します。1つ以上のmysqldプロセスが実行中である場合、通知メールが送信されます。このスクリプトは5分ごとに実行されます。

crontab.loggerのジョブ

ログの処理

zmlogprocess を10分間ごとに実行してログを確認させ、MTAのメトリクス (AS/AV、ボリューム、カウント、など) を生成させます。

日次レポート

logger のパッケージがインストールされるとcrontab内に日次メールレポートが自動的にスケジュールされます。レポートは毎朝11:30に実行され、管理者のメールアドレスに送信されます。

crontab.mtaのジョブ

キューのログ

Syslog経由で zmqueue のレポートステータスがレビューされます。これはLoggerのデータです。ステータスは10分ごとに更新されます。

迷惑メールのトレーニング

zmtrainsa のスクリプトを有効にして、迷惑メールと迷惑ではないメールとして分別されたメッセージをSpamAssassinアプリへ渡します。SpamAssassinは迷惑メールと迷惑ではないメールについての手がかりを学習します。このジョブは1つのZimbra MTAのみで実行する必要があります。ジョブは毎夜23:00に実行されます。

迷惑メールのトレーニングのクリーンアップ

zmtrainsa は毎日、迷惑メール用と迷惑ではないメール用のメールボックスをそれぞれ空にします。このジョブは23:45に実行されます。

迷惑Bayesの自動期限切れ

迷惑Bayesの自動期限切れにより、SpamAssassinのBayesデータベースを維持します。迷惑メールの処理時間が可能な限り迅速に行なわれるように、データベースのサイズを管理します。これは毎夜23:20に実行されます。

amavisd/tmpのクリーンアップ

このジョブでamavisdの一時ファイルをクリーンアップします。朝の5:15と夜の20:15に実行されます。

シングルサーバーのcrontab –l実例:

Example 89. crontab -l の出力内容
# ZIMBRASTART -- DO NOT EDIT ANYTHING BETWEEN THIS LINE AND ZIMBRAEND
#
# Log pruning
#
30 2 * * * find /opt/zimbra/log/ -type f -name *.log* -mtime +8 -exec rm {} \; > /dev/null 2>&1
35 2 * * * find /opt/zimbra/log/ -type f -name *.out.???????????? -mtime +8 -exec rm {} \; > /dev/null 2>&1
#
# Status logging
#
*/2 * * * * /opt/zimbra/libexec/zmstatuslog
#
# Backups
#
# BACKUP BEGIN
0 1 * * 6 /opt/zimbra/bin/zmbackup -f -a all
0 1 * * 0-5 /opt/zimbra/bin/zmbackup -i
0 0 * * * /opt/zimbra/bin/zmbackup -del 1m
# BACKUP END
#
# crontab.ldap
#
#
#
# crontab.store
#
# Log pruning
#
30 2 * * * find /opt/zimbra/mailboxd/logs/ -type f -name \*log\* -mtime +8 -exec rm {} \; > /dev/null 2>&1
30 2 * * * find /opt/zimbra/log/ -type f -name stacktrace.\* -mtime +8 -exec rm {} \; > /dev/null 2>&1
#
# Table maintenance
#
30 1 * * 7 /opt/zimbra/libexec/zmmaintaintables >> /dev/null 2>&1
#

# # Report on any database inconsistencies
#
0 23 * * 7 /opt/zimbra/libexec/zmdbintegrityreport -m
#
# Monitor for multiple mysqld to prevent corruption

*/5 * * * * /opt/zimbra/libexec/zmcheckduplicatemysqld -e > /dev/null 2>&1
#
# crontab.logger
#
# process logs
#
00,10,20,30,40,50 * * * * /opt/zimbra/libexec/zmlogprocess > /tmp/logprocess.out 2>&1
#
# Graph generation
#
10 * * * * /opt/zimbra/libexec/zmgengraphs >> /tmp/gengraphs.out 2>&1
#
# Daily reports
10 1 * * * /opt/zimbra/libexec/zmdailyreport -m
#

#
crontab.mta
#
#
# Queue logging
#
0,10,20,30,40,50 * * * * /opt/zimbra/libexec/zmqueuelog
#
# Spam training
0 23 * * * /opt/zimbra/bin/zmtrainsa >> /opt/zimbra/log/spamtrain.log 2>&1
#
# Spam training cleanup
#
45 23 * * * /opt/zimbra/bin/zmtrainsa --cleanup >> /opt/zimbra/log/spamtrain.log 2>&1
#
# Dspam cleanup
#
0 1 * * * [ -d /opt/zimbra/data/dspam/data/z/i/zimbra/zimbra.sig ] && find /opt/zimbra/dspam/var/dspam/data/z/i/zimbra/zimbra.sig/ -type f -name \*sig -mtime +7 -exec rm {} \; > /dev/null 2>&1
8 4 * * * [ -f /opt/zimbra/data/dspam/system.log ] && /opt/zimbra/dspam/bin/dspam_logrotate -a 60 -l /opt/zimbra/data/dspam/system.log
8 8 * * * [ -f /opt/zimbra/data/dspam/data/z/i/zimbra/zimbra.log ] && /opt/zimbra/dspam/bin/dspam_logrotate -a 60 -l /opt/zimbra/data/dspam/data/z/i/zimbra/zimbra.log
#
# Spam Bayes auto-expiry
#
20 23 * * * /opt/zimbra/libexec/sa-learn -p /opt/zimbra/conf/salocal.cf --dbpath /opt/zimbra/data/amavisd/.spamassassin --siteconfigpath /opt/zimbra/conf/spamassassin --force-expire --sync > /dev/null 2>&1
#
# Clean up amavisd/tmp
#
15 5,20 * * * find /opt/zimbra/data/amavisd/tmp -maxdepth 1 -type d -name 'amavis-*' -mtime +1 -exec rm -rf {} \; > /dev/null 2>&1
#
# Clean up the quarantine dir
#
0 1 * * * find /opt/zimbra/data/amavisd/quarantine -type f -mtime +7 -exec rm -f {} \; > /dev/null 2>&1

ZIMBRAEND -- DO NOT EDIT ANYTHING BETWEEN THIS LINE AND ZIMBRASTART

Appendix D: ABQ - SOAP API

要約

New for Zimbra Collaboration 8.8.15: 「Allow/Block/Quarantine」の機能では、サーバへ接続するモバイルデバイスのアクセスを管理することが可能です。 本機能の詳細につきまして、ABQ Service documentation のドキュメンテーションをご参照ください。

以下に ABQ サービスの SOAP API サポートを紹介しています。

Zimbra SOAP

Zimbra がクライアントと合体するために Simple Object Access Protocol (SOAP) を提供しています。詳細につきましては以下のドキュメントをご参照ください。

なお、Zimbra の SOAP 提供では以下の SOAP リクエストのように soap:Header および soap:Body が含まれています。

<?xml version="1.0" encoding="utf-8" ?>
<soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope">
    <soap:Header>
        <context xmlns="urn:zimbra">
            <authToken>$token</authToken>
            <format type="xml"/>
        </context>
    </soap:Header>
    <soap:Body>
        $xml
    </soap:Body>
</soap:Envelope>

上記の実例では、$xml に実行希望の SOAP リクエストを入力し、$token はクライアントの認証が正常に行った後に Zimbra が発行する値を入力する必要となります。

ログイン

Zimbra へアクセスするため、まずは認証を行って、有効なtokenを発行します。以下にtokenを取得できる XML リクエストの事例です。

<AuthRequest xmlns="urn:zimbraAdmin">
    <account by="name">"user@example.com"</account>
    <password>password</password>
</AuthRequest>

Here an example of a reply:

<soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope">
    <soap:Header>
        <context xmlns="urn:zimbra">
        <change token="699"/>
        </context>
    </soap:Header>
    <soap:Body>
        <AuthResponse xmlns="urn:zimbraAdmin">
            <authToken>0_2ebb6bdada2b1987c4fa625f95862d2a299b2e4c_69643d33363a34623065356237342d366135612d343435372d393032662d6630313833343131386666363b6578703d31333a313532393335333836373330303b61646d696e3d313a313b747970653d363a7a696d6272613b753d313a613b7469643d31303a313031323636373733383b76657273696f6e3d31333a382e382e385f47415f323030393b</authToken>
            <lifetime>43199998</lifetime>
        </AuthResponse>
    </soap:Body>
</soap:Envelope>

有効な token があれば、soap:Header<authToken>$token</authToken> に入力し、今後のリクエストに使用します。

ABQ API

すべてのABQコールは共通のXMLがあります:

<zextras xmlns="urn:zimbraAdmin">
    <module>ZxMobile</module>
    <action>$action</action>
</zextras>

上記の $actiongetDeviceControlList, getDeviceStatus または setDeviceStatus で指定し、必要であれば適切なパラメータも入力します。以下が返答の実例です:

<soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope">
    <soap:Header>
        <context xmlns="urn:zimbra">
        <change token="699"/>
        </context>
    </soap:Header>
    <soap:Body>
        <response content="{"response":{"devices":[{"device_id":"device4","status":"device1=allowed;device2=quarantined;device3=Blocked"}]},
        "ok":true}"/>
    </soap:Body>
</soap:Envelope>

すべての ABQ 返答は一般的であり、content 値で <response> のタグに追加されます。コンテンツは JSON 形式としてフォーマットし、1つの JSONObject: "response"Boolean: "ok" が含まれています。`JSONObject: "response"`に返答が含まれており、`Boolean: "ok"`でリクエストが成功されたかどうかを指定します。

getDeviceControlList

ステータスが “all”, ”allowed”, ”quarantined” または ”blocked”でフィルターされている ABQ デバイスリストを返答します(大文字と小文字を区別しない)

<zextras xmlns="urn:zimbraAdmin">
    <module>ZxMobile</module>
    <action>getDeviceControlList</action>
    <status>all</status>
</zextras>

getDeviceStatus

(セミコロン「;」で区切っている)デバイスリストから各 ABQ ステータスのリストで返答します。

<zextras xmlns="urn:zimbraAdmin">
    <module>ZxMobile</module>
    <action>getDeviceStatus</action>
    <device>device01;device02</device>
</zextras>

返答には devices の JSON アレーが含まれており、各位は`"device_id"` と "status" のストリングペアになります。以下は実例です。

{"response":{"devices":[{"device_id":"device1","status":"Allowed"}]},"ok":true}

リクエストしたデバイスが ABQ に確認していない場合、レスポンスに含まれません。

setDeviceStatus

指定したデバイス、またはデバイスのリストにデバイスのステータスを設定します。リストがセミコロン「;」で区切れており、各値が device_id = $status で、$statusAllowed, Quarantined または Blocked (大文字と小文字を区別しない) となります。失敗h氏tあデバイスのリストを返答します。

<zextras xmlns="urn:zimbraAdmin">
    <module>ZxMobile</module>
    <action>setDeviceStatus</action>
    <deviceStatus>device01=allowed;device02=blocked</deviceStatus>
</zextras>

返答には devices の JSON アレーが含まれており、各位は`"device_id"` と "status" のストリングペアになります。以下は実例です。

    {"response":{"devices":[{"device_id":"device4","status":"wrong"}]},"ok":true}
実例

AbqClient は ABQ api アクセスの簡単な java 事例です。独立しており、ant でビルドすることが可能です:

$ ant build

また、以下のコマンドで実施できます:

$ ant run

用語集

この用語集には、本書で使用している用語と略語をリストトアップしています。また、業界用語と本アプリケーションの用語の両方を対象としています。一般的な業界のプラクティスやコンセプトが本製品に固有の方法で実装されている場合は、そのことも記載します。

A レコード

A (アドレス) レコードは、ホスト名を数字のIPアドレスにマッピングします。Zimbraの場合、AレコードはZimbraサーバーのIPアドレスになります。

ABQ

NG モジュールで提供してる Allow/Block/Quarantine 機能では、システムの管理者が ActiveSync 経由で同期することが許可しているデバイスを管理できます。

アカウントのポリシー

Zimbra管理コンソール内で「提供サービス」として利用されています。

AD

Microsoft アクティブ・ディレクトリ・サーバー(Active Directory Server)の省略です。Zimbra CollaborationでOpenLDAPに加えて、ユーザー認証とGALのオプションとして使用することが可能です。

エイリアス

“別名” のメールアドレスであり、異なるメールアドレスを使うユーザーへ転送されます。

属性

ディレクトリサーバーエントリ用のオブジェクト関連データが含まれています。属性にはサーバーのホスト名やメールの転送先アドレスなどが保存されています。

認証

システムへアクセスするユーザーの権限を検証するために使う、ユーザーの入力したログイン情報を処理する方法です。

ブラックリスト

迷惑メール対策の用語で、既知の悪質なIPアドレスを示します。迷惑メール送信者が乗っ取ったIPアドレスである可能性もあります。または合法であるけれども維持管理が乏しいために認証されていないユーザーからのメッセージもリレーできるようなIPアドレスである可能性もあります。

BLOB

バイナリ・ラージ(大きい)・オブジェクト(Binary Large OBject)の省略です。

提供サービス (COS)

アカウントのメールボックス割り当て容量などの設定が含まれるZimbra Collaboration LDAPスキーマにあるオブジェクトです。各Zimbra Collaboration アカウントにはCOSが1つ適用され、そのアカウントは、適用されているCOSからすべての設定を継承します。

CLI

コマンド・ライン・インターフェース(Command-Line Interface)の省略です。zmprovなどのZimbra Collaborationのコマンド・ラインツールの集合体について言及する際に使用されます。

クラスタ

複数のサーバー(ノード)を使用している、可用性の高いネットワーク構成の一種です。サーバー1つが停止あるいはネットワークから外れた場合に、代替サーバーが引き継ぎます。

連絡先

Zimbra Collaboration上では、連絡先とはユーザーインターフェースの1機能で、ユーザーの個人的な住所や連絡先情報を集めて一覧にしたものです。

スレッド

Zimbra Collaboration上では、スレッドとはユーザーインターフェースの1機能で、メールのスレッド(同じ件名を使用しているメッセージ)を1つのスレッドリストとして表したものです。ユーザーは、スレッドを展開することで、それに含まれるメッセージをすべて閲覧することができます。

DHTML

ダイナミックHTML(Dynamic HTML)の省略です。Zimbraウェブクライアントで使用されている技術の一つです。

DNS

ドメイン・ネーム・システム(Domain Name System)とは、インターネットのディレクトリサービスです。DNSとは、ドメイン名がIPアドレスへ変換する方法であり、メール配信の制御も行ないます。Postfixがリモートの宛先へ正常にメッセージを送信するには、正しく設定されたDNSが必要です。

エッジMTA

受信メールのトラフィックを最前線で防御するメール配信エージェント(MTA)を指す一般用語です。エッジMTAに備わっている機能に、迷惑メールのフィルターリングなどがあります。

エントリ

ディレクトリサーバーにあるアイテム、例えばアカウントやメールホストです。

エフェメラルデータ

短命、あるいは即座に変化する性質のデータ。ログインのタイムスタンプや認証トークンなど。

フェールオーバー

メインサーバーが利用できないことを代替サーバーが検知して、メインサーバーに変わって代替サーバーが処理を行なう一連の引き継ぎ処理のこと。

FQDN

完全修飾ドメイン名を意味する「Fully Qualified Domain Name」の省略です。ホスト名とホストへのパスです。例えば、www.zimbra.comは完全修飾ドメイン名です。wwwはホスト、zimbraはセカンダリレベルのドメイン、そしてcomがトップレベルのドメインとなります。

GAL

グローバル・アドレス・リスト(Global Address List)の省略です。会社ディレクトリのOutlook版です。組織内の全従業員分のメールアドレスを含む連絡先のリストです。

グローバル設定

サーバーと提供サービスのデフォルト設定を保存しているZimbra Collaboration のオブジェクトです。

高可用性

HAと省略されます。高可用性とは、システム内のコンポーネントの障害の後でもそのコンピュータシステム内で使用できるリソースを示しています。

HTTP

ハイパーテキスト・トランスファー・プロトコル(HyperText Transfer Protocol)の省略です。UIの統合のため、SOAPと共に利用されます。

IMAP

インターネット・メッセージ・アクセス・プロトコル(Internet Message Access Protocol)の省略です。ユーザーがローカルでの作業のように、リモートのメッセージストアのメールにアクセスできる方法です。

ストア

Zimbra Collaboration内にある、特定のメールボックスサーバーのメールメッセージの全インデックス情報を保存するディレクトリです。

インデックス化

検索キーワードについて受信メールメッセージを解析するプロセスです。

Java

Javaは業界で使用されているオブジェクトベースのプログラミング言語です。JavaはコアのZimbra Collaborationアプリケーションサーバーに使用されています。

JavaScript

主にNetscapeで開発された、HTMLのソースコードと共に使用できるスクリプトです。この技術はZimbraウェブクライアントに使用されています。

LDAP

ライトウェイト・ディレクトリ・アクセス・プロトコル(Lightweight Directory Access Protocol)の省略です。業界標準で認証に使用されているプロトコルです。

Zimbra管理コンソール

Zimbra Collaboration の管理者インターフェースです。

Zimbraウェブクライアント

Zimbra Collaboration のエンドユーザーインターフェースです。

LMTP

ローカル・メール・トランスファー・プロトコル(Local Mail Transfer Protocol)の省略です。 最後の配信で、Postfix MTAから Zimbra Collaboration サーバーへメッセージを送信する際に使用します。

メールボックスサーバー

Zimbra Collaboration サーバーの代替名

MAPI

メッセージング・アプリケーション・プログラミング・インターフェース(Messaging Application Programming Interface)の省略です。異なる電子メールアプリケーションと共に実行できるようにMicrosoft Windowsへ組み込んだシステムです。

メッセージストア

Zimbra Collaboration内にある、特定のメールボックスサーバーのメールメッセージを保存するディレクトリエリアです。

MDA

メール・デリバリー・エージェント(Mail Delivery Agent)の省略で、「メールホスト」とも呼ばれます。Zimbra CollaborationサーバーはMDAとして機能します。

メタデータ

データの実際の内容を説明せずにそのデータを説明するためのデータです。Zimbra Collaboration内ではメタデータには、ユーザーのフォルダ、スレッド、メッセージ件名やタグ、ポインターが含まれています。

MIME

マルティパーパス・インターネット・メール・エクステンション(Multipurpose Internet Mail Extensions)の省略で、イメージファイル、などの非ASCIIのインターネットメッセージ内容をフォーマット化する技術仕様です。 メッセージストアにメッセージを保存するフォーマットです。

MTA

メッセージ・トランスファー・エージェント(Message Transfer Agent)の省略です。MTAは、マシン間でメールを送り届けるプログラムです。 Zimbra Collaborationのシステムでは、PostfixのMTAとエッジMTAの両方を想定しています。

MXレコード

メール・エクスチェンジ(Mail eXchange)の省略です。MXレコードはドメイン名データベースのエントリです。このエントリにより、該当のドメイン名のメールの処理を行なう担当のメールサーバーが識別できます。メールシステムは、ドメイン間でのメッセージ送信を行なうのに、DNSのMXレコードに依存しています。メールを処理する際、受信先アドレスのAレコードを確認する前にMXレコードが確認されます。

OOTO

「不在にしています」(Out Of The Office)のよくある省略です。不在メッセージ送信時に使用されます。

オープンソース

非営利的な配信を目的としたユーザーグループが作成したソフトウェアです。ソースコードは所有されずに公開されています。

OS

オペレーティング・システム(Operating System)の省略です。Linux, UNIX, Microsoft Windows、などはOSの一例です

POP

ポスト・オフィス・プロトコル(Post Office Protocol)の省略です。電子メールをTCP/IPでリモートのサーバーから取得し、ローカルのコンピュータへ保存します。

プロビジョニング

バッチやその他の自動化された方法によって、アカウントやその他のデータを作成する処理です。

RBH

リアル・タイム・ブラックホール(Real-time Black Hole)の省略です。公開サービスとして、良くない送信元IPアドレスのリストを提供しているウェブサイトです。これらIPアドレスは、迷惑メールの送信者として知られているサーバーか、安全でないまたは迷惑メール送信者に悪用されているサーバーであるため、ここからのメールは拒否するべきアドレスとしてリストアップされています。

Redoログ

再実行とレプリケーションに使用する Zimbra Collaboration serverの詳細なトランザクションログです。

SAN

ストレージ・アレー・ネットワーク(Storage Array Network)の省略です。高可用性のデータストレージエリアです。

スキーマ

特定の管理サイトのディレクトリサービスで使用中のデータ構造を指します。

SMTP

シンプル・メール・トランスファー・プロトコル(Simple Mail Transfer Protocol)の省略です。 Zimbra Collaboration のシステムではエッジMTAとPostfix MTAの間で使用されます。

SNMP

シンプル・ネットワーク・モニタリング・プロトコル(Simple Network Monitoring Protocol)の省略です。システムログから重要なエラーを取り出すために監視ソフトウェアで使用しています。

SOAP

シンプル・オブジェクト・アクセス・プロトコル(Simple Object Access Protocol)の省略で、ウェブサービスのリクエストの送信に使用する、XMLベースのメッセージングプロトコルです。 Zimbra Collaborationサーバーではリクエスト送受信にSOAPを使用しています。このリクエストは Zimbra Collaborationのコマンドラインツールまたは Zimbra Collaborationのユーザーインターフェースから送られます。

迷惑メール(スパム)

求められていない商用メールです。迷惑メール送信者はこれを “一括送信のビジネスメール” と呼んでいます。

SQL

ストラクチャー・クエリー・ランゲージ(Structured Query Language)の省略です。メッセージストア内のメッセージを検索するために使用します。

SSL

セキュア・ソケット・レイヤー(Secure Sockets Layer)の省略です。

タグ

Zimbraウェブクライアントの機能です。ユーザーはタグを作成してメールメッセージに検索用に適用することができます。

TCO

総保有コストを意味する「トータル・コスト・オブ・オーナーシープ」(Total Cost of Ownership)の省略です。Zimbra Collaborationは必要なサーバーのハードウェア、OSのライセンス手数料、サポートのアプリケーション手数料、必要なディスク容量および社員(IT、ヘルプデスク、コンサルティング、など)を減らすことで、総保有コスト(TCO)を削減します。

TLS

トランスポート・レイヤー・セキュリティ(Transport Layer Security)の省略です。

UCE

求められていない商用メールを意味する「アンソリシテット・コマーシャル・メール」(Unsolicited commercial email)の省略で、迷惑メールやスパムとも呼ばれます。

仮想エイリアス

Postfix MTA内で認識されるメールエイリアスの一つです。

ホワイトリスト

信頼できるメールやIPアドレスのための、迷惑メール対策の専門用語です。信頼できるアドレスから受信したメールは "自動的に信頼"できる場合が多いです。

XML

エクステンデッド・マークアップ・ランゲージ(eXtended Markup Language)の省略です。