Unyablog.

のにれんのブログ

iTerm2 JISキーボード 文字 拡大 Karabiner-Elements

iTerm2 で文字を拡大するショートカットは ⌘ + である。

JISキーボードでは + は Shift ; を入力することになるので、⌘ + は JIS では Shift ⌘ ; が入力される。

一方 iTerm2 では、Shift ⌘ ; が Open Command History に割り当てられている。このため、JISキーボードで文字を拡大しようとすると謎の機能が発火してしまう。

これの対策として、

  • iTerm2 を表示している
  • JISキーボードである

場合、Karabiner-Elements で Shift ⌘ ; を ⌘ + に変換するようにする。

{
  "title": "Send Cmd+'+' on iTerm2",
  "rules": [
    {
      "description": "Send Cmd+'+' on iTerm2",
      "manipulators": [
        {
          "type": "basic",
          "from": {
            "key_code": "semicolon",
            "modifiers": {
              "mandatory": [
                "command", "shift"
              ]
            }
          },
          "conditions": [
            {
              "type": "frontmost_application_if",
              "bundle_identifiers": [
                "com.googlecode.iterm2"
              ]
            },
            {
              "type": "keyboard_type_if",
              "keyboard_types": [
                "jis"
              ]
            }
          ],
          "to": [
            {
              "key_code": "keypad_plus",
              "modifiers": [
                "left_command"
              ]
            }
          ]
        }
      ]
    }
  ]
}

YAML から JSON に変換するツールを Nim で書き、GitHub Actions でリリースする

CI GitHub Actions

最近 config が YAML になっているアプリケーションが多い。ただ、自分は YAML の読み書きが苦手である。

設定を書くには機能が多すぎるのと、（config なので）ネストしやすいのにインデントが関わってくるのが苦手なのだと思う。

何度かハマった結果、これからは JSON に変換して読むことにした。JSON を読むのには慣れているし、jq など色付・抽出するツールも持っているので最高 *1 。

YAML を JSON に変換するツールは世の中に多くあるが、そんなに大変じゃないので自分で作ることにした*2。

github.com

何で作るか

案1 Ruby で書く

Ruby は標準ライブラリに YAML パーサーが入っているので、適当な ruby のスクリプトを書けば目的は達成される。

ただ、そのためだけに Ruby 入れるのも嫌だな…って思ってやめた。

案2 Go で書く

Go のようなコンパイラ言語であれば、標準ライブラリに入ってなくともコンパイルすれば良いので楽である。

また、Go は goreleaser や go get などインストールしやすい環境が整っており最高。

というわけで初めは Go で書いていたのだけど、YAML と JSON で型が微妙に違う（YAML は map[int]interface{} のこともあるが、JSON は map[string]interface{}）のが面倒でやめた。

案3 Nim で書く（採用）

Nim は先日 1.0.0 が出たイケイケの言語で、Python っぽく書けて便利という評判が自分の中である。Go が無理なら Nim チャンス！ということで Nim で書くことにした。

Nim の YAML ライブラリ は最高で、loadToJson 関数があるので一瞬で終わった。

バイナリを作る

リリース周りは CI でやりたい。今回は GitHub Actions を使ってみることにした。GitHub Actions では、Action を組み合わせたり、自分でコマンドを記述したりして CI の動作を記述する。

Action は 公式がいくつか配布している 他、サードパーティのもある。今回はサードパーティ Action は使わない方向でやってみた。

Nim with GitHub Actions

公式では Golang など様々な言語をインストールする Action があるが、残念ながら Nim はない。なので自分で環境構築を行った。

macOS

brew が入っているので、 brew install nim する。

Ubuntu

Ubuntu では Docker を使った（apt で Nim が配布されているものの、バージョンが古くて依存ライブラリがコンパイルできない）。

amd64 だと 公式 Nim Docker Image を使えばよかったが、クロスコンパイルはできなかったので、 arm 用には クロスコンパイルできる Image を Docker Hub に作った *3。

ちなみに、GitHub Workflow には Docker 上で動かしたり Volume を作ってくれたりする機能があるが、それを使うにはパブリックイメージを使う必要がある。そうでない場合は自前で docker build して docker run ... することになると思う。

その他

良かった

悪かった

まだ出たばかりというのもあって、使いづらい点も多かった。

  • 公式の Actions が機能不足

    artifact は一つずつしか Upload できない等、「一応できるけど不便」みたいな例が多い。 特にリリース周りは不便で、本当はもっとうまくできるのにな…と言いながら長い Workflow になってしまった。

  • job 間で値の受け渡しがしずらい

    値を直接受け渡しすることはできず、 artifact 経由になってしまう。「一回リリースつくって、そこに並列で artifact を追加する」といったケースでは upload_url を渡すことができずに困った。

  • 情報が多くない

    ドキュメントはちゃんとしているが、ユースケースがまだ少ないため情報が探しにくい。

  • YAML エディタが使いにくい

    エラーや補完を出てくれるのは嬉しいが、改行時は普通に改行してほしいな…。

多くの問題は時が経てば解決するだろう。

感想

  • YAML から逃げるために作ったのに、 GitHub Actions で数十行の YAML を書いていたのは悲しかった
  • こんな面倒なことをしなくても、Go 言語を使えばクロスコンパイルもリリースも一瞬でできるので最高だと思った。でも Nim も悪くないよ。

*1:書くのに向いているとは言っていないが、YAML よりはハマらない…

*2:手段が目的になった面もある

*3:実は Docker Hub 初めてです

VSCode 上で ESLint を使った TypeScript のフォーマット

VSCode
  1. https://github.com/microsoft/vscode-eslint を入れる
  2. VSCode のデフォルトフォーマッタを切る

グローバルか、ワークスペース上の .vscode/settings.json などに書くと良い

{
  "typescript.format.enable": false
}
  1. TypeScript で ESLint が働くようにする
    "eslint.validate": [
        "javascript",
        "javascriptreact",
        {
            "language": "typescript",
            "autoFix": true
        },
        {
            "language": "typescriptreact",
            "autoFix": true
        }
    ],

ISUCON9 予選に参加した（failed）

isucon

最近は O-Ku-Ri-Mo-No Sunday! にはまっている。めっちゃ良くない？

ということで先日 ISUCON9 に参加した。

isucon.net

チームは :innocent: で id:wass80, id:utgwkk と参加した。

全体的な話は utgwkk の記事を参照。

utgwkk.hateblo.jp

自分のやったことは大体以下の issue に書いてある。レポジトリも以下参照 *1 。

github.com

トラブル集

今回もいろんなことが起きたので列挙してみる。

サーバー構成を1台と勘違いする

全員が [重要] と書いてある場所を読み飛ばしてスコアの計算方法ばっかり気にしていた結果、複数台構成ができないと思い込んでいた！

コンテスト中は「これ複数台勝手に立てたらどうなるかな〜」とか言ってました。1台だったのでインフラ担当の自分は途中暇だった。

たとえ構成は1台限定だったとしても、3台立ててそれぞれ作業用にしたら良かったなあ、という反省も。

VSCode Remote をやめることで得点が10倍になる

なんか 410 点ぐらいしか出なくておかしいな〜とか言いながら htop を見ていたら VSCode Remote がめちゃくちゃ CPU 食ってた。やめると 4100 点ぐらいになって最大のブレイクスルーだった。

Gunicorn のオプションを間違えてプロセスが大量発生する

Gunicorn の --worker-connections を 10000 にしようとしたときに、間違えて -w 10000 として ワーカー数が 10000 になった。当然プロセスが大量に生まれるので、アクセスするとめちゃくちゃ重くて Load average が 170 になった。

sudo や w すらも謎のエラーで使えなくなったので、 root で入って systemctl kill した。 systemctl は kill できるので最高！*2

uWSGI の restart が効かないので reboot を繰り返す

いろいろあって Gunicorn を uWSGI に載せ換えたのだけど、なぜか restart がハングするようになってしまった。面倒なのでサーバーごと reboot することで restart の代わりにしていた。後述の Redis と同じ理由かも？

途中から systemctl kill --signal=9 すると restart=true で立ち上がることに気付いたのでそれを使うようにした。 systemctl は kill できるので最高！*3

Redis が立ち上がらないので memcached にする

Redis を apt で素朴に入れたけど apt install や systemctl restart がハングしたので諦めて memcached 入れた。おそらく↓の話っぽい。

Redis は kill して purge した。 systemctl は kill できるので最高！*4

並列 http アクセスライブラリを入れようとして未実装であることに気づく

transactions で外部 API を呼んでいるところが直列で遅かったので、並列にしよう！ということで検索して出てきた httpx というライブラリを使うことにした。

github.com

www.encode.io

このドキュメントに即して実装を始めたのだけど、20分程度して実装が終わりつつあったときにドキュメントにある警告文の存在に気付いた。

Warning

This page documents some proposed functionality that is not yet released. See pull request #52 for the first-pass of an implementation.

https://www.encode.io/httpx/parallel/

悲しいね〜。文章読めるようになる必要がある。

Gunicorn や uWSGI を使うと点数が伸びなくなる

途中、デバッグのために Gunicorn じゃなくて Flask の app.run() を直接使っていた。それでうまく伸びていたのだけど、Gunicorn にした瞬間に点数が1/10になった。uWSGI でも同様で、これについては今も謎。コンテスト中盤からずっとネックになっていて、終盤ドタバタした遠因になったと思う。

今見たら app.run() の方は threaded=True になってるので、10 workers の Gunicorn とはいろいろ違ったんだろうか。でも初めは上手くいってたので謎。

並列処理たちとのたたかい

gthread

Gunicorn は gthread を使うことができるのでなんとなく設定して使ったら動いているように見えた。ただ、大量に受け取りすぎて 499 ばかり返すようになってしまったので、もう少しチューニングが必要そうな雰囲気だった。

nodejs でも同じような悩みがあるのだろうか。それとも真にイベントループな言語は関係ないのだろうか...。

transaction

今回は transaction での外部 API が直列でめちゃくちゃ遅いのが課題になっていた。Python の並列処理にいい思い出が無いので、そこだけ nodejs に流すことも考えたものの、cookie やらを考えて結局 Python で行うことにした。

ただ Python の async await ほとんど分からないので難航。出たの最近だし機能もどんどん増えてるので、ぱっと調べるには向いていなかった *5。

結局最後の最後*6には aiohttp 使って勘でなんとかなった気もするけど、他のエラーでてたので分からなかった。

次回は go か node でやってもいいなあ、でも今回で async への理解深まったので Python で使える気もする。自分が一番好きで詳しい言語である Python によく分からないメジャー機能があるのがとても悔しい…。

良かった点

反省点ばっかりなのもアレなので良かった点も。

  • 遠隔で行ったが、専用ディスプレイにずっと遠隔者のディスプレイを写していた
    • スムーズな情報共有ができたと思う。全員同じ場所にいても有効だと思った。
    • 次は VSCode Liveshare とか使ってみたいな。
  • バグったときのために、オリジナル版を別ポートで動かしていた
    • バグったときにレスポンスをオリジナル版からも取得して diff する、といった活動を行っていて低コストながら高速にバグを発見できた
  • 計測やログイン環境のセットアップは順調にできた
  • pt-query-digest や kataribe などでボトルネックの計算をちゃんと行っていた
  • 定期的に git commit していたので容易に rollback できた
  • スコア計算方法の部分はちゃんと読み込んでいた
  • 手が空いたときに弁当を買いに行くという判断をした
  • 昼飯をちゃんと食べた
  • 楽しかった

その他

@チーム

今年もありがとうございました。 wass の迅速な方針決めや実装は頼りになったし、utgw が N+1 や index をバシバシ解決していく姿は最高だった。来年も頑張りたい！！

@運営

今回も楽しかったです！

バランスの良い問題になってて良かったです。isucari や還元キャンペーンなど、いかにもメルカリっぽい話題でニヤッとしました。あと得点がレスポンス数ではなく取引価格の合計なのも、実際のサービス目標感があって良かったです。

運営・インフラ提供・問題作成者の皆さん、ありがとうございました！！

感想

今年はあんまりやる気なくて練習もせず適当に始めたのだけど、実際やったらめっちゃ楽しいし、負けたらめっちゃ悔しい。 ISUCON4 からずっと参加しているけど、最高のコンテストだと思う。

次回もあれば絶対に参加したい！！！！！本戦行くぞ！！！

*1:async wait 実装は入っていない

*2:そういう話ではない

*3:そういう話ではない

*4:そういう話ではない

*5:asyncio.sleep() じゃなくて sleep() つかって上手く行かないじゃん！とか言ってた

*6:17:59 ぐらい

各 OS の 802.1X 認証における RADIUS サーバーの検証方法

RADIUS

最近 802.1X 認証（WPA2 Enterprise）を構築していた。野良 RADIUS サーバーに Credentail を渡さないためには、サーバー証明書などで RADIUS サーバーの検証を行うことが必要である。 各 OS でどう検証できるかを調べたのでメモ。

今回はクライアントにサーバーの証明書をインストールしない。また、EAP 方式は EAP-TTLS-PAP / EAP-TTLS-GTC。

Android

Android 7.0 より前は、自分でサーバーのCA証明書をインストールするしか検証方法がなかった。何も検証せずに使ってる人が多いのではないか…。

Android 7.0 以降は CA 証明書に「システム証明書」が使えるようになり、RADIUS サーバーの証明書をルート証明書で検証できるようになった。

システム証明書で検証する場合はドメイン名の指定が必須になる。

サーバーの証明書が指定したドメイン名であり、かつルート証明書で検証できれば接続される。

iOS

iOS 12 で検証。

802.1x 認証の場合、ルート証明書に関わらず サーバーの証明書を信頼するかどうかのダイアログが出る。

この時、サーバー証明書がルート証明書で検証できるかどうかが分からない *1 ので、SHA256 fingerprint などを頼りにユーザーが判断することになる。

管理者は SHA256 fingerprint とドメイン名（CN）を提供すれば良いと思う。

Windows 10

記事執筆時点での最新バージョンで検証。

Windows 10 では、ルート証明書での検証はしてくれるが、接続時に証明書の SHA256 fingerprint しか確認できない。

ドメイン名を指定するには、古い設定画面からドメイン名を入力し、信頼するルート証明書を選択する必要がある。この画面に行くのはなかなか難しい *2 ので、通常は SHA256 fingerprint を見てもらうことになりそう。

macOS

macOS 10.14 で検証。

macOS は接続時に証明書の確認画面が出る。そこには

などが見れる。

なので、ユーザーにはドメイン名と、証明書が信頼されているかの確認をして接続してもらうと良い *3 。

まとめ

OS ルート証明書での検証（ドメイン名指定） SHA256 fingerprint 表示
Android（7.0 以降） o x
iOS x o
Windows 10 △ o
macOS o o

となるので、管理者は

  • ルート証明書で検証できる証明書を LE 等で作る
  • ドメイン名 （または CN）と SHA256 Fingerprint を提供して、ユーザーに検証するよう呼びかける
    • Android 7.0 未満は諦めるかサーバーのCA証明書を配布する

と良さそうだった。

*1:困ってる人は割といそう。 https://seclists.org/educause/2017/q4/54 を読んでやや納得した。

*2:アダプタ設定から辿れる

*3:タイムアウトが非常に早く、確認しているとたいてい再認証が必要になるのが玉にキズ

Ansible で大量のホストに対して実行する場合のメモリ対策

Ansible

Ansible で大量のホストを対象として Playbook を実行すると、大量の変数を保持する結果、メモリが足りなくなることがある。

以下はその対策。

gather_subset を用いて収集する fact を制限する

Ansible は gather_facts（または setup モジュール）で大量の fact を取得するが、これを必要最低限にすることでメモリ使用量を抑えることができる。

gather_subset という setup モジュールのオプションを使う。

gather_facts: no
tasks:
- name: Gather facts
  setup:
    gather_subset: min

serial を用いて数回に分けて PlayBook を実行する

serial: 150 とすることで 、150ホストごとに PlayBook が走る。

使い終わった巨大な変数は初期化しておく

serial にしていても PlayBook の実行ごとにメモリ使用量は増えることがある。

このような場合は、PlayBook の最後で巨大な変数を初期化する（最終手段っぽい）。

tasks:
- name: Save large output
  command: command_outputs_large_text
  register: large_output
  
...

- name: Init values
  set_fact:
    large_output: !!null