タグ: Linux Page 27 of 33

Redmineへの不正ログインをfail2banで制御する。

概要

インターネット環境にあるRedmineを不正ログインから防ぐため、不正ログイン対策パッケージfail2banと連携させました。

参考としたURL

https://www.redmine.org/projects/redmine/wiki/HowTo_Configure_Fail2ban_For_Redmine

環境

2023年1月現在、以下の環境で動かしています。

  • AWS Lightsailに立てているUbuntu20.04インスタンス

前提(導入済みパッケージ)

以下、既に導入済みです。

  • Redmine 4.2
  • fail2ban 0.11.1

本記事ではproduction.logの格納場所を

/var/log/redmine/production.log

としています。ご自身の環境に合わせてください。(通例は/var/lib/redmine/log の場合が多いです)

手順

さっくりとした手順

  1. fail2banの設定ファイルにredmine用の設定ファイルを作成します。
  2. jail.localファイルに上記設定ファイルを読み込ませます。(ファイルに追記します)
  3. fail2banサービスを再起動します。

稼働サービス(fail2ban)に修正を加えるので、必ずバックアップは取りましょう。

詳細手順

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

cat <<- __EOF__ | sudo tee -a /etc/fail2ban/filter.d/redmine.conf
# redmine configuration file
#
# Author: David Siewert
#
# $Revision$
#
[INCLUDES]

# Read common prefixes. If any customizations available -- read them from
# common.local
before = common.conf

[Definition]

datepattern = %%Y-%%m-%%d %%H:%%M:%%S %%Z$
failregex = Failed [-/\w]+ for .* from <HOST>

# Option:  ignoreregex
# Notes.:  regex to ignore. If this regex matches, the line is ignored.
# Values:  TEXT
#
ignoreregex =

# Source:
#http://www.fail2ban.org/wiki/index.php/MANUAL_0_8
__EOF__
作成確認
ls -l /etc/fail2ban/filter.d/redmine.conf
# rootユーザで上記ファイルが作成されていることを確認します。

jail.localファイルのバックアップを取ります。

sudo cp -pi /etc/fail2ban/jail.local /etc/old/jail.local.$(date +%Y%m%d)
# バックアップの格納ディレクトリは自分の環境に合わせます。

diff -u /etc/fail2ban/jail.local /etc/old/jail.local.$(date +%Y%m%d)
# バックアップ元とバックアップ先の差分が無いことでバックアップが取れていることを確認します。(何も返ってこなければ正常にバックアップできています)

jail.localファイルに追記を行います。

cat <<- __EOF__ | sudo tee -a /etc/fail2ban/jail.local

[redmine]
enabled  = true
filter   = redmine
port     = 80,443
#backend  = polling
# 動作がうまくいかない場合は上記「backend」をコメントアウトしてください。
action   = iptables-allports[name=redmine]
logpath  = /var/log/redmine/production.log
# production.logの格納位置です。ここは自分の環境に合わせます。
maxretry = 3
# ログイン試行に3回失敗した場合、アクセスを拒否します。
findtime = 86,400
# 1日アクセスを禁止します。
bantime  = 20
# ログイン試行の判定です
# トータルで「20秒の間、ログインに3回失敗したときに1日アクセスを禁止する」設定です
__EOF__

追記した内容の差分を確認します。

diff -u /etc/old/jail.local.$(date +%Y%m%d) /etc/fail2ban/jail.local
差分内容
+
+[redmine]
+enabled  = true
+filter   = redmine
+port     = 80,443
+#backend  = polling
+# 動作がうまくいかない場合は上記「backend」をコメントアウトしてください。
+action   = iptables-allports[name=redmine]
+logpath  = /var/log/redmine/production.log
+# production.logの格納位置です。ここは自分の環境に合わせます。
+maxretry = 3
+# ログイン試行に3回失敗した場合、アクセスを拒否します。
+findtime = 86,400
+# 判定失敗時、1日アクセスを禁止します。
+bantime  = 20
+# ログイン試行の判定です
+# トータルで「20秒の間、ログインに3回失敗したときに1日アクセスを禁止する」設定です。

設定ファイルの動作確認を行います。

まず、自分のredmineのログイン画面でわざとログインを失敗させます。

このとき、

cat /var/log/redmine/production.log |grep Failed
# production.logのパスは自分の環境に合わせます。

とすることで、

Failed login for 'ユーザ名' from IPアドレス at 2023-01-01 00:00:00 UTC

のように、失敗させたときのログが表示されます。

次に、

fail2ban-regex /var/log/redmine/production.log /etc/fail2ban/filter.d/redmine.conf
# production.logのパスは分の環境に合わせます。

を実行します。

Results
=======

Failregex: 1 total
|-  #) [# of hits] regular expression
|   1) [1] Failed [-/\w]+ for .* from <HOST>
`-

Ignoreregex: 0 total

Date template hits:
|- [# of hits] date format
|  [2] Year-Month-Day 24hour:Minute:Second Zone name$
`-

Lines: 4281 lines, 0 ignored, 1 matched, 4280 missed
[processed in 0.08 sec]

と、ログイン失敗時の行数分「X matched」と表示されます。これで、設定ファイルとログのパス設定に問題がないと確認が取れました。

設定を反映します。

sudo systemctl restart fail2ban.service

systemctl status fail2ban.service
#active (running)であることを確認します。

以上で、設定は完了です。

mod_securityが検知した不審なアクセスをufwで一括遮断。

あらまし

apacheにmod_securityを導入後、以下を実施しました。

  1. Mod_Securityが検知した不審なアクセスのうち、IPアドレスのみを抜き出す
  2. その抜き出したIPアドレスをMod_securityによってブロックする
  3. これを日次で追加していく

この方法はそこそこうまくいっています。ですが、「これら不審なアクセス元はWebだけでの攻撃だけか? メールやSSHへの攻撃もしているだろう」と思い立ち、不審なアクセスを元から絶つ方法を採りました。

環境

AWS Lightsailで以下を動かしています。

  • Ubuntu 20.04
  • いわゆるLAMP環境

前提

以下が準備済みです。

  • Mod_Security導入済み
  • 前述したmod_securityから不審なアクセス元のみを抜き出したIPアドレスのリストがある
    • このリストをnegativelist.txtとして用意しています。
リスト形式
192.168.0.1
192.168.1.123

のように、一行ずつIPアドレスだけが記述されているファイルです。

さっくりとした手順

  1. ufwを有効化します。
  2. 不審なアクセス元のIPアドレスのみを抜き出したnegativelist.txtを一行ずつ読み込みアクセスを遮断するシェルスクリプトを作成します。
  3. 作成したスクリプトを実行します。

実行の前の注意事項

  • 自環境のアクセスが遮断される可能性があることに注意してください。
  • 事前にスナップショットやバックアップを取り、失敗した時に備え切り戻しができる準備を強く推奨します
  • この方法によりアクセスができなくなった等に対し、筆者は責任を負いかねます。

手順

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

ufwがインストールされていることを確認します。(導入済みの場合はスキップ)

apt list ufw
#  [インストール済み] となっていることを確認します。

ufwを有効化します。(導入済みの場合はスキップ)

ufw enable

許可するサービスを指定します。(導入済みの場合はスキップ)

ufw limit ssh
# 連続したSSHアクセスを遮断します
ufw allow http
ufw allow https
# その他の許可するサービスは必要に応じて指定してください

この段階で、以下を確認します。

  • ターミナルクライアントからSSH接続ができること
  • 既存のサービスが外部NWからアクセスできること

サービス確認

ufw status
実行例
状態: アクティブ

To                         Action      From
--                         ------      ----
22                         LIMIT       Anywhere                  
80                         ALLOW       Anywhere                  
443                        ALLOW       Anywhere                  
22 (v6)                    LIMIT       Anywhere (v6)             
80 (v6)                    ALLOW       Anywhere (v6)             
443 (v6)                   ALLOW       Anywhere (v6)             

シェルスクリプトを作成します。

vi /hoge/add_ufw.sh
スクリプト内容
#!/bin/bash

# UFWを念のため事前に有効化します
ufw enable

# ファイルに書かれたIPアドレスを一行ずつ読み込みアクセスを遮断します。
while read line; do
    ufw deny from $line
# 読み込むファイルを指定します
done < /path/to/negativelist.txt

シェルスクリプトに実行権限を与えます。

chmod +x /hoge/add_ufw.sh

シェルスクリプトを実行します。

./hoge/add_ufw.sh
# 行数によっては相当な時間がかかります

実行後の確認を行います。

ufw status
実行例(抜粋)
Anywhere                   DENY        192.168.0.1              
Anywhere                   DENY        192.168.1.111              

まとめ

これで、「Webサイトに対して不審なアクセスを行ったIPをまるごと遮断する」ことが可能になりました。相当乱暴な方法ではあることにご注意ください。

AWS LightsailでのUbuntu20.04立ち上げとUbuntu22.04へのアップグレード。

概要

定額でAWSのインスタンスを利用できるLightsail。

Ubuntu系OSを利用できるものの、2022年12月時点ではUbuntu22.04に対応していません。

20.04は選べますので、

  1. Ubuntu20.04で新たなインスタンスを立ち上げる
  2. Ubuntu22.04にアップグレードする

方法を紹介します。

どハマりしたこと

結論を言うと、Ubuntu 22.04にアップグレードするとLigtsailの管理画面から直接SSHすることはできません。
(SSH-1アルゴリズムによるRSA認証が無効化されます)

つまり、 何も設定せずWeb画面のSSH接続で最初にアップグレードをすると、再起動した瞬間にログインできず詰みます。

これに気づかず、アップグレード後に全くログインできずインスタンスを作り直す羽目になりました。以下はメモとして残しておきます。

成功した手順(さっくりした手順)

以下、ある程度の知識がある方ならこの手順を行えば問題ないと思います。

  1. Lightsail上でUbuntu 20.04のインスタンスを立ち上げる。
  2. 静的IPを付与してIPを固定化する。
  3. 必要に応じてDNSレコードに登録する。
  1. Lightsail管理画面から初期ユーザーでログインする。
  2. 初期ユーザー以外のrootに昇格可能なユーザーを作成する。
  3. そのユーザーで強力な暗号による秘密鍵/公開鍵を設定する。
  4. Ubuntu 20.04 → 22.04にアップグレードする。

成功した手順(より詳細な記述)

インスタンスの作成

AWS Lightsailの管理画面にログインします。

https://lightsail.aws.amazon.com/ls/webapp/home/instances

「インスタンスの作成」をクリックします。

インスタンス作成

自分は以下のように選択しました。

  • リージョン:東京
  • インスタンスイメージの選択:Linux (OSのみ)
  • Ubuntu 20.04 LTSを選択。
  • 月次料金:10USD/月
  • インスタンス名:任意のもの
  • そのほかは空白

→設定後、「インスタンスの作成」をクリックします。
 → 作成後、「ネットワーキング」から静的IPを付与します。
  → 必要に応じてDNSを設定し、名前解決できるようにします。

管理画面のWebコンソール(SSH)操作

Web画面からログインし、rootに昇格します。

sudo su -
# この時、パスワードは設定されていないのでそのまま昇格できます。

ここから、ローカルのターミナルクライアントから接続できるようにユーザーを作成し、設定します。

ここではhogeとしていますので、任意のユーザーを指定して下さい。

adduser hoge
# パスワードなどを設定します

usermod -G sudo hoge
# ユーザーhogeを管理者グループに入れます

su - hoge
# ユーザーhogeに変われることを確認します

sudo su -
# パスワード入力後にrootに昇格できることを確認します

exit
# ユーザーhogeに戻ります

whoami
# ユーザーhogeであることを確認します

ssh-keygen -t ed25519
# 鍵の格納場所は初期値でいいので空Enter。(/home/hoge/.ssh/
# パスワードを設定します。

cd .ssh
ls -l
# 以下のファイルを確認します
# └id_ed25519
# └id_ed25519.pub
# ※これらのファイルはscp等で自分のクライアントにコピーします

rm id_ed25519
# sshサーバ上でそのまま鍵を作成したので秘密鍵は*クライアントにコピー後*削除します

mv id_ed25519.pub authorized_keys
chmod 600 authorized_keys
# 公開鍵をauthorized_keysに変更し、パーミッションを厳密にします

この後、ローカルにコピーしたid_ed25519をSSHターミナルクライアントに保存して設定し、接続確認を行います。

接続ができたらいよいよUbuntu 20.04→Ubuntu22.04へのアップグレードです。

ローカルPC(ターミナルクライアント)からの操作

whoami
#上記、作成したユーザーであることを確認します

sudo su -
# rootに昇格できることを確認します

apt update && apt upgrade && apt autoremove
# パッケージを最新版にして不要パッケージを削除します。途中で不要パッケージを消すかを求められるので[y]で消去します

reboot
# 一度再起動をします
# 再起動後、ログインします

Ubuntu20.04→22.04へのアップグレード

whoami
#上記、作成したユーザーであることを確認します

sudo su -
# rootに昇格できることを確認します

do-release-upgrade
# *ここからの作業は中断せず、一気通貫で行います*
アップグレード中にプロンプトから質問されたこと

以下、主要な質問事項です。コメント(#の後)に概要を書いています。

Reading cache

Checking package manager

Continue running under SSH?

This session appears to be running under ssh. It is not recommended
to perform a upgrade over ssh currently because in case of failure it
is harder to recover.

If you continue, an additional ssh daemon will be started at port
'1022'.
Do you want to continue?

# SSHのポートを追加するか
# → y

Starting additional sshd 

To make recovery in case of failure easier, an additional sshd will 
be started on port '1022'. If anything goes wrong with the running 
ssh you can still connect to the additional one. 
If you run a firewall, you may need to temporarily open this port. As 
this is potentially dangerous it's not done automatically. You can 
open the port with e.g.: 
'iptables -I INPUT -p tcp --dport 1022 -j ACCEPT' 

To continue please press [ENTER]

# 設定を変更するか
# → Enter

Do you want to start the upgrade?


4 packages are going to be removed. 85 new packages are going to be
installed. 555 packages are going to be upgraded.

You have to download a total of 247 M. This download will take about
49 seconds with a 40Mbit connection and about 6 minutes with a 5Mbit
connection.

Fetching and installing the upgrade can take several hours. Once the
download has finished, the process cannot be canceled.

 Continue [yN]  Details [d]

# アップグレード前の最終確認
# → y

There are services installed on your system which need to be restarted when certain libraries, such as libpam, libc, and libssl, are upgraded. Since these restarts may cause interruptions of service for the system, you will     x
   x normally be prompted on each upgrade for the list of services you wish to restart.  You can choose this option to avoid being prompted; instead, all necessary restarts will be done for you automatically so you can avoid being   x
   x asked questions on each library upgrade.                                                                                                                                                                                            x
   x                                                                                                                                                                                                                                     x
   x Restart services during package upgrades without asking?

# アップグレード時、各種サービスを再起動前にプロンプトでy/nを確認するか
# → 質問されるのがめんどいので yes

# この間、SSH等の設定変更を行うか訊いてきます。プロンプトの選択を変えずに先に進みました
# keep the local version currently installed

Remove obsolete packages? 

# 不要パッケージの削除
# → Yes

System upgrade is complete.

Restart required

To finish the upgrade, a restart is required.
If you select 'y' the system will be restarted.

Continue [yN]

# アップグレード完了後にリブートするか
# → y

こうして、再起動後、無事にアップグレードが完了です。

cat /etc/lsb-release

DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=22.04
DISTRIB_CODENAME=jammy
DISTRIB_DESCRIPTION="Ubuntu 22.04.1 LTS"

アップグレード後の操作

以下、速やかに行います。

管理者に昇格できることを確認します。

sudo su -

rootのパスワードを設定します。

passwd root

初期ユーザー(ubuntu)が物理的にログインできないようにします。

cd /home/ubuntu/.ssh

rm authorized_keys

chatGPTが作成したシェルスクリプト。

こちらにより、apacheのバーチャルファイルをAIで作成できると知り、そこから更に発展させました。

作成して欲しいと思った機能

こちらのスクリプトで抜き出したIPアドレスを、

  • 10.0.0.0/24
  • 10.3.3.0/24
  • 172.28.3.0/24
  • 192.168.1.0/24

のように、ネットワークアドレスにした上でNWごとにブロックできないかと思い立ち、その前段として「IPをソートしてネットワークアドレスを付与できないか」

と、以下のようにして書いてもらいました。

AIへの質問

192.168.1.3
192.168.1.2
10.0.0.2
10.3.3.2
10.3.3.254
172.28.3.4
172.28.3.5

などのIPアドレスが書かれたテキストファイルip.txtがあります。

これを読み込んだ後にソートして

192.168.1.0/24
192.168.1.0/24
10.0.0.0/24
10.3.3.0/24
10.3.3.0/24
172.28.3.0/24
172.28.3.0/24

とネットワークアドレスに変換後、

10.0.0.0/24
10.3.3.0/24
172.28.3.0/24
192.168.1.0/24

と重複を排除し、アドレスごとに改行した上でnetwork.txtに出力するシェルスクリプトを書いてください。

AIの回答

以下のようなシェルスクリプトを作成することで、指定した要件を満たすことができます。

#!/bin/bash

# ip.txtを読み込んで、1行ごとに処理する
while read line; do
  # IPアドレスを/24のサブネットマスクで分割する
  network=$(echo "$line" | cut -d "." -f 1-3).0/24

  # 分割したサブネットアドレスを出力する
  echo "$network"
done < ip.txt | sort | uniq > network.txt

上記のスクリプトでは、ip.txtを読み込んで1行ごとに処理しています。

その後、cutコマンドを使用して、IPアドレスを"."で分割し、最初の3つのフィールドを取り出します。

最後に、取り出したフィールドに".0/24"を追加して、サブネットアドレスを生成します。

生成したサブネットアドレスをsortコマンドでソートし、uniqコマンドで重複を除外した上で、network.txtに出力するようにしています。

作成結果

以下、作成しました。

vi script.sh
# 上記のスクリプトを貼り付けて保存
chmod +x script.sh
# 平行してIPアドレスを抜き出したip.txtを用意します
./script.sh

で、予想通りの出力が得られました。

後は少しずつ応用していけば、まるごとブロックしたり他のセキュリティソフトとの連携も可能になります。

Ubuntu 22.04でZabbix 6.2(MySQL/nginx構成)を設定するときにハマったこと。

以下の環境でZabbixを導入してみましたが、いくつかハマったことがあったのでメモを残しておきます。

導入した環境

  • Ubuntu 22.04
  • 導入しようとしたZabbix : 6.2
  • MySQL / nginx構成
  • 他サービス未導入(OSインストールと初期設定を終えたのみです)
  • ドメイン登録済みです。
  • ワイルドカードSSL証明書を発行済みです。

導入手順(ハマりポイント込み)

前提

  • 全て管理者権限で実施しています。
  • パッケージ管理は基本的にaptitudeを利用しています。
  • ローカルNWで設定しているのでufwなどは考慮していません。

参考URL

Zabbixレポジトリを追加してインストールします。

aptitude update
aptitude upgrade
wget https://repo.zabbix.com/zabbix/6.2/ubuntu/pool/main/z/zabbix-release/zabbix-release_6.2-1+ubuntu22.04_all.deb
dpkg -i zabbix-release_6.2-1+ubuntu22.04_all.deb
aptitude update
aptitude install zabbix-server-mysql zabbix-frontend-php zabbix-nginx-conf zabbix-sql-scripts zabbix-agent

MySQLの初期設定

aptitude install mysql-server
systemctl start mysql
systemctl enable mysql

必要に応じて: mysql_secure_installation

参考 https://level69.net/archives/28557
vi /etc/mysql/mysql.conf.d/mysqld.cnf
追記内容
#末尾に以下を追加
default_authentication_plugin=mysql_native_password

設定後にmysqlサービス再起動

systemctl restart mysql

MySQL rootパスワード設定

mysql -u root -p
# 未設定のためパスワードは不要です
ALTER USER 'root'@'localhost' IDENTIFIED WITH mysql_native_password BY 'パスワード';
#パスワードは任意のものを入力ください
flush privileges;
exit

mysql初期設定

mysql_secure_installation
初期設定内容
Enter password for user root: 
# 上記で設定したパスワードを入力します

VALIDATE PASSWORD COMPONENT can be used to test passwords
and improve security. It checks the strength of password
and allows the users to set only those passwords which are
secure enough. Would you like to setup VALIDATE PASSWORD component?

Press y|Y for Yes, any other key for No: 
# Yを入力してEnter

There are three levels of password validation policy:

LOW    Length >= 8
MEDIUM Length >= 8, numeric, mixed case, and special characters
STRONG Length >= 8, numeric, mixed case, special characters and dictionary                  file

Please enter 0 = LOW, 1 = MEDIUM and 2 = STRONG:
# ポリシーに合わせて0/1/2を入力(ローカル環境のため0としました)

Estimated strength of the password: 50 
Change the password for root ? ((Press y|Y for Yes, any other key for No) : 
# 既に設定しているのでn

By default, a MySQL installation has an anonymous user,
allowing anyone to log into MySQL without having to have
a user account created for them. This is intended only for
testing, and to make the installation go a bit smoother.
You should remove them before moving into a production
environment.

Remove anonymous users? (Press y|Y for Yes, any other key for No) : 
# anonymousユーザーを削除するためY

Normally, root should only be allowed to connect from
'localhost'. This ensures that someone cannot guess at
the root password from the network.

Disallow root login remotely? (Press y|Y for Yes, any other key for No) : 
# rootユーザのリモートログインを禁止するためY

Remove test database and access to it? (Press y|Y for Yes, any other key for No) : 
# テストDBを削除するためY

Reload privilege tables now? (Press y|Y for Yes, any other key for No) : 
# 設定を反映するためy

MySQLでZabbix用のユーザーを作成

mysql -uroot -p
# 上記で設定したパスワードを入力します
CREATE DATABASE zabbix character set utf8mb4;
CREATE USER 'zabbix'@'localhost' IDENTIFIED BY 'パスワード';
# 任意のパスワードを設定
GRANT ALL ON redmine.* TO 'zabbix'@'localhost';
flush privileges;
exit

ハマりポイント1:SQL実行時にエラーが出る

ERROR 1419 (HY000) at line 2123: You do not have the SUPER privilege and binary logging is enabled (you *might* want to use the less safe log_bin_trust_function_creators variable)

と出たので、設定をしておきます。

対処方法
mysql -uroot -p

rootでmysqlにログイン後、以下を実行します。

SHOW VARIABLES LIKE 'log_bin_trust_function_creators';
# OFF を確認
set global log_bin_trust_function_creators=1;
# 設定を有効化
 SHOW VARIABLES LIKE 'log_bin_trust_function_creators';
 # ONを確認

ハマりポイント2: インポート用SQLが存在しない(正しい手順を後述)

Webサイトの手順によると、

zcat /usr/share/doc/zabbix-sql-scripts/mysql/server.sql.gz | mysql -uzabbix -p zabbix

とありますが、該当ディレクトリにmysql用のSQLが存在しません。

対処方法
apt reinstall zabbix-sql-scripts

として、sqlを再インストールします。

updatedb
 locate server.sql.gz
 →  /usr/share/zabbix-sql-scripts/mysql/server.sql.gz

SQLをインポートします。

zcat /usr/share/zabbix-sql-scripts/mysql/server.sql.gz | mysql -uzabbix -p zabbix
# zabbixのDBパスワードを入力します。

Zabbixの設定を行います。

vi /etc/zabbix/zabbix_server.conf
追記/編集内容
DBName=zabbix
DBUser=zabbix
DBPassword=zabbix

nginx用のconfファイルを設定します。

vi /etc/zabbix/nginx.conf
編集内容
        listen          443 ssl http2 default_server;
        # ポートを443のみで受け付けるようにします。
        server_name     ドメイン名;

        ssl_certificate "/SSL証明書と中間証明書を結合したファイル";
        ssl_certificate_key "秘密鍵ファイル";
        ssl_protocols TLSv1.2 TLSv1.3;
        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:ECDHE-RSA-AES128-SHA";
        ssl_prefer_server_ciphers off;
        ssl_session_cache shared:SSL:1m;
        ssl_session_timeout 10m;

設定内容を確認します。

nginx -t
# Syntax OKを確認します

設定内容を反映します。

systemctl restart zabbix-server zabbix-agent nginx php8.1-fpm
systemctl enable zabbix-server zabbix-agent nginx php8.1-fpm

セットアップ確認

ブラウザから

https://ドメイン名/setup.php

が表示されれば問題ないです。その後、Next Stepに進んでください。

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

前提

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

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

Page 27 of 33

Powered by WordPress & Theme by Anders Norén