カテゴリー: PC Page 33 of 50

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のログイン画面が出てきます。この段階で利用可能です。

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

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

コンテナ環境だともっと楽なのでしょうけれど、きちっとオンプレで運用したいので、こういう方法をとりました。

前提

  • インストールするサーバはUbuntu 20系のLinux Mint 20.03を用います。(22系はMongoDBで詰まりました)
  • 他にWebサーバを稼働していないサーバにて実施しています。
  • ローカルNW内で運用するため、サーバのセキュリティ設定は低くなっています。
  • インストールするディレクトリは「/var/growi」とします。
  • ここではあくまでもインストールと起動確認を行うまでです。
  • エディタによる編集は極力使わず、コマンドのコピー&ペーストで完結するようにしています。
  • ここではインストールと動作確認にとどめます。

参考にしたURL

  • Ubuntu Server 20.04 LTSにGROWIをインストール

https://qiita.com/BigTree777/items/4a67d36c4111a1fb50e7

  • Ubuntu18.04にGrowiをインストール

https://qiita.com/hawk777/items/0916024c1bd7b24904ae

手順

別途、記載がない限りは

  • 1行空いているコマンドは、1行ずつ実行します。
  • 空白行がない一連のコマンドは全てをコピー&ペーストして実行します。

必要に応じて:aptitudeのインストール

sudo apt-get install aptitude
# 本項ではパッケージ管理にaptitudeを用いますので、導入されていない場合はインストール。
# ポリシーによりaptを用いる場合は読み替えてください。

事前準備 - nginx リポジトリの追加

sudo add-apt-repository ppa:ondrej/nginx
# これを先に実施しないと、mongodbのバージョン固定に失敗しました

Node.js/npm/yarnのインストール

cd ~

curl -sL https://deb.nodesource.com/setup_14.x -o nodesource_setup.sh

sudo bash nodesource_setup.sh

sudo aptitude install nodejs
Node.jsとnpmのインストール確認
node -v

npm -v
# インストールしたバージョンを確認

yarnのインストール

sudo npm install -g yarn

yarn -v
# インストールしたバージョンを確認

Elasticsearchのインストール

wget -qO - https://artifacts.elastic.co/GPG-KEY-elasticsearch | sudo gpg --dearmor -o /usr/share/keyrings/elasticsearch-keyring.gpg

sudo aptitude install apt-transport-https

echo "deb [signed-by=/usr/share/keyrings/elasticsearch-keyring.gpg] https://artifacts.elastic.co/packages/7.x/apt stable main" | sudo tee /etc/apt/sources.list.d/elastic-7.x.list

sudo aptitude update && sudo aptitude install elasticsearch

dpkg -l |grep elasticsearch
#インストールしたバージョンを確認
Elasticsearchに割り当てるメモリを調整
sudo mkdir /etc/elasticsearch/old
# 切り戻しができるように、設定ファイルのバックアップを格納するディレクトリを作ります

sudo cp -pi /etc/elasticsearch/jvm.options /etc/elasticsearch/old/jvm.options.`date +%Y%m%d`
# .`date +%Y%m%d`をつけることで、バックアップファイルは当日日付(YYYY/MM/DD形式)で記録されます

echo -e "-Xms256m\n-Xmx256m" | sudo tee -a /etc/elasticsearch/jvm.options
メモリ調整確認
sudo diff -u /etc/elasticsearch/old/jvm.options.`date +%Y%m%d` /etc/elasticsearch/jvm.options

diffの出力結果(差分)が以下であることを確認します。

+-Xms256m
+-Xmx256m
Elasticsearchの自動起動の有効化
sudo systemctl start elasticsearch

sudo systemctl enable elasticsearch

sudo systemctl status elasticsearch
# (running) と enabledを確認

Growiに必要なElasticsearchプラグインのインストール

sudo /usr/share/elasticsearch/bin/elasticsearch-plugin install analysis-kuromoji

sudo /usr/share/elasticsearch/bin/elasticsearch-plugin install analysis-icu

sudo systemctl restart elasticsearch

Redisのインストール

sudo add-apt-repository ppa:chris-lea/redis-server

sudo aptitude update && sudo aptitude install redis-server
インストール後の確認
redis-cli --version

redis-server --version
# インストールしたバージョンが表示されることを確認

sudo systemctl start redis-server

sudo systemctl enable redis-server

sudo systemctl status redis-server
# (running) と enabledを確認

MongoDBのインストール

wget -qO - https://www.mongodb.org/static/pgp/server-4.4.asc | sudo apt-key add -

echo "deb [ arch=amd64,arm64 ] https://repo.mongodb.org/apt/ubuntu focal/mongodb-org/4.4 multiverse" | sudo tee /etc/apt/sources.list.d/mongodb-org-4.4.list

sudo aptitude update && sudo aptitude install mongodb-org=4.4.13 mongodb-org-server=4.4.13 mongodb-org-shell=4.4.13 mongodb-org-mongos=4.4.13 mongodb-org-tools=4.4.13

MongoDBのバージョン固定

echo "mongodb-org hold" | sudo dpkg --set-selections

echo "mongodb-org-server hold" | sudo dpkg --set-selections

echo "mongodb-org-shell hold" | sudo dpkg --set-selections

echo "mongodb-org-mongos hold" | sudo dpkg --set-selections

echo "mongodb-org-tools hold" | sudo dpkg --set-selections
インストール後の確認
redis-cli --version

mongod --version
# インストールしたバージョンが表示されることを確認

sudo systemctl start mongod

sudo systemctl enable mongod

sudo systemctl status mongod
# (running) と enabledを確認

Growiのインストール

sudo aptitude install git build-essential

sudo git clone https://github.com/weseek/growi /var/growi

cd /var/growi

sudo git tag -l
# 2022/09/15での最新版は5.1.4

sudo git checkout -b v5.1.4 refs/tags/v5.1.4

sudo yarn

Growi起動確認

ここでは「PASSWORD_SEED」を「GOLDEN_SEED」と設定します。任意のランダム文字列を指定してください。

先頭のsudo から最終行のnpm startまで全てコピー&ペーストで実行します。

sudo \
NODE_ENV=production \
MONGO_URI=mongodb://localhost:27017/growi \
ELASTICSEARCH_URI=http://localhost:9200/growi \
REDIS_URI=redis://localhost:6379 \
PASSWORD_SEED=GOLDEN_SEED\
FILE_UPLOAD=local \
npm start

以下の表示が出たら起動は成功です。

> growi@(インストールしたバージョン) start /var/growi
> yarn app:server

ブラウザで

http://IPorホスト名:3000

に接続し、ログインページ表示を確認します。(ここではまだログインをしないでください)

ログインページ表示を確認後、[Ctrl]+[C]で抜けます。

これからの流れ

最終的に以下を行います。

  • mkcertによるSSL取得と常時SSL化
  • nginxによるリバースプロキシー
  • growiの起動スクリプト化

Configuration GeneratorによるSSL強度再設定。

AWS Lightsailで運用している「インターネット接続用redmine」。運用にあたり、SSLの強化を図るため

こちらにあるように強度チェッカーで検証しながら設定を行っていました。

ところが最近、このチェックが厳しくなったようで評価がAまで落ちます。

信頼度は高いと言えるものの余り気分がいいものではありません。そこで、再びA+となるように設定を行いました。

SSL Configuration Generator

https://ssl-config.mozilla.org/

mozillaが公式に提供しているこのサイト、

  • サーバプログラム
  • プログラムのバージョン
  • 強度

を設定するだけでサンプルコードを示してくれる優れもの。これを使い、こんな感じで設定しました。

設定ファイル

<VirtualHost _default_:80>
servername 公開するドメイン
 RewriteEngine On
        RewriteCond %{HTTPS} off
        RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
        # http通信をhttps通信にリダイレクト
</VirtualHost>
<VirtualHost _default_:443>
servername 公開するドメイン

CustomLog /var/log/redmine/access.log combined
ErrorLog /var/log/redmine/error.log
# redmineログ設定

SecRuleEngine On
## ModSecurity有効化
SecRequestBodyInMemoryLimit 524288000
SecRequestBodyLimit 524288000
## ファイルのアップロードをできるようにします。
SecRuleRemoveById 949110
SecRuleRemoveById 941310
SecRuleRemoveById 980130
SecRuleRemoveById 911100
SecRuleRemoveById 200002
SecRuleRemoveById 200003
SecRuleRemoveById 200004
SecRuleRemoveById 959100
## 上記を無効化しないとチケット更新時にエラーとなりました(偽陽性)ため、上記ルールを除外します。
    SecRule ARGS:modsecparam "@contains test" "id:4321,deny,status:403,msg:'ModSecurity test rule has triggered'"
## テスト用の検知パラメータを付け加えます。

## Negativelist
SecRule REMOTE_ADDR "@pmFromFile negativelist.txt" "phase:1,id:2,deny,msg:'Negativelisted IP address'"
## Mod_Securityが検知したIPアドレスをブロックします。

Alias /redmine /var/lib/redmine/public

<Location /redmine>
PassengerBaseURI /redmine
PassengerAppRoot /var/lib/redmine
Require all granted
<RequireAll>
    Require all granted
</RequireAll>
</Location>

## 上記はredmineの設定です

  SSLEngine on
    Protocols h2 http/1.1
    Header always set Strict-Transport-Security "max-age=63072000"
## SSLならびにHSTS有効化。

SSLCertificateFile /path/to/SSL/Certificate
SSLCertificateKeyFile /Path/to/SSL/Private/Key
## 証明書を格納します。

        RewriteEngine On
        RewriteCond %{HTTP_HOST} ^ドメイン名
        RewriteRule ^/$ https://ドメイン名/redmine/ [R]
        # ドメイン名でアクセスした際に/redmine/にリライトします。

</VirtualHost>

SSLProtocol             all -SSLv3 -TLSv1 -TLSv1.1
SSLCipherSuite          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
SSLHonorCipherOrder     off
SSLSessionTickets       off

SSLUseStapling On
SSLStaplingCache "shmcb:logs/ssl_stapling(32768)"
## Configuration Generatorで追加した設定。<virtualhost>ディレクティブの外に出す必要がありました。

こちらを修正してサービス再起動。

再起動後の強度チェック

再びA+を取り戻しました。

Ubuntu系Linuxの最初の設定。

検証にしろなんにしろ、最初に行っている作業のメモ書きです。

サーバ名をドメイン込みで再設定

hostnamectl set-hostname [サーバ名]
uname -n
# 指定したサーバ名が表示されることを確認

Ubuntu系Linuxは、ドメイン込みでサーバ名を登録してもフルネームで登録されません。ここで最初にサーバ名を確定させます。

~/.bashrc末尾に以下を追記

PS1="[\u@\H \W]\\$ "
HISTSIZE=50000

→ これにより、ユーザ名とホスト名のフルネームがプロンプトに表示されます。また、コマンド「history」で記憶させる上限を増やします。

/etc/bash.bachrcに以下を追記

export HISTTIMEFORMAT='%y/%m/%d %H:%M:%S '

→ これはほぼ必須です。コマンド「history」を実行したときの日時を指定することでその後の証跡が追いやすくなります。

Page 33 of 50

Powered by WordPress & Theme by Anders Norén