第3章 Netatalk のセットアップ

afp.conf は，AFP ファイルサーバー及び提供する AFP ボリュームの挙動と設定を決定するために afpd が使用する設定ファイルである．

afp.conf は複数のサーバーセクションに分割できる．すなわち：

Global とも Homes，とも呼ばれないセクションは単なる一つの AFP ボリュームであると解釈される

Homes を定義してユーザーのホームディレクトリを共有するために， basedir regex オプションを明記しなければならない． これは全てのユーザーのホームの親ディレクトリのパスあるいは正規表現からなる単純な文字列でよい．

例：

[Homes]
basedir regex = /home

この場合，AFP サーバーにログインできるユーザーはそれぞれ /home/（ユーザー名） というパス名でのユーザーボリュームを使用できる．

より複雑なセットアップで，例えば二つの異なったファイルシステムにわたって分割された， 大量のユーザーホームディレクトリーのあるサーバーなら：

以下の設定が必要である：

[Homes]
basedir regex = /RAID./.*homes

もし，basedir regex にシンボリックリンクが含まれる場合， 正規化された絶対パスを指定すべきである．つまり，パス /home から /usr/home にシンボリックリンクがはられていた場合：

[Homes]
basedir regex = /usr/home

他の使用できるオプションの詳細な解説については afp.conf(5) の man page を参照いただきたい．

“コンカレント（concurrent:同時進行）データベース”バックエンドは Berkeley DB を基礎としたものである． このバックエンドだと複数の afpd デーモンが CNID データベースに直接アクセスできる． たとえ複数の afpd プロセスがある一つのボリュームに対して動作中の場合でも同期アクセスについては Berkeley DB ロック機構が全て負ってくれる．欠点としては，一つの afpd プロセスのクラッシュのみでデータベースの破損するかもしれないという点である． cdb は数多くのユーザーのホームディレクトリを共有するときのみ使用すべきで， かつ， 多数の cnid_dbd プロセスという状態は確実に問題を引き起こすということである．

CNID データベースへのアクセスは cnid_dbd デーモンプロセスのみに制限されている． afpd プロセスはデータベースの読み込みと更新のために cnid_dbd デーモン とやりとりをする． データベースが破損する可能性は経験的にはゼロである．

本バックエンドは Netatalk 2.1 以来，デフォルトのバックエンドとなっている．

tdb はまた別の永続性のある CNID データベースの一つであり， Samba の Trivial Database（軽量データベース）のことでもある． ユーザーボリューム用として cdb の代わりに使用することもできる．

tdb はメモリーにデータを保持するデータベースとして動作できるので， このバックエンドは内部向けに（メモリーにデータを保持する CNID データベースとして）， 最初のデータベースが開けない時など，予備として用いることもできる． これはもちろん再起動にすると CNID は失われるということを意味している．

last バックエンドはメモリーにデータを保持する tdb データベースである．それ故永続性がない． netatalk 3.0 からは，それは自動的に読み込み専用モードになる． このバックエンドは例えば CD-ROM などに有用である．

CNID バックエンドは MySQL サーバーを使用する． mysql 開発ライブラリが検出されると、自動的に設定される． コンパイル時に--without-mysql-configで無効にする．

内部的には，コンピューターは文字（キャラクター）について， テキストについて何も知らない，唯一“数字（数）”ならコンピュータにもわかる． それ故各々の“字”には“数”が割り当てられている．キャラクターセット，しばしば charset あるいは codepage とも呼ばれるが，これは“数”と“字”の一対一対応を規定している．

二つあるいはそれ以上のコンピューターがお互いに通信する必要がある場合， 各々は同じキャラクターセットを使う必要がある．1960 年代には ASCII (American Standard Code for Information Interchange) キャラクターセットが ASA（米国標準協会：the American Standards Association）によって標準化された． オリジナルの ASCII 形式は， 英語で用いられるアルファベット及び数字を網羅するのに十分な数より多い 128 のキャラクターを表している．今日においても， ASCII はコンピューターで使われるキャラクタースキームの標準的なものである．

国際的にもっと都合よく，そして若干内輪向けの記号文字を含めるために， つづくバージョンでは 256 のキャラクターを規定した． このエンコードの仕様だと一文字はきっちり 1 バイトに収まるが， 明らかに，256 キャラクターというのは， いろいろな言語で用いる全ての文字を一つのキャラクターに一対一対応させるのに依然十分ではなかった．

結果的には後にローカライズされたキャラクターセットが規定された． 例えば ISO-8859 キャラクターセットである． ほとんどのオペレーティングシステムベンダーは自らの要求を満たすために， 独自のキャラクターセットを導入した．すなわち IBM であれば コードページ 437 (DOSLatinUS)，アップルは MacRoman コードページ，などである． 127 以上のキャラクターが定義されているものを拡張 キャラクターと呼ぶ． これらのキャラクターセットは異なるキャラクターに同じ番号をふってあるので， 他のキャラクターセットとまたはキャラクターセット同士で衝突を起こす．

そういったキャラクターセットのほぼ全てが 256 個のキャラクターを定義していて， 最初の 128 個（0 から 127 まで）のキャラクターを ASCII と同一対応となるようにしている． 結果的に，違ったコードページを使っているシステム同士の通信では，事実上 ASCII キャラクターセット限定となった．

この問題を新たに解決するために，より大きいキャラクターセットが規定された． より多くのキャラクターマッピングの場所を確保するために， これらのキャラクターセットは一つのキャラクターの格納のために最低でも 2 バイトを使用する． このためそういったキャラクターセットはマルチバイト キャラクターセットと呼ばれる．

標準化されたマルチバイトキャラクターエンコード方式として知られているものの一つとして ユニコードがある． マルチバイトキャラクターセット使用の大きな利点として“それ一つで済む”がある． 二つのコンピューターが通信しているときに両者が同じキャラクターセットを使用しているか確認する必要がない．

過去に Apple クライアントは， ネットワーク間の通信のためにシングルバイトのキャラクターセットを使用していた． 年を経るに従い，Apple はいくつものキャラクターセットを定義したが， 欧米ユーザーは MacRoman コードセットを最もよく使用するであろう．

Apple の定義したコードページに含まれるもの：

Mac OS X 以降そして AFP3 以降では UTF-8 が用いられる．UTF-8 は Unicode キャラクターを ASCII 互換のやり方でエンコードする． 各々の Unicode キャラクターは一個から六個の ASCII キャラクターにエンコードされる． 故に， UTF-8 自体が本当のキャラクターセットなのではなく，ユニコードキャラクターセットのエンコーディングなのである．

厄介なことにも Unicode はいくつかの normalization（正規化） 方式を規定している．Samba はほとんどの Unix ツールも好んで用いる precomposed Unicode を使用する．一方 Apple は decomposed normalization を使うことに決めた．

例として、ドイツ語の文字 'ä' についてみてみる． Precomposed normalization を使えば Unicode はこの文字に 0xE4 を対応付ける． Decomposed normalization では 'ä' を正確には 0x61 と 0x308 の二つの文字に対応付ける． 0x61 は 'a' に，0x308 は COMBINING DIAERESIS（訳注：いわゆるウムラウト）に対応付けられている．

Netatalk では precomposed UTF-8 を UTF8 と，decomposed UTF-8 を UTF8-MAC と呼ぶ．

新しい AFP 3.x クライアントも古い AFP 2.x クライアントも同時にサポートするために， afpd は使われている様々なキャラクターセット間の変換が可能であることを必要とした． AFP 3.x クライアントは常に UTF8-MAC を， AFP 2.x クライアントは Apple コードページのうちの一つを使う．

本稿執筆時点（訳注：原文の）で， netatalk は以下の Apple コードページをサポートしている：

afpd は三つの異なるキャラクターセットオプションを扱う：

Apple は AFP クライアントとサーバー間の認証のために "User Authentication Modules" (UAM) と呼ばれる柔軟なモデルを選んだ． AFP クライアントがまず最初に AFP サーバーと接続するとき， サーバーが提供している UAM のリストを問い合わせる． そして，クライアントがサポートしている最も強い暗号化の UAM を選ぶ．

数個の UAM は時間をかけて Apple が開発してものであり， サードパーティの開発者によるものもある．

Netatalk はデフォルトで以下のものをサポートしている：

他にもオプションとして以下のような UAM がある：

"uam list" を Global セクションで定義することによって，どの UAM を有効化すべきか設定できる． afpd はどの UAM を使っているのか， UAM を有効化した時に問題が起こっているのかどうかを， netatalk.log あるいは起動時の syslog にログとして保存する． asip-status(1) も AFP サーバーで有効な UAM の問い合わせをするのに使うことができる．

ある特定の UAM がサーバー上で有効であるということが，直ちに， クライアントもそれを使うことができるということを意味するわけではない． クライアント側でのサポートもまた必要である． Mac OS X 以前が使われている古いマッキントッシュでも， DHCAST128 のサポートは AppleShare クライアント 3.8.x 以降には存在している．

OS X では， AFP クライアントをもっと冗長にするクライアント側のテクニックがいくつかあるので， 使用する UAM と折り合いをつけるまでに何が起こっているのか見ることができる．このヒント と比較してみるとよい．

第一義的には“何が必要か”と “サポートしようと考えている MAC OS のバージョンの種類”に依存する． 基本的にはそのパスワード暗号化の強力さから， 可能な限り DHCAST128 および DHX2 を試すべきである．

様々な UAM の技術的実装についてのより詳細な概要については，Apple の File Server Security ページを見ていただきたい．

いくつかの UAM は別の認証“バックエンド”を使えるようにしてある． いわゆる uams_cleartext.so， uams_dhx.so 及び uams_dhx2.soである．これらは /etc/passwd (/etc/shadow) からの古典的 Unix パスワードでも， システムがサポートしていれば　PAM でもどちらでも使うことができる． uams_cleartext.so は uams_passwd.so ないしは uams_pam.so へのシンボリックリンクとして， uams_dhx.so は uams_dhx_passwd.so ないしは uams_dhx_pam.so へのシンボリックリンクとして，さらには uams_dhx2.so は uams_dhx2_passwd.so ないしは uams_dhx2_pam.soへのシンボリックリンクとすることができる．

なので，もし Netatalk の UAM フォルダー（デフォルトで /etc/netatalk/uams/）が以下のようであれば：

uams_clrtxt.so -> uams_pam.so
uams_dhx.so -> uams_dhx_pam.so
uams_dhx2.so -> uams_dhx2_pam.so

PAM さもなくば古典的な Unix パスワードを使用しているわけである． PAM を使用することで最も有利なのは， 例えば LDAP 経由，あるいは NIS 経由などの集約した認証環境に Netatalk を統合できることである． そのような環境でのユーザーのログイン資格情報 (credentials) の保護は， UAM そのものが供している暗号化の強さにもまた依存している． ということを常に念頭においていただきたい． なので，"ClearTxt Passwrd" や "Randnum exchange" のような弱い UAM をネットワーク上から 完全に除去することを考えるべきである．

最も一般的に用いられる UAM の概観．

* Kerberos 概要 も一読のこと

トンネリングや VPN のたぐいのもの全ては， AFP 認証や UAM に関してすべきことは概ね皆無である． しかしながらアップルが「SSHを用いて安全な接続を可能にする」というオプションを導入して以来， 多数の人が両者について混乱する傾向にある．以下ではその点についても述べる．

ssh -l $USER $SERVER -L 10548:127.0.0.1:548 sleep 3000

基本的な方式で運用するならば設定することは何もない． Netatalk は ACL をオンザフライで読み込み，そののちいわゆる UARights パーミションビット経由で AFP クライアントに送られる有効なパーミッションを算出する． マック上では，これらのビットを Finder ウィンドウ内のパーミッションと調整するために Finder が使用する． 例：UNIX のモードでは書き込み専用だが ACL がユーザーに書き込み権限を与えているフォルダーは有効な読み書き権限を表示する． 権限のマッピングなしに Finder は読み込み専用アイコンを表示するだろうし， ユーザーはそのフォルダーに書き込みはできないであろう．

デフォルトでは，認証ユーザーに有効なパーミションは UNIX のモードではなく， 前記 UARights の機構のみに対応付けられる． この挙動は設定オプション map acls で修正することができる．

しかしながら，Finder の“情報を見る”ウィンドウでもターミナルでも， ACL を見ることは不可能で，そこで見ているのは OS X で ACL がどのように設計されたのかという結果である． もしクライアント上でも ACL を表示させたいと思うならば，諸々を認証ドメイン（ディレクトリサービス， 例えば，LDAP やOpenDirectory）の一部と，より内包されているようにして， クライアント側でもサーバー側でもセットアップをおこなうべきである． その理由は，OS X ACL が ただ，uid と gid だけでなく UUID と紐付いているためである． このため，afpd は全てのファイルシステムの uid と git を UUID に紐付けできなければならない． そうすれば， afpd は OS X の UUID に紐付けた UNIX uid と gid も含めたサーバー側の ACL を返すことができる．

Netatalk は LDAP クエリーを使ってディレクトリサーバーに問い合わせができる． ディレクトリサーバー（Active Directory，Open Directory）が既にユーザーとグループの UUID 属性を提供している． あるいはディレクトリサーバー（例えば OpenLDAP）に使用されていない属性を再利用する（あるいは新たに追加する）のいずれかである．

より踏み込むと：

アクセス制御リスト (ACL) と共に， Mac OS X は正統的な UNIX のパーミッションモデルの有力な拡張を提案した． ACL は， 所定のユーザーあるいはグループのパーミッションのセットを明示的に許可したり拒否するアクセス制御エントリー (ACE) の番号つきリストである．

ユーザー ID，またはグループ ID と紐付いている UNIX パーミッションとは異なり， ACL は UUID と紐付いている．この理由により，あるオブジェクトの ACL にアクセスすると， サーバーとクライアントは，UUID と ユーザー／グループ ID 間の変換をしてくれる， 共通のディレクトリサービスを使うことを要求される．

ACL と UNIX のパーミションの相互関係は比較的シンプルなものである． ACL はオプションなので，UNIX パーミションはアクセス制御のデフォルトのメカニズムの役割をする． オブジェクトの UNIX パーミションを変更しても ACL は手付かずのままで， ACL の修正でもオブジェクトの UNIX パーミションは決して変更されない．アクセスチェックの間， OS X は最初に以下の順序で ACE の評価をして，オブジェクトの ACL を検査する： 全てのリクエスト権限が許可されるまで，リクエストされた権限が ACE によって明示的に拒否された， あるいはリストの最後までたどり着いた．である．ACL がない， あるいは ACL に許可されたパーミションがリクエストを実行するのに十分でない場合， OS X は次にオブジェクトの UNIX パーミションの評価に入る． つまり，ACL は常に UNIX のパーミションより優先順位が上位ということである．

ZFS の ACL はほぼ OS X の ACL に匹敵するものである． 両者ともほぼ同一の良い粒度のパーミションと設定の継承が提供されている．