snapがうまく動かないのはmake 4.3とAppArmorの組み合わせのせいだった話

久しぶりにsnapで入れたmicrok8sを動かそうとしたら全然動かなくて、調べていくとAppArmorが動かなくなっていることに気付いた。

AppArmorの起動ログには、以下のようにcapabilityがおかしいというエラーがたくさんでていたのだけど、さすがに sys_admin がないというのはおかしい。

AppArmor parser error for /etc/apparmor.d/sbin.klogd in /etc/apparmor.d/sbin.klogd at line 17: Invalid capability sys_admin.

インターネットの海をさまようと、AppArmorのissue Make.rules fails to generate cap_names.h and af_names.h (#74) · Issues · AppArmor / apparmor · GitLab と、Gentoo側のissue 714158 – sys-apps/apparmor-2.13.4 -> ? fails at runtime if built with sys-devel/make-4.3をみつけて、なるほどとなった。

Gentoo側のissueの通り、make 4.3をmaskして4.2に落として、再度コンパイルしたら動くようになったのでよかったですね。

laymanからeselect-repositoryに移行した

数日前のGURUの記事に対してursmがmentionをくれたので早速移行した。

移行といっても、実際はemerge eselect-repositoryをするだけでよいので楽ちん。layman -leselect repository list -iを見比べて、有効になっているoverlayが同じだったらOK。

[11:20:33] in ~ via 💎 v2.7.1
❯ layman -l

 * dotnet                    [Git       ] (https://github.com/gentoo/dotnet.git                                              )
 * go-overlay                [Git       ] (https://github.com/Dr-Terrible/go-overlay.git                                     )
 * guru                      [Git       ] (https://anongit.gentoo.org/git/repo/proj/guru.git                                 )
 * jorgicio                  [Git       ] (https://github.com/jorgicio/jorgicio-gentoo.git                                   )
 * snapd                     [Git       ] (https://github.com/zigford/snapd.git                                              )


[11:23:36] in ~ via 💎 v2.7.1
❯ sudo eselect repository list -i
Available repositories:
  [99]  dotnet # (https://github.com/gentoo/dotnet)
  [148] gentoo * (https://gentoo.org/)
  [163] go-overlay # (https://github.com/Dr-Terrible/go-overlay)
  [168] guru # (https://wiki.gentoo.org/wiki/Project:GURU)
  [197] jorgicio # (https://github.com/jorgicio/jorgicio-gentoo)
  [276] pepabo @
  [349] snapd # (https://github.com/zigford/snapd)

eselect-repositoryの方は、privateなリポジトリもでて便利。よかったよかった。

see also: eselect/repository - Gentoo Wiki

procsのebuildをGURUにコミットした

Rustで書かれたモダンpsことdalance/procsのebuildファイルをGURUにコミットした。

Rustのツールをebuildにするのはcardoe/cargo-ebuildというコマンドを使うと一撃でできるのだけど、出来上がったebuildファイルにコメントがあるとおり、このツールではライセンスのリストがうまく出せないことがある。

cargo-ebuildが出力するebuildファイルのLICENSEの部分は、リンクする全てのライブラリのライセンスを集めてきて出してくれるのだけど、

  • 2つのライセンスが設定されている場合は両方でてくるが、実際にはどちらか一方となっているものも多い
  • portageのLICENSE名と必ずしも一致していない

という問題がある。

最終的にどういうライセンスにすればよいかは、onur/cargo-licenseというものを使えと書いてあって、これがメチャクチャ便利…すごい。これの出力をみながら、最小限のANDをとっていくとよさそう。

portageのライセンス名とのマッチングは License groups - Gentoo Wiki このあたりを見ながらマッチングしていけば良さそう。procsのebuildを作るにあたり困ったのは、BSD-3-Clauseというライセンスで、これはportage的にはBSDというライセンスだったので直したりした。

gnome-lightからの依存でClutterが入らなくなってた話

日課のうどんワールドとdepcleanの後、ChWick/gnomesome が動かなくなっているのに気付いて、GNOME Tweaksを見てみるとClutterがないよーというエラーが出ていた。

eix -e clutterを見てもたしかに入ってないし、/var/log/emerge.logを見るとdepcleanでも消えてることに気付いた。

とりあえず復旧させたいのだけど、Clutterを直接入れるのも違うよなーと思って、一番それっぽいgnome-shell-extensionsを入れてお茶を濁す子にした。

depcleanするときはよく画面を見ましょう。

Social Media Distancing

june29の Social Distancing と 2020 年 - #june29jp を楽しく読ませてもらった記憶も薄れないうちに、緊急事態宣言のニュースが飛び込んできた。

この発表内容およびスピーチについて、自分の立場と今の家庭環境においては、よいスピーチだと感じたし、内容についても引き続き頑張っていこうと思えるものだった。

さて、GMOインターネットグループの在宅勤務が始まったのは2020-01-27なので今月末で3ヶ月だ。この期間、インターネットを介さずに会話をした人は、家族、お隣さん、マンションの清掃の方、お店のレジの人、配達業者の方、これくらいだ。知人と呼べる人とはすべてインターネットでのみ繋がっている。自分と社会の接点はインターネットになったように思えた。

今の自分は、「インターネットでも繋がっている」と「インターネット繋がっている」の違いに戸惑っているのかもしれない。インターネット大好きだと思っていた自分が、「繋がり」の手段がインターネットに限定されたことによってストレスを感じているのかもしれない。

昨日、新型コロナウィルスと私と - 良いあそなすちゃんを読み、似たような思いをもっている人がn人いることを知って、心が少しだけ穏やかになった気がした。数ヶ月前なら許容できた言葉や、素直に受け止めることができたであろう言葉に、今は強く心を動かされてしまっている自分を許すことができるようになった気がした。

「今はしょうがないよ」。そう思いながら、青い鳥のアイコンを長押しして、左上に出てきた☓ボタンを押した。

NewRelicを使って特定のエラーの発生を検知する

NewRelicには、NRQL(New Relic Query Language)というクエリ言語を使って、NewRelicに溜まっている様々なデータを検索したりする仕組みがある。

NRQLについては、社内でもたまに勉強会が行われていて(New Relic勉強会をペパボ社内で開催しました - ペパボテックブログ)、うまく活用しているサービスも多い。

これとAlertsを組み合わせると、特定のエラーの発生や、エラーの傾向の変化でアラートを発生させることができるようになる。

NRQLとデータ構造

NRQLで扱うことのできるデータは NRQL入門 | New Relicのドキュメント あたりにまとまっており、アプリケーションのエラー情報は TransactionError に入っている。

さて、次はこのデータ構造がどうなっているかを調べる必要があるのだけど、それは New Relic data dictionary | New Relic Documentation を見るとわかる。もしくは、Insightsという機能で

SELECT * FROM TransactionError

といったクエリを流してみると、具体的にどういう情報が入っているかわかると思う。error.classerror.messageにどういった文字列が入るかは言語に依るところがあるので、実際のデータをみるのはどちらにしても必要だろう。

ドキュメントにはなさそうだけど面白いカラムとしてaggregateFacetというものがある。NewRelicやこの手のエラートラッキングシステムでは、類似のエラーをまとめる機能がだいたいついているが、このキーとなるのがaggregateFacetというカラムのようだ。今回は使わなかったが、このカラムのユニークカウントの傾向で、新しいエラーが起きているかを検知できそう。

NRQLでAlertsを設定する

TransactionErrorの内容はわかったので、これをアラートに適用していく。今回は「PHPを使ったアプリケーションで、WARNINGもNewRelicに通知しているが、E_ERRORが一定数を超えたときにアラートにしたい」ということをやった。

「Alerts poricies」がなければ新しく作り、あるものに追加するのであればそれを選び、「add a Condition」を選ぶと「Categories」の中に「NRQL」があるので選ぶ。

今回設定したクエリは以下の通り。PHPアプリケーションの場合は、error.classにはE_ERRORE_WARNINGといった文字列が入っていることがわかったので、これをつかってWARNINGを除いた単位時間あたりの数をアラートのしきい値にすることにした。

select count(*)
from TransactionError
where appName = 'your-app-name' and error.class not in ('E_USER_WARNING', 'E_WARNING')

アラートのしきい値の設定方法は以下の3つがあり、今回は「Static」を選んだが、他2つも便利そうなのでいつか使ってみようと思う。

  • 固定値の「Static」
  • 傾向を見る「Baseline」
  • 2つの値の関係をみる「Outliner」

実際に設定したのは画面はこんな感じ。時間や縦軸はぼかしてある。

NewRelic Alertsのスクリーンショット

おわりに

NewRelic(NRQL)を使って、特定のエラーの発生を通知する仕組みについて紹介した。エラーのトリアージが必要な場合もあると思っていて「新しい機能をリリースしたのでその機能に関係するエラーについてのみ知りたい」「特定の画面は特に重要度が高いので、通知のポリシーを分けたい」といったような使い方にも応用できると思う。

「エンジニアのためのリスクマネジメント入門」を読んだ

タイトルには「エンジニアのための」とあるが、3章の事例がエンジニアにとって身近な話題というだけで、一般的なリスクマネジメントの歴史から言葉の定義、関連する標準規格まで幅広くおさえられる書籍だと感じた。

特に、リスクコントロールの4つのパターン、「保有」「低減」「回避」「移転」という考え方を知ることができたのは、明日から役立つ内容でよかった。

仕事でもリスクの評価と対応について検討する機会があるが、リスクの評価については書籍のとおり「発生可能性」と「影響度」でマッピングしているものの、その後の対応をどうするかというのは迷うことがあった。この本のおかげで、より自信をもって論理的に判断できるようになったと思う。「リスクを保有する」と判断することもコントロールしていることなのだ。

また、3章のコラム的なところで、「防止的コントロール」と「発見的コントロール」という概念を知ることができたのも収穫だった。リスクに対処しようとすると、発生要因を潰す防止的コントロールを選択しがちだ。しかし、リスクの評価結果によっては、リスクが顕在化してからのダメージを軽減するための「発見的コントロール」でも十分のケースもあり、多くの場合は発見的コントロールのほうがコストが低いのだ。

このあたりも、なんとなくそういう選択をしていることはあったように思うが、これからはより意識的に選択することができるように思う。

本書を読んだことで、リスクマネジメントについての語彙や考え方を身につけることができ、今までやってきたことの意味を再確認できた。

エンジニアはもちろん、情報技術に関わる人で、リスクマネジメントを学ぶ際に最初に読む一冊としてとても良い内容ではないかと思った。索引や参考文献が数多く載っているので、より深く学びたいときのポインタも十分にあるのもおすすめポイントだ。

より細かい読書メモはscrapboxの エンジニアのためのリスクマネジメント入門 - kenchan にあるので、興味のある方はぜひ。