アップグレード準備

アップグレードを開始する前に、以下の作業の実施が必要な場合があります。このセクションにある作業を確認してから、アップグレード手順セクションに進んで下さい。アップグレードを行う前に必ず リリースノート を読んで下さい。

すべてのメールボックスサーバーにおいて、8.7 にアップグレードされる前に２要素認証 (2FA) が有効になっていた場合、ローリングアップグレード中に Bug 105056 に記述されている問題が発生する可能性があります。特に、8.7より前のメールボックスサーバーは 2FA 機能と互換性がありません。

そのため、すべてのメールボックスサーバーが 8.7 にアップグレードされるまでは、2FA機能を無効にしておくことを推奨します。

以下の新しいサービスはアップグレード時に導入が可能です。詳しくは Zimbra Collaboration Administration Guide を参照して、導入が必要かどうかを判断して下さい。

  • zimbra-chat

  • zimbra-drive

  • zimbra-imapd

データベースの整合性の確認

アップグレードする前に既にデータベースが壊れている場合、アップグレード作業が状況を悪化させてしまう場合があります。なるべく早い段階でデータベースの破損を検知するために、システムに対して変更を加える前に、 zmdbintegrityreport を使って MariaDB データベースを検証する手順を追加しています。 zmdbintegrityreport を実行するかどうか、アップグレードスクリプトからプロンプトが出されます。

zmdbintegrityreport はシステム規模とディスク帯域幅によって、実行に数分〜1時間かかります。

すべての zimbra-store ノードにおいて、cron で毎週 zmdbintegrityreport が実行されます。大規模なサイトでは zmlocalconfig -e zmdbintegrityreport_disabled=TRUE と設定することによって、設定を無効にすることができます。この設定を無効にした場合、通常の保守作業の時間中および ZCS のアップグレードの前にかならず整合性を確認することを推奨します。

オペレーティング・システムの準備

ZCS をアップグレードする前に、ZCS が試験された最新のパッチを当て、OS を最新にアップデートすることを推奨します。

Ubuntu OS

  • Ubuntu 16.04 LTS Server Edition (64-bit)

  • Ubuntu 14.04 LTS Server Edition (64-bit)

  • Ubuntu 12.04.4 LTS Server Edition (saucy (3.11) 以上のカーネル)

    もし既存のシステムが Ubuntu 12.04.2 以前で稼働している場合、手動で saucy (3.11) 以上のカーネルシリーズに切り替える必要があります。詳しくは LTSEnablementStack を参照して下さい。

    カーネルのバージョンを調べるためには以下のコマンドを実行して下さい。

    uname -a

    入力例:

    build@zre-ubuntu12-64:~$ uname -a
Linux zre-ubuntu12-64 3.11.0-17-generic #31~precise1-Ubuntu SMP Tue Feb 4
21:25:43 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

Red Hat Enterprise Linux/CentOS Linux

  • RHEL ディストリビューション上で稼働させる場合、RedHat からの有効なライセンスが必要です。

  • Zimbra パッケージサーバーにアクセスするために、インストール先のサーバーで yum あるいは apt-get の設定を正しく行って下さい。

  • RedHat® Enterprise Linux® 7, AS/ES (64-bit)

  • CentOS Linux® 7 (64-bit)

  • Red Hat Enterprise Linux 6, AS/ES (64-bit) パッチレベル4以降

  • CentOS Linux 6 (64-bit) パッチレベル4以降

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

  • アップグレードインストールの始めに、既存のライセンスを検証し、アップグレードが可能かどうかを確認します。もしライセンスの期限が切れている場合、エラーメッセージが表示され、アップグレードは実行されません。アップグレードできるように Zimbra 販売代理店に連絡し、ライセンスを更新して下さい。

  • アップグレードインストールは自動アクティベーションあるいは手動でアクティベートされたライセンスファイルが無いと動作しません。ライセンスファイルごとに5回までライセンスアクティベーションを行うことができます。もし商用環境をアップグレードする以前に、既にアクティベーション回数をすべて使い切ってしまっていた場合は、追加でライセンスのアクティベーションできるようにZimbra 販売代理店にご連絡下さい。

Network Edition のインストールには有効なライセンスとライセンスアクティベーションが必要です。新規インストールでは、ライセンス開始日から10日間、アクティベーション猶予期間があります。

ライセンスアクティベーションは、 Zimbraライセンスサーバーに外部アクセスできるシステムの場合、インストール中に自動的に行われます。Zimbraライセンスサーバーに外部アクセスできないシステムのためには、手動アクティベーションの方法が提供されます。詳しくは Zimbra Collaboration Administration Guide を参照して下さい。

現行システムにおいて古いバージョンの Zimbra Collaboration が稼働している場合、アップグレードに際して ZCO 機能およびアーカイブ機能に関するライセンスの適用方法が変わる場合があります。古いライセンスでは MAPIConnectorAccountsLimit が 0 になっている場合や、 ArchivingAccountsLimit がライセンスキーに含まれていない場合があります。もし ZCO やアーカイブ機能が使用できる契約をお持ちで、現在のライセンスが正しいユーザー数を反映していない場合、アップグレード作業を開始する前に、 Zimbra 販売代理店までご連絡いただき、ライセンスファイルを更新して下さい。

LDAPレプリカとマルチマスターサーバーのアップグレード

ZCS 8.0.0, 8.0.1, 8.0.2 から、8.0.4 以降へのアップグレード方法については、後述します。

現行システムがレプリカサーバー、あるいはマルチマスターノード環境で稼働している場合、ZCS 8.0.4 以降にアップグレードする前に、アップグレードしようとしているバージョンの Zimbra LDAP スキーマを、レプリカサーバーあるいはマルチマスターサーバーに対してインストールする必要があります。詳しくは Bug 81048 を参照して下さい。

  1. マスター LDAP サーバー上で、ZCS 8.0.4 以降のソフトウエアをインストールして下さい。

    ./install.sh -s

  2. 各レプリカおよび MMR モードでのマスター LDAP サーバー上で、zimbra ユーザーになって:

    1. 以下のどちらかのコマンドを使ってサーバーを停止して下さい。

      1. ldap stop

      2. zmcontrol stop

    2. zimbra スキーマを別名で保管します。

      cd /opt/zimbra/data/ldap/config/cn=config/cn=schema
mv cn={4}zimbra.ldif /opt/zimbra/data/ldap/cn={4}zimbra.ldif.dead

    3. マスタ LDAP サーバーからスキーマをコピーします。

      scp root@<master>:/opt/zimbra/openldap/etc/openldap/schema/zimbra.ldif cn={4}zimbra.ldif

    4. cn={4}zimbra.ldif を編集し、以下の2行を変更します。

      dn: cn=zimbra,cn=schema,cn=config     ------->     dn: cn={4}zimbra
cn: zimbra                            ------->     cn: {4}zimbra

    5. 以下のどちらかのコマンドを使ってサーバーを起動して下さい。

      1. ldap start

      2. zmcontrol start

  3. マスター LDAP サーバーで実行します。

    /opt/zimbra/libexec/zmsetup.pl

  4. レプリカサーバーで実行します。

     ./install.sh

    これ以降の手順は マルチサーバー環境でのアップグレード手順 を参照して下さい。

SSLv3サポートの無効化

ZCS 8.7.0 にアップグレードする場合、アップグレード後 SSLv3 サポートを完全に無効にする必要があります。SSLv3 脆弱性問題のため、SSLv3 を無効にすることを推奨します。詳細は Alert (TA14-290A) を参照して下さい。

デフォルトで SSLv3 サポートは 8.6.0 から廃止されています。しかしながら、古いバージョンの ZCS からアップグレードすると、幾つかのプロトコルは未だ有効になっている可能性があります。

  • ZCS 8.7.0 以降で新しいキーが追加され SSLv3 はデフォルトで無効になっています。

  • 古いバージョンの ZCS で使われていたキーが残っていて SSLv3 がアップグレード後も有効になっているかもしれません。

Zimbra Wiki How to Disable SSLv3 を参照して、ZCS 8.7.0 にアップグレード後 SSLv3 を無効にして下さい。

デフォルト Proxy SSL 暗号属性の更新

アップグレードするときは常に、以下の属性を確認し( zmprov gcf <attr> ) 、最新のデフォルト値と比較する ( zmprov desc -a <attr> ) ことを推奨します。

zimbraReverseProxySSLCiphers
zimbraReverseProxySSLProtocols
zimbraSSLExcludeCipherSuites
zimbraMailboxdSSLProtocols
システムの設定に対して新しいハードニングを施していない場合、現在の設定は既にZCS のデフォルト値に合致しているはずです。何も行う必要はありません。

加えて、以下の変更を行うことを奨励します。

  1. 以下の値を zimbraReverseProxySSLCiphers から削除して下さい。

    ECDHE-RSA-RC4-SHA
ECDHE-ECDSA-RC4-SHA
RC4-SHA

  2. 以下の値を zimbraReverseProxySSLCiphers に追加して下さい。

    !RC4
    暗号スイートの設定について、最新の詳細情報については Cipher suites を参照して下さい。

ZCO インストールのカスタマイズ

ZCO インストール MSI のカスタマイズを希望する管理者は、署名なしのバージョンの MSI ( ZimbraConnectorOLK_n.n.n.nnnn_xnn-unsigned.msi ) を使って下さい。それは Zimbra ダウンロードディレクトリに置いてあります。そして、エンドユーザーが /downloads/index.html からダウンロードしたり、あるいは ZCO の自動アップグレード処理にて使えるように、変更した MSI を 署名付き MSI ( ZimbraConnectorOLK_n.n.n.nnnn_xnn.msi ) で置き換えて下さい。詳しくは Bug 85067 を参照して下さい。

アップグレード手順

ソフトウエアのダウンロード

Network Edition をダウンロードする場合 zimbra collaboration にアクセスして下さい。

  • アップグレードを開始する前にに、全ユーザーの完全なバックアップが取られていることを確認してください!

  • 7.x から 8.x へのアップグレードに際してデータベースの再読込が行われます。

ZCS がインストール済みの環境でインストールスクリプトを実行すると、アップグレードを実施するかどうか聞かれます。このリリースノートはアップグレードを行う際の手順について述べます。更に詳しい情報については、インストールガイドを参照して下さい。

インストールやアップグレード作業の作業中に、端末のセッションが予期せずに終了することを防ぐために、screen などの UNIX コマンドを使うことを推奨します。特に大量のアカウントに影響のある設定をリストアする必要のあるアップグレード作業を行う際にとても重要です。

入力例:

screen ./install.sh

シングルサーバーでのアップグレード手順

アップグレードする前にサービスを停止する必要はありません。必要に応じて、アップグレード処理が自動的にサービスを停止・起動します。

手順

  1. root ユーザーで Zimbra サーバーにログインし、 ZCS Network Edition のアーカイブ tar ファイルが保存されているディレクトリに cd します。例えば cd /var/tmp 。そして以下のコマンドを入力します:

    ファイルを解凍します。

    tar xzvf zcs.tgz

    解凍したディレクトリに移動します。

    cd <expanded-directory>

    アップグレードインストールを開始します。

    ./install.sh

  2. アップグレードスクリプトは proxy と memcached が既に導入されているか確認します。もし両方とも見つかれば、アップグレードは次に進みます。もしどちらか片方でも見つからない場合には、アップグレードは警告を表示して終了します。

  3. Zimbra ソフトウェア使用許諾契約が表示されます。内容を確認し、Y を入力します。

  4. Use Zimbra’s packaging server [Y] が表示されたら、enter を押して下さい。Zimbra のサードパーティーパッケージをネットワーク経由でインストールできるように、yum あるいは apt-get のための Zimbra パッケージ用リポジトリの設定をインストール先システムに追加します。

  5. Do you wish to upgrade? [Y] が表示されたら、enter を押して下さい。アップグレードパッケージが展開されます。

  6. パッケージ名が一覧で表示されます。未インストールのパッケージのリストも表示されますので、この時点でパッケージをインストールしたい場合には Y を入力して下さい。さもなくば enter を押して下さい。アップグレードスクリプトはアップグレード作業に必要なディスク容量があるかを確認します。もし、十分な容量が無い場合には、アップグレードは終了します。

  7. The system will be modified. Continue? [N] が表示されたら、 Y を入力し、enter を押して下さい。Zimbra サーバーは停止され、古いパッケージが削除されます。アップグレードプロセスは、現在どのバージョンの ZCS が稼働中かを確認し、サービスをアップグレードし、既存の設定ファイル群を戻し、サーバーを再起動します。大量のアカウントが作成されている場合、作業に時間がかかることがあります。

  8. タイムゾーンが設定されていない場合、タイムゾーンを聞かれるので設定して下さい。ここで指定したタイムゾーンは、デフォルトの COS に設定されます。当該COSに含まれるユーザーの大部分が活動するタイムゾーンを選ぶとよいでしょう。

  9. 設定が完了したら、enter を押して下さい。 すべての MTA ノードが Zimbra Collaboration 8.8.5 にアップグレードされた後、必要であれば、以下のコマンドを入力して globalconfig のデフォルト値を修正して下さい。

    zmprov mcf zimbraMtaCommandDirectory /opt/zimbra/common/sbin
zmprov mcf zimbraMtaDaemonDirectory /opt/zimbra/common/libexec
zmprov mcf zimbraMtaMailqPath /opt/zimbra/common/sbin/mailq
zmprov mcf zimbraMtaManpageDirectory /opt/zimbra/common/share/man
zmprov mcf zimbraMtaNewaliasesPath /opt/zimbra/common/sbin/newaliases
zmprov mcf zimbraMtaSendmailPath /opt/zimbra/common/sbin/sendmail

  10. Zimbra Collaboration 8.7 以降DSPAMはサポートされません Bug 104158。以下を入力して DSPAM を無効にして下さい。

    zmprov ms `zmhostname` zimbraAmavisDSPAMEnabled FALSE
zmlocalconfig -e amavis_dspam_enabled=false
zmamavisdctl restart

  11. アップグレードは完了です。データベースのスキーマが変更になっているため、メジャーアップグレードを行った後には、フルバックアップを取ることを推奨します。

マルチサーバー環境でのアップグレード手順

以下の手順でサーバーをアップグレードします。手順 の指示に従って、サーバーをひとつづつ更新してきます。

  1. LDAP マスタサーバー。LDAP マスターサーバーは他のサーバーより先に、一番最初にアップグレードする必要があります。また、他のサーバーをアップグレードしているあいだ、ずっと稼働させておいて下さい。

  2. LDAP レプリカ

  3. MTA サーバー - オンディスクデータベースマップのためのサポートされたバックエンドとして LMDB を使う を参照して下さい。

  4. プロキシサーバー

  5. メールストアサーバー

手順

  1. root ユーザーで Zimbra サーバーにログインし、 ZCS Network Edition のアーカイブ tar ファイルが保存されているディレクトリに cd します。例えば cd /var/tmp 。そして以下のコマンドを入力します:

    ファイルを解凍します。

    tar xzvf zcs.tgz

    解凍したディレクトリに移動します。

    cd <expanded-directory>

    アップグレードインストールを開始します。

    ./install.sh

  2. アップグレードスクリプトは proxy と memcached が既に導入されているか確認します。もし両方とも見つかれば、アップグレードは次に進みます。もしどちらか片方でも見つからない場合には、アップグレードは警告を表示して終了します。

  3. Zimbra ソフトウェア使用許諾契約が表示されます。内容を確認し、Y を入力します。

  4. Use Zimbra’s packaging server [Y] が表示されたら、enter を押して下さい。Zimbra のサードパーティーパッケージをネットワーク経由でインストールできるように、yum あるいは apt-get のための Zimbra パッケージ用リポジトリの設定をインストール先システムに追加します。

  5. Do you wish to upgrade? [Y] が表示されたら、enter を押して下さい。アップグレードパッケージが展開されます。

  6. パッケージ名が一覧で表示されます。未インストールのパッケージのリストも表示されますので、この時点でパッケージをインストールしたい場合には Y を入力して下さい。さもなくば enter を押して下さい。アップグレードスクリプトはアップグレード作業に必要なディスク容量があるかを確認します。もし、十分な容量が無い場合には、アップグレードは終了します。

  7. The system will be modified. Continue? [N] が表示されたら、 Y を入力し、enter を押して下さい。Zimbra サーバーは停止され、古いパッケージが削除されます。アップグレードプロセスは、現在どのバージョンの ZCS が稼働中かを確認し、サービスをアップグレードし、既存の設定ファイル群を戻し、サーバーを再起動します。大量のアカウントが作成されている場合、作業に時間がかかることがあります。

  8. タイムゾーンが設定されていない場合、タイムゾーンを聞かれるので設定して下さい。ここで指定したタイムゾーンは、デフォルトの COS に設定されます。当該COSに含まれるユーザーの大部分が活動するタイムゾーンを選ぶとよいでしょう。

  9. 設定が完了したら、enter を押して下さい。 すべての MTA ノードが Zimbra Collaboration 8.8.5 にアップグレードされた後、必要であれば、以下のコマンドを入力して globalconfig のデフォルト値を修正して下さい。

    zmprov mcf zimbraMtaCommandDirectory /opt/zimbra/common/sbin
zmprov mcf zimbraMtaDaemonDirectory /opt/zimbra/common/libexec
zmprov mcf zimbraMtaMailqPath /opt/zimbra/common/sbin/mailq
zmprov mcf zimbraMtaManpageDirectory /opt/zimbra/common/share/man
zmprov mcf zimbraMtaNewaliasesPath /opt/zimbra/common/sbin/newaliases
zmprov mcf zimbraMtaSendmailPath /opt/zimbra/common/sbin/sendmail

  10. Zimbra Collaboration 8.7 以降DSPAMはサポートされません Bug 104158。以下を入力して DSPAM を無効にして下さい。

    zmprov ms `zmhostname` zimbraAmavisDSPAMEnabled FALSE
zmlocalconfig -e amavis_dspam_enabled=false
zmamavisdctl restart

  11. アップグレードは完了です。データベースのスキーマが変更になっているため、メジャーアップグレードを行った後には、フルバックアップを取ることを推奨します。

オンディスクデータベースマップのためのサポートされたバックエンドとして LMDB を使う

ZCS 8.5 以降で、 Postfix は LMDB にリンクします。 LMDB は ZCS の OpenLDAP で使用しているバックエンドと同じものです。 ZCS 8.0 以前では、Postfix は Berkeley DB をリンクしていました。

ZCS 8.5 以前では、オンディスクデータベースマップを利用した Postfix を公式にはサポートはしていませんでした。しかし、今までも postconf 設定を変更して使われてきていました。そのようなカスタム設定はアップグレード作業で消去されます。

アップグレード後の変更をリストアするために、以下の手順を実施して下さい:

  1. LMDB データベースを作成するために、データベースの入力ファイルに対して postmap を再実行して下さい。

  2. postconf を確認し、hash:/path/to/db という値を保持するキーについて、その LDAP で設定されている値を lmdb:/path/to/db に書き換えてください。

以前はオンディスクデータベースマップを利用した機能はサポートされていませんでしたが、これからは ZCSでサポートされます。アップグレードの際に、カスタマイズした設定が正しく引き継がれているか確認してください。 詳しくは Bug 77586 を参照して下さい。

アップグレード完了後

アップグレード作業が完了した後、以下の点について確認が必要になることがあります。

  • How to disable SSLv3 を確認する。

  • Cipher suites を確認する。

  • データベースフォーマットに対して大きな構造変更がされるときには、アップグレード処理中に Zimbra は既存のデータベースのバイナリバックアップを取ることがあります。これはダウングレードをしやすくするために行うものです。システムが正しくアップグレードされたと確認できたら、それらのファイルを削除することができます。LDAP サーバーについては、バックアップファイルは /opt/zimbra/data/ldap に　<dbname>.prev.$$ の形で保存されています。ここで $$ はアップグレードスクリプトのプロセスIDです。詳しくは Bug 81167 を参照して下さい。

  • アップグレード後、zmldapupgrade -b 66387 を実行して下さい。 zimbraAllowFromAddress 属性は内部アカウントおよび配布リストに対しては設定できません。このスクリプトを実行すると、zimbraAllowFromAddress の属性値を変更し、アクセス権を付与します。

    • zimbraAllowFromAddress 属性の変更を多くのアカウントに対して行うには時間がかかる場合があるので、この処理はインストーラーからは実行されません。

    • 移行コマンドは zimbraAllowFromAddress 属性を持つアカウント数と、そのうち移行が必要なアカウント数を報告します。すべてのアカウントが移行されたかどうかを確認するには、このコマンドをもう一度実行して下さい。全アカウント数は変わらず、移行済みアカウント数が 0 になっているはずです。詳しくは Bug 66387 を参照して下さい。

  • 自己署名証明書の有効期限が切れていた場合、更新して下さい。

    証明書の有効期限を確認するために、以下のコマンドを zimbra ユーザーにて実行して下さい。

    /opt/zimbra/libexec/zmcheckexpiredcerts -days 1 -verbose

    Zimbra Collaborationではコンポーネント間の通信のために、有効な自己署名証明書か商用の SSL 証明書が必要です。Zimbra インストーラーが自動的に生成した自己署名証明書はデフォルトの有効期限があります。

    自己署名証明書を使って 1年以上前にインストールした Zimbra Collaboration の場合、アップグレード前あるいはアップグレードしたら直ちに証明書を更新する必要があります。

    アップグレード後、次のコマンドを zimbra ユーザーで実行して自己署名 SSL 証明書を再生成して下さい。

    sudo /opt/zimbra/bin/zmcertmgr createca -new
sudo /opt/zimbra/bin/zmcertmgr deployca
sudo /opt/zimbra/bin/zmcertmgr deploycrt self -new

  • ZCS 8.0.7以前で zmlogger を使用していた場合、大量の rdd ファイルが生成される可能性があり、ディスク容量を占領するかもしれません。ZCS 8.0.7以降には logger サーバー上で rdd ファイルの増殖を防止するパッチが含まれています。サーバー上から rdd ファイルを消去するために、以下のスクリプトを実行して下さい。詳しくは Bug 85222 を参照して下さい。

    sudo su - zimbra
zmloggerctl stop
cd /opt/zimbra/logger/db/data

for nhostid in $(sqlite3 /opt/zimbra/logger/db/data/logger.sqlitedb 'select
id from hosts'); do for ID in $(sqlite3 logger.sqlitedb "select rrd_file, col_name_19 from rrds Where csv_file == 'imap.csv' and host_id == ${nhostid}" | egrep "__[0-9]+$" | cut -d'|' -f1 | sort -n | uniq); do mv rrds/${nhostid}-$ID.rrd /opt/zimbra/logger/db/data/wrong_rrds/; done ; done

for mon in {1..12}; do MON=$(LANG=en_US; date +%b -d 2013-${mon}-01); sqlite3 logger.sqlitedb "DELETE FROM rrds WHERE col_name_19 LIKE '${MON}_%'"; done

sqlite3 logger.sqlitedb "VACUUM;"

zmloggerctl start
rm -R /opt/zimbra/logger/db/data/wrong_rrds
rm /opt/zimbra/logger/db/data/logger.sqlitedb.backup

  • 以下のキーが設定されている場合、ここに示されている様に置き換える必要があります。

    以下のキーは廃止予定です。

    httpclient_client_connection_timeout
httpclient_connmgr_connection_timeout
httpclient_connmgr_idle_reaper_connection_timeout
httpclient_connmgr_idle_reaper_sleep_interval
httpclient_connmgr_keepalive_connections
httpclient_connmgr_max_host_connections
httpclient_connmgr_max_total_connections
httpclient_connmgr_so_timeout
httpclient_connmgr_tcp_nodelay

    上に挙げたキーは、以下のキーに置き換わります。

    httpclient_internal_client_connection_timeout
httpclient_internal_connmgr_connection_timeout
httpclient_internal_connmgr_idle_reaper_connection_timeout
httpclient_internal_connmgr_idle_reaper_sleep_interval
httpclient_internal_connmgr_keepalive_connections
httpclient_internal_connmgr_max_host_connections
httpclient_internal_connmgr_max_total_connections
httpclient_internal_connmgr_so_timeout
httpclient_internal_connmgr_tcp_nodelay
httpclient_external_client_connection_timeout
httpclient_external_connmgr_connection_timeout
httpclient_external_connmgr_idle_reaper_connection_timeout
httpclient_external_connmgr_idle_reaper_sleep_interval
httpclient_external_connmgr_keepalive_connections
httpclient_external_connmgr_max_host_connections
httpclient_external_connmgr_max_total_connections
httpclient_external_connmgr_so_timeout
httpclient_external_connmgr_tcp_nodelay

Ephemeral Data (一時的データ) の移行

Zimbra 8.8.5 より前のバージョンでは 一時的なデータ は LDAP に保存されていました。 一時的なデータ の例として以下があります:

  • zimbraAuthTokens

  • zimbraCsrfTokenData

  • zimbraLastLogonTimestamp

Zimbra Collaboration バージョン 8.8.5 で 一時的なデータ を SSDB といった外部サービスに保存することができるようになりました。この機能を使用するか使用しないかを選ぶことができます; しかし、この機能を使うと LDAP の性能と安定性を向上させることができます。

詳細は Zimbra Collaboration Administration Guide を参照して下さい。 一時的なデータ を LDAP から SSDB に移行する作業は、インストールあるいはアップグレードが完了してから行って下さい。

IMAPD サービス

Zimbra Collaboration バージョン 8.8.5 から新しく zimbra-imapd サービスが導入され、mailboxd プロセスとは別のプロセスで IMAP[S] を稼働させることができるようになりました。この新しいサービスは、メールボックスサーバー上に置くこともできますし、IMAP サービス専用のマシンを用意してそちらに置くこともできます。この分離によって、メールボックスに依存することなくIMAP 機能をスケールさせることができ、またメールボックスサーバーの負荷も軽減させることができます。

新しい `zimbra-imapd` は、大規模なマルチサーバー環境での導入を想定していますが、シングルサーバー環境でも有効に使うことができます。

単独のサーバー上で zimbra-imapd で稼働させるにあたって、IMAPと IMAPSのリクエストを捌くために二つの別々の JVM を使います。それぞれの JVM が、より少ないメモリを消費するのでガーベッジコレクションの効率も上がります。

アップグレード中に zimbra-imapd パッケージを選択した場合、パッケージはインストールされますが、起動のための設定はされません。起動させるには、以下の globalconfig を設定して下さい:

  • zimbraRemoteImapServerEnabled

  • zimbraRemoteImapSSLServerEnabled

zmprov mcf zimbraRemoteImapServerEnabled TRUE
zmprov mcf zimbraRemoteImapSSLServerEnabled TRUE
zmimapdctl start

詳しい設定は Zimbra Collaboration Administration Guide を参照して下さい。

現在のバージョンの削除とクリーンインストールの実行

アップグレードではなく、新しく Zimbra Collaboration Network Edition をインストールしたい場合は、Zimbra Collaboration Network Edition のインストールスクリプトを実行して Do you wish to upgrade? の質問に N と入力して下さい。

既存ユーザーとそのメールをすべて削除しても良いかという警告が表示されます。Yes と入力すると、新規インストールを始める前に、すべてのユーザー、メール、既存のインストールファイルはすべて消去されます。詳細はインストールガイドを参照して下さい。

既存システムに対するカスタマイズについて

最新リリースへのアップグレード作業では、アカウント情報や、設定情報を消去することはありません。LDAP および localconfig に保存されている設定情報はアップグレードしても引き続き保持されます。Zimbra Collaboration によってインストールされるファイルは、アップグレード中に上書きされることがあり、影響を受けたファイルに対してなされたカスタマイズは消去されることがあります。例えば、カスタマイズされたテーマ、ブランドロゴの変更、crontab の変更などが影響を受けます。アップグレード後、コアZimlet のみ有効になります。カスタマイズされ、配置された Zimlet は、アップグレード作業後も上書きされたりなどせず、そのままで残りますが、それぞれの Zimlet は無効化されます。リリース前にはカスタマイズされた Zimlet がアップグレード環境で動作するかをテストできないので、アップグレード後、エンドユーザーに対して Zimlet サービスを有効にする前に、カスタマイズされた Zimlet が正しく動作するかを検証することを推奨します。

Zimbra Collaboration 8.5.x より前のメジャーバージョンから 8.5.x へアップグレードする際に、すべての COS に含まれるコア Zimlet 以外の Zimlet は無効化されます。アカウントレベルでコアZimlet 以外の Zimlet を有効にしている場合、それらの Zimlet を手動で無効化することを検討して下さい。詳しくは Bug 77836 を参照して下さい。

アップグレード中に、Zimbra crontab ファイル内の特定のコメントに挟まれた部分のエントリは新しいデフォルト値に上書きされます。 Zimbra crontab に指定されたカスタムのバックアップスケジュール、および特定のコメントの外側に記述されたエントリはアップグレード後もそのまま残ります。

カスタム UI テーマの変更

Zimbra Collaboration 8.5.x 以降で、デフォルトの UIテーマが新しくなりました。 Zimbra 7.x用に作られたカスタムの UI テーマはZimbra Collaboration 8.5.x 以降では正しく動作しないかもしれません。正しく動かない要因としては、カスラマイズによって違いますが、それは色の指定方法の違いに起因するような簡単な原因から、背面レイヤーや画面からはアクセスできないエリアにあるコンポーネントに関連する問題まで様々です。問題を修正するには、まず 8.5.x 以降に含まれる既存のUIテーマをコピーし、古い UI テーマと同じになるようにテーマを手直しして下さい。詳しくは Bug 62523 を参照して下さい。