はじめに

先日、nginx 1.19.4 がリリースされ、ssl_conf_command ディレクティブが追加されました。
これにより、ChaCha20-Poly1305 を使った暗号スイートの運用が現実的になりました。

ChaCha20-Poly1305 の概要

RFC 7905 (2016/06) より、TLS における ChaCha20-Poly1305 の利用が標準化され、様々なライブラリで利用可能になっています。
OpenSSL だと 1.1.0 以降で利用可能です。

ChaCha20-Poly1305 は、ストリーム暗号である ChaCha20 とメッセージ認証符号である Poly1305 を組み合わせた、認証付き暗号です。

ChaCha20-Poly1305 はソフトウェア処理に向いた、簡潔なアルゴリズムです。
AES はハードウェア処理 (AES-NI) が利用できる環境ではとても高速ですが、ソフトウェア処理においては ChaCha20-Poly1305 の方が AES-GCM より 3 倍程度性能が出るようです。

このような性質から、TLS クライアントによっては、ネゴシエーション時にこの性能を考慮した暗号スイートリストを使うようになっています。

これまでの課題

TLS のネゴシエーションにおける暗号スイートは、クライアントとサーバの暗号スイートリストを比較することで、1 つに決定されます。
一般的な TLS サーバは、 サーバ側の暗号スイートリストを優先して 暗号スイートを決定するように設定されています。
つまり、クライアントの暗号スイートリストで AES-GCM または ChaCha20-Poly1305 が適切な優先度になっているのに、サーバの設定により決まった 1 つに決定されてしまいます。

これは、「サーバ側の暗号スイートリストを優先しつつ、特定の暗号スイート (特に ChaCha20-Poly1305) についてはクライアントの提示に従う」といった設定をすることで対処が可能ですが、これまで nginx の設定ファイルのみではできませんでした。

ssl_conf_command ディレクティブ

nginx 1.19.4 で追加された ssl_conf_command ディレクティブ により、OpenSSL の各種設定を、 SSL_CONF_cmd を通して行う事ができるようになりました。

下記の設定をすることで、 クライアントが ChaCha20 の暗号スイートを優先している場合はサーバも優先する という動作をさせることができます。

ssl_conf_command Options PrioritizeChaCha;

この設定を行い、Qualys SSL Labs SSL Server Test を行うと、下記のような表示が現れます。

バッチリですね。

(ちなみに、ssl_conf_command によって、下記のように TLSv1.3 の暗号スイートリストも設定が可能です。)

ssl_conf_command Ciphersuites TLS_AES_128_GCM_SHA256:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_256_GCM_SHA384;

おわりに

nginx の設定のみで、サーバ側での ChaCha20-Poly1305 の優先度を適切に制御できるようになったことで、運用が現実的になりました。

nginx 1.20 のリリースが楽しみですね。

• 参考
  • 新しいTLSの暗号方式ChaCha20-Poly1305 - ぼちぼち日記

はじめに

Amazon Linux 2 で TCP BBR を有効にするにあたって調べてみると、再起動を伴う手順ばかりなので、ほんとにそうなのか検証しました。

• 検証環境
  • OS: Amazon Linux 2 AMI
    • AMI: amzn2-ami-hvm-2.0.20190618-x86_64-gp2 (ami-0c3fd0f5d33134a76)
    • カーネル: 4.14.123-111.109.amzn2.x86_64
  • OS: Amazon Linux AMI 2018.03.0
    • AMI: amzn-ami-hvm-2018.03.0.20190611-x86_64-gp2 (ami-04b2d1589ab1d972c)
    • カーネル: 4.14.123-86.109.amzn1.x86_64

設定方法

結論から言うと、再起動せずに有効にできるようです。

sysctl の設定

# sysctl -w net.ipv4.tcp_congestion_control=bbr
# sysctl -w net.core.default_qdisc=fq

(もちろん、sysctl.conf にも書いておきましょう)

### /etc/sysctl.d/bbr.conf
net.ipv4.tcp_congestion_control = bbr
net.core.default_qdisc = fq

• sysctl -w するだけで関連のカーネルモジュール (tcp_bbr, sch_fq) は読み込まれていたので、modprobe する必要はなさそうです。
• 再起動するのであれば、設定はここまでで OK です。

qdisc の変更

multiqueue な NIC かどうかで手順がかわるので、まずはその確認です。

(multiqueue でない例)
# tc qdisc show
qdisc noqueue 0: dev lo root refcnt 2
qdisc pfifo_fast 0: dev eth0 root refcnt 2 bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1

(multiqueue な例)
# tc qdisc show
qdisc noqueue 0: dev lo root refcnt 2
qdisc mq 0: dev eth0 root
qdisc pfifo_fast 0: dev eth0 parent :2 bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
qdisc pfifo_fast 0: dev eth0 parent :1 bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1

変更します。

(multiqueue でない場合)
# tc qdisc replace dev eth0 root handle 1: fq quantum 3028 initial_quantum 15140

(multiqueue な場合)
# tc qdisc replace dev eth0 root handle 1: mq
# tc qdisc replace dev eth0 parent 1:1 handle 10: fq quantum 3028 initial_quantum 15140
# tc qdisc replace dev eth0 parent 1:2 handle 20: fq quantum 3028 initial_quantum 15140

• パラメタは、/etc/sysctl.d/bbr.conf を書いて再起動してみた検証時のものを踏襲しています。
  • 起動時に quantum は MTU の 2 倍、initial_quantum は 10 倍に設定されるようです。
  • パラメタ未指定だと大きな値になってしまいました。

確認

net.ipv4.tcp_congestion_control の確認

ss コマンドにて、 設定以後 に確立した TCP コネクションが bbr になっていれば OK です。

# ss -tni
State             Recv-Q              Send-Q                            Local Address:Port                            Peer Address:Port
ESTAB             0                   36                                  10.24.3.157:22                             203.0.113.123:48378
         bbr wscale:7,7 rto:212 rtt:9.556/10.213 ato:40 mss:1448 pmtu:9001 rcvmss:1448 advmss:8949 cwnd:36 bytes_acked:5357 bytes_received:4637 segs_out:59 segs_in:77 data_segs_out:55 data_segs_in:36 bbr:(bw:14.9Mbps,mrtt:4.306,pacing_gain:2.88672,cwnd_gain:2.88672) send 43.6Mbps lastsnd:4 lastrcv:4 lastack:4 pacing_rate 78.1Mbps delivery_rate 14.9Mbps app_limited busy:320ms unacked:1 rcv_rtt:5 rcv_space:26847 rcv_ssthresh:41423 minrtt:4.306

qdisc の確認

tc コマンドで確認

(multiqueue でない場合)
# tc qdisc show
qdisc noqueue 0: dev lo root refcnt 2
qdisc fq 1: dev eth0 root refcnt 2 limit 10000p flow_limit 100p buckets 1024 orphan_mask 1023 quantum 3028 initial_quantum 15140 low_rate_threshold 550Kbit refill_delay 40.0ms

(multiqueue な場合)
# tc qdisc show
qdisc noqueue 0: dev lo root refcnt 2
qdisc mq 1: dev eth0 root
qdisc fq 10: dev eth0 parent 1:1 limit 10000p flow_limit 100p buckets 1024 orphan_mask 1023 quantum 3028 initial_quantum 15140 refill_delay 40.0ms
qdisc fq 20: dev eth0 parent 1:2 limit 10000p flow_limit 100p buckets 1024 orphan_mask 1023 quantum 3028 initial_quantum 15140 refill_delay 40.0ms

アップローダの認証を API に行わせる、という設定をしていて、少しハマった。

こんな設定を入れてみたところ、クライアントからの POST リクエストが返ってこない。

location /api {
    proxy_pass http://backend-api;
}

location /uploader {
    auth_request /api/authn;
    client_max_body_size 0;

    proxy_buffering off;
    proxy_request_buffering off;
    proxy_pass http://backend-uploader;
}

ちょっと調べてみると、 auth_request によるサブリクエストをプロキシするときは、ボディを空にしないと行けないらしい。
これは 公式の例 にも書いてある。

そこで、下記の設定を入れると、今度は 500 が返るようになった。

location /api {
    proxy_pass http://backend-api;
}

location = /_api_authn {
    internal;
    proxy_set_header Content-Length "";
    proxy_pass_request_body off;
    proxy_pass http://backend-api/api/authn;
}

location /uploader {
    auth_request /_api_authn;
    client_max_body_size 0;

    proxy_buffering off;
    proxy_request_buffering off;
    proxy_pass http://backend-uploader;
}

エラーログにボディが大きすぎると出ていたので、下記のように client_max_body_size を入れたところ、望む動きになった。

location /api {
    proxy_pass http://backend-api;
}

location = /_api_authn {
    internal;
    client_max_body_size 0;   ### これを忘れていた！
    proxy_set_header Content-Length "";
    proxy_pass_request_body off;
    proxy_pass http://backend-api/api/authn;
}

location /uploader {
    auth_request /_api_authn;
    client_max_body_size 0;

    proxy_buffering off;
    proxy_request_buffering off;
    proxy_pass http://backend-uploader;
}

ボディを空にするために location を分けたので、当然内部のコンテキストも別になったのが原因。
考えてみるとそりゃそうだなんだけど、気づきにくいと思ったので、メモでした。

2020/02/04 追記

こんなことしなくても openssl.cnf でデフォルト設定できるんですね。知らなかった…。

経緯

openssl 1.1.1 で TLS 1.3 がサポートされましたね。

nginx でも使えますが、実はまだ完全ではありません。
ssl_ciphers を設定しても、TLS 1.3 の暗号スイートは、指定した順序にはならず、デフォルトの下記の順になってしまいます。

TLS_AES_256_GCM_SHA384
TLS_CHACHA20_POLY1305_SHA256
TLS_AES_128_GCM_SHA256

これは openssl で、TLS 1.3 の暗号スイートの設定インタフェースが、TLS 1.2 以前のものとは別になっているからです。

• #1670 (Chipers list order not respected for TLS 1.3) – nginx

コマンドラインでも別になっていますね。

$ openssl ciphers -help
Usage: ciphers [options]
Valid options are:
 -help              Display this summary
 -v                 Verbose listing of the SSL/TLS ciphers
 -V                 Even more verbose
 -s                 Only supported ciphers
 -tls1              TLS1 mode
 -tls1_1            TLS1.1 mode
 -tls1_2            TLS1.2 mode
 -tls1_3            TLS1.3 mode
 -stdname           Show standard cipher names
 -psk               include ciphersuites requiring PSK
 -srp               include ciphersuites requiring SRP
 -convert val       Convert standard name into OpenSSL name
 -ciphersuites val  Configure the TLSv1.3 ciphersuites to use   <== コレ

TLS 1.3 の暗号スイートは安全なものばかりなので良いんですが、AES256 が選択されてしまうのはちょっとオーバースペックです。

というわけで、対応されるまでの間は、ムリヤリ頑張って見る事にしました。

• バージョンメモ
  • nginx 1.15.7
  • openssl 1.1.1a

openssl にパッチを当てる

ssl_ciphers で設定できないので、ムリヤリ感が強いですが openssl にパッチを当て、デフォルトの暗号スイートを変更してしまいます。

あとは、通常と同じようにビルドします。

$ ./configure \
...snip...
--with-openssl=/path/to/openssl-1.1.1a \
--with-openssl-opt='-fPIC'

$ make -j$(nproc)
$ sudo make install

結果

SSL Server Test で見ても、ちゃんと望む順序になっています！

うーん、美しい…！

経緯

plantuml/plantuml-server:jetty は、 http://localhost:8080/ で動きますが、歴史的な経緯で http://localhost:8080/plantuml/ で動かしたいと思いました。

docker run 時に -e JAVA_OPTIONS="-Djetty.contextpath=/plantuml" を付けてみたり、 /var/lib/jetty/start.d や /usr/local/jetty/etc 等の設定をいじったりしてみても変わってくれず、悩んでいました。

色々試行錯誤して、わりと簡単な形で落ち着きました。

解決

plantuml/plantuml-server:jetty の元となっている jetty の Desc を見ると、こんな記述が。

Deployment

Webapps can be deployed under /var/lib/jetty/webapps in the usual ways (WAR file, exploded WAR directory, or context XML file). To deploy your application to the / context, use the name ROOT.war, the directory name ROOT, or the context file ROOT.xml (case insensitive).

plantuml-server のコンテナを覗いてみると、確かに ROOT.war が置かれているので、これを起動前リネームしてやる感じにしてみました。

docker-entrypoint.sh の前に処理をするスクリプトを作り、

### /srv/plantuml-server/docker-entrypoint-custom.sh (0755)

#!/bin/sh
mv /var/lib/jetty/webapps/ROOT.war /var/lib/jetty/webapps/plantuml.war
exec /docker-entrypoint.sh "$@"

こいつを entrypoint に指定して docker run します。

docker run --rm --name plantuml-server \
-p 127.0.0.1:8080:8080 \
-v /srv/plantuml-server/docker-entrypoint-custom.sh:/docker-entrypoint-custom.sh:ro \
--entrypoint /docker-entrypoint-custom.sh \
plantuml/plantuml-server:jetty \

無事、 http://localhost:8080/plantuml で動くようになりました。

さいごに

今回に限らず、このやり方は、"わざわざ手元でビルドしなおす程でもない調整" をする時に使えそうです。

Amazon Linux 2 正式版でた！

ついに Amazon Linux 2 の RC が取れましたね。
これから使っていく上で Ansible での OS 判定が必要になってきます。

Gather facts

Gather facts の使えそうなところを抜粋してみます。
※ ansible 2.5.4 で実行

まず参考に Amazon Linux

### amzn-ami-hvm-2018.03.0.20180412-x86_64-gp2

"ansible_distribution": "Amazon",
"ansible_distribution_major_version": "NA",
"ansible_distribution_release": "NA",
"ansible_distribution_version": "2018.03",
"ansible_os_family": "RedHat",

そして Amazon Linux 2

### amzn2-ami-hvm-2.0.20180622.1-x86_64-gp2

"ansible_distribution": "Amazon",
"ansible_distribution_major_version": "NA",
"ansible_distribution_release": "NA",
"ansible_distribution_version": "2",
"ansible_os_family": "RedHat",

ansible_distribution_version に 2 が入ってますね。(RC のときは Candidate でした。)

うーんこれ、 ansible_distribution_major_version が NA なのはなぜだろう。
ansible_distribution_version は、今後 AMI の更新で変わらないかちょっと心配です。
LTS だから変わらないのかな。

よくある書き方の問題点

例えば include_tasks でググってみると、こういう感じの書き方をよく見かけます。

### tasks/main.yml

- name: Include tasks (RedHat 6)
  include_tasks: install_redhat_6.yml
  when: ansible_os_family == 'RedHat' and ansible_distribution_major_version|int == 6

- name: Include tasks (RedHat 7)
  include_tasks: install_redhat_7.yml
  when: ansible_os_family == 'RedHat' and ansible_distribution_major_version|int == 7

- name: Include tasks (Amazon Linux)
  include_tasks: install_amazon.yml
  when: ansible_os_family == 'RedHat' and ansible_distribution == 'Amazon'

この書き方で各種ロールを運用していく中で、いろいろ悩みが出てきました。

• ぱっと見で when がわかりにくい
• OS・ディストロを追加するたびに include_tasks が増えていく
• 例えば RedHat と CentOS で分けたいときに when が更にややこしくなる
• どれにも当てはまらない場合のエラーハンドリングがしにくい

良い書き方

### tasks/main.yml

- name: Include tasks
  include_tasks: '{{ include_yml }}'
  loop_control:
    loop_var: include_yml
  with_first_found:
    - files:
      - 'install-d-{{ ansible_distribution }}-{{ ansible_distribution_major_version }}.yml'
      - 'install-d-{{ ansible_distribution }}.yml'
      - 'install-f-{{ ansible_os_family }}-{{ ansible_distribution_major_version }}.yml'
      - 'install-f-{{ ansible_os_family }}.yml'
      - 'install.yml'
      skip: false

ポイント

• with_first_found を使う事で、基本的にファイル追加のみで OS・ディストロの追加ができる
• ループ対象は条件がきついものが最初にあるので、 "RedHat 系だけど CentOS は特別な処理をしたい" 的な事に対応しやすい
• 当てはまるものがない場合の動きを skip パラメタで指定できる
• include した先でループ変数にデフォルトの item を使いたいだろう事を考慮し、 include_yml という変数名にしておく

例: Docker CE のインストール

• RedHat 7 系 は公式リポジトリからインストール
• Amazon Linux はアマゾンのリポジトリからインストール

### tasks/install-d-Amazon.yml

- name: Install docker
  yum: name=docker state=present

- name: Install pip
  yum: name=python27-pip state=present

- name: Install docker-py
  pip: name=docker-py state=latest

### tasks/install-f-RedHat-7.yml

- name: Install packages
  yum: name='{{ item }}' state=present
  with_items:
    - device-mapper-persistent-data
    - lvm2

- name: Install Docker CE repository
  get_url: >
    url='https://download.docker.com/linux/centos/docker-ce.repo'
    dest='/etc/yum.repos.d/docker-ce.repo'
    checksum='sha256:6650718e0fe5202ae7618521f695d43a8bc051c539d7570f0edbfa5b4916f218'

- name: Install docker-ce
  yum: name=docker-ce state=present

- name: Install pip
  yum: name=python-pip state=present enablerepo=epel

- name: Install docker-py
  pip: name=docker-py state=present

最後に

もちろん、include_tasks だけじゃなく include_vars 等にも使えます。
この書き方にしてから見通しがよくなって、運用しやすくなりました。

※ MySQL 5.7 からの透過的ページ圧縮 ではない です。

経緯

Zabbix のテーブルって膨れますよね。

# ls -l /var/lib/mysql/zabbix/*.ibd | sort -n -k 5 | tail -n 5
-rw-rw---- 1 mysql mysql    176160768 Dec 19 14:22 /var/lib/mysql/zabbix/events.ibd
-rw-rw---- 1 mysql mysql    494927872 Dec 19 14:02 /var/lib/mysql/zabbix/trends.ibd
-rw-rw---- 1 mysql mysql    591396864 Dec 19 14:32 /var/lib/mysql/zabbix/trends_uint.ibd
-rw-rw---- 1 mysql mysql 165217828864 Dec 19 14:32 /var/lib/mysql/zabbix/history_uint.ibd
-rw-rw---- 1 mysql mysql 183601463296 Dec 19 14:32 /var/lib/mysql/zabbix/history.ibd

ということで、テーブルをいくつか圧縮することにしました。

ALTER TABLE history ROW_FORMAT=COMPRESSED KEY_BLOCK_SIZE=8;

調べると上記のような方法がよく見つかりますが、ALTER TABLE は実行中の書き込みがブロックされてしまうのと、一時的なテーブルにデータをコピーする動きをするのでディスク容量に余裕が必要です。

以前、似たような経緯で 100GB くらいの history テーブルを ALTER TABLE したところ、3 日くらいかかったという経験もあり、今回は別のアプローチを試みました。

別のサーバに一時的に DB を作り、テーブルを圧縮形式にしておき、そこにレプリケーションを張り、トランスポータブルテーブルスペースで ibd ファイルをコピーする、という流れです。
ibd ファイルのコピー・インポート中は停止時間になってしまいますが、3 日止まるよりはマシでしょう。

前提

便宜上、Zabbix のデータベースを master 、レプリケーションする先の別サーバを slave と呼ぶことにします。

単純化のため、テーブル history についてのみ手順を書きます。

master のデータベースは MySQL 5.6 で、my.cnf には下記の設定が入ってます。

[mysqld]
innodb_file_per_table
innodb_file_format = Barracuda

server-id = 1
log-bin = mysql-bin

手順

テーブル定義出力

対象テーブルの CREATE TABLE 文を出力します。
圧縮形式になるように sed しておきます。

[master]# mysqldump --default-character-set=binary -uroot \
--opt --skip-lock-tables --no-data -f zabbix history \
| sed -e 's/\(ENGINE=InnoDB.*\);$/\1 ROW_FORMAT=COMPRESSED KEY_BLOCK_SIZE=8;/' \
> tbl_history.sql

ダンプの流し込み

まず、テーブル定義を slave に流し込み、圧縮形式のテーブルを作ります。

[slave]# cat tbl_history.sql | mysql -uroot zabbix

続いて、history テーブルのダンプを流し込みます。　　
前述の通り、 master にはダンプを吐き出すほどの空き容量の余裕がないので、nc で slave に送信し、 slave で直接流し込みます。

[master]# mysqldump --default-character-set=binary -uroot \
--opt --skip-lock-tables --single-transaction --order-by-primary --master-data=2 --no-create-info -f zabbix history \
| tee >(grep 'CHANGE MASTER TO' >&2) \
| pv -B 4m | nc <slave> 60000

--skip-lock-tables と --single-transaction でテーブルロックせずにダンプ処理をトランザクションで囲み、書き込みがブロックされないようにします。

tee で --master-data=2 での出力を確認しておくことがポイントです。
pv は、なんとなくの進捗がわかると精神的に良いのでつけてます。

nc の受け側は、こんな感じ。

[slave]# nc -l 60000 | mysql -uroot zabbix

レプリケーションを張る

ダンプの流し込みが終わりましたが、 slave には当然ダンプ開始時点までのデータしかないので、レプリケーションを張って master に追いつかせます。

特定のテーブルにしぼってレプリケーションしたいので、 slave の my.cnf は下記の感じにします。

[mysqld]
innodb_file_per_table
innodb_file_format = Barracuda

server-id = 2
replicate-do-table = zabbix.history

ダンプの際の --master-data=2 の出力を利用してレプリケーションを開始します。

-- @slave

CHANGE MASTER TO
MASTER_HOST = '<master>',
MASTER_USER = 'repl',
MASTER_PASSWORD = 'replpass',
MASTER_LOG_FILE = 'mysql-bin.000002',
MASTER_LOG_POS = 14490978;

START SLAVE;

テーブルスペースのコピー

レプリケーションが追いついたら、トランスポータブルテーブルスペースで圧縮形式になった ibd ファイルを master に持っていきます。

サービスの停止とコピーの準備

Zabbix Server を停止して、

[master]# systemctl stop zabbix-server.service

レプリケーションを止めて、

-- @slave
STOP SLAVE;
RESET SLAVE ALL;

master のテーブルを圧縮形式に作り直します。

-- @master
DROP TABLE history;

↓ 本来は slave での SHOW CREATE TABLE の出力を使うべきです。ここでは手抜きしてます。

[master]# cat tbl_history.sql | mysql -uroot zabbix

いざトランスポート

master のテーブルの既存のテーブルスペースを破棄し、

-- @master
ALTER TABLE history DISCARD TABLESPACE;

slave でエクスポートのためにロックします。
(この時点で後述の cfg が作成されます。)

-- @slave
FLUSH TABLES history FOR EXPORT;

そして、 slave の、
/var/lib/mysql/zabbix/{history.ibd,history.cfg}
を master の同じパスに持っていきます。

その後、 master でテーブルスペースを読み込みます。
(想定外だったけどこれも結構かかった…。3 時間くらい。)

-- @master
ALTER TABLE history IMPORT TABLESPACE;

サービスの再開

読み込めたら、Zabbix Server を再開しましょう。

[master]# systemctl start zabbix-server.service

お掃除

master に持っていった cfg ファイルは、インポート後は削除してしまって OK です。

また、 slave で取得したロックは下記で開放できます。

-- @slave
UNLOCK TABLES;

おわりに

この作業で、 history.ibd のサイズを 171GB から 82GB に縮めることができました。
※ Zabbix の housekeeping でフラグメントしてたりするので、圧縮の効果のみではないのですが。

TL;DR

• ユニット設定ファイルに LimitNOFILE を書く
• /etc/systemd/system/<unit>.d/override.conf に書くとなおよい

経緯

CentOS 7 に MariaDB を構築していて、my.cnf に下記設定を入れていました。

open-files-limit = 65536

しかし、プロセスの Limit を調べてみると 1024 になっていて、ログにもその旨が出ています。

# cat /proc/`pidof mysqld`/limits | grep -i "max open files"
Max open files            1024                 4096                 files

# tailf /var/log/mariadb/mariadb.log
...snip...
150712 16:48:49 [Warning] Could not increase number of max_open_files to more than 1024 (request: 2159)
...snip...

おすすめの設定方法

systemd のユニット設定ファイルに LimitNOFILE を書くことで制限を緩和できますが、rpm で配置されるユニット設定ファイルには、あまり触れたくありません。

そこで下記のように、"ユニット名.d" でディレクトリを掘り、その中に上書きしたい項目だけ記述します。ファイル名は override.conf でなくても良いです。

/etc/systemd/system/mariadb.service.d/override.conf

[Service]
LimitNOFILE=65536

反映されました。

# systemctl daemon-reload
# systemctl restart mariadb.service

# cat /proc/`pidof mysqld`/limits | grep -i "max open files"
Max open files            65536                65536                files

おわりに

よくよく見ると、rpm で配置された /usr/lib/systemd/system/mariadb.service の中のコメントにこんな記述があったのでした。

# For example, if you want to increase mariadb's open-files-limit to 10000,
# you need to increase systemd's LimitNOFILE setting, so create a file named
# "/etc/systemd/system/mariadb.service.d/limits.conf" containing:
#       [Service]
#       LimitNOFILE=10000

VirtualBox on OS X にて Vagrant で複数 VM を起動するとき、public_network を使っていると毎度ブリッジインタフェースの選択が面倒です。
各 VM の起動時に都度選択画面が出るので、全台起動するまでターミナルに張り付いていないといけません。

下記のように固定してしまっても良いのですが、ホストマシンが有線接続な時はそちらにブリッジしたいという欲もあります。

config.vm.network "public_network", bridge: 'en0: Wi-Fi (AirPort)'

そんなときは下記のように Vagrantfile 中に一文入れてしまえば良いです。
ありがたいことに、VBoxManage list bridgedifs は、ホストマシンのデフォルトルートのインタフェースを 1 番目に出力してくれるので、これを bridge オプションに入れるようにします。

Vagrant.configure(2) do |config|
  ...snip...

  # ホストマシンのデフォルトルートの NIC を取得
  bridge_if = %x(VBoxManage list bridgedifs | grep '^Name:' | head -n 1).chomp.sub(/^Name: +/, "")

  config.vm.define :web do |web|
    web.vm.network "private_network", ip: "172.16.0.101", netmask: "255.255.255.0"
    web.vm.network "public_network", bridge: bridge_if
  end

  config.vm.define :api do |api|
    api.vm.network "private_network", ip: "172.16.0.102", netmask: "255.255.255.0"
    api.vm.network "public_network", bridge: bridge_if
  end

  config.vm.define :db do |db|
    db.vm.network "private_network", ip: "172.16.0.103", netmask: "255.255.255.0"
    db.vm.network "public_network", bridge: bridge_if
  end
end

ちなみに、use_dhcp_assigned_default_route を書いておくと、VM のデフォルトルートが public_network になって何かと便利です。

config.vm.network "public_network", use_dhcp_assigned_default_route: true

久々に syslog-ng を使う機会があったのでメモ。

やりたいこと

• いくつかの特定の IP は、1 つのログファイルにまとめたい
• それ以外は、IP 毎にファイルを分割したい

たとえば、ネットワーク機器のログは 1 つにまとめ、その他サーバ機器のログは個別に分割したい、というような時。

設定

こんな感じにする

source s_remote {
  tcp(ip(0.0.0.0) port(514)); udp(ip(0.0.0.0) port(514));
};

filter f_specific {
  host(^172.16.0.1$) or
  host(^172.16.0.2$) or
  host(^172.16.0.253$) or
  host(^172.16.0.254$);
};

filter f_other {
  not filter(f_specific);
};

destination d_separate {
  file("/var/log/syslog-ng/$HOST/syslog.$YEAR-$MONTH-$DAY" create_dirs(yes));
};

destination d_merge {
  file("/var/log/syslog-ng/merged/syslog.$YEAR-$MONTH-$DAY" create_dirs(yes));
};

log { source(s_remote); filter(f_specific); destination(d_merge); };
log { source(s_remote); filter(f_other); destination(d_separate); };

ポイントは、f_specific を否定することにより、"特定の送信元 IP" と "それ以外の IP" というフィルタを作っている点。

※ host() の引数は regexp であることに注意

• 初稿 (Mon Mar 23 22:44:13 JST 2015)

検証や開発のために OS X ローカルで dnsmasq を使うとき、

• リゾルバの向き先を変えるためにいちいちネットワーク環境設定を開くのが面倒 (コマンドでもできるけど)
• 指定ドメイン名以外は通常通り名前解決したい

と思っている人のために。

TL;DR

/etc/resolver 配下に指定ドメイン名でファイルを作れば良い。

方法

指定ドメインのリゾルバを変更

設定

$ sudo mkdir /etc/resolver
$ sudo chown <USER>:wheel /etc/resolver
$ echo 'nameserver 127.0.0.1' > /etc/resolver/example.com

OS X では /etc/resolver 配下にドメイン名でファイルを作る (書式は resolv.conf と同じ) と、そのドメインの DNS サーバを変更することができる。
今回はローカルの dnsmasq に向けるので、nameserver 127.0.0.1 としている。

これによって通常通り /etc/resolv.conf を使いつつも、指定のドメインのみ 127.0.0.1 を使ってくれるようになる。
場所移動等で、DHCP で取得した DNS サーバが変わっても気にしないで良くなる。

いちいち sudo しなくて良いように、/etc/resolver のオーナーをログインユーザにしておくと良い。

確認

$ scutil --dns
   ...snip...
resolver #2
  domain   : example.com
  nameserver[0] : 127.0.0.1
  flags    : Request A records, Request AAAA records
  reach    : Reachable,Local Address
   ...snip...

dnsmasq

インストール

$ brew install dnsmasq

設定

/usr/local/etc/dnsmasq.conf

listen-address=127.0.0.1
user=<USER>
conf-dir=/usr/local/etc/dnsmasq.d
resolv-file=/etc/resolv.conf

/usr/local/etc/dnsmasq.d/example.com

address=/www.example.com/10.0.0.101

resolv-file で /etc/resolv.conf を指定することで、指定のドメインの中でも dnsmasq にてマッチしなかったものは、/etc/resolv.conf の DNS サーバに問い合わせるようになる。

起動・自動起動設定

$ sudo cp -a /usr/local/opt/dnsmasq/homebrew.mxcl.dnsmasq.plist /Library/LaunchDaemons
$ sudo chown root:wheel /Library/LaunchDaemons/homebrew.mxcl.dnsmasq.plist
$ sudo launchctl load -w /Library/LaunchDaemons/homebrew.mxcl.dnsmasq.plist

再起動・リロード

$ pkill dnsmasq

user を指定しているので、ログインユーザで kill して再起動できる。(launchctl を叩くのは面倒)

さいごに

/etc/resolver 配下にファイルを置いてから、実際に dnsmasq に聞きに行ってくれるようになるまで 2,3 分のラグがある気がする。

• 初稿 (Mon Dec 8 20:24:07 JST 2014)

ようやっと daemontools から Supervisor に乗り換えました。
ナウくていいですね。

ちょっとポイント書いていきます。

(バージョン: supervisor 3.1.2)

pip でインストール

# yum install python-setuptools
# easy_install pip
# pip install supervisor

epel リポジトリにもありますが、若干古いので pip で入れることにしました。
EPEL5/6 だと 2.1、EPEL7 だと 3.0 が入りました。 (2014/10/21)

基本設定と起動

メイン部分 (Supervisor 自体) の設定と、管理する子のプログラムの設定はファイルを分けるのが僕のポリシーです。
/etc/supervisord.d 以下に置いた conf ファイル 1 つにつき [program:x] セクションを 1 つ書く感じが良いかなと思います。

メイン部分の設定

/etc/supervisord.conf

[unix_http_server]
file=/var/run/supervisor.sock

[supervisord]
logfile=/var/log/supervisord.log
logfile_maxbytes=50MB
logfile_backups=10
loglevel=info
pidfile=/var/run/supervisord.pid
nodaemon=false
minfds=65536
minprocs=200

[rpcinterface:supervisor]
supervisor.rpcinterface_factory=supervisor.rpcinterface:make_main_rpcinterface

[supervisorctl]
serverurl=unix:///var/run/supervisor.sock

[include]
files=/etc/supervisord.d/*.conf

ちなみに、minfds を書いておけば、子プロセスの Max open files もその値になっていました。
(user パラメータで動作ユーザを変更していても OK っぽい)

自動起動設定

supervisord のために起動スクリプトを書くのもツラいので、下記で起動することに。

# echo 'supervisord -c /etc/supervisord.conf' >> /etc/rc.d/rc.local

起動

# supervisord -c /etc/supervisord.conf

子のプログラムの設定

だいたいの物は下記を書いておけば事足りるかなと思います。
stdout と stderr は指定しておかないと /tmp 以下に吐かれるので注意。

/etc/supervisord.d/hoge.conf

[program:hoge]
command=/bin/cat
autostart=true
autorestart=true
user=nobody
directory=/tmp
stdout_logfile=/var/log/supervisord/%(program_name)s_stdout.log
stdout_logfile_maxbytes=100MB
stdout_logfile_backups=5
stderr_logfile=/var/log/supervisord/%(program_name)s_stderr.log
stderr_logfile_maxbytes=100MB
stderr_logfile_backups=5

あとは下記あたりが使えそうです。(値はデフォルト値)
stopwaitsecs はデフォルトが 10 秒なので、InnoDB buffer pool dump 等、終了に時間かかる場合は長めにしておくといいかもしれません。

• startsecs=1
  • 起動成功と判定する秒数
  • この時間以内に exitcodes に示した終了コードで終わっても、失敗と判定する
  • 判定不要なら 0 を指定
• startretries=3
  • 起動失敗した時のリトライ数
• exitcodes=0,2
  • 正常終了とみなす終了コード (カンマ区切り)
• stopsignal=TERM
  • 終了するときに使うシグナル
• stopwaitsecs=10
  • この時間内にプロセスが終了しない場合、KILL が送られる
• killasgroup=false
  • KILL をプロセスグループ全体に送るかどうか

操作

セクションを変更した場合、reread してから各種操作 します。

子のプログラムの追加

[program:hoge] セクションを追加したときに、supervisord を再起動せずに反映する方法です。
早まって supervisorctl reload すると supervisord 自体が再起動するというトラップがあるので注意です。(ごめんなさいちゃんと help には書いてあります。)

# vi /etc/supervisord.d/hoge.conf   # <- 追加
# supervisorctl reread
hoge: available
# supervisorctl add hoge
hoge: added process group

子のプログラムの更新

引数や動作ユーザの変更等、[program:hoge] セクションの更新をしたときに、supervisord を再起動せず(ry
いきなり update でも良いですが、まずは reread で変更されたコンフィグを表示して確認するのが良いです。

# vi /etc/supervisord.d/hoge.conf   # <- 更新
# supervisorctl reread
hoge: changed
# supervisorctl update hoge
hoge: stopped
hoge: updated process group

子のプログラムの削除

[program:hoge] セクションを削除するときに(ry

# supervisorctl stop hoge
hoge: stopped
# rm -i /etc/supervisord.d/hoge.conf   # <- 削除
# supervisorctl reread
hoge: disappeared
# supervisorctl remove hoge
hoge: removed process group

• 初稿 (Wed Oct 22 00:15:38 JST 2014)

ProxyChains という、プログラムの TCP/DNS 通信を、指定した socks に通してくれるツールがあります。

よく下記のような使用例が書かれてます。

$ proxychains telnet 192.0.2.11 80
$ proxychains ssh 192.0.2.11
$ proxychains curl http://example.com/

これ、proxychains でシェル自体を起動しちゃえばいいんじゃないかと思ってやってみました。

$ tor &
$ proxychains bash
$ curl -kLs https://check.torproject.org/ | grep -i congratulations
[proxychains] DLL init
[proxychains] DLL init
[proxychains] Strict chain  ...  127.0.0.1:9050  ...  check.torproject.org:443  ...  OK
      Congratulations. This browser is configured to use Tor.

上記は tor を通している例ですが、うまくいってますね。
いちいち proxychains 挟むのが面倒だったので、これからこの使い方にしようと思います。

• 初稿 (Thu, 22 May 2014 03:53:09 JST)

いままでいろんな人に tmux を進めてきましたが、ターミナルマルチプレクサの使用経験が無い人にとっては、概念を掴むまで、というか、アタッチ・デタッチの操作を覚えるのに抵抗を感じてしまう人が多いように感じます。

というわけで、.bashrc なり .zshrc なりに下記を書いてあげると良いかなと。

function tm() {
  if [ -n "${1}" ]; then
    tmux -2 attach-session -t ${1} || \
      tmux -2 new-session -s ${1}
  else
    tmux -2 attach-session || \
      tmux -2 new-session
  fi
}

何も考えずに tm と打つだけで、既にセッションがある時はアタッチ、無いときは新規作成、という動きをしてくれるので楽です。

• 初稿 (Mon, 21 Apr 2014 17:36:18 JST)