Feel Think ～ 自由気ままな日記風

manコマンドを単純に

man ls > ls.txt

としてもファイルをエディタで開いても文字化けしたように表示される。

こんな時は、「col」コマンドを使うと文字化けを解消することができる。

コマンドは、

man ls | col -b > ls.txt

こんな感じ。

これで通常のテキストファイルにすることができます。

正月休み中に調べようと思っていた件を最終日にやっと調査。

PowerShellでは.net Frameworkのオブジェクトがそのまま扱えます。

win32apiを呼ぶこともできますが、せっかくなので、.netでウィンドウハンドルとメインウィンドウのタイトルを取得してみます。

ちなみにPowerShellから.netのメソッドを呼び出す方法は「[クラス]::メソッド名(引数)」とすることで、呼び出せます。

$psArray = [System.Diagnostics.Process]::GetProcesses()

foreach ($ps in $psArray){
[String]$ps.Handles + " : " + $ps.MainWindowTitle
}

重要なところは1行目だけSystem.Diagnostics.ProcessクラスのGetProcesses()メソッドを呼び出します。

あとはとりあえず画面に出すための文。

こんな感じでほかのクラスも呼び出せる。

原因判明！！

PowerShellで使うメッセージファイルの記述方法によってうまく出ないことが判明。。。

↓メッセージファイルをこんな風に書くと、ダメ。

LanguageNames = (Japanese=0x411:MSG00411)

MessageId = 0x1
Severity = Informational
Facility = Application
SymbolicName = MSG_0
Language = Japanese
%1
.

↓こんな風に書けばOK

LanguageNames = (Japanese=0x411:MSG00411)

MessageId = 0x1
Facility = Application
SymbolicName = MSG_0
Language = Japanese
%1
.

どこが違うかというと、「Severity = Informational」があるか、ないかの違いです。

ResourceHackerで見てみたところ、左のメッセージIDがちょっと変。（左がSeverityを書いている、右はSeverityがない）

画面の右のようになるようにDLLを作れば「Write-EventLog」の-EventIDにメッセージIDを指定すればちゃんと出てきます。

ちなみに「Write-EventLog」に-EntryTypeがあるのでここでError、Warning、Information、SuccessAudit、FailureAuditを設定すればメッセージファイルでSeverityを書かなくてもEntryTypeの設定どおりイベントログに記録されました。

Windows PowerShell のWite-EventLogコマンドレットを使ってEventLogを出力できる（はず・・・）。

でも、手元の環境では何度やっても、

「イベントID （X）（ソース hogehoge 内）に関する説明が見つかりませんでした。～」

のようなメッセージと自分が設定したメッセージがつながって出てくる。

「イベントID～」の部分はいらないんですが・・・。

いろいろ調べて、メッセージリソースファイル作ってレジストリにも書いてあるのになぁ。

TechNetライブラリになんか書いてあるのかなぁ。

もうちょっと探ってみるか。

ちょっとハマったのでメモ(._.) φ メモメモ

Apacheでmod_proxyを使ってProxyをさせる設定（バックエンドにはAPサーバ）で、リクエストがURLエンコードされていて、そのエンコードされた文字列に%2Fや%5Cが含まれていると404エラーになります。

これはデコードすると、%2cが「/(スラッシュ)」、%5Cが「\(バックスラッシュ・￥記号)」になってしまい、Apacheのデフォルトでは許可しないようになっているため404になるようです。

これを回避するためのオプション「AllowEncodedSlashes」（Apache2.0のドキュメントだけど、Apache2.2でも使えた）を設定しましょう。

httpd.confに「AllowEncodedSlashes on」を追加する。どこに追加すればよいかわからなければ、ファイルの一番最後にでも追加すればOK

Webサーバのサービス再起動をすれば、%2Fと%5Cが含まれていても正しくアクセスできると思います。

昨日の続きです。

今日は、初期化して、実際のリカバリをメモ

では早速、

先日の記事、Linux LVMのバックアップに引き続き、取得したバックアップからリカバリしてみたいと思います。

想定する状況としては、稼働していたサーバのハードディスクが物理的に故障して、新しいハードディスクに交換した環境にリカバリをする手順としてみたいと思います。

それでは、いってみよ～。

SystemRescueCDは32bitにも、64bitにも対応している。

CDでboot直後に表示されるbootプロンプトで以下のようにする。

32bitカーネルで起動する場合は「何も入力しない」か「rescuecd」と入力する。

64bitカーネルで起動する場合は、amd64に対応しているシステムだったら「rescue64」で起動できて問題無ければいいけど、amd64に対応してなかったり、なんかおかしければ「altker64」で起動すべし。
自分のシステムがamd64に対応してるかどうかわからなければ、とりあえず「rescue64」で起動したらいいと思います。

手元のVMwareの環境ではrescue64で起動したら、起動はしたものの仮想ハードディスクが認識されませんでした。
altker64で起動したらハードディスクも認識したので、試して見てちゃんと動く方で起動すればよいです。

SystemRescueCDメモ

ダウンロードは、http://www.sysresccd.org/Main_PageのDownloadからできます。
CDに焼くなり、ISOイメージのまま仮想マシンで使うなりどうぞご自由に使ってください。
SystemRescueCDはNTFSのマウントもできるらしく、partimageを使ってバックアップもとれたりするみたいです。
そのうち試して見たいと思います。
とりあえず今回は、起動した後、ネットワークにつなぐあたりのメモを残します。

1．ネットワークに接続する

DHCPのある環境であれば、
# dhcpcd eth0[Ent]
でDHCPが有効になり自動でIPを取得します。
※eth0の部分は環境に合わせてNICを選択してください。

DHCPが無い環境だったら、
# ifconfig eth0 IPアドレス[Ent]
# route add default gw ゲートウェイのIPアドレス[Ent]
# vi /etc/resolv.conf[Ent]
nameserver DNSサーバのIPアドレス
をしてあげればどこにでもつながるかもね。
※eth0の部分は環境に合わせてNICを選択してください。

もしインターネットにつながなくて良ければroute addとresolv.confは無くてもいいよ。

2．NFSのマウント（NTFSじゃないよ）

これは普通通りにやればいいのですが、
# mkdir /mnt/nfsmount[Ent]
# mount -t nfs IPアドレス:/NFSのパス[Ent]
というようにします。先にマウントポイントのフォルダを作っておきましょう。

当たり前ですが、ココで作ったマウントポイントのフォルダなどは、再起動したら消えますので、再起動したら毎回作成する必要があります。（再起動しなければ消えないはず）

Sambaとか、SSHとかも使えるみたいです。（FTPサーバは入ってなかった）

Linux LVMのバックアップの続き。

今日は、SnapShotをとって、バックアップをしてみたいと思います。
昨日やった所までやるとやり過ぎてしまったので、昨日の投稿を修正してVolume Groupを拡張したところまでにしました。
手元の環境ではLogical Volumeまで拡張してしまっていたので、Logical Volumeを縮小しようとして、lvreduceを実行したところ失敗してOSが起動できなくなってしまったので、急遽再インストールをしました。（VMなんだから先にイメージ取っておけば良かったんですが。。。）
lvreduceコマンドを実行するときは注意してやった方が良いです。（今回はオプションに「-」(マイナス)を付け忘れただけで追加した領域OSで使っている領域まで縮小してしまった）