2012/12/17

Sublime Text2を使い始めた

Sublime Text2というエディタを使い始めました。
http://www.sublimetext.com/

私は、WindowsではTeraPadユーザ...
また、Linuxでは、(にわか) Vimmer...(CUIでは専らVimです。一応。)
Eclipse/Aptana Studio ユーザでして....

エディタというのは慣れたもの以外は使いたくならないモノだったりしますが、
そんななかでも気になるエディタなのですw

簡単に言うと・・・
わりと美しいUIで...GUIを適度に活かしていて、
操作がややこしくなく、サクサク軽いということ。
インクリメンタルに結構気持ちよく補完してくれたり。
尚、ファイルは、単体はもちろん、フォルダごとプロジェクト的に開くことも可能。
ファイルの切り替えなんかもインクリメンタル検索でプレビューしながら行えますし、
あと、ミニマップで俯瞰できたり、終了するときは何も表示されず次回起動時に自動復元されるとか...
自分としては...これ面白いな&良いな〜と思うところが色々w


Sublime Text2で perlのファイルを編集しているところ。
Ctrl+Pでこのようにファイルをインクリメンタル検索しながらプレビューできる。
対応開発言語は幅広い。各種ライブラリのための入力補完・サポートなども...Packageで拡張可能。

特に何でも使えますが、私としてはWeb向きのエディタかなーと思います。
シンプルなテキストエディタや、逆にEclipseのようなIDEも良いのですが、
エディタとIDEの中間的なアプリケーション...という感じでしょうか。
ちなみに、Linux/Windows/Macのクロスプラットフォームで動作します。
(有料 59ドルですけど...全機能を制限なしにずっと試せます。払う価値もありそうです。)

基本からシンプルで使いやすいのですが、
Packageのインストールで機能強化できるところがミソですね。

他のブログで特徴や使い方を紹介してくださっているのでそちらを。
例えば、jQueryなどの各種フレームワークのサポートや、
MarkdownやLaTeXのための入力補完とか...。
Gitを組み込めるとか...。簡単に実現できます。

まずは、"Package Control"というPackageをインストールしておくと、
他のPackageをSublime上で楽々インストールしていくことができます。
こちらのページにあるコードをコピーして、[View]メニュー → [Show Console]をクリック、画面下に表示されるコンソールへ入力。

あとは、コマンドパレット(Ctrl+Shift+P)を開いて、
"install"などと入力して、Package Controlを呼び出すだけです。

(参考)私がインストールしたPackage:
  • Abacus - 複数行のコードを整形表示
  • AngularJS - AngularJSのスニペット
  • AutoFileName - ファイル名を自動補完
  • BracketHighlighter - カッコの強調表示
  • CSS Snippets - CSSのスニペット
  • Color Picker - 色ピッカー
  • Dart - Dartのスニペット
  • Git - Gitを扱うためのPackage
  • Gist - GitHubのGistを扱うためのPackage
  • HTML - HTMLのスニペット
  • jQuery - jQueryのスニペット
  • Markdown Preview - Markdownのプレビュー
  • Mojolicious - perlのWAF "Mojolicious" のスニペット
  • SublimeCodeIntel - 各種開発言語の自動補完など
  • SublimeLinter - HTML/CSS/JavaScriptなどなどのLint(構文チェック)
  • Terminal - ターミナルでカレントファイル/ディレクトリを開く
  • Nexus - Theme(テーマ)
  • ...
尚、SublimeLinterなどの一部のプラグインでは、nodeを介してコマンドを実行したりします。その場合は、nodeのインストールが必要です。
(参照: Ubuntu 11.04 Natty Narwhal に Node と npm をインストール - 自分の感受性くらい)

インストールしたPackageは
基本的にコマンドパレット(Ctrl+Shift+P)から呼び出せます。

また関係ないんですが、
設定ファイルがJSONフォーマットということも...
ある意味、今どきのエディタらしいですねw

カスタマイズはかなり効きます。
 参照: Y.A.M の 雑記帳: Sublime Text 2 の設定

私はとりあえずこれだけですが、設定しています:
{
 "color_scheme": "Packages/Color Scheme - Default/Monokai.tmTheme",
 "draw_white_space": "selection",
 "highlight_modified_tabs": true,
 "ignored_packages":
 [
  "Vintage"
 ],
 "theme": "Nexus.sublime-theme"
}

ショートカットもある程度は覚えておくと捗ります。チートシートを作ってくださっているので使わせていただきましょう。
 Sublime Text | Periodic table of the Keyboard Shortcuts.
また、キーバインディングは自分好みに変更できます。

「今までのエディタは放り投げろっ!」とも言えませんし...私もそうは思いませんが、
それでも、「お!?」と思えた、なかなか良さそうなエディタです。
しばらく弄ってみたいと思います。

2012/12/03

組み込み(マイコン)、はじめました。

プログラミングというモノを独学&趣味でかじりはじめて...
...気づけば、もう8年にもなるのですね〜・・・。
まだまだ初心者の域を出ませんが(汗;)w

ここ5年間くらいはWebやネットワーク系を独学で遊び・学んできましたし、
大学に入って、C++やアルゴリズムを学びつつ、ちょっとばかり組み込み方面にも触れて...といった感じで過ごしてきました。

そして大学2回生 冬となった今。

昔から「組み込み(*)をやりたいな〜」と思うことが幾度もあったにもかかわらず、これまで結局は取り組んだことが無かったのだと言う事を
友人のおかげで気づかされた...そんな今日このごろです。

(* 組み込み...というかセンサーロボットとかヘリコプターとか(ry) ロボコンとか!!)

やるなら今だっ! (ある意味、私にとっての新境地開拓ですww)

ということで、組み込み(マイコン)を始めました(笑)

最初のテーマは組み込みOSの自作です。
(何年か前にPC向けの自作OSをかじり...かけたこともありました。見事に投げてしまいましたがw)

理由としては・・・
  • 何よりOSの勉強になる!
  • 低階層な組み込みを折角やってみるのだから、
    面白そうですし踏み込んでやってみたいな〜。
というところです。

低階層を理解することが自分にとっての貴重な学びになるのだ...ということを、
友人・知人から教えてもらった、影響を受けた...という理由も大きいです。


Raspberry Piとか、mbed、Arduinoなど、比較的容易に扱えるボードにとても興味があって、
目的に応じてやりたいことを手軽に(そこに注力して)やれるのが良いな〜と思うのですが、
ただ、今のうちにもっと低いレベルにも触れておくことも大事なんだなーと悟ったのですw(

Rasberry Piを使って作りこんだりというのもまた必ずやってみたいです。
また、もっと新しいマイコンでロボットなども近いうちに挑戦してみるつもりです。

参考にさせていただく本は...


です。

これは、H8/3069Fのマイコンボードを使って、シンプルな組込みOSを作る本です。
ブートローダーから、割込み/スケジューリング等々をすべて実装していきます。
まさにこんな事、やりたかった><!
(筆者の方のサポートサイトでは、TCP/IPスタックの実装、Webサーバの搭載まで広げているようです。
私も、実はネットワーク系を志していたりするので、ココは外せないところですねw)


さらに参考にさせていただくウェブサイトとして...
2回目のC言語で『12ステップで作る組込みOS自作入門 』の通りに組込みOSを作ってみた - 三等兵
かなり最近(3ヶ月前)の記事ですが、Mac OS (Lion)を用いてこの本に取り組まれたそうです。私もLinux(Fedora 17)での開発となりますし、詰まった時には特に参考にさせていただこうと思います(><;)ゞ

早速、ボードのほうも調達しました。
ちょっと昔の自分みたいに、半田ゴテを持ち出して(汗;)...とも思ったのですが、
流石にここは大人しく...本の指示どおりに、部品実装済みのボードを購入しました。
秋月のAKI-H8/3049Fネット対応マイコンLANボード完成品 という商品です。

使用するマイコン自体、アーキテクチャ的にはもう古くなってしまっている?感じもするのですが、私にはこれで十分すぎますw
なにせ最初の第一歩なので、本どおりに進めてもつまづきそうですし(笑)


とりあえず...初日の今日は、セルフコンパイルのための開発環境構築から...。
とはいっても、普段使いのFedoraにはgccやその他諸々が入っていて、何かと使っている状況なので、特段やることはなさそうです。

シリアル<->USBケーブルがまだ手元ににないので、この先はお預けです(´・ω・`)w
(家を探しまわれば、どこかに落ちているかもしれませんがw)
尚、今回、シリアル<->USBケーブルは、BUFFALOのBSUSRC0610BSを購入しました。


のんびりでも、確実に取り組んでいきたいな〜と考えています。
友人とのWeb開発や、他にも進めたいプロジェクト・勉強がありますので、
平行になりますが、逐一メモを兼ねて、このブログに進捗状況をアップしていけたらな〜と考えています(><)/
頑張りますっ。

今後、一連の記事は"自作OS"というタグでまとめたいと思います。
こちらから一覧できます。

2012/11/05

【解決】GitLabでGit HTTPが使えない問題 (※サブディレクトリ環境)

昨日に引き続き、GitLabの話です。
GitLab 2.7から"Git HTTP"(Git Smart-HTTP)が実装されていたのですが、

いつもはSSH経由で利用しているため、これまでは使っていませんでした。
(※ Git HTTP = HTTP経由でGitLabを通してリポジトリにアクセスする機能)

さて...今日はこのGit HTTP機能をいざ使ってみようと...

GitLab3.0の画面。[SSH]ボタンと並んだ [HTTPS]ボタンをクリックすると
Git HTTPによるURLが表示される。
(URLは、プロジェクトの通常のURLに".git"を付加したものとなる)
表示されたURLをブラウザから開いてみる...と...
回やっても認証画面がwww

正しいメールアドレス+パスワードを入力しているのに
401エラーが出るという・・・(汗;)w

ところで。GitLabでは、サブディレクトリ下での運用を本来サポートしていません。
ですので、私はリバースプロキシ(nginx)を通して少々無理やり運用しています。
(それについては、記事:Gitlabの導入 (Unicorn+nginxでサブディレクトリへ配置)を参照)

今回は恐らく、そのための問題なのだろう...と仮定して調べてみました。
(他の可能性としては、gitlab.ymlの設定ミスもありますが、今回は問題ありませんでした。)

→ 結果...その通り!やはりサブディレクトリ下で運用していることが問題なようですorz

とりあえず...手探りで試行錯誤してみましたので、
対策方法を以下に残しておきます。

[注意] GitLabのサブディレクトリでの運用が本来サポート外であるうえに、
私はいまのところ Ruby/Unicornに全く詳しくありませんww
そのため保障はできませんが、参考にまで。
...もっと良い方法があればアドバイスお願いします m(_ _)m )





/gitlab/lib/gitlab/backend/grack_auth.rb : 17行目付近〜

@env['PATH_INFO'] = @request.path
@env['SCRIPT_NAME'] = ""

# Find project by PATH_INFO from env
#if m = /^\/([\w-]+).git/.match(@request.path_info).to_a #コメントアウト
if m = /^(\/([\w-]+))*?\.git/.match(@request.path_info).to_a
    self.project = Project.find_by_path(m.last)
    if m2 = /\/([\w-]+*?.git\/.*)/.match(@request.path).to_a
        @env['PATH_INFO'] = "/#{m2.last}"
    end
    return false unless project
end

変更点としてはこれくらいです。



以下に、何を行ったかの解説&メモを書いておきます。

まずGitLabでは、Grackというモジュールを用いることで
このGit HTTPを実現しているようです。
GitLabのルーター(/gitlab/config/routes.rb)はユーザからアクセスを受けると、
Git HTTPのためのアクセスをここで受け取ります。

Grackの認証(Basic認証)には、GitLab上のアカウント情報が用いられます。
実際にその処理を行なっているのは/gitlab/backend/grack_auth.rb ですね。


上のgrack_auth.rbでコメントアウトした行とその次行の
# if m = /^\/([\w-]+).git/.match(@request.path_info).to_a
    self.project = Project.find_by_path(m.last)
はリクエストされたパス(@request.path_info)からプロジェクト名を抜き出しています。
本来、パスが"/hoge.git/aaaa"だとしたら、
hogeという部分が正規表現で抜き出され、self.projectに代入されるわけです。

ただ当然これでは、パスがサブディレクトリを含んでいると正しく抜き出せないですね。

ですので...コメントアウトした行の代わりにこのように追加しました:
if m = /^(\/([\w-]+))*?\.git/.match(@request.path_info).to_a

これにより、サブディレクトリであっても正しくプロジェクト名が抜き出せます。

さて...この修正だけで、事態(?)には光が見えてきます(笑)w
プロジェクト名が正しく抜き出せなかったために、
プロジェクトを探せず、401エラーになっていたようです。

これでとりあえず、401エラーが改善し、認証は正常に通るようになります。

が...。

ここでまだ、git cloneしてもうまく行かないはず・・・。

Grackの認証が済むと...
プロジェクト名やパスを環境変数(@env)で渡して次の処理を
/gitlab/vendor/bundle/ruby/*.*.*/bundler/gems/grack-*/lib/grack/*.rb
が行うわけですが・・・。

ここでリポジトリ上のファイルを読み込む時・・・
サブディレクトリのせいでパスを正常に扱えず、ファイルが見つからないのですw
なのでエラーとなります。

この対策のために、前のステップでパスを直しておくことにしました。
先ほどとおなじくgrack_auth.rbでやってしまいましょうw

以上の理由から、先ほどの行の後に2行追加しました:

        if m2 = /\/([\w-]+*?.git\/.*)/.match(@request.path).to_a
                @env['PATH_INFO'] = "/#{m2.last}"

正規表現マッチもあれな書き方ですが、未だ詳しくないので許してください(><;)

これににより、環境変数に入れるパスからサブディレクトリ部分が削られます。
つまり、本来、GitLabが意図しているパスになるわけです(>ω<)♪

これで一応、解決です。

試しに...クライアントから
$ git clone https://example.com/git/hoge.git
を実行してみてください。正しくcloneできるはずです。

今回は以上となります。

今回もこのヒントを得るためにGitHubやコミュニティを参考にさせていただきました。
ありがとうございました m(_ _)m♪


p.s.

そもそもサブディレクトリじゃなくルートでGitLabを運用したらいいのに...
と思われる方もいらっしゃるかもしれません・・・。

私は学生個人でサーバを運用しています。
そしてこういったものに、HTTPSは必須だと考えております。
ところで、ルートディでGitLabを運用するには、当然、サブドメインなり別サーバ/IPアドレスなりの方法を取らなければなりませんが、
それをするとなると、サーバ証明書もGitLab用に別途用意することになります・・・。
サブドメインでも使える証明書は高価ですし・・・。
そこまでの余裕は無いのです(´・ω・`)...。

尚、GitLabはサブディレクトリへの対応を実装することは今のところないそうです。


2012/11/04

GitLab 2.8→3.0にバージョンアップ

前回の記事(Gitlab 2.7 → 2.8にバージョンアップ)から約2ヶ月...
9月末にGitLab 2.9が公開されていたんですが...
つい先月(10月)末に、GitLab 3.0が公開されたようです。
http://blog.gitlabhq.com/gitlab-3-dot-0-released/

とりあえず変更点を...(適当に翻訳しましたw)

2.9での変更点は以下の通り (公式ブログより抄訳)
  • 400コミット以上の素晴らしいコード
  • コメントの表示順を変更 (Wallを除く)
  • omniauthのサポート (twitter, google…)
  • Bunch of stuff の修正 (訳注: たくさんのモノ/諸々 とでも訳しておきますかw)
  • 多くのコードのリファクタリング
  • Gitolite v3への対応
  • 絵文字機能
  • LDAPとOAuth設定を一つに集約 -> config/gitlab.yml
  • ProfileとAdmin画面に新機能
  • 多くのAPIを追加

そして 3.0での変更点は以下の通り (こちらも公式ブログより抄訳)
  • 300コミット以上の素晴らしいコード
  • ウェブエディタ機能
  • より多くのAPIを追加
  • ファイルブラウザの改善
  • SSH鍵の追加と削除についての致命的な不具合修正
  • (非公式な) Postgreサポート
  • プロジェクトグループ機能
  • ファイルとコミットについてのパフォーマンスがかなーり改善
  • コードのリファクタリングとクリーンアップ など...
うーん。これは楽しみ!!
ということで、3.0へのバージョンアップを行いたいと思います(>ω<)

私の場合、2.9→3.0ではなく2.8→3.0のバージョンアップとなるため・・・
こちらのドキュメントを参考にしたいと思います:

https://github.com/gitlabhq/gitlabhq/wiki/From-2.6-to-3.0
(そうじゃなくてすでに2.9をお使いの方はこちらを参照)

毎度のことですが、更新はgit pullして取得できて楽ですね。
今回はそれに加えて、hooks(post-receive)の上書きと、
gitlab.ymlの再設定が必要になりました。
必要に応じて、バージョンアップ前にバックアップをとっておくといいかもしれません。
(さらに私の環境では、サブディレクトリで動作させる等々しているので殆ど前回同様に再設定が必要でした。)


GitLab 3.0にバージョンアップ完了

それにしてもGitLab、友人と一緒の開発に使っていますが...使いやすいですね。
(元々のアイデアであるGitHubもそうですけれど)
他のプロジェクト管理システムよりも色んなモノを削って、またGitに特化している分、
使いやすさがあるんだろうな〜と思います。

GitLab 2.9から追加された Issueでの+1 機能。
コメントを書く時、"+1"という文字を入れておくと、カウントしてくれます。
こういう機能も他のプロジェクト管理システムだとプラグインで使えたりしますが、
標準で実装されるのはちょっと嬉しいですねw
(尚、軽めにぼかし入れてますが、開発中のモノです。見えてもいいんですけど一応軽くw )
Trac,Redmine,etc...を使っていると、
欲を言えば、GitLabはモノ足りないかなーと思うことが無いこともないんですけど、
それでも...必要十分以上の機能は揃っているわけです。
毎日のように使うツールですから、”シンプル”であることは大切だと思います。
開発メンバーが増えたときの慣れやすさを考えてもそうですしね。




2012/10/30

Perl/Wx - Wx::Demo サンプルGUIアプリケーションを試そう

昨日(Perl/Wxをはじめてみよう (PerlでGUIアプリケーション))に引き続き、
PerlとWx(WxWidgets)でGUIアプリケーションを作るという話題です。

今回はCPANで公開されているデモアプリケーション(Wx::Demo)を試してみます。
サンプルプログラムとソースコードをインストールできるモジュールになっていて、
インストールするだけ、とっても簡単に試せます。

利用する環境は昨日の記事とおなじく、Linux(Fedora 17)+ perl-5.14.2 です。
すでにwxWidgetsとWxモジュールもインストール済みとなっています。



まずはWx::Demoをビルドしてインストールします。
http://search.cpan.org/~mdootson/Wx-Demo-0.19/lib/Wx/Demo.pm
執筆時点の最新版は、Wx-Demo-0.19となっています。
アーカイブファイルを適当なディレクトリに展開して、いつもどおりビルドします:

$ wget http://search.cpan.org/CPAN/authors/id/M/MD/MDOOTSON/Wx-Demo-0.19.tar.gz
$ tar zvxf Wx-Demo-0.19.tar.gz
$ cd Wx-Demo-0.19/
$ perl Makefile.PL
$ make
$ make test
$ sudo make install

これでWx::Demoのインストールは完了です♪

あとは実行するだけ:

$ wxperl\_demo.pl

これでこのようなウィンドウが表示されます。



左側のペイン("Categories"タブなど)に、サンプル一覧がツリー表示されます。
これを選択すると、右側のペインにこの画像のようにサンプルが表示され、
さらにSourceタブから該当ソースコードも閲覧できる仕組みになっています。

ちなみに、このWx::DemoをMacやWindowsなど他の環境で実行すると...
それぞれの環境に用意されたネイティブGUIを使って、違和感なく表示されます。
これは"ネイティブGUIへのラッパーを基本としているwxWidgetsの強み"でもあります。
(また、その環境のネイティブGUI上に該当するパーツが存在しない場合には、wxWidgetsによって再現された共通的なパーツで代替する仕組みになっています。)

今日はここまで(>ω<)♪


2012/10/29

Perl/Wx(wxPerl)をはじめてみよう (PerlでGUIアプリケーション)

Perl/Wxをはじめてみよう...ということで。
WxWidgets(クロスプラットフォーム対応のGUIライブラリ)で
超シンプルなGUIアプリケーションを作りますw とっても簡単です。


まず、wxWidgetsというのは、
Windows / Mac / Linux(GTK)のネイティブGUIを利用できるラッパーライブラリです。

PerlのCPANで公開されているWxモジュール(WxPerl)は、
このWxWidgetsをPerlから利用するためのモジュールです。
最新版は、0.9914 (2012年10月02日)、かなり最近です。
これに関して、Perlでこの話題を持ちだしてきたのにはちょっと理由があるのですが、それは最後にでも(笑)

余談ですが、かの "Google Drive"のPC向けアプリケーションも
wxWidgets(wxPython)で開発されているようです (→公式サイトのNews
参照)
様々なアプリケーションに利用されているライブラリであることは何より安心できますね(>ω<)♪



さて今回は、Linux(Fedora 17)環境で wxWidgets 2.9.4による
GUI(GTK+2)アプリケーションを作ってみたいと思います。

(尚、WindowsやMacにおいても、書くべきソースコードは共通となります。
WxWidgetsとWxモジュールのインストールが少々異なってきますが、参考にしてください。)

perlの環境がインストールされていることが前提です。
(私のFedora環境では、perl-5.14.2を利用しています。)

まず、GTK+2の開発パッケージをインストールします。
$ sudo yum install gtk2-devel

次に、Alien::wxWidgetsモジュールをビルドしてインストールします。
(今回はCPANでうまくインストールできなかった為、自前でtar.gzをダウンロードしビルドしました。)
http://search.cpan.org/~mdootson/Alien-wxWidgets-0.62/lib/Alien/wxWidgets.pm
このモジュールは、ビルド時に適切なWxWidgetsを取得してビルドしてくれます。

$ wget http://search.cpan.org/CPAN/authors/id/M/MD/MDOOTSON/Alien-wxWidgets-0.62.tar.gz
$ tar zxvf Alien-wxWidgets-0.62.tar.gz
$ cd Alien-wxWidgets-0.62/
$ perl Build.PL
〜ここで以下のような質問が表示されますが適当に答えて... 2.9.4 (執筆時点のLatest Development版) をインストールしてもらいますw〜 Which wxWidgets version? (2.8.10, 〜 , 2.9.4) [***] 2.9.4
Which archive type? [tar.bz2 ] (そのままEnter)
Do you want to include OpenGL support [no ] (そのままEnter)

$ perl Build
$ perl Build test
$ sudo perl Build install
$ sudo ldconfig

次に、Wxモジュールをビルドしてインストールします。http://search.cpan.org/~mdootson/Wx/Wx.pm

$ wget http://search.cpan.org/CPAN/authors/id/M/MD/MDOOTSON/Wx-0.9914.tar.gz
$ tar zxvf Wx-0.9914.tar.gz
$ cd Wx-0.9914/
$ perl Makefile.PL
$ make
$ make install
(後述のようにユーザディレクトリ下にPerl環境を置いている場合は、sudoをつけないほうが良さそうです。
もちろん、システムでPerl環境を共有している場合には、sudoをつけてmake installしてください。)

これで準備完了です。

あとは... ソースコードを書くだけです。
use Wx;

my $app = Wx::SimpleApp->new;
my $frame = Wx::Frame->new( undef, -1, 'Hello, world!' );

$frame->Show;
$app->MainLoop;

(http://search.cpan.org/~mdootson/Wx/Wx.pm より引用)

これを適当に保存して、実行してみましょう。
$ perl hoge.pl

こんなウィンドウが表示されたら成功です(>ω<)♪



この時、もしも...次のようなエラーが表示されたら...
Can't load '/***/Wx/Wx.so' for module Wx: libwx_gtk2u_adv-2.9.so.4: 共有オブジェクトファイルを開けません: そのようなファイルやディレクトリはありません at /***/DynaLoader.pm ***.
この場合はライブラリが認識されていません。

どうやらperlの環境によっては、ライブラリファイルがユーザディレクトリ内にインストールされてしまい、その結果として認識されないことがあるようです。
(Alien::WxWidgetsのビルド時にBuild.PL --prefix=***を指定しても効きませんでした・・・
調査中です。どなたか正しい方法をご存知でしたらアドバイスをお願いいたします m(_ _)m
Perlbrewの環境とかもそうなったりするんでしょうか・・・未確認です。)


(あんまり良い方法では無い気がしますが...)とりあえず対策として
ライブラリパスをユーザの環境変数に追加しておきます。

まずは目的のライブラリファイルを探します...
$ sudo find / -name "libwx_gtk2u_adv-2.9.so.4"

ファイルは見つかりましたか?
(例: /home/hoge/perl5/lib/perl5/x86_64-linux-thread-multi/Alien/wxWidgets/gtk_2_9_4_uni/lib/libwx_gtk2u_adv-2.9.so.4 )

見つかったファイルのあるディレクトリを登録します:
$ export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:***/Alien/wxWidgets/gtk_2_9_4_uni/lib/ (上の例であれば...ディレクトリは、/home/hoge/perl5/lib/perl5/x86_64-linux-thread-multi/Alien/wxWidgets/gtk_2_9_4_uni/lib/)

さらに、同じexport文を ~/.bashrc の末尾にも追加しておきます:
$ vi ~/.bashrc

export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:***/Alien/wxWidgets/gtk_2_9_4_uni/lib/

その後、もう一度、sample.plを実行してみてください。今度は動くはずです(汗;)
$ perl sample.pl


さて...今回はこのへんで。
大学のテストが間近なのでテスト勉強してきますっ(`・ω・´)シャキーン (汗;) (

デモアプリケーションがCPANでWx::Demoとして公開されているので
そちらを参考にしつつ使わせてもらいましょう(>ω<)♪


[2013/06/23 追記]
Arch Linux(64bit), perl-5.18.0の環境で試してみたところ...
$ cpan Alien::wxWidgets Wx
とCPANシェルでインストールするだけで、wxPerl環境の構築が楽にできました。
上記のサンプルコードもそのまま動作しました。何か作ってみようかな♪

また、直接関係ありませんが、wxWidgetsのドキュメント日本語訳プロジェクトが新たに始動されていました。
日本でもwx関連がまた活発になっていくといいですね。


[余談]

この記事を突然書くことにしたのには経緯があったりします。
実は以前から私はWxWidgetsとWxモジュール(WxPerl)をかじっていた時期がありました。
ただ、2010年になってからしばらく...モジュールのアップデートが特になくなり...。
私も、Web開発のほうに興味が傾いていた事もあって、GUIアプリ開発そのものが少なくなり、
その後はたまにWxPerlのウェブサイトをのぞいたり...といった程度になっていました・・・。

そんななかで先日、2012年になって再びアップデートが積極的に行われていることを知りました。
何より嬉しくなったのと、最近流行り(?)のWebアプリケーションでなく、
Linuxでも使えるスタンドアロンなGUIアプリケーションを作りたいな〜と考えていたことから
ちょっと記事に起こしてみることにしましたw

おっとww 余談が長くなってすみませんでした(^^;)ゞ

2012/10/07

[構想] 大学のA3プリント類を便利にスキャンするために

大学の夏休みもあけ、もうそろそろ稲刈りの時期ですね。
・・・というわけで(?)、大学のプリント類も少々溜まって来ました。
ScanSnapで整理しないとw と思っている今日このごろのMasanoriです。

以前から、ScanSnap S510を(旧)自宅サーバPCに接続しておいて、
プリント類をスキャンしてはGoogle Drive(Google Docs)に自動アップロード
...ということは行なっていました。家族共有もできますし、なかなか便利です。

ところで...。
うちの大学のプリントは、A3サイズで両面印刷が多いのです。

ScanSnapでは、
A4サイズの場合は、自動給紙で両面&複数枚を取り込めます。便利です。

しかし、A3サイズの場合は、2つ折りにして(物理的にA4サイズにして)、
”A3キャリアシート”というシートで挟み込んでからスキャンしなければなりません。
つまり、両面取り込むには、A3キャリアシートから一旦取り出して、裏返して、2つ折にして、再度挟み込んでからスキャンしなければなりません。

まあそれは、そもそも物理的にそういう仕様ですから仕方ないですね(^^;)ゞ

で・・・続きなんですが。
A4サイズの場合は、連続給紙した分をすべて1つのPDFファイルに仕上げてくれます。
しかし、A3キャリアシートを使っている場合はそうはいかず、別ファイルになってしまいます。
(※ScanSnapの付属ソフトウェアにある"継続読み取り機能"を使えば、解決できます。)
なので、私は、必要に応じて、できあがったPDFファイルをサーバPCから取ってきて、
手元のPCで、PDFを結合するなど処理を加えて、再度保存...ということをやっていますww

付属ソフトウェアにある"継続読み取り機能"を使えば実現できるんですけど、いちいち指定するのめんどくさい!
というか、サーバPCに接続しているんで、ディスプレイレスなんですww

私としては、本体のスキャンボタンを押すだけで、PCに触れることなく一連の操作を終わらせたい...という願望(?)がありますw

というわけで前置きが長くなりましたが、やりたいこと:
  • ScanSnap本体のスキャンボタンを押すだけで自動的にスキャンして、
    OCR処理をして、Google Driveに自動アップロード。
  • ScanSnapを接続するPCは、一切操作しなくていい。
  • ScanSnapを接続するPCは、Windowsじゃなく、Linux
  • A3キャリアシートを使っている場合も、一定時間内に複数枚スキャンすれば、
    それらを一つのPDFファイルにまとめてくれる。
以上です。Perlでごりごりやろうかな。

p.s.

このブログのデザインを変更しました。
...といっても背景画像は、about.meや他のサイトでも使っているものなんですが。
Androidファンなのでw ドロイドくんを使わせていただいています(><)♪

2012/09/12

Gitlab 2.7 → 2.8にバージョンアップ

友人との開発プロジェクトにGitLabを実際に利用させていただいています。
GitHubに使い勝手が近いこと、また、RedmineやTracほど大規模でないため
とても手軽で、メンバーの学習コスト的にも敷居が低く、最適だと思っています。
(前回の記事: Gitlabの導入 (Unicorn+nginxでサブディレクトリへ配置))

さて今回は、8月末にGitLab 2.8が公開されたため、
現在のGitLab 2.7からバージョンアップをすることとしました。

GITLAB 2.8 released - GITLAB Blog

Gitlab Flavored Markdownなどなど...便利になりますね。
(プレビュー機能が使えて、その場で確認もできるようになりました。)
また、詳細まで追ってはいませんが、Security fixもあるそうですから
アップデートしておいたほうが良いと思います。

アップデート手順のドキュメントが公開されており、基本的にはこのとおりです。
https://github.com/gitlabhq/gitlabhq/wiki/From-2.7-to-2.8
(推奨OSではなく、CentOS 6.2上で動作させていますが、特にこのとおりで問題ありません。))

GitLabのディレクトリでGitを使ってgit pullしてきて、
bundleコマンドをいくらか実行するだけなので、楽ちんですね♪



以下は、どちらかといえば私のサーバ環境固有の問題なのですが... (一応メモですw)

1. Gitoliteのユーザアカウントに対してホームフォルダを作っていないためそのままでは動作しませんでした(詳しくは前回の記事を参照)
→ egrepコマンドで"/home/git/"ディレクトリのパスが決め打ちされている箇所を探して書き換えることで対処できました。

2. nginx+Unicornでサブディレクトリ下でGitlabを動作させるため
コードをほんの一部書き換えているのですが、git pullする際に
マージするか、一旦上書きしてしまって再設定する必要がありました。


3. Gitlab2.8以降のGitlab Markdownによってリンクタグ生成処理が変更されており、
Markdown記述内のリンクには、サブディレクトリが含まれませんでした。
(<a href="http://example.com/gitlab/hoge/issues/1">〜〜</a> になってほしいところが<a href="http://example.com/hoge/issues/1">〜〜</a> になるという。)

→こちらは追加の変更で対処できました: (下線の箇所にサブディレクトリパスを記述)

/lib/gitlab/markdown.rb: 147行:
link_to("##{identifier}", 'gitlab/'+ project_issue_path(@project, issue), html_options.merge(title: "Issue: #{issue.title}", class: "gfm gfm-issue #{html_options[:class]}")) 
同じ感じで...153行、159行、165行目にもパスを追加していきます。

以上です。

GitLabのサブディレクトリの件、もし不具合なのであれば、
GitHubで報告したいのですが、以前からサブディレクトリ対応については
ドキュメントでも触れられていませんし・・・仕様なのかなと。
もし宜しければ、どなたかお願いしますm(_ _)m

2012/08/10

Travis CIでPerl(Mojolicious)アプリケーションを自動テスト


Perl+Mojoliciousで作成しているWebアプリケーションがあるのですが、
折角、GitHub上でオープンソースとしてリポジトリを公開しているのだから
Travis CI自動テスト(継続的インテグレーション)をしてもらわない手はないっ!
...ということでテストしてもらうことにしました。

この記事はMojolicious(Test::Mojo)でテストスクリプトを作成していること前提です。

まずは、http://travis-ci.org/ からGitHubアカウントの認証を行います。

認証できたら、Travis CIのプロフィールページへアクセスして
[Token]の文字列を確認しておきます。


次に、GitHubへアクセスして・・・
テスト対象とするリポジトリの[Admin]ページから、[ServiceHook]ページを表示。


AVAILABLE SERVICE HOOKSのリストから、[Travis]を選択します。

すると入力フォームが表示されるので、Token欄にさきほどのTokenを入力して
[Active]にチェックを入れたら、[Update Settings]ボタンをクリック。
さらに、[TestHook]ボタンをクリックします。





次に、Travis CIのプロフィールページへ再度アクセスし
[Repos]タブをクリックすると、自分のリポジトリ一覧が表示されるので、
テスト対象とするリポジトリ名の横にあるスイッチを[ON]にしておきます。



次に、Gitリポジトリのルートへ、".travis.yml"というファイルを作成します。
こんな感じでテストのための環境を定義しておきます。
$ vi .travis.yml 
language: perl
perl:
  - "5.16"
  - "5.14"
install:
    - cpanm --installdeps --notest .
script: "perl Makefile.PL && make test"
(2013/08/18 更新、2014/04/22 更新: mirrorの指定が不要になっていました。)

  • perl項目: テストしたいperlのバージョン
  • install項目: テスト & インストールのためのコマンド
    ここでは必要なモジュールをcpanmでインストールするよう指定しています。
    (さらに詳しいログが必要ならば、 cpanm -v 〜 のようにオプションを付ける。)

詳しくは、http://about.travis-ci.org/docs/user/languages/perl/ 参照のこと。

さらに、MojoのコマンドでMakefile.PLを作ります。
$ mojo generate makefile
Makefile.PLが作成されているので
これをテキストエディタで開き、必要に応じて修正を行います。

具体的には、テストの前にインストールが必要ないわゆる依存モジュールを
PREREQ_PMに定義しておきます。
$ vi Makefile.PL 
use strict;
use warnings;
use ExtUtils::MakeMaker;

WriteMakefile(
  VERSION   => '0.01',
  test      => {TESTS => 't/*.t'},
  PREREQ_PM => {
  'Mojolicious' => '3.20',
   'Validator::Custom' => 0,
   'Config::Pit'   => 0,
   'DateTime'    => 0,
   'JSON'     => 0,
   'String::Trigram'  => 0,
   'Data::Model'   => 0
  }
);

今回のアプリケーションの場合、このようになりました。

最後に、GitHubへプッシュ。
$ git push
これでしばらくすると...

Travis CIのトップ画面の一覧に自分のプロジェクトが表示されますww (おぉ〜!)


また、自分のプロジェクトのテスト結果ページができています。
http://travis-ci.org/#!/mugifly/Fsq2mixi



ここで緑色で表示されていれば、無事テストをパスしたことになります。
赤なら...詳細を見てエラーの原因を調べましょう...ということのようです。

後はプッシュするたびに自動テストを行なってもらえるようです。

さてさて...テストの中身をもっときちんと書かねば(^^;)ゞ
(実は今回お題にあげたプロジェクトはテストを思いっきりサボ(げふんげふん)




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

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/08/05

Ubuntu&Fedoraをマルチブートにして新規インストールしちゃおう


大学が夏休みに入って、さあ開発だ!と張り切っているMasanoriですw

大学の都合で、Ubuntu 10.10の環境のままになっていたPCがあるのですが、
これをそろそろ、アップグレードでなく新しくフルインストールしてしまって
新しいLinuxに入れ替えたいな...ということで、やってみることとしました。

この記事も例によって自分用メモです。
順をおって、ただしい知識を得たい方には特に申し訳ありません・・・
ページ下部の参考ページをあたってください。すみません。

また...<結論から言うと、今回インストールしたのはFedoraだけです>

現状のパーティション構成はこんな感じです:
  • /dev/sda (500GB)
    • [基本]NTFS (13GB) - Recovery
    • [基本]NTFS (315MB) - System
    • [基本]NTFS (210GB) - Windows7 システムパーティション
      • マウント: /win
    • [拡張] (60GB)
      • [拡張]ext4 (50GB) - Ubuntu ルートパーティション
        • マウント: /
      • [拡張]swap (10GB) - Ubuntu スワップパーティション
    • 未割当 (217GB)
もともと、Windows7とUbuntuのデュアルブートになっています。
ブートローダはGRUBで、1段階ブートです。

新しい構成としては次のような感じにします:
  • /dev/sda (500GB)
    • [基本]NTFS (13GB)  - Recovery
    • [基本]NTFS (315MB)  - System
    • [基本]NTFS (210GB)  - Windows7 システムパーティション
    • [拡張] (256GB)
      • [拡張]ext4 (50GB) - Ubuntu(旧) ルートパーティション
      • [拡張]swap (16GB) - スワップパーティション
      • [拡張]ext4 (20GB) - Ubuntu ルートパーティション
      • [拡張]ext4 (70GB) - Ubuntu /homeパーティション
      • [拡張]ext4 (20GB) - Fedora ルートパーティション
      • [拡張]ext4 (70GB) - Fedora /homeパーティション
      • 未割当 (15GB)
今回は、PBRのブートローダにMBRを使い、2段階ブートとし、
Windows、UbuntuとFedora、旧Ubuntuを選択できるようにしたいと思います。

まずは、念の為にバックアップ。何でも構いません。

私は...mondo rescueを使って...と思っていましたが、バージョンの互換性の問題のために色々とエラーが発生したので、
試行錯誤をしてみてもよかったのですが、面倒くさかったですし(おい)
今回は、Fedora 17のLiveCDでブートし、標準のディスク管理機能でイメージバックアップを取りました。

次に、パーティション構成を変更しておきます。

LiveCD上で、GPartedを用いてパーティション構成も変更します。
後からOSをインストールする際にパーティションを作成するのではなく、
あらかじめ、パーティションをリサイズし切り分けておくことにしました。
(切り分ける構成は、先述のとおりです。GPartedの使い方については、ググってくださいw)

ここで、スワップもLinuxで共通にしておきたいと思います。

既に、Ubuntuのためのスワップパーティションがあるので、これを使います。
メインメモリの容量が8GBですから、スワップの容量も余裕をもって、16GBに変更しました。
 (スワップ容量についてはここ参照)




次に、1段階から2段階ブートにするために ブートローダをMBMに変更します。
詳しい手順は、http://d.hatena.ne.jp/den8/20100605/1275709966 などを
参考に勉強させていただきましょう。先にじっくり読んでおくことを推奨します


まずは、"MBMをインストールするためのUSBメモリ"を作ります。
適当なUSBメモリ(容量は28MBより大きければ良い)を用意してください。

MBMインストールの機能が含まれた
Minimum Ubuntuという超軽量なレスキュー用Ubuntu環境を利用することにします。
バイナリが用意されているので、使わせていただきましょう。
http://winmac.blog33.fc2.com/blog-entry-119.html

ということなので、そのバイナリをダウンロード。
usb-minimumubuntu-include(dmraid)-0.9.013(100620)-10.04.img
28MBのファイルです。素晴らしい。

次に、mount -l でUSBメモリのデバイス名を調べます。


さらに、DDコマンドで、そのデバイス名を指定してイメージを焼きます。
$ dd if="usb-minimumubuntu-include(dmraid)-0.9.013(100620)-10.04.img" of=/dev/sdb

これでMBMをインストールするためのUSBメモリが作成できました。
おかげさまで...簡単ですね。ありがたいです(´;ω;`)

次に、現在のUbuntu環境のGRUBのエントリポイントを変更しておきます。(その際、”Ubuntu環境でルートにマウントされているパーティション”を指定します。)

$ sudo grub-setup  -f  /dev/sda5 
grub-setup: warn: Attempting to install GRUB to a partition instead of the MBR.  This is a BAD idea..
grub-setup: warn: Embedding is not possible.  GRUB can only be installed in this setup by using blocklists.  However, blocklists are UNRELIABLE and their use is discouraged..
warningが出ますが、気にしない。

さらに本来であれば、Debconfデータベースの更新をしておかなければいけないのですが
今回、現在のUbuntu環境はもはや残しておくだけでアップデートもしないので、
私はとりあえず飛ばしておきます。(皆さんは、ちゃんとやってくださいw(汗;)
http://wikiwiki.jp/disklessfun/?grub2_and_grub1#x3f37a52)


あとは、PCを再起動してUSBメモリからブートします。
ブートしたらコンソールが表示されますので、MBMのインストールを実行します。
(その際、インストール先となるHDDのデバイスを指定します。)

$ sudo install-mbm /dev/sdb

MBMのインストールが終わり...次はFedoraのインストールです。

正しく2段階ブートにするために、
インストールの際、パーティション設定は手動設定にして

  • ルートパーティションの指定
  • /homeパーティションの指定
  • swapパーティションの指定
  • ブートローダーのインストール先の指定
    (同じルートパーティションを指定。)
を行っておきます。

以上で、2段階ブートでのインストールは終了です♪




Fedoraのインストールが終わったら・・・

とりあえず、日本語設定にしておきます。
その後、一旦ログアウト&ログインして、
Firefoxを起動して、ちょろめをインストールしてww

visudoコマンドでsudoersを設定しておきます。
$ su
# visudo
root    ALL=(ALL)       ALL
hoge        ALL=(ALL)       ALL

みたいな感じで。(※リスクは理解した上で行ってください)

さらに、このPCはLet's noteなのですが
Let's noteのあのトラックパッドの回転スクロールを有効にするために...
gsynapticsをyumでインストールしておきます。
$ sudo yum install gsynaptics
Fedora17標準でも回転スクロールはサポートしていますが、
これを導入して有効にしたほうがさらに快適なスクロールができます。



さらにSDカードスロットのドライバも入れておきます。
lspciした結果によると・・・

$ lspci
~~~
14:00.1 SD Host controller: Realtek Semiconductor Co., Ltd. Device 5209 (rev 01)


ということでPCIE RTS5209 card reader driver for Linuxをダウンロード。
http://www.realtek.com.tw/downloads/downloadsView.aspx?Langid=4&PNid=15&PFid=25&Level=4&Conn=3&DownTypeID=3&GetDown=false#2

アーカイブファイルを展開してmakeしインストール。
$ tar vxf rts_pstor.tar.bz2
$ cd rts_pstor/
$ make
$ sudo make install
$ sudo depmod
さらに再起動をさせればSDカードを認識できるようになります。

次にIMEですが、私はMozcを使っているので
これは"ソフトウェアの追加と削除"から入れておきます。

次に開発環境。とりあえずAptanaを入れておきます。
http://www.aptana.com/products/studio3/download

Aptanaはパッケージになっていないため、自動的にアプリケーション一覧には登録されません。
ですから手動でショートカットをアプリケーション一覧に登録します。
まず、デフォルトでメニューエディタがインストールされていないようなので、
"ソフトウェアの追加と削除"で"alacarte"をインストール。
"メインメニュー"という項目がアプリケーション一覧に表示されるので、
そこでAptanaを自分で追加します。
あとは一旦ログアウトしてログインしなおすと、反映されます。

DartEditorとか、ベースとなっているEclipseも同様に。

最後に...Gnomeをカスタマイズしておきましょうw
今時は、https://extensions.gnome.org/ でExtentionをどんどん試せるんですね。
Web上で設定ができて面白いですね。実際にいくつか試して入れてみました。

ということで少し長くなりましたが・・・


これで以上です♪
(おっと!新しいUbuntuをまだインストールしていない件w←)



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

2012/07/20

naveとnpmでNode.js環境を構築

naveというツールを使うと、Node.js(Node)を簡単にインストールできるそうです。
やってみました。
例によって以下は自分用メモです。必要なものは予めインストール済みということで書いています。)


【お知らせ】ソースコードからビルドしてインストールした記事もあります:
 node.jsをソースからビルドしてインストール(簡単)

まずはnaveを適当なディレクトリにGit cloneしてきます。
$ mkdir ~/opt
$ git clone git://github.com/isaacs/nave.git 
次にnaveを使い、Nodeの最新版ファイルを取得します。
$ cd nave/
$ ./nave.sh install latest
このままではNodeへのパスが通っていなくて使えないので
以下のようなコマンドを実行すると一時的に通すことができます。
(latestと指定しているので最新版のNodeを利用できます。便利ですね。)
$ ~/opt/nave/nave.sh use latest
Already installed: 0.8.3
using 0.8.3
(※毎回実行させるには、.bashrcに登録するなどしておく。)

うーん...これはたしかに簡単!

つづいて、Nodeのためのパッケージマネージャ「npm」をインストールします。
$ curl https://npmjs.org/install.sh | sh
〜〜〜
It worked

できあがりです。


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






2012/06/24

Git+Gitoliteを使い始める

実は今までまともにGitを使ったことが無い(git cloneくらいしかないw)ので
この機会に実際にGitを使い初めて学んでみることにしました。
慣れてきたらSVNから徐々に移行していきたいつもりです。

尚、この記事は私のメモが目的であり、
申し訳ありませんがあまり役に立たないかもしれません。ご了承ください(汗;)
参考になる情報をお探しの方は、この記事の最後にある参考ページを。

さて、まずは...手始めにサーバ上でGitをインストールします。
server: $ sudo yum install git
さらに、リポジトリとユーザ管理を容易にしてくれる gitoliteをインストール。
server: $ sudo yum install gitolite
このとき、インストールと同時に、gitoliteというユーザがサーバ上に追加されます。

さて..gitoliteはユーザを認証鍵で識別するため、そのための鍵を作る必要があります。
(参照:この仕組みについては、gitoliteはどうやってユーザを判別しているか - SELECT * FROM life;が参考になりました。)
ですので、クライアントとなるPCで・・・
まず、gitolite用にいつもとは別の鍵を作成します。
client: $ ssh-keygen -t rsa 
Generating public/private rsa key pair.
Enter file in which to save the key (/home/hoge/.ssh/id_rsa): ~/.ssh/gitoliteEnter passphrase (empty for no passphrase): #空でEnter
Enter same passphrase again: #空でEnter
Your identification has been saved in /home/hoge/.ssh/gitolite.
Your public key has been saved in /home/hoge/.ssh/gitolite.pub.
The key fingerprint is:
〜〜〜〜
The key's randomart image is:
〜〜〜〜
これで、"gitolite"と"gitolite.pub"というファイルが、~/.ssh/下に生成されます。

さらにこの鍵を使うために、~/.ssh/configへ記述をしておきます。
client: $ vi ~/.ssh/config 
HOST git.example        USER            gitolite
        HOSTNAME        example.com        PORT            22        IDENTITYFILE    ~/.ssh/gitolite
こんな感じで。git.exampleは識別名なので何でも構いません。(あとで利用)
HOSTNAMEとPORTは、それぞれサーバのアドレスとSSHポート番号を指定します。

あとは、gitolite.pubをサーバの/tmp/あたりに転送します。(SCPか何かで適当に。)
client: $ scp ~/.ssh/gitolite.pub hoge@example.com:/tmp/gitolite.pub
今度はサーバ側で、アップロードしたファイルのパーミッションを変更。
server: # chmod a+r /tmp/gitolite.pub
さらに、gitoliteとしてログインしなおし...gitoliteの設定を行ないます。
server: $ su - gitolite 
server: $ gl-setup /tmp/gitolite.pub
The default settings in the rc file (/var/lib/gitolite/.gitolite.rc) are fine for most
people but if you wish to make any changes, you can do so now.
hit enter... #Enterキーで続行。#続けて.gitolite.rcがエディタで開きますが、気にせずそのまま閉じます。creating gitolite-admin...
Initialized empty Git repository in /var/lib/gitolite/repositories/gitolite-admin.git/
creating testing...
Initialized empty Git repository in /var/lib/gitolite/repositories/testing.git/
[master (root-commit) 〜] gl-setup /tmp/gitolite.pub 2 files changed, 8 insertions(+), 0 deletions(-)
 create mode 100644 conf/gitolite.conf
 create mode 100644 keydir/gitolite.pub 
server : $ exit
このとき、サーバ上に、"testing"というサンプルのリポジトリと、
"gitolite-admin"というリポジトリが自動生成されます。

このgitolite-admin リポジトリは、Gitolite管理用リポジトリとなります。
なぜかというと・・・・ここに対して設定ファイルをコミットしていくことで
Gitoliteの設定変更(Gitリポジトリの生成といった管理操作も!)ができるという仕組みなのです。面白いですね!!

さて今度はクライアント側から、この"gitolite-admin"リポジトリをgit cloneしてみます。
適当なディレクトリへcloneします。これでcloneされたローカルリポジトリが生成されるわけですね。
(アドレスは実際のサーバアドレスは指定しません。
git.exampleとしているように、先程設定した識別名を指定します。)
client: $ cd ~
client: $ git clone ssh://git.example/gitolite-admin
git cloneが成功しました。
試しに新しいリポジトリでも作ってみます...(ここではrepo1というリポジトリを作ってみる。)
cloneされたディレクトリ下にある conf/gitlite.conf をエディタで開き、記述を追加します。
client: $ cd gitolite-admin/
client: $ vi conf/gitolite.conf  
repo    gitolite-admin
        RW+     =   gitolite
repo    testing
        RW+     =   @all
#以下...追加
repo    repo1
        RW+     =   @all
そして...ローカルリポジトリへのコミット
client: $ git add .
client: $ git commit 
エディタが起動して、コミットログを編集する画面になるので、以下のように先頭の#を削除して終了。
# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
 On branch master
 Changes to be committed:
   (use "git reset HEAD <file>..." to unstage)
        modified:   conf/gitolite.conf 
ローカルリポジトリへのコミットが実行されます。 
[master 21e408a]  On branch master  Changes to be committed:    (use "git reset HEAD <file>..." to unstage)
 1 files changed, 2 insertions(+), 0 deletions(-)
最後にローカルリポジトリをサーバへプッシュします。
client: $ git push
サーバ側で作業することなくこれだけでリポジトリが追加されます。
なんだこれは便利www

あとは他のユーザをgitoliteに追加するとか、
RedmineにGitリポジトリを設定するとかあるのですが、それはまた (^^)/♪



参考にさせていただいたサイト(感謝♪!):

2012/05/02

Linux(Ubuntu)でPasoriを使う (ICOCA残高を読み取る)

以前はWindowsでPasoriを利用して、ICOCAの残高などを見ていましたが、
Linux (Ubuntu)でも、Pasoriを使うことができたら便利なんだけどなー・・・と思ったら、
libusbや、GSuica、libpafe (lib-pasori)、libpafe-ruby...によって実現出来るんですね
ありがたいです...m(_ _)m ということで早速やってみます。

いつも通りですが、記載内容は無保証、自己責任ですのでご了承を。

今回は既にRuby 1.8.7がインストール済みということで。
(↑...これ新しくしたほうが良いかもしれませんね...(汗;))

まず...libusbをapt-getでインストール。
$ sudo apt-get install libusb-dev

次に、libpafeをdebパッケージからインストール。Pasoriを扱う為のライブラリです。
最新は、libpafe-0.0.7です。(2009/10だそうです...。)
http://homepage3.nifty.com/slokar/pasori/libpafe.html
$ mkdir ~/tmp
$ cd ~/tmp
$ wget http://homepage3.nifty.com/slokar/pasori/libpafe_0.0.7-1_i386.deb
$ sudo dpkg -i libpafe_0.0.7-1_i386.deb


次に、libpafe-rubyをインストール。Rubyからlibpafeを扱う為のライブラリです。
こちらも最新は、lib-pafe-ruby-0.0.7。
http://homepage3.nifty.com/slokar/pasori/libpafe-ruby.html
$ cd ~/tmp
$ wget http://homepage3.nifty.com/slokar/pasori/libpafe-ruby-0.0.7.tar.gz
$ tar zxf libpafe-ruby-0.0.7.tar.gz
$ cd libpafe-ruby-0.0.7/
$ ruby extconf.rb
$ make
$ sudo make install

最後に、Suicaなどの残高表示をしてくれる GSuicaをインストール...といっても、
Rubyスクリプトになっていますので保存するのみでOKですね。
http://homepage3.nifty.com/slokar/pasori/gsuica.html
(ちなみに、GSuica、libpafe、libpafe-rubyともに作者は、H.Ito.さんだそうです。感謝♪)
$ cd ~/tmp
$ wget http://homepage3.nifty.com/slokar/pasori/gsuica
$ vi ./gsuica 
#! /usr/bin/ruby1.9.3 
〜〜〜〜 
$ sudo mv ./gsuica /usr/local/bin/
$ chmod a+x /usr/local/bin/gsuica
Gsuicaのスクリプトファイルを開き、
1行目のRubyインタプリタがバージョンごと指定されているので、これを書き換えます。
そして、/usr/local/binへ保存。実行権限を与えておきます。

あとは・・・実行するだけ。
$ sudo gsuica

おお・・・。

そして・・・Pasori(RC-S320)を接続して、
手持ちのICOCAカードをPasoriにのせ、[読取]ボタンを押すと...

おお〜!!問題なく動作してくれました。

駅名が不明になっていますが、
そこは、GSuicaのページに記載された方法に従えば、表示させることができそうです。
http://homepage3.nifty.com/slokar/pasori/gsuica.html





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
こんな感じです。

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