Setting up Netatalk 3.1
Chapter 3. Setting up Netatalk翻訳(deepl) netatalk.sourceforge.net
AFPファイルサーバーのセットアップ
AFP（Apple Filing Protocol）は、Apple Macintoshがファイルサービスに使用するプロトコルです。このプロトコルは長年にわたって進化してきました。このプロトコルの最新の変更点は「AFP 3.4」と呼ばれるもので、OS X Lion（10.7）のマイナーリリースで追加された。
afpdデーモンは、Appleクライアントにファイルサービスを提供します。設定ファイルはafp.confのみです。これは ini スタイルの設定構文を使用します。
Netatalk 3.1 で Spotlight のサポートが追加されました。Spotlight をサポートした Netatalk をコンパイルする方法については、このセクションを参照してください。
Mac OS X 10.5 (Leopard) では、AFP 上の Time Machine バックアップのサポートが追加されました。2つの新しい機能により、バックアップはサーバのキャッシュだけでなく、回転しているディスクにも書き込まれます。ホストオペレーティングシステムによって、このキャッシュフラッシュの扱いが異なります。ボリュームをTime Machineターゲットにするには、ボリュームオプション "time machine = yes "を使用してください。
Netatalk 2.1 以降、UNIX シンボリックリンクがサーバー上で使用できるようになりました。つまり、サーバー側で解決されるのではなく、クライアント側で解決することになり、クライアントのファイルシステムビュー内のどこかを指すリンクになります。
afp.conf
afp.confはAFPファイルサーバーとそれが提供するAFPボリュームの動作と設定を決定するためにafpdが使用する設定ファイルです。
afp.confはいくつかのセクションに分かれています。
- [Global]
- グローバルセクションでは、一般的なサーバオプションを定義します。
- [Homes]
- ホームセクションでは、ユーザーのホームボリュームを定義します。
Global または Homes と呼ばれないセクションは、AFP ボリュームとして解釈されます。
Homesセクションを定義してユーザーホームを共有する場合は、すべてのユーザーホームの親ディレクトリへのパスを含む単純な文字列または正規表現を指定することができます。
例:
[Homes] basedir regex = /home
これでAFPサーバーにログインしているユーザーは、パスが/home/NAMEであるユーザーボリュームを利用できるようになります。 より複雑な設定としては、大量のユーザーホームを持つサーバーで、2つの異なるファイルシステムに分割されている場合などが考えられます。
- /RAID1/home
- /RAID2/morehomes
以下の設定が必要です。
[Homes] basedir regex = /RAID./.*homes
basedir正規表現にシンボリックリンクが含まれている場合は、正規化された絶対パスを設定します。/homeが/usr/homeにリンクしている場合。
[Homes] basedir regex = /usr/home
利用可能なオプションの詳細な説明は afp.conf(5) の man ページを参照してください。
CNID backends
SMBやNFSのような他のプロトコルとは異なり、AFPプロトコルはほとんどの場合、ファイルやディレクトリをパスではなくIDで参照します（IDはCNIDとも呼ばれ、カタログノードIDを意味します）。典型的なAFPリクエストでは、ディレクトリIDとファイル名を使用します。例えば、Macの "Aliases "は基本的にIDで動作します（最近のAFPクライアントでは絶対パスにフォールバックされます）。ただし、これはFinderのみに適用され、アプリケーションには適用されません）。)
AFPボリューム内のすべてのファイルは一意のファイルIDを持たなければならず、IDは仕様によれば、決して再利用されないものでなければならず、IDは32ビットの数字である（ディレクトリIDは同じIDプールを使用しています）。そのため、40億個のファイル/フォルダがAFPボリュームに書き込まれると、IDプールは枯渇し、新しいファイルを書き込むことができなくなります。泣き言はやめてください。)
Netatalk はホストファイルシステム内のファイルやフォルダに ID をマッピングする必要があります。これを実現するために、いくつかの異なる CNID バックエンドが利用可能で、afp.conf(5) 設定ファイルの cnid スキームオプションで選択することができます。CNID バックエンドは基本的に ID <-> 名前のマッピングを格納するデータベースです。
CNID データベースはデフォルトで /var/netatalk/CNID にあります。
dbd と呼ばれるコマンドラインユーティリティがあり、CNID データベースの検証、修復、再構築に使用できます。
Note
netatalkで作業する際には、CNIDに関連して覚えておくべきことがいくつかあります。
- vol dbnest = yes "が設定されていない限り、ボリュームをネストしないでください。
- CNIDバックエンドはデータベースなので、afpdはファイルサーバとデータベースのミックスになります。
- ファイルシステム上の空き容量がなくなると、データベースが壊れてしまいます。これを回避するには、vol dbpathオプションを使用してデータベースファイルを別の場所に置くか、クオータを使用している場合は、CNIDデータベースフォルダがクオータなしのuser/groupによって所有されていることを確認してください。
- NFS経由でマウントされたボリュームのCNIDデータベースには注意してください。いずれにせよ、これはかなり大胆な決定ですが、データベースをそこに置くことは、データベースの破損などのトラブルを招くことになります。NFS マウントされたボリュームを使用しなければならない場合は、vol dbpath ディレクティブを使用してローカルディスクにデータベースを置くようにしてください。
cdb
"並行(concurrent)データベース"バックエンドは、Berkeley DB をベースにしています。このバックエンドでは、複数の afpd デーモンが CNID データベースに直接アクセスします。1つのボリュームに対して複数のafpdプロセスがアクティブな場合、アクセスを同期させるためにBerkeley DBロックが使用されます。欠点は、単一の afpd プロセスがクラッシュするとデータベースが破損する可能性があることです。
dbd
CNID データベースへのアクセスは cnid_dbd デーモンプロセスに制限されています。データベースが破損する確率は実質的にゼロです。 これは Netatalk 2.1 以降のデフォルトのバックエンドです。
tdb
tdbはもう一つの永続的なCNIDデータベースで、SambaのTrivial Databaseである。ユーザーボリュームのためにcdbの代わりに使うことができます。 重要なこと 共有されておらず、複数のクライアントから一度にアクセスされるボリュームにのみ使用してください。
このバックエンドは、プライマリデータベースを開くことができない場合のフォールバックとして内部的に(インメモリCNIDデータベースとして)使用されます。これはもちろん、再起動時に CNID が消えてしまうことを意味します。
last
最後のバックエンドはインメモリのtdbデータベースです。これは永続的ではありません。netatalk 3.0からは自動的に読み取り専用モードになります。これはCD-ROMなどに便利です。
mysql
CNID backend using a MySQL server.
Charsets/Unicode
なぜユニコードなのか？
内部的には、コンピュータは文字や文章については何も知らず、数字だけを知っています。したがって、各文字には番号が割り当てられています。文字セットは、しばしば文字セットやコードページと呼ばれ、数字と文字の間のマッピングを定義します。
2つ以上のコンピュータシステムがお互いに通信する必要がある場合、同じ文字セットを使用する必要があります。1960年代には、ASCII（情報交換のための米国標準コード）の文字セットが米国規格協会によって定義されました。ASCIIの元の形式は128文字を表し、英語のアルファベットと数字をカバーするのに十分以上の文字数でした。今日まで、ASCIIはコンピュータで使用される標準的な文字スキームとなっています。
後のバージョンでは、より国際的な流暢さを演出するために256文字が定義され、若干難解なグラフィカルな文字も含まれるようになりました。このエンコーディングモードを使用すると、各文字は正確に1バイトになります。明らかに、256文字では、さまざまな言語で使用されているすべての文字を1つの文字セットにマッピングするにはまだ十分ではありませんでした。
その結果、ローカライズされた文字セット、例えばISO-8859文字セットなどが後に定義されるようになりました。ほとんどのオペレーティング・システム・ベンダーは、ニーズを満たすために独自の文字セットを導入しました。127よりも大きな番号が割り当てられた文字は、拡張文字と呼ばれていました。これらの文字セットは、異なる文字に同じ番号を使用したり、その逆を行ったりして、別の文字と衝突します。
これらの文字セットのほとんどすべてが２５６文字を定義しており、最初の１２８（０〜１２７）の文字マッピングはＡＳＣＩＩＩと同じである。その結果、異なるコードページを使用するシステム間の通信は、事実上ASCII文字セットに制限されていました。
この問題を解決するために、新しいより大きな文字セットが定義されました。より多くの文字マッピングのためのスペースを確保するために、これらの文字セットは、1つの文字を格納するために少なくとも2バイトを使用します。したがって、それらはマルチバイト文字セットと呼ばれています。
1つの標準化されたマルチバイト文字セット符号化方式は、ユニコードとして知られています。マルチバイト文字セットを使用する大きな利点は、1つだけで済むことです。彼らが通信しているときに2台のコンピュータが同じ文字セットを使用していることを確認する必要はありません。
アップルが使用する文字セット
過去には、アップルのクライアントは、ネットワークを介して通信するために、シングルバイトの文字セットを使用していました。長年にわたり、Apple は多くのコードページを定義してきましたが、欧米のユーザーは MacRoman のコードページを使用している可能性が高いでしょう。 Apple が定義したコードページには以下のようなものがあります。
- MacArabic, MacFarsi
- MacCentralEurope
- MacChineseSimple
- MacChineseTraditional
- MacCroation
- MacCyrillic
- MacDevanagari
- MacGreek
- MacHebrew
- MacIcelandic
- MacJapanese
- MacKorean
- MacRoman
- MacRomanian
- MacThai
- MacTurkish
Mac OS XやAFP3からは、UTF-8が使用されています。UTF-8はASCIIと互換性のある方法でUnicode文字をエンコードしており、各Unicode文字は1～6のASCII文字にエンコードされています。したがって、UTF-8は実際には文字セットそのものではなく、Unicode文字セットのエンコーディングです。
物事を複雑にするために、Unicode はいくつかの正規化形式を定義しています。samba はほとんどの Unix ツールが好むプリコンポーズ Unicode を使用していますが、Apple はデコンポーズ正規化を使用することにしました。
例えば、ドイツ語の文字 'ä' を考えてみましょう。プリコンポーズ正規化を使うと、Unicode はこの文字を 0xE4 にマップします。デコンポーズ正規化では、'ä'は実際には0x61と0x308の2つの文字にマッピングされます。0x61 は「a」のマッピングで、0x308 は「COMBINING DIAERESIS」のマッピングです。
Netatalkでは、プリコンポーズされたUTF-8をUTF8、デコンポーズされたUTF-8をUTF8-MACと呼んでいます。
afpd and character sets
新しいAFP 3.xクライアントと古いAFP 2.xクライアントを同時にサポートするために、afpdは使用される様々な文字セット間で変換できる必要があります。AFP 3.xクライアントは常にUTF8-MACを使用し、AFP 2.xクライアントはAppleのコードページを使用します。
この記事を書いている時点では、netatalkは以下のAppleのコードページをサポートしています。
- MAC_CENTRALEUROPE
- MAC_CHINESE_SIMP
- MAC_CHINESE_TRAD
- MAC_CYRILLIC
- MAC_GREEK
- MAC_HEBREW
- MAC_JAPANESE
- MAC_KOREAN
- MAC_ROMAN
- MAC_TURKISH
afpd は 3 つの異なる文字セットオプションを扱います。
unix 文字セット
- これは、お使いのオペレーティングシステムで内部的に使用されるコードページです。指定されていない場合、デフォルトは UTF8 です。LOCALE が指定され、システムが Unix ロケールをサポートしている場合、 afpd はコードページを検出しようとします。 afpd はこのコードページを使用して設定ファイルを読み込んでいるので、 ボリューム名やログインメッセージなどに拡張文字を使用できます。
mac の文字セット
vol 文字セット
これは afpd がディスク上のファイル名に使用する文字セットを定義します。デフォルトでは、Unix の文字セットと同じです。iconv がインストールされていれば、iconv が提供する任意の文字セットを使うことができます。
afpd は unix ファイルシステム上でファイルを保存する際に、拡張 macintosh 文字や unix ファイル名では不正な文字を保存する方法を必要とします。以前のバージョンでは CAP エンコーディングと呼ばれるものを使用していました。例えば、Apple ロゴ (MacRoman: 0xF0) は :f0 として保存されていました。いくつかの特殊文字も同様に :xx 記法に変換されます。もし usedots が指定されていない場合は、先頭のドット '.' は :2e としてエンコードされます。
このバージョンでは、ファイル名のデフォルトエンコーディングに UTF8 を使用していますが、'/' は ':' に変換されます。欧米のユーザにとっては、vol charset = ISO-8859-15という設定も便利です。
mac の文字セットから選択した vol charset に変換できない文字がある場合、mac で -50 のエラーが表示されます。注意: 可能な限り、デフォルトの UTF8 ボリュームフォーマットを使用してください。
Authentication
AFP authentication basics
アップルは、AFPクライアントとサーバー間の認証を目的とした「ユーザー認証モジュール」（User Authentication Modules：UAMs）という柔軟なモデルを選択した。AFPクライアントが最初にAFPサーバーに接続すると、サーバーが提供するUAMのリストを要求し、クライアントがサポートする最も強力な暗号化機能を持つものを選択する。 いくつかのUAMは、Appleによって開発されたものもあれば、サードパーティの開発者によって開発されたものもあります。
NetatalkによってサポートされるUAM
Netatalkは、以下のものをデフォルトでサポートしています。
- "No User Authent" UAM (認証なしのゲストアクセス)
- "Cleartxt Passwrd" UAM (パスワード暗号化なし)
- "ランドナム交換"/"2ウェイランドナム交換 "UAM（弱パスワード暗号化、別パスワード保存
- "DHCAST128" UAM（より強力なパスワード暗号化)
- "DHX2" UAM (DHCAST128後継機)
他にもオプションのUAMも存在します。
- "PGPuam 1.0" UAM (Mac OS X以前のクライアント用のPGPベースの認証。これを動作させるには、PGPuam クライアントも必要です) この UAM を利用できるようにするには、configure スイッチに "--enable-pgp-uam" を追加する必要があります。
- "Kerberos IV"/"AFS Kerberos" UAM (Kerberos v4 ベースの認証と AFS ファイルサーバの使用に適しています) コンパイル時に"--enable-krb4-uam "を使用して、このUAMのビルドを有効にしてください。
- "Client Krb v2" UAM (Kerberos V、OS Xクライアントの "シングルサインオン "シナリオに適しています。) "--enable-krbV-uam "はこのUAMを使用する機能を提供します。
グローバルセクションで "uam list "を定義することで、どのUAMを有効にするかを設定することができます。afpdは、どのUAMを使用しているかをログに記録し、問題が発生した場合は起動時にnetatalk.logまたはsyslogに記録します。
サーバで利用可能な特定のUAMがあるからといって、自動的にクライアントが利用できるわけではない。クライアント側のサポートも必要である。Mac OS < Xの古いMacintoshでは、AppleShareクライアント3.8.x以降、DHCAST128のサポートがあります。
OS Xでは、AFPクライアントをより饒舌にするためのクライアントサイドのテクニックが存在しますので、使用するUAMをネゴシエートしながら何が起こっているかを見ることができます。このヒントと比較してみてください。
どのUAMを有効化するか?
それは主にあなたのニーズとサポートしなければならないMac OSのバージョンの種類に依存します。基本的には、パスワード暗号化の強さから、可能な限りDHCAST128とDHX2を使用するようにしてください。
本当にサーバーのボリュームにゲストアクセスを供給する必要がない限り、それが誤って不正アクセスにつながる可能性があるので、"No User Authent "を無効にすることを確認してください。ゲストアクセスを有効にしなければならない場合は、アクセスコントロールを使用してボリュームごとにこれを強制するように注意してください。
ClearTxt Passwrd" UAM は、パスワードが暗号化されていない状態で有線で送信されるため、聞こえが悪いです。サーバー側とクライアント側の両方でこれを避けるようにしてください。注意: Mac OS 8/9 のクライアントに NetBoot サービスを提供したい場合は uams_cleartext.so が必要です。
Randnum exchange」/「2-Way Randnum exchange」は暗号化に56ビットDESしか使わないので、これも避けるべきです。もう一つの欠点は、パスワードをサーバ上のクリアテキストに保存しなければならないことと、PAM シナリオや古典的な /etc/shadow に統合されていないことです (クライアントがこれらの UAM を使用する場合は afppasswd(1) ユーティリティを使用してパスワードを個別に管理しなければなりません)。
"DHCAST128 "または "DHX2 "は、より強力な暗号化とPAM統合を組み合わせているので、ほとんどの人にとって良い妥協点になるはずです。
Kerberos V ("Client Krb v2") UAMを使用すると、Kerberosチケットを使用して実際のシングルサインオンシナリオを実装することが可能です。パスワードはネットワーク経由では送信されません。その代わりに、ユーザパスワードは appleshare サーバのサービスチケットを復号化するために使用されます。サービスチケットには、クライアント用の暗号化キーと暗号化されたデータが含まれています（これは appleshare サーバだけが解読できます）。サービスチケットの暗号化された部分はサーバに送られ、ユーザの認証に使用されます。afpd サービスプリンシパル検出が実装されているため、この認証方法は中間者攻撃に対して脆弱です。
異なる UAM の技術的な意味合いについてのより詳細な概要については、Apple の File Server Security のページをご覧ください。
特定のUAMで異なる認証ソースを使用する
uams_cleartext.so、uams_dhx.so、uams_dhx2.so といった異なる認証「バックエンド」を使用する機能を提供している UAM もあります。uams_cleartext.so は uams_passwd.so や uams_pam.so にシンボリックリンクすることができます。 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のUAMsフォルダ（デフォルトの/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 を統合できることです。このようなシナリオでユーザのログイン認証情報を保護するには、問題のUAMが提供する暗号化の強さにも依存することを常に念頭に置いてください。したがって、「ClearTxt Passwrd」や「Randnum exchange」のような弱いUAMをネットワークから完全に排除することを考えてください。
Netatalk UAM概要表
よく使われているUAMの概要を少しご紹介します。
表 3.1. Netatalk UAMの概要
| UAM | No User Authent | Cleartxt Passwrd | (2-Way) Randnum exchange | DHCAST128 | DHX2 | Client Krb v2 |
|---|---|---|---|---|---|---|
| password length | guest access | max. 8 characters | max. 8 characters | max. 64 characters | max. 256 characters | Kerberos tickets |
| Client support | built-in into all Mac OS versions | built-in in all Mac OS versions except 10.0. Has to be activated explicitly in recent Mac OS X versions | built-in into almost all Mac OS versions | built-in since AppleShare client 3.8.4, available as a plug-in for 3.8.3, integrated in Mac OS X' AFP client | built-in since Mac OS X 10.2 | built-in since Mac OS X 10.2 |
| Encryption | Enables guest access without authentication between client and server. | Password will be sent in cleartext over the wire. Just as bad as it sounds, therefore avoid at all if possible (note: providing NetBoot services requires the ClearTxt UAM) | 8-byte random numbers are sent over the wire, comparable with DES, 56 bits. Vulnerable to offline dictionary attack. Requires passwords in clear on the server. | パスワードは128ビットSSLで暗号化され、ユーザーはサーバーに対して認証されますが、その逆ではありません。そのため、中間者攻撃には弱いです。 | パスワードは、CBC モードで CAST 128 の libgcrypt を使って暗号化されます。ユーザはサーバに対して認証されますが、その逆は認証されません。そのため、中間者攻撃には弱いです。 | パスワードはネットワーク経由では送信されません。サービス主検知方式のため、この認証方式は中間者攻撃に弱い。 |
| Server support | uams_guest.so | uams_cleartxt.so | uams_randnum.so | uams_dhx.so | uams_dhx2.so | uams_gss.so |
| Password storage method | None | Either /etc/passwd (/etc/shadow) or PAM | Passwords stored in clear text in a separate text file | Either /etc/passwd (/etc/shadow) or PAM | Either /etc/passwd (/etc/shadow) or PAM | At the Kerberos Key Distribution Center* |
Kerberosの概要を見てみましょう。
SSH トンネリング
トンネリングやVPNのようなものは、一般的にAFP認証やUAMとは何の関係もありません。しかし、Appleが「Allow Secure Connections Using SSH」というオプションを導入したことで、両者を混同しがちな人が多いので、ここではそれについても触れておきます。
AFPセッションを手動でトンネリングする
これは、「AFP over TCP」を話すAFPサーバーが最初にネットワークに登場したときから機能しています。リモートサーバーのAFPポートを548とは別のローカルポートにトンネルし、その後、ローカルでこのポートに接続するだけです。OS Xでは、これは次のようにして行うことができます。
ssh -l $USER $SERVER -L 10548:127.0.0.1:548 sleep 3000
トンネルを確立した後、"サーバへの接続 "ダイアログで "afp://127.0.0.1:10548 "を使用します。ローカルAFPクライアントはMacのローカルポート10548に接続し、リモートサーバーのAFPポート（デフォルトの548を使用しています）にSSHで転送されます。
この種のトンネルは、「本物の」VPNを使用する能力がなくても、インターネットを介して弱い認証メカニズムを提供するAFPサーバにアクセスしたい場合には、理想的なソリューションとなります。ssh の "-C" スイッチを使ってデータを圧縮することができることと、トンネルのエンドポイントが AFP クライアントとサーバの両方と異なる場合があることに注意してください (詳細については SSH のドキュメントと比較してください)。
トンネル化されたAFP接続を自動的に確立する
Mac OS X 10.2から10.4まで、Appleは「サーバへの接続」ダイアログに「SSHを使ったセキュアな接続を許可する」チェックボックスを追加しました。その背景にある考え方。サーバがSSHで連絡が取れることを知らせると、Mac OS XのAFPクライアントはトンネルを確立しようとし、AFPトラフィックをすべて自動で通過させる。
しかし、この機能が初めて動作するようになったのは Mac OS X 10.3 のリリースまででした...部分的には。SSHトンネルが確立できない場合、AFPクライアントは無言で暗号化されていないAFP接続を試みるようになりました。
Netatalkのafpdは、グローバルセクションで "advertise ssh "と "fqdn "の両方のオプションが設定されている場合、SSHトンネルされたAFPリクエストを処理できることを報告します（設定を変更したときにafpdを再起動した後、asip-status.pl(1)で二重に確認してください）。しかし、このオプションを全く使いたくない理由がいくつかあります。
(SSH のように) TCP 上に TCP をトンネルするのは最良のアイデアではありません。IP 層に基づいた VPN のようなより良いソリューションが存在します。
このSSHはAFP認証メカニズムに直接統合された通常のUAMではなく、その代わりにクライアントがトンネルを確立しようとするかどうかをシグナリングする単一のフラグを使っているので、何かがうまくいかないときに何が起こっているのかを見るのが難しくなります。
すべての接続試行がローカルホストから行われているように見えるので、macusers のような Netatalk ツールでどのマシンがログオンしているかを制御することはできません。
一方で、すべてのAFPセッションがSSHで暗号化されているかどうかを確認したい場合は、afpdへのアクセスをローカルホストのみに制限しなければなりません（TCPラッパー）。
... 10.2 - 10.3.3 を使用している場合は、期待していたのとは逆の結果になります: 暗号化されていない可能性のある AFP 通信 (ログオン認証情報を含む) がネットワーク上で行われ、トンネルの確立に失敗したという通知もありません。Appleはこの問題をMac OS X 10.3.4までは修正していませんでした。
ACL Support
AFPのACLサポートは、Solarisおよび派生プラットフォーム上のZFS ACLとLinux上のPOSIX 1e ACLに実装されています。
Configuration
基本的な動作モードでは、何も設定する必要はありません。Netatalkはその場でACLを読み取り、有効なパーミッションを計算し、それをUARightsパーミッションビットと呼ばれるビットを介してAFPクライアントに送信します。Macの場合、Finderはこれらのビットを使用してFinderウィンドウのパーミッションを調整します。例：UNIXモードが読み取り専用で、ACLによりユーザーに書き込みアクセス権が与えられているフォルダでは、有効な読み取り/書き込み権限が表示されます。パーミッションマッピングがない場合、Finder は読み取り専用のアイコンを表示し、ユーザーはそのフォルダへの書き込みができなくなります。
デフォルトでは、認証されたユーザの有効なパーミッションは、UNIX モードではなく、前述の UARightspermission 構造にのみマッピングされます。この動作は設定オプションの map acls で調整できます。
しかし、Finder の "Get Info" ウィンドウでもターミナルでも ACL を見ることはできませんが、これは OS X の ACL がどのように設計されているかに起因しています。クライアントで ACL を表示させたい場合は、クライアントとサーバの両方を認証ドメイン (LDAP, OpenDirectory などのディレクトリサービス) の一部にするように設定しなければならないので、物事はより複雑になります。理由は、OS X では ACL は uid や gid だけでなく UUID にバインドされているからです。そのため、afpd は、UNIX の uid と gid が OS X の UUID にマッピングされたサーバ側 ACL を返すことができるように、すべてのファイルシステムの uid と gid を UUID にマッピングできなければなりません。
Netatalk は、LDAP クエリを使用してディレクトリサーバに問い合わせを行うことができます。ディレクトリサーバが既にユーザやグループのUUID属性を提供している場合（Active Directory、Open Directory）、または未使用の属性をディレクトリサーバに再利用（または新規追加）する場合（OpenLDAPなど）があります。
詳細は以下の通りです。
aclinherit = passthrough aclmode = passthrough
このノブが何をするのか、どのように適用するのかについては、ホストの ZFS のドキュメント (例: man zfs) を参照してください。
- 認証領域
サーバーとクライアントは、IDデータが共通のソースから来るセキュリティアソシエーションの一部でなければなりません。DarwinのACLはUUIDに基づいており、AFP 3.2のACL仕様もそうです。したがって、IDデータのソースは、UUIDがASCII文字列として格納されているユーザーとグループごとに属性を提供しなければなりません。言い換えれば
- UUIDを何らかの属性で保存するOpen DirectoryサーバーまたはLDAPサーバーが必要です。
- クライアントがこのサーバーを使用するように設定されている必要があります
- サーバは nsswitch と PAM を介してこのサーバを使用するように設定されている必要があります。
- afp.confのACLのための特別なLDAPオプションを使用して、NetatalkがLDAP検索クエリを介してユーザーとグループのUUIDを取得できるようにNetatalkを設定します。
OS X ACLs
Mac OS Xでは、従来のUNIX権限モデルを強力に拡張したアクセス制御リスト（ACL）を提供しています。ACLとは、特定のユーザやグループに対する一連の権限を明示的に付与または拒否するアクセス制御エントリ（ACE）の順序付きリストのことです。
ユーザーやグループのIDに縛られているUNIX権限とは異なり、ACLはUUIDに縛られています。このため、オブジェクトの ACL にアクセスするには、サーバとクライアントが UUID とユーザ/グループ ID を変換する共通のディレクトリサービスを使用する必要があります。
ACLとUNIXパーミッションの相互作用は、かなり単純な方法で行われます。ACLはオプションであるため、UNIXパーミッションはアクセス制御のためのデフォルトのメカニズムとして機能します。オブジェクトのUNIXパーミッションを変更しても、そのオブジェクトのACLはそのままで、ACLを変更しても、そのオブジェクトのUNIXパーミッションは変更されません。アクセスチェックを行っている間、OS X は最初にオブジェクトの ACL を検査し、要求された権利がすべて付与されたか、要求された権利が ACE によって明示的に拒否されたか、またはリストの最後に達するまで ACE を順に評価します。ACLがない場合や、ACLによって付与されたパーミッションが要求を満たすのに十分でない場合、OS Xは次にオブジェクトのUNIXパーミッションを評価します。したがって、ACLは常にUNIXパーミッションよりも優先されます。
ZFS ACLs
ZFS の ACL は OS X の ACL と密接に一致しています。どちらもほとんど同じ細かいパーミッションと継承設定を提供しています。
POSIX ACL
概要
OS X や NFSv4 ACL と比較して、Posix ACL は、従来の UNIX パーミッションの制限を克服するための、異なる、汎用性の低いアプローチを表しています。実装は、廃止された Posix 1003.1e 標準に基づいています。 標準では、2種類のACLを定義しています。ファイルとディレクトリは、アクセスチェックのために参照されるアクセスACLを持つことができます。ディレクトリは、アクセスチェックとは無関係のデフォルトのACLを持つこともできます。デフォルトの ACL を持つディレクトリ内に新しいオブジェクトが作成されると、デフォルトの ACL がアクセス ACL として新しいオブジェクトに適用されます。サブディレクトリは親からデフォルト ACL を継承します。それ以上の継承制御のメカニズムはありません。 Posix ACL と OS X ACL の間のアーキテクチャの違いは、特に以下の点に関係しています。
- 細かい粒度のパーミッションモデルがない。UNIXのパーミッションと同様に、Posix ACLは読み取り、書き込み、実行のパーミッションのみを区別しています。
- ACL内のエントリは順番がありません。
- Posix ACLは権限のみを付与することができます。エントリによって明示的に権利を拒否する方法はありません。
- UNIX の権限は、特別なエントリとして ACL に統合されています。
Posix 1003.1eでは、6種類の異なるタイプのACLエントリを定義しています。最初の3つのタイプは、標準的なUNIX権限を統合するために使用されます。これらは最小限の ACL を形成し、その存在は必須であり、ACL 内では各タイプの 1 つのエントリしか許可されません。
残りのエントリタイプは、従来のアクセス権モデルを拡張したものです。
- ACL_USER: 特定のユーザーにアクセス権を付与します。
- ACL_GROUP: 特定のグループにアクセス権を付与します。
- ACL_MASK: ACL_GROUP_OBJ、ACL_USER、およびACL_GROUPタイプのエントリによって付与されるアクセス権の最大値を制限します。その名が示すように、このエントリはマスクとして動作します。ACLごとに1つのACL_MASKエントリだけが許可されます。ACLがACL_USERまたはACL_GROUPエントリを含む場合、ACL_MASKエントリも存在しなければならず、そうでない場合はオプションです。
ACLを認識しないアプリケーションとの互換性を維持するために、Posix 1003.1eでは、オブジェクトのUNIXパーミッションを取得または操作するシステムコールとユーティリティのセマンティクスが変更されています。オブジェクトが最小のACLしか持っていない場合、UNIX権限のグループ権限ビットは、ACL_GROUP_OBJエントリの値に対応します。
しかし、ACLにACL_MASKエントリが含まれている場合、それらのシステムコールやユーティリティの動作は異なる。UNIXパーミッションのグループパーミッションのビットは、ACL_MASKエントリの値に対応している。
POSIX ACLからOS X ACLへのマッピング
クライアントがオブジェクトの ACL を読みたい場合、afpd は Posix ACL を同等の OS X ACL にマップします。オブジェクトの ACL を書き込むには、afpd は OS X ACL を Posix ACL にマップする必要があります。Posix ACLのアーキテクチャ上の制限のため、正確なマッピングを見つけることは通常不可能であり、マッピング処理の結果は元のACLのセマンティックの近似値になります。
- afpd は、Posix アーキテクチャ内で表現できないため、一連のパーミッションを拒否するエントリを黙って破棄します。
- Posix ACL内のエントリは順序がないので、順序を維持することは不可能です。
- 継承制御も同様に厳しい制限を受けます。
- Posix側に細かい粒度のパーミッションモデルがないため、通常は許可されるパ ーミッションが増えることになります。
OS XクライアントはPosix 1003.1e特有のUNIXパーミッションとACL_MASKの関係を認識していないため、afpdは互換性の問題を避けるためにこの機能をクライアントに公開せず、Appleのリファレンス実装であるAFPと同じ方法で*UNIXパーミッションとACLを扱います。オブジェクトのUNIXパーミッションが要求されると、afpdは適切なグループ権限を計算し、FPUnixPrivs構造体の "permissions "と "ua_permissions "メンバーを介して、呼び出し元に所有者と全員のアクセス権とともに結果を返します(Apple Filing Protocol Reference、181ページ参照)。オブジェクトのパーミッションを変更すると、afpd は常に ACL_USER_OBJ、ACL_GROUP_OBJ、および ACL_OTHERS を更新します。ACL_MASK エントリも存在する場合、afpd はその値を再計算し、新しいグループ権限が有効になり、ACL_USER または ACL_GROUP タイプの既存のエントリがそのまま維持されるようにします。
Filesystem Change Events
Netatalk には、気の利いたファイルシステム変更イベントメカニズムが含まれており、 afpd プロセスは、特定のファイルシステムイベントについて興味のあるリスナーに UDP ネットワークデータグラムで通知します。
UDP パケットのフォーマットと、リスナーでの使用方法を示す C アプリケーションの例については、Netatalk のソースファイル bin/misc/fce.c を参照してください。
現在サポートされている FCE イベントは以下のとおりです。
利用可能なシンプルな設定オプションの詳細は afp.conf を参照してください。
スポットライト
バージョン3.1以降、NetatalkはSpotlight検索をサポートしています。Netatalk はメタデータストア、インデクサ、検索エンジンとして Gnome Tracker を使用します。
設定
スポットライトオプションを使用して、スポットライトとインデックスをグローバルに、または数量単位で有効にすることができます。
警告
一旦Spotlightが1つのボリュームで有効になると、Spotlightが無効になっている他のすべてのボリュームは検索できなくなります。
スポットライト機能を有効にするには、dbus-daemonバイナリをインストールする必要があります。dbus-daemonへのパスは--with-dbus-daemonオプションの "configure "で決定されます。
dbus-daemonバイナリが他のパスにインストールされている場合、パスを指定するためにグローバルオプションのdbus daemonを使用する必要があります。
dbus daemon = /opt/csw/bin/dbus-daemon
制限と備考
- 大容量ファイルシステム Linux 上の Tracker は、ファイルシステムの変更を追跡するために inotify カーネルのファイルシステム変更イベント API を使用します。大規模なファイルシステムでは、inotify API は再帰的なディレクトリウォッチを提供せず、代わりにサブディレクトリごとに個別にウォッチを追加しなければならないので、これは問題があるかもしれません。
Solaris では、FEN ファイルイベント通知システムが使用されています。このSolarisサブシステムがどのような制限やリソース消費をするかは不明です。
したがって、ライブのファイルシステム監視を無効にして、代わりに Tracker に定期的にファイルシステムの変更をスキャンさせることを推奨する。
サーバ上での Tracker コマンドラインツールの使用
Netatalk が起動している必要があり、コマンドは root で実行され、いくつかの環境変数が設定されている必要があります (PREFIX を調整して Netatalk がインストールされているベースディレクトリを指すようにしてください)。
# cat .tracker_profile PREFIX="/" export XDG_DATA_HOME="$PREFIX/var/netatalk/" export XDG_CACHE_HOME="$PREFIX/var/netatalk/" export DBUS_SESSION_BUS_ADDRESS="unix:path=$PREFIX/var/netatalk/spotlight.ipc" # . .tracker_profile #
OpenCSW から Tracker を使用する場合は、PATH も更新する必要があります。
Querying Tracker status
Recent Tracker:
# tracker daemon
Old Tracker:
# tracker-control -S
Stop Tracker
Recent Tracker:
# tracker daemon -t
Old Tracker:
# tracker-control -t
Start Tracker
Recent Tracker:
# tracker daemon -s
Old Tracker:
# tracker-control -s
Reindex directory
Recent Tracker:
# tracker index -f PATH
Old Tracker:
# tracker-control -f PATH
Query Tracker for information about a file or directory
Recent Tracker:
# tracker info PATH
Old Tracker:
# tracker-info PATH
Search Tracker
Recent Tracker:
# tracker search QUERY
Old Tracker:
# tracker-search QUERY
Advanced Tracker コマンドライン設定
Tracker は、gsettings コマンドで変更できる Gnome dconf バックエンドを介して設定を保存する。
Gnome dconf の設定はユーザごとの設定なので、Netatalk が root として Tracker プロセスを実行すると、設定は root ユーザコンテキストに保存され、これらの設定の読み込みや変更は root として実行され、Netatalk が実行されていなければならない (そして再び、上記のように環境が設定されていなければならない)。
# gsettings list-recursively | grep Tracker org.freedesktop.Tracker.Writeback verbosity 'debug' ...
以下のリストでは、いくつかの重要な Tracker オプションとそのデフォルト設定について説明します。
org.freedesktop.Tracker.Miner.Files index-recursive-directories
このオプションは、Tracker がインデックスを作成するディレクトリを制御します。Netatalk ボリュームの Spotlight オプションの設定を反映して Netatalk によって自動的に設定されるので、このオプションを手動で変更しないでください。
org.freedesktop.Tracker.Miner.Files enable-monitors true
この値は、Tracker が変更のために設定されたすべてのパスを監視するかどうかを制御する。ファイルシステムの変更のバックエンド (Linux では FAM、Solaris では FEN) に依存して、この機能は信頼性が低いので、これを無効にして、代わりに Tracker 自体の定期的なクロールに頼る方が安全かもしれません。オプションの crawling-interval も参照してください。
org.freedesktop.Tracker.Miner.Files crawling-interval -1
ファイルシステムがデータベースの最新の状態にあるかどうかをチェックするための日数間隔、最大値は365、デフォルトは-1です。 -2 = クローリングは完全に無効化され、-1 = クローリングは起動時に発生する可能性があります。
サポートされているメタデータ属性
次の表に、サポートされている Spotlight のメタデータ属性を示します。 表 3.2. サポートされている Spotlight のメタデータ属性
| Description | Spotlight Key |
|---|---|
| Name | kMDItemDisplayName, kMDItemFSName |
| Document content (full text search) | kMDItemTextContent |
| File type | _kMDItemGroupId, kMDItemContentTypeTree |
| File modification date | kMDItemFSContentChangeDate, kMDItemContentModificationDate, kMDItemAttributeChangeDate |
| Content Creation date | kMDItemContentCreationDate |
| The author, or authors, of the contents of the file | kMDItemAuthors, kMDItemCreator |
| The name of the country where the item was created | kMDItemCountry |
| Duration | kMDItemDurationSeconds |
| Number of pages | kMDItemNumberOfPages |
| Document title | kMDItemTitle |
| The width, in pixels, of the contents. For example, the image width or the video frame width | kMDItemPixelWidth |
| The height, in pixels, of the contents. For example, the image height or the video frame height | kMDItemPixelHeight |
| The color space model used by the document contents | kMDItemColorSpace |
| The number of bits per sample kMDItemBitsPerSample | |
| Focal length of the lens, in millimeters | kMDItemFocalLength |
| ISO speed | kMDItemISOSpeed |
| Orientation of the document. Possible values are 0 (landscape) and 1 (portrait) | kMDItemOrientation |
| Resolution width, in DPI | kMDItemResolutionWidthDPI |
| Resolution height, in DPI | kMDItemResolutionHeightDPI |
| Exposure time, in seconds | kMDItemExposureTimeSeconds |
| The composer of the music contained in the audio file | kMDItemComposer |
| The musical genre of the song or composition | kMDItemMusicalGenre |
参考文献
- エムディーアイアイ
- トラッカー
Netatalk の起動と停止
Netatalk ディストリビューションには、コンパイル前の "configure" スクリプトに与えられたオプションに応じて調整された、いくつかのオペレーテ ィングシステム固有の起動スクリプトテンプレートが付属しています。現在、RedHat (sysv 形式), RedHat (systemd 形式), SUSE (sysv 形式), SUSE (systemd 形式), Debian (sysv 形式), Debian (systemd 形式), Gentoo, NetBSD, Solaris 用のテンプレートが提供されています。configure」にシステムタイプを指定することで、生成されたスタートアップスクリプトをインストールするかどうかを選択できます。自動的にスタートアップスクリプトをインストールするには、利用可能な --with-init-style オプションのいずれかを "configure" に指定してください。
Linux ディストリビューションの新しいリリースは常に登場しており、上記の他のシステムのスタートアップ手順も変更される可能性があるので、やみくもにスタートアップスクリプトをインストールするのではなく、まずそれを見て、自分のシステムで動作するかどうかを確認することをお勧めします。Linux ディストリビューション、RPM、BSD パッケージなど、固定されたセットアップの一部として Netatalk を使用している場合は、おそらく適切に設定されているでしょう。そのため、以下の内容は Netatalk を自分でコンパイルした場合に適用されます。
以下のデーモンは、どのような起動スクリプト機構を使用しても起動する必要があります。 - netatalk さらに、設定ファイルafp.confが適切な場所にあることを確認してください。
