A few weeks ago I wrote about Git’s help.autocorrect setting and the strange tale of the origin of it’s deciseconds value. It got me to thinking about other git config settings that most people likely don’t know about and which should probably be defaulted differently. In this post, I’ll go through some of the perhaps obscure Git config settings that I have personally globally enabled and go into
セッションマネージャでインスタンスに接続する際にはインスタンスIDを事前に知る必要がありますが、マネジメントコンソールやCLIから調べるのが少し面倒だったりします。特に台数が多い場合なんかはそうです。そこでCLIで簡単に接続できるようにしてみました。 必要なもの 下記のインストールが必要になります。 AWS CLI AWS CLI 用の Session Manager Plugin fzf 検証した環境 OS: macOS Mojave 10.14.6 AWS CLI: aws-cli/1.16.220 Python/3.7.4 Darwin/18.7.0 botocore/1.12.210 session-manager-plugin: 1.1.26.0 設定 ~/.aws/cli/aliasファイルを作成し、下記のエイリアスを追加するだけです。私はstart-sessionを省略してs
The characters ^[[37m and ^[[0m are part of the ANSI escape sequences (CSI codes). See also these specifications. Using GNU sed sed -e 's/\x1b\[[0-9;]*m//g' \x1b (or \x1B) is the escape special character (GNU sed does not support alternatives \e and \033) \[ is the second character of the escape sequence [0-9;]* is the color value(s) regex m is the last character of the escape sequence Using the m
日頃の業務で複数台のサーバにログインしてオペレーションすることがあると思うんですが、cssh, i2css, tmux-css, xpanes 等便利なツールがあるし、tmux 関連の簡易スクリプトだけでも次のように色々見つかります。 もっと簡単に！tmuxで複数のサーバにSSH接続して同じコマンドを一気に送る | 三度の飯とエレクトロン tmuxで複数サーバの同時オペレーション – NaviPlus Engineers’ Blog tmux + ssh + Mackerel API を組み合わせたとにかくモダンなサーバオペレーション - ゆううきブログ tmux は even-horizontal, even-vertical, main-horizontal, main-vertical, tiled という layout が用意されていて、どのスクリプトもこのいずれかを使っています。
ターミナル＆bashでコマンドラインを編集する時、実にいろいろなキー操作がある。便利そうだからと、あれもこれも覚えようと欲張るのだけど、すぐに忘れてしまう...。もっと厳選して覚えておかなくては。自分にとって必要最小限のキー操作を探ってみた。 勝手な方針 OSX環境のキーバインドが使える場合は、そちらを優先する。 ホームポジションの維持にこだわらない。 よって、矢印キー・deleteキーなども遠慮なく使う。 カーソル移動 行頭・行末・単語区切りの移動で、カーソルを素早く動かす。 マウスカーソルで指定すれば、クリックした位置にジャンプする。 control-A・E 行頭・行末へ移動 option-←・→ 1単語ずつ移動 option-クリック クリックした位置へ移動 削除 行頭・行末・スペース・単語区切りの削除によって、修正を楽にする。 control-U・K 行頭・行末まで削除 contr
Operating systems (Linux and macOS included) have settings which limit the number of files and processes that are allowed to be open. This limit protects the system from being overrun. But its default is usually set too low, when machines had way less power. Thus a “gotcha” that is only apparent when “too many files open” crashes appear only under load (as in during a stress test or production spi
ヒストリ履歴からよく使ってるものをお焚き上げする。 注意点: npm 周り、グローバルコマンドは npm i -g で入れてて、ローカルで扱うものは yarn で使うという癖がある 追記: シェルじゃなくてCLIだろと言われるのが多かったので訂正した vscode $ code . -r 現在ディレクトリを VScode で開く。 -r が肝で、新しいウィンドウを生成せず、既存のウィンドウを開き直す。 yarn $ yarn install --prefer-offline yarn install 時にローカルキャッシュを優先する。テザリング環境下でリポジトリを作成するのに便利。 フリーランスになってから出先で作業することが多く、ギガ足りない問題が多々発生した。 git $ git clone <github-url> --depth 1 HEAD だけ clone する。テザリング環境
OpenSSHには1本のコネクションで複数のSSHセッションを束ねて使える機能があります。例えば、~/.ssh/configに Host example.com ControlMaster auto ControlPath ~/.ssh/mux-%r@%h:%pと設定しておくと、最初に接続したsshセッションのコネクション(マスターコネクション)を使いまわし、複数のSSHセッションをマスターコネクションに束ねることができます*1。 主なメリットは以下のとおり。 TCPセッションは1つなのでTCPの同時接続数が制限されているサーバでも複数sshが可能*2 コネクションを使いまわした場合、接続にかかる時間が短い(ssh経由で複数回に分けてコマンド投入とかで時間短縮) コネクションを使いまわした場合、パスワード入力やパスフレーズ入力が不要*3 ですが、ControlMasterとControlP
Linuxサーバの障害対応で社内で伝統的に使われているテクニック。I/Oで完全にブロックしているポイントを特定するノウハウ。 問題対応のため、怪しいプロセスをstraceしてみる read(2)やwrite(2)でブロックしていることを発見する read(2)やwrite(2)、connect(2)の引数にはファイルディスクリプタ番号がみえる プロセスIDとファイルディスクリプタ番号を使って、/proc//fd/ の中身をみると、ソケットI/Oで刺さっている場合はソケット番号を発見できる netstat からソケット番号でgrepして接続先を発見する [y_uuki@hogehoge ~]$ sudo strace -p 10471 Process 10471 attached - interrupt to quit read(58, <unfinished ...> Process 10
My favorite Linux tool in DB work is ‘iostat -x’ (and I really really want to see whenever I’m doing any kind of performance analysis), yet I had to learn its limitations and properties. For example, I took 1s snapshot from a slightly overloaded 16-disk database box: avg-cpu: %user %nice %system %iowait %steal %idle 8.12 0.00 2.57 21.65 0.00 67.66 Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s \ sda
iostat -x -d can display many i/o statistic info. For util of iostat, the explanation is : Percentage of CPU time during which I/O requests were issued to the device (band-width utilization for the device). Device saturation occurs when this value is close to 100% I want to know how the util was computed? I make an experiment, (see following code), start 40 thread to randomly read 40 files. I supp
# !/bin/bash batch_logger(){ message=${1:?} LOGLEVEL=${2:-INFO} case ${3:-NORMAL} in 'RED' ) COLOR_HEADER='\e[1;31m' ;COLOR_FOOTER='\e[m' ;; 'BLUE') COLOR_HEADER='\e[1;34m' ;COLOR_FOOTER='\e[m' ;; 'YELLOW') COLOR_HEADER='\e[1;33m' ;COLOR_FOOTER='\e[m' ;; 'GREEN') COLOR_HEADER='\e[1;32m' ;COLOR_FOOTER='\e[m' ;; * ) COLOR_HEADER='' ;COLOR_FOOTER='' ;; esac /bin/echo -e "time:$(date +'%Y/%m/%d:%H:%M:
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
