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

PrimoCache を使って Intel の最新チップセットでも HDD を SSD を使って高速化する

どうもみむらです。
先日 PC が故障しまして第9世代の Intel CPU (i7-9700) を用いて組み直していました。

故障する数日前からビープ音(長音)の連続で起動に失敗したりしていたので
なんか気持ち悪いなとは思っていたのですが。。

テレワークが推奨されており、お仕事に甚大な影響が出ることもありましたので
ツクモ電機さんのレジの横にあるリーダーにクレジットカードをシャコシャコッと何度も差し入れしてきました。。来月の引き落としに今から震えています。

写真の説明はありません。
図1 : 故障する直前 RAID-5 構成の HDD が全て認識出来なくなる

ただ今回買い換えを行ってみて
Intel Smart Response Technology (iSRT, HDD を SSD キャッシュで高速化するやつ) が
Intel Optane Memory との組み合わせ専用かつ、RAID 不可に変更
されており
iSRT を使って RAID-5 を高速化していた身としてはかなりショックでした。。

写真の説明はありません。
図2: Intel OPTANE Memory の実物。この数時間後 RAID に対して使えないことを知る。

では iSRT の代替としていいものは無いのかと探していたところ
PrimoCacheという良さそうなものを見つけたので試してみました。


PrimoCacheとは

HDD を SSD でキャッシュして高速化するソフトです。
まさしく Intel の Smart Response Technology で実現していたものを実現してくれます。

ほかにも FuzeDrive (AMD 環境では StoreMI という名前で提供されています) というソフトなどもありますが、いくつか試してみたところ PrimoCache がよさそうな感じでした。

PrimoCache は Romex Software 社の製品で、1つ当たり $29.95 の製品になっています。
https://www.romexsoftware.com/en-us/primo-cache/

なお私自身はメーカーさんから
今回の記事に関して何か支援を受けてはいませんのであしからず。。

PrimoCache の設定をする

左上のボタンを押してドライブを追加します。

図3 : ドライブの追加ボタン

次の画面で「高速化したいドライブ」を選択します。

図4: 高速化したいドライブを設定。今回は Intel RAID 1 ドライブ。

次にキャッシュの方法についての設定です。
Level-1 Cache が “DRAM 上” のキャッシュ、 Level-2 Cache がストレージとなります。

またキャッシュについては文字通り Level1, Level2 の階層構造になっています。

今回の場合は SSD キャッシュのみを有効にするため、
Level-1 Cache は 0MB に設定します。

図5: Level-1 Cache を 0MBに設定する

次に Level-2 Cache を設定するために、画面中央の小さなボタンを押下します。

図6: Level-2 Cache の設定ボタン

ボタンを押下すると次のような画面が表示され
キャッシュ用のドライブを選択する画面になります。

今回は Intel Optane Memory を使うため
INTEL MEMPEK.. で始まるドライブを選択します。

注:もちろん Intel Optane Memory を使わずに通常の SSD でも利用可能です。
注2:認識されている容量が小さい場合は何らかのパーティションを作ってから再試行してみてください。

図7: キャッシュ用ドライブを設定している図¥

設定後、 “Size” を “MAX” に変更し、その横にあるボタンを押下します。

図8: キャッシュ設定を行う

特に何もなければ
“Individual Read/Write Cache Space” のチェックを無効にします。

これが ON の時はそれぞれのキャッシュが設定した割合で行われますが
無効の場合は割合を気にせずに Read / Write キャッシュを行うようになります。

図9: Read/Write Cache の割振設定を無効にする。

最後にお好みで Defer-Write (遅延書き込み) の設定を行います。

遅延書き込みを有効にすると応答速度が速くなりますが、
ディスクへの書き込み(キャッシュ内容の反映)が遅くなります。

図10: 設定がほぼ完了した図

設定が完了したら “Start” を押下します。

画面UI について

稼働を始めると下記のようにキャッシュ率などが表示されます。

図11: 稼働が開始した画面

ある程度動きはじめたら、画面を閉じて仕事に戻りましょう。


冒頭のとおり PC の故障で買い替えたところ
Intel RAID 構成に対する SSD キャッシュが使えなくなって呆然としていたところ
こういうソフトを見つけることができてよかったです。。!

また前回の構成では Intel RAID の RAID-5 だったのですが
iSRT が有効な環境だと最新のマザーボードや mdadm ではマウントできず焦りましたが
dmraid を使うことでマウントができました。

PrimoCache の場合は Intel RAID と SSD Cache が別の機構なため
同じようにマウントできなくなることは(きっと)ないと思いますし安心です・・!

ではでは、素敵なテレワークライフを!

Ubuntu 19.10 で Hyper-V の Enhanced Mode を有効にする (Enable the Enhanced Mode with Ubuntu 19.10)

どうもみむらです。

Ubuntu を Hyper-V で使用していると、
起動時に高確率で GUI 起動待ちになって何も操作できなくなったり
( Ctrl + Alt + Function Key での切り替えしてもログイン画面が出てこない )
そもそも Enhanced Mode が使えなくて色々と不便でしたので、
有効にするスクリプトを作成しました。


Hi I’m Mimura.

I make a script to enable the “Enhanced Mode” on Hyper-V with “Ubuntu 19.10”.
Also, it fix an issue that to fail to start X.


Script:

下記からダウンロードできます。 / you can download from this link:
https://gist.github.com/mimura1133/a6aebf4945b6688d1a5aedffdfa9368c


How does it works / どういう仕組みか:

このスクリプトは、
Microsoft が提供している Enhanced Mode を有効にするスクリプトを元に
作成されています。

https://github.com/microsoft/linux-vm-tools/tree/master/ubuntu/18.04

最近の Ubuntu では Wayland を最初に使用しようと試みます。

上記のスクリプトでは、 Xorg を使うようにできているため、
Wayland を利用しないようにする処理を追加し、
Enhanced Mode を Xorg 経由で使えるようにしました。

# Stop to use wayland.
sed -i_orig -e 's/#WaylandEnable=false/WaylandEnable=false/g' /etc/gdm3/custom.conf

また、どうやら Ubuntu に入っている Wayland と Hyper-V が相性が悪いらしく
時々起動に失敗する(コンソール経由のログインも受け付けない状態になる)のですが
Wayland を無効にすることで、確実に起動できるようにもなります。

(Arch Linux に入れたときには上手く動いていたので、 Ubuntu の問題だと個人的には思ってます..)


this script based on Microsoft’s.
https://github.com/microsoft/linux-vm-tools/tree/master/ubuntu/18.04

Recent versions of ubuntu are try to use a Wayland before using Xorg.
So, I added a code to disable to use Wayland.

# Stop to use wayland.
sed -i_orig -e 's/#WaylandEnable=false/WaylandEnable=false/g' /etc/gdm3/custom.conf

In addition, the Wayland and Hyper-V seem to be incompatible, sometimes fail to boot,
but the issue is fixed at the same time by disabling wayland.


Ubuntu の最新版が Enhanced Mode でサクサク動いて、コピペも出来るようになりますし、
同じように Kal Linux でも Enhanced Mode が使えるようにするものも公開していますので
Linux を Hyper-V で使っている方は、是非お試しくださいませー。

I have also released another versions for Kali Linux.
Please feel free to use the script if you’re using Linux on Hyper-V.

Git Repository (Forked from Microsoft):
https://github.com/mimura1133/linux-vm-tools

Fiddler の Inspector プラグインを作ろう

どうもみむらです。

お仕事の関係上、アプリケーションの通信を見ることがありまして。
一般には “Burp” を使うことが多いのですが、
やっぱりサクッと見たいときには Fiddler 先生を使いたくなることがあります。[要出典]

Burp のプラグインを作る話はよくあるのですが Fiddler の話はあまりないのと、
作ってみたらサクッと出来たので記事に纏めてみようかと。


1.プロジェクトを作る

下記のようにまず、 “.NET Framework” の クラスライブラリを作成します。

Fiddler は .NET Framework の 4.6.1 を使用していますので、
バージョンは 4系を選択します。 (4.6.1 か それ以降を選択しておけば OK です)


2.Fiddler を参照に加える

Fiddler.exe を参照に加えます。

通常下記のパスに Fiddler がありますので、こちらを追加します。
%LOCALAPPDATA%\Programs\Fiddler\Fiddler.exe

また、Fiddler の Inspector プラグインはUI に Windows Forms を使用しますので System.Windows.Forms も忘れずに参照に加えます。


3.デバッグの設定をする

プラグインの開発時に F5 でデバッグ出来た方が良いですよね。

プロジェクトの設定の「デバッグ」から
Fiddler.exe (%LOCALAPPDATA%\Programs\Fiddler\Fiddler.exe) を
デバッグプログラムとして指定します。

同様に「ビルド」から、出力先のパスを
お使いのユーザのドキュメントフォルダの “Fiddler2\Inspectors” に出力するようにします。
(%USERPROFILE%\Documents\Fiddler2\Inspectors を展開したパスに保存すれば OK です)


4.Request 側と Response 側のビューのひな形を作る

それでは本題となるビューを作ってみましょう

ビューを作る際は下記のように、レスポンス用とリクエスト用を2つ定義する必要があります。

リクエスト用のビュー

基本的に Inspector2, IRequestInspector2 を継承して作ります。
上記の画像に当該するコードは下記の通りです

using Fiddler;
using System.Windows.Forms;

public class RequestView : Inspector2, IRequestInspector2
{
    /// <summary>
    /// Inspector ビューへの項目の追加やウィンドウの初期化等を行う
    /// </summary>
    /// <param name="o"></param>
    public override void AddToTab(TabPage o)
    {
        o.Text = "さんぷる!";
        o.Controls.Add(new TextBox() {Text = "リクエストヘッダ用!", Dock = DockStyle.Fill, Multiline = true, ReadOnly = true});
    }

    /// <summary>
    /// 項目が必要なくなった場合のクリーンアップ処理を書く (IDisposable の Dispose みたいな)
    /// </summary>
    public void Clear()
    {

    }

    /// <summary>
    /// POST リクエストとして送信されたメッセージ本文
    /// </summary>
    public byte[] body { get; set; }

    /// <summary>
    /// テキストが編集されたかどうかを返す
    /// </summary>
    public bool bDirty { get; }

    /// <summary>
    /// 読み取り専用項目かを取得・設定する
    /// </summary>
    public bool bReadOnly { get; set; }

    /// <summary>
    /// HTTP のリクエストヘッダ
    /// </summary>
    public HTTPRequestHeaders headers { get; set; }

    /// <summary>
    /// Inspector ビュー内の項目の順番(昇順でソートされるため、値が大きければ項目の最後に追加される)
    /// </summary>
    /// <returns>表示順番</returns>
    public override int GetOrder() => 1000;
}

レスポンス用のビュー

レスポンス用の場合は Inspector2, IResponseInspector2 を継承して作ります。
上記の画像に当該するコードは下記の通りです

using Fiddler;
using System.Windows.Forms;

public class ResponseView : Inspector2, IResponseInspector2
{
    /// <summary>
    /// Inspector ビューへの項目の追加やウィンドウの初期化等を行う
    /// </summary>
    /// <param name="o"></param>
    public override void AddToTab(TabPage o)
    {
        o.Text = "さんぷる!";
        o.Controls.Add(new TextBox()
            {Text = "レスポンスヘッダのびゅー!", Dock = DockStyle.Fill, Multiline = true, ReadOnly = true});
    }

    /// <summary>
    /// 項目が必要なくなった場合のクリーンアップ処理を書く (IDisposable の Dispose みたいな)
    /// </summary>
    public void Clear()
    {

    }

    /// <summary>
    /// 受信されたメッセージ本文
    /// </summary>
    public byte[] body { get; set; }

    /// <summary>
    /// テキストが編集されたかどうかを返す
    /// </summary>
    public bool bDirty { get; }

    /// <summary>
    /// 読み取り専用項目かを取得・設定する
    /// </summary>
    public bool bReadOnly { get; set; }

    /// <summary>
    /// HTTP のレスポンスヘッダ
    /// </summary>
    public HTTPResponseHeaders headers { get; set; }

    /// <summary>
    /// Inspector ビュー内の項目の順番(昇順でソートされるため、値が大きければ項目の最後に追加される)
    /// </summary>
    /// <returns>表示順番</returns>
    public override int GetOrder() => 1000;
}

5.Fiddler の RequiredVersion を宣言する

上記の2クラスだけではダメで、必要な Fiddler のバージョンを宣言する必要があります。

どこか1つのソースコードで問題ありませんので、
下記のようにバージョンを宣言するだけのソースコードを作成しましょう。

[assembly: Fiddler.RequiredVersion("2.3.0.0")]

6.実行してみよう

上手くいけば下記のように、「さんぷる!」という名前の項目が追加されて
作成したプラグインが読み込まれるはずです。

画像を編集

7.目的に合わせて拡張しよう

今回の例は Inspector プラグインとして任意のビューを表示するところまでを紹介しました。
ただこれだけではBody の処理や その他のパラメータの処理がかなりおざなりになっています。

そこで下記のような、Request / Response Body のテキストを編集できるサンプルを
下記の GitHub に公開しました。
https://github.com/mimura1133/sample_fiddlerInspector

コードも極力短く、また各パラメータに関しても極力コメントを入れてありますので、
これを踏み台にして独自の Inspector プラグインを作成頂けたら幸いです。


それでは、楽しい Fiddler ライフを!

Windows Terminal (Preview) をビルドして使おう

どうも、みむらです。

先日発表されたばかりの “Windows Terminal” を使ってみました。
とりあえず、これは今すぐ会社用PCとかにも入れておこうかと思いました。

普段使いそうなツール群を呼び出せるようにしてみたのですが、
結構使いやすそうな子のようです。

マイクロソフト社からちゃんとストア経由で今後出てくると思いますが
常に最新のものを触りたい!という人向けに、ビルド方法のメモになります。


1.ビルド環境の準備

執筆時点(2019年5月8日)では、下記のものを用意する必要があります。

1. Visual Studio 2017 (2019 だと上手くビルド出来ませんでした..)
2. Windows 10 (ストアアプリ扱いになります)

また、ビルドするためには Visual Studio 2017 にて
「C++ ユニバーサル Windows プラットフォームツール」を有効にする必要があります。


2.ビルド

下記 URL より git clone を実施してソースコードを取得します。
https://github.com/microsoft/Terminal

Clone 完了後、”git submodule” を使用して、
依存関係にあるコードもダウンロードします。

# git submodule update –init –recursive

コードの準備が完了したら “OpenConsole.sln” を Visual Studio 2017 で開きましょう。

“CascadiaPackage” を右クリック → ストア → 「アプリパッケージの作成」と選択します。

そして「サイドロード用」のパッケージとして、
お使いのアーキテクチャにチェックを入れて “Release” となっていることを確認してパッケージを作成します。

注意

ビルド中、もの凄くメモリを使います。
下手をすると下記のようなエラーが出てコンパイルエラーになることもあります。

13>c1xx : error C3859: PCH の仮想メモリを作成できませんでした
13>c1xx: note: PCH: ファイル マップ全体にメモリをコミットできません
13>c1xx: note: 詳細については https://aka.ms/pch-help をご覧ください

そのときは Visual Studio の同時コンパイル数を1にすることで
改善できる場合があります。

ツール → オプション → プロジェクトおよびソリューション → ビルド / 実行
にて「平行してビルドするプロジェクトの最大数」を1にします。


3.インストール

下記のようにビルドが完了したら、Add-AppDevPackage.ps1 を実行します。
あとはウィザードに従って進めればインストール完了となります。


なお、このファイルを常用するコンピュータに持って行き、
インストールをすることで他のコンピュータでも利用することが可能になります。

動作しないときは:

開発者モードになっているかを確認しましょう。


4.使う

早速スタートに登録されましたのでバンバン使っていきましょう。


初回起動時はこんな感じの無機質なターミナルが表示されます。

ここで Ctrl + T を押しましょう。
下図のようにいい感じにタブと設定メニューが登場します。

では右端のボタンから “Settings” を開きましょう。

下図のように json が表示されると思いますので、適宜成形 (Visual Studio であればドキュメントの整形機能があります)して眺めます。

まず、全体設定ですが確認できるのは次の通りです:

“alwaysShowTabs” はタブを画面に常時表示するかどうか。これについては “true” に書き換えておいた方が無難です。
“showTerminalTitleInTitlebar” はタイトルバーにアクティブなタブのタイトルを表示させるかどうか。
“experimental_showTabsInTitlebar” はタブをタイトルバー部分に表示するかどうか。

つぎに “profiles” の中ですが、ここに項目を追加すると呼び出せるプログラムが増えます・・!

お好きなフォントを “fontFace”, “fontSize” で設定し、
透過させたい場合は “useAcrylic” を true にした上で、 “acrylicOpacity” (1に近いほど無透過)を設定すると良いと思います。

参考までに、私の設定ファイルも置いておきます。参考までにどうぞ・・!
https://gist.github.com/mimura1133/4e65fdbf8fd686d3a3691bd9b43678ac


発表されてすぐさま使ってみて、かなり使い勝手がよさそうでしたので
私としては早く標準のコマンドプロンプトの代わりになって欲しいなと思うそんな今日この頃です。

CUI なアプリケーションを全部このタブに纏めておいたら凄く使いやすそうな感じがする。。

巻末に、私の環境でビルドしたファイル(x64 専用)もおいておきます。
どうしてもビルドに失敗してしまうかたがいれば、自己責任にてお試しください。

http://mimumimu.net/beta/programs/CascadiaPackage_1.0.0.0_Test.zip

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

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