viエディタの現在のモードをわかりやすくする

viエディタの現在のモードをわかりやすくする

コマンドモードにして(現在何モードかがわからなければ、とりあえず[Escキー]を連打)

:set showmode

すると、右下(または左下)に現在のモードが表示される。

                   
                   
— 挿入 —

コマンドモードの場合は、何も表示されない。

KSH のコマンド履歴 およびにファイル名補完を有効にする

KSH のコマンド履歴およびにファイル名補完を有効にする方法

シェルのviモードを有効にする。

$ set -o vi

viモードを有効にしたら・・・
Escキーを押して(viでいうところのコマンドモードにする)

[Escキー]

コマンド履歴は

Ctrl+K(一つ前(過去)のコマンド)
Ctrl+J(1つ後(直近)のコマンド)
/<検索ワード>[Enterキー] (コマンド履歴から検索)

ファイル名補完(bashでいうところのタブ補完)は

*(アスタリスクShift+:)
※補完できる状態まで入力している必要あり。候補が複数ある場合は全部rリストされるので注意。

シェルスクリプトでtelnet接続→コマンド実行

シェルスクリプトでtelnet接続→コマンド実行

シェルスクリプトで、他ホストにtelnetログインしてコマンドを実行し情報を取得する方法。
たとえば、L2/L3スイッチの統計情報やarpテーブルの情報を自動的に取得する処理をシェルスクリプトで作成したいとき
telnetの場合、FTP転送をヒアドキュメントを使用して自動的に実行するのと同じ方法では実装できない。理由は、ヒアドキュメントの場合、標準入力に間髪入れずに入力内容を送りこんでしまうので、ログインプロンプトを待つことができないから。
ユーザ名を標準入力に送り込む前に少し待機すると、ログインすることができる。
ポイントは、
・ヒアドキュメントを使用せずに、コマンドのグループ化とパイプを使用してtelnetコマンドの標準入力にコマンドを送り込む
・sleepコマンドで待機
実際のやり方は以下を参照。(Ciscoのスイッチからarpテーブル情報を取得する場合。)

$ (sleep 5; #パスワードプロンプトが表示されるまでsleepコマンドで待つ
echo username;sleep 5; #ユーザ名入力 標準入力に送り込むのでechoで出力(Ciscoスイッチは実際にはユーザ名入力はありません)
echo password;sleep 10; # パスワード入力
enable;sleep 5; #特権モードへ切り替え
echo enablepassword;sleep 1; # 特権モードのパスワード入力
show arp;sleep 1; # arpテーブル取得
exit; ) | telnet 192.168.1.250 >> arp.log # コマンドをグループ化し、その標準出力をパイプでtelnetコマンドの標準入力に送り込む

追記:
 この方法はスクリプトで、passwdコマンドを使ってパスワードを自動設定するときにも使えます!

clamdが起動しない・・・

clamdが起動しない

# service clamd start
clamd を起動中: /bin/bash: line 1: 14616 File size limit exceeded/usr/local/sbin/clamd [失敗]

でも

# /usr/local/sbin/clamd
# echo $?
0

では起動する。
この差はいったい・・・
このような場合の基本、ログを見てみる。
起動失敗パターン

# less /var/log/clamd.log
Sat Apr 11 01:07:07 2009 -> +++ Started at Sat Apr 11 01:07:07 2009
Sat Apr 11 01:07:07 2009 -> clamd daemon 0.95.1 (OS: linux-gnu, ARCH: i386, CPU: i686)
Sat Apr 11 01:07:07 2009 -> Log file size limited to 2097152 bytes.
Sat Apr 11 01:07:07 2009 -> Reading databases from /var/lib/clamav
Sat Apr 11 01:07:07 2009 -> Not loading PUA signatures.

こちらは成功パターン

# less /var/log/clamd.log
Sat Apr 11 01:08:17 2009 -> +++ Started at Sat Apr 11 01:08:17 2009
Sat Apr 11 01:08:17 2009 -> clamd daemon 0.95.1 (OS: linux-gnu, ARCH: i386, CPU: i686)
Sat Apr 11 01:08:17 2009 -> Log file size limited to 2097152 bytes.
Sat Apr 11 01:08:17 2009 -> Reading databases from /var/lib/clamav
Sat Apr 11 01:08:17 2009 -> Not loading PUA signatures.
Sat Apr 11 01:08:17 2009 -> Not loading PUA signatures.
Sat Apr 11 01:08:20 2009 -> Loaded 538775 signatures.
Sat Apr 11 01:08:20 2009 -> LOCAL: Unix socket file /tmp/clamd.socket
Sat Apr 11 01:08:20 2009 -> LOCAL: Setting connection queue length to 15
Sat Apr 11 01:08:20 2009 -> Limits: Global size limit set to 104857600 bytes.
Sat Apr 11 01:08:20 2009 -> Limits: File size limit set to 26214400 bytes.
Sat Apr 11 01:08:20 2009 -> Limits: Recursion level limit set to 16.
Sat Apr 11 01:08:20 2009 -> Limits: Files limit set to 10000.
Sat Apr 11 01:08:20 2009 -> Archive support enabled.
Sat Apr 11 01:08:20 2009 -> Algorithmic detection enabled.
:(以下省略)

失敗パターンはシグネチャを読み込めていない??
どこでこけてるのかわからないので、起動スクリプトをデバッグモードで実行してみる

# bash -vx /etc/init.d/clamd
:(省略)
clamd を起動中: + ulimit -f 20000
+ LANG=
+ daemon /usr/local/sbin/clamd
:(省略)
+ /bin/bash -c ‘ulimit -S -c 0 >/dev/null 2>&1 ; /usr/local/sbin/clamd’
/bin/bash: line 1: 14503 File size limit exceeded/usr/local/sbin/clamd
+ ‘[‘ 153 -eq 0 ‘]’
+ failure ‘clamd 起動’
:(省略)

このところどころで出てくるulimitって何ですか??
さっきの/usr/local/sbin/clamdを直接実行したときは起動できたのでulimitが非常にくさい!
で、さっきのログを見た結果、シグネチャが読み込めていない。
シグネチャのサイズがでかすぎる??

# ls -l /var/tmp/clamav-0cae8acb8c9855ce5c67f55328bfce6e:
合計 25380
-rw-rw-rw- 1 root root 17992 4月 11 01:26 COPYING
-rw-rw-rw- 1 root root 4725917 4月 11 01:26 main.db
-rw-rw-rw- 1 root root 716040 4月 11 01:26 main.hdb
-rw-rw-rw- 1 root root 318 4月 11 01:26 main.info
-rw-rw-rw- 1 root root 20480000 4月 11 01:26 main.mdb

20MB??この数字、起動スクリプトをデバッグしたときにどこかにあったよな・・・

# less /etc/init.d/clamd
:(省略)
start() {
echo -n $”Starting $prog: ”
# Don’t allow files larger than 20M to be created, to limit DoS
# Needs to be large enough to extract the signature files
ulimit -f 20000
LANG= daemon $progdir/$prog
RETVAL=$?
echo
[ $RETVAL -eq 0 ] && touch /var/lock/subsys/clamd
return $RETVAL
}
:(省略)

20480000byte ギリギリアウト??
なので/etc/init.d/clamd 中の ulimit -f の値を24000にしてみる。

# vi /etc/init.d/clamd
:(省略)
start() {
echo -n $”Starting $prog: ”
# Don’t allow files larger than 20M to be created, to limit DoS
# Needs to be large enough to extract the signature files
ulimit -f 24000
LANG= daemon $progdir/$prog
RETVAL=$?
echo
[ $RETVAL -eq 0 ] && touch /var/lock/subsys/clamd
return $RETVAL
}
:(省略)

起動

# service clamd start
clamd を起動中: [ OK ]

起動できた!
原因はシグネチャファイルのサイズが起動スクリプトで定義されているファイルサイズ制限より大きかったから。
以上

[linux]OS再インストールなしにマザーボードを交換してみる

OS再インストールなしに、マザーボードを交換してみる

C7プロセッサを載せた自宅サーバのマザーボードが不安定になったので、マザーボードを交換してみた。面倒なOS再インストールおよびミドルウェア再設定なしで。何も考えずにするとディスク(VG)が見えなくなるので厄介。
▼環境

 OS:CentOS 5.3
 マザーボード:EPIA-LN10000EG(C7) → D945GCLF2(Atom330)

マザーボードのSATAコントローラが交換前後で異なるので、マザーボード交換後は当然ディスク(というよりLVM VG)が見えなくなる。
▼ 以下やったこと。
マザーボード交換後、何も手当てをせずに起動してみる。
initrdを読み込んで、VGを探し始めたところで「No volume groups found」といわれてしまう。
予想通りの結果。initrdの中にICH7用のSATAドライバがないから(現時点で読み込んでいるのはVIAのSATAドライバ)。
念のためディスク自身が使用できることを確認するために、CentOSのインストールDVDのレスキューモードで起動。VGも認識したので、ディスク自身も使用できること(問題ないこと)は確定。
さて、ここでinitrdをICH7用ドライバを読み込むように作り変えることになるのだが、どれがICH7用ドライバかわからない。レスキューモードで起動しているがlsmodをみても判断できない。
ということで・・・
外付けHDDにCentOSをインストールしてみる(再インストールなしと書いているが、データを破壊しないという意味なので・・・)。
※このときGRUBの2段階目は外付けHDDに向くので、後ほど注意!
インストール後、/etc/modprobe.confの内容を確認。
こんな感じ。

alias scsi_hostadapter ata_piix
alias scsi_hostadapter1 usb-storage
alias snd-card-0 snd-hda-intel
options snd-card-0 index=0
options snd-hda-intel index=0
remove snd-hda-intel { /usr/sbin/alsactl store 0 >/dev/null 2>&1 || : ; }; /sbin/modprobe -r –ignore-remove snd-hda-intel
alias eth0 r8169

これをどこかにメモしておいて、こちらのOSはシャットダウン。外付けHDDは外す。
次に、もう一度CentOSのインストールDVDのレスキューモードで起動。
内蔵HDDの(/mnt/sysimage)/etc/modprobe.confの中身を上記メモの内容に置き換えて、initrdを再作成する。

# vi /mnt/sysimage/etc/modprobe.conf
(上記メモ内容に置き換え)
# chroot /mnt/sysimage
# cp -p /boot/initrd-2.6.18-92.1.22.el5.img? /boot/initrd-2.6.18-92.1.22.el5.img.c7
# mkinitrd -f? /boot/initrd-2.6.18-92.1.22.el5.img 2.6.18-92.1.22.el5

作成したinitrdを解凍してみて、ちゃんとICH7用のドライバが組み込まれていることを確認する

# gzip -dc? /boot/initrd-2.6.18-92.1.22.el5.img > /tmp/initrd.cpio
# mkdir /tmp/initrddir
# cd /tmp/initrddir
# cpio -i –file ../initrd.cpio
# less init
(ここで、insmod /lib/ata_piix.koがあることを確認)

確認できたら、GRUB(ブートローダ)の2段目の向き先を内蔵ディスクに戻す

(先ほどのchrootの環境のまま)
# /sbin/grub
grub> root (hd0,0)
grub> setup (hd0)
grub> quit
# sync

これにて完了!
あとはexitして、再起動すれば元通りに起動できる。

[windows]インストール後に使用者名を変える方法

Windowsのインストール後に「使用者名」を変更する方法
どこかのメーカーのインストールガイドCDが”使用者名”に半角英数しかうけつけてくれなくて日本語の名前が入力っできなかったとか、名前を間違っちゃったなんていうときの、”使用者名”の変更方法。
レジストリをいじります。
regeditを起動して([ファイル名を入力して実行]で「regedit」を入力してEnter)、ツリーで次を辿る[HKEY_LOCAL_MACHINESoftwareMicrosoftWindows NTCurrentVersion](CurrentVersionまで着たら、CurrentVersionをクリック)。
すると右側に[RegisteredOwner]や[RegisteredOrganization]がある。
この[RegisteredOwner]が”使用者名”、[RegisteredOrganization]が”組織名”。ダブルクリックして値を変更する。

[linux]コンパイル時に「ld: cannot find -l」となるときの解決方法

linux(Redhat系)にて、ソフトウェアインストールのコンパイル時に

/usr/bin/ld: cannot find -lXext

というエラーメッセージが表示され、コンパイルが失敗してしまうときの 解決方法。
-lに続くパッケージ?のライブラリがないから上記のようなエラーが発生する。(configureのチェックをすり抜けちゃってるんですね・・・)
つまり、-l<パッケージ名> なら「lib<パッケージ名>-devel」というパッケージを用意すればよいことになる。
具体的には 「ld: cannot find -lXext」なら「libXext-devel」
どのパッケージかわからなければ

yum search lib<パッケージ名>

で表示されたパッケージを全てインストールしてしまえばよい。

[JP1/Cm2/NNM]SNMPトラップを受信してアラームを表示する

JP1/Cm2/NNMでSNMPトラップを受信してアラームブラウザに表示する方法
やらないといけないことは

  1. MIBファイルのロード
  2. MIBに定義されたイベント(OID)毎にアラーム表示をONにする

の2つ。
当然のことながら プロダクト毎に用意されたMIBファイルをロードしなければならない。
ハマリどころは、 MIBファイルだけロードしてアラーム表示の設定をしないがために何も表示されない、ことである。未定義のOIDではないため、トラップをちゃんと受信していてもアラームブラウザに表示されない。そのためにトラップを受信しているかどうかもわからなくなる。
イベントごとのアラーム表示の設定はメニューバーの「オプション」??の「イベント設定」。エンタープライズを選択して、目的のイベントをダブルクリック 。
「イベント・ログ」タブにある コンボボックスでアラーム出力カテゴリーを設定すると、アラームブラウザに受信したSNMPトラップを表示できるようになる。
ちなみにSNMPトラップを受信しているかどうかの確認は、ovdumpeventsコマンドを使うとリアルタイムで確認できる。

>? ovdumpevents? -l 1 -t

何のNNMにこだわらなければ、ここにたくさん情報がある。 http://www.nec.co.jp/middle/WebSAM/products/Nnm/qabody2.html
[追記]
NNMiにおけるSNMPトラップを受信しているかどうかの確認はこちら