注意点

memtestのシリアルコンソール対応は、既に充分にはメンテナンスされていないのか若干の不具合がある。例えば configurationメニューから抜けたあと画面が乱れるので起動後のテストオプションが事実上変更できないとか、ESCキーで終了したとき rebootではなく system haltで止まってしまうなどだ。とは言え VGAデバイスを持たない機材のメモリ健全性テストができるだけで充分な利用価値があったりする。

なお memtestバイナリは 32bit実行ファイルとなるので、64bit環境で buildするには /usr/include/gnu/stubs-32.hが要求される。

CentOSの場合

まず必要なパッケージをインストールする。基本的な gccやライブラリの類は yum groupinstall "Development Tools"で揃う。また memtestを makeするために 32bitバージョンの glibc-develもインストールする。

sudo yum groupinstall -y "Development Tools"

# 64bit環境の場合
sudo yum install -y glibc-devel-2.17-78.el7.i686  

memtestの SRPMをダウンロードし、rpmコマンドで展開する。展開結果は ~/rpmbuildディレクトリ以下に現れる。

rpm -iv ftp://ftp.pbone.net/mirror/vault.centos.org/7.1.1503/os/Source/SPackages/memtest86+-4.20-14.el7.src.rpm  

シリアルポートの設定は、memtestの condfig.hで行うので、これに対する patchファイルを用意する。SERIAL_CONSOLE_DEFAULT を1にするだけだが、これによって起動オプションとして console=CONFIGURATIONが記述できるようになる。

--- memtest86+-4.20/config.h        2011-01-24 03:11:04.000000000 +0900
+++ memtest86+-4.20/config.h.serial 2015-07-03 13:15:26.716441211 +0900
@@ -13,7 +13,7 @@
 /* SERIAL_CONSOLE_DEFAULT -  The default state of the serial console. */
 /*     This is normally off since it slows down testing.  Change to a 1 */
 /*     to enable. */
-#define SERIAL_CONSOLE_DEFAULT 0
+#define SERIAL_CONSOLE_DEFAULT 1

 /* SERIAL_TTY - The default serial port to use. 0=ttyS0, 1=ttyS1 */ 
 #define SERIAL_TTY 0

次いで specファイルを修正する。元の memtest86+.specをコピーして、これらを適切な場所に追加する。

cp ~/rpmbuild/SPECS/memtest86+.spec ~/rpmbuild/SPECS/memtest86+-serial.spec  

# Patch1指示を Patch0指示行の直後に追加
Patch1:   memtest86+-4.20-serial.patch

# %patch1コマンドを %patch0コマンド行の直後に追加
%patch1 -p1 -b .serial

あとは rpmbuildコマンドを叩けば、RPMパッケージが作成される。これをインストールすると /bootに展開されるが、LiveBootの場合必要なのは memtestバイナリ本体だけなので（LiveBoot環境で buildした場合は）出来上がった memtest.binを /run/initramfs/live/syslinux/mt86plusにコピーして、syslinux.cfgを編集すれば事足りる。²

rpmbuild -bb rpmbuild/SPECS/memtest86+-serial.spec

ls -l ~/rpmbuild/RPMS/x86_64/memtest86+-4.20-14.el7.centos.x86_64.rpm  
-rw-rw-r-- 1 liveuser liveuser 80616 Jul  2 18:31 rpmbuild/RPMS/x86_64/memtest86+-4.20-14.el7.centos.x86_64.rpm

ls -l ~/rpmbuild/BUILD/memtest86+-4.20/memtest.bin  
-rwxr-xr-x 1 liveuser liveuser 176500 Jul  2 18:31 rpmbuild/BUILD/memtest86+-4.20/memtest.bin

cp ~/rpmbuild/BUILD/memtest86+-4.20/memtest.bin /run/initramfs/live/syslinux/mt86plus  

# Troubleshootingメニューに追加
label memtest  
  menu label Test ^memory
  kernel mt86plus
  append console=ttyS0,115200n8

memtest.binは FDDブートイメージなので、FDDへはそのまま ddするだけでも使える。ただしそれでは今回のようなシリアルコンソール設定オプションを渡すすべがないので、syslinux等の汎用ブートローダーを利用して起動するほうが一般的だろう。

Ubuntuの場合

まず build環境を整える。apt-get build-dep PACKAGEで指定パッケージを buildするのに必要なツール類がまとめてインストールされる。

sudo apt-get update  
sudo apt-get install devscripts  
sudo apt-get build-dep memtest86+  
apt-get source memtest86+  

memtestのシリアルポート設定は CentOSの場合と同様だが（memtest86+-4.20/debian/rulesを修正するのも面倒なので）config.hは直接修正する。その後はソースディレクトリの中で debuild -us -ucを実行すれば memtest.binバイナリと、親ディレクトリに .debファイルが作成される。

cd memtest86+-4.20/

vi config.h

debuild -us -uc

ls -l memtest.bin  
-rwxr-xr-x 1 ubuntu ubuntu 164216 Jul  3 02:57 memtest.bin

memtest.binは LiveBootフラッシュドライブの mt86plusと差し替えて使用する。

ls -l /cdrom/install/mt86plus  
-rwxr-xr-x 1 root root 150024 Jun 22 16:11 /cdrom/install/mt86plus

cp memtest.bin /cdrom/install/mt86plus  

label memtest  
  menu label Test ^memory
  kernel /install/mt86plus
  append console=ttyS0,115200n8

要件定義

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  

DynDNSプロトコル

まず基本的な情報だが、ARルータ側の設定項目はこう定義されている。

SET DDNS [SERVER=server] [PORT=port] [USER=userid] [PASSWORD=password] [DYNAMICHOST=hostnames] [PRIMARYINT=ipinterface] [SECONDARYINT=ipinterface] [OFFLINE={YES|NO|ON|OFF}] [PERIODICUPDATE={1..60|ON|OFF}]

server: ダイナミックDNSサーバー名。（1～31文字。英数字）  
port: HTTPポート番号。80(HTTP)または 8245(HTTP Bypass)  
userid: ユーザーID。（1～15文字。英数字。大文字小文字を区別する）  
password: パスワード（1～15文字。英数字。大文字小文字を区別する）  
hostnames: ホスト名（URL形式。カンマ区切りで複数指定可能。カンマを含め128文字まで。）  
ipinterface: インターフェース名。(ppp0など)  

その結果、DNSサーバには次のようなリクエストが送信される。

GET /nic/update?system=dyndns&hostname=example.dyndns.org&myip=123.45.67.89&wildcard=OFF&offline=OFF HTTP/1.1  
Host: members.dyndns.org  
Authorization: Basic [BASE64-ENCODED-USERNAME:PASSWORD-PAIR]  
User-Agent: Dyn DNS Client/CentreCOM AR560S version 2.9.2-09 21-Aug-2012  

これに対してサーバレスポンスにgood <IP_ADDR>が返るとそれは正常に受け付けられたことになり、show ddnsで確認できるステータス表示が更新される。

送信URIとして/nic/updateは固定、ユーザ認証はBASIC認証方式、パラメータとしてhostnameは必須。CGIインタフェースとして実装すべき内容はこれだけなのでそう難しいことではない。

ここでの実装では要件的には必要ないのだがエラーログを残すのにも使うので、good以外のレスポンス文字列も上げておく。¹

|応答|状態|説明|
|good <IP_ADDR>|OK|リクエストは正常に受け付けた|
|nochg <IP_ADDR>|OK|リクエストは正常だが更新されるステータスはない|
|nohost|NG|hostnameは存在しない|
|badauth|NG|認証に失敗した|
|badagent|NG|この機器は許可されていない|
|!donator|NG|利用料が支払われていない|
|abuse|NG|ユーザはブロックされている・乱用|
|911|NG|重大なエラー|

nginx perl moduleでの実装

今回はnginxのperl module機能を用いて実装する。CentOS版のnginxはこれに対応しているが、公式サイトで配布しているバイナリは対応していないため要リビルドである。次のようにしてなにも表示されなければ、このビルドオプションが足りていない。

$ nginx -V 2>&1 | tr ' ' '\n' | grep perl
--with-http_perl_module

perlモジュールが有効なら、レスポンスハンドラをperlで記述することが出来る。そこで以下のコードを/etc/nginx/lib/dyndns.pmに用意した。

#
# $Id: dyndns.pm 159 2015-05-15 04:18:23Z askn $
#
package dyndns;  
use strict;  
use utf8;  
use 5.010;  
use nginx;  
use Net::DNS;  
use MIME::Base64;  
use Sys::Syslog;

sub update_handler {  
    my $r = shift;

    $r->send_http_header("text/plain");
    return OK if $r->header_only;

    eval {
        openlog("ddns_update", "cons,pid", "daemon");

        die "unknown:nothing parameters\n" unless $r->args;

        my $auth = $r->header_in("Authorization") // "";

        die "badauth:bad authorization.\n"
            unless $auth =~ m{^Basic ([0-9a-z\+\/\=]+)}i;

        my $user = (split /:/, decode_base64($1))[0];

        my $q = {};
        foreach my $pair (split /&/, $r->args) {
            my($key, $val) = split /=/, $pair;
            next      unless defined $key;
            $val = "" unless defined $val;
            $q->{$r->unescape($key)} = $r->unescape($val);
        }

        my $hostname = lc($q->{hostname} // "");
        my $myip     =    $q->{myip} || $r->remote_addr;
#        my $system   =    $q->{system}   // "";
#        my $wildcard =    $q->{wildcard} // "";
#        my $offline  =    $q->{offline}  // "";
#        my $mx       = ls($q->{mx}       // "");

        syslog("info", "USER=".$user." HOSTNAME=".$hostname." MYIP=".$myip);

        die "unknown:badformat myip.\n"
            unless $myip =~ /^(\d{1,3}\.){3}\d{1,3}$/;

        my $resolver = new Net::DNS::Resolver;
        $resolver->nameservers("127.0.0.1");

        my @fqdn = split /,/, $hostname;

        die "numhosth:too many hostname.\n"
            if 4 < scalar @fqdn;

        foreach my $fqdn (@fqdn) {

        # ZONE name resolv stage

            defined $fqdn and $fqdn =~ s{(^\s+|\s+$)}{}g;

            die "nohost:badformat hostname.\n"
                unless defined $fqdn;

            die "badfqdn:badformat hostname.\n"
                unless $fqdn =~ /^([\w\-]+\.)*[\w\-]+$/;

            my $zone = "";
            my $ns = "";
            my(@stack, @ns);
            foreach my $dotted (reverse(split /\./, $fqdn)) {
                $zone = $dotted.".".$zone;
                unshift @stack, $zone;
            }

            foreach my $test (@stack) {
                my $query = $resolver->query($test, "NS");
                if ($query) {
                    foreach my $rr (grep {$_->type eq "NS"} $query->answer) {
                        push @ns, $rr->nsdname;
                    }
                    $zone = $test;
                    syslog("info", "ZONE=".$zone." NS=".join(",", @ns));
                    last;
                }
            }
            die "dnserr:Undefined query nameservers.\n"
                unless @ns;

            $resolver->nameservers(@ns);

        # Update stage

            my $update = new Net::DNS::Update($zone);
            $update->push(update => rr_del($fqdn.". IN A"));
            $update->push(update => rr_add($fqdn.". 3600 IN A ".$myip));

            my $reply = $resolver->send($update);

            die "dnserr:reply resolver ".$resolver->errorstring."\n"
                unless $reply;

            die "dnserr:reply ".$reply->header->rcode."\n"
                unless $reply->header->rcode eq "NOERROR";
        }

        $r->print("good " . $myip . "\n");
        syslog("info", "update success.");
    };
    if ($@) {
        chomp $@;
        syslog("info", "ERROR: " . $@);

        my $result = (split /:/, $@)[0];
        $r->print($result."\n");
    }

    return OK;
}
1;  
__END__  

コード中の$rはnginxから渡されるリファレンスオブジェクトで、mod_perlのそれと似た表現になっている。$r->argsに送信されたクエリが入っているのでこれをパースしてhostnameとmyipを受け取っているが、myipがなければ$r->remote_addrを代わりに使うよう²にもしている。その他のパラメータについてはこのコードでは対応していない。なお処理過程のログに付いては（perlの）Sys::Syslogモジュールを用いてsyslogのdaemonファシリティに送信するようにしている。

DNS Aレコード処理は（perlの）Net::DNSモジュールで行う。まずlocalhostネームサーバにFQDNを問い合わせてNSレコード=当該ネームサーバIPを取得し（resolvステージ）そこに対して既存DNS Aレコードの削除および新規DNS Aレコードの登録（updateステージ）を行う。ここでは処理を端折っているが、本格的な汎用サービス目的で実装するなら、updateステージではアクセス認証キーの処理を追加する必要があるだろう。³

nginx.conf側の記述

nginx.confから要点だけを抜き書きすると次のようになる。

http {  
    perl_modules  /etc/nginx/lib;
    perl_require  dyndns.pm;

    server {
        location /nic/update {
            auth_basic            "closed site";
            auth_basic_user_file  /etc/nginx/_htpasswd;
            perl                  dyndns::update_handler;
        }
    }
}

まずグローバル設定内でperl_modulesとperl_requireディレクティブを用いてperlコードをnginx本体にロードする。プロセス起動時にメモリ上に読み込まれるためコードを書き換えた場合は逐一nginxをreloadする必要がある。ここで読み込まれたperlコードのpackage名前空間名とハンドラ関数名をlocaltionブロック内で指定すると、URL（/nic/update）とperlコードとを紐付けることができる。またこの時BASIC認証を行うので、認証用パスワードファイルをauth_basic_user_fileディレクティブで指定する。

named.conf側の設定

named.confの設定では、FQDNが属すZONEを有しており、かつ上記のリクエストレコード送信元IPがallow-updateディレクティブで指定されていればよい。

zone "example.org" IN {  
    type master;
    :
    allow-update {
        127.0.0.1;
        192.168.0.0/24;
        key host1;
    }
}

参考：Perl-CGI版

nginx版の前に作成・使用していたPerl-CGIバージョンを以下に上げておく。こちらは単にnsupdateコマンドを叩くだけのシンプルなものだ。⁴

#!/usr/bin/perl
use strict;  
use CGI;  
use Sys::Syslog;  
use 5.010;

my($q, $hostname);  
my $myip = '0.0.0.0';  
eval {  
    openlog('ddns_update', 'cons,pid', 'daemon');

    $q = new CGI;
    $hostname = $q->param('hostname');
    $myip     = $q->param('myip') || $ENV{HTTP_X_FORWARDED_FOR} || $ENV{REMOTE_ADDR};
#    $system   = $q->param('system');
#    $wildcard = $q->param('wildcard');
#    $offline  = $q->param('offline');
#    $mx       = $q->param('mx');

    syslog('info', 'HOSTNAME='.$hostname.' MYIP='.$myip);

    unless ($hostname =~ /^([\w\-]+\.)*[\w\-]+$/) {
        die "nohost\n";
    }

    unless ($myip =~ /^(\d{1,3}\.){3}\d{1,3}$/) {
        die "unknown\n";
    }

    open my $PIPE, '|-', '/usr/bin/nsupdate' or die "badcall nsupdate.";
    print $PIPE <<__EOF;
server 127.0.0.1  
update delete ${hostname}. IN A  
update add ${hostname}. 3600 IN A ${myip}  
send

__EOF  
    close $PIPE or die "break nsupdate.\n";

    print 'Content-type: text/plain', "\r\n\r\n";
    print 'good ', $myip, "\n";
    syslog('info', 'Success.');
};
if ($@) {  
    print 'Content-type: text/plain', "\r\n\r\n";
    print 'nochg ', $myip, "\n";
    syslog('info', 'ERROR: '.$@);
}
1;  
__END__  

IPアドレスリストをAPNICから入手する

世界中に分配されているIPv4アドレスは総元締めのIANAから、世界を分割支配する5つの団体（ARIN/APNIC/LACNIC/AfriNIC/RIPE NCC）に分配され、そこからさらに各国別の元締め（日本ならJPNIC）に再分配されている。このIP分配リストは各団体のFTPサイト等で公開されているので、これを入手して日本にアサインされたIPリストだけを抽出すればACL（アクセス制限リスト）の元を作ることが出来る。今回の場合はJPNICに割り当てられたIPリストを得るために、APNICのFTPサイトから更新リストを入手する。

この更新リスト¹はほぼ毎日アップデートされている。ファイルサイズは1.8MBほどで約4万行弱ある。また世界中からダウンロードに来ることもあって、日に何回もアクセスにゆくと回数制限に引っ掛かって数時間ブロックされるということもある。故に基本的には1日1回、cronを使用してダウンロードすることになる。

一方で毎日更新されているとはいえ、日本にアサインされたIPが日々こまめに変化しているというわけでもない。だいたい週に1〜2回程度、僅かな追加と削除²が発生している程度だ。そこでダウンロードと共に前回のリストと比較して変化があったらメール通知を行い、さらにACLの更新処理を行うという仕組みを作ることにする。

なお以下の仕掛けはすべてrootユーザが行い、メインのワークエリアとしては/etc/rc.dを使用するものとする。

#!/bin/sh

### /etc/rc.d/apnic.list_update
###
### delegated-apnic-latest を取得して変化があれば
### メール通知およびrc.iptablesの再実行を行うスクリプト
###
### /etc/cron.daily からsymlinkを張るか、そこに配置すること
###

new=`mktemp`  
errors=`mktemp`  
DIR="/etc/rc.d"  
list="$DIR/delegated-apnic-latest"

test -f $list || touch $list  
wget -q -O - "http://ftp.apnic.net/stats/apnic/delegated-apnic-latest" > $new 2> $errors

if [ $? -eq 0 ]; then  
    sort_new=`mktemp`
    sort_old=`mktemp`
    diff_out=`mktemp`

    # 日本国内IPについてのみ比較する
    /bin/grep '^apnic|JP|ipv4|' $new > $sort_new
    /bin/grep '^apnic|JP|ipv4|' $list > $sort_old
    diff --ignore-matching-lines="^#" $sort_new $sort_old > $diff_out
    if [ $? -ne 0 ]; then
        (
         echo '-------------------- old delegated-apnic-latest --------------------'
         grep -P '^\d' $list
         echo
         echo '-------------------- new delegated-apnic-latest --------------------'
         grep -P '^\d' $new
         echo '---------------------- difference ----------------------'
         cat $diff_out

         # メールは rootにだす（ /etc/aliases に従う）
        ) | mail -s "delegated-apnic-latest updated $(hostname)" root
        cp -f $new $list

        # iptables の -s に渡せる形式に変換
        $DIR/jponly.pl < $list > $DIR/jponly.list

#        # rc.iptables を再実行する
#        \time $DIR/rc.iptables

         # iptables-save/restoreで更新する
         $DIR/update_mangle.pl
    fi
    rm -f $sort_new $sort_old $diff_out
else  
    cat $errors | mail -s "delegated-apnic-latest update check error $(hostname)" root
fi  
rm -f $new $errors  

このスクリプトは1日1回、APNICにお伺いを立てて（日本に割り当てられた）IPv4アドレスリストが変化していたら/etc/rc.d/delegated-apnic-latestファイルを更新する。通知メールはrootに向けて投げるため、/etc/aliasesに実際の通知先メールアドレスを書いておこう。

取得したリストの中身は概ね以下のような行の羅列である。

apnic|CN|ipv4|223.214.0.0|131072|20100803|allocated  
apnic|JP|ipv4|223.216.0.0|262144|20100712|allocated  
apnic|CN|ipv4|223.220.0.0|131072|20100723|allocated  
apnic|KR|ipv4|223.222.0.0|65536|20100721|allocated  
apnic|JP|ipv4|223.223.0.0|32768|20100803|allocated  
apnic|IN|ipv4|223.223.128.0|8192|20100809|allocated  

バーチカルラインで区切られた各カラムは次の意味を持つ。

• IP管理組織
• 2文字の国コード
• IP種別
• 割り当てブロック先頭のIPアドレス
• 割り当てブロックに含まれるIP数（2の冪乗に一致）
• 割り当てられた日付
• 現在のステータス

注意するのは5カラム目のIP数がIPマスクでもCIDRでもないという点で、ACLとして使用するにはこれをCIDRに変換する必要がある。これを行っているのが43行目のjponly.plだ。

日本国内IPのCIDRを抽出する

このフィルタスクリプトは、国コードがJPかつステータスがallocatedの行を抽出し、そのIP数からCIDRを計算して出力する。

#!/usr/bin/perl
use strict;  
use utf8;

###
### /etc/rc.d/jponly.pl
###
### delegated-apnic-latest から日本国内IPのCIDRを抽出する
###

my %CIDR;  
for my $bit ( 0..32 ) {  
    my $len = 2 ** ( 32 - $bit );
    $CIDR{$len} = $bit;
}
while ( <> ) {  
    chomp;
    if ( m{^apnic\|JP\|ipv4\|(\d+(?:\.\d+){3})\|(\d+)\|\d+\|allocated} ) {
        my $addr = $1;
        my $cidr = $CIDR{ $2 || 32 };
        printf "%s/%u\n", $addr, $cidr;
    }
}
exit 0;  
__END__  

これを通して生成した/etc/rc.d/jponly.listは1行1ブロックのIP/CIDRリストとなる。

223.216.0.0/14  
223.223.0.0/17  

iptablesでのACL

これを用いて例えばiptablesのmangleテーブル・Jponlyチェイン（フィルタ）に書き込むには次のようにする。

#!/bin/bash
JPONLY=/etc/rc.d/jponly.list

# mangleテーブルでフィルタを作る
iptables -t mangle -N Jponly  
cat $JPONLY | while read; do  
  iptables -t mangle -A Jponly -s $REPLY -j MARK --set-mark 2/2
done

# 上記のフィルタをINPUT/FORWARDに適用してパケットにmarkビットを立てる
iptables -t mangle -A INPUT -j Jponly  
iptables -t mangle -A FORWARD -j Jponly

# 他のチェインの中で、markビットが立っているならACCEPT、なければDROPする例
iptables -A Accept -m mark --mark 2/2 -j ACCEPT  
iptables -A Accept -j DROP  

mangleとmarkビットマスクを使うことで、このJponlyフィルタを容易に再利用できるようにしている。この他にホワイトリストチェイン・ブラックリストチェインを併用する場合も、markビットマスクを利用することで柔軟なACLフィルタを作り出すことが出来る。

フィルタチェインの高速更新

apnic.list_updateの49行目で呼び出しているupdate_mangle.plは、iptablesで設定した既存のJponlyチェインをアップデートするスクリプトだ。これはiptables-save・iptables-restoreコマンドを使用して高速に更新処理を行う。初回こそ前項のようにiptablesコマンドで丁寧に設定する必要があるが、これは数秒〜数十秒の処理時間が掛かってしまう。そこで2回目以降は該当チェインだけを書き換えることでダウンタイムを実用上問題ない時間（ミリ秒オーダー）まで切り詰める。³

#!/usr/bin/perl
use strict;

my $JPONLY  = '/etc/rc.d/jponly.list';  
my $UPDATE  = '/etc/rc.d/iptables.bak';  
my $SAVE    = '/sbin/iptables-save -c';  
my @RESTORE = ('/sbin/iptables-restore', '-c');

my $SEARCH   = qr{-A Jponly -s};  
my $TEMPLATE = "[0:0] -A Jponly -s %s -j MARK --set-xmark 0x2/0x2 \n";

my $BEFORE;  
my $AFTER = [];  
my @INSERT;

my $PIPE;  
open $PIPE, '<', $JPONLY or die;  
while (<$PIPE>) {  
    chomp;
    push @INSERT, sprintf $TEMPLATE, $_;
}

close $PIPE;  
open $PIPE, '-|', $SAVE or die;  
while (<$PIPE>) {  
    unless ($BEFORE) {
        if ($_ =~ $SEARCH) {
            $BEFORE = $AFTER;
            push @$BEFORE, @INSERT;
            next;
        }
    }
    elsif ($_ =~ $SEARCH) {
        next;
    }
    push @$AFTER, $_;
}
close $PIPE;

open $PIPE, '>', $UPDATE or die;  
print $PIPE @$BEFORE;  
print $PIPE @$AFTER;  
close $PIPE;

system @RESTORE, $UPDATE;

1;  
__END__  

ApacheでのACL

前述のjponly.listからApache用のACLを作り出すには次のようにする。

#!/bin/bash
JPONLY=/etc/rc.d/jponly.list

( cat $JPONLY | while read; do
  echo "Allow from $REPLY"
done ) > /etc/httpd/conf/jponly.conf  

こうして生成したACLを、必要な場所でIncludeディレクティブを使用して読み込む。なおリストが更新されたらhttpdプロセスをreload(あるいはgraceful)しなければ実際には反映されない。⁴

Order Allow,Deny  
Allow from localhost  
Allow from 192.168.0.0/16  
Include conf/jponly.conf  
Deny from All  

nginxでのACL

nginxでACLを掛けるには、geoモジュールを使用する。まずApacheの場合と同様にInclude可能なファイルを作成する。

#!/bin/bash
JPONLY=/etc/rc.d/jponly.list

( cat $JPONLY | while read; do
  echo "$REPLY 2;"
done ) > /etc/nginx/jponly.conf  

これをhttpブロックのgeoモジュールで読み込み、$acl変数に反映させる。これをlocationブロック内で参照して条件分岐する。なおリスト更新後はnginxプロセスをreloadしなければ実際には反映されない。

http {  
    geo $acl {
        default        0;
        127.0.0.1      1;
        192.168.0.0/16 1;
        include jponly.conf;
    }
    server {
        location /jponly/ {
            root /var/www/html_jponly;
            if ($acl = 0) {
                return 403;
            }
        }
        location / {
            root /var/www/html_public;
        }
    }
}

デーモンプロセス化を助けるツール

Node.jsのデーモン化実装にはいくつかあるが、以下が代表的なものだろう。

• supervisor
• forever
• pm2

いずれもnpm install -gで導入できる。おまけにLinuxでもWindowsでもそれなりに動く。それぞれに特徴がありセールスポイントがあり使い勝手も異なるが、一番リッチなのがpm2で、一番シンプルなのがforeverだろうか。

だがこれらはどういうワケかsuid/sugidをサポートしてないのである。いやNode.js自体にはPOSIX準拠のprocess.setuidとprocess.setgidが一応実装されているのだがそれをこれらで使っているのを見たことがない¹。なので上記のこれらを普通にroot権限で起動するとそのままroot権限プロセスで動き続けることになり、実行権限を落として運用したい場合は別の工夫が必要になる。

手っ取り早くデーモンにしてしまう

WindowsにはWindowsの事情があるから置いておくとして、まずCentOS6ではどうするか。6のinitプロセスにはupstartとsysvinitの2種類²が使われており、特段の事情がなければ使い慣れた後者に従うのが普通だろう。とりあえずroot権限でGhost（に限らずNode.jsで実装した各種サービス）を手っ取り早く動かしてしまうには以下のようにする。なおここではforeverを使用する。また一連の作業はすべてrootユーザで行う。

まずyumでredhat-lsb-coreを導入する。そしてforeverとinitd-foreverをnpmで導入する。

$ sudo -s
# yum install redhat-lsb-core
# npm install forever -g
# npm install initd-forever -g

# initd-forever --help

  Usage: initd-forever [options]

  Options:

    -h, --help             output usage information
    -V, --version          output the version number
    -a, --app [path]       Path to node.js main file
    -c, --command [value]  Command to execute on main file
    -e, --env [value]      Export NODE_ENV with value
    -l, --logfile [path]   Logs the daemon output to LOGFILE
    -n, --name [value]     Application name
    -p, --pidfile [path]   The pid file
    -m, --monit [value]    Generate the monit script file with the listen port number
    -f, --forever [value]  The location of forever

次いでGhostディレクトリに移動してinitd-foreverでinitdスクリプトを生成する。最低限出力ファイル名＝サービス名を決定する-n指定は必要だ。

# cd ~user/ghost
# initd-forever -n ghost 
Script daemon file saved to ghost  

出来上がったファイルに実行権限を付与して/etc/init.dへ移動し、chkconfigで使用可能にしてserviceで起動する。

# chmod +x ghost
# mv ghost /etc/init.d
# chkconfig ghost --add
# chkconfig ghost on
# chkconfig ghost --list
ghost              0:off   1:off   2:on    3:on    4:on    5:on    6:off  
# service ghost start

initd-foreverが生成したファイルは次のようなものだ。通常の用途ではまず修正するところはないだろう。

#!/bin/bash
### BEGIN INIT INFO
# Provides:          /home/user/ghost/core/index
# Required-Start:    $remote_fs $syslog
# Required-Stop:     $remote_fs $syslog
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: forever running /home/user/ghost/core/index
# Description:       /home/user/ghost/core/index
### END INIT INFO
#
# initd a node app
# Based on a script posted by https://gist.github.com/jinze at https://gist.github.com/3748766
#

# Source function library.
. /lib/lsb/init-functions

pidFile="/var/run/ghost.pid"  
logFile="/var/run/ghost.log"

command="node"  
nodeApp="/home/user/ghost/core/index"  
foreverApp="forever"

start() {  
    echo "Starting $nodeApp"

    # Notice that we change the PATH because on reboot
    # the PATH does not include the path to node.
    # Launching forever with a full path
    # does not work unless we set the PATH.
    PATH=/usr/local/bin:$PATH
    export NODE_ENV=production
    #PORT=80
    $foreverApp start --pidFile $pidFile -l $logFile -a -d -c "$command" $nodeApp
    RETVAL=$?
}

restart() {  
    echo -n "Restarting $nodeApp"
    $foreverApp restart $nodeApp
    RETVAL=$?
}

stop() {  
    echo -n "Shutting down $nodeApp"
    $foreverApp stop $nodeApp
    RETVAL=$?
}

status() {  
    echo -n "Status $nodeApp"
    $foreverApp list
    RETVAL=$?
}

case "$1" in  
    start)
        start
        ;;
    stop)
        stop
        ;;
    status)
        status
        ;;
    restart)
        restart
        ;;
    *)
        echo "Usage: $0 {start|stop|status|restart}"
        exit 1
        ;;
esac  

もう少し本格的に制御してみる

実行するNode.jsサービスがひとつやふたつでしかもrootオンリーなら上記の作業を必要なだけ繰り返せば良い。だがGhost Blogの場合これはあまりよろしくない。というのも；

• Ghost は記事に対して Draft と Publish の2モードを持つが Staging モードは持っていない。つまり投稿記事を一般公開前にレンダリングチェックすることができない。このために結局本番用とステージング用とでは個別のサービスインスタンスを立ち上げて使い分けたいという需要がある。
• Ghost はマルチユーザ（グループ）対応だが、ユーザ別にテーマを変更できるわけではなく全体でひとつのテーマに固定される。故にテーマやプラグインを開発するユースケースでもユーザ別インスタンスの需要がある。またこの作業は頻繁にインスタンスを再起動する必要が有るため、start/stopを行うのにいちいちrootへsuするのは現実的ではない。
• Ghost は自身のローカルディレクトリ内にアップロードされた画像ファイルと、記事DBファイルを格納³している。当然それらのファイル権限がそのままでは実効rootになってしまうから、非rootの開発ユーザがファイルメンテナンスをするうえで都合が悪い。

これらの諸々を助けるためにforeverdというinitdファイルを作成した。これは /etc/forver.d ディレクトリに配置した設定ファイルの数だけNode.jsのインスタンスを起動する。

NODE_DIR=/home/user/ghost  
NODE_ENV=staging  
NODE_APP=index.js  
NODE_USER=user  
OPTS="--silent"  

NODE_DIR=/home/user/ghost  
NODE_ENV=production  
NODE_APP=index.js  
NODE_USER=user  
OPTS="--silent"  

#!/bin/sh
#
# chkconfig: 2345 88 14
# description: Description of the Service
#
# Below is the source function library, leave it be
. /etc/init.d/functions
 
# result of whereis node_modules
export NODE_PATH=/usr/lib/node_modules  
 
PATH=/sbin:/bin:/usr/sbin:/usr/bin  
 
fordeamon(){  
    for conf in /etc/forever.d/*.conf; do
        name=$(basename $conf .conf)
        if [ -n "$2" ]; then
            if [ "$name" != "$2" ]; then
                continue
            fi
        fi
        source $conf
        : ${NODE_USER:=root}
        : ${NODE_APP:=index.js}
        : ${NODE_DIR:=~}
        if [ $(whoami) != $NODE_USER ]; then
            su -c "$0 $1 $name" $NODE_USER
        else
            echo $"Process id is $name"
            case "$1" in  
                start)
                    NODE_ENV=$NODE_ENV \
                        forever $OPTS \
                        --sourceDir="$NODE_DIR" \
                        --workingDir="$NODE_DIR" \
                        --minUptime=1000 \
                        --spinSleepTime=1000 \
                        --uid=$name \
                        -a \
                        start $NODE_APP
                    ;;
                stop)
                    NODE_ENV=$NODE_ENV \
                        forever stop $name
                    ;;
                restart)
                    NODE_ENV=$NODE_ENV \
                        forever restart $name
                    ;;
                list)
                    NODE_ENV=$NODE_ENV \
                        forever list | grep /$name.log
                    ;;
            esac
        fi
    done
}
 
case "$1" in  
    start)
        echo "Start service forever"
        fordeamon start $2
        ;;
    stop)
        echo "Stop service forever"
        fordeamon stop $2
        ;;
    restart)
        echo "Restart service forever"
        fordeamon restart $2
        ;;
    status)
        fordeamon list $2
        ;;
    list)
        fordeamon list $2
        ;;
    *)
        echo "Usage: $0 {start|stop|restart|status|list} [name]"
        exit 1
        ;;
esac  

これを実行権限を付与してchkconfigでサービス登録すると、サーバ起動時に /etc/forver.d/*.conf に従ってforeverインスタンスを起動するが、その後は一般ユーザ側で普通に（serviceコマンドを通さずに）foreverコマンドでlist/stop/restart⁴することができるようになる。またroot側からもservice foreverd COMMAND NAMEでインスタンス個別にユーザ権限でプロセス操作ができる。

# service foreverd start
# service foreverd restart NAME
# service foreverd stop NAME

$ forever list
$ forever restart NAME
$ forever stop NAME
$ /etc/init.d/foreverd start NAME
$ forever restartall

Switch Userは27行目のsuコマンドが行っているが、これは自分自身（/etc/init.d/foreverd）をsuidして再帰的に呼び出すようにした。正攻法ならsudoコマンドでforeverを呼びたくなるところだが、エスケープを含むコマンドラインの組み立てが煩雑になるのを避けたいのと、CnetOS6の/etc/sudoersのデフォルト設定では非TTYでのsudo実行を禁止しており、そのままでは rcプロセス（当然非TTY）で動作しない⁵という事情による。

なお当然だが well-known port を掴むようなインスタンスはrootユーザで起動しなければ意味が無い。また個々のインスタンスが掴むポート番号を重複しないように調整するのもroot管理者の仕事である。

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等のインストールが要求される。後者ならスタンドアロンインストーラ配布なので手軽だ。

本番用の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証明書（いわゆるオレオレ証明書）もこの方法でシステムに登録できる。

ソフトウェアのインストール

yum install PACKAGENAMES  

インストール済パッケージの一覧

yum list installed  

レポジトリ管理外も含むインストール済パッケージの一覧

rpm -qa  

アップデート可能なパッケージの一覧

yum list updates  

ソフトウェアのアップデート

引数を指定しなければyum list updatesで示されるパッケージすべてをアップデートしようとする。むしろ引数を指定することのほうが稀だろう。

yum update [PACKAGENAMES]  

キャッシュ/ワークファイルのクリア

yum clean all  

ソフトウェア削除

そのパッケージに依存している他のパッケージがある場合それも共に列挙される。¹

yum remove PACKAGENAMES  

RPMファイルのインストール

リポジトリを検索せずローカルダウンロード済のパッケージをインストールする場合に使用する。直接URLを指定してもよい。必要ならリポジトリから依存関係解決に必要なパッケージの追加導入やGPGKEYのインポートまでも面倒を見てくれる。かたや依存関係が解決できず、システムに適合しないRPMファイルについては何もしない。

yum localinstall PACKAGE.RPM  

yumリポジトリ管理外のRPMファイルのインストール

yum localinstallと異なり依存関係の解決は行われないし、GPGKEYが必要な場合でも別にインポートしなければならない。依存性の欠如はどんなファイルが不足しているかだけを示し、リポジトリを参照する訳ではないのでパッケージ名までは列挙しない。

rpm --import GPGKEY-FILE_OR_URL  
rpm -ivh PACKAGE.RPM-FILE_OR_URL  

ある特定ファイルを含むパッケージ名の検索

FILENAMEはグロブで指定することができる。既にインストール済の場合はinstalled、そうでなければ見つかったリポジトリ名も示す。

yum provides FILENAME  
yum provides */httpd --disablerepo=base  

パッケージに含まれるファイルとディレクトリの一覧

yum-utilsパッケージに含まれるrepoqueryコマンドはパッケージに含まれるファイルやディレクトリの一覧を、パッケージをダウンロードせずに取得できる。

repoquery --list PACKAGENAME  

クリーンなchroot環境を作る

最初のyum実行ではrpm環境がまだchroot内にないため--releaseverを明示することでエラーを避ける。Coreグループインストール完了後以降ではその必要はない。最後にclean allでyumのワークファイルを消して容量を節約する。

rm -fr /tmp/chroot  
yum --installroot=/tmp/chroot --releasever=6.6 groupinstall Core -y  
yum --installroot=/tmp/chroot update -y  
:
yum --installroot=/tmp/chroot clean all

chroot /tmp/chroot  

古いカーネルを削除する(CentOS6)

CentOS5まではバージョン番号も省略せずに指定しないと現在実行中のカーネルまでもが削除できてしまった²が、CentOS6では正しくプロテクトされるようになったので、逆にkernelとだけ指定することで現在実行中のカーネル以外を一括削除³できるようになった。

yum remove kernel  

カーネルを複数世代保持しておきたい場合はyumではなくpackage-cleanupコマンドを使用するとよい。

package-cleanup --oldkernels --count=2  

EPEL

Extra Packages for Enterprise Linux

FedoraリポジトリをソースにエンタープライズLinux向けに提供されているアドオンパッケージ群。RHELと互換性のあるスピンオフディストリビューション（CentOSやScientific Linux）で利用可能。Fedoraプロジェクトによって提供されている。Fedoraリポジトリより保守的なため提供されていないパッケージもある。

• EL7 epel-release (RPM Download page)
• EL6 epel-release (RPM Download page)
• EL5 epel-release (RPM Download page)

CentOSの場合は上記のパッケージがextrasリポジトリに含まれているため以下を実行するだけで利用開始可能となる。

yum install epel-release  

デフォルトでenablerepoであるから、必要ならdisableにしておこう。

[epel]
name=Extra Packages for Enterprise Linux 6 - $basearch  
#baseurl=http://download.fedoraproject.org/pub/epel/6/$basearch
mirrorlist=https://mirrors.fedoraproject.org/metalink?repo=epel-6&arch=$basearch  
failovermethod=priority  
enabled=0  
gpgcheck=1  
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-6  

enabled=0とするとyumコマンドに--enablerepo=REPONAMEオプションが必要となる。付けなければこのリポジトリを参照しない。インストール時だけでなくアップデート時にも必要とする。¹

yum install PACKAGENAME --enablerepo=epel  

remi

Les RPM de Remi - Repository

Remi Collet がメンテナンスしているリポジトリ。標準リポジトリには含まれていない最新バージョンのパッケージを多数提供しているが、そのぶん標準側アップデート時に不整合を起こしやすいため長期運用時はピーキーになりがちである。

• Enterprise Linux 7 (RPM Direct link)
• Enterprise Linux 6 (RPM Direct link)
• Enterprise Linux 5 (RPM Direct link)

yum localinstall http://rpms.famillecollet.com/enterprise/remi-release-6.rpm  

yum install PACKAGENAME --enablerepo=remi  

ius

ius community

Python2.7や3.3, PHP5.5、Python3.3、Git 1.8 などの最新リリースを提供している。

yum localinstall http://dl.iuscommunity.org/pub/ius/stable/CentOS/6/x86_64/ius-release-1.0-13.ius.centos6.noarch.rpm  

yum install python3.3 --enablerepo=ius  

RPMforge

RepoForge

Fedora系用アドオンコレクション。主にデスクトップ向けのパッケージが多いがサーバでも使えるものは多い。サーバ上で各種メディアファイルの編集加工等を扱う場合にはここからツール類を入手することが多い。とはいえremi同様標準リポジトリとバージョン管理が同期しているわけではないのでコンフリクトも起こしやすい。最近RepoForgeに名を改めたようだ。
導入は上記サイトから適切なバージョンとアーキテクチャのRPMファイルを示すURLを求めてyum localinstallで行う。

yum localinstall http://pkgs.repoforge.org/rpmforge-release/rpmforge-release-0.5.3-1.el6.rf.x86_64.rpm  

WANdisco

WANdisco

最新のsubversionを入手できる。repo.confパッケージは配布していないようなので以下のように自力で記述する必要がある。

[wandisco-svn]
name=WANDisco Repository - snv-1.8 centos6  
baseurl=http://opensource.wandisco.com/centos/6/svn-1.8/RPMS/$basearch/  
enabled=0  
gpgcheck=1  
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-WANdisco  

rpm --import http://opensource.wandisco.com/RPM-GPG-KEY-WANdisco  

yum install subversion --enablerepo=wandisco-svn --disablerepo=base,updates,epel