パッケージ・プログラムにより、クライアントの構成プロセスが多くの点で自動化できます。パッケージ・プログラムを使用すると、グローバル構成ファイルを定義して、多くのクライアントのローカル・ディスクの構成が簡単に行えます。
本章では、指示されたコマンド、またはプロトタイプ・ファイルの命令を使用した以下のタスクの実行方法を説明します。
クライアント・マシンのローカル・ディスクの構成 | パッケージ |
ディレクトリーを定義する | D[update_code] directory owner group mode_bits |
ファイルを定義する | F[update_code] file source_file [owner group mode_bits] |
記号リンクの定義 | L[update_code] link actual_file [owner group mode_bits] |
ブロック・スペシャル装置の定義 | B device_name major_device_number minor_device_number owner group mode_bits |
キャラクター型スペシャル装置の定義 | C device_name major_device_number minor_device_number owner group mode_bits |
ソケットを定義する | S socket_name [owner group mode_bits] |
パッケージ・プログラムは、システム独立型のプロトタイプ・ファイルを使用して、標準のディスク構成を定義します。プロトタイプ・ファイルは、どのファイルがローカル・クライアント・ディスクに常駐すべきか、どのファイルが AFS へのリンクとなるべきか、などを指示します。この後、このプロトタイプ・ファイルは、それぞれのシステム・タイプごとに構成ファイルにコンパイルされます。
すべてのクライアント・マシンが同じ構成を持つわけではありません。異なるプロトタイプ・ファイルを異なるクライアント機能 (プリント・サーバー、正規クライアント、など) に作成することも可能です。.
パッケージ・プログラムは、ローカル・クライアント・ディスクの内容を構成ファイルと比較します。何らかの相違がある場合は、 パッケージが、AFS からのファイルをディスクにコピーし、ローカル・ディスクに必要な更新を行います。パッケージ・プログラムの構成で、システム構成の一部ではないファイルを削除したり、または特定のファイル (dkload など) が更新されたときに、クライアントを自動的にリブートすることもできます。
パッケージ・プログラムでは、プロトタイプ・ファイルが作成されるまで、ある程度の時間がかかりますが、以下のような利点が生じます。
パッケージは、クライアント・マシン上で使用するように設計されていますが、ファイル・サーバー・マシンのディスクの構成に使用することもできます。しかし、構成ファイル内の参照されたファイルのいずれかが、そのファイル・サーバー上のボリュームに常駐している場合、 パッケージ・プログラムは、リブート中 (また、そのファイル・サーバーの処理、およびボリューム・サーバーの処理が再開するまで) は、そのボリュームにアクセスできなくなります。
パッケージ・プログラムがファイルにアクセスできずにアボートした場合、ファイル・サーバー・マシン上のボリュームに常駐している AFS 内のファイルへの参照を除去する必要があります。これらの制約のため、以下この章では、 パッケージ・プログラムがクライアント構成に使用されていることを前提としています。
パッケージ・プログラムを実行する前に、3 つの主なステップを踏む必要があります。
以下は、これらのステップの要約です。
クライアント・マシンが実行する各種機能および役割、およびこれらの機能をサポートするローカル・ディスク構成をリストすることより始めます。サンプルの役割には、AFS アクセスを提供する標準クライアント、プリンターを駆動するプリント・サーバー、および backup スイートからコマンドを発行するバックアップ・マシンが含まれます。役割ごとに、異なる プロトタイプ・ファイル を作成します。
プロトタイプ・ファイルは、特定の役割をサポートするディスク構成を定義します。通常、プロトタイプ・ファイルは、機能特定型のファイルですが、システムからは独立しています。つまり、システム特定型の値は、変数およびライブラリー・ファイルを使用して定義することができます。そのため、変数またはライブラリー・ファイルを変更すると、その変更は パッケージ・プログラムが起動されるときに、すべての該当するクライアントに伝達されます。
サンプル・プロトタイプ・ファイルおよびライブラリー・ファイル に、保守が簡単でフレキシブルなプロトタイプ・ファイルを構築するための方法が記載されています。
プロトタイプ・ファイルは、通常、システムからは独立したファイルですが、異なるシステム・タイプの必要性を満たすために ifdef ステートメントが組み込まれている場合があります。プロトタイプ・ファイルは、オペレーティング・システム特定型のバージョンを生成するためにコンパイルされます。コンパイル中、 パッケージ・プログラムは、それぞれのシステム・タイプごとに適切な定義を選択し、任意の変数を実際の値と置き換えます。これらのコンパイルされた、マシン特定型のファイルを、構成ファイルと呼びます。
プロトタイプ・ファイルは、パッケージ Makefile ファイル に記載されているように、標準タイプの Makefile ファイルを使用してコンパイルされます。
システム特定型の構成ファイルが作成されると、 パッケージ・プログラムがそのクライアント上で実行できるようになります。最初に、 パッケージのバイナリーを使用可能にし、正しい構成ファイルを指定しなければなりません。
以下に記載されているようにクライアントを変更します。
これらのステップは、クライアント・マシンの変更 に詳細に記されています。
本機能グループは、AFS インストールの手引き に推奨されているように、 パッケージ関連のファイルが、/afs/cellname/wsadmin の 3 つのサブディレクトリーの src、lib および etc に導入されていることを前提としています。
これらのディレクトリーには、いくつかのサンプル・プロトタイプ、ライブラリー、および構成ファイルが含まれており、 パッケージ・プログラムの機能を説明する手助けとなります。ただし、これは所属するセルに適したものであるとは限らず、必要に応じて修正する必要があります。
src ディレクトリーには、いくつかのサンプル・プロトタイプ・ファイル (構成ファイルの作成に使用される) 、プロトタイプ・ファイルの作成に使用される MAKE ファイル 、および結果としてのコンパイルされた構成ファイルが含まれます。
プロトタイプ・ファイルは、function.proto 形式の名前をとります。たとえば、minimal.proto ファイルは、 AFS の実行に必要な最小限のライブラリー・ファイルを定義し、staff.dkload.proto ファイルは、動的カーネル・ロード・プログラムを使用したクライアントの構成を定義します。プロトタイプ・ファイルは、 hosts.equiv などのシステム管理ファイルの定義を含むこともできます。
Makefile は、システムから独立したプロトタイプ・ファイルをシステム特定型の構成ファイルにコンパイルするために使用されます。ユーザーのセル内での使用のためにこのファイルを変更するには、パッケージ Makefile ファイル を参照してください。
構成ファイルは、プロとタイプ・ファイルのコンパイルされたバージョンで、 function.sysname という名前で呼ばれています。構成ファイルは、etc サブディレクトリー内にも表示され、 パッケージプログラムがディスクを構成するときにアクセスします。
lib ディレクトリーには、プロトタイプ・ファイル内で参照されたサンプル・ライブラリー・ファイルの多くが含まれます。たとえば、base.generic ファイルは、システムから独立したファイルで、セル名、システム・オプションおよび変数の各定義が組み込まれています。これらは、そのファイル内の owner、group、および mode_bits フィールド、およびシンボリック・リンクの定義の設定に使用されます。
etc ディレクトリーには、src サブディレクトリー内のプロトタイプ・ファイルから作成された、システム特定型の構成ファイルが含まれます。 パッケージ・プログラムは、 etc ディレクトリー内の構成ファイルを使用して、ディスクを構成します。
いくつかのサンプル・ファイルには、異なるシステム・タイプ用にコンパイルされた、minimal、および staff プロトタイプ・ファイルが組み込まれています。
プロトタイプ・ファイルは、クライアントのローカル・ディスクの構成を定義するテンプレートです。プロトタイプ・ファイルは、通常、機能特定型のファイル (たとえば、バックアップ・マシン、プリント・サーバーなど) ですが、システム独立型のファイルです。プロトタイプ・ファイルは、 ifdef ステートメントおよび変数をサポートしますので、システム特定型の定義を組み込むことができます。実際のシステム特定型の構成ファイルは、そのプロトタイプ・ファイルがコンパイルされるときに生成されます。
プロトタイプ・ファイル内に定義されているコンポーネンツは、プリント・サーバーあるいはバックアップ・マシンのような特定の役割を実行するために、クライアントのローカル・ディスク上に常駐している必要のあるディレクトリー、ファイル、シンボリック・リンク、ブロック・スペシャル・デバイス、キャラクター型スペシャル・デバイス、およびソケットを組み込むことができます。そのため、それぞれの異なるクライアント機能ごとに固有のプロトタイプ・ファイルを構成することをお勧めします。
パッケージ・プログラムをより有効に、かつ保守を簡単にするために、特定のプロトタイプ・ファイルではなく、モジュラーで汎用的なプロトタイプ・ファイルを作成します。
以下は、AFS を実行するのに必要な最低限の定義を含むサンプル・プロトタイプ・ファイルの一部です。 minimal.proto と呼ばれる類似ファイルが、src サブディレクトリーに常駐している場合があります。推奨されているように、このプロトタイプ・ファイルはライブラリー・ファイルを参照するのであって、実際の定義が組み込まれているのではありません。
. . # Package prototype for a minimal configuration. # Base components %include ${wsadmin}/lib/base.generic # Machine-specific components %ifdef rs_aix42 %include ${wsadmin}/lib/rs_aix42.readonly %include ${wsadmin}/lib/rs_aix42.AFS %endif rs_aix42 %ifdef alpha_dux40 %include ${wsadmin}/lib/alpha_dux40.readonly %include ${wsadmin}/lib/alpha_dux40.AFS %endif alpha_dux40 %ifdef sun4x_56 %include ${wsadmin}/lib/sun4x_56.readonly %include ${wsadmin}/lib/sun4x_56.AFS %endif sun4x_56 . .
上記サンプルのコメントのない第 1 行目には、/lib/base.generic ライブラリー・ファイルが組み込まれます。このライブラリー・ファイルには、多くのプロトタイプ・ファイルに適した定義が含まれている場合があります。 base.generic ライブラリー・ファイルも、staff.proto あるいは backup.proto のように、他のプロトタイプ・ファイルに組み込まれている場合があります。サンプル・ライブラリー・ファイルは、次の機能グループに記載されています。
システム特定型の定義は、ifdef 文および変数 (たとえば、${wsadmin} を使用してパス名を指定します) を使用した場合に許可されているので注意が必要です。したがって、異なるファイル、ディレクトリー、シンボリック・リンク、およびデバイスが必要な場合でも、 AIX 4.2 あるいは Solaris 2.6 を実行しているマシンを同じプロとタイプ・ファイルを使用して構成することができます。
このサンプルの、コメントのない次の行には、管理者が異なるシステム・タイプの異なるライブラリー・ファイルを構成してあります。これらはそれぞれ、固有の構成ファイルにコンパイルされます。たとえば、このプロトタイプ・ファイルの下記の行は、値 rs_aix42 が宣言されたら、構成ファイル用にライブラリー・ファイル lib/rs_aix42.readonly および lib/rs_aix42.AFS を使用するようパッケージ・プログラムに伝えます。 (システム・タイプの定義は、Makefile で宣言されます。パッケージ Makefile ファイル を参照してください。)
%ifdef rs_aix42 %include ${wsadmin}/lib/rs_aix42.readonly %include ${wsadmin}/lib/rs_aix42.AFS %endif rs_aix42
同様に、下記の行は、値 sun4x_56 が宣言されたら、ライブラリー・ファイル lib/sun4x_56.readonly および lib/sun4x_56.AFS を使用するよう パッケージ・プログラムに伝えます。
%ifdef sun4x_56 %include ${wsadmin}/lib/sun4x_56.readonly %include ${wsadmin}/lib/sun4x_56.AFS %endif sun4x_56
以下は、基本的な構成定義のためのサンプル・ライブラリー・ファイルの一部です。base.genericと呼ばれる類似ファイルが、lib サブディレクトリーに常駐している場合があります。構成は、標準の ifdef ステートメントを使用して定義されますので、ご注意ください。
. . # # Base package definitions. # %ifndef cell %define cell abc.com %endif cell %ifndef sys %include /etc/package.sys %endif sys %define ${name} ${name} %define ${cpu} ${cpu} %define ${sys} ${sys} %define ${dept} ${dept} %define ${hostname} ${hostname} %ifdef rs_aix42 % define AIX % define rootlinks %ifndef noafsd % define afsd %endif noafsd %endif rs_aix42 . . # # Some definitions to handle common combinations of owner, group, # and protection fields. # %define rzmode root wheel 600 %define usermode root wheel 666 %define systemmode root wheel 644 %define diskmode root wheel 644 %define ptymode root wheel 666 %define ttymode root wheel 666 . . %define aix_rootbin root bin %define aix_rootprintq root printq %define aix_rootstaff root staff %define aix_rootsys root system %define aix_binbin bin bin %define aix_binmail bin mail %define aix_binsys bin system %define aix_addsys adduser system %define aix_romode 444 %define aix_loginmode 544 %define aix_usermode 666 %define aix_systemmode 644 %define aix_textmode 644 %define aix_rwmode1 660 %define aix_allrugw 664
以下のサンプル・ライブラリー・ファイルは、パッケージ特定型の構文を使用して、ファイル、ディレクトリー、ソケットなどを定義しています。構成ファイル行と呼ばれる各行は、ディスク構成の、ある特定のコンポーネントを定義します。この命令の正しい構文は、 パッケージ構成ファイル命令の構文 に簡単に記載されています。詳細は、AFS Administration Reference のパッケージ構成ファイルを参照してください。
このサンプルでは、ライブラリー・ファイルに、 rs_aix42 マシンの構成特有の命令が含まれています。ユーザーの lib サブディレクトリーに類似のライブラリー・ファイルがある場合があります。
. . # # Generic configuration for an AFS rs_aix42 machine. # D / ${treemode} D /afs FAQ /unix ${machine}/unix.std ${binmode} LA /unix.std /unix D /bin ${treemode} F /bin/as ${machine} ${binmode} F /bin/ld ${machine} ${binmode} F /bin/nm ${machine} ${binmode} FO /bin/login ${afstest} ${suidmode} . . FAQ /usr/vice/etc/ThisCell ${common}/etc/ThisCell ${textmode} FQ /usr/vice/etc/afsd ${afstest}/root.client ${binmode} FA /usr/vice/etc/bos ${afstest}/bin/bos ${binmode} FA /usr/vice/etc/fs ${afstest}/bin/fs ${binmode}
ライブラリー・ファイル内では、構成ファイル命令は、特定のディスク構成の定義に使用されます。各命令は、クライアント・マシン上のファイル、ディレクトリー、ソケット、あるいはデバイスの定義に使用することができます。各有効命令タイプの構文は、ここに簡単に記載されています。フィールドの詳細記述については、 AFS コマンド解説書 に記載されています。
注: | それぞれの構成命令は、単一行に改行なしで配置しなくてはなりません。ここで複数行にわたって現れる命令がありますが、これは単に読みやすくするためです。
構成ファイルは、完全に正しいものである必要があります。構文エラーや誤った値があると、 package コマンド・インタープリターは命令を実行せずに終了します。 |
AFS 分散ファイル・システムの利点を生かすために、ローカル・クライアント・ディスク上のファイル数を最小限に抑えることをお勧めします。代わりに、AFS へと指しているシンボリック・リンクを作成します。こうすることによって、キャッシングおよびスワッピングのスペースを広げ、マシンのパフォーマンスを向上させます。
しかし、いくつかのファイルは、以下に記載されているように、ローカル・ディスク上に常駐しなければなりません。これらのファイルは、L (シンボリック・リンク) 命令ではなく F (ファイル) 命令を使用して、プロトタイプ・ファイルまたはライブラリー・ファイル内に作成してください。
以下のタイプのファイルは、すべての AFS クライアントのローカル・ディスク上に常駐していなければなりません。
afsd が実行され、キャッシュ・マネージャーが初期化されるまで、AFS はクライアントからアクセスできません。afsd より前に実行されるファイルはいずれも、ローカル・クライアント・ディスク上に常駐していなければなりません。
たとえば、ディスク・キャッシュを使用するマシンの場合、 /usr/vice/cache ディレクトリーは、キャッシュ・マネージャーを立ち上げる際には、キャッシュ・ファイルのロケーションの確保のために必ず存在していなければなりません。バイナリー・ファイル /etc/mount および /etc/umount は、マシンがブートする際にローカル・ディスク上で使用可能な状態である必要があり、 /usr/vice/cache ディレクトリーがマウントできるようにします。
また、初期設定ファイル (/etc/rc またはこれに同等) およびファイル・システム・マッピング・ファイル (/etc/fstab またはこれに同等) など特定の UNIX ファイルは、ローカル・ディスク上に常駐していなければなりません。
ある特定のコマンドが、ファイル・サーバーの故障が原因である問題の診断および回復に使用することができます。これらコマンドのバイナリーのコピーをローカル・ディスク上に配置しておくのがよいでしょう。たとえば、 bos および fs バイナリーをローカル・ディスクの /usr/vice/etc ディレクトリー、および /usr/afsws ディレクトリー (通常の構成における、 AFS へのシンボリック・リンク) に保管します。その上で、PATH 環境変数を設定し、 /usr/afsws が/usr/vice/etc の前に表示されるようにします。これにより、ユーザーが AFS にアクセスできない場合 (たとえば、ファイル・サーバー障害による)、bos および fs バイナリーのコピー (ローカル・ディスクの /usr/vice/etc にある) にアクセスすることができます。
cache サブディレクトリー内のキャッシュおよび etc サブディレクトリー内の構成ファイルを含む /usr/vice ディレクトリーの内容は、ローカル・ディスク上に常駐している必要がありますディレクトリー内のファイルの説明については、ローカル・ディスク上の構成ファイルおよびキャッシュ関連ファイル を参照してください。
D 命令は、ローカル・ディスク上に作成されるディレクトリーを定義します。シンボリック・リンク、ファイル、またはローカル・ディスクのその他の要素が同じ名前を持つ場合、これはディレクトリーに置き換えられます。ディレクトリーが既に存在する場合、その所有者、グループ、およびモード・ビットが、必要に応じて命令に適合するよう変更されます。
下記の命令を使用して、ディレクトリーを定義してください。
D[update_code] directory owner group mode_bits
下の例は、/usr ディレクトリーを定義しています。
D /usr root wheel 755
F 命令は、ローカル・ディスク上に作成されるファイルを定義します。ソース・ファイルは、AFS 内あるいはローカル・ディスク内のいずれかに常駐することができます。
この名前のファイルがすでに存在する場合は、I 更新コードが指定されていない限り、そのファイルはソース・ファイルで更新 (上書き) されています。この名前のシンボリック・リンクあるいはディレクトリーが存在する場合は、パッケージがソース・ファイルと置き換えます。
注: | ファイルには、ローカル・ディスクに常駐しなければならないものがあります。これらは、シンボリック・リンクになることはできません。ローカル・ファイル対シンボリック・リンク を参照してください。 |
下記の命令を使用して、ファイルを定義してください。
F[update_code] file source_file [owner group mode_bits]
ソースとして /afs/abc.com/rs_aix42/bin/grep を使用して、ローカル・ディスク上にファイル /bin/grep を作成/更新する例。
F /bin/grep /afs/abc.com/rs_aix42 root wheel 755
下の例では、2 つの更新コードが使用されており、owner 、group および mode_bits スロットが空です。そのため、そのディスク・ファイルはそれらのスロットにソース・ファイルの値を採用します。
FAQ /usr/vice/etc/ThisCell /afs/abc.com/common/etc/ThisCell
L 命令は、ローカル・ディスク上に作成されるシンボリック・リンクを定義します。シンボリック・リンクは、AFS ファイル・システムまたはローカル・ディスクを指す場合があります。同一のシンボリック・リンクがすでに存在する場合、パッケージは何も行いません。しかし、同じ名前の要素がファイルまたはディレクトリーとしてディスク上に存在する場合は、 パッケージは、その要素をシンボリック・リンクと置き換えます。
注: | ファイルには、ローカル・ディスクに常駐しなければならないものがあります。これらは、シンボリック・リンクになることはできません。ローカル・ファイル対シンボリック・リンク を参照してください。 |
以下の命令を使用して、シンボリック・リンクを定義します。
L[update_code] link actual_file [owner group mode_bits]
注: | 名前が番号記号 (#) またはパーセント記号 (%) で始まるファイルに対して、記号リンクを作成してはいけません。キャッシュ・マネージャーはこのようなリンクをそれぞれ標準の、または読み取り / 書き込みボリュームに対するマウント・ポイントと解釈します。 |
以下の例は、ローカル・ディスク上の /etc/ftpd から AFS 内の /afs/abc.com/hp_ux110/etc/ftpd へのシンボリック・リンクを作成します。owner、group および mode_bits の各フィールドが空のため、シンボリック・リンクはこれらのフィールドに実際のファイルから値を採用します。
L /etc/ftpd /afs/abc.com/hp_ux110
この例は、A 更新コードを使用しています。
LA /etc/printcap /afs/abc.com/common/etc/printcap.remote root wheel 644
B 命令は、ブロック・スペシャル・デバイスを定義します。ブロック・スペシャル・デバイスは、ディスクのような、マルチバイト・ブロックのユニット内のデータを使用するデバイスです。同じ名前のデバイスがすでに存在する場合、 パッケージは、それを指定されたブロック・デバイスと置き換えます。
以下の命令を使用してブロック・スペシャル装置を定義します (ここでは読みやすくするため 2 行で表示します)。
B device_name major_device_number minor_device_number \ owner group mode_bits
下の例は、/dev/hd0a と呼ばれるディスクのメジャー・デバイス番号およびマイナー・デバイス番号を 1 および 0 に定義しています。
B /dev/hd0a 1 0 root wheel 644
C 命令は、キャラクター型スペシャル・デバイスを定義します。これは、ターミナルまたは tty のような、一度に 1 つの文字のユニット内のデータを使用するデバイスです。同じ名前のデバイスがすでに存在する場合、パッケージは、それを指定されたキャラクター・デバイスと置き換えます。
以下の命令を使用してキャラクター型スペシャル・デバイスを定義します (ここでは読みやすくするため 2 行で表示します)。
C device_name major_device_number minor_device_number \ owner group mode_bits
下記の例は、/dev/ttyp5 と呼ばれる tty のメジャー・デバイス番号およびマイナー・デバイス番号を 6 および 5 に定義しています。
C /dev/ttyp5 6 5 root wheel 666
S 命令は、ソケットを定義しています。ソケットは、UDP および TCP/IP 接続用の通信装置です。同じ名前のソケットがすでに存在する場合、パッケージは、それを置き換えます。
以下の命令を使用して、ソケットを定義してください。
S socket_name [owner group mode_bits]
下の例は、/dev/printerと呼ばれるソケットを定義しています。
S /dev/printer root wheel 777
この機能グループは、パッケージのプロトタイプ・ファイルおよびライブラリー・ファイルの作成に必要な、一般的なステップを説明しています。ガイドラインについては前章を、例についてはユーザーの wsadmin ディレクトリー内のファイルを参照してください。プロトタイプ・ファイルおよびライブラリー・ファイルの構造は、それぞれのセルごとに異なります。
適切なプロトタイプ・ファイルおよびライブラリー・ファイルを作成したら、必ずそのプロトタイプをシステム・タイプごとにコンパイルしなければなりません。結果は、システム特定型の構成ファイルとなります。
Makefile ファイルは、使用されているプロトタイプ・ファイルとライブラリー・ファイルの定義、およびコンパイルの順序の定義をします。この機能グループに記載されているように、 AFS に提供されているサンプルを変更することによってユーザーの Makefile を作成することをお勧めします。通常の構成では、これは /afs/cellname/wsadmin/src/Makefile に配置されています。
以下のリストには、パッケージ Makefile ファイルの機能グループについて説明します。機能グループを開始するヘッダー名によりそれぞれを識別しています。詳細を以下に記します。
最後に、Makefile ファイルには、 パッケージ・プログラムが構成ファイルを生成するために従う命令セットが含まれます。この機能グループの変更は、一般に必要ありません。MAKE ファイルの命令機能グループ を参照してください。
前述のように、構成ファイルは、特定のオペレーティング・システム・タイプ用にコンパイルされたプロトタイプ・ファイルです。 Makefile ファイルの CONFIG 機能グループは、どのプロトタイプ・ファイルをどのシステム・タイプ用にコンパイルするのかを定義します。結果として生じたコンパイル済みファイルは、システム特定型の構成ファイルです。
サンプルの Makefile ファイルから取った以下の例をよくお読みください。構成ファイルが、プロトタイプ・システムの組み合わせを prototype_file.sysname と指定して定義されています。プロトタイプ・システム・タイプの組み合わせごとに構成ファイルを生成する必要はありませんので、ご注意ください。
#Makefile... # (C) Copyright IBM Corporation 1999 # Licensed Materials - Property of IBM # All Rights Reserved. # CONFIG = \ staff.rs_aix42 \ staff.alpha_dux40 \ staff.xdm.alpha_dux40 \ staff.sun4x_56 \ staff.hp_ux110 \ minimal.rs_aix42 \ minimal.alpha_dux40 \ minimal.hp_ux110 \ minimal.sun4x_56
CONFIG 機能グループの項目は以下の形式をとります。
たとえば、staff.rs_aix42 は、 staff.proto ファイルが AIX 4.2 を実行しているマシン用にコンパイルされることを示しています。結果のコンパイル済み構成ファイルは、 staff.rs_aix42 と呼ばれます。
この機能グループでは、任意のプロトタイプ・ファイルに組み込まれているすべてのシステム独立型および機能独立型のライブラリー・ファイルの完全なパス名を定義します。 (システム特定型のライブラリー・ファイルは、 MACHINE_LIBS 機能グループに定義されています)。パス名には、 ${wsadmin} 変数が組み込まれている場合があります。その値は、 make コマンド行に提供されています。
必ず、参照されているすべてのライブラリー・ファイルをプロトタイプ・ファイル内に組み込まなければなりません。組み込まれているファイルでも、使用されていないファイルは無視されます。
下の例をよくお読み下さい。すべての項目 (最後を除く) の後ろには、必ず円記号を付ける必要がありますので、ご注意ください。
BASE_LIBS = \ ${wsadmin}/src/admin \ ${wsadmin}/lib/devel \ ${wsadmin}/lib/base.generic
この機能グループは、プロトタイプ・ファイル内のすべてのオペレーティング・システム特定型のライブラリー・ファイルの完全なパス名をリストしています。 (システム独立型および機能独立型のライブラリー・ファイルは、 BASE_LIBS 機能グループに定義されています。)
下の例をよくお読み下さい。この例では、ライブラリー・ファイルがオペレーティング・システム・タイプによってグループ化されています。ここでも、すべての行 (最後を除く) の後ろには、必ず円記号が付いていなければなりません。 ${wsadmin} 変数が許可されています。また、組み込まれているファイルでも使用されていないファイルは無視されます。
MACHINE_LIBS = \ ${wsadmin}/lib/rs_aix42.generic \ ${wsadmin}/lib/rs_aix42.generic.dev \ ${wsadmin}/lib/rs_aix42.readonly \ ${wsadmin}/lib/rs_aix42.readwrite \ ${wsadmin}/lib/rt_aix42.generic.printer \ \ . . ${wsadmin}/lib/alpha_dux40.AFS \ ${wsadmin}/lib/hp_ux110.AFS \ ${wsadmin}/lib/sun4x_56.AFS \ ${wsadmin}/lib/rs_aix42.AFS
この機能グループには、1 つだけ命令が含まれています。その命令は、LIBS が、 MACHINE_LIBS および BASE_LIBS の組み合わせとして定義されていることを示しています。この行の後にブランク行を挿入して、この機能グループを次の行と分けてください。
LIBS = ${MACHINE_LIBS} ${BASE_LIBS}
この機能グループでは、有効なマシン・タイプのサフィックスをリストします。このリストには、現在 AFS でサポートされているシステム・タイプが含まれます。未使用のサフィックスは無視されます。
.SUFFIXES: .rs_aix42 \ .alpha_dux40 \ .proto \ .sun4x_56 \ .i386_linux22 \ .hp_ux110
Makefile ファイルの残りの部分では、 package プログラムによる構成ファイルの作成を制御します。
下の例をよくお読みください。ユーザーが、プログラミングおよび Makefile の概念に通じていることを前提としています。
#The following appear on a single line each in the actual file .proto.rs_aix42: ; mpp -Dwsadmin=${wsadmin} -Dsys=rs_aix42 -Dname=$* $*.proto > $@ .proto.alpha_dux40: ; mpp -Dwsadmin=${wsadmin} -Dsys=alpha_dux40 -Dname=$* $*.proto > $@ .proto.sun4x_56: ; mpp -Dwsadmin=${wsadmin} -Dsys=sun4x_56 -Dname=$* $*.proto > $@ .proto.hp_ux110: ; mpp -Dwsadmin=${wsadmin} -Dsys=hp_ux110 -Dname=$* $*.proto > $@ all: ${CONFIG} ${CONFIG}: ${LIBS} system: install install: ${CONFIG} cp ${CONFIG} ${wsadmin}/etc clean: rm -f ${CONFIG} *.BAK *.CKP
以下のような場合に、パッケージ Makefile ファイルを変更します。
これらの理由で Makefile ファイルを変更する方法の簡単な例を、以下の機能グループで提供します。
新規のプロトタイプ・ファイルを作成する場合、そのファイル名および Makefile ファイルの CONFIG 機能グループに新規のプロトタイプ・ファイルが構築される各システム・タイプを追加していください。
たとえば、 alpha_dux40 および hp_ux110 用の function.proto を追加するには、以下の項目を CONFIG 機能グループに追加します。
CONFIG = \ ... function.alpha_dux40 \ function.hp_ux110 \ ...
このプロトタイプ機能に新規のライブラリー・ファイルを追加した場合、それらを MACHINE_LIBS 機能グループに追加します。
新規のシステム・タイプ用に作成したいそれぞれのプロトタイプ・ファイルごとに、項目を CONFIG 機能グループに追加してください。任意の新規ライブラリーを MACHINE_LIBS 機能グループに、また、その新規のシステム・タイプを .SUFFIXES 機能グループに追加します。
以下の例は、この新規のシステム・タイプ用の staff および minimal プロトタイプ・ファイルを作成する際に適切な変更を示しています。
CONFIG = \ ... staff.sysname \ minimal.sysname \ ...
この新規のマシン・タイプに対応するライブラリー・ファイルが作成されている場合は、それらを MACHINE_LIBS 機能グループに追加します。
MACHINE_LIBS = \ ... ${wsadmin}/lib/sysname.generic \ ${wsadmin}/lib/sysname.generic.dev \ ${wsadmin}/lib/sysname.readonly \ ${wsadmin}/lib/sysname.readwrite \ ...
新規のシステム・タイプを SUFFIXES 機能グループに追加します。
.SUFFIXES: ...\ .sysname \ ...
このシステムのための構成ファイルを構築するための行を、構成ファイルを構築するための残りのコマンドのある機能グループに追加してください。
.proto.sysname: ; mpp -Dwsadmin=${wsadmin} \ -Dsys=sysname -Dname=$* $*.proto > $
システム・タイプごとに新規のライブラリー・ファイルを追加する場合は (sysname.library_file)、これらのファイルを Makefile ファイルの MACHINE_LIBS 機能グループに追加します。
MACHINE_LIBS = \ ... ${wsadmin}/lib/rs_aix42.library_file \ ... ${wsadmin}/lib/alpha_dux40.library_file \ ... ${wsadmin}/lib/sun4x_56.library_file \ ...
すべてのシステム・タイプに共通の新規のライブラリー・ファイルを追加する場合は (library_file)。これを BASE_LIBS 機能グループにのみ追加してください。
BASE_LIBS = \ ... ${wsadmin}/lib/library_file \ ...
パッケージ・プログラムは、構成ファイルを生成し、 make コマンド行で wsadmin= と指定されるディレクトリーの etc および src サブディレクトリーにこれを導入します。プロトタイプ・ファイルまたはライブラリー・ファイルを変更する場合は、必ず再コンパイルしてください。
注: | 以下の説明では、パッケージ関連のファイルが /afs/cellname/wsadmin ディレクトリーに格納されていることを前提としています。別のディレクトリーを使用する場合は、その名前を /afs/cellname/wsadmin に置き換えてください。 |
% fs listacl [dir/file path]
% cd /afs/cellname/wsadmin/src
% cp Makefile Makefile.example
wsadmin= 引き数を使用して、パッケージディレクトリーを指定します。これは、プロトタイプ・ファイルおよびライブラリー・ファイルの ${wsadmin} 変数の値になります。
パッケージ・プログラムは、構成ファイルを生成し、 wsadmin= ディレクトリーの etc および src サブディレクトリーにこれを導入します。
% make system wsadmin=/afs/cellname/wsadmin
クライアントが パッケージ・プログラムを自動的に実行するようにするには、以下のステップに従います。指示は、システム固有の構成ファイルを参照しないので、一般的なものです。必要であれば、 AFS Administration Reference に記載されているように、パッケージ・プログラムを特定の引き数で起動することもできます。
クライアント・マシンのルート (/) ディレクトリーにある .package ファイルは、 パッケージ・コマンドへの引き数として指定変更されます。 .package ファイルは、 パッケージがどの構成ファイルを使用するか指定します。
パッケージを実行するすべてのクライアント上で、以下に示した命令を繰り返してください。
下記の命令は、パッケージ構成ファイル (プロトタイプ・ファイルがコンパイルされたときに作成された) が、 /afs/cellname/wsadmin/etc に常駐していることを前提としています。
% su root Password: root_password
# echo "/afs/cellname/wsadmin/etc/config_file" >> /.package
たとえば、クライアントをスタッフ・マシンのメンバーに構成したい場合は (適切なプロトタイプ・ファイルが、そのシステム・タイプ用に定義およびコンパイルされていることを前提として)、適当なコマンドは以下のようになります。
# echo "/afs/cellname/wsadmin/etc/staff" >> /.package
パッケージ・バイナリーをローカルに保管するには、以下のコマンドを入力します。
# cp /afs/cellname/sysname/usr/afsws/etc/package /etc/package
シンボリック・リンクを作成するには、以下のコマンドを入力します。
# ln -s /afs/cellname/sysname/usr/afsws/etc/package /etc/package
-v および -c オプションの使用を推奨します。-v フラグは詳細なトレースを作成し、 -c オプションは、構成ファイルのベース名にシステム・タイプを追加します。他のオプションの説明については、AFS Administration Reference を参照してください。
注: | shutdown コマンドが、マシンをリブートするのに適切でない場合は、類似のコマンドに置き換える必要があります。 |
if [ -f /etc/package ]; then if [ -f /.package ]: then /etc/package -v -c `cat /.package` >/dev/console else /etc/package -v >/dev/console fi case $? in 0) echo "Package completed successfully" >/dev/console 2>&1 date >/dev/console 2>&1 ;; 4) echo "Rebooting to restart system" >/dev/console 2>&1 echo >/fastboot shutdown ;; *) echo "Update failed, continuing anyway" >/dev/console 2>&1 ;; esac fi
プロトタイプ・ファイルの作成およびコンパイルと、クライアント・マシンの変更が終わったら、パッケージを実行する準備が整ったことになります。 package プログラムをマシンの AFS 初期化ファイルで呼び出して、リブート時に自動的に実行するのが最も簡単ですが、コマンド・シェル・プロンプトでもコマンドを発行できます。
構成ファイルは、完全に正しいものである必要があります。構文エラーや誤った値があると、プログラムは命令を実行せずに終了します。構成ファイルを検査するには、 package コマンドに -noaction および -debug フラグを付けてコマンド・シェル・プロンプトから発行します。これにより、実際に命令を実行せずに、潜在的な問題のリストが表示されます。
パッケージ・プログラムは、以下に示した一般規則に従います。完全な説明は、パッケージ構成ファイル命令の構文 にあります。
% su root Password: root_password
# shutdown
% su root Password: root_password
# package [initcmd] [-config <base name of configuration file>] \ [-fullconfig <full name of configuration file, or stdin for standard input>] \ [-overwrite] [-noaction] [-verbose] [-silent] [-rebootfiles]
ここで、
`cat /.package`
この引き数は、 -fullconfig 引き数とは一緒に使用できません。
別の方法としては、 stdin があります。これは、発行元が標準入力経由で、パイプ接続されたファイルとして、または構成ファイルをキーボードからタイプ入力することによって、構成情報を提供することを示しています。 <Ctrl-d> を押して、入力を完了します。
この引き数は、 -config 引き数とは一緒に使用できません。