MondoRescueでさくらのVPSのDebianをVMwareの仮想マシンに持ってきた

MondoRescueでさくらのVPSをVMwareの仮想マシンにコピーしたいの続きっす。成功したと言っていいのやら・・・とりあえず起動はしたので後人のためにメモを残しときます。

今回の環境

  • さくらのVPS 2G
  • Debian 6.0.7
  • MondoRescue v3.0.4-r3177
  • VMware Fusion 5.0.3

Mondo Rescueについて

  • Linux上で使い自らのシステム全体をバックアップ、リストアするツール
  • Debianにはaptのソースリストがある
  • Mondo Rescueでのバックアップは mondoarchive コマンド, -i オプションでISOファイルとしてバックアップができる
  • -i オプションはデフォルトだとCDなので、DVDなら -s 4200m などDVDサイズ程度を指定する
  • VMwareだとISOファイルを順に選択することでディスクの入れ替えはできるがメディアに焼くことも考えるとDVDサイズが良いだろう
  • バックアップ中のファイル変更は監視されないのでリストアを確認するまでは気を抜けない
  • さくらのVPSはISOイメージでのインストールも対応しているのでさくらのVPSのバックアップとしても活用できるらしい

Mondo Rescueのインストール

/etc/apt/sources.list に下記を追加

deb ftp://ftp.mondorescue.org/debian 6.0 contrib
deb-src ftp://ftp.mondorescue.org/debian 6.0 contrib

mondoでインストールできる。

apt-get update
apt-get install mondo

root directoryがなんちゃらと言われたがデフォルトのallを設定。

W: mdadm: /etc/mdadm/mdadm.conf defines no arrays.
W: mdadm: no arrays defined in configuration file.

は無視。

バックアップするDebianではあまりディスク容量は使っておらず5GB程度しか使っていない様子。というわけでデフォルトの圧縮率で実行してみる。

mondoarchive -Oi -N -s 4200m -p `hostname`-`date '+%Y%m%d'` -d /backup -E /backup

-Oiがisoイメージを生成用、-sがイメージを分割するサイズ、-pがファイルのプレフィックス、-Nがネットワークドライブを無視、-dがバックアップ出力先、-Eがバックアップから除外するディレクトリ。

だいたい20分くらいかかり2.5GBのisoファイルが作成された。scpでローカルにコピー、5分ほどかかった。

ちなみに-Lオプションを使うとbzip2の代わりにlzoで圧縮し、圧縮率は落ちるがバックアップにかかる時間を短縮することができる。ネットのメモを公開している先人達はこのオプションを使っている人が多い。対象が5GBだからと甘く見て今回は使わなかった。(結果20分もかかった)

VMware Fusionにインストール

OS XなのでVMware Fusionをつかう。恐らくVMware Playerでも手順はさほど変わらないはず。

新規に仮想マシンを選択し、isoファイルを選択する。

デフォルトの仮想マシンの設定ではハードディスクがSCSI接続で20GBが初期値になる。さくらのVPS 2Gプラン上でバックアップしたDebian環境ではパーティションはこのようになっていた。特に/bootはパーティションを切っておらず、いつも冗長で使いこなせないので無駄にパーティションを切らなかった気もするが、さくらのVPSでインストールしたらデフォルトがこうなのかもしれない。セットアップ時の記憶がない。

   Device Boot      Start         End      Blocks   Id  System
/dev/vda1   *           1       25608   205688832   83  Linux
/dev/vda2           25608       26109     4023297    5  Extended
/dev/vda5           25608       26109     4023296   82  Linux swap / Solaris

仮想マシンが起動すると boot: とシェルプロンプトが表示されモードを入力する。nuke(auto)を使ったりexpertを使ったりしたがGRUBのインストールはこけたのであんまり関係ない気がする。nukeで薦めてもディスク情報がが違うのでインタラクティブモードでパーティションのセットアップをさせられる。もともとバックアップが5GB程度だったのでVMwareの仮想マシンの初期の20GBで十分。Swapであるsda5を2GBにして、sda1を17GB程度にしておいた。

次に進むと初期化するか、データを読み込むかと着替えるのでYESで進めていく。ただし、リストア後にOperationSystem not Foundと言われてGRUBが検出されなかった。

expertモードやってみたこと

ディスク情報が違うので /etc/fstab/dev/vda/dev/sda に置き換て UUID 削除、/etc/mtab も同様に置換。

/etc/default/grubGRUB_DISABLE_LINUX_UUID=trueアン コメント。でも grub-install /dev/sdaとかやっても cannot stat `/dev/sda’ と言われてディスクが認識されていない様子。マウントはしてるしリストアしたデータは見えてるんだけど、このあたり詳しくないんでよくわからない。

ちなみにautoモードでやっても起動はできずログはこんな感じ。

Launching: chroot /mnt/RESTORING grub-install /dev/sda
/usr/sbin/grub-probe: warn: disk does not exist, so falling back to partition device /dev/sda1.
/usr/sbin/grub-probe: warn: disk does not exist, so falling back to partition device /dev/sda1.
/usr/sbin/grub-probe: error: cannot stat `/dev/sda'.
grub-install returned 1
Now I'll use grub2-install
chroot: can't execute 'grub2-install': No such file or directory

バックアップ時にブートローダーは指定しなくても自動で検出されると書いてあったけど、ログを見る限り grub-install を探して試して、 grub2-install を探して試して・・・と地道なことをやっている様子。

Linux Rescue モードで修復する

おそらくモジュール関連を見なすべきなのだろうと思いつつ、P2Vならまだしも仮想環境から仮想環境の移行で何故にハードウェアを意識せねばならぬのかと面倒になって、DebianのネットワークインストールCDのisoファイルをダウンロードして、VMwareの仮想マシンからCDブートしてレスキュモードを実行してGRUBのインストールを決行。

あっさりとインストールは成功し、再起動後に無事にGRUBが立ち上がり、選択したDebianが起動した。

起動後の調整

さくらのVPSでわりあててもらったグローバルIPが静的IPで設定されていたのでDHCPに変換。

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet dhcp

/etc/network/interfaces を上記のように変更して再起動後、VMware仮想ネットワーク(NATモードの場合)のIPアドレス(172.16.x.x)になったことを確認し、sshで無事接続。

ブログを表示してみて、昨日のエントリは表示されなかったのでバックアップの状態で動いていることが確認できました。ようやくこれで目的であったOSのアップデートのテストができます。MondoRescueでリストアができるけど起動できない場合は、MondoRescueで頑張るよりも大概用意されているLinuxインストールCDにあるレスキュモードを使うと早いよという話でした。

MondoRescueでさくらのVPSをVMwareの仮想マシンにコピーしたい

さくらのVPSのOSをアップグレード(Debian 6->7)したいのでMondoRescue を使って仮想環境をコピーして予行演習をやりかったのだがうまくいかない。

さくらのVPSはデバイスがVirtioになっていて、VMware (Fusion)はデフォルトだとSCSI接続のハードディスクをエミュレーションしているので先人さん達の情報を元に/dev/sdaに置き換えてリストアしてみたものの、起動OSが見つからないと言われて起動しない。

この辺りはMondoRescueがよしなにやってくれると期待していたのだがGRUBあたりの設定がうまくいっていない様子。

OSをアップグレードしたらMinecraft Serverをアップデートして、Minecraft 1.6にあげたいのだけど。むむー。

VMware Player 5.0上に開発環境や検証環境を作るのは非営利目的として使える

VMware Player 5.0への更新が促されたので更新してみたら、アプリケーションのタイトルバーに「非営利目的の使用のみ」という若干ビビる内容の文字列が表示されるようになった。

VMware Player 5.0

いままでVMware Playerのライセンスについては以下の記事を見て企業内においてもOSやアプリの検証や開発環境の構築で使う分には問題ないと判断していた。

2011-05-26 VMware Player のライセンス(商用利用について)
http://red-treasure.com/report/?p=622

しかし5.0で表示が変わったことでライセンスも変わったのではないかと勘ぐる。以下のEULAを確認し許諾ボタンを押せずにしばしとどまる。

VMware Player

お客様は、お客様個人の営利目的以外の使用を目的とする場合、ライセンスを購入せずに本ソフトウェアをインストールおよび使用できます。

お客様は、内部業務の目的で、購入したライセンス数と同じ数のコンピュータで、本ソフトウェアをインストールおよび使用できます。複数のコンピュータ上でソフトウェアのシングルライセンスをインストールおよび使用することは、それらのコンピュータ上で本ソフトウェアが同時に実行されていない場合であっても禁止されています。VMware Player のライセンスの詳細については、http://www.vmware.com/go/player を参照してください。

しかし参照先のサイトを見てもやはり何か変わったのかはわからない。商用で使うならVMware Fusionのライセンスを買えとしか書いていない。そこで自分もVMwareへ質問しようと思ったが入力フォームの多さに面倒になってぐぐってみたらすでに質問してくださった人がいた。

2012-08-31 VMwarePlayerの「非営利目的の使用(商用利用)」はどこまで?
http://blog.cnu.jp/2012/08/31/vmwareplayer/

結論からいうとVMwareが言うところの営利目的というのは今まで変わっておらず。

弊社が定義しております商用利用は、そのライセンスを使用して直接的な利益を得るような行為を申します。 つまり、そのライセンスを第三者に提供、あるいは貸与する行為等で利益を得ることです

ということだ。

最悪の場合、例えば個人で有料のスマホアプリを販売していて、そのサーバサイドの開発環境をVMware Playerで構築するケースも該当するのかとドキドキしていたが単にソフトウェアの開発環境や検証環境の構築としてVMware Playerを使う分には今まで通り問題なさそうだ。

しかし変わっていないのになぜタイトルバーに表示するような画面変更をしたことは謎である。

逆にVMwareが指している営利目的という具体的な例がよくわからない。たとえばシステムにVMware Playerを組み込んだものを作って売るようなことだと思うのだが・・・ありそうか。システムに制限があったらありそうか。

画面変更するということはやはり実際に彼らが言うところと営利目的で使う輩がいるのだろうと勝手に自己解決。

VMwareイメージで公開されているGitLabを試してみる

GitLabとはGithubクローンで、要はGitリポジトリを閲覧できるソフトウェアプロジェクト管理のためのツールである。さくらのVPS 2Gを新規に契約したのでインストールしようかと思ったがRedmineと用途がかぶるうえにシステム要件もかぶる、Rubyのバージョンが微妙に違うし、GitLabの標準手順だとNginxを使うようだし、悩んでいた。先にVMware上にインストールしてためしてみるのがよいかと思ったらVMware Imageが公開されていた。

https://github.com/gitlabhq/gitlabhq/wiki/Vmware-image

しかしいろいろハマったので上記イメージから試す手順を多少手直ししておく。

notrootユーザ周り

user: notroot
pass: gitlabhqthoughtpolice

まず最初からハマったが wikiに書いてあるパスワードが違う という。チケットに問題があがっていたので解決、これはそのうちImageかWikiかが改修されるだろう。とりあえずこの時点で試した場合はパスワードは thoughtpoliceだった。

あとこのnotrootはsudo出来ないのでいろいろ困ったと思ったが、rootのパスワードもthoughtpoliceだった。

キーボード設定

とりあえず106が見つからなかったが、Generic 105-key -> Japan にすればよいらしい。

su
dpkg-reconfigure keyboard-configuration

変更後、解決しなかったがいろいろあった後に再起動したらうまく行っていた。

バーチャルホストの設定

ゲストOSでifconfigを実行してipアドレスを調べてホストOSから接続してみた。しかし接続するとなぜか http://192.168.0.105 にリダイレクトされてしまうので設定を変更した。

su
vi /etc/nginx/sites-enabled/gitlab

で 192.168.0.105 の部分をipconfigで得たIPアドレスに変更する。そしてNginxを再起動。

/etc/init.d/nginx restart

ゲストOSもDHCP設定なので設定したIPアドレスも固定ではないが、とりあえずのお試しなので良とする。

表示

自分の環境ではifconfigの結果は 192.168.1.27 だったので http://192.168.1.27 をホストOSからブラウザで開いてみた。

テストプロジェクトを作ってみたが最初は何もできない。Githubを使ったことがある人なら知っていると思うが、プロジェクトページを開いても最初のコミットをpushするやり方が表示されるだけである。しかたないので言われたとおり空のREADMEをpushしてみた。

Githubと微妙にできることが違うらしい。タブを見ている限りだとWallというページがあって、これはFacebookのWallのように小さなメッセージが書き込めるページになっている。ちょっとした進捗とかの情報共有に使われるのだろうか。

Wikiも使えてmarkdown形式で記述できるようだ。

その他

以下のコマンドがうまく行かなかったので無視してホストOSから普通にWeb UIベースでsshキーを設定した。

sudo -H -u git gitosis-init < ~/.ssh/id_rsa.pub

その他ProfileやIssueの登録などいろいろなところで500エラーになったが、原因を調査していないので不明。

感想

tracとかRedmineとかあんまりUIが今風っぽくないので代替として使ってみたかったGitLabだが、gitリポジトリありきのプロジェクトとなるとtracやredmineで管理しているようなsvnプロジェクトとか単にインストーラを配布するだけのプロジェクトなどを移行して使うのはちょっと難しいのかなという感じ。

GitLabに向いているプロジェクトはGithubに公開すればいいわけで今の所そこまでプライベートにしないといけないプロジェクトはないし、Github/gitのいいところはforkだと思っているからあまりプライベート公開を率先してもつまらないしね。

というわけで今のところはGitLabは使ってみたいけど、使う場面があまりないかなーという感じ。

VMwareで開発環境や実行環境を構築する利点・欠点の考察

VMWareを使って様々なプロジェクトの開発やビルド環境を仮想環境で共有しようと考えたが、いろいろ発見があったので書いてみる。

まずゲスト開発者の視点と担当の開発者の視点で要求がかわってくることに気がついた。前者は簡単に環境に触れられることを期待し、後者は日常の生産性を重視する。簡単に触れることを踏まえるとゲストOS上にIDEなどを揃えてしまうことを考えるが、EclipseなどのIDEはメモリを結構食う。連携する複数のプロジェクトの仮想環境を同時に動かす場合に仮想環境ごとにEclipseを立ち上げていてはホストOSのリソースが枯渇してしまう。

さらにソースコードをゲストOSだけに置いてしまうと、仮想環境を起動していないとソースが見れない、プロジェクトをまたいでソースコードを検索できないといったことが起きる。これらを解決しようとすると結局ホストOSですべてのプロジェクトのソースを持ちたくなる。IDEやソースをゲストOSに持たせるかホストOSに持たせるかは重要な要素である。

次に仮想環境を”共有”しようとするとソフトウェアライセンスの問題が発生する。LinuxやEclipseのようなフリーの環境は良いが、WindowsやVisual Studioは難しい。MSDNサブスクリプション会員同士であれば共有してよいような感じはするが、実作業を考えるとテキストエディタ(秀丸)やマージツール(AraxisMerge)など共有できないものが以外と普段の生産性に寄与していることに気がつく。プログラマーならみんなお気に入りのツールを持っているはずで、それらを全てライセンスフリーのツールで代用するというのは難しい。

さらにソフトウェア以外でもリポジトリへのアクセスなど人に属する情報は共有する仮想環境には入れられないという問題がある。コミットしないreadonlyなゲスト開発者なら良いが、コミットしたい担当者の場合、共有した仮想環境を取得したらまず、git configなり開発者固有の情報を設定してもらわないといけない。逆に今使っている仮想環境を公開しようと思うとgit configからひと通り[user]の設定を消さないといけなく仮想環境の更新の際は面倒である。

そこで仮想環境は単なる実行環境として扱い、ホストOSで開発を行うという手段が有効なのではないかと思うようになった。VMWareではホストOSにあるディレクトリをゲストOSに共有フォルダとして共有できる。Windowsの場合はUNCパスだと微妙なことがあるのでsymlinkをはったり共有フォルダにドライブレターを割り振ったりする必要があったりもするようだが。ソースコードやIDEがホストOSにあることでソースコードが分散したり、リポジトリの認証などの情報をゲストOSに置かなくても良くなる。IDE、readonlyなソースはゲストOSに置いてあげるというゲスト開発者への共存も成り立つ。

さらに実際やってみると、Webの実行環境なんかはWindowsやMacOSXで頑張ってつくるよりもLinuxな仮想環境で構築したほうがいろいろとメリットがあるのではと思ってきた。なんだかんだでWindowsやMacOSXでWebの実行環境をつくるのは簡単になってきているが、それでもLinuxに比べればまだまだだし、何より情報量が違いすぎる。あとメインストリームな環境は良いがちょっと道をそれたバージョンとかになるとLinuxと比べてWindowsやMacOSXでは一気に難易度が高くなるような感じする。

その他ではたまにしかメンテナンスしないプロジェクトの環境をいちいちメインPCで持っているのはシステムドライブの容量として勿体ないと思うようになった。SSDなら特にそう感じる。開発PCが壊れた時やOSの更新の時を考えると一から環境をつくるのはそれなりな労力になる。多くの場合ソースコードなどのデータの移行とアプリケーションの移行は別になり、後者は面倒な場合が多い、ものによってはOSを変えると動かなくなることもある。特にリリースエンジニアリングに使うビルド環境はその傾向が高いように思える。こういう場合は仮想環境でOSから別にしておいた方ががよいし、メインマシンの故障時のリスクの分散にもなると思った。

あと開発環境や実行環境の構築に特殊なシステム要件が必要でなく、かつ構築が簡単そうなものはわざわざ仮想環境にしなくてもいいかなぁと思ったりする。なんというか環境をつくるのも勉強になったりするし何でもかんでも仮想環境にして楽するのどうかなぁと。このあたりの線引きはちょっと難しいな。