Blog Alpha Networking: 3月 2015

2015年3月14日土曜日

CIMC(Cisco Integrated Management Controller)のCUI(CLI)操作手順

CIMCの運用上最低限必要な操作手順を残しておく.
CIMCへはweb(http)経由ではなく、sshでログインしているものとする.

(参考)
その他サーバ.
・HP系サーバ
・DELL系サーバ

【基本操作】
● スコープの変更(ディレクトリ移動)
存在するスコープの確認.
# scope ?

特定のスコープへ変更(ここではcimcへ移ることを想定).
# scope cimc

ホームへ戻る.
# top

【サーバの情報確認】
● バージョン、ファームウェア確認
# show version
もしくは
# show cimc

【HW(ハードウェア)のステータス確認】
● HDD(Hard Disk Drive)の状態確認
# scope chassis

# show hdd detail

# show storageadapter detail

● DIMM(Dual Inline Memory Module)の状態確認
# scope chassis

# show dimm-summary

# show dimm detail

● PSU(Power Supply Unit)の状態確認
# scope chassis

# show psu detail

● FANの状態確認
# scope chassis

# show fan-policy

【電源操作】
● cimcからサーバの電源オン、オフ
# scope chassis

# power shutdown

# power on

停止と起動の２コマンドを１回で実施することもできる.
# power cycle

完全にサーバOSが応答しなくなり、強制的な再起動が必要になったときは
物理的な電源OFFと同等のこともできる.
# power off

それでも反応がない場合は、リセット対応も可能である。
# power hard-reset

● cimcからcimc自体の再起動

# scope cimc

# reboot

【設定周り】
● 新規ユーザの作成
# show user
1 admin admin no
(略)
4 (n/a) (n/a) no

# scope user 4
# set name アカウント名
# set password
# set enabled yes
# set role {readonly | user | admin}
# commit

● snmpの設定
# scope snmp
# set enabled yes
# set community-str cimcpublic
# commit
# show detail

● snmp trapの設定
# set trap-community-str public
# set trap-ver 3
# set inform-type inform
# scope trap-destination 1
# set enabled yes
# set addr 192.168.0.1
# commit
# show detail

【ログ確認】
● CIMCログの確認
# scope cimc/log/

# show entries detail

scopeを移動しない場合はdetailが付与できない.
# show cimc/log/entries

● システムイベントログ(System Event Log)
# show sel/entries

● 調査ログの取得
# scope cimc
# scope tech-support
# set remote-ip 192.0.2.1
# set remote-username hoge
# set remote-password
Please enter remote-password:
Please confirm remote-password:
# set remote-path /tmp/yyyymmdd_teck-support.tar.gz
# set remote-protocol tftp | ftp | sftp | scp | http
# commit
# start
# show detail

進捗が確認できる

【HWのステータス確認用MIB】

snmpgetなりsnmpwalkでsnmp mibからHWのステータスを確認もできる.
(CISCO-UNIFIED-COMPUTING-STORAGE-MIB から参照)

● HDD(Hard Disk Drive)の状態確認

cucsStorageControllerOperState

.1.3.6.1.4.1.9.9.719.1.45.1.1.6

● DIMM(Dual Inline Memory Module)の状態確認

cucsMemoryUnitOperState

.1.3.6.1.4.1.9.9.719.1.30.11.1.13

● PSU(Power Supply Unit)の状態確認

cucsEquipmentPsuOperState

.1.3.6.1.4.1.9.9.719.1.15.56.1.7

● FANの状態確認

cucsEquipmentFanOperState

.1.3.6.1.4.1.9.9.719.1.15.12.1.9

【定期的に飛んでくるTRAP】

● MegaRAID のPatrol Read
RAIDを構成するディスクの全セクタの定期的な検査の始まりと終わりに出力される.

開始時
.1.3.6.1.4.1.3582.4.1.6.0.8021

終了時
.1.3.6.1.4.1.3582.4.1.6.0.8018

● Raid Battery Relearn
Raid Batteryの状態確認時の、放電、充電時に出力される.
下の５つは定期的なルーティン処理中の発報なので無視してもいいだろう.

開始時(Battery relearn started)
.1.3.6.1.4.1.3582.4.1.6.0.8041

稼働中(Battery relearn in progress)
.1.3.6.1.4.1.3582.4.1.6.0.8042

終了時(Battery relearn in completed)
.1.3.6.1.4.1.3582.4.1.6.0.8043

終了時(Battery relearn timed out)
.1.3.6.1.4.1.3582.4.1.6.0.8044

稼働待ち終了時(Battery relearn in pending
.1.3.6.1.4.1.3582.4.1.6.0.8045

バッテリのステータス変化時は以下も飛んでくる.
.1.3.6.1.4.1.9.9.719.0.2

これは、故障時にも、復旧時にも同一MIB番号で発報するため注意が必要である。
Raid Battery XX degraded: Cleared"の記載があれば
一時的な劣化であったと判断すればいい.

(参考)
・Cisco UCS C-Series Servers Integrated Management Controller CLI Configuration Guide
・CIMC CLI Navigator

Android Debug Bridge(ADB)の導入から使い方

ADBの導入方法からその使い方を手順として残しておく。

【Java(JDK)のインストール】
画像つきで非常に分かりやすい手順があったため参照先の紹介で終わる
http://andmem.blogspot.jp/2014/04/installjdkandroidsdkadb.html

【Android SDKのインストールと設定】
同上

【Android SDKの環境変数(Path)の設定】
同上

【ドライバのインストール】
Android SDKをインストールしたフォルダ内のドライバを見せてやれば足りることが多い
<sdk> -> extras -> google -> usb_driver
http://andmem.blogspot.jp/2012/10/android.html

対象ドライバが見つからなければここから探せる
https://sh-dev.sharp.co.jp/android/modules/driver/

【Android端末の設定】
設定 -> 開発者向けオプション

このあたりにチェックを入れておく
USBデバッグ
スリープモードにしない
ポインタの位置

あとはPCとモバイル端末をUSBケーブルでつなげばよい

ここからはよく利用したコマンド類をメモしておく
【コマンド】
● adbのバージョン確認
adb version

● 接続したデバイス情報の確認
adb devices

● adbシェルの利用
/system/bin/ 配下のコマンドをシェルから叩いて利用できる
adb shell ls
adb shell ping
など

● directional pad(十字キー)の操作
adb shell input keyevent 19
adb shell input keyevent 20
adb shell input keyevent 21
adb shell input keyevent 22
adb shell input keyevent 23

(参考)
19 : KEYCODE_DPAD_UP
20 : KEYCODE_DPAD_DOWN
21 : KEYCODE_DPAD_LEFT
22 : KEYCODE_DPAD_RIGHT
23 : KEYCODE_DPAD_CENTER(確定用、十字キーの真ん中)

● 検索
adb shell input keyevent 84
adb shell input text test
adb shell input keyevent 66

● ファイルの操作
(PCからandroidへ転送)
adb push test.txt /storage/sdcard0/

(androidからPCへ転送)
adb pull /storage/sdcard0/test.txt .

(android上のファイルを削除)
adb rm /storage/sdcard0/test.txt

● 電話をかける
adb shell am start -a android.intent.action.CALL tel:090********

● メールを送る
adb.exe shell am start -a android.intent.action.SENDTO -d mailto:***@example.com --es android.intent.extra.SUBJECT test_subject --es android.intent.extra.TEXT messeage
※メールアプリは起動するが、送信するところまでは実施しない
directional pad(十字キー)を操作し、送信ボタンを選択して押せばいい

● パッケージ周り
インストール済みパッケージの確認
adb shell pm list package -f
adb shell ls system/app/YouTube.apk

● 時計の設定
adb shell date -s YYYYMMDD.hhmmss

● 撮影(カメラで画面のスクリーンショットを取得)
adb shell screencap -p /storage/sdcard0/test.png

何かの操作後に画面の正常性を定期的に確かめたければ、
スクリーンのmd5値をとり前後で比較すればよいだろう
adb shell md5 /storage/sdcard0/test.png

● タッチ
adb shell input touchscreen tap x y
(例)
adb shell input touchscreen tap 890 840

● スワイプ
adb shell input touchscreen swipe x1 y1 x2 y2
(例)
adb shell input touchscreen swipe 900 1200 -500 0

● タッチ、スワイプの応用(タッチ操作を覚えて、再現)
adb shell getevent /dev/input/event1 | ./touch.rb > touch.sh
adb push touch.sh /storage/sdcard0/
adb shell sh /storage/sdcard0/touch.sh

(参考)
touch.rb

#!/usr/bin/ruby
time_b = Time.now

$stdin.each_line do |line|
  if line =~ /^([0-9a-f]+) ([0-9a-f]+) ([0-9a-f]+)$/
    array = [$1.to_i(16), $2.to_i(16), $3.to_i(16)] 
  else
    next
  end

  time_a = Time.now
  $stdout.puts "sleep #{time_a - time_b}" if time_a - time_b > 0.1
  $stdout.puts "sendevent /dev/input/event1 #{array[0]} #{array[1]} #{array[2]}"
  time_b = time_a
end

2015年3月10日火曜日

linuxでマウントできなくなった場合の対処法

サーバ起動時に特定領域がマウントできない事象に陥った。
その対処法を記録しておく。

【マウント状況の確認】
# df -TP
本来あるはずのマウントポイントがない。
下記が見えなくなっていた。
/dev/cciss/c1d0p1 ext3

【原因特定】
デバイスは存在している。
# fdisk -l
/dev/cciss/c0d0p1 * 1 25 101984 83 Linux

ファイルシステムは正常である。
# e2fsck -y /dev/cciss/c1d0p1
e2fsck 1.39 (29-May-2006)
/: clean, 157173/183091200 files, 97625776/366169796 blocks

手動で再度マウント。
失敗する。
# mount -t ext3 /dev/cciss/c1d0p1 /var
mount: wrong fs type, bad option, bad superblock on /dev/cciss/c1d0p1,
missing codepage or other error
In some cases useful info is found in syslog - try
dmesg | tail or so

起動時の状態を確認すると
ジャーナルログがないことで怒られているようである。
# dmesg | tail
VFS: Can't find ext3 filesystem on dev cciss/c1d0.
ext3: No journal on filesystem on cciss/c1d0p1
VFS: Can't find an ext2 filesystem on dev cciss/c1d0.
ext3: No journal on filesystem on cciss/c1d0p1
ext3: No journal on filesystem on cciss/c1d0p1

【ジャーナルを作成】
# tune2fs -j /dev/cciss/c1d0p1
Creating journal inode: done
This filesystem will be automatically checked every -1 mounts or
0 days, whichever comes first. Use tune2fs -c or -i to override.

※この手段はファ入りシステムをext2からext3へ、またext3をext4へ
　変換する場合にも使える。

【マウント】
# mount -t ext3 /dev/cciss/c1d0p1 /var

参考
http://alpha-netzilla.blogspot.com/2010/12/rescue.html
http://alpha-netzilla.blogspot.com/2011/12/volume.html
http://slashdot.jp/~daikoku/journal/435744/