messages とかに kernel: device eth0 entered promiscuous mode のようなログが残らなくなります。その代わりそのホスト宛てのパケットしかキャプチャされません。 カーネルログが監視されててもこっそりキャプチャ出来ます。 -w file キャプチャ結果をファイルに出力する。出力されたファイルは Wireshark で開けます。
messages とかに kernel: device eth0 entered promiscuous mode のようなログが残らなくなります。その代わりそのホスト宛てのパケットしかキャプチャされません。 カーネルログが監視されててもこっそりキャプチャ出来ます。 -w file キャプチャ結果をファイルに出力する。出力されたファイルは Wireshark で開けます。
Software Design 2014年8月号の後藤大地さんの記事を読んだメモを残しておきます。普通に書くとまんまコピーになるので、自分がよく使うであろうコマンドを主に載せています。詳しくかつちゃんと知りたい人はSoftware Designを読みましょうw #0.tcpdumpとは tcpdumpとはネットワーク通信の生のデータをキャプチャし、その結果を出力してくれるキャプチャツールです。 Linuxだとディストリのパッケージ管理ソフトでわりとさくっと入ると思います(無責任w)。実際には導入していませんが、WindowsでもWinDumpというtcpdumpライクなツールがあります。Mac OS X 10.9.4 では最初から入っているようです。 #1.tcpdumpコマンドの使い方 ##1.1.とにかく実行してみる 次のコマンドでとりあえずtcpdumpを実行できます。
firewall-cmd --add-port=22/tcp --zone=public --permanent こんな感じで開放できます。 その他は以下のような感じ。 # 許可されているサービスやポートの一覧を表示 firewall-cmd --list-all --zone=public firewall-cmd --list-services --zone=public firewall-cmd --list-ports --zone=public # 許可するサービスの追加と削除 firewall-cmd --add-service=ssh --zone=public --permanent firewall-cmd --remove-service=ssh --zone=public --permanent # 許可するポートの追加と削除 firewall-cmd --add-p
はじめに CentOS7では/etc/sysconfig/network-scripts/下のファイルをいじるんじゃないらしいです。 nmcliコマンド nmcliコマンドでネットワーク関連の確認、設定を行います。 接続情報の確認 $ nmcli device show GENERAL.デバイス: eno12 GENERAL.タイプ: ethernet GENERAL.HWADDR: 00:0C:29:0A:5B:74 GENERAL.MTU: 1500 GENERAL.状態: 100 (接続済み) GENERAL.接続: -- GENERAL.CON パス: /org/freedesktop/NetworkManager/ActiveConnection/0 WIRED-PROPERTIES.キャリア: オン IP4.アドレス[1]: ip = 192.168.248.128/24, g
CentOS 7をインストールして謎だったことの一つとして、ネットワーク名が今までの「eth0」みたいなやつから、「enp1s0」みたいな謎の文字列に変わった事がある。 気になったので調べてみた。 ネットワーク名は新しい命名規則に沿って自動的に作られる 調べていると、以下のブログに丁寧に説明が書いてあった。 Predictable Network Interface Names ざっくり訳すと以下の通り v197のsystemd/udevでは自動的に安定的なネットワークインターフェース名を割り当てる。 ローカルエリアネットワークに限らず、WLANやWWANに対しても割り当てる。 伝統的な ("eth0", "eth1", "wlan0", ...)といった命名規則はもうしない。 新しい命名規則では以下の嬉しい事がある。 OSが再起動してもインターフェース名が変わらない ハードウェアを追加し
Linuxの起動処理は、これまでinit/upstartと呼ばれる仕組みで行われていました。Red Hat Enterprise Linux 7 (RHEL7)では、これが、systemdと呼ばれるまったく新しい仕組みに置き換わります。Fedoraでは、すでに先行してsystemdが採用されていますが、この連載(?)では、Fedora 17での実装をベースとして、systemdの考え方や仕組み、利用方法を説明していきます。今回は、systemdの動作の基礎となる「Unit」の概念を理解します。 systemdを採用したFedoraでLinuxの基礎を学びなそう!という方には、「「独習Linux専科」サーバ構築/運用/管理――あなたに伝えたい技と知恵と鉄則」がお勧めです。(^^/ systemdの考え方 参考資料 ・Rethinking PID 1:systemdの開発者であるLennart
この連載では、Fedora 17での実装をベースとして、systemdの考え方や仕組み、利用方法を説明します。今後出てくる予定のRHEL7での実装とは異なる部分があるかも知れませんが、その点はご了承ください。 前回は、systemdの基本概念となるUnitの説明をしました。今回は、日々のオペレーションで必要となる、serviceの操作方法をまとめます。旧来のchkconfigコマンド、serviceコマンドに相当する部分ですね。 サービスの確認 現在稼働中のサービス一覧 # systemctl list-units --type=service UNIT LOAD ACTIVE SUB JOB DESCRIPTION auditd.service loaded active running Security Auditing Service crond.service loaded act
MySQL のチューニング (ボトルネックの検出) こんにちは! onk です。 SAPさんが各社とも「ソーシャルアプリは負荷対策が大事」って言っていますね。 弊社でも mixi アプリ(PC),mixi アプリモバイルをリリースしたときはお祭り状態だったので, ふりかえりも兼ねて MySQL のボトルネックを調べる方法を書いてみました。 (幸い,モバゲーオープンゲームのリリース時はこれらの経験が役に立ったので何ともなかったです) といっても 9 割方 そもそもサーバの設定がおかしい 更新が多いテーブルなのに MyISAM エンジン for 文の中でクエリを発行 INDEX 張ってない データ量がえらいことになってる 辺りなんですけどねー。 基本は下から まず,ボトルネックを調べるときは下の層から上がっていくのが基本です。たぶん。 なので ssh でサーバに入って (LoadAverage
NetflixのシニアパフォーマンスアーキテクトであるBrendan Gregg氏による、Linuxサーバにログインして60秒でまず調べることのまとめ。 パフォーマンス問題でLinuxサーバーにログインしたとして、最初の1分で何を調べますか? Netflixには、多数のEC2 Linuxからなるクラウドがあり、そのパフォーマンスを監視したり調査したりするための数々のパフォーマンス分析ツールがあります。その中には、クラウド全体にわたる監視を行うAtlasや、オンデマンドにインスタンスの分析を行うVectorがあります。これらのツールは多くの問題を解決する手助けをしてくれますが、各インスタンスにログインし、標準的なLinuxパフォーマンスツールを実行する必要がある場合もあります。 この記事では、すぐ使えるはずの標準的Linuxツールを使いコマンドラインにおいて、最適化されたパフォーマンス調査を
指標を読む ロードアベレージ # uptime 15:40:33 up 357 days, 22:34, 2 users, load average: 0.19, 0.17, 0.12 コマンド uptime。load averageに続く3つの数字が過去1分間、5分間、15分間の平均値を表します。 意味 処理を実行したいが、なにかしらの要因で実行を待たされているプロセスの数を表します。したがって、ロードアベレージが高い状態とは多くのプロセスが処理を実行できずに待たされている状態、ということになります。 解釈 なにかしらの要因としては「ほかのプロセスにCPUが使われていて、空くのを待っている状態」と「ディスクに読み書き要求を発行していて、その結果を待っている状態」の二種類が考えられます。前者は「CPU使用率」、後者は「I/O待ち率」として数値化することができます。ロードアベレージを見ただけ
sarコマンドを使うことで、LinuxサーバのCPUやメモリ、DISK IOなどの様々な情報のモニタリングが可能です。 サーバを運用する上で、モニタリングは非常に重要です。 車にはスピードやガソリン残量、モーターの回転数などの情報が見れるようになっているため、スピード違反やガス欠になるのを事前に防ぐことが可能です。 サーバについても、CPUやメモリ、DISK IOなどの情報を取得することで、異常の事前検知や、問題発生時の原因調査などが円滑におこなうことができるようになります。 今回は、sarコマンドを利用して統計情報を取得する方法を紹介します。 sarコマンドとは sarとは、sysstatパッケージに含まれている、システムの統計情報を取得するコマンドです。名前は、System Admin Reporterの頭文字をとったものになります。 大きな特徴としては、過去にさかのぼって情報が見れる
はじめに よく障害対応の際につかうコマンドの見方を自分でまとめていたものを一般公開してみる。 詳細についてはここを参考にせずにちゃんとmanをよみましょう! w ヘッダ部 現在の時刻 Uptime(システムが稼働している期間) 現在ログインしているユーザーの数 過去1,5,15minでのシステムのロードアベレージ Uptimeが短いと再起動した。 また、ロードアベレージの1が高く5,14が低いなら直近、 全部が高いなら継続、 1が低く他が高いならすでに問題が解消した可能性が高い。 下部 USER :ユーザ名 TTY : FROM :アクセス元 LOGIN:ログイン時間 IDLE :アイドル(現在時間-最後にttyにアクセスした時間)している時間 JCPU :そのttyから実行されている全プロセスが使った時間。これには 過去のバックグラウンドジョブは含まれないが、現在実行しているバックグラウ
command_tips.md Linuxの性能関連のまとめ 性能測定コマンド sar :システム稼動状況 mpstat:CPU稼働状況 vmstat:仮想メモリ稼働状況 free :メモリ情報 iostat:ハードディスク,CPU使用状況 ps :プロセス情報 top :プロセス情報 目安 CPU CPU使用率:90%以上 CPU待ちプロセス数:2より大きい(1CPUあたり) メモリ メモリ使用量:ページングの発生回数 ディスク ディスク使用率:80%以上 ネットワーク ネットワーク使用率:80%以上 パケット衝突回数:送信パケットの10%以上 sarコマンド # sar [オプション] [-o ファイル名] 取得間隔 取得回数 -u:CPU:CPU使用状況 -q:CPU:プロセスキュー、システム稼動負荷 -r:メモリ:メモリ,スワップ領域使用状況 -R:メモリ:メモリ動作状況 -B:メ
Amazon EC2 に Nginx をインストールして起動しようとすると、以下のようなエラーが出て起動に失敗しました。 $ sudo service nginx start Starting nginx: nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use) nginx: [emerg] still could not bind() エラーメッセージにある通り、ほかのプロセスが先に 80 番ポートをリッスンしていたのが原因でした。 特定のポートをリッスンしているプロセスを調べるには lsof コマンドが使えます。ポート番号を調べるには i オプションを使います。なお、lsof コマンドを実行するには root 権限が必要です。 $ sudo lsof -i:80 COMMAND PID USER F
①anacondaの画面フロー変更。 ②GUIでのパッケージ選択を廃止 ③6.5➡7へのupgradeをサポート CentOS6.5➡7にupdateするには下記 CentOS6.5 ➡ Centos7にアップグレード eth0などはそのまま引き継がれる。 サービスは停止するもの(例えばntpなど)があったり、 6.5で動いてたものが正常に動作しなくなる可能性があるので、upgradeは推奨はしません。
CentOS7系と6系のコマンドの違いについて 備忘録として、よく使いそうなコマンドをまとめてみました。逐次更新予定です。 もしかしたら、間違いがあるかもしれないのですm(_ _)m サービス系コマンド CentOS7系ではサービス起動デーモンとして、SysVinit/Upstartに代わって、 systemdが導入されたことによって、サービス系コマンドが大幅に変更されました サービスの状態確認 ################################################################################# # 状態の表示(サービス単位) ################################################################################# # CentOS7系 $ /usr/bi
バージョン : Jenkins 1.564 Jenkins さんだけ xxx.xxx.xxx.xxx:8080 とか野ざらしで可哀想…と思って Nginx のリバースプロキシ傘下に加えて http://hoge.hage.jp/jenkins とかでアクセスさせようと試みたのですがうまくいかない。何度やっても file not found 的な画面が出る。しかし Jetty が吐いているのはわかるのでおじさんまでは到達している。 そこで調べてみると http://www.phase2technology.com/blog/running-jenkins-behind-nginx/ に To get Jenkins ready to run behind a reverse proxy, we’ll first want to have it stop binding to all inte
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く