レンダリングバージョンを変更する

WebBrowserコンポーネント¹は、何もせずにそのまま使用すると必ず IE7相当のレンダリングエンジンと JavaScriptエンジンになってしまう。これは <meta http-equiv="x-ua-compatible" content="IE=Edge" /> などを食わせても変わらない。² この問題を解決するには、レジストリを触るしか方法がない。

Try  
    Dim RendererVersion As Integer = 11000
    Dim ExecName As String = Path.GetFileName(Environment.GetCommandLineArgs()(0))
    Dim Regkey As RegistryKey = _
        Registry.CurrentUser.CreateSubKey( _
            "SOFTWARE\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_BROWSER_EMULATION")
    Regkey.SetValue(ExecName, RendererVersion)
    Regkey.Close()
Catch ex As Exception  
    Console.WriteLine("CreateSubKey: " & ex.StackTrace)
End Try

WebBrowser1 = New WebBrowser()  
WebBrowser1.ObjectForScripting = Me  

レジストリには、キー＝実行ファイル(EXE)名、値＝IEバージョンの1000倍のDWORD値 を登録する。存在しない時の既定値は 7000 と見做される。またこのとき Visual Studio のデバッグRunでは .EXE名が 〜.vhost.exe になるのを考慮する必要がある。結局のところ、プログラム実行毎に毎回自分自身の .EXE名を新規／上書き登録してしまうのが手堅い。またレジストリの登録タイミングは初めて New WebBrowser() する以前でなければならない。

マウスイベントを VB.NET側で使いたい

WebBrowserコンポーネント内で発生したイベントはほぼすべて JavaScript内で完結して外部（Windows.Forms）に伝播しない。必要なら JavaScriptから ObjectForScripting機能経由で Formクラスを呼んで RaiseEvent しろということになっている。だがそういう毎回使うような定形処理はサブクラス化してまとめといたほうが良いに決まっている。

Imports System.Windows.Forms  
Public Class WebBrowserEx  
    Inherits WebBrowser

    Private WithEvents Body As HtmlElement

    Public Shadows Event MouseDown(ByVal sender As Object, ByVal e As MouseEventArgs)
    Public Shadows Event MouseLeave(ByVal sender As Object, ByVal e As MouseEventArgs)

    Protected Overrides Sub OnDocumentCompleted(ByVal e As WebBrowserDocumentCompletedEventArgs)
        Me.Body = Me.Document.Body
        MyBase.OnDocumentCompleted(e)
    End Sub

    Private Sub Body_MouseDown(ByVal sender As Object, _
                               ByVal e As HtmlElementEventArgs) _
                           Handles Body.MouseDown
        RaiseEvent MouseDown(sender, New MouseEventArgs(e.MouseButtonsPressed, 1, _
                                                        e.ClientMousePosition.X, _
                                                        e.ClientMousePosition.Y, 0))
    End Sub

    Private Sub Body_MouseLeave(ByVal sender As Object, _
                                ByVal e As HtmlElementEventArgs) _
                            Handles Body.MouseLeave
        RaiseEvent MouseLeave(sender, New MouseEventArgs(MouseButtons.None, 0, _
                                                         e.ClientMousePosition.X, _
                                                         e.ClientMousePosition.Y, 0))
End Class

' WebBrowser1 = New WebBrowserEx()  
' WebBrowser1.Navigate("about:blank")  

ここでは一部しか書いてないが、Up/Enter/Move/Over も同様に実装³できる。

ただこの実装においては、WebBrowserコンポーネント内で Refresh() する、あるいはF5(Ctrl+R)キーを押してのページリロードに対応できない。というのも .NET版の WebBrowserコンポーネントはリロード時に一切イベントを発火しないからだ。ページ内のJavaScriptでは通常通り onload等が発火するので ObjectForScriptingで補完する（Me.Document.Body を読み直す）必要がある。

JScriptTypeInfo と .NET オブジェクトの相互変換

ObjectForScriptingと InvokeScriptを使えば .NETと JavaScriptのユーザ関数を相互に呼び出し合うことが出来る。この時確実に引き渡せる引数は、数値・文字列・真偽値・null の4種類しかない。配列や連想配列（ハッシュ）はシリアライズする必要がある。だが実際には次のコードを試せば解るが、JavaScriptで生成された複雑なデータ構造は .NETのなかを素通りさせることができる。

var r = window.external.foo({a:[123, 456], h:{s:789}, s:"Test"});  
function bar (data) {  
    return {b:data.a[0] + data.h.s};
}
console.log(r.b); // 912  

Public Function foo (ByVal d As Object) As Object  
    Console.log(d.s)    ' Test
    Console.log(d.a(1)) ' 456
    Console.log(d.h.s)  ' 789
    Return WebBrowser1.Document.InvokeScript("bar", d)
End Function  

WebBrowserコンポーネントにはこのJavaScriptネイティブのデータ構造＝JScriptTypeInfo型オブジェクトを解釈する機能（オブジェクト定義）がない。単純な文字列や数値は ToString()や ToInt32()メソッドで変換できるし、ハッシュの場合は Item() メソッドこそ使えるものの Count() も Containes() もないので「静的な構造体」以外は直接扱えないのだ。

Console.log(d.s)               ' sメンバーがあれば読み出せるがなければ例外発生  
Console.log(d.Item("s"))       ' これもメンバーがなければ例外発生  
Console.log(d.Conatines("s"))  ' これもメンバーがなければ例外発生  

.NETのほうでは3.5以降で JSON文字列をシリアライズ／デシリアライズ出来るため、引数も返値も JSON文字列化する取り決めにすれば良い話なのだが、ネイティブにデータ構造を受け渡しできたほうが（JavaScript側の視点では）利便性が良い。もっぱら融通が効かないのは静的型言語である .NETの側なので、こちらをもう少し頑張ってみよう。

取り敢えず、JScriptTypeInfoを読んで比較的扱いやすい Dictionary型にまるごと変換するなら次のようなコードが書ける。いったん IExpando型にキャストすればメンバーのプロパティリストを得られるので、CallByName()で実体を得ることができる。これを再帰的に適用すればいちおう全体にアクセスすることが出来る。ただし配列については手を抜いてハッシュ化してしまっているが。

' Imports System.Reflection  
' Imports System.Runtime.InteropServices.Expando

Private Function JscInfoToDict(ByVal jscinfo As Object) As Dictionary(Of String, Object)  
    Dim dict = New Dictionary(Of String, Object)
    Dim keys() As String = DirectCast(jscinfo, IExpando).GetProperties( _
        BindingFlags.Default).Select(Function(p) p.Name).ToArray()
    For Each Key In keys
        Dim Var As Object = CallByName(jscinfo, Key, CallType.Get)
        ' Console.WriteLine("Key:" & Key & ", Var:" & Var.ToString & ", Type:" & Var.GetType.ToString)
        If Var.GetType.ToString = "System.__ComObject" Then  ' これだけでは配列とハッシュの区別がつけられない
            dict.Add(Key, JscInfoToDict(Var))
        Else
            dict.Add(Key, Var)
        End If
    Next
    Return dict
End Function  

これとは逆に、Dictionary型を JScriptTypeInfo型に変換するのは、JScriptTypeInfo型の定義がないので不可能だ。ならば「JScriptTypeInfo型を知っている」言語に変換を委託してしまえば良い。そもそも相互変換をしたい場面において WebBrowserコンポーネントを使っていないということは滅多にないだろうから、InvokeScriptで JSONクラスメソッドを呼び出してしまえば良い。⁴

' Imports System.Web.Script.Serialization

' Friend WithEvents Converter As WebBrowser  
' Converter = New WebBrowser()  
' Converter.Navigate(New Uri("about:blank"))

Private Sub Converter_DocumentCompleted(ByVal sender As Object, _  
                                        ByVal e As EventArgs) _
                                    Handles Converter.DocumentCompleted
    sender.Document.InvokeScript("eval", New Object() {"function __j2s(j){return JSON.stringify(j)};"})
    sender.Document.InvokeScript("eval", New Object() {"function __s2j(j){return JSON.parse(j)};"})
End Sub

Public Function jobject_decoder(ByVal jscinfo As Object) As Dictionary(Of String, Object)  
    Dim jss As JavaScriptSerializer = New JavaScriptSerializer()
    Dim jstring As String = Converter.Document.InvokeScript("__j2s", New Object() {jscinfo})
    Return jss.Deserialize(Of Dictionary(Of String, Object))(If(jstring, "{}"))
End Function

Public Function jobject_encoder(ByVal dict As Dictionary(Of String, Object)) As Object  
    Dim jss As JavaScriptSerializer = New JavaScriptSerializer()
    Dim jstring As String = jss.Serialize(dict)
    Return Converter.Document.InvokeScript("__s2j", New Object() {jstring})
End Function  

.NET版の InvokeScript() は COM版のそれとは異なり、ルート要素のユーザ関数しか呼び出せず、クラスメソッドを直接叩くことが出来ない。本来なら JSON.stringify JSON.parse を直接使いたいが使えないので、DocumentCompleted を待ってから変換用ユーザ関数を eval で登録する方法を取った。なお JSONクラスは IE7ではそもそも存在しないので、前述した IEバージョン変更のレジストリ登録が事前に必要になる。⁵

余談：cscript.exeでの JSON変換

Windows標準でかつ標準入出力が使える汎用インタプリタとして、cscript.exe は貴重な存在だ。うまく使えば grep/sed/awk あたりの代用にもなる。だが標準では JSON変換機能を持っていないなど基本的な言語仕様が少々古い。しかし COMオブジェクトとして HTMLファイルにアクセスすると、その中の最新 JavaScriptエンジンから欲しい機能をアドオン的に持ってくることが出来る。

// Ex) cscript.exe //Nologo //U jconvert.js <STDIN >STDOUT
var htmlfile = WScript.CreateObject('htmlfile'), JSON;  
htmlfile.write('<meta http-equiv="x-ua-compatible" content="IE=9" />');  
htmlfile.close(JSON = htmlfile.parentWindow.JSON);

while (!WScript.StdIn.AtEndOfStream) {  
    var json = JSON.parse(WScript.StdIn.ReadLine()),
    // user code
    WScript.StdOut.WriteLine(JSON.stringify(json));
}

このテクニックは色々と応用が効く。同じようにして（役に立つかどうかはともかく）jQueryをインポートすることが出来るし、include／require文代わりに使うことも出来る。

なお cscript.exe の標準入出力は、素で起動すると ANSI すなわち日本語では CP932 になる。このため JSON文字列中のマルチバイト文字はエスケープされていなければ正しく扱えない。そこで //U オプション付きで起動すると UTF-16LE でマルチバイト文字を扱えるようになるが、改行コードも2バイト文字（ワード幅）にしなければならない罠がある。更に余談となるが、cscript.exe のスクリプトコードは、ANSI(CP932)または UTF-16LE（BOM付き）で記述されていなければならない。一般的な UTF-8N では文字化けが発生する。⁶

.ppmxファイルの保存

ppm install を実行すると、レポジトリから .ppmxファイルが tempディレクトリにダウンロードされてインストールされる。だがこのファイルはコマンド終了時に全削除されるため、普段目にすることがない。.ppmxファイル自体は ppm install の引数に渡すことでオフラインインストールできるため、消される前にファイルのコピーを別の場所に取っておけば、あとでおなじ環境を再構築することが容易くなる。

--- C:/Perl64/lib/ActivePerl/PPM/Client.pm      Tue Feb 16 06:02:11 2016
+++ D:/Perl64/lib/ActivePerl/PPM/Client.pm      Fri Mar 10 12:12:03 2017
@@ -1328,6 +1328,9 @@
                    if ($save_len != $len) {
                        die "Aborted download ($len bytes expected, got $save_len).\n";
                    }
+use File::Copy;
+my $File = File::Basename::basename($save, '.tgz');
+File::Copy::copy($save, $File.'.ppmx');
                }
                # XXX An MD5 checksum for the tarball would be a good thing
            }

5.18以降に通用するこのパッチを当てると、カレントディレクトリにダウンロードされた .ppmxファイルが残されるようになる。依存関係で複数のモジュールが取得された場合はその全てが残される。このコードを見れば解るが、 .ppmxファイルの実態は単なる .tgzアーカイブだ。わざわざ拡張子を代えているのは、そうしないと ppmコマンドがオフラインインストール用ファイル名として認識しないからである。

なお ppmコマンドは自前のデータベースとキャッシュでダウンロード履歴を管理しており、毎回必ずしもファイルダウンロードが発生するわけではない。情報は以下のフォルダに保存されているので、作業前にこれを空にしてやればよい。

%LOCALAPPDATA%\ActiveState\ActivePerl

保存しておいた .ppmxファイルは、ppm install でインストールすることが出来るが、依存関係にあるサブモジュールを先にインストールしておかないと、オンラインで取りに行こうとしてしまう。そこで複数の .ppmxファイルから .ppdファイルを取り出し、そこに書かれた依存関係リストを読み出し、優先順位を付けて順次処理することになる。

#!C:/Perl/bin/perl.exe
use utf8;  
use strict;  
use Archive::Tar;  
use File::Basename;  
use File::Find;  
use Cwd;

my $cwd = $ARGV[0] // getcwd;  
print "Search directory: ", $cwd, "\n";  
my(@ppmx_list, %ppmx_hash, %ppmx_path);  
find(sub {  
    if (m/\.ppmx$/io) {
        $ppmx_path{$_} = $File::Find::name;
        push @ppmx_list, $_;
    }
}, $cwd);
foreach my $ppmx (@ppmx_list) {  
    $ppmx_hash{$ppmx} = 9999;
}
foreach my $ppmx (@ppmx_list) {  
    my $tar = Archive::Tar->new();
    $tar->read($ppmx_path{$ppmx}, 1);
    foreach my $file ($tar->get_files()) {
        if ($file->{name} =~ /\.ppd$/io) {
            foreach my $line (split /\n/, $file->{data}) {
                if (my $require = ($line =~ m/REQUIRE NAME="([^\"]+)"/o)[0]) {
                    $require =~ s/::/-/go;
                    foreach my $hash (keys %ppmx_hash) {
                        $ppmx_hash{$hash}-- if 0 == index lc($hash), lc($require);
                    }
                }
            }
        }
    }
}
undef @ppmx_list;  
while (my($key, $var) = each %ppmx_hash) {  
    push @ppmx_list, sprintf "%04u %s", $var, $key;
}
foreach my $ppmx (sort {lc $a cmp lc $b} @ppmx_list) {  
    $ppmx =~ s/^\d+ //o;
    my $command = "ppm install ".$ppmx_path{$ppmx}." --nodeps";
    print $cwd, "> ", $command, "\n";
    system $command and die "$!";
    print "\n";
}

1;  
__END__  

このコードは .ppmxファイルを含む親ディレクトリを引数に取る。引数は複数でもよく、省略されればカレントディレクトリを起点にする。-nオプションは ppmコマンドに --nodeps を付加する。-n オプションなしで起動すると依存解決に失敗した場合（依存する .ppmxが見つからない場合）レポジトリからのダウンロードが生じる。

.ppmxファイルの作成

.ppmxファイルの実態は .tgzで固められた .ppdファイルと blibディレクトリだ。cpanでソースからビルドしたものを .ppmxファイルにして保存しておくと、再ビルドする手間を減らせる。cpanの作業ワークは C:\Perl64\cpan\build または C:\Perl\cpan\build にある。

例えば既に cpan install に成功した Foo::Bar モジュールに対応する Foo-Bar-0.1010-4UofsT というディレクトリがあったなら、まずそこに cd して dmake ppd を実行¹する。すると Foo-Bar.ppd というファイルが作成されるだろう。

> cd C:\Perl64\cpan\build\Foo-Bar-0.1010-4UofsT
> dmake ppd
> type Foo-Bar.ppd
<SOFTPKG NAME="Foo-Bar" VERSION="0.1010">  
    <ABSTRACT>foobar foobar</ABSTRACT>
    <AUTHOR>Charlie Root &lt;foobar@example.com&gt;</AUTHOR>
    <IMPLEMENTATION>
        <PERLCORE VERSION="5,006,0,0" />
        <REQUIRE NAME="Carp::" />
        <REQUIRE NAME="Cwd::" VERSION="3.16" />
        <REQUIRE NAME="Exporter::" />
        <REQUIRE NAME="strict::" />
        <REQUIRE NAME="vars::" />
        <ARCHITECTURE NAME="MSWin32-x64-multi-thread-5.24" />
        <CODEBASE HREF="" />
    </IMPLEMENTATION>
</SOFTPKG>  

REQUIRE 行は依存をあらわす。ARCHITECTURE 行はインストール先のプラットフォームを限定するものだが、ピュアPerlで書かれた環境非依存モジュールの場合は noarch に書き換えることでインストール先を選ばないようにすることもできる。

<ARCHITECTURE NAME="noarch" />  

.ppmx(.tgz)ファイルを作るための tar+gzアーカイバは、C:\Perl64\bin に ptar.batとしてインストールされている。すでにパスは通っているので次のようにすれば .ppmxファイルができあがる。

> ptar -v -c -C -z -f foo-bar.ppmx blib foo-bar.ppd

この際注意が必要なのは、.ppmxと .ppdのファイル名は一致させておかなければならない点だ。.ppmxファイル名にバージョン番号を付加する一般的なルールに従う場合は、.ppdファイル名にもバージョン番号を付加しておく。もちろんそのバージョン番号は SOFTPKG行の VERSIONと一致しているべきだ。

> ren foo-bar.ppd foo-bar-0.1010.ppd
> ptar -v -c -C -z -f foo-bar-0.1010.ppmx blib foo-bar-0.1010.ppd

クライアント側は普通に open/close で読み書きできるので、サーバ側で namedpipe を作る部分を書いてみる。

use strict;  
use warnings;  
use Win32::API;  
use Fcntl;  
use constant {  
    PIPE_ACCESS_INBOUND     => 0x00000001,  # O_RDONLY相当
    PIPE_ACCESS_OUTBOUND    => 0x00000002,  # O_WRONLY相当
    PIPE_ACCESS_DUPLEX      => 0x00000003,  # O_RDWR相当

    PIPE_WAIT               => 0x00000000,
    FILE_FLAG_OVERLAPPED    => 0x40000000,
};

*STDOUT->autoflush;

my $PIPE_NAME = "\\\\.\\pipe\\pipesv";

my $CreateNamedPipe = Win32::API->new( "kernel32", "CreateNamedPipe", "PNNNNNNP", "N" ) or die;  
my $PIPE = $CreateNamedPipe->Call(  
    $PIPE_NAME,                #  LPCTSTR lpName,                             // パイプ名
    PIPE_ACCESS_DUPLEX,     #  DWORD dwOpenMode,                           // パイプを開くモード
    PIPE_WAIT,              #  DWORD dwPipeMode,                           // パイプ固有のモード
    255,                    #  DWORD nMaxInstances,                        // インスタンスの最大数
    0,                      #  DWORD nOutBufferSize,                       // 出力バッファのサイズ
    0,                      #  DWORD nInBufferSize,                        // 入力バッファのサイズ
    10_000,                 #  DWORD nDefaultTimeOut,                      // タイムアウト(msec)の間隔
    0,                      #  LPSECURITY_ATTRIBUTES lpSecurityAttributes  // セキュリティ記述子
);
my $CloseHandle = Win32::API->new( "kernel32", "CloseHandle", "N", "N" ) or die;

my $ReadFile = Win32::API->new( "kernel32", "ReadFile", "NPNPP", "N" ) or die;  
sub ReadFile {  
    my $hFile = shift;
    my $lpBuffer = "\0" x 512;
    my $nNumberOfBytesToRead = 512;
    my $lpNumberOfBytesRead = "\0" x 8;
    my $result = $ReadFile->Call(
        $hFile,
        $lpBuffer,
        $nNumberOfBytesToRead,
        $lpNumberOfBytesRead,
        0);
    return undef unless $result;
    my $length = unpack "V", $lpNumberOfBytesRead;
    return undef unless $length;
    return substr $lpBuffer, 0, $length;
}

my $WriteFile = Win32::API->new( "kernel32", "WriteFile", "NPNPP", "N" ) or die;  
sub WriteFile {  
    my $hFile = shift;
    my $lpBuffer = shift;
    while (my $nNumberOfBytesToWrite = defined $lpBuffer && length $lpBuffer) {
        my $lpNumberOfBytesWritten = "\0" x 8;
        my $result = $WriteFile->Call(
            $hFile,
            $lpBuffer,
            $nNumberOfBytesToWrite,
            $lpNumberOfBytesWritten,
            0);
        return undef unless $result;
        my $length = unpack "V", $lpNumberOfBytesWritten;
        $lpBuffer = substr $lpBuffer, $length;
    }
    return undef;
}

my $ConnectNamedPipe = Win32::API->new( "kernel32", "ConnectNamedPipe", "NP", "N" ) or die;  
my $DisconnectNamedPipe = Win32::API->new( "kernel32", "DisconnectNamedPipe", "N", "N" ) or die;

while ($ConnectNamedPipe->Call($PIPE, 0)) {  
    WriteFile($PIPE, "Welcome\n");
    print ReadFile($PIPE);         # client from "Hello"
    $DisconnectNamedPipe->Call($PIPE);
    #last;      # no loop
}
$CloseHandle->Call($PIPE);

1;  
__END__  

本来はセキュリティ記述子を指定すべきだが、本件は動作サンプルなので省略¹する。バッファサイズについてはダミーなので 0 と書いて良い。 こうして出来た PIPEハンドル（単なるint値）は、PerlIOの感知するところではないため² 通常の sysread/syswrite では扱えない。従って CloseHandle/WriteFile/ReadFile についても Win32API で実装する。

ConnectNamedPipe() はソケット通信の accept() に相当する関数で、クライアント側が同名パイプを開くまでI/Oブロックする。DisconnectNamedPipe()はこのセッションを閉じてクライアントを切断する。

いっぽう、クライアント側は普通のファイルアクセスとなんら変わるところはない。

use strict;  
use warnings;

*STDOUT->autoflush;

my $PIPE_NAME = "\\\\.\\pipe\\pipesv";

open my $FH, "+<", $PIPE_NAME or die "$!";  
$FH->binmode(":raw");
print scalar <$FH>;                # server from "Welcome"  
$FH->write("hello\n");
$FH->close;

1;  
__END__  

マルチクライアントサーバを実装する場合、基本的には ConnectNamedPipe のあとで CreateThread すればよいが、CreateNamedPipe に FILE_FLAG_OVERLAPPED の指定と、ConnectNamedPipe に lpOverlapped の指定が必要になる。³

モジュールマップ登録では個々の.fcgiファイルについて1エントリが必要とされるため、拡張子.fcgi全体をひとつのモジュールマップで済ませるための簡単なラッパーを書いてみた。ものすごく単純だが用法を誤らなければ相応に使える。

use strict;  
use warnings;  
use FCGI;  
use File::Spec;  
open STDERR, ">&", STDOUT;  
my $request = FCGI::Request or die;  
while ( $request->Accept >= 0 ) {  
    my $stderr = '';
    eval {
        local $SIG{__WARN__} = sub { $stderr .= shift };
        local $SIG{__DIE__} = sub { die($stderr = shift) };
        my $file = File::Spec->catfile(
            $ENV{DOCUMENT_ROOT} // 'Undefined',
            $ENV{SCRIPT_NAME} // 'index.fcgi'
        );
        return print "Status: 404\n\n" unless -f $file;
        do $file;
    };
    $stderr = "$@" if $@;
    if ($stderr) {
        print "Status: 403\nContent-Type: text/plain\n\n", $stderr;
    }
}
1;  
__END__  

このラッパーを要求パス *.fcgi に対して適用する¹と、ドキュメントルート以下の FastCGIファイルについて 半常駐化状態で実行されるようになる。PATH_INFO は期待どうり動作するし、 既定のドキュメント に index.fcgi を追加した場合にも対応する。ただしあくまでも簡易的に、だ。

このラッパーがなぜ半常駐化なのかというと、常駐対象になるのが、特殊変数および our 宣言²されたパッケージ変数と use または require で読み込まれたモジュールに限定されているからだ。.fcgi ファイル自体は do $file の形式で読込実行されているが、これはこの命令が実行される度にファイルアクセスが発生し、コードが再コンパイル³されることによる。このとき do $file は package main 名前空間内で実行されているため、複数の .fcgi で同名のグローバル変数や関数宣言が共有されることになる。

.fcgi 自体は毎回再コンパイルされるが、その中で使われる use モジュールについてはコンパイル済コードが再利用されるため、その使用比率が大きいコードほどメリットがある。一方で名前空間のファイル別隔離処理を端折っているため同名関数は後続のコード実行で上書きされてしまうため注意を要する。このあたりが簡易版と称する所以だ。

エラー処理について言えば、FastCGI 起動前に STDERR を STDOUT にリダイレクトすることで、do $file 実行時の構文エラーが極力 IIS Worker Process へ渡らないように細工している。$SIG{} の定義も同様に STDERR を漏らさないためだ。これを怠ると IIS が 503 Service Unavailable を返すようになり、かつ、サーバ自体を再起動しなければ回復できない⁴ことがままある。

IISのCGIセットアップ

まず普通にIISでPerl CGIを動かすための手順。一応 Windows 10/Windows Server 2012 と ActivePerl 5.20(64bit) を前提にしているが、他の組み合わせでも大差はない。

コントロールパネル＞プログラム＞プログラムと機能＞Windowsの機能の有効化または無効化と辿ってダイアログを開き、インターネットインフォメーションサービスにチェックを付ける。更にそのサブメニューを開いてWorld Wide Webサービス＞アプリケーション開発機能>CGIにチェックを付ける。最低限これだけを有効化すれば要は足りるからOKを押して変更を確定する。初回導入時についてはサーバ再起動は必要ない。¹

ActivePerl(64bit)が既にインストールされており、パスが通っているならコマンドプロンプトを管理者権限で開いて以下のコマンドをタイプする。

ap-iis-config add all --site 1 --cgi  

するとIISマネージャーのサイト＞Default Web Site＞機能ビュー＞ハンドラーマッピングに以下のスクリプトマップが登録されているはずだ。

復数のサイトが作られている場合、個別にこのスクリプトマップが必要になる。前述の--site 1の数字がサイトの登録番号を示しているので、これを変更しながら必要なだけ繰り返す。あるいはこのダイアログ画像を参考に手動でスクリプトマップを追加する。

なお32bit版のActivePerlでは、ISAPIを使用することもできる。Windows機能ダイアログでISAPIフィルターとISAPI拡張にもチェックをつけていれば、以下のコマンドでISAPIのハンドラーが作成できる。²

ap-iis-config add all --site 1 --cgi --isapi  

以上で .pl ファイルはCGIとして認識されるようになる。.cgi ファイルを扱いたい場合は手動でスクリプトハンドラーを追加しよう。³

FastCGIを有効化する

FastCGIも同様にハンドラーマッピングを追加することで有効化できるが、ひとつのスクリプトに対してひとつのモジュールマップエントリが必要になる。例えば以下のスクリプトを登録してみよう。⁴

use strict;  
use warnings;  
use FCGI;

my $count = 0;  
my $request = FCGI::Request();  
while ( $request->Accept >= 0 ) {  
    print "Content-type: text/html\r\n\r\n", ++$count;
}

このファイルは通常のURIで辿れる場所に存在しなければならない。つまりC:¥inetpub¥wwwroot以下以外にあるのならば、仮想ディレクトリパスが通っている必要がある。そうした上で次のようにモジュールマップを登録する。

要求パス欄は実ファイル名と一致⁵させなければならない。モジュール欄はドロップダウンからFastCgiModuleを選択する。名前欄は同一サイト内で重複しなければ自由だ。そして実行可能ファイル欄にPerlの実行フルパス名とスクリプトのフルパス名"を半角パイプ記号で続けて記入する。なぜパイプで繋げるのかは解らないがこのように書かなければならない。これでOKを押すとハンドラを登録してよいか警告ダイアログが出るのではいで応答する。

正しくFastCGIハンドラが登録されていれば、このスクリプトをブラウザで開けば（例えば localhost/test/count.fcgi）カウンタが表示されるだろう。Ctrl+RやF5でリロードすればカウントアップが進むはずだ。

なおスクリプトを書き換えたあとは、実行中のFastCGIハンドラを再起動しなければならない。手っ取り早いのはタスクマネージャのプロセス一覧から、IIS Worker Process を探して タスクの終了 をさせてしまう方法だ。こうすればすぐに再度1からカウントをやり直す。

Mojolicious::LiteアプリをFastCGIで実行する

Mojoliciousは、その開発当初はともかく現在はIISをサポートしていない。だが前述のもっとも単純な FastCGIスクリプトを見ればわかるように、Requestループの中で普通にCGIスクリプトを利用すれば、そのままFastCGIプロセス (IIS Worker Process) として永続化される。かといってループ内で Mojolicious を呼び出してもそのままでは正常に動作しない。app->start が IIS/CGIであるかどうかを正しく認識できないためだ。そこで次のようなコードにする。⁶

use strict;  
use warnings;

use Mojolicious::Lite;

plugin 'basic_auth';

my $count = 0;

get '/' => sub { $_[0]->render(text => 'Non restricted area' . ++$count); };

under sub {  
    my ($c) = shift;
    return $c->basic_auth(
        realm => sub {
            if ( @_ && ( "@_" eq 'foo bar' ) ) {
                $c->req->env->{REMOTE_USER} = $_[0];
                return 1;
            }
        }
    );
};

get '/rest' => sub {  
    $_[0]->render(text => 'Hello ' . $_[0]->req->env->{REMOTE_USER} . ++$count . join(",", @ARGV));
};

if ($ENV{APP_POOL_CONFIG}) {  
    use FCGI;
    my $request = FCGI::Request();
    while ( $request->Accept >= 0 ) {
        app->start("cgi");
    }
}
else {  
    app->start();
}

これはIIS固有の環境変数が存在するならば、FCGI::Requestループ実行に切り替えるようにしている。そうでなければ、つまりコマンドプロンプトで実行すれば、従来通りの挙動となる。こうしておいたうえで、FastCGIハンドラには次のように指定する。

C:¥Perl64¥bin¥perl.exe|C:¥test¥apps.fcgi cgi -m production  

ここでCGI形式で実行することを強要し、かつproductionモードを強制する。このモード指定がないと developmentモードで実行されることになり、標準出力に非HTTPプロトコルな出力が混じってしまうので、結果IISはInternal Server Errorを返すことになってしまう。

apps.fcgiのある場所に logディレクトリを掘っておくとそこにログが吐き出されるので、モード指定がなくても一見問題が解決できるように見える。だが実運用段階ではこのログを定期的に削除する必要に迫られるので、ここではその方法は取らない。ログファイルは IIS Worker Process が握っているので、このプロセスを終了させないとログファイルを削除することができないのだ。他には IISの環境変数に MOJO_MODE を追加して回避する手段があるが、今回は設定が一箇所ですむ手法を取り上げた。⁷

要件定義

1. 対象機は x86_64（amd64）とする。
2. VGAデバイスは物理的に搭載されていない。GUIも使用しない。よって起動する CentOSはコンソールベースとする。
3. BIOSコンソールリダイレクト機能は対象機材でサポートされているものとする。
4. シリアルコンソールは baud=115.2kで接続する。¹
5. 成果物は ISOイメージとし、CD-R/DVD-Rに焼いて USB-ODDブート（USB光学ドライブ起動）できるものとする。通常は、再起動毎にあらゆる設定や痕跡は完全に忘却される。
6. 他の Linuxマシンを必要とすることなく、一般的な Windowsマシンから既成の USBインストーラを用いて、USBフラッシュドライブに変換できるものとする。この際 persistent領域を設定できなければならない。
7. yum一式を備えている。追加したパッケージや設定は、persistent有効時は維持される。
8. 既定のログインユーザ名は liveuser とし、パスワードも無しとする。ゆえにパスワード無しで sudoできるものとする。（一般的な LiveBootの流儀）
9. 既定のネットワーク設定・接続はオフとする。
10. これらのパスワードやネットワーク設定は persistent有効時には自由に設定変更して永続化することができ、再起動しても設定内容が失われてはならない。

以後は CentOS-7-x86_64-LiveCD-1503.iso をベースにして話を進める。32bit版や CentOS-6でも同様の手順で構築できる。²

Ubuntuでは最終的な rootfsを作るのにオンメモリ（2GiB程度）で作業できたが、CentOS用の rootfsを作成するには作業領域が足りないため、起動用 USBメモリの他に Ext4でフォーマットできるフラッシュドライブや HDDを別途用意しなければならない。なお最終的に出来上がるブータブルイメージは CD-Rに充分格納できるサイズ（640MiB以下）になる。

なお製作時のリファレンス機材には Riava RS670A を使用した。³

シリアルコンソール対応のインストーラUSBメモリを作る

まずヘッドレス環境で使用できる CentOSインストーラを LiveCD ISOイメージから作成する。Windows上でこれを行うには Fedora LiveUSB Creator⁴を使用する。

次に起動メニューを書き換える。LiveUSB Creatorが作成したベースファイルからの相違点はシリアルコンソール設定の追加が主だ。

#serial 0 115200
#console 0

default vesamenu.c32  
timeout 100  
menu background  
menu autoboot Starting CentOS Linux 7 in # second{,s}. Press any key to interrupt.

menu clear  
menu title CentOS Linux 7  
menu vshift 4  
menu rows 12  
menu margin 8  
menu helpmsgrow 15  
menu tabmsgrow 13

menu tabmsg Press Tab for full configuration options on menu items.  
menu separator  
menu separator  
label linux0  
  menu label ^Start CentOS Linux 7 Live
  kernel vmlinuz0
  append initrd=initrd0.img root=live:CDLABEL=LIVE rootfstype=vfat ro rd.live.image quiet rd.luks=0 rd.md=0 rd.dm=0 console=tty0 console=ttyS0,115200n8
  menu default
menu separator  
menu begin ^Troubleshooting  
  menu title Troubleshooting
label check0  
  menu label ^Test this media & start CentOS Linux 7 Live
  kernel vmlinuz0
  append initrd=initrd0.img root=live:CDLABEL=LIVE rootfstype=vfat ro rd.live.image quiet rd.luks=0 rd.md=0 rd.dm=0 rd.live.check console=tty0 console=ttyS0,115200n8
menu separator  
label local  
  menu label Boot from ^local drive
  localboot 0xffff
menu separator  
label returntomain  
  menu label Return to ^main menu.
  menu exit
menu end  

このフラッシュドライブで、Troubleshootingサブメニュー内の Test this media & start CentOS Linux 7 Live を選んで起動しよう。しばらく待っているとログインプロンプトが出現する。ここからは root[ENTER]で rootシェルに入ることが出来る。

rootfsを作成する

この時点で NetworkManager は起動しているので DHCPでのIP取得は既に済んでいるだろう。作業に必要なパッケージを yumで追加する。

LANG=C  
yum install -y squashfs-tools  

作業用の追加ドライブを接続してパーテションをフォーマットし、/mntにマウントしてそこに移動する。ここでは /dev/sdb1とする。

mkfs.ext4 /dev/sdb1  
mount /dev/sdb1 /mnt  
cd /mnt  

起動時のフラッシュドライブは /run/initramfs/liveに ReadOnlyでマウントされているので、これを rwオプションでリマウントして書き換え可能にする。

mount -o rw,remount /run/initramfs/live  
cd /run/initramfs/live  

現在起動している rootfsの実体は /run/initramfs/live/LiveOS/squashfs.imgだ。このファイルを差し替えるのが最終目的だが、これは LiveOS/ext3fs.imgという loopbackファイルを squashfsで圧縮した構造になっている。そこでこれを以下のようにして再現する。rootfs容量はここでは8GiBとするが、適宜任意のサイズに変えても良い。

mkdir -p squashfs-root/LiveOS  
truncate -s $((2**33)) squashfs-root/LiveOS/ext3fs.img  
mkfs.ext4 -L _CentOS-7-livecd squashfs-root/LiveOS/ext3fs.img  

このファイルを loopbackマウントして /mnt/chrootでアクセスできるようにする。

mkdir /mnt/chroot  
mount -o loop squashfs-root/LiveOS/ext3fs.img /mnt/chroot/  

後は yumのグループインストールコマンド一発で、任意の新しい rootfs環境が構築できる。

yum --installroot=/mnt/chroot --releasever=7 -y groupinstall Core  

releaseverオプションに指定する CentOSのバージョンは、/etc/os-releaseファイルを参照すると良い。

rootfsの環境設定

まず各システム領域を chroot内に bindマウントする。そしてダミーの /etc/fstab（中身は空でも良い）を作成しておく。

mount -o bind /dev/ chroot/dev/  
mount -o bind /proc/ chroot/proc/  
mount -o bind /tmp/ chroot/tmp/  
mount -o bind /run/ chroot/run/  
touch chroot/etc/fstab  

initramfsの構築設定ファイルを追加する。これは LiveBoot可能な initramfsを作成するのに必須の設定だ。

hostonly="no"  
add_dracutmodules+="dmsquash-live"  
compress="xz"  

現在起動している LiveCDシステムの、livesysサービスファイルを chroot内にコピーしてサービス登録する。このサービスは初回起動時に liveuserアカウントの作成や rootパスワードの削除処理を行うようになっている。⁵

cp -p /etc/init.d/livesys* chroot/etc/init.d/  
chroot chroot/ chkconfig --add livesys  
chroot chroot/ chkconfig --add livesys-late  

タイムゾーンとロケール情報を設定し、NetworkManagerが初回起動時は起動しないように修正する。

ln -sf ../usr/share/zoneinfo/Asia/Tokyo chroot/etc/localtime

echo "LANG=en_US.utf8" > chroot/etc/locale.conf

chroot chroot /usr/bin/systemctl disable NetworkManager  

Linux kernelモジュールの組み込み

kernelと、その他の追加パッケージをインストールする。

yum --installroot=/mnt/chroot -y install kernel squashfs-tools dump isomd5sum epel-release  

kernelと作成された initramfsを、フラッシュドライブに移動する。rescue関係のファイルは必要ないので削除する。

rm -f chroot/boot/*rescue*  
mv chroot/boot/vmlinuz-* /run/initramfs/live/syslinux/vmlinuz0.new  
mv chroot/boot/initramfs-* /run/initramfs/live/syslinux/initrd0.img.new  

最後にクリーンアップを行ってアンマウントする。rootfsの umount後は fsckで損傷がないかチェックする。

yum --installroot=/mnt/chroot clean all  
find chroot/var/log -type f -exec /bin/truncate -s0 {} \;  
umount chroot/proc/  
umount chroot/dev/  
umount chroot/run/  
umount chroot/tmp/

du -sh chroot/  
720M    chroot/

umount chroot/  
fsck.ext4 squashfs-root/LiveOS/ext3fs.img  

squashfs.img ファイルの作成

こうして出来た rootfsを mksquashfsで圧縮すれば、LiveBoot可能な新しいシステムファイルになる。ただし Ext4フォーマットした loopbackファイルをそのまま圧縮するため、インストール過程で生じた削除ファイルの痕跡などもそのまま残っていて圧縮率が低下してしまう。

mksquashfs squashfs-root squashfs.img.new

ls -lh squashfs.img.new  
-rw-r--r--. 1 root root 474M Jun 24 08:21 squashfs.img.new

これを可能な限り取り除いて圧縮するには、dump/restoreコマンドを経由してファイルシステムを完全に作り直すとよい。ただし dumpコマンドはブロックデバイスしか扱えないので、losetupコマンドを用いて /dev/loopX に loopbackファイルをバインドして指定する。手順は面倒だが、比較するとその効果は絶大だ。

mv squashfs.img.new squashfs.img.nev

yum install -y dump

loopdev=$(losetup -f)  
losetup $loopdev squashfs-root/LiveOS/ext3fs.img  
dump -0z9 -f rootdump $loopdev  
losetup -d $loopdev

ls -lh rootdump  
-rw-r--r--. 1 root root 277M Jun 24 08:30 rootdump

rm -f squashfs-root/LiveOS/ext3fs.img  
truncate -s $((2**33)) squashfs-root/LiveOS/ext3fs.img  
mkfs.ext4 -L _CentOS-7-livecd squashfs-root/LiveOS/ext3fs.img

mount -o loop squashfs-root/LiveOS/ext3fs.img chroot  
(cd chroot/; restore -r -f ../rootdump)
rm -fr chroot/lost+found restoresymtable  
umount chroot

fsck.ext4 squashfs-root/LiveOS/ext3fs.img  
mksquashfs squashfs-root squashfs.img.new

ls -lh squashfs.img.ne?  
-rw-r--r--. 1 root root 474M Jun 24 08:21 squashfs.img.nev
-rw-r--r--. 1 root root 250M Jun 24 08:38 squashfs.img.new

cp squashfs.img.new /run/initramfs/live/LiveOS/  

新 rootfsでの起動テスト

こうして作成した rootfsファイルをブートUSBメモリにコピーして shutdownし、Windows（あるいは他のLinux機）で以下の起動用ファイルを差し替える。

• vmlinuz0.new を syslinux/vmlinuz0 へ
• initrd0.img.new を syslinux/initrd0.img へ
• squashfs.img.new を LiveOS/squashfs.img へ

syslinux/syslinux.cfg は前述のそのままでよいが、今度の起動は通常の Start CentOS Linuxラベルを選択する。ログイン・プロンプトは rootで直接、あるいは liveuser（いずれもパスワード無し）でシェルに入れる。liveuserアカウントは sudoで rootアカウントになれる。

NetworkManagerは停止状態なので、ネットワークに接続するには dhclientで Link Upするか、nmcli/nmtuiでインタフェース設定を行って NetworkManagerを起動する。

sudo -s

systemctl enable NetworkManager  
systemctl start NetworkManager

nmcli connection modify enp2s0 ipv4.method manual ipv4.addresses 192.168.240.101/24 ipv4.gateway 192.168.240.1 ipv4.dns 8.8.8.8

systemctl restart network.service

# cat /etc/sysconfig/network-scripts/ifcfg-enp2s0

ISOイメージを作成する

元の ISOの squashfs.img等を差し替えた、新しいISOイメージを作成する。まず作業に必要なパッケージをインストールし、作業領域に ISO内のファイルを展開して ReadOnlyを外す。

mount /dev/sdb1 /mnt  
cd /mnt

# install mkisofs tools
yum install -y mkisofs isomd5sum

# mount image: CentOS-7-x86_64-LiveCD-1503.iso
mkdir loop  
mount /dev/cdrom loop

# copy iso files and modify attributes
cp -rf loop files  
chmod -R +w files/  
umount loop  

フラッシュドライブから先に作成した新しいシステムファイルをコピーする。このときフラッシュドライブ上では /syslinuxに vmlinuz0と initrd0.img ファイルが置かれているが、ISOイメージでは /isolinuxディレクトリになる。⁶

# copy kernel and filesystem
cp -f /run/initramfs/live/syslinux/vmlinuz0 files/isolinux/  
cp -f /run/initramfs/live/syslinux/initrd0.img files/isolinux/  
cp -f /run/initramfs/live/LiveOS/squashfs.img files/LiveOS/  

files/isolinux/isolinux.cfg をシリアルコンソール対応に修正する。最初のシリアルポート設定は BIOSコンソールリダイレクトの有無による。また先に作成した rootfsは SELinuxをサポートするように構築してはいないので、これを無効にする。isolinux/mt86plusについては標準では存在しないが、これについては別稿を参照されたい。

#serial 0 115200
#console 0

default vesamenu.c32  
timeout 100  
menu background  
menu autoboot Starting CentOS Linux 7 in # second{,s}. Press any key to interrupt.

menu clear  
menu title CentOS Linux 7  
menu vshift 4  
menu rows 12  
menu margin 8  
#menu hidden
menu helpmsgrow 15  
menu tabmsgrow 13

menu tabmsg Press Tab for full configuration options on menu items.  
menu separator  
menu separator  
label linux0  
  menu label ^Start CentOS Linux 7 Live
  kernel vmlinuz0
  append initrd=initrd0.img root=live:CDLABEL=CentOS7-liveboot rootfstype=auto ro rd.live.image quiet rd.luks=0 rd.md=0 rd.dm=0 selinux=0 console=tty0 console=ttyS0,115200n8
  menu default
menu separator  
menu begin ^Troubleshooting  
  menu title Troubleshooting
label check0  
  menu label ^Test this media & start CentOS Linux 7 1503 Live
  kernel vmlinuz0
  append initrd=initrd0.img root=live:CDLABEL=CentOS7-liveboot rootfstype=auto ro rd.live.image quiet rd.luks=0 rd.md=0 rd.dm=0 rd.live.check selinux=0 console=tty0 console=ttyS0,115200n8 
label memtest  
  menu label Test ^memory
  kernel mt86plus
  append console=ttyS0,115200n8
menu separator  
label local  
  menu label Boot from ^local drive
  localboot 0xffff
menu separator  
label returntomain  
  menu label Return to ^main menu.
  menu exit

mkisofsコマンドで ISOイメージを作成する。ここではもっともシンプルなオプション構成として GRUB（gfxboot）や EFI対応、Macintosh対応は行ってはいない。注意が必要なのは -Vオプションに渡すCDラベルで、これは kernel起動オプションに記述したのと同じものでなければならない。またこのラベルは最大16文字なのでこれを超えないようにしよう。

find ./files -print | xargs touch -m {} \;  
LANG=C mkisofs -r -J -l \  
  -V CentOS7-liveboot \
  -cache-inodes \
  -b isolinux/isolinux.bin \n
  -c isolinux/boot.cat \
  -no-emul-boot \
  -boot-load-size 4 \
  -boot-info-table \
  -o CentOS7-liveboot.iso \
  ./files

こうして出来た ISOイメージに、それ自体の改竄検出 MD5チェックサムを implantisomd5コマンドで埋め込む。Ubuntuではファイル単位で MD5をチェックしていたが、CentOSではメディアそのものをチェックする。従ってフラッシュドライブではこの仕組は動かない。一方で CD-R等に焼いた際に Write Errorが有っても、メディアの完全性を確認することが出来る。⁷

LANG=C implantisomd5 CentOS7-liveboot.iso  

改竄チェックは checkisomd5コマンドで行える。引数には調べたい ISOファイルか、メディアを挿れた ODDのデバイスファイルを指定すればよい。なお implantisomd5と checkisomd5コマンドは、isomd5sumパッケージに含まれている。⁸

checkisomd5 CentOS7-liveboot.iso  
checkisomd5 /dev/cdrom  

CD-RW/DVD-RWに ISOイメージを焼く

光学メディアへのライティングは、Ubuntuとおなじく wodimコマンドで行える。

yum install -y wodim

# erase CD/DVD-RW media
wodim dev=/dev/sr0 blank=fast

# writing image
wodim -sao -eject dev=/dev/sr0 CentOS7-liveboot.iso

# check image
checkisomd5 /dev/sr0  

こうして作成した光学メディアで ODDブートが正常に行えたら、Test this media & start CentOSラベルで起動してみよう。検査が正常に終了するとログイン・プロンプトに進み、失敗した場合は System Haltするはずだ。⁹

persistentモードを設定する

前述の ISOイメージ/光学メディアで ODDブートが正常に行えたなら、次はその ISOイメージを Live USB Creatorでもって、今度は persistent領域を設定したフラッシュドライブを作成しよう。

persistentモードは kernelオプションの rd.live.overlay=LABEL=LIVEによって有効になる。initramfsは指定された LABELを blkidコマンドで探し、これを /run/initramfs/live/にマウントする。persistent領域ファイルは LiveOSディレクトリ内の overlay-${LABEL}-${UUID}というファイル名で探して、Device Mapperによって snapshotとして /に結合される。これ自体は初期状態では（ファイルシステムではないので）単なる Zero Fillファイルである。

blkid -L LIVE  
/dev/sda1

blkid /dev/sda1  
/dev/sda1: LABEL="LIVE" UUID="0621-6D9B" TYPE="vfat" 

ls -l /run/initramfs/live/LiveOS/  
total 1299100  
-rwxr-xr-x 1 root root      20480 Jun 26 05:26 osmin.img
-rwxr-xr-x 1 root root 1068498944 Jun 30 12:32 overlay-LIVE-0621-6D9B
-rwxr-xr-x 1 root root  261758976 Jun 30 08:26 squashfs.img

Ubuntuと異なり、Device Mapperを使用しているためもあって実際にあとどの程度データが書き込めるか（保存できるか）は dfコマンドでは判断することができない。dmsetupコマンドの statusサブコマンドで、live-rwボリュームの snapshot消費ブロック数（512byte単位）を知ることはできるから、これを利用するしかない。

dmsetup status live-rw  
0 16777216 snapshot 14960/2086912 72

echo | awk '{print 14960/2086912}'  
0.00716849  

また Ubuntuの場合は、persistentファイルは overlayfsで重ねられた独立したファイルシステムであったから、非起動状態のフラッシュドライブから persistent領域内のファイルを抜き出すことは容易だったが、CentOSではこれは容易なことではない。

（現在起動しているのとは別の）フラッシュドライブ内の persistent領域にアクセスするには、以下のようにする。

## 作業領域の準備

cd /mnt  
mkdir media squash rootfs

## フラッシュドライブを作業領域にマウントし、その中の squashfs.imgをマウントする

mount /dev/sdc1 media  
mount -o loop media/LiveOS/squashfs.img squash

## ext3fs.img（readonly）と overlayファイルに loopbackデバイスを割り当てる
## 空きデバイス名は losetup -fで得られる

losetup -f  
/dev/loop6

losetup /dev/loop6 squash/LiveOS/ext3fs.img -r  
losetup /dev/loop7 edia/LiveOS/overlay-LIVE-0621-6D9B

## ふたつのデバイスを束ねて rootfsを再生する

blockdev -q --getsz /dev/loop6  
16777216

dmsetup create live-rootfs --table "0 16777216 snapshot /dev/loop6 /dev/loop7 P 8"

dmsetup status live-rootfs  
0 16777216 snapshot 17312/2086912 80

## あとはfsckしたり・・・

fsck -f -y /dev/mapper/live-rootfs

## dumpしたり・・・
## （squashfs.img作成以後分だけを抜き出すのに /etc/dumpdatesを利用する例）

echo "/dev/mapper/live-rootfs 0 $(LANG=C \  
  date +"%a %b %d %X %z" \
    -r media/syslinux/ldlinux.sys)" >> /etc/dumpdates
dump -u1z9 /dev/mapper/live-rootfs -f rootfsdump

## mountしたり・・・

mount /dev/mapper/live-rootfs rootfs  
ls -a rootfs/home/liveuser

## 作業を終えたら後始末してフラッシュドライブを切り離す

umount rootfs  
dmsetup remove live-rootfs  
losetup -d /dev/loop6  
losetup -d /dev/loop7  
umount squash  
umount media  
rmdir media squash rootfs  

/homeや swapパーテションを設定する

/etc/init.d/livesysを覗いてみると解る¹⁰が、フラッシュドライブの /LiveOSディレクトリに、home.imgファイルがあれば /homeに、swap.imgファイルが有れば swapに、それぞれ自動的にマウントするようになっている。これらのボリュームファイルは以下のようにセットアップする。

## persistentオフの場合はフラッシュドライブを rwリマウントする 
mount -o rw,remount /run/initramfs/live

## 保存領域へcd
cd /run/initramfs/live/LiveOS

## home.img ボリュームの作成（サイズは適宜）
truncate -s $((2**31)) home.img  
mkfs.ext4 -L "home-vol" home.img

## swap.img ボリュームの作成（サイズは適宜）
truncate -s $((2**31)) swap.img  
mkswap -L "swap-vol" swap.img

## あとは特に設定変更もなく再起動するだけ
sync;sync;sync  
reboot

## homeボリュームの有無は losetupで確認できる
## 容量は dfコマンドで把握可能
losetup  
NAME       SIZELIMIT OFFSET AUTOCLEAR RO BACK-FILE  
/dev/loop0         0      0         0  1 /osmin.img (deleted)
/dev/loop1         0      0         0  1 /osmin
/dev/loop2         0      0         0  1 /run/initramfs/live/LiveOS/squashfs.img
/dev/loop3         0      0         0  1 /LiveOS/ext3fs.img
/dev/loop4         0      0         0  0 /LiveOS/overlay-LIVE-748B-70C6
/dev/loop5         0      0         0  0 /run/initramfs/live/LiveOS/home.img

## swapは freeコマンドで容量が確認できる
free  
              total        used        free      shared  buff/cache   available
Mem:        8162140      178452     7610852       16720      372836     7767880  
Swap:        262136           0      262136

ダウンロード

CentOS7-liveboot-20150703.iso 313MiB (md5sum)

要件定義

1. 対象機は x86_64（amd64）とする。
2. VGAデバイスは物理的に搭載されていない。GUIも使用しない。よって起動する Ubuntuはコンソールベースとする。
3. BIOSコンソールリダイレクト機能は対象機材でサポートされている。
4. シリアルコンソールは baud=115.2kで接続する。¹
5. 成果物はISOイメージとし、CD-R/DVD-Rに焼いてUSB-ODDブート（USB光学ドライブ起動）できるものとする。通常は、再起動毎にあらゆる設定や痕跡は完全に忘却される。
6. 他の Linuxマシンを必要とすることなく、一般的な Windowsマシンから既成のUSBインストーラを用いて、USBフラッシュドライブに変換できるものとする。この際 persistent領域を設定できなければならない。
7. apt-get一式を備えている。追加したパッケージや設定は、persistent有効時は維持される。
8. 既定のログインユーザ名は ubuntu とし、パスワードも無しとする。ゆえにパスワード無しで sudoできるものとする。（一般的なLiveBootの流儀）
9. 既定のネットワーク設定・接続はオフとする。
10. これらのパスワードやネットワーク設定は persistent有効時には自由に設定変更して永続化することができ、再起動しても設定内容が失われてはならない。

要するに、KVMやDocker等の仮想マシン環境のそれと同様の感覚で、気軽に使用できる使い捨て環境の物理版²である。その仕様上基本的には RAMシステムとなり Swapは初期設定しない。従ってメインメモリは充分潤沢に搭載されているものとする。³

Ubuntu LiveCD Customization については こちらを参照 のこと。

以後は ubuntu-15.04-desktop-amd64.iso をベースにして話を進める。32bit版でも同様だが、14.xx LTS では本稿で解説している手法は使えない。⁴

なお製作時のリファレンス機材には Riava RS670A を使用した。⁵

シリアルコンソール対応のインストーラUSBフラッシュドライブを作る

まずはヘッドレス環境で使用できるUbuntuインストーラを作らなければならない。UbuntuのインストーラISOには Desktop版と Server版があり、後者には CLI（テキスト）インストール機能があるが、本稿では Desktop版のISOイメージをベースにする。

端的には、内蔵ストレージにテキストベースの Ubuntuをクリーンインストールして GRUBで起動するのであれば、Server版をベースにするのが筋だ。だが Server版のISOイメージは LiveBoot機能を持たないため、今回の目的では Desktop版ISOイメージから作り出すほうが楽なのである。

用意するのは Ubuntu Desktop 64-bit Install ISO ファイルと、FAT32でフォーマットした1GiB以上のUSBフラッシュドライブと、Universal USB Installer⁶だ。

Windowsマシンで USBインストーラを立ち上げ、ダウンロードしたISOイメージと書き込み先フラッシュドライブを指定して起動可能メディアを作成する。この時 persistent領域は指定しない（永続化しない）。

次にブートメニューを書き換えてシリアルコンソールが使えるようにする。この作業は原則として TeraPadや MIFESのようなテキストエディタで行うが、Windows Notepadでもできなくはない。フラッシュドライブに書き込まれた元ファイルは LF改行なので Notepadでは全部が1行に繋がってしまうが、ブートローダー（SYSLINUX）は CR+LF改行でも動作するので、Notepadでも以下のテンプレートにそのまま入れ替えてしまってもよい。

isolinux.cfg冒頭のシリアルポート設定⁷は、BIOSにコンソールリダイレクト機能が備わっている場合には必要ない。BIOSとブートローダーの両方で設定をしてしまうと、入出力がバッティングして表示が崩れたりキー入力に不具合が生じる。従って今回の場合はコメントアウトで記述しておくだけとする。

#serial 0 115200
#console 0
path  
include menu.cfg  
default vesamenu.c32  
prompt 0  
timeout 50  

stdmenu.cfg からはスプラッシュ画像や表示色の設定をごっそり削る。またブートメニューが 80x24程度に収まるよう、vshift等を調整する。

menu vshift 4  
menu rows 10  
menu helpmsgrow 15  
menu cmdlinerow 16  
menu timeoutrow 16  
menu tabmsgrow 18  
menu tabmsg Press ENTER to boot or TAB to edit a menu entry  

txt.cfgのカーネルオプション行には、BIOSからカーネルに制御が渡った後のシリアルコンソール設定 console=tty0 console=ttyS0,115200n8を追記する。またLiveCD機能による自動ネットワーク構成が勝手に動かないよう ip=frommediaも必ず設定する。そしてこの段階では GUIと Ubuntuインストーラの起動をスキップしてシェルに落ちるための singleを指定しておく。

menu title Ubuntu Console boot menu  
default live  
label live  
  menu label ^Try Ubuntu Console
  kernel /casper/vmlinuz.efi
  append  file=/cdrom/preseed/ubuntu.seed boot=casper cdrom-detect/try-usb=true noprompt floppy.allowed_drive_mask=0 ignore_uuid initrd=/casper/initrd.lz ip=frommedia console=tty0 console=ttyS0,115200n8 single ---
label memtest  
  menu label Test ^memory
  kernel /install/mt86plus
  append console=ttyS0,115200n8
label hd  
  menu label ^Boot from first hard disk
  localboot 0x80

追加された kernel起動パラメータは以下の意味を持つ。

• boot=casper
  casperによるブートシーケンス（LiveBoot）を実行する。
• cdrom-detect/try-usb=true
  USBメモリブートデバイスを CDROMと同等に扱う。
• floppy.allowed_drive_mask=0
  フロッピーデバイスを無視する。
• ignore_uuid
  ブートメディアのUUIDをチェックしない。
• ip=frommedia
  ブートメディアの /etc/network/interfaces 設定を有効にする。
• console=tty0
  tty0をコンソール入出力に使用する。tty0は一般に VGA表示デバイスやフレームバッファである。
• console=ttyS0,115200n8
  ttyS0をコンソール入出力に使用する。ttyS0は一般に第一シリアルポート。通信要件は baud=115200、パリティなし、8bit幅とする。このふたつのconsole指定は、両方書く場合はこの順番（tty0、ttyS0）で書かなければならない。⁸
• single
  シングルモードで起動する。ここでは Ubuntuインストーラを起動させないために指定する。

なおインストールイメージに含まれる memtest86+（mt86plus）は、シリアルコンソールに対応していない。通常のVGA表示に加えてBIOSコンソール表示もするようにリビルドしたバイナリと差し替えておくと便利だ。⁹

rootfsを作成する

上記のUSBメモリで起動し Try Ubuntu Consoleを実行するとシングルユーザモードのbashシェルが起動する。まずは dhclientを起動したり、あるいは ifconfigと routeを叩くなりしてインターネットへ接続できるようにしよう。またロケール変数もセットする。

dhclient eth0

LANG=C  

現在起動しているこの環境は RAMシステムのため、8GiBの物理メモリを積んでいるなら 4GiB容量の RAMディスクが使える。これから作る rootfsは 2GiBも余裕があれば充分なので、/root以下を作業領域とする。なお /tmpは tmpfsマウント時のオプションのせいでそのままでは使用できない¹⁰。RAM容量が足りない場合には Ext4フォーマットした別の USBメモリや外付けHDD等を作業領域に使おう。

新しい rootfsは debootstrapパッケージを利用して作成する。さらにそれを LiveBootで使えるようにするために squashfs-toolsパッケージを用いるので、これらをインストールする。

apt-get install debootstrap squashfs-tools  

構築する Ubuntuのコードネームと CPUアーキテクチャは USBメモリから起動したそれと同じものとするが、これらは以下のコマンドで確認できる。

lsb_release -a  
No LSB modules are available.  
Distributor ID: Ubuntu  
Description:    Ubuntu 15.04  
Release:        15.04  
Codename:       vivid

dpkg --print-architecture  
amd64  

lsb_releaseコマンドが参照している実体は/etc/lsb-releaseなので、これをsourceコマンドで読めば環境変数で参照できるようになる。

cat /etc/lsb-release  
DISTRIB_ID=Ubuntu  
DISTRIB_RELEASE=15.04  
DISTRIB_CODENAME=vivid  
DISTRIB_DESCRIPTION="Ubuntu 15.04"

source /etc/lsb-release

echo $DISTRIB_CODENAME  
vivid  

これらを debootstrapコマンドの引数に記述してミニマムな新規 rootfsを構築する。

source /etc/lsb-release  
mkdir newroot  
debootstrap --arch $(dpkg --print-architecture) \  
   $DISTRIB_CODENAME newroot http://archive.ubuntu.com/ubuntu

rootfsの環境設定

構築された rootfsは上記のコマンドだけで、すでに chrootして一応 apt-getも実行できる状態になっているが、kernelはまだインストールされていない。そこでこれらを行う前の準備として /proc、/dev、/run を rootfs内にマウントする。またデフォルトロケールとタイムゾーンをセットする。

mount -o bind /proc/ newroot/proc/  
mount -o bind /dev/ newroot/dev/  
mount -o bind /run/ newroot/run/

chroot newroot/ /usr/sbin/locale-gen en_US.UTF-8  
chroot newroot/ /usr/sbin/update-locale LANG=en_US.UTF-8  
chroot newroot/ /usr/sbin/dpkg-reconfigure locales  
chroot newroot/ /usr/bin/timedatectl set-timezone Asia/Tokyo  

さらに aptが参照する newroot/etc/apt/sources.listには必要最小限の1行しか書かれていないので、これを以下の内容に書き換える。¹¹

deb http://jp.archive.ubuntu.com/ubuntu/ vivid main restricted  
deb-src http://jp.archive.ubuntu.com/ubuntu/ vivid main restricted  
deb http://jp.archive.ubuntu.com/ubuntu/ vivid-updates main restricted  
deb-src http://jp.archive.ubuntu.com/ubuntu/ vivid-updates main restricted  
deb http://jp.archive.ubuntu.com/ubuntu/ vivid universe  
deb-src http://jp.archive.ubuntu.com/ubuntu/ vivid universe  
deb http://jp.archive.ubuntu.com/ubuntu/ vivid-updates universe  
deb-src http://jp.archive.ubuntu.com/ubuntu/ vivid-updates universe  
deb http://jp.archive.ubuntu.com/ubuntu/ vivid multiverse  
deb-src http://jp.archive.ubuntu.com/ubuntu/ vivid multiverse  
deb http://jp.archive.ubuntu.com/ubuntu/ vivid-updates multiverse  
deb-src http://jp.archive.ubuntu.com/ubuntu/ vivid-updates multiverse  
deb http://jp.archive.ubuntu.com/ubuntu/ vivid-backports main restricted universe multiverse  
deb-src http://jp.archive.ubuntu.com/ubuntu/ vivid-backports main restricted universe multiverse  
deb http://security.ubuntu.com/ubuntu vivid-security main restricted  
deb-src http://security.ubuntu.com/ubuntu vivid-security main restricted  
deb http://security.ubuntu.com/ubuntu vivid-security universe  
deb-src http://security.ubuntu.com/ubuntu vivid-security universe  
deb http://security.ubuntu.com/ubuntu vivid-security multiverse  
deb-src http://security.ubuntu.com/ubuntu vivid-security multiverse  

次に LiveBoot専用の管理者ユーザ ubuntuおよびグループを作成し、パスワードなしでログイン出来るようにする。さらにrootアカウントでは直接ログイン出来ないようにロックしておく。このユーザ名は LiveBoot機能を提供している casperモジュールの設定に合わせたものだ。むろんそれぞれに任意のパスワードを設定しても構わない。（それを忘れたりしなければ）

chroot newroot/ /usr/sbin/addgroup --system --gid=999 ubuntu  
chroot newroot/ /usr/sbin/useradd -s /bin/bash -g ubuntu --uid=999 -m -k /dev/null ubuntu  
chroot newroot/ /usr/bin/passwd -d ubuntu  
chroot newroot/ /usr/sbin/usermod -L root  

内蔵ストレージに直接起動可能な rootfsをインストールする場合は、この時点で/etc/fstabを作成しなければならないが、LiveBootではこれが起動中に動的に作成・設定されるため、必要ない。

以上の環境設定が済んだら、apt-getで update/upgradeを行って chroot環境を更新する。

chroot newroot/ /usr/bin/apt-get update  
chroot newroot/ /usr/bin/apt-get upgrade  

Linux kernelモジュールの組み込み

いよいよ rootfs内に kernelモジュールをインストールするのだが、その前に現在起動中の USBメモリ（この例では/dev/sda）の MBRセクタを一応バックアップしておく。kernelインストール中に grub-pcセットアップが走るのだが、このとき MBRが上書きされてリブート不能¹²になるのを避けるためだ。なおインストールする kernelパッケージ名は 64bitと 32bitでは異なる。

dd if=/dev/sda of=mbr count=1  

chroot newroot/ /usr/bin/apt-get install linux-signed-image-$(uname -r)  

chroot newroot/ /usr/bin/apt-get install linux-image-$(uname -r)  

grub-pcセットアップは Continue without installing GRUB?を選んで何もせずに抜ける。そして忘れないうちにバックアップしておいた MBRを書き戻す。

dd if=mbr of=/dev/sda  

続いてその他のパッケージを追加インストールし、整合性を確認したのち、パッケージキャッシュを削除する。少なくとも plymouthはインストールが必要である。

chroot newroot/ /usr/bin/apt-get install plymouth squashfs-tools openssh-client  
chroot newroot/ /usr/bin/apt-get -f install  
chroot newroot/ /usr/bin/apt-get upgrade  
chroot newroot/ /usr/bin/apt-get autoremove  
chroot newroot/ /usr/bin/apt-get clean  

最後に newroot/var以下のクリーニング¹³と、newroot/bootから kernelとinitrdの削除する。LiveBootではブートデバイスの casperディレクトリにある kernelとinitrdをそのまま使用するのでこれらの容量を節約する。

find newroot/var/log -type f -exec truncate -s 0 {} \;  
find newroot/var/cache -name \*-old -delete  
rm -fr newroot/var/lib/apt/lists/*

rm -f newroot/boot/vmlinuz-* newroot/boot/initrd.img-*  

以上で rootfsの構築は完了したのだが、作業時にマウントした /proc、/dev、/run がアンマウントできない場合がある。その際は lsofコマンドで掴んでいるプロセス探して killすればよい。正しくアンマウントできていれば duコマンドで使用容量が把握できる。

lsof | grep newroot

kill <PID>

unmount newroot/run  
unmount newroot/dev  
unmount newroot/proc

du -sh newroot/  
420M    newroot/  

filesystem.squashfs ファイルの作成

構築した rootfsを mksquashfsコマンドで圧縮する。このファイルはUSBメモリの /casperディレクトリに格納するが、これは /cdrom/casperとして見ることが出来る。ただし /cdrom（USBメモリ）は roマウントされていてそのままでは書き込めないため、rwオプションでリマウントする。またそこにある filesystem.squashfsはいままさに /rofsにマウントして使われているため、直接上書きしてはならない。そこで別のファイル名で保存しておく。またこの rootfs全体のブロックサイズも保存しておく。

mount -o rw,remount /cdrom  
mksquashfs newroot /cdrom/casper/filesystem.squashfs.newroot  
printf $(du -s --block-size=1 newroot | cut -f1) > /cdrom/casper/filesystem.size.newroot  

ちなみに mksquashfsで作成したファイルは unsquashfsコマンドで展開することが出来る。

unsquashfs -d expand-root /cdrom/casper/filesystem.squashfs

ls expand-root/  
bin   dev  home        lib    media  opt   root  sbin  sys  usr  vmlinuz  
boot  etc  initrd.img  lib64  mnt    proc  run   srv   tmp  var  

新 rootfs での起動テスト

これらの作業を終えたら poweroff（shutdown -h）して、USBメモリを Windowsマシンに戻して以下の修正を行う。

• 既存の /casper/filesystem.squashfs を filesystem.squashfs.org にリネーム
• /casper/filesystem.squashfs.newroot を filesystem.squashfs にリネーム
• 同様に filesystem.size も差し替える。
• /isolinux/txt.cfg の append行からキーワード single を削除する。

この新たな環境での LiveBoot起動に失敗した場合は、上記の逆の手順でインストーライメージのシングルモードに戻す。そして unsquashfsコマンドで rootfsを展開して修正することを繰り返す。

新たな LiveBootが正しく起動してログイン・プロンプトが現れたら、ユーザ名 ubuntu（パスワード無し）でコンソールに入れるはずだ。また sudo -sで rootシェルになれる。

ISOイメージを作成する

こうして作成した filesystem.squashfsと、ブートメニューファイルを差し替えた ISOイメージを作成する。

まずベースになる Desktop版ISOイメージをローカルに展開する。これはODD（光学ドライブ）から読みだしても良いし、フラッシュドライブにISOイメージをコピーしておいて loopbackマウントで読みだしても良い。コピーしたファイルは書き込み不可となっているので chmodコマンドでパーミッションを変更する。

cd /tmp

mkdir loop

sudo mount -o loop ubuntu-15.04-desktop-amd64.iso loop/  
mount: /dev/loop2 is write-protected, mounting read-only

cp -r loop files  
sudo umount loop  
chmod -R +w ./files

ls files/  
autorun.inf  casper  EFI      isolinux    pics  preseed             ubuntu  
boot         dists   install  md5sum.txt  pool  README.diskdefines  wubi.exe  

現在起動している filesystem.squashfsは /cdrom/casper/以下に見えているのでこれをコピーする。

cat /cdrom/casper/filesystem.squashfs > files/casper/filesystem.squashfs  

isolinux/isolinux.cfg¹⁴や stdmenu.cfgについては前に上げたのと同じなので割愛する。新しい ODDブート用の isolinux/txt.cg は以下のように記述する。

menu title Ubuntu Console boot menu  
default live  
label live  
  menu label ^Try Ubuntu Console
  kernel /casper/vmlinuz.efi
  append  file=/cdrom/preseed/ubuntu.seed boot=casper initrd=/casper/initrd.lz quiet ip=frommedia console=tty0 console=ttyS0,115200n8 ---
label check  
  menu label ^Check disc for defects
  kernel /casper/vmlinuz.efi
  append  boot=casper integrity-check initrd=/casper/initrd.lz quiet console=tty0 console=ttyS0,115200n8 ---
label memtest  
  menu label Test ^memory
  kernel /install/mt86plus
  append console=ttyS0,115200n8
label hd  
  menu label ^Boot from first hard disk
  localboot 0x80

md5sum.txtは2番目の起動選択 Check disc for defectsを選んだ際に参照される改竄チェックファイルだ。単純にこのファイルをゼロバイトに切り詰めれば何もチェックされない。一方この機能を活かしたい場合、チェックファイルを作成した後に md5sumが変わってしまうファイル、すなわち md5sum.txt自身と mkisofsコマンドが作成・更新する boot.cat、isolinux.bin はチェックリストから除外しておかなければならない。

pushd ./files  
rm -f md5sum.txt isolinux/boot.cat  
find . -type f -print | xargs md5sum | grep -v isolinux.bin > ../md5sum.txt  
mv ../md5sum.txt .  
popd  

ISOイメージを作成する mkisofsコマンドは、同名のパッケージでインストールできる。

sudo apt-get install mkisofs  

mkisofsコマンドの引数¹⁵のうち -b（ブートローダーファイル）と-c（カタログファイル）は構築対象ディレクトリを基準とした場合のパス指定になるので注意しよう。また出力する ISOファイルは、先に上げた USBインストーラを使用する場合はその制限によりファイル名中に desktopの文字列が入っていなければならない。ともかく指定するオプションが多いのでシェルスクリプトにしておいたほうがコードの再利用と修正はしやすい。

find ./files -print | xargs touch -m {} ¥;  
LANG=C mkisofs -r -J -l \  
  -V UBUNTU64 \
  -cache-inodes \
  -b isolinux/isolinux.bin \
  -c isolinux/boot.cat \
  -no-emul-boot \
  -boot-load-size 4 \
  -boot-info-table \
  -o ubuntu-15.04-desktopless-amd64.iso \
  ./files

ls -la ubuntu-15.04-desktop*  
-rwxr--r-- 1 ubuntu ubuntu 1150844928 Jun 17 16:59 ubuntu-15.04-desktop-amd64.iso
-rw-rw-r-- 1 ubuntu ubuntu  238929920 Jun 17 17:25 ubuntu-15.04-desktopless-amd64.iso

出来上がった ISOイメージはフラッシュドライブや NASなどにコピーして保存しておこう。

CD-RW/DVD-RWに ISOイメージを焼く

前項で作成したISOイメージを Linuxで CD-RW/DVD-RWメディアに焼くには以下のようにする。

まずライティングソフトとして wodimパッケージをインストールする。

sudo apt-get install wodim  

USB-ODDは、おそらく /dev/sr0 等に見えるだろう。wodimコマンドの -scanbusオプションは SCSIバス以外には機能しないので、dmesgでデバイスノードを確認する。

sudo wodim dev=/dev/sr0 --devices  
wodim: Overview of accessible drives (1 found) :  
-------------------------------------------------------------------------
 0  dev='/dev/sr0'      rwrw-- : 'Slimtype' 'eTAU108   1'
-------------------------------------------------------------------------

CD-RW/DVD-RWメディアをブランク消去するには wodimコマンドの blankオプションを使う。

sudo wodim dev=/dev/sr0 blank=fast  

wodimコマンドにISOイメージファイルを与えると、それを指定のドライブに焼きこむ。

sudo wodim -sao -eject dev=/dev/sr0 ubuntu-15.04-desktopless-amd64.iso  

persistentモードを設定する

前述の ISOイメージ/光学メディアで ODDブートが正常に行えたなら、次はその ISOイメージを USBインストーラでもって、今度は persistentモードを設定した USBメモリを作成しよう。

persistentモードが有効な USBメモリは、kernel起動オプションに persistentが加わり、USBメモリのルートに casper-rwというファイルが作成される。このファイルの実体は overlayfsを用いて /に重ねられた ext4フォーマットの loopbackマウントファイルだ。/rofsにマウントされた filesystem.squashfsとの変更差分は、この casper-rwに記録されるようになる。

df -Th  
Filesystem     Type      Size  Used Avail Use% Mounted on  
udev           devtmpfs  3.9G     0  3.9G   0% /dev  
tmpfs          tmpfs     798M  8.6M  789M   2% /run  
/dev/sda       vfat      2.0G  1.5G  468M  76% /cdrom
/dev/loop0     squashfs  182M  182M     0 100% /rofs
/cow           overlay   976M   14M  895M   2% /
tmpfs          tmpfs     3.9G     0  3.9G   0% /dev/shm  
tmpfs          tmpfs     5.0M     0  5.0M   0% /run/lock  
tmpfs          tmpfs     3.9G     0  3.9G   0% /sys/fs/cgroup  
tmpfs          tmpfs     3.9G     0  3.9G   0% /tmp  
tmpfs          tmpfs     798M     0  798M   0% /run/user/999  

persistentモードが正しく効いているかどうかは、更新したログインパスワードやネットワーク設定が再起動しても正しく機能するか否かで容易にわかる。例えばrootアカウントでログイン可能にし、ubuntuアカウントを無効にして新たにadminユーザを作成し、rootとadminにパスワードを設定してみよう。

sudo -s

usermod -U root

passwd root  
Enter new UNIX password:  
Retype new UNIX password:  
passwd: password updated successfully

usermod -L ubuntu

addgroup --system admin  
Adding group `admin' (GID 112) ...  
Done.

useradd -s /bin/bash -g admin -m -k /dev/null admin

passwd admin  
Enter new UNIX password:  
Retype new UNIX password:  
passwd: password updated successfully  

/etc/network/interfaces に記述したネットワーク設定も persistentモードでなら起動時に反映される。¹⁶

source-directory /etc/network/interfaces.d

auto lo  
iface lo inet loopback

auto eth0  
iface eth0 inet static  
    address 192.168.240.135
    network 192.168.240.0
    netmask 255.255.255.0
    broadcast 192.168.240.255
    gateway 192.168.240.1
    dns-nameservers 192.168.240.1 8.8.8.8 8.8.4.4

auto eth4  
iface eth4 inet dhcp  

persistentモードで記録された内容を無視してデフォルト状態で起動するには、ブートメニューの起動ラベル選択時に persistentラベルを取り除けば良い。あるいは casper-rwファイルをリネームして再起動してしまう。¹⁷

cd /cdrom  
mv casper-rw casper-rw.bak  
reboot  

新たな（まっさらの）1GiBの casper-rwファイルは Linux上では以下の手順で作成できる。また事のついでなので、Windows上からもこのファイルを容易に置き換えられるように、フォーマットしたばかりの casper-rwファイルを zipコマンドで圧縮バックアップしておくと、USBインストーラを使わなくても最初期化できるので、いざというとき何かと便利だ。¹⁸

cd /cdrom

rm -f casper-rw.bak

truncate -s $((2**30)) casper-rw

ls -l casper-rw  
-rwxr-xr-x 1 root root 1073741824 Jun 18 13:11 casper-rw

mkfs.ext4 -L casper-rw casper-rw


apt-get install zip

zip casper-rw.zip casper-rw  

なお FAT32での最大のファイルサイズは 4GiB-1バイトなので、truncateコマンドでの容量指定は$((2**32-1))となる。¹⁹

ダウンロード

ubuntu-15.04-desktopless-amd64-20150703.iso 174MiB (md5sum)

OSXの場合

OSXの場合、AppKit/FrameworkのNSEvent->modifierFlagsを利用することでModefierKeyのビットフラグ値¹を取得することが出来る。OSX付属のPerlやPythonにはAppKitのバインディングが標準でインストールされているため、例えばPerlでは以下のようにすればビットフラグ値を標準出力へ返すことが出来る。コメント他を除けば実質5行だ。

#!/usr/bin/perl

=comment=
enum {  
   NSAlphaShiftKeyMask  = 1 << 16,
   NSShiftKeyMask       = 1 << 17,
   NSControlKeyMask     = 1 << 18,
   NSAlternateKeyMask   = 1 << 19,
   NSCommandKeyMask     = 1 << 20,
   NSNumericPadKeyMask  = 1 << 21,
   NSHelpKeyMask        = 1 << 22,
   NSFunctionKeyMask    = 1 << 23,
   NSDeviceIndependentModifierFlagsMask  = 0xffff0000U 
};
=cut=

use strict;  
use warnings;  
use Foundation;

@NSEvent::ISA = qw(PerlObjCBridge);

my $AppKit = '/System/Library/Frameworks/AppKit.framework';  
NSBundle->bundleWithPath_($AppKit)->load;

print +(NSEvent->modifierFlags);  
exit 0;

__END__  

Bashスクリプト等からModefierKey状態を扱いたい場合はこのスクリプトコマンドを呼び出せば充分用が足りる。

#/bin/bash
printf '%x¥n' $(modefierkey.pl)  

#/bin/bash
(($(modefierkey.pl) && 2**17)) && echo ShiftDown || echo ShiftUp

Windowsの場合

前述のコードを Windows Visual Basic² に転写すると次のようになる。OSXで言うcommandキー、fnキーに相当するものはないが、代わりにScrollLockキーを取得することが出来る。

Module Module1

    Sub Main()

        'OSX Cocoa
        'enum {
        '   NSAlphaShiftKeyMask  = 1 << 16,
        '   NSShiftKeyMask       = 1 << 17,
        '   NSControlKeyMask     = 1 << 18,
        '   NSAlternateKeyMask   = 1 << 19,
        '   NSCommandKeyMask     = 1 << 20,
        '   NSNumericPadKeyMask  = 1 << 21,
        '   NSHelpKeyMask        = 1 << 22,
        '   NSFunctionKeyMask    = 1 << 23,
        '   NSDeviceIndependentModifierFlagsMask  = 0xffff0000U 
        '};

        Dim intMask As Integer = 0

        If My.Computer.Keyboard.CapsLock Then
            intMask += 1 << 16
        End If
        If My.Computer.Keyboard.ShiftKeyDown Then
            intMask += 1 << 17
        End If
        If My.Computer.Keyboard.CtrlKeyDown Then
            intMask += 1 << 18
        End If
        If My.Computer.Keyboard.AltKeyDown Then
            intMask += 1 << 19
        End If
        If My.Computer.Keyboard.NumLock Then
            intMask += 1 << 21
        End If
        If My.Computer.Keyboard.ScrollLock Then
            intMask += 1 << 24
        End If

        Console.Write(intMask)
    End Sub

End Module  

Nw.jsの場合

そもそもコンソールプラットフォームであるNode.jsではModefierKeyを取得する手段は用意されていない³が、Nw.jsではGUIウィンドウが存在するのでそちらのwindow.eventからAlt/Ctrl/Shiftの3種類のキー状態真偽値を取得することが出来る。ChromiumベースのGUIプラットフォームなのだからこれは出来て当然だ。

<script language="javascript">
switch (true) {  
  case window.event.altKey   : console.log('altKey');   break;
  case window.event.ctrlKey  : console.log('ctrlKey');  break;
  case window.event.shiftKey : console.log('shiftKey'); break;
}
</script>

ただし注意が必要なのは、ウィンドウ本体を示すwindowグローバルオブジェクトはGUI内の<script>タグでロードされたコードのほうにしか継承されていない点⁴だ。つまりpackage.jsonのnode-mainでバックグラウンドロードされたNode.jsネイティブなコードの方からは直接使えない。また当然のことながらウィンドウ表示前・初期化前にはこれらのキー状態を取得出来ないという制約もある。故に「Altキーを押しながらドロップダウンメニューを開いた場合は内容をかえる」といった使いドコロになる。

艦板ではどうしたか

艦板では結局GUI初期化前にModefierKey状態をしたかったので、外部コマンドを child_process.execSync() で呼び出して結果を得るようになっている。ちなみにこの時の動作はWindows版の場合；

• ModefierKeyを調べて押されていなければそのまま起動継続する
• ModefierKeyが押されていた場合でも、キャッシュクリア済であったならそのまま起動継続する
• キャッシュクリアされていなかったら外部キャッシュクリアコードにexecして自分は終了する
• 外部キャッシュクリアコード⁵は自分でModefierKeyを再確認し、キャッシュフォルダを掃除したあとに艦板をexecして自身は終了する

・・・などと存外面倒なことをやっている。

CentOS6/Linux

CentOSの場合、nodejsとnpmの各パッケージはEPELレポジトリに収録されている。EPELを使用可能にするにはこちらを参照のこと。これが済んでいればyumだけで基本環境のインストールが出来る。

sudo yum install nodejs npm  

ただしこれでOSにインストールされるのはやや古いバージョンである。

$ node -v
v0.10.33  
$ npm -v
1.3.6  

異なるバージョンのNode.jsが必要な場合はnvmを使用して切り替える。まずnvmコマンドをgitでダウンロードし、添付のスクリプトを実行して導入する。¹

$ git clone https://github.com/creationix/nvm.git ~/.nvm
Initialized empty Git repository in ~/.nvm/.git/  
remote: Counting objects: 3595, done.  
remote: Compressing objects: 100% (20/20), done.  
remote: Total 3595 (delta 7), reused 0 (delta 0), pack-reused 3574  
Receiving objects: 100% (3595/3595), 765.49 KiB | 304 KiB/s, done.  
Resolving deltas: 100% (2060/2060), done.

$ source ~/.nvm/nvm.sh

nvmコマンドはエイリアスとしてシェル環境変数に組み込まれるため、新たな端末を開く度にnvm.shを再実行する必要がある。毎回使用するなら~/.bashrc等に追記しておくと良い。

初期状態ではsystemインストールされたNode.jsが使われているのでnvm currentを実行するとsystemが返る。

$ nvm current
system

$ which node
/usr/bin/node

取り敢えず最新のNode.jsを使えるようにするには次のようにするだけで良い

$ nvm install 0
######################################################################## 100.0%
Now using node v0.12.2 (npm v2.7.4)

$ nvm current
v0.12.2

$ node -v
v0.12.2

$ which node
~/.nvm/versions/node/v0.12.2/bin/node

上記のようにnvmでインストールされるnodeコマンドは、ユーザ環境毎に独立している。環境切替はシェル環境変数に依るので、systemサービスレベルでNode.jsを使用する場合は注意しなければならない。

なおsystemおよびnvmで導入したnodeコマンドと各グローバルnode_modulesパスは次のようになる。これはつまりnpm install -gで書き換えられる先がsudo不要になるということでもある。

|＼|system|nvm|
|-:|:-|:-|
|node|/usr/bin/node|~/.nvm/versions/node/[VER]/bin/node|
|npm|/usr/bin/npm|~/.nvm/versions/node/[VER]/bin/npm|
|modeules|/usr/lib/node_modules|~/.nvm/versions/node/[VER]/lib/node_modules|

Mac OSX

Mac OSXの場合、公式サイトからインストーラパッケージをダウンロードしてきて実行するのがもっとも手軽だろう。だがnpmコマンドで各モジュールをインストールする段階でネイティブビルド環境（Xcode）を要求されたりすると途端に面倒なことになり、最終的な手間は以下のどれをとっても結局は大差なくなる。

1. 公式サイトからインストーラを得て導入（/usr/local/bin/node）
2. 公式サイトまたはGitHubからソースを得て./configure && make
3. Mac Ports環境で port install nodejs（/opt/local/bin/node）

1番以外は結局Xcodeがなければ話にならない。なおXcode（それ自体はAppStoreから入手できる）のコマンドライン・デベロッパ・ツールの追加インストールは以下のコマンドをターミナルで実行する。²

$ xcode-select --install

nvmでのバージョン切替はLinuxと同じなので前項を参照のこと。

Windows

Windowsの場合はだいたい以下のシナリオがある。

1. 公式サイトからインストーラを得て導入
2. Visual Studio（Expressの場合はfor Web）にNTVSアドオンを追加する
3. CygwinあるいはMinGW環境でGitHunソースからmakeする
4. nodistで導入する

基本は1番だが、おすすめはWindowsらしい強力なIDEと一体化できる2番を更に追加した環境だ。開発PCでは1+2番、サービスサーバでは1番だけという使い分けが良いだろう。3番は余程の物好きでない限りおすすめしかねる。4番はもはやふるいやり方だがZIP配布なのでレジストリを汚すこともなくコンパクトな環境を作れるが環境変数設定等は全て手動なのでGUIインストーラを使えない場合の代替手段と見たほうが良い。^{3 4}

nvmでのnodeバージョン管理はnvmwとnvm-windowsの2通りの実装がある。
前者はPython2.7+が更に必要なので、ActivePython等のインストールが要求される。後者ならスタンドアロンインストーラ配布なので手軽だ。

OSX(Marvericks/Yosemite)の場合

まずはOSXでの話。テスト用には前掲【OSX用アイコンファイルをWindows上で作る】のmkosxicns.plを使ってmultisize.icnsという.icnsファイルを作成した。これには以下のアイコンが含まれている。

これをファインダーで表示したりアプリケーションアイコンに設定したりしてみる。OSXはMarvericksとYosemiteを使用したがどちらも結果は変わらなかった。

|表示サイズ|状況|
|:-:|:-|
|16x16|リスト表示<br>カラム表示<br>デスクトップ/アイコン表示(最小)|
|32x32|デスクトップ/アイコン表示(17〜32)|
|32x32@2x<br>(64x64)|デスクトップ/アイコン表示(サイズ33〜64)|
|128x128|デスクトップ(最大)<br>アイコン表示(65〜128)|
|256x256|アイコン表示(129〜256)<br>Cover Flow(最小〜256)|
|512x512|アイコン表示(257〜512)<br>Cover Flow(257〜512)|
|512x512@2x<br>(1024x1024)|プレビュー<br>Cover Flow(513〜最大)|

.icnsファイルはマルチ解像度なので必要な場面でもっとも適切な解像度のアイコンが自動的に選択される。その結果7種類の画像サイズすべてが何らかの形で出現した。Retina用@2xについても特別扱いしている様子はない。またプレビューについては常に使用可能な最大解像度が選択されるがこれはプレビューの性質からして妥当だろう。

アプリアイコン(OSX)

|表示サイズ|Retina(HiDPI)|状況|
|:-:|:-:|:-|
|16x16|16x16@2x<br>(32x32)|リスト表示<br>カラム表示<br>デスクトップ/アイコン表示(最小)|
|32x32|32x32@2x<br>(64x64)|デスクトップ/アイコン表示(17〜32)|
|128x128|128x128@2x<br>(256x256)|ドックアイコン<br>デスクトップ(33〜最大)<br>アイコン表示(33〜128)|
|256x256|256x256@2x<br>(512x512)|アイコン表示(129〜256)<br>Cover Flow(最小〜256)<br>プレビュー|
|512x512|512x512@2x<br>(1024x1024)|アイコン表示(257〜512)<br>Cover Flow(257〜最大)|

一方この.icnsファイルをアプリアイコンに設定した場合、同一リソースなのに使用されるファイルが5種類になる。つまり標準解像度ではRetina用アイコンが、Retina環境では標準解像度アイコンが選択されない。そしてこの5種類の中に64x64の等倍は含まれていないので、その上の128x128が使用されるようになるのだ。このため.icnsファイルと並べると、ファインダー設定のアイコン表示サイズによっては見映えが変わったり両者が混在して表示されたりする。

Windows 8.1 Updateの場合

次はWindowsでの話。こちらもOSX版と同様にマルチ解像度のマルチサイズ.icoファイルを用意した。これは以下の35種類のアイコンサイズに対応する。¹

.icoファイルの場合、収録可能な最大のアイコンサイズは256x256に制限される。一方で縦横サイズは任意に指定でき、実は正方形ではない長方形画像²も登録できる。また画像形式もVista以降はαチャンネル付透過True Color PNGフォーマットが使用できるようになった。ただしPNG形式アイコンでは表示に不具合がでる場面もあるため、旧来のDIB形式の.icoファイル multisizedib.icoと、PNG形式だけを集めた multisizepng.icoの2種類を用意した。

Windowsのアイコンの扱いについてはMSDNの該当ページ³が一次資料となるが、Explorerでは基本的には以下のようになる。

|96dpi<br>100%|120dpi<br>125%|144dpi<br>150%|192dpi<br>200%|状況|
|16x16|←|←|←|タスクバー（小・実行アプリ）<br>ウィンドウタイトル|
|16x16|20x20|24x24|32x32|タスクバー（小・ピン留め・ショートカット）<br>リストアイテム<br>Explorer（小）|
|32x32|←|←|←|タスクバー（中・実行アプリ）<br>ダイアログアイコン|
|32x32|40x40|48x48|64x64|タスクバー（中・ピン留め・ショートカット）<br>Explorer(コンテンツ)|
|48x48|60x60|72x72|96x96|Explorer（中・並べて表示）|
|256x256|←|←|←|Explorer（大・特大）|

このうちアプリケーションを直接起動した場合のウィンドウタイトル・タスクバー・ダイアログアイコンについてはコントロールパネルのテキストとその他の項目の大きさ設定にかかわりなく常に16x16と32x32に固定⁴される。またExplorer（大・特大）表示については原則として.icoファイルに収録された最大サイズのものがアイコンプレビューに選ばれる。

アプリケーションでもショートカットやピン留めから起動した場合、タスクバーアイコンについてはショートカットに登録されたアイコンが使用され、その場合はマルチ解像度が有効になる。

Windows 10 Tecnical Preview の場合

ところで、Windows10はまだ開発中ということもあるが、TP版にはタスクバーのアイコン表示に問題が有る。少なくとも以下の2点が判明している。

• タスクバー設定が標準の場合、アイコン表示サイズが実サイズの75%に縮小される。（32x32->24x24、48x48->36x36）
  ただしタスクバー表示が小アイコン設定の場合の16x16表示には問題がない。
• ショートカット・ピン留めでPNG形式アイコンを使用した場合、マスクプレーン（透過色切り抜き）が2ピクセル右にずれる。
  
  
  左がアプリケーション直接、右がショートカットから起動した場合でいずれもPNG形式アイコンだが、右のものには黒いゴミが付いている。これはアイコンを角丸にするためのマスクプレーン（PNG画像のαチャンネル）がずれて重ねられているためだ。DBI形式の場合はこのようにはならない。⁵

iOSアプリ用アイコンの場合

iOSの場合、使われる場面によってアイコンサイズが決められているため、用意する面倒を無視すれば悩む要素はない。ただしその規定サイズはiOSのバージョンによって異なり、マルチバージョン対応とする場合は当然準備しなければならない数が増える。以下はその対応一覧表だ。概ねホーム画面・設定画面・Spotlight検索⁶の3場面各々に標準解像度とRetina解像度が必要になる。iOS8の場合さらに大画面iPhone用の3倍精度が追加された。

|サイズ|iOS6|iOS7|iOS8|主な用途|
|:-|:-:|:-:|:-:|:-|
|29x29|◯|◯|◯|iPhone Spotlight(6)<br>iPhone設定(6)<br>iPad設定(78)|
|29x29@2x|◯|◯|◯|iPhone設定(67)<br>iPad設定(78)|
|29x29@3x|✕|✕|◯|iPhone設定(8)|
|40x40@2x|✕|◯|✕|iPhone Spotlight(7)|
|40x40@3x|✕|✕|◯|iPhone Spotlight(8)|
|50x50|◯|✕|✕|iPad Spotlight(6)<br>iPad設定(6)|
|50x50@2x|◯|✕|✕|iPad Spotlight(6)<br>iPad設定(6)|
|57x57|◯|✕|✕|iPhoneホーム(6)|
|57x57@2x|◯|✕|✕|iPhoneホーム(6)|
|60x60@2x|✕|◯|✕|iPhoneホーム(7)|
|60x60@3x|✕|✕|◯|iPhoneホーム(8)|
|72x72|◯|✕|✕|iPadホーム(6)|
|72x72@2x|◯|✕|✕|iPadホーム(6)|
|76x76|✕|◯|◯|iPadホーム(78)|
|76x76@2|✕|◯|◯|iPadホーム(78)|
|512x512@2|-|-|-|iTunes Store<br>App Store|

ダウンロード

• multisize.icns MacOS用
• multisizedib.ico Windows用(DIB)
• multisizepng.ico Windows用(PNG)

動機

艦板-KanPan- を開発するとき、最初からMacintoshとWindows両方に対応すると決めていたが、その際両者でフォーマットが異なるアイコンリソースをどうするかという問題があった。OSXでは.icns、Windowsでは.icoというファイル形式が使われる。それぞれを他方のプラットフォーム上のコマンドラインから作成できれば、make作業を一方の上で完結できる。とりあえず資料が豊富な.icoは放っておいて.icnsについて調べてみたところ意外と簡単な方法で作成できることが分かった。

iconutil ユーティリティ

OSX添付の純正アイコンリソース作成ユーティリティはiconutilという。このCLIコマンドは以下のように使用する。

• 以下の10個のフルカラーPNG画像(RGBA)を格納したfoo.iconsetというフォルダを作成する。アイコンファイル名は厳密にこの通りであり、フォルダ名の.iconsetという拡張子もこの通りでなければならない。

|ファイル名|画像サイズ|
|:-|:-:|
|icon_16x16.png|16x16|
|icon_16x16@2x.png|32x32|
|icon_32x32.png|32x32|
|icon_32x32@2x.png|64x64|
|icon_128x128.png|128x128|
|icon_128x128@2x.png|256x256|
|icon_256x256.png|256x256|
|icon_256x256@2x.png|512x512|
|icon_512x512.png|512x512|
|icon_512x512@2x.png|1024x1024|

• ターミナルで以下のように実行するとカレントディレクトリにfoo.icnsというアイコンファイルが作成される。

iconutil -c icns foo.iconset  

10個のファイル（画像サイズ自体は7種類）を用意しろというのは御無体だが、これはまあ原画をSVG形式で作成して所定サイズとファイル名のPNG画像にコンバートすればなんとかなる。ともかく出来上がった.icnsファイルを調べてみると次のようになっていた。

ICNSファイルフォーマット

ICNSファイルは次のような構造になっている

|:-:|
|ICNSファイルヘッダ|
|アイコンヘッダ|
|アイコンデータ|
|アイコンヘッダ|
|アイコンデータ|
|:|

まずファイル先頭にICNSファイルヘッダがあり、その後ろにアイコンヘッダとアイコンデータの組（ブロック）が任意個数続く。

ICNSファイルヘッダ

ICNSファイルヘッダの大きさは8バイトで、以下の2フィールドを持つ。

|Offset|Length|内容|
|-:|-:|:-|
|0|4|ファイル識別子`ICNS` (リテラルバイト文字列 0x69 0x63 0x6e 0x73)|
|4|4|ICNSファイル全体のバイナリサイズ (MSB First/Big Endian)|

先頭の4バイトがファイル識別子なのはMachintosh系データフォークの伝統だ。

アイコンヘッダ

アイコンヘッダの大きさは8バイトで、以下の2フィールドを持つ。

|Offset|Length|内容|
|-:|-:|:-|
|0|4|アイコンタイプ識別子（リテラルバイト文字列）|
|4|4|ブロック長(アイコンヘッダ＋アイコンデータの合計バイト長) (MSB First/Big Endian)|

アイコンタイプ識別子もまた４バイトのリテラル文字列で、これがアイコンデータの画像表示サイズと画像フォーマットとを示している。続くフィールドは後続するアイコンデータのバイナリサイズ+8に一致する。

アイコンデータ

これのデータフォーマットはアイコンタイプ識別子によって規定されるが、iconutilが作成するファイルの場合はPNG画像ファイルデータそのままかRGB生データかマスクデータである。とにかくPNG形式のアイコン識別子が付いていたならPNGファイルがそのまま埋め込まれているので、何も難しいことはない。

アイコンタイプ識別子一覧

iconutilが作成するアイコンファイルに含まれるアイコン識別子の一覧を次に示す。なお識別子のレターケースは区別される。

|Type|Length|Size|MacOS|詳細|
|:-:|:-:|:-:|:-:|:-|
|ic07|可変|128x128|10.7+|128x128 PNG/JPEG2000|
|ic08|可変|256x256|10.5+|256x256 PNG/JPEG2000|
|ic09|可変|512x512|10.5+|512x512 PNG/JPEG2000|
|ic10|可変|1024x1024|10.7+|1024x1024 PNG/JPEG2000 (1024x1024, 512x512@2x)|
|ic11|可変|32x32|10.8+|32x32 PNG/JPEG2000 (16x16@2x)|
|ic12|可変|64x64|10.8+|64x64 PNG/JPEG2000 (32x32@2x)|
|ic13|可変|256x256|10.8+|256x256 PNG/JPEG2000 (128x128@2x)|
|ic14|可変|512x512|10.8+|512x512 PNG/JPEG2000 (256x256@2x)|
|il32|可変|32x32|8.5+|32x32 24bit TrueColor RGB|
|is32|可変|16x16|8.5+|16x16 24bit TrueColor RGB|
|l8mk|1,024|32x32|8.5+|32x32 8bit MASK|
|s8mk|256|16x16|8.5+|16x16 8bit MASK|

ic11からic14はRetinaディスプレイ用に追加されたもので、それぞれその半分の画像サイズのアイコンと対応している。ic10はRetina対応であると同時にOSX10.7以降のデフォルトアイコンサイズである。極端な話、このic10さえあれば、OSX10.7以降のファインダー＆ドック表示はすべて可能になる。

一方で以下のアイコンタイプも10.7で登場したのだが iconutil では生成されないようだ。代わりに非Retina用等倍の16x16と32x32についてはOSX10.7のものではなくMaxOS8.5のアイコンフォーマットにコンバートして収録されている。これは後方互換性を維持するためだろう。

|Type|Length|Size|MacOS|詳細|
|:-:|:-:|:-:|:-:|:-|
|icp4|可変|16x16|10.7+|16x16 PNG/JPEG2000|
|icp5|可変|32x32|10.7+|32x32 PNG/JPEG2000|
|icp6|可変|64x64|10.7+|64x64 PNG/JPEG2000|

MacOS8.5形式アイコンフォーマット

il32とl8mk、is32とs8mkはそれぞれアイコンカラーデータとアイコンマスクデータのペアとして使用される。常にペアであるため個々に単独の画像ファイルとしては現れず、少なくとも2ブロックから成る.icnsファイルとして存在する。

アイコンカラーデータは1画素あたりRGB24bitだが、RGBそれぞれ別の(8bpp)プレーン毎に、連続する左上原点ビットマップデータ列をPackBitsしてまとめられている。

|Offset|Length|詳細|
|-:|-:|:-|
|0|4|アイコンタイプ識別子`il32` (0x69 0x6c 0x33 0x32)|
|4|4|ブロック長 (MSB First)|
|8|可変|Rプレーン1,024バイトのPackBitsデータ|
|?|可変|Gプレーン1,024バイトのPackBitsデータ|
|?|可変|Bプレーン1,024バイトのPackBitsデータ|

|Offset|Length|詳細|
|-:|-:|:-|
|0|4|アイコンタイプ識別子`is32` (0x69 0x73 0x33 0x32)|
|4|4|ブロック長 (MSB First)|
|8|可変|Rプレーン256バイトのPackBitsデータ|
|?|可変|Gプレーン256バイトのPackBitsデータ|
|?|可変|Bプレーン256バイトのPackBitsデータ|

アイコンマスクデータも同様に1画素あたり8bit(8bpp)の連続する左上原点ビットマップデータ列だが、無圧縮のベタデータとして定義されている。

これはPNG画像フォーマットのアルファチャンネルと実質同じもので、アイコン画像の背景デスクトップからの切り抜きとアンチエイリアス表現を実現する。 なお画像縦横サイズについてはアイコンタイプ識別子で一意に決定されるためデータブロック内には現れない。

|Offset|Length|詳細|
|-:|-:|:-|
|0|4|アイコンタイプ識別子`l8mk` (0x6c 0x38 0x6d 0x6b)|
|4|4|ブロック長 (MSB First)|
|8|1,024|MASKプレーンの8bppビットマップデータ|

|Offset|Length|詳細|
|-:|-:|:-|
|0|4|アイコンタイプ識別子`s8mk` (0x73 0x38 0x6d 0x6b)|
|4|4|ブロック長 (MSB First)|
|8|256|MASKプレーンの8bppビットマップデータ|

PackBits連長圧縮アルゴリズム

カラープレーンのビットマップは生データではなく、PackBitsと呼ばれる連長圧縮アルゴリズムでコンバートされている。これは古き良きMacintosh時代の、PICT (QuickDraw PICTure)ファイルフォーマットで用いられていたものだからとうぜん当時の資料を調べれば詳細を知ることが出来る。そのPackBitsデータ列は次のように解釈すれば元のビットマップデータへ復元・展開できる。

• ポインタ上の1バイトが128未満（MSBが0）であるならこのバイトが示す0〜127に1を加え、次のそのバイト数（1〜128バイト）を取り出してそのまま出力し、ポインタを進める。
• ポインタ上の1バイトが128以上 （MSBが1）であるならこのバイトが示す128〜255から125を引き、取り出した次の1バイトをその回数（3〜130回）繰り返して出力し、ポインタを進める。

このPackBitsの圧縮アルゴリズムを真面目に実装しようとするとそれなりに面倒だが抜け道はある。無圧縮でよしと妥協すれば、128バイト毎にバイトストリームを切り刻み、0x7Fを前置した129バイトブロックに整えて横流しすればすむのである。32x32画素プレーンと16x16画素プレーンのいずれも128バイトの整数倍バイト長なのだから全く不都合はない。32x32画素プレーンなら計8ブロック1,032バイト、16x16画素プレーンなら計2ブロック258バイトの固定長データとして処理してしまえる。

unosxicns.pl

ここまで解ってしまえばあとはもう悩むことはない。unosxicns.plは以上の情報をまとめて .icnsファイルから .png¹ファイルを抽出するように記述したものだ。ActivePerl(5.10+)²と ImageMagick(PerlMagick)³で動作する。OSX他でも MacPortsで同等の環境を揃えれば動作する。

使い方は引数に .icnsファイルを指定すると同名の .iconsetディレクトリを作成してその中に抽出したicon_NNNxNNN.pngを生成、あるいは-tオプションを付加した場合はアイコンタイプ.pngを生成する。前掲のアイコンタイプ以外は対応外として無視する。

unosxicns.pl -t foo.icns

ls foo.iconset  
ic07.png              ic08.png              ic09.png  
ic10.png              ic11.png              ic12.png  
ic13.png              ic14.png              il32.png  
is32.png  

#!/usr/bin/perl
# $Id: unosxicns.pl 122 2015-03-16 04:06:57Z askn $ ＵＴＦ８

use 5.010;  
use strict;  
use warnings;  
use File::Basename;  
use Image::Magick;  
use Getopt::Std;

my %iconset = (  
    ic07 => [128,  1],
    ic08 => [256,  1],
    ic09 => [512,  1],
    ic10 => [1024, 2],
    ic11 => [32,   2],
    ic12 => [64,   2],
    ic13 => [256,  2],
    ic14 => [512,  2],
    icp4 => [16,   1],
    icp5 => [32,   1],
    icp6 => [64,   1],
    is32 => [16,   0],
    il32 => [32,   0],
    s8mk => [16,   0],
    l8mk => [32,   0],
);

our($opt_t);  
getopts("t");

unless (scalar @ARGV) {  
    die "Usage: unosxicns.pl [-t] icon.icns [...]\n";
}

my %cache;  
my $dirname = dirname($0);  
foreach my $argv (@ARGV) {  
    foreach my $glob (glob $argv) {
        my $filename = $glob;
        my $basename = basename $filename, qw{.svg .png .ico .icns .icowin .iconset};
        my $folder = $basename . ".iconset";
        $filename = $basename . ".icns";
        next if $cache{$filename};
        die "file not found $filename\n" unless -f $filename;
        $cache{$filename} = 1;
        &mkpict($filename, $folder);
    }
}
exit;

# アイコンブロックの抽出
sub mkpict {  
    my $filename = shift;
    my $folder = shift;
    my %maskset;
    mkdir $folder, 0777;
    my($FH, $GH, $buff);
    unless (open $FH, "<", $filename) {
        die "Cant read input\n";
    }
    binmode $FH;

    # 先頭のアイコンヘッダ8バイトの取得
    die "Read error\n" unless sysread($FH, $buff, 8);
    my($filetype, $filesize) = unpack "A4N", $buff;
    die "Not ICNS format\n" unless $filetype eq "icns";
    die "File size unmatch\n" unless $filesize == -s $filename;
    say "$filename filesize $filesize";

    # 各アイコンブロックについて
    while (sysread $FH, $buff, 8) {
        my($set, $ext, $outname, $scale);

        # アイコンブロックヘッダ8バイト
        my($icontype, $blocksize) = unpack "A4N", $buff;
        my $readsize = $blocksize - 8;
        die "Format broken\n"
            if $readsize < 1
                or $readsize != sysread $FH, $buff, $readsize;
        say "  type $icontype length $blocksize";

        # 未知のアイコンタイプ
        unless ($set = $iconset{$icontype}) {
            say "    undefined icon type";
            next;
        }

        # PNGまたはJPEG2000形式
        if ($scale = $set->[1]) {

            # PNGヘッダ確認
            $ext = ("\x89\x50\x4E\x47" eq substr $buff, 0, 4) ? "png" : "jp2";

            # -t付きの場合はアイコンタイプをファイル名にする
            if ($opt_t) {
                $outname = sprintf "%s.%s", $icontype, $ext;
            }

            # 倍密解像度の場合のファイル名
            elsif ($scale == 2) {
                $outname = sprintf "icon_%ux%u\@x2.%s",
                    $set->[0] >> 1, $set->[0] >> 1, $ext;
            }

            # 標準解像度のファイル名
            else  {
                $outname = sprintf "icon_%ux%u.%s",
                    $set->[0], $set->[0], $ext;
            }
            say "\t$outname size $readsize";

            # 画像データ書出
            unless (open $GH, ">", "$folder/$outname") {
                die "Cant write output\n";
            }
            binmode $GH;
            print $GH $buff;
            close $GH;
            next;
        }

        # MacOS8.5 mask raw format
        if ($icontype =~ /(s8mk|l8mk)/) {
            die "Mask broken,  length missmatch\n"
                unless $set->[0] ** 2 == length $buff;
            $maskset{$icontype} = [unpack "C*", $buff];
        }

        # MacOS8.5 Color PackBits format
        if ($icontype =~ /(is32|il32)/) {
            my @data;
            my @input = unpack "C*", $buff;

            # PackBits unpack
            while (scalar @input) {
                my $code = shift @input;
                if ($code < 128) {
                    push @data, splice @input, 0, $code + 1;
                }
                else {
                    my $next = shift @input;
                    push @data, ($next) x ($code - 125);
                }
            }
            die "PackBits broken,  length missmatch\n"
                unless $set->[0] ** 2 * 3 == scalar @data;
            $maskset{$icontype} = \@data;
        }
    }
    close $FH;
    &mkpngicon(\%maskset, "il32", "l8mk", $folder);
    &mkpngicon(\%maskset, "is32", "s8mk", $folder);
}

# RGBAからPNGファイルへの変換
sub mkpngicon {  
    my $maskset = shift;
    my $type = shift;
    my $color;
    return unless $color = $maskset->{$type};
    my $mask = shift;
    my $folder = shift;
    $mask = $maskset->{$mask};
    my $size = $iconset{$type}->[0];
    my $sqrt = $size ** 2;

    my $image = Image::Magick->new(magick=>'png', size=>"${size}x${size}", matte=>"True");
    $image->Read("NULL:");

    for (my $y = 0; $y < $size; $y++) {
        for (my $x = 0; $x < $size; $x++) {
            my @pixcels;
            $pixcels[0] = $color->[$y * $size + $x]             / 255; # R
            $pixcels[1] = $color->[$y * $size + $x + $sqrt]     / 255;    # G
            $pixcels[2] = $color->[$y * $size + $x + $sqrt * 2] / 255;    # B
            $pixcels[3] = $mask ? 1.0 - $mask->[$y * $size + $x] / 255 : 0.0; # A (Opacity)
            my $err = $image->SetPixel(x=>$x, y=>$y, color=>\@pixcels, channel=>'RGBA', normalize=>'True');
            say $err if $err;
        }
    }
    my $outname = sprintf "icon_%ux%u.png", $size, $size;

    # -t付きの場合はアイコンタイプをファイル名にする
    if ($opt_t) {
        $outname = sprintf "%s.png", $type;
    }

    say "\t$outname";
    my $err = $image->Write("$folder/$outname");
    die $err if $err;
}

1;  
__END__  

mkosxicns.pl

これでようやく本題に辿り着いた。mkosxicns.pl はunosxicns.plとは逆に .pngファイルから .icnsファイルを生成する。ActivePerl(5.10+)と ImageMagick(PerlMagick)の他、パスの通った場所に PhantomJS⁴がインストールされている必要がある。iconrast.jsは PhantomJSスクリプトで mkosxicns.plと同じ場所に置く。OSX他でもMacPortsで同等の環境を揃えれば動作する。

使い方は引数に-bオプションと .iconsetディレクトリを指定すると、iconutilと同等の動作を行って同名の .icnsファイルを生成する。

mkosxicns.pl -b foo.iconset  

もうひとつの使い方は-mオプションとSVGファイル⁵を指定することで、iconutilが必要とする10個のPNGファイルを含む .iconsetディレクトリを自動的に生成する動作だ。

mkosxicns.pl -m foo.svg  

両者は-mbオプションを指定して実行することで同時に行うことが出来る。すなわち以下の場合 foo.svgファイルから foo.iconsetディレクトリを作成し foo.icnsファイルを生成する。

mkosxicns.pl -mb foo.svg  

#!/usr/bin/perl
# $Id: mkosxicns.pl 122 2015-03-16 04:06:57Z askn $ ＵＴＦ８

use 5.010;  
use strict;  
use warnings;  
use File::Basename;  
use Image::Magick;  
use Getopt::Std;

my @fileset = (  
    [128,  "icon_128x128.png",     "ic07"],
    [256,  "icon_256x256.png",     "ic08"],
    [512,  "icon_512x512.png",     "ic09"],
    [1024, "icon_512x512\@2x.png", "ic10"],
    [32,   "icon_16x16\@2x.png",   "ic11"],
    [64,   "icon_32x32\@2x.png",   "ic12"],
    [256,  "icon_128x128\@2x.png", "ic13"],
    [512,  "icon_256x256\@2x.png", "ic14"],
    [32,   "icon_32x32.png",       "icp5"],
    [16,   "icon_16x16.png",       "icp4"],
);

our($opt_m, $opt_b);  
getopts("mb");  
unless (($opt_m || $opt_b) && 1 == scalar @ARGV) {  
    die "Usage: mkosxicns.pl -mb icon[.svg] [...]\n";
}

my %cache;  
my $dirname = dirname($0);  
my $phantomjs = "phantomjs";  
my $rasterize = $dirname . "/iconrast.js";

foreach my $argv (@ARGV) {  
    foreach my $glob (glob $argv) {
        my $filename = $glob;
        my $basename = basename $filename, qw{.svg .png .ico .icns .icowin .iconset};
        my $folder = $basename . ".iconset";
        if ($opt_m) {
            $filename = $basename . ".svg";
            die "file not found $filename\n" unless -f $filename;
        }
        next if $cache{$filename};
        say $filename;
        $cache{$filename} = 1;
        &mkpng($filename, $folder) if $opt_m;
        &mkico($basename, $folder) if $opt_b;
    }
}
exit;

# SVGからPNGへの変換
sub mkpng {  
    my $filename = shift;
    my $folder = shift;
    mkdir $folder, 0777;
    foreach my $set (@fileset) {
        printf "%s/%s\n", $folder, $set->[1];
        system $phantomjs , $rasterize, $filename, $set->[0] , $folder . "/" . $set->[1];
    }
    say "complete";
}

# ICNSファイル作成
my @maskset;  
sub mkico {  
    my $basename = shift;
    my $folder = shift;
    my $FH;
    unless (open $FH, ">", $basename . ".icns") {
        die "Cant write output\n";
    }
    binmode $FH;

    my $total = 0;
    my $data = "";
    my @iconset;
    foreach my $set (@fileset) {

        # PNGファイル読込
        my $path = $folder . "/" . $set->[1];
        my $blob;
        if (open my $FI, "<", $path) {
            binmode $FI;
            $blob = join '', <$FI>;
            close $FI;
        }
        unless (scalar $blob) {
            die "Cant read $path\n";
        }

        # MacOS8.5形式への変換
        if ($set->[2] eq "icp4") {
            &buildmaskset($path, "is32", "s8mk", 16, 1, 3);
            next;
        }
        elsif ($set->[2] eq "icp5") {
            &buildmaskset($path, "il32", "l8mk", 32, 0, 2);
            next;
        }

        # アイコンタイプヘッダ8バイトの付加
        my $length = length $blob;
        $data .= pack("A4N", $set->[2], $length + 8);
        $data .= $blob;
        printf "%u %s\n", length($data), $path;
    }

    # 全アイコンブロック連結
    $data .= join "", @maskset if scalar @maskset;

    # アイコンヘッダ8バイトの付加
    my $output = pack("A4N", "icns", length($data) + 8);
       $output .= $data;
    print $FH $output;
    close $FH;
    printf "%u complete", length($output);
}

# 24bitカラーと8bitマスク作成
sub buildmaskset {  
    my $path = shift;
    my $name = shift;
    my $mask = shift;
    my $size = shift;
    my $idxc = shift;
    my $idxm = shift;

    # PNGファイルを読み込んで全ピクセルを取得
    my $image = Image::Magick->new(magick=>'png');
       $image->Read($path);
       $image->Set(magick=>'png');
    my @input = $image->GetPixels(x=>0, y=>0,
        width=>$size, height=>$size, map=>"RGBA", normalize=>"true");

    # カラープレーン・マスクプレーンに分割
    my @plane = ([], [], [], []);
    for (my $y = 0; $y < $size; $y++) {
        for (my $x = 0; $x < $size; $x++) {
            for (my $i = 0; $i < 4; $i++) {
                push @{$plane[$i]}, int(255 * shift(@input));
            }
        }
    }

    # カラープレーンをPackBits
    my @encode = ("", "", "", pack("C*", @{$plane[3]}));
    for (my $i = 0; $i < 3; $i++) {
        my $buff = pack "C*", @{$plane[$i]};
        while (length $buff) {
            $encode[$i] .= chr(127) . substr($buff, 0, 128, "");
        }
    }

    # 各データを連結してヘッダ8バイトを付加
    my $buff = join "", @encode[0..2];
    $maskset[$idxc] = pack("A4N", $name, length($buff) + 8) . $buff;
    $maskset[$idxm] = pack("A4N", $mask, length($encode[3]) + 8) . $encode[3];
}

1;  
__END__  

// $Id: iconrast.js 121 2015-03-13 10:01:44Z askn $

var page = require('webpage').create(),  
    system = require('system'),
    address, output, size;

if (system.args.length != 4) {  
    console.log('Usage: rasterize.js URL size filename');
    phantom.exit(1);
}
else {  
    address = system.args[1];
    size = system.args[2];
    output = system.args[3];
    page.viewportSize = { width: size, height: size };
    page.open(address, function (status) {
        if (status !== 'success') {
            console.log('Unable to load the address!');
            phantom.exit();
        } else {
            window.setTimeout(function () {
                page.render(output);
                phantom.exit();
            }, 200);
        }
    });
}
// End of script

ダウンロード

本項で述べた mkosxicns.pl unosxicns.pl iconrast.js の3点セット。

mkosxicns.zip

UWSCヘルプファイル(HTML版) v5.2.0 2015/10/18版 (Shift_JIS)

UWSC

UWSC公式サイト

あなたが行っている定型作業は
時間の無駄だとは思いませんか
退屈だとは感じませんか。

• マウスとキーボード入力を記録して再生する事ができます。 （スクリプト形式ですので自由に編集する事ができます）
• 強力なスクリプト言語によりアプリの操作ができます。 （COMオブジェクト、DLLの利用も可能です）
• スケジュール機能により指定時間や指定ウィンドウが現れた時などの指定ができます。

以上、公式サイトからの引用。

コマンドプロンプトでのバッチ処理やPowerShell、CygwinからのCLI操作で事が済めばそれに越したことはないが、WindowsはやはりGUI主体のOSなので、CLI未対応アプリのほうが圧倒的多数だったりする。それでも定型作業のネタは尽きないし、どうにかしてGUI操作をバッチ処理できればルーチンワークのミス率が大幅に減るんじゃないかという懸念は常に付きまとう。UWSCはそんな時に役立つ強力なツールになりうる。

マウスやキーボード入力の操作過程をレコーディングして簡単に再生操作することもできるが、その操作内容を専用スクリプト言語で書き出せるので、これを編集加工したり、あるいはゼロから緻密にスクリプトをコーディングするほうが主だろう。

その専用スクリプト言語は、言語仕様がBASIC風である。例えばあるBMP画像とデスクトップ画面とを比較して見つかったか否かの真偽値と、見つかった場合の座標を得るにはこんなコードを書く。

// 画像チェック

If ChkBmp("検査画像") Then  
    // 成功すると特殊グローバル変数に取得した座標が入っている
    Print "X=" + G_IMG_X + " Y=" + G_IMG_Y
Else  
    Print "見つからなかった"
EndIf

Function ChkBmp (BmpName)  
    // Result はExitでコール元に返される特殊グローバル変数
    Result = Chkimg("Resources\" + BmpName + ".bmp")
    Exit
Fend  

この画像比較・座標取得という機能が万能すぎて目眩がする。「GUI OSの自動操作」というジャンルでは OSX 標準装備の Automator + Apple Script がよく知られるところだが、残念ながらこんな機能があるかまでは過分にして知らない。もしあったら多分みんなもっと積極的に使っていて一般化しているんじゃないかと思える。

そんな強力な UWSC の泣き所はやはりこの言語仕様だろう。組込関数も独特なものが多い。添付のヘルプファイルや世間に流通するサンプルコードは欠かせない資料だ。ところがこのヘルプファイルは古き良き .chm 形式である。これは Windows Vista 以降ではセキュリティ上の問題からもはや非推奨になっているフォーマットで、ヘルプビューワもOS標準からは取り除かれている。よって.chmファイルを開いて閲覧するには別途ダウンロードしてインストールするなり、Windows SDKを持ってくるなりしなければならない。それが1台だけならまだしも何台ものPCに入れなきゃならんとなると全くもってゲンナリしてくるし、まして普段使いの PCが Macなのだからそっちの広大なデスクトップでドキュメント参照しながらコーディングして実機でトライ＆デバッグするほうが生産的というものだ。

CHM Decoder

http://gridinsoft.com/chm.php ¹

CHM Decoder は .chm ファイルをHTMLファイルセットに変換してくれる Windowsアプリである。使い方はごく簡単で、アプリを起動して .chm ファイルを読み込ませ、出力フォルダを指定して結果を書き出すだけだ。.chm ファイルの日本語文字コードは Shift_JIS であるが特に文字化けすることもなくそのまま書き出される。出力結果がどんな様子になるかは実際に UWSCヘルプファイルを変換した先のリンクを見て頂きたい。ヘルプビューワにあった検索機能や印刷機能は損なわれるがHTML化してブラウザ上で閲覧・検索できるメリットのほうがたいていは上回るので、それほどのデメリットでもないだろう。