連載 UNIX Communication Notes—O す技術も必要になる。多くの研究者がこれらの技術の開発 に挑戦しているが、これはという角夬カ 1 去はまだできてい ない。事実、筆者も Mosaic を利用していて使いにくさを 感しることがある。たとえば、かなりの数の WWW サー バーが世の中にあることは分かっているが、各サー にどのような情報か蓄えられているかを矢可間にかっ白寉 に孑巴屋する方法はいまのところない。たしかに、 anony- mous FTP アーカイフて提供されているファイル群を効 率的に発見するためのオ冓として、 X. 500 ディレクトリ・ サービスを用いたシステムか試作さ独自の機構を用い たシステムもいくつか開発されている。しかし、それらの システムがひろく普及しているわけではない。情報資源を 発見する技術の確立を強く願っている。 ほかの世界との融合 もう 1 つ、最近の注目すべき動向として、 AppIeTaIk や NetWare など、 TCP/IP とは異なる世界と共存共栄 するための技術がさかんに開発されていること力げられ る。たとえば、 AppleTalk と TCP/IP の共存を実現す るシステムとしては、フリー・ソフトウェアとして提供さ れている CAP か有名である。これを使えば、 AppleTalk て接続されたプリンタを共有したり、 UNIX ワークステー ションを Macintosh のファイルサーノヾーにすることが できる。また、 NFS/NetWare ファイルサーバー・プロ トコル変換ゲートウェイも、商品として市販されるように なった。 こういった、異なるプロトコル・ファミリー間での融 ・ X ウインドウ・システムエ竟の共有 ・プリンタなどの周辺機器共有 ・ファイル共有 支術には次のようなものがある。 26 よりいっそう一ヨ殳化することを期待している。 壜冓築を進める者にとって魅力的であり、この種の技術が ーズに合った工竟か構築できるようになる。これは、環 いた UNIX システムと PC の世界が融合し、利用者の これらの技術かンヨ殳化すれは、いままて憫係か聨色して 交換など ) ・メールの交換 (RFC822 メールと Lotus cc メールの ネットワーク管理 ネットワーク管理では、 SNMP を用いたシステムが一 般に利用されるようになってきた。たとえば、 Sun Net- manager などを使って、組織内ネットワークの監視と管 理をおこなっている組織も増えてきた。描丘のネットワー ク機器の大半は SNMP に対応しているため、 SNMP を 使えばネットワークのだいたいの管理かできるようになっ てきている。ネットワーク管理ツールもウインドウ・シス テムを用いた強力なものが多く、管理者がネットワークを 構成する機器の状態を詩ヾたり、設定を変更したりといっ たことか簡単にできるようになった。 ネットワーク管理の内容を大別すると、 ・構成管理 ・障害管理 ・セキュリティ管理 などに分けられる。 SNMP では、障害管理のうちのシス テムの監視機能と、簡単な設定変更ができる機能を提供し ているにすぎない。したがって、残りの機能をどのよう に実現するかカ吠きな間題となる。これらを麪爰するシス テムも、わすかではあるか登場しつつある。たとえは構成 管理では、ネットワークの回糸霜 - fl 画が適切かどうかをチェ ックするシステムか市販されるようになった。障書管理に ついても、エキスパート・システムを利用して、問題解 決を自重川ヒするシステムが開発されている。このような、 SNMP の枠から外れた部分でのネットワーク管理ツール の充実が、今後必要になるであろう。 おわりに 今回は、筆者の豸斤と偏見にもとづく、、蜷丘の注目すべ き技術 " を駆足て眺めてきた。もちろん、言田に説明した わけではないので、分かりにくい面も多かったと思う。し かし、ご安じ、を。今回紹介した技術については、今後の連 載のなかで偵次とりあげていく予定である。 ( やまぐち・すぐる奈良先端科学オ麪析大学ギ完大判 UNIX MAGAZINE 1994.5

図 2 dumpdates 」 ます。 fork するのはテープ装置を休みなく駆動するため /dev/rsd0g で、 4.3 BSD の dump て導入された機能です。優先度を /dev/rsdOa 自重加勺に上げるのは、バックアップ竹喋を早く終えるため /dev/rsdOa です。 /dev/rsd0g /dev/rsdOa dump は、使用中のファイルシステムに対して実行して /dev/rsdOg はいけません。読出しだけならいいのですが、書込みカ起 /dev/rsd0g /dev/rsdOa こると dump の出力に矛盾が生しることがあります。ほ とんどの場合、 dump 自体は正常に終了するのですが、あ dump は、 /etc/dumpdates に各ファイルシステムの とでテープを読もうとすると、 restore がエラーを出した レベルごとのバックアップ実行日時を言求しています。同 りします。 100 % 安全なのは、シングルューザー・モード ーレベルに関しては、最後におこなわれた日時だけカ蠢求 か、さもなければファイルシステムをアンマウントした状 されます。図 2 がその例です。 sd0 の a と g パーティショ 態での dump です。 ンを、 90 年 7 月にレベル 5 、 93 年 1 月にレベル 0 、 94 安全にダンプをおこなおうとすると、その間ファイルシ 年 2 月にレベル 1 、 94 年 3 月にレベル 4 でバックアッ ステムかイ吏用できなくなります。ということは、システム プしたことが分かります。 管理者はダンプをとる日ごとに最後まて残って残業しなけ ダンプレベルれでは、過去におこなわれたレベルれ未 ればなりません。また、ワークステーションの 24 時間運 満のダンプのうち、最後におこなわれたものの日該リ以降に 用サービスもできなくなります。 変更されたファイル ( レギュラー・ファイルだけでなく、 そこで、危険を覚語で使用中のファイルシステムのダン ディレクトリやスペシャル・ファイルも ) をバックアッフ プをとることもかなりおこなわれています。もちろん、フ します。たとえば、さきほどの例で sd0g に対してレベル ルダンプだけはけくなくとも 1 回は ) シングルューサー 5 のダンプをおこなうとします。 5 末岡ですから、レベル モードでとっておかなければなりません。計算サービスを 0 、 1 、 2 、 3 、 4 を捜すとそのうち言当求があるのは 0 、 1 、 停止できなくてダンフ。がとれないよりは、多少危険はあっ 4 で、もっとも山も丘おこなわれたのはレベル 4 だと分かり ても頻繁にインクリメンタル・ダンプをとるほうがよいと ます。したがって、 1994 年 3 月 14 日 22 時 29 分 58 秒 いうわけです。 以降に変更 ( あるいは新規作成 ) されたファイルがダンプ タンプレベル の対象となります。 指定したレベル未満のダンフ。言当求が dumpdates にみ dump は、差分バックアッフ ( インクリメンタル・ダン っからない場合 ( 指定したレベルが 0 のときも ) には、 力をおこなうために、ダンプレベルという概念を導入し 1970 年 1 月 1 日 0 時 0 分 0 秒 (GMT) 以降に更新 ています。このレベルは、 0 ~ 9 の 1 桁の整数です。 dump されたファイルが対象となります。この日時は UNIX に は分かりにくいといって tar を使うシステム管理者もけっ とって世界倉慥の日該リ (The epoch) であり 2 、けっきょ こういるようですが、その原因がダンプレベルの概念にあ くファイルシステム本のバックアップ ( フルダンフ ) と るようです。 いうことになります。 1 回ファイルシステム全体のバックアップをとってお インクリメンタルなダンプの必要性は、ディスクの容 き、日常的には変化があった部分だけのバックアップをと 量とテープ 1 巻に入るデータ量の差が大きいとき、そし るというのがインクリメンタル・バックアッフ。のアイテア てテープ 1 巻の価格か高いときに強くなります。やはり、 です。ーヨ殳に、ファイルシステムのうち更新されたり新た テーフ。装置の前で待っていて、テープを掛け替えるのは手 に作られるファイルは少なく、大多数は一度作られるとそ 間がかかるし、バックアップは重要だといっても予算は限 のまま更新も消去もされす凵尉寺されます。ですから、変 イ凵ゞんだけならはバックアッフ。竹喋も速く終るし、テープ 2 UNIX の時咳含理は、 Jan 1 00 : 00 : 00 GMT 1970 から数えた秒 の消費量も少なくてすむわけです。 数によっておこなわれています。 3 3 4 4 0 0 4 4 9 9 9 9 9 9 9 9 9 9 9 0 ) 9 1 6 0 8 0 9 3 5 3 0 4 5 5 5 4 0 0 8 8 9 っ 4 3 5 っ ) 8 9 2 2 4 4 0 7 6 5 4 4 5 5 3 3 CQ X tn tn t.n 0 0 4- 4- 一 LO -1 -1 108 UNIX MAGAZINE 1994.5

してください。 ・ X サーバーのなかで管理するウインドウやピクセルマッ それでは次に本題へ・・・・・つと、いつもならここですぐさ プなどの資源 ま外字を追加する話に入るところなのですが、その前にも ・ユーサーがカスタマイズ可能な要素 う 1 つ別の話題ーーー X ウインドウ・システムのリソースに ついてお話ししておきましよう。 今回紹介するリソースは後者で、、、ユーサー・フリファレ ンスクと呼ばれることもあります。 「外字を使う話なのに、どうして X のリソースがでしやば 以後の節では、 X のリソースを利用してさまざまな設定 ってくるの ? 」 をおこなう方法や、リソースを設定するためのコマンドに 「それはね、 MuIe で外字フォントを使う話の伏線なんだ ついて説明します。また、同じ設定を初期化ファイルに記 述した場合とリソースに設定したときの違いについても触 れることにします。 Emacs の話題からはすこし逸れてし まいますが、道草を楽しんでください。 リソースとリソースファイル ウインドウ・システム上のアプリケーションには、ユー ザーがカスタマイズしたくなる要素が溢れています。たと リソースは、リソース・データ ~ ース " と名付けられ 0 えば、ウインドウの大きさや位置、タイトルバーやスクロ データベースに保存されていて、、、リソース・マネージャー ールバーの形状や色文字の大きさやフォントの種類など が管理しています。ただし、リソース・データベースもリ など。アプリケーションのなかには、複数のウインドウを ソース・マネージャーも概 ] 勺なものです。ー殳のデータ 開いたりメニューやボタンを備えているものもあるので、 べース・システムのようにファイルシステム上にデータベ ウインドウやメニュー、ボタンの数が増えるとそれだけカ ース・ファイルを作ったり、データベースを管理するプロ スタマイズできる要素も多くなります。 グラムが走りまわるわけではありません。強いていえば、 X のアプリケーションのはとんどは、カスタマイズ可能 X ウインドウ・システムのなかに存在する情報と、その情 な要素をコマンド行オフションで指定できるようになって 報にアクセスする処理の集合のことです。 います。 リソースは X ウインドウの世界に存在する情報なので、 ふだんはユーサーの眼に触れることはありません。ューザ 「それはそれはけっこうな、ユーサーの自由度が増えてよ ーから見えないものを、ユーサーにカスタマイズさせよう かったしゃん」 というのはちょっと無理な話ですね。そこで、一殳的には いえいえ、現状を考えると手放しで喜んでばかりはいら リソースファイルにリソースの記述をおこない、このファ れません。ウインドウやメニューが増えれは、ユーサーが イルをリソース・データベースに読み込むようにしていま カスタマイズできる対象がそれだけ飛躍的に増加してし す。リソースファイルのほうは UNIX のファイルシステ まうからです。 ム上のファイルなので、ユーザーは普通のファイルと同様 に内容を見たり編集することが可能です。 たとえば、 X ウインドウ上のあるプログラムは、 100 不頁 を超えるカスタマイズ可能な要素をもっています。これだ リソースファイルをリソース・データベースに読み込む けの数のカスタマイズをコマンド行オフションだけに頼る には、コマンド、 のは、もはや現実的ではありません。そこで、 X ウインド xrdb ウ・システムではアプリケーションに対して与えるオプシ ョンを管理する仕組みを提供するようにしました。これが を使います。 xrdb はリソースファイルをリソース・データ 、、リソース〃と呼ばれるものです。 べースに翫み込む以外に X ウインドウ・システムの世界ではリソースを 2 不亟頁の 意味で使っています。 ・現在のリソース・データベースの内容を表示する ・特定のリソースを追加 / 削除する UNIX MAGAZINE 1994.5 emacs 入門 VX のリソース 136

ワークステーションの基礎知識 ( 11 ) はたして、これは情報工学利・らしいのか、らしくないの インフレームのバッチの角見書などはありません。 した。書庫を捜しても学術書はけっこうあるのですが、メ イつなくなり、昔のマニュアルもすっかり捨ててしまいま すむので、大型言 t 算機センター ( メインフレームです ) も ていの仕事が PC かワークステーションを使っていれば のバッチに関する資料か研究室にありません。しかもたい 計算機環竟は UNIX に変わってしまい、メインフレーム したのです。 1983 年に VAX-II を導入して以来、哮利の 文 DD を例にあげました。しつは、あの例を捜すのに苦労 ところで前回、メインフレームのジョブ・コントロール いぶん、暖かいのはいいのですけど・ ネクタイは首か締めつけられていけません。空気が逃げな にネクタイ、革靴という服装か檄増したんですが、どうも 引青報処理教育センターに異動しました。それで、スーツ その前に私事で恐縮てすが、 2 月 1 日イ寸で情報 : I : 学科か dump をとりあげます。 テープを使うアプリケーションについての解説の続きで、 お元気でしようか ? 今回は磁気テープの第 4 回目です。 WO R KSTATION? WHAT 磁気テーフ -4 齊藤明紀 悩んでいるうちに、ふと思い出しました。 IBM UNIX MAGAZINE 1994.5 tar 、 dd の次は dump/restore です。 dump 認できたのでした。 かくして、 dd はやつばり DD の真似だということカ毓 くれました。 いたかったのに ・・・」と思痴りながら、解説本を貸して かいたはす ! さっそく行って問い質すと「うう。忘れて のメインフレーム絡みのアノレヾイトをしていた学生がたし dump はファイルシステムのバックアップをとるツー ルです。特徴を列挙すると以下のようになります。 ・バックアッフ。の対象 ( 単位 ) がファイルシステムである。 デバイスファイルなど特殊ファイルのバックアップが できる。 ・変更されたファイルだけを取り出す嗟分ダンカこと カそきる。 ・システム管理者 (root) にしか実行できない。 これは、ファイルシステムの内音財冓造に立ち入った重川乍 をするからです。 大きなファイルシステムのバックアップをとるために 出力を複数巻のテープに分割する機能をもつ。 ・テープを読む機能がない。 dump で作成したバックアップ・テープを読み取るに は restore という別のツールを用います。 ・テープ装置をもたないワークステーションから、ネ ットワーク越しにバックアップをとることができる (rdump)o 機種ごとの違いがかなりある。 dump の引数 dump の引数の形式は、 tar と似ています。 dump キー文字 [ オプション列 ] [ 引数 ] [ 引数 ] [ ファイルシステ ム ] となり、最後にファイルシステムを 1 つだけ指定する点 が tar とは違います。 dump の第 1 引数はキー文字て始 まります。これは 0 ~ 9 までの霆ネで、あとで説明するダ ンプレベルを表します。 105

連載 / ・ IJN Ⅸ Communcation Notes—の ワーク竟が大莫化すればするはど不可欠なものとなろ う。 NIS 十のような、新たな考え方にもとづく分昔のア カウント情報管理システムカ球められるようになる日も近 いだろう。 ファイル 通常、ネットワーク竟では NFS を用いてファイル 共有機能を実現している。 NFS はほとんどの UNIX シス テムに実装さ匠では PC や Macintosh などでも使 えるようになりつつある。つまり、 NFS はごく一難勺な ファイル共有システムと捉えることかできる。 しかし、 NFS には、広域ネットワークのようなイ時玉な ネットワークではうまく機能しないという間題がある。 れに対処するには、次の 2 通りのガ去がある。 1. 広域ネットワークを偂醍とした分散ファイルシステムの 利用 2. プロトコル変換とキャッシュ技術にもとづく分散ファ イルシステムの利用 前者の代表例が AFS (Andrew File System) で ある。後者には、筆者らのグループが開発している WWFS (World Wide File System) や CMU か開発 した AIex などがある。これは、広域ネットワーク向きの プロトコルを用いてファイルを遠隔アクセスし、 LAN に 対しては NFS のような LAN に合ったプロトコルでファ イル共有機能を提供するものである。 NFS では、セキュリティ強化も課題となっている。最 近の NFS は Secure NFS プロトコルを採用し、ネットワ ーク上での情報漏れを防ぐような機構が導入されている。 ューサーの認証などの問題も Kerberos を用いて解決で きるが、国内では一イ勺な手法とはいえない。ファイル共 有機溝でのセキュリティ機能の強化は、早急に角共しなけ ればならない言翹である。 メッセージ交キ術 電子メールや電子ニュースなどのメッセージ交支術 における最近の大きな変化は、マルチメディア化である。 MIME と呼ばれるマルチメディア・メールの書式カ夬め らこれに匙したマルチメディア・メールを作成した り表示させたりするためのシステムが使われるようになっ 24 た。この書式を用いたマルチメディア・ニュースも、イン ターネットで IIJ が運用しているニュースグループ tnn などでみかけるようになった。 UNIX MAGAZINE 1994.5 いて超並列システムか構成できるという可能生は魅力的で ろく一ヨ殳に使えるわけではない。しかし、既存の竟を用 PVM のようなシステムはまだまた形全 . 上て、あり、ひ 管理するイ督はみになっている ( 図 4 ) 。 モンが各システムに割り当てられる並列処理部分の処理を ムでは、 PVM デーモンが各システムで下力し、このデー (Parallel Virtual Machine) カリ用できる。このシステ このような環境を構成するシステムとしては、 PVM ができる竟を作りだそうとすることである。 っくのが、複数台のワークステーションを使って並列処理 が大量に導入される竟か現実のものとなると、次に思い ネットワークか高速化ささらにワークステーション 並列里技術 れる。 ィ機能の実現は、よりいっそう重要になっていくと思わ えると、 PEM のようなメッセージ交換でのセキュリテ 麦のインターネットの普及と商用サーピスの充実を考 トではできないことが可能となる。 号を記して商品を注文するといった、朋大のインターネッ な技術が一ヨ殳化すれば、電子メールにクレジットカード番 ューザー名の詐称などか防止できるようになる。このよう これらの技術を使えば、電子メールの改竄や盜聴 ( 盗初、 ルにおけるセキュリティを向上させる 1 つの技術である。 とえば、 PEM(Privacy Enhanced Mail) は、電子メー 子メールにおけるセキュリティ機能の強イ支術である。た もう 1 つの大きな動きが、メッセージ交換、とくに電 テーション環竟が、標ま勺になっていくであろう。 ルチメディア情報の充実した編集環竟も提供するワークス に、マイクやスピーカー、テレビカメラを標準でもち、マ 増えてくるにちがいない。たとえば、 SGI の lndy のよう レビカメラや高速フレームバッフアなどを備えたマシンも 標準で装備されているものが多くなってきたが、今後はテ UNIX ワークステーションには、マイクやスピーカーが 表カ竟に対する要求を増大させる。現在市販されている ワークステーションでのマルチメディア情報の生成・編集・ このようなメッセージのマルチメディア化は、一方で

連載 Windows NT 五十嵐久和 セキュリティ NT のセキュリティ機能 Windows NT ( 以下 NT と略 ) のセキュリティ機能 は、米国政府の定めたセキュリティ基準の C2 レベルを満 たしている。『Ⅵⅱ n32 API リファレンス』によれば、 れは次の条件をクリアしていることを未する。 ・ファイルなどの資源のアクセスを個々のユーザー単位、 グルーフ。単位て管理できる。 プロセスカ埆早放したメモリから情報がリークしない。 ・ログオン時のユーザー識別が 1 つの方法でおこなわれ る。 ・特定の操作カ当求さオ L 、システムの監査ができる。 ・システム自体が一されている。 今回は、 NT がこれらのセキュリティ機能をどのように 実現しているかを、 UNIX と上交しながらみていくことに しよう。 UNIX でのセキュリティ ューザー側からみた場合、 UNIX の基本的なセキュリ ティは次のようになる。 ・ログイン・プロンプトに対してユーサー ID とパスワー ドを入力し、ログインする。 UNIX MAGAZINE 1994.5 これをシステム側からみると、 ついて、それぞれ独立に許可が - ドりる。 ファイルごとの読み、書き、実行という 3 つの操作に 使用できる。 ・自分のユーサー ID 、グループ ID をもっプログラムが 1. ューザー名に対してパスワードが正しいかを石薩忍する 2. ューサー ID 、グループ ID をセットしたシェルを起動 する 3. シェルなどのプロセスから子プロセスにユーサー ID 、 グループ ID を継承させる 4. ファイルごとに所有者のユーザー ID 、グループ ID を 管理し、所有者、グループ、それ以外について、読み、 書き、実行という 3 つの権限の有無をモードとして記 録する。ファイルをアクセスするフロセスのユーザー ID 、グループ ID により、そのプロセスのもつ権限を 判定する ドを入力し、そのユーザーであることを石忍後、ログオ システムの提供するダイアログにユーサー名とパスワー セキュリティと同じ手順でおこなわれる。 のコンピュータ上て考えるかぎり、基本的に UNIX での ューサー側からみた NT のセキュリティ管理は、単一 NT でのセキュリティ という流れになる。 ID 情報 アクセス制御 を証明する情報 ( アクセストークン ) をもつ。 ログオンの結果、ユーサーの各プロセスがユーザー ID ンする。 75 ト ) の各工ントリ ACE (Access Control Entry : ア 報が、 ACL (Access Control List : アクセス制御リス ファイルなどのオプジェクトについて、ユーザー ID 情

表 1 連載 /Windows NT—O UNIX と、 Vindows NT での用語 ID 情報 アクセス制御 UNIX ューサー ID とパスワード ログイン・プロンプト ューザー ID とグループ ID ューザー ID ファイノレ モード モードの各ピット 画面 3 アカウントの原則 ドメイン : パスワードの有効第澗 0 無期限 ) ・有効其脆匯 ) 日 パスワードの長さ 0 バスワードなしを許可但 ) ・最低 ( リ [ 当文字以上 パスワードの変更禁止 0 なし ( △ ) ◎禁止其躙 0 バスワードの一意性 0 バスワードの履歴を記録しない 0 ◎記録 ( 望 [ 亘 : 当 バスワードまで 日 ロログオプ靴 1 を超過したら強簫旧りにリモートユーザーをセ靆斤旧 NT ューザー ID とパスワード ログオン・ダイアログ アクセストークン ューサーのセキュリティ ID オプジェクト ACL ( アクセス缶雅卩リスト ) ACE ( アクセス匍衂工ントリ ) アクセス制徊ⅳスク ファイル、メモリマップ、名前付きパイプ、プロセス、 アクセス権の判定 ティ ID にはヌルなど特殊なものもある。 に対するアクセス権の管理か確実になる。なお、セキュリ てられる。これによって、削除されたユーザーのファイル ついては、画面 3 のように、有効月限、有効なパスワード など、各種の原則を設定することができる。 ログオンに成功すると、ユーサーのプロセスには、、アク セストークン " が与・えられる。これは UNIX のユーサー ID とグループ ID の組合せに相当するもので、ユーサー ID 、グループなどのセキュリティ ID と牛罸 ( 彳幻から なる ( 図 1 ) 。 アクセストークン UNIX MAGAZINE 1994.5 のユーサーを登録しても、別のセキュリティ ID カリり当 のユーサーに割り当てられることはない。たとえ同し名前 されたユーサーのセキュリティ ID としてイ求さはか る。このユーサーを削除すると、セキュリティ ID は削除 クであり、あるユーサーやグループを登録すると生成され セキュリティ ID は、ドメインまたはシステムでユニ でファイルアクセスをするような場合に使用する。 えは、ファイルサーバーがクライアントのユーザーの権限 アントのもつ権限でのみ重川乍するためのものである。たと の一部としての権限をもつサーバー・プログラムがクライ ation) アクセストークン " がある。偽装は、本来システム 効ューサー / グループ ID に相当する、、偽装 (imperson- る、、プライマリ・アクセストークン " と、 UNIX でいう実 アクセストークンには、本来のアクセストークンであ スレッド、セマフォ、サーピス、ウインドウ、 Registry デ ータベースのエントリなどのシステム上の名前をもつ、、オ プジェクト " には、セキュリティ・ディスクリプタを添付 することができる ( 名前をもたないものの一一部にも添付可 能 ) 。なお、オプジェクトとは NT システムからみた場合 の用語で、 OLE や C 十十などのオプジェクトとは異なる。 また、ウインドウ、ペンなど W ⅲ dows でのオプジェクト とも意味が違う。名前をもつオプジェクトは、 UNIX の ファイル件朱ファイルを含む ) を拡張したものと考える ことができる。事実、オプジェクトの名前は、 UNIX の ファイルシステムと同様の階層構造をもっている。 セキュリティ・ディスクリプタには、所有者のユーザー ID とグループ ID か書かオ L 、 ACL が置かれる。所有者 のユーザー ID とグループ ID は、ファイル作成時などに セットされ、 POSIX 互換工竟を寒見するといった目的で 用いられる。これに対し、アクセス管理に使われ、一ヨ殳に 重要な意床をもつのは ACL のほうである。 ACL は、 ACE の列から構成される。 ACE には、ア クセス許可、不許 - 可、監視 (Audit) の 3 不鶤頁があり、誰 に ( セキュリティ ID ) 、何を ( アクセス制笹をスク ) とい う情報が追加されている。アクセス制御マスクは 32 ビッ トのデータで、読み書き、実行、削除、同期 ()T では、 ファイルなどはとんどのオプジェクトに対する wait が可 能 ) などカ甘旨定できる。 アクセス権は、 ACL の先頭からセキュリティ ID を 77

もとの argv[O] になります。 errno が ENOEXEC であ ることを確認していますが、これは、ファイルは存在し たがバイナリ形式の実行ファイルではなかった " こと を示しています。その場合には、 INTERP マクロに定義 されているシェルを実行します。 リスト 1 のプログラムではシェルと同様な操作をおこ ないましたが、インタープリタ形式のファイルが連鎖し ているときに、それらを次々と調べて実行するプログラ ムを作ることもできます ( リスト 2 ) 。このプログラムに ついて簡単に説明しておきましよう。 execve に失敗して、かっそのときの errno の値が ENOEXEC の場合にのみ実行することや、何かに失敗し たときに execve のエラーコードである一 1 を返すのは、 リスト 1 のプログラムと同様です。ファイルがインター プリタ形式のものならば、引数の準備をして interp を 再帰的に呼び出しています。再帰的に呼び出すために、 同しファイルをインタープリタとして呼び出さないよう な工夫もしています。この関数を実行した場合、 errno の値が execve の設定するものと異なることがあるので 注意してください。 ちょっと脱線してしまいました。話をファイルの実行 に戻しましよう。シェルでは、シェル自身は生き続けな がらはかのプロセスを起動しますが、 exec だけを用い たのではこれは実現できません。このためにシェルは、 fork と exec を組み合わせて使っています。 fork により 子プロセスを作り、子プロセスがすぐに exec を実行す #include く stdio . h> たとえば、次のようになります。 るのです。 main ( ) int pid; if ((pid = fork()) く 0 ) { fprintf (stderr , exit(l); 土 f ・ (pid = execlp("/bin/ls" " ,/vmunix" fprintf (stderr , ( char "fork く "exec failed\n") ; 164 exit ( 0 ) ; printf ( "Parent\n" ) ; exit(l); このプログラムでは、 fork で作成した子プロセスで execlp を実行しています。そのため、親プロセスでは ほかの処理がおこなえます。ここではメッセージを出力 しているだけですが、シェルでははかのプロセスを起動 したりューサーからの入力を待ったりしています。 メモリの節約 さきはどの例では、 fork した直後に exec を実行しま した。 fork を実行すると、現在のプロセスのイメージが そのまま子プロセスにコピーされます。しかし、すぐに exec を実行してその内容を破棄してしまうのであれは、 このコピーはむだです。このような場合には、 fork の代 わりに vfork システムコールが使えます。 vfork システムコールは、基本的には fork システム コールと同様に働き、戻り値も rk システムコールと 同じ意味をもっています。また、子プロセスとして新た にすべてのコピーを作成するのではなく、親プロセスの 一部を使いながら処理を続けます。そのため、 vfork は fork にくらべてかなり軽くなっています。 しかし、いくら f 。 rk と同様に機能するとはいっても、 1 つのアドレス空間を親プロセスと子プロセスが共有す るのでいくつかの制限はあります。子プロセスが exec するか exit するまで、親プロセスは動作しません。ま た、子プロセスは vfork を呼び出した関数を終了するこ とはできません (return を実行すると最悪の場合暴走す るおそれがあります ) 。 しかし、プロセスが巨大でなおかっすぐに exec して メモリの内容を捨ててしまうのであれば、 vfork を使っ たほうがよいでしよう。さきはどの例では、 fork の代わ りに vf 。 rk を用いることができます。 標準入出力と終了方法 こまでの説明では、親プロセスと子プロセスの標準 入出力に関しては触れませんでした。これらはどうなっ ているのでしようか ? 親プロセスと子プロセスの両方が 標準出力に対して出力をおこなうとき、親プロセスはも ともとのプロセスなので標準入出力が通常の状態になっ ていると容易に想像できます。では、子プロセスの標準 入出力はどうでしよう ? 結論からいうと、標準入出力 ( と標準ェラー出力 ) は親プロセスのものをそのまま受 け継いでいます。 fork により作成された子プロセスは、 UNIX MAGAZINE 1994.5

めには、出力ファイル名をカンマで区切って倥白を入れ る ) 書き並べます。たとえば、 dump 0f /dev/rstO , /dev/rstl , /dev/rst2 /usr/src とすると、 3 つのテーフ。装置を順に使用します。装置の台 数以の巻数のテーフ。が必要な場合には、最後に指定した 装置か不足する巻数ぶんだけ繰り返し使われます。 OSF/I 不劫ゞ調べたのは DEC の Alpha AXP 用 OSF/I VI. 3 ですが、同 bDEC の Ultrix の dump とはまったく異 なるようです。 4.3BSD の dump と機能的にはかなり似 ています。とはいえ、マニュアルページは一から書き直さ れているし、バークレイのクレジットがどこにも入ってい ないので、おそらく dump コマンド自体も一から書き直 されたのでしよう。 変わっているのは、引数の形式です。 dump —Ou —f /dev/rmtOh —B —S 600000 /usr という普通の形式に変わっています。ただし、従来の dump と同じ形式でも受け付けるようになっていて、 れは第 1 引数がマイナスて始まっているかどうかで決ま ります。上と同等な引数は、 dump OufBS /dev/rmtOh 600000 /usr -B -S 600000 " は、ポリュームの記・慮容量を 600 , 000 KB と指定します。 -B フラグがないときは、 -s は -s と 同じです。 DEC がサポートしているテーフ。装置に関しては、テー プの言求密度は自重加勺に判別されます。 dump のスケジュール ファイルシステムのバックアップをとる目的は 2 つあ ります。 1 つは、ハードディスクの嶂などでファイルシ ステムカれたときにその内容を復旧するためです。ほと んどの場合、バックアッフ。の目的はこれです。もう 1 つ の目的は、ファイルの内容の保存です。つまり、ファイ ルを間違って消したり変更したりした場合に、昔の内容を 112 取り戻すためです。 す。たんなるディスク・クラッシュ対策ならは、フルダ 前者と後者の違いは、古いダンプテープの保存期間で ンプをとった点でそれまでのダンプテープはすべて不要 になり、次のダンプのために再使用できます。後者の場合 には、バックアップしたテープを保存しなけれはならず、 新しいテープを順次消費します。 既述のように dump はレベルを 10 もっていますが、 通常はこれを全部は使いません。ー殳に、ダンフ。のレベル を多く使うと、ダンプテープの量カ眇なくてすみます。そ の代わりディスク・クラッシュからの復旧をおこなうに は、全レベルのダンプテープを順次書き戻さなければなら す手間がかかります。 たとえば、毎月 1 日にはフルダンプをおこない、この テープは永久保存することを考えます。そして毎日終寺 : にバックアップをおこない、過去 1 週間のあいだはどの 日の状態にでも、 1 週間前から 4 週間前までは瞿の状態 には戻せるようにしたいとします ( 週休 2 日を想定 ) 。 もっとも簡単なのはテープを 10 組使い、毎日フルダン プをとることです。数 IOMB の小さなファイルシステム ではこれでもいいでしようが、大きなファイルシステムで は日肋ゞかかりすぎます。 そこで、 - 翁瞿にはレベル 1 、そオリ丿、外はレベル 4 のダン プをおこなうことを考えてみましよう。つまり、金曜には 1 日からの差分を、それ以外の日は翁瞿からの差分をバッ クアップします。このようにすると、月、火、水、 : 瞿日 の dump はあまりテープを消費しません。 ダンプレベルは 0 、 1 、 4 の 3 不鶤頁を使っていますから、 ファイルシステムの復旧には 3 段階の ( 乍業が必要です。た とえば 3 月 17 日材瞿日 ) にディスクの古章か起きたと します。新しいディスクを newfs して、ます 3 月 1 日の フルダンプ、 3 月 11 日 ( 瞿日 ) のレベル 1 ダンフ。、 16 日のレベル 4 ダンプのテープを順に戻すと、ディスクの内 容は 16 日の状態にまて彳夏旧できます。 dump とペアになる restore もとりあげたかったので すが、誌面が足りないようです。次回は、 rdump などダ ンフ闕連の残りと restore をとりあげます。 0 ( さいとう・あきのり : 邸反大学 ) UNIX MAGAZINE 1994.5

S 00 AUSPEX 高速大容量ファレサー謇、、 大容量データをシンプレな管理で、より高速に ! より多くのユーザに ! Auspex ファイルサーバは全世界て 1 , 000 以上ものシステムが現在稼働中。ハイ ■仕様 パフォーマンス、高信頼性を約束します。 ディスク容量 最大 180GB ( 拡張キャビネット ) FDDI/CDDI 最大 4 ポート Auspex 社独自開発の FMP (Functional Multi Processor) アーキテクチャ ィーサネット 最大 8 セグメント により、イーサネット I / O 部、 FDDI I/O 部、テンスク I / O 部、ファイルシステム部が ホストプロセッサ SunOS 完全にパラレル同時処理される為、最大 4 ポートの FDDI 、 8 ポートのイーサネ 32MB ~ 256MB プロセッサメモリ レ 0 キャッシュメモリ 16MB ~ 384MB ットをほば同時に飽和させる程の高速大容量 NFS パフォーマンスの威力を発 ストレージプロセッサ SCSI インターフェース 揮します。 10 本 ( 標準 ) ~ 30 本 ( 拡張キャビネット ) NFS パフォーマンス 2,037SPECnfs-A93 Ops/Sec@46.5msec また、スク I / 0 部においては RAIDIO 、ホットフラガビリティー機能及び支障 ( ィーサネット 8 本時 ) が発生したときそのファイルシステムを自動的にシステムから切り離すファイルシス 寸法 高さ 193.05 幅 61.05 テムアイソレーション機能を標準装備し、 2 重化電源 ( オプション ) などファイルサ 奥行 100.55 ーバとして細部に至る充実した信頼性を同時に提供します。 重量約 440kg 製品名等の固有名飼は各社の商標または登録商標です。 日商工レクトロ二クス株式会社 お問い合わせ先 財ープンシステム事業部・ネットワークコンビーティング営業部 A COMPANY OF NISSHO IWAI GROUP 〒 1 東京都中央区築地 7-3-1 ・ TEL : 03 ( 3544 ) 8332 ・ FAX : 03 ( 3544 ) 8260 ・支店大阪 06 ( 223 ) 3311 名古屋 052 ( 2 ) 90 ー営業所札幌 01 1 ( 23D2770 仙台 022 ( 262 ) 4859 北関東 73 ( 22 ) 1995 静岡 054 ( 25D2125 広島 082 ( 227 ) 2981 福岡 092 ( 78D18 資料請求 N 。 01 1