作成者別アーカイブ: yattenator

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 コマンドについて

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_clinet の -starttls オプションで実現できる。

SMTPの場合、以下のコマンドで接続可能だ。

$ openssl s_client -connect mail.example.com:587 -starttls 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 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 CN = mail.example.com
verify return:1

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

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

$ openssl s_client -quiet -connect mail.example.com:587 -starttls 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 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 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
dXNlcm5hbWU=
334 UGFzc3dvcmQ6
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:~$ sudo mysql
MariaDB [(none)]> CREATE USER wordpress@localhost IDENTIFIED BY 'testpass03';

Linux 同士の IPv6 IPsec 接続

個人的なことだが、自宅のフレッツ回線とプロバイダがIPv6ネイティブ方式 (IPoE) に対応したため、自宅内のノードに IPv6 グローバルアドレスを割り当てられるようになった。

これを利用して、自分で借りた「さくらの VPS」(こちらも IPv6 グローバルアドレスが付与される)と自宅内サーバの間に IPv6 IPsecトンネルを作成してみる。

前提環境:
自宅サーバ: Raspbian stretch + strongswan
自宅内グローバルIPv6アドレス範囲: 2001:db8:1234:5678::/64
自宅サーバIPv6アドレス: 2001:db8:1234:5678:9012:3456:7890:1234
VPS: CentOS 7.4 + strongswan
VPS グローバル IPv6 アドレス: 2001:db8:abcd:efab:cdef:abcd:efab:cdef
認証方式: X.509 証明書

1. 証明書の作成

オレオレ CA を作成して証明書を発行する。IPv4で構築した時の記事を参照のこと。

2. VPS 側の設定

strongswan をインストールする。

$ sudo yum install epel-release
$ sudo yum install strongswan

カーネルモジュールをロードする。
strongswan公式ドキュメントを参照して、必要なモジュールがロードされていない場合は手動でロードする。

$ sudo modprobe xfrm6_tunnel

設定ファイル
/etc/strongswan/ipsec.conf:

conn myhome-to-vps6
        authby=rsasig
        auto=add
        closeaction=clear
        dpdaction=clear
        leftid="C=JP, ST=Aichi, O=Home, OU=Server, CN=myvps1.example.jp"
        leftsubnet=2001:db8:abcd:efab:cdef:abcd:efab:cdef/128
        leftcert=myvps1.crt
        right=%any
        rightid="C=JP, ST=Aichi, O=Home, OU=Server, CN=myserver1.example.com"
        rightsubnet=2001:db8:1234:5678::/64
        ike=aes256-sha512-modp8192!
        esp=aes256-sha512
        keyexchange=ikev2

/etc/strongswan/ipsec.secrets:

: RSA myvps1.key

strongswanサービス起動

$ sudo systemctl enable strongswan
$ sudo systemctl start strongswan

3. 自宅内サーバ側の設定

strongswanをインストールする。こちらは Raspbian なので apt コマンドで。

$ sudo apt install strongswan

必要なカーネルモジュールをロードする。

$ sudo modprobe xfrm6_tunnel
$ sudo modprobe esp6

設定ファイル
/etc/ipsec.conf:

conn myhome-to-vps6
        authby=rsasig
        auto=start
        closeaction=restart
        dpdaction=restart
        leftid="C=JP, ST=Aichi, O=Home, OU=Server, CN=myserver1.example.com"
        leftsubnet=2001:db8:1234:5678::/64
        leftcert=myserver1.crt
        right=2001:db8:abcd:efab:cdef:abcd:efab:cdef
        rightid="C=JP, ST=Aichi, O=Home, OU=Server, CN=myvps1.example.jp"
        rightsubnet=2001:db8:abcd:efab:cdef:abcd:efab:cdef/128
        ike=aes256-sha512-modp8192!
        esp=aes256-sha512
        keyexchange=ikev2

/etc/ipsec.secrets:

: RSA myserver1.key

strongswanサービスを起動する。

$ sudo systemctl enable strongswan
$ sudo systemctl start strongswan

OpenVPN で L2VPN を作成する

自宅内のVPN Gatewayに、OpenVPNとブリッジインターフェイスを使って、レイヤー2 VPNを作成する。自宅外からVPN接続したとき、bonjourやWindowsネットワーク検索のように、同一ネットワークセグメントで利用可能なサービスが自宅内と同様に使えるのがメリット。

サーバ: Raspberry Pi 2 (Raspbian 9.0 stretch)
環境は以下の図の通り。

この文書の手順以外に別途、外部接続ルータでサービスポートを外部公開しておく必要がある。

Apple iOS系デバイスはtapに対応していないため、Layer2 VPNを利用できないので注意。Android系もroot権限なしの標準APIとそれを利用する標準クライアントではtapに対応していない(有料ソフトウェアのOpenVPN Clientはtapに対応している)。

1. OpenVPN パッケージインストール

$ sudo apt install openvpn bridge-utils

2. ネットワークインターフェイスをbridge設定にする

eth0デバイスを直接使わず、ブリッジデバイスbr0を使ってeth0をそのメンバーとするように設定する。IPアドレスはDHCP範囲外の固定IPアドレスを利用することとする。

interfacesファイルを編集する。

$ sudo vi /etc/network/interfaces

auto br0
iface br0 inet static
        address 192.168.100.20
        netmask 255.255.255.0
        network 192.168.100.0
        broadcast 192.168.100.255
        gateway 192.168.100.1
        dns-nameservers 192.168.100.1
        dns-search home.private
        bridge_ports eth0

もともとeth0だったところをbr0にして、bridge_ports eth0 を追加するように編集する。

ここで一度再起動して、br0にIPアドレスが付くことを確認する。
$ sudo shutdown -r now

3. サーバ設定

OpenVPN サーバの設定ファイルを作成する。

$ sudo mkdir -p /var/log/openvpn /etc/openvpn/ccd
$ sudo cp /usr/share/doc/openvpn/examples/sample-config-files/server.conf.gz /etc/openvpn/server/
$ sudo gzip -d /etc/openvpn/server/server.conf.gz
$ sudo mv /etc/openvpn/server/{server,udp7231}.conf
$ sudo vi /etc/openvpn/server/udp7231.conf

port 7231
proto udp
dev tap
ca ca.crt
cert server.crt
key server.key
dh dh2048.pem
client-config-dir ccd
server-bridge 192.168.100.0 255.255.255.0 192.168.100.192 192.168.100.223
push "dhcp-option DNS 192.168.100.1"
push "dhcp-option DOMAIN-SEARCH home.private"
client-to-client
keepalive 10 120
tls-auth ta.key 0
cipher AES-256-CBC
comp-lzo
user nobody
group nogroup
persist-key
persist-tun
status /var/log/openvpn/openvpn-status.log
log-append  /var/log/openvpn/openvpn.log
verb 3

トランスポート層プロトコルは UDP を利用する(TCP over TCP問題を避けるため)。利用するポートは念のため標準の 1194 から変え、適当にランダムで決める。今回は 7231 とした。

4. サーバ証明書の準備

easy-rsaパッケージを利用してCAを作成し、サーバ証明書・鍵を作成する。CA 作業用ディレクトリとして、/etc/openvpn/easy-rsa を作成する。

$ sudo make-cadir /etc/openvpn/easy-rsa
$ sudo -i
# cd /etc/openvpn/easy-rsa
# ln -s openssl-1.0.0.cnf openssl.cnf
# vi vars

以下のような設定をvarファイルに記述する。

export KEY_SIZE=2048
export KEY_COUNTRY="JP"
export KEY_PROVINCE="Aichi"
export KEY_CITY="Nagoya"
export KEY_ORG="Home"
export KEY_EMAIL="root@raspberrypi.home.private"
export KEY_OU="Server"

CAを作成し、サーバ鍵・証明書を作成する。

# . vars
# ./clean-all
# ./build-ca
# ./build-key-server server

TLS Static Key と DH Keyを作成する。DH Keyの生成にはかなりの時間がかかる(Raspberry Piでは10分以上)

# openvpn --genkey --secret /etc/openvpn/server/ta.key
# ./build-dh
# cp -p keys/ca.crt keys/server.crt keys/server.key keys/dh2048.pem /etc/openvpn/server/
# exit

5. OpenVPNサービスの有効化と起動

サーバ側 OpenVPN サービス用の systemd ユニットファイルは /lib/systemd/system/openvpn-server@.service である。@の後にサーバ側 conf ファイルのドットより前の名前(今回の場合は “udp7231″)を指定して有効化・起動する。

サービスを有効化し、起動する。
$ sudo systemctl enable openvpn-server@udp7231
Created symlink /etc/systemd/system/multi-user.target.wants/openvpn-server@udp7231.service → /lib/systemd/system/openvpn-server@.service.
$ sudo systemctl start openvpn-server@udp7231

これだけだと、ブリッジデバイスに tap0 デバイスが組み込まれず、通信できない。/etc/systemd 以下に追加の systemd ユニットファイルを作成し、tap0 デバイスをブリッジに追加する。

$ sudo vi /etc/systemd/system/openvpn-bridge.service

[Unit]
Description=OpenVPN bridge service
Requires=openvpn-server@udp7231.service
After=openvpn-server@udp7231.service

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/bin/sh -c '/sbin/brctl addbr br0 || /bin/true'
ExecStartPost=/bin/sh -c '/sbin/brctl addif br0 tap0 || /bin/true'
ExecStartPost=/sbin/ip link set tap0 up
ExecReload=/bin/true
ExecStop=/sbin/brctl delif br0 tap0

[Install]
WantedBy=multi-user.target

brctl addbr br0 の行は本来必要ないはず(br0 の立ち上げは /etc/network/interfaces に書いてあれば自動的に実行される)なのだが、タイミングの問題で openvpn サービス起動時にまだ br0 が無い場合があり、次の行の brctl addif br0 tap0 に失敗することがあるため、念のため加えている。

ブリッジ用自作サービスを有効化し、起動する。
$ sudo systemctl enable openvpn-bridge
Created symlink /etc/systemd/system/multi-user.target.wants/openvpn-bridge.service → /etc/systemd/system/openvpn-bridge.service.
$ sudo systemctl start openvpn-bridge

6. iptables設定

OpenVPNサービスポートの、ローカルファイアウォール設定を開けておく。

iptablesの設定にiptables-persistentパッケージを利用している場合は、/etc/iptables/rules.v4を編集して以下の行を加える。

-A INPUT -p udp -m udp --dport 7231 -j ACCEPT

設定を再読み込みする。
$ sudo netfilter-persistent reload

もしiptables直接ではなくufwを使っているのであれば、以下のコマンドでサービスポートを開ける。
$ sudo ufw allow 7231/udp
$ sudo ufw reload

ブリッジ設定の場合、パケットフォワーディングの設定(sysctl -w net.ipv4.ip_forward=1)は不要。

7. クライアント側設定テンプレートの作成

設定を複数のクライアントに配布するため、元となるテンプレートファイルを作成する。

$ sudo cp /usr/share/doc/openvpn/examples/sample-config-files/client.conf /etc/openvpn/client/client.template
$ sudo vi /etc/openvpn/client/client.template

client
dev tap
proto udp
remote 203.0.113.10 7231
resolv-retry infinite
nobind
persist-key
persist-tun
remote-cert-tls server
key-direction 1
cipher AES-256-CBC
comp-lzo
<tls-auth>
ここに/etc/openvpn/server/ta.keyファイルの内容をペーストする。
</tls-auth>
<ca>
ここに/etc/openvpn/server/ca.crtファイルの内容をペーストする。
</ca>
<key>
</key>
<cert>
</cert>

証明書・鍵ファイル等を別ファイルの形で配布しても良いが、設定ファイルの中に取り込む形にしてみる。設定を単一ファイルで配布できれば取り回しが良いため。

8. クライアント証明書の発行と設定ファイルの作成

まず1番目のクライアント用の鍵・証明書を発行する。

$ sudo -i
# cd /etc/openvpn/easy-rsa
# . vars
# ./build-key client1
# exit

クライアント1のためのファイル (client1.ovpn) をテンプレートから作成する。

$ sudo cp /etc/openvpn/client/{client.template,client1.ovpn}
$ sudo vi /etc/openvpn/client/client1.ovpn

client1.ovpnファイルの中の<cert>, <key>各セクションの中に、作成した証明書(client1.crt)と鍵(client1.key)ファイルの内容をコピー&ペーストする。

作成した/etc/openvpn/client/client1.ovpnファイルを配布して、クライアントデバイスにインストールして接続確認する。

接続成功するようなら、client2、client3、…と設定ファイルを同様に作成していく。

ffmpeg vs libav

動画・音声コーデック界のスイスアーミーナイフと呼ばれる ffmpeg から、数年前に libav がforkして分裂した。

参考: ffmpegとlibavの背景事情

Debian/Ubuntu の標準パッケージは libav の方に追随したのだが、結局メンテナンス頻度の問題で ffmpeg に再度鞍替えしたらしい。

参考: Ubuntu 15.10 その12 – Libavが無くなり、FFmpegに戻りました

forkがあったときにどっちに付いていくかは微妙な問題だけど、単なるいちユーザーとしては多数派になった方が使えればどうでもいいのよ、と思わないでもない。ffmpeg コマンドを前提にして色々スクリプトを書いていたが、コマンドが avconv に変わって、また ffmpeg に変わって、しかも微妙に互換性がないという困ったことになっている。

OpenOffice.org とか MySQL とか、ほかにも色々あるはず。

nginx のモジュール追加リビルド (CentOS 7版)

nginx 公式や epel パッケージの nginx バイナリでは使いたいモジュールがコンパイルされていない。特に nginx-dav-ext-module、headers-more-nginx-module を使いたいので、ソースからビルドすることにする。

前提として、使用 OS は CentOS 7 である。

nginx 公式の RPM パッケージもあるが、この記事では epel リポジトリの nginx RPM をベースに、必要なモジュールの記述を追加して SRPM からリビルドしてみる。

1. コンパイルに必要なパッケージをインストール

$ sudo yum install gperftools-devel openssl-devel pcre-devel zlib-devel GeoIP-devel gd-devel perl-devel perl-ExtUtils-Embed libxslt-devel expat-devel git

2. epel リポジトリを追加

epel リポジトリを追加する。追加済みであれば作業の必要なし。
$ sudo yum install epel-release

3. SRPM の入手

SRPM をダウンロード・インストールする。
$ sudo yum install -y yum-utils
$ yumdownloader --source nginx
$ rpm -ivh nginx-1.12.2-2.el7.src.rpm

今後 yum update で勝手にアップデートされないように、epel レポジトリを無効化しておく。
$ sudo yum-config-manager --disable epel

4. カスタマイズ

SRPM の spec ファイルを編集する。
$ vi rpmbuild/SPECS/nginx.spec

以下、nginx.spec に青字の部分を追加する。

(46行目から)
%if 0%{?with_gperftools}
BuildRequires:     gperftools-devel
%endif
BuildRequires:     openssl-devel
BuildRequires:     pcre-devel
BuildRequires:     zlib-devel
BuildRequires:     expat-devel
BuildRequires:     git

Requires:          nginx-filesystem = %{epoch}:%{version}-%{release}

%if 0%{?rhel} || 0%{?fedora} < 24
# Introduced at 1:1.10.0-1 to ease upgrade path. To be removed later.
Requires:          nginx-all-modules = %{epoch}:%{version}-%{release}
%endif

Requires:          openssl
Requires:          pcre
Requires:          expat
Requires(pre):     nginx-filesystem

(172行目から)
%prep
%setup -q
git clone https://github.com/arut/nginx-dav-ext-module.git
git clone https://github.com/openresty/headers-more-nginx-module.git
%patch0 -p0

(234行目から)
    --with-pcre-jit \
    --with-stream=dynamic \
    --with-stream_ssl_module \
    --add-module=./nginx-dav-ext-module \
    --add-module=./headers-more-nginx-module \
%if 0%{?with_gperftools}
    --with-google_perftools_module \
%endif
(以下略)

5. ビルド、インストール

ビルドを実行する。
$ rpmbuild -ba rpmbuild/SPECS/nginx.spec

RPM が出来上がったらインストールする。すでに EPEL や nginx 公式 RPM をインストールしてしまっている場合は、先に削除しておくこと。

既存パッケージの削除:
$ sudo yum erase `rpm -qa | grep nginx`

カスタマイズした RPM のインストール:
$ sudo yum localinstall rpmbuild/RPMS/x86_64/nginx-1.12.2-2.el7.centos.x86_64.rpm rpmbuild/RPMS/x86_64/nginx-mod-*.rpm rpmbuild/RPMS/noarch/nginx-*.rpm

6. 起動

デーモンを起動する。
$ sudo systemctl enable nginx
$ sudo systemctl start nginx

Exchange Server が正常終了しなかった場合のデータベース復旧

Exchange Server の入ったサーバが、OSごと固まったり、ハードウェアトラブルで停止した場合の復旧方法を考えてみる。

ひとまずOSを立ち上げなおすことが出来たとして、Exchange Server を起動しようとするとデータベースが dirty shutdown 状態となっており、マウントできない場合がある。

こういう場合にマイクロソフトの提供している手順ドキュメントがあるのだが…
修復済みの Exchange データベースのサポート ポリシーの変更

上記ドキュメントの手順3を進める前にデータベースをマウントする必要がある。しかし手順1、2でデータベースを掃除したにもかかわらず、それでもマウントできないということもある。

実行例:

[PS] C:\Windows\system32> Mount-Database -Identity MailboxDB01 -force
データベース "MailboxDB01" をマウントできませんでした。エラー: Active Manager
 の操作に失敗しました。エラー: データベース操作が失敗しました。エラー:
 操作が失敗し、メッセージが生成されました:
 MapiExceptionDatabaseError: Unable to mount database. (hr=0x80004005, ec=1108)
Diagnostic context:
...

そういう場合はトランザクションログが壊れている可能性が高いので、ログファイルを削除(退避)するとよい。

トランザクションログファイルの状態を示すコマンドとして、eseutil /ml コマンドがある。

[PS] C:\Windows\system32> eseutil /ml D:\Exchange\MailboxDB01\E00

これで壊れているログファイルがどれなのかわかるが、ともかくデータベースと同一ディレクトリにある拡張子.logのファイル(拡張子を隠す設定になっていたら表示すること!)をすべて別フォルダに退避してからマウントコマンドを実行するとよい。

[PS] C:\Windows\system32> D:
[PS] D:\> cd \Exchange\MailboxDB01
[PS] D:\Exchange\MailboxDB01> mkdir backup
[PS] D:\Exchange\MailboxDB01> move *.log backup
[PS] D:\Exchange\MailboxDB01> Mount-Database -Identity MailboxDB01 -force

openswan vs strongswan vs libreswan

IPsec の実装として、openswan / strongswan / libreswan どれを使えばいいの?というお話。

どの実装もかつてのFreeS/WAN IPsecの末裔であって、似た設定で動作するのだけど微妙に書式が違う、というやっかいなことになっている。

openswan:
もうメンテされていない古い実装。Ubuntu 18.04 LTS も CentOS 7 もパッケージを用意していないので、あえて使う理由がない。
libreswan:
openswanのフォークで、現状メンテされている。RedHat/CentOS系は標準パッケージで用意されている。Debian/Ubuntu系にはパッケージなし。
strongswan:
ご先祖から大幅に書き直されたもの。Debian/Ubuntu系OSの場合は標準パッケージで用意されている。RedHat/CentOS系はepelレポジトリに入っている。

Fedora の場合は strongswan / libreswan どちらもパッケージが用意されている。

ということで、openswan は使わないものとして、あとは OS によってパッケージがある方を選んでおけば良いのではないか。

※2018/04/12追記: メジャーなディストリビューションのうち、現時点で Debian 9.x (stretch) についてはまだ libreswan パッケージが無く、openswan が残っている。Debian stretch の場合は、strongswan を使っておくのが良いだろう。

参考:
IPsec for Linux – strongSwan vs Openswan vs Libreswan vs other(?)