Here’s an excerpt:

A San Francisco cable car holds 60 people. This blog was viewed about 3,400 times in 2011. If it were a cable car, it would take about 57 trips to carry that many people.

Click here to see the complete report.

desc:

Invalid Manpage

keywords: linux, manual, pages, complex

[tags]linux, manual, pages, complex[/tags]

Section: File Formats (5)
IndexReturn to Main Contents

名称

dhclient.conf – DHCP クライアント設定ファイル 

解説

dhclient.conf ファイルにはInternet Software Consortium の DHCP クライアントであるdhclientの設定情報が含まれます。

dhclient.conf は自由形式の ASCII テキストファイルです。このファイルは dhclient に組み込まれた再帰下降パーザに解析されます。ファイルには、整形の目的でタブや改行を余分に含めることもできます。ファイル中のキーワードでは大文字小文字を区別しません。(クォート内は除いて) ファイル中のどこでもコメントを置くことができます。コメントは文字 # で始まり、行末で終わります。

dhclient.conf ファイルで、クライアントのさまざまな動作を設定できます。それらには、プロトコルのタイミング、サーバに対して要求する情報、サーバに対して必須とされる情報、サーバが情報を提供しなかった場合に用いるデフォルト、サーバから提供された情報を上書きする値、サーバから提供された情報に前置や後置する値などがあります。また、DHCP サーバを持たないネットワークで使うアドレスであっても、あらかじめ設定ファイルで初期化することもできます。 

プロトコルのタイミング

クライアントのタイミング動作は、ユーザが設定する必要はありません。ユーザがタイミング設定を行わなければ、サーバに無秩序に負荷を与えたりせず適時更新を行うような、充分に適切なタイミング動作がデフォルトで用いられます。

しかし、必要に応じて、次の文を指定して DHCP クライアントのタイミング動作を調節できます:

timeout文

timeouttime;

timeout文は、クライアントがアドレスを決める試みを開始してから、サーバにアクセスすることができないと判断するまでに経過すべき時間を決めます。デフォルトではこのタイムアウト値は 60 秒です。このタイムアウト値が過ぎた後は、もし静的なリースが設定ファイルに定義されているか、リースデータベースにまだ期限切れになっていないリースが残っていれば、クライアントはそれらのリースをひとつずつ検証してみて、いずれかが有効なようであればそのリースのアドレスを使います。もし静的なリースも、リースデータベース内の期限の切れていないリースで有効なものも存在しなければ、クライアントは定義された retry 間隔の後でプロトコルを再開させます。

retry文

 retry time;

retry文は、クライアントが DHCP サーバが存在しないと判断してから再び DHCP サーバにアクセスを試みるまでの間に、経過するべき時間を決めます。デフォルトでは、これは 5 分です。

select-timeout文

 select-timeout time;

あるネットワーク上で、複数の DHCP サーバがサービスを提供することもできます(その方が望ましいという意見もあります)。その場合、最初のリース発見メッセージ (lease discovery message)への応答として、クライアントが複数のリース提供の申し出を受けることもあり得ます。それらのうち、ある提供が他の提供よりも好ましいかもしれません(例えば、クライアントが以前使用していたアドレスがある提供に含まれているが、他の提供には含まれないなど)。

select-timeoutはクライアントが最初のリース発見要求を送信して、少なくとも 1 つの提供申し出を受けた場合、サーバからの提供申し出待ちをやめるまでの時間です。もしselect-timeoutが切れるまでにどこからも提供申し出を受け取れなければ、クライアントはそのあと最初に到着する提供申し出を受け入れます。

デフォルトでは、select-timeout 値は 0 秒です。つまりクライアントは最初に受け取る提供申し出を受け入れます。

reboot文

 reboot time;

クライアントは、再起動すると、最後に保持していたアドレスをまず取得し直そうとします。これを INIT-REBOOT (初期リブート) 状態と呼びます。最後に動作していたときと同じネットワークにクライアントがまだ接続していれば、これが最も素早い起動法となります。reboot文は、クライアントが最初に古いアドレスの再取得を試みてから、あきらめて新しいアドレスを発見しようとするまでに、経過すべき時間を設定します。デフォルトでは、reboot タイムアウト値は 10 秒です。

backoff-cutoff文

 backoff-cutoff time;

クライアントは、指数的な一時退避 (backoff) アルゴリズムを、ある程度の乱数付きで使用します。これは、多くのクライアントが同時に自分を設定しようとしたときでも、リクエストがロックしてしまうことがないようにするためです。backoff-cutoff文は、一時退避に許された最大時間を決定します。デフォルト値は 2 分です。

initial-interval文

 initial-interval time;

initial-interval文は、サーバへの最初のアクセスの試みから次の試みまでの間の時間を設定します。メッセージの間隔は、メッセージを 1 回送信するたびに、現在の間隔に 0 から 1 の間の乱数値を乗じたものの 2 倍を、現在の間隔に加えたものになります。この値が backoff-cutoff 値より大きくなると、この時間が設定されます。デフォルト値は 10 秒です。 

リース要求とリクエスト

DHCP プロトコルでは、クライアントからサーバに対し、特定の情報を送るよう要求したり、受け入れ準備のできていない他の情報は送らないように要求したりできます。また、サーバからの提供申し出にクライアントの必要とする情報が含まれない場合や、提供された情報が充分でない場合、クライアントが提供申し出を拒否することもできます。

DHCP サーバが DHCP クライアントに送る提供申し出に含まれるデータには、さまざまなものがあります。特に要求できるデータは DHCP オプション と呼ばれるものです。DHCP オプションは
 dhcp-options(5)に定義されています。

request文

 request [ option ] [, ... option ];

request 文を指定することで、クライアントは、サーバに対し、そのクライアントに応答するならば、指定したオプションの値を送るよう要求するようになります。request 文にはオプション名だけを指定し、オプションパラメータは指定しません。デフォルトでは DHCP クライアントはsubnet-mask, broadcast-address, time-offset, routers,domain-name, domain-name-servers, host-nameオプションを要�
�します。

場合によっては要求リストを全く送らないことが望ましいこともあります。そうするためには、単純にパラメータを指定しない request 文を書いて下さい:

        request;

require文

 require [ option ] [, ... option ];

require 文には、ある提供申し出をクライアントが受け入れるためにサーバが送るべきオプションを列挙します。列挙されたオプションすべてを含まない提供申し出は無視されます。

send文

 send { [ option declaration ][, ... option declaration ]}

send 文を指定することで、クライアントは、指定したオプションを指定した値でサーバに送信するようになります。ここで指定できるオプションは、dhcp-options(5) で説明されているオプション宣言すべてです。DHCP プロトコルで常に送られるオプションはここに指定するべきではありません。但し、requested-lease-time オプションをデフォルトのリース時間 (2 時間)以外の値で指定することはできます。この文を使う他の場合として明らかなものは、自分と別の種類のクライアントとを区別できるような情報を、サーバに対し送信する場合です。 

動的 DNS

現在、リースが獲得された際に DNS の更新を行うための、非常に限定的なサポートがクライアントにあります。これはプロトタイプ的なものであり、おそらくあなたが思っているようには動きません。もし、あなたが偶然にも自分のところの DNS サーバの管理者であるというなら、その場合に限っては動きます。とてもありそうにないことですが。

これを動作させるためには、DHCP サーバの中で鍵とゾーンを宣言する必要があります (詳細は dhcpd.conf(5) を参照)。また、次のようにクライアントで fqdn オプションを設定する必要があります:

  send fqdn.fqdn "grosse.fugue.com.";  send fqdn.encoded on;  send fqdn.server-update off;

fqdn.fqdn オプションは 必ず 完全なドメイン名でなければなりません。更新するゾーンに対するゾーン文を 必ず 定義しなければなりません。fqdn.encoded オプションは、使用している DHCP サーバによっては、on か off に設定する必要があるかもしれません。

no-client-updates文

 no-client-updates [ flag ] ;

DHCP クライアントが直接 DNS の更新を行うよりも、DHCP クライアントスクリプト (dhclient-script(8) 参照) の中でDNS の更新を行いたい場合(例えば、DHCP クライアントが直接サポートしていないSIG(0) 認証を使用したい場合)には、no-client-updates 文を使って、更新を行わないようにクライアントに教えることができます。DHCP クライアントが更新することを望まない場合は flag を true にし、更新することを望む場合は flag を false にすることになります。デフォルトでは DHCP クライアントは DNS の更新を行います。

オプション修飾子

そのクライアントにとって実際には適切でないオプションデータを受け取ったり、必要な情報を受け取らなかったりする場合で、かつ、それらの情報に利用可能なデフォルトの値がクライアント側に存在する場合があります。また、利用可能ではあるがローカルの情報で補う必要のある情報をクライアントが受けとる場合もあります。こういう場合を扱うために、いくつかのオプション修飾子が利用できます。

default文

 default [ option declaration ] ;

あるオプションについて、サーバから提供される値をクライアントが使わなければならないが、もしサーバから値が提供されなければ何らかのデフォルト値を使う必要がある場合、それらの値をdefault文で定義することができます。

supersede文

 supersede [ option declaration ] ;

あるオプションについて、どのような値がサーバから提供されても、常にローカルで設定された値を使わなければならない場合、それらの値をsupersede文で定義することができます。

prepend文

 prepend [ option declaration ] ;

あるオプションの集合について、まずユーザが提供する値を使い、その次にサーバから提供された値があればそれを使う場合、それらの値をprepend文で定義することができます。prepend文は複数の値を取ることのできるオプションにのみ用いることができます。この制約は強制されるものではありませんが、これを無視した場合、どのような挙動になるかは予想できません。

append文

 append [ option declaration ] ;

あるオプションの集合について、まずサーバから提供された値を使い、その次にユーザが提供する値があればそれも使う場合、それらの値をappend文で定義することができます。append文は複数の値を取ることのできるオプションにのみ用いることができます。この制約は強制されるものではありませんが、もし違反すると予期できない結果となります。 

リース宣言

lease宣言

 lease { lease-declaration [ ... lease-declaration ] }

ある時間 (プロトコルのタイミング 参照) の後、DHCP クライアントはサーバへのアクセスに成功しそうにないと判断する場合があります。その時点で、クライアントは自分が持っている、古いリースのデータベースを見て、時間切れになっていないリースを順に調べ、そこに挙がっているルータに ping を行って、それが利用可能なリースかどうかを調べます。DHCP サービスや BOOTP サービスが存在しないネットワークのために、1 つ以上の 固定 リースをクライアント設定ファイルに定義しておいて、クライアントがアドレスを自動的に設定できるようにすることもできます。これはlease文で行います。

注意: lease 文は、DHCP サーバから受け取ったリースを記録するために、dhclient.leases ファイルでも使われます。以下に説明するリース用のシンタックスにはdhclient.leases ファイルでのみ必要なものもあります。説明を完全なものにするため、そのようなシンタックスもここで記述します。

lease 文は、リースキーワード、左中括弧、1 つ以上のリース宣言文、右中括弧が続いたもので構成されます。リース宣言として、次のものが可能です:

 bootp;

bootp文は、リースが DHCP プロトコルではなく、BOOTP プロトコルを用いて取得されたことを示します。この文をクライアント設定ファイルに指定する必要は全くありません。クライアントはこの構文をリースデータベースファイル内で使います。

 interface "string";

interfaceリース文は、そのリースを有効とするインタフェースを示します。これが設定されている場合、このリースは、指定されたインタフェース上でのみ使用されます。サーバからリースを受け取ったとき、クライアントは常にそのリースを受け取ったインタフェース番号を記録します。dhclient.conf ファイルで事前にリースを定義している場合、要求されてないのですが、そのリースでインタフェースもあわせて指定しなければなりません。

 fixed-address ip-address;

fixed-address文は特定のリースの IP アドレスを指定する際に使います。これはすべての lease 文に必要です。IP アドレスは (12.34.56.78 のように) ドット付き 4 つ組形式で指定しなければなりません。

 filename "string";

filename文は使用するブートファイル名を指定します。これは標準的なクライアント設定スクリプトでは使われませんが、説明の完全を期すためにここに含めてあります。

 server-name "string";

server-name文は使用するブートサーバ名を指定します。これも標準的なクライアント設定スクリプトでは使われません。

 option option-declaration;

option文は、サーバから提供されるオプションの値を指定するのに使います。あるいは、dhclient.conf で事前定義リースが宣言されている場合には、その事前定義リースが使われる際にクライアント設定スクリプトで使用して欲しい値を指定します。

 script "script-name";

script文は dhcp クライアント設定スクリプトのパス名を指定するのに使います。このスクリプトは、アドレスを要求したり、以前に提供されたアドレスを試したり、リースを取得してからインタフェースの最終設定を行ったりする前に、dhcp クライアントが各インタフェースの初期設定を行うのに使います。リースが取得できなかった場合には、事前定義リースが存在する場合、それらを試すためにこのスクリプトが使われます。また、有効なリースがひとつも得られなかった場合でも、このスクリプトは、1 回は呼び出されます。より詳しくは、dhclient-script(8)を参照してください。

 vendor option space "name";

vendor option space文は、vendor-encapsulate-options オプションを受信した場合、復号化にどのオプション空間を使用するべきかを指定するために使用されます。サーバからのベンダオプションの特定のクラスを要求するために、dhcp-vendor-identifier を使用することができます。詳細はdhcp-options(5)を参照してください。

 medium "media setup";

medium文は、接続されているネットワークのタイプをネットワークインタフェースが自動的に判断できないようなシステムで使うことができます。文字列 media setup はシステム依存のパラメータで、インタフェース初期化の際に dhcp クライアント設定スクリプトに渡されます。Unix および Unix 風のシステムでは、この引数はインタフェースを設定するときに ifconfig コマンドラインに渡されます。

リースを得るためにインタフェースを設定する際に、dhcp クライアントがメディアタイプ (media文を参照) を使用する場合、dhcp クライアントは、このパラメータを自動的に宣言します。ネットワークインタフェースがメディアタイプの設定を必要とする場合は (する場合に限り)、この文を事前定義リースで使用しなければなりません。

 renew date;

 rebind date;

 expire date;

renew 文は、現在使用中のリースを更新 (renew) するために、dhcp クライアントが使用中のリースを提供してくれたサーバへのアクセスの試みを開始しなければならない日時を定義します。rebind 文は、リースを更新するために、dhcp クライアントが いずれかの dhcpサーバへのアクセスの試みを開始しなければならない日時を定義します。expire 文は、リースの更新のためにサーバにアクセスできなかった場合、dhcp クライアントがそのリースの使用を停止しなければならない日時を定義します。

これらの宣言は、DHCP クライアントが得たリース中では自動的に設定されます。事前定義リースのうち、DHCP クライアントに有効期限が過ぎたものを使用して欲しくないものの中では、これらの宣言を設定しておく必要があります。

date は以下のように指定します。

 <weekday> <year>/<month>/<day><hour>:<minute>:<second>

weekday は、人間が見てリース期限をわかりやすくするために存在します。これは、0 から 6 までの数字で指定します。0 は日曜日です。year は世紀込みで指定します。ですから、本当に長いリースを別にすると、必ず 4 桁になるはずです。month は 1 (1 月を表します) から始まる数字で指定します。day は同様に 1 から始まる (月における) 日として指定します。hour は、0 から 23 の間の数字です。minute と second はともに 0 から 59 の間の数字を指定します。 

エイリアス宣言

 alias {  declarations … }

DHCP クライアントが TCP/IP ローミング (roaming) プロトコルを実行している場合、DHCP を用いて得られるリースだけでなく、事前に定義されたIP エイリアスも、自分が使用するインタフェースに設定する必要がある場合があります。Internet Software Consortium 版 DHCP クライアントは、固定アドレス直接指定のローミングをサポートしていませんが、その種の実験ができるように、この dhcp クライアントは、alias宣言を使って IP エイリアスを設定する準備はできています。

alias 宣言は lease 宣言に似ています。但し、標準のクライアント設定スクリプトでは、subnet-mask オプション以外のオプションと、各種有効期限 (expiry times) が無視される点が異なります。普通の alias 宣言では、 interface 宣言、IP エイリアスのための固定アドレス宣言、subnet-mask オプションを含みます。alias 宣言にはmedium 文は決して含まれてはなりません。 

その他の
宣言

 reject ip-address;

reject文により、DHCP クライアントは指定したアドレスをサーバ識別子として使用するサーバからの提供申し出を拒否するようになります。標準に準拠しない dhcpサーバや設定を間違えている dhcp サーバによってクライアントが設定されないようにするために、この文を使用することができます。しかしながら、これは最後の武器とするべきです。これに先立ち、腐った DHCP サーバを追いかけてそれを直す方がよいです。

 interface "name" { declarations …  }

複数のネットワークインタフェースを持つクライアントの場合、DHCP で設定されるインタフェースによって異なる動作をさせる必要がある場合があります。lease 宣言と alias 宣言を除くすべてのタイミングパラメータと宣言を、interface 宣言で囲むことができます。その場合、囲まれたパラメータは指定した名前に合致するインタフェースにのみ適用されます。interface 宣言を持たないインタフェースは、すべての interface 宣言の外側で宣言されたパラメータ、もしくはデフォルトの設定が適用されます。

 pseudo "name" "real-name" { declarations …  }

状況によっては仮想インタフェースを宣言し、DHCP クライアントがこのインタフェースのための設定を取得するようにすると便利になり得ます。通常 DHCP クライアントがサポートしている各インタフェースは、そのリースを獲得し管理するために、DHCP クライアントの状態機械を実行しています。仮想インタフェースは、real-name と名付けられたインタフェース上で稼働している、まさしくもう一つの状態機械です。この機能を使用する場合、仮想インタフェースと実際のインタフェースの両方に対してクライアント識別子を提供しなければなりません。また、使用したい IP アドレスに対する仮想インタフェース用に分離されたクライアントスクリプトを提供しなければなりません。例えば次のようになります:

        interface "ep0" {                send dhcp-client-identifier "my-client-ep0";        }        pseudo "secondary" "ep0" {                send dhcp-client-identifier "my-client-ep0-secondary";                script "/etc/dhclient-secondary";        }

仮想インタフェースのためのクライアントスクリプトはインタフェースを有効にしたり無効にしたりする設定をするべきではありません。特に、リースの獲得や更新の状態、そしてリースの期限切れの状態を取り扱うためには、そのことが必要です。詳細は dhclient-script(8) を参照して下さい。

 media "media setup" [ , "media setup", ... ];

media文は、IP アドレス取得中に使用が試みられる、メディア設定パラメータを 1 つ以上定義します。dhcp クライアントは、リスト中の各 media setup 文字列を順次使用し、あるインタフェースをそれで設定し、ブートを試みます。駄目ならば次の media setup 文字列を使用します。この文は、メディアタイプを検出する能力を持たないネットワークインタフェースに対して利用できます。サーバへのリクエストができ応答が得られるものならば、どのようなメディアタイプでもたぶん正当です (保証はしませんが)。

media setup はアドレス取得の初期フェーズ (DHCPDISCOVER パケットとDHCPOFFER パケット)でのみ使用されます。ひとたびアドレスが取得されると、dhcp クライアントはそのアドレスをリースデータベースに記録し、そのアドレスを得る際に用いたメディアタイプを記録します。クライアントがリースを更新しようとする際には常に、それと同じメディアタイプを使用します。リースを期限切れにしてはじめて、クライアントはメディアタイプを順に試す状態に戻ります。 

使用例

以下の設定ファイルは、NetBSD 1.3 を実行するあるラップトップマシンで使用されているものです。このマシンは、IP エイリアスとして 192.5.5.213、インタフェース ep0 (3Com 3C589C) をひとつ持っています。このクライアントは、DHCP 活動がほとんどないネットワークで時間の大部分を消費することがわかっているので、ブート間隔はデフォルト値からいくぶん小さくしてあります。このマシンは複数ネットワーク間でローミング (移動) します。

timeout 60;retry 60;reboot 10;select-timeout 5;initial-interval 2;reject 192.33.137.209;interface "ep0" {    send host-name "andare.fugue.com";    send dhcp-client-identifier 1:0:a0:24:ab:fb:9c;    send dhcp-lease-time 3600;    supersede domain-name "fugue.com rc.vix.com home.vix.com";    prepend domain-name-servers 127.0.0.1;    request subnet-mask, broadcast-address, time-offset, routers,            domain-name, domain-name-servers, host-name;    require subnet-mask, domain-name-servers;    script "CLIENTBINDIR/dhclient-script";    media "media 10baseT/UTP", "media 10base2/BNC";}alias {  interface "ep0";  fixed-address 192.5.5.213;  option subnet-mask 255.255.255.255;}

これは dhclient.conf ファイルとしては非常に複雑なものです。一般に、皆さんが使用するものははるかに簡単なはずです。多くの場合、dhclient.confファイルとして空のファイルを生成するだけで十分なはずです。つまり、デフォルト値でよいのが普通です。 

関連項目

dhcp-options(5), dhclient.leases(5), dhclient(8), RFC2132,RFC2131 

作者

dhclient(8)は Vixie Labs との契約のもとで Ted Lemon が書きました。本プロジェクトの基金は Internet Software Consortium が提供しました。Internet Software Consortium に関する情報は、http://www.isc.orgにあります。

Index

名称

解説

プロトコルのタイミング

リース要求とリクエスト

動的 DNS

オプション修飾子

リース宣言

エイリアス宣言

その他の宣言

使用例

関連項目

作者

desc:

dhclient.conf

Section: File Formats (5)
IndexReturn to Main Contents

---

 

名称

dhclient.conf – DHCP ク�
�イアント設定ファイル

keywords: linux, manual, pages, dhclient.conf

[tags]linux, manual, pages, dhclient.conf[/tags]

Section: File Formats (5)
IndexReturn to Main Contents

名前

xferlog – FTP サーバログファイル 

説明

xferlogファイルはFTP サーバデーモン、ftpd(8)からのログ情報を含んでいる。このファイルは通常 /usr/adm にあることがわかるが、ftpd(8)のオプションを使用することによりどこにでも置くことができる。各々のサーバエントリは次の形式の単一行で構成されていて、全てのフィールドはスペースによって区切られている。

current-time   transfer-time   remote-host   file-size   filename   transfer-type   special-action-flag   direction   access-mode   username   service-name   authentication-method   authenticated-user-id   completion-status

current-time

は"DDD MMM dd hh:mm:ss YYYY"形式の現在の地域時間である。DDD は週の日、MMM は月、dd は月の日、hh は時間、mm は分、ss は秒、そしてYYYY は年である。

transfer-time

は秒単位での転送の総合時間である。

remote-host

はリモートホスト名である。

file-size

はバイト単位での転送されたファイルのサイズである。

filename

は転送されたファイルの名前である。

transfer-type

には転送の種類を示す文字（一文字）を指定する。指定できるのは次のどちらかである:

a

アスキー転送

b

バイナリ転送

special-action-flag

には特殊な操作が行われたことを示す文字（一文字以上）を指定する。指定できるのは次のどれかである。一文字以上指定してもよい:

C

ファイルは圧縮された

U

ファイルは解凍された

T

ファイルは tar された

_

なにも行われていない

direction

は転送の方向である。指定できるのは次のどちらかである:

o

出て行く方向

i

入ってくる方向

access-mode

はどのユーザがログインしているかのメソッドである。指定できるのは次のうちの一つである:

a

(anonymous)は匿名なゲストユーザである。

g

(guest)はパスワード設定されたゲストユーザである(ftpaccess(5)のguestgroupコマンドを参照)。

r

(real)はローカルで認証されたユーザである。

username

はローカルユーザ名、またはゲストであるならば、ID文字列が与えられる。

service-name

は起動しているサービス名で、たいていFTP である。

authentication-method

は使用された認証のメソッドである。指定できるのは次のどちらかである:

0

なし

1

RFC931 認証

authenticated-user-id

は認証メソッドにより復帰したユーザIDである。* は認証されたユーザIDが使用不可の場合に使用される。

completion-status

には転送の状態を示す文字を指定する。指定できるのは次のどちらかである:

c

転送完了

i

転送未完了

ファイル

/usr/adm/xferlog

関連項目

ftpd(8),ftpaccess(5)

Index

名前

説明

ファイル

関連項目

desc:

XFERLOG

Section: File Formats (5)
IndexReturn to Main Contents

---

 

名前

xferlog – FTP サーバログファイル

keywords: linux, manual, pages, xferlog

[tags]linux, manual, pages, xferlog[/tags]

desc:

Invalid Manpage

keywords: linux, manual, pages, resolver

[tags]linux, manual, pages, resolver[/tags]

Section: File Formats (5)
Updated: 28 April 1993
IndexReturn to Main Contents

名前

xinetd.log – xinetd サービスのログ形式 

説明

サービスへのアクセスが試みられたときに、サービスの設定によっていろいろな程度でのログ出力を行える。そのサービスに対するログ出力が有効になっていれば、xinetdは下記の形式で 1 行のログエントリを生成する(全てのエントリには、最初にタイムスタンプがつく)。

entry: service-id data

dataはentryに依存する。entryには以下のものがある。

START

サーバが起動されたときに生成される

EXIT

サーバが終了したときに生成される

FAIL

サーバを起動できなかったときに生成される

DATA

サーバの起動に失敗し、サービスがRECORDログオプションをサポートしているときに生成される

USERID

USERIDログオプションが指定されていれば生成される

NOID

USERIDログオプションとIDONLYサービスフラグが指定されていて、かつ相手側ホストが誰がサービスにアクセスしようとしているかを識別できなかった場合に生成される

適切なログオプションを使用している場合に、角括弧の内側に現れる情報について以下に述べる。

STARTエントリでは次の形式である。

START: service-id [pid=%d] [from=%d.%d.%d.%d]

EXIT エントリでは次の形式である。

EXIT: service-id [type=%d] [pid=%d] [duration=%d(sec)]

typeはstatusとsignalのどちらかである。数値は、終了ステータスか、プロセスを終了させたシグナル番号のどちらかである。

FAILエントリは以下の形式である。

FAIL: service-id reason [from=%d.%d.%d.%d]

reasonsには以下のものがある。

fork

ある連続した回数、フォークに失敗した(回数は設定可能なパラメータである)。

time

時間チェックに失敗した

address

アドレスチェックに失敗した

service_limit

そのサービスに対する同時サービス数(instances)の制限を越えた

process_limit

フォークしたプロセス数が制限を越えた

DATAエントリは以下の形式である。

DATA: service-id data

ログ出力されるdataはサービスに依存する。

login

remote_user=%s local_user=%s tty=%s

exec

remote_user=%s verify=status command=%s
statusには以下のものがある。

ok

パスワードは正しかった

failed

パスワードが正しくなかった

baduser

そのようなユーザは存在しない

shell

remote_user=%s local_user=%s command=%s

finger

受け取った文字列または空行

USERIDは以下の形式である。

USERID: service-id text

textは相手側ホストの ident デーモンからの返事のうち、ポート番号を除いたものである(ポート番号は返事に含まれている)。

NOIDは以下の形式である。

NOID: service-id IP-address reason

関連項目

xinetd(1),xinetd.conf(5)

Index

名前

説明

関連項目

desc:

XINETD.LOG

Section: File Formats (5)
Updated: 28 April 1993
IndexReturn to Main Contents

---

 

名前

xinetd.log – xinetd サービスのログ形式

keywords: linux, manual, pages, xinetd.log

[tags]linux, manual, pages, xinetd.log[/tags]

Section: File Formats (5)
IndexReturn to Main Contents

名前

dhcpd.conf – dhcpd の設定ファイル 

説明

dhcpd.conf は、Internet Software Consortium DHCP サーバdhcpdの設定情報が書かれたファイルです。

dhcpd.conf ファイルは自由形式の ASCII テキストファイルです。dhcpd に組み込まれた再帰下降型のパーザによって解釈されます。このファイルには、整形の目的で余分なタブや改行を入れてもかまいません。このファイルでは、キーワードの大文字小文字は区別されません。コメントはファイルのどこにでも入れられます (クォートの内部を除く)。コメントは # 文字で始まり、行末で終わります。

このファイルは基本的には文 (statement) のリストからなります。文は大きく二つのカテゴリに分けられます。パラメータ文と宣言文です。

パラメータ文は、なにかをどの様に行うか (例えば提供するリースの長さ)、なにかを行うかどうか(例えば素性のわからないクライアントにもアドレスを与えるかどうか)、クライアントにどの様なパラメータを与えるか(例えばゲートウェイとして 220.177.244.7)、などを決めます。

宣言文は、ネットワークのトポロジーを記述したり、ネットワークのクライアントを記述したり、クライアントに割り当て可能なアドレスを決めたり、ひとまとまりのパラメータを宣言文のグループに与えたりするために用います。パラメータ文や宣言文のグループにおいては、ある宣言文が依存するパラメータ文は、その宣言文よりも前に指定しなければなりません。

ネットワークトポロジーに関する宣言にはshared-network 文と subnet 文があります。サブネットにあるクライアントがアドレスを動的に割り当ててもらう場合は、subnet 宣言の内部に range 宣言文も必要になります。静的にアドレスが割り当てられたクライアントや、素性のわかっているクライアントにのみアドレスを提供するような設定では、このようなクライアントに対して host 宣言文が必要です。特にサブネットに関連付けられていない宣言グループに何らかのパラメータを与えたい場合は、group 宣言文が使えます。

サービスを受けるサブネットや、dhcp サーバが接続するサブネットには、すべて subnet 宣言が必要となります。これによって dhcpd は、あるアドレスがそのサブネットにあることを認識するのです。subnet 宣言は、そのサブネットに動的割り当てを受けるアドレスがなくても必要です。

場合によっては、一つの物理的なネットワークに上で2 つ以上の IP サブネットが動作することがあります。例えば、組織のルールで 8 ビットのサブネットマスクを使っているとしましょう。このときある部門で、一つの物理イーサネットネットワークに接続するノードが 254 を越えてしまったら、新しい物理ネットワークが追加できるまでは、そのイーサネットで 8 ビットのサブネットを 2 つ走らせなければならないでしょう。このような場合には、これらの 2 つのネットワークに対する subnet 宣言は、shared-network (共有ネットワーク) 宣言で囲うことができます。

サイトによっては、ある部門のクライアントが 2 つ以上のサブネットに接続されていることもあるでしょう。このときこれらのクライアントに共通のパラメータを与え、かつ同じサブネットにいる別の部門のクライアントには違うパラメータを与えたいとしましょう。host 宣言によって明示的に宣言するクライアントでは、これらを group 宣言によって囲って、その部門に共通のパラメータを与えることができます。アドレスが動的に割り当てられるクライアントでは、今のところネットワークトポロジーによる他には、グループ単位でのパラメータ割り当てを行う方法はありません。

あるクライアントがブートする場合、そのブートパラメータを決定するには、まずそのクライアントの host 宣言が (存在すれば) 参照されます。次にその host 宣言を囲っているgroup 宣言が (存在すれば) 参照されます。その次にはブートするクライアントが所属するサブネットのsubnet 宣言が参照され、さらにそのサブネットを囲っているshared-network 宣言が (存在すれば) 参照されます。最後に、すべての宣言の外部に置かれている、トップレベルのパラメータが参照されます。

dhcpd がクライアントに対応する host 宣言を探すときには、まずそのクライアントがブートしようとしているサブネット (または共有ネットワーク)にマッチする fixed-address パラメータを含む host 宣言を探します。そのようなエントリがなければ、fixed-address パラメータが含まれないエントリを探します。そのようなエントリもなければ、たとえそのクライアントのエントリが別のサブネットや共有ネットワークにあっても、dhcpd はそのクライアントのエントリがdhcpd.conf ファイルには存在しないかのように動作します。 

例

よくある dhcpd.conf ファイルの例を示します:

global parameters...shared-network ISC-BIGGIE {  shared-network-specific parameters...  subnet 204.254.239.0 netmask 255.255.255.224 {    subnet-specific parameters...    range 204.254.239.10 204.254.239.30;  }  subnet 204.254.239.32 netmask 255.255.255.224 {    subnet-specific parameters...    range 204.254.239.42 204.254.239.62;  }}subnet 204.254.239.64 netmask 255.255.255.224 {  subnet-specific parameters...  range 204.254.239.74 204.254.239.94;}group {  group-specific parameters...  host zappo.test.isc.org {    host-specific parameters...  }  host beppo.test.isc.org {    host-specific parameters...  }  host harpo.test.isc.org {    host-specific parameters...  }}Figure 1

ファイルの先頭にはグローバルなパラメータのための場所があることにお気づきになったかと思います。ここでは組織のドメイン名、ネームサーバのアドレス(組織全体に共通のものがあれば) などを指定します。従って、例えば次のようになるでしょう。

        option domain-name "isc.org";        option domain-name-servers ns1.isc.org, ns2.isc.org;Figure 2

Figure 2 にあるとおり、パラメータに与えるホストのアドレスは、数値形式の IP アドレスではなくドメイン名で与えてもかまいません。与えられたホスト名が 1 つ以上の IP アドレスに解決される(例えばホストがイーサネットインターフェースを 2 つ持っているなど)場合には、クライアントにはすべてのアドレスが渡されます。

Figure 1 からわかるとおり、shared-network 文もsubnet 文もパラメータを取ることができます。ここで共有ネットワーク ISC-BIGGIE は部門 (例えば経理部門)全体をサポートしている
としましょう。経理部門には自前のドメインがあるとすると、shared-network 専用のパラメータとして以下を与えるべきでしょう。

        option domain-name "accounting.isc.org";

すると shared-network 宣言の内部にある subnet 宣言では、domain-name オプションは単なる "isc.org" ではなく "accounting.isc.org"になります。

Figure 1 のように subnet に固有のパラメータを与えたいのは、当然ながら、サブネットはそれぞれ違ったルータを必要とするからです。したがって最初のサブネットには、例えば以下のような文が置かれることになるでしょう。

        option routers 204.254.239.1;

ここではアドレスは数値で指定されています。これは必須ではありません。もしルータの各インターフェースが別々のドメイン名を持っているなら、そのインターフェースの指定には、数値でなくドメイン名を用いても全くかまいません。しかしながら、多くの場合ルータの IP アドレスそれぞれには一つの同じドメイン名がつけられているでしょうから、ここでその名前を用いるのは適切ではないでしょう。

Figure 1 では、group 文も使われており、3 つのホスト (zappo, beppo, harpo) に共通のパラメータをあたえています。おわかりのように、これらのホストはすべて test.isc.org ドメインに属しています。したがってこれらのホストには、グループ固有のパラメータとしてドメイン名を上書きするかたちで与えるのが良いでしょう。

        option domain-name "test.isc.org";

また、所属するドメイン名から想像できるように、これらはおそらくテスト用のマシンでしょう。DHCP 貸し出し機構をテストする場合には、貸し出しの期限をデフォルトよりは少々短くしておくのが良いでしょう。

        max-lease-time 120;        default-lease-time 120;

これまでのところで、option キーワードによって始まるパラメータと、そうでないパラメータとがあることにお気づきになったでしょうか。option キーワードで始まるパラメータは、実際の DHCP オプションに関連したものです。そうでないものは、DHCP サーバの動作を制御するもの (例えば dhcpd が提供する貸し出しの期限など) か、DHCP プロトコルでは提供されていないクライアント用のパラメータ(例えばサーバ名やファイル名) です。

Figure 1 では、各ホストは「ホスト固有のパラメータ」を持っていました。これらには例えば、hostname オプション、取得するするファイル (filename パラメータ)、ファイルを取得するホスト (next-server パラメータ)などが含まれます。一般的には、パラメータを指定できる場所にはどんなパラメータでも指定でき、そのパラメータは置かれた場所のスコープにしたがって適用されます。

NCD の X 端末がたくさんあるようなサイトを想像してください。これらの端末にはさまざまなモデルがあるので、それぞれのモデルに対して別々のブートファイルを指定したいとします。これを行う一つの方法は、各端末に host 宣言をさせ、それらをモデルごとに group 化することです。

group {  filename "Xncd19r";  next-server ncd-booter;  host ncd1 { hardware ethernet 0:c0:c3:49:2b:57; }  host ncd4 { hardware ethernet 0:c0:c3:80:fc:32; }  host ncd8 { hardware ethernet 0:c0:c3:22:46:81; }}group {  filename "Xncd19c";  next-server ncd-booter;  host ncd2 { hardware ethernet 0:c0:c3:88:2d:81; }  host ncd3 { hardware ethernet 0:c0:c3:00:14:11; }}group {  filename "XncdHMX";  next-server ncd-booter;  host ncd1 { hardware ethernet 0:c0:c3:11:90:23; }  host ncd4 { hardware ethernet 0:c0:c3:91:a7:8; }  host ncd8 { hardware ethernet 0:c0:c3:cc:a:8f; }}

リファレンス: 宣言文

shared-network文

 shared-network name {   [ parameters ]   [ declarations ] }

shared-network 文は、複数の IP サブネットが実際には一つの物理ネットワークを共有していることを DHCP サーバに伝えるために用います。共有ネットワーク内にあるサブネットは、shared-network 文の内部で宣言するようにすべきです。shared-network 文の内部で指定されたパラメータは、それらのサブネットでブートしたクライアントによって用いられます(ただしそのパラメータがサブネットやホストレベルで上書きされた場合を除く)。共有ネットワークに属するサブネットに動的割り当て可能なアドレスがあると、これらのアドレスは共有ネットワーク用の場所に共通にプールされ、必要に応じてクライアントに提供されます。あるクライアントが、(共有ネットワークに属する)どのサブネットからブートさせるべきかを識別する方法はありません。

nameには共通ネットワークの名前を指定しておきましょう。この名前はデバッグメッセージの出力時に用いられるので、その共通ネットワークの認識に役立ちます。名前にはドメイン名として有効な書式 (ただしドメイン名としては用いられない)が使えます。あるいはクォートすればどんな名前でも使えます。

subnet文

 subnet subnet-number netmask netmask {   [ parameters ]   [ declarations ] }

subnet 文は、ある IP アドレスが特定のサブネットに属しているかどうか判断するための情報をdhcpd に与えるために用います。またサブネット固有のパラメータを指定したり、そのサブネットでブートしたクライアントに動的割り当て可能なアドレスを指定するためにも利用されます。後者のようなアドレスは range 宣言で指定されます。

subnet-numberには IP アドレスか、あるいは宣言するサブネットの IP 番号に解決されるドメイン名を与えます。netmaskには IP アドレスか、あるいは宣言するサブネットのサブネットマスクに解決されるドメイン名を与えます。サブネット番号とネットマスクとを与えると、ある与えられた IP 番号がそのサブネットに属しているかどうかを判断できるようになります。

ネットマスクはすべての subnet 宣言に必要ですが、あるサイトの内部で用いているサブネットマスクに複数の種類がある場合は、subnet-mask オプション文を各 subnet 宣言の内部で用いて、適切なサブネットマスクを設定することもしておくべきです。なぜかというと、subnet-mask オプション文は、subnet 文で宣言されたサブネットマスクより優先されるからです。

range文

 range [ dynamic-bootp ] low-address [ high-address];

動的に割り当てられるアドレスを含むサブネットでは、少なくとも range 文を一つ指定しなければなりません。range 文には IP アドレスの範囲の最小値・最大値を与えます。その範囲に入る IP アドレスのすべては、range 文が宣言されたサブネットの中に入っている必要があります。指定した範囲のアドレスを DHCP クライアン
トとBOOTP クライアントの両方に割り当てて良い場合は、dynamic-bootp フラグを指定します。アドレス 1 つだけを割り当てる場合は、high-address は省略できます。

host文

 host hostname {   [ parameters ]   [ declarations ] }

サービス対象となる BOOTP クライアントには、それぞれhostが最低ひとつづつ必要になります。DHCP クライアントに対してもhost文は指定できますが、素性のわからないホストにはブートを許可しないような設定でなければ、指定しなくてもかまいません。

ある DHCP クライアントや BOOTP クライアントを、複数のサブネットにおいて固定アドレスでブートさせたい場合には、fixed-addressパラメータに複数のアドレスを指定するか、あるいはhost文を複数指定します。

クライアント固有のブートパラメータを、接続されたネットワークによって代えなければならない場合には、host文を複数用いるべきです。

可能な場合にはクライアントを固定アドレスでブートさせたいが、それができなければ動的なアドレスを割り当てたい、という場合には、host文の内部ではfixed-address文を指定しないようにします。

host 宣言を実際の DHCP クライアントやBOOTP クライアントにマッチさせる際には、host 宣言の内部で指定されたdhcp-client-identifier オプションが、クライアントが渡してきた識別子とマッチするかを確認します。もし host 宣言の内部に dhcp-client-identifier がなかったり、クライアントがこの識別子を渡してこなかった場合には、host 宣言の内部で指定されたhardware パラメータが、クライアントが渡してきたハードウェアアドレスとマッチするかを確認します。BOOTP クライアントは通常dhcp-client-identifier を渡さないので、BOOTP プロトコルでブートさせるクライアントに対しては、必ずハードウェアアドレスを用いなければなりません。

group文

 group {   [ parameters ]   [ declarations ] }

group文は、なんらかのパラメータを宣言のグループに適用するために用います。ホスト、共有ネットワーク、サブネット等をまとめたり、あるいは他のグループをまとめることもできます。 

リファレンス: ALLOW と DENY

allow文とdeny文を使うと、いろいろな要求に対する dhcpd の振る舞いを制御できます。

unknown-clientsキーワード

 allow unknown-clients;
 deny unknown-clients;

unkown-clients フラグは、素性のわからない (unkown な) クライアントに動的にアドレスを割り当てるかどうかをdhcpd に指示します。デフォルトでは unkown なクライアントへの動的アドレス割り当てはallow (許可) されています。

bootpキーワード

 allow bootp;
 deny bootp;

bootp フラグは、bootp クエリ (問い合わせ) に答えるかどうかをdhcpd に指示します。デフォルトでは bootp クエリはallow (許可) されています。

bootingキーワード

 allow booting;
 deny booting;

booting フラグは、特定のクライアントからのクエリに答えるかどうかをdhcpd に指示します。このキーワードは、host 宣言の内部に置かれた場合にのみ意味を持ちます。デフォルトでは booting はallow (許可) されています。しかしこれを特定のクライアントに対して無効にすると、そのクライアントはこの DHCP サーバからはアドレスを取得できなくなります。 

リファレンス: パラメータ

default-lease-time文

 default-lease-time time;

timeは秒単位の時間で、貸し出しを要求しているクライアントが特に期限を求めなければ、この時間が貸し出し時間になります。

max-lease-time文

 max-lease-time time;

timeは秒単位の時間で、貸し出しを要求しているクライアントが期限を求めた場合に、割り当て可能な最大の貸出時間です。

hardware文

 hardware hardware-type hardware-address;

BOOTP クライアントが認識されるためには、host文の内部でhardware指定によってそのネットワークハードウェアアドレスが指定されていなければなりません。hardware-typeは物理ハードウェアインターフェースの形式名です。現在のところはethernetとtoken-ringだけが認識されます(fddiなどのハードウェア型も認識されると良いのでしょうが)。hardware-addressは 16 進オクテット (0 から ff までの数値) のセットで、区切りはコロンです。hardware文は DHCP クライアントにも用いることができます。

filename文

 filename "filename";

filename文はクライアントにロードさせる初期ブートファイルの指定に使います。filenameはクライアントが使うであろうファイル転送プロトコルで認識されるファイル名でなければなりません。

server-name文

 server-name "name";

server-name文はクライアントに接続中のサーバの名前を伝えるために用います。nameはクライアントに渡される名前です。

next-server文

 next-server server-name;

next-server文は初期ブートファイル(filename文で指定したもの) をロードするサーバのホストアドレスを指定するために使います。server-nameは数値の IP アドレスかドメイン名です。接続してきたクライアントに対して与えるべきnext-serverパラメータがなければ、DHCP サーバの IP アドレスが用いられます。

fixed-address文

 fixed-address address [, address ... ];

fixed-address文は、あるクライアントに対して一つまたは複数のIP アドレスを割り当てるために用います。host宣言の内部でのみ用いられます。複数のアドレスが指定された場合には、そのクライアントがブートするネットワークに所属するアドレスが割り当てられます。クライアントがブートするネットワークに属するアドレスがfixed-address文にない場合は、そのクライアントはそのfixed-address文が含まれるhost宣言にマッチしないことになります。各addressは IP アドレスか、一つ (または複数) の IP アドレスに解決されるドメイン名です。

dynamic-bootp-lease-cutoff文

 dynamic-bootp-lease-cutoff date;

dynamic-bootp-lease-cutoff文は、動的に割り当てたBOOTP クライアントへのすべての貸し出しを終了させる時刻を設定します。BOOTP クライアントは貸し�
��しを更新する機構を持たず、また貸し出しがいつ期限切れになるかを知らないので、デフォルトでは dhcpd は BOOTP クライアントへは無期限の貸し出しを行います。しかし、ある場合には BOOTP の貸し出し停止に意味があるかもしれません。例えば学期の最後や、夜中のある時間になると施設が閉まって、すべてのマシンが電源停止になるような場合などです。

dateは割り当てられた BOOTP 貸し出しのすべてが終了する時刻です。date は以下の書式で指定します。

W YYYY/MM/DD HH:MM:SS

W は曜日を数値で指定したもので、0 (日曜日) から 6 (土曜日) までです。YYYY は年で、世紀の桁も指定します。MM は月を数値で指定したもので、 1 から 12 マデです。DD は月内日を数値で指定したもので、 1 から数えます。HH は時間で、0 から 23 までです。次の MM は分で、SS は秒です。時刻は常に協定世界時 (UTC) で指定します (地方時ではありません)。

dynamic-bootp-lease-length文

 dynamic-bootp-lease-length length;

dynamic-bootp-lease-length文は BOOTP クライアントへの動的割り当ての貸し出し期間の設定に用います。サイトによっては、一度アドレスを貸し出したクライアントから一定の間 BOOTP や DHCP での再割り当て要求がなければ、そのアドレスはもう使われない、とみなすことが可能かもしれません。貸出機関はlengthに秒単位で指定します。その期間のうちにクライアントが BOOTP を用いて再ブートすると、貸し出し期間もlengthにリセットされます。したがって頻繁にブートする BOOTP クライアントは、割り当てられたアドレスをずっと保持し続けます。言うまでもありませんが、このパラメータは細心の注意を払って決めてください。

get-lease-hostnames文

 get-lease-hostnames flag;

get-lease-hostnames文は、貸し出し用にプールされているIP アドレスのドメイン名を引き、そのアドレスを DHCPhostnameオプションに用いるかどうかを dhcpd に伝えるために用います。flagが真ならば、現在のスコープにあるすべてのアドレスに対してこの名前引きが実行されます。デフォルトではflagは偽で、名前引きは行われません。

use-host-decl-names文

 use-host-decl-names flag;

use-host-decl-namesパラメータがその置かれたスコープで真 (true) だと、そのスコープに置かれたすべての host 宣言において、宣言に使われた名前がホスト名としてクライアントに渡されます。したがって例えば、

    group {      use-host-decl-names on;      host joe {        hardware ethernet 08:00:2b:4c:29:32;        fixed-address joe.fugue.com;      }    }は次と全く同じになります。      host joe {        hardware ethernet 08:00:2b:4c:29:32;        fixed-address joe.fugue.com;        option host-name "joe";      }

host 宣言の内部に置かれたoption host-name文は、宣言に用いられた名前よりも優先されます。

authoritative文

 authoritative;

 not authoritative;

通常 DHCP サーバは、あるネットワークセグメントの設定情報は正しくかつ信頼できるとみなしています。よってクライアントがあるネットワークセグメントの IP アドレスを要求したとき、サーバがそれがそのセグメントでは正しくないことを知っていると、サーバは DHCPNAK メッセージを返します。するとクライアントはその IP アドレスを忘れ、新しいアドレスを取得しようとします。

DHCP サーバがネットワーク管理者ではない人間によって設定され、よってこのレベルの権威を持たせたくない場合には、設定ファイルの適切なスコープに "not authoritative"という文を入れておくと良いでしょう。

通常は、not authoritativeをファイルのトップレベルに書いておけば十分です。しかし、あるネットワークに対しては権威を持たせ、別のネットワークに対しては持たせないように DHCP サーバを設定したい場合には、ネットワークセグメント単位で authority を宣言するほうが良いでしょう。

authority が意味を持つスコープは、物理ネットワークセグメントの単位です。すなわち shared-network 文か、shared-network 文の内部にはない subnet 文です。共有ネットワークに属しているサブネットの一部のみに対してサーバに権威を持たせても意味はありません。また一部の host 宣言に対してのみサーバに権威を持たせても、同じく意味はありません。

use-lease-addr-for-default-route文

 use-lease-addr-for-default-route flag;

use-lease-addr-for-default-routeパラメータがその置かれたスコープで真だと、routers オプションで指定した値を送る (あるいは値を全く送らない)代わりに、割り当てようとしている IP アドレスをクライアントに送ります。こうすると Win95 マシンはすべての IP アドレスを ARP するようになり、使っているルータが proxy ARP に設定されている場合には役に立ちます。

use-lease-addr-for-default-route が有効になっていて、option routes 文も同じスコープにある場合には、routes オプションが優先されます。この理由は、この機能を使いたい局面では、たくさんある Windows 95 マシンすべてにはこの機能を有効にし、その他数台のマシンではこれを無効にしたくなるだろうからです。不幸にして状況が逆の場合は、このフラグは用いないほうがたぶん良いでしょう。

always-reply-rfc1048文

 always-reply-rfc1048 flag;

BOOTP クライアントの中には、受信には RFC1048 形式のものを期待するのに、送信では RFC1048 を守らないものがあります。あるクライアントがこの問題を抱えている場合には、そのクライアントは設定したオプションを取得せず、また BOOTREQUEST するたびにサーバのログに "(non-rfc1048)" というメッセージが現れます。

このようなクライアントに rfc1048 オプションを送信したい場合は、そのクライアントの host 宣言にalways-reply-rfc1048を設定します。すると DHCP サーバはRFC-1048 形式のベンダーオプションフィールドを用いて応答します。このフラグはどのスコープにも設定でき、そのスコープでカバーされるすべてのクライアントに適用されます。

server-identifier文

 server-identifier hostname;

server-identifier文は、それが置かれたスコープ内において、DHCP サーバ識別子オプションで送られる値を定義するために用います。指定する値は DHCP サーバの IP アドレスでなければならず、そのスコープにおいてサービスを受けるすべてのクライアントから到達可能でなければなりません。

server-identifier 文の使用は勧められません。唯一の利用局面は、デフォルトで送られる値が間違っている場合に、その値を別のものに変更する場合だけです�
��デフォルトの値は、要求が到達した物理ネットワークインターフェースに関連付けられた最初の IP アドレスです。

server-identifier文が必要になるのは、物理インターフェースに複数の IP アドレスがついていて、デフォルトで送られるアドレスが、サービスを受ける一部または全部のクライアントにとって適切ではない場合です。他にあり得る例としては、DHCP サーバの IP アドレスを一貫させるために IP エイリアスが定義されており、クライアントがサーバいん接続する際にはこのIP アドレスを用いるのが望ましい場合があります。

リファレンス: オプション文

DHCP オプション文はマニュアルページdhcp-options(5)で説明されています。 

関連項目

dhcpd.conf(5), dhcpd.leases(5), RFC2132, RFC2131. 

著者

dhcpd(8)は Ted Lemon <mellon@vix.com>が Vixie Labs との契約のもとに書きました。このプロジェクトの資金は、Internet Software Corporation によって提供されました。Internet Software Consortium の情報はhttp://www.isc.org/iscにあります。

Index

名前

説明

例

リファレンス: 宣言文

リファレンス: ALLOW と DENY

リファレンス: パラメータ

リファレンス: オプション文

関連項目

著者

desc:

dhcpd.conf

Section: File Formats (5)
IndexReturn to Main Contents

---

 

名前

dhcpd.conf – dhcpd の設定ファイル

keywords: linux, manual, pages, dhcpd.conf

[tags]linux, manual, pages, dhcpd.conf[/tags]

Section: Derek D. Martin (5)
Updated: 7 Jul 2003
IndexReturn to Main Contents

概要

rssh.confはrsshの設定ファイルである。これにより、システム管理者はシェルの動きを制御できるようになる。設定に使うキーワードは、それ自身で行を構成するか、またはそれに続くイコール記号(‘=’)と設定値とともに使われる。コメントはクロスハッチ(‘#’)で始まり、行の任意の場所に置くことができる。設定オプションでは大文字と小文字を区別しない。行の先頭や行の終り、イコール記号とキーワードや値との間の空白は無視される。もし設定値が空白を含むのであれば、それ(少なくともその空白)はシングルクォートまたはダブルクォートで囲まれていなければならない。デフォルトの設定ファイルは、rsshのソースとともに提供される。設定ファイルがない場合は次のデフォルト値が使われる。umask は 022 でscpのみが許可される。設定ファイルがある場合は、scp と sftp のどちらも明示的に許可されていなければ、ユーザは閉め出される。v2.1 からは、user キーワードを使ったユーザごとの設定オプションが使用できる。詳細は追って説明する。 

設定キーワード

allowscp

scp が許可されていることを示す。

allowsftp

sftp が許可されていることを示す。

allowcvs

cvs が許可されていることを示す。

allowrdist

rdist が許可されていることを示す。

allowrsync

rsync が許可されていることを示す。

umask

scp/sftp セッションで作成したファイルの umask 値を設定する。通常は、ログイン時にユーザのシェルによって設定される。システムデフォルトを使わないようにするために、rsshは umask を設定しなければならない。

logfacility

rsshがログ出力しようとする syslog の機能分類(facility)を指定する。機能分類はsyslogd.conf(5)で使われているものと同じものである。代わりに C のマクロを使って指定することもできる。たとえば、

logfacility=userlogfacility=LOG_USER

は全く同じで、rsshに機能分類 user を使って syslog へのログ出力を行わせる。

chrootpath

rssh(実際には補助プログラム)がchroot()システムコールを呼んで、指定されたディレクトリにファイルシステムのルートディレクトリを変更する。例えば、

chrootpath=/usr/chroot

は仮想的なファイルシステムのルートを /usr/chroot に変更し、ファイルシステムの /usr/chroot の下以外にユーザがアクセスできないようにし、/usr/chroot がルートディレクトリとして見えるようにする。chroot jail を適切に設定するように注意すること。どのようにしたらよいかのヒントについては、rssh ソースとともに配布されるCHROOT ファイルを見ること。またchroot(2)の man ページも参照すること。

もし(/etc/password で指定される)ユーザのホームディレクトリが、このキーワードで示されるパス以下であれば、ユーザはホームディレクトリへと chdir される。そうでなければ、chroot jail の / へと chdir される。

user

user キーワードはユーザごとのオプション設定を可能にする。このキーワードは、指定されたユーザのすべての他のキーワードを上書きする。すなわち、ユーザ foo に user キーワードを使用したなら、user 行にある設定だけがユーザ foo に使用され、今までに述べたキーワードによるすべての設定は無視される。user キーワードの引数は、コロン(‘:’)で区切られた、以下に示すフィールドのかたまりからなる。フィールドは、順番に:

username

このエントリがオプションを提供するユーザ名

umask

そのユーザーの 8 進数での umask 値で、シェルで設定するのと同じ意味である。

access bit

5個の 0/1 で、rsync, rdist, cvs, sftp, scp の順に、ユーザーがそれらを許可されるかを示す。1 はコマンドが許可され、0 は許可されないことを意味する。

path

そのユーザーが chroot されるべきパス。例えば、以下のような行になる。

user = luser:022:00001:

これは次のような意味になる。ユーザ名 "luser" について、umask を 022 に設定し、sftp を許可せず、scp を許可する。chroot パスが指定されていないので、他のキーワードでのデフォルトオプションににかかわらず、ユーザは chroot されない。このユーザーが chroot されるようにしたならば、たとえ chrootpathキーワードを使って設定したものと同じであっても、明示的に chroot パスを指定する必要がある。もし path に空白があれば、以下のようにそれを括る必要があることを思い出して欲しい。

user = "luser:022:00001:/usr/local/chroot dir"

さらなる例については、デフォルトの rssh.conf ファイルを参照のこと。

関連項目

rssh(1),sshd(8),ssh(1),scp(1),sftp(1),syslogd.conf(5),chroot(2).

Index

概要

設定キーワード

関連項目

desc:

RSSH.CONF

Section: Derek D. Martin (5)
Updated: 7 Jul 2003
IndexReturn to Main Contents

---

/etc/rssh.conf – rssh の設定ファイル 

概要

rssh.confはrsshの設定ファイルである。これにより、システム管理者はシェルの動きを制御できるようになる。設定に使うキーワードは、それ自身で行を構成するか、またはそれに続くイコール記号(‘=’)と設定値とともに使われる。コメントはクロスハッチ(‘#’)で始まり、行の任意の場所に置くことができる。設定オプションでは大文字と小文字を区別しない。行の先頭や行の終り、イコール記号とキーワードや値との間の空白は無視される。もし設定値が空白を含むのであれば、それ(少なくともその空白)はシングルクォートまたはダブルクォートで囲まれていなければならない。デフォルトの設定ファイルは、rsshのソースとともに提供される。設定ファイルがない場合は次のデフォルト値が使われる。umas
k は 022 でscpのみが許可される。設定ファイルがある場合は、scp と sftp のどちらも明示的に許可されていなければ、ユーザは閉め出される。v2.1 からは、user キーワードを使ったユーザごとの設定オプションが使用できる。詳細は追って説明する。

keywords: linux, manual, pages, rssh.conf

[tags]linux, manual, pages, rssh.conf[/tags]

Section: File Formats (5)
Updated: 26 September 2000
IndexReturn to Main Contents

名前

papd.conf – papd(8) が使う設定ファイル。Netatalk 印刷デーモンが使うプリンタを設定する

説明

/etc/netatalk/papd.conf は papd が使う設定ファイルであり、netatalk が提供する印刷サービスを設定する。これを有効にするためには、papd が /etc/netatalk/netatalk.conf で有効にされていなければならない点に注意すること。papd のデフォルトは、多くのシステムで lpd と同様である(ただし Solaris では異なる)。

# が先頭にない行が解釈される。設定ファイルの行は以下のように構成される:

printername:[options]

最も簡単なケースは、papd.conf がない場合や、このファイルの有効な行がない場合である。この場合、atalkd はマシンのローカルプリンタを自動的に検出する。 を使えば、行の途中で分割できる点に注意すること。

printername は (Printer 1) のような名前でも、nbp_name フォーマットの(Printer 1:LaserWriter@My Zone) のような完全な名前でもよい。16 台以上のプリンタを定義する場合は、各プリンタのゾーンを明示的に定義すべきである。さもないと Mac のセレクタは全てのプリンタを表示することができない。

指定可能なオプションはコロン (:) で区切られ、行はコロンで終らなければならない。指定可能なオプションとフラグを以下に示す:

am=(uam のリスト)

am は、特定のプリンタに対して UAM を指定することを可能にする。au フラグが指定されていない場合や、papd 認証が netatalk に組み込まれていない場合、何も影響を及ぼさない。

au

このフラグが存在する場合、プリンタを使うための認証が有効にされる。このフラグが有効になるためには、papd 認証が netatalk に組み込まれていなければならない点に注意すること。

op=(オペレータ)

lpd にスプールするためのオペレータ名を指定する。

pa=(appletalk アドレス)

Appletalk アドレスの指定する。通常は必要ない。

pd=(ppd ファイルのパス)

選択されたプリンタに関連した特定の PPD (プリンタ記述ファイル) を指定する。

pr=(lpd プリンタ名)

スプールする lpd プリンタを設定する。

関連項目

papd(8), atalkd.conf(5), lpd(8)

Index

名前

説明

関連項目

desc:

papd.conf

Section: File Formats (5)
Updated: 26 September 2000
IndexReturn to Main Contents

---

 

名前

papd.conf – papd(8) が使う設定ファイル。Netatalk 印刷デーモンが使うプリンタを設定する

keywords: linux, manual, pages, papd.conf

[tags]linux, manual, pages, papd.conf[/tags]

Section: File Formats (5)
IndexReturn to Main Contents

NAME

hosts_options – ホストアクセスコントロールの拡張書式 

DESCRIPTION

この文書は、hosts_access(5) で説明する文法のオプショナルな拡張について解説するものである。この拡張は、プログラムをコンパイルした際に利用の可否が決まる。例えば、Makefile を編集し、コンパイル時に PROCESS_OPTIONS を有効にした場合である。

拡張書式はこのような形式である:

   daemon_list : client_list : option : option …

最初のふたつのフィールドについては、hosts_access(5) のマニュアルで解説されている。ルールの残りの部分は、0 個以上のオプションの列である。オプションの中では、すべての ":" という文字はバックスラッシュによって保護される必要がある。

オプションは "keyword" または "keyword value" の形式をとる。オプション群は記述された順に解釈される。いくつかのオプションは %<letter> による置き換えを仮定している。初期のバージョンとの互換性のために、"=" を keyword と value(値) の間におく事も許されている。 

LOGGING (ログの記録)

severity mail.info

severity notice

イベントをログに記録する severity("激しさ") のレベルを変更する。Facility names (供される利便の項目、たとえば mail) は任意であり、古い syslog の実装ではサポートされていない。severity オプションは、指示されたイベントを強調するか、あるいは無視するために有意である。

ACCESS CONTROL (アクセスの可否)

allow

deny

サービスの可否。これらのオプションは、ルールの最後に記述しなければならない。

allow と deny は、すべてのアクセスコントロールのルールを、ただひとつのファイル、たとえばhosts.allow に納める事を可能にしている。

明示されたホストだけにアクセスを許可するには:

   ALL: .friendly.domain: ALLOW
   ALL: ALL: DENY

トラブルメイカーとなる、いくつかのホストを除いて、すべてのホストからのアクセスを許可するには:

   ALL: .bad.domain: DENY
   ALL: ALL: ALLOW

ドメイン名のパターンの最初にはドットがついている事に注目されたい。 

RUNNING OTHER COMMANDS (外部コマンドの実行)

spawn shell_command

hosts_access(5) のマニュアルで解説される %<letter> の置き換えが実行されたのちに、子プロセスで、指定のシェルコマンドを実行する。コマンドは標準入力、標準出力、そして標準エラー出力を null デバイスに繋げた状態で実行される。したがって、これによってクライアントホストとの会話が混乱するようなことはない。例えば:

   spawn (/some/where/safe_finger -l @%h


         ]]>
			http://japaneselinuxmanpages.wordpress.com/2011/07/14/5hosts_options/feed/
		0
	
		
			kalamundawebdesign