オブジェクトストレージ
1GBプランのバックアップイメージを512MBプランへ展開することはできない ようなので、結局手動で移設したなど。同期に失敗してデータ欠損しないかと動悸が止まりませぬ。
前提条件
現サーバー | 新サーバー | |
---|---|---|
ConoHaプラン(ともに東京リージョン) | 1GBプラン(月額900円) | 512MBプラン(月額630円) |
メモリ1GB+SSD50GB | メモリ512MB+SSD20GB | |
OwnCloud | 8.1.5.2 | 9.1.1.3 |
OS(ConoHa製アプリケーションサーバーイメージ | CentOS 6.7 (Final) | CentOS 7.2.1511 |
データ格納 | ConoHaオブジェクトストレージ |
- 現サーバー
- ConoHa 東京リージョン・メモリ1GB+SSD50GB
- OwnCloud 8.1.5.2
- OS (ConoHa製アプリケーションサーバーイメージ) CentOS 6.7 (Final)
- 新サーバー
- ConoHa 東京リージョン・メモリ512MB+SSD20GB
- OwnCloud 9.1.1.3
- OS (ConoHa製アプリケーションサーバーイメージ) CentOS 7.2.1511
データ格納先はともにConoHaオブジェクトストレージ
手順
- ownCloudとの同期アプリを全て終了(自動起動もOFFにしておくとなお安心)
- 現サーバーでmysqlのフルダンプを取得
$ mysqldump -u root -p owncloud_db |gzip -c > owncloud_db.dump.gz
- 新サーバー構築
- ConoHaコントロールパネルへログイン
- [サーバー追加]タブ
- タイプ=VPS
- メモリ=512MB
- イメージタイプ=アプリケーション
- アプリケーション=[その他] – ownCloud
- ディスク容量=SSD20GB
- その他の設定=適宜
- サーバー起動後、OSアップデート、作業ユーザー追加等々のセキュリティ対策は適宜。
- 現サーバーから新サーバーへmysqlのフルダンプをコピー
$ scp owncloud_db.dump.gz <新サーバーIP>:
- 現サーバーの /var/www/html/owncloud/config/config.php を新サーバーへコピー (注: このファイルはapacheオーナーのみ参照可になっているので、適当にセキュリティ突破すること)
$ scp /var/www/html/owncloud/config/config.php <新サーバーIP>:
- 新サーバーへログイン
- mysqlのダンプを新サーバー上mysqlへロード
$ zcat owncloud_db.dump.gz |mysql -u root -p -D owncloud_db
- config.php を /var/www/html/owncloud/config/ へ配置 (注: 既にファイルが存在するので、適宜バックアップ)
$ sudo cp config.php /var/www/html/owncloud/config/config.php
- /var/www/html/owncloud/config/config.php の内容を編集
- trusted_domainsの配列内に現サーバーのhostname, IPアドレス等があるので、これを新サーバーのものへ変更
- overwrite.cli.url のドメイン名部分を現サーバーから新サーバーのものへ変更
- version を 現サーバー(8.1.5.2)から新サーバー(9.1.1.3)へ変更
- dbpasswordを新サーバーのmysqlサーバー、owncloud_userアカウントのものへ変更
- /var/www/html/owncloud/config/config.php のオーナーを user=apache, group=apacheに変更(なお、SELinuxはDisabledになっていました)
$ sudo chown apache.apache /var/www/html/owncloud/config/config.php
- apache2をリスタート
$ sudo systemctl restart httpd
- 新サーバーのOwncloudへWebアクセスしてみる (成功していれば、セットアップ画面ではなく通常のログイン画面が表示されるはず)
- このあたり、初回はプラグインのアップデートが始まる場合も
- 新サーバーのOwnCloud上にあるべきファイルがあることを確認
- 各OwnCloud同期アプリを起動
- 現サーバーの設定を削除し、新サーバーの設定を追加
- 同期が成功することをConoHaたんに祈る
- 現サーバーはこれにてお役御免ですので、最後にバックアップするなり、きれいに削除するなり、お好きに。
新サーバーへの残項目
- HTTPS化
- SELinuxがDisabledなので有効化したい
- PHPが5.6系なので7.x系にしたい
- ていうかこのPHP、PHP-fpmになってないよね?
新サーバー(512MBプラン)の注意点
- やっぱりメモリに余裕ない感じ(以下は一通りの移設作業を終えた状態での計測)
$ free —mega
total used free shared buff/cache available
Mem: 489 386 10 1 91 75
Swap: 2047 121 1926
- yum upgradeしたら最初のyumリポジトリへのアクセスが遅いように感じました。メモリでしょうか…?
ConoHaのownCloudとオブジェクトストレージでオンラインストレージを作る(前編)の続き。いよいよオブジェクトストレージと連結し、Windowsの同期バックアップストレージとして運用しますよ。
ownCloudのデータ保存領域をオブジェクトストレージにする
ownCloud のドキュメントに設定のサンプルがあります。ただ、一部項目の入れ替えが必要となりますので注意。
ConoHaオブジェクトストレージを契約する
- ConoHa管理画面の「オブジェクトストレージ設定」 を開く
- 「ディスク容量」バーの右端にある設定アイコンをクリック
- お好みでディスク容量をセット。最低100GBからなので、予め使う容量が分かっているのでなければ、とりま100GBでよろしいかと。容量セット後から課金スタートです。
ConoHaオブジェクトストレージのAPI情報を確認する
APIユーザーにパスワードを設定します。既にある場合はテナント名、パスワード、エンドポイントURLを確認。
- 左側グローバルメニューの上から7つめ「API」をクリック
- 「APIユーザー」の右側「+ユーザー」ボタンをクリック
- 適宜パスワードをセット。ConoHaアカウント自体、ownCloud管理者、ownCloud運用VPSのroot(権限を持つ)アカウント等とはパスワードを変えておいたほうがより安全かと思われ。
- パスワードの他、画面上段の「テナント情報」内「テナントID」と「エンドポイント」内「Identity Service」の情報も確認。
ownCloudにオブジェクトストレージの情報をセットする
/var/www/htmi/owncloud/config/config.php に以下の内容を追加します。’dboassword’等と同じ階層になるよう注意。
'objectstore' => array(
'class' => 'OC\\Files\\ObjectStore\\Swift',
'arguments' => array(
'username' => ←APIユーザー名
'password' => ←APIパスワード
'container' => 'owncloud', ←任意のコンテナ名(別途作成が必要)
'region' => ← Identity Service URLの identity と conoha.io の間にあるサブドメインを指定。認証情報の endpoints.region としても得られます
'url' => ← Identity Service のURL
'tenantId' => ←テナントIDをセット
'serviceName' => 'Object Storage Service' ←ConoHa APIのエンドポイント名
),
),
ハマった点としては tenantIdがありました。ownCloudのサンプルコードでは tenantName を使用しており、ConoHaのAPI情報にも「テナント名」があるのでてっきりコレかと思ったのですが、「テナントID」のほうを渡してやらないとConoHaの認証エンドポイントから他のエンドポイント一覧が提供されないという罠。しかも tenantName があると tenantId を書いてあっても無視される。…というのを ownCloud のソースコードを追いかけまわしてようやく見つけましたよ…。
ConoHaオブジェクトストレージにコンテナを作成する
コンテナは自動では作成されない模様。 autocreate オプションは true にしてみても反応しないし、ソースコード中には「テスト用」的なコメントがあったのでどこかで無効化されているんだろうな。ともあれ、仕方ないので node.js でコンテナ生成だけ実行するスクリプトを書きました。gistにテンプレートがありますので宜しければどうぞ(以下)。こちらでの注意としては、認証URL(AuthURL)にバージョン番号が入らない点があります。node.jsは v5.2.0-linux-x64 を使用していますが、ほぼ同一の JavaScript を他のサーバーでかなり前に入れた v0.12.7 で動かしていたりしますので、概ね動くかと思われ。しかし node.js のバージョン番号はよく分からん。なんで1年も経たないうちにこんなに上がるんだ。
Windows 7 との同期
できれば WebDAV でスマートにいきたいのですが、HTTPS にしないといけないようです(レジストリをいじればいけるっぽい)。後々ちゃんとしたSSL証明書を取得する方向でいきたいので、今回はひとまず ownCloudの公式デスクトップアプリを使うことにします。
- owncloud.org の ダウンロード画面 から「Desktop Clients」をクリック、Windows用インストーラをダウンロード
- さくさくとインストール(これといった選択肢もありませぬ)
- さくさくと起動すると、サーバーアドレスを入力する画面が現れますので、http://
/owncloud/ を入力(結局ここでもHTTPS問題が発生…致し方なし) - ユーザ名とパスワードを入力
- サーバー側の同期対象フォルダ、ローカル側の同期対象フォルダを選択
あとはローカル側に作成された同期フォルダにがつがつとモノを入れていけば同期されるようデス。
ファイルの行先を確認など。
本当にちゃんとConoHaオブジェクトストレージに収まっているんでしょうか…?
- owncloud をインストールした VPS の
/var/www/html/owncloud/data/administraotr/files/
にはファイルが作成されていません - ConoHaオブジェクトストレージのディスク使用量を確認すると、イイ感じに増加しております
ということで、まあオブジェクトストレージには収まったかな、と。次の疑問は、具体的にどういうオブジェクトになっているのか、とか、メタデータとかどうなんですかね?といった点ですが。
あと、HTTPSは早めに対応しないとなぁ…。
ConoHa VPSに標準で用意されているownCloudアプリケーションサーバーとConoHaオブジェクトストレージを組み合わせて、Windows PCから同期可能なオンラインストレージを作る試み。まずはowncloudを起動するまで。
[2015.12.10] 追記
後編 も書きました。
レシピ
- ConoHa VPS (ownCloudパッケージ)
- ConoHa オブジェクトストレージ
- ownCloudのリファレンス
- このはへの愛(ん?)
VPSとオブジェクトストレージを契約
- 清楚可愛いこのはちゃんと契約する
- 言語モードを「このは」にする(重要!)
- ConoHaチャージ(月額で最低金額1500円くらいかな)またはクレジットカードを登録する
- ConoHa VPSは次の仕様で組んでみた
- vCPU 1個
- メモリ1GB
- 東京リージョン
- イメージタイプは「アプリケーション」を選択(初期値)
- アプリケーションは「その他」から「ownCloud」を選択、バージョンは8-x64固定
- なお、ベースになっているOSは CentOS release 6.7 (Final) カーネルは 2.6.32-573.7.1.el6.x86_64 でした (2015.12.06現在)
- owncloud自体は 8.1.3 がinstalled、yumで 8.1.4 が来ていますね(後程アップデートしませぅ)
- rootパスワードをセット
- 自動バックアップはお好みで。今回はアプリケーションサーバーとしてのみ使用するので、変更した設定さえ別途保管しておけば全体バックアップは不要かも。
- ディスク容量は最低のSSD50GBで十分。これでも多いかも?
- インストール後の空き容量は / が 51GB割り当て、47GB空きなのでがら空き…
- 準備が整うまでは色々危ないので、取り敢えず接続許可ポートはすべてOff(コントロールパネルのブラウザコンソールで作業する)。なお、ここのポートはConoHa VPS外部のファイアウォールらしく、VPS側でSSHポートを22番以外にした場合は「すべて許可」一択となる。
- SSHキーはお好みで新規作成するなり、手持ちをセットするなり
- ネームタグもお好みで
あとは料金を確認して「追加」ボタンを押し、準備が整うまでこのはちゃんのお姿を堪能して待ちませぅ。
コンソールを開いてVPSの初期設定
- 左側「サーバー」から目的のサーバーを見つけ、ネームタグをクリック
- 「コンソール」アイコンをクリック(新しいWebブラウザ画面で仮想コンソールが開く)
- 画面が真っ暗ならEnterとか押してみる
- 作業アカウントを作る
- rootで作業すると失敗が致命的になるし、rootでのSSHログインは拒否しておきたいので、通常作業するための作業アカウントを作り、sudo権限を与える
- [注意!] ConoHaのコントロールパネルでセットした公開鍵は、rootアカウントに紐付けられています(/root/.ssh/authorized_keysに書き込まれる)。作業アカウントは別途キーを準備するなり、rootからキーを奪ってくるなりしましょう(rootのキーを移動した場合はパーミッションとオーナーに注意)。
- /etc/ssh/sshd_config を開いて編集
- 「Port 22」のコメントアウトを外し、22番以外の未使用ポートに変更 (ポート22狙いのアタッカーが回避できます)
- 「PermitRootLogin」を「no」に変更 (SSH経由でのrootログイン不可)
- /etc/sysconfig/iptables を開いて編集 (空だった)
-A INPUT -m state --state NEW -m tcp -p tcp --dport <SSH port> -j ACCEPT
を追記- (owncloudのWeb画面を開くために)
-A INPUT -m state --state NEW -m tcp -p tcp --dport 80 -j ACCEPT
を追記 - あとはお好みで。基本的に全部 REJECT してホワイトリストのポートだけ ACCEPT すれば良いかと。
- この辺りのことは覚えたところで、どうせ CentOS 7になればfirewalldに代わって役に立たなくなりますよ… (今回firewalldを探して10分くらい彷徨った…)
- sshdとiptablesを(再)起動
$ sudo service sshd restart
$ sudo service iptables restart
- ConoHaのコントロールパネルの「ネットワーク情報」をプルダウンさせ、「接続許可ポート」で「すべて許可」を選択(以後、ポートアクセス制御はVPS側のiptablesに委任)
- お好みのターミナルエミュレーターから接続できることを確認 (以降はターミナルエミュレーターから作業)
- 念のため、rootでログインできないことも確認しませぅ
- さらに念のため、ConoHaコントロールパネルのWebブラウザコンソールからはrootでログインできることを確認しませぅ
- 適当なタイミングで
sudo yum upgrade
でも打って最新環境にするべし
ownCloudの設定
- コンソールにログインするとwelcomeメッセージとして URLやらMySQLのパスワードやらが表示されるので、URLにアクセスする。
- 管理者アカウントを作成する
- 試しに適当なファイルをアップロードしてみる
たぶん通常アカウントを作って、そっちで使ったほうが良い…いや所詮プライベートストレージだからこのままでもいいか…な?
なおアップロードしたファイルは /var/www/html/owncloud/data/<アカウント名>/files/ に収まる様子。 (/var/www/html/owncloud/data/ 以下はapacheユーザー/グループ管轄、otherにアクセス権無し)アカウント名>
残項目
- HTTPSアクセスにしたほうが良い気がするぞ
- ポートをガチガチに塞ぎ過ぎてメールアラートも出なくなってるので、必要なポートを開けたい
- ていうかちゃんとドメイン割り当ててメールサーバーも設定しておこう
- 本題であるWindowsとの同期とオブジェクトストレージの使用はどうした
[2015.12.08] 追記
yum upgrade したのち reboot してそのまま気持ちよく作業を終えたところ、数日経ってからアクセスしたら owncloud がメンテナンスモードに入ってしまっているという仕打ちが発生。モード解除自体は /var/www/html/owncloud/config/config.php 内の ’maintenance’ を false にすればOKだったのだけど、なんでメンテナンスになったんだ…。しかも画面には「owncloudを再起動すれば解除されます」とある割に、 httpd をリスタートしても何も変わらんかったし。
もしかして yum upgrade で owncloud 自体が 8.1.3 から 8.1.4 にアップデートされたので、このタイミングで自動的にメンテナンスモードになるんですかね…?
あと数日放置してたら、案の定 httpd にアタッカーの皆さんからご訪問を受けておりました。幸い突破された様子は無かったけど、一度アクセス範囲を見直したほうが良さげ。
[2015.12.10] 追記
後編 に続く…!