ラベル nginx の投稿を表示しています。 すべての投稿を表示
ラベル nginx の投稿を表示しています。 すべての投稿を表示

2013/04/28

Raspberry Pi + L-02A + ServersMan SIM (490円SIM) で3G接続

Raspberry Pi(ModelB, Raspbian)を3G回線に接続してみることにしました。

回線は、ServersMan SIM 3G 100 (月額490円SIM)を使います。

通信端末は、RPi界隈においては D02HWがよく使われるようですが、
今回は、docomoのFOMA-USBデータ通信カード L-02Aを使います。安く入手できたので。
(※ 尚、ServersMan SIMは、docomo FOMAのMVNO回線ですので、最近よく売っている Xi端末では利用できません。L-02AはFOMA端末です
【2013/08/08 追記】9月より、ServersMan SIMもXiのMVNO回線 (即ち、LTE)へ移行となるようです。Xi用のデータ通信カードが利用可能となります。)

Raspberry Pi (Model B) + L-02A
加えて今回は、Raspberry Pi上でnginxを起動させ、Webサーバにしてみます。
実用的なサーバを求めているわけではなく、あくまで遊びです(笑)
速度/レイテンシはともかく、動的グローバルIPアドレスが割り当てられるので、一応サーバにも使えます。
(※ DTIはそのような利用目的を推奨していませんし、私もあくまで実験であり推奨しません。自己責任でお願いします。)

【2013/08/08 追記, 2014/04/05 編集】
ServersMan SIM 100がLTEに対応し、ServersMan SIM LTE 100へ移行されることとなりました。
これに伴い、グローバルIPアドレスの提供がなくなり、
プライベートIPアドレスのみとなりましたので基本的にWebサーバなどとしては使えなくなります。
(ngrokなどを使う方法はありますが。)




まずは、WindowsのPCに、SIMカードを取り付けた状態のL-02Aを接続して、一旦設定を行なっておきます。

docomoの接続ツールをインストールします。
接続設定は、Serversman SIMのものを使い、実際に一旦接続してください。
尚、このように一旦設定を行なっておかないと、後から Linux上に接続してponする際、問答無用に"NO CARRIER"でエラーになってしまいました。

次に、Raspberry Piを起動して...
コンソールで apt-getを用いて、"pppconfig"と"eject"をインストールします。
$ sudo apt-get install pppconfig eject

続いて、L-02Aを、Raspberry PiのUSBポートに接続します。

ここで、lsusb コマンドを実行...。
$ lsusb
~~~
Bus 001 Device 007: ID 1004:610c LG Electronics, Inc.
というように、認識されていることがわかります。

ところで、L-02Aは、ゼロインストール機能があるので・・・
接続直後はCD-ROMドライブとして認識される仕様になっています.
$ ls /dev/sr* -la
brw--rw---T+ 1 root cdrom 11, 0 xxx xx xx:xx /dev/sr0
これですね。CD-ROMになっています。

これをEjectすることで、本来のデータカードとして認識されるはず...。
が!しかし...このままejectしても、実際にはうまく行きません。

モデムを/dev/ttyUSB*として認識してほしいところなのですが、
/dev/ttyACM*として認識されてしまいます。

こちらのページによると...。
Ejectを行ったあと、cdc_acmドライバの読み込みが行われるらしいのですが、L-02Aは情報がないため、その読み込みに失敗するそうです。


ですから、対策としてcdc_acmドライバが読み込まれないように設定しておきます。
$ sudo vi /etc/modprobe.d/cdc_acm-blacklist.conf
blacklist cdc_acm

さらに、udevでttyUSB*として認識してもらうための設定をします。
(引用元http://slashdot.jp/journal/491733/ubuntu-9.04-%E3%81%A7-docomo-L-02A-%E3%82%92%E4%BD%BF%E3%81%86 (ありがとうございます!))
$ sudo vi /etc/udev/rules.d/99-foma_l-02a.rules
# for FOMA L-02A
# USB Storage (Zero Installation)
KERNEL=="sr[0-9]*", ENV{ID_VENDOR_ID}=="1004", ENV{ID_MODEL_ID}=="610c", RUN+="/usr/bin/eject /dev/$kernel"

# USB Modem (ttyUSB)
SUBSYSTEM=="usb", ATTR{idVendor}=="1004", ATTR{idProduct}=="6109", RUN+="/sbin/modprobe usbserial vendor=0x$attr{idVendor} product=0x$attr{idProduct}"</del>
これでL-02Aを接続しなおしてみると...。
$ ls /dev/ttyUSB* -la
crw-rw---T 1 root dialout 188, 0 xxx  xx  xxxx /dev/ttyUSB0
crw-rw---T 1 root dialout 188, 1 xxx  xx  xxxx /dev/ttyUSB1
crw-rw---T 1 root dialout 188, 2 xxx  xx  xxxx /dev/ttyUSB2
認識されましたね( ´∀`)b!

続いて、接続設定をします。

pppconfigを実行すると、テキストベースのGUIが表示されます。
$ sudo pppconfig
まずは、[Create]を選択。
尚、都合によりスクリーンショットはターミナルからSSH接続したものですw
  • Provider name:
    ponするときの名前になりますので、適当に入力します。
    ここでは、"serversman_sim100"としました。
  • Number: "*99***1#"
  • Authentication Method: "CHAP"
  • User: "user@3gd.ynmbl.net" → "user@dream.jp" (LTEへの移行にともない変更)
  • Password: "3gd" → "dti"
  • Speed: "115200"
  • Com: "/dev/ttyUSB0"
  • DNS:"Static"を選び、適当にGoogle Public DNSでも登録しておきますw
    ("Dynamic"を選んでも良いはずなのですが、何故かうまくいかなかったので・・・。)
    • Primary: 8.8.8.8
    • Secondary: 8.8.4.4
最後に "Finished"を選択して、接続設定は完了です。

あとは、ponコマンドで接続するだけです。 (ちなみに切断するときは、poffコマンド。)
$ sudo pon serversman_sim100
これで接続されます。
尚、接続中は、L-02Aのランプ(下側)が青色に点灯します。

接続できているか、確認してみましょう。
$ ifconfig -a
ppp0 Link encap:Point-to-Point Protocol
    inet addr:xx.xx.xx.xx  P-t-P:10.64.64.64  Mask:255.255.255.255
    UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
    RX packets:xxxxx errors:x dropped:0 overruns:0 frame:0
    TX packets:xxxxx errors:x dropped:0 overruns:0 carrier:0
    collisions:x txqueuelen:x 
    RX bytes:xxxxxx (xxx.x KiB)  TX bytes:xxxxxx (xxx.x KiB)
グローバルIPアドレスが割り当てられている事が確認できます。

pingも通るようならOKですね。
$ ping google.com
さらに、自動接続できるようにしておきます。
$ sudo gpasswd -a pi dip
$ vi /etc/local.d
~~~~
pon serversman_sim100

exit 0;
接続は以上です。

...おっとw サーバにしてみよう!ということでしたね ( ゚д゚)!

とりあえず、ファイアウォールの設定を。
いつも通りにiptableを直接使ってもいいのですが、Raspbianですし、手軽にufwで。
$ sudo ufw default DENY
$ sudo ufw allow 80/tcp
$ sudo ufw enable
あとは、nginxをインストールしてお茶を濁しておきます(笑)
$ sudo apt-get install nginx
$ sudo service nginx start

これで、他のPCのブラウザから、L-02Aに割り当てられたグローバルIPアドレスにアクセスすることで、Raspberry Pi上のHTTPサーバにアクセスができます!
歴としたWebサーバの完成です∩( ・ω・)∩!w

もちろん...このIPアドレスは変動しますので、一般的な自宅サーバなどと同様に、DDNS (MyDNS.jpなど)のお世話になると良いかと思います。
また、DDNSへのIPアドレス登録には、DiCEを使わせてもらってもいいのですが、今回はもっと簡単に、”数分ごとにIPアドレスの変動をチェックしてDDNSにIPアドレス登録を行う”ようなスクリプトを書きました。

あとは切断された時に自動接続するスクリプトを書いてcrontabに入れておくとか...。
perlでゴリゴリしてみるとか、Webカメラをつないでネットワークカメラ代わりにしてみるとか、何かおもしろいセンサーをつけてみるとか...
(Raspberry Piは普通にLinuxですので大概何でもできてしまいます。夢が膨らみますね(>ω<)♪ww)

※ 最後になりましたが、前もって当然のことながら、SSH等は別途必要に応じて適切に設定しておいてください。(パスワードログインを無効化して公開鍵認証にするとか、ポート変更をするとか....その他諸々。)

2012/08/06

Gitlabの導入 (Unicorn+nginxでサブディレクトリへ配置)

Gitlab 2.7をCentOS 6.2でインストールしてみることにしました。
nginx+Rails+Unicornで動作させます。
  • もはや言い訳のようになっていますが、試行錯誤の結果の自分用メモです (汗;)
    試行錯誤の結果、適当にやってみているところ、
    また、環境依存の箇所もありますのでご了承おねがいします
    m(_ _;)m
  • 従いまして、もし参考にしていただける場合は、お手数をお掛けしますが、
    一度このページの末尾まで全て目を通されることをおすすめします。
  • Gitlabのドキュメントでは、socketファイルを用いてnginxとUnicornを通信させていますが、この記事では、ポートを指定させて動作させます。
  • 本記事では、GitLabをサブディレクトリに配置して動作させます。
  • GitとGitoliteは以前に導入済みです:
    http://masanoriprog.blogspot.jp/2012/06/gitgitolite.html

作業の前にvisudoを実行し、secure_pathに/usr/local/binを追加しておきます。
(参照: http://blog.bungu-do.jp/archives/3525)
$ su
# visudo 
~~~~
Defaults    secure_path = /sbin:/bin:/usr/sbin:/usr/local/bin/:/usr/bin
~~~~
さて..まずはGitlabのためのユーザアカウントを作成します。
また、作成したアカウントをgitoliteのグループに所属させます。

# useradd gitlab
# usermod -G gitolite gitlab
次に、Gitのリポジトリディレクトリのパーミッションを変更しておきます。
(gitoliteグループに対して読み書き実行の許可をあたえます。)

# chmod -R g+rwx /pathto/repositories/
次に、GitlabアカウントがGitoliteに接続するためのSSH鍵生成と設定を行います。
とりあえず、gitlabユーザになるために一旦suします。
# su gitlab
$ ssh-keygen -t rsa -P "" -f ~/.ssh/gitadmin 
$ vi ~/.ssh/config
Host    localhost
HostName        localhost
User    gitolite
IdentityFile    ~/.ssh/gitadmin 
$ chmod 0600 ~/.ssh/config
$ git config --global user.name "gitadmin"
$ git config --global user.email "gitadmin@example.com"
$ exit
この作成したgitlabアカウントと鍵で
Gitolite上のgitolite-adminへアクセスできるよう設定しておきます。

(いつも管理してるクライアントPCからやると楽です。)
Gitlabのドキュメントでは、サーバ上でgitoliteをgit cloneして最初に鍵ファイルを設定して登録しています・・・
が...今回は、運用中のシステムのセキュリティの設定上面倒なこともあり、このようにしています。
本来であればドキュメント通りが正しいですのでそちらの方法で行なってください。
CLIENT $ git clone gitolite@example.com:gitolite-admin
CLIENT $ cd gitolite-admin/
CLIENT $ touch keydir/gitlab.pub
CLIENT $ vi keydir/gitlab.pub 
ssh-rsa ~~~~ gitlab@~~ #gitadmin.pubの中身をコピペ
CLIENT $ vi conf/gitolite.conf 
repo    gitolite-admin
        RW+     =   gitolite gitlab #gitlabを追加しておく
CLIENT $ git add .
CLIENT $ git commit
CLIENT $ git push
次に、Gitlabをgitlabアカウントのルートディレクトリへgit cloneしてきます。
# cd /home/gitlab/
# sudo -H -u gitlab git clone -b stable git://github.com/gitlabhq/gitlabhq.git gitlab
# cd gitlab/
# sudo -u gitlab mkdir tmp 
# sudo -u gitlab cp config/gitlab.yml.example config/gitlab.yml
GitlabでSQLiteを使うための設定を適用しておきます。
# sudo -u gitlab cp config/database.yml.sqlite config/database.yml
必要なものをインストールしていきます。
# easy_install pygments
# gem install bundler
# bundle
・・・とここでエラー(´・ω・`)
~~~~ ~~~~
Gem::Installer::ExtensionBuildError: ERROR: Failed to build gem native extension.
        /usr/local/bin/ruby extconf.rb
checking for main() in -licui18n... no
which: no brew in (/usr/local/bin:/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/sbin:/home/masanori/bin)
checking for main() in -licui18n... no

***************************************************************************************
*********** icu required (brew install icu4c or apt-get install libicu-dev) ***********
***************************************************************************************
*** extconf.rb failed ***
Could not create Makefile due to some reason, probably lack of
necessary libraries and/or headers.  Check the mkmf.log file for more
details.  You may need configuration options.
Provided configuration options:
--with-opt-dir
--without-opt-dir
--with-opt-include
--without-opt-include=${opt-dir}/include
--with-opt-lib
--without-opt-lib=${opt-dir}/lib
--with-make-prog
--without-make-prog
--srcdir=.
--curdir
--ruby=/usr/local/bin/ruby
--with-icu-dir
--without-icu-dir
--with-icu-include
--without-icu-include=${icu-dir}/include
--with-icu-lib
--without-icu-lib=${icu-dir}/lib
--with-icui18nlib
--without-icui18nlib
--with-icui18nlib
--without-icui18nlib

Gem files will remain installed in /usr/local/lib/ruby/gems/1.9.1/gems/charlock_holmes-0.6.8 for inspection.
Results logged to /usr/local/lib/ruby/gems/1.9.1/gems/charlock_holmes-0.6.8/ext/charlock_holmes/gem_make.out
An error occured while installing charlock_holmes (0.6.8), and Bundler cannot continue.
Make sure that `gem install charlock_holmes -v '0.6.8'` succeeds before bundling.
libicuが無いっぽいのでインストール。
# wget http://mirror.centos.org/centos/6/os/x86_64/Packages/libicu-4.2.1-9.1.el6_2.x86_64.rpm
# rpm -ivh libicu-4.2.1-9.1.el6_2.x86_64.rpm
# wget http://mirror.centos.org/centos/6/os/x86_64/Packages/libicu-devel-4.2.1-9.1.el6_2.x86_64.rpm
# rpm -ivh libicu-devel-4.2.1-9.1.el6_2.x86_64.rpm
# rm ./libicu-devel-*

もう一回、bundleを実行...
# bundle 
~~~ 
Your bundle is complete! Use `bundle show [gemname]` to see where a bundled gem is installed.
Post-install message from httparty:
When you HTTParty, you must party hard!
うまくいった。続いて...Gemのインストール。
# sudo -u gitlab -H bundle install --without development test --deployment
DBのセットアップ。
# sudo -u gitlab bundle exec rake gitlab:app:setup RAILS_ENV=production
構成のテストを行います。
# sudo -u gitlab bundle exec rake gitlab:app:status RAILS_ENV=production
rake aborted!
Connection refused - Unable to connect to Redis on 127.0.0.1:6379
Tasks: TOP => gitlab:app:status => environment
(See full trace by running task with --trace)
(´・ω・`)・・・まずRedis入ってなかったorz
# yum install redis
~~~
Installed:
  redis.x86_64 0:2.4.10-1.el6                                                
Complete!
# service redis start
はい。 もう一丁、テスト実行
# sudo -u gitlab bundle exec rake gitlab:app:status RAILS_ENV=production 
Starting diagnostic
config/database.yml............exists
config/gitlab.yml............exists
/home/git/repositories/............missing
rake aborted!
unexpected return
Tasks: TOP => gitlab:app:status
(See full trace by running task with --trace)

(´・ω・`)まあそりゃーな。無いもんな。
実はうちの環境では、/home/git/repositories/下にリポジトリを置いていないのです・・・
ということでGitlabの設定変更。

# vi config/gitlab.yml
~~~
git_host:
  admin_uri: git@localhost:gitolite-admin
  base_path: /pathto/repositories/  # host: localhost
  git_user: git
~~~
再度、テスト実行。
# sudo -u gitlab bundle exec rake gitlab:app:status RAILS_ENV=production 
Starting diagnostic
config/database.yml............exists
config/gitlab.yml............exists
/var/lib/gitolite/repositories/............exists
/var/lib/gitolite/repositories/ is writable?............YES
ssh: connect to host localhost port 22: Connection refusedfatal: The remote end hung up unexpectedly
Can clone gitolite-admin?............YES
UMASK for .gitolite.rc is 0007? ............NOrake aborted!
unexpected return
Tasks: TOP => gitlab:app:status
(See full trace by running task with --trace)



まず、うちの環境ではSSHのポートを22番から変更しているため
接続できていないということ・・・。
なので再度、Gitlabの設定(gitlab.yml)を変更しておきます。
# vi config/gitlab.yml
~~~~
git_host:
  admin_uri: gitolite@localhost:gitolite-admin
  base_path: /pathto/repositories/
  host: example.com #ホスト名もちゃんと設定しておく。
  git_user: git
  upload_pack: true
  receive_pack: true
  port: 22 #コメントアウトを外してポート番号を変更。
~~~~
同時に、GitlabユーザのSSH設定のほうも変更しておきます。
# vi /home/gitlab/.ssh/config 
Host    localhost
HostName        localhost
User    gitolite
IdentityFile    ~/.ssh/gitadmin
Port    22
また、.gitolite.rc内のUMASKを書き換えろとのこと。やってなかったので・・・
うちの環境では、/var/lib/gitolite/下にありますのでそれを書き換えます。
# cp /var/lib/gitolite/.gitolite.rc  /var/lib/gitolite/.gitolite.rc.backup
# vi /var/lib/gitolite/.gitolite.rc
$REPO_UMASK = 0007; #0077の箇所を0007にしておく 
これで...もう一度、テスト実行。
# sudo -u gitlab bundle exec rake gitlab:app:status RAILS_ENV=production
bundle exec rake gitlab:app:status RAILS_ENV=production
Starting diagnostic
config/database.yml............exists
config/gitlab.yml............exists
/var/lib/gitolite/repositories/............exists
/var/lib/gitolite/repositories/ is writable?............YES
remote: Counting objects: 31, done.
remote: Compressing objects: 100% (24/24), done.
remote: Total 31 (delta 7), reused 0 (delta 0)
Receiving objects: 100% (31/31), 3.10 KiB, done.
Resolving deltas: 100% (7/7), done.
Can clone gitolite-admin?............YES
UMASK for .gitolite.rc is 0007? ............YES


OKですね〜。

データベースに初期データを登録します。
# sudo -u gitlab bundle exec rake db:setup RAILS_ENV=production
# sudo -u gitlab bundle exec rake db:seed_fu RAILS_ENV=production
このとき、初期ユーザ名とパスワードが表示されるのでメモを。
さて、デーモン起動させてみましょう。
#  sudo -u gitlab bundle exec rails s -e production -d
=> Booting Thin
=> Rails 3.2.5 application starting in production on http://0.0.0.0:3000
お。OKっぽいですねw 続いて...Resqueプロセスを起動させてみます。 
# ./resque.sh
では今後は、Unicornで。
# sudo -u gitlab cp config/unicorn.rb.orig config/unicorn.rb 
# sudo -u gitlab bundle exec unicorn_rails -c config/unicorn.rb -E production -D
次にGitlabをサブディレクトリ下で動作させるために
設定ファイル(config.ru)を変更します。

(config.ruを開いて、run ~~ の一行を次のように囲みます。)
# vi config.ru 
require ::File.expand_path('../config/environment',  __FILE__)
map ActionController::Base.config.relative_url_root || "/" do
        run Gitlab::Application
end
また、バックエンドとなるUnicornをサービスさせるポートを定義するために
Unicornのスクリプトファイル(unicorn.rb)を変更します。
# vi config/unicorn.rb 
~~~~
#listen "#{app_dir}/tmp/sockets/gitlab.socket" #コメントアウトする
listen 8081 #Unicornをサービスさせるポート番号を指定
~~~~
さらに、すでに稼働させているnginxの設定ファイル(nginx.conf)に
Gitlabのためのリバースプロキシ設定を追加しておきます。

$ su

# vi /etc/nginx/nginx.conf

upstream gitlab {
    server 127.0.0.0:8081; #Unicornのポート番号を指定
}
~~~~
server {
    ~~~~
    location ~ ^/gitlab/(.*) { #Gitlabを配置するディレクトリを指定
        proxy_redirect off;
        proxy_pass http://gitlab;
        break;
    }
}

nginxの実行アカウントをgitlabグループに所属させておきましょう。

# usermod -G gitlab nginx

そして、nginxを再起動。
# service nginx restart

さらにgitlabをServiceにするために
/etc/init.d/gitlab を作成しておきましょう。

(Source: https://github.com/gitlabhq/gitlabhq/blob/stable/doc/installation.md)
# vi /etc/init.d/gitlab 
#! /bin/bash
### BEGIN INIT INFO
# Provides:          gitlab
# Required-Start:    $local_fs $remote_fs $network $syslog redis-server
# Required-Stop:     $local_fs $remote_fs $network $syslog
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: GitLab git repository management
# Description:       GitLab git repository management
### END INIT INFO
DAEMON_OPTS="-c /home/gitlab/gitlab/config/unicorn.rb -E production -D --path /gitlab" #Gitlabを配置するディレクトリを指定
NAME=unicorn
DESC="Gitlab service"
PID=/home/gitlab/gitlab/tmp/pids/unicorn.pid
RESQUE_PID=/home/gitlab/gitlab/tmp/pids/resque_worker.pid
case "$1" in
  start)
        CD_TO_APP_DIR="cd /home/gitlab/gitlab"
        START_DAEMON_PROCESS="bundle exec unicorn_rails $DAEMON_OPTS"
        START_RESQUE_PROCESS="./resque.sh"
        echo -n "Starting $DESC: "
        if [ `whoami` = root ]; then
          sudo -u gitlab sh -l -c "$CD_TO_APP_DIR > /dev/null 2>&1 && $START_DAEMON_PROCESS && $START_RESQUE_PROCESS"
        else
          $CD_TO_APP_DIR > /dev/null 2>&1 && $START_DAEMON_PROCESS && $START_RESQUE_PROCESS
        fi
        echo "$NAME."
        ;;
  stop)
        echo -n "Stopping $DESC: "
        kill -QUIT `cat $PID`
        kill -QUIT `cat $RESQUE_PID`
        echo "$NAME."
        ;;
  restart)
        echo -n "Restarting $DESC: "
        kill -USR2 `cat $PID`
        kill -USR2 `cat $RESQUE_PID`
        echo "$NAME."
        ;;
  reload)
        echo -n "Reloading $DESC configuration: "
        kill -HUP `cat $PID`
        kill -HUP `cat $RESQUE_PID`
        echo "$NAME."
        ;;
  *)
        echo "Usage: $NAME {start|stop|restart|reload}" >&2
        exit 1
        ;;
esac
exit 0
スクリプトのパーミッションを変更。
# chmod +x /etc/init.d/gitlab
自動起動を有効にしておきます。
# chkconfig --add gitlab
# chkconfig gitlab on
あとはサービスを実行するだけ。
# service gitlab start
これで・・・
http://example.com/gitlab/ にアクセスすると・・・


うまく行ったようです♪

追記: このままではpublic/uploads/下にアップロードするファイルに
アクセスすることができませんでした。
ということで・・・nginxの設定ファイル(nginx.conf)に修正を...。
# vi /etc/nginx/nginx.conf 
~~~~
        location ~ ^/gitlab/uploads/(.*) {
                #静的ファイル
                rewrite ^/gitlab/uploads/(.*) /$1;
                root    /home/gitlab/gitlab/public/uploads/;
                index   index.html;
                ssi     off;
                break;
        }
        location ~ ^/gitlab/(.*) {
                proxy_pass      http://gitlab;
                break;
        }
~~~~
さらに、/home/gitlab/ のパーミッションに
# chmod g+x /home/gitlab/
しておく。以上です。

これで静的ファイルはnginxから直接レスポンスされるようになります。
たぶんこんな感じでOKなはずです。たぶん(汗;←

2012/04/30

nginxをリバースプロキシとしてSubsonicを構築する

SubsonicをVPS上で稼働させることにしました。
そのままポート割り当てて公開してもいいのですが、
折角ですからSubsonicのオレオレ証明書ではなく、
nginxで利用している正規のSSL証明書を使うために、
nginxによるリバースプロキシを通してみることに。

Subsonicに一つのポートを割り当てて単独で動作させるのではなく、
nginxで動作しているサーバの"subsonic/"ディレクトリ下を割り当てることにします。

Java環境は導入済なので・・・

まずは...Subsonicをrpmパッケージでインストールします。
(2012/04/30現在の最新は、subsonic-4.6)

http://www.subsonic.org/pages/download.jsp
$ cd ~
$ wget http://downloads.sourceforge.net/project/subsonic/subsonic/4.6/subsonic-4.6.rpm
$ sudo rpm -ivh subsonic-4.6.rpm
これだけで自動的にSubsonicが動作しはじめます。お手軽です。


自動エンコードに必要なライブラリ類をyumでインストール。

$ sudo yum -y install lame flac faad2 vorbis-tools ffmpeg
(参照: http://sourceforge.net/apps/mediawiki/subsonic/index.php?title=Transcoders


次に、Subsonicの設定
を変更します。(/etc/sysconfig/subsonic)
$ sudo vi /etc/sysconfig/subsonic 
SUBSONIC_ARGS="--port=8100 --max-memory=100 --context-path=/subsonic"
こんな感じで、Subsonicのポート番号と、パスを指定しておきます。


さらに...nginxの設定に、Subsonicへのリバースプロキシを追加。

$ sudo vi /etc/nginx/nginx.conf

upstream Subsonic.backend {
server 127.0.0.1:8081;
}
server {
        listen       80;
        〜〜〜
        location ~ ^/subsonic(\/|).* {
                if ($server_port = 80){
                        rewrite (.*) https://$http_host$request_uri last;
                        break;
                }
                proxy_pass      http://Subsonic.backend;
                proxy_redirect  http://$http_host/subsonic/  https://$http_host/subsonic/;
                break;

        }
}
基本的には、proxy_passでSubsonicのアドレスを指定するだけなのでシンプルですね。
ここでは、HTTPでアクセスしたときにHTTPSへリダイレクトする記述と、
proxy_directを使って、Subsonicがリダイレクトさせようとしたときに
HTTPSへリダイレクトされるように記述をしておきました。


あとは、Subsonicとnginxの設定を反映させて・・・

$ sudo service subsonic restart
$ sudo service nginx restart

ブラウザからアクセスしてみます。
(http//〜〜〜/subsonic/)


とりあえず、うまく動作しているようです。


参考にさせていただきました。(感謝♪)

2012/02/24

nginxのログをLogWatchにセットする

nginxのログをLogwatchにセットしておくのを忘れていました。
ということで設定します。

Logwatchの設定ファイルを ユーザ設定ディレクトリに作成します。
# touch /etc/logwatch/conf/logfiles/httpd.conf
作成したファイルをエディタで開いて...
# vi /etc/logwatch/conf/logfiles/http.conf
LogFile = nginx/*access.log
Archive = nginx/*access.log.*.gz
*ExpandRepeats
*ApplyhttpDate 
という感じで、nginxのログファイル名とアーカイブファイル名、オプションを記述。

尚、nginxの設定によりログは/var/log/nginx/下に出力するよう設定しています (→前記事)。
また、ログローテートはlogrotateを利用しており、/etc/logrotate.d/nginxで設定済みです。

ちなみに、Logwatchの設定ファイルの配置構成ですが・・・
(※間違っている可能性があります)

  • /usr/share/logwatch/default.conf/ - デフォルトの定義設定が格納されたディレクトリ
    • logfiles/〇〇〇.conf - ログファイルグループの定義設定
       ("ログファイルのパス"が指定されている。)
    • services/△△△.conf - サービスフィルタの定義設定
       (サービスフィルタが処理する"ログファイルグループ名(○○○)"が指定されている。)
  • /usr/share/logwatch/dist.conf/ - ディストリによる定義設定が格納されたディレクトリ
  • /usr/share/logwatch/scripts/ - デフォルトのサービスフィルタ(処理スクリプト)が格納されたディレクトリ
    • logfiles/〇〇〇 - ログファイルフィルタ (Perlスクリプト)
       (ログファイルグループ"○○○"に対する処理スクリプト)
    • services/△△△ - サービスフィルタ (Perlスクリプト)
       ("△△△"のログ内容に対する処理スクリプト)
    • shared/***
  • /etc/logwatch/conf/ - ユーザによる定義設定を格納するディレクトリ
    • logfiles/〇〇〇.conf - ログファイルグループの定義設定
    • services/△△△.conf - サービスフィルタの定義設定
  • /etc/logwatch/scripts/ - ユーザによるサービスフィルタ(処理スクリプト)を格納するディレクトリ
    • logfiles/〇〇〇 - ログファイルフィルタ (Perlスクリプト)
    • services/△△△ - サービスフィルタ (Perlスクリプト)
となっているようです。たぶん。(間違いあれば、ご指摘お願いします!)

元々、/usr/share/logwatch/default.conf/logfiles/下には"http.conf"が存在しており、
そこにApacheのためのログファイルグループ定義が記述されています。


今回はさらに、/etc/logwatch/conf/logfiles/下に"httpd.conf"を新しく作成して
そこにnginxのための定義を記述しました。
こうすることで.../usr/share/logwatch/default.conf/logfiles/下の"http.conf"で定義された内容に加えて(上書きではなく追加で)、今回の定義した内容が追加されて処理されるようです。
つまり、nginxの定義設定を Apacheのための定義設定に追加したことになります。
そのため、ログの処理は、Apacheのためのスクリプトがそのまま利用されます。
nginxのログはApacheのログと形式が殆ど同じであるためにこれが可能なのですね。
尚、実際のログレポートは、Apacheとnginxのログが混ざった形で送られてきます。
(Apacheのためのログファイルグループ定義を上書きしたのではなく、あくまでそこに追加しただけであるからです。)

LogWatchによって生成されるレポートメールは
# logwatch -service http -print
でテスト出力を行うこともできます。
(この例では、httpサービスフィルタのテスト。)
あと、設定にもよりますが・・・
動作チェックのためにわざとログに残るようなアクセスをしてみても、
Logwatchのレポート出力範囲が”昨日分”だったりするので、
うっかり忘れていたりすると戸惑いましたw 注意ですね(^^;))


参考にさせていただきました(感謝♪):

2012/02/23

nginxによるリバースプロキシ+Apacheによるバックエンドの構成 (with SSL)

nginxによるリバースプロキシ+Apacheによるバックエンドの構成をしてみました。
1台のサーバ上で、nginxとApacheが共存している状態です。
  • example.com 203.0.113.0
    • nginx - リバースプロキシ
      • 127.0.0.0 :80
      • 127.0.0.0 :443 (SSL)
    • Apache - バックエンド
      • 127.0.0.0 :8080 - ローカルのみ
      • 127.0.0.0 :8443 - ローカルのみ
nginxとApache間は、ローカルでHTTP通信をしています。
(SSLであっても、nginxでSSLを取り払って、Apacheへ渡しています。)

[課題]
問題としては、”Apache側のポート番号”がありました。
バックエンドであるApache自身でリッスンしているポート番号が8443であるために、
Apache上のCGIがリダイレクトなどを行う際に、
ユーザから見える本来のポート番号である"443"(=nginxのポート番号)ではなく
"8443"へリダイレクトしてしまうという状態となったのです。

もし、複数台のサーバ環境であれば、nginxとApacheを1台に共存させる必要がないため、
Apacheのポート番号を、nginxのポート番号と同じにしておけば良いのですが・・・。
今回はとりあえず、Apacheが都合よく、自分のリッスンしているポート番号ではなく
本来のポート番号をCGIなどに伝えてくれれば良いので、
Apache側の設定で環境変数を書き換えして解決しました。
これについてご指摘や正しい解決方法などありましたら、アドバイスお願いします m(_ _)m

[おことわり]
この構成ではあまりリバースプロキシにする意味がないのですが、
実は...この記事は端折っていて、実際の運用では
バックエンドとして、Apacheだけでなく他のアプリケーションも用意しており、
この記事のApacheへの振り分けと同様に
nginxのLocationディレクティブで振り分けるようにしています。
また、キャッシュや圧縮をnginx側で行なってもらっていたりします。
今回は、あくまでSSLまわりの設定の仕方をメモすることが目的の記事であるため、
これだけの内容に端折りました
。 あとの詳しいことはまた追々(汗;)



nginxは、先日インストールしたものです:
Masanoriのプログラミング日誌++: nginxをEPELから導入して最新版上書き&モジュール導入

Apacheに”mod_rpaf”モジュールを適用。
http://stderr.net/apache/rpaf/
http://stderr.net/apache/rpaf/download/mod_rpaf-0.6.tar.gz
尚、Apache 2.2なので、デフォルトでUseCanonicalName Off。

/etc/nginx/nginx.conf :
リバースプロキシであるnginxの設定
user              apache apache;
error_log  /var/log/nginx/error.log;

http {
    access_log  /var/log/nginx/access.log  main;
    server {
        listen 80;
        listen 443 default_server ssl;
        server_name _;
     
        ssl_certificate        /etc/pki/tls/certs/server-chained-ca.crt;
        ssl_certificate_key  /etc/pki/tls/certs/server.key;
     
        charset utf-8;
     
        proxy_set_header Host                   $http_host;
        proxy_set_header X-Real-IP              $remote_addr;
        proxy_set_header X-Remote-Addr          $remote_addr;
        proxy_set_header X-Forwarded-For        $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Host       $host;
        proxy_set_header X-Forwarded-Server     $host;
        proxy_set_header X-Forwarded-Proto      https;
        proxy_set_header X-Forwarded-Port       $server_port;
     
        location ~ ^.+ {
                #この例では全てのアクセスを振り分けている
                if ($server_port = 80){
                        proxy_pass      http://127.0.0.1:8080;
                        break;
                }
                if ($server_port = 443){
                        proxy_pass      http://127.0.0.1:8443;
                        break;
                }
        }
        〜
    }
}
/etc/httpd/conf.d/vhost.conf :
バックエンドであるApacheのHTTPアクセス時設定
NameVirtualHost *:8080
Listen 8080
<VirtualHost *:8080>
    DocumentRoot "/var/www/a/hogehoge"
    ServerName example.com:80
    CustomLog /var/log/apache/access.log combined
    ErrorLog /var/log/apache/error.log
    SetEnv SERVER_PORT 80
</VirtualHost>
/etc/httpd/conf.d/vhost_ssl.conf :
バックエンドであるApacheのHTTPSアクセス時設定
LoadModule ssl_module modules/mod_ssl.so
NameVirtualHost *:8443
Listen 8443
<VirtualHost *:8443>
    DocumentRoot "/var/www/a/hogehoge"
    ServerName https://example.com:443
    ErrorLog /var/log/apache/ssl_error.log
    CustomLog /var/log/apache/ssl_access.log combined
 
    SetEnv SERVER_PORT 443
    SetEnv HTTPS ON
 
    SSLEngine off
</VirtualHost>
別に..ファイルを分ける必要も、LoadModuleする必要も無い気がしますが(汗;)

/etc/httpd/conf.d/rpaf.conf :
Apacheの”mod_rpaf”モジュールによって、
アクセス元であるリバースプロキシのIPアドレス(127.0.0.0)を
実際のアクセス元のIPアドレスに置き換えるための設定。

LoadModule rpaf_module modules/mod_rpaf-2.0.so
RPAFenable On
RPAFsethostname Off
RPAFproxy_ips 127.0.0.1
こんな感じです。

参考にさせていただいたページ(感謝♪):

2012/02/22

nginxをEPELから導入して最新版上書き&モジュール導入

nginxをEPELから導入したいと思います。
最新版は1.0.12ですが、EPELには最新版がありません。
また、nginxのモジュールの組み込みにはビルドしなおす必要があります。

だったら完全にソースから...となるのですが、それはそれでinit.dの準備などなど面倒です。
そのため、EPELからnginx-0.8.55-1を取得して...これを基に、
nginx-1.0.12と、モジュール ngx_cache_purge-1.5 を適用します。

今回は...
http://sakuratan.biz/archives/4582 と
http://sakura.off-soft.net/centos/apache-nginx-1-reverse-proxy-install.html

を参考にさせていだきます。感謝♪
(参考というか大半写しですね...自分用のメモを兼ねているのでお許しを m(_ _)m
以下の内容を参考にされる方は、そのまえに上記のサイトをじっくりお読みください。

前準備にパッケージをインストール。
$ sudo yum --enablerepo=epel install make automake gcc gcc-c++ rpm-build spawn-fcgi pcre-devel zlib-devel openssl-devel libxslt-devel GeoIP-devel gd-devel

次にEPELからnginxのSource RPMをダウンロード。
nginxの最新版は1.0.12なわけですが、ここにあるのは0.8.55-1。
http://dl.fedoraproject.org/pub/epel/5/SRPMS/repoview/nginx.html
$ wget http://dl.fedoraproject.org/pub/epel/5/SRPMS/nginx-0.8.55-1.el5.src.rpm
インストール。
$ sudo rpm -ivh nginx-0.8.55-1.el5.src.rpm
警告: グループ mockbuild は存在しません - root を使用します

とりあえず、このエラーは無視で構わないそうです。

次は、このインストールしたnginxに対して
最新版のnginxとモジュールで上書きをします。


まずはインストールしたソースディレクトリへ移動して...
$ su
# cd /usr/src/redhat/SOURCES
nginxの最新版(1.0.12)のパッケージをダウンロード。
# wget http://nginx.org/download/nginx-1.0.12.tar.gz
次に、ngx_cache_purge モジュールの最新版(1.5)のパッケージをダウンロード。
# wget http://labs.frickle.com/files/ngx_cache_purge-1.5.tar.gz
さらに、SPECファイルを編集します。
SPECディレクトリへ移動して、nginx.specをエディタで開きます。

# cd /usr/src/redhat/SPECS
# cp nginx.spec nginx.spec.org
# vi nginx.spec
11行目付近:バージョン番号を変更。
Version:        1.0.12

42行目付近:モジュールのパッケージファイル名を追加。
Source10:   ngx_cache_purge-1.5.tar.gz

51行目付近:パッチのための記述をコメントアウト。
#Patch0:     nginx-auto-cc-gcc.patch

60行目付近:同様にコメントアウト。
#%patch0 -p0

61行目付近:ビルド前処理としてモジュールパッケージを展開する記述を追加。
%setup -T -D -a 10

69行目付近:文字コードを設定する記述を追加しておきます。
export LANG='ja_JP.UTF-8'

106行目付近:モジュールを追加しているため、ここの記述も書き換え。
    --with-cc-opt="%{optflags} $(pcre-config --cflags)" \
    --with-cc-opt="%{optflags} $(pcre-config --cflags)" \
    --add-module=%{_builddir}/nginx-%{version}/ngx_cache_purge-1.5
make %{?_smp_mflags}

110行目付近:モジュールのドキュメントファイルの名前を変更する記述を追加。
mv ngx_cache_purge-1.5/CHANGES ngx_cache_purge-1.5/CHANGES.ngx_cache_purge
mv ngx_cache_purge-1.5/README.md ngx_cache_purge-1.5/README.ngx_cache_purge

168行目付近:モジュールのドキュメントファイルをnginxに追加。
%doc ngx_cache_purge-1.5/CHANGES.ngx_cache_purge ngx_cache_purge-1.5/README.ngx_cache_purge

これで上書きします。

あとは・・・ビルド。
# rpmbuild -bb nginx.spec
〜〜〜
書き込み完了: /usr/src/redhat/RPMS/x86_64/nginx-1.0.12-1.x86_64.rpm
書き込み完了: /usr/src/redhat/RPMS/x86_64/nginx-debuginfo-1.0.12-1.x86_64.rpm
実行中(%clean): /bin/sh -e /var/tmp/rpm-tmp.56019
+ umask 022
+ cd /usr/src/redhat/BUILD
+ cd nginx-1.0.12
+ rm -rf /var/tmp/nginx-1.0.12-1-root-root
+ exit 0

ビルドが終わったようです。
あとは、今できあがったパッケージをインストールします。
# cd ../RPMS/x86_64/
# rpm -Uvh nginx-1.0.12-1.x86_64.rpm

これで完了ですね。