ディスクレスノード

From Gentoo Wiki
Jump to:navigation Jump to:search
This page is a translated version of the page Diskless nodes and the translation is 76% complete.

この記事では、Gentoo Linux でディスクレスノードを作成・構成する方法を提供します。

はじめに

この記事について

この記事は、Gentoo Linux ディストリビューションベースのディスクレスワークステーションを構成する手助けをします。このガイドは、プロセスを可能な限りユーザフレンドリーにして、Linux 初心者も対象読者となるように意図しています。誰でもある時点では初心者だからです。経験豊富なユーザであれば、ディスクレスノードやネットワーク設定に関する利用可能な複数の記事を容易に組み合わることができるでしょうが、ギークかどうかにかかわらず、関心のあるすべてのユーザのインストール作業が、このガイドによって緩和できるのであれば幸いです。

ディスクレスマシンとは?

ディスクレスマシンは、ハードディスク、フロッピードライブ、CD-ROM などの通常のブートデバイスを持たない PC です。ディスクレスノードはネットワークからブートするので、ローカルハードディスクの代わりとなる記憶空間を提供するサーバを必要とします。以降はこのサーバのことをマスタと呼び、ディスクレシマシンはスレーブと呼びます (名前がどうしたって言うんですか? :)。スレーブノードには、PXE ブートまたは Etherboot に対応したネットワークアダプタも必要になります。対応状況表については Etherboot.org を確認してください。現代的なカードの多くは PXE に対応しており、多くのマザーボード組み込みのアダプタもまた機能するでしょう。

始める前に

Gentoo はマスタノードにインストールされます。マスタには、ホストするスレーブノードのファイルシステムを保存するのに十分な容量があるべきです。また、ローカルエリア接続とは別に、インターネットに接続するインターフェースがあることも確認してください。

構成

マスタとスレーブ

カーネルについて

カーネルは、ハードウェアと、マシンにロードされた他のすべてのソフトウェアとの間に立つソフトウェアで、カーネルベースのオペレーティングシステムの心臓とも言えます。コンピュータを起動させると、BIOS はハードドライブ上の予約されたブートスペースにある命令を実行します。これらの命令は、典型的には、カーネルをロードするブートローダです。カーネルがロードされると、他のすべてのプロセスはカーネルによって管理されます。

カーネルとカーネルコンフィギュレーションについてのさらなる情報は、カーネルの記事を確認してください。

マスタカーネル

マスタカーネルは好きなだけ大きくカスタマイズすることができますが、選択する必要のあるオプションがいくつか存在します。次を入力して、カーネルコンフィギュレーションメニューに入ってください:

root #cd /usr/src/linux
root #make menuconfig

手動で /usr/src/linux/.config ファイルを編集する代わりとなる、安全な灰色と青の GUI が現れるはずです。現在カーネルが正しく機能しているのであれば、GUI から抜けて次を入力することで、現在のコンフィギュレーションファイルを保存しておくのは良い考えかもしれません:

root #cp .config .config_working

以下のサブメニューに入り、書かれている項目が組み込みで (モジュールとしてではなく) チェックされていることを確認してください。下に示したオプションは 2.6.10 カーネルバージョンから取られたものです。異なるバージョンを使用している場合は、テキストや並び順が異なるかもしれません。少なくとも下に示したものは忘れずに選択してください。

カーネル マスタのカーネルオプション
[*] Networking support --->
  Networking options --->
    <*> Packet socket
    <*> Unix domain sockets
    [*] TCP/IP networking
    [*]   IP: multicasting
    [ ] Network packet filtering (replaces ipchains)
  
File systems --->
  Network File Systems  --->
    <*> NFS server support
    [*]   Provide NFSv3 server support

マスタノードを介したインターネットへのアクセスが必要な場合、または安全なファイアウォールが必要な場合は、iptables の対応を追加していることを確認してください:

カーネル iptables 対応を有効化する
[*] Network packet filtering (replaces ipchains)
  IP: Netfilter Configuration  --->
    <*> Connection tracking (required for masq/NAT)
    <*> IP tables support (required for filtering/masq/NAT)

パケットフィルタリングが必要な場合は残りを後で追加してください。これを適切にセットアップする方法については、Gentoo Security Handbook のファイアウォールに関する章を読んでおいてください。

メモ
これらのカーネルコンフィギュレーションオプションは、システム固有のコンフィギュレーションオプションに加えて設定すべき部分のみであり、カーネルコンフィギュレーションを完全にこれで置き換えることを意図したものではありません。

マスタカーネルが再コンフィギュレーションされたら、再ビルドする必要があります:

root #make && make modules_install
root #cp arch/i386/boot/bzImage /boot/bzImage-master

そして、使用されているブートローダに応じて、lilo.conf または grub.conf に新しいカーネルのためのエントリを追加して、新しいカーネルをデフォルトのカーネルとしてください。新しい bzImage がブートディレクトリにコピーされたら、あとはこれらの新しいオプションをロードするためにシステムを再起動するだけです。

スレーブカーネルについて

リモートブート経由でモジュールをロードしてセットアップするのは難しく不要なプロセスなので、スレーブカーネルはモジュールを使わずにコンパイルすることをおすすめします。加えて、ネットワークからでも効率的にブートするために、スレーブカーネルはできる限り小さくコンパクトにすべきです。スレーブのカーネルはマスタのコンフィグを行ったのと同じ場所でコンパイルします。

混乱と時間の浪費を避けるため、以下を入力してマスタのコンフィギュレーションファイルをバックアップしておくのがいいでしょうː

root #cp /usr/src/linux/.config /usr/src/linux/.config_master

それでは、マスタのカーネルと同じようにして、スレーブのカーネルコンフィギュレーションを行いましょう。新しいコンフィギュレーションファイルが必要であれば、次をタイプして、デフォルトの /usr/src/linux/.config ファイルから復元することができます:

root #cd /usr/src/linux
root #cp .config_master .config

それでは、次をタイプしてコンフィギュレーション GUI に入ってください:

root #cd /usr/src/linux
root #make menuconfig

次のオプションを、カーネルモジュールとしてではなく、カーネルに組み込むものとして選択しているか確認してください:

カーネル スレーブのカーネルオプション
[*] Networking support --->
  Networking options --->
    <*> Packet socket
    <*> Unix domain sockets
    [*] TCP/IP networking
    [*]   IP: multicasting
    [*]   IP: kernel level autoconfiguration
    [*]     IP: DHCP support
  
File systems --->
  Network File Systems  --->
    <*> file system support
    [*]   Provide NFSv3 client support
    [*]   Root file system on NFS
メモ
dhcp サーバを持たせる代わりに、BOOTP サーバを構成する方法もあります。
重要
ノードのカーネルにネットワークアダプタを追加する (モジュールとしてではなく) のは重要です。しかしながら、モジュールの使用は通常はディスクレスノードでは問題にはなりません。

次に、スレーブのカーネルをコンパイルする必要があります。ここで、マスタのためにビルドしたモジュール (もしあれば) を上書きして台無しにしないように気を付けてください:

root #cd /usr/src/linux
root #make

それではマスタ上に、スレーブのファイルと必須のシステムファイルを置くために使用するディレクトリを作成してください。ここでは /diskless を使用しますが、好きな場所を選んでかまいません。では、スレーブの bzImage を /diskless ディレクトリにコピーしてください:


メモ
異なるアーキテクチャを使用する場合は、それぞれのコンフィグを.config_arch として保存しておくと便利かもしれません。イメージについても同様にしてください: /diskless 内に bzImage_arch として保存してください。


root #mkdir /diskless
root #cp /usr/src/linux/arch/i386/boot/bzImage /diskless

The preliminary slave file system

The master and slave filesystems can be tweaked and changed a lot. Right now the only point of interest is in getting a preliminary filesystem of appropriate configuration files and mount points. First it's required to create a directory within /diskless for the first slave. Each slave needs its own root file system because sharing certain system files will cause permission problems and hard crashes. These directories can be called anything the administrator deems appropriate but the article suggests using the slaves IP addresses as they are unique and not confusing. The static IP of the first slave will be, for instance, 192.168.1.21:

root #mkdir -p /diskless/192.168.1.21/etc

/etc 中の各種設定ファイルは、スレーブで動作するように修正する必要があります。次をタイプして、マスタの /etc ディレクトリを新しいスレーブルートにコピーしてください:

root #cp -r /etc/* /diskless/192.168.1.21/etc/

まだ様々なマウントポイントとディレクトリが必要ですので、このファイルシステムは準備ができていません。それらを作成するには、次をタイプしてください:

root #mkdir /diskless/192.168.1.21/home
root #mkdir /diskless/192.168.1.21/dev
root #mkdir /diskless/192.168.1.21/proc
root #mkdir /diskless/192.168.1.21/tmp
root #mkdir /diskless/192.168.1.21/mnt
root #chmod a+w /diskless/192.168.1.21/tmp
root #mkdir /diskless/192.168.1.21/mnt/.initd
root #mkdir /diskless/192.168.1.21/root
root #mkdir /diskless/192.168.1.21/sys
root #mkdir /diskless/192.168.1.21/var
root #mkdir /diskless/192.168.1.21/var/empty
root #mkdir /diskless/192.168.1.21/var/lock
root #mkdir /diskless/192.168.1.21/var/log
root #mkdir /diskless/192.168.1.21/var/run
root #mkdir /diskless/192.168.1.21/var/spool
root #mkdir /diskless/192.168.1.21/usr
root #mkdir /diskless/192.168.1.21/opt

Most of these "stubs" should be recognizable; stubs like /dev, /proc, or /sys will be populated when the slave starts, the others will be mounted later. The /diskless/192.168.1.21/etc/conf.d/hostname file should also be changed to reflect the hostname of the slave. Binaries, libraries and other files will be populated later in this HOWTO right before attempting to boot the slave.

/dev の内容は後で udev によって埋められますが、console エントリは作成しておく必要があります。これを作成しないと、"unable to open initial console" というエラーメッセージが現れるでしょう。

root #mknod /diskless/192.168.1.21/dev/console c 5 1

DHCP サーバ

DHCP サーバについて

DHCP は Dynamic Host Configuration Protocol の略です。DHCP サーバは、スレーブが PXE ブートするときに最初に通信相手となるコンピュータです。DHCP の第一の目的は、IP アドレスを割り当てることです。DHCP サーバは、ホストの ethernet MAC アドレスに基づいて IP アドレスを割り当てることができます。スレーブが IP アドレスを持つと、DHCP サーバはスレーブに初期ファイルシステムとカーネルをどこで得られるか教えるでしょう。

始める前に

始める前に、適切に機能しているか確認すべきことがいくつかあります。まずはネットワーク接続を確認してください:

root #ifconfig eth0 multicast
root #ifconfig -a

動作している eth0 デバイスが存在することを確認してください。次のように表示されるべきです:

コード 適切に動作している eth0 デバイス
eth0      Link encap:Ethernet  HWaddr 00:E0:83:16:2F:D6
          inet addr:192.168.1.1  Bcast:192.168.1.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:26460491 errors:0 dropped:0 overruns:2 frame:0
          TX packets:32903198 errors:0 dropped:0 overruns:0 carrier:1
          collisions:0 txqueuelen:100
          RX bytes:2483502568 (2368.4 Mb)  TX bytes:1411984950 (1346.5 Mb)
          Interrupt:18 Base address:0x1800

MULTICAST と表示されることが重要です。もし表示されていない場合は、マルチキャストサポートを含めてカーネルを再コンパイルする必要があるでしょう。

DHCP サーバをインストールする

ネットワーク上にまだ DHCP サーバがインストールされていない場合は、今インストールする必要があります:

root #emerge --ask dhcp

ネットワークに既に DHCP サーバがインストールされている場合は、PXE ブートが正しく機能するように、設定ファイルを編集してください。

DHCP サーバを設定する

DHCP サーバを開始する前に編集する必要のある設定ファイルは、/etc/dhcp/dhcpd.conf だけです。提供されるサンプルファイルをコピーして、編集してください:

root #cp /etc/dhcp/dhcpd.conf.sample /etc/dhcp/dhcpd.conf
root #nano -w /etc/dhcp/dhcpd.conf

このファイルの一般的なレイアウトは、インデントを整えると次のような見た目になるように構成されるでしょう:

コード dhcpd.conf レイアウト例
# ここにグローバルオプション
ddns-update-style none;
shared-network LOCAL-NET {
  # ここに共有ネットワークのオプション
  subnet 192.168.1.0 netmask 255.255.255.0 {
    # ここにサブネットのネットワークオプション
    host slave{
        # ここにホスト固有のオプション
    }
    group {
        # ここにグループ固有のオプション
    }
  }
}

The shared-network block is optional and should be used for IPs that are required to be assigned that belong to the same network topology. At least one subnet must be declared and the optional group block allows options to be grouped between items. A good example of dhcpd.conf looks like this:

コード dhcpd.conf の例
#
# ディスクレスクライアントのための dhcpd.conf の例
#
  
# 動的 DNS を無効化する
ddns-update-style none;
  
# IP トラフィックのためには 1 個のデフォルトゲートウェイで十分と仮定する
option routers 192.168.1.1;
  
# クライアントに DNS 情報を提供する
option domain-name-servers 192.168.1.1;
option domain-name "mydomain.com";
  
# 使用する TFTP サーバを指定する
next-server 192.168.1.1;
  
# PXE クライアントのためのベンダ固有オプションバッファを宣言する
# コード 1: ブートファイルサーバのマルチキャスト IP アドレス
# コード 2: クライアントが MTFTP レスポンスを監視する UDP ポート
# コード 3: MTFTP サーバが MTFTP リクエストを listen するのに使用する UDP ポート
# コード 4: クライアントが新しい MTFTP 転送を開始しようとする前に
#           待機しなくてはならない秒数
# コード 5: クライアントが MTFTP 転送を再開しようとする前に
#           待機しなくてはならない秒数
  
option space PXE;
option PXE.mtftp-ip               code 1 = ip-address;
option PXE.mtftp-cport            code 2 = unsigned integer 16;
option PXE.mtftp-sport            code 3 = unsigned integer 16;
option PXE.mtftp-tmout            code 4 = unsigned integer 8;
option PXE.mtftp-delay            code 5 = unsigned integer 8;
option PXE.discovery-control      code 6 = unsigned integer 8;
option PXE.discovery-mcast-addr   code 7 = ip-address;
  
# ディスクレスノードが属するサブネットを宣言する
subnet 192.168.1.0 netmask 255.255.255.0 {
  
  # PXE クライアントに適切な情報を提供する
  class "pxeclient" {
    match if substring(option vendor-class-identifier, 0, 9) = "PXEClient";
    vendor-option-space PXE;
  
    # クライアントのブート ROM に対して、このサーバが PXE に準拠した
    # サーバであると認識させるには、ベンダ固有 PXE オプションのうち
    # 少なくとも 1 つを設定しなくてはいけません。サーバがマルチキャスト
    # TFTP を提供できないことをブート ROM に伝えるために、MCAST IP
    # アドレスを 0.0.0.0 に設定します。
  
    option PXE.mtftp-ip 0.0.0.0;
  
    # これがブート ROM がダウンロードすべきファイルの名前です。
    filename "pxelinux.0";
  }
  
  # Etherboot クライアントに適切な情報を提供する
  class "etherboot" {
    match if substring(option vendor-class-identifier, 0, 9) = "Etherboot";
    filename "vmlinuz_arch";
  }
  
  # ディスクレスホストごとにホスト定義を 1 つ追加する
  host slave21 {
    hardware ethernet 00:02:A5:04:3B:66;
    fixed-address 192.168.1.21;
  }
}
メモ
PXE ブートと Etherboot の併用を妨げるものは何もありません。上のコードリストはただの例です; 問題がある場合は、DHCPd のドキュメンテーションを参照してください。

next-server の後の IP アドレスは、指定されたfilename を求められるでしょう。この IP アドレスは tftp サーバの IP とするべきで、これは通常はマスタの IP アドレスと同じです。filename/diskless ディレクトリからの相対パスです (これは後で説明する tftp サーバ固有のオプションのためです)。host ブロックの中で、hardware ethernet オプションは MAC アドレスを指定し、fixed-address はその特定の MAC アドレスに対して固定 IP アドレスを割り当てます。dhcpd.conf については、この HOWTO のスコープ外のオプションのことも書かれた、とてもよくできた man ページがあります。man ページは次をタイプすることで読むことができます:

user $man dhcpd.conf

DHCP サーバを開始する

dhcp 初期化スクリプトを開始する前に、次のような感じに /etc/conf.d/dhcp ファイルを編集してください:

コード /etc/conf.d/dhcp の例
IFACE="eth0"
# 必要なカスタマイズがあれば追加する

IFACE 変数は DHCP サーバが動作するデバイスで、この場合は eth0 です。複数の Ethernet カードを持つ複雑なネットワークトポロジでは、IFACE 変数にさらに引数を追加することで活用することができます。dhcp サーバを開始するには、次をタイプしてください:

root #rc-service dhcpd start

dhcp サーバをスタートアップスクリプトに追加するには、次をタイプしてください:

root #rc-update add dhcpd default

DHCP サーバをトラブルシュートする

ノードがブートできるか確認するために、/var/log/messages を見てください。ノードが正しくブートできた場合は、messages ファイルの末尾に次のような行があるはずです:

コード dhcp によって作成されたログファイルエントリの例
DHCPDISCOVER from 00:00:00:00:00:00 via eth0
DHCPOFFER on 192.168.1.21 to 00:00:00:00:00:00 via eth0
DHCPREQUEST for 192.168.1.21 from 00:00:00:00:00:00 via eth0
DHCPACK on 192.168.1.21 to 00:00:00:00:00:00 via eth0
メモ
このログファイルはスレーブの MAC アドレスを知るために役立てることもできます。

次のメッセージに遭遇した場合はおそらく、設定ファイルにおかしな点があるものの、DHCP サーバは正しくブロードキャストできているということでしょう。

コード dhpc サーバのエラーの例
no free leases on subnet LOCAL-NET

設定ファイルを変更した後は毎回、DHCP サーバを再起動する必要があります。サーバを再起動するには、次をタイプしてください:

root #rc-service dhcpd restart

TFTP server and PXE Linux Bootloader and/or Etherboot

TFTP サーバについて

TFTP は Trivial File Transfer Protocol の略です。TFTP サーバはスレーブにカーネルと初期ファイルシステムを供給します。スレーブカーネルとファイルシステムはすべて TFTP サーバ上に保存されることになるので、おそらくマスタを TFTP サーバにするのが良い考えでしょう。

TFTP サーバをインストールする

とてもおすすめの tftp サーバが tftp-hpa パッケージとして利用可能です。この tftp サーバは SYSLINUX の作者によって書かれており、pxelinux とはとても相性良く機能します。インストールするには、単に次をタイプしてください:

root #emerge --ask tftp-hpa

TFTP サーバを設定する

/etc/conf.d/in.tftpd を編集してください。tftproot ディレクトリを INTFTPD_PATH で、コマンドラインオプションを INTFTPD_OPTS で指定する必要があります。次のようになるべきです:

ファイル /etc/conf.d/in.tftpd
INTFTPD_PATH="/diskless"
INTFTPD_OPTS="-l -v -s ${INTFTPD_PATH}"

-l オプションは、このサーバがスタンドアローンモードモードで listen し、inted を実行する必要がないことを指定します。-v はログ/エラーメッセージを詳細にすべきことを指定します。-s /diskless は tftp サーバのルートを指定します。

TFTP サーバを開始する

tftp サーバを開始するには次をタイプしてください:

root #rc-service in.tftpd start

これにより、/etc/conf.d/in.tftpd 内で指定されたオプション付きで tftp サーバが開始されるはずです。このサーバをブート時に自動で開始したい場合は、次をタイプしてください:

root #rc-update add in.tftpd default

PXELINUX について

この節は、Etherboot のみを使用する場合には必要ありません。PXELINUX は、LILO や GRUB に相当するネットワークブートローダで、TFTP を介して提供されることになります。これは基本的にはごく小さな命令の集合で、クライアントに対してどこにカーネルと初期ファイルシステムを配置すべきかを伝え、様々なカーネルオプションを設定できるようにします。

始める前に

pxelinux.0 ファイルが必要になりますが、これは H. Peter Anvin による SYSLINUX パッケージに含まれています。このパッケージは次をタイプすることでインストールできます:

root #emerge --ask syslinux

PXELINUX をセットアップする

メモ
これは Etherboot では必要ありません。

tftp サーバを開始する前に、pxelinux をセットアップする必要があります。まずは pxelinux バイナリを /diskless ディレクトリの中にコピーしてください:

root #cp /usr/share/syslinux/pxelinux.0 /diskless
root #mkdir /diskless/pxelinux.cfg
root #touch /diskless/pxelinux.cfg/default

これでデフォルトのブートローダ設定ファイルができるでしょう。pxelinux.0 バイナリは、pxelinux.cfg ディレクトリ内で、ファイル名が 16 進法でのクライアントの IP アドレスと一致するファイルを探索します。そのファイルが見つからなければ、ファイル名から最も右の桁を削除し、すべての桁がなくなるまで繰り返し試します。バージョン 2.05 以降の syslinux は、最初に MAC アドレスをもとに命名されたファイルを検索します。ファイルが見つからなかった場合は、先述の探索ルーチンを開始します。何も見つからなかった場合は、default ファイルが使用されます。

コード PXE が pxelinux.cfg/ 中のファイルを探索する順序
## (先頭の 01 は Ethernet を意味し、以降のバイト列はスレーブの MAC アドレスにマッチします)
01-00-40-63-c2-ca-c9
  
## (16 進法での、割り当てられた IP)
C0A80115
C0A8011
C0A801
C0A80
C0A8
C0A
C0
C
  
default
メモ
These are all in lowercase.

default から始めましょう:

コード pxelinux.cfg/default の例
DEFAULT gentoo
LABEL gentoo
LINUX /bzImage
APPEND ip=dhcp root=/dev/nfs nfsroot=192.168.1.1:/diskless/192.168.1.21

The DEFAULT tag directs pxelinux to the kernel bzImage that was compiled earlier. The APPEND tag appends kernel initialisation options. Since the slave kernel was compiled with NFS_ROOT_SUPPORT , the nfsroot will be specified here. The first IP is the master's IP and the second IP is the directory that was created in /diskless to store the slave's initial filesystem. Other NFS options may also be supplied. For example, to use NFS v4.1 over TCP, append ,tcp,vers=4.1 to the nfsroot kernel option: nfsroot=192.168.1.1:/diskless/192.168.1.21,tcp,vers=4.1.

Etherboot について

メモ
PXE ブートを使用する場合は、これは必要ありません。

Etherboot boots network boot images from a TFTP server. As the PXE this is equivalent to LILO or GRUB. The mknbi utility enables the creation of different images using different options.

始める前に

The mknbi (utility for making tagged kernel images useful for netbooting) package is needed to create the Etherboot images. This tool will create a preconfigured kernel image from the original kernel. This contains the boot options as shown further down.

root #emerge --ask mknbi

Etherboot をセットアップする

In this section a simple etherboot image will be created. As the dhcp server gives out the clients root-path in the "option root-path" dhcp.conf, this does not have to be included here. More details can be found in the mknbi manual.

user $man mknbi

Making the boot images. This will create a ELF bootable image capable of passing dhcp and the rootpath to the kernel. Also forcing the kernel to browse the network for a dhcp server.

root #mkelf-linux -ip=dhcp /diskless/bzImage > /diskless/vmlinuz
メモ
For the arch specific images bzImage_arch and vmlinuz_arch have to be typed.

ネットワークブートプロセスをトラブルシュートする

There are a few things that can be done to debug the network boot process. Primarily a tool called tcpdump can be used. To install tcpdump type:

root #emerge --ask tcpdump

Now various network traffic can be listened to, to make sure the client/server interactions are functioning. If something isn't working there are a few things that could be checked. First make sure that the client/server is physically connected properly and that the networking cables are not damaged. If the client/server is not receiving requests on a particular port make sure that there is no firewall interference. To listen to interaction between two computers type:

root #tcpdump host client_ip and server_ip

The tcpdump command can also be configured to listen on particular port such as the tftp port by typing:

root #tcpdump port 69

A common error that might be received is: "PXE-E32: TFTP open time-out". This is probably due to firewall issues. If TCPwrappers is being used, it might be worth checking /etc/hosts.allow and /etc/hosts.deny and make sure that they are configured properly. The client should be allowed to connect to the server.

NFS サーバ

NFS サーバについて

NFS stands for Network File System. The NFS server will be used to serve directories to the slave. This part can be somewhat personalized later, but right now all that is wanted is a preliminary slave node to boot diskless.

Portmapper について

Various client/server services do not listen on a particular port, but instead rely on RPCs (Remote Procedure Calls). When the service is initialised it listens on a random port and then registers this port with the Portmapper utility. NFS relies on RPCs and thus requires Portmapper to be running before it is started.

始める前に

The NFS Server needs kernel level support so if the kernel does not have this, the master's kernel needs to be recompiled. To double check the master's kernel configuration type:

root #grep NFS /usr/src/linux/.config_master

The output should look something like this if the kernel has been properly configured:

カーネル Proper NFS specific options in the master's kernel configuration
CONFIG_PACKET=y
# CONFIG_PACKET_MMAP is not set
# CONFIG_NETFILTER is not set
CONFIG_NFS_FS=y
CONFIG_NFS_V3=y
# CONFIG_NFS_V4 is not set
# CONFIG_NFS_DIRECTIO is not set
CONFIG_NFSD=y
CONFIG_NFSD_V3=y
# CONFIG_NFSD_V4 is not set
# CONFIG_NFSD_TCP is not set

NFS サーバをインストールする

The NFS package that can be acquired through portage by typing:

root #emerge --ask nfs-utils

This package will emerge a portmapping utility, nfs server, and nfs client utilities and will automatically handle initialisation dependencies.

NFS サーバを設定する

There are three major configuration files that will have to be edited:

コード Nfs configuration files
/etc/exports
/diskless/192.168.1.21/etc/fstab
/etc/conf.d/nfs

The /etc/exports file specifies how, to who and what to export through NFS. The slave's fstab will be altered so that it can mount the NFS filesystems that the master is exporting.

A typical /etc/exports for the master should look something like this:

ファイル /etc/exportsmaster exports file
# one line like this for each slave
/diskless/192.168.1.21   192.168.1.21(sync,rw,no_root_squash,no_all_squash)
# common to all slaves
/opt   192.168.1.0/24(sync,ro,no_root_squash,no_all_squash)
/usr   192.168.1.0/24(sync,ro,no_root_squash,no_all_squash)
/home  192.168.1.0/24(sync,rw,no_root_squash,no_all_squash)
# if you want to have a shared log
/var/log   192.168.1.21(sync,rw,no_root_squash,no_all_squash)

The first field indicates the directory to be exported and the next field indicates to who and how. This field can be divided in two parts: who should be allowed to mount that particular directory, and what the mounting client can do to the filesystem: ro for read only, rw for read/write; no_root_squash and no_all_squash are important for diskless clients that are writing to the disk, so that they don't get "squashed" when making I/O requests. The slave's fstab file, /diskless/192.168.1.21/etc/fstab , should look like this:

コード Sample slave fstab
# these entries are essential
master:/diskless/192.168.1.21   /         nfs     sync,hard,intr,rw,nolock,rsize=8192,wsize=8192    0 0
master:/opt                     /opt      nfs     sync,hard,intr,ro,nolock,rsize=8192,wsize=8192    0 0
master:/usr                     /usr      nfs     sync,hard,intr,ro,nolock,rsize=8192,wsize=8192    0 0
master:/home                    /home     nfs     sync,hard,intr,rw,nolock,rsize=8192,wsize=8192    0 0
none                            /proc     proc    defaults                                     0 0
# useful but superfluous
master:/var/log                 /var/log  nfs     hard,intr,rw                                 0 0

In this example, master is just the hostname of the master but it could easily be the IP of the master. The first field indicates the directory to be mounted and the second field indicates where. The third field describes the filesystem and should be NFS for any NFS mounted directory. The fourth field indicates various options that will be used in the mounting process (see mount(1) for info on mount options). Some people have had difficulties with soft mount points so here they are made hard mounts, a look into various /etc/fstab options should be done to make the cluster more efficient.

The last file that should be edited is /etc/conf.d/nfs which describes a few options for nfs when it is initialised and looks like this:

コード Sample master /etc/conf.d/nfs
# Config file for /etc/init.d/nfs
  
# Number of servers to be started up by default
RPCNFSDCOUNT=8
  
# Options to pass to rpc.mountd
RPCMOUNTDOPTS=""

The RPCNFSDCOUNT should be changed to the number of diskless nodes on the network.

NFS サーバを開始する

The nfs server should be started with its init script located in /etc/init.d by typing:

root #rc-service nfs start

If this script is to be started every time the system boots simply type:

root #rc-update add nfs default

Completing the slave filesystem

足りないファイルをコピーする

Now the slave's file system will be made in sync with the master's and provide the necessary binaries while still preserving slave specific files.

root #rsync -avz /bin /diskless/192.168.1.21
root #rsync -avz /sbin /diskless/192.168.1.21
root #rsync -avz /lib /diskless/192.168.1.21
メモ
cp ではなく rsync -avz を使用している理由は、シンボリックリンクとパーミッションを保つためです。

Configure diskless networking

In order to prevent the networking initscript from killing the connection to the NFS server, an option needs to be added to /etc/conf.d/net on the diskless client's filesystem.

コード Editing /etc/conf.d/net
config_eth0="noop"
メモ
For more information, please read /usr/share/doc/openrc-*/net.example.bz2 .

初期化スクリプト

Init scripts for slaves are located under /diskless/192.168.1.21/etc/runlevels for services needed on the diskless nodes. Each slave can be set up and customized here, it all depends on what each slave is meant to do.

警告
Do not use the rc-update program to add or remove scripts from the slave runlevels when logged on to the master. This would change the master runlevels. The links need to be manually created or by logging into the slave nodes using ssh or connecting a screen and keyboard to the slave.
コード Typical slave runlevels
/diskless/192.168.1.21/etc/runlevels/:
total 16
drwxr-xr-x    2 root     root         4096 2003-11-09 15:27 boot
drwxr-xr-x    2 root     root         4096 2003-10-01 21:10 default
drwxr-xr-x    2 root     root         4096 2003-03-13 19:05 nonetwork
drwxr-xr-x    2 root     root         4096 2003-02-23 12:26 single
  
/diskless/192.168.1.21/etc/runlevels/boot:
total 0
lrwxrwxrwx    1 root     root           20 2003-10-18 17:28 bootmisc -> /etc/init.d/bootmisc
lrwxrwxrwx    1 root     root           19 2003-10-18 17:28 checkfs -> /etc/init.d/checkfs
lrwxrwxrwx    1 root     root           17 2003-10-18 17:28 clock -> /etc/init.d/clock
lrwxrwxrwx    1 root     root           22 2003-10-18 17:28 domainname -> /etc/init.d/domainname
lrwxrwxrwx    1 root     root           20 2003-10-18 17:28 hostname -> /etc/init.d/hostname
lrwxrwxrwx    1 root     root           22 2003-10-18 17:28 localmount -> /etc/init.d/localmount
lrwxrwxrwx    1 root     root           19 2003-10-18 17:28 modules -> /etc/init.d/modules
lrwxrwxrwx    1 root     root           18 2003-10-18 17:28 net.lo -> /etc/init.d/net.lo
lrwxrwxrwx    1 root     root           20 2003-10-18 17:28 netmount -> /etc/init.d/netmount
lrwxrwxrwx    1 root     root           21 2003-10-18 17:28 rmnologin -> /etc/init.d/rmnologin
lrwxrwxrwx    1 root     root           19 2003-10-18 17:28 urandom -> /etc/init.d/urandom
  
/diskless/192.168.1.21/etc/runlevels/default:
total 0
lrwxrwxrwx    1 root     root           23 2003-10-18 17:28 consolefont -> /etc/init.d/consolefont
lrwxrwxrwx    1 root     root           19 2003-10-18 17:28 distccd -> /etc/init.d/distccd
lrwxrwxrwx    1 root     root           19 2003-10-18 17:28 keymaps -> /etc/init.d/keymaps
lrwxrwxrwx    1 root     root           17 2003-10-18 17:28 local -> /etc/init.d/local
lrwxrwxrwx    1 root     root           16 2003-10-18 17:28 sshd -> /etc/init.d/sshd
lrwxrwxrwx    1 root     root           21 2003-10-18 17:28 syslog-ng -> /etc/init.d/syslog-ng
lrwxrwxrwx    1 root     root           17 2003-10-18 17:28 vixie-cron -> /etc/init.d/vixie-cron
  
/diskless/192.168.1.21/etc/runlevels/nonetwork:
total 0
lrwxrwxrwx    1 root     root           17 2003-10-18 17:28 local -> /etc/init.d/local
  
/diskless/192.168.1.21/etc/runlevels/single:
total 0

Now is a good time to boot the slave and cross some fingers. It works? Congratulations, you are now the proud owner of (a) diskless node(s).


This page is based on a document formerly found on our main website gentoo.org.
The following people contributed to the original document: Michael Andrews, Kristian Jerpetjoen, Xavier Neys
They are listed here because wiki history does not allow for any external attribution. If you edit the wiki article, please do not add yourself here; your contributions are recorded on each article's associated history page.