Ubuntu

Discourseをインストールしてみる

システムを運営していると似たような問い合わせが多いので、相談しやすい窓口を用意してそこで聞いてもらう。電話での問い合わせも、運営メンバーが記録の代わりにそのサイトに書き込んでおく。

最初のうちは同じ質問が多数来るだろうけれども、そのうち一度はそのサイトを見てから聞いてくるようになって、みんなハッピーに。



広告


こんな世界を夢見てDiscourseをインストールしてみようと思った。前回のものよりも高機能に見える。

DiscourseはオープンソースでGithubからインストールが可能、ホスティングサービスも提供されている。

 

環境

VMware PlayerでUbuntu 18.04を立ち上げ、そこにインストールする。

Let’s Encryptを使うのが標準だけど、自己署名証明書を使いたい。
また、LDAP認証にも対応しているようなので、Samba AD DCで認証させる。

構築するサーバーは temp.hogeserver.hogeddns.jp とする。
実作業時には読み替える。

インストール

どこに行ってもDockerインストールが説明されているので何でかな?と思ったら、公式がDockerしかサポートしないスタイル。環境構築は複雑で大変だし、アップデートボタンで簡単にアップデートできるようにしてあるよ、とのこと。環境設定が上手くいくのいかないの、といった問い合わせを減らすには一番簡単な方法なのかもしれない。

インストールガイドはこちら。かなり逸脱したかも。
Github / discourse / discourse / docs / INSTALL-cloud.md

意識しておくと違うかもしれないので最初に書いておくと「Dockerの中の環境は、色々変更しても再構築で元に戻る。app.ymlというファイルに書いたとおりに構築されるから、これを理屈通りに組み立てればOK。」といえる。

この手順を流すだけなら、待ち時間もあるから…だいたい1時間もあれば構築できると思う。

Dockerのインストール

とりあえずこれでインストール。Dockerの操作そのものはDiscourseがラッピングしたコマンドを用意してくれているので、今回もDockerについてはあまり頑張らない。

$ sudo apt update; sudo apt -y dist-upgrade; sudo apt -y autoremove
$ sudo reboot ※必要なら

$ sudo timedatectl set-timezone Asia/Tokyo
$ sudo ufw allow ssh
$ sudo ufw allow http
$ sudo ufw allow https
$ sudo ufw enable

$ sudo apt install docker docker-compose

 

Discourseのダウンロード

手順書と違って恐縮だけれども、/opt/discourseにインストールしてみようかと。
※本来は/var/discourseにインストールする、そうすると、ログとかのディレクトリとの接続性が良くなるように作られている。2021/02/23追記

$ sudo su -
# git clone https://github.com/discourse/discourse_docker.git /opt/discourse
# cd /opt/discourse/

 

メールサーバーの準備

メールサーバーを準備しておくように書かれている。ウチでは以前メールサーバーを立ててあってインターネットに口を開けていて、そこからプロバイダーにリレーする設定になっているので、それを使うことにする。

ドメイン名の準備

IPアドレスでは動作しないとされているので、FQDNっぽい名前で名前解決ができるようにしておく必要がある。

ウチはインターネットに向けてサービスを公開しつつ、宅内からも同じFQDNでアクセスができるようにしたかったので、宅内に内向きDNSサーバーを立ててあるのでどうにか。その気になればインターネットからも名前解決ができる。

まずはお試し、ということなら、hostsに名前を設定しておけばどうにかなるだろう。

設定から構築

セットアップを実行したところ、以下のエラーとなった。

# ./discourse-setup
Ports 80 and 443 are free for use
'samples/standalone.yml' -> 'containers/app.yml'
Found 1GB of memory and 2 physical CPU cores
setting db_shared_buffers = 128MB
setting UNICORN_WORKERS = 2
containers/app.yml memory parameters updated.

Hostname for your Discourse? [discourse.example.com]: temp.hogeserver.hogeddns.jp

Checking your domain name . . .
WARNING: Port 443 of computer does not appear to be accessible using hostname:  temp.hogeserver.hogeddns.jp.

SUCCESS: A connection to port 80 succeeds!
This suggests that your DNS settings are correct,
but something is keeping traffic to port 443 from getting to your server.
Check your networking configuration to see that connections to port 443 are allowed.

The first thing to do is confirm that temp.hogeserver.hogeddns.jp resolves to the IP address of this server.
You usually do this at the same place you purchased the domain.

If you are sure that the IP address resolves correctly, it could be a firewall issue.
A web search for "open ports YOUR CLOUD SERVICE" might help.

This tool is designed only for the most standard installations. If you cannot resolve
the issue above, you will need to edit containers/app.yml yourself and then type

./launcher rebuild app

こうなると、途中までの設定ファイルが残ってしまっているので、一旦ファイルを削除。

# rm containers/app.yml*
# ./discourse-setup

※上手くいくまで繰り返す。

何度か実行しているうちに上手くいった。

# ./discourse-setup
Ports 80 and 443 are free for use
'samples/standalone.yml' -> 'containers/app.yml'
Found 1GB of memory and 2 physical CPU cores
setting db_shared_buffers = 128MB
setting UNICORN_WORKERS = 2
containers/app.yml memory parameters updated.

Hostname for your Discourse? [discourse.example.com]: temp.hogeserver.hogeddns.jp

Checking your domain name . . .
Connection to temp.hogeserver.hogeddns.jp succeeded.
Email address for admin account(s)? [me@example.com,you@example.com]: webmaster@hogeserver.hogeddns.jp
SMTP server address? [smtp.example.com]: smtp.hogeserver.hogeddns.jp
SMTP port? [587]: 25
SMTP user name? [user@example.com]: administrator@hogeserver.hogeddns.jp
SMTP password? [pa$$word]: password
Optional email address for Let's Encrypt warnings? (ENTER to skip) [me@example.com]: OFF

Does this look right?

Hostname      : temp.hogeserver.hogeddns.jp
Email         : webmaster@hogeserver.hogeddns.jp
SMTP address  : smtp.hogeserver.hogeddns.jp
SMTP port     : 25
SMTP username : administrator@hogeserver.hogeddns.jp ※うちでは使わないので後で無効化する
SMTP password : password                             ※ 〃

ENTER to continue, 'n' to try again, Ctrl+C to exit: [Enter]
Enabling Let's Encrypt ※うちでは使わないので後で無効化する
web.ssl.template.yml enabled
letsencrypt.ssl.template.yml enabled

Configuration file at  updated successfully!

Updates successful. Rebuilding in 5 seconds.
Building app
…

※この後、かなり時間を掛けて構築されていく…。

起動しているのか確認してみる。

# docker images
REPOSITORY            TAG                 IMAGE ID            CREATED             SIZE
discourse/base        2.0.20200512-1735   991acdba0b1f        4 weeks ago         2.22GB

このやり方だと、この段階ではログインできなかった。

自己署名証明書の設置

証明書はLet’s Encryptで取るのが常識?なのかもしれないけれど、企業で利用するならドメインがCAをやっていることもあるだろうし、Dynamic DNSを使わせていただいているケースでは上手くいかないこともあると思う。ということで、自己署名証明書を設置。
Discourse / Advanced Setup Only: Allowing SSL / HTTPS for your Discourse Docker setup

ここに証明書を配置。ファイル名をあわせて、権限を修正して、こんな感じに。

# ll /var/discourse/shared/standalone/ssl
-rw-r--r--  1 root root 1480 Jun 13 09:44 ssl.crt
-rw-------  1 root root 1679 Jun 13 09:46 ssl.key

※テンプレートがssl.crtとssl.keyを求めているので、名前を変えてはいけない、と書かれていた。

証明書の用意ができたら、設定ファイルの書き換え。

/opt/discourse/containers/app.yml

…
templates:
  - "templates/postgres.template.yml"
  - "templates/redis.template.yml"
  - "templates/web.template.yml"
  - "templates/web.ratelimited.template.yml"
## Uncomment these two lines if you wish to add Lets Encrypt (https)
  - "templates/web.ssl.template.yml"
# - "templates/web.letsencrypt.ssl.template.yml"
…

ここまで設定したところで再構築。

# ./launcher rebuild app

実際に ./launcher enter app でコンテナの中に入って見たところ、確かにその設定がされていた。

launcher/etc/nginx/conf.d/discourse.conf

…
ssl_certificate /shared/ssl/ssl.crt;
ssl_certificate_key /shared/ssl/ssl.key;
…

 

メール送信時のSMTP認証と暗号化をやめる

メール送信用に立てたLAN内のサービスはセキュリティ設定を一切していない。それを使うためには、設定が必要。
※ちゃんとしたサーバーを使う場合には行わない設定。

/opt/discourse/containers/app.yml

…
env:
…
  ## TODO: The SMTP mail server used to validate new accounts and send notifications
  # SMTP ADDRESS, username, and password are required
  # WARNING the char '#' in SMTP password can cause problems!
  DISCOURSE_SMTP_ADDRESS: smtp.hogeserver.hogeddns.jp
  DISCOURSE_SMTP_PORT: 25
  #DISCOURSE_SMTP_USER_NAME: webmaster@hogeserver.hogeddns.jp
  #DISCOURSE_SMTP_PASSWORD: "nashi"
  #DISCOURSE_SMTP_ENABLE_START_TLS: true           # (optional, default true)
  DISCOURSE_SMTP_ENABLE_START_TLS: false
  DISCOURSE_SMTP_AUTHENTICATION: none
  DISCOURSE_SMTP_OPENSSL_VERIFY_MODE: none

ここまで設定したところで再構築。

# ./launcher rebuild app

 

最初のアカウントを作る

アクセスしてみる。今回だと https://temp.hogeserver.hogeddns.jp にアクセス。

Congratulations, you installed Discourse! と表示されているので、Registerボタンをクリックする。

Register Admin Account と表示される。
Email欄にはインストール時に入力したメールアドレスが表示されている。
UsernameとPasswordを入力してRegisterボタンをクリックする。

Confirm your Email 画面が表示され、アクティベーションのメールが送信される。
メールの中にあるURLをブラウザで開くとアクティベートが完了する。

初期設定で、言語に日本語、日本語…あった!

主たるロゴは高さ120以上で3:1以上の横長のものを用意してアップロード。
正方形ロゴも用意。
ブラウザー用のアイコン等は、正方形ロゴから自動生成してくれるらしい。

スタッフの招待はしなくても大丈夫みたい。

そんなこんなで新しいページができて、使い始められるようになった。

LDAP認証

会社で使いたいと思っているので、SSOが理想だけれども、最低でもLDAP認証は実装したい。
Github / guideline-tech / discourse-ldap-auth

/opt/discourse/containers/app.yml

…
## Plugins go here
## see https://meta.discourse.org/t/19157 for details
hooks:
  after_code:
    - exec:
        cd: $home/plugins
        cmd:
          - git clone https://github.com/discourse/docker_manager.git
          - git clone https://github.com/guideline-tech/discourse-ldap-auth.git

再構築。

# ./launcher rebuild app

再構築が終わったら、最初に作った管理者ユーザーでログインし、https://temp.hogeserver.hogeddns.jp/admin/site_settings/category/plugins にアクセスする。
(画面からだと、設定→プラグイン)

ldap enabled の項目をチェックして、値を設定していく。今回は以下の値とした。

設定項目設定値備考
ldap user create modeautoLDAP認証でアカウントが作られる。アクティベーションのためのメールが送られなかった。
ldap lookup users byusernameIDでログインしたいと考えたため。プロフィールにはLDAPから渡されたメールアドレスが設定された。
ldap hostnameldap.hogeserver.hogeddns.jpSambaのLDAPサーバーを指定。
ldap port636LDAPSのポートを指定。
ldap methodsslちゃんと気にして設定していなかったけれど、ウチはtlsでは動かなくてsslだけをサポートしていた。
ldap baseDC=hogeserver,DC=hogeddns,DC=jpSamba AD DCなのでこれ。ADとかだとちょっと違うかもしれない。
ldap uidsAMAccountNameユーザー名。
ldap bind dnAdministrator@hogeserver.hogeddns.jpLDAPの情報を検索するのに使っている。ウチは匿名だとエラーを返している。
ldap password<Administratorのパスワード>
ldap filter(&(sAMAccountName=%{username})(memberOf:1.2.840.113556.1.4.1941:=CN=Administrators,CN=Builtin,DC=hogeserver,DC=hogeddns,DC=jp))この指定の仕方をすると、グループに含まれるグループをたどってくれるとのこと。
StackOverflow / ldap filter in omniauth ldap module not working in discourse

LDAPでログインできるようになって、必要なアカウントに管理者権限を付けたら、サービス公開に向けてLDAP以外のログイン認証をしないように設定ができる。https://temp.hogeserver.hogeddns.jp/site_settings/category/login にアクセスする。
(画面からだと、設定→ログイン)

そこで、以下の項目を設定する。今回は以下の値を設定した。

設定項目設定値備考
login requiredチェックしないプラグインの公式ではチェックするように書かれているが、見るだけのユーザーもそれなりにいると思うので、参照はできてもいいかなと。
インターネットに公開するときにはチェックする。または、クライアント証明書によるアクセス制限を考える。
enable local loginsチェックしないローカルにログインするダイアログが表示されなくなる。最初に登録した管理者ユーザーが使えなくなる。
認証の条件を変える時には、チェックしておくことをオススメする。ログインできなくなるとどうしようもない。※

これで、LDAP認証ログインができる。LDAPで作ったユーザーに管理者権限を渡して、enable local loginsのチェックを外せば、正式運用開始!

※2020/07/26追記 強制的に復活させる手順を発見(別ページ)。

やったこと

セットアップ後にアクセスが拒否される

セットアップ直後、アクセスして見ると ERR_CONNECTION_REFUSED といわれて拒否される。

docker-proxyというのが動いていることが分かったので、appの中に入って確認してみると、NGINXが動いていて、証明書が読み込めないというエラーが発生していた。

/var/discourse/shared/standalone/log/var-log/nginx/error.log

2020/06/12 21:52:07 [emerg] 5124#5124: cannot load certificate "/shared/ssl/temp.hogeserver.hogeddns.jp.cer": PEM_read_bio_X509_AUX() failed (SSL: error:0909006C:PEM routines:get_name:no start line:Expecting: TRUSTED CERTIFICATE)

※ログが確認しやすいように、/var/discourseで色々と設定を共有してくれている模様。

なるほど、自己署名証明書を使おうとするなら、ここに設定する訳か。

Discourse appの中に入って証明書と鍵を設置。

# ./launcher enter app
これで、rootでappに入れる。

# vi /etc/nginx/conf.d/discourse.conf
これで、設定を見てみる。

これで中を見てみると…
/etc/nginx/conf.d/discourse.conf

…
ssl_certificate /shared/ssl/temp.hogeserver.hogeddns.jp.cer;
ssl_certificate /shared/ssl/temp.hogeserver.hogeddns.jp_ecc.cer;

ssl_certificate_key /shared/ssl/temp.hogeserver.hogeddns.jp.key;
ssl_certificate_key /shared/ssl/temp.hogeserver.hogeddns.jp_ecc.key;
…

どうやら、鍵までは作っているけれども、証明書は空っぽですね、と。

# ll /shared/ssl
total 16
drwxr-xr-x  2 root root 4096 Jun  9 23:27 ./
drwxr-xr-x 13 root root 4096 Jun  9 23:26 ../
-rw-r--r--  1 root root    0 Jun 12 21:27 temp.hogeserver.hogeddns.jp.cer
-rw-r--r--  1 root root    0 Jun 12 21:28 temp.hogeserver.hogeddns.jp_ecc.cer
-rw-------  1 root root  302 Jun 12 21:28 temp.hogeserver.hogeddns.jp_ecc.key
-rw-------  1 root root 3243 Jun 12 21:27 temp.hogeserver.hogeddns.jp.key

バージョンアップの時にどうなるのかが気になるけれど、従来使っているecc.keyなしの秘密鍵と証明書を配置して読み込ませることにした。

今あるファイルをどけておいて…
# mkdir /shared/ssl/org
# mv /shared/ssl/temp.hogeserver.hogeddns.jp* /shared/ssl/org/

秘密鍵と証明書をコピペで作り(pemなので)、権限を修正。

# chmod 600 /shared/ssl/temp.hogeserver.hogeddns.jp.key

 

eccのところは削除する…
/etc/nginx/conf.d/discourse.conf

…
ssl_certificate /shared/ssl/temp.hogeserver.hogeddns.jp.cer;
#ssl_certificate /shared/ssl/temp.hogeserver.hogeddns.jp_ecc.cer;

ssl_certificate_key /shared/ssl/temp.hogeserver.hogeddns.jp.key;
#ssl_certificate_key /shared/ssl/temp.hogeserver.hogeddns.jp_ecc.key;
…

修正したら、いつの間にか秘密鍵と証明書を読み込んでくれたらしく、ここでアクセスができるようになった。
とはいえ、一度、以下を叩いておいた方が安心。

# nginx -s reload

ここまでやって、後から気が付いたのは…この/sharedディレクトリって、実はホストの/var/discourse/sharedとつながっているのね。
だから、中に入って作業しなくても、ホスト側でファイルを操作すれば上手いこと動きそう。

というあたりまで気付いたところで、Let’s Encryptで鍵を作ろうとする動きがあって、証明書が上書きされ、エラーが再発したのだった。

vimでソースをコピーしようとしたらVISUALモードになった

appの中に入ってvim設定ファイルを開き、メモを取ろうとマウスで範囲選択をしたらVISUALモードになった。文字がコピーできない…
Qiita / vimでマウスを無効にする

:set mouse=

これでマウス選択した範囲がコピーできた。再び有効にするには…

:set mouse=a

ただ、これ、毎回なの?そう、毎回なの。ということで面倒なので、~/.vimrcを作って無効化しておいた。

~/.vimrc

set mouse=

これで、起動するたびに設定する必要はなくなった。

launcher enter app後のbashの様子がおかしい

※リビルドするとここで変えたものは元に戻る。当然と言えば当然か。

launcher enter appでログインした直後のディレクトリが /var/www/discourse だし、ちょっと操作しやすくしようと.bashrcを書いても効果がない。

おかしいと思ったら…
Qitta / 本当に正しい .bashrc と .bash_profile の使ひ分け

/root/.bash_profile

cd /var/www/discourse

何か理由があるのだろうけれども、メンテナンスしづらい。エイリアスやカラー表示に慣れ過ぎていて、ないと困るレベル。そのため、書き換え。

#cd /var/www/discourse
cd
test -r ~/.bashrc && . ~/.bashrc

その上で、.bashrcをコピって貼り付けておいた。

メール送信エラー

LANの配信専用のSMTPはセキュリティ意識ゼロ。試行錯誤の中でいくつかエラーが出たのでメモしておく。

まずは最初に出ていたエラー。

/var/discourse/shared/standalone/log/rails/production.log

Job exception: hostname "smtp.hogeserver.hogeddns.jp" does not match the server certificate

暗号化?してないな…と、この設定を入れた後。
DISCOURSE_SMTP_ENABLE_START_TLS: false

/var/discourse/shared/standalone/log/rails/production.log

Job exception: 503 5.5.1 Error: authentication not enabled

で、最終的に本編の設定となった。

このサイトで目にする画像は…

ようやく動き出したと思ったら、サイトが完全に保護されていないとかいう表示。
こんなのはじめて。

httpで書かれたリンクがある、ということらしい。
見てみると、インストール中に登録したサイトロゴとアイコンが問題になっているようだった。

そこで、一旦サイトロゴを削除してみたけれども、変化なし。

設定→セキュリティで force https をチェックしたところ、安全な接続になった。

その上で、設定→Brandingで logo と large icon を再度設定したところで安全な接続となった。

NGINXのステータスが確認できない

秘密鍵と証明書を配置し、NGINXの設定ファイルを変更したところで起動できるようにはなったんだけれど、systemctlコマンドでNGINXのステータスが確認できない。

launcher app enter 後の環境

# systemctl status nginx
System has not been booted with systemd as init system (PID 1). Can't operate.
Failed to connect to bus: Host is down

# ps u -C nginx
USER        PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root      27984  0.0  0.3  55184  7504 ?        S    00:50   0:00 nginx: master process /usr/sbin/nginx
www-data  27985  0.0  0.3  56448  7480 ?        S    00:50   0:00 nginx: worker process
www-data  27986  0.0  0.1  55848  3724 ?        S    00:50   0:00 nginx: worker process
www-data  27987  0.0  0.1  55648  3780 ?        S    00:50   0:00 nginx: cache manager process

ホストの環境

# systemctl status nginx
Unit nginx.service could not be found.

# ps u -C nginx
USER        PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root      49908  0.0  0.3  55184  7504 ?        S    09:50   0:00 nginx: master process /usr/sbin/nginx
www-data  49909  0.0  0.3  56448  7480 ?        S    09:50   0:00 nginx: worker process
www-data  49910  0.0  0.1  55848  3724 ?        S    09:50   0:00 nginx: worker process
www-data  49911  0.0  0.1  55648  3780 ?        S    09:50   0:00 nginx: cache manager process

せいぜいこんなところ。

ポートとディレクトリを変更(やめておいた方が無難)

ポートとディレクトリの変更まではできた。しかし、Proxyで動作させることができなかった。
結果としてはCSRFの問題が発生して挫折。不思議と、シークレットモードだとログインできるが、通常モードのブラウザでアクセスできない。

ただしこれは、実装できるかもしれないけれども、問題が発生するかもしれないと開発サイドが言っている。
Discourse / How to specify a different port (not 80) during installation?
※見た感じ、問題が明確に分かっているわけではなく、保証できないよということなのかなという感じ。正式サービス公開するなら使わない方が安心だけど、製品比較をやってるような段階なら行けるかなと思った。

ここでは、forumというサブディレクトリに移動してみようと思う。
Discourse / Subfolder support with Docker

また、サービス提供するポートを10080(HTTP)、10443(HTTPS)として、ApacheでProxyする。
Discourse / Install Discourse, change docker port 80

ApacheによるProxyは後日成功。2020/06/19追記

/opt/discourse/containers/app.yml

…
expose:
  "10080:80"   # http
  "10443:443"  # https

…
env:
…
  ## Sub directory
  DISCOURSE_RELATIVE_URL_ROOT: /forum
…

run:
  - exec: echo "Beginning of custom commands"
  ## If you want to set the 'From' email address for your first registration, uncomment and change:
  ## After getting the first signup email, re-comment the line. It only needs to run once.
  #- exec: rails r "SiteSetting.notification_email='info@unconfigured.discourse.org'"

  - exec:
      cd: $home
      cmd:
        - mkdir -p public/forum
        - cd public/forum && ln -s ../uploads && ln -s ../backups
  - replace:
     global: true
     filename: /etc/nginx/conf.d/discourse.conf
     from: proxy_pass http://discourse;
     to: |
        rewrite ^/(.*)$ /forum/$1 break;
        proxy_pass http://discourse;
  - replace:
     filename: /etc/nginx/conf.d/discourse.conf
     from: etag off;
     to: |
        etag off;
        location /forum {
           rewrite ^/forum/?(.*)$ /$1;
        }
  - replace:
       filename: /etc/nginx/conf.d/discourse.conf
       from: $proxy_add_x_forwarded_for
       to: $http_your_original_ip_header
       global: true

  - exec: echo "End of custom commands"

設定を変更したので再構築。そして、一部アップロード済みのコンテンツを書き換える。

$ sudo su -
# cd /opt/discourse
# ./launcher rebuild app

ここでコンテナの中に入る。

# ./launcher enter app
root@temp-app:/var/www/discourse# RAILS_ENV=production bundle exec discourse remap '/uploads' '/forum/uploads'
Rewriting all occurences of /uploads to /forum/uploads
THIS TASK WILL REWRITE DATA, ARE YOU SURE (type YES)
YES
Warning: no type cast defined for type "name" with oid 19. Please cast this type explicitly to TEXT to be safe for future changes.
optimized_images=66
uploads=5
user_auth_token_logs=1
user_histories=6
Done

root@temp-app:/var/www/discourse# RAILS_ENV=production bundle exec discourse remap '/user_avatar/temp.hogeserver.hogeddns.jp' '/forum/user_avatar/temp.hogeserver.hogeddns.jp'
同じようにYESとタイプ。コピペ実行するときにはサイト名に注意!

root@temp-app:/var/www/discourse# RAILS_ENV=production bundle exec discourse remap '/images' '/forum/images'
YESとタイプして実行

root@temp-app:/var/www/discourse# RAILS_ENV=production bundle exec discourse remap '/plugins' '/forum/plugins'
YESとタイプして実行

※コンテナに入った後の操作は、再構築のたびにやり直が必要になる。

LDAP認証のモジュールがサブディレクトリに対応していないので、以下で示されているパッチを当てる。
Github / omniauth / omniauth-ldap / changing callback_path to callback_url to account for relative root url

/var/www/discourse/plugins/discourse-ldap-auth/gems/2.6.6/gems/omniauth-ldap-1.0.5/lib/omniauth/strategies/ldap.rb

…
      def request_phase
        OmniAuth::LDAP::Adaptor.validate @options
        f = OmniAuth::Form.new(:title => (options[:title] || "LDAP Authentication"), :url => callback_url)
        f.text_field 'Login', 'username'
        f.password_field 'Password', 'password'
        f.button "Sign In"
        f.to_response
      end
…

※callback_pathとなっているところを、callback_urlに置き換える。
※この操作は再構築のたびに必要になる。

この後色々とApacheで設定してみたけれど、どうしてもProxyできなかった。実力不足。

ログのある場所 2020/07/23追記

ログはどこに?と思って探したらここに情報があった。
Discourse / Where does Discourse store and show logs?

Discourseにログインしたあとであれば、http(s)://temp.hogeserver.hogeddns.jp/logs でログを見ることができる。
Dockerに入って探さなくても分かったりすることがあって、楽かもしれない。

さいごに

これは凄くよくできたシステムだと思うんだけれど、まだ国内では注目されていないのかな。

会社でTeamsを使い始めているけれど、Q&Aシステムとして使おうとすると一番弱いのが検索だと思う。このシステムならかなりノウハウが残せるんじゃないだろうか。

広告

コメントはこちらから お気軽にどうぞ ~ 投稿に関するご意見・感想・他