タグ: Linux Page 19 of 24

Elasticsearchバージョンアップ後、サービス起動せず全文検索できない件について

前提

Linux Mint 20.3でGrowiを運用しています。

現象

aptによるアップデート後、Growiで全文検索ができない現象が発生しました。

状況把握

[root@chisato.lyco.reco ~]# systemctl status elasticsearch.service 
● elasticsearch.service - Elasticsearch
     Loaded: loaded (/lib/systemd/system/elasticsearch.service; enabled; vendor preset: enabled)
     Active: failed (Result: exit-code) since Sun 2022-10-30 19:06:41 JST; 1 day 1h ago
       Docs: https://www.elastic.co
    Process: 983 ExecStart=/usr/share/elasticsearch/bin/systemd-entrypoint -p ${PID_DIR}/elasticsearch.pid --quiet (code=exited, status=1/FAILURE)
   Main PID: 983 (code=exited, status=1/FAILURE)

10月 30 19:06:41 chisato.lyco.reco systemd-entrypoint[983]:         at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.<init>(ThreadPoolExecutor.java:637)
10月 30 19:06:41 chisato.lyco.reco systemd-entrypoint[983]:         at java.base/java.util.concurrent.ThreadPoolExecutor.addWorker(ThreadPoolExecutor.java:928)
10月 30 19:06:41 chisato.lyco.reco systemd-entrypoint[983]:         at java.base/java.util.concurrent.ThreadPoolExecutor.processWorkerExit(ThreadPoolExecutor.java>
10月 30 19:06:41 chisato.lyco.reco systemd-entrypoint[983]:         at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1158)
10月 30 19:06:41 chisato.lyco.reco systemd-entrypoint[983]:         at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642)
10月 30 19:06:41 chisato.lyco.reco systemd-entrypoint[983]:         at java.base/java.lang.Thread.run(Thread.java:1589)
10月 30 19:06:41 chisato.lyco.reco systemd-entrypoint[983]:         at java.base/jdk.internal.misc.InnocuousThread.run(InnocuousThread.java:186)
10月 30 19:06:41 chisato.lyco.reco systemd[1]: elasticsearch.service: Main process exited, code=exited, status=1/FAILURE
10月 30 19:06:41 chisato.lyco.reco systemd[1]: elasticsearch.service: Failed with result 'exit-code'.
10月 30 19:06:41 chisato.lyco.reco systemd[1]: Failed to start Elasticsearch.

→ この後、

systemctl restart elasticsearch.service 

を行っても起動しません。この事象を解決したときのメモです。

原因調査

cat /var/log/elasticsearch/elasticsearch.log 
(中略)
java.lang.IllegalArgumentException: Plugin [analysis-icu] was built for Elasticsearch version 7.17.6 but version 7.17.7 is running

を発見しました。ElasticSearchをバージョンアップしたのに、動いてるプラグインが対応しきれなかったためエラーになったようです。

対処

以下のコマンドを実行しました。

/usr/share/elasticsearch/bin/elasticsearch-plugin remove analysis-icu
/usr/share/elasticsearch/bin/elasticsearch-plugin install analysis-icu
/usr/share/elasticsearch/bin/elasticsearch-plugin remove analysis-kuromoji
/usr/share/elasticsearch/bin/elasticsearch-plugin install analysis-kuromoji
# 問題を起こしているプラグインの削除→再インストールを実施

systemctl restart elasticsearch.service

対処確認

 systemctl status elasticsearch.service 
● elasticsearch.service - Elasticsearch
     Loaded: loaded (/lib/systemd/system/elasticsearch.service; enabled; vendor preset: enabled)
     Active: active (running) since Mon 2022-10-31 21:23:02 JST; 23s ago
       Docs: https://www.elastic.co
   Main PID: 5424 (java)
      Tasks: 94 (limit: 9199)
     Memory: 768.5M
     CGroup: /system.slice/elasticsearch.service
             ├─5424 /usr/share/elasticsearch/jdk/bin/java -Xshare:auto -Des.networkaddress.cache.ttl=60 -Des.networkaddress.cache.negative.ttl=10 -XX:+AlwaysPreTouch -Xss1m -Djava.awt.headless=true -Dfile.encoding=UTF-8 -Djna.nosys=true>
             └─5617 /usr/share/elasticsearch/modules/x-pack-ml/platform/linux-x86_64/bin/controller

10月 31 21:22:38 chisato.lyco.reco systemd[1]: Starting Elasticsearch...
10月 31 21:23:02 chisato.lyco.reco systemd[1]: Started Elasticsearch.

で、正常に起動したことを確認できました。

Ubuntu 20.04にNextcloudをインストール。

Dropboxのようにファイルを保存できて、各種アプリ(プラグイン)で様々な機能を拡張できるOSS、Nextcloudをインストールしました。

このエントリーで行うこと

  1. nextcloud用のphpモジュールを入れる
  2. nextcloudに即したデータベースを入れる
  3. apache設定ファイルを作成する
  4. 設定反映を行い、初期画面を出す。

インストールしたハードウェア

この、2台目のChuwi Herobox Proです。redmineのデータ同期サーバのデータをマウントするために選びました。

前提

以下が導入済みです。

  • Ubuntu 20.04
  • Apache 2.4 (2.4.41)
  • mysql 80 (8.0.30)
  • php 7.4 (7.4.32)
  • nextcloud用のドメインを設定していること
  • サーバ証明書 (Let's Encryptワイルドカードを用いました)

手順

全て管理者権限で実施しました。

phpの追加モジュールをインストールします。

sudo apt install php7.4-{opcache,pdo,bcmath,calendar,ctype,fileinfo,ftp,gd,intl,json,ldap,mbstring,mysqli,posix,readline,sockets,bz2,tokenizer,zip,curl,iconv,phar,xml}

systemctl restart apache2

データベースを作成します。

mysql -u root -p
CREATE USER 'nextcloud'@'localhost' IDENTIFIED BY 'パスワード';
CREATE DATABASE IF NOT EXISTS nextcloud CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;
GRANT ALL PRIVILEGES ON nextcloud.* TO 'nextcloud'@'localhost';
FLUSH PRIVILEGES;

ファイルをダウンロードして配置します。

導入したサーバは/homeディレクトリを別SSDにマウントしているため、以下のようにしました。

wget https://download.nextcloud.com/server/releases/latest.zip
unzip latest.zip /home/www-data
chown -R www-data:www-data /home/www-data/nextcloud

設定ファイルを作成します。

mkdir /var/log/apache2/nextcloud
chown -R www-data:www-data /var/log/apache2/nextcloud
vi /etc/apache2/sites-available/nextcloud.conf

設定ファイルの内容

<VirtualHost _default_:80>
 ServerName [公開するドメイン名]
 RewriteEngine On
        RewriteCond %{HTTPS} off
        RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
 CustomLog /var/log/apache2/nextcloud/access.log combined
 ErrorLog /var/log/apache2/nextcloud/error.log
</VirtualHost>

<VirtualHost _default_:443>
 ServerName [公開するドメイン名]
 CustomLog /var/log/apache2/nextcloud/ssl_access.log combined
 ErrorLog /var/log/apache2/nextcloud/ssl_error.log
  SSLEngine on
  Header always set Strict-Transport-Security "max-age=15552000; includeSubDomains"
    SSLProtocol All -SSLv2 -SSLv3  -TLSv1
     SSLCipherSuite ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA
    SSLCertificateFile /etc/certs/ssl.crt
    # 証明書のファイルパス
    SSLCertificateKeyFile /etc/private/ssl.key
    # 秘密鍵のファイルパス

    DocumentRoot /home/www-data/nextcloud
    <Directory /home/www-data/nextcloud>
        Options Indexes FollowSymLinks MultiViews
        AllowOverride All
        Require all granted
    </Directory>

</VirtualHost>

設定を反映します。

a2ensite nextcloud.conf
apache2ctl configtest
# Syntax ok を確認します
systemctl restart apache2

起動確認

ブラウザから設定したドメインにアクセスします。

アクセス後、ガイドに従い

  • 管理者アカウント
  • パスワード
  • データベース情報

を設定後、以下の画面が出てくれば成功です。

PHPの再インストール。(混在環境の改善)

こちらの続きです。

  • システム内にPHP 7.4と8.1が混在
  • 一部をアップグレード対応しても満足に動かない

パターンがあったので、完全削除を対応しました。

手順

PHPの完全削除

apt-get --purge autoremove php*

これにより、設定ファイルを含めてPHPが削除されました。

PHP7.4インストール

add-apt-repository ppa:ondrej/php
aptitude update
aptitude upgrade

apt install php7.4

apt install php7.4-{opcache,pdo,bcmath,calendar,ctype,fileinfo,ftp,gd,intl,json,ldap,mbstring,mysqli,posix,readline,sockets,bz2,tokenizer,zip,curl,iconv,phar,xml}


設定反映

systemctl restart apache2

その後、正常に上がっていることを確認。

[--purge]オプションで完全に削除するのを失念していました。

AWS LightsailとLet’s Encryptによるワイルドカード証明書発行。

ひょんな事から無料でドメインを取得。このドメインを軸に「mkcertではなくLet's Encryptでもワイルドカード証明書が発行できないか」と思って試してみました。

やりたいこと

  • せっかく手に入れたドメインなので、自宅でそれを用いる。
  • mkcertを用いている自宅内サーバのgrowiをLet's Encryptに差し替える。

前提

以下は準備済みです。

  • AWS Lightsailで運用しているUbuntu 20系サーバがある
  • ドメインを取得している
  • certbotを運用している

手順

作業対象が手順によって異なります。

手順 -1- ドメイン設定

  1. lightsailのDNS設定で取得したドメインを有効にします。
  2. お名前.comのDNSサーバの向き先をlightsailのものに設定します。
  3. lightsailのAレコードに「自分が運用しているローカルサーバのIPと適当な名前」を設定して紐付けます。

手順 -2- ワイルドカード証明書発行コマンド入力 (lightsail側サーバ)

sudo certbot certonly --manual \
    --preferred-challenges dns-01 \
    --server https://acme-v02.api.letsencrypt.org/directory \
    -m 自分のメールアドレス \
    -d *.ドメイン名

入力後、以下のようにTXTレコードを登録するように求められます。

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Please deploy a DNS TXT record under the name
_acme-challenge.ドメイン名 with the following value:

DNSに登録するレコードの値

Before continuing, verify the record is deployed.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Press Enter to Continue

ここではまだEnterは押しません。

手順 -3- TXTレコード追加 (AWS Lightsail管理画面)

lightsailのDNS設定で

  • TXTのレコード
  • サブドメイン:_acme-challenge
  • 「以下で応答します」にDNSに登録するレコードの値

をそれぞれ設定して反映させます。

反映後、別のターミナルで以下を実行します。

nslookup -type=TXT _acme-challenge.登録したドメイン名 8.8.8.8

結果が返ってきたら次のステップに進みます。

手順 -4- ワイルドカード証明書発行 (lightsail側サーバ)

手順-2-で押していなかったEnterを押します。

以下のようにパスとファイルが明示されているので、そのパスの内容を控えておきます。(外部に公開しないよう注意します)

IMPORTANT NOTES:
 - Congratulations! Your certificate and chain have been saved at:
   /etc/letsencrypt/live/ドメイン名/fullchain.pem
   Your key file has been saved at:
   /etc/letsencrypt/live/ドメイン名/privkey.pem
   Your certificate will expire on 2023-01-09. To obtain a new or
   tweaked version of this certificate in the future, simply run
   certbot again. To non-interactively renew *all* of your
   certificates, run "certbot renew"

hostsファイル書き換え(growiサーバ側)

/etc/hostsファイルを

IPアドレス lightsailで設定したフルドメイン サブドメイン

で修正します。

証明書差し替え

こちらを元に、証明書を差し替えます。

動作確認

証明書差し替え → nginx再起動後、「AWS Lightsailで設定したドメイン名」でアクセスします。

DNS情報がインターネット上に公開されているので

  • 同じNWにつながっていれば、DNSを明示していなくともアクセスできる
  • mkcertのように端末に証明書をインポートせずに済む

のがLet's Encrypのいいところです。

growiサーバのログローテーション。

この記事で設定していたgrowiサーバ、ログの設定が漏れていたので追加しました。

手順

すべて管理者権限で実施しています。

ローテート設定追加

vi /etc/logrotate.d/growi

 ファイル内容

/var/log/nginx/chisataki.lyco.reco/*.log {
    daily
    rotate 10
    missingok
    notifempty
    sharedscripts
    compress
    delaycompress
    postrotate
        /usr/sbin/nginx -s reopen >/dev/null 2>&1 || true
    endscript
}

今回は

  • 日毎にログを取る
  • ローカルなので保存期間は10日

としています。

動作確認

logrotate -d /etc/logrotate.d/growi

でエラーが出ないことを確認しました。

nginxとapache連携。(リバースプロキシー&SSLアクセラレータ)

自室のサーバに専用redmineを運用するようになって半年ほど。一つの課題が浮かび上がりました。

課題

現状、

  • redmine
  • フォトアルバム
  • growi

を自宅サーバ群で運用中。Webサービスが増えるたびに「証明書更新をサーバ毎に行うのが面倒」です。ワイルドカード証明書を用いて、シンボリックリンクの張り替えで済むようにしてもなお各サーバに同じ設定を行うのは手間がかかる上にミスが生じる温床となります。

施策

そこで、既にgrowiサーバで運用しているnginxのリバースプロキシーをredmineにも拡張するようにしました。

やりたいことは以下です。(IPアドレスとドメインは便宜上です)

sequenceDiagram participant クライアント participant nginx as nginxサーバ<br> 192.168.1.30<br>abc .local participant redmine as redmine<br> 192.168.1.99<br>xyz.local クライアント->> nginx: abc.localにhttpアクセス par クライアント~nginxはhttps通信 note over nginx: httpsにリライト nginx -->> クライアント: httpsでの接続要求 and nginx~redmineはhttp通信 クライアント ->> nginx: redmineにhttpsアクセス note over nginx: SSLデコード nginx -->>+ redmine: クライアントからの要求を<br>redmine(xyz.local)に送信 redmine -->>- nginx: redmineのデータを送信 end nginx ->> クライアント:redmineからのデータを<br>abc.localとしてhttpsで送信

サクッとまとめると

  • redmineサーバのリバースプロキシーとしてnginxを利用
  • クライアント~nginxは常時SSL通信
  • nginx ~ redmineはhttp通信

これにより、SSLを導入する箇所をnginxサーバのみとします。

前提

以下を用意しています。

  1. nginxサーバ (仮IP: 192.168.1.30)
  • mkcertでローカル証明書を導入済み
  1. redmineサーバ(apacheで稼働)(仮IP: 192.168.1.99)
  2. ローカルDNSに以下を登録します。(自分の環境に読み替えます)
  3. abc.local - 192.168.1.30
  4. xyz.local - 192.168.1.99

環境

ともにUbuntu Linux 20.04系で動いています。

手順

全て管理者権限で実施します

redmineサーバでの設定(apache)

以下、ファイルを編集します。

vi /etc/apache2/sites-available/redmine.conf
ファイル内容
<Location /redmine>
PassengerBaseURI /redmine
PassengerAppRoot /var/lib/redmine
Require all granted
</Location>

Alias /redmine /var/lib/redmine/public

<VirtualHost 192.168.1.99:80>
    ServerName  abc.local
    ErrorLog /var/log/redmine/error.log
    CustomLog /var/log/redmine/access.log combined

        RewriteEngine On
        RewriteCond %{HTTP_HOST} ^abc\.local
        RewriteRule ^/$ http://abc.local/redmine/ [R]
</VirtualHost>

設定反映

a2ensite redmine.conf
apache2ctl configtest
#Syntax OKを確認
systemctl restart apache2

nginxサーバでの設定

hostsファイル追記

vi /etc/hosts
追記内容
192.168.1.30 abc.local

nginx confファイル作成

vi /etc/nginx/sites-available/redmine.conf
ファイル内容
upstream abc {
       server 192.168.1.99:80;
}

server {
        listen 80;
        server_name abc.local;
        server_tokens off;
        return  301 https://$host$request_uri;
        access_log /var/log/nginx/redmine/access.log;
        error_log /var/log/nginx/redmine/error.log warn;
}

server {
        listen 443 ssl http2;
        server_name abc.local;
        server_tokens off;
        ssl_session_timeout 1d;
        ssl_session_cache shared:SSL:50m;
        ssl_session_tickets off;
        ssl_dhparam /etc/nginx/dhparam.pem;
    #openssl dhparam -out /etc/nginx/dhparam.pem 2048 として作成します(環境によっては5分以上かかります)
        ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384;
        ssl_prefer_server_ciphers off;
        add_header Strict-Transport-Security 'max-age=63072000';

        ssl_certificate /etc/certs/local.crt;
       # 証明書のパスに読み替えます
        ssl_certificate_key /etc/private/local.key;
      # 秘密鍵のパスに読み替えます

        access_log /var/log/nginx/redmine/ssl_access.log;
        error_log /var/log/nginx/redmine/ssl_error.log warn;

        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-Host $host;
        proxy_set_header X-Forwarded-Server $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto https;
        proxy_max_temp_file_size 10240m;
        client_max_body_size 10240m;
        proxy_buffer_size 10240m;
        proxy_buffers 10 10240m;
        proxy_busy_buffers_size 10240m;
        proxy_redirect off;

       set $proxy_target  'abc';

       location / {
          proxy_pass http://$proxy_target;
       }
}

設定反映

ln -s /etc/nginx/sites-available/redmine.conf /etc/nginx/site-enabled/redmine.conf
nginx -t
# syntax is ok と test is successfulを確認します
systemctl restart nginx -t

確認

ローカルNWに接続されているクライアントのブラウザから

http://abc.local

にアクセスし、

  • https://abc.local/redmine の内容が出てくること
  • SSL通信ができていること

を確認します。

Ubuntuサーバで再起動が必要かを判断するコマンド。

apt(aptitude)でパッケージをインストール後、以下の判断に迷うことがあります。

  • サーバの再起動は必要なのか
  • サービスを再起動させる必要があるのか

これらをチェックするコマンドがありました。

コマンドインストール

sudo aptitude install debian-goodies update-notifier-common

再起動判断基準

カーネルなどのアップデートがされて、システム全体の再起動が必要な場合、以下のファイルが作成されます。

/var/run/reboot-required

cat /var/run/reboot-required
*** System restart required ***

また、サービスの再起動が必要な場合は、次のコマンドを実行してその判断が可能です。

sudo checkrestart

Found 27 processes using old versions of upgraded files
(14 distinct programs)
(10 distinct packages)

Of these, 9 seem to contain systemd service definitions or init scripts which can be used to restart them.
The following packages seem to have definitions that could be used
to restart their services:
accountsservice:
        441     /usr/lib/accountsservice/accounts-daemon
networkd-dispatcher:
        470     /usr/bin/networkd-dispatcher
policykit-1:
        471     /usr/lib/policykit-1/polkitd
rsyslog:
        473     /usr/sbin/rsyslogd
modemmanager:
        511     /usr/sbin/ModemManager
unattended-upgrades:
        567     /usr/share/unattended-upgrades/unattended-upgrade-shutdown
openssh-server:
        683     /usr/sbin/sshd
        246134  /usr/sbin/sshd
        246245  /usr/sbin/sshd
apache2-bin:
        15285   /usr/sbin/apache2
        238252  /usr/sbin/apache2
        238253  /usr/sbin/apache2
        238254  /usr/sbin/apache2
        238255  /usr/sbin/apache2
        238258  /usr/sbin/apache2
        238559  /usr/sbin/apache2
        238902  /usr/sbin/apache2
        244571  /usr/sbin/apache2
        244580  /usr/sbin/apache2
packagekit:
        246707  /usr/lib/packagekit/packagekitd

These are the systemd services:
systemctl restart accounts-daemon.service
systemctl restart networkd-dispatcher.service
systemctl restart polkit.service
systemctl restart ModemManager.service
systemctl restart packagekit-offline-update.service
systemctl restart packagekit.service

These are the initd scripts:
service rsyslog restart
service unattended-upgrades restart
service ssh restart
service apache2 restart

These processes (1) do not seem to have an associated init script to restart them:
passenger:
        238230  /usr/lib/passenger/support-binaries/PassengerAgent
        238235  /usr/lib/passenger/support-binaries/PassengerAgent

上記で再起動の必要性があったのでシステム全体を再起動。

sudo checkrestart
# Found 0 processes using old versions of upgraded filesと表示されること
cat /var/run/reboot-required
# ファイルがないこと

を確認し、システムを最新の状態に保ちました。

mkcertのエラーを解消。

ローカル環境でのSSL通信を可能にするmkcert。単純な設定ミスを見つけました。

発生した現象

Kaspersky Antivirusで「もうこうな証明書のSSL接続が検知されました」のエラーを検知。理由は「この証明書チェーンは不完全です」

というもの。

原因

  • nginxの設定
  • mkcertの証明書の内容

は問題なしでした。(そもそも、他のドメインで同じように作ったときにはこんなエラーを検知しませんでした)

そこで、どんなコマンドを打っていたかの履歴をたぐります。

mkcert -install

mkcert -key-file [証明書秘密鍵].key.YYYYMM -cert-file [証明書].crt.YYYYMM ドメイン 

とすべきところを、

mkcert -install

sudo mkcert -key-file [証明書秘密鍵].key.YYYYMM -cert-file [証明書].crt.YYYYMM ドメイン 

と、root権限を付けていたことが原因。

  • ローカル証明局:一般ユーザ
  • SSL証明書:root

だったため、齟齬を起こしていたという次第。

対処

  1. 「sudo」で作っていた証明書を削除。
  2. 再度、一般権限でmkcertでローカル証明書を作成。
  3. 証明書ファイル差し替え

により、冒頭で述べたエラーは消えました。

こちらで紹介した手順では、このエラーが発生しないように差し替え済みです。

新規インストールしたLinux Mint 20.03にgrowiをインストール。-3-

growiとnginxを連携させ、ポート番号をブラウザに入力することなくアクセスできるよう設定します。

前提

この作業を行う場合は、サーバ名とIPアドレスが名前解決できることが必須となります。

mkcertのインストール

sudo su -

curl -s https://api.github.com/repos/FiloSottile/mkcert/releases/latest | grep browser_download_url | grep linux-amd64 | cut -d '"' -f 4 | wget -qi - \
    && mv mkcert-v*-linux-amd64 mkcert \
    && chmod a+x mkcert \
    && mv mkcert /usr/local/bin/

exit

mkcert 認証局作成

mkcert -install

mkcert -CAROOT
# 指定通りの場所にあるかを確認します
# このディレクトリにある「rootCA.pem」はブラウザにインポートすることによって「信頼された情報局」であると示すことができます

mkcertでローカル証明書を作成

cd ~

mkcert -key-file [証明書秘密鍵].key.YYYYMM -cert-file [証明書].crt.YYYYMM ドメイン 
mkcert -key-file corn.wall.key.202204 -cert-file corn.wall.crt.202204 corn.wall penzance.corn.wall "*.corn.wall" 
# ワイルドカード証明書も作成できます

openssl x509 -text -noout -in ./corn.wall.crt.202204 |grep DNS
# DNSの蘭に登録した証明書のローカルドメイン名があることを確認します

ローカル証明書を格納

sudo mkdir /etc/certs

sudo cp -pi ./*.crt* /etc/certs/

sudo mkdir /etc/private

sudo cp -pi ./*.key* /etc/private/

ローカル証明書のシンボリックリンク化

mkcertsはあくまでもローカル環境での証明書を作成するツールなので、更新サイクルが3ヶ月程度となっています。
そこで、後のメンテナンスがしやすいようにシンボリックリンクを張ります。

実行例

cd /etc/certs/

ln -s corn.wall.crt.202204  corn.wall.crt

cd /etc/private/

ln -s corn.wall.key.202204 corn.wall.key

nginxインストール

sudo aptitude install nginx

リバースプロキシー化事前設定

sudo mkdir /etc/old

sudo cp -pi /etc/hosts /etc/old/hosts.`date +%Y%m%d`

sudo sed -i 's/127.0.1.1/127.0.0.1/g' /etc/hosts
# Ubuntu系はhost名のローカルアドレスを127.0.1.1と記載するので書き換えます
sudo openssl dhparam -out /etc/nginx/dhparam.pem 2048
# 環境によっては5分以上かかります

sudo mkdir /var/log/nginx/growi

sudo chown www-data:www-data /var/log/nginx/growi

nginx設定ファイル作成

※ コマンド実行の前に[ ]でくくった箇所を自分の環境に置き換えてください。

以下の順番で行うとやりやすいです。

  1. 以下のコマンド全行(cat - ~ 最下行のEOFまで)をコピーする
  2. 任意のテキストエディタに貼り付ける
  3. [ ]でくくった箇所を置き換えて編集する(このとき、[ ] も外します)
  4. 置き換えて編集したコマンド全行をコピー
  5. ターミナルに貼り付けて実行する
cat <<- 'EOF' | sudo tee -a /etc/nginx/sites-available/growi.conf
upstream [growiを公開するサブドメイン(e.g. growi)] {
       server [growiサーバのIPアドレス]:3000;
}

server {
        listen 80;
        server_name [公開するWebドメイン(e.g. growi.example.test)];
        server_tokens off;
        return  301 https://$host$request_uri;
        access_log /var/log/nginx/growi/access.log;
        error_log /var/log/nginx/growi/error.log warn;
}

server {
        listen 443 ssl http2;
        server_name [公開するWebドメイン(e.g. growi.example.test)];
        server_tokens off;
        ssl_session_timeout 1d;
        ssl_session_cache shared:SSL:50m;
        ssl_session_tickets off;
        ssl_dhparam /etc/nginx/dhparam.pem;
        ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384;
        ssl_prefer_server_ciphers off;
        add_header Strict-Transport-Security 'max-age=63072000';

        ssl_certificate [証明書が格納されているディレクトリ/証明書ファイル];
        ssl_certificate_key [秘密鍵が格納されているディレクトリ/秘密鍵ファイル];

        ssl_stapling on;
        ssl_stapling_verify on;
        # mkcert以外のきちんとした証明書を用いる時に使うオプションです

        access_log /var/log/nginx/growi/ssl_access.log;
        error_log /var/log/nginx/growi/ssl_error.log warn;

        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-Host $host;
        proxy_set_header X-Forwarded-Server $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto https;
        proxy_max_temp_file_size 10240m;
        client_max_body_size 10240m;
        proxy_redirect off;

       set $proxy_target  '[growiを公開するサブドメイン(upstreamの行で設定したもの)]';

       location / {
          proxy_pass http://$proxy_target;
       }

       location /socket.io/ {
          proxy_http_version 1.1;
          proxy_set_header Upgrade $http_upgrade;
          proxy_set_header Connection "Upgrade";
          proxy_cache_bypass $http_upgrade;
          proxy_pass http://$proxy_target/socket.io/;
       }
}
EOF

コンフィグファイルの有効化

cd /etc/nginx/sites-enabled
sudo unlink default
# nginxの基本設定を無効化します
sudo ln -s /etc/nginx/sites-available/growi.conf growi.conf
# 先ほど作成したコンフィグファイルを有効化します

起動確認

sudo nginx -t
# syntax is ok と test is successful を確認します

sudo systemctl restart nginx

sudo systemctl enable nginx

systemctl status nginx
# (runnning) と enabled を確認します

確認後、

http://[指定したドメイン名]

で、

  • Growiのログイン画面が見えること(:3000を付ける必要がないこと)
  • SSL通信(httpsにリダイレクトされること)を確認してください

新規インストールしたLinux Mint 20.03にgrowiをインストール。-2-

ここでは、インストールしたGrowiをサービス化して、サーバを再起動しても自動実行されるようにします。

起動スクリプト化

※ cat ~ EOFまで全行を実行します。

※ コマンド実行の前に[ ]でくくった箇所を自分の環境に置き換えてください。

以下の順番で行うとやりやすいです。

  1. 以下のコマンド全行(cat - ~ 最下行のEOFまで)をコピーする
  2. 任意のテキストエディタに貼り付ける
  3. [ ]でくくった箇所を置き換えて編集する(このとき、[ ] も外します)
  4. 置き換えて編集したコマンド全行をコピー
  5. ターミナルに貼り付けて実行する
cat <<- 'EOF' | sudo tee -a /var/growi/growi-start.sh
#!/bin/sh
cd /var/growi
NODE_ENV=production \
AUDIT_LOG_ENABLED=true \
FORCE_WIKI_MODE=private \
MONGO_URI=mongodb://localhost:27017/growi \
ELASTICSEARCH_URI=http://localhost:9200/growi \
REDIS_URI=redis://localhost:6379 \
PASSWORD_SEED=[ランダムな文字列を指定する] \
FILE_UPLOAD=local \
npm start
EOF

また、上記は筆者の環境に合わせています。不要な場合は削除ください。

  • AUDIT_LOG_ENABLED=true \
    • v5.1.10から実装された監査ログを有効化する機能
  • FORCE_WIKI_MODE=private \
    • 強制的に全てのページを非公開にする

起動スクリプトに実行権限を付与

sudo chmod +x /var/growi/growi-start.sh

ls -l /var/growi/growi-start.sh
# 実行権限がついていることを確認

サービスとして登録

cat <<- 'EOF' | sudo tee -a /etc/systemd/system/growi.service

[Unit]
Description = growi
After=network-online.target mongod.service
ConditionPathExists=/var/growi

[Service]
ExecStart=/var/growi/growi-start.sh
Restart=no
Type=simple

[Install]
WantedBy=multi-user.target

EOF

登録したサービスを有効化

sudo systemctl daemon-reload

sudo systemctl start growi.service

sudo systemctl enable growi.service

sudo systemctl status growi.service
# (running)とenabledを確認

起動確認

起動後(3分ぐらいかかります)、
http://[IPアドレス/dns登録名]:3000

にアクセスすることで、growiのログイン画面が出てきます。この段階で利用可能です。

次にご紹介するリバースプロキシー有効化などは、ローカル運用と割り切ってしまえば不要なオプション設定です。

Page 19 of 24

Powered by WordPress & Theme by Anders Norén