Debianで作るプロジェクト管理環境
プロジェクト管理環境の構築とサーバOS
「第1回：そもそもサーバOSとは何か（http://www.thinkit.co.jp/article/80/1/）」ではサーバOSのおおまかな分類と特徴を、そして「第2回：OS選定のポイントを整理する（http://www.thinkit.co.jp/article/80/2/）」では当社を例にとりサーバOSの選び方を紹介した。ここまでを理論編とすると、ここからは実践編として、実際の構築に加え、「なぜそのサーバOSなのか？」「そのサーバOSの採用にどんな付加価値があるのか？」といった舞台裏も紹介していく。
さて、タイトルにもあるように、今回はサーバOSとしてDebian GNU/Linux（以下Debian）を取り上げる。Debianを採用する理由を説明する前に、まずは「プロジェクト管理環境」について簡単に説明しておこう。
プロジェクト管理とは、プロジェクト（＝案件）を達成するために必要な課題それぞれにおいて、解決順序、期限設定、リソースの割り当て、進行度合い、関連ドキュメントといったものを管理することを指す。簡単に言えば「進ちょくとドキュメントの管理」である。
プロジェクトと言うと大きな話のように思えるかもしれないが、実はプロジェクトと呼べる仕事は至る所に存在する。例えば、身近なプロジェクトの例として「複数人で行く旅行」を考えてみよう。この場合は、あらかじめ幹事が行く場所と内容を設定し、予算金額や人数を決め、交通機関や旅館の手配、もしくは旅行代理店との調整を行い、「旅のしおり」としてまとめた事前計画書を参加者に配布する。旅行中も、必要に応じて、幹事が計画を随時書き換えて参加者に伝え、旅行が無事終わるようにナビゲートする。
この場合、幹事はプロジェクトマネージャであり、参加者はプロジェクトメンバー、旅のしおりはドキュメントにあたる。そして、プロジェクトの達成のために管理者が必要な課題を整理し、参加者をナビゲートするというプロセスは、われわれが仕事でかかわるさまざまなプロジェクトとなんら変わらないものである。
さて、小規模の旅行なら幹事1人で管理できるが、もっと大規模だと、旅のしおりの配布だけでも一苦労だ。参加者に旅館や交通機関の手配を依頼することもあるかもしれない。そうなると幹事は、依頼した課題の進行状況＝進ちょくを把握する必要があるし、旅のしおりの事前配布を簡単に済ます方法も考えなければならない。このようなときに使用するのが、冒頭で述べた「プロジェクト管理環境」だ。
アプリとハードの条件からDebianを選定
ここまで、少々サーバOSとは直接関係のない話題が続いているが、「第2回：OS選定のポイントを整理する（http://www.thinkit.co.jp/article/80/2/）」でも説明したように、まずアプリケーションとハードウェアが決定しないと、サーバOSまで話が進まないので、しばらくご辛抱願いたい。
プロジェクト管理環境とは、その名の通り、プロジェクト管理のさまざまなフェーズを効率よく行うため、アプリケーションやハードウェアを用いて実現される管理環境のことである。プロジェクト管理自体は直接利益を生むものではないため、導入・運用費用は極力安く済ませたい。また、プロジェクトにまつわる情報をすばやくまとめなければ管理は不可能であるため、プロジェクト管理環境の導入はすばやく済ませなければいけない。
この命題に合致するものを見つけるべく、検索エンジンで「プロジェクト管理」と検索すると、非常に多くのプロダクトがあることに驚かされるが、今回は、Think ITでもすでに紹介されているTrac（トラック）（http://www.thinkit.co.jp/free/article/0708/5/1/）を取り上げる。
TracはオープンソースのBTS（Bug Tracking System、バグ追跡システム）であり、プロジェクト管理用に設計されたわけではないが、バグフィックス（＝課題）を担当者に割り当て、進ちょくを管理するという本質的な部分が、プロジェクト管理環境として十二分に活用可能である。Tracの導入は非常にシンプルだし、コストいらずの無償ソフトウェアであることも大きな魅力だ。
こうしてプロジェクト管理のためのアプリケーションが決まったら、次はハードウェアを決めたいところだが、用意できるハードウェアは環境によりまちまちである。よって、「ハードウェアは場合により異なる」ものとし、その次の段階、つまりTracを動かすサーバOSを決めることにしよう。
と、ようやくサーバOSの話題となったが、今回動かすTracはオープンソースソフトウェアであるため、第2回で紹介した「マトリックス図（http://www.thinkit.co.jp/article/80/2/2.html）」によると、Linux系サーバOSかBSD系サーバOSに絞られる。ただ、先ほどの条件から、できるだけ多くのハードウェアプラットフォームに対応するものが必要だ。そうなると、Linux系サーバOSならばDebian、BSD系サーバOSならばNetBSD、OpenBSDが候補に挙がる。
今回はプロプライエタリソフトウェアの利用予定はないため、Linux系、BSD系どちらでもかまわない。あとは、第2回で紹介したの「3つの基準（http://www.thinkit.co.jp/article/80/2/2.html）」に照らし合わせるだけだ。
どのOSも「5年以上の開発」や「2：8」の条件は満たしていたが、筆者が最も「慣れている」OSであるDebianを、サーバOSとして選択することにした。
これで、アプリケーション＝Trac、ハードウェア＝場合により異なる、サーバOS＝Debianと決まった。
Debianを最小構成でインストール
それぞれ決まったところで、実際のサーバ構築に話題を移そう。
本連載では、x86アーキテクチャのサーバを信頼できるネットワーク環境に配置でき、かつHTTPもしくはFTPにてDebianのリポジトリにアクセスできる環境があると仮定して、サーバとしてDebianをインストールするときのポイントを紹介する。また、ハードウェアが用意できずとも、既存の環境に「間借り」することも可能であるため、その方法についても後述する。
なお、Debianインストールの詳しい手順は、Debianの公式サイトに記載されているマニュアルを見ていただいたほうが良い。ここでは、サーバとして構成するときのポイントを紹介する。
まず、インストールに使用するCDイメージは、netinstイメージを利用するのが良いだろう。
Debianにはそのほかのイメージとしてbusinesscardイメージや、ネットワークからのダウンロードが不要な全セットのCD/DVDイメージが用意されているが、いずれもサーバOSとしてインストールする場合はおすすめできない。これは、インストールに必要なファイルやアプリケーションをダウンロードにて取得するため時間がかかったり、大量のパッケージがインストールされていると、サーバOSとしては不要なパッケージの削除作業を行う必要があったりするからである。
netinstイメージで起動するとCUIのダイアログが表示される。最近の多くのLinuxディストリビューションはインストール時にGUIを採用していることが多いため、ちょっと面食らってしまうかもしれないが、十字キーとTABキー、そしてエンターキーで十分操作可能だ。
また、CUIであるがゆえに、ハードウェアによってはインストール時からシリアルコンソールが利用可能である。これは、モデムなどを経由してリモートインストールも可能であることを意味し、ハードウェアをデータセンターに配置している場合は、現地オペレータにCD-ROMをセットしてもらい電源ONしてもらうだけでインストール作業を開始できる。これはサーバ向けの特徴と言えよう。
そのほか、インストール時のポイントとしては「ソフトウェアの選択」で、何も指定しないことだろう。こうすることで、最小限のシステムを構築することができる。
以上、ここまでの作業は、ダウンロードの時間にもよるが、手慣れていれば30分前後、慣れていなくとも1時間でインストール可能だ。
インストール後の初期設定
インストール直後のプロセスを見ると、不要なサービスは一切動いておらず、サーバOSの初期状態としては非常に理想的な環境だ。しかし何も入っていないがゆえに、何も行うことができない。まずは、sshによるリモートログイン環境を整えて、Tracの環境構築に備えることにする。
その前に、OS自体のアップグレード確認作業を忘れてはならない。インストール直後のOSに対し、すでにセキュリティパッチが出ている可能性があるからだ。DebianはAPTによって新しいアプリケーションのインストールから、インストール済みアプリケーションのアップグレードまでの作業を簡単にできる。
# aptitude update
# aptitude upgrade
筆者の環境では、kernel（linux-imageパッケージ）のアップグレードが発生した。aptitude upgrade後に再起動し、最新のkernelで稼働するようにした。
なおroot権限が必要な作業はsudoを利用するのが常とう手段ではあるが、今回はコマンドラインを簡素化するため、すべてrootユーザで作業を行っている。
さて、次はリモートログイン環境である。インストール直後の状態では、常にサーバの前で作業をしなければならないため、sshによるリモートログインが可能なように構成する。これもAPTで簡単に構成可能だ。
# aptitude install openssh-server
これでsshによるリモートログインが可能になった。ただし、この時点ではrootユーザによるログインが許可された状態（PermitRootLogin yes）であるため、サーバが信頼できるネットワークに配置されているかを、再度確認しておく。
もし信頼できないネットワークに配置されていたのであれば、直ちにsshdを停止し、信頼できるネットワークへ再配置してからセットアップ作業を行うようにする。また、セットアップが完了したら、PermitRootLoginをnoにした上で、ログイン方法に公開鍵を利用するなどでセキュリティを向上させる作業を行っておきたい。
以上で、起動するだけのクリーンなDebian環境ができ上がった。クリーン環境の構築は、システム開発において比較的頻繁に行われる作業であるため、この手法を知っておくだけでもシステム開発の効率を上げられるのではないだろうか。
では、このクリーン環境に対し、Tracの環境構築を行っていく。
Tracのインストールと動作確認
TracもAPTでインストール可能だ。Debianには「trac-ja-resource」というメッセージやメニューを日本語化するパッケージも存在するが、筆者が確認したところ、Trac本体のバージョンと一致していなかったため、動作が不安定だった。trac-ja-resourceの内容は、テンプレートファイルとメッセージのテキストファイルであるため、多少の修正で動作させることは可能であるが、本連載の趣旨から外れてしまうため、今回はメッセージやメニューはオリジナルの英語のままで環境構築することにする。
TracはCGIとして動作させるようにした。こうすると、mod_pythonなどに比べ動作速度面では不利になるが、動作環境の制約が少なくて済む（＝環境を汚さない）といったメリットがある。例えばハードウェアが用意できず、既存の環境に「間借り」するといったことも、CGIならば比較的容易だろう。「環境を汚さない」というメリットは、情報システム部門と交渉して既存サーバに間借りする際にも、良い説得材料となるだろう。
さて、実際のインストールは以下のコマンドを実行する。
# aptitude install trac
以上で終わりだ。APTを利用すると依存関係まで解決してくれるので非常に簡単である。ただし、Tracはインストールだけでは動作しない。プロジェクトごとに環境を設定する必要がある。設定方法は図3の環境設定手順の通りだ。
これで、/var/lib/trac/pj1というディレクトリに、「ProjectName No.1」というプロジェクトが設定された。
この状態で、「http://TRAC動作ホスト/trac」にアクセスすると、簡素ではあるが、プロジェクトの名前一覧が表示される。プロジェクト名をクリックすれば、プロジェクトのトップページが表示される。ここまでくればTracの動作確認は完了だ。TRAC動作ホストは適宜読み替えていただきたい。
動作に失敗している場合、大抵はパーミッションの設定ミスであると考えられる。環境設定手順におけるchownコマンド周辺を見直してほしい。それでも稼働しない場合は、apacheの設定ミスが考えられる。/var/log/apache2/error.logやaccess.logを頼りに対処してもらいたい。
本連載はTracの紹介ではないため、Tracそのものの使い方や、Tracの特徴の1つであるSubversion（http://www.thinkit.co.jp/free/article/0611/2/2/）連携については紹介を見送る。しかし、今回紹介しているインストール方法は、Subversion連携と共存可能なようにしているため、この設定を元にSubversion連携が可能なTracへと育てていくことも可能である。Tracの使い方やSubversion連携については、読者自身で調べてもらいたい。
Debianを採用したメリット
さて、ここまででサーバOSの話題はほとんど出てこなかったが、サーバOSとしてDebianを採用したメリットとは、何なのだろうか？
Debianを選択した経緯をおさらいしてみよう。アプリケーションはTrac、ハードウェアは場合により異なる、とした。その上でDebian選択のポイントになったのは、「多様なハードウェアに対応」する点、そして「慣れ」だった。
Debianは幅広いハードウェアプラットフォームをカバーしているため、どのようなハードウェアが提供されたとしても、おおむね対応できるだろう。OSをインストールしてしまえば、基本的にはハードウェアプラットフォームを意識することなく管理が可能になり、大きなメリットになる。
ただし、このメリットを享受できるのは、Debianに「慣れている」技術者がいる場合である。担当者が扱えないOSを採用しても、システム構築は不可能だ。現在扱うことのできるOSをあらためて認識しておき、必要であればその幅を広げていきたいものだ。
以上、今回はDebianという汎用的なサーバOSでシステムを構築していく様子を紹介した。しかし世の中には、固有の目的に特化したOSも存在する。次回は、NAS（Network-Attached Storage）構築に特化したサーバOSの「FreeNAS」を紹介し、その中で、目的に合ったOSがもたらす導入・運用の容易性を踏まえ、もう1つのOSの選択基準を提案してみようと思う。
