--- C:\Perl64\site\lib\SOAP\Transport\HTTP.pm    2016-12-17 10:45:40.000000000 +0900
+++ D:\Perl64\site\lib\SOAP\Transport\HTTP.pm    2017-01-23 12:42:33.000000000 +0900
@@ -586,6 +586,7 @@
         #my $content = q{};
         if ( !$chunked ) {
             my $buffer;
+            no strict 'subs';
             binmode(STDIN);
             if ( defined $ENV{'MOD_PERL'} ) {
                 while ( read( STDIN, $buffer, $length ) ) {

直接原因はよくわからんがとにかくこうすれば正常動作はした。STDIN が strict subs に引っかかるって通常ではちょっと考えにくいところだが？

// textareaでのTABキー入力
$('textarea').on('keydown', function(e){
    if (e.keyCode === 9) {
        e.preventDefault();
        var elem = e.target;
        var val = elem.value;
        var pos = elem.selectionStart;
        elem.value = val.substr(0, pos) + '\t' + val.substr(pos, val.length);
        elem.setSelectionRange(pos + 1, pos + 1);
    }
});

• e.keyCode === 9
  TABキー押し下げを検知する。
• e.preventDefault()
  ブラウザのデフォルト動作を停止する。つまりフォーカス移動をキャンセルする。
• e.target
  イベント対象のDOMエレメントを取得する。すなわち <textarea/> 本体。jQueryの $(this)[0] におなじ。
• elem.value
  入力されている <textarea/> の内容。
• elem.selectionStart
  キャレットカーソルの位置。次の行でこの位置に\tを挿入して書き戻している。
• elem.setSelectionRange(Start, End, [Direction])
  キャレットを\tの後ろへ進める。選択範囲は無いので Start と End にはおなじ値を指定する。

なお selectionStart/selectionEnd プロパティは直接書き換えることもできる。またキャレット選択範囲の後方は elem.selectionEnd で得られる。なので選択範囲があるなら丸ごとインデントするといったコードも書けなくはない。選択方向を指示する Direction はプラットフォームによって挙動が若干異なるのでこちら¹も参照のこと。

コンソールへのアラートを黙らせる

AR系や87xx系でファイアウォールを有効にすると、デフォルトではルールにないパケットを受信する度にマネージャ権限以上でログインしているコンソール（async/telnet/ssh）にアラート通知が流れてしまう。

XXX.XXX.XXX.XXX attempting to use non-policy interface

Denial of service attack from XXX.XXX.XXX.XXX is finished  

設定作業中にこれらが次々に流れてゆくと作業の邪魔も甚だしい（電源を切りたくなる）ので、次のコマンドでコンソールへのアラートは止めてしまおう。

disable firewall notify=manager  

UnTagポートにTagパケットが入ってきた時も attempting to use non-policyと怒られるので、VLAN変更をしている最中にも、これをしておくと結構助かる。

なおnotify=allにするとすべてのアラートが止まるが、ログにも残らなくなる。ファイアウォール設定が充分固まって逆に FIRE ATACK 通知で sh log が埋まるようになったら、全部止めたほうがむしろ都合が良いだろう。

時系列逆順ログ

コマンドラインヘルプ（?キーのあれ）では表示されないので気づきにくいが show log reverse (sh log rev) でログを時系列の逆順に見ることが出来る。最新のログだけ確認して Quitで抜けるのに便利だ。

> sh log rev

Date/Time   S Mod  Type  SType Message  
-------------------------------------------------------------------------------
27 17:58:21 3 IPG  IPFIL DUMP  Received invalid DA 8.240.213.66>22.103.89.96  
                               Prot=17 Int=ppp5
27 17:57:57 3 IPG  IPFIL FRAG  DirBcast Fail 6.102.80.241>22.103.89.103  
                               Prot=6 Int=vlan12
27 17:57:43 3 IPG  IPFIL FRAG  DirBcast Fail 19.6.240.45>22.103.89.103 Prot=6  
                               Int=vlan12

もちろん moduleと組み合わせて特定カテゴリのログだけ表示するときにも使える。

> sh log reverse module=ssh

Date/Time   S Mod  Type  SType Message  
-------------------------------------------------------------------------------
27 17:51:39 3 SSH  SSH   RJCT  Rejecting SSH connection from 43.29.53.43  
                               incompatible versions
27 17:43:23 3 SSH  SSH   RJCT  Rejecting SSH connection from 45.14.11.37  
                               incompatible versions
27 17:37:53 3 SSH  SSH   RJCT  Rejecting SSH connection from 43.29.53.51  
                               incompatible versions

この機能は AR5xxS系や8xxxXL系で使えるが、9424T/SP等では使えない。

Security Mode の有効時間を伸ばす

IPSec/PKI/SSH を有効化して SECURITYOFFICERユーザに切り替えると、デフォルトでは1分で再ログインを求められるようになる。いくらなんでもこれは短いと感じた時は、次のコマンドを打ち込む。

set user securedelay=3600  

設定可能な範囲は 10〜3600秒である。最短の10秒にすると相当の苦行を味わえるが、タイプ速度が上達する効能もある。

非同期ポートのボーレートを変更する

アラテレ製品では、管理用シリアルコンソールポートを非同期ポートと呼称する。初期値は baud=9600なのでこれを変更するには、次のようなコマンドを打ち込む。

set asyn=0 speed=115200

# 以下でも同じ（show conf dynの表示はこちら）
set asyn=asyn0 speed=115200  

打ち込んだ瞬間に設定が反映されるので、現在正に非同期ポートでログインしている場合は、対向端末側も設定を合わせるまで制御不能になることに注意しよう。

だがこの設定にかかわらず、機器ブート（起動時診断）メッセージは baud=9600固定である。従って動的にボーレートを変更できる端末ソフトを使っていないと思ったより難儀してしまう。結局できるだけ 9600固定で運用するほうがいざというとき慌てずに済むかもしれない。

なお設定内容は show asyn=0 で確認できる。

NTPモジュール

NTP時刻合わせのテンプレを以下に示す。ログ記録に関わるので、機器に IPを付したら真っ先に行う作業だ。

# NTPモジュールを活かして時差を指定する
enable ntp  
set ntp utc=+09:00:00

# peerアドレスは一つだけ書ける
# DNSモジュールを活かしていても FQDNでは指定できない。
add ntp peer=133.243.238.163

# 強制同期
# "ACTIVATE NTP" コマンドではない（そういうものはない）
reset ntp

# ステータス表示
show ntp

# peerアドレスの変更
# "SET NTP PEER"コマンドが存在しないので "DEL"して "ADD"する
# 当然DNSラウンドロビンも出来ないので機器毎にバラけた設定をしたりする
del ntp peer=133.243.238.163  
add ntp peer=133.243.238.164  

L3スイッチでの PPP接続

L3スイッチでのLAN型PPP接続の例を挙げる。下記は 8948XL、8724SL/8748SLでの場合だ。²

# Port1をアップリンクポートとして ONU接続に使う
create vlan="PPPoE-FLET" vid=4  
add vlan="4" port=1

# そのポートの中に PPPセッションを張って PPPインタフェースを作る
create ppp=4 over=vlan4-any  
set ppp=4 bap=off iprequest=on username="<ISPアカウント>" password="<パスワード>"  
set ppp=4 over=vlan4-any lqr=off echo=10 

# PPPインタフェースの IPは ISPから貰う
enable ip  
enable ip remote  
add ip int=ppp4 ip=0.0.0.0

# ・・・ことにしつつ、内側のVLANにそのIPを付けて NETMASKを切る
# これがL3スイッチ配下から見たゲートウェイIPになる
add ip int=vlan1 ip=<付与されたグローバルIPのひとつ> mask=255.255.255.248

# デフォルトルートは PPPインタフェースに丸投げする
add ip rou=0.0.0.0 mask=0.0.0.0 int=ppp4 next=0.0.0.0  

上位への接続は L3ルーティングとなる。設定のミソは本来 PPPインタフェースに付くべき IPを、内側の VLANにつけるところだ。

言うまでもなかろうが、IPが一つしか付与されない端末型接続の PPPでは、NATが使えなければおよそ意味が無い。L3スイッチ系では通常は NAT接続ができないので（ファイアウォールライセンスの購入が別途必須）、その場合はおとなしく ARシリーズを使おう。AR系と 89xx/87xx系の使い分けは、装備された物理ポートの数とNAT機能の有無で、PPPインタフェースの設定については概ね互換性がある。

工場出荷時初期化

Security Mode 状態から工場出荷時設定へ一気に戻すには次のようにする。AR550S v2.9.2 で確認した。

# 非同期ポート速度を初期値に変更
set asyn=0 speed=9600

# 設定ファイルを読み込まずにコールドスタート
restart router config=none

Warning: Config file MUST add a user with SECURITY OFFICER privilege.  
Do you wish to proceed with restart using specified config?(y/n)

INFO: Initialising Flash File System.  
INFO: Router startup complete

# 規定値ユーザの manager/friend でログイン
login: manager  
Password:

# SECURITY_MODE を切る
disable system security_mode

Warning: This command will disable security mode and delete all security files.  
Are you sure you wish to proceed?(y/n)  y

Info (1034003): Operation successful.

# 起動設定を消して、元の起動設定ファイルを rename あるいは delete fileする
set conf=none  
rename boot.cfg boot-old.cfg  

見れば解るが、デフォルトの managerユーザは Security Mode を切ることができる。起動設定ファイル（規定値では boot.cfg）を削除して再起動しても同じことだが、Security Mode 状態は設定ファイルと関係なく EEPROM内に保存されているため、これを切る方法を知らないと show confも create confも出来ない。

ところで起動診断時に以下のメッセージの途中で数秒間止まる。そこで "y" を押すと何が起きるだろう？

INFO: Self tests beginning.  
INFO: RAM test beginning.  
PASS: RAM test, 65536k bytes found.  
INFO: Self tests complete.  
INFO: Downloading router software.  
Force EPROM download (Y) ? 

INFO: Initialising Flash File System.  

INFO: Executing configuration script <flash:boot-1.cfg>  
INFO: Router startup complete

AR550S login:  

答えは「起動設定ファイルは読み込むが、すべてのEnableコマンドを無視する（組み込みモジュールを有効化しない）」である。このため Security Mode は切れて起動するものの、SET USERは通常通り実行されているために SECURITY OFFICERでログインすることが出来ず、かつ managerユーザが設定ファイルから削除もしくはパスワード変更されていたならば、結局は再ログイン手段が得られずに行き詰まる。

ところがここで "y" ではなく "s" を押すとどうなるだろう？³

Force EPROM download (Y) ?  
INFO: Initial download successful.

INFO: Initialising Flash File System.  


INFO: Router startup complete

 login: 

ログインプロンプトに "SET SYS NAME" が反映されていなければ成功である。つまり起動設定ファイルを読み込まないで起動できる。こうなれば自動的に managerユーザが復活するので、それでログインして Security Modeを切り、工場出荷時状態に戻してしまえる。

この Undocumentedな挙動は、対応しているいくつかの機種・ファームウェアでのみ可能⁴ですべての機種で可能なわけではない。同じ機種でもファームウェアによっては（Undocumentedなのだから当然だが）そもそも対応していなかったり、GS916M/GS924M に至っては managerユーザは復活するもののパスワードはリセットされない⁵ので、パスワード忘れ事案には対応できない。

要件定義

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)

犯人はだれ

Linuxサーバをテキトーに作ってテキトーに運用してるとやらかしがちなのがrootメールの始末だろう。ターミナルログインしてrootにsuしたら毎回You have mailと言われるアレである。mailコマンドを打ってもよくわからんメールが大量に溜まっておりいちいち読むのも削除するのも面倒だからと放置しがちだが、気を抜くと何年かして忘れた頃に突如ディスクが溢れて、システム丸ごと制御不能ということも稀にあるからあなどれない。それはまあ自業自得なのだが、ミニマルな普通のRHEL/CentOS（Linux）ならrootメールの生成元は基本的に以下のふたつだけだ。

• crond
• logwatch

たったふたつしかないのだからサーバセットアップ時に忘れずに対処しておくに越したことはない。あとからnagiosやらchkrootkitやらを動かしだすと当然メール生成元が増えてゆくわけだしその前に、である。とりあえず手堅いのは/etc/aliasesを編集してrootメールを外部のまともなメールアドレスに丸ごと転送してしまうことだ。

aliasesで転送する

/etc/aliasesの末尾を見ると次のようになっている。

# trap decode to catch security attacks
decode:         root

# Person who should get root's mail
#root:          marc

見れば分かる通り root: USERIDを追記すれば、 root宛のメールは指定のローカルアカウントに転送され、 rootのスプールには残らなくなる。従って普段コンソールログインに使用するアカウントを指定してやれば、 rootにならなければメールが来ていることに気付かない、という事態は避けられる。

/etc/aliasesを編集したら忘れずに newaliasesを実行してMTAを更新しよう。

当然、USERIDの代わりに外部メールアドレスを記述すれば、 rootメールはすべてそこに送られる・・・はずなのだが、システムによってはうまく動かない。その秘密が直前にある decode: rootだ。コメントにある通りセキュリティ上の理由で rootメールが外部に送信されないよう制限をかけている。故にこの制限をコメントアウトすれば意図通りあらゆる rootメールが外部メールアドレスへ全転送されるようになる。

# trap decode to catch security attacks
#decode:        root

# Person who should get root's mail
root:           log@example.com  

言うまでもなくこの設定で万一あれやこれやをされるとたいへん面白くない事態になる。セキュリティ設定は無闇に外すべきではないのが筋であるから、いったん普段使いのログインアカウントに転送し、そちらで外部メールアドレスへ再転送するように設定するのが正しい。

# trap decode to catch security attacks
decode:         root

# Person who should get root's mail
root:           charlie

charlie:        log@outer.example.com  

ログイン管理者が複数いるなら、カンマで区切って転送先を列挙すればめいめいに転送される。これは簡易的なメーリングリストの作成方法と同じだ。

root:           charlie, dennis  

当たり前だが自分自身に転送すればループメールになってしまう。外部転送しつつローカルにもメールを残したい場合は、バックスラッシュをつけたエイリアス名を記述する。

X charlie:        charlie, log@outer.example.com

O charlie:        \charlie, log@outer.example.com  

aliasesで MailFroｍを書き換える

ところで、当然ながら外部メールアドレスへの転送を行う場合は、リジェクトやらドロップやらでエラーメールが戻ってくる¹ことになる。これをまた転送してしまえば当然無限ループになるので、回避するために転送メールの Fromをカスタマイズする手がある。各メール生成元で個別に MailFromを設定するのが正道だが、上記のエイリアスの仕組みを使えば該当アカウントを通過するすべてのメールのFromをもれなく上書きしてしまえる。

charlie:          \charlie, "|/var/local/fw-charlie-to-log.sh"  
owner-fw-charlie: \charlie  

#!/bin/sh -
/usr/lib/sendmail -f owner-fw-charlie@mydomain log@outer.example.com

これは、charlieに届いたメールは自分自身のローカルに保存されるとともに、指定スクリプト²の標準入力に送る。スクリプトの方は Fromを charlieのエイリアス owner-fw-charlie³に書き換えつつ外部の log@outer.example.comに送信する。こうしておいていざリジェクトメールが帰ってくると、それは owner-fw-charlie宛に着信することになる。 owner-fw-charlieのエイリアス設定行では charlieへのローカル保存のみを指示しているので、再度の外部転送は発生せず、ループメールもここで止めつつリジェクトを捨てずに保存させることができる。

この話はクラウドVPS等の運用でグローバルIPを持っておりかつ SMTPポートを開けてメール受信もする正規のサーバでのことだが、送信元サーバ自身でエラーメールを受け取らないような運用でも、同じように MailFromを書き換える価値はある。とは言えその場合は From偽装とやっていることは同じなので正しく着発信できループにもならないよう充分に気を払う必要がある。

crondのメール送信を止める

ここまでは各種ステータス＆ジョブメールを捨てずに外部転送して受け取り＆閲覧する前提の話⁴だったが、ここからはメール生成そのものを元から止めてしまう方法である。

cronの出すジョブメールを止めるには、まず第一に cron実行されるジョブがstdoutもstderrも吐かないことが最重要だ。出力が何もなければ cronメールは生成されない。本来cronジョブのバックグラウンド終了結果を実行ユーザに返す仕組みなので、その中身は個々のジョブが責任を持っている・・・が、そうも言ってられない事態も時にはあるもので、そういう時は /etc/sysconfig/crond のCRONDARGSを次のように修正し、 service crond restartする。

# Settings for the CRON daemon.
# CRONDARGS= :  any extra command-line startup arguments for crond
CRONDARGS="-m off"  

もう少し一般的な（汎用的な）メールの止め方としては、 /etc/crontabに MAILTO=""を書く方法だろう。この方法は RHEL/CentOSに限らず Linux全般や *BSDにも通用する。そして編集後には crondを再起動（あるいはkill -HUP）しなければならないのだが、どういうわけか誰もが頻繁にプロセス再起動を忘れるのは定番のお約束である。⁵

SHELL=/bin/bash  
PATH=/sbin:/bin:/usr/sbin:/usr/bin  
MAILTO=root  
MAILTO="log@outer.example.com"  
MAILTO=""  
HOME=/

# For details see man 4 crontabs

# Example of job definition:
# .---------------- minute (0 - 59)
# |  .------------- hour (0 - 23)
# |  |  .---------- day of month (1 - 31)
# |  |  |  .------- month (1 - 12) OR jan,feb,mar,apr ...
# |  |  |  |  .---- day of week (0 - 6) (Sunday=0 or 7) OR sun,mon,tue,wed,thu,fri,sat
# |  |  |  |  |
# *  *  *  *  * user-name command to be executed

ところがこの方法には落とし穴がある。crontabファイルは /etcの下にあるものばかりではない。

# /usr/bin/crontab -l
MAILTO="root"  
#* * * * * /etc/pound/poundchk.sh 1>/dev/null 2>&1
* * * * * /etc/rc.d/secure_cleaning.pl
*/3 * * * * /etc/rc.d/dns_listen_flush.sh

/var/spool/cron/ 以下には各ユーザ別の crontabファイルを作ることが出来る。 /etc/crontabに比べると6カラム目のユーザ指定がない⁶ことを除けば実質同じものだ。当然MAILTO環境変数も同様に指定できるので、こちらでもメール送信が設定されていないか確認したほうがよい。

言うまでもなく先に上げた /etc/sysconfig/crondでメールを止める方法はメール送信が完全に止まるので、MAILTO環境変数を改めて指定してもジョブメールが出たりすることはない。

logwatchのレポートメールを止める

logwatchについては、もっと高級なシステム監視（ZABBIXやNagios）を採用しているなら不必要なことがほとんどなので、logwatchパッケージ自体を削除して最初からなかったことにしてしまうのが一番シンプルで確実だ。

sudo yum remove logwatch  

logwatchはperlやsendmail（postfix）くらいにしか依存していないはずなので、依存性により本パッケージ削除できないという事態は滅多にない。だが事情により既存パッケージを削除したくない・できない⁷等という運営上の理由があるならば、以下の設定で動作を止めることができる。

echo "DailyReport=No" >> /usr/share/logwatch/default.conf/logwatch.conf  

これは/etc/cron.daily/0logwatchが次のように書かれているためだ。

#!/bin/bash

DailyReport=`grep -e "^[[:space:]]*DailyReport[[:space:]]*=[[:space:]]*" /usr/share/logwatch/default.conf/logwatch.conf | head -n1 | sed -e "s|^\s*DailyReport\s*=\s*||"`

if [ "$DailyReport" != "No" ] && [ "$DailyReport" != "no" ]  
then  
    logwatch
fi  

/etc/cron.daily/0logwatchを削除したり実行パーミッションを落とせば良くないか？という発想は甘い。yum updateの際に欠損ファイルが復旧されたり、パーミッションが元通りに修復されてしまう事態がおこるため、こういうものは設定ファイルで動作を止めるのが正義である。

溢れたrootメールを消す・証拠を残す

以上の予防処置を講じるまでもなく rootメールが溢れたあとでは、まあだいたいシステム（のディスク残量）が終わっているのでこうするしかない。

# > /var/spool/mail/root 

ゼロバイト消去をするか、rm -fで削除するかは好みではあるが、いずれにせよ早急にディスク容量を回復する必要がある状況のはずだ。悠長に問題ファイルのバックアップを保存して・・・などという余裕はないだろう。そもそもファイルコピーするだけのリソース余地なぞ残っていまい。

だが障害報告書に貼り付けるだけの最小限の状況証拠は残しておきたい場合はどうするか。かろうじてリモートターミナル⁸が繋がっているなら、ターミナルアプリのログ機能を利用して記録を取ることができる。要するにスプールファイルを catでコンソールに流して保存したりスクリーンショットを撮影したりする。

もっとも真正直に catで全部流すと何時間掛かるか分かったものではないので、 head と tailで最初と最後の数メールぶん程度を記録すれば充分だろう。少なくとも何時からメールが溜まり始め、何時までシステムが動いていたかの問題期間を特定することは出来るはずだ。

Postfixのドロップメールを消す

rootメールを外部送信するようにしていながら送信先がなかったり間違っていた場合、maildropやbounceディレクトリが溢れることになる。「それ」が溢れていることが自明⁹であるならば、敢えてディレクトリの中を lsしようとしたり、rm -fしようとしたりしてはいけない。¹⁰

# rm -f /var/spool/postfix/maildrop/*
Too many arguments  

この場合は該当ディレクトリごと rm -frして改めてディレクトリを作りなおすか、 find|xargsで消すか、今時の findなら -deleteオプションが備わっているので、それを使って消す。

# rm -fr /var/spool/postfix/maildrop
# mkdir /var/spool/postfix/maildrop
# chown postfix:postdrop /var/spool/postfix/maildrop
# chmod 730 /var/spool/postfix/maildrop

# find /var/spool/postfix/maildrop/ -type f -print | xargs rm -f

# find /var/spool/postfix/maildrop/ -type f -delete

/bootbank/boot.cfg の修正

通常の手順で既にインストール＆稼働済のESXiホストが相手の場合、シリアルコンソール化するには起動設定ファイルに修正を加えるだけで済む。ESXiのバージョンによって多少異なるが、5.x系はkerneloptの1行にシリアルコンソール設定を加えるだけで良い。

bootstate=0  
kernel=tboot.b00  
kernelopt=no-auto-partition text nofb com1_baud=115200 com1_Port=0x3f8 tty2Port=com1 gdbPort=none logPort=none  
modules=b.b00 --- useropts.gz --- k.b00 --- a.b00 --- net-ixgb.v00 --- ata-pata.v00 --- ata-pata.v01 --- ata-pata.v02 --- ata-pata.v03 --- ata-pata.v04 --- ata-pata.v05 --- ata-pata.v06 --- ata-pata.v07 --- block-cc.v00 --- ehci-ehc.v00 --- s.v00 --- ima-qla4.v00 --- ipmi-ipm.v00 --- ipmi-ipm.v01 --- ipmi-ipm.v02 --- misc-cni.v00 --- misc-dri.v00 --- net-be2n.v00 --- net-bnx2.v00 --- net-bnx2.v01 --- net-cnic.v00 --- net-e100.v00 --- net-e100.v01 --- net-enic.v00 --- net-forc.v00 --- net-igb.v00 --- net-nx-n.v00 --- net-r816.v00 --- net-r816.v01 --- net-s2io.v00 --- net-sky2.v00 --- net-tg3.v00 --- ohci-usb.v00 --- sata-ahc.v00 --- sata-ata.v00 --- sata-sat.v00 --- sata-sat.v01 --- sata-sat.v02 --- sata-sat.v03 --- scsi-aac.v00 --- scsi-adp.v00 --- scsi-aic.v00 --- scsi-bnx.v00 --- scsi-fni.v00 --- scsi-hps.v00 --- scsi-ips.v00 --- scsi-lpf.v00 --- scsi-meg.v00 --- scsi-meg.v01 --- scsi-meg.v02 --- scsi-mpt.v00 --- scsi-mpt.v01 --- scsi-mpt.v02 --- scsi-qla.v00 --- scsi-qla.v01 --- scsi-rst.v00 --- uhci-usb.v00 --- imgdb.tgz --- state.tgz  
build=5.0.0-3.48.1851670  
updated=3  

このファイルは起動中なら上記のパスにある。そうでなければ起動ディスク中のVFATフォーマットされたパーテションの一つにある。¹

ヘッドレスインストール

ヘッドレスで起動できることが確認できたから、これを応用すればヘッドレスインストールだってできる。インストールディスクはブートローダーにISOLINUXを使用しているので、これを丸ごとtftpサーバの/tftpboot/images/esxにコピーして、要所をPXELINUX用に修正すればよい。この時のpxelinux.cfgは以下のようになる。

serial 0 115200  
console 0

DEFAULT menu.c32  
MENU TITLE ESXi-5.x.x-XXXXXX-full Boot Menu  
NOHALT 1  
PROMPT 0  
TIMEOUT 80  
LABEL install  
  KERNEL images/esx/mboot.c32
  APPEND -c images/esx/boot.cfg text nofb com1_baud=115200 com1_Port=0x3f8 tty2Port=com1 gdbPort=none logPort=none
  ipappend 2
  MENU LABEL ESXi-5.x.x-XXXXXX-full ^Installer

LABEL hddboot  
 LOCALBOOT 0x80
 MENU LABEL ^Boot from local disk

1,2行目がSYSLINUXの表示をシリアルポート（0=最初のシリアルポート）にもリダイレクトするための設定²だが、PCのBIOS自体にリダイレクトコンソールサポートがある場合は必要ない。これは存外見落としがちなのだが、BIOSでそれが有効な場合、SYSLINUX（やGRUB）のほうでも有効にしてしまうと入出力が二重化してしまい、特にキーボード入力で不具合が生じる。従ってこれはBIOSリダイレクトコンソールを使えない環境・設定においてのみ必須となる。

一方10行目のカーネルパラメータは、コンソール制御がBIOSやSYSLINUXから離れてカーネルに移ってから有効になるものなので、BIOSリダイレクトコンソールの有無に関わらず必要となる。

bootstate=0  
title=Loading ESXi installer  
prefix=images/esx/  
kernel=tboot.b00  
kernelopt=runweasel text nofb com1_baud=115200 com1_Port=0x3f8 tty2Port=com1 gdbPort=none logPort=none  
modules=b.b00 --- useropts.gz --- k.b00 --- chardevs.b00 --- a.b00 --- user.b00 --- s.v00 --- ata_pata.v00 --- ata_pata.v01 --- ata_pata.v02 --- ata_pata.v03 --- ata_pata.v04 --- ata_pata.v05 --- ata_pata.v06 --- ata_pata.v07 --- block_cc.v00 --- ehci_ehc.v00 --- weaselin.t00 --- esx_dvfi.v00 --- xlibs.v00 --- ima_qla4.v00 --- ipmi_ipm.v00 --- ipmi_ipm.v01 --- ipmi_ipm.v02 --- misc_cni.v00 --- misc_dri.v00 --- net_be2n.v00 --- net_bnx2.v00 --- net_bnx2.v01 --- net_cnic.v00 --- net_e100.v00 --- net_e100.v01 --- net_enic.v00 --- net_forc.v00 --- net_igb.v00 --- net_ixgb.v00 --- net_nx_n.v00 --- net_r816.v00 --- net_r816.v01 --- net_s2io.v00 --- net_sky2.v00 --- net_tg3.v00 --- net_vmxn.v00 --- ohci_usb.v00 --- sata_ahc.v00 --- sata_ata.v00 --- sata_sat.v00 --- sata_sat.v01 --- sata_sat.v02 --- sata_sat.v03 --- sata_sat.v04 --- scsi_aac.v00 --- scsi_adp.v00 --- scsi_aic.v00 --- scsi_bnx.v00 --- scsi_fni.v00 --- scsi_hps.v00 --- scsi_ips.v00 --- scsi_lpf.v00 --- scsi_meg.v00 --- scsi_meg.v01 --- scsi_meg.v02 --- scsi_mpt.v00 --- scsi_mpt.v01 --- scsi_mpt.v02 --- scsi_qla.v00 --- scsi_qla.v01 --- scsi_rst.v00 --- uhci_usb.v00 --- tools.t00 --- xorg.v00 --- imgdb.tgz --- imgpayld.tgz  
build=  
updated=0s  

インストーラ起動用のboot.cfgにもシリアルポート用の設定を加える。またネットワークブートカーネルのパスも修正が必要だ。

以上でESXiインストーラを動かせるはずだがインストール終了後に、最初に述べた/bootbank/boot.cfgの修正が必要だ。ここを自動化したい場合にはインストーライメージ内からkickstartファイルを見つけて、postスクリプトセクションに以下の1行を加えておく。

sed -i '/no-auto-partition/ s/$/ text nofb com1_baud=115200 com1_Port=0x3f8 tty2Port=com1 gdbPort=none logPort=none/' /bootbank/boot.cfg  

iOSの場合

iOSの場合、特に何もしていなければホーム画面登録時に以下のファイルをサーバのドキュメントルートへ探しに行く。

|ファイル名|表示サイズ|クライアント|
|apple-touch-icon-152x152.png|152px|Retina版のiPad、iPad mini用、iOS 7以降|
|apple-touch-icon-144x144.png|144px|Retina版のiPad、iPad mini用、iOS 6以前|
|apple-touch-icon-120x120.png|120px|Retina版のiPhone、iPod touch用、iOS 7以降|
|apple-touch-icon-114x114.png|114px|Retina版のiPhone、iPod touch用、iOS 6以前|
|apple-touch-icon-76x76.png|76px|非Retina版のiPad 2、iPad miniの用、iOS 7以降|
|apple-touch-icon-72x72.png|72px|非Retina版のiPad 2、iPad miniの用、iOS 6以前|
|apple-touch-icon.png|57px/60px|デフォルト|

iOS7未満ではグローエフェクトをバイパスする-precomposed付きのapple-touch-icon-precomposed.png等も探しに行くようになっていたが、iOS7以降は廃止された。¹

真面目にアイコンを用意しようとするとこれらを全部用意しなければならないが、サーバに404 File not foundエラーログが残ることを気にしないならばapple-touch-icon.pngさえ存在していれば実用上の問題はない。

もともとの画像サイズの規定値は上記の通りだが、サイズが合ってなければ自動的にリサイズされるし、また使用されている大多数のiOSデバイスは既にRetinaディスプレイ化されているため、生真面目に最小公倍数で作成する必要も取り立ててない。ざっくり512pxや600pxあたりで作画してしまってもよいだろう。

その他気を付けるべきこととして以下の制約がある。

• 画像ファイルは標準的な24bit PNG形式とする。
• True Color 形式とし、Indexカラーにしてはならない。
• インタレース化してはいけない。リサイズによって表示が乱れる。
• SSLは問題ないが、クライアント認証に対応していない。
• Expires等で有効期限が指示されている場合、期限が切れると自動的に再アクセス・再生成される。ファイルサイズが大きいと処理の重さが気になるかもしれない。

Androidの場合

Android系の場合、Webクリップ画像についてはiOSに準じたものでよい。それを<head>セクション内の<link>要素で指定することができる。

<link rel="apple-touch-icon" href="apple-touch-icon.png"/>  
<link rel="apple-touch-icon" sizes="72x72" href="apple-touch-icon-72x72.png"/>  
<link rel="apple-touch-icon" sizes="76x76" href="apple-touch-icon-76x76.png"/>  
<link rel="apple-touch-icon" sizes="114x114" href="apple-touch-icon-114x114.png"/>  
<link rel="apple-touch-icon" sizes="120x120" href="apple-touch-icon-120x120.png"/>  
<link rel="apple-touch-icon" sizes="144x144" href="apple-touch-icon-144x144.png"/>  
<link rel="apple-touch-icon" sizes="152x152" href="apple-touch-icon-152x152.png"/>  

<sizes>属性で優先するアイコンサイズを指定することができるが、これは機種やAndroidバージョンによって千差万別²となるため「これは必須」と明言することができない。従ってこれもアバウトに大きめのサイズをひとつ用意するのが実利的だろう。

Windowsタイル画面へのピン留め

Windows8.x では（正確にはInternet Explorer 11の機能）スタートタイル画面にWebクリップを貼ろうとすると、デフォルトではまずドキュメントルートのbrowserconfig.xmlを探しに行く。このブラウザ構成ファイルのフォーマットは次のようになっている。

<?xml version="1.0" encoding="utf-8"?>  
<browserconfig>  
  <msapplication>
    <tile>
      <square70x70logo src="images/smalltile.png"/>
      <square150x150logo src="images/mediumtile.png"/>
      <wide310x150logo src="images/widetile.png"/>
      <square310x310logo src="images/largetile.png"/>
      <TileColor>#009900</TileColor>
    </tile>
  </msapplication>
</browserconfig>  

このカスタム構成ファイルは<head>中の<meta>要素で明示的に指定することができる。

<meta name="msapplication-config" content="ieconfig.xml" />  

このカスタム構成ファイルが見つからない場合は、通常のFaviconがタイル画像として採用される。

使用される画像のサイズは下表のとおりだが、ワイドサイズのみ長方形でそれ以外は正方形として規定されている。

|タイルのサイズ|標準のタイルのサイズ|最小画像サイズ|推奨される画像のサイズ|
|:-|:-:|:-:|:-:|
|小サイズ|70 x 70|56 x 56|128 x 128|
|普通サイズ|150 x 150|120 x 120|270 x 270|
|ワイドサイズ|310 x 150|248 x 120|558 x 270|
|大サイズ|310 x 310|248 x 248|558 x 558|

カスタム構成ファイルには画像更新間隔や通知テキストを追記することもでき、ウェザーサイトのように一定時間間隔で画像を書き換えさせることもできる。詳しくはMSDNの該当ページを参照されたい。³

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

本番用のSSL/TLSサーバ証明書を請求するには

SSL/TLSサーバ証明書を得るまでには概ね以下の手順を踏む。

1. サーバを運用するための独自ドメインを取得し自身の管理下に置く。そもそもこれがなければ始まらない。
2. 認証局を選択して会員登録を行い、会員の実在性承認を受ける。個人の場合は少なくとも住所氏名電話番号、会員登録したメールアドレスなどが実在するかの確認がなされる。
3. 認証局の証明書発行要件を確認し、必要なら独自ドメインの管理者情報をWHOISに登録し公開する。¹
4. 証明書申請者は証明書に埋め込まれる管理者メールアドレスを受信できるように準備する。これは一般にwebmaster、postmaster、hostmasterといった認証局が指定する定型メールアドレスである。無論その独自ドメイン名は合致していなければならず、他のドメインのメールアドレスにすることは出来ない。
5. 独自ドメインの承認を受ける。すなわちWHOIS情報などと照らしあわせてその独自ドメインが正しく請求者に所有権があるか、管理者メールアドレスにセキュリティトークンを送信して請求者が正しくその運用権限を有しているかの確認がなされる。²
6. 証明書申請者はSSL/TLSサーバ証明書を運用するサブドメインをDNSに登録・公開し、そのサブドメインをコモンネーム(CN)と管理者メールアドレスその他を記入した証明書請求（CSR）ファイルを作成し、認証局に送付する。
7. 認証局はCSR記載の内容と会員情報とを照らし合わせて監査し、不備なく承認となれば自身の持つCA証明書と秘密鍵でCSRに署名を行い、証明書（CRT）ファイルとして証明書申請者の会員登録あるいは管理者メールアドレスに返送する。

証明書請求(CSR)ファイルの作成では、先の自己証明書と同様に必要な項目を記入しなければならない。これらはサーバ証明書のSubjectフィールドに埋め込まれるが、コモンネーム(CN)は必須である。

• Country Name : 組織所在地の2文字の国コードを記名する。一般に省略不可。日本ならJP。
• State or Province Name : 組織所在地の都道府県名。一般に省略不可。東京都なら Tokyo。
• Locality Name : 組織所在地の市町村名。一般に省略不可。千代田区なら Chiyoda。
• Organization Name (O): 組織名。中間CA証明書や法人格EV認証を取る場合は原則必須で、正式な英語名称を記入する必要がある。このフィールドが必須の場合は証明書運用管理上重要なため、当然ながら無関係な他組織名を偽証することは許されない。非EV認証や個人登録申請では省略できるが時に認証局側で適宜削除・修正を受けることもある。この場合は他組織と区別のつくオリジナルな組織名を名乗ってさえいれば問題なく、個人登録では屋号や同人サークル名を記名してもよい。
• Organizational Unit Name (OU): 部署名。省略可能。同一のONで複数のサーバ証明書が必要になる場合、その区別のために入力する。申請者側で自由に記名できるコメント欄とも言える。
• Common Name (CN): サーバホスト名。サーバ証明書においては必須。ブラウザのアドレスバー表示とこれが一致しない場合は認証エラー³となる。故に独自ドメイン管理と一体でなければならない。原則として一つのサーバホスト名にはただ一つの証明書が一対一で対応するべきなので、有効期間切れ以前に新しい証明書の再発行を行う際は、同時に古い証明書を破棄申請（Revoke）して公開CRTリストに記載しなければならない。⁴
• Email Address : 管理者連絡用メールアドレス。多くの場合必須。WebサイトやメールベースでCSR申請・CRT発行を行う場合はここに記載したメールアドレスに署名された証明書が返送されたりする。なかには自動で正しい記載に差し替えてくれる認証局もあり、その場合は省略しても誤入力しても関係がない。むしろ気にすべきは、このフィールドは無条件に世界中に公開される⁵ということである。ゆえに普段使いのメールアドレスを記載すると大変な目に合うこともあるので、専用の管理者用メールアドレスや、エイリアスにしておくとよい。⁶

証明書申請(CSR)ファイルの作成

証明書申請(CSR)ファイルの作成手順は、自己証明書ファイルの時とほぼ同じである。すなわち/etc/pki/tls/certs/に移動してmake server.csrを実行するだけだ。CSRファイルと同時に同名の秘密鍵も作成される。

[root@secure ~]# cd /etc/pki/tls/certs/
[root@secure certs]# make server.csr
umask 77 ; \  
    /usr/bin/openssl genrsa -aes128 2048 > server.key
Generating RSA private key, 2048 bit long modulus  
............................+++
.............+++
e is 65537 (0x10001)  
Enter pass phrase:  
Verifying - Enter pass phrase:  
umask 77 ; \  
    /usr/bin/openssl req  -new -key server.key -out server.csr
Enter pass phrase for server.key:  
You are about to be asked to enter information that will be incorporated  
into your certificate request.  
What you are about to enter is what is called a Distinguished Name or a DN.  
There are quite a few fields but you can leave some blank  
For some fields there will be a default value,  
If you enter '.', the field will be left blank.  
-----
Country Name (2 letter code) [XX]:JP↩  
State or Province Name (full name) []:Tokyo↩  
Locality Name (eg, city) [Default City]:Chiyoda↩  
Organization Name (eg, company) [Default Company Ltd]:MULTIX↩  Organizational Unit Name (eg, section) []:↩  
Common Name (eg, your name or your server's hostname) []:secure.multix.jp↩  
Email Address []:hostmaster@multix.jp↩

Please enter the following 'extra' attributes  
to be sent with your certificate request  
A challenge password []:↩  
An optional company name []:↩  
[root@secure certs]# ls -l server.*
-rw------- 1 root root 1037 Jan 29 12:58 server.csr
-rw------- 1 root root 1766 Jan 29 12:49 server.key
[root@secure certs]# 

作成したserver.crtファイルを認証局に送付して署名を依頼する。また新しい秘密鍵からもパスフレーズを削除した版を生成してパーミッションを落としておく。

[root@secure certs]# umask 77; openssl rsa -in server.key -out ../private/server.key
Enter pass phrase for server.key:********↩  
writing RSA key  
[root@secure certs]# ls -l ../private/server.key 
-rw------- 1 root root 1679 Jan 29 12:59 ../private/server.key
[root@secure certs]#

発行されるSSL/TLSサーバ証明書が深さ2以上となる場合は、認証局のサイトから対応する中間CA証明書もダウンロードしておこう。これは/etc/pki/tls/certs/にserver-chain.crtのファイル名で保存しておく。

[root@secure certs]# ls -l server-chain.crt 
-rw-------. 1 root root 2212 Jan 29 14:07 server-chain.crt
[root@secure certs]# 

本番用SSL/TLSサーバ証明書でWebサーバを起動する

無事に認証局から署名されたSSL/TLSサーバ証明書ファイルが返送されてきたら、これをserver.crtのファイル名でcertsディレクトリに保存する。これでサーバ運用に必要な秘密鍵と証明書の用意が終わったので、ふたたびhttpsサーバ設定/etc/httpd/conf.d/ssl.confの該当項目2箇所を書き換える。また中間CA証明書server-chain.crtの設定⁷も行頭コメントを削除して有効にする。そしてこのファイル中のServerNameを正式なサーバホスト名（証明書のコモンネーム）に変更する。

#ServerName www.example.com:443
ServerName secure.multix.jp

#SSLCertificateFile /etc/pki/tls/certs/localhost.crt
#SSLCertificateFile /etc/pki/tls/certs/develop.crt
SSLCertificateFile /etc/pki/tls/certs/server.crt

#SSLCertificateKeyFile /etc/pki/tls/private/localhost.key
#SSLCertificateKeyFile /etc/pki/tls/private/develop.key
SSLCertificateKeyFile /etc/pki/tls/private/server.key

SSLCertificateChainFile /etc/pki/tls/certs/server-chain.crt  

また必要ならブラウザを開くPCの/etc/hostsファイルにサーバホスト名を追加しよう。これはNATやDMZの内側にサーバがありまだテスト段階で外部公開していない場合の代替手段となる。

192.168.0.252 secure secure.multix.jp  

あとはconfigtestで書き換えエラーがないのを確認してサービスを再起動すればよい。またサーバ再起動時にWebサーバも起動するようにchkconfigも設定しておこう。

[root@secure ~]# service httpd configtest
Syntax OK  
[root@secure ~]# service httpd restart
httpd を停止中:                                            [  OK  ]  
httpd を起動中:                                            [  OK  ]  
[root@secure ~]# chkconfig httpd on
[root@secure ~]# chkconfig httpd --list
httpd              0:off   1:off   2:on    3:on    4:on    5:on    6:off  
[root@secure ~]# 

以上ですべての準備が整ったので、ブラウザでサーバホスト名を参照⁸してみよう。今度は【頼できない接続】の警告なしでサイトが閲覧できるはずだ。証明書を確認して署名を依頼した認証局名が表示されれば正常である。⁹

SSL/TLSサーバ証明書の配置場所と作成コマンド

https通信を必要とするWebサイト/アプリの開発では以上の作業を行えば充分用が足りる。次は自己サーバ証明書を自作しそれを用いてWebサーバを設定する手続きを練習してみよう。

SSL/TLS証明書を得るには openssl コマンドで秘密鍵と証明書のセットを作成する必要があるが、この作業を簡略化する Makefile が openssl パッケージとともにインストールされているので、ここではこれを使用する。これは /etc/pki/tls/certs に配置されている。

[root@localhost ~]# cd /etc/pki/tls/certs/
[root@localhost certs]# ls -la
合計 1780
drwxr-xr-x. 2 root root    4096  2月 20 12:41 2015 .  
drwxr-xr-x. 5 root root    4096  2月 20 11:03 2015 ..  
-rw-r--r--. 1 root root    2242  1月 21 02:32 2015 Makefile
-rw-r--r--. 1 root root  786601  7月 14 23:55 2014 ca-bundle.crt
-rw-r--r--. 1 root root 1005005  7月 14 23:55 2014 ca-bundle.trust.crt
-rw-------. 1 root root    1541  2月 20 11:29 2015 localhost.crt
-rwxr-xr-x. 1 root root     610  1月 21 02:32 2015 make-dummy-cert
-rwxr-xr-x. 1 root root     829  1月 21 02:32 2015 renew-dummy-cert

ここで例えばmake develop.crtを実行すると、秘密鍵develop.keyと証明書develop.crtのセットを作成することが出来る。質問事項のうち秘密鍵を作成・参照するためのパスフレーズは必須、Organization Name（ここではDEVELOP）とCommon Nameの入力（ここではlocalhost）は必要だが、その他は規定値で構わないので空ENTERでもよい。

[root@localhost certs]# make develop.crt
umask 77 ; \  
    /usr/bin/openssl genrsa -aes128 2048 > develop.key
Generating RSA private key, 2048 bit long modulus  
.............................+++
...........................................+++
e is 65537 (0x10001)  
Enter pass phrase:********↩  
Verifying - Enter pass phrase:********↩  
umask 77 ; \  
    /usr/bin/openssl req -utf8 -new -key develop.key -x509 -days 365 -out develop.crt -set_serial 0
Enter pass phrase for develop.key:********↩  
You are about to be asked to enter information that will be incorporated  
into your certificate request.  
What you are about to enter is what is called a Distinguished Name or a DN.  
There are quite a few fields but you can leave some blank  
For some fields there will be a default value,  
If you enter '.', the field will be left blank.  
-----
Country Name (2 letter code) [XX]:JP↩  
State or Province Name (full name) []:Tokyo↩  
Locality Name (eg, city) [Default City]:Chiyoda↩  
Organization Name (eg, company) [Default Company Ltd]:DEVELOP↩  
Organizational Unit Name (eg, section) []:↩  
Common Name (eg, your name or your server's hostname) []:localhost↩  
Email Address []:↩  
[root@localhost certs]# ls -l develop.*
-rw-------. 1 root root 1261  2月 20 13:18 2015 develop.crt
-rw-------. 1 root root 1766  2月 20 13:18 2015 develop.key

出来上がったdevelop.crtの署名情報を確認してみると-subjectと-issuerの中身が同一なので自己証明書である事がわかる。

[root@localhost certs]# openssl x509 -in develop.crt -noout -subject -issuer -dates
subject= /C=JP/ST=Tokyo/L=Chiyoda/O=DEVELOP/CN=localhost  
issuer= /C=JP/ST=Tokyo/L=Chiyoda/O=DEVELOP/CN=localhost  
notBefore=Feb 20 04:18:44 2015 GMT  
notAfter=Feb 20 04:18:44 2016 GMT  

次にパスフレーズを削除した秘密鍵を/etc/pki/tls/private/に作成し、パーミッションを落としておく。¹

[root@localhost certs]# umask 77; openssl rsa -in develop.key -out ../private/develop.key
Enter pass phrase for develop.key:********↩  
writing RSA key  
[root@localhost certs]# ls -l ../private/
合計 8
-rw-------. 1 root root 1679  2月 20 13:21 2015 develop.key
-rw-------. 1 root root 1679  2月 20 11:29 2015 localhost.key
[root@localhost certs]#

自作したSSL/TLSサーバ証明書でWebサーバを起動する

これで秘密鍵と証明書が用意出来たので、httpsサーバ設定/etc/httpd/conf.d/ssl.confの該当項目2箇所を書き換える。またこのファイルの中にもServerNameを指定する箇所があるが、いまは何もしなくても良い。

#ServerName www.example.com:443

#SSLCertificateFile /etc/pki/tls/certs/localhost.crt
SSLCertificateFile /etc/pki/tls/certs/develop.crt

#SSLCertificateKeyFile /etc/pki/tls/private/localhost.key
SSLCertificateKeyFile /etc/pki/tls/private/develop.key  

あとはconfigtestで書き換えエラーがないのを確認してサービスを再起動するだけだ。

[root@localhost conf.d]# service httpd configtest
Syntax OK  
[root@localhost conf.d]# service httpd restart
httpd を停止中:                                            [  OK  ]  
httpd を起動中:                                            [  OK  ]  
[root@localhost conf.d]# 

ブラウザでふたたびhttps://localhostを閲覧して証明書の内容を確認してみると、認証局の位置に先ほどOrganization Nameに入力した文字列 DEVELOP が表示されているだろう。

Apache導入

必要なupdateを行った上で、Apache、mod_sslを導入する。もしopensslが入っていなければ自動的に追加される。

yum update -y  
yum install httpd mod_ssl  

Webサーバを起動する

さっそくこのWebサーバを起動してみよう。/etc/httpd/conf/httpd.conf を編集してServerNameを所定の位置に追記する。既定では記入例がコメントで書かれているからその直下にServerName localhostを追記して保存する。設定編集が必要なのはこれだけだ。¹

#ServerName www.example.com:80
ServerName localhost  

設定に間違いがないか確認してhttpdサービスを起動する。

[root@localhost ~]# service httpd configtest
Syntax OK  
[root@localhost ~]# service httpd start
httpd を起動中:                                            [  OK  ]  
[root@localhost ~]#

Linuxデスクトップ上でWebブラウザを起動しhttp://localhostを参照すると以下の画面を得ることが出来る。

自分自身（localhost）以外から参照するにはファイアウォールでHTTPポート接続を許可する必要²がある。これにはWWW(HTTP)と安全なWWW(HTTPS)のふたつを許可しよう。

HTTPSで接続する

実はこの段階で、プリインストールされた自己CA証明書を用いたHTTPSサーバがすでに起動している。ブラウザからhttps://localhostを参照すると以下【信頼できない接続】の画面を得ることが出来る。

FireFoxの場合は【危険性を理解した上で接続するには】の【例外を追加】からこの自己CA証明書を【承認】する。

すると先のHTTP接続と同じ画面が表示されるが、アドレス欄には鍵マークが付いている。これをクリックするとHTTPSで確かに通信されていることが判る。

サーバに設定された証明書を確認する

正しくSSL通信が為されているならば証明書の署名と発行者、またSSLネゴシエーションのパラメータや暗号方式が得られる。

openssl s_client -connect HOSTNAME_OR_ADDR:443 -showcerts  

中間証明書が正しく設定されているならばそれらを通じてルートCAまで一貫して辿れることが確認できる。 なお、ポート番号にはデフォルトでは以下を指定する。

• 443 HTTPS
• 995 POP over SSL
• 465 SMTP over SSL
• 993 IMAPS

このコマンドは「---」で表示が止まるが、TCPセッションは接続したままになっている。HTTPSの場合はget /ENTERを打てばトップページの内容が得られるし、SMTPならHELO等を打つことでSMTPサーバと直接会話することができる。

証明書ファイル(CRT)の内容を確認する

-informを省略した場合は-inファイルは（BASE64エンコードされた）PEMフォーマットであると仮定する。解読できない場合はDERを指定してみると良い。これは他のコマンドでも同様である。

openssl x509 -in "CERTFILE.PEM" -noout -text  

openssl x509 -in "CERTFILE.CRT" -inform der -noout -text  

証明書ファイルの有効期間を確認する

-textでの表示内容から有効期間(Validity)フィールドだけを表示する。

openssl x509 -in "CERTFILE.PEM" -noout -dates

notBefore=Jan 28 17:19:49 2015 GMT  
notAfter=Jan 29 17:58:54 2016 GMT  

証明書ファイルの要求使用者名を確認する

-textでの表示内容から要求使用者(Subject)フィールドだけを表示する。

openssl x509 -in "CERTFILE.PEM" -noout -subject

subject= /C=JP/CN=secure.example.jp/emailAddress=hostmaster@example.jp  

証明書ファイルの発行署名者を確認する

-textでの表示内容から発行署名者(Issuer)フィールドだけを表示する。

openssl x509 -in "CERTFILE.PEM" -noout -issuer

issuer= /C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Class 1 Primary Intermediate Server CA  

証明書申請ファイル(CSR)の内容を確認する

openssl req -in "CERTRESIGNQUEST.PEM" -noout -text  

秘密鍵ファイルの内容を確認する

openssl rsa -in "PRIVATEKEY.PEM" -noout -text  

証明書と秘密鍵の公開鍵(PUB)が一致するかを確認する

これは証明書と秘密鍵それぞれから公開鍵を抽出して比較することで実現できる。

openssl rsa -in "PRIVATEKEY.PEM" -pubout -out "PUBKEY.PEM"  
openssl x509 -in "CERTIFICATE.PEM" -pubkey -noout > "CERTPUB.PEM"  
diff "PUBKEY.PEM" "CERTPUB.PEM" && echo OK  

秘密鍵のパスフレーズを削除する

サービスデーモンで使用する秘密鍵は、サービスを起動する度に毎回パスフレーズ入力を求められることになるのを避けるため、セキュリティ的に弱くなるのを承知しつつパスフレーズを削除しておくのが一般的¹だ。入力ファイルと出力ファイルは同じファイル名にして上書き保存しても良いし別ファイルに変えても良い。普通は使用するサービスが区別できるような名前にするだろう。

openssl rsa -in "PRIVATEKEY.PEM" -out "SERVERKEY.PEM"  

作成した秘密鍵ファイルは速やかにファイル属性をrootユーザの読み込み専用に変更し、通常は/etc/pki/tls/certs/に適切な名前で格納する。

openssl rsa -in localhost.key -out localhost.key  
chown root.root localhost.key  
chmod 400 localhost.key  
mv localhost.key /etc/pki/tls/certs/  

証明書のフォーマット変換

UNIX系サーバソフトやアプリではPEM形式が多用されるが事実上平文も同然なので、外部とのやりとりやWindows/Macintosh上ではDER形式やPKCS12形式を利用するほうが多いだろう。なのでファイルフォーマット変換は利用する機会が多い。²

openssl x509 -in "input_file.der" -inform DER -out "output_file.pem" -outform PEM  

openssl x509 -in "input_file.der" -inform DER -text -noout  

openssl x509 -in "input_file.pem" -inform PEM -out "output_file.der" -outform DER  

openssl pkcs12 -export -in "input_file.pem" -out "output_file.p12" -name "FRIENDLYNAME"  

PKCS12への変換はシステムから外部へのエクスポートなのでパスフレーズの設定入力が求められる。-nameは任意入力だがたいていは誰彼が使うために発行したのかが区別できるように書く。

openssl pkcs12 -in "input_file.p12" -nodes -out "output_file.pem"  

PKCS12からの変換は外部からシステムへのインポートなので正しいパスフレーズを解除入力しないと実行されない。

なおWindowsでは証明書ファイルをフォーマット形式ではなく用途によって既定の拡張子を定めている。用途と合致しない拡張子の証明書をインポートしようとすると正しい場所へストアされずに悩まされることがある。³

証明書の正当性検証

ルートCA証明書は自分自身を証明して他には依存していないため以下のコマンドでOKが返る。⁴

openssl verify ルートCA証明書  

ルートCA証明書で直接署名された（ルートから見て深さが1の）証明書は-CAfileオプションにルートCA証明書を与えることで直接検証できる。

openssl verify -CAfile 親証明書 子証明書  

中間CA証明書で署名された（ルートから見て深さが2以上の）証明書の場合は検証確認が煩雑になる。取り敢えず簡便なのは、ルートCA証明書と必要な中間CA証明書をすべて含む一つの親証明書を作成してこれで検証する方法だろう。

cat StartSSL_CA_Root.pem StartSSL_CA_Class1.pem > StartSSL_CA.pem  
openssl verify -CAfile StartSSL_CA.pem cert.pem 

cert.pem: OK  

アプリケーションのSSL警告を抑制する

システムにバンドルされていない証明書をシステムに追加するにはca-certificatesパッケージに付属のupdate-ca-trustコマンドを使用する。/etc/pki/ca-trust/source/anchors/に中間CA証明書をコピーしてupdate-ca-trust extractを実行すると/etc/pki/ca-trust/extracted/pem/*.pem証明書ストアに結合される。⁵

cp StartSSL_CA_Class1.pem /etc/pki/ca-trust/source/anchors/  
update-ca-trust extract  
openssl verify -CAfile /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem cert.pem

cert.pem: OK  

この証明書ストアはwgetコマンド等が参照しているので、この作業を行うとこのCA証明書を参照するホストについては--no-check-certificateオプションを付加する必要がなくなる。自作CA証明書（いわゆるオレオレ証明書）もこの方法でシステムに登録できる。