redmine を Ubuntu 20.04 にインストール

古い内容だが、インストール時のメモを残しておく。

言語と地域の設定

sudo locale-gen ja_JP.UTF-8
sudo timedatectl set-timezone Asia/Tokyo

開発環境、Webサーバその他インストール

sudo apt install -y build-essential zlib1g-dev libssl-dev \
 libreadline-dev libyaml-dev libcurl4-openssl-dev libffi-dev
sudo apt install -y mariadb-server libmariadb-dev
sudo apt install -y apache2 apache2-dev
sudo apt install -y imagemagick fonts-takao-pgothic
sudo apt install -y subversion git
sudo apt install -y postfix

ruby をインストール

curl -O https://cache.ruby-lang.org/pub/ruby/2.7/ruby-2.7.6.tar.gz
tar xvf ruby-2.7.6.tar.gz
cd ruby-2.7.6
./configure --disable-install-doc
make
sudo make install
cd ..

MariaDBでデータベースを生成

sudo mysql
CREATE DATABASE redmine CHARACTER SET utf8mb4; CREATE USER 'redmine'@'localhost' IDENTIFIED BY 'password'; GRANT ALL PRIVILEGES ON redmine.* TO 'redmine'@'localhost'; \q

redmine をインストール・設定

sudo mkdir /var/lib/redmine
sudo chown www-data /var/lib/redmine
sudo -u www-data svn co https://svn.redmine.org/redmine/branches/4.2-stable /var/lib/redmine
sudo cp -p /var/lib/redmine/config/database.yml{.example,}
sudo vi /var/lib/redmine/config/database.yml

database.ymlを以下のように編集

--- /var/lib/redmine/config/database.yml.example        2022-06-14 07:48:44.550006498 +0000+++ /var/lib/redmine/config/database.yml        2022-06-14 07:50:28.124755810 +0000
@@ -6,8 +6,8 @@
   adapter: mysql2
   database: redmine
   host: localhost
-  username: root
-  password: ""
+  username: redmine
+  password: "password"
   # Use "utf8" instead of "utfmb4" for MySQL prior to 5.7.7
   encoding: utf8mb4
sudo cp -p /var/lib/redmine/config/configuration.yml{.example,}
sudo vi /var/lib/redmine/config/configuration.yml

configuration.ymlを以下のように編集

--- /var/lib/redmine/config/configuration.yml.example   2022-06-14 07:48:44.510007084 +0000+++ /var/lib/redmine/config/configuration.yml   2022-06-14 07:52:21.095751263 +0000
@@ -227,6 +227,12 @@
 # specific configuration options for production environment
 # that overrides the default ones
 production:
+  email_delivery:
+    delivery_method: :smtp
+    smtp_settings:
+      address: "localhost"
+      port: 25
+      domain: "ubuntu-redmine.example.com"

 # specific configuration options for development environment
 # that overrides the default ones

ruby の bundle install

cd /var/lib/redmine
sudo bundle install --without development test

トークン生成、データベース作成

sudo -u www-data bin/rake generate_secret_token
sudo -u www-data RAILS_ENV=production bin/rake db:migrate

passenger をインストール

sudo gem install passenger -N
sudo passenger-install-apache2-module --auto --languages ruby

Apache の設定

passenger-install-apache2-module --snippet
sudo vi /etc/apache2/conf-available/redmine.conf

redmine.confの中身

<Directory "/var/lib/redmine/public">
  Require all granted
</Directory>

LoadModule passenger_module /usr/local/lib/ruby/gems/2.7.0/gems/passenger-6.0.14/buildout/apache2/mod_passenger.so
<IfModule mod_passenger.c>
  PassengerRoot /usr/local/lib/ruby/gems/2.7.0/gems/passenger-6.0.14
  PassengerDefaultRuby /usr/local/bin/ruby
</IfModule>

PassengerMaxPoolSize 20
PassengerMaxInstancesPerApp 4
PassengerPoolIdleTime 864000
PassengerStatThrottleRate 10

<Directory /var/lib/redmine/public>
  Allow from all
  Options -MultiViews
  Require all granted
</Directory>

Alias /redmine /var/lib/redmine/public
<Location /redmine>
  PassengerBaseURI /redmine
  PassengerAppRoot /var/lib/redmine
</Location>

apacheの設定を読み込む

sudo a2enmod ssl
sudo a2ensite default-ssl
sudo a2enconf redmine
sudo apache2ctl configtest
sudo systemctl reload apache2

AWS (Amazon Lightsail) で Redmine サーバ作成

EC2よりも更に簡易なLightsailで、Redmineサーバを構築してみる。

1. 仮想マシンのデプロイ

WebブラウザでLightsailコンソールを表示する。

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

プラットフォームは「Linux/Unix」を選択(デフォルト)する。

画面を下へスクロールする。

設計図は「Redmine」を選択する。 SSHキーペアは、既にあるものを使う場合は何もしない。新たに作る場合は「SSH キーペアの変更」で作成する。

さらに下へスクロールすると、インスタンスプランの選択画面になる。少人数の利用であれば、デフォルトの512MB 1vCPUのプランでよい。

インスタンス名はわかりやすいものを自分で決める。ここではデフォルトが「Redmine-1」なので、それをそのまま利用した。

「インスタンスの作成」をクリックすると、実際に作成される。画面が切り替わって、 インスタンスがグレーアウトした状態で現れ「保留中」と表示されるので、しばらく待つ。

表示が「実行中」に変わったら、インスタンス名をクリックする。

2. シェルログイン

「SSHを使用して接続」をクリックすると、ブラウザでコンソールを表示できるので、今回はそちらを使ってみる。

※「パブリックIP」に表示されているグローバルIPv4アドレスへ、sshコマンドで接続してもよい。その場合はユーザ名bitnami、sshキーペアはインスタンス作成時に指定したものを使用する。

コンソールで cat bitnami_credentials を実行する。

上記のように、Redmineログイン用のユーザ名とパスワードが表示される。この場合はユーザ名「user」、パスワード「yXenWa2DLcJr」である。

3. Redmine ログイン

Webブラウザで、http://パブリックIP/ にアクセスする。

ログインしていない状態の Redmine が表示される。右上の「ログイン」をクリックする。

さきほどコンソールで表示したユーザ名「user」とパスワードを入力してログインする。

これで、管理者として Redmine にログインした状態となった。あとはブラウザ上から Redmine を操作していく。

4. 初期設定

まずは「Administration」→「Settings」→「Display」タブ→「Default language」を「Japanese(日本語)」に変更、「Save」をクリックする。

次に「Administration」→「Users」へ移動して、新しい管理者ユーザを作成する。*が付いている項目は入力必須である。「Administrator」にはチェックをつけておくこと。

作成出来たら、右上の「Sign out」をクリックしていったんログアウトし、さきほど作成したユーザを使い再ログインする。

ログイン出来たら、元の「user」ユーザを使えないようにしておく。「管理」→「ユーザー」へ移動して、「user」をロックまたは削除する。

AWS (Amazon EC2) で Redmine サーバ作成

課題管理サーバを立てる必要が出てきたので、AWS (EC2) でお手軽に作ってみた。

1.仮想マシンデプロイ

AWS コンソールで EC2 のインスタンス追加画面に行き、AWS Marketplace から検索で「Redmine Certified by Bitnami」を探す。

この AMI を利用して、t1.micro の仮想マシンを作成する。

2. 初回ログイン

sshで仮想マシンにログインする。ユーザ名はbitnami、ssh鍵はデプロイ時に指定したものを使う。

bitnamiユーザのホームディレクトリに “bitnami_credentials”というテキストファイルがあるので、中を閲覧する。Redmine上のユーザ名とパスワードが記載されている。

Welcome to the Bitnami Redmine Stack

******************************************************************************
The default username and password is 'user' and 'TBLwnBpotZT3'.
******************************************************************************

You can also use this password to access the databases and any other component the stack includes.
Please refer to https://docs.bitnami.com/ for more details.

https://RedmineホストのグローバルIPアドレス/ にアクセスして、ユーザ名: user パスワード: 上記テキスト内のパスワード でログインする。

実際に使うユーザを作成してシステム管理者権限を割り当て、そのユーザで再ログインして元々の「user」ユーザを削除する(セキュリティを考慮して)。

3. ホスト名の付与と SSL 証明書の取得

自分の所有ドメインがある場合は、ホスト名を割り当て、Let’s Encryptで証明書を取得することで正規の https サイトにする。

所有ドメインのゾーンファイルに、以下のようなAレコードを追加してリロードする。例示アドレスの 203.0.113.100 は Redmine ホストのグローバル IP アドレスとする。

redmine.example.com.    IN A     203.0.113.100

Redmine サーバに ssh ログインして、/opt/bitnami 以下にインストール済みの letsencrypt クライアント (lego) を利用する。

$ sudo /opt/bitnami/letsencrypt/scripts/generate-certificate.sh -m root@example.com -d redmine.example.com
...
It will create a certificate for the domain "redmine.example.com" under the email "root@example.com"
Do you want to continue? [y/n]: y
...
You can now configure a cronjob to renew it every month.
Do you want to proceed? [y/n]: y

Apache の設定も自動で書き換わるので、これで作業完了でもよいが、httpでアクセスされたらhttpsに転送するようにしておく。

$ sudo vi /opt/bitnami/apache2/conf/bitnami/bitnami.conf

13行目付近に太字の3行を追加
<Directory "/opt/bitnami/apache2/htdocs">
Options Indexes FollowSymLinks
AllowOverride All
RewriteEngine on
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
<IfVersion < 2.3>
Order allow,deny
Allow from all

28行目をコメントアウト
#Include "/opt/bitnami/apache2/conf/bitnami/bitnami-apps-prefix.conf"


$ sudo /etc/init.d/bitnami restart

X.509 証明書による IPsec 認証 (libreswan)

libreswan を使って、IPsec の X.509 証明書認証を検証する。

検証環境は前回記事と同様で、以下の図の通りである。

vpn1、vpn2、host1、host2、router1 OS は全て Ubuntu 18.04 である。

1. 証明書の用意

libreswan で証明書を扱う場合、NSS Tools の流儀に従って管理しなければならない。strongswan のようにファイルベースでの証明書管理はできないようなので、少し不便である。

vpn1 側の NSS Tools でオレオレ CA を作って、vpn1・vpn2 両方の証明書をここで作成することにする。あとでエクスポートして vpn2 へ持っていく。

1.1 初期化

最初に、NSS ライブラリの証明書ストアを両サーバで初期化する。Ubuntu の場合は標準のパスが /var/lib/ipsec/nss になっている。

user@vpn1:~$ sudo rm -f /var/lib/ipsec/nss/*.db
user@vpn1:~$ sudo ipsec initnss
user@vpn2:~$ sudo rm -f /var/lib/ipsec/nss/*.db
user@vpn2:~$ sudo ipsec initnss

1.2 CA鍵・証明書の作成

次に、vpn1 上で CA 鍵と証明書のセットを作成する。以下のように certutil コマンドを使用する。

user@vpn1:~$ sudo certutil -S -k rsa -n ca -s "CN=ca.example.com" -v 120 -t "CT,C,C" -x -d sql:/var/lib/ipsec/nss

A random seed must be generated that will be used in the
creation of your key. One of the easiest ways to create a
random seed is to use the timing of keystrokes on a keyboard.


To begin, type keys on the keyboard until this progress meter
is full. DO NOT USE THE AUTOREPEAT FUNCTION ON YOUR KEYBOARD!


Continue typing until the progress meter is full:

|***************************************************************|

Finished. Press enter to continue:

Generating key. This may take a few moments…

途中で、乱数の種としてキーボードからの入力を求められるので、適当にランダム入力する。

コマンドラインオプションについては、それぞれ以下のような意味がある。
-S は鍵・証明書の生成とデータベース登録を指示する。
-k は鍵のタイプを指定する。ここでは RSA を使う。
-n は、この鍵/証明書の NSS ストア内でのニックネームを指定する。
-s は、CA の CN (コモンネーム) を指定する。適当に決めてよい。
-v は、証明書の有効期限を指定する。(単位: 月)
-t "CT,C,C" は、証明書の信頼属性を指定する。
3つのフィールドの最初は SSL、2番目はメール、3番目はオブジェクト署名の用途を表す。
C は CA、T はクライアント認証証明書発行のための CA を表す。
IPsec の認証以外にこの CA を使うことがなければ、C,, だけでも良い。
-x は、自己署名証明書にすることを指定する。
-d sql:/var/lib/ipsec/nss は、証明書ストアのパスを表す。sql: を付けておかないと libreswan から利用できないので注意。

1.3 ホスト鍵・証明書の作成

次に、vpn1 のホスト鍵/証明書セットを作る。途中でキーボードからの入力を求められるのは先ほどと同様である。
user@vpn1:~$ sudo certutil -S -k rsa -c ca -n vpn1 -s "CN=vpn1.example.com" -v 60 -t "u,u,u" -d sql:/var/lib/ipsec/nss

コマンドラインオプションについては以下の通り。
-c で、先ほど作成した CA 鍵 (ニックネームが “ca”) での署名を指定する。
-n は、この鍵/証明書の NSS ストア内でのニックネームを指定する。あとでこれを利用する。
-s は、証明書の CN (コモンネーム) を指定する。ここでは vpn1 の FQDN にしておく。
-t "u,u,u" は、証明書の信頼属性を指定する。u はユーザ証明書を表す。

さらに、同じ作り方で vpn2 用の鍵・証明書を作る。同様に、ランダムキー入力が求められる。
user@vpn1:~$ sudo certutil -S -k rsa -c ca -n vpn2 -s "CN=vpn2.example.com" -v 60 -t "u,u,u" -d sql:/var/lib/ipsec/nss

ここまでで CA と vpn1 と vpn2 の 3セットの鍵・証明書が作成できた。

1.4 vpn2 用の鍵と証明書をエクスポート・インポート

vpn2 の鍵・証明書と、CA 証明書をファイルへエクスポートして、vpn2 へ持っていく。鍵を含むファイルは PEM 形式でエクスポートする方法が無いので、PKCS#12 形式でエクスポートする。
user@vpn1:~$ sudo certutil -L -n ca -a -d sql:/var/lib/ipsec/nss > ca.pem
user@vpn1:~$ sudo pk12util -n vpn2 -o vpn2.p12 -d sql:/var/lib/ipsec/nss
Enter password for PKCS12 file: password (適当に決めた PKCS#12 ファイル用パスワード)
Re-enter password: password (再度入力)
pk12util: PKCS12 EXPORT SUCCESSFUL
user@vpn1:~$ sudo chown user vpn2.p12

エクスポートしたファイルを vpn2 へネットワークコピーする。
user@vpn1:~$ scp ca.pem vpn2.p12 vpn2:
user@vpn1:~$ rm ca.pem vpn2.p12

vpn2 側でインポートする。
user@vpn2:~$ sudo certutil -A -a -i ca.pem -n ca -t 'CT,,' -d sql:/var/lib/ipsec/nss
user@vpn2:~$ sudo pk12util -i vpn2.p12 -d sql:/var/lib/ipsec/nss
Enter password for PKCS12 file: password (先ほど決めたパスワード)
pk12util: PKCS12 IMPORT SUCCESSFUL
user@vpn2:~$ rm ca.pem vpn2.p12

2. libreswan の設定

2.1 vpn1 側

vpn1 の libreswan 設定を編集する。

user@vpn1:~$ sudo vi /etc/ipsec.d/linux-to-linux.conf

conn linux-to-linux
	authby=rsasig
	auto=add
	dpdaction=clear
	leftcert=vpn1
	leftid="CN=vpn1.example.com"
	left=198.51.100.100
	leftsubnet=10.0.1.0/24
	rightid="CN=vpn2.example.com"
	right=203.0.113.100
	rightsubnet=10.0.2.0/24

leftcert に vpn1 を指定する。これは vpn1 証明書を作成した時のニックネームを指定している。

leftid、rightid は、それぞれの端点の Peer ID である。証明書の CN フィールドをダブルクォーテーションで囲って指定する。

2.2 vpn2 側

vpn2 の方も同様に設定する。

user@vpn2:~$ sudo vi /etc/ipsec.d/linux-to-linux.conf

conn linux-to-linux
	authby=rsasig
	auto=start
	dpdaction=restart
	leftcert=vpn2
	leftid="CN=vpn2.example.com"
	left=203.0.113.100
	leftsubnet=10.0.2.0/24
	rightid="CN=vpn1.example.com"
	right=198.51.100.100
	rightsubnet=10.0.1.0/24

2.3 再起動

デーモンを再起動する。
user@vpn1:~$ sudo systemctl restart ipsec
user@vpn2:~$ sudo systemctl restart ipsec

2.4 確認

接続状態を確認する。

user@vpn1:~$ sudo ip xfrm state
src 203.0.113.100 dst 198.51.100.100
        proto esp spi 0xc8f7a785 reqid 16389 mode tunnel
        replay-window 32 flag af-unspec
        auth-trunc hmac(sha1) 0xed85061c48c4fbc2dcce034191fb5a5a7c12d9e3 96
        enc cbc(aes) 0x7e39a613f56f3cb06b022561c0a8e65b
        anti-replay context: seq 0x0, oseq 0x0, bitmap 0x00000000
src 198.51.100.100 dst 203.0.113.100
        proto esp spi 0x90027aeb reqid 16389 mode tunnel
        replay-window 32 flag af-unspec
        auth-trunc hmac(sha1) 0xf3fa1c2609590b83e4c9c95b1ad38d80492f267a 96
        enc cbc(aes) 0x9e039bf741f7a4c7a9e1920d241fae65
        anti-replay context: seq 0x0, oseq 0x0, bitmap 0x00000000

参考:
HOWTO: Using NSS with libreswan
certutilによる証明書管理 [Fedora14]

Linux サーバ間 IPsec 接続 (libreswan)

Linux サーバ同士の間で libreswan を使って IPsec を接続してみる。strongswan を使ったやり方は別記事にて。

I. 前提

環境は以下の通り。

vpn1、vpn2、host1、host2、router1 OSは全てUbuntu 18.04である。

vpn1←→vpn2の間で、libreswanでトンネルモードIPsec接続をする。10.0.1.0/24 から 10.0.2.0/24 へのパケット、またその逆方向のパケットはトンネルへ入るようにする。つまり、例えばhost1からhost2へpingを打つとトンネルを通ることになる。10.0.1.0/24や10.0.2.0/24へのスタティックルートはrouter1に追加しないようにしておくので、VPNトンネルが出来なければhost1からhost2へのpingは到達できない。

vpn2側に自動接続開始の設定を入れることで、VPNトンネルを自動的に張ることにする。

II. 設定

以下、設定を記述する(IPアドレス設定など基本的なところは省略)

1. router1 の設定:

通過パケットを転送できるように、カーネルパラメータを変更する。
user@router1:~$ sudo vi /etc/sysctl.conf

net.ipv4.ip_forward=1  #28行目のコメントを外す

上記カーネルパラメータを有効化する。
user@router1:~$ sudo sysctl -p /etc/sysctl.conf

2. vpn1の設定:

libreswan をインストールする。このネットワーク構成ではインターネットからの apt install 不可なので、インターネット接続可能なネットワークに一時的に接続しておく。
user@vpn1:~$ sudo apt install libreswan

インストールが終わったら、ネットワーク構成を検証用の構成に戻す。以下のように netplan 設定ファイルを編集する。
user@vpn1:~$ vi /etc/netplan/50-cloud-init.yaml

network:
    version: 2
    ethernets:
        ens160:
            addresses: [198.51.100.100/24]
            gateway4: 198.51.100.1
        ens192:
            addresses: [10.0.1.1/24]

編集したら適用する。
user@vpn1:~$ sudo netplan apply

カーネルパラメータを設定する。
user@vpn1:~$ sudo vi /etc/sysctl.conf

net.ipv4.ip_forward=1  #28行目のコメントを外す

上記カーネルパラメータを有効化する。
user@vpn1:~$ sudo sysctl -p /etc/sysctl.conf

IPsecの事前共有鍵を設定する。
user@vpn1:~$ sudo vi /etc/ipsec.d/linux-to-linux.secrets

: PSK "mypresharedkey"

一般ユーザで読めないようパーミッションを変えておく。
user@vpn1:~$ sudo chmod 600 /etc/ipsec.d/linux-to-linux.secrets

IPsecの接続設定を記述する。
user@vpn1:~$ sudo vi /etc/ipsec.d/linux-to-linux.conf

conn linux-to-linux
        authby=secret		# 共有鍵認証とする
        auto=add		# こちら側からはVPN接続を自動開始しない
        dpdaction=clear
        left=198.51.100.100	# 自ホストのIPアドレス
        leftsubnet=10.0.1.0/24	# 自分側のプライベートネットワーク
        right=203.0.113.100	# 対向側ホストのIPアドレス
        rightsubnet=10.0.2.0/24	# 対向側のプライベートネットワーク

デーモンを起動する。
user@vpn1:~$ sudo systemctl enable ipsec
user@vpn1:~$ sudo systemctl start ipsec

3. vpn2 の設定:

vpn1 と同様に、libreswan をインストールする。検証構成ではインターネットからの apt install 不可なのも vpn1 と同様である。一時的にインターネット接続可能なネットワークに接続しておく。
user@vpn2:~$ sudo apt install libreswan

インストールが終わったら、ネットワーク構成を検証用の構成に戻す。
user@vpn2:~$ vi /etc/netplan/50-cloud-init.yaml

network:
    version: 2
    ethernets:
        ens160:
            addresses: [203.0.113.100/24]
            gateway4: 203.0.113.1
        ens192:
            addresses: [10.0.2.1/24]

編集したら適用する。
user@vpn2:~$ sudo netplan apply

カーネルパラメータを設定する。
user@vpn2:~$ sudo vi /etc/sysctl.conf

net.ipv4.ip_forward=1  #28行目のコメントを外す

上記カーネルパラメータを有効化する。
user@vpn2:~$ sudo sysctl -p /etc/sysctl.conf

IPsec 事前共有鍵を設定する。
user@vpn2:~$ sudo vi /etc/ipsec.d/linux-to-linux.secrets

: PSK "mypresharedkey"

一般ユーザで読めないようパーミッションを変えておく。
user@vpn2:~$ sudo chmod 600 /etc/ipsec.d/linux-to-linux.secrets

IPsec の設定を記述する。right/left を vpn1 側とは入れ換える。
user@vpn2:~$ sudo vi /etc/ipsec.d/linux-to-linux.conf

conn linux-to-linux
        authby=secret
        auto=start		# こちら側から VPN 接続を自動開始する
        dpdaction=restart
        left=203.0.113.100
        leftsubnet=10.0.2.0/24
        right=198.51.100.100
        rightsubnet=10.0.1.0/24

デーモンを起動する。
user@vpn2:~$ sudo systemctl enable ipsec
user@vpn2:~$ sudo systemctl start ipsec

これで完成。

III. 確認

ipsec status コマンドで、接続状況を確認できる。

user@vpn1:~$ sudo ipsec status
(snip)
000 #3: "linux-to-linux":500 STATE_MAIN_R3 (sent MR3, ISAKMP SA established); EVENT_SA_REPLACE in 3326s; newest ISAKMP; lastdpd=-1s(seq in:0 out:0); idle; import:not set
000 #4: "linux-to-linux":500 STATE_QUICK_R2 (IPsec SA established); EVENT_SA_REPLACE in 28526s; newest IPSEC; eroute owner; isakmp#3; idle; import:not set
000 #4: "linux-to-linux" esp.a61da06f@203.0.113.100 esp.53ec235d@198.51.100.100 ref=0 refhim=0 Traffic: ESPin=0B ESPout=0B! ESPmax=4194303B

router1 で tcpdump を仕掛けておき、host1 から host2 あてに ping を打ってみる。
user@host1:~$ ping 10.0.2.100
user@router1:~$ sudo tcpdump -n -i ens192 not tcp port 22
15:27:34.103230 IP 198.51.100.100 > 203.0.113.100: ESP(spi=0xa61da06f,seq=0x1), length 132
15:27:34.103475 IP 203.0.113.100 > 198.51.100.100: ESP(spi=0x53ec235d,seq=0x1), length 132
15:27:35.131026 IP 198.51.100.100 > 203.0.113.100: ESP(spi=0xa61da06f,seq=0x2), length 132
15:27:35.131271 IP 203.0.113.100 > 198.51.100.100: ESP(spi=0x53ec235d,seq=0x2), length 132

ESPにカプセル化されてパケットが通過していることが確認できた。

※パケットがトンネルに入るか入らないかは、IP ルーティングではなく xfrm ポリシーによって決まっている。
ip xfrm policy コマンドで確認できる。

user@vpn1:~$ sudo ip xfrm policy
src 10.0.1.0/24 dst 10.0.2.0/24
        dir out priority 2344
        tmpl src 198.51.100.100 dst 203.0.113.100
                proto esp reqid 16389 mode tunnel
src 10.0.2.0/24 dst 10.0.1.0/24
        dir fwd priority 2344
        tmpl src 203.0.113.100 dst 198.51.100.100
                proto esp reqid 16389 mode tunnel
src 10.0.2.0/24 dst 10.0.1.0/24
        dir in priority 2344
        tmpl src 203.0.113.100 dst 198.51.100.100
                proto esp reqid 16389 mode tunnel
(snip)

CentOS7 + nginx + phpMyAdmin

CentOS7にphpMyAdminをEPEL経由でインストールしてみた。

環境:
OS: CentOS 7.5
Webサーバ: nginx (EPELパッケージ)
PHP: php-fpm 5.4.16 (CentOS標準パッケージ)
DB: MariaDB 5.5.56 (CentOS標準パッケージ)

1. nginxインストール

EPELリポジトリを追加する(まだ追加していない場合)
$ sudo yum install epel-release

nginxをインストールする。
$ sudo yum install nginx
追加機能をコンパイルしたい場合は、SRPM を自前でリビルドしてもよい

あとは自分の用意したいWebサーバに合わせてバーチャルホスト設定ファイルを作成することになる。設定ファイルの中に、phpMyAdmin 用の記述を入れる。Apache 用の設定が /etc/httpd/conf.d/phpMyAdmin.conf にあるので、参考にする。

  root /usr/share/phpMyAdmin;
  ...
  location ~ ^/libraries/ { deny all; }
  location ~ ^/setup/lib/ { deny all; }
  location ~ ^/setup/frames/ { deny all; }
  location ~ ^/.*\.php$ {
    allow 203.0.113.100;		←自宅からのアクセス許可
    deny all;				←それ以外は全部拒否
    fastcgi_pass unix:/run/php-fpm/php-fpm.sock;
    include fastcgi_params;
    fastcgi_split_path_info ^(.+\.php)(/.+)$;
    fastcgi_param PATH_INFO $fastcgi_path_info;
    fastcgi_param PATH_TRANSLATED $document_root$fastcgi_path_info;
    fastcgi_param SCRIPT_FILENAME $document_root/$fastcgi_script_name;
  }
  location / {
    allow 203.0.113.100;
    deny all;
  }

$ sudo systemctl enable nginx
$ sudo systemctl start nginx

2. mariadb インストール・設定

$ sudo yum install mariadb mariadb-server
$ sudo systemctl enable mariadb
$ sudo systemctl start mariadb

rootパスワードの初期設定を行っておく。
$ mysql_secure_installation

3. phpインストール・設定

必要そうなパッケージをまとめてインストールしておく。
$ sudo yum install php-fpm php-mysql php-gd php-mbstring

phpの基本設定を行う。
$ sudo vi /etc/php.ini

expose_php = Off			←PHPの情報を隠す

ほかにもパフォーマンスチューニングのパラメータがphp.iniの中にあるので、必要に応じて変更しておく。

php-fpmとして動作するときの設定を行う。
$ sudo vi /etc/php-fpm.d/www.conf

listen = /run/php-fpm/php-fpm.sock	←UNIXソケットを利用
listen.owner = nginx			←UNIXソケットの所有者をnginx実行ユーザにする
listen.group = nginx
listen.mode = 0600			←nginx以外からソケットを利用できないようにする
user = nginx				←php-fpm実行ユーザをnginxにそろえておく
group = nginx

php-fpmデーモンを起動する。
$ sudo systemctl enable php-fpm
$ sudo systemctl start php-fpm

3. phpMyAdminインストール・設定

phpMyAdminをインストールする。
$ sudo yum install phpMyAdmin

必要なディレクトリの作成、nginxから読めるよう権限の修正を行う。
$ sudo mkdir -p /var/lib/php/session
$ sudo chown nginx:nginx /var/lib/php/session
$ sudo chgrp -R nginx /etc/phpMyAdmin
$ sudo chown -R nginx:nginx /var/lib/phpMyAdmin

phpMyAdminに必要なDB・テーブルの作成を行う。
$ mysql -u root -p
Enter password:
MariaDB [(none)]> source /usr/share/phpMyAdmin/sql/create_tables.sql;
MariaDB [(none)]> \q

あとはWebブラウザで http://自分のサーバ/phpMyAdmin/ にアクセスし、動作確認を行う。

LM ハッシュパスワードと NTLM ハッシュパスワードの生成

現代において、NTLM ハッシュや LM ハッシュを使うこともそうそうないのだが、無線 LAN の PEAP 認証で mschap を利用する場合は必要となるので、手動生成する方法を調べてみた。

ハッシュの作り方説明は、Wikipedia の該当ページにある。

NTLM ハッシュについては、シェルスクリプトのワンライナーでも生成できる。
$ printf "pass_string" | iconv -f utf-8 -t utf-16le | openssl md4 | awk '{print $2}' | tr '[a-z]' '[A-Z]'

LM ハッシュの方はもう少し手順が面倒くさいので、ワンライナーでは無理な感じだ。車輪の再発明は避けて、既存のコードをもらってくることにする。

php によるコード
C によるコード (mkntpwdコマンド)
あたりをもらってくると良い。

また FreeRADIUS がインストールしてあれば、付属の smbencrypt コマンドが使えるはず。

openssl s_client で SMTP STARTTLS と SMTP AUTH を動作確認する

概要: openssl s_client コマンドについて

telnet コマンドで HTTP や SMTP、POP の接続テストを行うことがあるが、同様に openssl の s_client サブコマンドで、TLS 接続の手動確認をすることが可能だ。例えば、HTTPS の確認は以下のように実行できる。

$ openssl s_client -connect www.example.com:443
(中略)
GET / HTTP/1.0(Enter)
Host: www.example.com(Enter2回押す)

さらに、最初は平文接続して、アプリケーションプロトコル上の STARTTLS コマンドで TLS 状態に入りたい場合もある。SMTP、IMAP、LDAP、FTP などの STARTTLS が相当する。これも s_client サブコマンドの -starttls オプションで実現できる。

mail.example.com サーバの TCPポート 587 (SMTP Submission) で SMTP STARTTLS が使える場合、以下のコマンドで接続が可能となる。-starttls オプションの引数に、smtp をとる。

$ openssl s_client -connect mail.example.com:587 -starttls smtp

ただし、SMTP セッションの中で RCPT TO: を大文字で打った瞬間に、RENEGOTIATING という表示とともに先へ進めなくなってしまうので注意が必要である。

$ openssl s_client -connect mail.example.com:587 -starttls smtp
CONNECTED(00000003)
depth=2 C = JP, O = "SECOM Trust Systems CO.,LTD.", OU = Security Communication RootCA2
verify return:1
depth=1 C = JP, L = Academe, O = National Institute of Informatics, CN = NII Open Domain CA - G4
verify return:1
depth=0 C = JP, L = Academe, O = Example, OU = Example Dept, CN = mail.example.com
verify return:1
(中略)
250 DSN
EHLO mail.example.com
250-mail.example.com
250-PIPELINING
250-SIZE 52428800
250-ETRN
250-AUTH PLAIN LOGIN
250-AUTH=PLAIN LOGIN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
MAIL FROM: test@example.com
250 2.1.0 Ok
RCPT TO: test@example.jp
RENEGOTIATING
depth=2 C = JP, O = "SECOM Trust Systems CO.,LTD.", OU = Security Communication RootCA2
verify return:1
depth=1 C = JP, L = Academe, O = National Institute of Informatics, CN = NII Open Domain CA - G4
verify return:1
depth=0 C = JP, L = Academe, O = Example, OU = Example Dept, CN = mail.example.com
verify return:1

標準入力の一文字目が大文字の「R」になっていると、openssl s_client の TLS 再ネゴシエーションコマンドとして解釈されてしまうためである。

再ネゴシエーションを回避するには、先頭の r を小文字で打つか、openssl s_client のオプションとして -ign_eof または -quiet を追加する。

$ openssl s_client -quiet -connect mail.example.com:587 -starttls smtp

SMTP AUTH のテスト

上記の openssl s_client コマンドを用いて、SMTP のセッションを手打ちで再現テストする。さらに SMTP セッションの中で、SMTP AUTH のテストも組み込んでみる。

実行例1: AUTH PLAIN 認証

SMTP AUTH の PLAIN コマンドで必要な文字列は、「ユーザ名\0ユーザ名\0パスワード」(\0はヌル文字)という合成文字列を BASE64 エンコードしたものである。あらかじめ文字列を作っておく。

$ printf 'username\0username\0password' | base64
dXNlcm5hbWUAdXNlcm5hbWUAcGFzc3dvcmQ=

さきほどのエンコード文字列を AUTH PLAIN の引数として与える。

$ openssl s_client -quiet -connect mail.example.com:587 -starttls smtp
depth=2 C = JP, O = "SECOM Trust Systems CO.,LTD.", OU = Security Communication RootCA2
verify return:1
depth=1 C = JP, L = Academe, O = National Institute of Informatics, CN = NII Open Domain CA - G4
verify return:1
depth=0 C = JP, L = Academe, O = Example, OU = Example Dept, CN = mail.example.com
verify return:1
250 DSN
EHLO mail.example.com
250-mail.example.com
250-PIPELINING
250-SIZE 10485760
250-ETRN
250-AUTH PLAIN LOGIN
250-AUTH=PLAIN LOGIN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
AUTH PLAIN dXNlcm5hbWUAdXNlcm5hbWUAcGFzc3dvcmQ=
235 2.7.0 Authentication successful ←認証成功
MAIL FROM: test@example.com
250 2.1.0 Ok
RCPT TO: test@example.jp
250 2.1.5 Ok ←メールリレー成功
QUIT
221 2.0.0 Bye

実行例2: AUTH LOGIN 認証

AUTH LOGIN コマンドでは、ユーザ名とパスワードをそれぞれ BASE64 エンコードした文字列が必要になる。

$ printf 'username' | base64
dXNlcm5hbWU=
$ printf 'password' | base64
cGFzc3dvcmQ=

サーバからの 334 VXNlcm5hbWU6 に対してはユーザ名のエンコード文字列を、334 UGFzc3dvcmQ6 に対してはパスワードのエンコード文字列を入力する。

$ openssl s_client -quiet -connect mail.example.com:587 -starttls smtp
depth=2 C = JP, O = "SECOM Trust Systems CO.,LTD.", OU = Security Communication RootCA2
verify return:1
depth=1 C = JP, L = Academe, O = National Institute of Informatics, CN = NII Open Domain CA - G4
verify return:1
depth=0 C = JP, L = Academe, O = Example, OU = Example Dept, CN = mail.example.com
verify return:1
250 DSN
EHLO mail.example.com
250-mail.example.com
250-PIPELINING
250-SIZE 10485760
250-ETRN
250-AUTH PLAIN LOGIN
250-AUTH=PLAIN LOGIN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
AUTH LOGIN
334 VXNlcm5hbWU6 ←"Username:" が BASE64 エンコードされている
dXNlcm5hbWU=
334 UGFzc3dvcmQ6 ←"Password:" が BASE64 エンコードされている
cGFzc3dvcmQ=
235 2.7.0 Authentication successful ←認証成功
MAIL FROM: test@example.com
250 2.1.0 Ok
RCPT TO: test@example.jp
250 2.1.5 Ok ←メールリレー成功
QUIT
221 2.0.0 Bye

参考URL:

Ubuntu 18.04 + MariaDB

Ubuntu 標準パッケージの MariaDB を使うにあたってハマりそうな箇所を記述してみる。

DB root ユーザでの接続に失敗する

MariaDB/MySQL データベースを使い始めるときは、まず mysql_secure_installation コマンドで状態を初期化して root パスワードを設定するのが一般的だろう。そして、設定したパスワードを使って DB root 接続し、アプリケーション等に必要なデータベースや DB 一般ユーザを作成する。この手順を実行しようとすると、DB に root ログインできない (パスワード認証が通らない) という事象にぶち当たる。

user@bionic$ sudo mysql_secure_installation (初期化してrootパスワードを設定)
Set root password? [Y/n]y
New password: testpass01
Re-enter new password: testpass01
Remove anonymous users? [Y/n]y
Disallow root login remotely? [Y/n]y
Remove test database and access to it? [Y/n]y
Reload privilege tables now? [Y/n]y

user@bionic$ mysql -u root -p
Enter password: testpass01
ERROR 1698 (28000): Access denied for user 'root'@'localhost' ←認証エラー!

上記動作の原因は、初期状態の DB root ユーザ認証に unix_socket 認証プラグインが使われていることである。この状態では、DB root として接続するために OS の root 権限にならなければならない (sudo または su コマンドを使う)。OS root になっていれば、以下のようにパスワードなしで DB root として接続可能である。

user@bionic:~$ sudo mysql
Welcome to the MariaDB monitor.  Commands end with ; or \g.
Your MariaDB connection id is 35
Server version: 10.1.29-MariaDB-6 Ubuntu 18.04

Copyright (c) 2000, 2017, Oracle, MariaDB Corporation Ab and others.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

MariaDB [(none)]>

DB root でログインすると、認証プラグインの状態も確認できる。

MariaDB [(none)]> SELECT user,host,plugin from mysql.user;
+------+-----------+-------------+
| user | host      | plugin      |
+------+-----------+-------------+
| root | localhost | unix_socket | ← unix_socket 認証プラグインが使われている
+------+-----------+-------------+
1 row in set (0.00 sec)

さて、この認証方式をそのまま使うか?それとも昔ながらのパスワード認証に戻すか?

初期状態の認証設定でそのまま利用する

初期設定に乗っかっていくなら、DB の root パスワードを設定する必要がない。

また一般ユーザでも同一の仕組みを使う場合は、UNIX ユーザと DB ユーザを同名で作成すればよい。

(ただし、この認証方式では外部ホストから TCP/3306 経由でログインできないことになる。必ずローカルの UNIX ドメインソケット経由でなければならない)

以下はブログエンジン WordPress を「wordpress」というユーザ名で利用する場合の例。OS の wordpress ユーザを作り、DB の wordpress ユーザも作成する。

user@bionic:~$ sudo useradd -m -s /bin/bash wordpress
user@bionic:~$ sudo mysql
MariaDB [(none)]> CREATE USER wordpress@localhost IDENTIFIED VIA unix_socket;

wordpress ユーザで接続できるかどうか確認する。

user@bionic:~$ sudo -i -u wordpress
wordpress@bionic:~$ mysql -u wordpress
Welcome to the MariaDB monitor.  Commands end with ; or \g.
Your MariaDB connection id is 57
Server version: 10.1.29-MariaDB-6 Ubuntu 18.04

Copyright (c) 2000, 2017, Oracle, MariaDB Corporation Ab and others.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

MariaDB [(none)]> \q
Bye

このやり方では、WordPress のファイル群を実行する PHP の実行ユーザが wordpress ユーザである必要がある。例えば PHP 実行環境に php-fpm を使っている場合は、/etc/php/7.2/fpm/pool.d/www.confを編集して php-fpm 実行ユーザを wordpress に変更する。

/etc/php/7.2/fpm/pool.d/www.conf 抜粋

user = wordpress
group = wordpress

wordpressデータベースの作成

user@bionic:~$ sudo mysql
MariaDB [(none)]> CREATE DATABASE wordpress;
MariaDB [(none)]> GRANT SELECT,INSERT,UPDATE,DELETE,CREATE,INDEX,ALTER ON wordpress.* TO wordpress@localhost;

wordpress 側の設定 (wp-config.php) では、パスワードを空にしておく。

define('DB_NAME', 'wordpress');
define('DB_USER', 'wordpress');
define('DB_PASSWORD', '');
define('DB_HOST', 'localhost');

従来のパスワード認証を使っていく場合

DB の root ユーザを従来のパスワード認証に変更する (以前の方式に戻す) 。私自身は、こちらの手法で行くことにする。

user@bionic:~$ sudo mysql
MariaDB [(none)]> set password for 'root'@'localhost'=password('testpass02');
MariaDB [(none)]> use mysql;
MariaDB [mysql]> update user set plugin='' where user='root';
MariaDB [mysql]> flush privileges;
MariaDB [mysql]> \q

root ユーザの認証プラグインを外し、通常のパスワードを設定している。

一般ユーザについても、通常のパスワードを設定して作成する。

user@bionic:~$ mysql -u root -p
Enter password: testpass02
MariaDB [(none)]> CREATE USER wordpress@localhost IDENTIFIED BY 'testpass03';

この場合、ログローテートの処理 (/etc/logrotate.d/mysql-server の16行目) にrootパスワードが必要になる。/etc/mysql/debian.cnf の password 行に平文パスワードを記述しておくこと。
user@bionic:~$ sudo vi /etc/mysql/debian.cnf

5行目、10行目
password = testpass02