AppImage版のPowerShellが提供されました

PowerShell on Linuxの話です。

先日リリースされた PowerShell 6.0.0.Alpha17 からAppImageの実行バイナリが提供されました。

AppImageについて

公式サイトは以下。

appimage.org

かつてklikやPortableLinuxAppsと呼ばれていたプロジェクトで、ディストリビューションを問わずに実行可能な単一のバイナリファイル(*.AppImage)でアプリケーションを提供するための仕組みだそうです。

このツールで作られた*.AppImageなバイナリファイルはダウンロードしてファイルに実行権限を付けるだけでアプリケーションが利用可能になります。

正直まだよくわかっていないのですが、仕組みを調べてみた結果、AppImageではアプリケーションの実行バイナリと依存モジュール一式を一つの*.AppImageなファイルにまとめ、この*.AppImageなファイルの実行時にFUSEを使って仮想ファイルシステムに依存パッケージごと展開して(サンドボックス的な環境を作ってるっぽい？)実行バイナリを起動している様です。

このためディストリビューションを選ばないと言うものの、実行環境にFUSEがインストールされている必要があります。

インストール方法

公式な手順はこちら。

今回は例としてCentOS 7.3での方法を紹介します。
他のディストリビューションでも基本的な流れは変わらないはずです。

1. FUSEのインストール

先ほど述べた通りAppImageのバイナリを実行するためにはFUSEがインストールされている必要があります。

今回の検証環境にFUSEはインストールされていなかったのでYum(EPELリポジトリ)からインストールします。

FUSEが利用可能な環境ではこの手順は不要です。

# bash
# FUSEのインストール
sudo yum install -y epel-release
sudo yum install -y --enablerepo=epel fuse-sshfs

2. AppImageのインストールと実行

FUSEをインストールした後はAppImageのバイナリ(PowerShell-x86_64.AppImage)をダウンロードして実行権限をつけるだけでOKです。

# bash
# バイナリのダウンロードと実行権限の付与
curl -OL https://github.com/PowerShell/PowerShell/releases/download/v6.0.0-alpha.17/PowerShell-x86_64.AppImage
chmod a+x ./PowerShell-x86_64.AppImage

# 実行
./PowerShell-x86_64.AppImage

実行した結果は以下の様になり、PowerShellの起動前に/tmp/に対して仮想ファイルシステムの展開がなされているのがわかります。

あとは普通にPowerShellを利用することができます。

注意点

あまり影響はないと思いますが1点だけ気を付けておいた方がよさそうな点があります。

AppImageの仕組み上、実際の実行ファイル(powershell)は/tmp/.mount_[ランダム文字列]/usr/binに展開されます。
このためPowerShellを実行するたびに$PSHOMEのディレクトリが変わります。

試してはいませんが都度$PSHOMEが変わってしまう以上PSRemotingのサーバー側になることはできないでしょう。
PowerShellのクライアント側の機能しか使えないと思われます。

また、/tmp/.mount_[ランダム文字列]配下はReadOnlyになります。
このため$PSHOMEにファイルを置くことができずAllUsers*なプロファイルを作ることができません。

最後に

若干制限はありますが、環境によっては一番気軽にPowerShellを実行できる方法かもしれません。

個人的にはテスト用の一時的な環境を作るのに向ていると感じています。

PowerShell on Linuxに普通にPSRemotingしてみる - その3

その1とその2の続き的な。

以前のエントリで書いた、

github.com

のIssueがクローズされ、OMIおよびPowerShell on Linux OMI Providerがpackages.microsoft.comリポジトリからインストール可能になったので試してみました。

インストール

私が使い慣れているCentOS 7.3で検証します。

はじめにpackages.microsoft.comリポジトリの追加とPowerShellのインストールをしておきます。

# CentOS 7, Bash
curl https://packages.microsoft.com/config/rhel/7/prod.repo | sudo tee /etc/yum.repos.d/microsoft.repo
sudo yum install -y powershell

こちらは以前のエントリで書いた通りですのでとくに問題はないでしょう。

続けてPowerShell on Linux OMI Providerをインストールします。

パッケージ名はomi-psrp-serverで、依存パッケージにOMI(omi)が登録されているので、こちらをインストールすればOMIも同時にインストールされます。
ですので以下の様にyum install一回でインストールできます。

# CentOS 7, Bash
sudo yum install -y omi-psrp-server

実行結果は以下の様な感じになります。

インストールが完了したあとはOMIDが動いてればOKです。

OMIDが起動しているかはservice(またはsystemctl status)コマンドで確認してください。

# OMIDが動作しているのを確認
service omid status
# または
# systemctl status omid.service

ちなみに、現時点の各パッケージのバージョンは、

• PowerShell - Ver.6.0.0.alpha16
• PowerShell on Linux OMI Provider - Ver.1.1.0-alpha18 (1.0.0.18)
• OMI - Ver.1.2.0

となっています。

接続確認

例によってWindows Server 2012 R2(PowerShell 5.1)から接続確認をしてみます。
接続先のIPは192.168.33.209、ユーザーはvagrantおよびrootで試しています。

# Enter-PSSessionで接続
$o = New-PSSessionOption -SkipCACheck -SkipRevocationCheck -SkipCNCheck
Enter-PSSession -ComputerName 192.168.33.209 -Credential vagrant -Authentication basic -UseSSL -SessionOption $o

普通に使えますが、切断時に謎なエラーが出ました...

とりあえずこいつは気にしないことにして、CIM情報の取得をします。

# Get-CimInstanceで情報取得
# こっちは要root
$o = New-CimSessionOption -SkipCACheck -SkipRevocationCheck -SkipCNCheck -UseSsl
$s = New-CimSession -ComputerName 192.168.33.209 -Credential root -Authentication Basic -SessionOption $o
Get-CimInstance -CimSession $s -Namespace root/omi -ClassName OMI_Identify

こちらもこれまで試した結果と同じです。

最後に

とりあえずこんな感じです。

各パッケージのインストールがかなり楽になったのであとは動作が安定してくれれば使い物になるのかな、と思います。

AdmxPolicyというPowerShellモジュールを公開しました

ちょっとしたきっかけから、AdmxPolicyというADMXファイルの中身を解析して各グループポリシーが使用するレジストリキーの値を取得するPowerShellモジュールを作ってみました。

ソースと基本的な使い方はGitHubに上げています。

github.com

またPowerShell Galleryでも公開しており以下のコマンドでインストール可能です。

www.powershellgallery.com

Install-Module -Name AdmxPolicy -Scope CurrentUser

なお動作環境はPowerShell 2.0以上です。
PowerShell 2.0の環境ではReleaseにあるZipファイルを解凍してAdmxPolicyフォルダをImport-Moduleしてください。

モジュールを作るきっかけ

このモジュールを作ろうと思ったきっかけはteratailのこの質問になります。

teratail.com

この質問で参考にして頂いているエントリに以下の様に書きましたが、各グループポリシーが取るレジストリ値を調べるのは容易ではありません。

そして各ポリシーがどの様なレジストリ値を取るのかについては、
* Group Policy Registry Reference や、
* Group Policy Settings Reference for Windows and Windows Server からダウンロードできるExcelファイルを参照することである程度わかります。
(2014/12/12追記：上記の他にポリシーのadm/admxファイルをテキストエディタ等で直接参照することでもレジストリ値の情報を知ることができます。)

そこでADMXファイルを解析するツールを作れば少しは楽ができるかなと思い作ってみました。

作った結果

現時点でこのモジュールは個々のADMXファイルを解析して各ポリシーが取りうるレジストのキーとその値を取得することができます。

ただし、各ポリシーが取りうる値は非常に多岐にわたり、このモジュールがあればグループポリシーの設定をすべて自動化できるという訳にはいきませんでした。
また、ADMXファイルに記載されているレジストリの設定情報はグループポリシーエディタのUIと非常に強く結びついており、一見しただけでは何の設定値か判別しにくい(グループポリシーエディタのUI上でみてはじめて意味が通る)ものも結構あります。

そのためコレはあくまでも補助ツールとして使うのが良いかなと思っています。

きっかけとなる問題に対して完璧なソリューションにはなりませんでしたが、それでも何もないよりはマシかなといったところです。

使用例

使用例として、実際のグループポリシーの設定とこのモジュールの結果を突き合わせてみます。

0. 試験環境について

適当なドメインcontoso.localに設定したポリシーTextPolicyを例にします。
このTestPolicyではコマンド プロンプトにアクセスできないようにするポリシーを有効に設定しておきます。

1. ポリシーの検索

まずはコマンド プロンプトにアクセスできないようにするポリシーを検索する必要があります。

ADMXファイルがインストールされているディレクトリ(ここではセントラルストア)のADMXファイルを対象に以下の様にポリシーを検索します。

$admxPath = "C:\Windows\SYSVOL\domain\Policies\PolicyDefinitions\*.admx"
ls $admxPath | Get-AdmxPolicies | ? { $_.DisplayName -like "*コマンド プロンプト*" }

ちょっと時間がかかりますが、結果はこんな感じになり、Shell-CommandPrompt-RegEditTools.admxにあるDisableCMDというポリシーであることがわかります。

2. ポリシーの取得

該当のポリシーがわかったのでポリシー情報を取得してみます。

$admxPath = "C:\Windows\SYSVOL\domain\Policies\PolicyDefinitions\Shell-CommandPrompt-RegEditTools.admx"
$policy = Get-AdmxPolicies -FilePath $admxPath | ? { $_.Name -eq "DisableCMD" }

取得した結果はこんな感じになります。

この結果のRegistryType、RegistryRootKeys、RegistryPathプロパティからレジストリのキー情報を取得することができます。

$policy.RegistryType     # マシンポリシー、ユーザーポリシー、その両方かの種別
$policy.RegistryRootKeys # RegistryTypeに応じたルートキー
$policy.RegistryPath     # レジストリのサブキー

結果、このポリシーはHKEY_CURRENT_USER\Software\Policies\Microsoft\Windows\Systemキーを使うことがわかります。

次に、レジストリ値についてはValueInfoプロパティから取得可能です。

$policy.ValueInfo # レジストリ値情報

ここからが厄介なところで、ADMXファイルで定義されるレジストリ値は大きく3パターンに分類されます。

1. 単純なEnabled/Disabled値
   • RegistryValueName、EnabledValue、DisabledValue
2. Enabled/Disabledのリストを取るEnabledList/DisabledList
   • HasEnabledList、EnabledList、HasDisabledList、DisabledList
3. グループポリシーエディタのUIと紐づく値となるElement値
   • HasElements、Elements

今回のポリシーは3.のElement値だけをもっています。*1

ですので、このElementにアクセスしてみると以下の様な情報を得ることができます。

この結果はElementの中の列挙体であるEnumElementで、レジストリ値がDisableCMD、取りうる値が1または2であることを示しています。

Keyのはい、いいえについてはグループポリシーエディタのコンボボックスに表示される名称になり、こういったところがぱっと見でわからない感じになっています…

ちなみに、ElementはEnumElementを含めて

• BooleanElement
• DecimalElement
• LongDecimalElement
• TextElement
• MultiTextElement
• EnumElement
• ListElement

の7種類存在します。
これらの詳細はADMX Policy Definition Schemaに定義されています。

本エントリでは個々の詳細まで触れませんが、実際に見ればそれなりに予測はつくかと思います。

これで情報は全て集まり、

• キー : HKEY_CURRENT_USER\Software\Policies\Microsoft\Windows\System
• 値 : DisableCMD
• 設定値 : 1または2

であることがわかりました。

3. 実際のポリシーと付け合わせる

前項の結果が正しければGet-GPRegistryValueコマンドで値を取得できるはずです。
実際に確認してみます。

Get-GPRegistryValue -Name TestPolicy -Key HKEY_CURRENT_USER\Software\Policies\Microsoft\Windows\System

結果は以下の様になりAdmxPolicyモジュールで得た情報と合っていることがわかります。

補足 : POLファイルを解析する

AdmxPolicyモジュールではテンプレートであるADMXファイルの情報からレジストリ値を探しましたが、補足として、実際のポリシー定義の情報であるPOLファイルからレジストリ情報を取得する方法について説明します。

GPRegistryPolicyParser

PowerShell Teamが公式にグループポリシーのPOLファイルを解析するモジュールGPRegistryPolicyParserを提供しているのでこれを使います。

github.com

このモジュールは、もともと、Nano Serverに対してグループポリシーを適用する・情報を取得することを目的としている様でPowerShell 5.0以上でないと動作しませんので注意してください。

POLファイルはSYSVOLなどから直接取得しても構いませんが、安全のためにBackup-GPOコマンドでとったバックアップから抜くなどした方が良いでしょう。

本エントリではその辺の手順は端折りますが、取得したPOLファイルに対して以下のコマンドを実行するとPOLファイルの中身を見ることができます。

Parse-PolFile -Path [POLファイルのパス]

実行例)

テスト用のポリシーを自由に作れる環境であればこちらを使う方が楽ができるでしょう。

最後に

とりあえずこんな感じです。

グループポリシーで使うレジストリ値の取得は一筋縄ではいきませんが、AdmxPolicy、GPRegistryPolicyParserといったツールを使うことで多少は楽ができるかと思います。

*1:なお、これらのパターンはどれか一つというわけではなく組み合わせで設定されます…