Mac OS X Snow Leopardでafpdサーバに接続できない（解決編）

「Mac OS X Snow Leopardでafpdサーバに接続できない（未解決編） « 突然消失するかもしれないブログ」で書きましたが、原因が明らかになり、解決しましたのでメモ。

（１）原因

原因は大きく２つあります。

原因１：

Debian Squeezeにおいて、2010年2月に入ってからのバージョンアップにより、netatalkのパッケージ、

ii  netatalk                          2.0.5-3                    AppleTalk user binaries

が依存するファイル群と整合がとれなくなり、暗号化パスワード認証（DHX2）でのPAM認証が正常に行えないため、ユーザ認証が失敗してしまいます。

Debian Squeezeのパッケージのバグのようです。

Bug#568601: netatalk: PAM DHX2: libgcrypt versions mismatch

原因２：

ユーザ認証に成功しても、CNIDデータベース（.AppleDB）のバージョンの不整合が発生しているため、Mac OS X Snow LeopardのFinderの接続が失敗してしまいます。

尚、CNIDが何かについては、HATさんのHPにある「CNIDの管理」が参考になります。

netatalk and samba

MacOSの為に作られたHFS+というファイルシステムでは、ファイルやフォルダにCNID (Catalog Node ID)と呼ばれる番号を付けて管理しています。これはAFPの場合も同様です。
netatalkでは、Berkeley DBを使って .AppleDB/というディレクトリでCNIDのデータベースを管理しています。 何らかの理由でこのディレクトリの中のファイルが壊れると、クライアントからうまく接続出来ないといったトラブルが発生します。

で、HFS+の拡張属性（EA:Extended Attribute）とアクセスコントロールリスト（Access Control List）に関する情報は以下が詳しいです。

Undocumented Mac OS X：第11回 HFS Plus独自の機能【後編】 (2/2) – ITmedia エンタープライズ

Tigerで追加されたのが、拡張属性（Extended Attribute）とアクセスコントロールリスト（Access Control List）だ。

簡単に説明すると、ファイル名やパーミッション、作成日時や更新日時、所有者とグループといった、あらかじめ決められた属性以外に、ファイルの内容により即した属性をユーザーやアプリケーションが自由に割り振れるようにするというのがEAである。また、これまでの所有者、グループ、それ以外に読み、書き、実行を割り振るという大雑把なパーミッションに対して、指定ユーザーやグループに対して個々にアクセス権を割り振るという、より詳細なアクセスコントロールを実現するのがACLだ。

（２）解決方法

（２－１）netatalkのパッケージをソースコードから再ビルドして再インストールする

以下の手順を参考に作業をしていきます。

APT HOWTO (Obsolete Documentation) – ソースパッケージでの作業

apt-get を使ってソースから deb パッケージを作成してインストールする – make world

1.  build-essential のインストール(初回のみ)
2. 依存関係の確認
3. 依存関係にあるパッケージの用意
4. インストールするパッケージのソースを取得する
5. ソースコードから生成された deb パッケージをインストールする

具体的な手順は以下の通りです。

## まず、インストール済みのnetatalkのパッケージをアンインストールします。purgeすると設定ファイルもすべて削除されるのでバックアップを忘れずに。
# apt-get purge netatalk

## 開発環境のインストール
# apt-get install build-essential

## 依存するパッケージをインストールする
# apt-get build-dep netatalk

## インストールするパッケージのソースを入手してビルドする。玄箱Proのセルフビルド環境だとビルドするのに結構時間がかかりますので、ビルドが終わるのを気長に待ちましょう。
# apt-get -b source netatalk

## 生成されたdebパッケージをインストールする
# dpkg -i netatalk_2.0.5-3_armel.deb

（２－２）.AppleDBディレクトリ以下をすべて削除する。

afpdの公開フォルダとして指定しているディレクトリにある.AppleDBディレクトリ以下をすべて削除します。

自動で一気に削除したい場合は、以下を実行します。

尚、findのオプションの指定方法を間違えると、.AppleDB以外の重要なファイルまできれいさっぱり消えてしまうこともありますので、実行するときはしっかり確認してから、慎重に行ってください。（あくまで自己責任で）

# find “afpdの公開フォルダとして指定しているディレクトリ” –name “.AppleDB” –print –exec rm –rf {} \;

また、おまけですが、HATさんのnetatalk and sambaを参考にして、

/etc/netatalk/AppleVolumes.defaultに以下を追記します。

:DEFAULT: maccharset:MAC_JAPANESE volcharset:UTF8 options:usedots,upriv dperm:0700 fperm:0600 cnidscheme:dbd

これにより、「cnidscheme:dbdを指定するとnetatalkの信頼性（.AppleDBの信頼性）が高まります。」とのことです。

尚、「maccharset:MAC_JAPANESE」については、afpdにパッチがあたっていない場合は指定できないので、ディストリビューションの状況に応じて調整します。
（Debian SqueezeではOK、Ubuntu9.0.4ではNGでした。）

更に、/etc/default/netatalkの設定を以下のように変更します。

CNID_METAD_RUN=yes

というのは、HATさんのnetatalk and sambaにあるとおり、CNIDデータベース（.AppleDB）の管理をcnid_metadデーモンに一元的にまかせてしまうと、信頼性が上がるようです。（BerkeleyDBって複数のプロセスから同時アクセスがあった場合、きちんと排他制御していないのでしょうか？）

cnidscheme:dbd
かなり安定している。cnid_metadデーモンがデータベースを一括管理する。各afpdはcnid_metadと通信するだけ。

（３）まとめ

netatalkは、需要と供給の問題のせいか、sambaほど開発が活発ではないような印象を受けますし、Debianプロジェクトでもあまり重視されているとは思いがたいので、よほど特別な理由がないかぎり本番環境では、sambaを使った方が無難そうです。特に、Windows環境とMac OS X環境との相互運用を考えるとsambaが無難ですかね。

最近では、Finderからsambaも快適に使えるようになってきているので、古いMac製品を持っている方は別としても、netatalkを使用する強い理由も見あたらないような気がします。

それでも、腕に覚えがあって、労力を惜しまない方は、netatalkとsambaを併用するのも悪くはないかなと思います。