ソフトウェア」カテゴリーアーカイブ

Windows と Linux の和暦対応

どうも、みむらです。
しばらく記事を書かない間に、新暦が発表され、
そして私も会社が変わってしまいました。
 
最近はアプリ診断員にジョブチェンジしました。
IDA さんが友達です。

特に最近は iOS アプリを見ているので、
フォレンジックネタとか iOS に関するセキュリティ診断ネタであれば、
凄く話に乗れると思います。

それ以外には、Unity のアプリとか (lib2cpp の読み解きとか)
Windows ならユーザランドからカーネルランドまで。お話まってます。


閑話休題。

新暦と言えば、やはり新暦対応でしょう。
私も新暦が発表された直後から「なんとしても対応しよう」と遊んでました。

画像
(from : https://twitter.com/mimura1133/status/1112566297135480838/ )

などなど。
 
今回は、もし「令和じゃない元号にします」と発表があった際に
素早く手持ちの環境を自己責任において対応させられるように
(要出典)
Windows と Linux の対応の仕組みを見ておこう
、とそういうテーマです。

 


Windows 側での対応

Windows の場合はレジストリキーを追加します。

(注:本修正を実施した事によりご利用中のプログラムに不具合が発生しても本サイトは責任を負いかねますと共に、くれぐれもプログラムの製造元へ連絡されませんようお願い致します)

 

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Nls\Calendars\Japanese\Eras 以下に
年号情報が詰まっていますので

REG_SZ 型にて
キー名:”<開始年> <開始月> <開始日>”
値:”<フル読み>_<代表する一文字>_<英語表記>_<英語短縮表記>”

のフォーマットにてキーを生成すれば OK のようです。

 

この値を設定すると、
この値を参照しているプログラムの処理系であれば
基本的に新年号に対応出来るようになります。

画像

 


Linux (glibc) での対応

Linux の場合は locale ファイルを修正します。

(注:本修正を実施した事によりご利用中のプログラムに不具合が発生しても本サイトは責任を負いかねますと共に、くれぐれもプログラムの製造元へ連絡されませんようお願い致します)
 

locales ファイルは下記のパスに保存されています。
(Arch Linux, CentOS 7 にて確認)

/usr/share/i18n/locales/ja_JP

 
修正するのは、”era” の部分。

「○○元年」(+1 で始まるレコード)と「○○年」(+2 で始まるレコード)
を用いて年号の変換を行います。

そして年号は UTF-16BE の順番で書いていきます。

リトルエンディアンでの「令和」のバイト列

できあがった例は次の通り

新しい年号に対応させた ja_JP ファイル.

1つめの “+:1:2019//05//01:2019//12//31:<U4EE4><U548C>:%EC<U5143><U5E74> は
2019年5月1日~2019年12月31日までを「令和(<4EE4><548C>) 元年(<5143><5E74>)」

表記するというもの。

2つめの “+:1:2020//01//01:+*:<U4EE4><U548C>:%EC%Ey<U5E74> は
2020年1月1日以降を「令和(<4EE4><548C>) %Ey(+2)年(<5E74>)」

表記するというものになります。

ですので上記のような ja_JP ファイルを作成し、locale-gen をすると
下記のように新暦に対応することができます。

新暦対応後の図

 


最後に。

Windows や Linux のシステムがかなり柔軟に新暦対応させられる作りになっていることはおわかりいただけたかと思います。
 
ただ、これは一人のソフトウェア作者としてのコメントではありますが
全てのプラットフォームが上記で挙げたような簡単な方法で
すぐ対応出来るようになっているわけではありません。

 
また、上記のようなレジストリキーやファイルを参照するものであっても
(平成)31年から(令和)1年へ変わるわけですので
エラーが発生するシステムも十二分に考えられます。
 
ですので上記の方法で対応ができ、
ご利用のソフトウェアで問題なく稼働した場合でも
これは運が良かったという程度にお考えいただき、
ベンダーの正式対応を基本的にはお待ちいただくようにしてください。
 
上記のリスクにご理解いただけるかたで、新しいものに楽しみを感じるかたは
ぜひ自己責任において新暦対応を一足お先にお試しくださいませ。
なお、それによりデータ破損等が発生しても当方では責任を負いかねます。

・・というわけで。であであー。

Kali Linux で Hyper-V の拡張セッション (Enhanced Session) を有効にする

どうもみむらです。

VirtualBox や VMware だとできるのに、
Hyper-V だと出来ない事。色々とあります。

多分一番大きなところは、共有クリップボードでしょうか。

最近 ESXi に VMware Remote Console でつなぎに行ってもクリップボードが使えなくなりまして
なんとも悲しい思いをしています。

さて。

Hyper-V では Linux で通常セッションは普通使えないのですが、
ふと「拡張セッションは本当に有効に出来ないのかな・・?」と思いやってみました。

結論としてはクリップボードの共有も、画面の高速な描画も出来した。


How to Implement.

1. 普通に Kali Linux をインストールします。
(Install the Kali Linux.)

2. 下記のスクリプトを Root で実行します。
(Execute the script with Root account on Kali Linux.)

bash –c “$(curl –sL https://go.mimumimu.net/2CQlyKy)”

# Do you want to check the code?, please check the page: 
# https://gist.github.com/mimura1133/25451be04929d65993e0fb658d0b6890

3. Kali Linux をシャットダウンします。
(Shutdown the Kali Linux.)

4. 管理者権限の PowerShell で下記のコマンドを実行します
(Execute the PowerShell Script with Administrator Account on Host Windows OS)

Set-VM –VMName <YOUR_VM_NAME> -EnhancedSessionTransportType HvSocket

5. Kali Linux を起動します。
(Start the Kali Linux VM.)

正常にインストールが完了していれば、
5番で起動した際に、下記のように「拡張セッション」で接続しなおすように聞いてきます。

( When open the VM window, it will ask you an window-size settings if you’re finished the installation successfully. )

image

で、これって何をやっているの?

元ネタはこれ。
( Sneak Peek: Taking a Spin with Enhanced Linux VMs – Virtualization Blog )

https://blogs.technet.microsoft.com/virtualization/2018/02/28/sneak-peek-taking-a-spin-with-enhanced-linux-vms/

下図が凄く分かりやすいのですが、
Hyper-V の 拡張セッションモードは内部的に “RDP” を利用して機能が実現されています。

早い話がリモートデスクトップのあれです。

Windows Server 2012 R2では、キーボードなどのドライバの代わりにリモートデスクトップサービスに変更される


(Src : https://channel9.msdn.com/Events/TechEd/NorthAmerica/2013/MDC-B330#fbid=M3oY0SjYJi2 )

今回のスクリプトを確認頂くとわかるのですが、
XRDP を用いて、VMCI (hv_sock) 経由で RDP 接続を受け付けることで
今回の「拡張セッションモード」を実現する、という構図です。

Ref : https://gist.github.com/mimura1133/25451be04929d65993e0fb658d0b6890


他の Linux 用のサポートはないの?

あります。

Microsoft のリポジトリで Arch Linux 用と Ubuntu 用が提供されています。
https://github.com/Microsoft/linux-vm-tools

Redhat 系列の場合は、xrdp パッケージが vsock オプションが使えるようにビルドされていませんので、
SRPM を取ってきてコンパイルオプションを設定してコンパイルしなおせば動きます。


というわけで、私自身の作業環境がこれでぐぐっと作業しやすくなりました。
であであー。

Hyper-V Server をブラウザから制御出来るようにする

どうもみむらです。

“Project Honolulu” というものが Microsoft さんから発表されたのも数ヶ月前
気がついたら “Windows Admin Center” という名前になっていましたので
少し試してみました。


Windows Admin Center とは?

ブラウザベースのサーバ管理ツールです。

2018-07-16 (3)

こんな感じで、サーバをごにょごにょとブラウザから管理することができます。

ツール類はかなりまとまっていて、
単純に “Server Manager” が ブラウザベースになったとかそういう感じではなさそうで、
使いやすい印象を受けました。

公式ドキュメントは次の URL にあります:
https://docs.microsoft.com/ja-jp/windows-server/manage/windows-admin-center/overview

ダウンロードは下記リンクから:
https://docs.microsoft.com/en-us/windows-server/manage/windows-admin-center/understand/windows-admin-center


Hyper-V Server + Windows Admin Center 環境を作ってみる

今回は執筆時点 (2018/07/16) で最新である
Windows Insider Preview Server Hypercore Build 17709  と
Windows Admin Center Preview 1806 を組み合わせて構築してみます。

Step 0. (Hyper-V 上で検証環境を構築したい人用の事前準備)

PowerShell にて下記のようにコマンドを叩き、 Nested VM を有効にしておきます。

Set-VMProcessor –VMName <VMName> –ExposeVirtualizationExtensions $true

Step 1. Hyper-V Server をインストール

通常通りインストールを進めます。

途中、下記のような表示が出たときは “I don’t have a product key” を選択して進めます。

image

Step 2. Administrator のパスワード設定

Insider 版ですと、初回ログイン時にパスワード設定に遷移しないようですので、
下記のコマンドを打って Administrator のパスワードを設定します。

net user Administrator *

Step 3. Windows Admin Center のインストール

Windows Admin Center のインストールを実行します。

インストーラのファイルは USB メモリか共有フォルダを作成して転送すると良いでしょう。

共有フォルダを作成して共有設定する例:

mkdir c:\SHARE
net share SHARE=C:\SHARE /GRANT:Everyone,FULL

セットアップ途中、下記のようなダイアログが表示されますので
必要に応じて適宜設定を変更します。

image

Step 4. Windows Admin Center に接続する

適当なブラウザから、先ほどセットアップした環境に接続します。

特に何も無ければ下記のような画面が表示されます。

image

サーバをクリックすると、下記のようにログイン情報を聞かれますので、
先ほど設定した Administrator アカウントを設定します。

image

image

また、もしこのとき、ブラウザからユーザ名とパスワードを聞かれた場合は
”Administrator” と設定したパスワードを入力して進めます。

上手く接続が完了すると、下記のように設定画面が表示されます。

image

あとは自由に VM を立てたり設定を変更したりしましょう!


私の環境でもついこの前から Server マネージャによる管理 (RSAT) ではなく
Windows Admin Center に切り替えて使っています。

まだ一部手が届かない所はあるものの、概ね使い勝手は良く、
今後の更新もかなり期待できるのではないかと期待しています。

利用者はまだ少ない印象を受けますが、
ブラウザで管理出来るという点や、ワークグループ環境でも設定変更をせずに動いてくれるところ
(ex. TrustedHosts の設定を変えたり、ネットワークを Private に変更したり etc..) があったりと
便利ですので、平行して導入を検討してみても良いのかも知れません。

Windows 10 の更新が 45% 付近で中断されてしまう時の確認事項。

お疲れ様です。みむらです。

Windows 10 RS2 がリリースされました。皆さんはお使いでしょうか。
私はそのあとの Insider Preview で RS3 のブランチに移行しております。。

今回はそんなときに遭遇した Windows のビルド更新がうまくいかない人向けの話です。
RS1 (Anniversary Update) から RS2 (Creators Update) のアップデートでも嵌る可能性があります。


ところで、冒頭でも書いたような
仕事のメールを書くと必ず先頭に書く「お疲れ様です」というメッセージ。
あのプロトコルはどこから来ているんでしょうか。

英語のメールではあんまり見たことないけれど、
英語の “GoodDay!!” と書くあれに該当するのでしょうか。

それならカットできそうなそんな気がする。

かといって「業務最適化だ!」と言ってそういうところから削除し始めて、
削除に熱中になりすぎると、必要なことまで削ってしまい不安定になる。

昔の Windows 向けのレジストリクリーナーの結果と同じように、
消していいもの悪いものってのはある気がしますが、
どうしてそれがあって、それがどういう効果を生んでいるというのは考えてみると楽しそうです。


冗談はここまでにしておいて。


事象

Windows 10 のアップグレード / アップデートが45% ぐらいまで進んだあたりで勝手に再起動がかかり、「以前の Windows を復元しています…」というようなメッセージと共にアップデート前に戻るため完了できない。

またログ中には次のようなログが残ります。

MigApply caught exception: Win32Exception: Can't switch to requested user context: USER00000001.: 
システムに接続されたデバイスが機能していません。 [0x0000001F] int __cdecl Mig::CKnowledgeManager::Apply
(class Mig::CPlatform *,class Mig::CPlatform *,class Mig::CPlatform *,
class Mig::CUserMappingList *,class UnBCL::Hashtable *,
class Mig::CAgentManager *,struct IMigExecuteProgress *)[gle=0x00000003]

特に 自作ユーザでシステムはSSD, ユーザファイルはHDD (別ドライブ) というような
使い方をされている場合
、今回の事象を踏み抜く可能性が考えられます。

回避方法

下記の値をアップデート前にデフォルト値に戻す。
KEY : HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList
NAME : ProfilesDirectory
DEFAULT-VALUE : %SystemDrive%\Users

戻したのちに再度アップデートを試みるとうまくいくかと思います・・!

回避方法による副作用

新規ユーザ作成時に C:\Users 以下にファイルが作成されるようになります。
もちろん、アップグレード後に再度変更すれば問題ありません。

また既存ユーザは “ProfileImagePath” にて格納先が別途指定されているため
パスが変わることはありません。


取り急ぎー。なんとなく自作ユーザだとはまる人が多そう・・。
であであ!

“Zsh” on “Arch Linux” on “Windows 10”

どうもみむらです。

最近、Windows 10 の RS1 から “Windows Subsystem for Linux” という機能が乗りました。

早い話が Linux アプリケーションを Windows 10 上で動かせるようになりました、
というような機能でして、 “Bash on Ubuntu on Windows” とも呼ばれたりします。

ただ、私は “Bash” 派ではなく “Zsh” 派だったりして、
また “Ubuntu” 派でもなく “Arch Linux” 派だったりしますので、
ちょいとこの機能を使って、表題のようなことをしてみようかと。


余談ですが・・:

どういう風に Bash on Ubuntu on Windows が実現されているかと言うことですが、
ざっくり書くと Linux 環境で Windows アプリケーションを動かす “WineHQ” の逆操作のような
そんな感じです。

Wine が Windows API 呼出 → Linux システムコール として、動かせるようにしているように、
WSL ではその逆で Linux のシステムコール → Windows API 呼出 に変換して動かすような。

詳しいことはこの記事では触れませんが、
気になる方は Microsoft 社のブログ “Windows Subsystem for Linux Overview” をご参照ください
https://blogs.msdn.microsoft.com/wsl/2016/04/22/windows-subsystem-for-linux-overview/

日本語ですと ASCII さんの “Windows Subsystem for Linux の中身を詳しく見る” がわかりやすいかと思います。
http://ascii.jp/elem/000/001/246/1246548/

 

また Windows は可能であれば Insider Build  (Fast) の方が対応しているシステムコールが多く
色々と楽しめるかと思います。

このあたりが気になる方は、リリースノートが公開されていますのでご確認ください。
https://msdn.microsoft.com/ja-jp/commandline/wsl/release_notes


Zsh on Arch Linux on Windows のつくりかた:

1. Windows 10 RS1 もしくは Insider Preview の環境を用意する。

(Windows のインストールの仕方は割愛します・・。)

Insider 版のビルドをダウンロードするには:

設定画面を開き「更新とセキュリティ」をクリック。

image

 

左ペインから「Windows Insider Program」を選択し、右ペインの「ファースト」を選択。
(初めての場合は「Insider Preview ビルドの開始」というボタンがあると思いますので、そちらをクリックします)

image

 

あとは Windows Update を実行することで、
運が良ければ直ぐ、悪ければ1日後に降ってくるようになります。
(Insider Preview ビルドを受け取れるようにするためにちょっと時間が掛かるそうです。)

 

 


2.開発者モードを有効にする

左ペインから「開発者向け」を選択し、右ペインの「開発者モード」を選択します。

image

 

 


3. Windows Subsystem for Linux (Beta) を有効化する

3.1. Windows キー + R  で「ファイル名を指定して実行」を表示し、
“appwiz.cpl” と入力して OK を押します。

image

 

3.2. 開いた画面の左側にある「Windows の機能の有効化または無効化」をクリック。

image

 

3.3. 「Windows Subsystem for Linux (Beta)」にチェックを入れて “OK” をクリック。
image

 

 


4. WSL 環境に “Arch Linux” を導入する。

こちらのサイトで公開されているスクリプトを実行して、インストールを行います。
https://github.com/alwsl/alwsl

 

4.1. 適当なフォルダに “alwsl.bat” をダウンロード。
image

 

4.2. コマンドプロンプトを立ち上げる。

何もないところで “SHIFT キー” を押しながら右クリックすると、
「コマンドプロンプトをここに開く」もしくは 「Power Shell ウインドウをここに開く」
というメニューが現れますので、こちらを利用すると楽かと思います。

image

 

4.3. インストール
( “alwsl.bat install” と入力することで、セットアップが実行されます)

image

 

4.4. “bash” と打って実行。

image

そのまま “root” の Arch Linux 環境に入ります。

 


5. 一般ユーザの設定

さすがに Root で使い続けるのはあまり気分が良くないので、
一般ユーザを作成して、最初はそのユーザになるようにします。

5.1. Root のパスワードを設定する。
→ そのまま passwd と入力して再設定を行ってください。

 

5.2. ユーザを作る
※bash コマンドで Linux 環境に入っていない方は ”bash” と入力して Linux 環境に入ってください。

5.2.1. useradd コマンドでユーザを作成します。
ex) useradd mimura1133

5.2.2. passwd コマンドでパスワードを設定します。
ex)  passwd mimura1133 → パスワードを求められるので入力、設定.

5.2.3 ホームディレクトリを Windows と同一にする。
→ “/mnt” 以下に Windows のドライブ名が並んでいますので
シンボリックリンクを張って、同一にしてしまいます。
ex)   ln –s /mnt/c/Users/mimura1133 /home/mimura1133

…纏めるとこんな感じのコマンドを入力していきます:

root@Satoshi:/mnt/e/temp# passwd
New password:
Retype new password:
passwd: password updated successfully

root@Satoshi:/mnt/e/temp# useradd mimura1133

root@Satoshi:/mnt/e/temp# passwd mimura1133
New password:
Retype new password:
passwd: password updated successfully

root@Satoshi:/mnt/e/temp# ln -s /mnt/c/Users/mimura1133 /home/mimura1133

root@Satoshi:/mnt/e/temp# ls -al /home/mimura1133
lrwxrwxrwx 1 root root 24 Mar  9 18:46 /home/mimura1133 -> /mnt/c/Users/mimura1133/

 

5.3. 起動時のユーザを設定

5.3.1. 一度 “exit” と入力して Linux 環境を抜けます

5.3.2. lxrun /setdefaultuser <5.2 で作ったユーザ名>  と入力。

image

 

5.4. 変わったことを確認。

そのまま “bash” と入力して、Linux 環境に入り、
ちゃんと一般ユーザでログインされていることを確認します。

 


6. Zsh の導入。

6.1. Zsh をインストール。
→ root に昇格後  “pacman –S zsh”

※もし失敗する場合は一度 “pacman –Syu” と入力して全体をアップデートしてみてください。

image

 

6.2. bash コマンドで Linux 環境に入っても “zsh” が立ち上がるように細工する。

私の場合は .bashrc に次のように書き込んでおきました:

/bin/zsh
exit 0;

とりあえずこれで、bash コマンドで起動しても zsh が起動し、
zsh の終了と共に Windows 環境に戻ってくるような感じになります。

 


最後に。

image

インストールするとこのような感じでスタートメニュー内に “archlinux” が追加されます。

またここから起動された端末は文字コードが “UTF-8” となっていますので、
何かと便利かな・・と・・!

image

 

また、Windows のコマンドプロンプト・端末周りも Windows 10 になってかなり良くなりまして

image

AA の nyancat もちゃんと表示される良い子になりました。

 

元から Windows, Arch Linux が大好きな人も、そうじゃない人も
もしよろしければお試し下さいー。