オープン・ソース・ソリューションを実装する方法：ファイル・サービス
IBM i でオープン・ソース・ソリューションを実装する方法の第 2 弾では、オープン・ソース・ファイル・サービスの機能だけでなく、ファイル・サービスのさまざまな面を設定する手順をお話します。手始めに、SAMBA ファイル・サーバーについて重点的に説明します。これは、実質的にすべての Linux ディストリビューションに付属するオープン・ソース・ファイル・サーバーであるためです。(このシリーズの第 1 弾は「オープン・ソース・ソリューションを実装する方法: Linux の基盤を構築する」をご覧ください。）
SAMBA の概要
SAMBA はオープン・ソース・ファイル・サーバーで、Microsoft Networking とクライアント互換性があります。これはServer Message Block (SMB) プロトコルの UNIX インプリメンテーションです。SAMBA の特長として、無償、一般的に使用されている、GNU Public License でライセンスされている、構成可能度が高い、常に機能拡張されている、成熟したサーバー、ベンダーに依存しない、ということが挙げられます。他のファイル転送や共有プロトコルと異なり、SMB プロトコルは、クライアントがサーバーからファイルを要求する方法を定義し、サポートされているファイル共有機能がクライアントでサポートされている機能に限定されているという点で、クライアント駆動型と言えます。SAMBA の現行バージョンはバージョン 3 で、ドメイン・コントローラーのサポートとアクティブ・ディレクトリーとの統合を可能にする NT レベル・ダイアレクトを実装しています。ドメイン・コントローラーとアクティブ・ディレクトリーについては後で詳しくお話します。
SAMBA の基本機能として、ファイルおよびプリンターの共有、時間同期のサポート、システム管理者によるリモート・パスワードの管理などがあります。さらに、SAMBA は NetBios ネーム・サーバーを組み込み、隣接ネットワークなどのブラウズ活動をサポートしています。
SAMBA の構成
SAMBA サーバーの基本的な構成を見てみましょう。この記事では、SAMBA サーバーの構成設定自体だけではなく、WebMin システム管理ツールを利用して構成設定を行う手順についてもお話します。SAMBA をデフォルト・インストールすると構成ファイルは /etc/samba ディレクトリーに格納され、構成ファイル名は smbd.conf になります。SAMBA には次のようなコンポーネントが含まれています。
- smbd daemon:
ファイル・サービスと印刷サービスを Windows または他の Linux クライアントや UNIX クライアントなどの SAMBA クライアントへ提供する永続的プロセス - nmbd daemon:
NetBIOS ネーム・サービスおよびブラウズ・サポートを提供する永続的プロセス - smbclient:
FTP のようなシンプルなクライアントを Linux または UNIX システムに実装し、SMB プロトコルをサポートするファイル・サービスから共有にアクセスするユーティリティー・プログラム - smbmount:
サーバー・ディレクトリーを Linux システムまたは UNIX システムにマウントできるユーティリティー・プログラム
SAMBA の構成ファイルは多数のセクションに分割され、各セクションは括弧に囲まれたキーワードで指定されています。予約済みキーワードがいくつかあり、他のキーワードは共有の名前に使用されます。次のような予約済みキーワードがあります。
- [global]
ワークグループの名前、実施中のセキュリティーのレベルなどファイル・サーバーの全体的な情報を指定します。Global セクションに含まれるパラメーターは、共有定義内でオーバーライドされない限り、すべての共有定義に適用されます。 - [homes]
すべてのユーザーのホーム・ディレクトリーを共有する場合に使用され、あるユーザーによるホーム・ディレクトリーの参照をそのユーザーのホーム・ディレクトリーのみに制限します。 - [printers]
プリンター・リソースの共有専用の共有パラメーターを指定する場合に使用します。 - [print$]
プリンター・ドライバーを格納する共有を定義する場合に使用します。この共有を使用して、印刷ドライバーをクライアントへ自動的にダウンロードします。
グローバル構成
SAMBA 構成ファイルの Global セクションでは、ファイル・サーバー全体に適用されるすべての情報、つまりファイル・サーバーのグローバル的な意味を持つパラメーターが定義されます。また Global セクションには、他のセクションおよび共有のデフォルト設定を含めることができます。特定の共有定義において、設定はオーバーライドできる点を覚えておいてください。
Linux ディストリビューターが提供した構成ツール SWAT (SAMBA Web Administration Tool)、コマンド・ライン、WebMinなど、SAMBA を構成する多数のツールがあります。このシリーズの導入編の記事で説明したように、WebMin 画面と、適宜、構成ファイル中の結果エントリーを示します。ファイル・サーバーの構成用 WebMin インターフェースは、実質的に SAMBA 構成ファイルのセクションに一致する多数の領域に分割されています。Global Configuration 設定でサポートされる構成項目については、図 1 を参照してください。
Global セクションでおそらく最も興味深い構成設定は、図 2 に示すように Windows Networking での設定でしょう。これらの設定は、ファイル・サーバーがサポートする可能性が高い環境である、Windows クライアント環境に直接反映されるためです。構成ファイル中の結果エントリーを次に示します。
[global]
include = /etc/samba/dhcp.conf
logon drive = P:
map to guest = Bad User
logon home = \\%L\%U\.9xprofile
printcap cache time = 750
cups options = raw
netbios name = SMB_FS
printing = cups
server string = Test SAMBA FIle Server
logon path = \\%L\profiles\.msprofile
workgroup = WORKGROUP
os level = 20
printcap name = cups
usershare allow guests = Yes
preferred master = no
ファイル共有
ファイル・リソースは、 SAMBA 経由でディレクトリー・レベルで共有されます。ファイル共有は、共有名を括弧で囲んだ SAMBA 構成ファイルで表されます。ファイル共有のゲスト・サポートがサポートされています。ファイル共有は、利用できるものの参照 (Windows 隣接ネットワーク) リストに組み込まれない形で非表示にできます。WebMin 経由でファイル共有を定義するには、いくつか方法があります。1 つには図 3 に示すように、「Samba Windows File Sharing」画面から「Create a new file share」オプションを使用する方法があります。
もう 1 つは、図 4 に示すように、 WEBMIN の 'File Manager' 部分の 'Share' オプションを使用する方法です。
いずれも、結果的にファイル共有セクションが smb.conf ファイルに追加されています。
[Media Share]
comment = Share of media directory
path = /media
guest only = no
writable = yes
browseable = yes
ここでは、ディレクトリー /media (path = /media) をポイントする 'Media Share' という共有が定義され、ゲスト・ユーザー (guest only = no) だけでなく両方の既知のユーザーが利用できます。ファイル・システムに書き込み権限があるユーザーは、この共有に書き込むことができ (writable = yes)、共有名は参照リストに表示されます (browseable = yes)。'browseable = yes' などのデフォルト設定は、デフォルト設定であるために実際は共有定義で指定できない点に注目する必要があります。
ユーザーのホーム・ディレクトリーを共有する
ユーザーのホーム・ディレクトリーを Linux サーバーに保存しようとする場合、ユーザーが SAMBA サーバーに接続したとき、図 5 に示すように、その共有が共有リストで利用できるようになるよう、ホーム・ディレクトリーを簡単に共有する方法があります。構成ファイルの結果エントリーは次のようになります。
[homes]
comment = Home Directories
valid users = %S, %D%w%S
browseable = No
read only = No
inherit acls = Yes
この共有にパス・ステートメントが含まれていない点に注目してください。パスは、ユーザーのホーム・ディレクトリー (¥¥servername¥username) をマップまたはそれにアクセスしようとしたとき、クライアントにより提供され、送信されたユーザー名のホーム・ディレクトリーに自動的にセットされます。また、'valid users' ステートメントには中に多数の変数が存在する点に注目してください。%S は現在の共有名を示します。その通り、ユーザー名になります。%D%w%S の組み合わせにより、ドメイン名の入ったユーザー名が構築されます。そのため、valid users パラメーターによりユーザーは、ホーム・ディレクトリーの所有者に制限されます。共有は 'browseable=no' エントリーで示すように、参照リストでは表示されません。共有は 'read only = no' で示すように、アップデートを許可します。最後に、共有中のファイルは親ディレクトリーからアクセス制御リスト情報を継承します。NFS など、ユーザー ID 番号に依存する他のファイル・サービス・プロトコルと異なり、SMB プロトコルはクライアントとサーバー間でユーザー名を渡します。示したとおり、SAMBA サーバーはこれにより現行ユーザーのホーム・ディレクトリーのみ共有できます。例として、ユーザー 'george' がファイル・サーバーに接続し、'homes' 共有をマップする場合、サーバーの '/home/george' ディレクトリーをポイントすることになります。そのユーザーのみ共有にアクセスできるようになります。
ユーザー認証を統合する
SAMBA のデフォルト構成はローカル・ユーザー認証を使用することです。つまり、SAMBA ファイル・サーバーをホストしている Linux サーバー上で動作する認証ということです。SAMBA を NT 型のドメイン・コントローラーやアクティブ・ディレクトリー・サーバーなどの外部認証メカニズムと統合したり、他のサーバーが使用できる認証メカニズムを SAMBA に実装することさえ可能です。認証サーバーとの具体的な統合方法を検討する前に、ユーザー資格情報がどのように認証されるのか理解することが重要です。認証は次のように動作します。
- ユーザーがファイル共有を要求すると、データの中でもユーザー名と暗号化されたパスワードがファイル・サーバーに送信されます。覚えておくことが 2 つあり、まず、これは他のプロトコルの場合のように、折衝パケットで送信されているユーザー ID ではなくユーザー名ということ、そしてパスワードは Windows などのクライアントにより暗号化されて送信されているということです。
- ファイル・サーバーがリモート認証向けに構成されている場合、ユーザー名と暗号化パスワードを含む認証要求がそのサーバーに送信されます。
- リモート認証サーバーで、ユーザー名とパスワードが認証され、対応するユーザー ID とグループ ID はファイル・サーバーに戻されます。
- ファイル・サーバーは受信したユーザー ID とグループ ID を、ローカル・ユーザー ID とグループ ID にマップします。
- ファイル共有権限は、提供されたユーザー ID およびグループ ID による許可にしたがって与えられます。
ドメイン・コントローラー環境への統合
ドメイン・コントローラー (DC) 環境は、1 次ドメイン・コントローラー (PDC) と 1 つまたは複数のバックアップ・ドメイン・コントローラー (BDC) を構成し、認証サービスを行っている環境です。通常これらは NT 型のサーバーです。ドメイン・コントローラーと統合して認証するためには、多数の手順を行う必要があります。
認証順を指定する
Linux サーバーでは、複数の認証メカニズムを指定でき、どの順番でこれらのメカニズムを使用するか指定できます。その順番は 'passwd' および 'group' エントリーを通して Name Server Switch 構成ファイル (/etc/nsswitch.conf) に定義されています。
passwd: files winbind
group: files winbind
ここでは、順番が問題になります。上記の例では、passwd (user) 認証については、ローカル・ファイル (/etc/passwd など) を最初にチェックし、ローカルでユーザーが見つからない場合は、SAMBA で提供されている winbind メカニズムを使用することを言おうとしています。同様に、group 認証も同じ順序で行われます。すぐにわかると思いますが、winbind は NT サーバーに対して認証するよう構成されます。
いったん Name Server Switch ファイルが変更されると、その変更内容を次のコマンドで有効にする必要があります。
/sbin/ldconfig
SAMBA File Server の [global] 構成は、Domain セキュリティーを反映させ、マッピングのために一連のユーザー ID とグループ ID の位置を入れ替えるため変更する必要があります。WebMin の SAMBA 構成セクションの Winbind オプションを使用して、一連の UID および GID を設定でき、図 6 に示すように 前述の Windows Network Settings の 'Security' ドロップダウンを使用して、ドメイン・セキュリティーを指定できます。構成ファイルのエントリーを次に示します。
idmap uid = 10000-20000
idmap gid = 10000-20000
security = domain
workgroup = WORKGROUP
2 つの idmap エントリーは、認証サーバーで提供されたユーザー ID およびグループ ID のマッピングに使用するユーザー ID およびグループ ID を予約、つまり指定します。認証サーバーからユーザーに対して提供されたユーザー ID およびグループ IDが、ローカル・サーバーで利用できるようになる保証はないことを覚えておいてください。つまり、それらの ID をローカル ID にマップできるようになる必要があります。'security = domain' は認証はドメイン・サーバーから行われていることを示し、最終的に 'workgroup = WORKGROUP' エントリーは、ドメイン名が WORKGROUP であることを示します。
いったん変更が行われると、SAMBA サーバーと認証サーバー間で「信頼」関係を築く必要があります。これは図 7 に示すように WebMin (Bind to Domain ツールにより) または Linux コマンド・ラインから行うことができます。
smbpasswd -J WORKGROUP -U Administrator
上記のコマンドは、WORKGROUP ドメインに参加するための要求が行われているところを示します。要求は Administrator アカウントで行われています。コマンドが実行されると、Administrator のパスワードを指定する必要があります。コマンドで指定したユーザーは、ドメイン・コントローラーで定義された有効なドメイン管理者でなければなりません。
それだけです。この時点で SAMBA ファイル・サーバーは企業の認証サーバーに対してユーザーを認証できます。これが実際に動作しているか確認テストをする方法がいくつかあります。
wbinfo -u
wbinfo -g
上記の 2 つのコマンドは、認証サーバーからユーザーおよびグループを表示します。
getent passwd
getent group
上記の 2 つのコマンドは、/etc/nsswitch ファイルで定義された各認証メカニズムから、指定の順序でユーザーおよびグループの情報を表示します。したがって、例ではローカル・ユーザーおよびローカル・グループが表示され、続いてドメイン・コントローラーのユーザーおよびグループが表示されます。'getent' コマンドには、認証サーバーのユーザー ID およびグループ ID からローカルなユーザー ID およびグループ ID へのマッピングも行うという効用もあります。
ログイン・サーバーを実装する
Linux による SMB プロトコルのサポートを使用して、ログイン・サーバーを実装できます。実際は、NT4 型ドメイン・コントローラーの機能を置き換えます。SAMBA は 、Windows クライアントには １ 次ドメイン・コントローラー (PDC)、また既存の SAMBA 対応 PDC にはバックアップ・ドメイン・コントローラー (BDC) として使用できます。smb 構成ファイルの 3 つのコンポーネントは、ログイン・サーバー、グローバル設定、netlogon 共有、プロファイル・ディレクトリーの設定という観点から見る必要があります。
SAMBA 構成ファイルの [global] セクションでは多数のエントリーを追加または変更する必要があります。変更は、構成ファイルを直接編集するか、webmin から行うことができます。webmin を使用して、次の変更を前述の Windows Networking オプションに行う必要があります。
domain logons = yes # PDC を有効にします
security = user # ローカル認証を行います
workgroup=WORKGROUP # ドメイン名を testgroup に設定します
wins support = yes # WINS サーバーとして smb を設定します
domain admin group = root # ドメイン管理者として root ユーザーを定義します
# 次は、ファイル・サーバーが「信頼」関係要求を受信する場合に実行する
# スクリプトを設定します
add user script = /usr/sbin/useradd -d / -g 100 -s /binfalse -M %u
logon drive = "H:" # ホーム・ディレクトリーのマップ先のクライアント上のドライブ文字
'domain logons = yes' エントリーは、この SAMBA サーバーがドメイン・ユーザーからログオン要求を受け入れる必要があることを示します。ユーザー認証は、'security = user' エントリーで示すようにローカルで処理されます。このサーバーが 1 次ドメイン・コントローラーであるドメインの名前が 'workgrop = WORKGROUP' エントリーに指定されています。サーバーは、'wins support = yes' エントリーに基づいて WINS 経由でアドレスの要求をサポートします。'domain admin group = root' エントリーは、Linux のルート・グループをドメインの管理グループとして扱うことを示します。'add user script' エントリーは、「信頼」関係を築くための要求がサーバーで受信されたときに実行するコマンドを示します。最後に、'logon drive = "H:"' エントリーは、ユーザーのホーム・ディレクトリーのマップ先となるクライアントのドライブ文字を示します。
上記に定義したグローバル設定の他に、前述のように [homes] セクションを定義して、ユーザーのホーム・ディレクトリーを共有する必要があります。
アクティブ・ディレクトリー・サーバーとの統合
ドメイン・コントローラーとの統合に加えて、認証を行うために SAMBA をアクティブ・ディレクトリー・サーバーと統合することもできます。この認証の SAMBA の構成は似ていますが、ADS サーバーと SAMBA サーバー間のセキュリティー・チケットの認証に Kerberos が使用されている点が異なります。
アクティブ・ディレクトリーと統合するためには、いくつか手順を踏む必要があります。
- ADS 認証の winbind を使用するよう Name Server Switch ファイルを変更します。(ドメイン・コントローラーの統合で示した場合と同様)
- samba 構成ファイルの [global] セクションを変更し、認証設定を指定します。
- Kerberos 構成 (/etc/krb5.conf) を設定します。
- アクティブ・ディレクトリー・サーバーとの信頼関係を築きます。
[global] 構成設定
この記事の前半で、すでに WebMin からの [global] 構成設定についてほとんどお話しました。セキュリティー・レルムの名前は WinBind オプションで設定され、セキュリティー・メカニズムは Windows Networking オプションで設定されています。
workgroup = WORKGROUP
realm = WORKGROUP.LOCAL
security = ADS
idmap wid = 10000-20000
idmap gid = 10000-20000
admin users = WORKGROUP\Administrator, WORKGROUP\administrator
nt acl support = yes
'workgroup' エントリーはドメイン名を示します。realm エントリーは Kerberos レルム名を示します。security エントリーは、認証にアクティブ・ディレクトリー・サーバーを使用していることを示します。idmap uid エントリーと idmap gid エントリーは、ドメイン・コントローラーの例で示した winbind エントリーと同じ機能を果たします (実際には winbind エントリーは idmap エントリーの代わりに使用することができたかもしれません)。admin users エントリーは、ファイル・サーバーで管理者として扱わなければならないユーザー・アカウントを示します。最後に、nt acl support エントリーはファイル・サーバーが、ファイル・システムの拡張属性である NT 型アクセス制御リスト情報をサポートすることを示します。
ADS 統合サポート時の Kerberos 構成
Kerberos 構成は /etc/krb5.conf ファイルに定義されています。構成ファイルは、セクションを括弧で囲むという点で samba 構成ファイルと似ています。統合するため、図 8 に示すように、統合するレルムを定義する [realms] セクションと、異なる形式のレルム名を 1 つの統一した名前にマッピングすることを定義する [domain_realm] セクションの 2 つのセクションを定義します。結果は次のようになります。
[logging]
default = FILE:SYSLOG:NOTICE:DAEMON
kdc = FILE:/var/log/krb5/krb5kdc.log
admin_server = FILE:/var/log/krb5/kadmind.log
[libdefaults]
default_realm = WORKGROUP.LOCAL
[realms]
WORKGROUP.LOCAL = {
default_domain = WORKGROUP
kdc = AD.WORKGROUP.LOCAL:
admin_server = AD.WORKGROUP.LOCAL:
}
[domain_realm]
WORKGROUP = WORKGROUP.LOCAL
[realms] セクションのエントリーは、鍵配布センター (kdc = AD.WORKGROUP.LOCAL) に使用するサーバーと Kerberos 管理サーバー (admin_server = AD.WORGRKOUP.LOCAL) を定義します。
この例では、これら両方の関数同じサーバーで実行されます (極めて一般的な構成です)。しかし、別々のサーバーで実行することもできます。ドメインは 'default_domain = WORKGROUP' エントリーで定義されます。
[domain_realms] セクションは WORKGROUP レルムが WORKGROUP.LOCAL レルムとして扱われることを示します。
いったん構成が変更されると、信頼関係が築かれます。
nt ads join -Administrator
上記のコマンドは、SAMBA 構成ファイルおよび Kerberos 構成ファイルで定義されたように、アクティブ・ディレクトリー環境に参加するよう要求が行われていることを示します。要求は Administrator アカウントで行われています。コマンドが実行され、Administrator のパスワードを指定する必要があります。コマンドで指定されたユーザーは、アクティブ・ディレクトリー・サーバー上で定義された有効な管理者でなければなりません。
上記の手順は、ユーザー認証のためにアクティブ・ディレクトリー・サーバーと統合する方法を示しており、今後の SAMBA では、SAMBA をアクティブ・ディレクトリー・サーバーとして設定する機能がサポートされる予定です。
データ・マイグレーション
通常 SAMBA ファイル・サーバーは既存のファイル・サーバーと置き換えるために設定されています。その場合、データ (ファイル) を新しいサーバーに移行する必要性が出てきます。もちろんこれは、テープのバックアップ/リストア、ftp による一括コピー、2 つのサーバー間でのドラッグ・アンド・ドロップなどさまざまな方法で行うことができます。はるかにエレガントな方法は、次のように SAMBA で提供されている 'net rpc' コマンドを使用して、既存のファイル共有からすべてのファイルをコピーする方法です。
net rpc share MIGRATE FILES fileshare -S old-server --acls --attrs --timestamps -v -U Administrator
上記のコマンドは、共有 'fileshare' のファイルをファイル・サーバー 'old-server' から現在のファイル・サーバーへ、ファイル共有 (fileshare など) というような名前にコピーします。コピーされたファイルは、アクセス制御リスト (--acls)、ファイル属性 (--attrs)、さらにファイル作成/変更/アクセス時間 (--timestamps) を維持します。-v フラグは、コピーされた各ファイルのメッセージを出力することを示し、'-U Administrator' は、ターゲット・ファイル・サーバーで 'Administrator' アカウントとしてコピーを行うことを示します。
その他 SAMBA のクールな点
SAMBA には、他にも次のように活用できる多数の機能があります。
- ユーザーまたは IP アドレスによるアクセス制御
- SAMBA をタイム・サーバーとして設定する
- 表示されない、またはアクセスできないファイルをファイル共有で非表示にする
- 接続タイプに基づき構成設定を組み込むまたはオーバーライドする
- SAMBA ファイル・サーバー 1 台で実質的にネットワーク上の複数のファイル・サーバーの機能を果たすことができるよう仮想ドメインを設定する
これらや他の SAMBA トピックのパブリック・ドメインで入手できる情報を調べてみることをお勧めします。
最後にお話しておきたい 2 つの項目として、アクセスの監査とバックアップの自動化があります。ユーザーが Linux サーバーにログインすると、ログインが成功しているかどうかに関係なく、そのログイン要求は、だれがシステムにアクセスしたか管理者が判断する材料となるアクセス・ファイルに登録されています。ファイルは、管理者以外のユーザーには見えないよう「ハッシュ」されています。デフォルトでは、SAMBA でのアクセスは登録されていませんが、次の 2 つのエントリーを SAMBA 構成ファイルの [global] セクションに追加して、その動作を変更することができます。
root preexec = /usr/X11R6/bin/sessreg -l %m -h %m -a %u
root postexec = /usr/X11R6/bin/sessreg -l %m -h %m -d %u
'preexec' 行は、ユーザーにアクセス権が与えられる前にコマンドを実行することを示し、'postexec' 行はユーザーが SAMBA 接続を閉じている場合に実行するコマンドを示します。/usr/X11R6/bin/sessreg プログラムは、user-access 監査ファイルにエントリーを配置する場合に使用するプログラムです。残りのパラメーターは、エントリーがシステムのホスト名 (%m) だけでなく、アクセスしようとしているユーザー (%h) を含むことを示しています。'root' エントリーは、root ユーザーとしてコマンドを実行することを示しています。
'preexec' エントリーと 'postexec' エントリーもファイル共有定義に使用できます。これは、バックアップを自動化する優れた方法と言えます。
[homes]
path = /home/%u
browseable = no
writable = yes
root postexec = tar cfz /var/samba/backup/%u/%T.tar.gz /home/%u
以前に [homes] セクションを見たことがあると思いますので、'postexec' 行にコメントする以外、ここであえて細かくお話することはしません。これは、ユーザーが共有への接続を閉じたときに実行するコマンドを示します。tar コマンドにより新しいバックアップが /var/samba/backup/user-name ディレクトリーに作成されます。ここで user-name を SAMBA の 'user-name' に置き換えます。ファイル名は、現在の日時の後に .tar.gz 拡張子が付けられます。結果生じるバックアップ・ファイルには、ユーザーのホーム・ディレクトリー (/home/user-name) のすべてのファイルが再帰的に入ります。これは、すべてのユーザー・ファイルを確実にバックアップする優れた方法です。
まず Linux によるファイル・サービス。で、次は?
この記事からいいアイデアをいくつか得られたことと思います。経験上、ファイル・サービスは、 IBM i ショップが実装する最初の Linux ベース機能の 1 つになる傾向があります。というのも、設定と管理が比較的簡単で、エンド・ユーザーを教育する必要がないためです。正しく行えば、ファイル・サーバーを 1 日で Windows にホストさせ、夜間に Linux サーバーと交換しても、エンド・ユーザーには違いが分からないでしょう。このシリーズの次号では、Linux を使用して多数のネットワーク・インフラストラクチャー・ソリューションを実装する方法を見てゆきましょう。このシリーズで特に取り上げてもらいたいオープン・ソース・ソリューションがあれば、opensolutions@askerwin.com までお知らせください。
