タイトルが長くなってしまいましたな。
gitlabで作成したプロジェクトからソースを取得する際2つの方法がある。1つはsshでもう1つはhttp。ｈｔｔｐの場合、アクセスするポート番号がgitlabの環境を構築したときのポート番号になっている。ReverseProxyを経由してgitlabにアクセスしている場合、デフォルトで表示しているポート番号が一致しないためそのままコピペできないし、ReverseProxyで運用していることや、どのポートを使用しているかがわかられてしまう。
この問題を改善します。目指すところはReverseProxyの受付ポートを表示する、です。
←これが、 こうなる→
突然ですが、gitlabのキツネ(?)画像の存在感が強すぎるため変更したい思います。変更するのは以下の画像。
サブドメインでgitlab環境を構築する方法をまとめる。サブドメインで構築するとavatarのicon問題は発生しないの。…というかicon問題が完全に解決しないことに対するある意味逃げです。はい。
今回の挙動は以下を目指します。一応、前提環境はCentOS 6.5とします。DebianやUbuntuでも問題ないけれど、その場合はyumとかを適宜置き換えてください。
やることはだいたい以下。
gitlabのavatar対策をどうするかを考えつつ、gitlabをmanual install環境でも同じなのかを試そうと思ったのだけれどこれがなかなかうまいこといかない。詰まった点は色々あるのだけれどそのうちの1つであるsudo時にコマンドが見つからない問題と解決方法を書く。
gitlabのmanual install時はbundleを実行する機会が多いのだけれど必ずcommand not foundと帰ってくる。絶対パス指定で実行するとコマンドが実行できるのでパスが通っていないのがわかる。
$ sudo -u git -H bundle sudo: bundle: コマンドが見つかりません $ sudo -u git -H /usr/local/bin/bundle Could not locate Gemfile
手元の資料としてはmanualとgoogleぐらい。今回はman sudoから関係しそうなキーワードで検索してみた。とりあえずpathで検索をしたら以下のような記載があった。
環境変数
sudo は以下の環境変数を利用する。
(中略)
PATH sudoers の secure_path オプションが設定されていれば、無難な値にセットされる
どうやら無難な値にセットされるらしい。sudoersのsecure_pathが関係しているのでvisudoからsecure_pathを検索すると以下の行を発見。
Defaults secure_path = /sbin:/bin:/usr/sbin:/usr/bin
無難なPATHがこのsecure_pathの内容だそうなので必要なパス(/usr/local/bin)を追加したらsudo -u git -H bundleが正常に実行できた。
sudoで実行する際は環境変数がそのまま引き継がれるわけでも実行ユーザの環境変数が使われるわけでもないみたい。引き継いで実行したい場合はsudoersをカスタマイズすることで可能とのこと。
あとgoogleで検索したらたくさん結果がでてきた。解決方法はsudoersを変更するものから環境変数を渡すものまで色々。sudoersの変更でも数種類の方法を提示しているところも。
わかってはいたけれどwebで調べた方が圧倒的に早いね。(情報量も多いし。)
前の記事にわかりにくい箇所や、「sudo -u git -H bundle exec rake…」について記載していなかったりしたので、改めてここにまとめなおします。
構築内容は以下の通り。