Nexus7 蓋キーボード

Nexus7用のケース&キーボードとなるアイテムを購入しました。
どういうものかというと、

GIZMODOのこれを見てもらえばイメージが掴めるかと。
http://www.gizmodo.jp/2012/11/nexus_7bluetoothmobile_bluetoo.html

国内代理店の扱いではMAGREXが有名です。
http://www.magrex.co.jp/plusm/mk/mk5000/

いわゆる蓋キーボード

実際にはいろいろな代理店が扱っていて、amazonでも 2500円程度から見つけることができます。
今回、amazonにも出店している 卸問屋sample18ドットコム の 「【minisuit】Google Nexus 7 アルミフィニッシュ ワイヤレス キーボード スタンド　カバー シルバー シルバー」という商品が 1880円という格安だったので、さっそくポチりましたよ。
ポチった後で改めてレビューを見てみると、かなり製品差があるようで、チャタリングするとか、スリープ用の磁石が今ひとつとか、小さいとか(そりゃそうだ)、tabキーが無いのが不便とか。

ん?
tabキー?
ありますよ。
ほら。

tabキー

他の方がblogに載せている写真と、手元にあるモノが、よくよく見ると最上段のキーレイアウトに違いがあるようです。
いやそれどころか、パッケージの箱の写真とも違う。

最上段の左端にtabがあり、右に向かって1,2,3,…0 とあります。
キーの数は12個しかないので何が省かれているかというと、

- (マイナス、ハイフン、長音)

0と-が同居しているので、通常は「0」が入力でき、「-」を入力するときは左下の「Ctrl」と同時押しという変態仕様! なんてこったい!! Ctrl押しづらいよ!!

何なんでしょね、これ。

親父の体調が判る店

常に同じ味の料理を提供する、という飲食店があるそうです。
その日の気温や湿度によって塩分を変えたり、水の量を調整したり、そうすることで一定の味が保たれるという…そうです。そうです、というのはそういう店に行ったこともないし、知らないから。

これって凄いことですよね。
もちろん、同じ味を提供する事もそうですが、同じ味であることを確認する方も大変です。
世の中には常連という方もいらっしゃいますけれど、日々の味の違いが判るくらい連日通う店がある人なんて、どれくらいらっしゃるんでしょう。
私なんて経済上の都合もあって 連日店に通うなんてできません。

閑話休題。
料理は人が作るものですから、塩分ひとつにしてもその日の気温、湿度、食材、食材の産地、料理人の体調、その他もろもろの要素があるはです。更にそれを確認する人の体調なども加わるわけで、全く同じ味になるなんてまさに奇跡に近いのではないかと、私は思うわけです。

いや、まぁそれはそうとして。
そういう料理人がいるかもしれませんが、そうでない人も沢山いると思うので、その料理を食べれば親父(おふくろでも可)の体調が判る店、そういう店があっても良いのではないでしょうか。

連日通うと親父の体調と同調して味が七色に変化するラーメン屋とか、それはそれで行ってみたい気は…まぁ…するような、しないような。

こういうの、Daily Portal Zでやってくれないですかね。(他力本願)

apache経由でwebminを使う

今回のお話は...

・apache + SSL + クライアント証明書 でサーバを構築する(構築済みとする)
・apacheのproxy機能を使って、https://ec2.my.server/webmin/ を localhost:10099にリダイレクトする
・webminはリソース大食いなので、webminはdaemonで常時動かさずxinetd経由で必要時のみ起動させる
・セキュリティ上の観点から webminが待ち受けるポートはデフォルトの10000ではなく、10099(任意)に変更する
・同じく、webminは127.0.0.1からのみの接続を許可する

要は、安全にwebminを使えるようにしましょう、というお話です。

AWS EC2インスタンスで構築したサーバをwebmin経由で操作できるように設定します。webminをデフォルトで起動すると 10000番ポートをLISTENし、基本的にbasic認証になりますが、今回サーバでは既にapacheが起動しており、SSL接続のクライアント認証しているので、アクセスコントロールはこちらに任せることにします。
職場などの環境からは10000番ポートに限らず大方のHigh-Portはブロックされているので、SSL(443)でアクセスする必要がありました。これはapache proxyで解決させます。
webminをapache経由(mod_proxy経由)にする方法は http://www.webmin.com/apache.html に書かれていますが、SSLが絡むと少し追加設定が必要でした。

まずは webminをインストール。
http://webmin.com/download.html から .deb形式のファイルをダウンロード。
2012/1/29時点では http://prdownloads.sourceforge.net/webadmin/webmin_1.580_all.deb でした。

# wget  http://prdownloads.sourceforge.net/webadmin/webmin_1.580_all.deb
# dpkg -i webmin_1.580_all.deb

libxxxに依存している とエラーが出るので、dependパッケージをインストールします。この追加するパッケージは環境によって異なると思いますので、必要なものをインストールしてください。

# aptitude install libnet-ssleay-perl libauthen-pam-perl libio-pty-perl apt-show-versions

apache側の設定。proxy設定をします。
Debianのapacheはproxy(mod_proxy)が使えるようにビルドされているので、モジュールでそれを有効にします。

# a2enmod proxy
# a2enmod proxy_http

SSL接続なので、SSLProxyEngine On にしておきます。これを忘れると 500番台エラーになります。ちょっとハマりました。
/etc/apache2/conf.d/proxy (新規作成)

SSLProxyEngine On
ProxyPass /webmin/ https://localhost:10099/
ProxyPassReverse /webmin/ https://localhost:10099/

/etc/apache2/mods-available/proxy.conf を以下のように書き換えます。

ProxyRequests On
<Proxy *>
#        AddDefaultCharset off
#        Order deny,allow
#        Deny from all
  Allow from all
        #Allow from .example.com
</Proxy>

webmin側の設定
/etc/webmin/config に以下の設定を記述します。(変更点のみ)

webprefix=/webmin
webprefixnoredir=1
referer=***.***.jp    # 新規追加行。稼動しているホストのDQDNを記述します。

/etc/webmin/miniserv.conf を編集して xinetd経由にします。(変更箇所のみを記述しています)

#session=1
inetd=1

webmin daemonが動いている場合はそれを停止し、サーバ再起動などでdaemonモードで起動しないようにします。

# /etc/init.d/webmin stop
# update-rc.d webmin remove

/etc/xinetd.d/webmin を新規に作成します。

# webmin
service webmin
{
 disable  = no
 type  = UNLISTED
 id  = webmin
 socket_type = stream
 protocol = tcp
 user  = root
 wait  = no
 env  = LANG=
 port  = 10099
 server  = /usr/share/webmin/miniserv.pl
 server_args = /etc/webmin/miniserv.conf
}

xinetdのリスタート

# /etc/init.d/xinetd restart

10099番ポートを誰がLISTENしているか、確認します。

# lsof -i:10099
COMMAND   PID USER   FD   TYPE  DEVICE SIZE/OFF NODE NAME
xinetd  18478 root    5u  IPv4 5968365      0t0  TCP *:webmin (LISTEN)

無事にxinetdがLISTENしています。

apacheをリスタートします。

# /etc/init.d/apache2 restart

クライアント証明書をインストールしてあるwebブラウザから、 https://ec2.my.server/webmin/ にアクセス。

https://ec2.my.server:10099/ のようにポート番号直打ちでアクセスされるとapache proxyを経由せずにbasic認証になるので、ブルートフォース攻撃の対象になるおそれがあります。
対策として、webmin上の設定で、Webmin Configuration の Ports and Addresses にて 127.0.0.1 からの接続のみを受け付ける(apacheでproxyされたものだけを受け付ける)ように変更します。
これでアタックが多い日でも安心。

お楽しみください!

参考URL
webmin公式
http://www.webmin.com/apache.html
ネットワーキングすきま情報
http://last-resort.seesaa.net/article/123147890.html
bushimichiの日記
http://d.hatena.ne.jp/bushimichi/20090417/1239970196

Blogpress had updated.

オンラインに記事が保存出来ないという致命的なバグを含んでいた Blogpressが数週間という緩慢な速度で更新されたので書き込んで見るテスト。

追記。
はい、無事に修正されているようです。
公開出来ないBlog管理/作成アプリではお笑いにしても寒過ぎます。

EC2インスタンスのDynamic DNSへの登録

今回構築したAWS EC2のインスタンス(サーバ)はElastic IP Addressは付与せずに動的IPアドレスで運用しているので、世界から見たホスト名は ec2-xxx-xxx-xxx-xxx.ap-northeast-1.compute.amazonaws.com です。(xxx-xxx-xxx-xxxにはIPv4アドレス相当の数字が入ります)
リブート(インスタンス停止/開始)するとIPアドレスも変化するので、外部からホスト名決め打ちで接続することができるように Dynamic DNSへの登録をします。
数あるDDNSサービスの中から、今回は無料で、ドメイン名が短く、さらにDNS登録が簡単に行える(=危険性もあり。後述) ddo.jp (http://ddo.jp)を選びました。
無料で xxxx.ddo.jp (xxxxは任意)のドメインが登録でき、Aレコード1つ、MXレコード3つ、TXTレコードが登録可能で、一ヶ月更新がないと自動的に登録が削除されるサービス。今回は 1サーバだけなので、無料の範囲で十分です。

DDNS更新はwebアクセスのgetメソッドで行います。
http://free.ddo.jp/dnsupdate.php?dn=xxxx.ddo.jp&pw=xxxxxx
にアクセスすることで DDNSが更新されます。

Linuxからの更新は具体的には、
wget -O - 'http://free.ddo.jp/dnsupdate.php?dn=xxxx.ddo.jp&pw=xxxxxx'
のコマンドを cronで一日一回の周期で定期的に行うように設定します。

このDNS更新方法の欠点は、httpのgetメソッドを使うため登録ドメインと登録用パスワードが平文でインターネット上を流れる、という事です。
これらが第三者に漏洩するとファーミングされてしまい、正しいドメインを指定しても第三者が指定したサーバに接続されてしまうので注意が必要です。
(注意といっても、気が付いたときにはもう遅いんだけどさ)

自宅サーバをAWSへ移行する検討

これまで10年以上前から、時代遅れのCPU(Pentium時代にi386を使うとか)を搭載した中古ノートPCを安く購入しては自宅に設置し、基本的に24h/7dサーバを運用してきました。
CPUパワーは必要としないので問題はないのですが、ストレージやメインメモリの容量制限から数年ごとにリプレースする必要が生じ、そのたびに次の中古PCを購入してはOS(Debian GNU/Linux 1.3(bo)の頃から Debian一択です)を入れ替えてきたのが、そろそろ疲れた…
と思って先日 Xenによる仮想環境を作成してハードウェア変更に伴う環境構築のやり直しは回避できる環境にしましたが、そろそろ...

中古のノートPCを24h運用するのはやはりあまりよろしくないであろうということから、Amazon Web Servicesの一つ Amazon EC2で仮想サーバを借りて運用することにしました。
EC2はよくあるWebベースレンタルサーバー(?)と異なって sshログインして ターミナル上で rootになって何でも作業できるので自由度も違います。

それにいまなら(2012/1/19現在) マイクロインスタンスのLinux(or Windows Server)を1年間無料で使用できます。(http://aws.amazon.com/jp/free/)
マイクロインスタンスは 613 MB メモリ、5GBストレージ、32ビッドまたは64ビットプラットフォーム で、CPUは他インスタンスの空きリソースを使うタイプですが、現在自宅サーバで使用している EeePC 4G-Xに比べれば十分なスペックです。
(インスタンスについては http://aws.amazon.com/jp/ec2/ を参照してください)
1年間の無料期間が終了しても、同じマイクロインスタンスであれば オンデマンドからリザーブドインスタンスにして 1年間 $65+$0.009/時*750時間 = $71.75 ですから格安です。
AWS EC2の価格設定は、CPUやメモリのサーバスペック、使用するストレージ、データ転送量などいろいろな要素があるので公式サイトで確認してください。無料マイクロインスタンスも各種制約があります。 (http://aws.amazon.com/jp/ec2/pricing)

早速 AWSにweb経由で登録すると、本人確認用の電話が掛かってくるので正しくpin番号を音声で伝えます。英語で答えても発音が悪いらしく何度言っても全く伝わらなかったのですが、日本語で答えたらOKでした...

AWSアカウントが作成したら、AWS Management Consoleにログインして Launch Instance でインスタンスを作成します。
DebianはCommunity AMIsから選択する必要があり、私は EBS image のDebian 64bit (rightimage_debian_6.0.1_amd64_20110405.1_ebs) を選択しました。



さぁ、遊びましょう!

Blogpress update again, again

Blogpressが再び更新されて ver.3.0.2 になったので試してみます。
line breakのbugfixと書かれていたから、今度こそ大丈夫...と願いたいところです。
日本語の変換カラムに隠れる問題は治っていないようで、少々残念です。

追記
改行問題は解決しています。
この記事を読み返してみると、小学生の作文みたいですね。

Blogpress update again

iPhone/iPad アプリケーション Blogpress がまた更新されたので、さっそく使ってみました。 改行問題は解決したかな? カーソルが漢字変換カラムに隠れる問題は再発しているようだ。非常に入力し辛い、何とかして欲しいものです。 追記 改行は勝手にはいらないようです。

BlogPress update

iPhone/iPad用ブログ管理アプリの BlogPressがやっと更新されました。 iOS5になった時と記憶していますが、管理画面で公開済や一時保管中の記事が見えないという不具合がありました。 一気に書いて公開してしまえば問題無いとはいうものの、私なりに遂行して何度も保存と編集し直しをする者にとっては致命的でした。 更新後、早速こうして記事を書いてみました。 おぉ、あたり前ですがちゃんと直っている。素晴らしい。 日本語入力IMEの表示カラムにもちゃんと対応しているようです。カーソルが隠れたかな? と思っても、少し待てばスクロールしてくれます。有り難や、有り難や。 追記。 何だか改行がダメっぽい...

ディスクイメージを再構成をしてスパースファイルを小さくする

一時的に作成されたファイルにより大きくなってしまったスパースファイルを小さくする為に、イメージの再構成をします。

例によって、これは未来の私宛のメモです。
ホスト名やディレクトリ名などは架空のものであり現実とは関係ありません

環境
ワーク領域に SDHCカードを/dataにマウントして使用する。
元のファイルはXen guestマシン(Linux)用のイメージファイルとする。
イメージファイルはホストマシンの/data_local 配下にある。

OLD image: /data_local/xen/domains/alpha/disk.img

OLD imageで動いていた仮想マシンをshutdown.

ホストマシンで SDHCをマウント
# mount /data

念のためバックアップ
# cp --sparse=auto /data_local/xen/domains/alpha/disk.img /data/old_disk.img.BAK
# cksum /data_local/xen/domains/alpha/disk.img /data/old_disk.img.BAK

古いイメージファイルを削除
# rm /data_local/xen/domains/alpha/disk.img

NEW image用 sparse file作成
# dd if=/dev/zero of=/data_local/xen/domains/alpha/disk.img bs=1024k seek=2048 count=0
# du /data_local/xen/domains/alpha/disk.img
0 /data_local/xen/domains/alpha/disk.img

ファイルシステム作成
# mkfs -t ext3 /data_local/xen/domains/alpha/disk.img

新旧imageをマウント
# mkdir -p /mnt/old /mnt/new
# mount -o loop /data/old_disk.img.BAK /mnt/old
# mount -o loop /data_local/xen/domains/alpha/disk.img /mnt/new
# df

コピー
# rsync -Saxv /mnt/old/ /mnt/new

アンマウント
# umount /mnt/old /mnt/new
# ls -l /data/old_disk.img.BAK /data_local/xen/domains/alpha/disk.img
# du -m /data/old_disk.img.BAK /data_local/xen/domains/alpha/disk.img
# umount /data
# df

alpha再起動
# xm create alpha.cfg
# xm list

iPhoneアプリ bloggerからの投稿テスト

iPhone用 Google blogger公式アプリケーション、その名もズバリ blogger から投稿テスト。

----
フライトモードにしてオフラインで追記してみた。

続けて新規作成しようとしたが、未アップロード記事の編集画面になる。
オフラインで記事の書き溜めはできないみたいです。
オンラインでサーバーにdraft保存すれば書き溜め可能のようです。
つたない検証なので間違っていたらごめんなさい。
----
再度試してみたら、フライトモードでも複数記事を書き溜めできました。
BlogPressのアドバンテージはタグの選択入力くらいしかない気がしてきました。しかもBlogPressは日本語入力カラムが編集画面にかぶってカーソルが見えなくなるし...

ゲストマシンをディスクイメージとしてバックアップする

そもそもゲストマシンはディスクイメージとして存在しているので、ホストマシンがそのファイルをコピーするだけで良いのですが、スパースファイルを再構成することで一度大きくなってしまったディスクイメージを小さくしましょう、という意図があります。
(SSDが潤沢にあればこんなことしなくて良いのに!)

また、ホストマシン側は 4GBのSSDしか使用できない環境なので、今回はゲストマシン側だけで何とかします。
(SSDが潤沢にあればこんなことしなくて良いのに!!)

なお、このblogは例によってメモ for 未来の私 です。

ゲストマシン環境
ディスクマウント状態はこんな感じ
/dev/xvda3 /dataは SDHCです。
バックアップ対象は /(/dev/xvda1) だけです。
バックアップ保存先は /data(/dev/xvda3) です。

/dev/xvda1 none swap sw 0 0
/dev/xvda2 / ext3 rw,noatime,nodiratime,errors=remount-ro 0 0
/dev/xvda3 /data ext3 rw,noatime,nodiratime 0 0

ホストマシン側から見ると、
/dev/xvda1 と /dev/xvda2 は EeePC 4G-X 上のSSDに保存されている ディスクイメージファイル(スパースファイル)です。
/dev/xvda3 は外付けSDHC(/dev/sdc1)です。
ホストマシン側でマウントしているデバイスはゲストマシンでマウントできないため、ホストマシンは /dev/sdc1はマウントしていません。
仮想マシン起動用のcfgはこんな感じ(抜粋)

disk = [
  'file:/data_local/xen/domains/alpha/disk.img,xvda2,w',
  'phy:/dev/sdc1,xvda3,w',
  'file:/data_local/xen/domains/alpha/swap.img,xvda1,w',
]

バックアップ手順
1. ディスクイメージ作成
2GBのスパースファイルを作成します。
作成先は /data/tmp/disk.img です。

# dd if=/dev/zero of=/data/tmp/disk.img bs=1024M seek=2 count=0

2. ファイルシステム作成
作成したディスクイメージに ext3ファイルシステムを構築します。
対話的に y/n を聞かれることがあるので、自動的に y を答えるようにします。

# echo "y" | /sbin/mkfs -t ext3 /data/tmp/disk.img

3. 作成した空ディスクをマウント
ループバックデバイスとして作成したディスクを /mnt/tmp にマウントします。

# mount -o loop /data/tmp/disk.img /mnt/tmp

4. コピー
rsyncを使用して、/(ファイルすべて) を /mnt/tmp にコピーします。
ただし、SDHCである /data/ と マウントしている /mnt/tmp/ は除外します。
90秒スリープしているのはバッファの内容を書きこむのを待っているため。sleepしなくても良いのですが、なんとなく。

# /usr/bin/rsync -Sax / /mnt/tmp --exclude "/data/" --exclude "/mnt/tmp/"
# sleep 900

5. アンマウント
マウントを解除します。

# umount /mnt/tmp

6. GNU tarでアーカイブ
gzip や bzip2 では sparseとしての扱いが出来ずに、今回であれば 2GBのファイルとして扱ってしまいますが、sparseファイルが扱える GNU tar (Sオプション)を使い、/data/tmp/disk.img から /data/Dropbox/backup/disk.img.tgz を作成します。

# cd /data/tmp
# tar -Szcf /data/Dropbox/backup/disk.img.tgz ./disk.img

/data/Dropbox は Dropbox同期ディレクトリになっているので、ここに保存した disk.img.tgz はDropboxクラウドやLAN同期を経由して手元のMacにも転送されます。
これでバックアップは終了です。


これらバックアップはスクリプトにして、cronで週3回ほど自動実行させています。
スクリプトはこんな感じ。バックアップ開始/終了をtwitterにpostしています。

USERNAME@SERVER:# cat backup_image.sh

#! /bin/sh
set -x

TMP_DIR=/data/tmp
TMP_IMAGE=disk.img
DST_DIR=/data/Dropbox/backup
DST_FILE=disk.img.tgz
MNT_POINT=/mnt/tmp
TMP_FILE=/tmp/tmp.$$

TW_POST=/home/root/bin/twitter_post.pl

# mount check
# if mounted /mnt/tmp , this script will finish.
df | grep '/mnt/tmp$' > /dev/null
test $? -eq 0  &&  exit

#
if [ -f $TW_POST ]; then
    HM=`date +%H:%M`
    echo "disk image backup start at $HM" > $TMP_FILE
    $TW_POST $TMP_FILE
    rm $TMP_FILE
fi


test -f $TMP_DIR/$TMP_IMAGE  &&  rm -f $TMP_DIR/$TMP_IMAGE

# make new 2GB sparse file
dd if=/dev/zero of=$TMP_DIR/$TMP_IMAGE bs=1024M seek=2 count=0
echo "y" | /sbin/mkfs -t ext3 $TMP_DIR/$TMP_IMAGE

# mount image
test ! -d $MNT_POINT  &&  mkdir -p $MNT_POINT
mount -o loop $TMP_DIR/$TMP_IMAGE $MNT_POINT

# mount check
# if NOT mounted /mnt/tmp , this script will finish.
df | grep '/mnt/tmp$' > /dev/null
if [ $? -ne 0 ]; then
    if [ -f $TW_POST ]; then
        HM=`date +%H:%M`
        echo "disk cannot mounted. abort. $HM" > $TMP_FILE
        $TW_POST $TMP_FILE
        rm $TMP_FILE
    fi
    exit
fi
   

# copy
/usr/bin/rsync -Sax / $MNT_POINT --exclude "/data/" --exclude "$MNT_POINT/"
sleep 900

umount $MNT_POINT

test -f $DST_DIR/$DST_FILE  &&  rm -f $DST_DIR/$DST_FILE

(cd $TMP_DIR ; tar -Szcf $DST_DIR/$DST_FILE ./$TMP_IMAGE )

rm -f $TMP_DIR/$TMP_IMAGE

if [ -f $TW_POST ]; then
    HM=`date +%H:%M`
    echo "disk image backup finished at $HM" > $TMP_FILE
    $TW_POST $TMP_FILE
    rm $TMP_FILE
fi

Xen

禅。
唐突ですが、自宅サーバを仮想化しました。

これまでも設定ファイルなどをtarで固めて外部ストレージに書きだしてバックアップとしていたのですが、いざ故障が発生してサーバ移行を強いられた時にちまちまアプリケーションをインストールして設定ファイルから環境を戻して... というのがすごく面倒くさいのではないかと、感じたからです。
これまでも自宅サーバは幾度かの世代交代を行ってきて、そのたびに数日の稼働をかけながら復旧させていたのですがあまりにも面倒臭い。
もちろん、再設定を行うことで知識は深まるメリットはあるものの、正直やっぱり面倒くさい。

ならば、いつ本体が故障して新ハードウェアになったとしても、従来の環境をガッツリ戻せたほうが便利なのではないかと、そう思ったわけです。
というわけで、禅です。

自宅サーバ2011のスペック、環境について
ASUS EeePC 4G-X (日本発売EeePC初代モデル)
CPU Intel Celeron M 900MHz の 600MHz駆動
Mem DDR2 2GB に増設
eth0を使う(wlan0ではXenが使えない)
SSD 4GB(デフォルト)
SDHC 32GB

設計(最終的な環境)
ホストマシン、ゲストマシン ともに Debian GNU/Linux 6.0(squeeze)
仮想環境はXenを使用する。(EeePCはIntel-VTなど無いので、KVMは使用できない)
ホストマシン(domain-0)は SSD上に構築。メモリ割り当ては約0.5GB
ゲストマシン(domain-U)は SSD上にイメージファイルで構築。メモリ割り当ては1.5GB
ゲストマシン用のストレージとして SDHCを物理デバイスとして使用する。

なお、このblogは例によってメモ for 未来の私 です。

Xen 4.0 インストール

# aptitude install xen-linux-system-2.6.32-5-xen-68 xen-tools

他に入れたかもしれませんが、結局入っているXen関連は以下のとおりです。たぶん aptitudeが入れてくれるはずです。
debootstrapも入っています。

asatsuki@eeetan:~$ dpkg -l | grep -i xen
ii  libc6-xen                             2.11.2-10                    Embedded GNU C Library: Shared libraries [Xen version]
ii  libxenstore3.0                        4.0.1-2                      Xenstore communications library for Xen
ii  linux-image-2.6.32-5-xen-686          2.6.32-35squeeze2            Linux 2.6.32 for modern PCs, Xen dom0 support
ii  xen-hypervisor-4.0-i386               4.0.1-2                      The Xen Hypervisor on i386
ii  xen-linux-system-2.6-xen-686          2.6.32+29                    Xen system with Linux 2.6 for modern PCs (meta-package)
ii  xen-linux-system-2.6.32-5-xen-686     2.6.32-35squeeze2            Xen system with Linux 2.6.32 on modern PCs (meta-package)
ii  xen-tools                             4.2-1                        Tools to manage Xen virtual servers
ii  xen-utils-4.0                         4.0.1-2                      XEN administrative tools
ii  xen-utils-common                      4.0.0-1                      XEN administrative tools - common files
ii  xenstore-utils                        4.0.1-2                      Xenstore utilities for Xen

Xen設定
/etc/xen/xend-config.sxp で(本体)内部ネットワークにブリッジを生成するオプションを有効化(コメント外し)します。

 (network-script network-bridge)

grub設定
環境にもよりますが、Xen対応カーネルは grub的に言うと (0番目から数えて)4番目に該当するので、
/etc/grub/grub.cfg に set default="4" を書いておきます。
(menuentryの順番を書き換えて Xen対応カーネルを 0番目にして、set default="0"のままにしておくという方法もあります)

Xen-tools 設定
仮想環境構築を手助けしてくれる xen-toolsの設定ファイル /etc/xen-tools/xen-tools.conf を編集します。
変更場所は以下のとおりです。
(括弧内はもちろんこのblogのためのコメントです)

 dir = /data_local/xen  (仮想環境のイメージファイル作成場所。お好みのディレクトリに)
 size   = 2Gb (仮想イメージファイルサイズ)
 memory = 1536MB (割り当てるメモリ 1.5GB)
 swap   = 128Mb (スワップファイルサイズ)
 fs     = ext3 (ディスクフォーマット)
 dist   = `xt-guess-suite-and-mirror --suite` (Default distribution to install.)
 image  = sparse (スパースファイルでディスクイメージを作成)
 gateway    = 192.168.1.1 (ネットワーク関連設定)
 netmask    = 255.255.255.0 (ネットワーク関連設定)
 broadcast  = 192.168.1.255 (ネットワーク関連設定)
 arch = i386 (CPUアーキテクチャを指定)

仮想イメージ作成
(ゲストマシンのIPアドレスを 192.168.1.204とした場合)

# xen-create-image --hostname SERVERNAME --ip 192.168.1.204

おなじみのDebianインストールをして、終了させます。
/etc/xen/SERVERNAME.cfg が作成されているはず...です。

/etc/xen/SERVERNAME.cfg設定
bootローダーを pygrub に変更します。
これをしないとXenが正常に起動しませんでした。

bootloader = '/usr/lib/xen-default/bin/pygrub'

ホストマシンの SDHCは /dev/sdc1 として認識されているので、これをゲストマシンに
/etc/xen/SERVERNAME.cfg を編集して SDHCを割り当てます。

disk = [
  'file:/data_local/xen/domains/alpha/disk.img,xvda2,w',
  'phy:/dev/sdc1,xvda3,w',
  'file:/data_local/xen/domains/alpha/swap.img,xvda1,w',
]

             
file:~ はイメージファイルを指定する方法、
phy:~ は物理デバイスを指定する方法です。

このへんで一度ホストマシンを再起動しておきましょう。

ゲストマシン起動

# xm create -c SERVERNAME

ゲストサーバ SERVERNAME が起動して、そのコンソールに接続する... はずです。
ここでいろいろインストールするもよし、あとで行うもよし。
ホストマシンのSDHC /dev/sdc1 は ゲストマシンでは/dev/xvda3 として認識されているはずなので、/etc/fstabに書いておきます。

 /dev/xvda3 /data ext3 noatime,nodiratime 0 0

とりあえず shutdown させてホストマシンに戻ります。
コンソールから抜けるには Ctrl + ] を使います。

仮想(ゲスト)マシンの自動起動
ホストマシンを再起動したときにゲストマシンも自動的に起動する設定です。
/etc/xen/auto ディレクトリを作成し、その下にゲストマシンの cfgファイルを置きます。
実際にはシンボリックリンクを作成します。

# ln -s /etc/xen/SERVERNAME.cfg /etc/xen/auto/SERVERNAME.cfg

ものすごく雑ですが、これでゲストマシンが作成されました。
あとはゲストマシンに apache, mysql, php, squid, postfix, bind, dhcp 他、そのたもろもろサービスをインストール&構築してサーバ環境を構築しましょう。

Have Fun!

execute Dropbox on Text Based Linux

仮想化した自宅サーバのバックアップ方法として、ディスクイメージファイルを dropboxにアップロードする方法を検討しました。

サーバはCLIなので、TextBasedLinuxInstall を参考にインストールします。
参考に、というかそのままなのですが、ここにメモ for 未来の私。

Step-by-step versionの手順を踏みます。

1. Dropboxを利用するユーザでログイン
rootで動かすにはセキュリティ的にも不安があるので、一般ユーザでDropboxを動かすようにします。

2. wgetでソースをダウンロード
ホームディレクトリにダウンロードします。

$ cd ~/
$ wget -O dropbox.tar.gz "http://www.dropbox.com/download/?plat=lnx.x86"   

(64bit ver.の場合は wget -O dropbox.tar.gz "http://www.dropbox.com/download/?plat=lnx.x86_64"   )

3. tarボールを展開する...まえにチェック
tar t します

$  tar -tzf dropbox.tar.gz

4. 展開
tar x します

 $ tar -xvzf dropbox.tar.gz 

~/.dropbox/
~/.dropbox-dist/
2つのディレクトリが展開されます。

5. ランゲージ設定
環境変数 LANG を設定します。
私はCLIでしか使用しないので、'C'です。

$ export LANG=C LC_ALL=C

ログイン時に自動的に指定したいときは ~/.bashrc や ~/.profile などに この一行を入れておきます。

6. dropboxd起動
dropboxdを起動すると ~/Dropbox ディレクトリを作成します。
もし、異なるディレクトリを Dropboxファイル格納ディレクトリにしたい場合は、
そのディレクトリ(/data/Dropbox など)を作成し、~/Dropbox -> /data/Dropdox などのようにシンボリックリンクを作成します。
受け皿が用意できたら心を鎮めてプロセスを起動します。

$ ~/.dropbox-dist/dropboxd

初回起動時は怪しげなURLが数秒後とに表示されるので、別マシン(Mac や Windows)のWebブラウザからリンクに移動します。
This client is not linked to any account... Please visit https://www.dropbox.com/cli_link?host_id=謎の文字列  to link this machine.

うまくいけば Linuxマシンがクライアントとして認証され、上記メッセージは停止してクライアントとしての動作が開始します。

インストールはここまで終了です。

dropboxd は一般プロセスなので、ログインして起動しなければなりません。
nohup ~/.dropbox-dist/dropboxd &
でログアウトあとでも動くようにしても良いのですが、サーバ再起動後などはログインしなおしてまた実行しなければいけません。
そこで、プロセスの有無をチェックしてなければ起動するスクリプトを 1日1回程度 cronで実行するようにします。

スクリプトはこんな感じ

USERNAME@SERVER:~$ cat /home/USERNAME/bin/exec_dropbox.sh

#! /bin/sh
# check dropbox process, exec if dropbox process isn't exist.

A=`ps -ef | grep dropbox | grep '/home/USERNAME/.dropbox-dist/dropbox' | grep -v grep | sed '/^$/d' | wc -l`

if [ $A -eq "0" ]; then
    nice -n +19 /home/USERNAME/.dropbox-dist/dropboxd &
#    echo "execute dropbox"
fi

crontabはこんな感じ

USERNAME@SERVER:~$ crontab -l | grep dropbox

# execute dropbox
25 8 * * *    /home/USERNAME/bin/exec_dropbox.sh > /dev/null 2>&1

サーバ仮想化についてはまた後日...

Lion Library

先日MacBook Pro 15インチを購入しました。
本当は13インチで検討していたのですが、2011/7/20発表のMacBook Airが Core i7プロセッサを搭載して、そりゃ反則だろう! MacBook Pro13インチの立場はどうなるんだ?! と憤慨し(何に?)、ProがAirに負けるわけにいかないので(誰と勝負しているんだ?)、15インチを買ったというわけです(なんだこりゃ)

前環境(MacBook)のデータはタイムマシン経由などで引き継げるのですが、なにぶん前々環境(MacBookG4)の10年前のPanther時代から引き継がれて既に使用していないファイルも多々有りそうなので、今回は一から構築しました。

前Macのデータは以下のコマンドでUSB接続HDDに保存しておきます。
(HDD320GはUSB接続HDD名です。適宜環境に合わせて読み替えてください)

OldMacBook> cp -R ~ /Volumes/HDD320G/

新MacBook ProにUSB HDDを接続して、各アプリケーションに関連したデータを個別にコピーします。
が、そこでわかる新事実、
Lionではfinderからライブラリ(Library)ディレクトリがデフォルトで不可視らしいので、ターミナルからコマンドラインでシンボリックリンク(ソフトリンク)を作成してfinderからアクセスできるようにします。

NewMacBookPro> ln -s ~/Library ~/Link2Library

これで Link2Library というディレクトリ(のようなもの)がホームに現れるので、そこから ライブラリ ディレクトリにアクセスできます。

後でわかったのですが、こんなの事をしなくても
Lionのライブラリフォルダはどこにいった？のようにfinderのツールバーにある「移動」をOptionを押しながらクリックすれば見えるそうです。
(でも忘れそうなので、環境構築が終わるまではシンボリックリンクは残しておきました)

アドレスブック、iCal、Firefox、Thunderbird、Virtualbox などのデータを ライブラリ配下にコピーして環境の移行完了。
ホーム配下のミュージック、ピクチャ なども旧環境通りにファイルを配置して、かなりスムーズに環境移行が出来ました。

感想: やっぱりMacBook Proは速い。

キンエン、キツエン

禁煙と喫煙をよく間違えそうになります。
キンエン と キツエン で ひと文字しか違っていないのがよろしくないのではないでしょうか。

モノゴトAとBがあり、Aを覚えておかなければならない時に、
「Aである」
と覚えれば苦労はありませんが、
なぜか
「Bではない」
と覚えてしなうと酷く混乱を招くことになります。

先日飲食店に入ったときも、
「煙草は吸いますか?」
と案内の店員さんに対して即答できずに
「ン だったか ツ だったか、ツ ではなく ン の方だったよな」
と悩んでいたら、言葉が通じない客と思われたのか ピースサインを口元で作ってゼスチャーされてしまいました。

その点、英語はいいですね。
「ノー スモーキング」
とりあえず頭に「ノー」を言えば間違いありません。
また日本語の特徴で「喫煙席ですか」と「禁煙席ですか」の問いに対して答えを異なるものにする必要があります。

だからと言って日本語がダメだとか、ンキエン と ツキエン にしろと言うつもりはありませんよ。

ノータバコ、タバコハダメデス。