例えば踏み台サーバに個人のアカウントで入ってから，或るuserにsuで切り替わって色々する，みたいなシチュエーションがあると思います．
そんな時に，或るuserにsuする際にあらかじめ任意のコマンドを実行しておいてほしいという時がある．あるのです．
というわけでこうです;
$ su "$LOGIN_USER" -c "$ANY_COMMAND && $LAUNCH_SHELL"
suコマンドの-c (--command) を使うと，そのuserに切り替わってから任意のコマンドを実行することができます．それを利用して「事前実行したい任意のコマンド」を実行してから「実行したいシェル」を起動すると，あたかも事前実行コマンドが実行されてからログインしたように利用できて便利．
取りあえずこれで動く．ヨッシャヨッシャ．
tcpdumpの提供する-Wオプションと-Gオプション，ならびにcrontabを併用するといける．
tcpdumpの-Wオプションはログローテーションを行う回数で，-Gはそのローテーション期間を秒数で指定できる．
例えば
$ tcpdump -w ./%Y%m%d%H%M%S.pcap -W1 -G60
などとやると，ログローテーション1回，ローテーション期間は60秒となるので，つまり60秒tcpdumpを実行した後にexitする (ローテーション1回指定なので)．
ちなみに-wオプションで指定するファイル書き出し先についてはstrptimeと同じフォーマットが利用できるのでこういう時に便利．
あとはcrontabでこのコマンドを仕込んでやるとOK (id:hirose31さんから「crontabでは%をエスケープする必要がある」との指摘があり修正しました)．
55 * * * * tcpdump -w /var/pcap/\%Y\%m\%d\%H\%M\%S.pcap -W1 -G600
例えば上記のようなcrontabを書いてやると，毎時55分にtcpdumpを起動して，そこから10分間キャプチャを取る，ということができる．
シナリオとして「毎時0分付近のリクエストの失敗が多い」という問題の調査を行うときなんかに，こういったcronを仕込んでおくと，サクッと欲しい部分のパケットだけ解析できるようになるし，何より不要なパケットキャプチャでディスク容量を食わなくて良い．
plenvやperlbrew等できれいなperl環境を利用している際に，Perl::Critic (例えばエディッタのsyntax checkingに引っ掛けているようなシチュエーション) やLなどの自分の環境でだけ動かすようなモジュールを環境グローバルに入れたくないという場合が生きているとあるでしょう．かと言って複数人で開発していてcpanfileをrepositoryで管理しているようなプロジェクトだとcarton/carmelでインストールするというのも微妙．そういう時にどうするか，と言う時の話です．
僕は雑な人間なので，そういったモジュールを利用したい時は普通にcpanm Lとかやってしまいがちなんですが (なんと前提が崩れた)，真面目にやるときはdirenvを使ってPERL5OPTを設定するようにしています．
例えば
$ cpanm -l mydist L
という風に，-lオプションとともに任意のディレクトリの以下にモジュールをインストールしておいて，
export PERL5OPT="$PERL5OPT -I/path/to/mydist/lib/perl5"
みたいな感じで-Iオプションによってincludeするパスを指定したPERL5OPTを.envrcに書き込んでやる．この時指定するパスは，モジュールをインストールした先のパスを指定する．
そうすると，.envrcが置かれているディレクトリ以下ではこのPERL5OPTが有効になるので，-lオプションと共にインストールしたモジュールが実行時にincludeされ (PERL5OPTの-Iに指定したディレクトリ以下が走査される)，自動的に利用可能になります．
注意としては，PERL5OPTに書く-Iオプションに与えるパスはフルパスである必要があるということです．これが相対パスだとincludeするパスの位置の決定がperlを実行するディレクトリに依存してしまい正しく動作しなくなります．
これできれいな環境を保ちながら任意のモジュールを任意の場所にインストールしつつ，自分の環境でだけ有効にすることができる．やりましたね．
PERL5LIBを使う方法ここまでPERL5OPTを使う方法を書いたのですが，冷静に考えてみればPERL5LIBを使ったほうが役割的に正しいのでしっくり来ることに気づきました．.envrcに以下のように書くと良い;
export PERL5LIB="/path/to/mydist/lib/perl5:$PERL5LIB"
注意としては，PATHなどと同じでPERL5LIB上では先に書いたものが優先されるということでしょうか．つまり先に書いたパスから評価されてゆき，そこに対象となるモジュールがあった場合はそれが利用されます．適宜，オリジナルの$PERL5LIBを置く位置に気をつけたほうが良いでしょう．
ElasticsearchのX-Packはマジ便利なんですが，有償なので (だたしmonitor機能なんかは無償のBasicライセンスで使えて最高) 使わない人も多いでしょう．
そんな場合，Elasticsearch/KibanaをDockerで動かすという時にX-Packを取り除きたくなるというのが人情でしょう．コンテナは軽いと嬉しい．
というわけでそういう場合の法です．
Elasticsearch:
FROM docker.elastic.co/elasticsearch/elasticsearch:5.6.3 RUN bin/elasticsearch-plugin remove x-pack
Kibana:
FROM docker.elastic.co/kibana/kibana:5.6.3 RUN bin/kibana-plugin remove x-pack
プラグインマネジメント機能を介して，docker build時にゴリッとX-Packを消すという構造．
そんでもって，設定のyamlファイルに
xpack: monitoring.enabled: false security.enabled: false watcher.enabled: false ml.enabled: false graph.enabled: false reporting.enabled: false
などと書いてやるとX-Packを無効化した状態で起動することができる．このissueから情報を得ました: Unable to start Kibana 5.3.0 without X-Pack · Issue #27 · elastic/kibana-docker · GitHub．
とは言えX-PackのBasicライセンスで利用できるmonitoring機能は普通に便利だったので，別にX-Pack消さんでも良いなというのが最近の感想です．
補足: Kibanaの場合はなんか特殊で，以下のようなyamlを書いてやる必要があった．
xpack: monitoring.enabled: false grokdebugger.enabled: false searchprofiler.enabled: false security.enabled: false watcher.enabled: false ml.enabled: false graph.enabled: false reporting.enabled: false tilemap.enabled: false upgrade.enabled: false xpack_main.enabled: false
なお現在はX-PackのBasicを有効にしているのでKibanaの設定は
monitoring.enabled: true grokdebugger.enabled: true searchprofiler.enabled: true
というふうになっており (差分を心の目で見てください)，Elasticsearchの設定は
monitoring.enabled: true
となっています (差分を心の目で見てください)．
やり方についてはドキュメントを読むと良い．
option_settings: aws:elasticbeanstalk:command: DeploymentPolicy: Immutable HealthCheckSuccessThreshold: Ok IgnoreHealthCheck: false Timeout: "600"
設定ファイルでやるならばこういった設定を書き，.ebextensions/ 以下に deploy.config みたいな名前で放り込んでデプロイするとImmutable deployがされる．
最初は素朴なhealth checkベースのrolling deployを試していたのだけど，JavaのApp serverと相性が悪いのか (私はJavaを書いています) 上手くhealth checkが通らない時があり，また場合によってはJavaのプロセスが2個立ち上がったりしてしまってまともにデプロイできなかったので，ものは試しとImmutable deployを試してみたところ上手く行った．
基礎的な動作・挙動についてはドキュメントを参照してもらうとして，immutable deployの利点は
というものが挙げられる．これはディスポーザブルな構成が持つ良い特徴そのもののように思う．
一方で懸念すべき点としては (公式ドキュメントにもあるが)
と言うものがある．
前者については「一台だけ新しいインスタンスを立ててデプロイする」->「health checkが通るかどうか確認する」->「health checkが通るのであれば残りのインスタンスも立ててデプロイする」->「health checkが通るかどうか確認する」->「health checkが通るのであれば新しいインスタンス群をauto scaling groupに突っ込む」->「古いインスタンス群をauto scaling groupからterminateする」という手順を踏むのでそれは時間が長くなるだろうなという感じ．急ぎのデプロイの時は中々ヒリヒリしそうなので，場合によってはhealth checkをスキップしたり，別のデプロイ手法を試したりする必要がありそうだと思った．
後者についてはもうそういうもんだと割り切るしかあるまい……2倍の数のインスタンスが必要となるのはデプロイ時だけなので寛容な心が必要であろう (オンデマンド制限については考えなければならないだろうが)．
とはいえEC2も秒単位の時間課金になったので，かつてよりはImmutable deployもやりやすくなったんじゃないでしょうか．良い時代になりましたね．
それにしても日本語化されたドキュメント上で「Immutable」を「変更不能」と訳すの，気持ちはわかるんだがそれはどうなんだ……
例えばCIでテストのためのストレージのコンテナを上げる際，そのストレージが上がりきるまで待たなければテストには使えないわけですが「上がりきるまで何秒待てばよいのか」というのは一概に決められるものではありません．
そうした際，実際にストレージに対してHTTP(S)のリクエストを投げてみて，繋がったら「上がりきった」とみなして処理を次に進めるというようなことがよく書かれます．そういった要件を満たす為には接続に失敗したらリトライをしつつ一定回数試行するという処理を書かなくてはなりません．
つまりはそういう話です．
retry-connrefusedtrieswaitretryを利用すると出来る．
retry-connrefused が無いと connection refusedに対応できずにリトライが不可能となるので，今回のような要件を満足するためには付ける必要があります．
e.g.
$ wget --tries 10 --waitretry 10 --retry-connrefused localhost:5000
この例だと
というような動きをします． tries には最大リトライ回数を指定します．
waitretry は失敗するごとに1秒ずつリトライ間隔を伸ばしてゆく際の上限値となります (例えば，値が1だと常に1秒間隔をあけるようになる．0だと一切待たない)．
場合によっては timeout を設定する必要があるでしょう．
なおこのコマンドはTravis CIのドキュメントにも書かれている由緒正しいコマンドから拝借しました．
retry-connrefusedretryretry-delayretry-max-timeを利用するとできる．
retry-connrefused が必要な理由はwgetのそれと同様です．なお，retry-connrefused は2016-12-21にリリースされたバージョン7.52.0から入ったわりと新しい機能なので古いcurlだと使えません．新しいものにアップデートしましょう．
e.g.
$ curl --retry 10 --retry-delay 1 --retry-connrefused localhost:5000
この例では最大10回リトライしつつ (retry で指定)，リトライ間隔は常に1秒 (retry-delay で指定) というふうになります．
retry 単体で利用すると失敗する度にretry間隔が倍々になり (つまり失敗回数をnとすると2^(n-1)秒待つ)，
retry と retry-delay を組み合わせると固定長秒数のretry間隔を設定できます．
また retry と retry-max-time を組み合わせると，retry間隔は倍々で増えてゆき，そのリトライ間隔が retry-max-time を超えるとギブアップする (retry で指定された回数に満たなくても) という挙動をします．
class EmptyCat {} def cat = new EmptyCat() cat.metaClass.nyan = { return 'meow' } cat.nyan() // => 'meow'
インスタンスの metaClass からMetaClass (HandleMetaClass) を引っ張ってきて，それ経由で生やしたいメソッドの名前を指定し，Closureを代入してやると良い．
上記がインスタンス自体にメソッドを生やしていたのに対し，こちらはクラスに対してメソッド追加の処理を行い，そのクラスがinstantiateされた際にそのメソッドを利用可能にするという方法．
class EmptyHuman {} EmptyHuman.metaClass.greet = { return '無……' } def human = new EmptyHuman() human.greet() // => '無……'
クラスの metaClass からMetaClass (ExpandoMetaClass) を引っ張ってきて，それ経由で生やしたいメソッドの名前を指定し，Closureを代入してやると良い．
class EmptyDog {} EmptyDog.metaClass.static.wan = { return 'bow' } EmptyDog.wan() // => 'bow'
クラスの metaClass.static からMetaClass (ExpandoMetaClass) を引っ張ってきて，それ経由で生やしたいメソッドの名前を指定し，Closureを代入してやると良い．
