カテゴリー: Linux Page 32 of 46

Nextcloudのバージョンアップ。

WordPressと変わらない操作感でバージョンアップを行うことができました。

操作手順

NextcloudのWeb画面にログインし、「Administration settings」をクリックします。

更新できることを確認します。

アップデーターを開きます。

「アップデーターを開く」をクリックします。

アップデートを開始します。

「Start update」をクリックします。

どの段階まで進んだかを示してくれる親切設計でした。(写真を大量に保管しているのでバックアップ作成はかなりの時間がかかりました)

メンテナンスモードを解除します。

「Disable maintenance mode and continue in the web based updater」をクリックします。

「アップデートを開始」をクリックします。

何も問題がなければ、Nextcloudの管理者にログインされた状態でページが切り替わります。

アップデート後の後処理を行います。

アップデート対象に「Themes」が含まれていたので、背景が真っ白になっていました。これを修正するため再び「Administation settings」に進み、テーマをクリックします。

Background and login imageをクリックして任意の画像に置き換えます。

この後、「概要」をクリックすることで

「最新版です」となっていることを確認しました。

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.

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

mod_securityで検知したIPの自動遮断。

ここから更に改良を加えました。

やりたいこと

  • 上記抜き出したIPアドレスのリストを日々統合する。
  • 自動的にmod_securityのnegativeリストに入れる。
  • その上で普段アクセスしているIPアドレスを除外して偽陽性から逃れる。

前提

以下を導入済みです。

  • Mod_security
  • Apache 2.4.1
  • Redmine 4.2
  • ログの格納先は /var/lib/redmine/log/

手順

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

ログを格納するディレクトリを作成します。

mkdir /var/lib/redmine/log/suspicious_ip

自動実行するスクリプトを作成します。

cd /hoge/
vi negativelist_add.sh
スクリプト内容
#!/bin/sh

SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

cd /var/lib/redmine/log
cat error.log | awk 'match($0,/[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+/) { print  substr($0, RSTART, RLENGTH) }' | sort | uniq > /var/lib/redmine/log/suspicious_ip/suspicious_ip.`date +%Y%m%d`
chown www-data:www-data /var/lib/redmine/log/suspicious_ip/suspicious_ip.`date +%Y%m%d`
cat /var/lib/redmine/log/suspicious_ip/suspicious_ip.2* |sort |uniq > /var/lib/redmine/log/suspicious_ip_all.txt
cat suspicious_ip_all.txt > /etc/apache2/sites-available/negativelist.txt
chown www-data:www-data suspicious_ip_all.txt
sed -i  /除外したいIPアドレス/d /etc/apache2/sites-available/negativelist.txt

スクリプトに実行権限を設定します。

chmod +x negativelist_add.sh

Apacheの設定ファイルを編集します。

ここでは/etc/apache2/sites-available/redmine-le-ssl.conf にコンフィグを作成済みです。

cd /etc/apache2/sites-available
cp -pi redmine-le-ssl.conf redmine-le-ssl.conf.bak
vi redmine-le-ssl.conf
設定ファイル内容
<VirtualHost _default_:80>
servername [redmineのドメイン名]
 RewriteEngine On
        RewriteCond %{HTTPS} off
        RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
</VirtualHost>
<VirtualHost _default_:443>
servername [redmineのドメイン名]
CustomLog /var/log/redmine/access.log combined
ErrorLog /var/log/redmine/error.log
Alias /redmine /var/lib/redmine/public

# Mod Security
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'"

# /etc/apache2/sites-available/negativelist.txt に記載されたIPアドレスを自動的に遮断します。

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

  SSLEngine on
    Protocols h2 http/1.1
    Header always set Strict-Transport-Security "max-age=63072000"


SSLCertificateFile [let's encryptが指定した証明書ファイルのパス]
SSLCertificateKeyFile [let's encryptが指定した秘密鍵ファイルのパス]

#Include /etc/letsencrypt/options-ssl-apache.conf

        RewriteEngine On
        RewriteCond %{HTTP_HOST} ^samplehoge\.hogehoge
        RewriteRule ^/$ https://samplehoge.hogehoge/redmine/ [R]

</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)"

設定を反映します。

apache2ctl configtest
# Syntax OKを確認します
systemctl restart apache2

crontabで自動実行できるようにします。

crontab -e

追記内容

0 8 * * * /hoge/negativelist.sh

これで、以下の動きができるようになります。

  • アクセスログ(エラーログ)に従ってIPアドレスの抜き出し
  • 重複を抜き出し、その日にアクセスされた不審なIPアドレスを記載する。
  • 蓄積されたIPアドレスを全て統合。重複を抜き出しネガティブリストに上書きする。
  • そこから普段アクセスしているIPアドレスを削除する。

Nectcloud recognizeアプリ導入後のOPcacheの設定。

発生した事象

Nextcloudにアップロードされた画像をタグ付けしてくれる「recognize」アプリを使っています。

それを用いて運用したところ、以下のエラーに出くわしました。

発生画面

メニュー > Administration settings > 概要

  • PHP OPcacheモジュールが正しく設定されていません。詳細はドキュメントを参照してください。
    • 「OPcacheのインターン文字列バッファーがまもなく一杯になります。全てのスクリプトをキャッシュに保管できるようにするには、opcahe,interned_strings_bufferの値を8より多い値で、PHP設定に適用することを推奨します。

これを放置していったところ、Webサービスが止まり、SSHにも接続できなくなりました。そのため、以下の対処を施しました。

前提:環境

以下の環境で動いています。

  • Ubuntu 20.04
  • Apache 2.4.54
  • PHP 7.4.32

※snapは使わず、オンプレで構築しました。

また、Opcacheモジュールは設定済みです。

対処

以下、管理者権限で実施しています。

mkdir /etc/old
cd /etc/php/7.4/mods-available
cp -pi opcache.ini /etc/old/opcache.ini.`date +%Y%m%d`
vi opcache.ini
設定内容
opcache.interned_strings_buffer=16
; 8 → 16に修正

設定反映

apache2ctl configtest
# Syntax OK を確認します
systemctl restart apache2

反映確認

メニュー > Administration settings > 概要

へと進みます。

「全てのチェックに合格しました。」

を確認します。

余談:recognizeアプリの注意点

万単位のファイルを既にインポートしたため、画像認識とタグ付けのためにかなりのCPUリソースを消費します。(平均オーバーロードが7を超えるときもありました)
そのため、zabbix等で負荷を監視している場合は認識中は閾値を上げておく等の対処が必要です。

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
# ファイルがないこと

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

Page 32 of 46

Powered by WordPress & Theme by Anders Norén