4 つの Windows ツールを単一の Linux VM に置き換えました

James Mitchell included in Windows Linux

2026-02-07 202 words One minute

Contents

<本文>

過去数年間にわたって、私の Windows インストールにはツールのコレクションが徐々に蓄積されていきましたが、そのほとんどはメインワークステーション上に存在する必要はありません。ここにはスケジュールされたタスク、そこにはネットワークスキャナー、後でアンインストールすると誓った SSH クライアント、そして Windows がその特定の仕事に適していないためにのみ存在した 6 個の小さなユーティリティがあります。どれもそれ自体では特に重いアプリケーションではありませんでしたが、乱雑なアプリケーションには少しうんざりしていました。 Proxmox ボックスを有効活用し、これらのユーティリティに使用できる Linux VM を作成する時期が来たと判断しました。その結果、よりクリーンなワークステーションと、私のユースケースにより適したツールが誕生しました。

rsync の Cron ジョブ

タスクスケジューラやサードパーティのバックアップツールの優れた代替品

Windows タスクスケジューラは、私が信頼するというよりもむしろ許容していたものの 1 つでした。再試行、電源状態に応じてトリガーが勝手に動作すること、操縦室に正しくないことを実行することに関しては、あまり信頼性がありませんでした。

スケジュールされたジョブを Linux VM に移動し、適切に構成すると、そのような不確実性はすべて基本的になくなりました。単純な繰り返し作業は cron に存在し、より複雑なものは systemd タイマーとして実行されます。これは、rsync バックアップなどに最適です。サードパーティツールやタスクスケジューラに依存する代わりに、VM はワークステーションからデータを取得して NAS に保存するすべての rsync ジョブを処理します。失敗した場合は、明確なログとトラブルシューティングパスにより、その理由がすぐにわかります。

新しく始めるときに誰もが犯す Proxmox のよくある 5 つの間違い (およびそれらを回避する方法)

そうだ、私は Proxmox の初期にこれらの間違いをいくつか犯した

ネットワークスキャン

Nmap はオフサイトシステムでの方が優れています

ネットワークスキャンとトラブルシューティングは、私がメインワークステーションで実行できるように常に準備していましたが、実際にはそれを実行するのに最適な場所ではありませんでした。私は、nmap のインストールをポータブルな状態に保つか、メインマシンから完全に外したほうがよいと考えています。

有効に機能するための適切なレベルのアクセス権があれば、Linux VM はおそらく nmap のようなものにとって最適な場所です。基本的な検出は高速で反復可能であり、ブロードキャストを多用する GUI ツールに依存せずに、単純なサブネットスキャンで何が生きているかを知ることができます。さらに詳細な情報が必要な場合は、対象を絞ったスキャンによって、どのサービスが公開されているか、どのように応答しているかが正確に明らかになります。 CLI ファーストであるため、出力を保存したり、結果を経時的に比較したり、トラブルシューティングの一環としてスクリプトスキャンを行ったりすることができ、それらを 1 回限りのアクションとして扱うのではありません。

おそらく最も重要なことは、VM 上に存在するすべてのものは、VM が必要なネットワークセグメント上にすでに存在していることを意味します。私は主にホームラボ側のスキャンを行いますが、それ以外はあまりスキャンしません。また、Windows ファイアウォールを使用すると、おかしなビジネスを完全に回避できます。これは追加のボーナスです。

Tmux は、すべての Linux ユーザーが必要とする生産性ツールです

ターミナルを多用するタスクには必須のツールです

実際に意味のある SSH ハブ

Tmux はメジャーアップグレードでした

VM が登場する前は、Windows 上の SSH は期待以上に一時的であるように感じられました。クライアントをインストールし、いくつかのセッションを保存すると、実際にどこで作業したかが徐々にわからなくなります。長時間実行されるコマンドをいじって変更するのは危険でした。切断するとコンテキストが失われ、再起動すると最初からやり直すことになりますが、これは私のメインワークステーションでは一般的でした。

SSH のすべてを Linux コンテナに移行するということは、何よりもまず一貫性を意味します。これを実際に機能させるのは tmux です。長時間実行される SSH セッションは、ターミナルウィンドウではなく tmux ペイン内に存在します。これは、ワークステーションがスリープ、再起動、または切断されても、何も停止しないことを意味します。 VM に再接続し、tmux に再アタッチすると、履歴、環境変数、中途半端なコマンドなどがすべて残った状態で、中断したところから再開されます。

Docker コンテナ

WSL は優れていますが、専用 VM 内の Docker の方が合理的です

ワークステーション上で Linux 関連のことを行う場合、WSL は救世主になる可能性がありますが、WSL 内でコンテナー化されたものを実行するのはあまり現実的ではありません。 WSL を使用して小規模なサービスとテスト環境を実行していましたが、これは便利でしたが、それらを Linux VM の Docker に移行すると、多くのことが煩わしくなくなりました。その主なものはネットワークとハードウェアパススルーでした。

Linux VM ワークフローに関するニュースレターを購読する

ニュースレターを購読して、実践的な Linux VM のチュートリアルを入手してください。詳細な構成、トラブルシューティングのヒント、Windows ユーティリティを VM に移行するための実際の例 (SSH/tmux ワークフロー、rsync バックアップセットアップ、Docker ネットワーキング、スキャンなどをカバーしています) が含まれています。

購読する

購読すると、ニュースレターとマーケティング電子メールの受信に同意し、利用規約とプライバシーポリシーに同意したものとみなされます。いつでも購読を解除できます。

WSL ではネットワーキングは楽しいものではありません。これは主に WSL で使用される抽象化の層が原因です。ポート転送の動作はバージョンに応じて異なります。localhost は「Windows」を意味する場合もあれば、「Linux」を意味する場合もあります。サービスをネットワークの残りの部分に公開するには、追加の構成や回避策が必要になることがよくあります。パススルーも同様に煩わしく、多くの場合まったく機能しないことがよくあります。 VM で両方のことを実行できる機能はよく踏まれた道であり、追加の構成はそれほど必要ありません。

新しいサーバーごとに実行する 4 つの必須 Docker コンテナー

ワークステーションを管理するための便利なコンテナのコレクション

私のセットアップはよりクリーンでより集中していると感じました

なくなるまで、自分がどれだけ散らかっていたかわかりませんでした。これらのツールを Linux VM に移動すると、Windows インストールは、必要なものまで取り除かれ、私が時々ゲームをする高速で応答性の高いワークステーションになりました。オートメーション、ネットワーキング、SSH、コンテナーはすべて、デスクトップ OS に関連付けられていない方がより適切に機能し、いずれにせよ Linux により適していることがよくあります。

*️⃣ 出典リンク:

ネットワークスキャナー、Proxmox、新しく始めるときに誰もが犯す Proxmox のよくある 5 つの間違い (およびその回避方法) 、Tmux はすべての Linux ユーザーが必要とする生産性ツールです、、、利用規約、プライバシーポリシー、4 必須の Docker新しいサーバーごとに実行するコンテナー、Linux VM、SSH、