一般公開しているRedmine「クーケン島観光ガイド」、新規VPS、XServerへの移行に伴いデータの移設を行いました。

の構成はそのまま。コンテンツもそのまま移植しています。
ここに至るまで盛大にハマりましたが、なんとかなりました。
この時の記事は改めて記載します。
一般公開しているRedmine「クーケン島観光ガイド」、新規VPS、XServerへの移行に伴いデータの移設を行いました。
の構成はそのまま。コンテンツもそのまま移植しています。
ここに至るまで盛大にハマりましたが、なんとかなりました。
この時の記事は改めて記載します。
サーバの移設中なので、ログに関しての記録を残しています。
Webサーバ全般のメンテナンスで特に必要なのは
「ログを適切に管理する」
です。
を目の当たりにできる手段だからです。(特に後者に助けられたことは幾度となくあります)
そのため、Webサーバ上のログのローテーションを行い、履歴を追いやすくし、更にサーバの容量も削減するログローテーションを行います。
ログファイルが肥大化するのを防ぐために、古いログを一定のルールに基づいて新しいログに切り替えたり、削除したりする仕組みのことです。
hogeサイトのアクセス記録である/var/log/access.log
というファイルは、何も設定していないとログが記録され続けます。これによって以下の問題が起きます。
「Webサーバに新たなWebサイトやサービスを立ち上げたとき」 です。
試験運用などでもログは問題が起きたときのヒントとなるからです。
apt
(aptitude
)によるパッケージ管理でインストールしているため、Apacheの実行ユーザはwww-data
です。ディストリビューションが違ってもこの手順は有効ですが、RockyやAlma等のRHEL系のApacheの実行ユーザは通常はapache
であることに注意しましょう。
www-data
に変えます。ここでは、hogeサイト(/var/log/hoge
)のログをローテーションする方法です。
これは、Redmineのlogプラグインのように、Webインタフェース上からログを閲覧できるプラグインがある場合、Apacheを実行しているサービス自体が参照できるようにするためです。
sudo chown -R www-data:www-data /var/log/hoge
ログ一式の所有者を変えます。ログファイルの形式は自分の環境に合わせます。
ls -l /var/log/hoge
ログファイルの所有者とグループがwww-data
であることを確認します。
ファイル名やログのパスは自分の環境に合わせます。 ここを間違えると元も子もありません。
cat <<- __EOF__ | sudo tee -a /etc/logrotate.d/hoge
/var/log/hoge/*.log {
daily
missingok
rotate 10
compress
copytruncate
notifempty
su www-data www-data
__EOF__
これは、以下を行います。
他、週ごとやログのファイル形式(日付形式)などを設定できます。こちらは運用に合わせてください。
sudo logrotate -dv /etc/logrotate.d/hoge
※先ほど作成したファイル名に合わせます。
ここでエラーがなければログローテーションはできています。
すぐにローテーションを確かめる場合は以下を実行します。強制的にログローテーションを行うコマンドです。
sudo logrotate -f /etc/logrotate.d/hoge
このコマンドを実行後、/var/log/hoge/
ディレクトリ内にaccess.log.1.gz
のようなファイルが作成され、元のaccess.log
が空になっていれば、設定は完璧です。
サーバスペックの要となる
を一度に表示するワンライナーです。
awk 'BEGIN {FS=":"; OFS="\t"} /^model name/ && !cpu_model {cpu_model=$2; gsub(/^ */, "", cpu_model)} /^processor/ {cores++} /^MemTotal/ {mem_total=$2} /^MemAvailable/ {mem_avail=$2} /^SwapTotal/ {swap_total=$2} END {printf "CPUモデル\t: %s\n", cpu_model; printf "CPUコア数\t: %s\n", cores; printf "合計メモリ\t: %.2f GiB\n", mem_total/1024/1024; printf "利用可能メモリ\t: %.2f GiB\n", mem_avail/1024/1024; printf "合計スワップ\t: %.2f GiB\n", swap_total/1024/1024}' /proc/cpuinfo /proc/meminfo
CPUモデル : AMD EPYC-Milan Processor
CPUコア数 : 4
合計メモリ : 5.78 GiB
利用可能メモリ : 5.34 GiB
合計スワップ : 2.00 GiB
と、分かりやすい表示で一気に表示してくれます。
設定変更時、過去のコマンド履歴を確認するため
history | grep command
として過去の履歴を確認します。これをシェルスクリプトの力で解決します。(スクリプト作成にはGemini pro 2.5を利用)
#!/bin/bash
# スクリプトに引数が渡されたかどうかで処理を分岐
if [ "$#" -gt 0 ]; then
# 引数が存在する場合、その値を検索文字列として使用
SEARCH_TERM="$1"
else
# 引数がない場合、対話式でユーザーに入力を促す
read -p "探したいコマンドを入力してください: " SEARCH_TERM
fi
# 検索文字列が空の場合はエラーメッセージを出して終了
if [ -z "${SEARCH_TERM}" ]; then
echo "検索文字列が入力されていません。"
exit 1
fi
# historyコマンドの代わりに、履歴ファイルを検索する
HISTFILE_PATH="${HISTFILE:-$HOME/.bash_history}"
echo "実行履歴から「${SEARCH_TERM}」を含むコマンドは以下の通りです。"
grep "${SEARCH_TERM}" "${HISTFILE_PATH}"
これを保存して、
chmod +x histgrep.sh
で実行権限をつけます。
./histgrep.sh
探したいコマンドを入力してください: bundle
実行履歴から「bundle」を含むコマンドは以下の通りです。
sudo -u www-data bundle install --without development test --path vendor/bundle
sudo -u www-data bundle install
sudo -u www-data bundle install --without development test --path vendor/bundle
sudo -u www-data bundle exec gem install rake
sudo -u www-data bundle install --without development test --path vendor/bundle
sudo -u www-data bundle install --without development test --path vendor/bundle
sudo bundle install
と、探したい文字列を含む履歴をhistory(正確には履歴ファイル)から参照します。
./histgrep.sh configtest
実行履歴から「configtest」を含むコマンドは以下の通りです。
sudo apache2ctl configtest
このように、探したい文字列を引数とすることで、そのコマンドを探せます。
これをコマンド化します。
sudo ln -sf /path/to/script/directory/histgrep.sh /usr/local/bin/histgrep
/path/to/script/directory/histgrep.sh
はフルパスで、スクリプトがある場所を指定します。
which histgrep
で、/usr/local/bin/histgrep
を確認。
後は、作業中でも
histgrep tar
などとすれば、過去に実行したコマンドの履歴を容易に参照することができます。
VPSサービスなどで、最初にroot
アカウントとWebコンソールのみが提供される環境を想定し、安全な運用を行うための初期設定手順を解説します。
root
アカウントでの直接ログインを禁止する。sudo
権限を持つ一般ユーザーで行うようにする。この設定作業は、手順を一つでも誤ると、二度とサーバーにログインできなくなる危険性を伴います。特に、SSH接続を唯一のアクセス手段としている場合は、細心の注意が必要です。この記事では、Webコンソールを「ライフライン」として使い、安全に設定を完了させる手順を示します。
今回のケースは、XServer VPSで、Ubuntu 24.04を立ち上げたばかりの設定です。
※Webのシリアルコンソールは最初しか使わないため、この時のサーバではsshd秘密鍵は作成しません。(後で作成します)
DNS設定を行い、名前解決ができるようにしておくと便利です。
sudo
権限を付与する。sudo
権限が有効になったことを確認し、root
アカウントをロックする。adduser [メンテナンス用ユーザ]
※[メンテナンス用ユーザ]
は英数字です。その後、パスワード設定などを対話式で求められるので、指示に従って入力します。
exit
Webシリアルコンソールから抜けます。
Webコンソールで、作成したユーザ名とパスワードでログインできることを確認。
whoami
で、設定したアカウントであることを確認します。
sudo su -
としても、rootに昇格することはできません。なので、一度
exit
でコンソールを抜け、rootでログインし直します。
rootでログイン後、
usermod -aG sudo [メンテナンス用ユーザ]
で、sudo
グループにこのユーザを加えます。
id -a [メンテナンス用ユーザ]
で、以下のように表示されることを確認します。
uid=1000(hoge) gid=1000(hoge) groups=1000(hoge),27(sudo),100(users)
修正したユーザのグループに、27(sudo)
と表示されることがポイントです。
確認後、
exit
で更にrootを抜け、今度はメンテナンス用のユーザでログインします。
メンテナンス用のユーザでログイン後、
sudo su -
で、rootに昇格できることを確認します。(※できない場合は前段の作業をやり直してください)
whoami
でroot
表示されることも確認します。
passwd -l root
として、rootそのものをロックします。
exit
を2回行い、Webコンソールから抜けます。
これ以降はメンテナンス用のユーザで作業を行います。
Ubuntu Desktop系と違い、Ubuntu Serverではsshdがデフォルトでインストールされていない場合があります。
sudo apt install ssh
で、sshdをインストールします。
インストール後、
ssh -V
でバージョンが表示されることを確認し、
systemctl status ssh.service
で、running
とenabled
を確認します。
鍵認証でログインできるようにします。
ssh-keygen -t ed25519
cd .ssh
ls -l
以下のファイルを確認します。
公開鍵をauthorized_keysに変更し、パーミッションを厳密にします。
cat id_ed25519.pub >> authorized_keys
chmod 600 authorized_keys
この秘密鍵(id_ed25519
)は、サーバー全体のアクセス権を持つ、言葉通りの意味でのマスターキーです。
この秘密鍵を奪われることは、サーバーの全権限を奪われることと同義です。 そのため、管理は厳密に、そして自分だけがアクセスできる安全な手段(パスワードマネージャーや暗号化されたストレージなど)で、必ずバックアップをこの段階で行ってください。
SSHで外部から接続する前に、VPS事業者が提供するファイアウォール機能で、SSHのポート(22/tcp)が開放されていることを確認します。
SSH
または 22
TCP
任意のターミナルクライアントで接続を行います。(筆者が愛用しているのはRLoginです)
を指定して、SSHログインできることを確認します。
sudo cp -pi /etc/ssh/sshd_config /path/to/backup/directory/sshd_config.$(date +%Y%m%d)
任意のバックアップディレクトリを指定します。(筆者の場合は/etc/conf_backup
)
diff -u /path/to/backup/directory/sshd_config.$(date +%Y%m%d) /etc/ssh/sshd_config
エラーがない(差分がない)ことでバックアップを確認します。
sudo sed -i -e 's/^#PasswordAuthentication yes/PasswordAuthentication no/' -e 's/^#PermitEmptyPasswords no/PermitEmptyPasswords no/' /etc/ssh/sshd_config
diff -u /path/to/backup/directory/sshd_config.$(date +%Y%m%d) /etc/ssh/sshd_config
-#PasswordAuthentication yes
-#PermitEmptyPasswords no
+PasswordAuthentication no
+PermitEmptyPasswords no
sudo systemctl restart ssh.service
パッケージ全体のアップグレードを行います。
sudo apt update && sudo apt upgrade
アップグレード後、再起動を行います。
sudo reboot
個人的に重要な作業です。「どういうサーバに育てていくか」はその名前にかかっているというのが持論です。
sudo hostnamectl set-hostname hoge.example.com
等として、自分のサーバを命名しましょう。
設定後、
uname -n
で、サーバ名を確認します。
この時、
sudo reboot
後、再起動後も名前が変わらないことを確認します。
最初期のプロンプトは
hoge@hoge$
になっているので、好みに沿って設定していきます。
cat << ___EOF___ | tee -a ~/.bashrc
PS1="[\u@\H \W]\\$ "
# 一般ユーザ向けのプロンプト設定
if [ "\$PS1" ]; then
if [ "\$(id -u)" -eq 0 ]; then # rootユーザの場合
PS1='\[\e[0;31m\][\u@\H \W]#\[\e[0m\] '
else # 一般ユーザの場合
PS1='\[\e[0;32m\][\u@\H \W]\$\[\e[0m\] '
fi
fi
___EOF___
Ubuntu系は.bashrcが統一されないので、やむなくこの方法をとります。
sudo su -
cat << ___EOF___ | tee -a ~/.bashrc
PS1="[\u@\H \W]\\$ "
# 一般ユーザ向けのプロンプト設定
if [ "\$PS1" ]; then
if [ "\$(id -u)" -eq 0 ]; then # rootユーザの場合
PS1='\[\e[0;31m\][\u@\H \W]#\[\e[0m\] '
else # 一般ユーザの場合
PS1='\[\e[0;32m\][\u@\H \W]\$\[\e[0m\] '
fi
fi
___EOF___
設定後、SSHセッションを開き直します。以下を確認します。
これは完全に筆者の好みです。パッケージ管理をaptではなくaptitudeに変えます。
sudo apt install aptitude
以前も書いていたadditonalsプラグインのインストール、Redmine5.1版です。
このプラグインの最新版はRedmine6.0のみ対応しています。そのため、ややバージョンの落ちるRedmine5.1で動かすには少し手間があります。
Redmineにかなり強力なマクロを付与するプラグイン:additionalsをインストールします。
また、このプラグインは「additonal_tags」プラグインでも必要です。
2025年にリリースされているプラグインはRedmine 5.xをサポートしていないため、動くバージョン(タグ)をダウンロードしてのインストールです。
cd /hoge
任意のディレクトリに移動します
wget https://github.com/AlphaNodes/additionals/archive/refs/tags/3.4.0.zip
sudo chown www-data:www-data 3.4.0.zip
apache / nginxの実行ユーザに所有者を合わせます
sudo -u www-data unzip 3.4.0.zip
sudo -u www-data mv additionals-3.4.0 /path/to/redmine/root/directory/plugins/additionals
このとき、リネームも行います。(-3.4.0を外す)
自分の環境に合わせます。(筆者環境/home/www-data/redmine/plugins/
)
cd /path/to/redmine/root/directory && pwd
自分の環境に合わせます。(筆者環境/home/www-data/redmine
)
sudo -u www-data bundle install
sudo -u www-data bundle exec rake redmine:plugins:migrate RAILS_ENV=production
sudo systemctl restart apache2
このスクリプトの改善案をGoogle Geminiに言ったところ、更に完成度が上がりました。
Web運用において、「サーバのSSL証明書更新」をチェックすることは大切です。
適切に更新されていない/更新が遅れたまま放置すると
など、リスクは甚大です。
そこで、
を表示するRubyスクリプトを準備しました。
#!/usr/bin/env ruby
require 'openssl'
require 'socket'
require 'date'
require 'uri'
require 'timeout'
# 色付け用の定数
COLOR_RED = "\e[31m"
COLOR_YELLOW = "\e[33m"
COLOR_GREEN = "\e[32m"
COLOR_RESET = "\e[0m"
# URLの最終的な到達先を取得するメソッド
def get_effective_url(url)
# curlを使ってリダイレクトを追いかけ、最終的なURLを取得する
# -s: サイレント, -L: リダイレクト追従, -I: ヘッダのみ, -o /dev/null: ボディ破棄, -w '%{url_effective}': 最終URLを出力
effective_url = `curl -sLI -o /dev/null -w '%{url_effective}' "#{url}"`
effective_url.empty? ? nil : effective_url
end
# 証明書の有効期限を取得するメソッド
def get_certificate_expiry_date(url)
uri = URI.parse(url)
hostname = uri.host
port = uri.port || 443 # ポートがなければ443を使う
ssl_socket = nil
tcp_client = nil
begin
Timeout.timeout(5) do
tcp_client = TCPSocket.new(hostname, port)
ssl_context = OpenSSL::SSL::SSLContext.new
ssl_socket = OpenSSL::SSL::SSLSocket.new(tcp_client, ssl_context)
ssl_socket.hostname = hostname
ssl_socket.connect
cert = ssl_socket.peer_cert
expiration_date = DateTime.parse(cert.not_after.to_s)
days_remaining = (expiration_date - DateTime.now).to_i
return expiration_date, days_remaining
end
rescue Timeout::Error
return nil, "サーバーへの接続がタイムアウトしました。"
rescue => e
return nil, e.to_s
ensure
ssl_socket&.close
tcp_client&.close
end
end
# 結果を表示するメソッド
def print_result(url, expiration_date, days_remaining)
if expiration_date
formatted_date = expiration_date.strftime("%Y/%m/%d")
# 残り日数に応じて色を選択
color = if days_remaining < 14
COLOR_RED
elsif days_remaining < 30
COLOR_YELLOW
else
COLOR_GREEN
end
puts "サイト #{url} の有効期限は #{formatted_date} です。#{color}残り #{days_remaining} 日です。#{COLOR_RESET}"
else
puts "#{COLOR_RED}サイト #{url} の証明書取得に失敗しました: #{days_remaining}#{COLOR_RESET}"
end
end
# メイン処理
def main
# コマンドライン引数があるかどうかで処理を分岐
domains_to_check = if ARGV.empty?
# 引数がない場合は、対話式で入力を受け付ける
print "チェックしたいサイトのドメインを入力してください(例: example.com): "
[gets.chomp]
else
# 引数がある場合は、それらを全てチェック対象とする
ARGV
end
# 各ドメインをチェック
domains_to_check.each do |domain|
# 対話モードで空エンターされた場合などをスキップ
next if domain.nil? || domain.strip.empty?
# http/httpsから始まらない場合はhttpsを付与
initial_url = domain.start_with?('http') ? domain : "https://#{domain}"
puts "Checking: #{initial_url} ..."
final_url = get_effective_url(initial_url)
if final_url.nil?
puts "#{COLOR_RED}サイト #{initial_url} にアクセスできませんでした。#{COLOR_RESET}"
next
end
expiration_date, days_remaining = get_certificate_expiry_date(final_url)
print_result(final_url, expiration_date, days_remaining)
end
end
# メイン処理を呼び出し
main
ruby ssl_checker.rb
※Rubyで動かすためスクリプトに実行権は持たせる必要はありません
ruby script.rb www.hoge.com
など、ドメインを引数にしても同様の効果が得られるとアラートも出してくれるようにしています。
ruby ssl_checker.rb
チェックしたいサイトのドメインを入力してください(例: example.com): www.yahoo.co.jp
Checking: https://www.yahoo.co.jp ...
サイト https://www.yahoo.co.jp/ の有効期限は 2026/05/14 です。残り 310 日です。
ruby ssl_checker.rb yahoo.co.jp www.msn.com
Checking: https://yahoo.co.jp ...
サイト https://www.yahoo.co.jp:443/ の有効期限は 2026/05/14 です。残り 310 日です。
Checking: https://www.msn.com ...
サイト https://www.msn.com/ の有効期限は 2025/10/05 です。残り 89 日です。
筆者は/etc/update-motd
配下に
ruby /path/to/script/ruby/ssl_checker.rb ryza.jp
と記入することで、ログインのたびに
Checking: https://atelier.reisalin.com ...
サイト https://atelier.reisalin.com/ の有効期限は 2025/08/15 です。残り 37 日です。
と次の更新のタイミングを読みやすくしています。
Redmineとの連携でmod_passangerを用いています。これのアップグレードメモです。
var/log/apache2/error.log
を確認したところ、
[ E 2025-07-04 15:08:31.6489 116405/T5 age/Cor/SecurityUpdateChecker.h:521 ]: A security update is available for your version (6.0.17) of Phusion Passenger(R). We strongly recommend upgrading to version 6.0.27.
と出たのでバージョンアップを行います。
passenger-config --version
Phusion Passenger(R) 6.0.17
を確認。
※筆者の好みでaptitudeを用いています。好みに応じてaptに変更してください。
sudo aptitude install passenger
を行いましたが、インストール・削除・更新されるパッケージがありません。
と出たので、レポジトリの追加に伴うアップグレードを行いました。
※導入済みであれば不要です。
sudo aptitude install dirmngr gnupg apt-transport-https ca-certificates curl
curl https://oss-binaries.phusionpassenger.com/auto-software-signing-gpg-key.txt | gpg --dearmor | sudo tee /etc/apt/trusted.gpg.d/phusion.gpg >/dev/null
これは、これから追加するリポジトリがPhusion社による本物であることを保証するための電子署名キーです。
sudo sh -c 'echo deb https://oss-binaries.phusionpassenger.com/apt/passenger $(lsb_release -sc) main > /etc/apt/sources.list.d/passenger.list'
sudo aptitude update
sudo aptitude install passenger
一式を
今度はアップグレードされました。
Ubuntu24.04はneedrestart
により、サービス再起動が必要なパッケージ更新が走った後は再起動してくれますが、念のため
sudo systemctl restart apache2.service
を行います。
passenger-config --version
Phusion Passenger(R) 6.0.27
と、アップグレードされていました。
筆者にとってこの作業は当たり前すぎていたため、メモを残すのを失念していました。
Webサイトを公開する際に必須と言っていいSSL証明書を、Let's Encrypt(certbot)を用いて無料で発行する手順です。
今回用意するのはワイルドカード証明書です。
「*.example.com」という証明書を取得することで、
など、サブドメインすべてに有効な証明書を1回で発行できます。
/etc/letsencrypt/live/
ではなく、任意の作業ディレクトリに証明書一式を保存する運用を行っています。※すでにcertbotがインストール済の場合は、この手順はスキップして構いません。
sudo snap install --classic certbot
sudo ln -s /snap/bin/certbot /usr/bin/certbot
which certbot
/usr/bin/certbot
を確認します。
性質上、rootで実行します。操作は慎重に行ってください。
sudo su -
mkdir /hoge/example.com_ssl$(date +%Y%m)
任意のディレクトリを指定します。$(date +%Y%m)オプションをつけているのは、Let's Encryptの有効期限が90日間と短いため、定期的に更新するためです。
cd /hoge/example.com_ssl$(date +%Y%m) && pwd
指定したディレクトリにいることを確認します。
※ ドメイン名やメールアドレスの打ち間違いは特に注意してください。このコマンドをコピー&ペーストし、自分のドメインやメールアドレスで間違いないように確認後に発行してください。
certbot certonly --manual \
--preferred-challenges dns \
--server https://acme-v02.api.letsencrypt.org/directory \
-m あなたの有効なメールアドレス@example.com \
-d "*.example.com" \
-d "example.com"
--manual
モードは非自動化のため、証明書更新のたびに手動でTXTレコード登録が必要です。自動化したい場合はDNS API対応のプラグインを検討してください(例:certbot-dns-cloudflare)。certonly
は証明書の取得だけを行い、Webサーバ設定などには手を加えないモードです。以下のように実施します。
nslookup -type=TXT _acme-challenge.example.com
→ 結果が返ってきたらEnter。証明書が作成されます。
cp -pi /etc/letsencrypt/live/example.com/fullchain.pem ./example.com.crt.$(date +%Y%m)
※root権限のためsudo
を用いないことに注意
cp -pi /etc/letsencrypt/live/example.com/privkey.pem ./example.com.key.$(date +%Y%m)
(通例、証明書はroot権限でしか読めないように制限されています。読み取り時は注意してください)
以下、自分が発行したドメインに基づく証明書や秘密鍵に読み替えます。
openssl x509 -noout -dates -subject -in example.com.crt.$(date +%Y%m)
notBefore=May 17 04:35:55 2025 GMT
notAfter=Aug 15 04:35:54 2025 GMT
のように90日間であることを確認します。
openssl x509 -pubkey -in example.com.crt.$(date +%Y%m) -noout | openssl md5
openssl pkey -pubout -in example.com.key.$(date +%Y%m) | openssl md5
→ 確認1/確認2で出てきた公開鍵のハッシュ値が一致していればOKです。
openssl crl2pkcs7 -nocrl -certfile example.com.crt.$(date +%Y%m) | openssl pkcs7 -print_certs -outform PEM | awk 'BEGIN {c=0;} /BEGIN CERTIFICATE/ {c++} { print > "cert" c ".pem"}' && openssl verify -CAfile cert2.pem cert1.pem
openssl verify -CAfile cert2.pem cert1.pem
cert1.pem: OK
となることを確認します。
確認後、
exit
でrootから抜けます。
※Let's Encryptは3ヶ月(90日)しか有効期限がありません。
そこで、証明書更新の際にApacheの設定ファイルを修正することなく行えるように、証明書/秘密鍵ファイルにシンボリックリンクを張り、ファイル名.202507等とすることで「最後に発行したのはいつか」を確認します。
sudo mkdir /etc/certs
証明書を格納するディレクトリです
sudo mkdir /etc/private
秘密鍵を格納するディレクトリです
など、適当な方法を用います。(割と効率的なのがcat
でファイル内容を開き、それを別サーバに貼り付ける方法です)
秘密鍵格納後、
sudo chmod 600 /etc/private/hoge.sample.com.key.202507
として、アクセス権を厳密にします。
上記、取得した*.example.com
の証明書と秘密鍵を
に格納したとして手順を進めます。
cd /etc/certs && pwd
/etc/certs
にいることを確認
sudo ln -sf hoge.sample.com.crt.202507 hoge.sample.com.crt
ls -l hoge.sample.com.crt
リンクの向き先がhoge.sample.com.crt.202507であることを確認します。
例
lrwxrwxrwx 1 root root 31 7月 2 14:35 hoge.sample.com.crt -> hoge.sample.com.crt.202507
cd /etc/private && pwd
/etc/private
にいることを確認
sudo ln -sf hoge.sample.com.key.202507 hoge.sample.com.key
ls -l hoge.sample.com.key
リンクの向き先がhoge.sample.com.crt.202507であることを確認します。
後は、お使いのWebサーバに適用していきます。この方式であれば、
SSLCertificateFile 【/etc/certs/hoge.example.com.crt】
# SSL証明書を指定します
SSLCertificateKeyFile 【/etc/private/hoge.example.com.key】
# 秘密鍵を指定します
とすることで、.confファイルをいじることなく更新作業を行えます。
以下、Redmineでの設定例です。
https://atelier.ryza.jp/projects/zettel/knowledgebase/articles/20
オープンソースの解析システムであるMatomoをインストールしたときのメモです。
ということで運用しました。
以前のメモがUbuntu 20.04のインストールだったので、こちらを改めて書き起こしています。
リアルタイムでアクセスする性質上、PVが非常に多いWebサイトではサーバ自体の冗長化構成が必要です。(上記URL参照)
筆者のサイトは10万ページ/月に満たないので、そこそこのスペックで運用できています。
既に以下のシステムがWAN環境に揃っていること。
www-data
です。sudo mysql -u root -p
CREATE DATABASE IF NOT EXISTS matomo CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;
DB名は自分の環境に合わせます。
CREATE USER 'matomo'@'localhost' IDENTIFIED WITH mysql_native_password BY 'YOUR_STRONG_PASSWORD';
DBユーザーは自身の環境に合わせます。パスワードはポリシーに沿って強固なものを設定してください。
GRANT ALL PRIVILEGES ON matomo.* TO 'matomo'@'localhost';
mysql -u matomo -p
DB名・ユーザー名は適宜自分が設定したものに読み替えてください。
SHOW DATABASES;
作成したDBがあることを確認します。
EXIT
MySQLコンソールから抜けます。
cd /hoge &&pwd
自分の環境に合わせます。
wget https://builds.matomo.org/matomo-latest.zip
unzip matomo-latest.zip
sudo chown -R www-data:www-data matomo
ディレクトリ一式をApache実行ユーザー(www-data
)に修正します。
sudo mv matomo /home/www-data/
自分の環境に合わせます。(筆者環境は/home/www-data/matomo
で動かします)
ls -ld /home/www-data/matomo
該当ディレクトリにファイル一式があることを確認します。
【】内を自分の環境に合わせます。
コマンド一式をコピー → 別のエディタにペースト
その後、【】内を自分の環境に修正してコピー
コマンド一式をSSHクライアントに貼り付ける
cat <<- __EOF__ | sudo tee /etc/apache2/sites-available/matomo.conf > /dev/null
<VirtualHost _default_:80>
ServerName 【設定したドメイン名】
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
</VirtualHost>
<VirtualHost *:443>
ServerName 【設定したドメイン名】
CustomLog 【/var/log/matomo/matomo_access.log combined】
ErrorLog 【/var/log/matomo/matomo_error.log】
# アクセスログとエラーログは自分の環境に合わせて設定します。
DocumentRoot 【/home/www-data/matomo】
<Directory 【/home/www-data/matomo】>
# DcoumentRootとDirectoryは自分の環境に合わせて設定します
Options Indexes FollowSymLinks MultiViews
AllowOverride All
Require all granted
</Directory>
#SSL設定
SSLEngine on
Protocols h2 http/1.1
# SSLを有効化します
SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1 -TLSv1.2
#TLS1.3に対応していないクライアントがアクセスする場合は以下を用います
#SSLProtocol -ALL +TLSv1.2 +TLSv1.3
SSLCipherSuite ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384
SSLHonorCipherOrder off
SSLSessionTickets off
SSLUseStapling On
SSLStaplingCache "shmcb:/var/run/apache2/ssl_stapling(32768)"
# 2025年5月よりLet's EncryptはSSL Staplingに伴うOCSPを廃止しました。そのため、証明書をLet's Encryptにしている場合は上記2行をコメントアウトし、代わりにこちらを用いてください。
# SSLUseStapling Off
SSLCertificateFile 【/etc/certs/example.com.crt】
# SSL証明書を指定します
SSLCertificateKeyFile 【/etc/private/example.com.key】
# 秘密鍵を指定します
# SSLCACertificateFile 【/etc/certs/example.com.CA.crt】
# 中間証明書が発行元から別ファイルで提供されている場合は、この直上をコメントアウトして中間証明書を指定します
#セキュリティヘッダー付与
Header always set Strict-Transport-Security "max-age=63072000"
Header always set X-Content-Type-Options "nosniff"
Header always set X-Frame-Options "SAMEORIGIN"
Header always set X-XSS-Protection "1; mode=block"
# Matomo: 機密情報が含まれるディレクトリへの直接アクセスを禁止
<DirectoryMatch "/(config|core|lang|tmp|vendor)">
Require all denied
</DirectoryMatch>
# Matomo: .ini や .json といった設定ファイルへの直接アクセスを禁止
<FilesMatch "\.(ini|json)$">
Require all denied
</FilesMatch>
</VirtualHost>
__EOF__
ls -l /etc/apache2/sites-available/matomo.conf
ファイルがあることを確認します。
sudo a2ensite matomo.conf
sudo apache2ctl configtest
Syntax OK
を確認します
sudo systemctl restart apache2.service
sudo systemctl status apache2.service
ブラウザで
https://【matomoを設定したドメイン名】
にアクセスし、初期画面が出ることを確認します。
をそれぞれ入力し、「次へ」をクリックします。正常に入力されれば「テーブルを作成されました」と出るので「次へ」をクリックします。
をそれぞれ入力して「次へ」をクリックします。
を設定して「次へ」をクリックします。
これらを設定後、トラッキングタグが表示されます。これらを控えて「次へ」をクリックします。
「おめでとうございます!」と表示されればインストールの一連の作業は完了します。
Powered by WordPress & Theme by Anders Norén