yumiを作成する

解説 ― SET 1 で何をしたか

1行目でホームディレクトリにいることを確認し、2行目のls /homeで、今はubuntuディレクトリしか存在しないことを先に見ておきます。この「作成前」の状態を覚えておくと、あとの変化がよくわかります。

3行目のsudo adduser yumiが今回の主役です。adduserは新しいユーザーを作成するコマンドですが、「ユーザーを新しく作る」というのはシステム全体に関わる重い操作なので、2-1で学んだsudoが必須です。一般ユーザーであるubuntuには、他人のアカウントを勝手に作る権限はありません。管理者権限を借りて初めて実行できます。

実行すると出力例のように、いくつか対話形式の質問が続きます。New passwordではyumiというアカウントに設定するパスワードを入力します(画面には文字が表示されませんが、ちゃんと入力されています)。Retype new passwordで確認のため同じパスワードをもう一度入力し、Full Nameなどの追加情報はこの講座では空欄のままEnterで進めて構いません。最後に内容確認が表示されるのでyで確定すると、ユーザー作成が完了します。4行目のwhoamiで、adduserを実行した後も自分自身は変わらずubuntuのままであることを確認しておきます(adduserはあくまで「新しい人を作る」操作であって、自分がその人に変わるわけではありません)。

5行目のid yumiは、2-1で自分自身に対して使ったidコマンドに、確認したいユーザー名を引数として渡す使い方です。実行するとuid=1001(yumi) gid=1001(yumi) groups=1001(yumi)のような出力が得られ、yumiにも専用のUIDとGIDが割り振られ、yumiという名前のグループにも所属していることがわかります(Ubuntuでは、ユーザーを作ると同じ名前の専用グループも自動的に作られます)。

6行目のls /homeを実行すると、2行目と見比べて、yumiという新しいディレクトリが増えていることが確認できます。adduserはユーザーを作るだけでなく、/home/yumiという専用のホームディレクトリも自動で用意してくれます。7行目でsudoを付けて中身を覗くと、ubuntuユーザーの~で見たのと同じような初期ドットファイル一式が、すでにyumiのために用意されていることがわかります。sudoが必要な理由は、他人(yumi)のホームディレクトリの中身を見る操作だからです。自分のディレクトリなら不要ですが、他のユーザーの領域を覗くには管理者権限が要ります。8行目のgroups yumiで、この時点のyumiがまだ自分専用のyumiグループにしか所属していないことも確認しておきます(devteamグループへの追加は2-5で扱います)。9行目のhostname(0-3で学習済み)でサーバー名を再確認し、10行目のcd ~でホームディレクトリに戻って次のSETに備えます。

解説 ― SET 2 で何をしたか

1行目のcat /etc/passwdを実行すると、大量の行がずらっと表示されて面食らうかもしれません。これはこのサーバー上に存在する全てのユーザー(人間だけでなく、システムが裏側で使う専用アカウントも含む)の一覧です。2-1で見た/etc/shadowとは違い、/etc/passwd^※5は誰でも読めるファイルであることにも注目してください。パスワードそのものはここには含まれていないため、比較的ゆるく公開されています。2行目のwc -l(1-4で学んだ行数カウント)で、全部で何行(何ユーザー分の情報)あるかを先に数えておきます。

情報量が多いので、3行目のようにgrep(3-4で詳しく扱う検索コマンド。ここでは「特定の文字列を含む行だけを抜き出す」働きだと理解してください)を使ってyumiの行だけに絞り込みます。出力例のyumi:x:1001:1001:,,,:/home/yumi:/bin/bashという1行は、:(コロン)区切りで7つの情報を持っています。左から順に「①ユーザー名」「②パスワード欄(xは実体が/etc/shadowにあることを示す印)」「③UID^※3」「④GID」「⑤コメント(氏名など)」「⑥ホームディレクトリ」「⑦ログインシェル^※4」です。4行目で見比べるubuntuの行と並べると、UIDが1000と1001で連番になっていることや、どちらも/bin/bashというシェル(コマンドを解釈するプログラム。普段私たちが打っているのはこのbash)を使っていることがわかります。

5行目、改めてsudoなしで/etc/shadowを見ようとすると、2-1で確認したとおりPermission deniedで拒否されます。6行目のsudo grep yumi /etc/shadowでは、sudoを付けて2-1で読めなかった/etc/shadow側のyumiの行を見ます。ここでもsudoが必要な理由は、パスワードのハッシュ値という機密情報を含むファイルだからです。出力例の$6$...という部分が暗号化されたパスワードの実体で、これは復号できない一方向のハッシュ^※1という仕組みで守られています。

7〜8行目のgetent passwdは、/etc/passwdを直接grepするのと似た結果を、システムのユーザー情報データベースから正式なやり方で取得するコマンドです。grepは「たまたまそのファイルにその文字列がある行」を探すのに対し、getentは「そのユーザー名は本当に存在するか」をシステムに正式に問い合わせるという違いがあります。9行目のcut -d: -f1 /etc/passwd | tail -n 3(3-5で詳しく扱うcutを先取り)は、:区切りの1番目のフィールド、つまりユーザー名だけを取り出し、末尾3件を表示しています。最後の10行目のtype yumi(1-5で学んだコマンド)は、あえて「yumiというコマンドがあるか」を調べていますが、yumiはコマンドではなくユーザー名なので、出力例のようにnot foundとなります。「ユーザー名とコマンド名は別の名前空間で管理されている」ことをここで確認しておきましょう。

解説 ― SET 3 で何をしたか

1行目で改めてyumiのホームディレクトリの中身を確認し、2行目では.bashrc(bashの設定ファイル)の先頭5行だけをhead(1-4で学習済み)とパイプ^※2で覗いています。3行目でも同様に.profile(ログイン時に読み込まれる別の設定ファイル)の先頭を確認します。中身はubuntuユーザーが最初から持っていたものとほぼ同じ、Ubuntuが用意した標準のテンプレートです。

4行目のls -ldは、-lに-d(directory)を加えたオプションで、ディレクトリの「中身」ではなく「そのディレクトリ自体」の情報を1行で表示します。出力例のdrwxr-x--- 3 yumi yumi ...を見ると、所有者もグループもyumiになっていることがわかります。これは、adduserがホームディレクトリを作成する際、自動的にそのユーザー自身を持ち主として設定してくれるためです。5行目でubuntuの/home/ubuntuと見比べても、同じパターンになっていることが確認できます(権限記号の詳しい読み方は2-4で扱います)。

6行目のtail -n 1で/etc/passwdの最後の1行を見ると、直近で追加されたyumiの行が末尾にあることが多く、「新しいユーザーは基本的に一覧の後ろに追加されていく」感覚がつかめます。7行目のsudo passwd -S yumiは、yumiのパスワードが正しく設定されている状態かどうかを一行で確認するコマンドです(Pと表示されれば有効なパスワードが設定済みという意味です)。ここでsudoが必要なのは、他人のパスワード状態を照会する操作だからです。8行目のdate(0-3で学習済み)で、yumiが誕生した記念すべき日時を確認しておきましょう。

最後に9行目のcd ~、10行目のpwdで、自分(ubuntu)のホームディレクトリに戻っていることを確認してこのページを締めくくります。