「 サーバー構築 」一覧

RhodeCodeが様変わりしてた


RhodeCode が良さそうに思って以前に導入記事を書いてみましたが、久しぶりにどうなったかなと思って確認したところ、なんと色々と大きく変わっていました。

RhodeCode Enterprise というものになっていて、20ユーザーまではフリーで使えるという状態のようです。以前はそんな制約はなかったと思います。GPLv3 のライセンス下で配布されていたと思います。

検証当時は GitLab vs RhodeCode で、個人的には RhodeCode を推していこうと思っていたのに、この制限があるとチームで使う際には除外されていきそうです。残念。

追記

どうやら、1.7.1はGPLv3のままの提供、その後の新バージョン 2.x 系を RhodeCode Enterprise としてライセンス体系を変えたっぽいです。



GitLab


GitLab 4.1が先日公開されました。この4.1がなかなか魅力的だったのでここで紹介したいと思います。

今までのGitLabは無料のGitHubで出来ない、プライベートなリポジトリを持つことを前提として、
公開リポジトリに関してはサポートしないという位置づけでした。
これが今回の4.1では、パブリックなリポジトリをGitLab上で管理できるように機能が拡張されました。

これすごく欲しかったんですよね・・・。2.4のころにサポートされていればこちらをじっくり検討したかもしれない・・・。

4.0ではCIまわりで手が入っているし、これはぼちぼち再チェックした方がよさそうな雰囲気を感じました。


RhodecodeのActiveDirectory認証


ActiveDirectoryの認証を用いてユーザー認証できるというRhodecodeですが、その説明を書いた部分が見つからないのでここにメモがてら残しておきたいと思います。一応紹介記事ではLDAP/ActiveDirectoryが使える!とあるのにその設定が見つからないのはどうなのだろうと思ったり。

Rhodecodeの設定

ここで試しているRhodecodeは 1.4.3 です。
管理者ユーザーでログインして LDAP の項目を表示させます。そして以下の内容で設定していきます。

  • LDAPを有効にする にチェックを入れる。
  • ホスト: ActiveDirectory(ドメインサーバー)が動いているアドレスを入力
  • ポート: 389
  • アカウント:検索用のユーザー名. なければ適当なユーザー名を。
  • パスワード:上記ユーザーのパスワード
  • 接続のセキュリティ:暗号化無し
  • 証明書チェック:NEVER
  • Base DN: ドメイン名がMYDOMAIN.LOCALの場合だと、 DC=MYDOMAIN,DC=LOCAL と入力する
  • LDAPフィルター: 空欄のまま
  • LDAP検索範囲:SUBTREE
  • ログイン属性: sAMAccountName
  • 名前属性(FirstName): givenName
  • 名字属性(LastName): sn
  • メールアドレス属性:mail

これらの設定で自分の環境ではドメインのユーザーを認証できています。


GitlabとRhodecodeのメール設定


GitlabとRhodecodeを調べていてメール関連でどちらも設定を放置していたので調べてみました。

Gitlabの場合

gitlab.yml の email セクションの host という項目に対して、メールサーバーのアドレスを設定します。
たいていlocalhostのままなので、ここにメールサーバーのアドレスを記載します。
localhostのままでメールを送れるようにするためには、gitlabを動かしているサーバーでPostfixなりssmtpなりのメールサーバーを動かす必要があります。

Rhodecodeの場合

production.ini ファイルの中に smtp_server という項目があるので、そこにメールサーバーのアドレスを記載します。送信についてSMTP認証がかかっていたりする場合には、smtp_serverの行付近にアカウント情報を設定するような項目があったので、そこで設定してあげればよいように思います。

ついでに、email_prefix という項目もあるので、何かしら設定しておくと、メール振り分け設定の指標になるし便利だと思います。


Rhodecodeのバージョン更新


1.3.6を以前インストールしましたが、最近は既に1.4.3が出ているようなので以下の手順でバージョンをあげてみました。

バージョンを更新する

production.ini.oldの中身を確認しつつ、新しく作られた production.ini の中身を再設定していく.
自動マージされるらしいのだけど、手元ではうまくいきませんでした。

データベースを更新します。

起動し直します

そういえば更新してみて気付きましたが、言語を日本語の設定にすることが出来るようになったようです。production.iniの中にlangという項目があり、そこにjaを設定することができます。

チケット連携?

rhodecodeのIssue Tracker連携があるかと思っていたのですが、連携というわけでは無く単にリンクが張られるだけのようでした。コミットコメントにチケット番号を記述しておくと、それに対応する
IssueTrackerのチケットへ飛べるだけの機能のようにみえます。


Rhodecodeの使い方とGitの問題と


Rhodecodeの使い方

まず管理者でログインして、普段使用するユーザーを作成します。
下記の画像に示すようにしてユーザーを作成します。

ユーザーの作成が終わったら、ログアウトしておきます。
続いて先ほど作った普段使いのアカウントでログインします。
そして、”ADD REPOSITORY”を押して、リポジトリの追加を行います。

とりあえずリポジトリの名前、リポジトリの種別(git/hg)、概要などを記入して、画面下部のaddボタンを押します。Private repository にチェックを入れればプライベートリポジトリとなります。

ここでは、タイプにgitを選んでいることにします。

ある適当なフォルダで、右クリックしてtortoiseGitのCloneを選びます。
Urlには先ほどのRhodecodeのリポジトリ情報で表示されていた Clone url の部分のテキストを入力します。

取得できたら、適当にファイルを追加して、gitのAdd, Commitなど実行しておきます。
最初なので readme.txt とかファイルを用意しておくとよいかもしれません。

ここまで準備が出来たら、Rhodecodeのリポジトリへ反映させます。
tortoiseGitのメニューで Push があるのでそれを実行します。
実行するとパスワードを聞かれると思います。これはRhodecodeのユーザーに設定したパスワードを用います。

この状態でブラウザからRhodecodeの自分のリポジトリ情報を表示させてみると、今回Pushした内容が反映されているのがわかります。

GitとRhodecodeの罠(履歴とかコメントとか表示されない)

将来的にはこれからの内容は既に解決済みとなっていることでしょう。
2012/08/26現在ではGitでコミット&プッシュしているのにRhodecodeで反映されない!という問題があります。昨年の情報を見る限りではそんな人はいないようですが…。

ちょっと調べてみたところ、この原因はサーバー側のGitのバージョンによるものっぽいです。
CentOS 6.0の環境で yum install git として入ったバージョンが 1.7.1
これがあるコマンドオプションに対応していないために上記の問題が起こるようです。

これを解決するために新しいバージョンのgitを入れる必要があります。
これにはRPMForgeをyumの対象に加えて、再度gitをインストールすることで行います。

# yum install wget
# rpm –import http://apt.sw.be/RPM-GPG-KEY.dag.txt
# wget http://packages.sw.be/rpmforge-release/rpmforge-release-0.5.2-2.el6.rf.x86_64.rpm
# rpm -ivh rpmforge-release-0.5.2-2.el6.rf.x86_64.rpm

# yum install git –enablerepo=rpmforge-extras

この後、gitのバージョンを確かめてみると、1.7.11.1 が入っていました。
この状態で、Rhodecodeのリポジトリに対してgitのコミットを行ったり、ブラウザからリポジトリ情報を表示させたときには、今までの操作履歴が表示されるようになっています。


Rhodecodeのインストール


はじめに

GitLabに続きRhodecodeもよさそうだったので、ここにインストールまでの手順をメモしておきます。GitLabは完全にプライベートリポジトリの扱いだったのですが、Rhodecodeは認証無しの状態でもどんなリポジトリがあるのかを見ることが出来ます。
もちろんプロジェクトの設定によっては非公開とすることも可能です。
いくつかの記事にあるように ActiveDirectory/LDAPとの認証連携が出来るのは大きなポイントかと思います。残念な点としては内部にIssueTrackerを持たないことでしょうか。これについては、外部のバグトラッカーと連携することも考えられて設計されているような感じです。

CentOSの準備

CentOS 6.0をMinimumインストールしてある状態からの手順を下記に書きます。

まず今後ネットワークを使えるようにしておきます。

ifcfg-eth0のファイルを編集します。

続いてSELinuxを無効化します。

ファイアウォールも無効化しておきます。

ここまで設定したら一度再起動します。

必要な物のインストール

Rhodecodeのインストール

途中で、リポジトリを格納する場所、管理者ユーザーの情報を入力します。

他のホストから接続できるように設定ファイルを変更します。

host = 127.0.0.1 の部分を割り当てられているIPに変更します。
(どこからでも受け付けたいなら0.0.0.0を設定する. )
そしてRhodeCodeを起動します。

5000番ポートで起動するので、http://(アドレス):5000/ にアクセスします。


あとはセットアップ時につくった管理者ユーザーでログインして、ユーザーを作成したりリポジトリの用意をしたりして運用していきます。

Apacheとの連携

httpd.confに記述を追加して、5000ポートへリダイレクトさせるようにします。

この設定の中で、アドレス中の “rhc” がプレフィックス扱いです。

production.iniを開き、[app:main]セクション内の編集を行います。

同じくファイルの末尾の部分に以下の内容を追記します。
上記のfilter-withの直後に書くとセクション情報の破壊を起こしてしまうので、セクションの切れ目で追記する必要があります。まぁファイル末尾に追記ならそういった問題が起こらないので・・・。

prefixの行に、先ほどのプレフィックス扱いとなっていた部分の文字列を設定します。

自分の環境では、このプレフィックス部分が”rhodecode” ではどうもうまく動作しませんでした。ChromeではうまくいくのにFirefox, IE9では失敗します。/rhodecode/ → /rhodecode./ というようにアドレスが展開されたところまでわかったのですが、それの原因はわからずじまいです。

環境情報

  • CentOS 6.0(x64)
  • Rhodecode 1.3.6
  • Pythonはvirtualenvを使用. (virtualenvを使用しなくても動作できることは確認しています。)

今後のネタ予定

  • 基本的な使い方
  • ActiveDirectoryとの連携
  • 外部バグトラッカー との連携

gitをhttp経由で使いたい その2


先日の追記情報だけではまだ不十分でした。
確かにclone, commit, push まで成功するのですが、それは最初にcloneしたリポジトリでの操作に限定したものでした。他のcloneした場所で編集して push しようとして失敗したり、そもそもcloneで失敗(空っぽリポジトリ)といった現象が見られました。

再度確認してみると足りなかったのは以下の2点

  • hooks/post-update.sampleを post-update として配置
  • サーバー側のリポジトリのアクセス権が全てapache(wwwのユーザー)になっていること

これらをまず確認してみることが必要かと思います。

意外に、git update-server-info を実行するとファイルが作成されて、それが実行したユーザーになっていたりするので、apacheユーザーが所有者ではないファイルができてしまっていたりします。
また、pushのたびに update-server-info の実行が必要なようで、それをやってくれるのが post-updateのスクリプト内となっています。

他に、リバースプロキシ背後で動かそうとするとまたパスの問題が出てきそうなので、それはまたいずれ調査と言うことで。


gitをhttp経由で使いたい(ついでにgitweb)


以前にGitLabのインストールや使い方を書いてみたのですが、どうやらあれはsshをつかえる環境でないといけないようで、簡単にhttp(やhttps)を経由してのclone, pushなどはできないようでした。おまけに各ユーザーのプライベートリポジトリを作ることが前提で、非登録のユーザーが閲覧することもできないようです。(言い分としてはその場合はGitHubでいいでしょ、ということだそうで)。

さて、なぜHttp経由かという理由ですが、httpプロトコルしか通過できないファイアウォールがあるところも多いです。特に開発の現場ではまだまだ多く存在するようです。こういった場合にはgitを使う場合にclone,pushらをhttpによって行う必要が出てきます。
Subversionでもsvnプロトコルではなくhttp経由のWebDAVを用いて使っている例も多いのはその理由によるところもあるのかなと思ったりしています。

前提条件

次のものはインストール済みで設定も終わっているものとします。

  • Apache(WebDAV有効状態で)
  • git

設定

リポジトリらを /var/www/html/repos-git に配置するとして、ディレクトリを用意しておきます。
これから説明するディレクトリらの所有者はapacheとしておきます。

Apacheの設定ファイル(httpd.conf)を開いて、リポジトリらをWebDAVでアクセスできるように修正します。

※上記で指定するWebDAVを有効にするディレクトリを指定する際には、gitリポジトリそのものである必要があります。
SVNのよう な親ディレクトリを指定すればOKな感じでは無く、各リポジトリそれぞれでDAV ONとしなくてはならないようです。この点にはまりました(5/29追記)

apacheを再起動した上で、テストのためにリポジトリを用意してみます。

動作チェック

次のコマンドを実行していき、リモートリポジトリを用意します。

入力するアドレスは、 http://(サーバーのIP)/repos-git/test です。
うまくいけば、Success を表示されて、リポジトリが取得できます。

gitを試していると、リポジトリが取得できても、push ができないことが割と発生しますので、ここでpushも正常にできるかを確認しておきます。
適当なファイルを追加して、編集した後で、commit, push してリモートリポジトリにpushが成功するかを確認してみてください。

Gitwebのインストール

せっかくなのでGitwebも入れてみました。

このコマンドで簡単にインストールが完了します。
あとは設定ファイル /etc/gitweb.conf を編集するだけです。

$projectroot という変数にGitリポジトリの場所を設定するようになっているので、次のように書き換えます。

そして、apacheを再起動して、http://(サーバーのIP)/git/ にアクセスしてみます。
問題なければ、testリポジトリが一覧に並んでいることでしょう。

まとめ

とりあえずユーザー認証はなしでまずはサーバーにgitを用意してhttpによるアクセスをさせるというところを目的として、環境設定を行ってみました。今のところやっぱりWebDAVによってhttp経由のアクセスをさせるというところに落ち着いてしまいました。 ただWebDAVを使っていると遅いという話もあるようなので、別の方法でhttp経由のgitリポジトリ取得の方法がないかを、もうしばらく探してみたいと思います。