第 2 章 主な変更について

Solaris 2.6 環境には、SunOS 4.x 環境と似ている点があり、また、異なる点もいくつかあります。このマニュアルのこれ以降の章では、これらのリリースの間で変更された作業手順、ツール、コマンド、また、概念について説明します。

この章では、主な変更点について紹介します。また、第 3 章「SunOS 4.x システムから Solaris 2.6 環境への変換」以降で取り上げられる項目の概念を説明します。この章で取り上げる項目の中には、記述されている説明だけで十分なものもあれば、より詳細な技術的背景の説明を必要とするものもあります。後者の場合は、詳細に説明されている章を示してあります。

• 「ソフトウェアパッケージとクラスタ」

• 「ディスクスライス (またはディスクパーティション)」

• 「デバイスの命名」

• 「ファイルシステム」

• 「カーネルの構成」

• 「自動マウント」

• 「Admintool」

• 「ネットワーク情報サービスプラス (NIS+)」

• 「印刷サブシステム」

• 「サービスアクセス機能」

• 「ボリュームマネージャ」

ソフトウェアパッケージとクラスタ

Solaris 2.6 システムソフトウェアは、 パッケージ という単位で出荷されます。パッケージとは、ソフトウェア製品に必要なファイルとディレクトリの集合体のことです。クラスタは、パッケージの集合体のことです。

ここで 4 つのクラスタについて説明します。2 番目以降の各クラスタは、その上にあるクラスタのソフトウェアに、別のソフトウェアを追加したものとなっています。

• コアシステムサポート - 必要最小限のソフトウェア構成です。Solaris 2.6 環境のブートと動作に必要なソフトウェアだけから構成されています。

• エンドユーザシステムサポート - コアシステムサポートに、エンドユーザをサポートする OpenWindows ウィンドウシステムや、関連する DeskSet アプリケーションファイルを追加したものです。このクラスタの中には、エンドユーザに推奨されるソフトウェアが含まれています。

• 開発者システムサポート - エンドユーザシステムサポートに、Solaris 2.6 環境でソフトウェア開発を行うために必要なライブラリ、インクルードファイル、ツールを追加したものです。ここでいう Solaris 2.6 環境には、コンパイラとデバッガは含まれていません。

• 全体ディストリビューション - Solaris 2.6 環境全体が含まれます。

詳細は、『Solaris のシステム管理』を参照してください。

パッケージの管理

パッケージを管理するプログラムにより、ソフトウェアのインストールとアップデートが容易になります。管理システムのソフトウェアと、サードパーティのアプリケーションの管理方法が一貫しているため、管理が簡単になっています。ソフトウェアパッケージを作成するツールは、アプリケーションパッケージ作成ツールのライブラリの中に含まれています。

パッケージのインストールと削除に使用できるツールは 2 つあります。

• グラフィカルユーザインタフェースプログラム (admintool(1M) のマニュアルページを参照)

• コマンド行ユーティリティ (pkgadd(1M) と pkgrm(1M) のマニュアルページを参照)

グラフィカルユーザインタフェース (admintool)

admintool (admintool コマンドで起動します) を使用して、ローカルシステムやリモートシステムにソフトウェアをインストールすることができます。デフォルトでは、ローカルシステムへインストールされます。

Admintool を使用すると、次のことが行えます。

• ローカルシステムにインストールされているソフトウェアの表示

• ローカルシステムでのソフトウェアのインストールと削除

ソフトウェアのインストールと削除を行うには、スーパーユーザまたはシステム管理グループ (グループ 14) のユーザとして Admintool を実行しなければなりません。システム上にすでにインストールされているソフトウェアパッケージを表示する場合は、スーパーユーザでなくてもかまいません。

コマンド行ユーティリティ

コマンド行ユーティリティにより、ソフトウェアパッケージをインストールしたり、削除したり、また、インストールの状況をチェックしたりすることができます。コマンドは次のとおりです。

• pkgadd(1M) は、パッケージのインストールを行います。

• pkgrm(1M) は、パッケージの削除を行います。

• pkgchk(1M) は、パッケージのインストール状況をチェックします。

• pkginfo(1M) は、システム内にインストールされているパッケージを一覧表示します。

パッチの管理

patchadd(1M) コマンドと patchrm(1M) コマンドは、Solaris 2.x システムにパッチをインストールするためと、パッチを除去するために使われます。システム、クライアント、サービス、またはネットインストールイメージに 1 つ、または複数のパッチを追加できます。

詳細は、 patchadd(1M) と patchrm(1M) を参照してください。

ディスクスライス (またはディスクパーティション)

1 つの連続ブロック、またはディスクの物理的なサブセットを SunOS 4.x ではディスクパーティションといいます。SunOS 5.xでは、ディスクの物理的なサブセットをディスクスライスといいます。ディスク上でファイルシステムを作成する前に、ディスクをフォーマット化し、いくつかのスライスに分割する必要があります。これは通常、Solaris 2.x インストレーションプログラムを使って Solaris をインストールする時に行われます。インストール後にディスクをインストールし、フォーマット化しなければならない場合は、『Solaris のシステム管理』を参照してください。

一部の Solaris のマニュアルでは、Solaris スライスをまだ「パーティション」と呼んでいる場合があります。Solaris 2.x のマニュアルでは、fdisk パーティション (Intel システムの場合) と、fdisk パーティション内部の区分を区別しています。後者の場合、各区分はスライスともパーティションとも呼ばれています。

Solaris fdisk パーティションの説明については、『Solaris のシステム管理』を参照してください。

スライスはスワップ空間用の raw デバイスとして、または 1 つの UFS ファイルシステムだけを持つデバイスとして使用できます。ただし、Solstice DiskSuite^TM のような製品を使っている場合は除きます。表 2-1 に、それぞれの Solaris 2.x プラットフォーム上でディスクスライスをセットアップする方法を説明します。

プラットフォーム別のディスクスライスの慣例的な割り当ての説明については、 『Solaris のシステム管理』を参照してください。

シリンダグループ

あるディスクスライス上に UFS ファイルシステムを作成した場合、このディスクスライスは、1 つまたは複数の領域に分割されますが、この領域のことをシリンダグループと呼びます。シリンダグループは、1 つまたは複数の連続したディスクシリンダによって構成されています (ディスク装置は複数のディスクによって構成され、各ディスクの円周方向に沿っていくつものトラックが刻まれています。シリンダとは、いくつかのディスクで、ディスクの中心から同じ距離にあるトラックのことを指します) 。ディスクの構造に関する詳細は、『Solaris のシステム管理』を参照してください。

シリンダグループごとに、シリンダグループマップが作成されます。シリンダグループマップには、ブロックの使用状況と利用可能なブロックが記録されます。

図 2-1 は、ディスクスライスとシリンダグループの関係を示しています。

図 2-1 ディスクスライスとシリンダグループ

デバイスの命名

SunOS 5.6 のデバイス名は、そのデバイスの特徴を容易に推定できるようになっています。SunOS 4.x では、デバイスの属性よりもタイプを表す名前を採用していたため、プログラムやスクリプトがデバイスに関する情報を得ることが困難でした。SunOS 5.6 では、ディスクに 8 つのパーティションしか設けられないので、AT&T SVR4 とはわずかに異なるデバイスの命名規則を採用しています。

さらに、特殊なデバイスファイルは現在は階層構造の/devices ディレクトリに格納されており、これには管理者とユーザがデバイスにアクセスするために使用する階層構造の /dev ディレクトリへのシンボリックリンクが付いています。/dev ディレクトリには、ディスクデバイスにアクセスするための /dev/dsk/*、raw ディスクデバイスにアクセスするための /dev/dsk/*, などのサブディレクトリが含まれています。詳しくは、「デバイス命名規則」を参照してください。デバイスの命名規則については、「開発者に関係するデバイスの命名規則」を参照してください。

ファイルシステム

SunOS 5.6 と SunOS 4.x のファイルシステムは類似していますが、システムディレクトリとシステムファイルの位置と名前には変更が加えられています。5.6 には、新しいファイルシステムと新しい疑似ファイルシステムが追加される一方で、1 つのディレクトリが使用されなくなっています。

「ファイルシステムの変更」では、ファイルシステムの変更について説明しています。『Solaris のシステム管理』では、ファイルシステムの概念と管理について詳細に説明しています。

ファイルシステムの位置と名前の変更

ファイルシステムの位置と名前についての変更は、次のとおりです。

• /dev ディレクトリは、平坦な構造から階層構造に変更されました。

• /etc ディレクトリには、システム構成情報が含まれるようになりました。ファイルとサブディレクトリの追加、削除、変更が行われています。

• /etc/vfstab ファイルは、/etc/fstabに変更されました。

• /etc/lp ディレクトリは、/etc/printcap に変更されました。

• SunOS 5.6 では、/sbin ディレクトリに、システムの実行レベルを変更する rc スクリプトと、ファイルシステムをマウントする前にシステムを初期設定する rcs スクリプトが含まれています。

• SunOS 5.6 では、/usr ディレクトリに、システムの提供する共有可能ファイルと実行可能ファイルが含まれています。

• /var ディレクトリには、通常の使用の際に大きさが変化するファイルが含まれています。ファイルとサブディレクトリの追加、削除、変更が行われています。

• /var/mail ディレクトリは、 /var/spool/mail に変更されました。

• カーネルが動的にロードされるため、/sys ディレクトリは使用されなくなりました。

• terminfo データベースは、termcap に変更されました。

• SunOS 5.6 のコアカーネルは genunix と呼ばれます。カーネルモジュールは/kernel、/usr/kernel、/platform および /usr/platform の各ディレクトリに格納されています。

疑似ファイルシステム

疑似ファイルシステムとは、ディスクベースのシステムに存在する、論理的なファイルグループのことです。SunOS 5.6 には、TFS 疑似ファイルシステムは含まれていません。

SunOS 5.6 で使用されている疑似ファイルシステムは、次のとおりです。

• CACHEFS 疑似ファイルシステム - CD-ROM ドライブのような低速デバイスの性能を上げるために使用します。

• PROCFS 疑似ファイルシステム - メモリに常駐し、アクティブなプロセスのプロセス番号を /proc ディレクトリに保持しています。proc(4) のマニュアルページを参照してください。

• FDFS 疑似ファイルシステム - 明示的なファイル名を提供し、ファイル記述子を使用してファイルをオープンします。

• FIFOFS 疑似ファイルシステム - パイプファイルを格納して、複数のプロセスが共通のデータをアクセスをできるようにします。

• NAMEFS 疑似ファイルシステム - ファイル記述子をファイルの先頭に動的にマウントするのが目的で、ほとんどの場合 STREAMS が使用します。

• SWAPFS 疑似ファイルシステム - デフォルトのスワップデバイスで、システムのブート時やシステム管理者が他のスワップ空間を作成するときに使用します。

追加されたファイルシステム

SunOS 5.6 のディレクトリ構造には、次のファイルシステムも含まれています。

• オプションの /opt ファイルシステム - サードパーティのソフトウェアや、アンバンドルのソフトウェアを格納するために使用します。/opt が単独のファイルシステムではない場合は、/usr/opt へのシンボリックリンクになっています。

• /vol ファイルシステム - ボリューム管理デーモン vold(1M) が使用するデフォルトのファイルシステムを提供します。 volfs(7) のマニュアルページを参照してください。

除去されたファイルシステム

RFS ファイルシステムタイプのサポートは除去されました。

カーネルの構成

SunOS 4.x とは異なり、SunOS 5.6 のカーネルは、動的に構成されます。したがって、システム構成に変更を加えても、システム管理者が手作業でシステムを再構築する必要はありません。

SunOS 5.5 以降、カーネルとそのモジュールはプラットフォーム非依存オブジェクトとプラットフォーム依存オブジェクトに分割されました。プラットフォーム非依存カーネルは /kernel/genunix と呼ばれる小さい静的コアと動的にロード可能なカーネルモジュールで構成されています。動的にロード可能なカーネルモジュールは、プラットフォーム非依存の場合は /kernel ディレクトリと /usr/kernel ディレクトリに格納され、プラットフォーム非依存の場合は /platform ディレクトリと /usr/platform ディレクトリに格納されます。プラットフォーム依存ディレクトリとその内容については、『Solaris のシステム管理』を参照してください。

ドライバ、ファイルシステム、STREAMS モジュール、その他のモジュールは、ブート時か実行時に、必要に応じて自動的にロードされます。modinfo(1M) コマンドは、現在システムにロードされているモジュールに関する情報を表示します。

modload(1M) と modunload(1M) の各コマンドは、リリース 5.6 でも利用できますが、動作が変更されています。これらのコマンドの用途は限られたものとなっており、ロード可能ドライバをシステムにインストールするには、もはや十分ではありません。 modunload(1M) コマンドは、SunOS 4.x のコマンドに似ていますが、現在は、次の例のように、アンロード可能な (そして使用されていない) すべてのモジュールをアンロードする機能を備えています。

# modunload -i 0

第 18 章「システムとデバイスの構成」ではこれらの項目について詳細に説明します。

カーネルのレイアウト

カーネルの内容は、以前は 1 つのファイル /vmunix に入っていましたが、現在、プラットフォーム非依存とプラットフォーム依存のディレクトリ階層内の複数のモジュールになっています。デフォルトでは、ディレクトリ階層は以下のようになっています。

• /kernel

• /usr/kernel

• /platform

• /usr/platform

/etc/system ファイル内の moddir 変数を使用して、モジュールのディレクトリ検索パスを設定することも可能です。system(4) のマニュアルページを参照してください。通常は、/kernel/genunix はロードされるカーネルの先頭部分になります。詳しくは、system(4) とkernel(1M)を参照してください。

自動マウント

AutoFS と呼ばれる新規バージョンの自動マウント機能が組み込まれました。SunOS 4.x では、自動マウント機能は /tmp_mnt にすべてマウントして、シンボリックリンクを使ってルックアップをリダイレクトしました。AutoFS では、ファイルシステムを所定の場所 (たとえば、/home) にマウントできます。

SunOS 4.x では、自動マウント機能のマップには auto.master および auto.home という名前が付けられていました。Solaris 2.6 では、これらのマップの名前は auto_master、auto_home などに変更されています。この変更は、このリリースに組み込まれている NIS+ ネームサービスが必要とするものです。このリリースにはこれらのマップのデフォルトコピーが組み込まれているため、システムをブートした時に AutoFS サービスが起動します。SunOS 4.x にはマップは組み込まれていなかったため、余分なインストール手順が必要でした。

Solaris 2.6 には、/etc/nsswitch.conf を通して使われるネームサービスを選択できる機能が備わっています。自動マウントのエントリを変更して、ローカルファイル、NIS+、NIS、またはこれらの組合せを選択するようにできます。

旧リリースは、/home/server/login のようなホームディレクトリの命名規則をサポートしていました。AutoFS マップを使うと、/home/login をエントリ別に簡単に使用できるようになります。この新しい命名規則には、位置に依存しない機能も備わっています。古い規則もまだ使用できますが、いったん AutoFS マップの使用に移行すると、短いパスの管理が簡単になります。

AutoFS で使用できるパスには、次のものがあります。

• /net - 認識されているホストからファイルシステムをマウントする場合

• /home - 認識されているユーザのホームディレクトリをマウントする場合

• /xfn - X/Open XFN 標準対応のファイルシステムをマウントする場合

ホームディレクトリサーバでは、実際のホームディレクトリを /home ではなく /export/home に移動して、自動マウント機能のディレクトリ構造との干渉を防ぐ必要があります。つまり、自動マウント機能が実行している間は /home にファイルシステムをマウントすることはできません。

AutoFS ソフトウェアは現在、2 つのプログラムを持っています。1 つは automount であり、ブート時に実行して AutoFS マウントポイントを設定します。このコマンドは、マウントポイントを変更するためにスーパーユーザがいつでも実行できます。もう 1 つのコマンドは状態なしデーモンである automount で、これは AutoFS ファイルシステムのマウントおよびアンマウントの要求に応答します。この 2 つのプログラムは、4.1.x automount デーモンに代わるものです。

自動マウントデーモンは、現在は完全にマルチスレッドに対応しています。複数の自動マウント要求に同時に対応できるため、AutoFS の信頼性が高まります。要するに、1つのマウント要求が遅いサーバへの接続をブロックしている間に、2 番目の要求を待たせずに処理することができます。

Solaris 2.6 では、間接的な AutoFS マップのブラウズ機能をサポートします。AutoFS マウントポイント (例: /home) に属するマウント可能なエントリはすべて、最初にそれをマウントしなくても表示できるようになりました。

また、階層的に関連しているファイルシステムの要求時自動マウント機能も改善されました。旧リリースでは、ファイルシステムが階層的に関連している場合は、ファイルシステムの中の 1 つだけを参照するときでも、そのセット全体 (たとえば、/net/server) を自動的にマウントしていました。参照されるファイルシステムは動的にマウントされるようになり、階層内のその他のファイルシステムをマウントする必要がなくなりました。その他のファイルシステムは、個別に参照されたときにマウントされます。

詳しくは、「ファイルシステムのマウントと autofs」を参照してください。また、AutoFS の使用法については『NFS の管理』を参照してください。

メールの管理

このリリースに組み込まれている sendmail のバージョンは、バージョン 8 と互換性があります。新しいバージョンではセキュリティ上の不備をいくつか修正しており、バージョン 5 を改善した内容も組み込まれています。ネームサービススイッチや NIS+ のサポートなど、標準 BSD リリースの拡張機能もいくつか追加されています。

NIS+ をさらにサポートするために、aliasadm という新しいコマンドが組み込まれています。このコマンドは、NIS+ エイリアスリストの管理に役立ちます。

メールボックススプールディレクトリは、/var/spool/mail から /var/mail に移動しました。新しいディレクトリ /var/mail/:saved が、ロックおよび一時ファイルの作成のために mailx プログラムによって使われます。また、メール構成ファイルはすべて /etc/mail に配置されるようになりました。この新規ディレクトリには aliases ファイルと sendmail.cf ファイルが入っています。

メールボックスロッキング機構が機能拡張されたため、Solaris 2.6 のクライアントは Solaris 2.x および SunOS 4.x のメールサーバの両方から安全にメールボックスをマウントできます。この拡張機能によって、とくに大規模なサイトでのメールの管理が容易になります。

Solaris 2.6 では、/usr/ucb/mail に代わって /usr/bin/mailx が使われています。mailx プログラムは、/usr/ucb/mail の SunOS 4.x バージョンと同じように動作するよう機能拡張されました。/usr/ucb/mail ファイルは、現在は /usr/bin/mailx へのシンボリックリンクになっています。

SunOS 4.x では、sendmail.mx と呼ばれるプログラムを DNS サイトで使ってメール交換レコードにアクセスしていました。新規バージョンの sendmail には必要な機能が組み込まれており、/etc/nsswitch.conf を通して構成できます。

『メールシステムの管理』に sendmail の管理方法を説明しています。

Admintool

システム管理に関する SunOS 4.x と SunOS 5.6 の主な変更点の 1 つは、基本的な管理タスクを実行する Admintool (システム管理ツール) を利用できるようになったことです。このツールは、グラフィカルユーザインタフェースを採用して、ユーザ、ホスト、プリンタ、シリアルデバイスの管理作業を容易にします。適切なアクセス権が割り当てられていれば、ローカルシステムでこれらの作業を管理することができます。

Admintool のアプリケーションを使用すると、ローカルシステムで次の管理を行うことができます。

• aliases や netmasks のようなシステムデータベースファイルの管理

• ユーザとグループの追加、機能追加に伴うパスワードの変更、ユーザアカウント情報の削除などを含む、ユーザアカウント情報の管理

• ローカルとリモートのプリンタとリモートプリンタの設定

• 端末とモデムの設定

• パッケージの管理

Admintool のようなグラフィカルユーザインタフェースを使用してシステム管理作業を行うと、次のようなメリットがあります。

• SunOS の多くのコマンドを使用して同じ作業を行う場合より高速です。

• 手作業で編集する場合は、ミスをする危険がありますが、システムファイルは自動的に更新されるので、そのような危険がありません。

• これらのアプリケーションプログラムは適切なシステムデーモンと相互に情報を交換し、これらの同期がとれなくなると、そのことをシステム管理者に通知します。

Admintool を起動するために root としてログインする必要はありません。ただし、sysadmin グループ (GID= 14) のメンバでなければなりません。

Admintool ウィンドウを表示するには、任意のウィンドウで次のコマンドを入力します。

$ admintool &

ネットワーク情報サービスプラス (NIS+)

NIS+ とは、Solaris ネットワーク用のネットワーク情報サービスのことです。Solaris ネットワークは NIS を NIS+ の代替機能としても、NIS+ の補足機能としても使用できます。

NIS+ とは、ONC トランスポート独立遠隔手続き呼び出し (transport-independent remote procedure call, RPC) インタフェースの最上位に構築されているネームサービスのことです。NIS+ は、セキュリティ、パフォーマンス、スケーラビリティ、管理の面で、NIS に比べて大きな利点を持っています。NIS+ を使用する利点は、次のとおりです。

• NIS+ は、NIS 環境とデータを共有するので、円滑に移行できます。

• ドメインは階層構造です。サブドメインを作成することもできます。

• ネームサービススイッチ (/etc/nsswitch.conf) を使用して、NIS+、NIS、/etc、DNS のうち、システムが最初にどのネームサービスを試みるか設定することができます。

• AdminSuite を使用して、NIS+ のテーブルを変更し、情報を追加、変更、削除、検索することができます。

• NIS+ で企業全体のネームサービスを作成し、保守することができます。WAN リンクによって接続されている地理的に離れたサイトにも対応できます。

• NIS+ バックアップおよび復元機能を使って、名前空間データセットをすばやく、簡単に保存できます。また、この機能を使って追加のレプリカサーバをすぐにオンライン化することもできます。

詳細は、このマニュアルの第 13 章「ネームサービスの使用方法」や、『NIS+ への移行』、『NFS の管理』を参照してください。

印刷サブシステム

SunOS 4.x と、Solaris 2.6 環境の間で、印刷管理コマンドが変更されています。Solaris 2.6 環境では、コマンド行からの操作や Admintool を使用してプリンタを設定できるほか、管理コマンドや印刷ツールを使用して印刷ジョブを制御することができます。

詳細は、第 11 章「プリンタ、端末、モデムの管理」と、『Solaris のシステム管理』を参照してください。

印刷ツール

印刷ツールとは、Solaris 2.6 ユーザ環境で利用できるソフトウェアツールのことです。このツールを使用すると OpenWindows や CDE でユーザはプリンタの監視や、印刷ジョブの監視と中止を行うことができます。

コマンドの変更

次に変更されたコマンドを示します。

• lpr は、lp(1) に変更されました。

• lpq は、lpstat(1) に変更されました。

• lprm は、cancel(1) に変更されました。

• troff(1) は、プリンタ名を必要とするようになりました。

• Solaris 2.6 では、TEX と pscat (C/A/T) とラスタイメージフィルタは利用できません。

lp サービスは、複数のデーモン (プロセス) によって構成されて、これらのデーモンは、システムの動作と、/etc/lp ディレクトリ内の構成ファイルの階層を監視しています。また、lp サービスを管理コマンドのセットとみなすこともできます。

サービスアクセス機能

サービスアクセス機能 (SAF) とは、端末、モデム、他のネットワークデバイスの管理に使用するツールのことです。特に、SAF を使用すると次の作業が行えます。

• ttymon と listen ポートモニタの追加と管理 (sacadm コマンドを使用)

• ttymon ポートモニタサービスの追加と管理 (pmadm と ttyadm コマンドを使用)

• listen ポートモニタサービスの追加と管理 (pmadm と nlsadmin コマンドを使用)

• TTY デバイスの管理と問題の解決

• 印刷サービスを要求するネットワーク要求の管理と問題の解決

• サービスアクセス制御 (SAC) の管理と問題の解決 (sacadm コマンドを使用)

SAF はオープンシステムソリューションで、TTY デバイスとローカルエリアネットワーク (LAN) を通して、システムへのアクセスとネットワークの資源を制御します。SAF は、適切な定義の行われたインタフェースを提供し、新しい機能の追加と既存の機能の構成を容易にします。

SAF はプログラムではありません。バックグラウンドプロセスと管理コマンドからなる階層によって構成されています。最上位にある SAF プログラムは、SAC です。SAC は、システム管理者が sacadm コマンドにより管理するポートモニタを制御します。各ポートモニタは、1 つまたは複数のポートを管理することができます。

pmadm コマンドを使用して、ポートに関係するこれらのサービスを管理することができます。SAC 経由で提供されるサービスはネットワークごとに異なりますが、SAC と、管理プログラムの sacadm と pmadm は、ネットワークの種類に合わせてカスタマイズされてはいません。

表 2-2 は、SAF の制御階層を示しています。sacadm コマンドは SAC を管理し、SAC は ttymon と listen の各ポートモニタを制御します。

ttymon と listen のサービスは、pmadm によって順番に制御されます。ある ttymon のインスタンスは、複数のポートへサービスを提供することができます。また、ある listen のインスタンスは、1 つのネットワークインタフェースを使用して複数のサービスを提供することができます。

詳細は、第 11 章「プリンタ、端末、モデムの管理」を参照してください。

ボリュームマネージャ

Solaris 2.2 以降のバージョンでは、CD-ROM とフロッピーディスクデバイスを管理する新しいソフトウェア階層、ボリュームマネージャが採用されています。このソフトウェアは、ユーザが CD-ROM やフロッピーディスクに対して行う操作を自動化します。

CDE OpenWindows ファイルマネージャにボリュームマネージャが利用できるように変更を加え、ファイルシステムを持つ CD-ROM やフロッピーディスクに、すぐにアクセスすることができます。ファイルマネージャの新しい機能の詳細については、『Solaris ユーザーズガイド』を参照してください。

システム上でボリュームマネージャの管理を支援する新しいコマンドも追加されています。

詳細は第 7 章「デバイスの管理」 「ボリュームマネージャの使用」を参照してください。