One IT Thing

IT業界を楽しむ為の学習系雑記

git GitLab linux mattermost

GitLabのIPを変更したらMattermostにログイン出来なくなった話「the redirect uri included is not valid. 」

投稿日:2019年5月19日 更新日:

発端

先日オフィスの引っ越しが有りネットワークセグメントが変わる為、GitLabを入れているCentOS7のIPを以下のように変更しました。

  • 旧:10.85.122.5
  • 新:10.85.130.30

GitLabは設定変更することで問題無く動いたのですが、同梱のMattermostにログインが出来なくなってしまいました(MattermostへはGitLabのOAuthを介してログインしています)。

同じ罠にはまった人向けにシチュエーションを公開しておきます。

環境

  • CentOS 7
  • GitLab 11.5.4(10.85.130.30:18080で運用)
  • Mattermost 5.4.0(10.85.130.30:18081で運用)

GitLabのIP変更設定を開始

GitLab設定ファイル「/etc/gitlab/gitlab.rb」で変更するべき箇所は以下の5行です。
(ここ1年くらいに新規インストールしたGitLabなら下三行は設定する必要は無いかも知れません)

# grep 10.85.130.30 /etc/gitlab/gitlab.rb
external_url 'http://10.85.130.30:18080'
mattermost_external_url 'http://10.85.130.30:18081'
mattermost['gitlab_auth_endpoint'] = "http://10.85.130.30:18080/oauth/authorize"
mattermost['gitlab_token_endpoint'] = "http://10.85.130.30:18080/oauth/token"
mattermost['gitlab_user_api_endpoint'] = "http://10.85.130.30:18080/api/v3/user"

「gitlab-ctl reconfigure」して設定をGitLabに反映。この時点でGitLabのWeb画面には正常にログイン出来ました。

自分の開発用PCのgit設定もremote originを新IPに設定し直し、変更後のGitLabに接続出来ることを確認しておきます。

git remote set-url origin http://10.85.130.30:18080/チーム名/プロダクト名.git

そしてハマる

さて、変更が終わったことをチーム皆の衆にMattermostで周知するか、と意気揚々とMattermostログイン画面を開きます。

「Sign in with: GitLab」でOAuthサインインしようとすると・・・GitLab画面で以下のエラー。

An error has occurred
the redirect uri included is not valid.

なんですと・・・?
OAuthログインが上手く行ってないようです。どこで設定するのでしょうか?それっぽい設定ファイルが無いか探します。

# locate mattermost | grep .json

    (snip)

/var/opt/gitlab/mattermost/config.json  ← それっぽいの

それっぽいのが有りました。中身もOAuth関連で、しかも旧IPのままになっていました。
「フフ、こいつが犯人だな」。確信を持って新IPに変更しました。

# grep 10.85.130.30 /var/opt/gitlab/mattermost/config.json
        "SiteURL": "http://10.85.130.30:18081",
        "AllowedUntrustedInternalConnections": "10.85.130.30",
        "AuthEndpoint": "http://10.85.130.30:18080/oauth/authorize",
        "TokenEndpoint": "http://10.85.130.30:18080/oauth/token",
        "UserApiEndpoint": "http://10.85.130.30:18080/api/v3/user"

設定反映ミスでガッカリしたくないので、gitlab-ctl reconfigure、gitlab-ctl stop、gitlab-ctl startしておきます。 再度Mattermostログイン画面から「Sign in with: GitLab」を押下・・・!

・・・GitLabのアイコンに化かされている気がしてきました。

気を取り直してOS内の全.jsonを全文検索、mattermost関連設定を探します。1ファイル有りましたが・・・OAuth関連設定ではありませんでした。

# locate -r "\.json$" | xargs grep -i mattermost | grep 10.85.130.30

/opt/gitlab/embedded/nodes/ホスト名.json:      "mattermost-external-url": "http://10.85.130.30:18081",

ここまで来て設定ファイルで設定されていないことに気付き始めます。

解決

設定ファイルに設定が無いならWeb画面&DBで設定されるんだろう、とadminユーザでGitLab画面にログイン、色々探していると・・・ありました。

  • 上部メニューバー内の「Admin Area」をクリック
  • 左メニュー内の「Application」をクリック

右ペイン「GitLab Mattermost」の「Redirect URI」が旧IPのままになっています。

これを新IPに変えてやることでMattermostにログイン出来るようになりました。

結局どこに設定が保存されていたか

GitLabの組み込みPostgreSQLテーブルを探したらoauth_applicationsテーブルのredirect_uriカラムに設定が保存されていました。

# gitlab-psql -d gitlabhq_production

gitlabhq_production=# select name, redirect_uri from oauth_applications;
       name        |                    redirect_uri
-------------------+-----------------------------------------------------
 GitLab Mattermost | http://10.85.130.30:18081/signup/gitlab/complete\r+
                   | http://10.85.130.30:18081/login/gitlab/complete
(1 row)

まとめ

GitLab初回インストール時はOAuthのリダイレクト先はgitlab.rbを汲み取って自動的に設定してくれていた(と思います)が、変更が入った時はWeb画面から自分で設定する必要があるようです。

GitLab、Mattermostの設定方法は以下の3系統がありますが、

  • gitlab.rb
  • 各種json
  • Web画面

GitLabのWeb画面で設定した値は、基本的にGitLabの組み込みPostgreSQLに保存される、と考えて良さそうです。

LAN内だからと言ってIPベースで運用していると変更が有った時面倒ですね。Jenknsジョブも手直しが必要で結局一日仕事になってしまいました。DNSを建てて徐々に移行していくモチベーションを与えてくれる出来事でした。

-git, GitLab, linux, mattermost

執筆者:

関連記事

Omnibus版のGitLab、Mattermostデータベースに外部ホストからJDBCで接続

Omnibusで入れたPostgreSQLは、 Unix Domainソケットで接続待機Peer認証で認証 していて外部からの接続は出来ないことが前回分かりました。 One IT Thing …

CentOSで暗号鍵用のパスワードを生成

そこそこ長くて文字種の入り混じった強度の高いものを自分で考えるのは面倒です。 暗号化処理を使う際に必要なパスワード文字列を、mkpasswdコマンドでいい感じに生成出来るようにしておきます。 目次1 …

編集中の内容をgit stashで退避する手順

「gitlabでブランチを切ったのに、ローカルPCでブランチを切り替えず、masterやdevelopなどの主流ブランチでコード変更してしまった」 やってしまったらgit stashで変更を退避してお …

Nodeアプリが依存するnpmモジュールライセンスをlicense-checker & Jenkinsで自動チェック(2)

目次1 目的1.1 動作イメージ2 Jenkinsジョブを設定2.1 前提2.2 Jenkins「シェルの実行」を設定2.3 想定外ライセンスが含まれていた場合の通知3 まとめ 目的 前回の続き。&n …

LinuxでDOOMをプレイ(ゲームソースコードをコンパイル)

「IT業界に”技術者”として身を置く人はおよそ100%コンピュータゲーム好き、あるいは若い頃にハマった経験がある」という仮説を唱えてやまない投稿主です。 そんなゲーム好きな皆様(決めつけ)は「arch …


shingo nakanishi。東京で消耗中の職歴20年越え中年ITエンジニアです。「生涯現役プログラマを楽しむ」ことができる働き方探しをライフワークにしています。

19歳(1996年)から書き始めた個人日記が5,000日を超え、残りの人生は発信をして行きたいと思い、令和元日からこのサイトを開始しました。勉強と試行錯誤をしながら、自分が経験したIT関連情報を投稿しています。