とあるエンジニアの備忘log

2013年7月17日水曜日

make が関数を展開するタイミング

GNU make での話。

makefile のコマンド行は単純に、上から1行ずつ順番に実行されるものと思っていた。

例えば、次のような makefile を作成。

all:
        echo foo > a
        cat a

`echo` コマンドをファイルにリダイレクトし、すぐさま `cat` で読み出すという単純なものです。試しに実行してみます。

$ make
    echo foo > a
    cat a
    foo

予想通りの結果。

では、 makefile をちょっとだけ変えて、

all:
        echo foo > a
        echo $(shell cat a)

としてみる。同じ結果になると思いきや、、

$ rm -f a
    $ make
    cat: a: そのようなファイルやディレクトリはありません
    echo foo > a
    echo

なんと、動かないではないか！

`echo foo > a` よりも `cat a` が先に実行されてしまっているようです。

この実験結果を見ると、上から1行ずつ関数を展開しつつ実行するのではなく、
すべての関数を展開してしまってからコマンド行を上から順に実行するように見えます。

しかも、関数を展開する順番は、出現順でもないらしい。

例えば、

all:
        : $(shell touch a1)
        touch a2
        echo $(shell ls a*)

という makefile を実行すると

$ rm a*
    $ make 
    : 
    touch a2
    echo a1
    a1

となった。

`$(shell touch a1)` → `$(shell ls a*)` の順に行われているようです。

一方、

all:
        : $(shell touch a1)
        touch a2
        echo $(wildcard a*)

という makefile を実行すると

$ rm a*
    $ make 
    : 
    touch a2
    echo

となった。

今度は `$(wildcard a*)` → `$(shell touch a1)` の順に行われたようです。

2013年6月25日火曜日

VirtualBox 自動起動

ホストOSが起動した時に、ゲストOSも自動的に起動して欲しい！そう思ってやってみました。

動作確認は Ubuntu 12.04 LTS および Ubuntu 13.04 で行なっています。

- VirtualBox 本家からダウンロードしてインストールした場合
- Ubuntu 13.04 で apt-get でインストールした場合
- Ubuntu 12.04LTS で apt-get でインストールした場合

の順番に説明します。たぶん、最初のが正式？なやり方。

### 本家からダウンロードする場合 ###

<http://www.virtualbox.org/manual/ch09.html#autostart-linux>
に記載があるのですが、VirtualBox 4.2 から autostart に対応しています。

一応、Ubuntu でやってみましたが、同じやり方でほぼすべてのディストリビューションで動くはず。

#### インストール方法 ####

<https://www.virtualbox.org/wiki/Downloads> のページに行き、
自分のディストリビューション用のパッケージをダウンロードしてきて、インストールする。
(現時点では VirtualBox 4.2.12 for Linux というのがダウンロードできるようだ。)

#### 設定方法 ####

$ sudo -i
    # mkdir -p /etc/vbox/autostart_db
    # chmod 1777 /etc/vbox/autostart_db
    # echo "default_policy = allow" > /etc/vbox/autostart.cfg

みたいな感じで、データベースディレクトリ `/etc/vbox/autostart_db` およびコンフィグファイル `/etc/vbox/autostart.cfg` を作ります。

名前は必ずしもこの通りでなくてもいいです。
後で `VBOXAUTOSTART_DB` 変数と `VBOXAUTOSTART_CONFIG` 変数にこれらのパスをセットするので。

`/etc/vbox/autostart_db` ディレクトリは一般ユーザーが設定ファイルを作成したり、削除したりするので、全員に書き込み権限を与えます。
ただし、他のユーザーの設定ファイルを勝手に削除できないように、sticky ビットを立てておきます。

`/etc/vbox/autostart.cfg` のコンフィグファイルは

# Default policy is to deny starting a VM, the other option is "allow".
    default_policy = deny
    
    # Bob is allowed to start virtual machines but starting them
    # will be delayed for 10 seconds
    bob = {
        allow = true
        startup_delay = 10
    }
    
    # Alice is not allowed to start virtual machines, useful to exclude certain users
    # if the default policy is set to allow.
    alice = {
        allow = false
    }

みたいな感じでユーザーごとに設定することもできるが、とりあえず

default_policy = allow

の1行だけ書いておけば動きます。

次に、 `/etc/vbox/vbox.cfg` (または `/etc/default/virtualbox`) というファイルを作って、データベースディレクトリと設定ファイルへのパスを追加します。

VBOXAUTOSTART_DB=/etc/vbox/autostart_db
    VBOXAUTOSTART_CONFIG=/etc/vbox/autostart.cfg

みたいに追加します。

続いて、ユーザーごとの設定をします。

$ VBoxManage setproperty autostartdbpath /etc/vbox/autostart_db
    $ VBoxManage modifyvm VM_NAME --autostart-enabled on

とします。 (`VM_NAME` の部分は動かしたい仮想マシン名に置きかえてください。)

上記をすると、 `~/VirtualBox VMs/VM_NAME/VM_NAME.vbox` に以下のように Autostart enabled の設定が書き込まれます。

さらに `/etc/vbox/autostart_db/` 以下に `USER_NAME.start` というファイルが作られ 中身は `1` が書かれています。
ファイルの中身は、自動起動する仮想マシンの台数を表しています。

もう一台 `--autostart-enabled on` すると `2` になります。
中身が `0` になるとファイル削除されます。

`VM_NAME.vbox` とか `/etc/vbox/autostart_db/` 以下のファイルを直接いじると辻褄が合わなくなるので、理屈を理解しないうちは

$ VBoxManage modifyvm VM_NAME --autostart-enabled on

とか

$ VBoxManage modifyvm VM_NAME --autostart-enabled off

とかコマンドで操作するのがよいです。面倒ですけどね。。

ちなみに

$ VBoxManage modifyvm VM_NAME --autostop-type acpishutdown

として autostop の設定もすることはできますが、現時点では autostop は動かないらしい。。

以上で、設定は完了です。

再起動すると、VirtualBox も自動起動するはず、、、と思ったら起動しない。

ちょっと落とし穴がありました。

`/etc/init.d/vboxautostart-service` の中身を見てみると

vboxdrvrunning() {
        lsmod | grep -q "vboxdrv[^_-]"
    }

のように vboxdrv モジュールがロードされているかどうかを確認するコードがあります。
vboxdrv をロードしているのは `/etc/init.d/vboxdrv` です。

つまり、 `/etc/init.d/vboxdrv` より後に `/etc/init.d/vboxautostart-service` が実行されないといけません。

`/etc/rc2.d/` の下を `ls -l` で見てみると、

S20vboxautostart-service -> ../init.d/vboxautostart-service
    S20vboxdrv -> ../init.d/vboxdrv

となっています。怪しいな。。

そこで `S20vboxdrv` を `S19vboxdrv` にリネームしてみました。

S19vboxdrv -> ../init.d/vboxdrv
    S20vboxautostart-service -> ../init.d/vboxautostart-service

これで再起動すると、、バンザーイ。動きました。

`/etc/init.d/virtualbox` は簡単なシェルスクリプトなので読んでみると、起動時のシーケンスは

1. `/etc/init.d/vboxautostart-service` を実行
2. `/etc/vbox/vbox.cfg` と `/etc/default/virtualbox` 読み込む
3. `/etc/vbox/autostart_db/*.start` を見て、ユーザーを確認
4. ユーザーごとに `/usr/lib/virtualbox/VBoxAutostart` を実行。引数に `/etc/vbox/autostart.cfg` を渡す

という感じになっているようです。

### Ubuntu 13.04 で apt-get でインストールした場合 ###

Ubuntu 13.04 で

$ sudo apt-get install virtualbox

でインストールした場合です。

この場合、VirtualBox4.2.10 がインストールされますが、本家サイトからパッケージをダウンロードしてきた場合と、 etc ファイルの構成がかなり異なります。

本家パッケージをインストールしたときにあった

- `/etc/init.d/vboxautostart-service`
- `/etc/init.d/vboxballoonctrl-service`
- `/etc/init.d/vboxdrv`
- `/etc/init.d/vboxweb-service`
- `/etc/vbox` ディレクトリ

が、Ubuntu 13.04 で apt でインストールした場合にはありません。

その代わり、

- `/etc/init.d/virtualbox` : `/etc/init.d/vboxdrv` の代わり
- `/etc/defauult/virtualbox`

があります。

`/etc/init.d/vboxautostart-service` が存在しませんので、代わりとして `/etc/rc.local` に `VBoxAutostart` を叩くコードを追加してみました。以下のような感じです。

binary=/usr/lib/virtualbox/VBoxAutostart
    /sbin/start-stop-daemon --background --chuid USER_NAME --start --exec $binary -- --background --start --config /etc/vbox/autostart.cfg

`USER_NAME` の部分は、動かしたい仮想マシンの所有者に置き換えてください。

次に `/etc/vbox/autostart.cfg` を作り、以下の内容を記載。

default_policy = allow

あとは自動起動したい仮想マシンの `VirtualBox VMs/VM_NAME/VM_NAME.vbox` を開き、以下のように1行追加。

### Ubuntu 12.04LTS で apt-get でインストールした場合 ###

Ubuntu 12.04 LTS で

$ sudo apt-get install virtualbox

でインストールした場合です。

VirtualBox のバージョンは 4.1.12 で `/usr/lib/virtualbox/VBoxAutostart` も存在しないので、上記のやり方は使えません。

`/etc/rc.local` に以下の行を追加しておきます。

su - USER_NAME -c "VBoxHeadless -startvm VM_NAME &"

`USER_NAME` の部分はユーザー名に、`VM_NAME` の部分は動かしたいバーチャルマシンに置き換えてください。

というか、これが一番簡単かも。VirtualBox 4.2 以前でも使えるし。

Ubuntu 13.04 アップグレード後始末

RAID 上の Ubuntu をアップグレードする

Ubuntu 12.04 LTS から Ubuntu 13.04 にアップグレードしてみました。

マシンは、以前 [Linuxインストール on RAID (Intel RST)](/2012/09/linux-on-raid5-intel-rst.html) で書いた SDD 4 台で RAID5 構成です。

いきなり 13.04 にアップグレードできないので、 12.04 ⇒ 12.10 ⇒ 13.04 へとアップグレードすることにしますう。

アップデートマネージャーで 「設定...」を選び、

Ubuntu の新バージョンの通知:

を「長期サポート(LTS)版」から「すべての新バージョン」へ変更する。

すると、「Ubuntu の新しいリリース '12.10'が利用可能です」というのが出てくる。

普通ならこれで簡単にアップグレードできるはずなのですが、困ったことに RAID を組んでいると、GUI でうまくアップグレードしてくれないみたいです。

Googleで調べつつやって、うまくいったので、やり方をまとめておきます。

とりあえず、アップデートマネージャーでアップグレードしていきました。

途中で、「起動デバイスへの GRUB の書き込みが失敗しました。続行しますか？」と出てくる。

[![grub-install failed](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgr4b_u5uBEv745EWcRgCZu0wQVRGMV0GmoBVVQ_T_fBlugq-6_sUjhWpmhXXyeGpaoUYwvOkUUqupJc_bu5ASNh3xV3v6I2ekoJy8Wx4656NpAPx7Xcdm-5SgEOMMS-dPGA7v55kI9hOk/s320/grub-fail.png)](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgr4b_u5uBEv745EWcRgCZu0wQVRGMV0GmoBVVQ_T_fBlugq-6_sUjhWpmhXXyeGpaoUYwvOkUUqupJc_bu5ASNh3xV3v6I2ekoJy8Wx4656NpAPx7Xcdm-5SgEOMMS-dPGA7v55kI9hOk/s1600/grub-fail.png)

とりあえず、続行ボタンを押して、後で手動で GRUB をインストールすることにする。

で、最後までいって、再起動する直前に端末から

$ sudo grub-install /dev/mapper/isw_bdafdjfgcf_Volume0
    Path `/boot/grub' is not readable by GRUB on boot. Installation is impossible. Aborting.

とやったのですが、失敗。ガビーン。
(`isw_xxxxxxxxxx_Volume0` の部分は人によって違うでしょう。)

このまま再起動するも、やっぱり起動せず。

こういう困った時のために [Boot Repair](https://help.ubuntu.com/community/Boot-Repair) という素晴らしいツールがあります。
メディアに書き込んで、Boot Repair からブート。

起動したら「おすすめの修復」というのを選択。

途中で、「ターミナルを開いて、次のコマンドを入力（またはコピー&ペースト）してください。」という指示が出るので、言われるままに実行していきます。

最後にGRUBをインストールする画面が出てくるので
「/dev/mappder/isw_xxxxxxxxxx_Volume0」を選択します。

これで再起動すると、 Ubuntu 12.10 が起動するようになった。
困った時の Boot Repair 、覚えておこう。

Ubuntu Old Releases

何かで必要になった時のために。

- Warty Warthog Sounder: <http://releases.ubuntu.com/4.10/>
- Hoary Hedgehog Array: <http://releases.ubuntu.com/5.04/>
- Breezy Badger Colony: <http://releases.ubuntu.com/5.10/>
- Dapper Drake Flight: <http://releases.ubuntu.com/6.06/>
- Edgy Eft Knot: <http://releases.ubuntu.com/6.10/>
- Feisty Fawn Herd: <http://releases.ubuntu.com/7.04/>
- Gutsy Gibbon Tribe: <http://releases.ubuntu.com/7.10/>
- Hardy Heron: <http://releases.ubuntu.com/8.04/>
- Intrepid Ibex: <http://releases.ubuntu.com/8.10/>
- Jaunty Jackalope: <http://releases.ubuntu.com/9.04/>
- Karmic Koala: <http://releases.ubuntu.com/9.10/>
- Lucid Lynx: <http://releases.ubuntu.com/10.04/>
- Maverick Meerkat: <http://releases.ubuntu.com/10.10/>
- Natty Narwhal: <http://releases.ubuntu.com/11.04/>
- Oneiric Ocelot: <http://releases.ubuntu.com/11.10/>
- Precise Pangolin: <http://releases.ubuntu.com/12.04/>
- Quantal Quetzal: <http://releases.ubuntu.com/12.10/>
- Raring Ringtail: <http://releases.ubuntu.com/13.04/>

FreeBSD のソースを git-svn で取ってきた

以前 [git-svn](/2012/10/git-svn.html) でも書いたのですが、プロジェクトの管理が cvs とか subversion とか聞いただけでも嫌になってしまう。

現在、FreeBSDは Subversion で管理されている。(以前は cvs だった。)

リポジトリの構造が、Subversion標準の

- trunk
- branches
- tags

になっていれば、git に変換するときにわかりやすいんですが、

$ svn ls http://svn.freebsd.org/base

で見てみると、そうはなっていないようです。

リポジトリの構造についての説明は

- <http://people.freebsd.org/~peter/svn_notes.txt>
- <http://www.freebsd.org/doc/en/articles/committers-guide/article.html#subversion-primer>
- <http://svn.freebsd.org/base/ROADMAP.txt>

にあたりに説明があるようですが、最後のリンクが一番わかりやすいと思う。

- base/head → trunk
- base/stable → branches
- base/releng → branches
- base/release → tags

という対応のようです。
(tags なのか branches なのかは、実はそれほど気にしなくてもよい。結局 git-svn で変換すると、 branches も tags も git 上ではブランチになってしまうので。)

base/projects の下はトピックブランチのようなのですが、 base/projects/<topic> の下にさらに trunk と branches があったりして、ポリシーが一定していないので、変換はあきらめ。

他にも、 base/vendor, base/vendor-sys とかいくつかのワークエリアがあるようだが、これらも無視した。

というわけで、

$ git svn clone -T head -t release -b releng -b stable http://svn.freebsd.org/base freebsd_base

という感じで変換して取って来ました。

途中何度か、サーバーのエラーか何かで止まったのですが、その度に `git svn fetch` で再開。

なんだか、むちゃくちゃ時間がかかる。しまった、 trunk だけにしとけばよかったか、と思いつつも、なんとか変換が終わりました。
(time コマンドで測ってみたが、58時間くらいかかった。。)

ちなみに、

head -> stable/* -> releng/*.* -> release/*.*.*

という風に、なっているので、基本的にブランチ(タグ)名はかぶらないようになっているはずなのだが、最初の頃はポリシーが徹底されていなかったのか、

`base/stable/2.0.5` と `base/releng/2.0.5` の名前がかぶっています。git に変換したときに 2.0.5 のブランチ名がかぶってしまうのですが、この処理がどうなっているのか不明。

FreeBSD 入門中その4 : 環境整備2

[前回](/2013/06/freebsd-3.html)の続きです。

検索すればすぐ出てくるような内容ですが、いちいち調べ直すのも面倒なので、メモしてあります。

### PAGER を lessに ###

PAGER をデフォルトの more から less に設定します。

bash系: `~/.profile` で

export PAGER=less

C shell系: `~/.cshrc` または `~/.login` で

setenv PAGER less

とする。
(個人的には、環境変数は `~/.cshrc` よりも `~/.login` に書く方がよいと思っているが。。)

### sudo できるようにする ###

Ubuntu に慣れていると、`sudo` できないと面倒に感じることがあります。

# pkg_add -r sudo

でインストールする。

# visudo

を実行して、

# %wheel ALL=(ALL) ALL

となっている部分のコメントを外す。

設定ファイルはなぜか `/etc/sudoers` ではなく、 `/usr/local/etc/sudoers` にある。

ここから先は、一般ユーザーでログインしなおして、必要な時のみ、`sudo` で (もしくは `su` で rootに変身して)実行することにする。

### NFS サーバー 設定 ###

`sysinstall` で Configure -> Networking -> NFS Server
途中で、 `/etc/exports` を設定してください、とエディタが開くので設定を書く。
`/etc/exports` の書き方はコメント欄 (または `man exports`)を見ればわかる。

`/etc/rc.conf` に以下が追加されるはず。

nfs_server_enable="YES"
    rpcbind_enable="YES"

`/etc/exports` を設定せずに ZFS の機能でやる方法もある。
例えば、 /homeディレクトリ以下を 192.168.xx.yy と 192.168.zz.ww へ公開する場合

# zfs set sharenfs="192.168.xx.yy 192.168.zz.ww" rpool/root/home

のようにする。
`/etc/hosts` に記載したホスト名で指定はできなさそう。
あと `-network 192.168.11.0 -mask 255.255.255.0` みたいな書き方もできなさそうだし。
 `/etc/exports` で設定したほうがよさそう。。

NAT経由のクライアントからマウントできるようにするには、 `/etc/rc.conf` に

mountd_flags="-n"

を書いておく。

### Auto Mount ###

次は、NFS クライアントとしての設定。
`/net/` 以下にアクセスしたときに、自動で mount し、しばらくアクセスしないと自動で umount して欲しい。

Linux では autofs だったが、FreeBSD では AMD (auto mount daemon) というデーモンがあるらしい。

`sysinstall` して Configure -> Networking -> AMD にチェックを入れる。
AMD Flags はよくわからんが、デフォルトのままで使えた。

`/etc/rc.conf` に以下が追加されるはず。

amd_enable="YES"

これでサーバー FOO が BAR というディレクトリで公開している場合、
`/net/FOO/BAR` にアクセスすると自動的にマウントしてくれるようになった。

### Linux のバイナリを実行可能にする

`/etc/rc.conf` に

linux_enable="YES"

を追加。

# pkg_add -r linux_base

でインストール。

### proc file system ###

`/etc/fstab` に以下を追加

proc     /proc    procfs  rw    0    0

### ssh X port Forward ###

`/etc/ssh/sshd_config` で

X11Forwarding yes

を有効にしてみるも、動かず。

後述の xorg をインストールしたときに、 `DISPLAY` 環境変数がセットされて、動くようになった。

よくわかりませんが、とりあえず動くようになりました。

### X の設定 ####

# pkg_add -r xorg

でインストール。

/etc/rc.conf に

hald_enable="YES"
    dbus_enable="YES"

を追加する。

$ startx

で起動する。 twm というWindow Manager が動く。

### gnome ###

# pkg_add -r

でインストール。

`/etc/rc.conf` に

gnome_enable="YES"

を追加する。(gnome関連デーモン起動)

システム起動時に gdm を起動させる場合は、

`/etc/rc.conf` に

gdm_enable="YES"

を追加。

`startx` で起動させる場合は

$ echo "/usr/local/bin/gnome-session" > ~/.xinitrc
    $ startx

### pkgng ###

pkg_* の代替ツール。 apt や yum みたいなもの。個人的には、必ずしも導入しなくてもよいと思う。

一応、[FreeBSD pkg_*システム捨てるのはいつ？今でしょ！](http://april.fool.jp/blogs/?p=1947) を参考に使ってみた。

最初に

# pkg

とやるとセットアップしてくれる。

`/etc/make.conf` に以下を追加。

WITH_PKGNG= yes

すでに `pkg_*` を使っていた場合は `pkg2ng` でデータベースを移行。

現時点では、リポジトリがすっからかん(サーバーに侵入されたらしい)なので

`/usr/local/etc/pkg.conf` を開き、

packagesite: http://pkgbeta.FreeBSD.org/freebsd:9:x86:64/latest

をコメントアウトし、

packagesite: http://ftp.jaist.ac.jp/pub/PC-BSD/packages/9.1-RELEASE/amd64

を追加。

あとは、 `pkg install PACKAGE_NAME ...` でインストールしていく。

pkg install emacs

とすると、`Conflict found on path` というエラーメッセージが大量に出てびっくりした。

`pkg install emacs` は複数のバージョンの emacs を一度にインストールしようとするらしく、
`pkg install emacs-24.3,3` みたいにバージョンまで入力しないといけないらしい。

apt や yum に比べると、このあたりは洗練されていない気がするなぁ。

登録: 投稿 (Atom)