やるきなし

2018/08/14 16:16 / microSDXC 速度計測

Silicon Power の microSDXC UHS-1 Speed Class 1 256GB (elite)を購入したのだが,今まで使っていた Samsung の microSDXC UHS-I Speed Class 1 128G (EVO+)と比較してなんだかもっさりしている.

CrystalDiskMark で調べた結果,以下のように Silicon Power は結構遅い...

Silicon Power microSDXC UHS-1 Speed Class 1 256GB (elite)

   Sequential Read (Q= 32,T= 1) :    86.820 MB/s
  Sequential Write (Q= 32,T= 1) :    21.993 MB/s
  Random Read 4KiB (Q=  8,T= 8) :     6.187 MB/s [   1510.5 IOPS]
 Random Write 4KiB (Q=  8,T= 8) :     1.340 MB/s [    327.1 IOPS]
  Random Read 4KiB (Q= 32,T= 1) :     6.208 MB/s [   1515.6 IOPS]
 Random Write 4KiB (Q= 32,T= 1) :     1.319 MB/s [    322.0 IOPS]
  Random Read 4KiB (Q=  1,T= 1) :     5.466 MB/s [   1334.5 IOPS]
 Random Write 4KiB (Q=  1,T= 1) :     1.236 MB/s [    301.8 IOPS]
Samsung microSDXC UHS-I Speed Class 1 128G (EVO+)

   Sequential Read (Q= 32,T= 1) :    87.620 MB/s
  Sequential Write (Q= 32,T= 1) :    63.907 MB/s
  Random Read 4KiB (Q=  8,T= 8) :     5.574 MB/s [   1360.8 IOPS]
 Random Write 4KiB (Q=  8,T= 8) :     2.594 MB/s [    633.3 IOPS]
  Random Read 4KiB (Q= 32,T= 1) :     5.617 MB/s [   1371.3 IOPS]
 Random Write 4KiB (Q= 32,T= 1) :     2.552 MB/s [    623.0 IOPS]
  Random Read 4KiB (Q=  1,T= 1) :     4.783 MB/s [   1167.7 IOPS]
 Random Write 4KiB (Q=  1,T= 1) :     2.430 MB/s [    593.3 IOPS]

今なら Samsung でSpeed Class 3のものもあるので,そちらにしたら良かった.以下ついでに測った NotePC の SSD.

   Sequential Read (Q= 32,T= 1) :   508.879 MB/s
  Sequential Write (Q= 32,T= 1) :   191.672 MB/s

2018/08/14 15:57 / docker.io を install すると kvm -net bridge がうまく動かない

Debian GNU/Linux に docker.io (18.03.1+dfsg1-6) を Install すると KVM (ブリッジ接続)に接続できなくなった.docker0 という interface ができたのが原因かと思い,かなり悩む.

% /sbin/ifconfig -s | awk '{print $1}'
Iface
br0
docker0
eth0
lo
tap0
% /sbin/brctl show
bridge name     bridge id               STP enabled     interfaces
br0             8000.xxxxxxxxxxxx       yes             eth0
                                                        tap0
docker0         8000.yyyyyyyyyyyy       no

原因は https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=865975 のとおり iptables の Chain FORWARD の default policy を dockerDROP にしてしまうこと.sudo iptables -P FORWARD ACCEPT すれば直る.

2018/07/17 22:33 / OpenVPN 2.4.4-2~bpo9+1

Debian GNU/Linux の OpenVPN (server) を 2.4.0-6+deb9u2 から 2.4.4-2~bpo9+1 に version up したらユーザー認証ができなくなった./etc/default/openvpn は以下のとおり(抜粋).

AUTOSTART="vpn_server"

/etc/openvpn/vpn_server.conv で以前は以下で password 認証(というかLDAP)ができていた.

plugin /usr/lib/openvpn/openvpn-plugin-auth-pam.so openvpn
client-cert-not-required

まずclient-cert-not-requiredについては以下のように怒られるので,verify-client-cert optionalぐらいに変更.See https://community.openvpn.net/openvpn/wiki/DeprecatedOptions#a--client-cert-not-required . client-cert-not-required は OpenVPN 2.5 で削除される様子.

DEPRECATED OPTION: --client-cert-not-required, use --verify-client-cert instead

/usr/lib/openvpn/openvpn-plugin-auth-pam.so はまず path が /usr/lib/x86_64-linux-gnu/openvpn/plugins/openvpn-plugin-auth-pam.so に変更になっている.パスの変更については,full path を書かなければ良いらしく以下で対応.

plugin openvpn-plugin-auth-pam.so openvpn

ただし,これだと,以下のようなエラーで認証できない(client の IP Address が 127.0.0.1 なのは SSH でポートフォワードしているから).

myserver openvpn[XXXXX]: AUTH-PAM: BACKGROUND: user 'myn' failed to authenticate: System error
myserver ovpn-vpn_server[XXXXX]: 127.0.0.1:XXXXX PLUGIN_CALL: POST /usr/lib/x86_64-linux-gnu/openvpn/plugins/openvpn-plugin-auth-pam.so/PLUGIN_AUTH_USER_PASS_VERIFY status=1
myserver ovpn-vpn_server[XXXXX]: 127.0.0.1:XXXXX PLUGIN_CALL: plugin function PLUGIN_AUTH_USER_PASS_VERIFY failed with status 1: /usr/lib/x86_64-linux-gnu/openvpn/plugins/openvpn-plugin-auth-pam.so

調べてみたところ,/lib/systemd/system/openvpn@.serviceCapabilityBoundingSetCAP_AUDIT_WRITE を追加する必要があるらしい.

参考:

2018/07/12 12:15 / overlayfs の挙動がおかしい(Linux 4.17.5)

以下のような状況を想定.

% ls -Rla
.:
total 0
drwxr-xr-x 1 myn    users   24 Jul 12 12:06 ./
drwxr-xr-x 1 myn    users 2018 Jul 12 12:12 ../
drwxr-xr-x 1 myn    users    8 Jul 12 12:13 low/
drwxr-xr-x 1 myn    users    0 Jul 12 12:06 over/
drwxr-xr-x 1 myn    users   16 Jul 12 12:14 up/
drwxr-xr-x 1 myn    users    0 Jul 12 12:14 work/

./low:
total 0
drwxr-xr-x 1 myn    users  8 Jul 12 12:13 ./
drwxr-xr-x 1 myn    users 24 Jul 12 12:06 ../
drwxr-xr-x 1 myn    users 18 Jul 12 12:08 dir0/

./low/dir0:
total 0
drwxr-xr-x 1 myn    users 18 Jul 12 12:08 ./
drwxr-xr-x 1 myn    users  8 Jul 12 12:13 ../
-rw-r--r-- 1 myn    users  0 Jul 12 12:05 test
-rw-r--r-- 1 myn    users  0 Jul 12 12:05 test1

./over:
total 0
drwxr-xr-x 1 myn    users  0 Jul 12 12:06 ./
drwxr-xr-x 1 myn    users 24 Jul 12 12:06 ../

./up:
total 0
drwxr-xr-x 1 myn    users   16 Jul 12 12:14 ./
drwxr-xr-x 1 myn    users   24 Jul 12 12:06 ../
c--------- 1 root   root  0, 0 Jul  6 11:18 dir0
drwxr-xr-x 1 myn    users   20 Jul 12 12:14 dir1/

./up/dir1:
total 0
drwxr-xr-x 1 myn    users   20 Jul 12 12:14 ./
drwxr-xr-x 1 myn    users   16 Jul 12 12:14 ../
-rw-r--r-- 1 myn    users    0 Jul 12 12:09 file0
c--------- 1 root   root  0, 0 Jul  6 11:18 file1

./work:
total 0
drwxr-xr-x 1 myn    users  0 Jul 12 12:14 ./
drwxr-xr-x 1 myn    users 24 Jul 12 12:06 ../

ここで

% sudo mount -t overlay -olowerdir=low,upperdir=up,workdir=work overlay over

で mount すると,

% ls -Rla over
over:
total 0
drwxr-xr-x 1 myn    users 16 Jul 12 12:14 ./
drwxr-xr-x 1 myn    users 26 Jul 12 12:16 ../
drwxr-xr-x 1 myn    users 20 Jul 12 12:14 dir1/

over/dir1:
ls: cannot access 'over/dir1/file1': No such file or directory
total 0
drwxr-xr-x 1 myn    users 20 Jul 12 12:14 ./
drwxr-xr-x 1 myn    users 16 Jul 12 12:14 ../
-rw-r--r-- 1 myn    users  0 Jul 12 12:09 file0
c????????? ? ?      ?      ?            ? file1

といった悲しい状況になる.uppwer 側で消すファイルが lower 側に存在せず,かつ,その directory が uppwer 側でのみ存在する場合に発生する様子(しかも起こったり起こらなかったり).Linux の Version は 4.17.5.

2018/07/11 00:37 / Mailgun

お名前.com で取得していた(ある用途で利用する)ドメインをとある会社に移管したのだが,メールの設定等はそちらでやってね,みたいなことを言われて(正確には,連絡してきた内容が「普通のメールアカウントを作りかた」(しかもメールで先方に指示)のみで),仕方なくお名前.com の共用サーバーに MX 「だけ」向けるアプローチを探すも情報がなかく,Google Compute Engine (GCE)で飼っている VM instance に MX を向けようとするもいろいろハマる.

そもそも以下のとおり,GCE では ポート 25,465,587 はブロックされている.

G Suiteで Gmail 化するということも考えたが Basic で USD 5/month の費用がかかって,特に今回 ML を作成したい(かなりシンプルな設定のみでOK)ということもあって,Google Group ベースの ML を利用するのもちょっとイマイチな気がして(退会案内のフッタが挿入されるとか),いろいろ悩む.

いろいろ悩んだ結果,Compute Engine ドキュメント|インスタンスからのメールの送信で紹介されているクラウドベースの Email Service を利用することにした.候補はCompute Engine のドキュメントにある以下の3つで考える.この時はメール受信のことはあまり考えていなかった.

https://qiita.com/yukari-n/items/45624096582111dd25b9に記事もあったので,Mailgunを利用することにした.設定は至って簡単.https://www.ritolab.com/entry/39にアカウントの作成から順に解説されている.ちょっとだけ DNS (サーバ側)の設定項目が多いが,これはやむなし.

Mailgun には SMTP Server としての機能があるので(送信サーバとして使用するには認証が必要),Compute Engine からメールを送信する場合は postfix をつかって smtp.mailgun.org:2525 に relay するという設定を行うだけでOK (外向きポート2525なのでブロックされない).

受信メールについても Compute Engine 側に転送できるだろうと思っていたのであるが,Mailgun には SMTP を SMTP に relay する機能がなく(メールは別メールアドレスに転送可能),あったとしても結局 Compute Engine 側でブロックされるということに気づく...

ただ,調べてみると Mailgun でメール転送のルールを書くことができ,かつ,メーリングリストの設定も可能なので,Mailgun 上で全て設定することにした(そもそも,Compute Engine から送信可能とする必要もなかったが,Mailgun の Google パートナーページでアカウントを作成しないと無料枠が 10,000 件になる).

Mailgun での各 ML メンバについて,Subscribe するしない,を設定できる.ML への投稿者限定は以下の種類(https://documentation.mailgun.com/en/latest/user_manual.html#mailing-lists).

ML から unsubscribe する自動生成 URL を mail に含めることも可能だが(送信する mail に %mailing_list_unsubscribe_url% を含める),これは API 経由で送信しなければ %mailing_list_unsubscribe_url% が正しく変換されない(普通に SMTP で送信するとそのまま送られる).

ちなみに,ML を subscribe している投稿者にはメールが配信されない様子.

追記 (2018/7/11)

MLの詳細.結構独特な挙動をする(特に To: の書き換え).

また,Route 機能で,特定の宛先宛のメールを他のアドレスに転送することができるが(複数転送することも可能),こちらは上記のような書き換え等は発生しない(ただし誰からでも送信可能になって,メンバの管理 I/F も Web のものだと ML のようなバルク登録はサポートしていない(APIを使って自前で用意すれば可能)).

ちなみに ML と Route は排他的ではなく,ML 宛メールが Route のルールにマッチしていれば,ML にも配信されかつ Route のルールも適用される.

http://mailgun-documentation.readthedocs.io/en/latest/user_manual.html#mailing-lists

Mailing Lists work independently from Routes. If there is a Mailing List or Route with the same address, the incoming message will hit the Route and Mailing List simultaneously. This can be pretty convenient for processing replies to the Mailing List and integrating into things like forums or commenting systems.

追記 (2018/7/11)

他にはmailman のホスティングサービスを利用するということも考えられたのかもしれない.一度リストは見たが,選択肢が多く(比較が大変),面倒になって辞めた.