Solaris 移行ガイド

第 2 章 主な変更について

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

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

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

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

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

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

パッケージの管理

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

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

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

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

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

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

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

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

パッチの管理

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

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

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

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


注 -

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


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

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

表 2-1 プラットフォームによるスライスの相違

SPARC 

Intel ベース 

ディスク全体が Solaris 動作環境専用に使われます。 

ディスクは 4 つの fdisk パーティションに分割され、1 つの動作環境に 1 つずつ使われます。

ディスクは 8 つのスライスに分割されており、0 〜 7 の番号が付いています。 

Solaris fdisk パーティションは 10 個のスライスに分割されており、0 〜 9 の番号が付いています。そのうち、ユーザのデータを格納できるのは 0 〜 7 だけです。

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

シリンダグループ

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

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

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

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

Graphic

デバイスの命名

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

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

ファイルシステム

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

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

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

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

疑似ファイルシステム

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

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

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

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

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

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

カーネルの構成

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

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

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

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

# modunload -i 0

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

カーネルのレイアウト

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

/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 7 では、これらのマップの名前は auto_masterauto_home などに変更されています。この変更は、このリリースに組み込まれている NIS+ ネームサービスが必要とするものです。このリリースにはこれらのマップのデフォルトコピーが組み込まれているため、システムをブートした時に AutoFS サービスが起動します。SunOS 4.x にはマップは組み込まれていなかったため、余分なインストール手順が必要でした。

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

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

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

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

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

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

Solaris 7 では、間接的な 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 7 のクライアントは Solaris 2.x および SunOS 4.x のメールサーバの両方から安全にメールボックスをマウントできます。この拡張機能によって、とくに大規模なサイトでのメールの管理が容易になります。

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

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

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


注 -

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+ を使用する利点は、次のとおりです。

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

印刷サブシステム

Solaris 2.6 リリースの印刷用ソフトウェアから、ネットワーク上のプリンタに対するクライアントアクセスの設定と管理を行うための集中的な環境が実現しました。印刷用ソフトウェアは以下の機能を含んでいます。

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

印刷ツールまたはコマンドをシェルで使用しても、上記の基本的なタスクを実行できます。

印刷ツール

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

コマンドの変更

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

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

サービスアクセス機能

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

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

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

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

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

表 2-2 SAF の機能と関連プログラム
 機能 プログラム 説明

全体的な管理 

sacadm

ポートモニタの追加と削除を行うコマンド  

サービスアクセス制御  

sac

SAF のマスタプログラム

ポートモニタ

ttymon

シリアルポートのログイン要求を監視する 

 

listen

ネットワークサービスの要求を監視する  

ポートモニタサービスの

管理 

pmadm

ポートモニタのサービスを制御する 

サービス

ログイン、 

遠隔手続き  

呼び出しなど 

SAF がアクセスを提供するサービス 

access 

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

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

ボリュームマネージャ

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

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

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

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