少し前に prefers-color-scheme メディアクエリを使ったダークモード対応を入れた。 ざっくりと色を反転させてみて、暗すぎると感じる部分は少し明るめに調整したり現物合わせであれこれした。 まあ、見かけ上はそれっぽい感じになってはいると思う。

内情は、色関係のSass変数の値をCSSのカスタムプロパティに突っ込んでさらにメディアクエリで上書きする、というなかなか泥臭い感じになっている。

$color-foreground: (
    body: #333,
      :
);
$color-background: (
    body: #fff,
      :
);

:root {
    --color-foreground: #{map-get($color-foreground, body)};
    --color-background: #{map-get($color-background, body)};
      :
}
@media (prefers-color-scheme: dark) {
    :root {
        --color-foreground: #{invert(map-get($color-foreground, body))};
        --color-background: #{invert(map-get($color-background, body))};
          :
    }
}

body {
    color: var(--color-foreground);
    background-color: var(--color-background);
      :
}

どうにかならんもんか、とは思うものの、いろいろと調べてみてもこれ以上スマートな方法が思いつかない。 ごちゃごちゃさせたくなくて実は色関係以外はカスタムプロパティでなくSass変数を直接参照している、というのもきまりが悪い。 もういっそSassを捨ててしまおうかとも考えたけれど、ネストなしで維持してゆける気がしない。

あんまりプリプロセッサに頼りっぱなしだと素のCSSの仕様に疎くなってしまって良くない。 正直な話、カスタムプロパティは今回の件で初めて知ることになった。 Sassを使い始めた一番の理由だった CSSに変数機構がない という点が、気づかないうちに解消されていた。

そろそろ潮時と感じたので、自宅のNAS（HP ProLiant MicroServer N54L）をFreeNAS (11.2-U1) からXigmaNAS (x64-embedded-11.2.0.4.6625) に入れ替えた。

インストール

インストーラをLiveメディアから起動する必要があるので、転がっていた適当なUSBメモリにLiveUSBのイメージを書き込んだ。 光学ドライブは載っていないし、RACの仮想ディスクも使えない、というかたぶんmacOSに対応していない。

ベースシステムのストレージには、FreeNASで使っていたUSBメモリを流用する。 念のため dd if=/dev/zero して先頭100MBくらいを書き潰してからインストールを始めたものの、必要だったのかどうかはわからない。 まあブート順を気にせずに済んだのはメリットかもしれない。

メニューに沿って適当にインストールして初期設定して終了。

ZFSのインポート

一番の肝であるところの FreeNASで構築したZFSをimportできるか は、結果的に特に苦労もなくできた。 あまり調べずにウェブインタフェースをいじり回していたらできてしまったので、正解がよくわからないままだけれど、たぶんこれが最適解。

Preferred method:
1: Go to "Disks > Management > HDD Management" and Click on "Import Disks" and Apply.
2: Go to: "Disks > ZFS > Configuration > Synchronize" and click on "Synchronize" and apply.

Re: From freenas to XigmaNas

同じFreeBSDがベースだし、こんなこともあろうかとupgradeもしばらく控えていたので、正直あまり心配はしていなかった。 ただAFPの設定を済ませればTime Machineのバックアップデータすらそのまま引き継げてしまったことには、さすがに少し拍子抜けした。

Rsync over SSH

Services > Rsync > Client の設定はウェブインタフェースから行なえるものの、TCP直結が前提の様子。 自前でパパッとcronの設定をしてみたもののうまく動かない。

さてどうやってover SSHで定期実行させたものか、と思っていたら、 Services > Rsync > Local の設定画面からできた。 変にパスの検証とかをしていないことが逆に都合が良く、ホスト名を入れても普通に動いてしまう。 将来的にはどこかのアップデートで使えなくなるかもしれないけれど、そうなったらその時に考える。

所感

ウェブインタフェースのデザインとかには少し古さを感じるけれど、考えようによってはこれくらい枯れている方が逆に信頼がおける。 ビール代くらいはdonateしよう、と思ったけど日本からはできないらしい。 ごめん。

ちょっと込み入ったスクリプトを書こうと思ったらRubyやPython（書けないけど）はおろかPerlすらなく、PHPが唯一の選択肢でびっくりした。 仕方がないのでPHPで書いた。 実に数年ぶりに。

このサーバの死活監視はUptime Robotに面倒を見てもらっている。 もちろんアラートを上げることもできて、様々な通知チャンネルを用意してくれているわけだけど、悩ましい。

なにが悩ましいって？

もしサーバが死んだ場合、当然このドメインのメールは使い物にならないと想定できる。 普段使いしているメールアドレスはこのドメインのものだけなので、メールでアラートを受け取るという選択肢がまず消える。

以前はTwitterのDMを飛ばしていたけれど、スマホからTwitterアプリを消してしまって以来、この方法も使えなくなった。

他に常用している適当なサービスもないので、スマホでリアルタイムにアラートを受け取るためには、新たにサービスにサインアップしたりアプリを入れたりしないといけない。

めんどくさい。 インフラ側でなんとかしたい。

SMSという選択

そんな要求を満たす通知チャンネルとして、SMSという選択肢がある。 メールをSMSに変換して送ってくれるようなサービスを使えば良いだろう。

というわけで、 TextMagicを使うことにした。 Email to SMS gatewayのサービスは他にもあるようだけど、説明がわかりやすくて料金体系もリーズナブルだったのでここにした。

とりあえずアカウントを作ったところ、お試し用に0.4ドル分のクレジットがもらえた。 日本宛てだと一通あたり0.101ドルなので、3通（3パート）までは無料でテストができる計算になる。

今回の用途だと、以下のどちらかの機能を使うことになる。

• Email to SMS

  予め登録したメールアドレスから、任意の電話番号にSMSを送ることができる。 電話番号は宛先のメールアドレスで指定する。

• SMS Distribution Lists

  電話番号のリストを作るとユニークなメールアドレスが割り当てられ、そこにメールを送ると全ての電話番号にSMSが飛ぶ。 要はメーリングリスト的な感じ。

最初はEmail to SMSを使おうとしていたけど、よく見たらドキュメントに 「外部のサービスからの重要なメールをSMSで転送したい、みたいな用途だったらDistribution Listがいいよ」 と書いてあったし、実際適していそうなので、リストである必要はないわけだけど素直にそちらを使っている。

余談

実はUptime RobotにもSMSの有料オプションがあるのだけれど、サブスクリプション＋従量制なのでコスパが見合わなかった。ごめん。

さくらのVPSのサーバ監視(β)が最近機能を充実させてきているので興味はあるのだけど、現時点では任意のメールアドレスを指定できないのでまだ使えない。

詳しくは書かないけど、TextMagicのEmail to SMSを実際に使ってみて不安を覚えた人がいれば、今のところその不安は正しいので、気にするのであればユーザ側で何らかの対策が必要。 サポートに問い合わせてみたけど、解決の見込みは今のところない。