共有ユーザー環境でIPアドレスごとにhistoryコマンドを使い分ける

Linux環境で、共有ユーザーを使っている場合に過去のコマンドの実行履歴を見てみようとしても誰が発行したものかわからなかったりして、何かサーバーに問題があったりした際にどのような作業をしたのかがわからずに困ったりすることがあります。

まぁ、共有でユーザー使うなよって話はありますが、そういった場合でも接続元のIPアドレスごとにhistoryコマンドの実行ログファイルを分けて保存することでユーザーごとのコマンド実行ログを残せたりします。

接続元のIPアドレスごとに.bash_historyを保存する

historyコマンドは、bash環境では通常は.bash_historyに保存されていきますが、これは環境変数で設定を変えることが出来ます。

以下のように、接続元のIPアドレスをベースにhisotryファイルを作るように.bash_profileに記述しておきます。

export RIPADDR=`who am i | cut -d '(' -f 2 | sed -e 's/)//g'`
export HISTFILE=~/.bash_history_${RIPADDR}

if [ ! -f $HISTFILE ]; then
    touch $HISTFILE
    chmod 600 $HISTFILE
fi

環境変数はRIPADDRは接続もとのIPアドレスを、HISTFILEでhistoryコマンドの実行履歴の保存ファイルを定義します。
あとは、接続時にその設定ファイルが存在しなければ作成するというような具合です。

SSHで接続した場合は、SSH_CONNECTIONという環境変数に接続元のIPアドレスがセットされますが、suしたりすると環境変数が消えてしまうので、who am iから取得しています。（もっと簡単に取得する方法ないんですかね）

ただ、この方法は接続先のサーバーにだけは有効ですが、踏み台にして接続したりしたら当然その先のサーバーでは接続元が皆同一になるので意味がなくなったりします・・・。

そういった場合は、制御端末ごとに保存するようにしておいてもよいかもしれません。

export RIPADDR=`who am i | cut -d '(' -f 2 | sed -e 's/)//g'`
export TTY_NUM=`tty | cut -d '/' -f4`
export HISTFILE=~/.bash_history_${RIPADDR}_pts${TTY_NUM}

ちなみに、誰がサーバーへの接続元IPや制御端末を誰が使ったかの情報は、lastコマンドで取得できるので、何かあった際はつき合わせて確認するということもできます。

$ last | less
work     pts/1        192.168.0.1 Sun Mar  4 15:25   still logged in
work     pts/2        192.168.0.2 Sun Jan 22 22:55 - 00:04  (01:08)
work     pts/1        192.168.0.1 Sun Jan 22 22:55 - 23:41  (00:46)

.bash_historyファイルは編集や削除が出来てしまうので、ログとしての信憑性は薄いのですが、日々の運用の中で参考情報としては使えるかもしれません。

[PR]安心の365日電話サポート付きWADAXレンタルサーバー。

[PR]スマホやTV、PCで、いつでも映画や海外ドラマを見れる！今すぐ無料視聴！

[PR]固定IPが【業界最安値クラス】＋【５分で発行】＋【２ヶ月無料体験】

Linux OSユーザーの色々なリソースを制限する

ものすごい数のアタックを受けているようなのでその際のユーザー名を晒す

対話型のコマンドを自動化できるexpectコマンド

[Linux] ファイルを暗号化する方法あれこれ

Linuxサーバー上でデータ操作に便利な10のコマンド

[Linux] 削除できないファイルの作り方

不要なファイルやディレクトリを削除できる「tmpwatch」コマンド

inotifyを使ってファイルやディレクトリに起きたイベントを簡単に監視する

Logwatchでサーバー上のログを集約する

[24時間365日] サーバ/インフラを支える技術

クラウド時代のエンジニアの活きる道

数年前と比べてエンジニアを取り巻く環境は劇的に変わってきています。

クラウドサービスが提供されるようになり、自社で構築しなくても素早く安価にサービスインできたり、非エンジニアでもアイデアを実現するツールとして比較的容易に利用できます。

こうなってくるとエンジニアの生きる道というのも限られてくるのではないかなと、自分としても不安に思ってきてしまいます。

作る側と使う側という二極化

クラウドサービスがユーザーの要件を満たす環境を素早く提供しだすと、エンジニアの仕事はどんどんとそのサービスによって搾取されていきそうです。

今更BBSやブログシステムを一から作ってサービスとして公開しようと思うエンジニアはいないしょう。
その辺は既に大規模なサービスやパッケージやそしてオープンなライブラリが提供されており、自分で作るより高機能でそして優秀です。

また、個人レベルてはなくSIerのような受託開発業者も一からスクラッチで作ってくれという案件も減ってくるかもしれません。

日本人は細かな所にこだわりますし、クラウドやパッケージで提供されるサービスが一見無駄と思える日本企業の文化に何処までマッチしてるかは不明ですが、要件に多少目を瞑れば遥かに高速、低コストで環境を揃えられるようになっています。

こうなってくるとエンジニアが例えシステムを作り上げる力量があったとしてもそれを活かす場が少なくなってきます。

もはや、エンジニアはクラウドやパッケージなど、ある程度シェアを誇るサービスを提供する企業でその中の人をやるか、サービスをカスタマイズしたり上手く組み合わせて付加価値を提供する使う側に回るという二極化をしてしまうかもしれません。

前者は豊富な経験と知識を兼ね備えたエンジニアが求められますので狭き門になりそうですし、後者はエンジニア以外にもアイデア次第でどうにかなってしまうところもあるので厳しい競争になりそうです。

一から何かを作るにしても大規模なサービスが完全に覇権を握ってしまっている領域ではとても太刀打ちできないでしょうから、ひと昔前のようになかなか新たに開拓して切り開くのは難しく思えます。

エンジニアが活きるニッチな領域を探す

ここまでの事は少し前まで自分が思ってたことですが、最近はそんな事もないのかなと感じてきたりしています。
理由は、大きなサービスはその提供範囲が広い故に必ず隙間ができてしまうということです。

その隙間、つまりはニッチな所で個人のエンジニアが活きる道はあるのではないかなと。

そのサービスのど真ん中に突っ込んで行くのは、先ほども言ったとおり到底太刀打ちできず、結果は目に見えているのでやめた方が良いでしょう。

しかし、大規模なサービスはその大きさゆえに小回りが効かなかったり、必ず取りこぼす領域がでてきます。
マイノリティだけど確かにニーズがある機能や、特定の地域にフォーカスを当てたサービスや、他社との利権が絡むような領域であったり、ニーズは多いんだけどマネタイズすることが難しかったりと、それは大企業だと目に入らない領域であったり、大きなサービスをそのためだけにカスタマイズするのは採算が合わなかったり、そんな小さなところに目を向けるぐらいならもっと金のなる木を見つけようとしたりと、規模が大きくなるサービス故の問題点やジレンマも出てきます。

だからこそそんなニッチな所に個人が入り込む隙間があるのではないかなと思うわけです。

大企業が手を出せない部分ってのはあるわけですから、そこを個としてのエンジニアがついていくというのはありでしょうし、小回りが効く故の利点もでてきます。

すべての顧客が既存のサービスを使う事を望んでるわけでもないでしょうし、差別化を図るならそのニーズもより協力に生まれてきます。

場合によっては大きく成長できる分野も出てくるのでしょうし、他の切り口から既存のサービスを切り崩していける可能性もあるでしょう。

まとめ

ここで書いた事は別に目新しい事ではありません。

IT業界を切り開いた先人も最初はそのニッチな分野から始めたという例も多々あります。

似たようなサービスでも視点を変えて、自分ならこうするのにってアイデアとそれが実現できるというエンジニアならではの自負があるからこそ新たなサービスが生まれてくるのでしょう。

OSS界では、似たようなパッケージやライブラリが次々出てきたりすることが多いですが、その辺も見た目は同じでも設計思想やユーザーに与えるメリットが異なるものが多かったりします。

これからのエンジニアはより、その隙間を見つける力も必要になってくるのだと思います。

この分野はあのサービスが抑えていると諦めるのではなく、ターゲットや切り口をを変えてみたりして隙間を狙って見ることも大事なんだなと最近感じます。

開発における感動は薄くなったのか

ソースを書くエンジニアと読み書きするエンジニア

クラウド化によって捨て去られる技術

エンジニアの管理をうまくやっていくためのコツ

フルスタックエンジニアなんて目指さない方がいい

未だにシステム化さえすれば自動化されると思っている人は多い

クラウド時代で高められる情シスの価値

サービス構築の実行コストは構築側より提案側のほうが上回ってるんじゃないかって話

プログラマが知るべき97のこと

規模の大きなプロジェクト運営で気をつけたいこと

システム屋が非システム屋と話すときに留意すること

部下ができたプログラマーのもどかしさ

今の会社には、世間一般の役職のような概念がないのでちゃんと部下と呼べないのかもしれませんが、チームの中で一緒に働く下の子達がいて、その子に色々仕事を頼んだりするわけです。

勝手な想像としては、「○○くん、これを頼む」って言えば後は勝手に仕事が進むようなイメージを持ってたりもしたんですが、この状況は状況で別でやる事も増え、返ってもどかしさが募るもんだなと感じたりします。

現場を一歩離れる任せるもどかしさ

そのもどかしさの一つが、自分がやった方が早いという気持ちを抑えるというものだったりします。

自分が下の立場だった時に上司も感じていたことなんでしょうけど、やはり何かとつたない感じで仕事をしているのを見ると、自分がやればすぐに終わる事でも想定以上の時間がかかり、何でこんなやり方してんだろって気持ちにもなります。

エンジニアの仕事柄、色んな技術やツールや手法があるわけですけど、そういったものって経験が優位に働くことも多いので、回りくどいやり方をしているのを見ると「それ、○○でできるよ」といちいちツッコミたくなるもどかしさがでてきます。

ただ、その気持ちを優先させて何でもやってしまうと、部下に経験を積ませる事もできませんし、自分も本来違う事をやる為に仕事を振ってるわけで、その本来やるべき事に注力できないという事態に陥ります。
部下に任せる許容力が必要ですし、何かあった際に責任をとる覚悟も必要でしょう。

もう一つは、現場から離れるもどかしさです。
自分がやった方が早いというのは、どこかしらその現場に固執してる自分がいたりして、今までや自負みたいなものもあったりして捨てきれない気持ちがあります。

こういったもどかしさは、現場を離れて間もないうちなのかもしれません。
現場での仕事がまだ頭から離れてないから、そういったもどかしさが募るわけで、もう頭の片隅からも消えたって状態になれば、部下がやってる内容を理解できず、一歩下がってスケジュールとタスク管理を淡々とこなせるのかなと。

まぁ、その現場を理解できるというのは、何かあったら自分で責任取れるって強みにもなると思います。
なので、余計に強みがあるのに発揮できないもどかしさと、現場を忘れていくことへのもどかしさが複雑に絡まってくるのかなとも思います。

部下に頼む仕事、自分がする仕事

部下に仕事を頼めば時間に余裕ができ、随分と仕事も楽になるだろうなと思ってたりもしましたが、実際のところそこまで楽にはなりません。

部下がする仕事をマネジメントするのに時間がかかりますし、部下がした仕事をチェックする時間も必ず必要になりますので、100の仕事を割り当ててもそのうちの3割ぐらいは自分が担当する事になるのではないかと思います。

実際、タスクの量は同じでも処理する時間が違うため、これまた自分がやった方が早いとなるかもしれません。

下の子が書いたコードをレビューすることもあるでしょうし、その過程で指摘したことを積み上げると、自分で書いたのと変わらないじゃんという気持ちにもなったりするわけです。

まぁ、それが上司の仕事なわけではありますが、部下は一人ではなかったりして、自分の時間が結構細切れに削り取られます。
そういうのをなくす為には仕事を丸投げするしかないのかなと。
ただ、自分が楽するだけでなく部下も与えられた範囲が多くなれば責任を感じたりもしますし、たまには丸投げも必要なんじゃないかなと思ったりします。
もちろん、何かあった際の責任はとる覚悟は必要になってくるので、現場と一定の距離を置くとはいえ、そこでの知識や技能というのは常に持っていないといけないと感じます。

このあたりのことは、現場での最新技術についていけなくても、長年の現場の感って結構当たったりして、なんとなく何が悪いのかとか、どう直せばよいのかとかの気付きが得られたりもするものです。

ただ、何時までも同じコードを書くようなことには興味が薄れてきたりして、アーキテクチャやシステムデザインやら別のところへ移っていったりもしますので、同じレベルで仕事は出来ないなとも思ったりします。

結局、部下が出来ても周りに気を使いながら自分の仕事をこなしていく起用さが必要になってきます。
それはやっぱり仕事が楽にはならないわけで、ただ本来の仕事とは関係ないところで忙しくなってるわけですよね。
上司だろってことで、本来のミッションとは違うところで時間が取られことが多くなるなと感じています。