約1年越しでownCloudを触ってみてるのでレポートする。
ownCloud5.0で漸く実用レベルに？
昨年はownCloud4.0とWindows版クライアントアプリ1.0.3で検証していたが、そこから情報更新が滞ったのには訳がある。実のところ、複数のPC間でファイル共有を試してみたところ、ファイル更新時にうまく同一ファイルと認識されずコンフリクト扱いとなってしまう現象が頻繁に発生した。これでは使いものにならないので、検証をやめていたのだ。
今年の3月にownCloudが5.0になり、クライアントアプリも先月1.2.5になったので、再度試してみた。
複数アカウントでのファイル共有を検証
昨年のエントリ
自前でDropBoxもどきを作れるownCloudを入れてみたの冒頭で述べたように、私がownCloudに期待しているのは、おじさんでも使えるリポジトリを構築することである。セキュリティポリシー的にDropBox等のパブリックなサービスを使えない企業は多いと思うので、オンプレミスで構築できることが重要だ。
ownCloudをリポジトリ的に使うためには、複数のアカウントで同一ファイルを共有し、お互いが更新できる必要がある。また、履歴管理も必須だ。
このようなシナリオを想定して検証をスタート。
検証環境を下記のように定める。
サーバ
クライアント
| PC | OS | クライアントアプリ | アカウント |
|---|
| PC1 | Windows7 | 1.2.5 | dsp74118 |
| PC2 | Windows7 | 1.2.5 | member1 |
ownCloudのWeb UIの管理画面でアカウントを作成。
|
| Figure.1 アカウントの作成
|
アカウント"dsp74118"の方で、Web UIにてフォルダを作成。名前は"share"とした。member1との共有設定を行う。
|
| Figure.2 フォルダの共有設定
|
PC1にて、共有フォルダ"share"をローカルフォルダと同期させる。ここでは"D:\share"とした。
|
| Figure.3 PC1の同期設定
|
検証用に適当な文書を作ってみた。Excelおじさんらしく、Excelの台帳的なものにする。
|
| Figure.4 検証に使うドキュメントの初版 |
検証用文書を、PC1のローカル同期フォルダに保存。
|
| Figure.5 ローカル同期フォルダに文書を保存 |
しばらく待つと、PC1のクライアントアプリによって、文書がowncloudサーバに同期（アップロード）される。下図はWeb UIにてファイルの存在を確認したところ。
|
| Figure.6 ファイルが同期された様子
|
では、共有フォルダがmember1でどのように見えるか確認する。
member1のWeb UIを見ると、"Shared"というフォルダが自動作成されている。
 |
| Figure.7 Sharedフォルダが自動作成された様子 |
"Shared"の中を見ると、dsp74118アカウントが共有設定を行った"share"フォルダが確認できる。
 |
| Figure.8 Sharedフォルダ内に共有フォルダが見える |
PC2にてローカルフォルダとの同期設定を行う。リモートパスは、↑で確認したように"/Shared/share"となる。ここではローカルの"D:\ownCloudShare"と同期するよう設定した。
|
| Figure.9 PC2の同期設定 |
しばらく待つと、ローカル同期フォルダに、dsp74118アカウントが作成したファイルが同期（ダウンロード）されてきた。
|
| Figure.10 共有フォルダ内のファイルが無事ダウンロードされた。
|
では、PC2側でこのドキュメントを開き、更新してみる。下図の赤字部分を修正し、上書き保存する。
|
| Figure.11 PC2にてドキュメントを更新
|
しばらく待つと…。あれれー、PC2のクライアントアプリがエラーを吐いたぞ、どうなってる。しかし、ファイル名の右には「アップロード済み」の表示が。？？？？訳が分からない。同期（アップロード）できたのかい？ できなかったのかい？ どっちなんだい！
|
| Figure.12 クライアントアプリで何かエラーが出た
|
しばらく待ってからPC1のクライアントアプリを確認すると、「同期されたファイル」に「ダウンロード済み」と出てきた。どうやらPC2側の同期（アップロード）処理は無事成功し、PC1への同期（ダウンロード）も行われたようだ。
|
| Figure.13 PC1にてダウンロード完了
|
PC1上のファイル。Figure.5と比較すると、更新日時が変わったことが確認できる。
|
| Figure.14 PC1上のファイルの更新日付が変わった |
PC1でファイルを開いてみると、ちゃんと更新版になってた。
|
| Figure.15 PC1でファイルを開いてみたところ |
履歴機能を検証
次に、履歴機能を検証してみる。過去バージョンを取り出す操作は、Web UIでしか行えない。この辺りもDropBoxと同じだ。
履歴機能には2通りの使い方がある。
- Web UIにて任意のバージョンのファイルを指定してダウンロードする
- サーバ上のファイルを任意のバージョンのファイルに戻す(revert)
【その1 Web UIにて任意のバージョンのファイルを指定してダウンロードする場合】
下図のように、ファイル名の「バージョン」リンクをクリックし、取り出したいバージョンのタイムスタンプを選択する。ここでは初版のファイルを指定してみる。
※なお、過去バージョンがない（初回アップロード後に一度も更新されていない）ファイルの場合は"No older versions available"と表示される。
|
| Figure.16 ダウンロードしたいバージョンを指定
|
その後、"ダウンロード"をクリックすると、ダウンロードダイアログが出てくるので、ローカルの適当なところに保存する。
|
| Figure.17 ファイルのダウンロード |
ダウンロードしたファイルを開くと、ちゃんと初版が取り出せたことが分かる。
|
| Figure.18 古いファイルがダウンロードできたことを確認 |
【その2 サーバ上のファイルを任意のバージョンのファイルに戻す(revert)】
次に、サーバ上のファイルを過去バージョンに戻す検証をする。"All versions"をクリック。
 |
| Figure.19 All versionsをクリック |
戻したいバージョンの"Revert"ボタンをクリック。ここでは初版を選ぶ。
 |
| Figure.20 任意のバージョンにRevert |
その後、"ダウンロード"をクリックすると、初版のファイルがダウンロードできることが確認できた。
では、クライアントアプリはどう動くか？
|
|
| Figure.21 PC1上のファイルの更新日付が変わらない |
…あれ。ファイルの更新日付は、新しいバージョンのままだ。初版に戻ってくれない。
これじゃイマイチだなー。クライアントのローカルファイルも古いバージョンに戻ってほしいわ。
所感
同期できてるのにエラーと表示されたり、まだまだ不安定な感じが否めない。
サーバ上のファイルを旧バージョンにRevertした時にクライアントのファイルが旧バージョンに戻らないのもイマイチだが、技術的に難しいのだろうか。DropBoxとかだとどうだっけ。（試してない…）
あと、今回の検証では大量ファイルのテストをしていないが、ファイル数が多いと同期にめっちゃ時間がかかる。これも実用を考えると結構厳しい。
惜しいところまで来てるけど、まだ実戦投入には不安が残るように感じた。自分一人で使うならいいんだけど。更なる品質向上に期待したい。
0 コメント:
コメントを投稿