前書き

私の会社では、HOST環境(Linux開発環境)を1ユーザ/PC1台ではなく、
複数ユーザ/PC1台として割り当て、同じ環境を共有しながら開発する事が少なくありません。
当然、1ユーザ/PC1台で開発できる事が望ましいですが、その理想との現実の間には、

PC台数を増やすのに、社内調整が必要
開発環境の準備が面倒かつデプロイの仕組みを改善するメリットが少ない
ライセンスの都合上、1台のPCにしか導入できないツールの存在

と複数の問題があり、根本的解決を図る事が~~できるがやりたくない~~難しい場合が多いです。
そのため、代替案として複数人が同じ環境にSSHを用いて、同じアカウントでログインします。
　
　
しかし、この代替案は不満点があります。

アカウントが一つしか無いため、ユーザ固有設定ファイル(例：.vimrc、.emacs)を置きづらい
パスワードを複数人で共有(セキュリティ的に問題がある)
誤って他人のディレクトリを消去する事故が発生
不必要な人に管理権限を渡して事故る(~~オペミスで/etc/passwdを消して環境壊したのは私だ~~)

これらの小さな不満を解消し、
少しでも効率的な開発をするために押さえたいポイントを本記事に記載します。

検証環境

　・Debian8.6(64bit)

ユーザアカウントは1ユーザ/1アカウント

目的は、ユーザ固有の設定ファイル(例：.vimrc、.emacs)を自由に作成できるようにする事、
突発的な事故(例：$ rm -rf ./)などの影響範囲を少くする事です。
# そもそも、アカウントを人単位で作成しない理由を聞きたい時がある。

ログインシェルは、bashを指定するのが無難です。
その理由は、ShellScriptを作成する人によっては、bashによる実行を想定しつつも、
Shebangを#!/bin/shで記載する不届き者がいるからです。
DebianやUbuntuではshはdashであり、bash想定の実装はエラーになります。

$ ls -al /bin/sh
lrwxrwxrwx 1 root root 4  1月 24  2017 /bin/sh -> dash

そんな人から「Scriptが動かない！」とクレームが入るより、Shellをbashに設定して、
意識の高いdash/tcsh/zsh派からの「Shellを変更していいですか」に対応する方が精神的に楽です。

なお、ユーザアカウントの作成方法(useraddコマンドの使い方)は、以下の通りです。

$ sudo useradd -s /bin/bash -d /home/qiita -m qiita


(アカウント作成確認)
$ cat /etc/passwd | grep qiita
qiita:x:1006:1006::/home/qiita:/bin/bash

$ ls -al /home/qiita/
合計 20
drwxr-xr-x  2 qiita qiita 4096  3月 10 12:48 .
drwxr-xr-x 10 root  root  4096  3月 10 12:48 ..
-rw-r--r--  1 qiita qiita  220 11月 13  2014 .bash_logout
-rw-r--r--  1 qiita qiita 3526  5月 16  2017 .bashrc
-rw-r--r--  1 qiita qiita  675 11月 13  2014 .profile

useraddのオプション	説明
-d, --home-dir	新アカウントのホームディレクトリ
-m, --create-home	ユーザのホームディレクトリを作成
-s, --shell	新アカウントのログインシェル(cronと同じで絶対PATHで指定する事)

ちなみに、ログインシェル変更には、chshコマンドを使用します。

$ sudo chsh qiita
qiita のログインシェルを変更中
新しい値を入力してください。標準設定値を使うならリターンを押してください
    ログインシェル [/bin/bash]: /bin/dash

初回ログイン時にパスワードを強制的に変更させる

目的は、セキュリティ対策と社内規定対策で、
パスワードを変更しない人にデフォルトパスワードを使用させない事です。
セキュリティポリシー(パスワードに対する制約)を意識する場合はPAMの設定が必要ですが、
私はメンバにパスワードを一度変更してもらえれば満足なので、そこまでしません。

初回ログイン時にパスワードを強制変更させるには、passwdコマンドの-eオプションを使用します。
以下の例で試していますが、パスワードを変更したフリ(同じパスワードを使いまわす)と怒られます。

$ sudo passwd -e qiita
passwd: パスワード期限切れ情報を変更しました

$ su qiita
パスワード:
パスワードを直ちに変更する必要があります(強制されたルート)
qiita 用にパスワードを変更中
現在の UNIX パスワード:
新しい UNIX パスワードを入力してください:
新しい UNIX パスワードを再入力してください:
パスワードが変更されていません
新しい UNIX パスワードを入力してください:
新しい UNIX パスワードを再入力してください:

管理者権限は最小限に

目的は、不注意による事故防止です。
sudoコマンドを初めて実行する際に以下の警告(引用)が出ますが、
世界中のベテランでもウッカリをやらかすので、権限を余計なメンバに渡すべきではないと考えてます。

[原文]
We trust you have received the usual lecture from the local System
Administrator. It usually boils down to these three things:

1) Respect the privacy of others.
2) Think before you type.
3) With great power comes great responsibility.

[和訳]
我々は、あなたが身近な管理者から日常的なレクチャーを受けていると信じています。
通常、以下の3点に要約されます。

1）他のユーザのプライバシーを尊重する事
2）入力する前に考える事
3）大いなる力には大いなる責任が伴う事

しかし、メンバが管理者権限を使いたい場面がある事も事実です。
その場合、全てのコマンドにsudoコマンドを適応できる状態にするのではなく、
管理者権限が必要なコマンドを明確に"/etc/sudoers"ファイルに記載するべきです。
# シス管系女子で似たような話題を読んだ気もします。

以下の例では、ユーザ(qiita)にuseraddコマンド実行時のみ管理者権限が使えるようにしています。
なお、"/etc/sudoers"ファイルを編集する際のお作法として、visudoコマンドを使用します。
sudoersに誤った文法を記載した場合はsudoが実行負荷になります(rootユーザによる復旧が必須になります)が、
visudoコマンドで編集した場合は文法チェックが実行されます(誤変更は、保存されず破棄される)。

/etc/sudoers.(抜粋)

# 書式
# who     where     = (as_whom)      what
# ALLはワイルドカード
qiita   ALL=(ALL)  /usr/sbin/useradd

sudoers書式項目	説明
who	ユーザ名もしくはグループ名
where	HOSTNAME、IPアドレス、ネットワークアドレス、ネットグループ名のいずれかをカンマ区切りにしたリスト
as_whom	sudo付与時のプログラム実行ユーザ(指定がなければroot)
what	絶対PATHで指定したコマンドをカンマ区切りしたリスト

useraddコマンドがqiitaユーザで実行でき、
および管理者権限が必要なdeluserコマンドが実行できない事を以下に示します。

$ sudo useradd testtest
[sudo] qiita のパスワード:
$ cat /etc/passwd | grep testtest
testtest:x:1007:1007::/home/testtest:

$ sudo deluser testtest
ユーザー qiita は'/usr/sbin/deluser testtest' を root として nao 上で実行することは許可されていません。すみません。

アカウント作成時に設定ファイルを$HOME以下にインストール

目的は、ユーザが初期設定(例：.bashrcの編集やスクリプトのコピー)を行う手間を減らす事です。
ユーザのホームディレクトリの雛形は、"/etc/skel"ディレクトリであるため、
このディレクトリに適宜ファイルを追加・編集をします。

以下に、実行例を示します。

$ ls -al /etc/skel/
合計 28
drwxr-xr-x   2 root root  4096  3月 10 14:43 .
drwxr-xr-x 167 root root 12288  3月 10 14:42 ..
-rw-r--r--   1 root root   220 11月 13  2014 .bash_logout
-rw-r--r--   1 root root  3526  5月 16  2017 .bashrc
-rw-r--r--   1 root root   675 11月 13  2014 .profile

$ sudo touch /etc/skel/test_file　　　(注釈) 確認のためのテストファイル

$ sudo useradd -s /bin/bash -d /home/imas -m imas
$ ls /home/imas/
test_file                             (注釈) 通常のユーザ作成では、test_fileは存在しない

ログイン時に連絡事項・注意事項を表示

目的は、管理者から他のユーザへの告知です。
例えば、「ビルドが実施される時間帯」や「メンバで共有して使用するツールのPATH」を記載します。

このような目的を果たすには、"/etc/motd"ファイルを編集します。
MOTDは"Message of the day"の略であり、Debianのデフォルトは以下の通りです。

/etc/motd.

The programs included with the Debian GNU/Linux system are free software;                                    
the exact distribution terms for each program are described in the                                           
individual files in /usr/share/doc/*/copyright.                                                              

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent                                            
permitted by applicable law.

私は、motdの記述をcowsayコマンドで作れる牛に変更して、イタズラする事が多いです。
# でも最近、他の人が書いたエラーメッセージがアメコミ風でイラッとしたから、止めようと思う。

以下に、SSHを用いて、naoユーザにログインした場合の例を示します。

$ ssh nao@localhost
nao@localhost's password: 
Linux nao 4.9.0-4-amd64 #1 SMP Debian 4.9.65-3 (2017-12-03) x86_64
 ____________
< こんな感じ >
 ------------
        \   ^__^
         \  (oo)\_______
            (__)\       )\/\
                ||----w |
                ||     ||
You have new mail.
Last login: Sat Mar 10 14:58:55 2018 from ::1

最後に

内容が低レベルですが、バッドノウハウだから書く事に意味があると信じたい。
基本的に、LPIC Level1と被っているため、本記事の内容はご存じの方が多いと思います。

残念な事に、最も解決したい「内製便利Scriptをどのように保守するか」の答えが出ていません。
Scriptは"/usr/local/bin"に格納する事を前提にした場合、
gitやsvnなどでどのように保守すべきかが悩ましいです。~~サーバを建てると怒られるし~~

HOST環境(Linux開発環境)を複数ユーザで共有する際に押さえたい5つのポイント

前書き