この章では、サービスの起動と停止、ディレクトリアクセスの設定など、コマンド行ユーティリティーを使用して実行できる Messaging Server の一般的なタスクについて説明します。個々の Messaging Server サービス (POP、IMAP、HTTP、SMTP など) に固有のタスクについては、あとの章で説明します。この章の内容は次のとおりです。
初期設定 (「1.3 Messaging Server の初期実行時設定を作成する」を参照) で同じパスワードを持つ多数の管理者を設定しているため、これらの管理者のパスワードを変更することをお勧めします。
初期実行時設定の際にデフォルトのパスワードが設定されているパラメータと、それらを変更するためのユーティリティーを確認するには、表 4–1 を参照してください。configutil ユーティリティーを使用するこれらのパラメータについては、『Sun Java System Messaging Server 6.3 Administration Reference』の「configutil」で構文の詳細と使用方法を確認してください。
表 4–1 Messaging Server の初期実行時設定で設定されるパスワード
パラメータ |
説明 |
---|---|
local.ugldapbindcred |
configutil ユーティリティーを使って設定したユーザー/グループ管理者のパスワードです。 |
local.service.pab.ldappasswd |
configutil ユーティリティーを使って設定した、PAB 検索のバインド DN によって指定されたユーザーのパスワードです。 |
キーファイルの SSL パスワード |
sslpassword.conf ファイル内に直接設定されているパスワードです。 |
サービス管理者の資格 |
ldapmodify コマンドを使って LDAP ディレクトリに直接設定されている資格です。 |
Delegated Administrator のサービス管理者 |
Sun LDAP Schema 1 が有効になっていて、iPlanet Delegated Administrator ユーティリティーを使用している場合は、この管理者のパスワードを変更するだけで済みます。 Delegated Administrator サービス管理者のパスワードを変更するには、LDAP ディレクトリ (ldapmodify コマンドで)、または Delegated Administrator の UI でパスワードを変更します。 |
ストア管理者 |
ストア管理者のパスワードを変更するには、LDAP ディレクトリ (ldapmodify コマンドで) でパスワードを変更できます。 |
次の例では、local.enduseradmincred configutil パラメータを使用してエンドユーザー管理者のパスワードを変更します。
configutil -o local.enduseradmincred -v newpassword |
すべてのユーザー、メーリングリスト、およびドメインの情報は、LDAP ディレクトリ内にエントリとして保存されています。LDAP ディレクトリには、従業員、顧客、または組織に何らかのかかわりを持つその他の人々に関する詳細な情報を保存しておくことができます。これらの人々は、組織のユーザーとして扱われます。
LDAP ディレクトリ内のユーザー情報は、各ユーザーエントリのさまざまな属性に基づいて効率的に検索できるようになっています。ユーザーエントリに関連付けられている属性には、氏名やその他の ID、部署、職名、勤務地、マネージャー名、直属の部下名、組織内の各部へのアクセス権限、およびその他の詳細設定があります。
組織内に電子メッセージングサービスがある場合は、大部分またはすべてのユーザーがメールアカウントを持っているはずです。Messaging Server の場合、メールアカウント情報はサーバーにローカルには保存されません。これは、LDAP ユーザーディレクトリの一部です。各メールアカウントの情報は、ディレクトリ内のユーザーのエントリに付加されたメール属性として保存されます。
メールユーザーとメーリングリストの作成と管理は、ディレクトリ内のユーザーおよびメーリングリストのエントリを作成および変更することによって行います。これを行うには、Sun LDAP Schema 2 対応の Delegated Administrator およびメッセージング用 iPlanet Delegated Administrator (Sun LDAP Schema 1 対応) の Delegated Administrator コマンド行ユーティリティーを使うか、Sun LDAP Schema 1 の LDAP ディレクトリを直接変更します。
commadmin user delete コマンドを実行して、ユーザーを削除済みとしてマークします。(『Sun Java System Delegated Administrator 6.4 管理ガイド』の第 5 章「コマンド行ユーティリティー」を参照)。
ユーザーからサービスを削除します。
サービスとしては、メールボックスやカレンダなどがあります。Messaging Server の現在のバージョンの場合、このプログラムの名前は msuserpurge です。(『Sun Java System Messaging Server 6.3 Administration Reference』の「msuserpurge」を参照。)カレンダサービスの場合、このプログラムは csclean です。(『Sun Java System Calendar Server 6.3 管理ガイド』を参照。)
commadmin domain delete コマンドを実行して、ドメインを削除済みとしてマークします。(『Sun Java System Delegated Administrator 6.4 管理ガイド』の第 5 章「コマンド行ユーティリティー」を参照)。
そのドメインのユーザーからサービスを削除します。
サービスとしては、メールボックスやカレンダなどがあります。Messaging Server の場合、このプログラムの名前は msuserpurge です。(『Sun Java System Messaging Server 6.3 Administration Reference』の「msuserpurge」を参照。)カレンダサービスの場合、このプログラムは csclean です。(『Sun Java System Calendar Server 管理ガイド』を参照。)
Sun ONE Administration Console は、Messaging Server でサポートされなくなりました。同等のコマンド行インタフェースを使用してください。
サービスを起動および停止する方法は、そのサービスが HA 環境にインストールされているかどうかによって異なります。
Messaging Server を HA 制御下で実行している場合は、個々の Messaging Server サービスを制御するための通常の Messaging Server コマンド (起動、再起動、停止) を使用することはできません。HA 配備で stop-msg を試みると、HA 設定が検出されたという警告と適切なシステムの停止方法が示されます。
次の表に、適切な起動、停止、再起動のコマンドを示します。ほかの Messaging Server サービス (たとえば SMTP) を個別に起動、再起動、停止するための特定の HA コマンドはないことに注意してください。ただし、stop-msg service コマンドを実行して、imap、pop、sched などの個々のサーバーを停止または再起動することはできます。
Sun Cluster の最小単位は、個々のリソースです。Messaging Server は Sun Cluster でリソースとして認識されるため、scswitch コマンドがすべての Messaging Server サービスに影響を及ぼします。
表 4–2 Sun Cluster 3.0/3.1 環境での起動、停止、再起動
動作 |
個々のリソース |
リソースグループ全体 |
|
---|---|---|---|
起動 |
scswitch -e -j resource |
sscswitch -Z -g resource_group |
|
再起動 |
|
scswitch -R -g resource_group |
|
停止 |
scswitch -n -j resource |
scswitch -F -g resource_group |
表 4–3 Veritas 1.3、2.0、2.1、および 3.5 環境での起動、停止、再起動
動作 |
個々のリソース |
リソースグループ全体 |
||
---|---|---|---|---|
起動 |
hares -online resource -sys system |
hagrp -online group -sys system |
||
再起動 |
|
|
||
停止 |
hares -offline resource -sys system |
hagrp -offline group -sys system |
コマンド行からサービスを起動または停止するには、コマンド msg-svr-base/sbin/start-msg および msg-svr-base/sbin/stop-msg を使用します。コマンド テンプレート msg-svr-base /sbin/stop-msg service (サービスは smtp、imap、pop、store、http、ens または sched) を使用して個別にサービスを起動および停止することは可能ですが、このマニュアルで説明している特定のタスクを除いては推奨されません。特定のサービスは別のサービスに依存しているため、所定の順序で起動する必要があります。サービスを単独で起動しようとすると、面倒な問題が生じる可能性があります。そのため、start-msg コマンドおよび stop-msg コマンドを使用して、すべてのサービスを同時に起動および停止するようにしてください。
POP、IMAP、HTTP などの各サービスを起動または停止するには、まずそれらを使用可能な状態にする必要があります。詳細は、「5.1.1 サービスの有効化と無効化」を参照してください。
重要: サーバープロセスがクラッシュすると、ほかのプロセスがハングアップする可能性があります。これは、それらのプロセスが、クラッシュしたサーバープロセスによって保持されていたロックを待機しているためです。自動再起動 (「4.5 障害が発生したサービスや応答がないサービスの自動再起動」を参照) を使用していない場合で、サーバープロセスがクラッシュした場合は、すべてのプロセスを停止し、再起動するようにしてください。これには、POP、IMAP、HTTP、MTA の各プロセス、stored (メッセージストア) プロセス、およびメッセージストアを変更するすべてのユーティリティーが含まれます。このユーティリティーには、mboxutil、deliver、reconstruct、readership、upgrade などがあります。
繰り返しますが、このマニュアルの各所で説明されている特定のタスクを除き、個々のサービスをシャットダウンすることは推奨されません。特定のサービスは別のサービスに依存しているため、所定の順序で起動する必要があります。サービスを単独で起動しようとすると、面倒な問題が生じる可能性があります。そのため、start-msg コマンドおよび stop-msg コマンドを使用して、すべてのサービスを同時に起動および停止するようにしてください。
任意のメッセージングサービスを起動または停止するには、start-msg コマンドおよび stop-msg コマンドを使用します。例:
msg-svr-base/sbin/start-msg imap
msg-svr-base/sbin/stop-msg pop
msg-svr-base/sbin/stop-msg sched
msg-svr-base/sbin/stop-msg smtp
サービスを停止または起動するには、サービスが有効になっている必要があります。「4.4.2.1 起動できるサービスを指定する」を参照してください。
start-msg smtp および stop-msg コマンドを実行すると、SMTP サーバーだけでなく、すべての MTA サービスが起動または停止します。特定の MTA サービスだけを起動または停止する場合は、ディスパッチャーおよびジョブコントローラに対して start/stop msg コマンドを使用します。詳細は、『Sun Java System Messaging Server 6.3 Administration Reference』の「start-msg」および 『Sun Java System Messaging Server 6.3 Administration Reference』の「stop-msg」を参照してください。
デフォルトでは、start-msg を使って次のサービスが起動されます。
#./start-msg Connecting to watcher ... Launching watcher ... Starting ens server .... 21132 Starting store server .... 21133 checking store server status ... ready Starting imap server .... 21135 Starting pop server .... 21138 Starting http server .... 21141 Starting sched server .... 21143 Starting dispatcher server .... 21144 Starting job_controller server .... 21146 |
これらのサービスは、次の configutil パラメータを有効化または無効化することによって制御できます。service.imap.enable、service.pop.enable、service.http.enable、local.smsgateway.enable、local.snmp.enable、local.imta.enable、local.mmp.enable、local.ens.enable、および local.sched.enable。IMAP を無効にするには、service.imap.enable と service.imap.enablesslport の両方を 0 に設定する必要があります。POP および HTTP の場合も同様です。これらのパラメータの機能の詳細については、『Sun Java System Messaging Server 6.3 Administration Reference』の「configutil Parameters」を参照してください。
Messaging Server では、watcher と msprobe の 2 つのプロセスが提供されています。これらのプロセスによってサービスは透過的に監視され、クラッシュしたり応答がなくなった (ハングアップしている) 場合には、自動的に再起動されます。watcher はサーバークラッシュを監視します。msprobe は応答時間をチェックすることでサーバーハングアップを監視します。サーバーでエラーが発生した場合や、サーバーが要求に応答しなくなった場合、サーバーは自動的に再起動されます。表 4–4 に、各ユーティリティーで監視されるサービスを示します。
表 4–4 watcher と msprobe で監視されるサービス
watcher (クラッシュ) |
msprobe (応答しないハングアップ) |
---|---|
IMAP、POP、HTTP、ジョブコントローラ、ディスパッチャー、メッセージストア (stored)、imsched、MMP (LMTP/SMTP サーバーはディスパッチャーによって監視され、LMTP/SMTP クライアントは job_controller によって監視される。) |
IMAP、POP、HTTP、証明書、ジョブコントローラ、メッセージストア (stored)、imsched、ENS、LMTP、SMTP |
local.watcher.enable=on (デフォルト) を設定すると、プロセスの失敗と応答しないサービスが監視され、default ログ ファイルに特定の失敗を示すエラーメッセージが記録されます。サーバーの自動再起動を有効にするには、configutil のパラメータ local.autorestart を yes に設定します。デフォルトでは、このパラメータは no に設定されています。
メッセージストアのサービスのどれかが失敗またはフリーズした場合、起動時に有効にしたすべてのメッセージストアのサービスが再起動されます。たとえば、imapd が失敗すると、少なくとも stored および imapd が再起動されます。POP または HTTP サーバーなど、メッセージストアのほかのサービスが実行されている場合、それらのサービスも失敗や成功にかかわらず再起動されます。
自動再起動は、メッセージストアユーティリティーが失敗またはフリーズした場合にも機能します。たとえば、mboxutil が失敗またはフリーズした場合、すべてのメッセージストアサービスが再起動されます。ただし、ユーティリティーは再起動されません。msprobe は 10 分ごとに実行されています。サービスとプロセスの再起動は 10 分間に最大 2 回実行されます (local.autorestart.timeout を使用して設定可能)。
local.autorestart が yes に設定されているかどうかにかかわらず、サービスはシステムによって監視され、失敗または応答なしのエラーメッセージがコンソールおよび msg-svr-base/data/log/watcher に送信されます。watcher はデフォルトではポート 49994 を待機しますが、これは local.watcher.port を使って設定可能です。
watcher ログファイルが msg-svr-base/data/log/watcher に生成されます。このログファイルは、ログが記録されるシステムでは管理されません (ロールオーバーおよび消去は行われない)。このログファイルにはすべてのサーバーの起動と停止が記録されます。ログの例を次に示します。
watcher process 13425 started at Tue Oct 21 15:29:44 2003 Watched ’imapd’ process 13428 exited abnormally Received request to restart: store imap pop http Connecting to watcher ... Stopping http server 13440 .... done Stopping pop server 13431 ... done Stopping pop server 13434 ... done Stopping pop server 13435 ... done Stopping pop server 13433 ... done imap server is not running Stopping store server 13426 .... done Starting store server .... 13457 checking store server status ...... ready Starting imap server ..... 13459 Starting pop server ....... 13462 Starting http server ...... 13471 |
この機能の設定方法の詳細については、「27.8.9 msprobe および watcher 関数を使用した監視」を参照してください。
msprobe は imsched によって制御されます。imsched がクラッシュすると、このイベントは watcher によって検出され、再起動がトリガーされます (自動再起動が有効になっている場合)。ただし、ごくまれに imsched がハングアップした場合は、kill imsched_pid を使用して imsched を強制終了する必要があります。これにより、imsched が watcher によって再起動されます。
可用性が高い配備での自動再起動には、次の configutil パラメータを設定する必要があります。
表 4–5 HA 自動再起動パラメータ
パラメータ |
説明/HA 値 |
---|---|
start-msg による起動で watcher を有効にします。デフォルトは yes です。 |
|
local.autorestart |
失敗またはフリーズした (応答しなくなった) サーバー (IMAP、POP、HTTP、ジョブコントローラ、ディスパッチャー、MMP サーバーなど) の自動再起動を有効にします。デフォルトは No です。 |
再試行失敗のタイムアウトです。ここに指定した時間内でサーバーに 3 回以上障害が発生すると、システムはサーバーの再起動を試行しなくなります。HA システムでこれが発生すると、Messaging Server がシャットダウンし、別のシステムへのフェイルオーバーが行われます。値 (秒数) は、msprobe の間隔よりも長い時間を設定するようにしてください。(後述の local.schedule.msprobe を参照)。デフォルトは 600 です。 |
|
msprobe の実行スケジュールです。crontab 形式でスケジュールを示す文字列です (表 20–10 を参照)。デフォルトは 5,15,25,35,45,55 * * * * lib/msprobe です。 無効にするには、local.schedule.msprobe.enable を NO に設定します。 |
Messaging Server は、imsched というプロセスを使って一般的なタスクスケジュールを行うメカニズムを提供します。これは、Messaging Server プロセスをスケジュールするためのものです。これは、local.schedule.taskname configutil パラメータを設定して有効にします。スケジュールを変更している場合は、コマンド stop-msg sched および start-msg sched を使用してスケジューラを再起動するか、refresh sched でスケジューラプロセスを更新する必要があります。
パラメータには、コマンドとコマンドを実行するスケジュールが必要です。形式は次のとおりです。
configutil -o local.schedule.taskname -v “schedule”
taskname は、このコマンドとスケジュールの組み合わせを示す一意の名前です。
schedule は次の形式をとります。
minute hour day-of-month month-of-year day-of-week command args
command args (コマンド 引数) は、Messaging Server の任意のコマンドとその引数をとることができます。コマンドのパス名は、完全修飾でなければなりません。
minute hour day-of-month month-of-year day-of-week (分 時 日付 月 曜日) は、コマンドを実行するスケジュールです。UNIX の crontab の書式に従います。
値は空白文字またはタブ文字で区切られ、値の範囲は、分は 0 〜 59、時は 0 〜 23、日付は 1 〜 31、月は 1 〜 12、曜日は 0 〜 6 (0 = 日曜日) となります。各時間フィールドには、アスタリスク (すべての取りうる値)、コンマ区切りの値のリスト、またはハイフンで区切られた 2 つの値による範囲を使用することもできます。日は日付と曜日の両方を使用して指定します。両方の使用を指定した場合には、どちらの値も必要です。たとえば、月の 17 日目と火曜日を設定すると、コマンドは、火曜日で、かつ 17 日である場合だけ実行されます。表 20–10 を参照してください。
スケジューラを変更している場合は、コマンド stop-msg sched および start-msg sched を使用してスケジューラを再起動するか、SIGHUP をスケジューラプロセスに送信する必要があります。
kill -HUP scheduler_pid
スケジュールされたタスクを無効にするには、次を実行します。
# configutil -o local.schedule.taskname.enable -v no # refresh sched |
imexpire を 12:30am、8:30am、4:30pm に実行する場合
# configutil -o local.schedule.rm_messages -v “30 0,8,16 * * * /opt/SUNWmsgsr/sbin/imexpire” |
次の例では、MTA チャネルキューのメッセージカウンタを 20 分おきに表示します。
# configutil -o local.schedule.counters -v “20,40,60 * * * * /opt/SUNWmsgsr/sbin/ims # imta qm counters > /tmp/temp.txt” |
次の例では、imsbackup を月曜日から金曜日の真夜中 (12 am) に実行します。
# configutil -o local.schedule.msbackup -v “0 0 * * 1-5 /opt/SUNWmsgsr/sbin/imsbackup -f \ backupfile /primary” |
インストール時に、定義済みの自動タスクが Messaging Server によって作成およびスケジュールされて、有効になります。それらを次に示します。
メッセージストア用に次の自動タスクが設定されて、有効になります。
local.schedule.expire = "0 23 * * * sbin/imexpire" local.schedule.expire.enable = 1 local.schedule.snapshotverify = "0 0,4,8,12,16,20 * * * sbin/imdbverify -m" local.schedule.snapshotverify.enable = 1 |
MTA 用に次の自動タスクが設定されて、有効になります。
local.schedule.purge="0 0,4,8,12,16,20 * * * sbin/imsimta purge -num=5" local.schedule.purge.enable = 1 local.schedule.return_job = "30 0 * * * lib/return_job" local.schedule.return_job.enable = 1 |
メッセージストア用に次の自動タスクが設定されて、有効になります。
local.schedule.msprobe = "5,15,25,35,45,55 * * * * lib/msprobe" local.schedule.msprobe.enable = 1 |
Messaging Server では、コンソールまたはパラメータを使って、新規ユーザーに送る電子メールグリーティングメッセージを作成できます。
コマンド行を使って新規ユーザーへのグリーティングメッセージを作成するには、次のように入力します。
configutil -o gen.newuserforms -v Message
Message には少なくとも件名行を含むヘッダーがあり、$$、メッセージ本文がその後に続いている必要があります。$ は、新しい行を表します。
たとえばこのパラメータを有効にするため、次のように設定変数を設定することができます。
configutil -o gen.newuserforms -v ’Subject: Welcome!! $$ Sesta.com welcomes you to the premier internet experience in Dafandzadgad!
使用しているシェルによっては、$ の前に特殊文字を追加して、$ が持つ特殊な意味をエスケープする必要があることもあります。(ほとんどの場合、$ はシェルのエスケープ文字。)
新規のホストしているドメインを作成する場合は常に、サポートされている言語のドメイン単位のグリーティングメッセージを作成することをお勧めします。これを行わない場合は、gen.newuserforms によって設定されている一般的なグリーティングメッセージが送信されます。
新規ユーザーへのグリーティングメッセージは、ドメインごとに設定できます。メッセージは、ユーザー、ドメイン、またはサイトの優先言語に応じて変えることができます。これを行うには、対象の LDAP ドメインエントリの mailDomainWelcomeMessage 属性を設定します。属性の構文は次のとおりです。
mailDomainWelcomeMessage;lang-user_prefLang mailDomainWelcomeMessage;lang-domain_prefLang mailDomainWelcomeMessage;lang-gen.sitelanguage |
次の例では、英語のドメインのグリーティングメッセージが設定されています。
mailDomainWelcomeMessage;lang-en: Subject: Welcome!! $$Welcome to the mail system.
次の例では、フランス語のドメインのグリーティングメッセージが設定されています。
mailDomainWelcomeMessage;lang-fr: Subject: Bienvenue!! $$Bienvenue a siroe.com!
上記の例から、次のことを仮定します。
ドメインは siroe.com である
新規ユーザーはこのドメインに所属している
LDAP 属性 preferredlanguage で指定されているように、ユーザーが優先する言語はフランス語である
siroe.com では、上記の英語およびフランス語のグリーティングメッセージが使用可能である
gen.sitelanguage で指定されているように、サイト言語は en である
サポートされるロケールおよびその言語値タグの一覧は、Directory Server Reference Manualを参照してください。
ユーザーは、初めてログインしたとき、フランス語のグリーティングメッセージを受信します。フランス語のグリーティングメッセージが使用不可の場合、英語のグリーティングメッセージを受信します。
グリーティングメッセージは、LDAP 属性 mailDomainWelcomeMessage と configutil パラメータ gen.newuserforms の両方によって設定できます。メッセージが選択される順序を、優先順位の高い順に次に示します。
mailDomainWelcomeMessage;lang-user_prefLang mailDomainWelcomeMessage;lang-domain_prefLang mailDomainWelcomeMessage;lang-gen.sitelanguage mailDomainWelcomeMessage gen.newuserforms;lang-"$user-prefLang" gen.newuserforms;lang-"$domain-prefLang" gen.newuserforms;lang-"$gen.sitelanguage" gen.newuserforms |
アルゴリズムは次のように機能します。ドメインが存在しない場合 (または存在してもドメイン単位のグリーティングメッセージが提供されない場合)、gen.newuserforms パラメータが指定されていれば、このパラメータを使ってグリーティングメッセージが設定されます。ユーザーに優先言語があり (preferredlanguage LDAP 属性で設定)、gen.newuserforms;lang-user_prefLang が設定されていれば、ユーザーはサーバーに最初にログインしたときにグリーティングメッセージを受信します。gen.newuserforms;lang-gen.sitelanguage が設定されていて、preferredlanguage が設定されていない場合で、サイト言語が設定 (gen.sitelanguage パラメータを使用) されている場合、ユーザーはメッセージを受信します。言語タグのパラメータが設定されていない場合は、タグなしの gen.newuserforms が設定されていれば、そのメッセージがユーザーに送信されます。いずれの値も設定されていない場合は、ユーザーはグリーティングメッセージを受信しません。
ユーザーがドメインに所属している場合は、上記の説明と同様に、ユーザーは mailDomainWelcomeMessage;lang-xx のうちのいずれかを受信します。受信するメッセージは、どのメッセージがリストおよび所定の順序で使用可能であるかによって異なります。
次にその例を示します。ドメインは siroe.com です。ドメインの優先言語はドイツ語 (de) です。しかし、このドメインの新規ユーザーの優先言語はトルコ語 (tr) です。サイト言語は英語です。使用できる値は次のとおりです (mailDomainWelcomeMessage はドメイン siroe.com の属性)。
mailDomainWelcomeMessage;lang-fr mailDomainWelcomeMessage;lang-ja gen.newuserforms;lang-de gen.newuserforms;lang-en gen.newuserforms |
アルゴリズムに従って、ユーザーに送信されるメッセージは gen.newuserforms;lang-de になります。
管理者は、ユーザーの LDAP エントリの属性 preferredLanguage を設定することで、GUI およびサーバーで生成されるメッセージの優先言語を設定できます。
サーバーの管理ドメイン外のユーザーにメッセージを送信する場合、サーバーはそのユーザーの優先言語は判断できません。ただし、その着信メッセージが、ヘッダーに優先言語が指定された着信メッセージへの応答である場合を除きます。これらのヘッダーフィールド (accept-language、Preferred-Language、または X-Accept-Language) は、ユーザーのメールクライアントで指定された属性に応じて設定されています。
優先言語に対して複数の設定がある場合、たとえば、Directory Server に保存されている優先言語属性とメールクライアントで指定された優先言語があるような場合は、次の順序で優先言語が選択されます。
元のメッセージの accept-language ヘッダーフィールド
元のメッセージの Preferred-Language ヘッダーフィールド
元のメッセージの X-Accept-Language ヘッダーフィールド
差出人の優先言語属性 (LDAP ディレクトリで見つかった場合)
ドメインの優先言語は、特定のドメイン用に指定されているデフォルトの言語です。たとえば、mexico.siroe.com というドメイン用にスペイン語を指定するとします。管理者は、ドメインの LDAP エントリの属性 preferredLanguage を設定することでドメインの優先言語を設定できます。
次の手順に従って、サーバーのデフォルトサイト言語を指定できます。ユーザーの優先言語が設定されていない場合は、サイト言語を使用して特定言語のメッセージを送信します。
コマンド行: 次に示すように、サイト言語を指定します。
configutil -o gen.sitelanguage -v value
value には、ローカルでサポートされているいずれかの言語を指定できます。サポートされるロケールおよびその言語値タグの一覧は、『Sun Java System Directory Server 5 2005Q1 Administration Guide』の第 5 章を参照してください。
Messaging Server は、Sun Java System Directory Server などの LDAP ベースのディレクトリシステムがないと機能しません。Messaging Server には、多くの目的を果たすためにディレクトリアクセスが必要です。次に例を示します。
メールユーザーまたはメールグループ用のアカウント情報を作成または更新すると、その情報はユーザーディレクトリと呼ばれるディレクトリに保存されます。
メッセージのルーティング時やメールボックスへのメールの配信時に、Messaging Server はユーザーディレクトリ内で差出人または受取人に関する情報を検索します。
メールルーティングの検索のためにユーザーの認証を行います。
別のユーザーディレクトリに接続してユーザーやグループを検索するように Messaging Server を再設定するかどうかは、管理者の判断次第です。通常は、サーバーの管理ドメインを定義しているユーザーディレクトリがドメイン内のすべてのサーバーによって使用されます。
ユーザーディレクトリ接続設定のコマンドを説明しますが、その前に次のようにして LDAP および PAB のパスワードを設定してください。
設定属性 local.ugldapbinddn で指定されているユーザーのパスワードを変更します。このユーザーアカウントは、設定属性 local.ugldaphost に指定されているディレクトリサーバー内にあります。
local.service.pab.ldapbinddn および local.service.pab.ldaphost 属性で指定されているものと同じアカウントが PAB アクセスで使用されている場合は、local.service.pab.ldappasswd に保存されているパスワードも更新する必要があります。
Messaging Server 固有のディレクトリ設定を使用するかどうかを指定するには、次のように入力します。
configutil -o local.ugldapuselocal -v [ yes | no ]
ホスト名: インストールのユーザー情報を含むディレクトリがあるホストマシンの名前。通常、これは Messaging Server ホストとは別のものです。ただし、非常に小規模のインストールでは、同じ場合もあります。ユーザー検索用の LDAP ホスト名を指定するには、次のように入力します。
configutil -o local.ugldaphost -v name[: port_number]
ポート番号: Messaging Server がユーザー検索用のディレクトリにアクセスするときに使用するディレクトリホストのポート番号。この番号は、ディレクトリ管理者が定義するもので、必ずしもデフォルトのポート番号 (389) である必要はありません。ユーザー検索用の LDAP ポート番号を指定するには、次のように入力します。
configutil -o local.ugldapport -v number
ベース DN: 検索ベース (ユーザー検索の開始点を示すディレクトリエントリの識別名)。ディレクトリツリー内で検索ベースが目的の情報に近いほど、検索処理は速くなります。ディレクトリツリーに「people」や「users」などの分岐がある場合は、それを開始点にするのが妥当です。ユーザー検索用の LDAP ベース DN を指定するには、次のように入力します。
configutil -o local.ugldapbasedn -v basedn
バインド DN: Messaging Server が検索を行うために Directory Server に接続する際、その Messaging Server を識別するために使われる名前。バインド DN は、ディレクトリのユーザー部分に対する検索特権がある、ユーザーディレクトリのエントリの識別名でなければなりません。ディレクトリに対して匿名検索アクセスを許可する場合は、このエントリを指定しないことも可能です。ユーザー検索用の LDAP バインド DN を指定するには、次のように入力します。
「23.5.2 SSL を有効化し暗号化方式を選択する」で説明します。また、Messaging Server のセキュリティーとアクセス制御に関するすべてのトピックにおける背景情報についても説明しています。
複数の LDAP サーバーをユーザーまたはグループディレクトリとして指定することができます。これによって、1 つのサーバーに障害が発生しても別のサーバーが処理を引き継ぎます。
local.ugldaphost を複数の LDAP マシンに設定します。次にその例を示します。
configutil -o local.ugldaphost -v "server1 server2 ..."
local.ugldapuselocal を yes に設定します。これによって、ユーザーまたはグループの LDAP 設定データはローカル設定ファイルに保存されます。これ以外の場合は、LDAP に保存されます。次にその例を示します。
configutil -o local.ugldapuselocal -v yes
リストにある最初のサーバーに障害が発生した場合、既存の LDAP 接続はダウンしたとみなされ、新しい接続が確立されます。新規の LDAP 接続が必要な場合、LDAP ライブラリはすべての LDAP サーバーをリストされている順序で試します。