Metacat: メタデータとデータの管理サーバ
Metacat: メタデータとデータの管理サーバ
Note
Metacat のリプリケーション・サブシステムによって提供されていた機能の多くは、 現在では DataONE によって一般化・標準化されている。そこで、 リプリケーションのためには、Metacat 特有のリプリケーションシステムよりも、 より一般的・標準的な手法である DataONE のサービスを利用することを 考慮すること。 Metacat のリプリケーションシステムは今しばらくはサポートされる予定だが、 将来的にはおそらく非推奨とし、 DataONE のリプリケーション手法の使用を支持することになるだろう。
Metacat にはリプリケーション機能が組み込まれており、他の Metacat サーバと お互いにデータを共有する（XML文書とデータファイルの両方）ことができる。 Metacat は自分独自の文書を複製するだけでなく、他の Metacat サーバから 複製した文書も複製できる。リプリケーションネットワーク内のあるサーバに 対して変更が実行されると、その変更は自動的にネットワークに伝播される。 たとえネットワークが落ちていたとしても。
リプリケーション機能は、ユーザが自分のデータをローカルで管理しつつ、 （データを共有の Metacat リポジトリに複製することにより） より大きな科学コミュニティが集中型の検索を通じてそれらのデータを 使えるようにすることができる。 言い換えれば、各自のMetacat はより広いネットワークの一部になることができる が、しかし各ユーザはローカルリポジトリの制御権を保持しており、どのように 管理するか制御できる。
たとえば、KNB ネットワーク（図 6.1）は、現時点で世界中にある 10個の異なる Metacat サーバからできているが、リプリケーションを使用して まったく別々のサーバを結合し、単一の頑強かつ検索可能なデータリポジトリを 形成している。このリポジトリは、データの所有権を保存しており、 ローカルの管理者によって管理されているにもかかわらず、 データの発見を促進することができるのである。
KNB Metacat ネットワークの地図。
正しく設定されると、Metacat のリプリケーション機構は自サーバまたは 相手サーバで生じた数種のイベントをきっかけにして実行される。 すなわち、文書の追加、更新、または自動複製（つまり一定の時間間隔で モニタリングする）、この時間感覚はユーザが指定出来る。
| 複製のきっかけ | 説明 |
|---|---|
| Insert | Metacat に文書が追加されたら、サーバは リプリケーションリスト内の各サーバに、新しいファイルが 利用可能になったことを通知する。 |
| Update | 文書が更新されたら、サーバはリプリケーションリスト内の 各サーバに更新を通知する。 |
| Delta-T monitoring | ユーザが指定した時間間隔で、Metacat はリプリケーション リスト内の各サーバに対して更新された文書がないか調べる。 |
リプリケーションを設定するには、自サーバと相手サーバの両方に設定を 施さなければならない。
以下では各手順についてより詳しく説明する。
自サーバのリプリケーションリストのサーバを追加・削除・変更したり、 時間間隔処理を有効化したり調整したりするには、 Replication コントロールパネルを使用する。 これには以下の URL にある Metacat 管理インタフェイスを通じてアクセスできる。:
http://somehost.somelocation.edu/context/admin
“http://somehost.somelocation.edu/context” は各自の Metacat サーバの 名前とコンテクストで置き換えること（たとえば http://knb.ecoinformatics.org/knb/ ）。 管理者として Metacat にログインしなければならない。
Replication コントロールパネル。
なお現時点では、リプリケーションが実行された後で Replication Control Panel を使ってサーバを削除することはできない。 2つのサーバ間でのリプリケーションを停止するには、 メタデータやデータを複製するかどうかを制御するフラグを更新する。
Metacat のリプリケーション機能を利用する前に、 相手サーバと自サーバの両方においてセキュリティ証明書を生成しなければならない。 証明書がどのように生成されたかによって、 各サーバが他のサーバの複製用アクセスを「信用する」ために 証明書を交換する必要があるかも知れない。 証明書を商用のよく知られた認証局から購入した場合は、 リプリケーション前に証明書を複製相手と交換する必要はない。 Metacat のリプリケーション機構はクライアントの証明書の認証が有効化された SSL を信頼する。 複製相手のサーバが他の複製相手と通信する時は、そのサーバが信用出来る ということを検証して認証するための証明書を提出する。
自署証明書を作らなければならない場合は、複製相手のサーバは、 公的証明書（または署名した認証局の証明書）を既知認証局リストに追加する 必要がある。
註: 以下の記述は Ubuntu/Debian システム用である。
openssl を用いて秘密鍵を生成する。鍵は <hostname>-apache.key とする。ここで <hostname> は 各自の Metacat サーバの名前である。 以下の表に個々の入力項目の例を示す。
openssl req -new -out REQ.pem -keyout <hostname>-apache.key
| 項目 | 説明および例 |
|---|---|
| Country Name | 2文字の国コード （たとえば US） |
| State or Province Name | 州または地域の名前（略記しない）（たとえば California） |
| Locality Name | 市名 （たとえば Santa Barbara） |
| Organization Name | 社名もしくは組織名 （たとえば UCSB） |
| Organizational Unit Name | 部局名または部署名 （たとえば NCEAS） |
| Common Name | サーバのホスト名（ポート番号除く）（たとえば myserver.mydomain.edu） |
| Email Address | 管理者の連絡用メールアドレス（たとえば administrator@mydomain.edu） |
| A challenge password | （ここは空欄にする） |
| An optional company name | （ここは空欄にする） |
以下のコマンドを実行してローカルの証明書ファイルを作成する。
openssl req -x509 -days 800 -in REQ.pem -key <hostname>-apache.key -out <hostname>-apache.crt
鍵を生成した時と同じ <hostname> を使用すること。 <hostname>-apache.crt というファイルが openssl を実行した ディレクトリに作成されるだろう。 註: 証明書ファイルの名前は自由に付けて良いが、しかしこのファイルは リプリケーションのために複製相手に送付されるということを 気に留めておくと良いだろう。証明書の名前は、これを見た人が、 これがどこから来たもので、使用目的は何なのか、を十分に理解出来るような ものにするべきである。
証明書を Apache のセキュリティ設定に入れる。 これは複製相手に対して自分のサーバの身元を証明するのに使う。 証明書をローカルの Apache に登録しなければならない。 Apache のインストール方法によって、セキュリティ関係のファイルの 置き場はこの説明書の記述とは違っているかも知れないので 注意すること。 証明書と鍵ファイルを以下のようにコピーする。
sudo cp <hostname>-apache.crt /etc/ssl/certs
sudo cp <hostname>-apache.key /etc/ssl/private
リプリケーション API が使用された時にクライアントの証明書を要求するように Apache を設定する必要がある。 “knb-ssl” という補助ファイルに、Apache を SSL およびクライアント 証明書認証用に設定するデフォルトルールが入っている。 これらの SSL 設定項目を設定するには、knb-ssl ファイルを sites-available ディレクトリにコピーし、関連する値を 自分のシステムに合うように編集し、 a2ensite を実行して サイトを有効化する。 （註: knb-ssl 内の幾つかの設定項目は各自のシステムや Metacat の 配置に合うように変更する必要がある）
sudo cp <metacat_helper_dir>/knb-ssl <apache_install_dir>/sites-available
sudo a2ensite knb-ssl
ssl モジュールを有効化する。
sudo a2enmod ssl
Apache を再起動して変更を反映させる。
sudo /etc/init.d/apache2 restart
自署証明書を使用する場合は、 <hostname>-apache.crt を リプリケーション相手のコンピュータに scp して、 追加の認証局として追加する。
自署証明書を使用する場合は、証明書を作成して、各複製相手にそのファイルを scp で転送し、さらに各相手から逆に証明書ファイルを受け取った後で、 自サーバおよび相手サーバの両方でそれぞれの相手の証明書を 認証局として追加する必要がある。
証明書を Apache のディレクトリにコピーする
sudo cp <remotehostfilename> /etc/ssl/certs/
Apache 用に証明書のハッシュを作り直す。
cd /etc/ssl/certs
sudo c_rehash
ここで <remotehostfilename> は、複製相手によって作成されて 自サーバに転送されてきた証明書ファイルの名前である。
Java の keytool を使用してデフォルトの Java keystore にインポートする。
sudo keytool -import -alias <remotehostname_alias> -file <remotehostfilename> -keystore $JAVA_HOME/lib/security/cacerts
Tomcat を再起動する
sudo /etc/init.d/tomcat6 restart
ここで <remotehostfilename> は、複製相手によって作成されて 自サーバに転送されてきた証明書ファイルの名前である。 また<remotehostname_alias> はこの証明書に対する短く覚えやすい別名で、 $JAVA_HOME は Tomcat 実行環境の設定と同じものである。 註: cacerts のパスは、実際の Java のインストール状況によっては 違っているかも知れない。
サーバ証明書および秘密鍵両方のパスを Metacat に設定する必要がある。
metacat.properties を編集し、これらのプロパティを各自の状況に 合うように修正する。
replication.certificate.file=/etc/ssl/certs/<hostname>-apache.crt
replication.privatekey.file=/etc/ssl/private/<hostname>-apache.key
replication.privatekey.password=<password, or blank if not protected>
リプリケーションを使用するようにMetacat データベースを更新するには、 Replication Control Panel を使うのが簡単である。 または SQL を使ってデータベースを更新することもできる。 この節では両方のやり方を説明する。
Replication Control Panel を使って Metacat データベースを更新する。
リプリケーションを使用するようにMetacat データベースを更新するには、 Replication Control Panel で “Add this server” ラジオボタンを選び、 相手のサーバ名を入力し、リプリケーションの実行形式を指定する （xmlとデータを複製するか、またはローカルマシンをハブとして使うか）。
データベースにログインする
psql -U metacat -W -h localhost metacat
リプリケーションテーブルから全行を select する
select * from xml_replication;
相手サーバを追加する。
INSERT INTO xml_replication (server,last_checked,replicate,datareplicate,hub) VALUES ('<partner.server/context>/servlet/replication',NULL,1,1,0);
ここで <partner.server/context> は相手サーバの名前とコンテクスト である。’NULL, 1,1,0’ という値は（それぞれ）リプリケーションの 最終実行時刻、XML 文書が相手サーバに複製されるべきである、データファイルが 相手サーバに複製されるべきである、ローカルサーバはハブとして動作する べきではない、ことを示している。 自分の Metacat サーバを相手からの受信のみとし、相手に複製を送らない場合は ‘NULL,0,0,0’ と指定する。
データベースを抜ける
自サーバおよび複製相手のサーバの両方で、Apache と Tomcat を再起動する