ownCloudをCentOS 6.2にセットアップして自分だけのDropbox

Dropbox++

Dropboxは激しく便利ではあるのですが現在、私の無料で使える容量は7.25GB。十分とはいえ、いつも気にしながら使わないと溢れる容量です。

本来の用途では使ってないのですがCamera Uploadsボーナス早期ベータ テスト期間で増えた容量5GBはありがたかった。現在は最大の追加は3GBみたいです。

Bitcasa（10GB！）など他の選択肢も増えてきましたが、もっと！（欲張り...）

それなりのサービスが欲しかったら課金しなさいですよね...ごもっともです（-ω-）

Dropboxですと毎月約$10で100GB。いいですね。たしかに高いというほどではない。バックアップもされているでしょうから安いくらいでしょうか。

しかしネットに繋がってさえいれば複数のMacで常に同期された状態のディスクスペースって、技術的にはそれほど難しくないよな〜自分のアカウントのS3を使って出来るんじゃね？ （Dropboxと同程度の正確性は難しいかもですが） ていうかあるに違いないと探してみるとS3じゃないけど、すぐひとつ見つかった。

ownCloud

インストール

さっそく試してみるのです。

このブログを運用しているVPSサーバを借りているのでそこにインストールします。ディスクは150GB以上余っていますから、これが使えれば私のMBAのSSD容量以上なので十分すぎます。

http://owncloud.org/install/ の.tar Archiveボタンをクリックするとダウンロードのための簡単な説明が表示されますのでリンクのURLをコピーして、

cd /path/to/work
wget http://download.owncloud.org/community/owncloud-5.0.0.tar.bz2
tar jxvf owncloud-5.0.0.tar.bz2

表示されているownCloud Administrators Manualリンクに飛ぶと、PHPが必要とのこと。自分では全く使わないので入っていない。そこから入れます（汗）

sudo yum install php php-gd php-xml php-intl

セットアップ

必要な道具は揃ったのでいよいよownCloudのセットアップをします。

sudo mv owncloud /path/to/htdocs/
cd /path/to/htdocs/owncloud
chown -R www:www app config

chownコマンドは自分の環境でhttpdが動かしているユーザを指定してください。

http://www.iwazer.com/owncloud/ にアクセスするとエラー（-ω-）

Apacheのログを確認すると

owncloud/.htaccess: ErrorDocument not allowed here

と出てました。.htaccessを使えない様です。権限を変えるのが面倒だったので、この.htaccessファイルをApacheのconf.dにコピーして読み込ませちゃいます。

sudo mv -p .htaccess /path/to/conf.d/owncloud.conf
sudo /etc/init.d/httpd restart

こんどは、ページが表示されましたが、まだ足らないようです。

ここに書かれている設定を行います。

sudo mkdir data
sudo chown www:www data
sudo yum install php-mysql php-mbstring php-pdo
sudo /etc/init.d/httpd restart

MySQLはもともと入っていたのですがパッケージのバージョンが合わなかったので、yumから入れ直しました。その際、パッケージリポジトリとしてremiを使いましたが、手順はCentOS6 で remi から php や mysql をインストールするための yum の設定を参照しました。

はたして...

adminアカウントとすべきユーザ名とパスワードを入力すれば、アカウント作成＆ログインします。

クライアントアプリ

Desktop appボタンをクリックしてMac Client（WindowsPCの方はそちらを）をダウンロードしてインストールします。

インストールしたowncloudアプリを起動すると、サーバへの接続設定ダイアログが表示されます。

さすがにhttpでは不安だったのでSSLにしました。自分しか使わないのでもちろんオレオレ証明書です。オレオレですよ警告は出ますが接続できました。

HomeフォルダにownCloudというフォルダが作成されていると思います。そこにファイルやディレクトリをコピーしてみると...メニューバーのアイコンがDropboxのようにクルクルはじめた！！

同期が終わったらしいのでブラウザからも確認してみると、ちゃんと同期されているようです。Dropboxに比べると少し遅いかなという印象でした。

もう一台で同期を試す

もう一台のロートルMacBookにもインストールして、こんどはダウンロード側を試してみました。

...だがしかし...いくら待っても同期される気配なし（-ω-）古いMacなのでOSがSnow Leopardで止まってるのですが、一応サポート対象ではあります。ずいぶん時間が経ってからSync Directory Statusがエラーになったり正常に戻ったりとイマイチな感触（笑）

まだこの状態ではDropboxから移行するわけにはいかないですが、ownCloudはオープンソースなのでGithubにリポジトリがあります！

https://github.com/owncloud

直せちゃいますね！（PHPかぁ...）

最後に

容量を気にせずに自分のための同期フォルダを持てるownCloudは非常に便利そうです。

じつはownCloudはファイルの同期だけではなく、というかそれは機能のごく一部で、音楽やカレンダーや連絡先をも同期するクラウドサービスなのです。いやクラウドの定義が微妙だけど、ネットの向こう側にデータがあるという意味で。

まだ使い始めたばかりですので後日またレポートしようと思います。

HerokuでRails3アプリケーションを作成するさいストレージにMongoDBを、ORMにMongoMapperを使用する場合の手順です。 ＃他にも方法があるかも知れませんが...

まだ、やってなかったらherokuモジュールを入れたり、Railsを入れたりアップデートしたりしときます。

$ gem install heroku
$ gem update rails

アプリケーションを生成します。MongoMapperを使うのでデフォルトのactive-recordを切っときます。

$ rails new test-app --skip-active-record
$ cd test-app
$ git init
$ git add .
$ git commit -m 'Initial commit.'

必要なモジュールを追加しましょう。

$ vi Gemfile

gem "mongo_mapper", '>=0.8.2'
gem "bson_ext"
gem "rails3-generators"
gem "rspec-rails"

$ bundle install

GeneratorにMongoMapperの設定を追加してもらいます。

$ script/rails g mongo_mapper:install test-app-db

ローカルではデフォルトのlocalhost:27017を使うとするとconfig/database.mongo.ymlは何も変える必要はありません。

接続できているか確認しましょう。

$ rails console
Loading development environment (Rails 3.1.3)
ruby-1.9.2-p290 :001 > class Hoge
ruby-1.9.2-p290 :002?>   include MongoMapper::Document
ruby-1.9.2-p290 :003?>   key :name, String
ruby-1.9.2-p290 :004?>   end
 => # 
ruby-1.9.2-p290 :005 > Hoge.create!(:name => 'Nanashi San')
 => # 
ruby-1.9.2-p290 :006 > 

mongoに直接つないでも確認してみます。

$ mongo
MongoDB shell version: 1.6.5
connecting to: test
> show dbs
test-app-db_development
> use test-app-db_development
switched to db test-app-db_development
> db.getCollectionNames()
[ "hoges", "system.indexes" ]
> db.hoges.find()    
{ "_id" : ObjectId("4ee6f1f15ce68e3de8000001"), "name" : "Nanashi San" }
> 

ローカルの接続設定ができたので、一度コミットしておきます。

$ git add .
$ git st
$ git commit -m 'local mongo setting'

次は、いよいよHeroku上でもMongoLabに繋がるようにしたいと思います。

$ heroku create
Creating warm-sunrise-3496...
 done, stack is bamboo-mri-1.9.2
http://warm-sunrise-3496.heroku.com/ | git@heroku.com:warm-sunrise-3496.git
Git remote heroku added

warm-sunrise-3496 という名前でHeroku上にアプリケーションができました。

MongoLab Add-onをアプリケーションに追加します。

$ heroku addons:add mongolab:starter
-----> Adding mongolab:starter to warm-sunrise-3496... done, (free)
       Welcome to MongoLab.

（MongoLabを使用するにはFree版を使う場合でもクレジットカードなどで課金情報を有効にしておく必要があります）

Herokuで作成したアプリケーションの設定ページを表示します。

https://api.heroku.com/myapps/warm-sunrise-3496

右上にAdd-onsというメニューがあるので、MongoLabを選択します。

Usersタブを表示して、Addボタンをクリックしアプリケーションが接続するためのユーザを登録します。

また、タブの上部に

mongodb://:@ds000000.mongolab.com:11111/heroku_app2222222

このような接続URI情報が表示されているのを確認し、config/database.mongo.yml のproductionモードにHerokuの設定を追加します。 usernameとpasswordは先ほどUserタブで追加したものです。

$ vi config/database.mongo.yml
 ：
production:
  <<: *defaults
  host: ds000000.mongolab.com
  port:11111
  username: hogehoge
  password: password
  database: heroku_app2222222
 ：

あと、もう一点。このままではポートの変更が効かないようで、初期化ファイルを少しだけ変更します。

$ vi config/initializers/mongo_mapper.rb

-  MongoMapper.connection = Mongo::Connection.new(mongo['host'])
　　↓
+  MongoMapper.connection = Mongo::Connection.new(mongo['host'], mongo['port'])

いよいよHerokuに送ります。

$ git add .
$ git commit
$ git push heroku master

動いたかな？

http://warm-sunrise-3496.heroku.com/

大丈夫そうです(｀･ω･´)

ローカルのMacBook ProにJenkinsを入れて色々試したくなりました。 サイトに行ったらMac OS X用のインストーラがあったので、これはラクチンだと入れてみたら少しハマったので回避方法を書いておきます。

まず、pkgをダウンロードしてインストールしてpsを見てみると既に起動してます。

コマンドオプションが何も指定されていないので、http://localhost:8080/を叩いてみると404 Not Found orz

システム環境設定を見てもJenkinsの設定などなく一旦終了しようとkill -KILLしても自動再起動してしまう...

調べたところLaunchDaemonで起動されているようです。 ここにドキュメントがインストールされてました。

しかしまず起動と停止の方法が知りたいのですが書いてません。LaunchDaemonで調べると下記コマンドで行える事が分かりました。

まぁ、ちゃんと動いてないので再起動しただけでは状況は変わらず。

/Library/LaunchDaemons/org.jenkins-ci.plistの内容を見てみると、

という指定があるのでディレクトリを見ると/Users/Shared/Jenkinsまでしかなく、ディレクトリの所有者がrootです。

jenkinsの実行ユーザはdaemonであるので、ここにHomeディレクトリを作れなくて実行できないと推測されます。

これで無事、起動することができました。

デフォルトは8080ポートで起動するのですが、8080は開発マシンとしては空けておきたいところです。

先程のドキュメントを見ると、OSXのdefaultsというコマンドで設定できるようです。

HTTPを18080ポート、AJP13を18009、ヒープサイズを128mに設定するには下記のようにします。

これで、まっさらなローカルJenkins環境ができました。

Shell History | Weboo! Returns.

おぉ、面白そうな企画です。恥ずかしいコマンド（？）が並んだらどうしようと思いましたが… $ history|awk '{a[$2]++ } END{for(i in a){print a[i] " " i}}' |sort -rn|head 191 cd 178 ls 162 tail 87 svn 85 script/imayomi 57 su 45 exit 39 less 16 vi 12 top $ わりとありきたりな結果に（汗）
やはり cd と ls は多いのだなぁ。tail もログを見てたりするので多い。

script/imayomi っていうのが謎ですが、実は今読ミ（imayomi）の再起動スクリプトなのでした。Rails プロジェクトの script ディレクトリ内に作りました。svn update してから script/imayomi を実行するという流れで今読ミの本番更新をしているというわけです。これが cd, ls, tail に次いで私が多く打つコマンドになっていると。つまり最近はほとんど今読ミの更新時にしか、このシェルを使ってないってことだ。

ちなみに、script/imayomi は、こんな Ruby スクリプトです。 #!/usr/bin/env ruby require 'open3' stdin, stdout, stderr = *Open3.popen3("ps -ef | grep 'mongrel_rails start'") stdin.close Thread.fork do stderr.each do |l| STDERR.puts "Terminate imayomi server failed!" exit 1 end end stdout.each do |l| a = l.split(/\s+/) process_id = a[1] system("kill -TERM #{process_id}") break end stdout.close script_dir = File.dirname(__FILE__) cmd = "ruby #{script_dir}/server -p 3030 -e production -d" system(cmd) …はい、そうです。ps -ef | grep 'mongrel_rails start' を打って、プロセスIDを調べて、kill -TERM するだけ。シェルスクリプトでいいじゃん！と思われるでしょうが、これを書いた当初は何でもRubyで書きたかったんです。Rubyスキルがまだまだ低いので、かなり無理無駄がありそうですが、まぁ便利に使ってます。
読むと分る通り、実はまだ分散してません。ユーザーが少ないのを良いことに 1 Rails サーバーで動かしちゃってます。よく言われますが、Rubyは本番環境を作るのが難しいですよね。たぶん mod_proxy_balancer で複数の mongrel_rails アプリケーションサーバーに分散する方法が一番使われているのかなぁ。
先週、mod_railsというのも知ったので、要チェックです！

完全に脱線しました。次のコマンドに行きましょう。
su が多い。これは良くない習慣だと思います。やはり山下さんの様に sudo すべきですよね。

次は exit 。私はいきなりターミナルエミュレーターをバッテンで殺すのは嫌いなので、抜けるときは大抵、律儀に exit を打ちます。

次が less に vi。ターミナルエミュレーターでは、テキストファイルの参照は less、編集は vi です。コード書きはEmacs派ですが、設定ファイル程度なら vi で編集します。
ちなみにサーバでの作業は、いつもWindows からPoderosaで接続しています。

最後に top。あまり起動している記憶はないので意外です。まぁ、サーバは基本、ほったらかしなので 12 回でもランクインしてしまいました。

ちなみにスーパーユーザーでも、ほぼ同じ。svn, script/imayomi, su の代わりに、ps, grep, apachectl などがランクインする感じでした

現在仕事で運営しているサイトはPHPで、複数のWEBサーバで稼働しているが、セッション情報を各WEBサーバのローカルファイルに保存している（PHPのデフォルト）ため、ユーザがサーバ間で移動するとセッション維持できない。

なので同じ接続元からは暫く同じWEBサーバに振り続けるような設定をロードバランサにしている。

ただ、これでは本当に負荷分散出来ていないわけだし、SSL用のサーバがより限定された台数しかないため、何も手を打たないとSSLアクセスした結果サーバが切り替わってセッション切れと、かっこ悪い事態になってしまうわけなのだ。

常々どうしようかと頭を悩ませていたわけなのだが一般的には次のどちらかで実現しているのだと思う。

・DBに覚える
・memcachedに覚える

DBに覚える方法は、ただでさえ負荷が高くなりがちなDBサーバに毎回、参照・更新する事になりちょっと怖いなと。

memcachedに覚える方法は、非常に魅力的なのであるが、daemonを終了すると全て忘れてしまうという、重大な不都合がある。

他にもRuby on RailsであればDRbを使う方法などあるんだが、残念PHP！
などとりとめもなく考えながらRSSを消化していると、こんな物を発見。

memcachedb

恐らくmemcachedのBerkeley DB版といった感じだ。おれの心眼が使えると言っている。

ただPHPのバージョンが古いので、まずはそこからというオチなのだが。