第 4 章 ユーザーアカウントとグループの管理 (概要)

この章では、ユーザーアカウントとグループを管理するためのガイドラインと管理計画の概要について説明します。また、ユーザーの作業環境のカスタマイズについても説明します。

この章の内容は以下のとおりです。

• 「ユーザーとグループの管理における新機能」

• 「ユーザーアカウントとグループとは」

• 「ユーザーアカウントとグループ情報の格納場所」

• 「ユーザーアカウントとグループを管理するツール」

• 「ユーザーの作業環境のカスタマイズ」

ユーザーアカウントとグループの管理手順については、第 5 章ユーザーアカウントとグループの管理 (手順)を参照してください。

ユーザーとグループの管理における新機能

この節では、この Solaris リリースで新たに追加または変更された、ユーザーとグループの管理機能について説明します。

この Solaris リリースで新たに追加または変更された機能はありません。

Solaris の新機能の一覧および Solaris リリースについての説明は、『Solaris 10 の概要』を参照してください。

ユーザーアカウントとグループアカウントの管理用のツール

次の表に、ユーザーアカウントとグループの管理に使用できるツールを示します。

次のツールを使ってグループを追加できます。

Solaris 管理コンソールのグループツール

この Solaris リリースでは Admintool は使用できません。

ユーザーアカウントとグループとは

基本的なシステム管理作業の 1 つに、サイトの各ユーザーにユーザーアカウントを設定することがあります。通常のユーザーアカウントには、ユーザーがスーパーユーザーのパスワードを知らなくても、システムにログインして、システムを使用するのに必要な情報が含まれています。ユーザーアカウント情報の構成要素については、「ユーザーアカウントの構成要素」で説明します。

ユーザーアカウントを設定するときに、ユーザーをあらかじめ定義されたユーザーグループに追加できます。グループは一般に、ファイルまたはディレクトリへのグループアクセス権を設定して、グループ内のユーザーだけがファイルとディレクトリにアクセスできるようにするために使用されます。

たとえば、ごく少数のユーザーだけにアクセスさせたい機密ファイルを入れるディレクトリを作成できます。topsecret プロジェクトに携わるユーザーを含む topsecret という名前のグループを設定します。そして、topsecret ファイルの読み取り権を topsecret グループに対して設定します。こうすれば、topsecret グループ内のユーザーだけが、ファイルを読み取ることができます。

また、「役割」という特別な種類のユーザーアカウントは、指定したユーザーに特別な特権を与えるときに使用します。詳細は、『Solaris のシステム管理 (セキュリティサービス)』の「役割によるアクセス制御 (概要)」を参照してください。

ユーザーアカウントの構成要素

次の節では、ユーザーアカウントのそれぞれの構成要素について説明します。

ユーザー (ログイン) 名

ユーザーは、ユーザー名 (ログイン名とも呼ばれる) を使って、適切なアクセス権を持つ自分のシステムとリモートシステムにアクセスできます。作成するユーザーアカウントそれぞれに、ユーザー名を選択しなければなりません。

ユーザー名を探しやすいように、ユーザー名の標準的な割り当て方法を使用することを検討してください。また、ユーザー名はユーザーが覚えやすいものにしてください。単純な規則の例としては、ユーザーのファーストネームの頭文字とラストネームの最初の 7 文字を使用します。たとえば、Ziggy Ignatz は zignatz になります。ほかのユーザー名と重複する場合は、ユーザーのファーストネームの頭文字、ミドルネームの頭文字、ラストネームの最初の 6 文字を使用します。たとえば、Ziggy Top Ignatz は ztignatz になります。

さらに重複する場合、ユーザー名の作成には次の方法を検討してください。

• ファーストネームの頭文字、ミドルネームの頭文字、ラストネームの最初の 5 文字を使用します

• 固有の名前になるまで 1、2、3 などの数字を使用します

それぞれの新しいユーザー名は、システムまたは NIS や NIS+ のドメインに登録されているメール別名 (エイリアス) とは異なるものでなければなりません。そうしないと、メールは実際のユーザーにではなく別名に送られることがあります。

ユーザー (ログイン) 名の設定方法の詳しいガイドラインについては、「ユーザー名、ユーザー ID、およびグループ ID を使用するガイドライン」を参照してください。

ユーザー ID 番号

ユーザー名に関連するものとして、ユーザー識別 (UID) 番号があります。ユーザーがログインしようとするシステムは、UID 番号によってユーザー名を識別したり、ファイルとディレクトリの所有者を識別したりします。多数の異なるシステム上で、ある個人用にユーザーアカウントを作成する場合は、常に同じユーザー名と ID 番号を使用してください。そうすれば、そのユーザーは、所有権の問題を起こすことなく、システム間で簡単にファイルを移動できます。

UID 番号は、2147483647 以下の整数でなければなりません。UID 番号は、通常のユーザーアカウントと特殊なシステムアカウントに必要です。次の表に、ユーザーアカウントとシステムアカウントに予約されている UID 番号を示します。

0 - 99 の UID 番号を割り当てないでください。これらの UID は、Solaris オペレーティングシステムによる割り当て用として予約されています。システム上の定義により、root には常に UID 0、daemon には UID 1、擬似ユーザー bin には UID 2 が設定されます。また、UID が passwd ファイルの先頭にくるように、uucp ログインや、who、tty、ttytype などの擬似ユーザーログインには低い UID を指定するようにしてください。

UID の設定方法の詳しいガイドラインについては、「ユーザー名、ユーザー ID、およびグループ ID を使用するガイドライン」を参照してください。

ユーザー (ログイン) 名と同様に、固有の UID 番号を割り当てる方法を決めてください。企業によっては、従業員に固有の番号を割り当て、管理者がその従業員番号にある番号を加えて固有の UID 番号を作成している場合もあります。

セキュリティー上のリスクを最小限に抑えるため、削除したアカウントの UID を再利用することは避けてください。 どうしても UID を再利用する必要がある場合、はじめから作りなおして、新しいユーザーが前のユーザーの属性に影響されないようにしてください。たとえば、前のユーザーがプリンタの拒否リストに含まれていたためプリンタにアクセスできなかった場合、その属性を新しいユーザーに適用することが正しいとは限りません。

大きな数値のユーザー ID とグループ ID の使用

UID とグループ ID (GID) には、符号付き整数の最大値 (つまり 2147483647) までの数値を割り当てることができます。

ただし、60000 より大きな数値の UID と GID は機能的に完全でなく、多くの Solaris の機能と互換性がありません。したがって、60000 を超える UID と GID は使わないようにしてください。

次の表では、Solaris の以前のリリースとの相互運用性に関する問題について説明します。

UNIX グループ

「グループ」とは、ファイルやその他のシステム資源を共有できるユーザーの集合のことです。たとえば、同じプロジェクトで作業するユーザーはグループを構成することになります。グループは、従来の UNIX グループのことです。

各グループには、名前、グループ識別 (GID) 番号、およびそのグループに属しているユーザー名のリストが必要です。システムは GID 番号によって内部的にグループを識別します。

ユーザーは次の 2 つの種類のグループに所属できます。

• 一次グループ – オペレーティングシステムが、ユーザーによって作成されたファイルに割り当てるグループです。各ユーザーは、1 つの一次グループに所属していなければなりません。

• 二次グループ – ユーザーが所属する 1 つまたは複数のグループです。ユーザーは、最大 15 個の二次グループに所属できます。

グループ名の設定方法の詳しいガイドラインについては、「ユーザー名、ユーザー ID、およびグループ ID を使用するガイドライン」を参照してください。

ユーザーの二次グループは、場合によっては重要でないことがあります。たとえば、ファイルの所有権は、一次グループだけが反映し、二次グループは反映しません。ただし、アプリケーションによってはユーザーの二次グループが関係することがあります。たとえば、ユーザーは以前の Solaris リリースで Admintool ソフトウェアを使用するとき sysadmin グループ (グループ 14) のメンバーでなければなりませんが、グループ 14 がそのユーザーの現在の一次グループであるかどうかは問題にはなりません。

groups コマンドを使用すると、ユーザーが所属しているグループのリストを表示できます。ユーザーは一度に 1 つの一次グループにしか所属できません。ただし、newgrp コマンドを使用して、ユーザーがメンバーとなっているほかのグループに一時的に一次グループを変更することはできます。

ユーザーアカウントを追加するときは、ユーザーに一次グループを割り当てるか、デフォルトの staff グループ (グループ 10) を使用する必要があります。一次グループは、すでに存在しているものでなければなりません。存在しない場合は、GID 番号でグループを指定します。ユーザー名は、一次グループに追加されません。ユーザー名が一次グループに追加されると、リストが長くなりすぎるからです。ユーザーを新しい二次グループに割り当てる前に、そのグループを作成し、それに GID 番号を割り当てなければなりません。

グループは、システムにとってローカルにすることも、ネームサービスを介して管理することもできます。グループ管理を簡単に行うには、NIS などのネームサービスや LDAP などのディレクトリサービスを使用する必要があります。これらのサービスを使用すると、グループのメンバーを一元管理できます。

ユーザーパスワード

ユーザーを追加するときにそのユーザーのパスワードを指定できます。または、ユーザーが最初にログインするときにパスワードを指定するよう強制できます。

ユーザーのパスワードは、次の構文に準拠している必要があります。

• パスワード長は、/etc/default/passwd ファイル内の PASSLENGTH 変数に指定された値に一致している必要があります。PASSLENGTH にはデフォルトで 6 が設定されています。

• パスワードの最初の 6 文字には、2 文字以上の英字と 1 文字以上の数字または特殊文字を含める必要があります。

• 最大パスワード長を 9 文字以上に増やすには、9 文字以上に対応しているアルゴリズムで /etc/policy.conf ファイルを構成します。

ユーザー名は公表されますが、パスワードを知っているのは各ユーザーだけでなければなりません。各ユーザーアカウントには、パスワードを割り当てる必要があります。パスワードには、6 - 8 文字の英数字と特殊文字を組み合わせることができます。

コンピュータシステムのセキュリティーを強化するには、ユーザーのパスワードを定期的に変更する必要があります。高いレベルのセキュリティーを確保するには、ユーザーに 6 週間ごとにパスワードを変更するよう要求してください。低いレベルのセキュリティーなら、3 ヵ月に 1 度で十分です。システム管理用のログイン (root や sys など) は、毎月変更するか、root のパスワードを知っている人が退職したり交替したりするたびに変更してください。

コンピュータセキュリティーが破られる原因の多くは、正当なユーザーのパスワードが解読される場合です。ユーザーについて何か知っている人が簡単に推測できるような固有名詞、名前、ログイン名、パスワードを使わないよう各ユーザーに対して指示してください。

良いパスワードの例としては次のようなものが考えられます。

• 単語を組み合わせたフレーズ (たとえば、beammeup)。

• フレーズ内の各単語の頭文字だけを集めた、意味のない文字列 。たとえば、SomeWhere Over The RainBow から取った swotrb。

• 文字を数字や記号に代えた単語。たとえば、snoopy から文字を代えた sn00py。

次のものは、パスワードに不適当です。

• 自分の名前そのもの、逆読み、飛ばし読みのもの

• 家族やペットの名前

• 免許証番号

• 電話番号

• 社会保険番号

• 従業員番号

• 趣味や興味に関連した単語

• 季節に関係のある名前 (たとえば 12 月に Santa を使うなど)

• 辞書にある単語

ホームディレクトリ

ホームディレクトリは、ユーザーが独自のファイルを格納するのに割り当てられるファイルシステムの一部分です。ホームディレクトリに割り当てる大きさは、ユーザーが作成するファイルの種類、サイズ、および数によって異なります。

ホームディレクトリは、ユーザーのローカルシステムまたはリモートファイルサーバーのどちらにでも配置できます。どちらの場合も、慣例により、ホームディレクトリは /export/home/username として作成します。大規模なサイトでは、ホームディレクトリをサーバーに格納してください。ホームディレクトリのバックアップおよび復元を簡単にするには、/export/homen ディレクトリごとに別々のファイルシステムを使用してください。たとえば、/export/home1 と /export/home2 を使用します。

ホームディレクトリが配置される場所に関係なく、ユーザーは通常 /home/username という名前のマウントポイントを介してホームディレクトリにアクセスします。Autofs を使用してホームディレクトリがマウントされていると、どのシステムでも /home マウントポイントの下にディレクトリを作成することは許可されません。Autofs が使用されていると、システムはマウントされている /home を特別なものと認識します。ホームディレクトリを自動マウントする方法については、『Solaris のシステム管理 (ネットワークサービス)』の「autofs 管理作業の概要」を参照してください。

ネットワーク上の任意の場所からホームディレクトリを使用するには、/export/home/username ではなく、常に $HOME という環境変数の値によって参照するようにしてください。前者はマシンに固有の指定です。さらに、ユーザーのホームディレクトリで作成されるシンボリックリンクはすべて相対パス (たとえば ../../../x/y/x) を使用する必要があります。こうすることによって、そのリンクはどのシステムにホームディレクトリがマウントされても有効になります。

ネームサービス

大規模サイトのユーザーアカウントを管理する場合は、LDAP、NIS、NIS+ などのネームサービスまたはディレクトリサービスの使用を検討することをお勧めします。ネームサービスまたはディレクトリサービスを使うと、ユーザーアカウント情報を各システムの /etc 内のファイルに格納するのではなく、一元管理できます。ユーザーアカウントにネームサービスまたはディレクトリサービスを使用すると、サイト全体のユーザーアカウント情報をシステムごとにコピーしなくても、同じユーザーアカウントのままシステム間を移動できます。ネームサービスまたはディレクトリサービスを使用すると、ユーザーアカウント情報を集中化および一元化して管理できます。

ユーザーの作業環境

ファイルを作成して格納するホームディレクトリのほかに、ユーザーには仕事をするために必要なツールとリソースにアクセスできる環境が必要です。ユーザーがシステムにログインすると、初期設定ファイルによってユーザーの作業環境が決定されます。これらのファイルは、ユーザーの起動シェルによって定義されます。起動シェルは Solaris リリースによって異なる可能性があります。

ユーザーの作業環境を管理するのに便利な方法として、カスタマイズしたユーザー初期設定ファイル (.login、.cshrc、.profile など) をユーザーのホームディレクトリに置くという方法があります。

システム初期設定ファイル (/etc/profile または /etc/.login) を使用してユーザーの作業環境を管理しないでください。これらのファイルはローカルシステムに存在するため、一元管理されません。たとえば、Autofs を使用してネットワーク上の任意のシステムからユーザーのホームディレクトリをマウントした場合、ユーザーがシステム間を移動しても環境が変わらないよう保証するには、各システムでシステム初期設定ファイルを修正しなければならなくなります。

ユーザー初期設定ファイルをユーザー用にカスタマイズする方法については、「ユーザーの作業環境のカスタマイズ」を参照してください。

また、役割によるアクセス制御 (RBAC) でユーザーアカウントをカスタマイズする方法もあります。詳細は、『Solaris のシステム管理 (セキュリティサービス)』の「役割によるアクセス制御 (概要)」を参照してください。

ユーザー名、ユーザー ID、およびグループ ID を使用するガイドライン

ユーザー名、UID、および GID は、複数のドメインにまたがることもあるユーザーの組織内で一意でなければなりません。

ユーザー名または役割名、UID、および GID を作成するときは、次のガイドラインに従ってください。

• ユーザー名 – 2 - 8 文字の英数字を使用する必要があります。最初の文字は英字でなければならず、少なくとも 1 文字は小文字にする必要があります。

  ---

  注 –

  ユーザー名にはピリオド (.)、下線 (_)、ハイフン (-) を使用できますが、これらの文字により障害が発生するソフトウェアもあるため、使用はお勧めできません。

  ---

• システムアカウント – デフォルトの /etc/passwd および /etc/group ファイルに含まれているユーザー名、UID、または GID を使用しないでください。0 - 99 の UID と GID は使用しないでください。これらの番号は、Solaris オペレーティングシステムによる割り当て用に予約されており、どのユーザーも使用してはいけません。この制限は、現在使用されていない番号にも適用されます。

  たとえば、gdm は GNOME ディスプレイマネージャーデーモン用に予約されたユーザー名とグループ名であるため、ほかのユーザーは使用できません。デフォルトの /etc/passwd と /etc/group のエントリの全リストについては、表 4–5 と表 4–6 を参照してください。

  nobody と nobody4 のアカウントは、プロセスの実行には使用しないでください。これらの 2 つのアカウントは NFS 用に予約されています。これらのアカウントをプロセスの実行に使用すると、予期しないセキュリティー上のリスクにさらされる可能性があります。root 以外のユーザーとして実行する必要があるプロセスでは、daemon または noaccess のアカウントを使用してください。

• システムアカウントの設定 – デフォルトのシステムアカウントの設定は絶対に変更しないでください。この設定には、現在ロックされているシステムアカウントのログインシェルの変更が含まれています。ただし、root アカウントのパスワードとパスワード有効期限のパラメータ設定だけはこの規則に当てはまりません。

ユーザーアカウントとグループ情報の格納場所

ユーザーアカウントとグループ情報は、サイトの方針に応じて、次のようにローカルシステムの /etc ファイル、ネームサービス、またはディレクトリサービスに格納されます。

• NIS+ ネームサービス情報はテーブルに格納されます。

• NIS ネームサービス情報はマップに格納されます。

• LDAP ディレクトリサービス情報はインデックス付きのデータベースファイルに格納されます。

混乱を避けるために、ユーザーアカウントとグループ情報の格納場所は、「データベース」、「テーブル」、「マップ」という 3 種類の呼び方ではなく、単に「ファイル」と呼びます。

ほとんどのユーザーアカウント情報は、passwd ファイルに格納されます。パスワード情報は次のように格納されます。

• NIS または NIS+ を使用するときは passwd ファイルに

• /etc ファイルを使用するときは、/etc/shadow ファイルに

• LDAP を使用するときは、people コンテナに

パスワード有効期限は、NIS+ または LDAP を使用するときは利用できますが、NIS を使用するときは利用できません。

NIS、NIS+、および files の場合、グループ情報は group ファイルに格納されます。LDAP の場合、グループ情報は group コンテナに格納されます。

passwd ファイルのフィールド

passwd ファイルの各フィールドはコロンで区切られ、次のような情報が入っています。

username:password:uid:gid:comment:home-directory:login-shell

次に例を示します。

kryten:x:101:100:Kryten Series 4000 Mechanoid:/export/home/kryten:/bin/csh

passwd ファイルのフィールドの完全な説明については、passwd(1) のマニュアルページを参照してください。

デフォルトの passwd ファイル

Solaris のデフォルトの passwd ファイルには、標準のデーモン用のエントリが入っています。デーモンとは、通常ブート時に起動され、システム全体で有効な操作 (印刷、ネットワーク管理、ポートの監視など) を実行するプロセスのことです。

root:x:0:0:Super-User:/:/sbin/sh
daemon:x:1:1::/:
bin:x:2:2::/usr/bin:
sys:x:3:3::/:
adm:x:4:4:Admin:/var/adm:
lp:x:71:8:Line Printer Admin:/usr/spool/lp:
uucp:x:5:5:uucp Admin:/usr/lib/uucp:
nuucp:x:9:9:uucp Admin:/var/spool/uucppublic:/usr/lib/uucp/uucico
smmsp:x:25:25:SendMail Message Submission Program:/:
listen:x:37:4:Network Admin:/usr/net/nls:
gdm:x:50:50:GDM Reserved UID:/:
webservd:x:80:80:WebServer Reserved UID:/:
postgres:x:90:90:PostgreSQL Reserved UID:/:/usr/bin/pfksh
svctag:x:95:12:Service Tag UID:/:
nobody:x:60001:60001:NFS Anonymous Access User:/:
noaccess:x:60002:60002:No Access User:/:
nobody4:x:65534:65534:SunOS 4.x NFS Anonymous Access User:/:

shadow ファイルのフィールド

shadow ファイルの各フィールドはコロンで区切られ、次のような情報が入っています。

username:password:lastchg:min:max:warn:inactive:expire

次に例を示します。

rimmer:86Kg/MNT/dGu.:8882:0::5:20:8978

shadow ファイルのフィールドの完全な説明については、shadow(4) と crypt(1) のマニュアルページを参照してください。

group ファイルのフィールド

group ファイルの各フィールドはコロンで区切られ、次のような情報が入っています。

group-name:group-password:gid:user-list

次に例を示します。

bin::2:root,bin,daemon

group ファイルのフィールドの完全な説明については、group(4) のマニュアルページを参照してください。

デフォルトの group ファイル

Solaris のデフォルトの group ファイルには、システム全体に有効な操作 (印刷、ネットワーク管理、電子メールなど) をサポートする次のようなシステムグループが記述されています。これらのグループの多くは、passwd ファイルのエントリに対応しています。

root::0:
other::1:root
bin::2:root,daemon
sys::3:root,bin,adm
adm::4:root,daemon
uucp::5:root
mail::6:root
tty::7:root,adm
lp::8:root,adm
nuucp::9:root
staff::10:
daemon::12:root
sysadmin::14:
smmsp::25:
gdm::50:
webservd::80:
postgres::90:
nobody::60001:
noaccess::60002:
nogroup::65534:

ユーザーアカウントとグループを管理するツール

次の表に、ユーザーとグループを管理するための推奨ツールを示します。これらのツールは、Solaris 管理コンソールツール群に含まれています。Solaris 管理コンソールの起動および使用方法については、第 2 章Solaris 管理コンソールの操作 (手順)を参照してください。

これらの作業の実行方法については、Solaris 管理コンソールのオンラインヘルプを参照してください。

ユーザーアカウントとグループの管理に使用できる Solaris コマンドについては、表 1–6 を参照してください。これらのコマンドは、認証およびネームサービスサポートを含め、Solaris 管理ツールと同じ機能を提供します。

Solaris ユーザーおよびグループ管理ツールの作業

Solaris ユーザー管理ツールを使用すると、ローカルシステムまたはネームサービス環境のユーザーアカウントとグループを管理できます。

次の表で、ユーザーツールのユーザーアカウント機能を使って実行可能な作業について説明します。

ユーザーをローカルシステムまたはネームサービスに追加する方法については、「ユーザーアカウントとグループとは」および 「ユーザーアカウントの構成要素」を参照してください。

ユーザーに権限を付与する方法については、『Solaris のシステム管理 (セキュリティサービス)』の「権利プロファイルの内容」を参照してください。

管理役割の使用方法については、『Solaris のシステム管理 (セキュリティサービス)』の「RBAC の実装を計画する方法」を参照してください。

ユーザーをグループに追加する方法については、「UNIX グループ」を参照してください。

メーリングリストの作成方法については、Solaris 管理コンソールのオンラインヘルプを参照してください。

プロジェクトでユーザーおよびリソースを管理する

Solaris 9 リリース以降、ユーザーおよびグループを「プロジェクト」(システム使用率またはリソースアロケーションチャージバックの基礎として使用される、作業負荷の構成要素を示す識別子) のメンバーにすることができます。プロジェクトは、Solaris リソース管理機能の一部で、システムリソースの管理に使用されます。

Solaris 9 リリースを実行するシステムにログインするには、ユーザーはプロジェクトのメンバーになる必要があります。デフォルトでは、ユーザーは Solaris 9 リリースのインストール時に group.staff プロジェクトのメンバーになり、ほかのプロジェクト情報は設定されていません。

ユーザーのプロジェクト情報は、/etc/project ファイルに格納され、このファイルは、ローカルシステム (ファイル)、NIS ネームサービス、または LDAP ディレクトリサービスに保存できます。Solaris 管理コンソールを使用すると、プロジェクト情報を管理できます。

/etc/project ファイルは、ユーザーがログインするために必要ですが、プロジェクトを使用しない場合は管理する必要はありません。

プロジェクトの使用方法および設定方法については、『Solaris のシステム管理 (Solaris コンテナ : 資源管理と Solaris ゾーン)』の第 2 章「プロジェクトとタスク (概要)」を参照してください。

ユーザーの作業環境のカスタマイズ

ユーザーのホームディレクトリの設定には、ユーザーのログインシェルにユーザー初期設定ファイルを提供することも含まれます。ユーザー初期設定ファイルは、ユーザーがシステムにログインしたあとにユーザーのために作業環境を設定するシェルスクリプトです。基本的にシェルスクリプトで行える処理はどれもユーザー初期設定ファイルで実行できます。主に、ユーザーの検索パス、環境変数、ウィンドウ機能の環境など、ユーザーの作業環境を定義します。次の表に示すように、各ログインシェルには、1 つまたは複数の、固有のユーザー初期設定ファイルがあります。

Solaris 環境には、次の表に示すように、各システムの /etc/skel ディレクトリに、各シェル用のデフォルトのユーザー初期設定ファイルが用意されています。

これらのファイルを変更して、すべてのユーザーに共通の作業環境を提供する標準のファイルセットを作成できます。または、異なるタイプのユーザーに作業環境を提供することもできます。ユーザーツールを使って、カスタマイズしたユーザー初期設定ファイルを作成することはできませんが、指定された「スケルトン」ディレクトリ内のユーザー初期設定ファイルでユーザーのホームディレクトリを生成することができます。このためには、ユーザーテンプレートツールを使ってユーザーテンプレートを作成し、コピーするユーザー初期設定ファイルを保存するスケルトンディレクトリを指定します。

異なるタイプのユーザーにユーザー初期設定ファイルを作成する手順については、「ユーザー初期設定ファイルをカスタマイズする方法」を参照してください。

ユーザーツールで新しいユーザーアカウントを作成して、ホームディレクトリを作成するオプションを選択すると、選択したログインシェルに合わせて次のファイルが作成されます。

サイト初期設定ファイルの使用方法

ユーザー初期設定ファイルは、管理者とユーザーの両者によってカスタマイズできます。この重要な機能は、「サイト初期設定ファイル」と呼ばれる、大域的に配布されるユーザー初期設定ファイルによって実現します。サイト初期設定ファイルを使用して、ユーザーの作業環境に新しい機能を絶えず導入でき、しかもユーザーはユーザー初期設定ファイルをカスタマイズすることもできます。

ユーザー初期設定ファイルでサイト初期設定ファイルを参照するとき、サイト初期設定ファイルに対して行なったすべての更新は、ユーザーがシステムにログインするときかユーザーが新しいシェルを起動するとき自動的に反映されます。サイト初期設定ファイルは、ユーザーを追加したときにはなかったサイト全体の変更をユーザーの作業環境に配布するよう設計されています。

ユーザー初期設定ファイルでできるカスタマイズは、サイト初期設定ファイルでも行えます。これらのファイルは通常はサーバー、またはサーバーのグループにあり、ユーザー初期設定ファイルの最初の行に現れます。また、各サイト初期設定ファイルは、それを参照するユーザー初期設定ファイルと同じ型のシェルスクリプトでなければなりません。

C シェルのユーザー初期設定ファイルでサイト初期設定ファイルを参照するには、ユーザー初期設定ファイルの先頭に次のような行を挿入します。

source /net/machine-name/export/site-files/site-init-file

Bourne シェルまたは Korn シェルのユーザー初期設定ファイルでサイト初期設定ファイルを参照するには、ユーザー初期設定ファイルの先頭に次のような行を挿入します。

. /net/machine-name/export/site-files/site-init-file

ローカルシステムへの参照を避ける

ユーザー初期設定ファイルに、ローカルシステムへの個々の参照を追加しないでください。ユーザー初期設定ファイルの設定は、ユーザーがどのシステムにログインしても有効になる必要があります。

次に例を示します。

• ユーザーのホームディレクトリをネットワーク上の任意の位置で利用できるようにするには、常に環境変数の値 $HOME を使用してホームディレクトリを参照してください。たとえば、/export/home/username/bin ではなく $HOME/bin を使用してください。$HOME 変数は、ユーザーが別のシステムにログインする場合でも有効で、その場合ホームディレクトリは自動マウントされます。

• ローカルディスクのファイルにアクセスするには、/net/system-name/directory-name などの大域パス名を使用してください。システムが AutoFS を実行していれば、/net/system-name で参照されるディレクトリはすべてユーザーがログインする任意のシステムに自動的にマウントできます。

シェル機能

次の表に、各シェルの基本的な機能を示します。ユーザー初期設定ファイルを作成するときにどのシェルがどのような機能を提供するか参考にしてください。

シェル環境

シェルは、login プログラム、システム初期設定ファイル、ユーザー初期設定ファイルによって定義される変数を含む環境を管理します。また、一部の変数はデフォルトで定義されます。

シェルには次の 2 種類の変数があります。

• 環境変数 – シェルによって生成されるすべてのプロセスにエクスポートされる変数。環境変数の設定値は env コマンドで表示できます。PATH などを含む環境変数の一部が、シェルそのものの動作に影響を与えます。

• シェル (ローカル) 変数 – 現在使用中のシェルだけに関係する変数。C シェルの場合は、シェル変数は環境変数と特別に対応しています。これらのシェル変数は user、term、home、path です。シェル変数は、対応する環境変数の値によって初期設定されます。

C シェルでは、小文字を使って set コマンドでシェル変数を設定し、大文字を使って setenv コマンドで環境変数を設定します。シェル変数を設定すると、対応する環境変数が設定されます。同様に、環境変数を設定すると、対応するシェル変数も変更されます。たとえば、path シェル変数を新しいパスで更新すると、シェルは PATH 環境変数も新しいパスで更新します。

Bourne、Korn の両シェルでは、任意の大文字の変数名を使って、シェル変数と環境変数の両方を設定できます。その後に実行されるコマンドに対して変数を有効にするためには、export コマンドの実行も必要です。

すべてのシェルで、シェル変数と環境変数は一般的に大文字の名前で参照します。

ユーザー初期設定ファイルでは、ユーザーのシェル環境を、あらかじめ定義された変数の値を変更するか、変数を追加することによってカスタマイズできます。次の表に、ユーザー初期設定ファイルで環境変数を設定する方法を示します。

次の表では、ユーザー初期設定ファイルでカスタマイズできる環境変数とシェル変数について説明します。各シェルで使用される変数の詳細は、 sh(1)、ksh(1)、csh(1) の各マニュアルページを参照してください。

PATH 変数

ユーザーが絶対パス名でコマンドを入力すると、シェルはそのパス名を使ってコマンドを探します。ユーザーがコマンド名しか指定しないと、シェルは PATH 変数で指定されているディレクトリの順でコマンドを探します。コマンドがいずれかのディレクトリで見つかれば、シェルはコマンドを実行します。

デフォルトのパスがシステムで設定されますが、大部分のユーザーはそれを変更してほかのコマンドディレクトリを追加します。環境の設定や、正しいバージョンのコマンドまたはツールへのアクセスに関連して発生するユーザーの問題の多くは、パス定義の誤りが原因です。

パスの設定のガイドライン

次に、効率的な PATH 変数を設定するためのガイドラインをいくつか示します。

• セキュリティーが特に問題とならない場合は、現在の作業ディレクトリ (.) をパスの最初に指定します。しかし、現在の作業ディレクトリをパスに入れると、セキュリティー上の問題となることがあり、特にスーパーユーザーにとって問題となります。

• 検索パスはできるだけ短くしておきます。シェルはパスで各ディレクトリを探します。コマンドが見つからないと、検索に時間がかかり、システムのパフォーマンスが低下します。

• 検索パスは左から右に読まれるため、通常使用するコマンドをパスの初めの方に指定するようにしてください。

• パスでディレクトリが重複していないか確認してください。

• 可能であれば、大きなディレクトリの検索は避けてください。大きなディレクトリはパスの終わりに指定します。

• NFS サーバーが応答しないときに「ハング」の可能性が小さくなるように、NFS がマウントするディレクトリより前にローカルディレクトリを指定します。この方法によって、不要なネットワークトラフィックも減少します。

ユーザーのデフォルトパスの設定

次の例は、ユーザーのデフォルトパスを設定する方法を示しています。

次の例は、ユーザーのデフォルトパスがホームディレクトリとほかの NFS マウントディレクトリを含むように設定する方法を示しています。現在の作業ディレクトリはパスの最初に指定されます。C シェルユーザー初期設定ファイルでは、次の行を追加してください。

set path=(. /usr/bin $HOME/bin /net/glrr/files1/bin)

Bourne シェルまたは Korn シェルユーザー初期設定ファイルでは、次の行を追加してください。

PATH=.:/usr/bin:/$HOME/bin:/net/glrr/files1/bin
export PATH

ロケール変数

LANG と LC の各環境変数は、ロケール固有の変換と表記をシェルに指定します。指定できる変換と表記には、時間帯や照合順序、および日付、時間、通貨、番号の書式などがあります。さらに、ユーザー初期設定ファイルで stty コマンドを使って、端末のセッションが複数バイト文字をサポートするかどうかを指定できます。

LANG 変数は、ロケールのすべての変換と表記を設定します。ロケールの各種の設定を個別に行うには、次の LC 変数を使用します。 LC_COLLATE、LC_CTYPE、LC_MESSAGES、LC_NUMERIC、LC_MONETARY、および LC_TIME です。

次の表に、LANG と LC 環境変数の値の一部を示します。

サポートされるロケールの詳細については、『国際化対応言語環境の利用ガイド』を参照してください。

例 4–1 LANG 変数によるロケールの設定

次の例は、LANG 環境変数を使ってロケールを設定する方法を示しています。C シェルユーザー初期設定ファイルでは、次の行を追加してください。

setenv LANG de_DE.ISO8859-1

Bourne シェルまたは Korn シェルユーザー初期設定ファイルでは、次の行を追加してください。

LANG=de_DE.ISO8859-1; export LANG

デフォルトのファイルアクセス権 (umask)

ファイルまたはディレクトリを作成したときに設定されるデフォルトのファイルアクセス権は、「ユーザーマスク」によって制御されます。ユーザーマスクは、初期設定ファイルで umask コマンドによって設定されます。現在のユーザーマスクの値は、umask と入力して Return キーを押すと表示できます。

ユーザーマスクは、次の 8 進値で構成されます。

• 最初の桁でそのユーザーのアクセス権を設定する

• 2 桁目でグループのアクセス権を設定する

• 3 桁目でその他 (「ワールド」とも呼ばれる) のアクセス権を設定する

最初の桁がゼロの場合、その桁は表示されません。たとえば、ユーザーマスクを 022 に設定すると、22 が表示されます。

設定する umask の値は、与えたいアクセス権の値を 666 (ファイルの場合) または 777 (ディレクトリの場合) から引きます。引いた残りが umask に使用する値です。たとえば、ファイルのデフォルトモードを 644 (rw-r--r--) に変更するとします。このとき 666 と 644 の差 022 が umask コマンドの引数として使用する値です。

また、次の表から umask 値を決めることもできます。この表は、umask の各 8 進値から作成される、ファイルとディレクトリのアクセス権を示しています。

次の例は、デフォルトのファイルアクセス権を rw-rw-rw- に設定します。

umask 000

ユーザー初期設定ファイルとサイト初期設定ファイルの例

ここでは、ユーザー自身の初期設定ファイルのカスタマイズを始める際に使用するユーザー初期設定ファイルとサイト初期設定ファイルの例を示します。例の中のシステム名やパス名は、実際のサイトに合わせて置き換えてください。

例 4–2 .profile ファイル

(Line 1) PATH=$PATH:$HOME/bin:/usr/local/bin:/usr/ccs/bin:. 
(Line 2) MAIL=/var/mail/$LOGNAME 
(Line 3) NNTPSERVER=server1 
(Line 4) MANPATH=/usr/share/man:/usr/local/man 
(Line 5) PRINTER=printer1 
(Line 6) umask 022 
(Line 7) export PATH MAIL NNTPSERVER MANPATH PRINTER

1. ユーザーのシェル検索パスを設定する

2. ユーザーのメールファイルへの検索パスを設定する

3. ユーザーの Usenet ニュースサーバーを設定する

4. マニュアルページへのユーザーの検索パスを設定する

5. ユーザーのデフォルトプリンタを設定する

6. ユーザーのデフォルトのファイル作成アクセス権を設定する

7. 指定された環境変数をエクスポートする

例 4–3 .cshrc ファイル

(Line 1) set path=($PATH $HOME/bin /usr/local/bin /usr/ccs/bin)
(Line 2) setenv MAIL /var/mail/$LOGNAME 
(Line 3) setenv NNTPSERVER server1 
(Line 4) setenv PRINTER printer1 
(Line 5) alias h history 
(Line 6) umask 022 
(Line 7) source /net/server2/site-init-files/site.login 

1. ユーザーのシェル検索パスを設定する

2. ユーザーのメールファイルへの検索パスを設定する

3. ユーザーの Usenet ニュースサーバーを設定する

4. ユーザーのデフォルトプリンタを設定する

5. history コマンドの別名を作成する。これにより、h と入力するだけで history コマンドを実行できる

6. ユーザーのデフォルトのファイル作成アクセス権を設定する

7. 指定されたサイト初期設定ファイルを読み込む

例 4–4 サイト初期設定ファイル

次のサイト初期設定ファイルの例では、ユーザーは特定のバージョンのアプリケーションを選択できます。

# @(#)site.login
main: 
echo "Application Environment Selection"
echo ""
echo "1. Application, Version 1"
echo "2. Application, Version 2"
echo "" 
echo -n "Type 1 or 2 and press Return to set your 
application environment: " 

set choice = $<	

if ( $choice !~ [1-2] ) then 
goto main 
endif 

switch ($choice) 

case "1": 
setenv APPHOME /opt/app-v.1 
breaksw 

case "2": 
setenv APPHOME /opt/app-v.2 
endsw

次のようにして、このサイト初期設定ファイルをユーザーの .cshrc ファイル (C シェルユーザーのみ使用可能) で参照させることができます。

source /net/server2/site-init-files/site.login

この行では、サイト初期設定ファイルは site.login という名前で、server2 という名前のサーバー上にあります。また、自動マウンタがユーザーのシステムで実行されていることを前提としています。