分かってる。2017年にもなって、まだ Boxen ユーザーがいたことに驚いているんだろう？
しかし、今回の焦点はそこではない。少なくとも僕のユースケース（後述）にとっては、パーフェクトではないにしろ、Boxen は良い働きをしてくれていたし、長く苦楽を共にした戦友ともいえる存在だった。
そんな Boxen がリブセンス入社初日に死んだ。
具体的に言うと、
- Mac の ユーザー名が数字のみ だと Boxen がエラーを吐いてマトモに動かない
- 原因は Boxen が使っている Puppet が、ユーザー名が数字のみだと、user ではなく uid として扱ってしまうため
- ユーザー名が数字のみだと Boxen や Puppet だけでなく他のツールでも不具合を引き起こす可能性がある
ということについて、皆さんに注意を促すエントリーである。
前提）リブセンスでは
前提として、リブセンスでは
- ユーザーとコンピュータの管理に Active Directory を使っている
- Mac ユーザーと Windows ユーザー間で共有ドライブでファイルを共有したりもしている
- 入社時には既に Active Directory でユーザー作成された Mac（または Windows）を貸与してもらえる
- ユーザー名は
123456などの数字のみ - プライマリのグループ名は
staffではない
ユーザー名が数字のみのユーザーは作れるのか？
そもそもユーザー名が数字のみのユーザーなんて作れるのか？という話だが、通常はバリデーションに引っ掛かって作成できない。
しかし、Active Directory を使うと、アカウント名やパスワードのポリシーが Active Directory に従うようになるので、数字のみのユーザー名が作成できたのだと思う（このあたりあまり詳しくない）
ユーザー名が数字のみだと権限まわりで問題が発生する
そして、自分用の Boxen マニフェストをダウンロードして boxen コマンドを実行したときに問題は起こった。
（なお、Boxen は裏で Puppet を使っており、Boxen は Mac 上で Puppet を便利に使うためのフレームワーク）
下記のようなメッセージがたくさん吐かれたんだけど、最初は意味が分からなかった。
Notice: ... File[/Users/123456/.ssh]/owner: owner changed '123456' to '123456'
検索すると、下記に辿り着いた。
意訳）ユーザー名が数字のみだと、別アカウントとして扱われる
これに対して、最後のコメントあたりで、user 109056 ではなく uid 109056 として扱われたのでは？と書かれている。
Here's another test - what happens when you run "chown 9827 /home/109056"? Then what happens when you run "chown 109056 /home/109056"? In your home dir listing above, uid 109056 owns /home/109056, not user 109056. That's why you get a perm error when you try to su. Puppet may be part of...
公式ドキュメントみると、File リソースの owner 属性は、ユーザー名またはユーザーID で指定してねと書かれているので、まさにそういうことだった。
Resource Type: file - Puppet (PE and open source) 4.10 | Puppet https://puppet.com/docs/puppet/4.10/types/file.html#file-attribute-owner
The user to whom the file should belong. Argument can be a user name or a user ID.
僕のケースでは例えば /Users/123456/.ssh の権限が別アカウントのものになって、Git を使った操作がことごとく Authentication failed. になったりした。
（その後 chown 12345 /Users/123456/.ssh 打って、ディレクトリの権限を元に戻した）
Boxen を諦めるに至った理由
なんとか Boxen を使い続けたかったので粘ってみた。
問題となっているのは File リソースの owner を、
File {
...
owner => $boxen_user
}
というように記述している箇所で、owner 指定を全部外してしまえば、とりあえず動くのでは？と一旦思ったりしたけれど、ライブラリ等、自分で記述している以外の箇所でも書かれていて断念した。
（owner 属性の指定を省略すると、デフォルトで実行ユーザーのものになるんだっけ？公式ドキュメントで見つけられなくて、かつ試していない）
例えば Boxen の根幹を担う boxen/puppet-homebrew にも owner => $::boxen_user の記述がある。
ついでに言うと group => 'staff という記述もあり、リブセンスの
プライマリのグループ名は
staffではない
という現状にマッチしていない。
Boxen を諦めてどうしたか？
では Boxen を諦めてどうしたか？
最初のうちは、やむを得ず、手動でいろいろなアプリをインストール＆設定していたが、先週末にカッとなって Itamae に移行した。
構成管理ツールが必要だった理由
そもそも Boxen で何をやっていたかというと、いろいろなアプリケーションの インストールはメインではない。メインは 設定ファイルのバージョン管理及び複数マシン間での同期 だった。
設定ファイルはホームディレクトリ配下のいわゆる dotfiles だけでなく、~/Library/Application Support 配下や ~/Library/Preferences 配下のものも対象としていた。
- 例: JetBrains IDE の設定ファイルは
~/Library/Preferences配下にある
そのような理由で dotfiles リポジトリを作成するだけでは不足しており、かつ設定ファイルも相当数に及ぶのでこれを手作業で扱うのはしんどいという理由からどうしても構成管理ツールが必要だった。
Itamae を選んだ理由
選定にあたって下記を要件とした。
- 多機能ではなく、シンプルであること
- 用途は限られているので多機能は不要
- 自分で書いていない（自分で制御しにくい）範囲はできるだけ小さく保ちたい
- ソースが読みやすいこと
- 今回の件のように予期せぬ挙動をしたときに対応できるようにするため
シンプル重視なので Chef を候補から外し、自分は Python よりも Ruby のほうが得意なので Ansible ではなく Itamae を選んだ。
あと 転職ドラフト では構成管理に Itamae を使っているんだけど、自分はそれを使ったことがなくて、手に馴染ませておきたいというのも少し影響した。
Itamae が（現時点では）大丈夫だと判断した理由
Boxen で踏んだ轍を踏まないように、ユーザー名が数字のみでも Itamae なら大丈夫か確認した。
- Itamae は owner を指定しなければ、ファイル権限について余計なことはしない
- Itamae が使っている Specinfra も、ユーザー名が数字のみだったら uid として扱うなどということはしない
- Itamae から Homebrew を使うときに itamae-plugin-resource-brew という gem を使っているが、これも意図しないうちにファイル権限を指定したりしない
そんなこんなで、今は Itamae とトモダチだ。
今後のこと
さて、Boxen や Puppet に限らず、他のツールでもユーザー名は OS のポリシーに従って作成されているだろうという前提のもとに作られていると考えられる。
つまり（こちら でも指摘されているけれど）OS のポリシーに反するユーザー名を付けていれば、他のツールでも何らかの不具合を引き起こす可能性がある。
したがって、ゆくゆくは数字のみのユーザー名は変更していきたいという気持ち。既存のマシンはさておき、せめて今後セットアップするマシンについては例えば usr123456 みたいな感じで prefix 付けるとか。
ただ、これまでの経緯を知らないし、変更による Active Directory などへの影響も分からないので、まずは関係部署に相談といったところかなあ。