私が参加しているプロジェクトでサーバーのログをログ集約サーバーに転送することになりました。
syslogの転送先サーバーはすでに構築されているので、こちらの作業はsyslogを転送する設定を入れるだけですが、勉強のために転送の設定についても調べてみました。
まずはsyslogについて。
syslogはsendmailの一部として開発されましたが、便利だと言うことでUNIX/Linux等のデファクトスタンダードのロギング方式となりました。
syslogが使用するポートは514/udpなのでデータの保証はないが、TCPでの実装版であるrsyslogがあります。使用するには"/etc/services"に"syslog 514/udp"のエントリが必要です(RHEL5ではデフォルトで登録されている)。このエントリが無い場合、ポートを開けることができないのでデーモンは終了します。
ポートがない場合
ポートがある場合
・転送先サーバー設定
"/etc/sysconfig"にある"syslog"ファイルの"SYSLOGD_OPTIONS"を元の"-m 0"から"-m 0 -r"に修正します。また、"/etc/init.d"にも"syslog"ファイルがあるので同じように"SYSLOGD_OPTIONS"を修正します。
-mオプションは後ろの数字の時間(分)ごとにタイムスタンプを記録させます。"-- MARK --"という文字列がログの代わりに記録されます。ここでは"0"なのでこの機能は使わない設定になっています。
-rオプションはネットワークからのメッセージを受信する機能を有効にします。ver1.3以降のデフォルト設定はオフになっており、オプションをつけない限り受信しません。
以上の設定を終えたらsyslogデーモンを再起動します。
・転送元サーバー設定
"syslog.conf"の設定に"@"で始まるIPアドレス/ホスト名を追加します。
(ホスト名の名前解決ができない場合には10回問い合わせをした後、エラーメッセージを出力します。RHEL5ではエラーメッセージの出力が確認できませんでした)。今後の保守性を高めるためにもhostsに記述されているホスト名を使用する方が良いです。
全くすべてのログを転送するのであれば"*.* @hostname"と記述します。今回は通常"/var/log/messages"と"/var/log/secure"に書き込まれるレベルを転送することにしました。
以上の設定を終えたらsyslogデーモンを再起動します。再起動し次第、ログが転送され始めます。
今回設定した際にログ転送先サーバーのファイアウォールのポートを開けるのを忘れていました。
ホストLINUX02でログインしてもログが記録されません。
ログイン
tcpdumpを使って、ログが転送されているのかを確認しました。プロトコルはudpで宛先ポートが514の通信を表示します。
ログ転送先のポートが開いているかを確認。514ポート(下図ではsyslogと表記)自体は開いてリスン状態になっています。
ここまで来たら後はファイアウォールが怪しいです。ファイアウォールでポートをふさいでいないか確認したところ、見事にふさいでおりました。
"system-config-securitylevel"コマンドで"514/udp"ポートを開きます。
注意書きに「"サービス名:プロトコル"で記述せよ」とあったので"syslog:udp"と入力しました。
ファイアウォールのポートを開き、ホストLINUX02でログインしたところ、ログが記録されました。転送先サーバーのログには下記の様にホスト名が表示され、どこのサーバーで出力されたログかがわかるようになっています。転送されたログのホスト名が小文字なのは仕様なのでしょうか?
転送先サーバーでログがどのように振り分けて記録されるのかについても確認しました。
転送先サーバーの設定は認証についてのログを"/var/log/secure"だけでなく"/var/log/messages"にも記録するようにしてありました。
これをデフォルト通り"/var/log/secure"のみに書き込むように変更しました。
すると、最初にログの転送を確認したときには"/var/log/messages"にも記録されていた認証についてのログが"/var/log/secure"のみに記録されるようになりました。
ログの書き分けルールは転送先サーバーの設定に従うと言うことがわかりました。
RHEL5で確認してあります。
syslogの転送先サーバーはすでに構築されているので、こちらの作業はsyslogを転送する設定を入れるだけですが、勉強のために転送の設定についても調べてみました。
まずはsyslogについて。
syslogはsendmailの一部として開発されましたが、便利だと言うことでUNIX/Linux等のデファクトスタンダードのロギング方式となりました。
syslogが使用するポートは514/udpなのでデータの保証はないが、TCPでの実装版であるrsyslogがあります。使用するには"/etc/services"に"syslog 514/udp"のエントリが必要です(RHEL5ではデフォルトで登録されている)。このエントリが無い場合、ポートを開けることができないのでデーモンは終了します。
ポートがない場合
ポートがある場合
・転送先サーバー設定
"/etc/sysconfig"にある"syslog"ファイルの"SYSLOGD_OPTIONS"を元の"-m 0"から"-m 0 -r"に修正します。また、"/etc/init.d"にも"syslog"ファイルがあるので同じように"SYSLOGD_OPTIONS"を修正します。
-mオプションは後ろの数字の時間(分)ごとにタイムスタンプを記録させます。"-- MARK --"という文字列がログの代わりに記録されます。ここでは"0"なのでこの機能は使わない設定になっています。
-rオプションはネットワークからのメッセージを受信する機能を有効にします。ver1.3以降のデフォルト設定はオフになっており、オプションをつけない限り受信しません。
以上の設定を終えたらsyslogデーモンを再起動します。
・転送元サーバー設定
"syslog.conf"の設定に"@"で始まるIPアドレス/ホスト名を追加します。
(ホスト名の名前解決ができない場合には10回問い合わせをした後、エラーメッセージを出力します。RHEL5ではエラーメッセージの出力が確認できませんでした)。今後の保守性を高めるためにもhostsに記述されているホスト名を使用する方が良いです。
全くすべてのログを転送するのであれば"*.* @hostname"と記述します。今回は通常"/var/log/messages"と"/var/log/secure"に書き込まれるレベルを転送することにしました。
以上の設定を終えたらsyslogデーモンを再起動します。再起動し次第、ログが転送され始めます。
今回設定した際にログ転送先サーバーのファイアウォールのポートを開けるのを忘れていました。
ホストLINUX02でログインしてもログが記録されません。
ログイン
tcpdumpを使って、ログが転送されているのかを確認しました。プロトコルはudpで宛先ポートが514の通信を表示します。
ログ転送先のポートが開いているかを確認。514ポート(下図ではsyslogと表記)自体は開いてリスン状態になっています。
ここまで来たら後はファイアウォールが怪しいです。ファイアウォールでポートをふさいでいないか確認したところ、見事にふさいでおりました。
"system-config-securitylevel"コマンドで"514/udp"ポートを開きます。
注意書きに「"サービス名:プロトコル"で記述せよ」とあったので"syslog:udp"と入力しました。
ファイアウォールのポートを開き、ホストLINUX02でログインしたところ、ログが記録されました。転送先サーバーのログには下記の様にホスト名が表示され、どこのサーバーで出力されたログかがわかるようになっています。転送されたログのホスト名が小文字なのは仕様なのでしょうか?
転送先サーバーでログがどのように振り分けて記録されるのかについても確認しました。
転送先サーバーの設定は認証についてのログを"/var/log/secure"だけでなく"/var/log/messages"にも記録するようにしてありました。
これをデフォルト通り"/var/log/secure"のみに書き込むように変更しました。
すると、最初にログの転送を確認したときには"/var/log/messages"にも記録されていた認証についてのログが"/var/log/secure"のみに記録されるようになりました。
ログの書き分けルールは転送先サーバーの設定に従うと言うことがわかりました。
RHEL5で確認してあります。
大阪地検のFD改ざん事件ではファイルの更新日を変更していました。Linuxではtouchコマンドを使って作成日等を変更することができますが、Windowsではそれに該当するコマンドは無いようです。
WindowsでもtouchコマンドがあればいいのになとMSDNのライブラリを見ていた頃にメソッドがあったのを思い出して使ってみました。フリーウェアで探してみると結構たくさん出てきました。しかもとても使いやすそうな物も。そういったすぐれた物に比べればちゃっちいけれども、案外簡単に作れるなと言うのが正直な思いです。
使ったのはDirectoryクラスのメソッド6種類です。
GetCreationTime
GetCreationTimeUtc
GetLastAccessTime
GetLastAccessTimeUtc
GetLastWriteTime
GetLastWriteTimeUtc
【仕様】
.NET Framework1.0以上で動く。
テキストボックスに入力されたディレクトリもしくはファイルのタイムスタンプを変更する。
【課題】
課題は前回のMngDirと同じです
ファイル等のパスををドラッグ&ドロップで入力できない。これは調べ中です。
コードの書き方がわからなかったのでオブジェクトのイベント毎にコードを書いている。クラスなりにして外だしする方が再利用性が高くなるのはわかっているのだが。
ダウンロードはこちら-> Touche
zipを解凍して使ってください。
WindowsでもtouchコマンドがあればいいのになとMSDNのライブラリを見ていた頃にメソッドがあったのを思い出して使ってみました。フリーウェアで探してみると結構たくさん出てきました。しかもとても使いやすそうな物も。そういったすぐれた物に比べればちゃっちいけれども、案外簡単に作れるなと言うのが正直な思いです。
使ったのはDirectoryクラスのメソッド6種類です。
GetCreationTime
GetCreationTimeUtc
GetLastAccessTime
GetLastAccessTimeUtc
GetLastWriteTime
GetLastWriteTimeUtc
【仕様】
.NET Framework1.0以上で動く。
テキストボックスに入力されたディレクトリもしくはファイルのタイムスタンプを変更する。
【課題】
課題は前回のMngDirと同じです
ファイル等のパスををドラッグ&ドロップで入力できない。これは調べ中です。
コードの書き方がわからなかったのでオブジェクトのイベント毎にコードを書いている。クラスなりにして外だしする方が再利用性が高くなるのはわかっているのだが。
ダウンロードはこちら-> Touche
zipを解凍して使ってください。
Visual C++で物を作ることができるようになるとようやく決意して数日。一つ目のツールを作りました。
ディレクトリを作って削除するだけ。
仕事ではLinuxを使っているのだが、Linuxでは入れ子になったディレクトリを作成することも削除することもできるのに、何でWindowsではできないんだろうと疑問に思ってました(注:今確認したところ、入れ子ディレクトリはコマンドラインからもPowerSherllからも作成できますが、削除はPowerSherllでしかできませんでした)。
なので入れ子ディレクトリをいじくることができるツールを作ってみました。
正直、.NET Frameworkと言う物が何なのかすらよくわからなかったのですが、結構簡単に作れました。純粋にC言語で作ろうと思っていたのでどう作って良いのかあれこれ考えながらMSDNのライブラリを見ていたら、使いたいけど自分で作るしかない機能(関数)がたくさん用意されていました。
そうか。.NET FrameworkはStrutsなどと同じ用にFrameworkなんだと今更ながらに気がつきました。
なんだ、思っていたほど難しくはないな。パフォーマンスを要求する様な高度な物でなければ何とか作れるのかもしれません。
今回作ったツールについて:
【仕様】
.NET Framework2.0以上で動く。
テキストボックスに入力されたディレクトリを作成もしくは削除する。
【課題】
ファイル等のパスををドラッグ&ドロップで入力できない。これは調べ中です。
コードの書き方がわからなかったのでオブジェクトのイベント毎にコードを書いている。クラスなりにして外だしする方が再利用性が高くなるのはわかっているのだが。
ダウンロードはこちら-> MngDir
zipを解凍して使ってください。
ディレクトリを作って削除するだけ。
仕事ではLinuxを使っているのだが、Linuxでは入れ子になったディレクトリを作成することも削除することもできるのに、何でWindowsではできないんだろうと疑問に思ってました(注:今確認したところ、入れ子ディレクトリはコマンドラインからもPowerSherllからも作成できますが、削除はPowerSherllでしかできませんでした)。
なので入れ子ディレクトリをいじくることができるツールを作ってみました。
正直、.NET Frameworkと言う物が何なのかすらよくわからなかったのですが、結構簡単に作れました。純粋にC言語で作ろうと思っていたのでどう作って良いのかあれこれ考えながらMSDNのライブラリを見ていたら、使いたいけど自分で作るしかない機能(関数)がたくさん用意されていました。
そうか。.NET FrameworkはStrutsなどと同じ用にFrameworkなんだと今更ながらに気がつきました。
なんだ、思っていたほど難しくはないな。パフォーマンスを要求する様な高度な物でなければ何とか作れるのかもしれません。
今回作ったツールについて:
【仕様】
.NET Framework2.0以上で動く。
テキストボックスに入力されたディレクトリを作成もしくは削除する。
【課題】
ファイル等のパスををドラッグ&ドロップで入力できない。これは調べ中です。
コードの書き方がわからなかったのでオブジェクトのイベント毎にコードを書いている。クラスなりにして外だしする方が再利用性が高くなるのはわかっているのだが。
ダウンロードはこちら-> MngDir
zipを解凍して使ってください。
一昨年参加したカンファレンスでMicrofsoft Visual Studio 2008をもらった。PCにインストールしてLinuxツールのソース等を見るのに使っていたのだが、やっぱり自分で何かを作らなきゃもったいないし技術がつかないのであれこれ作ってみることにした。
自分のわかる範囲では存在していないけれど、あったら便利であろうソフト/ツールのアイディアはいくつかある。とは言っても、開発経験はほぼゼロなのでそんなソフト/ツールを作るどころか、しょうもないツールを作ることでもあっぷあっぷ。
とりあえず、「習うより慣れろ」で試行錯誤していこうと思う。「こんなん作ってどうするの?このツール使うより、手で作業した方が早いでしょ?」という台詞はしばらく封印する。
ところで、Visual C++とVisual C#、どっちをやったらよいのだろう・・・一つのツールを二言語で作ってみるか。
自分のわかる範囲では存在していないけれど、あったら便利であろうソフト/ツールのアイディアはいくつかある。とは言っても、開発経験はほぼゼロなのでそんなソフト/ツールを作るどころか、しょうもないツールを作ることでもあっぷあっぷ。
とりあえず、「習うより慣れろ」で試行錯誤していこうと思う。「こんなん作ってどうするの?このツール使うより、手で作業した方が早いでしょ?」という台詞はしばらく封印する。
ところで、Visual C++とVisual C#、どっちをやったらよいのだろう・・・一つのツールを二言語で作ってみるか。
リモートでのイベントビューアー確認~その一 接続でリモートからイベントビューアーを確認するとサーバーの役割についての確認が取れませんでした。
調べてみたところ、WindowsのクライアントOSからサーバーOSを確認する場合、「リモート サーバー管理ツール」をクライアントにインストールする必要があります。インストールすることにより、Windows Server 2008 R2、Windows Server 2008、Windows ServerR 2003 を実行しているコンピューターにインストールされた役割と機能を管理できるようになります。
この「リモート サーバー管理ツール」ですが、現在はVISTA/VISTA(64)/7の三種類がリリースされており、概要は下記の通りです。
・Windows Vista for x64-based Systems 用 Microsoft リモート サーバー管理ツール
Windows Vista Business 64-bit edition; Windows Vista Enterprise 64-bit edition; Windows Vista Ultimate 64-bit edition
Windows Vista Service Pack 1 (SP1)、もしくはそれ以降のバージョンのサービス パックが必要です。
・Windows Vista 用 Microsoft リモート サーバー管理ツール
Windows Vista Business; Windows Vista Enterprise; Windows Vista Ultimate
Windows Vista Service Pack 1 (SP1)、もしくはそれ以降のバージョンのサービス パックが必要です。
・Windows 7 用のリモート サーバー管理ツール
Windows 7
Windows 7 用のリモート サーバー管理ツールは、Enterprise、Professional、Ultimate の各エディションの Windows 7 を実行しているコンピューターのみにインストールでき、管理対象となるサーバーにはインストールできません。
まずはリモートサーバー管理ツールをMicrosoftのページからダウンロードして、インストールします。
次に必要なツールを有効にします。
コントロールパネル -> プログラム -> Windowsの機能の有効化または無効化 -> リモートサーバー管理ツールから必要なツールのチェックボックスをオンにします。
プログラム一覧の管理ツールを開くと、先ほど追加したツールが追加されていることが確認できます。
Hyper-Vマネージャーを起動する前にいくつか準備をする必要があります。
まず、ファイアウォールの設定です。サーバー側もクライアント側も"Windows Management Instrumentation(WMI)"の規則を有効化します。
サーバー側
クライアント側
次に、サーバー側の設定で、サーバーマネージャーのトップページで「サーバーマネージャーのリモート管理の構成」というメニューがあるので「有効」に設定します。
最後に、クライアント側の設定で、dcomcnfgでCOMセキュリティを変更します。
dcomcnfgを検索・実行し、コンポーネントサービス -> コンピューター -> マイコンピューターと進み、右クリックからプロパティを開きます。COMセキュリティタブを開き、アクセス許可の「制限の編集」をクリック。ANONYMOUS LOGONのリモートアクセスを「許可」します。
これで設定は終了なので、Hyper-Vマネージャーを開くとサーバー上に構築されている仮想マシンが表示され、サーバー上にいるのと全く変わりなく管理することができるようになりました。
仮想マシンに接続しようとすると「お使いの資格情報は機能しませんでした」というメッセージとともにログインウィンドウが開きます。
これはWorkgroupで管理しているからかもしれません。要調査です。
ここで入力するユーザーはサーバー上のAdministrators権限を持っていなければいけないようです。権限を持っていない場合、下記のエラーが発生します。このエラーについても要調査です。
「MSDN Code Gallery」が参考になりました。
調べてみたところ、WindowsのクライアントOSからサーバーOSを確認する場合、「リモート サーバー管理ツール」をクライアントにインストールする必要があります。インストールすることにより、Windows Server 2008 R2、Windows Server 2008、Windows ServerR 2003 を実行しているコンピューターにインストールされた役割と機能を管理できるようになります。
この「リモート サーバー管理ツール」ですが、現在はVISTA/VISTA(64)/7の三種類がリリースされており、概要は下記の通りです。
・Windows Vista for x64-based Systems 用 Microsoft リモート サーバー管理ツール
Windows Vista Business 64-bit edition; Windows Vista Enterprise 64-bit edition; Windows Vista Ultimate 64-bit edition
Windows Vista Service Pack 1 (SP1)、もしくはそれ以降のバージョンのサービス パックが必要です。
・Windows Vista 用 Microsoft リモート サーバー管理ツール
Windows Vista Business; Windows Vista Enterprise; Windows Vista Ultimate
Windows Vista Service Pack 1 (SP1)、もしくはそれ以降のバージョンのサービス パックが必要です。
・Windows 7 用のリモート サーバー管理ツール
Windows 7
Windows 7 用のリモート サーバー管理ツールは、Enterprise、Professional、Ultimate の各エディションの Windows 7 を実行しているコンピューターのみにインストールでき、管理対象となるサーバーにはインストールできません。
まずはリモートサーバー管理ツールをMicrosoftのページからダウンロードして、インストールします。
次に必要なツールを有効にします。
コントロールパネル -> プログラム -> Windowsの機能の有効化または無効化 -> リモートサーバー管理ツールから必要なツールのチェックボックスをオンにします。
プログラム一覧の管理ツールを開くと、先ほど追加したツールが追加されていることが確認できます。
Hyper-Vマネージャーを起動する前にいくつか準備をする必要があります。
まず、ファイアウォールの設定です。サーバー側もクライアント側も"Windows Management Instrumentation(WMI)"の規則を有効化します。
サーバー側
クライアント側
次に、サーバー側の設定で、サーバーマネージャーのトップページで「サーバーマネージャーのリモート管理の構成」というメニューがあるので「有効」に設定します。
最後に、クライアント側の設定で、dcomcnfgでCOMセキュリティを変更します。
dcomcnfgを検索・実行し、コンポーネントサービス -> コンピューター -> マイコンピューターと進み、右クリックからプロパティを開きます。COMセキュリティタブを開き、アクセス許可の「制限の編集」をクリック。ANONYMOUS LOGONのリモートアクセスを「許可」します。
これで設定は終了なので、Hyper-Vマネージャーを開くとサーバー上に構築されている仮想マシンが表示され、サーバー上にいるのと全く変わりなく管理することができるようになりました。
仮想マシンに接続しようとすると「お使いの資格情報は機能しませんでした」というメッセージとともにログインウィンドウが開きます。
これはWorkgroupで管理しているからかもしれません。要調査です。
ここで入力するユーザーはサーバー上のAdministrators権限を持っていなければいけないようです。権限を持っていない場合、下記のエラーが発生します。このエラーについても要調査です。
「MSDN Code Gallery」が参考になりました。
「Hyper-Vの構築~その五 仮想マシンのインストール(Red Hat Enterprise Linux 5.4)」でLinux IC (統合コンポーネント)v2.0をインストールしました。
しかし、2010年7月にLinux Integration Services v2.1がリリースされています。対応しているLinuxゲストOSは下記の6つです。
Linux Distributions (4コア)
SUSE Linux Enterprise Server 10 with Service Pack 3 (x86 Editionまたはx64 Edition)
SUSE Linux Enterprise Server 11 (x86 Editionまたはx64 Edition)
Red Hat Enterprise Linux (RHEL) 5.2、5.3、5.4および5.5 (x86 Editionまたはx64 Edition)
さらに、v2.1ではインストール方法が変更されています。
注意点は下記の二点です。
・v2.1をインストールするには対象Linux OS上の"/usr/src/kernels/2.6.18-155.el5-i686"にカーネルがインストールされている必要があります。
・Software Developmentパッケージがインストールされている必要があります。
それではインストールしていきますが、新規インストールも旧バージョンからのアップグレードも手順は全く同じになります。ここではアップグレードした際のイメージを載せておきます。
まずはCDをマウントし、中身をすべて"/opt"以下の任意のディレクトリにコピーします(MSのドキュメントでは"/opt/linux_ic_v21_rtm2となっています)。
コピーしたらそのディレクトリへ移動し、"make"コマンドを実行します。
"make"が完了したら"make install"でインストールします。
インストールが完了したらLinuxを再起動します。
再起動後にsshで接続した図ですが、前回のログイン時刻と現在時刻が大きくずれています。これは、v2.1で追加されたホストOSとの時刻同期が動いているためです。インストールから1週間で3時間ほどずれています。
サーバーマネージャーで確認をすると、ステータスのところで「ハートビート」が「OK」になっています。Linux ICをインストールする前は「OFF」となっていました。
また、サーバーマネージャーからOSのシャットダウンをすることもできます。
これもv2.1からの新機能です。サポートLinuxゲストOSでも書いてありますが、複数コアのサポート等もv2.1から追加されています。詳細についてはMicrosoftのドキュメントを参照してください。
Linux Integration Services v2.1 for Windows Server 2008 Hyper-V R2
しかし、2010年7月にLinux Integration Services v2.1がリリースされています。対応しているLinuxゲストOSは下記の6つです。
Linux Distributions (4コア)
SUSE Linux Enterprise Server 10 with Service Pack 3 (x86 Editionまたはx64 Edition)
SUSE Linux Enterprise Server 11 (x86 Editionまたはx64 Edition)
Red Hat Enterprise Linux (RHEL) 5.2、5.3、5.4および5.5 (x86 Editionまたはx64 Edition)
さらに、v2.1ではインストール方法が変更されています。
注意点は下記の二点です。
・v2.1をインストールするには対象Linux OS上の"/usr/src/kernels/2.6.18-155.el5-i686"にカーネルがインストールされている必要があります。
・Software Developmentパッケージがインストールされている必要があります。
それではインストールしていきますが、新規インストールも旧バージョンからのアップグレードも手順は全く同じになります。ここではアップグレードした際のイメージを載せておきます。
まずはCDをマウントし、中身をすべて"/opt"以下の任意のディレクトリにコピーします(MSのドキュメントでは"/opt/linux_ic_v21_rtm2となっています)。
コピーしたらそのディレクトリへ移動し、"make"コマンドを実行します。
"make"が完了したら"make install"でインストールします。
インストールが完了したらLinuxを再起動します。
再起動後にsshで接続した図ですが、前回のログイン時刻と現在時刻が大きくずれています。これは、v2.1で追加されたホストOSとの時刻同期が動いているためです。インストールから1週間で3時間ほどずれています。
サーバーマネージャーで確認をすると、ステータスのところで「ハートビート」が「OK」になっています。Linux ICをインストールする前は「OFF」となっていました。
また、サーバーマネージャーからOSのシャットダウンをすることもできます。
これもv2.1からの新機能です。サポートLinuxゲストOSでも書いてありますが、複数コアのサポート等もv2.1から追加されています。詳細についてはMicrosoftのドキュメントを参照してください。
Linux Integration Services v2.1 for Windows Server 2008 Hyper-V R2