2017年8月27日日曜日

Operations Management Suite の Service Map ソリューション - Windowsに入れてみたよ

Operations Management Suite の Service Map エージェントをWindows Serverにも入れてみました。
ターゲットは、SC 2016 OM。
※このマシンでは、Service Mapの管理パックを確認予定です。

Service Map エージェントは、ここのマシンにインストールする前提です。
では、Service Map エージェントを入れてみます。

Service Mapの画面に移動します。
すでにLinuxエージェントからデータが上がっています。
この画面のどこからエージェントをダウンロードするのかちょっと迷いましたが、[Add Machines]をクリックすればよいです。


そうするとダウンロードリンクが表示されます。ここからWindowsとLinuxのエージェントをダウンロードすれば良い訳です。


ダウンロードしたWindows版エージェントはこちらの通り。


これをインストールします。といってもワンステップで

インストール完了。

すぐにService Mapに表示されます。

さてこの右側ペイン、別記事でまとめてみていこうと考えています。

2017年8月22日火曜日

Operations Management Suite の Service Map ソリューション - まずはLinuxに入れてみたよ

Operations Management Suite の Service Map ソリューションを使いには、先にOMS Agnetをインストールしておくとのこと。
Configure Service Map in Operations Management Suite

Connect your Linux Computers to Operations Management Suite (OMS)
Linux コンピューターを Operations Management Suite (OMS) に接続する

Connect Windows computers to the Log Analytics service in Azure
Windows コンピューターを Azure の Log Analytics サービスに接続する
※Windows AgnetはLog Analyticsとなっております。。。

本稿では、すでにOMS Agent for Linux導入済みマシンを使うので、上記は飛ばします。
このマシンは、Zabbixが動いているので、サービスマップの確認にちょうど良いかなと。

直接ダウンロードして、インストールする方法は、下記に記載があります。
Configure Service Map in Operations Management Suite - インストール スクリプトの例
では、やってみます~



インストール自体は、これだけのようです。

割とすぐに表示されますね。


OMSのタイルから、更にドリルダウンしてみるとこうなります。

これ、実物見るとなかなか面白いですね。
Windowsのエージェントも試してみようっと。

2017年8月19日土曜日

Operatioins Management SuiteのService Map


Service Map integration with Operations Manager in public preview

を見かけました。図は上記リンクに掲載されているものを見ていただきたいのですが、アプリケーションを構成するミドルウェアといいますかソフトウェアとその利用ポートが表示されるマップということです。
こちらはOMS(Microsoft Operatioins Management Suite)で実装されます。そのサービスマップをSCOMとの統合できるプレビューの管理パックがリリースされています。

ソリューションを利用可能にしてみたところ、専用のエージェントがいるみたい。


Service Mapは、2016年11月にアナウンスがあったようで、これまでに下記の情報が公開されています。
Operations Management Suite の Service Map ソリューションの使用


サービス マップと System Center Operations Manager の統合

こちらでは、SCOMとの統合について初めて言及されています。

Announcing the general availability of Service Map solution
では、2017年4月にGAされた旨の記載。

Service Map Machine Groups
という記事もあります。

そして冒頭のリンクで、SCOMとの統合がプレビューの管理パックとして実装されました。

ということでこの後2~3回に渡り確認していこうと思います。

2017年8月15日火曜日

Windows Server Insider Preview Build 16257のWindows Subsystem for Linuxでsshdを有効化

注)Windows Subsystem for Linuxは、随時起動させていますから、deamonというかWindowsのサービス的な使い方は、現時点で想定されておりません。
Announcing Windows Server Insider Preview Build 16257にも下記の通り記載があります。
At this time, WSL does not support persistent Linux services (such as daemons and jobs) as background tasks.


まずsshdについて、Debian系のパッケージ名を調べる。
パッケージ: ssh (1:6.0p1-4+deb7u6) [security]の"その他の ssh 関連パッケージ"に、openssh-serverである旨、記載がありますね。
これで、パッケージ導入済みか調べてみます。
dpkg --status パッケージ名
でわかりますね。


runlevelを確認したいので、sysv-rc-confを起動してみたら入っておりません。


というわけで、パッケージ追加。



runlevel 2,3,4,5で有効化されています。


ps axを実行してみましたが、deamonは起動していない様子。


sshdを起動してみた。

あれ、ホストキーがない。。。ホストキーがなければ作成してくれる仕様だったはず。
調べたら、
Ubuntu 16.04 LTS ServerでSSHのホストキーが自動生成されない
という記事があり、
dpkg-reconfigure openssh-server
を実行すればよいらしい。

ホストキーができた。

ssh localhostしてみる。

permission denied (publickey)
が発生しております。
Teratermからは、接続エラー。


Windows Server Insider Preview機のWindows Firewallを開放。


.ssh配下、known_hostsしかないですね。

SSH using publickey not working on debian (Permission denied (publickey,password).) with clean /var/log/auth.logあたりを見てみると、
and yes - the my local ~/.ssh/id_rsa.pub is in the servers ~/.ssh/authorized_keys
となっているので、鍵のファイルがないことに起因している。今回は接続確認が目的なので、パスワード認証を有効化できれば良いと考え、

sshd_configを開いたら、パスワード認証が無効化→鍵で認証ということになります。。。上の画面通り、パスワード認証を有効化しました。

sshdを再起動。


ローカルホストから、ssh成功。


リモートホストから、ssh成功。



以上で接続確認とれました。

今回のポイントは、下記のとおりです。
  • Windows Subsystem for Linuxが動作するOSにおいて、Windows Firewallを開けておく
    今回の例では、Windows Firewall自体を無効化しまししたが、sshの22/TCPだけあけるのが推奨
  • Windows Server Insider Preview Build 16257のWindows Subsystem for Linuxで利用しているUbuntuのsshd_configは既定で鍵認証になっている
    1. そのまま使うならssh鍵の用意が必要。ローカル側にid_rsa.pub、ssh先に~/.ssh/authorized_keysとして用意。
      ssh鍵は、ssh-keygen - 認証用の鍵を生成 - Linuxコマンド等々を参照すれば作成できますね。
    2. 本稿のようにパスワード認証を有効化することも可能です。

2017年8月12日土曜日

Windows Server Insider Preview Build 16257でascii以外のファイル名はどうなる

英語版なので、日本語ファイル名どうなるのかと思い、別サーバーのファイル共有をnet useでマウントしてみた。

やっぱり文字化けしますよね。これは日本語言語パックが入っていませんから至極当たり前の挙動です。


Insider Previewで言語の追加はたぶんできないのだろうとは思いますが、コントロールパネル周りで使えるのは何か調べおきます。
でも、whereコマンドで調べようと思ったら、PowerShellのWhere-Objectのエイリアスだった。。。


Use Windows PowerShell to search for filesにLinuxのfindライクなファイルの探し方が載っていたので、それを応用。


従来通り、
  • 地域
  • 日付と時刻
の二つのみ利用可能です。
実際にそれぞれを起動してみました。

地域




日付と時刻




さて、Windows Subsystem for Linuxでもascii以外のファイル名を確認しておきます。
Windows Server Insider Preview Build 16257なサーバーから、日本語ファイル名のファイルはコピーできないため、別サーバーからコピーします。
Windows PowerShell によるセキュリティ管理が強化された Windows ファイアウォールをみて、Windows Firewallを無効化。


別サーバーから、Windows Server Insider Preview Build 16257に向け、日本語ファイル名のファイルをコピーします。


Windows Server Insider Preview Build 16257でも、言語が入っていないのでうまく見えないわけです。(これは日本語言語パックが入っていませんから当たり前の挙動)


Windows Subsystem for Linuxでも同様です。

Insider Previewなので、今後も日本語言語パックが出てくるかは不明です。ということで、検証用途だけで使いましょう。

ちなみに、Windows Subsystem for Linuxは、随時起動させていますから、deamonというかWindowsのサービス的な使い方は、現時点で想定されておりません。
Announcing Windows Server Insider Preview Build 16257にも下記の通り記載があります。
At this time, WSL does not support persistent Linux services (such as daemons and jobs) as background tasks.

Windows Server Insider Preview Build 16257のWindows Subsystem for Linuxで、/mnt配下はどこまで?

別稿の準備中に気づいた。

net useで別サーバーのファイル共有をマウント後、ubuntu.exeを起動してWindows Subsystem for Linuxで、/mnt配下を見てみると、Cドライブだけです。

net useでマウントしたもののは、Windows Subsystem for Linuxでは対象に含まれないようですね。
Windows Subsystem for Linuxが動作しているローカルサーバーのローカルディスクだけってこと。

2017年8月11日金曜日

Windows Server Insider Preview Build 16257とWindows Subsystem for Linux

Announcing Windows Server Insider Preview Build 16257をみて、Windows Subsystem for Linuxを入れてみることに。

Announcing Windows Server Insider Preview Build 16257にダウンロードリンクありますので、ISOイメージ、RSATをダウンロードします。

今回は、VMにISOイメージをマウントしてインストールしてみます。
キーボードだけ日本語にして、進めます。


このあたりも特に従来と変わりなし。


プロダクトキーが必要です。Announcing Windows Server Insider Preview Build 16257に記載ありますので、それを使いましょう。今回は、Server Coreのプロダクトキーを使います。



ライセンス条項をチェックします。


アップグレード元はないので、Customを選択して次に進みます。


仮想ハードディスクをインストール先に指定して続行。


インストール中


インストール完了後、再起動。
コマンドプロンプトでアンロックの指示が出ます。


初回のパスワード変更も、コマンドプロンプトで行います。
(Windows Server 2016 Server Coreと大差ないとおもうのですが、どうでしょう?)

パスワードを二回セットするのもGUI同様。(画面キャプチャー忘れました)


無事にサインイン完了。

今回の環境では、DHCPが動いているため、IPアドレス設定は省略しています。
PowerShell等使えますので、必要な場合はそちらで設定すれば良いでしょう。

RSATもダウンロードしていますので、ホストOSのWindows Server 2016に入れてみます。

が、証明書の問題で失敗。別途確認が必要。。。


今回の目的は、Windows Subsystem for Linuxなので、そちらの導入方法を探します。
Windows Server 2016 Installation GuideのEnable the Windows Subsystem for Linuxに詳細な手順がありました。
これに沿って進めていきます。

コマンドプロンプトでPowerShellを起動後、
Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux
を実行します。



Windows Subsystem for Linuxの有効化には、再起動が必要ですね。


再起動後、改めてサインインします。


PowerShellを起動し、Windows Subsystem for Linux用のファイルをダウンロードします。今回は、操作に慣れているということもあり、手順通りのUbuntuとしました。
Invoke-WebRequest -Uri https://aka.ms/wsl-ubuntu-1604 -OutFile ~/Ubuntu.zip -UseBasicParsing



ダウンロード完了。


zipファイルを展開します。


ユーザープロファイル配下にUbuntuに存在します。展開後、~/Ubuntuにcdします。


手順通り、Ubuntu.exeを実行。


Linuxで使うユーザー名を指定。


パスワードは二回設定します。



しばらく待つと完了します。


sudo apt-get update
します。




sudo apt-get upgrade
します。





完了。screenfetchを実行してみるのですが、標準では導入されていません。

sudo apt-get install screenfetch
で導入しましょう。

導入し終えて、screenfetchを実行すると下記の画面になります。


別途、日本語のファイル名がどう取り扱われるのかも確認してみます。
※別サーバーからコピーして確認。

以上。