スタンドアロンサーバは、ネットワーク上での独立したドメインコントローラである。それらはドメインメンバではなく、ワークグループサーバのように機能する。多くの場合、スタンドアロンサーバは、提供されたデータが容易にすべての利用者からアクセス可能という意図で、最低限のセキュリティ制御で設定されているサーバである。
スタンドアロンサーバは、必要性によって、セキュアにも非セキュアにもできる。単純あるいは複雑な設定を取ることが出来る。上記のように、ドメインセキュリティについて、過大な説明にもかかわらず、多くは普通のインストールのままである。
もしも、サーバに必要とされるものがすべて読み込み専用ファイルか、プリンタのみならば、複雑な設定をするのは意味をなさない。たとえば、設計事務所が古い設計図と設計標準を格納しておく必要があるとする。すべての文書が変更されないままでいることが法律的に重要なので、誰もサーバにファイルを書き込めない。シェアモードのリードオンリスタンドアロンサーバは理想的な解決方法である。
単純さを正当化するもう1つの状態は、一つの中央サーバから待ち行列に入れられる多くのプリンタを持っているオフィスである。全員がプリンタに印刷出来る要求があるが、アクセス制御の必要がなく、プリンタサーバにはファイルがない場合である。繰り返すと、シェアモードスタンドアロンサーバはとても優れた解決方法を提供する。
standalone serverという言葉は、ローカルな認証とその上で有効なすべてのリソースのアクセスを制御する機能を提供するという意味である。一般的に、これは、ローカルユーザデータベースがあると言うことを意味する。もう少し技術的な言葉で言うと、これは、マシン上のリソースは、shareモードかuserモードのいずれかが有効であるということである。
ユーザアカウントを作成するため以外に特別な操作は必要ない。スタンドアロンサーバはネットワークログオンサービスを提供しない。これは、このサーバを使うマシンはこれに対するドメインログオンを実行しないことを意味する。ワークステーションが使うどんなログオン機能も、このマシンからは独立している。しかし、使用するログオン名がローカルで持っているユーザ名をスタンドアロンサーバ上でローカルに変換(マップ)するために、任意のネットワークユーザを一致させることは必要である。このことを実行するためにはいくつかの方法がある。
Sambaはスタンドアロンサーバの定義中で少しだけ区別を曖昧にするのに役立つ。これは、SMBプロトコルの視点から、Sambaサーバがドメインセキュリティコンテキストのメンバでないとしても、認証データベースがローカルかリモートサーバ上にあるという理由である。
UNIXユーザデータベースを操作するPAMとネームサービススイッチ(NSS)を使って(PAMに付いての節を参照)、認証のソースは別のサーバ上にあってもよい。これを認証サーバと呼ぶ傾向がある。これは、SambaサーバはローカルのUNIX/Linuxシステムパスワードデータベース(/etc/passwd
か/etc/shadow
)か、ローカルのsmbpasswdファイルか、LDAPバックエンドか、認証のために、PAMとWinbind経由で他のCIFS/SMBサーバを使っても良いことを意味する。
参照用文書サーバの例とセンタ印刷サーバは単純さにヒントを得てデザインされた。それは高度な創造性を試みることと、サーバとネットワーク設計においてとても複雑であることを説明することはとても簡単である。
誰でもアクセスできる読み込み専用データサーバの設定はとても単純である。既定値では、すべての共有は、smb.conf
ファイルに何か書かれるまではリードオンリである。参照用文書サーバの例はこれを行うためのsmb.conf
ファイルである。すべての参照用文書はディレクトリ/export
に格納されていて、文書はnobody以外のユーザによって所有されていることを仮定する。ホームディレクトリは共有されず、UNIXシステムデータベース/etc/passwd
中にはユーザはいない。これは管理者にとって単純なシステムである。
もう少し準備に時間があれば、もう少し簡単にできた。 | ||
--Mark Twain |
この例中で、マシン名はGANDALFに設定され、ワークグループはローカルワークグループ(MIDEARTH)の名前に設定され、ユーザがなじみのあるシステムと一緒に表示される。必要とされる唯一のパスワードバックエンドは、既定値の非制限アカウント名として使われることを許可する“guest”バックエンドである。このネットワーク上でWINSサーバがあるならば、もちろんそれを使う。
米国空軍連隊長が言った有名なことは:A US Air Force Colonel was renowned for saying: “最善は善の的(Better is the enemy of good enough!)”。専門的に完全な解決を避けることと同様、複雑さを避けることに対して、しばしば健全な理由が存在する。不幸にも、トラブルがないことを保持するのにちょうど十分な術を、多くのネットワーク管理者は引き続き覚える必要がある。
単純な印刷サーバの設定は、システム上のすべての正しいツールがあるならば簡単である。
前提条件
印刷サーバは管理不要でなければならない。
印刷サーバ印刷の、スプールと処理をするシステムはCUPSである。 (詳細情報はCUPS印刷システムを参照のこと)。
印刷サーバはネットワークプリンタのみ処理を行う。ネットワーク管理者は プリンタをサポートするためにCUPS環境を正しく設定している。
すべてのワークステーションはPostScriptドライバを使う。選択したプリンタ ドライバはApple Color LaserWriterのためのWindows OS用のものを選択する。
この例では、印刷サーバは入力したすべての印刷ジョブを、Sambaによって、CUPS印刷プロセッサに向けて送られたジョブが実行可能になるまで/var/spool/samba
にスプールする。すべての入力された接続は匿名(guest)ユーザなので、匿名印刷を有効にするために、2つ設定が必要である。
匿名印刷を有効にする
UNIX/Linuxシステムはguest
アカウントを持たねば ならない。この既定値は、通常nobody
である。 使用するバージョンで使っている正しい名前を探すためには、以下を実行する:
$
testparm -s -v | grep "guest account"
このアカウントはシステムのパスワードデータベース (/etc/passwd
)に存在するようにしておかねばならない。
このアカウントに対してパスワードを設定するか、UNIXでの使用からロックすることは 良い考えである。ゲストアカウントがpcguest
であると仮定した時、 以下を実行することでロックが出来る:
root#
passwd -l pcguest
正確なコマンドは使用するUNIX/Linuxディストリビューションによって異なる。
Sambaがファイルをスプールするディレクトリはゲストアカウントに対して 書き込み許可を持たねばならない。以下のコマンド操作で、このディレクトリ が使えるようにする:
root#
mkdir /var/spool/samba
root#
chown nobody.nobody /var/spool/samba
root#
chmod a+rwt /var/spool/samba
smb.conf
ファイルの内容は匿名印刷の例にある。
CUPSが有効なシステム上で、CUPSプリントフィルタ経由の中間処理なしで生データを直接プリンタに送る機能がある。このモードの操作が要求される場合、raw印刷デバイスの設定が必要である。また、/etc/mime.conv
と/etc/mime.types
ファイル中にraw mime ハンドラを有効にする設定も必要である。CUPS印刷サポート、application/octet-streamで明示的にraw印刷を有効にするを参照のこと。
匿名印刷の例中では、CUPSライブラリAPI経由で直接印刷のためにCUPSを使用する。これは、すべてのプリンタはprintcapファイルを設定する必要なしにWindowsユーザから見えるようになるという意味である。もしも、プリンタのサブセットのみか、特別な種類のプリンタ(たとえばPDFフィルタ)を見せる必要があるならば、printcap name = cups
をprintcap name = /etc/samba/myprintcap
に置き換えても良い。この場合、指定されたファイルはWindowsネットワークユーザに見せるべきプリンタ名の一覧を含む必要がある。