回答:
私の直感は、あなたの2番目のルートがより簡単になるということです。最初のルートは、それぞれが独自の癖を持つ2つの異なるシステムに触れることです。
このアプローチは、より多くの「障害点」を作成するようです(Windowsがイベントをリモートsyslogに記録するのをブロックするネットワークの問題を想像してください)。
最初のルートでは、Linux用のwmiクライアントをインストールするだけで済みます。お勧めしwbemcli
ます。(Debian / Ubuntuで試してみてくださいapt-get install wbemcli
。)これにより、Windowsロギング(私の経験では堅実です)は変更されません。一時的なネットワークの問題がある場合でも、ネットワークが完全に動作するようになった後、妥協のないログへのアクセスが戻ります。
ご存知かもしれませんが、WMIはMicrosoftによるWBEM(Webベースのエンタープライズ管理)の実装にすぎません。WBEMは、Distributed Management Task Forceコンソーシアムによって定義された業界標準です。
MSのWMIには、WBEM標準といくつかの違いがあります(ほとんどの場合、MSが「標準を実装している」と言っているためです)。たとえば、標準のWBEMとは異なるトランスポートプロトコルを使用します(WBEMは通常、HTTP over TCP / 5988またはHTTPS over TCP / 5989を使用します。WMIもわずかに異なる名前空間を使用します。それ以外はほとんど同じです。
これら2つについてコメントすることはできませんが、3つ目は知っています。ログを読み取り、クエリに応答するか、Linuxに新しいイベントをプッシュするWindowsに小さなサーバーをインストールします。このようなタスクには、win32モジュールでPythonを使用しました。
はいgit-bash
。Windows、sshサーバーが必要です(bitvise sshd
個人接続は推奨しませんが、非常に安定しており、十分にテストされています)。
それが完了したらgit-bash
、Windowsパスに配置する必要があります。
ssh username@10.15.3.3 'bash -c "tail -n 20 -F /c/Users/username/Desktop/logging_file.log"'