88171.net

PRW-3100にNATOストラップ

CASIOのPRO TREK PRW-3100 を使い始めて3年くらい経つ。 電波ソーラーはストレスがなくていい。 あと気圧計・温度計はたまに役に立つ。 コンパスの出番はほとんどない。

数少ない不満点として、純正のウレタンバンドがある。 自分のような手首貧弱勢にはいろいろとしんどいので、NATOストラップに替えている。

PRW-3100Y NATOストラップ カスタム

ラグ周辺はかなり特殊な構造に見えるけれど、分解するとわかるとおり「一本通し」が可能ではある。 ラグ幅は16mmで、NATOストラップの選択肢は(正直少ないけれど探せば)ある。 見た目のバランスの好き嫌いは分かれるところだと思う。

ちなみに巷では「先環カバー」というパーツが出回っていて、これを使うと23mm幅のストラップを一本通しすることができる。 ただ、残念ながら手首貧弱勢の救いにはならなかった。

さて、純正バンドを外しただけの状態でも16mm幅のNATOストラップが通せるわけだけど、ラグ周りに結構な隙間が開いてしまう。 装着感も見た目も、お世辞にもよろしいとは言えない。

ラグ周りの隙間が残念

なので、自作したスペーサーを入れている。 内径2mm程度(純正のパイプが無理なく通る径)の適当な樹脂パイプに熱収縮チューブを重ねて、現物合わせで外径を調整した。

自作のスペーサーと、純正パイプとネジ

スペーサーの外径は実測4.7mmで、ラグの縁とストラップがほぼツライチになっている。 これ以上追い込むには偏心させる必要があるけれど、位置を保持する良い方法は思いつかない。

このくらいまでは追い込める

こういう「可逆性を担保でき外見上のクオリティを追求する必要もない」系のカスタマイズはとても楽しい。


Blosxom プラグイン無効化プラグイン

プラグインを無効化するプラグイン。

なんのこっちゃという話なので具体例を挙げると、最近 gsitemap プラグインを使ってXML形式のサイトマップを吐けるようにした。 全エントリぶん吐き出す必要性は感じないので直近100に絞ってみたものの、それでも体感的にはなかなか遅い。 NYTProf でプロファイルを取ってみると、トータルが520msくらい。 このうち、サイトマップ用の flavour には不要な Markdown::story() を100回呼ぶのに300msもかかっていた。

この300msを削るためにこのプラグインを書いた。 コールバックを抑制するだけなので、対象のプラグインのロード時間までは削れないことに注意。

識者の皆様はお気づきのとおり、 Markdown::start() で flavour を見た方がコスト安では?という話ではある。 オリジナルに一行も手を加えたくないという Markdown 原理主義者の足掻きでしかない。


自分向け Gentoo Cheat Sheet

本家: https://wiki.gentoo.org/wiki/Gentoo_Cheat_Sheet

パッケージ管理

パッケージリポジトリを更新

# emerge --sync
※現在の実装では emaint --auto sync と等価

パッケージを検索

$ emerge --search <pattern>

パッケージをインストール

# emerge --ask <ebuild>

@worldをアップデート

# emerge --ask --update --deep --changed-use @world

@worldからの依存関係ツリーに存在しないパッケージを削除

# emerge --ask --depclean

パッケージをアンインストール

# emerge --deselect <ebuild>
# emerge --ask --depclean

インストール済みパッケージの一覧を表示

$ equery list \*

特定のパスもしくはファイル名がどのパッケージに含まれているかを表示

$ equery belongs --early-out <path>

パッケージに含まれるパスの一覧を表示

$ equery files --tree <ebuild>

パッケージのUSEフラグを表示

$ equery uses <ebuild>

パッケージデフォルトの設定ファイルをマージ (diff/mergeツールを設定しておくのがオススメ)

# dispatch-conf

キャッシュ(不要なdistfiles, binary packages)を削除

# eclean --deep distfiles
# eclean --deep packages

カーネル管理(genkernelを使用)

インストール済みカーネルソースの一覧を表示

$ eselect kernel list

指定したカーネルソースを /usr/src/linux のリンク先に設定 (sys-kernel/gentoo-sourcesのUSEフラグに symlink を設定するとアップデート時に自動で)

# eselect kernel set <n>

カーネルおよびモジュール一式をコンパイルしインストール

# genkernel all

GRUB2の設定を更新 (genkernelに --bootloader=grub2 を指定するとインストール時に自動で)

# grub-mkconfig -o /boot/grub/grub.cfg

最新nバージョンを除いた古いカーネルをブートローダ設定含め削除

# eclean-kernel --ask --destructive -n <n>

サービス管理

defaultランレベルにサービスを追加

# rc-update add <service>

サービスの起動・停止・状態表示

# rc-service <service> {start|stop|status}

サービスの一覧を表示

# rc-config list

defaultランレベルからサービスを削除

# rc-update delete <service>

セキュリティ関連

セキュリティアドバイザリ(GLSA)に該当するインストール済みパッケージを表示

$ glsa-check --test affected

サーバ更新に伴ってやめたこと

挙げてみたら結構あった。

Zone Apex をあちこちで使うのをやめた

以前はMUAの設定にまで Zone Apex を使っていたが、サーバ切り替えの際に面倒だったので可能な限りホスト名を使うようにした。 ホスト名でのTLS証明書が新たに必要になったが、そこは Let's Encrypt のお世話に。

Google Authenticatorをやめた

二要素認証でリモートログインできるよう、 Google Authenticator のPAMモジュールを入れていた。 いざという時に普段使いでない(秘密鍵を持っていない)端末からでもログインできるように、くらいのつもりだったが実際に役に立ったことはないし、今ではスマホにすら専用の秘密鍵を入れているので本当にメリットがなくなった。

Fail2banをやめた

SSHやWebへのアタックのログが目障りだったので入れていたが、ログの減量を除けば、悪者を釣り上げて悦に入る以上の実効性はなかったのでやめた。

SSHをwell-knownでないポートで運用するのをやめた

アタック避けに7022/tcpで運用していたが、捕捉されるまでの時間稼ぎくらいにしかならないことがわかったのでやめた。

Muninをやめた

直近1年間の稼働状況がグラフ化されているというのは便利だったし、ついでに監視にも使っていたが、正直めったに見なかったし必要性も薄かったのでやめた。 代わりにsysstatとMonitを使っているが、十分だと思う。

Gitwebをやめた

サーバ上のリポジトリの一部をWebで公開していたが、大したものはないのでやめた。 ところどころリンク切れを起こしているはずだけど、それは追って考える。

ClamAVをやめた

実はかなり前のことだけども、メール受信時にClamAVを通すのをやめていた。 物理メモリを固定で数百MB食うわりに、いろいろ試しても昨今のマルウェア相手では満足な検出率が得られず、コスパが悪かった。

パッケージの更新通知をやめた

Debianではapticronでパッケージ更新通知のメールを投げていた。 Gentooでもたとえばglsa-checkを使って同じような仕組みは作れるが、日頃のアップデート作業を習慣づけるために敢えてやめた。 GLSAは別途、フィードを購読している。


Debianに別れを告げGentooに移った顛末

思い返せば2007年頃のサーバ移転以来、ずっとDebianのお世話になってきた。 当時から見ても情けないスペックの省スペースデスクトップマシンで自宅サーバ運用をしていたので、そういったしがらみは大いにあった気がする。 ただそんな事情を差し置いても、安定性や明快さの観点でDebianはサーバ用途に理想的なディストリビューションだと思っていた。

転機は、Debian 8 “Jessie”のリリースだった。 詳細を省いて煙に巻く言い方をすれば 宗教上の理由 で、systemdを忌避している。 このsystemdがJessieで標準のinitシステムとして採用されてしまって以来、じわじわと肩身が狭くなっていくのを感じてきた。 新しいメジャーバージョンがリリースされる度に余計な神経を使うようになり、SysVスタイルのinitスクリプトに不具合を見かけるようになった。 きっと、このままでは未来はない。

また別の観点では、ポイントリリースモデルに徐々に扱いづらさを感じ始めていた。 若い頃と違い、今ではサーバ管理作業そのものに対するモチベーションはすっかり下がってしまった。 数年おきとはいえ、リリースノートに目を通しつつ非互換の有無を精査しながらのアップデート作業は、可能なら避けたい部類の負担になっていた。 そして億劫になりLTSのお世話になりがちになるものの、それだって結局は先延ばしに過ぎない。

systemdからの逃避先として最初に浮かんだのはBSDだった。 しかし経験がほぼないに等しいBSDをぶっつけ本番で、とは考えられなかった。 Devuanという選択肢もあったけれど、どうも乗り気にはなれなかった。

考えた末に、Gentooで行くことにした。 昔デスクトップ環境として使っていたことがあるので多少の勘は残っていそうだし、ローリングリリースというのも好都合だった。

期待通り、セットアップ作業全体を通じて概ねトラブルはなかったのだけど、メモリに関しては大誤算をした。 VPSの物理メモリが1GBで、swapはまあ1GBも取っておけば大丈夫だろうなんて思っていたら、GCCのアップデートがメモリ不足でビルドできなかった。

Recent gcc versions have been known to take 1 GB to 1.5 GB of RAM per job.

MAKEOPTS - Gentoo Wiki

腹を括ってパーティションを切り直し、swapを4GB確保した上で再セットアップした。 平時の負荷なんて知れてるので、盛大にswap outしてでも乗り切れるならそれで良い、という割り切り。

本番運用に入ってみて、ディストリビューションを変えるなんて冒険をしたわりに意外と不安はないな、なんて思ったのだけど、考えてみればこの1年あまりずっと低レイヤーの保守作業はやってきたわけなので、当然と言えば当然だった。