| Sun ONE Messaging Server 6.0 管理者ガイド |
第 15 章
メッセージストアを管理するこの章では、メッセージストアとその管理インタフェースについて説明します。この章には、以下の節があります。
概要メッセージストアには、特定の Messaging Server インスタンス用のユーザーメールボックスが格納されています。メッセージストアのサイズは、メールボックス、フォルダ、およびログファイルの数が増えるに従って増大していきます。ストアのサイズを制御するには、メールボックスのサイズ制限 (ディスク制限容量) を指定するか、許可するメッセージ総数を制限指定するか、ストア内のメッセージに関する保存期間決定ポリシーを設定します。
システムにユーザーを追加していくに従い、ディスクストレージ要件も増えていきます。サーバーがサポートするユーザー数によって、メッセージストアに必要な物理ディスクが 1 つであるか、複数であるかが決まります。この追加ディスク容量をシステムに統合するには、2 種類の方法が存在します。もっとも簡単な方法は、別のメッセージストアパーティションを追加することです (「メッセージストアのパーティションを構成する」を参照)。
また、複数のホストしているドメインをサポートしている場合は、1 つのサーバーインスタンスを単一の大規模ドメイン専用にした方がよい可能性があります。この構成を行えば、特定のドメインに対するストア管理を指定することができます。また、パーティションをさらに追加することで、メッセージストアを拡張することもできます。
Messaging Server では、メッセージストアの管理のために、Sun ONE Console インタフェースに加えてコマンドラインユーティリティのセットを提供しています。表 15-1 では、このコマンドラインユーティリティについて説明しています。これらのユーティリティの使用に関する詳細については、「メッセージストアの保守手順を実行する」および『Messaging Server リファレンスマニュアル』を参照してください。
メッセージストアのディレクトリレイアウト図 15-1 は、サーバーインスタンスに対するメッセージストアのディレクトリレイアウトを示しています。メッセージストアはメールボックスの内容に高速でアクセスできるように設計されています。ストアディレクトリについては、表 15-2 を参照してください。
図 15-1 メッセージストアのディレクトリレイアウト
メッセージストアは、いくつかのメールボックスデータベースとユーザーメールボックスで構成されています。メールボックスデータベースは、ユーザー、メールボックス、パーティション、制限容量、およびその他のメッセージストア関連のデータで構成されています。ユーザーメールボックスには、ユーザーのメッセージとフォルダがあります。メールボックスはメッセージストアパーティションに格納されます。メッセージストアパーティションとは、ディスクパーティション上の、メッセージストアを格納するための専用エリアです。詳細は、「メッセージストアのパーティションを構成する」を参照してください。メッセージストアパーティションはディスクパーティションと同じではありませんが、管理の便宜をはかるために、各メッセージストアパーティション用に 1 つのディスクパーティションを使用することをお勧めします。
INBOX などのメールボックスは、store_root にあります。たとえば、ディレクトリパスの例は以下のようになります。
store_root/partition/primary/=user/53/53/=mack1
次の表で、メッセージストアディレクトリについて説明します。
表 15-2 メッセージストアのディレクトリの説明
場所
内容/説明
msg_svr_base
デフォルト:/opt/SUNWmsgsr
サーバプログラム、設定、管理、および情報についてのファイルの格納に使用される、Messaging Server マシン上のディレクトリ
store_root
msg_svr_base/data/store
メッセージストアのトップレベルのディレクトリ。mboxlist、user、および partition サブディレクトリが格納されている
./store.expirerule
メッセージを自動的に削除するルール (有効期限ルール) が格納されている。このオプションのファイルは別の場所に置くこともできる。「自動メッセージ削除 (有効期限およびパージ) 機能を設定するには」を参照
store_root/dbdata/snapshots
メッセージストアデータベースのバックアップスナップショット
store_root/mboxlist/
メールボックスデータベース (Berkeley DB) が格納されている。このデータベースには、メールボックスや制限容量についての情報が保存されている
folder.db には、メールボックスが保存されているパーティションの名前、ACL、および store.idx にある情報のいくつかのコピーなど、メールボックスに関する情報が格納されている。folder.db には、メールボックスごとに 1 つのエントリが存在する
quota.db には、制限容量および制限容量の使用状況に関する情報が格納されている。quota.db には、ユーザーごとに 1 つのエントリが存在する
lright.db - acl 検索権限別のフォルダのインデックス
peruser.db には、ユーザーごとのフラグに関する情報が格納されている。このフラグは、特定のユーザーがメッセージを開封したかどうか、または削除したかどうかを示す
subscr.db には、ユーザーの購読に関する情報が格納されている
store_root/session/
アクティブなメッセージストアプロセスについての情報が格納されている
store_root/user/
使用されていない
store_root/partition/
メッセージストアパーティションが格納されている。デフォルトで primary パーティションが作成されている。このディレクトリには、ほかのパーティションを定義して格納することもできる
store_root/partition/primary/
=user/パーティションのサブディレクトリにある全ユーザーのメールボックスが格納されている。メールボックスは、高速で検索できるようにハッシュ構造で保存されている。特定のユーザーのメールボックスを格納するディレクトリを検索するには、hashdir ユーティリティを使用する
.../=user/hashdir/hashdir/
userid/userid という ID を持つユーザー用のトップレベルのメールフォルダ。これがそのユーザーの INBOX である。デフォルトドメインでは、userid は uid となる。ホストしているドメインでは、userid は uid@domain となる。受信メッセージはこのメールフォルダに配信される
.../userid/folder
メッセージサーバー上のユーザー定義のフォルダ
.../userid/store.idx
/userid/ ディレクトリに保存されたメールについての次の情報を提供するインデックス。メッセージの数、このメールボックスが使用するディスクの制限容量、メールボックスが最後に追加された時間、メッセージフラグ、各メッセージの可変長情報 (ヘッダーや MIME 構造を含む)、各メッセージのサイズなど。さらにこのインデックスには、各ユーザーに関する mboxlist 情報のバックアップコピーや、各ユーザーに関する制限容量情報のバックアップコピーも含まれる
.../userid/store.usr
フォルダにアクセスしたユーザーのリストが格納されている。リストされた各ユーザーについて、そのユーザーが最後にフォルダにアクセスした時間、ユーザーが表示したメッセージのリスト、ユーザーが削除したメッセージのリストといった情報が格納されている
.../userid/store.sub
ユーザーの購読に関する情報が格納されている
.../userid/store.exp
削除されたものの、ディスクからは削除されていないメッセージファイルのリストを格納している。このファイルは、削除されたメッセージが存在する場合のみ表示される
.../userid/nn/
または
.../userid/folder/nn/nn は message_id.msg の形式でメッセージが格納されているハッシュディレクトリであり、 nn には 00 〜 99 までの数字が入る。message_id も数字である。例 : メッセージ 1 〜 99 は .../00 ディレクトリに保存される。最初のメッセージは 1.msg、2 番目のメッセージは 2.msg、3 番目のメッセージは 3.msg となる。以降同様に続く。メッセージ 100 〜 199 は 01 ディレクトリに保存され、メッセージ 9990 〜 9999 は 99 ディレクトリに保存され、メッセージ 10000 〜 10099 は 00 ディレクトリに保存される。以降同様に続く
メッセージストアによるメッセージの削除方法メッセージは、次の 3 段階の手順でメッセージストアから削除されます。
- 削除: クライアントがメッセージフラグを「削除」に設定します。この時点では、メッセージには削除のマークが付けられますが、クライアントは削除フラグを外せばメッセージを復元できます。第 2 のクライアントが存在する場合、そのクライアントからは削除されたフラグがただちには認識できない可能性があります。configutil パラメータの local.imap.immediateflagupdate を設定すると、フラグの更新がただちに行われるようになります。
- 消去: メッセージはメールボックスから削除されます。厳密には、メッセージはメッセージストアのインデックスファイルである store.idx から削除されます。メッセージ自体はディスクに残っていますが、メッセージの消去後、クライアントはメッセージを復元できなくなります。
期限切れは、消去の特殊なケースです。メッセージのサイズや存続期間など、管理者が定義した一連の削除条件に適合するメッセージが消去されます。「自動メッセージ削除 (有効期限およびパージ) 機能を設定するには」を参照してください。
ストアへの管理者によるアクセスを指定するメッセージストアの管理者は、ユーザーのメールボックスを表示してモニターしたり、メッセージストアに対するアクセス制御を指定することができます。ストア管理者は、すべてのサービス (POP、IMAP、HTTP、または SMTP) に対するプロキシ認証権限を持っているので、任意のユーザーの権限を使用して任意のサービスを認証することができます。これらの権限により、ストア管理者は特定のユーティリティを実行してストアを管理することができます。たとえば、MoveUser を使用して、ストア管理者はあるシステムから別のシステムへユーザーアカウントやメールボックスを移動させることができます。
この節では、Messaging Server のメッセージストアに対してストア権限を付与する方法を説明します。
次の項で説明する管理者のタスクを実行することができます。
管理者を追加するには
コンソール コンソールで管理者エントリを追加するには、以下の手順に従います。
コマンドライン コマンドラインで管理者のエントリを追加する場合は、以下のようになります。
configutil -o store.admins -v "adminlist"
この adminlist は、スペースで区切られた管理者 ID のリストです。複数の管理者を指定する場合は、引用符でリストを囲んでください。また、管理者は、サービス管理者グループのメンバーである必要があります (LDAP ユーザーエントリ : memberOf: cn=Service Administrators,ou=Groups,o=usergroup)。
管理者エントリを変更するには
コンソール コンソールでメッセージストアの管理者 UID リストにある既存のエントリを変更するには、以下の手順に従います。
コマンドライン コマンドラインでメッセージストアの管理者 UID リストにある既存のエントリを変更する場合は、以下のようになります。
configutil -o store.admins -v "adminlist"
管理者エントリを削除するには
コンソール コンソールを使用してメッセージストアの管理者 UID リストからエントリを削除するには、以下の手順に従います。
コマンドライン コマンドラインでストア管理者を削除する場合は、以下のように管理者リストを編集することができます。
configutil -o store.admins -v "adminlist"
共有フォルダについて共有フォルダは、ユーザーのグループによってアクセスおよび読み取りが可能なフォルダです。言い換えると、共有フォルダへのアクセス権は、複数のユーザーに付与されます。たとえば、golf というフォルダを作成し、他のユーザーがそのフォルダの内容を表示することを許可できます。
デフォルトでは、Messaging Server によって電子メールアカウントに Shared Folders/Users というフォルダが作成されます。ユーザーはこのフォルダ内に共有フォルダを作成しアクセスします。図 15-2 に、クライアントで共有フォルダが表示される例を示します。この例については、「分散共有フォルダを設定するには」でもさらに説明します。
図 15-2 Ed のクライアント共有メールフォルダリストの例
ユーザーは専用の共有フォルダを作成し、電子メールクライアントを使用してそのフォルダに対するアクセス権を付与できます。ただしその電子メールクライアントは共有フォルダをサポートしている必要があります。これらの共有フォルダは、アクセス権を持つほかのユーザーの Shared Folders に表示されます。
共有フォルダは、ある話題についてのリアルタイムの会話を開始、共有、アーカイブする場合に便利です。たとえば、ソフトウェア開発者のグループは、プロジェクトの進行状況について話し合うための共有フォルダを作成できます。メッセージが共有フォルダに送信されると、その共有フォルダを購読しているユーザーは誰でもそのメールボックスを開いてメッセージを読むことができます (購読者は個々のアドレスでもグループアドレスでも追加できる)。
共有フォルダには 2 種類あります。
通常、共有フォルダは特定のメッセージストア上のユーザーのみが使用できます。ただし、Messaging Server では、複数のメッセージストアからアクセスできる特殊な共有フォルダが作成できます。このようなフォルダは、分散共有フォルダと呼ばれます。詳細は、「分散共有フォルダを設定するには」を参照してください。
共有フォルダへのアクセス権
アクセス権は、folder.db に保存されているアクセス制御リスト (ACL) で保守されます。アクセス権は ACL を設定することで付与できます。ACL を設定するには、readership コマンドラインユーティリティで IMAP SETACL コマンド (-s オプション) を使用するか (「公開フォルダのアクセス制御権を変更するには」を参照)、Messenger Express インタフェースを使用します。
ACL の識別子
各 ACL エントリには、エントリが適用されるユーザーまたはユーザーのグループを特定する識別子があります。ダッシュ記号 - で始まる識別子は、ユーザーまたはユーザーのグループに付与されていない権限です。
anyone は特別な識別子です。anyone のアクセス権は、すべてのユーザーに適用されます。同様に、anyone@domain のアクセス権は、同一ドメイン内のすべてのユーザーに適用されます。
グループの識別子は group= で始まります。
ACL 権限を示す文字
各 ACL エントリには、文字列で示される権限セットがあります。この文字列は RFC 2086 で定義されています。ユーザーの権限セットを計算するために、サーバーはユーザーとユーザーが属しているグループすべてに付与されているすべての権限を加算してから、ユーザーとユーザーが属しているグループに認められていないすべての権限を減算します。
次の表は、Messaging Server によって認識される文字の一覧です。文字の名前を示すとともに、各文字についての簡単な説明、および権限を持つユーザーが発行できる IMAP コマンドを示します。
グループ ACL
ACL エントリの識別子で、グループ名を指定できます。このエントリのアクセス権は、グループのすべてのメンバーに適用されます。グループのメンバーは、inetMailUser オブジェクトクラスの aclGroupAddr 属性を使用してサーバーによって決定されます。aclGroupAddr 属性のフィルタを介して、グループはダイナミックなメーリングリストに示されます。次に、グループを定義する LDIF レコードの例を示します。これには aclGroupAddr 属性も含まれます。
フォルダの ACL で使用されるグループ電子メールアドレスは、必ずしもグループ用に作成されるわけではありません。実際には、グループにメンバーを追加する際に、このようなダイナミックグループを作成し、ユーザーエントリに対して aclGroupAddr 属性を設定することがあります。このようなグループが作成されると、スタティックな外部メンバーを mgrpRfc822MailMember 属性にある電子メールアドレスを使用して追加できるようになります。メンバーの追加には uniqueMember 属性を使用したり、memberURL 属性に値を追加したりしないでください。これを行うと、MTA がメーリングリストのメンバーとして認識している内容と IMAP サーバーがグループメンバーとして認識している内容が切断されます。
ユーザーが IMAP サーバーにログインしたり、Messenger Express などの HTTP アクセスサービスクライアントを使用してログインすると、サーバーは aclGroupAddr 属性をほかのメッセージストア関連の属性とともに取り込み、グループ名をメモリにキャッシュします。サーバーはこの情報を使用して、クライアントがアクセス権の確認が必要なコマンド (LIST、SELECT など) を発行するたびにユーザーのアクセス権を判断します。
共有フォルダに関するタスクこの節では、共有フォルダ管理者のタスクについて説明します。
公開フォルダを作成するには
公開フォルダの場合は、LDAP データベースおよび readership コマンドへのアクセスが必要であるため、システム管理者が作成する必要があります。
- すべての公開フォルダのコンテナとして機能する LDAP ユーザーエントリを追加します。たとえば、public というエントリを追加します。
dn:cn=public,ou=people,o=sesta.com,o=ISP
objectClass:person
objectClass:organizationalPerson
objectClass:inetOrgPerson
objectClass:inetUser
objectClass:ipUser
objectClass:inetMailUser
objectClass:inetLocalMailRecipient
objectClass:nsManagedPerson
objectClass:userPresenceProfile
cn:public
mail:public@sesta.com
mailDeliveryOption:mailbox
mailHost:manatee.siroe.com
uid:public
inetUserStatus:active
mailUserStatus:active
mailQuota: -1
mailMsgQuota: 100
- mboxutil コマンドラインユーティリティを使用して、パブリックアカウント内にフォルダを作成します。
例 :
mboxutil -c user/public/golftournament
- readership コマンドラインユーティリティを使用して、このフォルダに適した ACL を設定します。
このフォルダを公開するためには、アクセスできるユーザーグループをフォルダに割り当てる必要があります。そのためには、readership コマンドを使用して ACL を設定します。ACL の設定方法については、この後に続く「公開フォルダのアクセス制御権を変更するには」を参照してください。
公開フォルダのアクセス制御権を変更するには
公開フォルダのアクセス制御を変更したり、新規に作成した公開フォルダのアクセス制御を設定したりする必要が生じることがあります。
これを実行するには、readership コマンドラインユーティリティを使用します。このコマンドの形式は、次のとおりです。
readership -s foldername identifier rights_chars
foldername は権限設定対象の公開フォルダの名前、userid は権限割り当て先の個人またはグループ、rights_chars は割り当てる権限です (これらは、RFC 2086 準拠のアクセス制御文字)。各文字の意味については、「ACL 権限を示す文字」を参照してください。公開フォルダのアクセス制御は、Messenger Express インタフェースを使用しても変更できます。
例
たとえば、sesta ドメインの全員に公開フォルダ golftournament の検索、読み取り、電子メールのマーク付けができる (ただし、送信は除く) アクセス権を付与する場合は、次のようにコマンドを発行します。
readership -s User/public/golftournament anyone@sesta lwr
検索、読み取り、電子メールのマーク付け、および送信する権限をグループに割り当てる場合は、次のようにコマンドを発行します。
readership -s User/public/golftournament group=golfinterest lwrp
このフォルダの管理者権限と送信権限を jdoe という個人に割り当てる場合は、次のようにコマンドを発行します。
readership -s User/public/golftournament jdoe lwrpa
公開フォルダへの個人またはグループのアクセスを拒否するには、ダッシュを userid の前に付けます。たとえば、jsmith の検索、読み取り、書き込み権限を拒否するには、次のようにコマンドを発行します。
readership -s User/public/golftournament -jsmith lwr
共有フォルダの一覧表示を有効化または無効化するには
設定オプション local.store.sharedfolders の設定によって、サーバーは LIST コマンドに対する応答として共有フォルダを返す場合と返さない場合があります。このオプションを off に設定すると、オプションは無効になります。デフォルトでは、この設定は有効 (on) になっています。
SELECT および LSUB コマンドは、このオプションの影響を受けません。LSUB コマンドは、すべての購読されているフォルダを返します。これには共有フォルダが含まれます。ユーザーは SELECT を使用して所有するフォルダや購読しているフォルダを選択できます。
分散共有フォルダを設定するには
通常、共有フォルダは特定のメッセージストア上のユーザーのみが使用できます。ただし、Messaging Server では、複数のメッセージストアからアクセスできる分散共有フォルダが作成できます。つまり、分散共有フォルダへのアクセス権は、メッセージストアグループ内の任意のユーザーに付与できます。ただし、Web メールクライアント (Messenger Express などの HTTP アクセスクライアント) では、リモートでの共有フォルダアクセスがサポートされていないことに注意してください。ユーザーは共有フォルダを一覧表示および購読できますが、内容を表示したり変更したりすることはできません。
分散共有フォルダでは、次の条件を満たす必要があります。
リモートのメッセージストア (つまり、共有フォルダを保持していないメッセージストア) は、表 15-4 に示されている設定変数を使用してプロキシサーバーとして設定されている必要があります。
表 15-4 分散共有フォルダの設定に使用する変数
名前
値
データ形式
local.service.proxy.serverlist
メッセージストアのサーバーリスト
スペースで区切られた文字列
local.service.proxy.admin
デフォルトのストア管理者ログイン名
文字列
local.service.proxy.adminpass
デフォルトのストア管理者パスワード
文字列
local.service.proxy.admin.hostname
特定ホスト用のストア管理者ログイン名
文字列
local.service.proxy.adminpass.hostname
特定ホスト用のストア管理者パスワード
文字列
分散共有フォルダの設定例
図 15-3 に、StoreServer1、StoreServer2、および StoreServer3 という 3 つのメッセージストアサーバーで共有する分散フォルダの例を示します。
図 15-3 分散共有フォルダの例
これらのサーバーは、表 15-4 で示されている変数を設定することによって、ピアプロキシメッセージストアとして互いに接続しています。各サーバーには、golf (Han が所有), tennis (Kat が所有)、および hurling (Luke が所有) という非公開共有フォルダがあります。さらに、press_releases および Announcements という 2 つの公開共有フォルダもあります。これら 3 つのサーバーのいずれかに存在するユーザーは、これら 3 つの共有フォルダすべてにアクセスできます。図 15-2 に、Ed の共有フォルダリストが示されています。次に、この構成における各サーバーの ACL の例を示します。
$ StoreServer1 :> readership -l
Ed: user/Han/golf
Ian: user/Han/golf
anyone: user/public/press_releases
$ StoreServer2 :> readership -l
Jan: user/Kat/tennis
Ann: user/Kat/tennis
anyone: user/public+Announcements user/public+press_releases
$ StoreServer3 :> readership -l
Tuck: user/Ian/hurling
Ed: user/Ian/hurling
Jac: user/Ian/hurling
anyone: user/public/Announcements
共有ファイルデータをモニターおよび保守するには
readership コマンドラインユーティリティを使用すると、folder.db、peruser.db、および lright.db の各ファイルに保存されている共有フォルダデータをモニターおよび保守できます。folder.db には、ACL のコピーが格納された各フォルダの記録があります。peruser.db には、ユーザーおよびメールボックスごとのエントリがあり、このエントリには、各種フラグ設定およびユーザーが任意のフォルダに前回アクセスした日付が示されています。lright.db には、全ユーザーの一覧があり、ユーザーが検索権限を持つ共有フォルダも示されています。
readership コマンドラインユーティリティでは次のオプションが使用できます。
表 15-5 readership オプション
オプション
説明
-d days
指定した日数以内にフォルダを選択したユーザーの数を共有フォルダごとに示すレポートを返す
-p months
指定した月数以内に共有フォルダを選択していなかったユーザーの peruser.db からデータを削除する
-l
lright.db のデータを一覧表示する
-s folder_identifier_rights
指定したフォルダにアクセス権を設定する。これによって、lright.db および folder.db が更新される
さまざまなオプションを使用して、次の機能を実行できます。
共有フォルダ使用状況をモニターするには
共有フォルダに積極的にアクセスしているユーザーの数を調べるには、次のコマンドを発行します。
readership -d days
days は、チェック対象とする日数です。このオプションではアクティブなユーザーの数が返されるのであって、アクティブなユーザーの一覧が返されるのではないことに注意してください。
例 : 過去 30 日以内に共有フォルダを選択したユーザーの数を調べるには、次のようにコマンドを発行します。
readership -d 30
ユーザーとその共有フォルダを一覧表示するには
ユーザーおよびユーザーがアクセスした共有フォルダを一覧表示するには、次のコマンドを発行します。
readership -l
出力例 :
$ readership -l
group=lee-staff@siroe.com: user/user2/lee-staff
richb: user/golf user/user10/Drafts user/user2/lee-staff user/user10/Trash
han1: user/public+hurling@siroe.com user/golf
gregk: user/public+hurling@siroe.com user/heaving user/tennis非アクティブなユーザーを削除するには
非アクティブなユーザー (指定の期間内に共有フォルダにアクセスしなかったユーザー) を削除するには、次のコマンドを発行します。
readership -p months
months は、チェックに使用する月数です。
例 : 過去 6 か月間に共有フォルダにアクセスしなかったユーザーを削除します。
readership -p 6
アクセス権を設定するには
新規の公開フォルダにアクセス権を割り当てたり、現在の公開フォルダのアクセス権を変更したりできます。
このコマンドを使用したアクセス権の設定方法の例については、「公開フォルダのアクセス制御権を変更するには」を参照してください。
メッセージストアの制限容量についてこの節では、以下の情報について説明します。
ユーザーの制限容量
ユーザーのメールボックスのサイズ制限を指定することで、メッセージストアのサイズを制限することができます。以下のタイプの制限容量を指定することができます。
制限容量の情報は、LDAP 属性および設定変数として保存されます。制限容量の適用が有効になっている場合、Messaging Server は、メッセージストアにメッセージを挿入する前に制限容量キャッシュと設定ファイルをチェックして、制限容量を超えないようにします。制限容量の通知が有効になっている場合、ユーザーがディスク制限容量に到達したら、エラーメッセージが送信されます。また、ユーザーが制限容量に近づいたらサーバーから警告メッセージを送信することも可能です。
すべてのユーザーに対してデフォルトの制限容量を設定することも、個々のユーザーに対して制限容量を設定することもできます。ユーザーが制限容量を超えているかどうかを判別するために、Messaging Server は、まず個々のユーザーに対する制限容量が設定されているかどうかを確認します。個別の制限容量が設定されていない場合、Messaging Server はすべてのユーザーに対して設定されているデフォルトの制限容量を確認します。
ユーザーのメッセージが制限容量を超えてしまった場合、以下のどちらかの状態になるまで、メッセージは MTA キューに残ったままとなります。
(1) ユーザーのメッセージのサイズまたは数が制限容量を超えない状態になったとき。この時点で MTA によってユーザーにメッセージが配信されます。(2) 未配信のメッセージが MTA キューに残留している期間が指定された猶予期間を超えてしまったとき。「猶予期間を設定するには」を参照してください。
ディスク容量は、ユーザーがメッセージを削除または消去したときや、設定された存続期間決定ポリシーに従ってサーバーがメッセージを削除したときに使用可能になります。
ドメインの制限容量
imquotacheck -f コマンドを使用して、特定のドメインにも制限容量を設定することができます。ドメインがその制限容量を超過すると、maildomainstatus 属性が overquotam に設定され、このドメインへの全配信が停止します。ドメインが overquota でない場合、値は active に設定されます。
Telephony Application Server に関する例外
統一されたメッセージング要件をサポートするために、Messaging Server ではメッセージストアによって課された制限容量を無効にする機能を提供しています。これにより、特定のエージェント、つまり Telephony Application Servers (TAS) が受け取ったメッセージが確実に配信されます。TAS によって受け入れられたメッセージは特別な MTA チャネルを通るようにルーティングされ、メッセージは制限容量に関係なくストアに配信されるようになります。TAS チャネルの設定の詳細については、第 10 章「チャネル定義を設定する」を参照してください。
メッセージストアの制限容量を設定するすべてのユーザー対するデフォルトの制限容量は、Sun ONE Console または configutil コマンドを使用して設定できます。また、個々のユーザー、ファミリーグループ、およびホストしているドメインについての制限容量も設定することができます。
この節では、以下のタスクについて説明します。
コンソールを使用する場合は、以下の手順に従います。
デフォルトのユーザー制限容量を指定するには
デフォルトの制限容量は、個別の制限容量がまだ設定されていないユーザーに適用されます。個別の制限容量の設定はデフォルトの制限容量よりも優先されます。
コンソール コンソールでデフォルトの制限容量を指定するには、以下の手順に従います。
- 「制限容量」タブをクリックします。
- デフォルトのユーザーディスク制限容量を指定するには、「デフォルトのユーザーディスク制限容量」フィールドで次のオプションのどちらかを選択します。
無制限: このオプションは、デフォルトのディスク制限容量を設定しない場合に選択します。
サイズ制限: このオプションは、デフォルトのユーザーディスク制限容量を特定のサイズに制限する場合に選択します。ボタンの横のフィールドに数字を入力し、ドロップダウンリストから「M バイト」または「K バイト」を選択します。
- メッセージ数の制限を指定する場合は、「デフォルトのユーザーメッセージ制限容量」ボックスに数字を入力します。
- 「保存」をクリックします。
コマンドライン メッセージの合計サイズについてのデフォルトのユーザーディスク制限容量を指定する場合は、以下のようになります。
configutil -o store.defaultmailboxquota -v [ -1 | number ]
ここで -1 は制限がないことを示し、number はバイト数を示します。
メッセージの合計数についてのデフォルトのユーザー制限を指定する場合、以下のようになります。
configutil -o store.defaultmessagequota -v [ -1 | number ]
ここで -1 は制限がないことを示し、number はメッセージ数を示します。
制限容量の適用と通知を有効にするには
制限容量の適用と通知は、有効にしたり無効にしたりすることができます。サーバーの動作は、表 15-6 に示すように、設定変数の設定方法によって異なります。
表 15-6 制限容量の適用と通知
適用オン
適用オフ
通知オン
メッセージは指定された猶予期間まで据え置かれます。猶予期間が切れたら拒否されます。メッセージをメールボックスに追加することはできません。
IMAP SELECT、IMAP APPEND、SMTP メール送信機能、および配信コマンドによってエラーメッセージが表示されます。
メッセージがストアに配信されます。メッセージをメールボックスに追加することができます。
IMAP SELECT、IMAP APPEND、SMTP メール送信機能、および配信コマンドはエラーメッセージを表示しません。
通知オフ
メッセージは指定された猶予期間まで据え置かれます。猶予期間が切れたら拒否されます。メッセージをメールボックスに追加することはできません。
IMAP SELECT コマンド、配信コマンド、および SMTP メール送信機能はエラーメッセージを表示しません。
IMAP APPEND コマンドによってエラーメッセージが表示されます。
メッセージがストアに配信されます。メッセージをメールボックスに追加することができます。
IMAP SELECT、IMAP APPEND、SMTP メール送信機能、および配信コマンドはエラーメッセージを表示しません。
制限容量の適用を有効にする
コンソール コンソールで制限容量の適用を有効にするには、以下の手順に従います。
コマンドライン コマンドラインで制限容量の適用を有効または無効にするには、以下のようにします。
configutil -o store.quotaenforcement -v [ on | off]
メッセージストアが制限容量を超過する原因になるメッセージを拒否するには、以下のようにします。
configutil -o local.store.quotaoverdraft -v off
制限容量を超えた後に適用を開始する (つまり、メッセージストアが制限容量を超過する原因となるメッセージを許可してから、制限容量の適用を開始する) には、上記の値を on に設定します。デフォルトは off です。
制限容量の通知を有効にする
コンソール コンソールで制限容量の通知を有効にするには、以下の手順に従います。
- 「制限容量」タブをクリックします。
- 「容量制限有効化の通知」ボックスにチェックマークを付けます。
このボックスでオンとオフの切り替えを行います。制限容量の通知を無効にするには、このボックスのチェックマークを外します。
- 制限容量の警告メッセージを定義します。
「制限容量の警告メッセージの定義」を参照してください。
- 「保存」をクリックします。
コマンドライン コマンドラインで制限容量の通知を有効にする場合は、以下のようになります。
configutil -o store.quotanotification -v [ yes | no ]
configutil -o store.quotaexceededmsg -v messagemessage に何も設定されなかった場合、ユーザーには制限容量の警告メッセージは送信されません。制限容量の警告メッセージの形式については、次の節を参照してください。
制限容量の警告メッセージの定義
ディスク制限容量を超えたユーザーに送信するメッセージは、以下の手順で定義することができます。メッセージはユーザーのメールボックスに送られます。
コンソール コンソールで制限容量の警告メッセージを定義するには、以下の手順に従います。
コマンドライン コマンドラインで制限容量の警告メッセージを定義する場合は、以下のようになります。
configutil -o store.quotaexceededmsg -v message
メッセージは RFC 822 形式でなければなりません。メッセージには少なくとも件名行を含むヘッダーがあり、$$、メッセージ本文がその後に続いている必要があります。$ は、新しい行を表します。
例 :
configutil -o store.quotaexceededmsg -v 'Subject:WARNING:User quota exceeded$$User quota threshold exceeded - reduce space used.'
警告メッセージの送信頻度を定義する場合は、以下のようになります。
configutil -o store.quotaexceededmsginterval -v number
この number は日数を示しています。たとえば、3 が入っていれば 3 日ごとにメッセージが送信されます。
制限容量のしきい値の指定
制限容量のしきい値を指定すれば、IMAP ユーザーがディスク制限容量に到達する前に、警告メッセージを送ることができます。ユーザーのディスク使用量が指定したしきい値を超えたら、サーバーからユーザーに警告メッセージが送信されます。
クライアントが IMAP ALERT 機能をサポートしている IMAP ユーザーの場合は、ユーザーがメールボックスを選択するたびに画面にメッセージが表示されます (メッセージは IMAP ログにも書き込まれる)。
コンソール コンソールで制限容量のしきい値を指定するには、以下の手順に従います。
コマンドライン コマンドラインで制限容量のしきい値を指定する場合は、以下のようになります。
configutil -o store.quotawarn -v number
この number は許可された制限容量のパーセンテージを示しています。
猶予期間を設定するには
猶予期間は、メッセージを差出人にバウンスするまでメールボックスが制限容量 (ディスク容量やメッセージの数) を超えた状態でいられる期間を指定するものです。MTA がメッセージを受け取っても、メッセージは MTA キューに残り、次のいずれかの状況が発生するまでメッセージストアには配信されません。
たとえば、猶予期間が 2 日間に設定されているときに 1 日分の制限容量を超えた場合、新しいメッセージは引き続き受信され、メッセージキュー内に保持され、配信試行は続行します。2 日目を過ぎると、メッセージはバウンスされます。
注
猶予期間とは、メッセージがメッセージキュー内に保持される期間ではなく、メッセージキュー内に含まれているすべての受信メッセージがバウンスされるまでに、メールボックスが制限容量を超えた状態でいられる期間です。猶予期間は、ユーザーが制限容量のしきい値に達し (「制限容量のしきい値の指定」を参照)、警告を受けたときに開始します。
コンソール コンソールで、メッセージがキューに保持される猶予期間を設定するには、以下の手順に従います。
コマンドライン コマンドラインで制限容量の猶予期間を指定する場合は、以下のようになります。
configutil -o store.quotagraceperiod -v number
この number は時間数を示しています。
自動メッセージ削除 (有効期限およびパージ) 機能を設定するには自動メッセージ削除機能 (有効期限切れおよびパージとも呼ばれる) を使用すると、管理者が定義した一連の条件に基づいて、メッセージストアからメッセージが自動的に削除されます。この機能によって、古いメッセージやサイズの大きいメッセージ、開封済みまたは削除済みメッセージ、特定の Subject: 行を持つメッセージなどを自動的に削除できます。次の削除条件が設定できます。
この機能は、メッセージの消去やパージを行う imexpire ユーティリティを使用して実行します。メッセージ削除プロセスの詳細については、「メッセージストアによるメッセージの削除方法」を参照してください。
注
サーバーによってメッセージは警告なしに削除されます。したがって、自動メッセージ削除ポリシーについてユーザーに知らせておくことは重要です。メッセージが突然削除されると、ユーザーや管理者は大変驚くことになるからです。
imexpire の動作方式
imexpire は、コマンドラインから呼び出すか、imsched デーモンを使用して自動的に実行されるようにスケジュールします。管理者は、コンソールまたは configutil コマンドラインユーティリティを使用して、グローバル有効期限ルール (メッセージストア全体に適用されるルール) を設定します。ローカル有効期限ルール (フォルダまたはユーザーに適用されるルール) は、有効期限ルールファイル (store.expire) をメッセージストアパーティション、ユーザーまたはメールボックスディレクトリに作成することで設定できます。
imexpire は、起動時にすべての有効期限ルールをロードします。デフォルトでは、imexpire はパーティションごとに 1 つのスレッドを作成します。各スレッドは割り当てられたパーティションの下にあるユーザーフォルダのリストを通過し、その間にローカル有効期限ルールをロードします。この有効期限機能により、各フォルダは有効期限ルールに照らしてチェックされ、メッセージは必要に応じて消去されます。メールボックスディレクトリの内に store.exp ファイルが存在し、store.cleanupage 設定パラメータで指定した期間を過ぎていたために消去されたり期限切れになっているメッセージがある場合は、パージ機能によってメッセージハッシュディレクトリ内にあるメッセージファイルが完全に削除され、store.exp ファイルからユーザー ID のレコードが削除されます。
自動メッセージ削除機能を配備するには
自動メッセージ削除は、コマンドラインを使用するか、コンソールの GUI を使用して配備できます。このプロセスには 次の 3 つの手順があります。
- 自動メッセージ削除ポリシーを定義します。自動削除するメッセージ、自動削除するメッセージを所有しているユーザー、ドメイン、パーティション、およびサイズ、メッセージ存続期間、ヘッダーについて特定して削除条件を定義します。「自動メッセージ削除ポリシーを定義するには」を参照してください。
- imexpire ルールを指定してこのポリシーを実装します。「自動メッセージ削除ポリシーを実装するルールを設定するには」を参照してください。
- imexpire スケジュールを指定する「自動メッセージ削除とログレベルをスケジュールするには」を参照してください。
自動メッセージ削除ポリシーを定義するには
削除条件を指定して独自の自動メッセージ削除ポリシーを定義します。Imexpire を使用すると、次の条件を使用する削除が可能になります。
メッセージの存続期間: X 日間より存続期間が長いメッセージを自動的に削除します。属性 : messagedays。
メッセージの件数: X 件を超えたフォルダ内のメッセージを自動的に削除します。属性 : messagecount。
サイズ超過メッセージの存続期間: X バイトを超えるメッセージを Y 日間の猶予期間後に自動的に削除します。属性 : messagesize および messagesizedays。
開封済みおよび 削除済みメッセージフラグ: 「開封済み」または「削除済み」フラグが付いているメッセージを自動的に削除します。これらの条件には、「and」または「or」が設定できます。or に設定した場合、メッセージに開封済みまたは削除済みフラグが付いていると、ほかの条件にかかわらず自動削除されます。and に設定した場合、メッセージに付いている開封済みまたは削除済みフラグは、指定したほかの条件すべてを満たした場合に設定されます。属性 : seen および deleted。
メッセージのヘッダーフィールド: メッセージを削除する条件としてヘッダーおよび文字列を指定できます。たとえば、「Subject: Work from Home!」というヘッダーがあるメッセージをすべて削除できます。
メッセージのフォルダ: メッセージを削除するフォルダを指定できます。属性 : folderpattern
注
imexpire を使用して、メッセージが開封されてからの期間に基づいてメッセージを削除または保存することはできません。たとえば、200 日経過しても読まれていないメッセージを削除するという指定はできません。
自動メッセージ削除ポリシーの例
例 1 : 1,000 件を超えるメッセージが存在するフォルダ内の、存続期間が 365 日のメッセージをすべて削除する
例 2 : ドメイン siroe.com 内の、存続期間が 180 日を超えるメッセージを削除する
例 3 :「削除済み」のマークが付いているメッセージをすべて削除する
例 4 : sesta.com 内の 1,000 件を超えるメッセージが存在するフォルダから、「開封済み」マークが付いていて、存続期間が 30 日より長く、サイズが 100K バイトより大きく、X-spam というヘッダーが付いたメッセージを削除する
自動メッセージ削除ポリシーを実装するルールを設定するには
前の節で定義した自動メッセージ削除ポリシーを実装するには、imexpire ルールを設定する必要があります。ルールは、次の方法で設定できます。
- GUI を使用する (図 15-4 を参照)
- store.expirerule.attribute configutil パラメータを設定する
この例では、Rule 1 でごみ箱フォルダ内のすべてのメッセージが 2 日後に削除されることを指定しています。Rule 2 ではメッセージストアのすべてのメッセージが 14 日後に削除されることを指定しています。
有効期間ルールのガイドライン
ここでは、store.expirerule.attribute configutil パラメータおよび store.expirerule ファイルのルールについてのガイドラインを示します。
- ルールは store.expirerule というファイルに指定するか、configutil パラメータの store.expirerule.rulename.attribute を使用して指定します。
- 同一のルールで複数の有効期限条件が指定できます (上記の例を参照)。
- ルールはメッセージストア全体に適用でき (グローバルルール)、メッセージストアパーティション、ユーザー、フォルダごとにも適用できます。グローバルルール以外は、store.expirerule ルールを使用してのみ作成できます。
- グローバルルールは、configutil パラメータの store.expirerule.rulename.attribute を使用するか、msg_svr_base/config/store.expirerule にルールを指定して作成する
- パーティションルールは、store_root/partition/partition_name/store.expirerule にルールを指定して作成できる
- ユーザールールは、store_root/partition/partition_name/userid/store.expirerule にルールを指定するか、folderpattern ルールをuser/userid/.* となるように指定して作成できる
- 複数の有効期限ルールが同時に 1 つのメールボックスに適用できます。メールボックスに対する有効期限ポリシーは、グローバルルールとローカルルールで構成されます。ローカルルールは同一ディレクトリのメールボックスおよびそのサブフォルダのすべてに適用されます。
- imexpire によって、メールボックスに排他的なルールが指定されていないかぎり、そのメールボックスに適用されているすべての有効期限ルールが結合されます (表 15-7 を参照)。その結果、ルールセットには、すべての適用可能なルールの中からもっとも制約度の高い有効期限ポリシーが採用されます。たとえば、メッセージの最長存続期間がルール X によって 10 日間、ルール Y によって 5 日間と指定されている場合、結合結果は 5 日間となります。
表 15-7 imexpire 属性
属性
説明 (属性値)
exclusive
ルールが排他的であるかどうかを指定する。exclusive として指定すると、指定したメールボックスにこのルールのみが適用され、これ以外のルールはすべて無視される。複数の排他的なルールが存在する場合、最後にロードされた排他的なルールが使用される。たとえば、グローバルな排他的ルールおよびローカルな排他的ルールが指定された場合、ローカルルールが使用される。グローバルな排他的ルールが複数存在する場合、 configutil によって最後にリストされたグローバルルールが使用される (yes/no)
folderpattern
このルールによって影響を受けるフォルダを指定する。形式は user/ で始まる必要があり、これはディレクトリ store_root/partition/*/ を表す。図 15-4 および表 15-8 を参照 (POSIX 正規表現)
messagecount
フォルダ内の最大メッセージ数。この数を超える新しいメッセージが配信されると、もっとも古いメッセージが消去される (整数)
foldersize
新しいメッセージが配信されたときにもっとも古いメッセージが消去される前のフォルダの最大サイズ (整数、バイト単位)
messagedays
メッセージが消去されるまでの存続期間 (日数)(整数)
messagesize
消去のマークが付けられる前のメッセージの最大サイズ (単位 : バイト)(整数)
messagesizedays
猶予期間。サイズを超過しているメッセージをフォルダに残す日数 (整数)
メッセージのヘッダーフィールド
メッセージに削除のマークを付けるためのヘッダーフィールドと文字列を指定する。値は大文字と小文字が区別されず、正規表現は認識されない。
例 : Rule1.Subject:Get Rich Now!Expires ヘッダーや Expiry-Date ヘッダーについては、これらのヘッダーフィールドで指定された日付の値が messagedays 属性よりも古い場合、imexpire によってそのメッセージは削除される。複数の有効期限ヘッダーフィールドが指定されている場合は、もっとも早い有効期限日が使用される (文字列)
regexp
UNIX 正規表現をルール作成において有効にする (1 または 0)
seen
seen はメッセージのステータスフラグの 1 つであり、ユーザーがメッセージを開いたときにシステムによって設定される。seen 属性が and に設定されている場合、メッセージが開封済みであり、かつ、ほかの条件が満たされていればルールは適用される。seen 属性が or に設定されている場合、メッセージが開封済みであるか、または、もう 1 つの条件が満たされていればルールは適用される (and/or)
deleted
deleted はメッセージのステータスフラグの 1 つであり、ユーザーがメッセージを削除ときにシステムによって設定される。属性 deleted が and に設定されている場合、メッセージが削除済みであり、かつ、もう 1 つの条件が満たされいればルールは適用される。属性 deleted が or に設定されている場合、メッセージが削除済みであるか、または、もう 1 つの条件が満たされていればルールは適用される (and/or)
imexpire ルールをテキストモードで設定する
自動メッセージ削除ルールは、configutil パラメータの store.expirerule.rulename.attribute を使用してテキストモードで設定するか、store.expirerule ファイルにルールを指定して設定できます。
store.expirerule ファイルは、1 行につき 1 つの有効期限条件を含みます。グローバルルール設定ファイル (msg_svr_base/data/store/store.expirerule) の有効期限条件は、次の形式になっています。
rule_name.attribute:value
コード例 15-1 に、msg_svr_base/config/store.expirerule の一連の有効期限ルールを示します。
Rule 1 では、グローバル有効期限ポリシー (すべてのメッセージに適用されるポリシー) を設定しています。設定内容は次のとおりです。
Rule 2 では、ホストしているドメインが siroe.com のユーザーに対して自動メッセージ削除ポリシーを設定しています。メールボックスサイズを 1M バイトに制限し、削除済みメッセージを削除し、存続期間が 14 日より長いメッセージを削除します。
Rule 3 では、ユーザー f.dostoevski の inbox フォルダに対して自動メッセージ削除ポリシーを設定しています。「On-line Casino」という件名行のあるメッセージを削除します。
コード例 15-1 imexpire ルールの例
Rule1.regexp: 1
Rule1.folderpattern:user/.*
Rule1.messagesize: 100000
Rule1.messagesizedays: 3
Rule1.deleted:or
Rule1.Subject:Viagra Now!
Rule1.Subject:XXX Porn!
Rule1.messagecount: 1000
Rule1.messagedays: 365
Rule2.regexp: 1
Rule2.folderpattern:user/.*@siroe.com/.*
Rule2.exclusive:yes
Rule2.deleted:or
Rule2.messagedays: 14
Rule2.messagecount: 1000
Rule3.folderpattern:user/f.dostoevski/inbox
Rule3.Subject:*On-line Casino*
これと同じグローバル有効期限ポリシーは、次のように configutil で設定できます。
% configutil store.expirerule.rule1.regexp 1
% configutil store.expirerule.rule1.messagesizedays 3
% configutil store.expirerule.rule1.deleted or
% configutil store.expirerule.rule1.Subject Viagra Now!
% configutil store.expirerule.rule1.Subject XXX Porn!
% configutil store.expirerule.rule1.messagecount 1000
% configutil store.expirerule.rule1.messagedays 365
% configutil store.expirerule.rule1.messagesize 100000imexpire フォルダパターンを設定する
フォルダパターンは POSIX 正規表現を使用して指定できます。形式はuser/ で始まる必要があり、これはディレクトリ store_root/partition/*/ を表します (表 15-8 に、各種フォルダのフォルダパターンを示す)。
表 15-8 imexpire フォルダパターン
フォルダパターン
範囲
user/userid/.*
userid の全フォルダ内の全メッセージにルールを適用する
user/userid/Sent
フォルダ Sent 内の userid のメッセージにルールを適用する
user/.*
メッセージストア全体にルールを適用する
user/.*/trash
すべてのユーザーの trash フォルダにルールを適用する
user/.*@siroe.com/.*
ホストしているドメイン siroe.com: のフォルダにルールを適用する
user/[^@]*/.*
デフォルトドメインのフォルダにルールを適用する
user/partition_name/.*
特定のパーティションにルールを適用する
コンソールを使用して自動メッセージ削除ルールを設定するには
- 次の操作で自動メッセージ削除の GUI を呼び出します。
メインコンソール -> サーバーグループ -> Messaging Server (開く) -> Messaging Server コンソール -> 構成タブ -> メッセージストア -> 有効期限またはパージ -> 追加
この GUI の略図を図 15-4 に示します。
図 15-4 自動メッセージ削除 (有効期限またはパージ) GUI - 略図
- 新しいルールの名前を入力します。
- メッセージを自動的に削除するフォルダを入力します。
前述の「imexpire フォルダパターンを設定する」を参照してください。
- このルールが指定した条件と一致するフォルダに対する排他的なルールである場合は、「除外」ボックスをクリックします。
このボックスにチェックマークを付けると、このルールが、指定したパターンに一致するほかのすべてのルールに優先します。「除外」チェックボックスの詳細については、表 15-7 を参照してください。
- フォルダサイズに基づいてルールを作成するには、以下を実行します。
- メッセージの存続期間に基づいてルールを作成するには、「メッセージ存続期間の制約」チェックボックスにチェックマークを付けます。
「日数」フィールドで、メッセージがフォルダに保持される期間を日数で指定します。
- メッセージサイズに基づいてルールを作成するには、以下を実行します。
- 「開封済み」または「削除済み」メッセージフラグが設定されているかどうかに基づいてルールを作成するには、以下を実行します。
- 「メッセージフラグの制約」チェックボックスにチェックマークを入れます。
- 「開封済み :」フィールドでは、「および」を選択すると、メッセージが開封済みであり、かつ、もう 1 つの条件を満たしている場合にルールを適用することを指定できます。「または」を選択すると、メッセージが開封済みであるか、または、もう 1 つの条件を満たしている場合にルールを適用することを指定できます。
- 「削除済み :」フィールドでは、「および」を選択すると、メッセージが削除済みであり、かつ、もう 1 つの条件を満たしている場合にルールを適用することを指定できます。「または」を選択すると、メッセージが削除済みであるか、または、もう 1 つの条件を満たしている場合にルールを適用することを指定できます。
- ヘッダーフィールドとその値に基づいてルールを作成するには、以下を実行します。
- 「OK」をクリックすると、新しいルールが自動メッセージ削除リストに追加されます。
自動メッセージ削除とログレベルをスケジュールするには
自動メッセージ削除は、imsched スケジューリングデーモンによってアクティブになります。デフォルトでは、imsched は毎日 23:00 に imexpire を呼び出し、メッセージは消去およびパージされます。このスケジュールは、configutil パラメータの local.schedule.expire、local.schedule.purge、および store.cleanupage を設定することによってカスタマイズできます。表 15-9 を参照してください。
有効期限およびパージは、大きなメッセージストアでは完了するまでに時間のかかることがあるので、これらのプロセスの実行頻度は実験して決定することをお勧めします。たとえば、有効期限およびパージの 1 サイクルに 10 時間かかる場合、有効期限およびパージのデフォルトスケジュールを 1 日に 1 回とするわけにはいきません。local.schedule.purge を使用して有効期限およびパージを設定し、パージが別のスケジュールで実行されるように指定します。local.schedule.purge が設定されていない場合、imexpire は有効期限を実行した後にパージを実行します。
表 15-9 有効期限およびパージ configutil ログおよびスケジュールパラメータ
パラメータ
説明
local.schedule.expire
imexpire の実行間隔。次の UNIX crontab フォーマットを使用する。
minute hour day-of-month month-of-year day-of-week値はスペースまたはタブで区切る。それぞれ 0 〜 59、0 〜 23、1 〜 31、1 〜 12、0 〜 6 (0=日曜日) の範囲で指定できる。各時間フィールドは、アスタリスク (すべての適正な値を示す)、値をコンマで区切ったリスト、2 つの値をハイフンで区切って示した範囲のいずれかになる。日は、「日」と「曜日」の両方で指定できることに注意する。ただし、このような発生回数は非常に少ないので、通常、両方で指定することはない。日と曜日の両方で指定した場合、その両方が必須条件になる。たとえば、17 日と火曜日を設定すると、両方の値が真であることが求められる
実行間隔の例
1) imexpire を 12:30 am、8:30 am、および 4:30 pm に実行する
30 0,8,16 * * *2) imexpire を平日の 3:15 am に実行する
15 3 * * 1-53) imexpire を毎週月曜のみに実行する
0 0 * * 1デフォルト : 0 23 * * *
local.schedule.purge
purge の実行間隔。次の UNIX crontab フォーマットを使用する。
minute hour day-of-month month-of-year day-of-weekデフォルト :0 0,4,8,12,16,20 * * * /opt/SUNWmsgsr/lib/purge -num=5
(4 時間ごと)store.cleanupage
有効期限切れのメッセージまたは消去されたメッセージが purge によって永久に削除されるまでの存続期間 (単位 : 時間)
デフォルト :なし
local.store.expire.loglevel
ログレベルを指定する。
1 = 有効期限セッション全体の要約を記録する
2 = 有効期限切れのメールボックスごとに 1 つのメッセージを記録する
3 = 有効期限切れのメッセージごとに 1 つのメッセージを記録するデフォルト : 1
コンソールを使用した場合の imexpire スケジュール
次の操作で自動メッセージ削除の GUI を呼び出します。
メインコンソール -> サーバーグループ -> Messaging Server (開く) -> Messaging Server コンソール -> 構成タブ -> メッセージストア -> 有効期限またはパージ
このコンソールページでは、有効期限ルールが上部に、有効期限およびパージスケジュールが下部に一覧表示されます。有効期限およびパージをスケジュールするには、「有効期限/パージスケジュール」のプルダウンメニューを使用して、有効期限とパージの両方の月、日、曜日 (0=日曜日)、時、分を設定します。
注
日の値は、「日」と「曜日」の両方で設定できます。両方で設定した場合、両方が評価されます。水曜日と 17 日を設定した場合、パージおよび有効期限は、17 日が水曜日にあたった場合にのみ実行されます。
imexpire ログレベルを設定する
imexpire が完了すると、デフォルトのログファイルに要約が記録されます。有効期限をコマンドラインから呼び出す場合は、 -v (詳細) および -d (デバッグ) の各オプションを使用して、詳細ステータスまたはデバッグメッセージを stderr に記録するように imexpire に指示できます。imsched を使用して imexpire を呼び出す場合は、configutil パラメータの local.store.expire.loglevel を 1、2、または 3 に設定して各ログレベルを選択できます。Loglevel 1 はデフォルトで、有効期限セッション全体の要約が記録されます。Loglevel 2 では、有効期限切れのメールボックスごとに 1 つのメッセージが記録されます。Loglevel 3 では、有効期限切れのメッセージごとに 1 つのメッセージが記録されます。
メッセージストアのパーティションを構成するメールボックスはメッセージストアパーティションに格納されます。メッセージストアパーティションとは、ディスクパーティション上の、メッセージストアを格納するための専用エリアです。メッセージストアパーティションはディスクパーティションと同じではありませんが、管理の便宜をはかるために、各メッセージストアパーティション用に 1 つのディスクパーティションと 1 つのファイルシステムを使用することをお勧めします。メッセージストアパーティションは、メッセージストアとして特に指定されたディレクトリです。
デフォルトでは、ユーザーメールボックスは store_root/partition/ ディレクトリに保存されています (図 15-1 を参照)。partition ディレクトリは、単一または複数のパーティションを格納している論理的なディレクトリです。起動時には、partition ディレクトリに primary パーティションと呼ばれるサブパーティションが格納されています。
必要に応じて partition ディレクトリにパーティションを追加できます。たとえば、ユーザーを体系化するために 1 つのディスクを分割する場合、以下のようになります。
store_root/partition/mkting/
store_root/partition/eng/
store_root/partition/sales/ディスクストレージに対する要求が高まるに従い、これらのパーティションを異なる物理ディスクドライブにマッピングする必要が生じてくると考えられます。
どのディスクでもメールボックスの数を制限しなければなりません。メールボックスを複数のディスクに分散させることにより、メッセージ配信時間を短縮することができます (ただし、必ずしも SMTP の受け入れ率が変更されるわけではない)。ディスクごとに割り当てるメールボックスの数は、ディスク容量や各ユーザーに割り当てられたディスク容量によって異なります。たとえば、ユーザーごとのディスク容量の割り当て量が少ない場合は、ディスクごとに割り当てるメールボックスの数を多くできます。
メッセージストアに複数のディスクを必要とする場合、RAID (Redundant Array of Inexpensive Disks) 技術を使用すれば複数ディスクの管理を容易に行うことができます。RAID 技術によってデータを一連のディスクに分散させることができます。このときディスクは単一の論理ボリュームとして表示されるので、ディスク管理が簡単になります。また、冗長性を得るために RAID 技術を使用することもできます。つまり、障害復旧用にストアを複製する目的で使用することができるわけです。
パーティションを追加するには
パーティションを追加する場合、ディスク上でパーティションが保存されている場所の絶対的な物理パスと、パーティションニックネームと呼ばれる論理名を指定します。
パーティションニックネームにより、物理パスに関係なくユーザーを論理的なパーティション名にマッピングさせることができます。ユーザーアカウントの設定時やユーザーのメッセージストアを指定するときに、パーティションニックネームを使用できます。名前の入力に使用するのは英数字で、アルファベットは小文字を使用してください。
パーティションを作成および管理するには、サーバーの実行に使用するユーザー ID が、物理パスで指定した場所への書き込み権限を持っていなければなりません。
コンソール コンソールを使用してストアにパーティションを追加するには、以下の手順に従います。
- 構成を行う Messaging Server をコンソールから開きます。
- 「構成」タブをクリックして、左のペインの「メッセージストア」を選択します。
- 右のペインの「パーティション」タブをクリックします。
- 「追加」ボタンをクリックします。
- パーティションニックネームを入力します。
これは指定したパーティションの論理名です。
- パーティションのパスを入力します。
これは指定したパーティションの絶対パス名です。
- これをデフォルトのパーティションに指定するには、「デフォルトのパーティションにする」というラベルの付いた選択ボックスをクリックします。
- 「OK」をクリックしてこのパーティション構成エントリを送信し、ウィンドウを閉じます。
- 「保存」をクリックして現在のパーティションリストを送信し保存します。
コマンドライン コマンドラインでストアにパーティションを追加する場合は、以下のようになります。
configutil -o store.partition.nickname.path -v path
ここで、nickname はパーティションの論理名、path はパーティションが保存されている場所の絶対パス名を示しています。
デフォルトのプライマリパーティションのパスは次のように指定します。
configutil -o store.partition.primary.path -v path
メールボックスを別のディスクパーティションに移動するには
特に設定を変更しないかぎり、メールボックスは primary パーティション内に作成されます。このパーティションの容量が一杯になると、メッセージを保存することができなくなります。この問題には、次のような対応策があります。
- ユーザーのメールボックスのサイズを小さくする
- 容量管理ソフトウェアを使用している場合、別のディスクを追加する
- 別のパーティションを作成し (「パーティションを追加するには」)、メールボックスを新しいパーティションに移動する
可能なかぎり、容量管理ソフトを使用して、システムにディスク容量を追加する方法をお勧めします。これは、この方法がユーザーにとってもっとも透過性が高いからです。ただし、次の手順に従って、メールボックスを別のパーティションに移動することもできます。
- 移行プロセス中は、ユーザーがメールボックスに接続していない状態にしてください。このためには、ユーザーに通知を出して、メールボックスの移動作業を行う前にログオフし、作業期間中にログオンしないように指示します。または、ユーザーがログオフしたあと、POP、IMAP、および HTTP のサービスを使用できないように mailAllowedServiceAccess 属性を設定します (『Sun ONE Messaging Server スキーマリファレンス』を参照)。
- ユーザーのメールボックスを移動するには、次のコマンドを使用します。
mboxutil -r user/<userid>/INBOX user/<userid>/INBOX <partition_name>
例 :
mboxutil -r user/ofanning/INBOX user/ofanning/INBOX secondary
- 移動したユーザーの LDAP エントリで mailMessageStore 属性を新しいパーティションの名前に設定します。
例 : mailMessageStore:secondary
- ユーザーにメッセージストアへの接続が再開されたことを通知します。必要に応じて、POP、IMAP、および HTTP サービスを使用できるように mailAllowedServiceAccess 属性を変更します。
メッセージストアの保守手順を実行するこの節では、メッセージストアの保守タスクと回復タスクを実行するのに使用するユーティリティについて説明します。サーバーから送信される警告のためのポストマスターメールを常に読む必要があります。また、サーバーの実行状況に関する情報を記録したログファイルをモニターする必要もあります。ログファイルの詳細については、第 17 章「ログ記録とログ解析」を参照してください。
この節では以下の内容について説明します。
メールボックスを管理するには
この節では、メールボックスの管理およびモニターを行う次のユーティリティについて説明します。mboxutil, hashdir, readership.
mboxutil ユーティリティ
mboxutil コマンドを使用して、メールボックスの一般的な保守タスクを実行します。mboxutil プロセスを実行途中で強制終了しないでください。SIGKILL (kill -9) で強制終了すると、各サーバーを再起動し、回復処理を行わなければならないことがあります。
mboxutil タスクには以下のものが含まれます。
また、mboxutil コマンドを使用して制限容量に関する情報を表示することもできます。詳細は、「制限容量をモニターするには」を参照してください。
表 15-10 に mboxutil コマンドの一覧を示します。構文や使用要件の詳細については、『Messaging Server リファレンスマニュアル』を参照してください。
表 15-10 mboxutil オプション
オプション
説明
-a
すべてのユーザーの制限容量に関する情報を表示する
-c mailbox
指定したメールボックスを作成する
-d mailbox
指定したメールボックスを削除する
-f file
指定したデータファイルにリストされているメールボックスを、作成、削除、またはロックする
-k mailbox cmd
指定したメールボックスをフォルダレベルでロックし、指定したコマンドを実行し、コマンドが完了したらメールボックスのロックを解除する
-l
サーバーのすべてのメールボックスを一覧表示する
-p pattern
-l オプションとともに使用した場合、名前がpattern と一致するメールボックスのみが一覧表示される。POSIX 正規表現を使用できる
-q domain
指定したドメインの制限容量に関する情報を一覧表示する
-r oldname newname
[partition]メールボックスの名前を現在の名前から新規の名前に変更する。フォルダを別のパーティションに移動するには、partition オプションに新しいパーティションを指定する。
このオプションを使用してユーザー名を変更することができる。たとえば、mboxutil -r user/user1/INBOX user/user2/INBOX では、user1 のすべてのメールとメールボックスが user2 に移動し、新しいメッセージは新しい INBOX に表示される (user2 がすでに存在している場合は、この操作は失敗する)
-u user
メールストアの現在のサイズ、制限容量 (設定されている場合)、現在使用されている制限容量の割合など、ユーザーのメールストアのサイズに関する情報を一覧表示する
-x
-l オプションとともに使用すると、メールボックスのパスとアクセス制御が表示される
メールボックスのネーミングルール
メールボックス名は、次のフォーマットで指定します。user/userid/mailbox。ここで、userid はメールボックスを所有するユーザー、mailbox はメールボックスの名前を表します。ホストしているドメインでは、userid は uid@domain です。
たとえば次のコマンドでは、ユーザー ID が crowe であるユーザーの、INBOX という名前のメールボックスが作成されます。INBOX は、ユーザー crowe に配信されたメール用のデフォルトのメールボックスとなります。
mboxutil -c user/crowe/INBOX
重要 : INBOX という名前は、各ユーザーのデフォルトのメールボックス用に確保してある名前です。INBOX は、大文字と小文字が区別されない唯一のフォルダ名です。ほかのフォルダ名はすべて大文字と小文字が区別されます。
例
全ユーザーの全メールボックスを一覧表示するには :
mboxutil -l
すべてのメールボックスを、パスと ACL の情報とともに一覧表示するには :
mboxutil -l -x
ユーザー daphne に対し、INBOX というデフォルトのメールボックスを作成するには :
mboxutil -c user/daphne/INBOX
ユーザー delilah に対し、projx という名前のメールフォルダを削除するには :
mboxutil -d user/delilah/projx
ユーザー druscilla について、INBOX というデフォルトのメールボックスとすべてのメールフォルダを削除するには :
mboxutil -d user/druscilla/INBOX
ユーザー desdemona の memos というメールフォルダの名前を、memos-april という名前に変更するには :
mboxutil -r user/desdemona/memos user/desdemona/memos-april
ユーザー dulcinea の legal という名前のメールフォルダをロックするには :
mboxutil -k user/dulcinea/legal cmd
この場合の cmd は、フォルダがロックされている間に実行するコマンドです。
ユーザー dimitria のメールアカウントを新しいパーティションに移動するには :
mboxutil -r user/dimitria/INBOX user/dimitria/INBOX partition
この場合、partition には新しいパーティションの名前を指定します。
ユーザー dimitria のメールフォルダ personal を新しいパーティションに移動するには :
mboxutil -r user/dimitria/personal user/dimitria/personal partition
hashdir ユーティリティ
メッセージストア内のメールボックスは、高速で検索できるようにハッシュ構造で保存されています。したがって、特定のユーザーのメールボックスを格納するディレクトリを検索するには、hashdir ユーティリティを使用します。
このユーティリティは、特定のアカウントのメッセージストアを含むディレクトリを識別します。また、メッセージストアへの相対パスをレポートします。これは d1/a7/ のようになります。このパスは、ユーザー ID に基づくディレクトリの 1 つ上のディレクトリレベルを基準にしたものです。このユーティリティによってパス情報が標準出力に送られます。
たとえば、ユーザー crowe のメールボックスへの相対パスを検索する場合は次のようになります。
hashdir crowe
readership ユーティリティ
readership ユーティリティは、メールボックスの所有者以外に、何人のユーザーが共有 IMAP フォルダ内のメッセージを読んだかを報告するユーティリティです。
IMAP フォルダの所有者は、フォルダ内のメールを読む権限をほかのユーザーに与えることができます。ほかのユーザーにアクセス権が与えられたフォルダは、共有フォルダと呼ばれます。管理者は readership ユーティリティを使用して、所有者以外に何人のユーザーが共有フォルダにアクセスしたかを表示することができます。
このユーティリティは、すべてのメールボックスをスキャンして、各共有フォルダにつき 1 行ずつ、アクセスしたユーザー数とメールボックスの名前を表示させます。ユーザー数とメールボックスの名前の間にはスペースが挿入されます。
アクセスしたユーザーとは、過去の指定した日数内に共有フォルダを選択した、個別の認証を受けたユーザーのことです。自分の個人用メールボックスを読んだユーザーは、数には含められません。個人用メールボックスは、フォルダの所有者以外に購読者がいない場合は、レポートされません。
たとえば次のコマンドでは、最近の 15 日以内に共有の IMAP フォルダを選択したユーザーをすべてカウントします。
readership -d 15
制限容量をモニターするには
mboxutil ユーティリティを使用して、制限容量の使用状況やその限界をモニターすることができます。mboxutil ユーティリティは、定義された制限容量を一覧表示し、制限容量の使用状況に関する情報を提供するレポートを生成します。制限容量と使用状況に関する数値は、キロバイト (KB) でレポートされます。
たとえば次のコマンドでは、全ユーザーの制限容量に関する情報を一覧表示します。
mboxutil -a
次の例では、ユーザー crowe の制限容量に関する情報を一覧表示します。
mboxutil -u crowe
次の例では、ドメイン siroe.com の制限容量に関する情報を一覧表示します。
mboxutil -q siroe.com
ディスク容量をモニターするには
システムがディスク容量をモニターする頻度と、システムが警告を送信する環境条件を指定することができます。ディスク容量のモニターと通知について設定するには、configutil コマンドを使用してディスク容量の警告属性を設定します。表 15-11 を参照してください。
表 15-11 ディスク容量の警告属性
ディスク容量の属性
デフォルト値
alarm.diskavail.msgalarmstatinterval
3600 秒
alarm.diskavail.msgalarmthreshold
10%
alarm.diskavail.msgalarmwarninginterval
24 時間
たとえば、システムがディスク容量を 600 秒毎にモニターするようにするには、次のコマンドを指定します。
configutil -o alarm.diskavail.msgalarmstatinterval -v 600
使用可能なディスク容量が 20% を下回ったら常に警告を受け取るようにするには、次のコマンドを指定します。
configutil -o alarm.diskavail.msgalarmthreshold -v 20
警告属性の設定の詳細については、『Messaging Server リファレンスマニュアル』および「ディスク容量をモニターする」を参照してください。
stored ユーティリティを使用する
stored ユーティリティは、以下の監視タスクと保守タスクをサーバーに対して実行します。
- バックグラウンドと日常のメッセージ処理タスク
- デッドロックの検出とデッドロックしたデータベーストランザクションのロールバック
- 起動時の一時ファイルのクリーンアップ
- 存続期間決定ポリシーの実装
- サーバーの状態、ディスク容量、サービスへの応答時間などの定期的モニター (「stored」を参照)
- 必要に応じて警告を生成
- 必要に応じたデータベース回復 (「メッセージストアの起動と回復」を参照)
stored ユーティリティは毎日午後 11 時に自動的にクリーンアップと (有効期限による) 失効の操作を行います。また、これ以外の時間にもクリーンアップと失効の操作を行うように選択することもできます。
表 15-12 に stored オプションの一部を示します。一般的な使用例についてはこの表に従ってください。構文や使用要件の詳細については、『Messaging Server リファレンスマニュアル』を参照してください。
表 15-12 stored オプション
オプション
説明
-d
廃止。stored を起動するには、start-msg store を使用する。start-msg store は、デーモンとして実行され、システムチェックを実行し、アラーム、デッドロック検出、およびデータベース修復をアクティブにする
-t
stored のステータスをチェックする。このコマンドのリターンコードはステータスを示す
-v
詳細モード出力を行う
-v -v
その他の詳細モード出力
ステータスを出力するには、次のコマンドを入力します。
stored -t -v
自動的なクリーンアップと失効の操作の時間を変更する場合は、以下のように configutil ユーティリティを使用します。
configutil -o store.expirestart -v 21
場合によっては、stored ユーティリティを再起動する必要があるかもしれません。たとえば、メールボックスリストのデータベースが破損した場合などです。UNIX 上でstored を再起動するには、コマンドラインで以下のコマンドを使用します。
msg_svr_base/sbin/stop-msg store
msg_svr_base/sbin/start-msg storeサーバーのいずれかのデーモンがクラッシュした場合は、すべてのデーモンを停止させ、stored を含むすべてのデーモンを再起動しなくてはなりません。
メッセージストアのバックアップと復元を行うメッセージストアのバックアップと復元は、もっとも一般的で重要な管理タスクです。メッセージストアのすべてのメッセージとフォルダのバックアップを行います。メッセージストアにバックアップと復元のポリシーを実装して、以下のような問題が発生した場合でも、データが失われないようにしておかなければなりません。
コマンドラインユーティリティの imsbackup と imsrestore を使用するか、Legato Networker が採用された統合ソリューションを使用してメッセージストアのバックアップと復元を行うことができます。
Messaging Server は、単一コピーによるバックアップ手順を提供しています。特定のメッセージを格納するユーザーフォルダがいくつあるかにかかわらず、バックアップ時には、メッセージファイルは最初に見つかったメッセージファイルを使用して 1 度バックアップされるだけです。2 つ目のメッセージコピーは、1 つ目のメッセージファイルの名前へのリンクとしてバックアップされます。以降も同様です。imsbackup は、メッセージファイルのデバイスや inode をインデックスとして使用してすべてのメッセージのハッシュテーブルを保守します。ただし、この方法を採用する場合はデータの復元時に注意が必要です。詳細は、「部分的な復元に関する考察」を参照してください。
この節には、以下の項があります。
メールボックスバックアップポリシーの作成
バックアップポリシーは以下のようないくつかの要素に依存しています。
ビジネス負荷のピーク
システムのバックアップのスケジュールを設定する場合は、ビジネス負荷のピークを考慮に入れる必要があります。システムのバックアップによってピーク時のシステム負荷が減少することがあるからです。たとえば、バックアップは 2:00 am など早朝 (深夜) の時間帯にスケジュール設定するのが最善であると考えられます。
フルバックアップと増分バックアップ
増分バックアップとは、ストアをスキャンして変更データを見つけ、変更分だけをバックアップする方法です。フルバックアップとは、メッセージストア全体をバックアップすることです。システムが増分バックアップに対してどのくらいの頻度でフルバックアップを実行するのかを決定する必要があります。増分バックアップを毎日の保守手順の中で実行し、フルバックアップを週に 1 度実行することをお勧めします。
同時バックアップと順次バックアップ
ユーザーのデータが複数のディスクに保存されている場合、必要に応じて複数のユーザーグループを同時にバックアップすることができます。システムリソースによっては、同時バックアップによってバックアップ手順全体の処理速度を向上させることができます。ただし、たとえばサーバーのパフォーマンスに影響を与えたくないような場合、順次バックアップを実行することもあります。同時バックアップを行うか順次バックアップを行うかは、システム負荷、ハードウェア構成、使用可能なテープドライブの数など、多くの要素によって決まります。
バックアップグループを作成するには
バックアップグループは、正規表現で定義されたユーザーメールボックスの任意の集まりです。ユーザーメールボックスをバックアップグループに組織化することで、より柔軟なバックアップ管理を定義することができます。
たとえば、3 つのバックアップグループを作成し、第 1 のグループには A 〜 L で始まるユーザー ID を、第 2 のグループには M 〜 Z で始まるユーザー ID のユーザーを、第 3 のグループには ID が数字で始まるユーザーを含めます。管理者はこれらのバックアップグループを使用してメールボックスを同時にバックアップできます。または、ある日に一部のグループのみバックアップし、別の日にほかのグループをバックアップすることもできます。
バックアップグループについて注意すべき事項がいくつかあります。
- バックアップグループはメールユーザーの任意仮想グループです。これらは見かけとは異なり、メッセージストアディレクトリに正確にはマッピングされません (図 15-1)。
- バックアップグループは、UNIX 正規表現を使用して管理者によって定義されます。
- 正規表現は、次の設定ファイルで定義されています。
msg_svr_base/config/backup-groups.conf。- バックアップグループが imsbackup および imsrestore で参照された場合、次のパス形式が使用されます。/partition_name/backup_group。
backup-groups.conf フォーマットは以下のとおりです。
上記の例を使用して、次の 3 つの定義によるバックアップグループを作成するとします。
これで imsbackup および imsrestore をいくつかのレベルでスコープすることができます。次のバックアップコマンドを使用してメッセージストア全体をバックアップおよび復元することができます。
imsbackup -f device /
groupA の全ユーザー全メールボックスをバックアップするには、次のコマンドを使用します。
imsbackup -f device /partition/groupA
デフォルトのパーティションは primary です。
事前定義のバックアップグループ
Messaging Server には backup-groups 設定ファイルを作成しなくても使用することができる、事前定義のバックアップグループが含まれています。これは user という名前のグループで、ここにはすべてのユーザーが含まれています。たとえば、次のコマンドで primary パーティションのすべてのユーザーがバックアップされます。
imsbackup -f backupfile /primary/user
Messaging Server のバックアップと復元のユーティリティ
データのバックアップと復元のために、Messaging Server では imsbackup および imsrestore ユーティリティが提供されています。ただし、imsbackup および imsrestore ユーティリティは、Legato Networker のような汎用目的ツールに見られる高度な機能は備えていません。たとえば、これらのユーティリティでは、テープのオートチェンジャーに対するサポートは非常に限定されています。また、複数の同時実行デバイスに単一のストアを書き込むことはできません。総合的なバックアップは、Legato Networker などの一般化ツールのプラグインを使用して達成することができます。Legato Networker の使用に関する詳細については、「Legato Networker を使用するには」を参照してください。
imsbackup ユーティリティ
imsbackup ユーティリティを使用すると、選択したメッセージストアの内容を、シリアルデバイス (磁気テープ、UNIX パイプ、通常のファイルなど) に書き込むことができます。バックアップの全体または一部は、あとから imsrestore ユーティリティを使って回復できます。imsbackup の出力は、imsrestore に受け渡すことができます。
次の例では、メッセージストア全体が /dev/rmt/0 にバックアップされます。
次の例では、ユーザー ID joe のメールボックスが/dev/rmt/0 にバックアップされます。
次の例では、バックアップグループ groupA に定義された全ユーザーの全メールボックスが backupfile にバックアップされます (「バックアップグループを作成するには」を参照)。
このコマンドはデフォルトのブロック係数である 20 を使用します。imsbackup コマンドの完全な構文に関する説明は、『Messaging Server リファレンスマニュアル』を参照してください。
imsrestore ユーティリティ
バックアップデバイスからメッセージを復元するには、imsrestore コマンドを使用してください。たとえば、次のコマンドは backupfile から user1 のメッセージを復元します。
imsrestore -f backupfile /primary/user1
imsbackup コマンドの完全な構文に関する説明は、『Messaging Server リファレンスマニュアル』を参照してください。
部分的な復元に関する考察
メッセージストアでは単一コピーによるメッセージシステムが使用されています。つまり、メッセージの 1 つのコピーのみが 1 つのファイルとしてストアに保存されます。コピーされたメッセージのほかのインスタンス (メッセージが複数のメールボックスに送信される場合など) は、コピーへのリンクとして保存されます。このため、メッセージを復元する場合には注意が必要です。
例 :
次の例では、部分的な復元が実行された場合に、複数のユーザーによって使用されるメッセージに発生する事柄を示します。以下のように、3 人のユーザー A、B、C に属する、まったく同じ 3 つのメッセージが存在すると仮定してみてください。
A/INBOX/1
B/INBOX/1
C/INBOX/1例 1 : 最初の例では、システムは部分的なバックアップと完全な復元を以下のように実行します。
この例では、B/INBOX/1 および C/INBOX/1 には新しい inode 番号が割り当てられ、メッセージデータはディスク上の新しい場所に書き込まれます。メッセージは 1 件だけ復元されます。2 件目のメッセージは最初のメッセージへのハードリンクです。
例 2 : この例では、システムはフルバックアップと部分的な復元を以下のように実行します。
A/INBOX/1 には新しい inode 番号が割り当てられます。
例 3 : この例では、複数回の部分的な復元が必要となる可能性があります。
- フルバックアップを実行します。
B/INBOX/1 と C/INBOX/1 は A/INBOX/1 へのリンクとしてバックアップされます。
- ユーザー A と B のメールボックスを削除します。
- ユーザー B のメールボックスを復元します。
復元ユーティリティが、最初に A/INBOX を復元するよう管理者に要求します。
- ユーザー A と B のメールボックスを復元します。
- ユーザー A のメールボックスを削除します (任意)。
注
すべてのメッセージを部分的な復元で復元できるようにするためには、-i オプションを付けて imsbackup コマンドを実行します。-i オプションは必要に応じて各メッセージを複数回バックアップします。
ドライブやテープなど、バックアップデバイスが検索可能である場合、imsrestore は A/INBOX/1 が格納されている位置を検索し、B/INBOX/1 として復元します。UNIX パイプなど、バックアップデバイスが検索不能である場合、imsrestore はオブジェクト ID とリンクされているオブジェクトの ID をファイルに記録します。管理者は -r オプションを使用して imsrestore を再び呼び出し、欠落しているメッセージ参照を復元する必要があります。
Legato Networker を使用するには
Messaging Server は、Legato Networker のようなサードパーティ製のバックアップツールへのインタフェースを提供する、バックアップ API を装備しています。物理的なメッセージストア構造とデータ形式は、バックアップ API の中にカプセル化されています。バックアップ API はメッセージストアと直接対話します。さらに、バックアップサービスに対してメッセージストアの論理ビューを提示します。バックアップサービスは、メッセージストアの概念表現を使用して、バックアップオブジェクトの保存や検索を行います。
Messaging Server は Application Specific Module (ASM) を提供しています。これは、Legato Networker の save および recover コマンドによって呼び出され、メッセージストアのデータのバックアップと復元を行います。さらに ASM は、Messaging Server の imsbackup および imsrestore ユーティリティを呼び出します。
注
この節では、Messaging Server のメッセージストアで Legato Networker を使用する方法についての情報を提供します。Legato Networker インタフェースについて理解するには、Legato のマニュアルを参照してください。
Legato Networker を使用したデータのバックアップ
Legato Networker を使用して Messaging Server メッセージストアのバックアップを行うには、Legato インタフェースを呼び出す前に以下の準備手順を実行する必要があります。
- /usr/lib/nsr/imsasm から msg_srv_base/lib/msg/imsasm へのシンボリックリンクを作成します。
- Sun または Legato から nsrfile バイナリのコピーを取得して、それを以下のディレクトリにコピーします。
/usr/lib/nsr/nsrfile
- ユーザーをグループ別にバックアップする必要がある場合は、以下の手順を実行します。
- 「バックアップグループを作成するには」の説明に従って、バックアップグループファイルを作成します。
- 設定を確認するために、mkbackupdir.sh. を実行します。
mkbackupdir.sh によって作成されたディレクトリ構造を確認してください。その構造は、表 15-4 に示されているようになっている必要があります。
backup-groups.conf ファイルを指定していないと、バックアッププロセスはすべてのユーザーに対して、デフォルトのバックアップグループ ALL を使用します。
- ディレクトリ /nsr/res/ で、保存グループ用に res ファイルを作成して、バックアップの前に mkbackupdir.sh スクリプトを呼び出します。表 15-4 に示した例を参照してください。
注
Legato Networker の旧バージョンでは、保存設定の名前には最高 64 文字まで使用できます。このディレクトリ名とメールボックスの論理名を合わせたもの (たとえば /primary/groupA/fred) が 64 文字を超えた場合、mkbackupdir.sh -p を実行する必要があります。このため、mkbackupdir.sh の -p オプションの短いパス名を使用する必要があります。たとえば、次のコマンドでは /backup ディレクトリの下にバックアップイメージが作成されます。
mkbackupdir.sh -p /backup
重要 : バックアップディレクトリは、メッセージストアの所有者による書き込みが可能でなければなりません (例 : inetuser)。
表 15-4 には、バックアップグループのディレクトリ構造のサンプルが示されています。
図 15-5 バックアップグループのディレクトリ構造
次の例に、res ファイルのサンプルとして、/nsr/res ディレクトリにある IMS.res という名前のファイルを示します。
type:savepnpc
precmd:"echo mkbackupdir started",
"/usr/siroe/server5/msg-siroe/bin/mkbackupdir.sh -p /backup"
pstcmd:"echo imsbackup Completed";
timeout:"12:00 pm";
ここまでの準備が完了したら、以下の手順に従って Legato Networker インタフェースを実行します。
- 必要に応じて Messaging Server 保存グループを作成します。
- バックアップコマンドとして savepnpc を使用して、バックアップクライアントを作成します。
単一セッションのバックアップには、/backup を使用します。
同時バックアップには、/backup/server/group を使用します。
「バックアップグループを作成するには」の定義に従って group があらかじめ作成されていることを確認します。
また、同時実行するバックアップセッションの数も設定する必要があります。
「例 : Networker でバックアップクライアントを作成する」を参照してください。
- Group Control | Start の順に選択して、バックアップ設定のテストを行います。
例 : Networker でバックアップクライアントを作成する
Networker でバックアップクライアントを作成するには、 nwadmin から、Client | Client Setup | Create の順に選択します。
Name:siroe
Group:IMS
Savesets:/backup/primary/groupA
/backup/secondary/groupB
/backup/tertiary/groupC
.
.
Backup Command:savepnpc
Parallelism: 4
Legato Networker を使用したデータの復元
データの回復は、Legato Networker の nwrecover インタフェースまたは recover コマンドラインユーティリティを使用して実行できます。以下の例では、ユーザー a1 の INBOX を回復しています。
recover -a -f -s siroe /backup/siroe/groupA/a1/INBOX
次の例では、メッセージストア全体を回復しています。
recover -a -f -s siroe /backup/siroe
サードパーティのバックアップソフトウェア (Legato 以外) を使用するには
Messaging Server では、コマンドライン imsbackup と Solstice Backup (Legato Networker) の 2 つのメッセージストアバックアップソリューションを提供しています。メッセージストア全体をバックアップするために imbackup を単体で実行すると、大規模なメッセージストアの場合、非常に長い時間がかかってしまう可能性があります。Legato ソリューションでは、複数のバックアップデバイスでのバックアップセッションの同時実行をサポートしています。バックアップを同時実行することにより、バックアップ時間を大幅に短縮できます (毎時 25G バイトのデータバックアップが達成できる)。
その他のサードパーティのバックアップソフトウェア (Netbackup など) を使用する場合は、以下の方法によってバックアップソフトウェアを Messaging Server に統合します。
- ユーザーをグループに分割し (「バックアップグループを作成するには」を参照)、msg_svr_base/config/ ディレクトリの下に backup-groups.conf ファイルを作成します。
注
このバックアップソリューションは追加のディスク容量を必要とします。すべてのグループを同時にバックアップするには、メッセージストアの 2 倍のサイズのディスク容量が必要になります。ディスク容量に余裕のない場合は、ユーザーを小規模なグループに分け、グループセット単位でバックアップしていきます たとえば、group1 〜 group5、group6 〜 group10 というようになります。バックアップ後、グループデータファイルを削除します。
- imsbackup を実行して、準備領域にあるファイルに各グループをバックアップします。
このためのコマンドは、imsbackup -f <device> /<instance>/<group> です。
複数の imsbackup プロセスを同時に実行することができます。
例 :
# imsbackup -f- /primary/groupA > /bkdata/groupA &
# imsbackup -f- /primary/groupB > /bkdata/groupB &. . .
imsbackup は大きなサイズのファイルをサポートしていないため、バックアップデータが 2G バイトを超える場合は -f- オプションを使用して、データを stdout に書き込み、ファイルへ出力を受け渡します。
- サードパーティ製のバックアップソフトウェアを使用して、準備領域 (上の例では /bkdata) のグループデータファイルをバックアップします。
- ユーザーを復元するには、ユーザーのグループファイル名を確認し、そのファイルをテープから復元し、imsrestore を使用してデータファイルからユーザーを復元します。
imsrestore は大きなサイズのファイルをサポートしていません。データファイルが 2 G バイトより大きい場合は、次のコマンドを使用します。
# cat /bkdata/groupA | imsrestore -f- /primary/groupA/andy
ユーザーアクセスをモニターするMessaging Server では、imsconnutil コマンドが提供されます。このコマンドを使用して、ユーザーの IMAP、POP、および HTTP を介したメッセージストアアクセスをモニターできます。また、ユーザーの最新のログインおよびログアウトを確認できます。このコマンドは、メッセージストア単位で機能するものであり、メッセージストア全体に対しては機能しません。
このコマンドを使用するにはシステムユーザー (デフォルト : inetuser) によるルートアクセスが必要です。また、設定変数の local.imap.enableuserlist、local.http.enableuserlist、local.enablelastaccess を 1 に設定する必要があります。
IMAP または Web メールクライアントを介して現在ログインしているユーザーを一覧表示するには、次のコマンドを使用します。
# imsconnutil -c
メッセージストアのユーザーごとの最新の IMAP、POP、または Messenger Express によるアクセス (ログインおよびログアウト) を一覧表示するには、次のコマンドを使用します。
# imsconnutil -a
次のコマンドは 2 つの処理を実行します。1) 指定したユーザーが現在 IMAP、Messenger Express、または mshttp を介して接続しているクライアントからログインしているかどうか判別します (一般に、POP ユーザーの場合は常時接続でない場合があるので、この処理は POP には機能しないことに注意)。2) ユーザーが最後にログインおよびログアウトした時刻を一覧表示します。
# imsconnutil -c -a -u user_ID
ユーザーの一覧は、次のコマンドを使用して 1 行につき 1 ユーザーずつファイルで入力できます。
# imsconnutil -c -a -f filename
-s フラグを使用して、特定のサービス (imap または http) を指定することもできます。たとえば、特定のユーザー ID が IMAP にログインしたかどうかを一覧表示するには、次のコマンドを使用します。
# imsconnutil -c -s imap -u user_ID
imsconnutil の構文の詳細については、『Sun ONE Messaging Server リファレンスマニュアル』を参照してください。
次に出力例を示します。
$ ./imsconnutil -a -u soroork
UID IMAP last access HTTP last access POP last access
=========================================================================
soroork 08/Jul/2003:10:49:05 10/Jul/2003:14:55:52 ----NOT-RECORDED----
$ ./imsconnutil -c
IMAP
UID TIME AUTH TO FROM
===========================================================================
ed 17/Jun/2003:11:24:03 plain 172.58.73.45:193 129.157.12.73:2631
bill 17/Jun/2003:04:28:43 plain 172.58.73.45:193 129.158.16.34:2340
mia 17/Jun/2003:09:36:54 plain 172.58.73.45:193 192.18.184.103:3744
jay 17/Jun/2003:05:38:46 plain 172.58.73.45:193 129.159.18.123:3687
paul 17/Jun/2003:12:23:28 plaintext 172.58.73.45:193 192.18.194.83:2943
tony 17/Jun/2003:05:38:46 plain 172.58.73.45:193 129.152.18.123:3688
anil 17/Jun/2003:12:26:40 plaintext 172.58.73.45:193 192.18.164.17:1767
anil 17/Jun/2003:12:25:17 plaintext 172.58.73.45:193 129.150.17.34:3117
jack 17/Jun/2003:12:26:32 plaintext 172.58.73.45:193 129.150.17.34:3119
toni 17/Jun/2003:12:25:32 plaintext 172.58.73.45:193 192.18.148.17:1764===========================================================================
10 users were logged in to imap.
Feature is not enabled for http.
------------------------------------------------------------------------------
メッセージストアをトラブルシューティングするこの節では、障害に備えてメッセージストアを保守する際のガイドラインについて説明します。また、メッセージストアが壊れたり、予期せずシャットダウンされた場合に使用する、その他のメッセージストアの回復手順についても説明します。メッセージストア回復の追加手順に関する節は、「メールボックスとメールボックスデータベースの修復」の続きになります。
この節を読む前に、この章のこれまでの部分と同様に、『Sun ONE Messaging Server リファレンスマニュアル』のコマンドラインユーティリティおよび configutil に関する章を再度読まれますよう、強くお勧めします。この節では、以下の項目について説明します。
標準的なメッセージストアのモニター手順
ここでは、メッセージストアのモニターの標準的な手順の概要を説明します。ここで説明する手順は、メッセージストアの全般的なチェック、テスト、および標準的な保守を行う場合に役立つものです。
その他の情報については、「メッセージストアをモニターする」を参照してください。
ハードウェアの容量のチェック
メッセージストアには、十分な追加のディスク容量とハードウェアリソースが必要です。メッセージストアがディスク容量とハードウェア容量の上限に近づくと、メッセージストアに問題が発生することがあります。
ディスクの空き容量の不足は、メールサーバーで発生する問題や故障のうち、特に頻繁におきる原因の 1 つです。メッセージストアへ書き込むとき、そのための容量が不足していると、メールサーバーにエラーが発生します。さらに、利用可能なディスク容量が一定のしきい値より少なくなると、メッセージ配信やログ記録などに関連する多数の問題が発生します。stored プロセスのクリーンアップ機能が失敗し、削除されたメッセージがメッセージストアから消去されていないと、ディスク容量が急激に不足することがあります。
ディスク容量のモニターの詳細については、「ディスク容量をモニターするには」および「メッセージストアをモニターする」を参照してください。
ログファイルのチェック
ログファイルをチェックして、メッセージストアプロセスが設定どおりに実行されていることを確認します。Messaging Server は、サポートしている主なプロトコルまたはサービス (SMTP、IMAP、POP、および HTTP) ごとに一連のログファイルを作成します。ログファイルはコンソールを使用して表示するか、msg_svr_base/log/ ディレクトリで表示できます。ログファイルは定期的にモニターする必要があります。
ログ記録はサーバーパフォーマンスに影響することがあります。より詳細なログ記録を指定するほど、一定期間にログファイルが多くのディスク容量を占有することになります。効果的に定義する必要がありますが、現実的なログローテーション、有効期間、サーバーのバックアップポリシーなどを考慮する必要があります。サーバーのログポリシーの定義の詳細については、第 17 章「ログ記録とログ解析」を参照してください。
ユーザーの IMAP/POP セッションをチェックする
Messaging Server では、テレメトリと呼ばれる機能が提供されており、ユーザーの IMAP または POP セッション全体をファイルに取得できます。この機能は、クライアント問題をデバッグするのに便利です。たとえば、メッセージアクセスクライアントが期待どおりに機能しないとユーザーが訴えた場合、この機能を使用してアクセスクライアントと Messaging Server 間の対話を記録することができます。
セッションの記録をとるには、次のディレクトリを作成します。
msg_svr_base/data/telemetry/pop_or_imap/userid
Messaging Server によって、セッションにつき 1 ファイルがそのディレクトリに作成されます。出力例を次に示します。
LOGIN redb 2003/11/26 13:03:21
>0.017>1 OK User logged in
<0.047<2 XSERVERINFO MANAGEACCOUNTURL MANAGELISTSURL MANAGEFILTERSURL
>0.003>* XSERVERINFO MANAGEACCOUNTURL {67}
http://redb@cuisine.blue.planet.com:800/bin/user/admin/bin/enduser MANAGELISTSURL NIL MANAGEFIL
TERSURL NIL
2 OK Completed
<0.046<3 select "INBOX"
>0.236>* FLAGS (¥Answered ��agged raft eleted ¥Seen $MDNSent Junk)
* OK [PERMANENTFLAGS (¥Answered ��agged raft eleted ¥Seen $MDNSent Junk ¥*)]
* 1538 EXISTS
* 0 RECENT
* OK [UNSEEN 23]
* OK [UIDVALIDITY 1046219200]
* OK [UIDNEXT 1968]
3 OK [READ-WRITE] Completed
<0.045<4 UID fetch 1:* (FLAGS)
>0.117>* 1 FETCH (FLAGS (¥Seen) UID 330)
* 2 FETCH (FLAGS (¥Seen) UID 331)
* 3 FETCH (FLAGS (¥Seen) UID 332)
* 4 FETCH (FLAGS (¥Seen) UID 333)
* 5 FETCH (FLAGS (¥Seen) UID 334)
<etc>
stored プロセスのチェック
stored 機能は、存続期間決定ポリシーを実行したり、ディスクに保存されているメッセージを消去して、メッセージデータベースのデッドロック操作やトランザクション操作などの、さまざまな重要なタスクを実行します。stored が実行を停止すると、最終的には Messaging Server に問題が発生します。start-msg が実行されているときに stored が起動していないと、ほかのプロセスも起動しません。
stored プロセスの詳細については、「stored ユーティリティを使用する」および『Messaging Server リファレンスマニュアル』の Messaging Server コマンドラインユーティリティの章の stored ユーティリティを参照してください。
stored 機能のモニターの詳細については、「メッセージストアをモニターする」を参照してください。
データベースログファイルをチェックする
データベースログファイルは、sleepycat トランザクションのチェックポイントログファイル (store_root/mboxlist ディレクトリ内) を指します。ログファイルが蓄積されると、データベースのチェックポイント設定は行われません。通常は、単一の期間内に、2 つまたは 3 つのデータベースログファイルがあります。ログファイルがそれ以上ある場合は、問題がある可能性があります。
ユーザーフォルダのチェック
ユーザーフォルダをチェックする場合は、以下のコマンドを実行します。
reconstruct -r -n (recursive no fix)。これにより、ユーザーフォルダおよびレポートのエラーを確認します。reconstruct コマンドの詳細については、「メールボックスとメールボックスデータベースの修復」を参照してください。コアファイルのチェック
コアファイルは、プロセスが予期せず終了したときにのみ存在します。コアファイルを確認することは、メッセージストアに問題がありそうなときは特に重要です。Solaris の場合は、coreadmin を使用して core ファイルの場所を設定します。
メッセージストアの起動と回復
メッセージストアのデータはメッセージ、インデックスデータ、およびメッセージストアデータベースで構成されています。このデータは堅固ですが、ごくまれにメッセージストアのデータに関する問題がシステムに存在することがあります。このような問題はデフォルトのログファイルに示され、ほとんどの場合は透過的に修正されます。ただし、reconstruct ユーティリティを実行する必要があることを示すエラーメッセージがログファイルに表示される場合がまれにあります。また、最終手段として、メッセージは「メッセージストアのバックアップと復元を行う」で説明されているバックアップと復元のプロセスによって保護されます。この節では、stored の自動起動および回復プロセスについて説明します。
メッセージストアでは、以前は管理者の職責であった多くの回復処理が自動化されています。これらの処理はメッセージストアデーモンの stored によって起動時に実行され、必要に応じてデータベーススナップショットおよび自動高速復元が含まれます。stored によってメッセージストアのデータベースが徹底的にチェックされ、問題が検出された場合は自動的に修復されます。
また、stored は、デフォルトのログにステータスメッセージを出力することで、データベースのステータスの総合的な分析を提供し、メッセージストアに行われた修復およびメッセージストアを回復するために行われた自動試行について報告します。
自動起動と自動回復 - 動作方式
stored デーモンは、ほかのメッセージストアプロセスが起動する前に起動します。このデーモンによってメッセージストアデータベースは初期化され、必要に応じて回復処理が行われます。メッセージストアデータベースは、フォルダ、容量制限、購読、およびメッセージフラグの情報を保持します。データベースはログ用とトランザクション用であるので、回復はすでに組み込まれています。また、一部のデータベース情報は、各フォルダのインデックス領域に予備でコピーされています。
データベースは非常に堅固ですが、まれに壊れたとしても、ほとんどの場合は stored によって透過的に回復および修復されます。ただし、stored が再起動された場合は毎回、デフォルトのログファイルをチェックして、ほかに管理操作が必要ないことを確認してください。データベースをさらに修復する必要がある場合は、ログファイルのステータスメッセージで reconstruct を実行するように示されます。
メッセージストアデータベースを開く前に、stored はデータベースの完全性を分析し、ステータスメッセージを warning のカテゴリの下にあるデフォルトログに出力します。メッセージには管理者にとって有用なものも、内部分析に使用されるコード化されたデータで構成されるものもあります。stored によって問題が検出された場合は、データベースの修復が試行され、再起動が試行されます。
データベースが開くと、stored は、ほかのサービスが起動することを合図します。自動修復が失敗した場合、デフォルトログのメッセージで実行するべきアクションが示されます。詳細は、「reconstruct -m が必要であることを示すエラーメッセージ」を参照してください。
以前のリリースでは、stored は非常に長い時間がかかる回復プロセスを開始することがあり、stored が「スタック」したかのように見えることがありました。このタイプの長い回復プロセスは取り除かれ、stored は最終的な状態を 1 分以内に判断するようになりました。ただし、stored がスナップショットからの回復などの回復手段を採用する必要がある場合、プロセスは数分かかる場合があります。
ほとんどの回復プロセスでは通常、終了後のデータベースは最新の状態になっていて、ほかに必要な操作はありません。ただし、一部の回復プロセスでは、reconstruct -m を実行してメッセージストアの冗長データを同期させる必要がある場合もあります。これもデフォルトログに示されます。したがって、起動後にデフォルトログをモニターすることは重要です。メッセージストアが通常どおり起動し、機能しているように見える場合でも、reconstruct など、要求されている操作がある場合は実行することが重要です。
ログファイルを読むもう 1 つの理由は、データベースに障害を引き起こした原因を確認することです。stored は、システムでの問題の種類にかかわらずメッセージストアを回復するように設計されていますが、データベース障害はより大きな問題が潜んでいることの徴候である可能性があるので、原因を解明することをお勧めします。
reconstruct -m が必要であることを示すエラーメッセージ
ここでは、reconstruct -m の実行が必要なエラーメッセージのタイプについて説明します。
エラーメッセージでメールボックスエラーが示された場合は、reconstruct <mailbox> を実行します。
例 :
"Invalid cache data for msg 102 in mailbox user/joe/INBOX.Needs reconstruct"
"Mailbox corrupted, missing fixed headers:user/joe/INBOX"
"Mailbox corrupted, start_offset beyond EOF:user/joe/INBOX"
エラーメッセージでデータベースエラーが示された場合は、reconstruct -m を実行します。
例 :
"Removing extra database logs.Run reconstruct -m soon after startup to resync redundant data"
"Recovering database from snapshot.Run reconstruct -m soon after startup to resync redundant data"
データベーススナップショット
スナップショットは、データベースのホットバックアップであり、壊れたデータベースを数分で透過的に回復するために stored で使用されます。これは、ほかの領域に保存された冗長情報に依存する reconstruct を使用するよりもはるかに速い方法です。
メッセージストアのデータベーススナップショット - 動作方式
データベースのスナップショット (mboxlist ディレクトリ内) は自動的に作成されます。デフォルトでは、24 時間ごとに作成されます。デフォルトでは、スナップショットは store ディレクトリのサブディレクトリにコピーされます。デフォルトでは、常時 5 つのスナップショットが保存されています。ライブデータベースが 1 つ、スナップショットが 3 つ、データベース / 削除済みコピーが 1 つです。データベース / 削除済みコピーはより新しいものであり、mboxlist データベースディレクトリの removed サブディレクトリに入れられたデータベースの非常時用のコピーです。
現在のデータベースに障害があるために回復プロセスで削除することが決定されると、stored がデータベースを removed ディレクトリに移動します (可能な場合)。したがって、必要に応じてそのデータベースを分析できるようになっています。
データの移動は、1 週間に 1 度だけ実行されます。データベースのコピーがすでに移動先に存在する場合、stored はストアが起動するたびごとにはコピーを置き換えません。removed ディレクトリのデータが 1 週間よりも古い場合にのみ置き換えます。これは、元のデータベースが一連の起動によってあまりにも早く置き換えられないようにするためです。
メッセージストアのデータベーススナップショットの間隔と場所を指定するには
データベースとスナップショットを組み合わせるには、5 倍の容量が必要です。スナップショットが別のディスク上で実行されるように再設定し、システムの要件に合わせることを強くお勧めします。
stored によって起動時にデータベースに関する問題が検出された場合は、最善のスナップショットが自動的に回復します。3 つのスナップショット変数を使用して設定できるパラメータは、次のとおりです。スナップショットファイルの場所、スナップショットの作成間隔、保存されるスナップショットの数。表 15-14 に、これらの configutil パラメータを示します。
スナップショットの間隔が短すぎると、システムに頻繁に負荷がかかるとともに、データベースの問題がスナップショットとしてコピーされる可能性が高くなります。スナップショットの間隔が長すぎると、データベースはスナップショットが作成された過去の時点の状態を維持することになります。
スナップショット間隔は 1 日にすることをお勧めします。1 週間またはそれより長い間隔のスナップショットは、システムで問題が数日間解消されない場合に、問題が存在する前の状態に戻すのに便利です。
stored はデータベースのモニターを実行し、データベースが完全でない可能性がある場合は最新のスナップショットを拒否する高度な機能があります。代わりに最新のもっとも信頼性の高いスナップショットを取り出します。1 日前のスナップショットが取り出される可能性があることにもかかわらず、システムはより新しい冗長データがある場合はそのデータを使用して古いスナップショットデータを無効にします。
つまり、スナップショットの根本的な役割は、システムを最新の状態に近づけることと、進行中のデータを再構築しようとするシステムのほかの部分の負担を軽減することです。
表 15-14 メッセージストアデータベーススナップショットのパラメータ
パラメータ
説明
local.store.snapshotpath
メッセージストアのデータベーススナップショットファイルの場所。既存の絶対パスまたは store ディレクトリを基準とする相対パスのいずれか
デフォルト : dbdata/snapshots
local.store.snapshotinterval
スナップショット間隔 (単位 : 分)。有効な値 : 1 - 46080
デフォルト : 1440 (1440 分 = 1 日)
local.store.snapshotdirs
保存される異なるスナップショットの数。有効な値 : 2 -367
デフォルト : 3
メールボックスとメールボックスデータベースの修復
1 つまたは複数のメールボックスが破損した場合、reconstruct ユーティリティを使用してメールボックスまたはメールボックスデータベースを再構築し、すべての矛盾を修復することができます。「reconstruct -m が必要であることを示すエラーメッセージ」を参照してください。
reconstruct ユーティリティは、1 つまたは複数のメールボックスまたはマスターメールボックスファイルを再構築し、すべての矛盾を修復します。このユーティリティを使うと、メールストアにおけるほとんどすべてのデータ破損を回復することができます。トランザクションの完了や、完了しなかったトランザクションのロールバックなど、低レベルのデータベースの修復は起動時に自動的に実行されます。
表 15-15 では、reconstruct オプションを一覧表示しています。構文や使用要件の詳細については、『Messaging Server リファレンスマニュアル』を参照してください。
表 15-15 reconstruct オプション
オプション
説明
-e
再構築時に store.exp ファイルを削除する
-i
再構築時に store.idx ファイルを初期化する
-f
reconstruct に 1 つまたは複数のメールボックスで修復を行うように強制する
-m
メールボックスのデータベースを修復し、整合性チェックを行う。このオプションを使用すると、スプールエリアで見つかったすべてのメールボックスがチェックされ、必要に応じてメールボックスのデータベースエントリの追加または削除が行われる。データベースでエントリの追加または削除が行われると、メッセージが標準出力ファイルに出力される
-n
メールボックスの修復を実行せずに、メッセージストアだけをチェックする。メールボックス名を指定せずに、-n オプションを単独で使用することはできない。メールボックス名を指定しない場合、-n オプションは -r オプションとともに使用する必要がある。-r オプションは、-p オプションと組み合わせる場合もある。たとえば、以下のコマンドはすべて有効である
reconstruct -n user/dulcinea/INBOX
reconstruct -n -r
reconstruct -n -r -p primary
reconstruct -n -r user/dulcinea/
-o
孤立したアカウントをチェックする。このオプションは、現在の Messaging Server ホスト内の Inbox で、対応するエントリが LDAP にないものを検索する。たとえば、-o オプションは、所有者が LDAP から削除された、または別のサーバーホストに移動された inbox を検索する。見つかった孤立アカウントのそれぞれに対し、reconstruct ユーティリティは標準出力に次のコマンドを書き込む
mboxutil-d user/userid/INBOX
-o -d filename
-o オプションで「-d filename」が指定されている場合、reconstructは指定したファイルを開き、そのファイルに mboxutil -d コマンドを書き込む。このファイルをスクリプトファイルにして、孤立したアカウントを削除することができる
-p パーティション
パーティション名を指定する。完全なパス名は使用しないこと。このオプションを指定しない場合、reconstruct がすべてのパーティションのデフォルト
-q
制限容量サブシステムの矛盾 (メールボックスの制限容量ルートが正しくない、または制限容量ルートで誤った容量の使用状況がレポートされるなど) を修正する。-q オプションは、ほかのサーバープロセスの実行中に実行できる
-r [mailbox]
指定した 1 つまたは複数のメールボックスのパーティションエリアを修復し、整合性をチェックする。また、-r オプション は、指定したメールボックス内のすべてのサブメールボックスも修復する。-r を指定してメールボックス引数を入力しなかった場合は、ユーザーパーティションディレクトリ内にあるすべてのメールボックスのスプールエリアが修復される
メールボックスを再構築するには
メールボックスを再構築するには -r オプションを使用します。このオプションは以下の場合に使用します。
5.0 リリースでは、reconstruct -r は、最初に整合性チェックを実行します。問題が検出されたときのみ整合性および再構築についてレポートされます。したがって、このリリースでは reconstruct ユーティリティのパフォーマンスが向上しています。
reconstruct は、次の例で説明するように使用することができます。
ユーザー daphne に属するメールボックスのスプール領域を再構築するには、次のコマンドを使用します。
reconstruct -r user/daphne
メールボックスデータベースに一覧表示されたすべてのメールボックスのスプール領域を再構築するには、次のように入力します。
reconstruct -r
ただし、このオプションは注意して使用してください。メールボックスデータベースに一覧表示されたすべてのメールボックスのスプール領域を再構築する場合、メッセージストアが大規模なため非常に長い時間を要する可能性があるからです (「reconstruct のパフォーマンス」を参照)。これよりも優れた障害復旧に対する手段は、ストア用に複数のディスクを使用することでしょう。ディスクが 1 つダウンしてもストア全体がダウンすることはないからです。ディスクが破損した場合、次のように -p オプションを使用してストアの一部分を再構築するだけですみます。
reconstruct -r -p subpartition
コマンドラインの引数にリストされたメールボックスが primary パーティションに存在する場合のみそれらを再構築するには、次のように入力します。
reconstruct -p primary mbox1 mbox2 mbox3
primary パーティションに存在するすべてのメールボックスを再構築する必要がある場合は、以下のようになります。
reconstruct -r -p primary
整合性チェックを実行せずにフォルダを再構築する場合は、-f オプションを使用します。たとえば、次のコマンドはユーザーフォルダ daphne の再構築を実行します。
reconstruct -f -r user/daphne
すべてのメールボックスを修正せずにチェックする場合は、以下のように -n オプションを使用します。
reconstruct -r -n
メールボックスのチェックと修復
高レベルの整合性チェックを行い、メールボックスデータベースを修復するには次のようになります。
reconstruct -m
-m オプションは以下の場合に使用します。
孤立アカウントを削除するには
孤立アカウント (対応するエントリが LDAP にないメールボックス) を検索するには、次のコマンドを使用します。
reconstruct -o
コマンド出力が以下のように続きます。
reconstruct:Start checking for orphaned mailboxes
mboxutil -d user/test/annie/INBOX
mboxutil -d user/test/oliver/INBOX
reconstruct:Found 2 orphaned mailbox(es)
reconstruct:Done checking for orphaned mailboxes
孤立メールボックスをリストしたファイルを作成するには、次のコマンドを使用します。作成したファイルは、孤立メールボックスを削除するスクリプトファイルにすることができます。ここでは、ファイルは orphans.cmd という名前です。
reconstruct -o -d orphans.cmd
コマンド出力は次のとおりです。
reconstruct:Start checking for orphaned mailboxes
reconstruct:Found 2 orphaned mailbox(es)
reconstruct:Done checking for orphaned mailboxes
reconstruct のパフォーマンス
reconstruct が処理を実行するのにかかる時間は、次に示すいくつかの要素によって異なります。
reconstruct -r オプションにより、最初の整合性チェックが実行されます。このチェックでは、再構築の必要なフォルダの数に応じて reconstruct のパフォーマンスが向上します。
ユーザー数が約 2400、メッセージストアが 85G バイトで、POP、IMAP、または SMTP アクティビティが同時にサーバーで実行されているシステムでは、次のパフォーマンスが得られました。
一般的な問題と解決策
この節では、以下のようなメッセージストアの一般的な問題と解決策の一覧を示します。
ワイルドカードパターンを使用したコマンドが機能しない
UNIX シェルには、ワイルドカードパターンを引用符で囲む必要があるものとその必要のないものがあります。たとえば、C シェルはワイルドカード (*、?) を含む引数をファイルとして展開しようとするため、一致するものがない場合は失敗します。これらのパターンマッチング引数は、mboxutil のようなコマンドに渡すためには引用符で囲む必要があります。
例 :
mboxutil -l -p user/usr44*
これは Bourne シェルで機能しますが、tsch や C シェルでは失敗します。これらのシェルには次のコマンドが必要です。
mboxutil -l -p "user/usr44*"
ワイルドカードパターンを使用したコマンドが機能しない場合は、そのシェルではワイルドカードを引用符で囲む必要があるかどうかを確認してください。
不明または無効なパーティション
ユーザーのメールボックスが作成されたばかりの新しいパーティションに移動され、Messaging Server が更新または再起動されていない場合、ユーザーは Messenger Express で「Unknown/invalid partition」というメッセージを表示されることがあります。この問題は新しいパーティションでのみ発生します。この新しいパーティションにユーザーメールボックスを新しく追加する場合、Messaging Server の更新または再起動を行う必要はありません。
ユーザーメールボックスディレクトリに関する問題
ユーザーメールボックスに関する問題が発生するのは、メッセージストアの損傷が少数のユーザーに限られていて、システム全体に対する損傷がないときです。ユーザーメールボックスのディレクトリに関する問題を識別、分析、および解決する際は、以下のガイドラインを参考にしてください。
- ログファイル、エラーメッセージ、またはユーザーが見た異常な動作を確認します。
- デバッグ情報と履歴を保存しておくには、server-root/mboxlist/ ユーザーディレクトリ全体を、メッセージストア外部の別の場所にコピーします。
- 問題の原因になっている可能性のあるユーザーフォルダを見つけるには、reconstruct -r -n コマンドを実行します。reconstruct を使用しても問題のあるフォルダが見つからない場合は、該当のフォルダが folder.db 内にない可能性があります。
reconstruct -r -n コマンドを使用してもフォルダが見つからない場合は、hashdir コマンドを使用して場所を確認します。hashdir の詳細については、「hashdir ユーティリティ」および、『Messaging Server リファレンスマニュアル』の Messaging Server コマンドラインユーティリティの章の hashdir ユーティリティを参照してください。
- ファイルが見つかったら、ファイルを調べ、権限をチェックし、適切なファイルのサイズを確認します。
- reconstruct -r (-n オプションは付けない) を使用して、メールボックスを再構築します。
- reconstruct で問題が検出されない場合は、reconstruct -r -f コマンドを使用して、メールフォルダを強制的に再構築することができます。
- フォルダが mboxlist ディレクトリ (store_root/mboxlist) 内にはなく、partition ディレクトリ (store_root/partition) にある場合は、全体的な矛盾がある可能性があります。この場合は、reconstruct -m コマンドを実行する必要があります。
- 上記の手順が機能しない場合は、store.idx ファイルを削除してから、再度 reconstruct コマンドを実行してください。
- 原因が問題を起こすメッセージに限られている場合は、メッセージファイルをメッセージストアの外側の別の場所にコピーしてから、mailbox/ ディレクトリ上で reconstruct -r コマンドを実行する必要があります。
- フォルダがディスク (store_root/partition/ ディレクトリ) 上にあっても、明らかにデータベース (store_root/mboxlist/ ディレクトリ) 内にはないことがわかった場合は、reconstruct -m コマンドを実行してメッセージストアの整合性をチェックします。
reconstruct コマンドの詳細については、「メールボックスとメールボックスデータベースの修復」を参照してください。
store デーモンが起動しない
stored が起動せずに次のエラーメッセージが表示される場合があります。
# msg_svr_base/sbin/start-msg
msg_svr_base:Starting STORE daemon ...Fatal error:Cannot find group in name service上記のメッセージは、local.servergid に設定された UNIX グループが見つからないことを示しています。Stored などは、gid をグループに設定する必要があります。local.servergid によって定義されたグループが誤って削除されることがあります。この場合は、削除されたグループを作成し、inetuser をグループに追加し、instance_root の所有権とそのファイルを inetuser とグループに変更します。
