カテゴリー別アーカイブ: Linux

何やってるのか生中継

このエントリーをはてなブックマークに追加

LINUXの運用で障害が発生したときに
あの人はどうやって切り分けを行っているんだろうか。
どうやって回復させているんだろうか。
すごく気になりますが、ゲーセンの立ち見みたいに後ろに立ってみるわけにもいかない・・・

そんな悩みを解決してくれそうなものが有ったので入れてみた。
ttyreccast

手元のwindows10上のubuntu 16.04に入れてみました。
node.js いれて npmでパッケージ入れるだけなので他のディストリでも大して変わらないと思います。

これでインストール完了!

1枚目のターミナルは、録画+配信のラッパープログラムの起動

↑なかんじで起動しておくと、/tmp/ttycast の内容を ~/date +%F_%H%M.rec に録画しておきながら、http://localhost:13377/ で配信してくれる。

2枚目のターミナルは、垂れ流し用のコンソール

ってしたら、その後の作業がhttp://localhost:13377/ で垂れ流しされている。

最後は<CTRL+D>で終わらせればいい。

自分でふりかえるのは

ってすれば、再生される。
ムーディー・ブルース!

ubuntuのデフォルトのエディタがnanoだったのでびっくりした。

このエントリーをはてなブックマークに追加

windows10にbash入れてsudoのパスワードいちいち聞かれるの鬱陶しいので
visudo コマンド叩いたら、エディタがnanoだったのでCtrl+Xでそっと閉じた。

visudoって言ってるんだから、viで開いてよ!ってことで、デフォルトのエディタを変えた。

ちゃんとvimで開いてくれた。

どうでもいいけど、vipwコマンド大好き(名前が

apachetopを入れてみた。

このエントリーをはてなブックマークに追加

何か、xxtop系のコマンドっていっぱいあるっぽい。
とりあえず、目に止まったapachetopを入れてみた。(だけ)

CentOS6環境です。

入れてみる

とりあえずhelpみる。

とりあえず叩けば、リアルタイムにリクエスト状況とか見えるんかな。

おしゃれにプロセス見る。だけじゃなかった。

このエントリーをはてなブックマークに追加

今時、topコマンドじゃなくてhtopなんていうおしゃれなコマンドがあるんですね。

しかもカジュアルにプロセス殺せるという。
なんか、クソみたいなプロセスがうごいてたのでKILLしてみた。

シグナルも選べるんですね。

–追記–
プロセス選んでsでstraceできるし
プロセス選んでlでlsofできるし
ちょっと、できること豊富っぽい。
時間が有れば、しっかり調べてみる。

Let’s Encryptを使って無料でhttps化する。(初回発行)

このエントリーをはてなブックマークに追加

職場で話題に上がったLet’s Encryptを使って、無料でhttps化する。

Let’s Encryptって90日間の証明書で、都度都度更新めんどくさいんだろうな。
というイメージだったのですが、
どうやら自動化がいい感じにある。って聞いたのでやってみようと思った次第です。

Let’s Encrypt の使い方に従って進めていきます。

手元の環境はCentOS6です。

まずは、epelリポジトリを追加するようですが、既に追加してるのでスキップ

CentOS6では、パッケージ管理でインストールできないようなので手動で導入する必要が有った。

少し躓いたのん、epelリポジトリ追加してるけど、デフォルト有効にしていないから、前もってパッケージ群を追加しておく。

パッケージ追加したし、やってみる。

ドメイン名、メールアドレスの入力して、Agreeしたらなんか怒られた。

httpd落として、ローカルで発行コマンド叩いたらいけるっぽい事書いてあったので、
気を取り直して叩いた。

うまく言った気がする。

sslの設定を書き換えて、証明書、中間証明書、秘密鍵を指定してあげれば良い。

で、停止していたhttpdを起動すればhttps化できた。

今のところ、自動化はまだできてない・・・

dstatは知ってると役に立つ

このエントリーをはてなブックマークに追加

だいぶ前に、dstat -tlaf 1は良さげ
と言ってたのですが、ちゃんとオプションとか知らずに言っててすいませんでした。

すごく良いので、ちゃんとオプションについて書いてみます。

オプションなしで動かすと、デフォルトの-cdngyが渡される。

-c:cpu stats (system, user, idle, wait, hardware interrupt, software interrupt)
-d:disk stats (read, write)
-n:network stats (receive, send)
-g:page stats (page in, page out)
-y:system stats (interrupts, context switches)

次は、dstat -tla 1

-t:time/date output
-l:load average stats (1 min, 5 mins, 15mins)
-a:equals -cdngy (default)
1 は1秒ごとに更新ですね。

ヨサゲと言ってたdstat -tlaf 1

-fは
CPUや、DISK、NETWORKを詳細に表示してくれるんですね。

ページングはあるけどメモリが出てないですね、man見れば書いてますが-mですね。
メモリは-f渡してもこれ以上の詳細表示は無いですね。

ここまで欲張るとターミナルからはみ出る。

vmstatに時刻出すときどうやってたっけ?って悩むことなく-tvで

manはボリューム満点なので
まずは–helpから見ていくと良いと思います。

どうしてもSSHしたいから踏み台を作ったはなし

このエントリーをはてなブックマークに追加

ちょっとした研修施設でMicrosoftAzureの研修のようなものに参加させていただいたのですが
インスタンスの構築はwebブラウザからサクサクと進めればいいのですが
立ったインスタンスにsshでアクセスしようとしたものの、アクセスできないorz
どうやらその研修施設のネットワークがガチガチすぎて、22番ポートに出ていけない。
というか、80番と443番にしか出ていけないw

困ったので、443番でssh待ち受けるサーバを作った
AmazonEC2上に立てたので、標準だと公開鍵認証認証なのですが
公開鍵を持ち歩くことないので、踏み台アカウントを作成して、踏み台アカウントはパスワード認証にした。
#さすがにec2-userとかパスワード認証にする勇気はないです。(ユーザー名知れ渡ってるし、総当たりされそう)

ちなみに、上記な環境です。

やったことはシンプル
* /etc/ssh/sshd_config の編集
* sshdの再起動
の2つだけです。

リッスンポートを22から443に変更

踏み台アカウントはパスワード認証

変更後にsshdの再起動。
めでたくして、443ポートで待ち受ける踏み台サーバができました。

CentOS7のAMI使った時のメモ

このエントリーをはてなブックマークに追加

EC2でCentos7のAMI使ってインスタンス立てた時のメモ。
無料枠のt2microで立ててます。

* SELINUXの確認→無効化

* epelリポジトリ追加する

使う。

I/O性能の監視

このエントリーをはてなブックマークに追加

I/O性能見たい!

フィールドの説明があった!
https://www.kernel.org/doc/Documentation/iostats.txt

Field4 の読み込み(ミリ秒)とField8 の書き込み(ミリ秒)があったら良いのかな。

Field 1 — # of reads completed
This is the total number of reads completed successfully.

Field 2 — # of reads merged, field 6 — # of writes merged
Reads and writes which are adjacent to each other may be merged for
efficiency. Thus two 4K reads may become one 8K read before it is
ultimately handed to the disk, and so it will be counted (and queued)
as only one I/O. This field lets you know how often this was done.

Field 3 — # of sectors read
This is the total number of sectors read successfully.

Field 4 — # of milliseconds spent reading
This is the total number of milliseconds spent by all reads (as
measured from __make_request() to end_that_request_last()).

Field 5 — # of writes completed
This is the total number of writes completed successfully.

Field 6 — # of writes merged
See the description of field 2.

Field 7 — # of sectors written
This is the total number of sectors written successfully.

Field 8 — # of milliseconds spent writing
This is the total number of milliseconds spent by all writes (as
measured from __make_request() to end_that_request_last()).

Field 9 — # of I/Os currently in progress
The only field that should go to zero. Incremented as requests are
given to appropriate struct request_queue and decremented as they finish.

Field 10 — # of milliseconds spent doing I/Os
This field increases so long as field 9 is nonzero.

Field 11 — weighted # of milliseconds spent doing I/Os
This field is incremented at each I/O start, I/O completion, I/O
merge, or read of these stats by the number of I/Os in progress
(field 9) times the number of milliseconds spent doing I/O since the
last update of this field. This can provide an easy measure of both
I/O completion time and the backlog that may be accumulating.