diff --git a/ja_JP.eucJP/books/handbook/book.sgml b/ja_JP.eucJP/books/handbook/book.sgml index 474e07dc98..6354bde1c7 100644 --- a/ja_JP.eucJP/books/handbook/book.sgml +++ b/ja_JP.eucJP/books/handbook/book.sgml @@ -1,161 +1,161 @@ %man; %bookinfo; %chapters; %authors; %jauthors; %mailing-lists; %newsgroups; ]> FreeBSD ハンドブック FreeBSD ドキュメンテーションプロジェクト
doc@FreeBSD.org
1999 年 2 月 1995 1996 1997 1998 1999 2000 The FreeBSD Documentation Project &bookinfo.legalnotice; FreeBSD へようこそ! このハンドブックは FreeBSD Release &rel.current; のインストールおよび, 日常での使い方について記述したものです. 本ハンドブックは改編作業中であり, さまざまな人々が編集に携わっています. 多くのセクションはまだ存在しませんし, いま存在するセクションにも更新作業の必要があるものも含まれています. もし, このハンドブックを編集するプロジェクトに協力したいとお考えなら, &a.doc; まで電子メールを(英語で)送ってください. この文書の最新バージョンは, いつでも 日本国内版 FreeBSD World Wide Web サーバ および FreeBSD World Wide Web サーバ で入手することができます. また, 他のさまざまな文書形式, 圧縮形式のものが FreeBSD FTP サーバや数多くのミラーサイトからダウンロードすること ができます. ハンドブックの検索を行なうこと可能です. 日本語版の作成は FreeBSD 日本語ドキュメンテーションプロジェクト(FreeBSD doc-jp)がおこなっています. 日本語訳および, 日本語版のみに関することは FreeBSD &a.jp.doc-jp; において日本語で議論されています. 文書の日本語訳に関するお問い合わせや, 文書の原文に関する問い合わせをしたいが英語が得意でないという方は FreeBSD &a.jp.doc-jp; まで, 日本語でコメントをお寄せください. 導入 &chap.introduction; &chap.install; &chap.basics; &chap.ports; システム管理 - - + &chap.boot; + &chap.users; &chap.kernelconfig; &chap.security; &chap.printing; &chap.disks; &chap.backups; &chap.quotas; &chap.x11; &chap.l10n; ネットワーク通信 &chap.serialcomms; &chap.ppp-and-slip; &chap.advanced-networking; &chap.mail; さらに進んだ話題 &chap.cutting-edge; &chap.contrib; &chap.policies; &chap.kernelopts; &chap.kerneldebug; &chap.linuxemu; &chap.internals; 付録 &chap.mirrors; &chap.bibliography; &chap.eresources; &chap.staff; &chap.pgpkeys; &chap.hw; &chap.jcontrib; diff --git a/ja_JP.eucJP/books/handbook/boot/chapter.sgml b/ja_JP.eucJP/books/handbook/boot/chapter.sgml new file mode 100644 index 0000000000..cf2275d3db --- /dev/null +++ b/ja_JP.eucJP/books/handbook/boot/chapter.sgml @@ -0,0 +1,569 @@ + + + + FreeBSD の起動のプロセス + + + 概要 + + FreeBSD は通常, 起動(bootstrap)を三段階に分けて行ないます. + これには基本的に, 互いに順番に呼び出される三つのプログラム(二つの + 起動ブロック(boot block)と + ローダ(loader))が使われています. + これらのプログラムはそれぞれ, + その前に呼び出されるプログラムの情報に基づいて動作し, + より洗練された機能を提供します. + + デバイスの検出と初期化が終わると, カーネルが起動されます. + そしてカーネルの起動が終わると, 制御はユーザープロセスの + &man.init.8; へ移されます. &man.init.8; はまず + ディスクが利用可能であることを確かめ, + ファイルシステムのマウント, + ネットワークで利用するネットワークカードのセットアップ, + そして通常 FreeBSD システムで初期時に起動されるすべてのプロセスの起動, + といったユーザーレベルでのリソース(資源)設定を行ないます. + + + + 起動ブロック: 起動ステージ 1 および 2 + + 起動(bootstrap)とは, + コンピュータが接続されたデバイスを検出, 初期化し, + 必要となるプログラムを動作させることを指します. + + 起動には起動の際の動作が記録された, + 特殊な読み出し専用メモリチップを利用します. + その動作は通常, + メモリテストやデバイスの設定を行なう他のチップに制御を渡し, + そして設定された内容をプログラムに提供するというものです. + + 標準的な個人向けコンピュータでは, + BIOS と呼ばれる起動を行なう部分と, + CMOS と呼ばれる, 設定を記録する部分によって起動が実現されています. + これらはディスクが存在すること, + そしてオペレーティングシステムをロードするためのプログラムが + ディスク上のどこにあるのかを認識しています. + + この章では上に述べたような起動の初期の過程については扱いません. + 焦点を合わせるのは, + ディスク上のプログラムに制御が移された後の内容についてです. + + 起動ブロックは(通常), ローダを見つけて実行する役割を持っています. + したがって, ファイルシステム上のプログラムを見つけること, + 実行できること, + そしてその動作に関して最低限の設定が可能である必要があります. + + + boot0 + + まず実際に最初にあるのは boot0 と呼ばれる起動ブロックです. + これは マスターブートレコード(MBR; Master Boot + Record) という, + システムが起動時にプログラムを検索するディスク上の特殊な部分に存在します. + この部分は, 単に起動可能なスライスのリストが格納されています. + + boot0 は非常に単純なプログラムです. + これは, MBR にあるプログラムは + 512 バイトの大きさでなければならないという制限があるためです. + + boot0 は, 下のような出力をします. + + + boot0 のスクリーンショット + + +F1 DOS +F2 FreeBSD +F3 Linux +F4 ?? +F5 Drive 1 + +Default: F2 + + + + + boot1 + + boot1 は起動スライス(slice)の起動セクタにあります. + 起動セクタは boot0 が存在し, + MBR にある他のプログラムが + 起動のプロセスを続けるために必要なプログラムを探す部分です. + + boot1 も非常に単純なプログラムです. + これは boot0 同様に, + 512 バイトの大きさでなければならないという制限があるためです. + boot1 は boot2 を検索し, + 実行するため, そのスライスの情報を保持する FreeBSD + のディスクラベル(disklabel) + に関する最低限の情報を持っています. + + + + boot2 + + boot2 はもう少し高機能です. + これは FreeBSDのファイルシステム上でファイルを見つける能力を持ち, + 実行するカーネルやローダを指定するための簡単なインターフェイスを提供する事ができます. + + ローダ(loader)はさらに高機能なもので, + 使いやすく簡単な起動設定が行なえる手段を提供します. + boot2 は通常それを起動します. 以前の boot2 は, + カーネルを直接起動する機能しかありませんでした. + + + boot2 のスクリーンショット + + >> FreeBSD/i386 BOOT +Default: 0:wd(0,a)/kernel +boot: + + + + + + ローダ(loader): 起動ステージ 3 + + ローダは三段階の起動プロセスの最終段階です. + ローダは通常, ファイルシステム上の + /boot/loader + として存在しています. + + + /boot/boot0, + /boot/boot1, + /boot/boot2 というファイルがありますが, + これらは MBR, + 起動セクタ, ディスクラベルの実際のコピーではありません. + + + ローダは, よりさまざまなコマンド群をサポートした + 強力なインタープリタによって提供される簡易組み込みコマンド群を利用することで, + ユーザが利用しやすい設定手段となるように設計されています. + + + ローダプログラムの処理の流れ + + ローダは初期化の際にコンソールとディスクの検出を行ない, + どのディスクから起動しているかを調べます. + そして必要な変数を設定してからインタープリタを起動し, + 簡易コマンドを解釈します. + + ローダは次に + /boot/loader.rc + を読み込み, 通常, 変数の標準値を定義した + /boot/defaults/loader.conf + と, そのマシンにローカルな変数を定義した + /boot/loader.conf + を読み込みます. + loader.rc + はそれらの変数にもとづき, + 選択されたモジュールとカーネルをロードします. + + ローダは最後に, 標準設定で 10 秒のキー入力待ち時間を用意し, + 入力がなければカーネルを起動します. + 入力があった場合, 簡易コマンド群が使えるプロンプトが表示され, + ユーザは変数を調整したり, + すべてのモジュールをアンロードしたり, + モジュールをロードしたりすることができます. + その後, 最終的な起動や再起動へ移行します. + + この処理に関するより技術的な説明は + &man.loader.8; にあります. + + + + ローダの組み込みコマンド + + 簡易コマンド群は, 次のようなもので構成されています. + + + + autoboot seconds + + + seconds + で与えられた時間内に入力がなければ, + カーネルの起動へと進みます. + カウントダウンを表示し, 標準設定では 10 秒間です. + + + + + boot + -options + kernelname + + + すぐにカーネルの起動へ進みます. + オプション, カーネル名が指定されている場合は, + それらが使われます. + + + + + boot-conf + + + すべてのモジュールの設定を, + 起動時と同じように変数にもとづいて自動的に行ないます. + このコマンドは, まず unload を行なって, + 変数—普通 kernel + など—を変更した場合にのみ有効に働きます. + + + + + help + topic + + + /boot/loader.help + を読み込み, ヘルプメッセージを表示します. + topic に + index 指定された場合, + 利用可能な topic を表示します. + + + + + include filename + … + + + 指定されたファイル名のファイルを処理します. + ローダはファイルを読み込み, 行単位で解釈します. + エラーが発生した場合, + include コマンドの実行はその時点で停止します. + + + + + load + type + filename + + + 指定されたファイル名のカーネル, + カーネルモジュール, あるいは + type に指定された種類のファイルをロードします. + ファイル名以降に指定された引数はファイルへと渡されます. + + + + + ls + path + + + 指定された path + にあるファイルを表示します. + path + が指定されていなければ, ルートディレクトリを表示します. + + が指定されていればファイルサイズも表示されます. + + + + + lsdev + + + モジュールがロード可能なすべてのデバイスを表示します. + もし が指定されていれば, + より詳細な出力がされます. + + + + + lsmod + + + ロード済みのモジュールを表示します. + が指定されていれば, + より詳細な内容が出力されます. + + + + + more filename + + + LINES + 単位でスクロールを停止しながら指定されたファイルを表示します. + + + + + reboot + + + すぐにシステムを再起動します. + + + + + set variable + set + variable=value + + + ローダの環境変数を設定します. + + + + + unload + + + すべてのロード済みモジュールを削除します. + + + + + + + ローダの使用例 + + 次にあげるのは, ローダの実践的な使用例です. + + + + 普段使っているカーネルをシングルユーザモードで起動します. + + boot -s + + + + 普段使っているカーネルとモジュールをアンロードし, + 古い(もしくは別の)カーネルをロードします. + + unload + load kernel.old + + kernel.GENERIC とすると, + インストールディスクに入っていた + generic カーネルを指定することができます. + また, 直前にインストールされていたカーネル(たとえば, + カーネルを自分で設定したり, + アップグレードしたりした場合)を指定するには + kernel.old とします. + + + 普段のカーネルで使っているモジュールを + 指定したカーネルでロードする場合は, 下のようにします. + + unload +set kernel="kernel.old" +boot-conf + + + + + カーネルの設定スクリプト(通常, + カーネル起動時に設定される内容を自動化するスクリプト)をロードします. + + load -t userconfig_script + /boot/kernel.conf + + + + + + + カーネル起動時の応答 + + カーネルがローダ(通常は) + かboot2 + (ローダを迂回して)によってロードされると, + 起動フラグを調べます. + もし起動フラグがあれば, それに応じて動作を調整します. + + + カーネル起動フラグ + + 良く使われる起動フラグは次のとおりです. + + + + + + + カーネル初期化中に, + ルートファイルシステムとしてマウントするデバイスを尋ねます. + + + + + + + + CDROM から起動します. + + + + + + + + 起動時にカーネルコンフィグレーションを行なう + UserConfig を実行します. + + + + + + + + シングルユーザモードで起動します. + + + + + + + + カーネル起動時により詳細な情報を表示します. + + + + + + 起動フラグはこの他にもあります. + それらについては &man.boot.8; を参照してください. + + + + + + + + + Init: プロセス制御の初期化 + + カーネルの起動が完了すると, init + というユーザプロセスに制御が移されます. + これは /sbin/init, + もしくは loader の + init_path 変数で指定される場所にあります. + + + 自動再起動(automatic reboot)の動作 + + 自動再起動では, + システム上で利用できるファイルシステムの一慣性を確認します. + もしそれに問題があって fsck がその不一致を修復できなければ, + 管理者に直接に処置させるため init + はシステムをシングルユーザモードへと移行させます. + + + + シングルユーザモード + + このモードには, + 自動再起動の処理中か, + ユーザが起動時に を指定た場合, + あるいは loader で + boot_single 変数を設定することによって移行します. + + また, + マルチユーザモードから + 再起動オプション() + や停止(halt)オプション()なしで + shutdown を呼び出すとこのモードに移行します. + + /etc/ttys + でシステムコンソール console + が insecure に設定されている場合, + システムはシングルユーザモードに移行する前に + root のパスワードを入力するように求めます. + + + /etc/ttys の insecure コンソール + + # name getty type status comments +# +# This entry needed for asking password when init goes to single-user mode +# If you want to be asked for password, change "secure" to "insecure" here +# +# 訳) このエントリは init がシングルユーザモードへ移行する際にパスワードを要 +# 求させるために必要です. もし, パスワードの要求を望む場合, ここの "secure" を +# "insecure" へ変更してください. +# +console none unknown off insecure + + + + insecure コンソールとは, + あなた自身, コンソールが物理的に安全でないと考えていて, + root パスワードを知る人だけがシングルユーザモードを使えるようにしたいという意味であり, + コンソールを安全でない状態で使いたいという意味ではありません. + そのため, 安全性を求めるならば + secure でなく + insecure を選んでください. + + + + + マルチユーザモード + + init がファイルシステムが正常であると判断するか, + ユーザがシングルユーザモードを終了すると, + システムはマルチユーザモードへ移行し, + リソースの設定を始めます. + + + リソース設定(rc) + + リソース設定システムはデフォルト設定を + /etc/defaults/rc.conf から, + そのシステム独自の細かな設定を + /etc/rc.conf から読み込みます. + そして /etc/fstab + に記述されるシステムファイルシステムをマウントし, + ネットワークサービスの開始, + さまざまなシステムデーモンの開始, + そして最後に, ローカルにインストールされた package + の起動スクリプトの実行へと進みます. + + リソース設定システムのに関する参考資料は, &man.rc.8; にあります. + これはスクリプトそのものを調べることと同じくらい優れたものです. + + + + + + シャットダウン動作 + + shutdown + を用いてシステムを意図的にシャットダウンした場合, + init は + /etc/rc.shutdown + というスクリプトの実行を試みます. + そして, すべてのプロセスへ終了(terminate)シグナルを送り, + 続いてうまく終了できなかったプロセスへ + 強制終了(kill)シグナルを送ります. + + + + + diff --git a/ja_JP.eucJP/books/handbook/chapters.ent b/ja_JP.eucJP/books/handbook/chapters.ent index 8c608c08bb..d363c08bca 100644 --- a/ja_JP.eucJP/books/handbook/chapters.ent +++ b/ja_JP.eucJP/books/handbook/chapters.ent @@ -1,54 +1,56 @@ + + diff --git a/ja_JP.eucJP/books/handbook/internals/chapter.sgml b/ja_JP.eucJP/books/handbook/internals/chapter.sgml index f0e579f281..5ddb989c7f 100644 --- a/ja_JP.eucJP/books/handbook/internals/chapter.sgml +++ b/ja_JP.eucJP/books/handbook/internals/chapter.sgml @@ -1,2433 +1,1809 @@ FreeBSD の内部 - - - FreeBSDのブート処理の流れ - - - はじめに - - - ブートストラップ(bootstrap) とは, - コンピュータがデバイスのプローブと初期化および, - どのプログラムを実行させるべきであるかを判断する一連の処理のことです. - - - - これはシステムの動作を決定する特殊な ROM チップを利用して実現され, - 通常, システムの一慣性とメモリの検査, デバイスの設定, - どのような設定がなされたかをプログラムに伝える機構の提供などをを行なう - 他のチップに処理が渡されます. - - - - 通常のパーソナルコンピュータの場合, - ブートストラップの監視をする - BIOS と, 設定を保持する CMOS が利用されます. - これらはディスクを扱う事ができ, - オペレーティングシステムを起動するプログラムが, - ディスクのどこにあるかを認識しています. - - - - この章はブートストラップの第一段階については触れず, - ディスク上のプログラムへ制御が移された後に何が起こるのかについて注目します. - - - - - ブートプロセスの概要 - - - FreeBSD はデフォルトで三段階のブートストラップを行ないます. - 基本的に順に互いを呼び出す三つのプログラム(二つの - ブートブロックと - ローダ)を必要とします. - これらは前のプログラムを土台にしており, - より高い洗練性を提供します. - - - - そして, 利用するデバイスの検出され, - 初期化の間にカーネルが起動されます. - カーネルのブートプロセスが終ると, - 制御はユーザープロセスの init へ移されます. - ディスクが利用可能であることを確かめると, - ファイルシステムのマウント, - ネットワークで利用するネットワークカードのセットアップ, - そして一般的な FreeBSD - システムで初期時に起動される, - すべてのプロセスの起動といったユーザーレベルでのリソース設定を行ないます. - - - - - ブートブロック: ブートストラップステージ 1 と 2 - - - ブートブロックは(通常)ローダを見つけ, - 実行する役割を持っています. - したがって, ファイルシステム上のプログラムを見つけ, 実行し, - その動作に関して多少の設定が可能である必要があります. - - - - boot0 - - - 実際には boot0 と呼ばれるブートブロックが先行しており, - マスターブートレコード(MBR; Master Boot - Record)にあります. これは, - システムのブートストラップが起動時に探して実行するディスクの特殊な部分で, - 単にブートできる可能性のあるスライスのリストを表示します. - - - - MBR - に置くプログラムは 512 バイト以上にできないことから - boot0 はとても単純です. - - - - こんな感じの出力をします. - - - - boot0のスクリーンショット - - -F1 DOS -F2 FreeBSD -F3 Linux -F4 ?? -F5 Drive 1 - -Default: F2 - - - - - boot1 - - - boot1 はブートスライスのブートセクタにあります. - ブートセクタには boot0 があり, - MBR にある他のすべてのプログラムが, - ブートプロセスを続けるために必要なプログラムを探し, - 実行するための部分となっています. - - - - boot1 も同様に 512 バイト以上にできないことから, - とても単純で, - boot2 を見つけ, - 実行するための情報を保持する FreeBSD の - disklabel - について最低限のことを認識しているに過ぎません. - - - - - boot2 - - - boot2 はもう少し精巧で, - FreeBSDのファイルシステム上でファイルを見つけるのに十分な能力を持ち, - カーネルかローダを指定するための簡単なインターフェイスを提供する事ができます. - - - - ローダははるかに高機能あり, - 簡易的なブート設定の手段を提供するため, - boot2 は通常それを起動します. - しかし, 以前はカーネルを直接起動することを要求されていました. - - - - boot2のスクリーンショット - - >> FreeBSD/i386 BOOT -Default: 0:wd(0,a)/kernel -boot: - - - - - - ローダ: ブートストラップステージ 3 - - - ローダは三段階ブートストラップの最終段階で, - 通常, ファイルシステム上に /boot/loader - として存在します. - - - - - /boot/boot0, - /boot/boot1, - /boot/boot2 とがありますが, - これらは実際に MBR, - ブートセクタ, - あるいはディスクラベルにあるものとは異なります. - - - - - ローダは, - より複雑なコマンド群を持つ強力なインタープリタを使った - 簡易組み込みコマンド群を利用することで, - ユーザフレンドリな設定の手段となるように設計されています. - - - - ローダプログラムの流れ - - - 初期化の際, - ローダはコンソールとディスクの検出を行ない, - どのディスクからブートしているかを調べます. - そしてしかるべき変数を設定してからインタープリタを起動し, - 簡易コマンドを解釈します. - - - - ローダは次に - /boot/loader.rc - を読み込みます. デフォルトで - /boot/defaults/loader.conf - を読み込むことで適当な初期値を変数に与え, - ローカルな変数値設定のために - /boot/loader.conf - を読み込みます. - loader.rc - はそれらの変数に従い適当なモジュールをロードしカーネルを選択します. - - - - 最後に, デフォルトではローダは 10 秒のキー入力待ち時間を用意し, - 入力がなければカーネルを起動します. - 入力があった場合, - ユーザには先に述べた簡易コマンドが使えるプロンプトが出されます. - そこでユーザは変数を調整したり, - すべてのモジュールをアンロードしたり, - モジュールをロードしたりすることができ, - それから最終的にブートやリブートへ移ります. - - - - この処理に関するより技術的な説明は - &man.loader.8; にあります. - - - - - ローダの組み込みコマンド - - 簡易コマンドセットの構成は, 次のようになっています. - - - - autoboot seconds - - - - seconds - で与えられた時間内に入力がなければ, - カーネルのブートへと進みます. - カウントダウンを表示し, デフォルトは 10 秒間です. - - - - - - boot - -options - kernelname - - - - 即座にカーネルのブートへと進みます. - もし指定されていれば, - 与えられたオプションとカーネルの名前を使います. - - - - - - help - topic - - - - /boot/loader.help - から読み込まれたヘルプメセッジを表示します. - 与えられた topic が - index ならば, - 有効な - topic - を表示します. - - - - - - include filename - … - - - - 与えられたファイル名のファイルを処理します. - ファイルは読み込まれ, 行単位で解釈されます. - エラーは即座に include コマンドの実行を停止します. - - - - - - load - type - filename - - - - 与えられたファイル名のカーネル, カーネルモジュール, - あるいは指定されたtypeのファイルをロードします. - ファイル名以降の引数はファイルへと渡されます. - - - - - ls - path - - - - 与えられた path にあるファイル, - あるいは path - が指定されていなければルートディレクトリを表示します. - - が指定されていればファイルサイズも表示されます. - - - - - lsdev - - - - モジュールをロード可能なデバイスをすべて表示します. - もし が指定されていれば, - より詳細な出力がされます. - - - - - - lsmod - - - - ロードされたモジュールを表示します. もし - が指定されていれば, - より詳細な内容が出力されます. - - - - - - more filename - - - - LINES - 毎に停止しながら指定されたファイルを表示します. - - - - - - reboot - - - 即座にシステムをリブートします. - - - - - set variable - set - variable=value - - - ローダの環境変数を設定します. - - - - - - ローダの例 - - - ローダのいくつかの実践的な使用例です. - - - - - - 通常のカーネルをシングルユーザモードでブートします. - - - boot -s - - - - - 通常のカーネルとモジュールをアンロードし, - 古い(もしくは別の)カーネルをロードします. - - - unload -load kernel.old - - - インストールディスクに入っていた - generic カーネルを参照するためには - kernel.GENERIC, - あるいは直前にインストールされていたカーネル(例えば, - カーネルを自分で設定したり, - アップグレードしたりして)を参照するには - kernel.old - が使えます. - - - - - - カーネルの設定スクリプト(通常, - カーネルブート時に設定される内容を自動化するスクリプト)をロードします. - - - load -t userconfig_script - /boot/kernel.conf - - - - - - - ブート時のカーネルとの応答 - - - カーネルはローダ(通常は) - かboot2 - (ローダを迂回して)によってロードされるとブートフラグを調べ, - もしあればそれに応じて動作を調整します. - - - - カーネルブートフラグ - - 良く使われるブートフラグです. - - - - - - - - カーネル初期化中, - ルートファイルシステムとしてマウントするデバイスを尋ねます. - - - - - - - - - CDROM からブートします. - - - - - - - - - ブート時のカーネルコンフィグレーションを行なう - UserConfig を実行します. - - - - - - - - - シングルユーザモードでブートします. - - - - - - - - カーネル起動時に, より詳細な情報を表示します. - - - - - - ブートフラグはこの他にもあり, それらについては - &man.boot.8;をお読みください. - - - - - - - - - Init: プロセスコントロールの初期化 - - - カーネルがブートされると, 制御はユーザプロセスである - initへ移されます. これは, - /sbin/init, もしくは - loader の - init_path 変数で指定される場所にあります. - - - - 自動リブート動作の流れ - - - 自動リブート動作では, - システム上で利用できるファイルシステムの一慣性を確認します. - もし問題があり, - fsck がその不一致を修復できなければ, - init - は管理者に直接に処置させるため, - システムをシングルユーザモードへと移行させます. - - - - - シングルユーザモード - - - このモードには一連の自動リブート動作, - もしくはユーザが - - を指定してブートするか - loader で - boot_single 変数を設定することによって移行できます. - - - - マルチユーザモードから - shutdownをリブートオプション - () や halt - オプション()なしで呼び出すことでも移行できます. - - - - /etc/ttys - でシステムコンソール - console - が - insecure - に設定されていれば, - システムはシングルユーザモードを始める前に - root - パスワードの入力を求めます. - - - - /etc/ttys の insecure コンソール - - # name getty type status comments -# -# This entry needed for asking password when init goes to single-user mode -# If you want to be asked for password, change "secure" to "insecure" here -# -# 訳) -# このエントリはinitがシングルユーザモードへ移行する際にパスワードを要 -# 求させるために必要です. もし, パスワードの要求を望むならば"secure"を -# "insecure"へとここで変更してください. -console none unknown off insecure - - - - - insecure コンソールとは, - コンソールが物理的に安全でないと見なされ, - root パスワードを知る人だけがシングルユーザモードを使えるようにするという意味であり, - コンソールを安全でない状態で使いたいという意味ではありません. - よって, 安全性を求めるならば - secure でなく - insecure を選んでください. - - - - - - マルチユーザモード - - - init - がファイルシステムが正常であると判断するか, - ユーザがシングルユーザモードを終了したならば, - システムはマルチユーザモードへ移行し, - リソースの設定を始めます. - - - - リソース設定(rc) - - - リソース設定システムはデフォルト設定を - /etc/defaults/rc.conf から, - システム独自の詳細を - /etc/rc.conf から読み込み, - /etc/fstab - に記述されるシステムファイルシステムのマウント, - ネットワークサービスの開始, - さまざまなシステムデーモンの開始, - そして最後にローカルにインストールされたパッケージの起動スクリプトの実行へと進みます. - - - - &man.rc.8; は, - スクリプトそのものについて調べることと同様に, - リソース設定システムの優れた参考資料です. - - - - - - - シャットダウン動作の流れ - - - shutdown からのシャットダウンでは, - init がスクリプト - /etc/rc.shutdown の実行を試みます. - そして, 全てのプロセスへ terminate シグナルを送り, - 続いてうまく終了できなかったプロセスへ - kill シグナルを送ります. - - - - PC におけるメモリの利用 - 原作: &a.joerg;. - 16 Apr 1995. + 原作: &a.joerg;. 1995 年 4 月 16 日. - 訳: &a.jp.tomo;. - 29 Oct 1996. + 訳: &a.jp.tomo;. 1996 年 10 月 29 日. FreeBSD が i386 - プラットフォーム上でどのようにメモリを使うかに - ついての説明です. + プラットフォーム上でどのようにメモリを使うかに + ついての説明です. ブート部分は0:0x7c00にロードされ, すぐに自分自身を 0x7c0:0に移します. (これは手品ではなく, 単なる%cs セレクタのための調節であり, ljmpにより行われます. ) それから最初の 15 セクタを 0x10000 (biosboot の Makefile のなかの BOOTSEG部分)にロードし, 作業領域のスタックを 0x1fff0以下に セットします. このあと, boot2 に飛びます. つまり, boot1 自身と (ダミーの) DOS パーティションテーブルを飛び越えて, %csセレクタを 調節します — この時点ではまだ16ビットモードです. boot2 はブートファイルを要求し, a.outヘッダを調べます. 0x00ffffffによってファイルエントリポイントを (通常は0xf0100000に)マスクし, ロードします. このため, 通常のロードポイントは 1MB (0x00100000) になります. ロードしている間, リアルモードでBIOSを使うため, ブートコードは, リアルモードとプロテクトモードの間を行ったり来たりします (訳注: これは, BIOSがリアルモード用に書かれていて, ロードすべき領域がリアルモードではアクセスできない1MBより上位の アドレスであることから, ブートコードがリアルモードと プロテクトモードを切り替えながら動作するためです). ブートコード自身はプロテクトモードで %csと%ds/%es 用に セグメントセレクタ 0x18 と 0x20 を使い, リアルモードに戻るのに0x28を使います. 最終的にカーネルはアドレス空間全体をカバーできるようなダミーの ディスクリプタを参照して%cs 0x08と %ds/%es/%ss 0x10でスタートします. カーネルはそのロードポイントで起動されます. 別の(高位)アドレスにリンクされるので, ページテーブルやページディレクトリなどが適切に設定され, ページングが有効になり, カーネルがリンクされたアドレスで 動作するようになるまでは, カーネルはロードアドレスからの 相対アドレス (PIC: position independent code) を用いて 実行されなければなりません. - 寄贈: &a.dg;. - 16 Apr 1995. + 寄稿: &a.dg;. 1995 年 4 月 16 日. カーネルの BSS セグメントの直後の物理ページ (実メモリ) に proc0 (訳注: プロセス番号 0, swapper) のページディレクトリや ページテーブル, Uページが配置されます. 仮想記憶機構が初期化された少しあと, 0x1000-0x9ffffの実メモリとカーネル (text + data + bss + 上記の proc0 に関わるもの + その他) の後ろの実メモリは, 通常の仮想記憶ページの形で利用可能となり, グローバルな空きページリストに追加されます. DMAとはどういったものでどういう働きをするのか - 原作: &a.uhclem; - 訳: &a.jp.yasu; - 10 December 1996. 最終更新日 8 October 1997. + 原作: + Copyright © 1995,1997 &a.uhclem;, All Rights + Reserved. + 1996 年 10 月 10 日. + 最終更新日 1997 年 10 月 8 日. + + 訳: &a.jp.yasu; Direct Memory Access (DMA)は, 中央演算処理装置 (CPU)からの干渉なく データを計算機中である場所から別の場所に動かすための手法です. DMA 機能の実装の方法はそれぞれの 計算機アーキテクチャ間で異なるもので あるため, ここでの議論はIBMパーソナルコンピュータ(PC), PC/AT とその互換機における DMA サブシステムの実装と働きに限定します. PCの DMAサブシステムは, Intelの 8237 DMAコントローラをベースにして います. 8237はそれぞれ独立にプログラムできる4つのDMAチャネルを持ち, それぞれどのチャネルもいつでもアクティブにできます. これらのチャネルは順に 0, 1, 2, 3となっています. PC/ATからは, セカンド 8237 チップが追加され,それらは 4, 5, 6, 7と なっています. オリジナルの DMAコントローラ(0, 1, 2, 3)は, 1回の転送で1バイト 転送します. セカンドDMAコントローラ(4, 5, 6, 7)は1回で 隣接する2つのメモリ番地から 16ビット転送します. ここで, 最初のバイトは通常偶数のアドレスになります. 2つのコントローラは全く同じものであり, 転送量が異なるのは セカンドコントローラがシステムに直結しているためです. 8237 は個々のチャネルについて, DRQと-DACKという2つの電気信号を 持っています. その他に, HRQ (Hold Request), HLDA (Hold Acknowledge), -EOP (End of Process)があり, バス制御信号として -MEMR (Memory Read), -MEMW (Memory Write), -IOR (I/O Read), and -IOW (I/O Write)があります. 8237 DMACは, いわゆる“fly-by” DMAコントローラです. これは, データの移動を行う際に, データは DMACチップを通過せず, DMACチップに格納されないことを意味します. また, DMACはI/Oポートとメモリアドレス間でのみデータを 転送することができますが, 2つのI/Oポートもしくは2つのメモリアドレス 間ではできません. 8237 は, 非 “fly-by”モードでは, 互いに接続された 2つのチャネルでのメモリ-メモリ間でのDMA操作を許可します. しかし, PC メーカは, ただでさえ乏しいこのリソースをこんなふうに 使ったりしません. なぜなら, CPUを使用してメモリ間のデータを動かす方が早いからです. PC アーキテクチャでは, それぞれのDMAチャネルは, 通常 与えられた DMA チャネルを使用するハードウェアがそのチャネルについて DRQ線を使って転送を要求した時のみ動作します. DMA転送の例 DMA転送の発生と処理の手順の例をあげてみましょう. この例では, フロッピーディスクコントローラ (FDC)が ディスケットから1バイト読み込んで, DMAを使って,メモリの0x00123456番地に 格納したいとします. 処理は, FDCが, DRQ2信号(DMAチャンネル2に 対するDRQ線)を有効にして DMAコントローラに要求を伝えることで開始されます. DMAコントローラは DRQ2 シグナルが有効になったことを記録します. するとDMAコントローラはDMAチャネル2がプログラムされ, マスクが かかっていない(有効になっている)ことを確認します. 同様に, DMAコントローラは, 他のDMAチャネルがアクティブまたは アクティブになろうとしていないこと, そしてより高い優先度を持って いないことを確認します. 一旦これらのチェックが完了すると, DMACはDMACがバスを使うために バスを開放するようにCPUに要求します. DMACはCPUにHRQ信号を送ってバスを要求します. CPUはHRQ信号を検出し, 現在の指示の実行を完了します. 一旦プロセッサがバスを開放することができる状態になると, 解放を 行います. 通常は CPU により駆動される信号 (-MEMR, -MEMW, -IOR, -IOW, その他)を すべてハイインピーダンス (ハイともローとも指定しない)状態にした後, CPUは HLDA信号を有効にして DMAコントローラにバスを明け渡したことを 伝えます. プロセッサによっては, CPUはバスを使用しないいくつかの 命令を追加して実行することもできますが, しかし,プロセッサの内部キャッシュや パイプライン以外のメモリから 何か読み出すといった指示に到達したら結局 CPU は待たなくてはなりません. ここで,DMACが バスを“託される”と, DMACはその -MEMR, -MEMW, -IOR, -IOW 出力信号をアクティブにし, DMACから出力されるアドレスは 0x3456にセットされます.これは 転送しようとする特定のメモリ番地をバイトで 指示するのに使われます. すると DMAC は DMA 転送をリクエストしたデバイスに転送が始まることを 知らせます.これは -DACK 信号をアクティブにすることで行われます. フロッピーディスクコントローラの場合は, -DACK2を アクティブにすることで行われます. バスのデータ線に転送されるバイトにを出力することについては フロッピーディスクコントローラが責任をもつことになります. もし,フロッピーディスクコントローラがバス上にバイトデータを 出力するのに余計な時間を必要としなければ (もし周辺装置がもっと時間を必要とする場合には, READY信号を 経由してDMACに通知します), DMAは 1 DMAクロック待ち, メモリにバス上のバイトデータを格納するために -MEMW および -IOR 信号を解除します. そして FDCはバイトデータが転送されたことを認識します. DMAサイクルは1度に1バイトしか転送しないので, FDCはDRQ2信号を止めて, DMACに転送が終了したことを知らせます. DMACは-DACK2信号を解除して, FDCはバス上へのデータ出力を 停止しなくてはならないことを知らせます. 次にDMACは他のDMAチャネルのいずれかに要求がきていないか チェックを行います. もしどのチャネルのDRQも有効になっていなければ, DMAコントローラは処理を完了して, -MEMR, -MEMW, -IOR, -IOW および アドレス信号をハイインピーダンス状態にします. 最後に, DMAはHRQ信号を解除します. CPUはこれを見ると,HOLDA信号を 解除します. そしてCPUは自らの -MEMR, -MEMW, -IOR, -IOW 信号および アドレス線を有効にし, 命令の実行やメインメモリや周辺機器へのアクセスを 再開します. 典型的なフロッピーディスクの1セクタについては, 上記のプロセスが それぞれのバイトについて1回行われ, 全部で512回繰り返されます. 1 バイト転送される毎に, DMAC 内のアドレスレジスタはインクリメントされ, 同じくDMAC内にある, 何バイト転送すればよいかを示すカウンタが デクリメントされます. カウンタが0になると, DMAはEOP信号を送ります. この信号は カウンタが0であり, DMAコントローラがCPUによって再び プログラムされるまで, これ以上データは転送されないことを 示すものです. このイベントはターミナルカウント(TC)とも呼ばれます. EOP信号は1本しかありません. そして, 一度にアクティブにできる DMAチャネルは一本だけなので, 現在アクティブであるDMAチャネルこそが, たった今処理を終了したDMAチャネルだと言うことができます. もし, バッファの転送が完了した時に周辺機器から割り込みを発生させたい とき, 周辺機器は -DACKn信号およびEOP信号の両方が同時に発信されたか どうかをテストします. その場合, DMACはCPUの介在がなければ これ以上はその周辺機器についての情報を転送しません. その後で, 周辺機器はプロセッサに割り込みを生じさせるために, 何らかの割り込み信号を発生させることができます. PCアーキテクチャ においては, DMAチップ自身が割り込みを生じさせることはできません. 周辺機器とそれに関連するハードウェアが割り込みを生成する責任を 持ちます. また, DMAを使用する周辺機器が割り込みを使用しない 可能性もあります. DMAC が要求を出したときには CPU は常にバスを DMAC に開放しますが, この動作は, DMAC がアクティブになった時にプロセッサが命令を実行するのに かかる時間がわずかに変化することを除いては, アプリケーション, オペレーティングシステムの両方からはわからないということを 理解することが重要です. そのため, プロセッサが確かにDMA転送が完了したことを知るためには, 周辺装置や DMA チップ中のレジスタを調べたり,周辺装置からの割り込みを 受け取る必要があります. DMA ページレジスタ および 16メガ アドレス空間制限 これまで述べたのとは異なり, DMACはアドレス線を 0x0123456 にセットする 代わりに 0x3456 だけをセットすることにあなたは気づいたかも しれません. この理由について少し説明します. オリジナルのIBM PCがデザインされた時, IBMは, DMACと割込み制御チップの 両方を, 8085(8ビットプロセッサで, 16ビットのアドレス空間(64k)を持つ)と 組み合わせて使うように設計されたチップを使うことを選びました. IBM PCが64k以上のメモリをサポートしていたため, DMACが64kを越えるメモリ番地に読み込み又は書き込みを行うために 変更を行う必要が生じました. この問題を解決するためにIBMが行ったのは, それぞれのDMAチャネルに, 読み込み元または書き込み先のアドレスの 上位ビットを保持するための 外部的なラッチを追加することでした. DMAチャネルがアクティブな時はいつでも, このラッチの内容はアドレスバスに書かれて, そのチャネルのDMA操作が 終了するまでそこに保持されます. IBM はこれらのラッチを “ページレジスタ” と呼んでいます. そのため上記に示した例では, DMACはアドレスの0x3456の部分をバス上に 置き, DMAチャネル2に対するページレジスタは, 0x0012xxxxをバス上に 置きます. これらの2つの値が組み合わされてアクセスされるメモリ中の完全な アドレスを形成します. ページレジスタのラッチはDMAチップとは独立であるので, 読み込まれる又は書き込まれるメモリ領域は, 64kの物理的境界を またいではなりません. 例えば, もし DMACがメモリの0xffff番地をアクセスした場合, データの転送後, DMACはアドレスレジスタをインクリメントし, 0x0000番地にある次のバイトを アクセスします. 0x10000番地ではありません. これはおそらく意図されたものとは異なっているでしょう. “物理的な” 64Kの境界を 8086モードの 64k“セグメント”と混同してはいけません. セグメントは, セグメント レジスタに数学的にオフセットレジスタを 加算して作られるものです. ページレジスタにはアドレスのオーバーラップも無く, 数学的に OR を取られることもありません. さらに複雑なことには, PC/ATでは外部のDMAアドレスのラッチは 8ビットしか保持しません. よって8+16で24ビットになり, これは DMAが0から16メガの間のメモリ番地しか指し示せないことを 意味します. 16メガ以上のメモリを持ったより新しいマシンにおいても, 標準的なPCコンパチブルなDMAでは16メガ以上のメモリ番地には アクセスできません. この制限を避けるために, オペレーティングシステムは 16 メガ以下にある物理的な 64k の境界をまたがない領域に RAM バッファを 予約します. そして, DMACはデータを周辺機器からそのバッファに 転送するようにプログラムされます. 一旦DMACがこのバッファに データを動かすと, オペレーティングシステムは本当にデータを 格納したいアドレスにバッファからデータをコピーします. 16メガを越えるアドレスからDMAベースの周辺機器にデータを 書き込む際には, データは16メガ以下に位置したバッファから最初に コピーされなくてはならず, その後, DMACはバッファからハードウェアに データをコピーすることができます. FreeBSDでは, これらの予約バッファは “バウンスバッファ”と呼ばれます. MS-DOSの世界では, これらは“スマートバッファ”などと呼ばれます. 82374と呼ばれる8237の新しい実装においては, ページレジスタを16ビットで指定して, バウンスバッファを使用しなくても, 32 ビットのアドレス空間全体にアクセスすることが可能です. DMA操作モードとその設定 8237 DMA はいくつかのモードで動作します. 主なモードは, 以下のとおりです. シングル転送モード シングルバイト(もしくはワード)が転送されます. DMAは1バイト毎にバスを開放し, 再び要求しなくてはなくてはなりません. これは一般に, すぐにはデータのブロック全てを転送できないデバイスに よって使用されます. 周辺装置は次の転送の準備ができる毎にDMAを要求します. 標準的な PC コンパチブルなフロッピーディスクコントローラ(NEC 765)は 1バイトのバッファしか持たないので, このモードを使用します. ブロック/デマンド転送モード 一旦 DMAC がシステムバスを取得すると, 最大64kまでのデータブロック 全体が転送されます. もし周辺装置が余分に時間を必要とするときは, 転送を一時中断するためにREADY信号を有効にします. READY信号は過度に使われるべきではなく, 遅い周辺装置の転送の場合は シングル転送モードを代わりに使うべきです. ブロック転送モードとデマンド転送モードの違いは, 一旦ブロック転送が 始まると, 転送カウンタか 0 になるまでそれが行われるところです. DRQ は -DACK が有効になるまでの間は有効でなければなりません. デマンドモードは DRQ が有効な間転送が続けられます. DRQが有効でなくなった場合, DMA はその時点で転送を中断し, バスを解放して CPU に返します. その後, DRQが有効になると, 転送は中断したところから再開されます. データの転送, 特に転送に使われるメモリ番地が16Mを越える場合に, CPU を使った方が効率がよくなるまで CPU の速度が向上する以前の 古いハードディスクコントローラはデマンドモードを 使っていました. カスケード転送モード このメカニズムは DMA チャネルがバスを要求することを許可する ものですが, 接続されたデバイスはバス上のアドレス情報の配置に ついてDMACに代わって責任を持ちます. これは“バスマスタ” と呼ばれる技術の実装に利用されます. カスケードモードの DMA チャネルがバスのコントロールを受け取ると, DMA は通常行われるようなバス上のアドレスと I/O コントロール信号の 出力を行いません. 代わりに, DMAはアクティブなチャネルの -DACK信号を 有効にします. この時点で, アドレスとバスコントロール信号の供給は DMAチャネルに接続された周辺機器が担当します. 周辺機器はシステムバスの完全なコントロールを行い, 16 メガ以下の任意のアドレスの読み込みおよび書き込みを 行うことが できます. 周辺機器はバスの使用を終えると DRQ 線を無効にするので, DMA コントローラは CPU もしくは他のDMAチャネルに制御を返すことが できます. カスケードモードは複数の DMA コントローラを相互接続するのに 使われます. PC内ではDMAチャネル4がまさにこの用途に使われています. 周辺機器がDMAチャネル0, 1, 2, 3でバスを要求すると, スレーブDMAコントローラは HLDREQ を有効にしますが, この線はCPUではなく, 実際にはプライマリDMAコントローラのDRQ4に 接続されています. その後, チャンネル4になにか仕事があるものと見なしたプライマリの DMAコントローラは HLDREQ を使ってCPUにバスを 要求します. バスが与えられると, -DACK4が有効になりますが, この線は実際にはスレーブDMAコントローラの HLDA信号に 接続されています. スレーブDMAコントローラはその後要求したDMAチャネル (0, 1, 2, 3) に対してデータを転送するか, SCSIコントローラのような バスマスタリングを要求する周辺機器にバスを許可します. このような配線がおこなわれているため, PC/ATシステムの 周辺機器ではDMAチャネルは 0, 1, 2, 3, 5, 6, 7のみが使用できます. 初期のIBM PCコンピュータでは, DMAチャネル0は操作の リフレッシュのために予約されていますが, 最近のシステムでは通常, 周辺機器によって使用することができます. 周辺機器がバスマスタリングを行っている時は, システムバスを保持している間絶えずメモリに もしくはメモリから データを転送することが重要です.もし, 周辺機器がこのように できないときは, システムがメインメモリのリフレッシュを 行なえるようにしばしばバスを開放しなくては なりません. 全ての PC でメインメモリとして使われるダイナミック RAM は, 中身が “満たされている” ビットを保持するため 頻繁にアクセスされなくてはなりません. ダイナミック RAM は, それぞれが 1 ビットのデータを記憶するコンデンサが たくさん集まって構成されています. これらのコンデンサは充電された 状態で 1, 充電されていない状態で 0 を表します. 全てのコンデンサは放電するため, 1 の値を保持するために, 一定の間隔で電力を加える必要があります. 実際に RAM チップは RAM の適切な場所に電力を送る作業を行ないますが, メモリのリフレッシュ作業が RAM を普通にアクセスする時と 衝突しないように, それをいつ行なうかを コンピュータが休止状態の時に知らせなくてはなりません. もしコンピュータがメモリのリフレッシュを 行なえない場合は, メモリの中身はわずか数ミリ秒で壊れてしまいます. メモリの読み込みと書き込みのサイクルは リフレッシュサイクルとして カウントされる(ダイナミック RAM のリフレッシュサイクルは 実際には不完全なメモリ読み込みサイクルになります)ので, 周辺機器のコントローラが連続するメモリ番地から データの読み込み または書き込みを行う間は, メモリの全てがリフレッシュされます. バスマスタリングはいくつかの SCSI ホストインターフェースやその他の ハイパフォーマンスな周辺機器コントローラに 見られます. 自動初期化転送モード このモードにおいてDMAはバイト, ブロック, デマンド転送を行いますが, DMA転送カウンタが0になると, カウンタとアドレスはDMAチャネルが もともとプログラムされた時のものに戻されます. これは, 周辺機器が転送を要求している間は転送が続けられることを 意味します. 転送領域としてDMACにプログラムされた固定バッファの中で, 出力操作でDMACがデータを読み出す前もって新しいデータを 書き込んだり入力操作でDMACが書き込んだあとに, そこから新しいデータを読み出す作業は CPU が受け持ちます. このテクニックは, “サンプリング” 用のバッファが小さいもしくは それを持たないオーディオデバイスによく使われます. この“環状” バッファの管理は更なる CPU オーバーヘッドになりますが, DMAカウンタが0になり, 再プログラムされるまでDMAが停止してしまう ことによって起きる遅延は, この方法でしかなくす事ができない 場合もあります. DMAのプログラミング プログラムされるDMAチャネルは, 通常, 設定を行う前に “マスクする”べきです. これはハードウェアが予期せずそのチャンネルに対してDRQを有効に した場合, たとえ全てのパラメータが 満たされてない場合や更新されていない場合でも, DMACは それに応答してしまう可能性があるからです. マスクを行ってから,ホストは転送の方向(メモリからI/O, もしくはI/Oからメモリ)と, 転送に使用するDMA操作のモード (シングル, ブロック, デマンド, カスケードなど)を設定し, 最後に アドレスや転送の長さを設定します. 設定される長さはDMACに転送させたい量よりも1少なくなります. アドレスや転送長のLSBとMSBは同じ8ビットI/O ポートに書き込まれます. そのためDMACが最初のバイトをLSBとして, 2番目のバイトをMSBとして 受け取ることを保証するために, 最初に別のポートに書き込みを行なって LSBとMSB の判別を行なうフリップフロップをクリアしておく必要があります. そして,DMAのページレジスタを更新します. これはDMACの外部にあり I/O ポートの別のセットを通してアクセスされます. すべての設定ができると, DMAチャネルはマスクを解除することができます. そのDMAチャネルは“準備ができた”とみなされ, そのチャンネルのDRQが 有効になると応答します. 8237のプログラミングの正確な詳細については, ハードウェアデータブックを参照してください. PCシステムにおける I/O マップについても参照する必要があるでしょう. このマップには DMA およびページレジスタのポートがどこに位置するのかを 書いてあります. 以下に完全なポートのマップテーブルを示します. DMAポートのマップ IBM-PCとPC/ATに基づくすべてのシステムでは, 同じI/Oポートに配置された DMAハードウェアを持っています. その完全なリストを以下に示します. DMAコントローラ2に割り当てられたポートは, AT以外のデザインでは 未定義になっています. 0x00 – 0x1f DMA コントローラ #1 (Channels 0, 1, 2 and 3) DMA アドレス および カウントレジスタ 0x00 write Channel 0 starting address 0x00 read Channel 0 current address 0x01 write Channel 0 starting word count 0x01 read Channel 0 remaining word count 0x02 write Channel 1 starting address 0x02 read Channel 1 current address 0x03 write Channel 1 starting word count 0x03 read Channel 1 remaining word count 0x04 write Channel 2 starting address 0x04 read Channel 2 current address 0x05 write Channel 2 starting word count 0x05 read Channel 2 remaining word count 0x06 write Channel 3 starting address 0x06 read Channel 3 current address 0x07 write Channel 3 starting word count 0x07 read Channel 3 remaining word count DMA コマンドレジスタ 0x08 write Command Register 0x08 read Status Register 0x09 write Request Register 0x09 read - 0x0a write Single Mask Register Bit 0x0a read - 0x0b write Mode Register 0x0b read - 0x0c write Clear LSB/MSB Flip-Flop 0x0c read - 0x0d write Master Clear/Reset 0x0d read Temporary Register (新しいバージョンでは利用不可) 0x0e write Clear Mask Register 0x0e read - 0x0f write Write All Mask Register Bits 0x0f read Read All Mask Register Bits (Intel 82374にのみ存在する) 0xc0 – 0xdf DMA コントローラ #2 (Channels 4, 5, 6 and 7) DMA アドレス および カウントレジスタ 0xc0 write Channel 4 starting address 0xc0 read Channel 4 current address 0xc2 write Channel 4 starting word count 0xc2 read Channel 4 remaining word count 0xc4 write Channel 5 starting address 0xc4 read Channel 5 current address 0xc6 write Channel 5 starting word count 0xc6 read Channel 5 remaining word count 0xc8 write Channel 6 starting address 0xc8 read Channel 6 current address 0xca write Channel 6 starting word count 0xca read Channel 6 remaining word count 0xcc write Channel 7 starting address 0xcc read Channel 7 current address 0xce write Channel 7 starting word count 0xce read Channel 7 remaining word count DMA コマンドレジスタ 0xd0 write Command Register 0xd0 read Status Register 0xd2 write Request Register 0xd2 read - 0xd4 write Single Mask Register Bit 0xd4 read - 0xd6 write Mode Register 0xd6 read - 0xd8 write Clear LSB/MSB Flip-Flop 0xd8 read - 0xda write Master Clear/Reset 0xda read Temporary Register (Intel 82374には存在しない) 0xdc write Clear Mask Register 0xdc read - 0xde write Write All Mask Register Bits 0xdf read Read All Mask Register Bits (Intel 82374にのみ存在する) 0x80 – 0x9f DMA ページレジスタ 0x87 r/w Channel 0 Low byte (23-16) page Register 0x83 r/w Channel 1 Low byte (23-16) page Register 0x81 r/w Channel 2 Low byte (23-16) page Register 0x82 r/w Channel 3 Low byte (23-16) page Register 0x8b r/w Channel 5 Low byte (23-16) page Register 0x89 r/w Channel 6 Low byte (23-16) page Register 0x8a r/w Channel 7 Low byte (23-16) page Register 0x8f r/w Low byte page Refresh 0x400 – 0x4ff 82374 Enhanced DMA Registers Intel 82374 EISA System Component (ESC)は1996年の初めに発表されました. この中 には機能的には8237のスーパーセットであり, 1つのパッケージの中にその他の PC 互換機のコアとなる周辺コンポーネントをも含んだ DMA コントローラも含まれています. このチップはEISAとPCI 両方のプラットホームをターゲットにしたものであり, scatter-gather I/O やリングバッファを始めとして, システムDMAをして32ビットの アドレス空間全体に直接アクセスする能力も提供しています. これらの機能を使用する場合でも, 過去16年間のPC互換機で利用されてきた 同等機能を提供するコードも含めておく必要があります. 互換性の問題から, 82374の レジスタの一部は, 従来の8237のレジスタをプログラムした 後 に, 転送の度にプログラムされる必要があります. 8237のレジスタに書き込みを行うとき, ソフトウェアの下位互換性のために, 82374で追加された一部のレジスタの内容が 強制的に0にクリアされるからです. 0x401 r/w Channel 0 High byte (bits 23-16) word count 0x403 r/w Channel 1 High byte (bits 23-16) word count 0x405 r/w Channel 2 High byte (bits 23-16) word count 0x407 r/w Channel 3 High byte (bits 23-16) word count 0x4c6 r/w Channel 5 High byte (bits 23-16) word count 0x4ca r/w Channel 6 High byte (bits 23-16) word count 0x4ce r/w Channel 7 High byte (bits 23-16) word count 0x487 r/w Channel 0 High byte (bits 31-24) page Register 0x483 r/w Channel 1 High byte (bits 31-24) page Register 0x481 r/w Channel 2 High byte (bits 31-24) page Register 0x482 r/w Channel 3 High byte (bits 31-24) page Register 0x48b r/w Channel 5 High byte (bits 31-24) page Register 0x489 r/w Channel 6 High byte (bits 31-24) page Register 0x48a r/w Channel 6 High byte (bits 31-24) page Register 0x48f r/w High byte page Refresh 0x4e0 r/w Channel 0 Stop Register (bits 7-2) 0x4e1 r/w Channel 0 Stop Register (bits 15-8) 0x4e2 r/w Channel 0 Stop Register (bits 23-16) 0x4e4 r/w Channel 1 Stop Register (bits 7-2) 0x4e5 r/w Channel 1 Stop Register (bits 15-8) 0x4e6 r/w Channel 1 Stop Register (bits 23-16) 0x4e8 r/w Channel 2 Stop Register (bits 7-2) 0x4e9 r/w Channel 2 Stop Register (bits 15-8) 0x4ea r/w Channel 2 Stop Register (bits 23-16) 0x4ec r/w Channel 3 Stop Register (bits 7-2) 0x4ed r/w Channel 3 Stop Register (bits 15-8) 0x4ee r/w Channel 3 Stop Register (bits 23-16) 0x4f4 r/w Channel 5 Stop Register (bits 7-2) 0x4f5 r/w Channel 5 Stop Register (bits 15-8) 0x4f6 r/w Channel 5 Stop Register (bits 23-16) 0x4f8 r/w Channel 6 Stop Register (bits 7-2) 0x4f9 r/w Channel 6 Stop Register (bits 15-8) 0x4fa r/w Channel 6 Stop Register (bits 23-16) 0x4fc r/w Channel 7 Stop Register (bits 7-2) 0x4fd r/w Channel 7 Stop Register (bits 15-8) 0x4fe r/w Channel 7 Stop Register (bits 23-16) 0x40a write Channels 0-3 Chaining Mode Register 0x40a read Channel Interrupt Status Register 0x4d4 write Channels 4-7 Chaining Mode Register 0x4d4 read Chaining Mode Status 0x40c read Chain Buffer Expiration Control Register 0x410 write Channel 0 Scatter-Gather Command Register 0x411 write Channel 1 Scatter-Gather Command Register 0x412 write Channel 2 Scatter-Gather Command Register 0x413 write Channel 3 Scatter-Gather Command Register 0x415 write Channel 5 Scatter-Gather Command Register 0x416 write Channel 6 Scatter-Gather Command Register 0x417 write Channel 7 Scatter-Gather Command Register 0x418 read Channel 0 Scatter-Gather Status Register 0x419 read Channel 1 Scatter-Gather Status Register 0x41a read Channel 2 Scatter-Gather Status Register 0x41b read Channel 3 Scatter-Gather Status Register 0x41d read Channel 5 Scatter-Gather Status Register 0x41e read Channel 5 Scatter-Gather Status Register 0x41f read Channel 7 Scatter-Gather Status Register 0x420-0x423 r/w Channel 0 Scatter-Gather Descriptor Table Pointer Register 0x424-0x427 r/w Channel 1 Scatter-Gather Descriptor Table Pointer Register 0x428-0x42b r/w Channel 2 Scatter-Gather Descriptor Table Pointer Register 0x42c-0x42f r/w Channel 3 Scatter-Gather Descriptor Table Pointer Register 0x434-0x437 r/w Channel 5 Scatter-Gather Descriptor Table Pointer Register 0x438-0x43b r/w Channel 6 Scatter-Gather Descriptor Table Pointer Register 0x43c-0x43f r/w Channel 7 Scatter-Gather Descriptor Table Pointer Register FreeBSD VM システム 原作: &a.dillon;. 6 Feb 1999 物理メモリ管理 — <literal>vm_page_t</literal> 物理メモリはページ単位に, vm_page_t構造体を用いて管理されます. 物理メモリのページは, ページキューの一つに存在する, それぞれの vm_page_t 構造体の配置によって分類されます. ページは, wired(ワイヤード), active(活性状態), inactive(非活性状態), cache(キャッシュ状態), free(使われていない状態)の 各状態をとります. wired 状態を除いて, ページは通常 その状態を示す二重連結リストのキューに置かれます. wired 状態のページがキューに置かれることはありません. FreeBSD は, ページカラーリング(page coloring)を実装するため, cache 状態, free 状態にあるページ用に, さらに複雑なページキューを実装しています. その各々の状態は, プロセッサの L1, L2 キャッシュサイズに応じて最適化された 多重キューを利用します. FreeBSD は, 新たなページを確保(allocate)することが 必要になった場合に確保される VM オブジェクトのために, L1, L2 キャッシュに対して合理的にアライン(align)されたページを 得ようと試みます. 加えて, ページは参照カウントとともに保持され, ビジーカウントとともにロックされます. VM システムは, ページフラグとして PG_BUSY を使う “完全ロック状態” も実装しています. 一般的には, 各々のページキューは最長不使用 (LRU) 方式で動作します. ページは普通, 最初に wired, もしくは active 状態に置かれます. wired 状態の場合, そのページはどこかにあるページテーブルに 関連づけられています. VM システムはアクティブなキュー内のページをスキャンし, wired 状態のページにエイジング (訳注: ページ参照頻度を量る手法の一つ; aging) を施します. そして, そのページはあまりアクティブでないキューへ 移動することになります. cache キューに移動させられたページは, 再利用の候補になっている VM オブジェクトに割り付けられています. free キューにあるページは, 完全に自由の状態にあります. FreeBSD は, free キューにあるページ数を最小限にとどめようと 試みますが, 割り込み発生時のページ確保を融通するため, 完全に自由なページをいくつか持っていなければなりません. プロセスがページテーブルに存在しない, ページキューの一つ(例えば, inactive, cache キュー等)に 存在するページをアクセスしようとしたとき, 比較的負荷の小さなページ再活性化フォールトが起こります. システムメモリに全く存在していないページの場合は, ディスクからページを読み出す間, そのプロセスはブロック(block)されます. FreeBSD は, ページキューを動的に調節し, 同期済(clean)のページ, 同期していない(dirty)ページの分類を 合理的に保つのと同様に, それぞれのキューにあるページが合理的な 比率に保つように試みます. 再バランス化処理が起こる量は, システムのメモリ負荷に依存します. この再バランス化処理は ページアウトデーモンによって実装されていて, (補助記憶とページを同期して)同期していないページの クリーニングすることや, (LRU キュー内でのページ位置を再配置したり, ページをキューの間を移動することで)ページが頻繁に 参照状態にあることに注目すること, キューを均等にするための キュー間ページ移動等を伴います. ページが実際にどれだけ使われているかを決定するために, FreeBSD の VM システムは, ページの再活性化フォールトを 自発的に, 合理的な数だけ発生します. これは, ページをスワップアウトしたり, クリーニングする時期を より良く決めることに繋がります. 統合バッファキャッシュ — <literal>vm_object_t</literal> FreeBSD は, 一般化した “VM オブジェクト” という考え方を実装しています. VM オブジェクトは, 様々な種類の補助記憶(backing store) — 補助記憶なし, スワップ, 物理デバイス, ファイル, に割り付けられます. ファイルシステムは ファイルと関連するインコアデータを管理するのに, 同じ VM オブジェクトを利用するため, 統合バッファキャッシュと呼ばれます. VM オブジェクトは, シャドウ化 することができます. シャドウ化とは, オブジェクトがそれぞれ互いの上に スタック(stack)されるということです. 例えば, MAP_PRIVATE mmap() の 動作を実装するために, ファイルに割り付けられた VM オブジェクトの上にスタックされた, スワップに割り付けられた VM オブジェクトが存在しているでしょう. このスタッキングは, fork されたアドレス空間のための 様々な共有属性, コピーオンライト(訳注: ページ共有のための 手法の一つ; cow,copy-on-write) を実装するのにも利用されています. vm_page_t は, 同時に一つの VM オブジェクトしか割り付けられることが できないことに注意しなければなりません. VM オブジェクトのシャドウ化は, 複数のインスタンスが同じページに 共有できるように実装されています. ファイルシステム I/O — <literal>struct buf</literal> 補助記憶にファイルを使う VM オブジェクトのように, v ノードを使う VM オブジェクトは通常, 処理されているかどうかという情報を, VMシステムが管理する処理情報から独立して 管理される必要があります. 例えば, VM システムが物理ページと補助記憶を同期させようとしたとき, VM システムは, 実際に書き戻す前に, ページがクリーニング済であるという マークを付ける必要があるわけです. さらに, ファイルシステムは, KVM 内で操作できるように, ファイルや, ファイルメタデータの一部分を KVM にマッピングすることが できなくてはなりません. これを管理するために使われる実体は, ファイルシステムバッファ, struct buf, bp として知られています. ファイルシステムに VM オブジェクトの一部を操作することが 必要となるときは通常, オブジェクトの部分が struct buf に マッピングされ, KVM に struct buf 内のページがマッピングされます. 同じ方法で, ディスク I/O はオブジェクトの部分を バッファ構造体内にマッピングし, その時バッファ構造体上の I/O を 発行することで発行されます. 基礎となっている vm_page_t は, I/O 処理の間 ビジー(busy)状態になります. ファイルシステムにも 独立したビジー状態があり, それはハードウェア上の VM ページの代わりに ファイルシステムバッファで動作する ファイルシステムドライバのコードに とって有用です. FreeBSD は, マッピングを保持するためにある量に制限された KVM を 予約していますが, KVM がマッピングを保持するためだけに使われ, キャッシュデータの能力を制限しないということは 明確にされるべきでしょう. 物理データキャッシュを行うことは厳密に vm_page_t の機能になっており, ファイルシステムバッファの機能ではありません. しかし, ファイルシステムバッファは placehold I/O に使われるため, それは実質的に同時処理可能な I/O 処理量を制限します. 通常は二, 三千のファイルバッファが利用可能ですから, このことは問題にならないでしょう. マッピングページテーブル — <literal>vm_map_t</literal>, <literal>vm_entry_t</literal> FreeBSD は, 物理ページテーブルの形態を VM システムと分離しています. ハードウェア上にある全てのプロセス毎のページテーブルは, その場その場で再構成され, 通常, 使い捨てだとみなされています. KVM を管理するような特殊なページテーブルは, 最初に永続的な確保が 行われ, これらのページテーブルが破棄されることはありません. FreeBSD は, vm_objects の部分を, 仮想メモリのアドレス範囲に vm_map_t と vm_entry_t 構造体を通して割り付けます. ページテーブルは, vm_map_t /vm_entry_t/vm_object_t という階層から 直接つくられます. “物理ページは, 直接一つの vm_object に 割り付けられる” と私が述べたことを思い出して下さい. ええと, そうですね, しかしそれはいつでも完全に当てはまる, というわけでもないのです. vm_page_t のは, 実際に割り付けられた ページテーブルにもリンクされています. 一つの vm_page_t は ページテーブルが呼ばれた時, いくつかの pmaps と リンクされることがあります. しかし, そのような階層的な割り付けは, 同じ vm_page_t を参照するオブジェクト内の, 同じページへの参照全てを保持しているため, その結果, 常にバッファキャッシュの統合を得ることができるわけです. KVM メモリマッピング FreeBSD は, 様々なカーネル構造体を保持するため, KVM を利用します. ファイルシステムバッファキャッシュは, KVM 内で最も大きなものです. それはつまり, struct buf の実体に対するマッピングに他なりません. Linux と異なり, FreeBSD は全ての物理メモリを KVM にマッピングしません. これは, FreeBSD が 32 ビットプラットフォームで 4G バイトまでの メモリを扱える, ということを意味します. 実際, MMU がそれを可能にしているならば, 理論上, FreeBSD は 32 ビットプラットフォームで 8TB までのメモリを扱うことができることになります. しかし, 大部分の 32 ビットプラットフォームは 4G バイトの RAM しか マッピングできないようになっている, ということには議論の余地があるでしょう. KVM は, いくつかのメカニズムによって管理されています. 中心となっているのは, ゾーンアロケータ(zone allocator)です. ゾーンアロケータは, 特定の構造体型を確保するために KVM の部分(chunk)を得て, 一定の大きさのメモリブロックに分割します. vmstat -m コマンドで, ゾーンによって 分割された, 現在の KVM 利用状況一覧を得ることができます. FreeBSD VM システムのチューニング FreeBSD カーネルでは, 動的に自分自身をチューニングするために, 協調的な努力が行なわれています. 普通は, maxusers と NMBCLUSTERS という カーネルオプション, つまり, /usr/src/sys/i386/conf/CONFIG_FILE で 指定されるもの以外, 変更する必要はありません. 可能なカーネルオプションの一覧は, /usr/src/sys/i386/conf/LINT に 記載されています. 大きなシステムに対しては, maxusers を増やしたいと思うかも知れませんね. この値は普通, 10 から 128 の間の値にします. maxusers を増やしすぎるとシステムの利用可能な KVM がオーバフローしてしまい, 予測できない動作に陥ってしまうことに注意して下さい. maxusers はある適度な値にとどめておいて, 特定のリソースを制御する NMBCLUSTERS のような, 他のオプションを増加させる方が良いでしょう. もし, システムが負荷の高いネットワーク用途に使われるなら, NMBCLUSTERS を増やしたいと望むことでしょう. この値は普通, 1024 から 4096 の間です. NBUF パラメータも, 伝統的にシステムの規模を決めるのに使われます. これは, システムがファイルシステムバッファを I/O のために マッピングするのに使われる, KVA の大きさを決めるのに使われます. このパラメータは, 統合バッファキャッシュには何の影響も与えません. これは 3.0-RELEASE 以降のカーネルでは動的にチューニングされるため, 普通は手作業で調整されるべきものではありません. NBUF パラメータは, 指定しようとしないことを推奨します. システムに選択させれば良いのです. 小さすぎる値は極端に非効率的なファイルシステム動作を招き, 一方で, 大きすぎる値は wired 状態のページを数多くつくりだし, ページキューを枯渇させてしまうでしょう. デフォルトでは, FreeBSD カーネルは最適化されていません. カーネルコンフィグにある makeoption ディレクティブを使って 最適化とデバッグフラグをセットすることができます. ただし, それによって得られる大きな (7MB 超の)カーネルを相手にするのが嫌なら, オプションは使ってはいけません. makeoptions DEBUG="-g" makeoptions COPTFLAGS="-O2 -pipe" sysctl は, 実行時にカーネルパラメータをチューニングする 手段を提供しています. しかし, 普通は sysctl 変数, 特に VM に関連したものを変更する必要が 生じるようなことはありません. 実行時の VM とシステムのチューニングは, 比較的単純です. まず, 可能ならば UFS/FFS ファイルシステムで softupdates を使いましょう. /usr/src/contrib/sys/softupdates/README のファイルに, 設定方法に関する手順(と制限)について書かれています. 次に, 十分なスワップを設定します. “作業” ディスクを含む 各物理ディスク装置毎に一つずつ (最大四つまで)のスワップパーティションを 設定すべきです. 少なくとも, メインメモリの 2 倍の スワップ空間が望ましく, メモリがあまりない場合には, おそらくそれより多く必要になります. また, スワップパーティションのサイズは, 後でパーティションをつくり直しする必要がないように マシンに設定したいメモリ設定の最大値を基準に 決めるべきでしょう. もし, クラッシュダンプをとりたい場合, スワップパーティションは最低限メインメモリと同じの大きさで, /var/crash にはダンプを保持するのに十分な 空きがなければなければなりません. NFS 経由のスワップは, -4.x 以降のシステムで完全に動作しますが, NFS サーバ側では, ページングがその負荷の主な原因になることに 注意しなければなりません. diff --git a/ja_JP.eucJP/books/handbook/users/chapter.sgml b/ja_JP.eucJP/books/handbook/users/chapter.sgml new file mode 100644 index 0000000000..34db38e0ad --- /dev/null +++ b/ja_JP.eucJP/books/handbook/users/chapter.sgml @@ -0,0 +1,507 @@ + + + + ユーザと基本的なアカウントの管理 + + + 概要 + + 寄稿: &a.nbm;, 2000 年 2 月. + + + システムへアクセスするには, かならずユーザアカウントが使われます. + また, プロセスもすべてユーザによって実行されますので, + ユーザとアカウントの管理は FreeBSD + システムにおいて欠かすことのできない重要なものです. + + + + アカウントには大きく分けて三種類のものがあります. それは, + スーパーユーザ(Superuser), + システムユーザ(system users), + そしてユーザアカウント(user accounts)です. + スーパーユーザのアカウントは通常 root と呼ばれ, + 無制限の特権を持つためにシステムの管理に用いられます. + また, システムユーザはサービスの運用に用いられ, + 最後のユーザアカウントは, + 実際にログインしてメールを読むといった作業を行なう利用者のためのものです. + + + + + スーパーユーザアカウント + + スーパーユーザアカウントは通常 + root と呼ばれ, 初期時から設定済みです. + このアカウントはシステム管理を行なうためのもので, + メールのやりとり, システムの調査, + プログラミングといった日常的な作業を行なうために使われるべきものではありません. + + + + その理由は, スーパーユーザが通常のユーザアカウントと異なり, + 操作にまったく制限を受けないことによります. + そのためスーパーユーザアカウントで操作を間違えると, + システムに重大な影響を与えてしまう恐れがあるのです. + ユーザアカウントでは, 仮に操作を間違えてもシステムを壊してしまうようなことは + できないようになっています. したがって特権を必要としていないのであれば, + できるだけいつもユーザアカウントを利用する方が望ましいと言えるでしょう. + + + + また, スーパーユーザで実行するコマンドはいつでも, + 二回, 三回と何度もコマンドをチェックしてください. + なぜならスペースが多かったり, 文字が欠けていたりするだけで, + 取り返しのつかないデータの破壊につながる可能性があるからです. + スーパーユーザになると得られる特権は, + 言い換えてみれば通常のユーザアカウントの保護を受けることができない, + ということも意味しています. + + + + ですから, この章を読んでからあなたが最初にすべきなのは, + もし用意していないなら, 日常的に利用するための + あなた自身のユーザアカウントを作成することです. + これはマルチユーザモード, シングルユーザモードを問わず, + 同様にあてはまります. + この章のうしろの方では, アカウントの追加と通常のユーザから + スーパーユーザへと移行する手順について扱います. + + + + + システムアカウント + + + システムユーザとは, DNS, メール, + ウェブサーバといった各種サービスを運用するために使われるものです. + これはセキュリティを確保するためのもので, + サービス自体はスーパーユーザで実行される場合と同様, + 制限を受けません. + + + + システムユーザの具体例として, + daemon, + operator, + bind (DNS; Domain Name Service 用) および + news といったものがあります. + またシステム管理者はよく, + インストールしたウェブサーバを運用するために + httpd + というユーザを作成しています. + + + + nobody + ユーザは通常の特権を持たないシステムユーザですが, + nobody + を利用するサービスが増えれば増えるほど, その特権も大きくなります. + + + + + ユーザアカウント + + + ユーザアカウントは, + 主に現実のユーザがシステムにアクセスする手段として用いられるものです. + このアカウントは利用するユーザとシステム環境を分離します. + そのため, システムや他のユーザに危害をおよぼす危険性をなくし, また, + 他に影響を与えることなくユーザ自身の環境をカスタマイズすることを可能にしています. + + + システムにアクセスするすべてのユーザは, + それぞれに一人一つのユーザアカウントを持つべきです. + こうすることで誰が何を行なっているかがわかりますし, + 他の人の設定を壊してしまったり, + 他人にメールを読まれてしまうようなことを避けることができます. + + それぞれのユーザは快適にシステムを利用するため, + シェル, エディタ, キー設定, 言語など, + 各自の環境をセットアップすることができます. + + + + アカウント情報の変更 + + 強力で柔軟性に富むアカウント情報の変更手段として, + pw があります. + しかし, 新しいアカウントをつくる場合は + adduser を, + アカウントを削除する場合は rmuser + を使うことが推奨されています. + + chpass を使うことで, + システム管理者, 通常のユーザはパスワード, シェル, + その他の個人情報を変更することができます. + また, 特にパスワードを変更する場合には, + 通常 passwd の方が良く使われます. + + + adduser + + adduser は, + 新しいユーザを登録するためのシンプルなプログラムです. + このプログラムは passwd と + group + に新しいユーザのエントリを作成するのと同時に, + ホームディレクトリを作成して /usr/share/skel + からデフォルトで使用されるドットファイル(訳注: + ホームディレクトリに存在する . + から始まるファイルのことで, 各種設定に用いられます)をコピーします. + また, 新しく作成されたユーザに対して, + ウェルカムメッセージをメールで送信することも可能です. + + + 初期設定ファイルを作成するには, + adduser -s -config_create. + とします + オプション をつけると, + デフォルトで詳細を表示しないように adduser を設定します. + この後に詳細を表示させるようにしたい場合は, + オプション を指定してください. + . + そして次に adduser のデフォルト設定を行ない, + 最初のユーザアカウントを作成します. + システムを日常利用する際に root を用いるのは最悪です. + + + adduser の設定の変更 + + &prompt.root; adduser -v +Use option ``-silent'' if you don't want to see all warnings and questions. +Check /etc/shells +Check /etc/master.passwd +Check /etc/group +Enter your default shell: csh date no sh tcsh [sh]: tcsh +Your default shell is: tcsh -> /usr/local/bin/tcsh +Enter your default HOME partition: [/home]: +Copy dotfiles from: /usr/share/skel no [/usr/share/skel]: +Send message from file: /etc/adduser.message no +[/etc/adduser.message]: no +Do not send message +Use passwords (y/n) [y]: y + +Write your changes to /etc/adduser.conf? (y/n) [n]: y + +Ok, let's go. +Don't worry about mistakes. I will give you the chance later to correct any input. +Enter username [a-z0-9_-]: jru +Enter full name []: J. Random User +Enter shell csh date no sh tcsh [tcsh]: +Enter home directory (full path) [/home/jru]: +Uid [1001]: +Enter login class: default []: +Login group jru [jru]: +Login group is ``jru''. Invite jru into other groups: guest no +[no]: wheel +Enter password []: +Enter password again []: + +Name: jru +Password: **** +Fullname: J. Random User +Uid: 1007 +Gid: 1007 (jru) +Class: +Groups: jru wheel +HOME: /home/jru +Shell: /usr/local/bin/tcsh +OK? (y/n) [y]: y +Added user ``jru'' +Copy files from /usr/share/skel to /home/jru +Add another user? (y/n) [y]: n +Goodbye! +&prompt.root; + + + 簡単に上の操作を説明します. + まずデフォルトシェルを tcsh + (packages にある追加のシェルです) に変更し, + 新しいユーザにウェルカムメッセージのメールを送付しないようにしました. + そしてその設定を保存し, wheel + グループ(後に, + これが重要な意味を持っていることがわかるでしょう)に所属する + jru + というアカウントを作成しています. + + + + 入力したパスワードは画面に表示されません. + アスタリスク記号も表示されませんので, + パスワードを二回とも間違えて入力してしまわないように注意してください. :-) + + + + + これ以降はオプション引数をつけず単に adduser + を起動します. + デフォルト設定を変更する必要はありません. + もし, adduser がデフォルト設定を変更するかどうか尋ねてきたら, + adduser を終了し, + オプションを使うようにしてください. + + + + + rmuser + + rmuser は, + システムからユーザを削除します. + これにはユーザデータベースからの削除だけでなく, + その他, そのユーザに依存する情報すべてが含まれます. + + + rmuser + は次の手順を実行します. + + + + 指定されたユーザの &man.crontab.1; エントリを削除 + (存在する場合). + + + + 指定されたユーザの &man.at.1; ジョブをすべて削除. + + + + 指定されたユーザが所有するすべてのプロセスを強制終了. + + + + ローカルパスワードファイルから, + 指定されたユーザのエントリを削除. + + + + 指定されたユーザのホームディレクトリを削除 + (ディレクトリの所有者が指定されたユーザのものだった場合). + + + + /var/mail + から, 指定されたユーザの到着メールファイルを削除. + + + + /tmp + のような一時ファイル保存領域から, + 指定されたユーザの所有するファイルを削除. + + + + そして最後に, + /etc/group にある + すべてのグループから, 指定されたユーザを削除します. + + + + 指定されたユーザと同じ名前のグループで, + そのユーザが削除されると空のグループとなる場合は, + そのグループ自体が削除されます. + これは &man.adduser.8; によってユーザごとに作成される, + ユニークなグループに対応するものです. + + + + + + + スーパユーザアカウントの削除に + rmuser を利用することはできません. + スーパユーザアカウントの削除はほとんどすべての場合, + 大規模なシステムの破壊を意味するからです. + + + デフォルトでは, + どういう操作を行なっているか確認できる対話モードが使われます. + + + + rmuser による対話的なアカウントの削除 + + &prompt.root; rmuser jru +Matching password entry: +jru:*:1000:1000::0:0:J. Random User:/home/jru:/usr/local/bin/tcsh +Is this the entry you wish to remove? y +Remove user's home directory (/home/jru)? y +Updating password file, updating databases, done. +Updating group file: trusted (removing group jru -- personal group is empty) done. +Removing user's incoming mail file /var/mail/jru: done. +Removing files belonging to jru from /tmp: done. +Removing files belonging to jru from /var/tmp: done. +Removing files belonging to jru from /var/tmp/vi.recover: done. +&prompt.root; + + + + + pw + + pw は, + ユーザやグループの作成, 削除, + 変更および表示を行なうことができ, + システムユーザファイルやシステムグループファイルの編集機能を持った + コマンドラインのユーティリティです. + + + + これはシェルスクリプトからの利用や, + 直接コマンドを実行する際に便利に使えるように設計されたものです. + + + 詳細はすべて &man.pw.8; に書かれています. + + + + chpass + + chpass は, + パスワード, シェル, その他の個人情報といった, + ユーザデータベース情報を変更します. + + + システム管理者に限りスーパユーザ権限で chpass を用い, + 他のユーザの情報やパスワードを変更することが可能です. + + + ユーザ名の他にオプションを指定しないと, + chpass + はユーザ情報を編集するエディタを表示します. + そのエディタを終了すると, + chpass + はユーザデータベース情報の変更を試みます. + + + + スーパユーザによる対話的な chpass + + #Changing user database information for jru. +Login: jru +Password: * +Uid [#]: 1000 +Gid [# or name]: 1000 +Change [month day year]: +Expire [month day year]: +Class: +Home directory: /home/jru +Shell: /usr/local/bin/tcsh +Full Name: J. Random User +Office Location: +Office Phone: +Home Phone: +Other information: + + + 通常のユーザは, この情報の限られた部分のみ変更が可能です. + また, 変更できるのはそのユーザ自身の情報のみです. + + + + 通常のユーザによる対話的な chpass + + #Changing user database information for jru. +Shell: /usr/local/bin/tcsh +Full Name: J. Random User +Office Location: +Office Phone: +Home Phone: +Other information: + + + + chfn, + chsh はいずれも, + 単に chpass へのハードリンクになっています. + また, ypchpass, + ypchfn および + ypchsh も同様です. + NIS のサポートは自動的に行なわれますので, + コマンドの先頭に yp + をつける必要はありません. + + + + + + passwd + + passwd は, + ユーザが自分のパスワードを変更する通常の方法です. + スーパユーザ権限では, + 他のユーザのパスワードを変更するのに使われます. + + + + ユーザはパスワードを変更する前に, + もともと設定されていたパスワードを入力しなければなりません. + これはユーザがコンソールを離れた際に, + 不審な人物によってパスワードが変更されることを防ぐためです. + + + + + passwd + + &prompt.user; passwd +Changing local password for jru. +Old password: +New password: +Retype new password: +passwd: updating the database... +passwd: done + +&prompt.root; passwd jru +Changing local password for jru. +New password: +Retype new password: +passwd: updating the database... +passwd: done + + + + yppasswd は, + 単に yppasswd へのハードリンクになっています. + NIS のサポートは自動的に行なわれますので, + コマンドの先頭に yp + をつける必要はありません. + + + + + + ユーザへの制限と設定 + + quota がシステムで有効化されていると, + システム管理者はディスク使用の上限を設定し, + ユーザは自身のディスク使用量をチェックできるようになります. + quota については, quota + の章に書かれています. + + 地域化(localization)とは, + それぞれ異なる言語, キャラクタセット, + 日付や時間の標準などに適応させるための環境設定を, + システム管理者やユーザが行なうことを指します. + 地域化については, + 地域化の章に書かれています. + + + +