カテゴリー: 未分類

letsencrypt-autoの名前が変わっていた

certbotに名前が変わっていた。
以前みたいに長い引数を与えなくてもletsencrypt renew --dry-runで勝手に設定ファイルを読み込んで更新してくれる模様。便利だ。

QEMUでtapなブリッジネットワークをsystemd-networkdで使う

最初は上記URLのArchWikiの内容みたいにqemu-ifupやqemu-ifdownを使った方法でやっていたが、仮想マシンの起動と終了時にホストのネットワークが途切れるという問題が起こっていた。systemd-networkdで何とかしようと思ったが、どうもうまく行かなかったので、しばらくはArchWikiの様な方法で放置していたが、さっき調べ直して設定し直した。
そうしたら、ネットワークが途切れるという問題は解決した様だ。
/etc/systemd/network/*は次のようにした。
/etc/systemd/network/bridge.netdev

[NetDev]
Name=br0
Kind=bridge

/etc/systemd/network/bridge.network

[Match]
Name=br0

[Network]
DHCP=ipv4

[DHCP]
ClientIdentifier=mac

/etc/systemd/network/en.network

[Match]
Name=en*

[Network]
Bridge=br0

/etc/systemd/network/tap.netdev

[NetDev]
Name=tap0
Kind=tap

/etc/systemd/network/tap.network

[Match]
Name=tap*

[Network]
Bridge=br0

そして、qemuに渡す引数は次のような感じだ。

-netdev tap,ifname="tap0",id=mynet0,script=no,downscript=no \
-device virtio-net-pci,mac="(ランダムなMACアドレス)",netdev=mynet0

QEMUの仮想HDDにTrimやDiscardを送信出来るようにしたい

-drive file=windows10.raw,format=raw,if=virtio,discard=on
これではだめだった。
-drive file=windows10.raw,format=raw,if=none,discard=on,id=hda \ -device virtio-scsi-pci,id=scsi \ -device scsi-hd,drive=hda
こんな感じで、virtio-scsi-pciを使うと、トリムできるようになる。

BIOSブートなArch LinuxをUSBメモリに入れたら起動しなかった

初期 RAM ディスクを作成 (# mkinitcpio -p linux) する前に、/etc/mkinitcpio.conf の HOOKS の udev のすぐ後に block フックを追加してください。初期ユーザー空間で適切なモジュールをロードするために必要です。

USB キーに Arch Linux をインストール
これが重要だった。
UEFIブートの時は確かmkinitcpio.confを編集しなかったと思うのだが…、UEFIだと必要ない編集なのかな。

ECS LIVA(初代)でGRUBを使ってEFIでブートするのに手間取った。

https://wiki.archlinuxjp.org/index.php/GRUB#UEFI_.E3.83.95.E3.82.A1.E3.83.BC.E3.83.A0.E3.82.A6.E3.82.A7.E3.82.A2.E3.81.AE.E5.BF.9C.E6.80.A5.E5.87.A6.E7.BD.AE
手間取ったとは言え、上記のURLに書いてあることを実施しただけ。
$esp/EFI/boot/bootx64.efiにefiファイルを置かないといけないらしい。
GRUBの更新でコピーし忘れそうなのでメモしておく。

しかし、長い間WordPressを放置していたけど、大丈夫なのか少し不安だ。
自動的に更新されていなかったらしい…

letsencrypt-autoがなかなか自動化できない(本当に動くか未検証)

./letsencrypt-auto run -d akimasa.jp -d www.akimasa.jp -d blog.akimasa.jp --renew-by-defaultで自動化できると思いきや、いろいろと足りなかった。まず、crontabで実行するときの環境変数PATHが足りないようで、apacheが検出できない。PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/binを適当なシェルスクリプトの最初に書いておいて、そっから実行するようにした。
ほかに、引数として--no-redirect --non-interactive --apacheが足りていなかったので、ユーザーの操作を求められたり、プラグインの指定が無いと言われたりする。

PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin ./letsencrypt-auto run -d akimasa.jp -d www.akimasa.jp -d blog.akimasa.jp --renew-by-default --no-redirect --non-interactive --apacheを実行するようにしておいたらなんとかなった。ただ、一定期間に発行できる証明書の数をオーバーしてしまって発行できない状態なので、これが本当に機能するのか謎である。
ちなみに、実際のシェルスクリプトはslackへの通知を行う1> >(in="STDOUT:" postbot) 2> >(in="STDERR:" postbot)とかがついたり、postbotの関数があったりする。process substitutionではfdが返ってくるとよく知らなくて、echo "hogehoge" >(postbot)をやっても、何か変なゴミが出力されているし、postbotで何故か標準入力を受け取れないなあとか思ってしまった。echo "hogehoge" 1> >(postbot)と書くべきだったな

Raspberry Pi 2のmicroSDことmmcblk0への書き込みが多い問題

まずは、blktrace -d /dev/mmcblk0 -o - | blkparse -i - -a writeなりbtrace -a write /dev/mmcblk0なりで書き込みを行っているプロセスを特定…しようと思ったが、kworkerやbtrfs-transactiの書き込みが多いという事しかわからなかった…
179,0 1 45 30.198921748 9215 M WS 3148800 + 64 [kworker/u8:2]
みたいな感じで出力されているのだが、
3148800 + 64の部分がどうもkB単位のオフセットとサイズでは無いかと思い、dd if=/dev/mmcblk0 skip=3148800 count=64 bs=1024 | base64で読み取ってみた。そしたら、軒並みAAAAAAAAAAAAAAAAAAAAAだった。/dev/zeroを読み込んでいるのと同じですな。ゼロクリアされている…。いくつか拾ってみて見ただけなので、もしかしたら何か有効なデータがある場所もあるのかもしれない。
いろいろ調べていたら、fatraceというコマンドで、どのプロセスが書き込みを行っているか調べられるらしい事がわかった。
しかし、apt-getで入れたfatraceは動いてくれなかった。Raspberry Pi 2なのに、Raspbianを使わずcdebootstrapでセットアップしたDebian 8が動いているのが原因かもしれない。実行すると、Cannot initialize fanotify: Invalid argumentと怒られる。仕方が無いので、fatraceのコードを拾ってきて、fatraceのfanotify_initをfanotify_init (0, KERNEL_O_LARGEFILE);からfanotify_init (0, 0);に書き換えたらうまく動いてくれた。
./fatrace | fgrep Wを動かしつつ、btrace -a write /dev/mmcblk0を眺めていたら原因がわかったっぽい。ログの書き込みが原因だった。ログファイルの書き込みの後に、kworkerやbtrfs-transactiの書き込みが始まっている様だ。btrfsをファイルシステムとして使っているのだが、btrfsはcopy on writeらしい。ログファイルが丸ごとコピーされて、追記されて、元あった空き領域は用済みなのでゼロクリアでもされたんだろうか。それだとしたら、書き込んだところを読み取ってもゼロなのが納得できる。
今のところ、SamsungのmicroSDカードは半年間、問題無く動き続いているが、これだけ書き込んでいればいつ壊れてもおかしくは無さそうな気がする。iostat情報だと、38KB/sで書き込みされているらしいので、半年で315GBWか…。microSDの容量は32GBなので、理想的にウェアレベリングされていても約10回は書き込んだことになる。あれ？思ったよりも少ない…。