shimarin / walbrix.old Goto Github PK

ブートパーティションにある WALBRIX_系変数の設定ファイルも walbrix.cfg なので合わせた方が良いし、grubに読み込ませる以外の用途（バージョンやビルドIDの確認）にも使われているため。

レスキューモードでVPN接続や外部からのsshログインを可能にするため、

• /etc/conf.d/hostname
• /etc/conf.d/keymaps
• /etc/openvpn/client.key
• /etc/openvpn/client.crt
• /etc/ssh/ssh_host_*
• /etc/wb/backup
• /root/.ssh/authorized_keys
• （・・・だけでいいだろうか？）

の内容を無圧縮tarにかためて /.overlay/boot/walbrix.emg に保存するコマンドを実装する。(emgは emergencyのつもり)

tarに固める処理はユーティリティで既に実装済み
https://github.com/wbrxcorp/walbrix/blob/master/wbui/src/util/__init__.py#L176

https://github.com/wbrxcorp/walbrix/blob/master/files/walbrix/init
では既にレスキューモード起動時にそのファイルが存在すればtmpfsに展開するような実装になっている。

オプションとして --export=FILE|- を指定すると、/.overlay/profile の内容を全て無圧縮 tarにして出力する。(手動バックアップ用途)

https://github.com/wbrxcorp/walbrix/blob/master/files/update/index.json#L4
https://github.com/wbrxcorp/walbrix/blob/master/wbui/src/cli2/update.py#L55

TCPでEOFまでダウンロードできたのであれば中身が壊れていることはないはずだが、万一壊れているとレスキューですら起動できなくなる恐れがあるので可能ならダウンロード直後のハッシュ値チェックを入れられるようにしたほうが良いかもしれない。

https://github.com/wbrxcorp/walbrix/blob/master/wbui/src/cli2/fbinfo.py

但し、

• /dev/fb0の調査に失敗した場合: gfx-640x480x32
• フレームバッファのIDが"EFI VGA" "VESA VGA"のいずれでもない場合: --xen-vgaオプションの指定自体を無視

とする。2番目についてはGUIインストーラから wb installがコールされた場合を想定した（GUI側にわざわざ /dev/fb0の素性を調査させないための）挙動。コマンドラインからの利用を想定すると直感に反するがやむを得ない。

https://github.com/wbrxcorp/walbrix/blob/master/files/walbrix/install.cfg#L47

$LINUX_NOMODESET_ARGSを外して video=640x480-32 を付け、KMSに画面モード設定を任せる。
問題の起こりがちなMatroxのG200も Xenの配下でなければ KMSで問題を起こすことはないし、どうしても nomodesetでないと起動出来ないマシンではレスキューを使って貰う手がある。

で、Matroxだけは特別に判定して VESA VGAと同じフローに流すことにする。

ここで
https://github.com/wbrxcorp/walbrix/blob/master/wbui/src/installer/__init__.py#L192

コマンドラインから仮想マシンのリネームをできるほか、
#39 https://github.com/wbrxcorp/walbrix/blob/master/wbui/src/domain/operate.py#L285

にて使用される。

リネーム対象の指定は仮想マシン名のほかにデバイス名も受け付けること。（別のVGにまたがってLV名がかぶってしまっているた時にはそちらで特定するしかないため）

リネーム先の名前がかぶらないよう当然チェックする。

FATファイルシステムをダーティシャットダウンすると、ディレクトリエントリからは見えないのに容量を占有し続けるファイルが残ることがある（もっとも、ブートパーティションが書き込み可能でマウントされるのはインストール時を除けばアップデートの処理を行っている時だけなので、この問題が実運用環境で起こる可能性はそれほど高くない）。回収するには dosfsck -afをかけて /FSCKnnnn.REC (nnnnは0000から始まる通し番号）を削除しなければならないが、自動で行うとしたらどのタイミングでそれをするべきか考える必要がある。

busyboxのfsckアプレットで fsck -t fat をしたところ本物の fsck.fatをexecしているだけのようなので fsck.fatが利用できる環境でないといけない。したがって initramfs内でこれをやるにはそれなりの対応が必要となる。

https://github.com/wbrxcorp/walbrix/blob/master/wbui/src/domain/operate.py#L281

Walbrix Desktopなどのバリアントを考慮した措置。

今は
https://github.com/wbrxcorp/walbrix/blob/master/wbui/src/cli2/create_install_disk.py#L161
の中で決め打ちになっているが、この関数にアップデートURLを渡せるようにした上で、呼び出し元では表題のファイルから WALBRIX_UPDATE_URL なりの変数を取り出してそれを使って呼び出すようにする。

もっとも、create_install_disk.py スクリプト単体で関係ない Linuxから起動した時などはそういうわけにもいかないので適当なデフォルトなりオプションなりを提供する。

#26 を却下した代わりに、この対応が必要。

https://github.com/wbrxcorp/walbrix/blob/master/wbui/src/cli2/install.py#L18

古いVGAチップなどはDRM/KMSに対応していないため非互換として判定されVESA VGAのフローに流されなければならない。

ただ、KMSへの対応有無をビデオカードのベンダIDとデバイスIDだけからどう判定するかが問題。

VirtualBox環境でインストール操作が行われる場合、確実に VirtualBox内の仮想マシンで実行することを意図していると考えられるため。

https://github.com/wbrxcorp/walbrix/blob/master/files/iso9660/grub.cfg#L28
https://github.com/wbrxcorp/walbrix/blob/master/files/walbrix/init

walbrix.boot=CDROM のような抽象的な指定を可能にする必要がある。

Walbrixのsquashfsイメージは現時点で400MBほどあり、アップデート処理時には旧バージョン・現在稼働中のバージョン・新バージョンの3つが最大で同時に存在する可能性があるため、現在ブートパーティションとして確保している2GBの容量は将来にわたって十分余裕のある大きさとは言えないかもしれない。

CPUとチップセットの組み合わせによるが、それがないと Linuxがハードウェアをまともに認識できないことがある。結構昔からある問題。Intel VT-dを切ると intel_iommu=offがなくても正常に起動出来る。VT-dがなくても Walbrixとしての機能には支障ないため、基本要らないという判断でよいと思われる。

（推奨ではないにもかかわらず）多くの場合 Walbrixは VirtualBox上で走らされるので、便宜を図ることにやぶさかではない。portageには virtualbox-guest-additions なる ebuildがある。

VirtualBoxを積極的に用いる層のユーザーが32bit環境を必要としているとは思えないので、本件は 64bitのみ対象にする。

https://github.com/wbrxcorp/walbrix/blob/master/wbui/src/domain/operate.py#L368

Walbrixインストール時、 /.overlay/boot/walbrix.ins というファイルがある場合はそれをRWレイヤに展開するようにする。

https://github.com/wbrxcorp/walbrix/blob/master/wbui/src/cli2/install.py#L124

CDブートの場合については考慮しない（CDにユーザー個別の情報を焼き込むことはないため）

insファイルを作成するためのスクリプトも用意する。（このスクリプトはWalbrixと関係ない環境でもpython2.7とopensslさえあればスタンドアロンで動作するように考慮すること）

create-ins --key=秘密鍵 --cert=証明書 --ssh-pubkey=authorized_keys

それぞれ /etc/openvpn/clientkey, /etc/openvpn/client.crt, /root/.ssh/authorized_keys になる(生成時 /rootと /root/.ssh のモードに注意、特に後者)。/etc/conf.d/hostnameは証明書のCNから自動で生成する。出力される insファイル名は指定のない場合証明書のCNを用いる。例: CNが ABC12345の場合は ABC12345.ins

create-insの実行uidがrootでなくてもtar作成時には中身の所有権を全てrootにする

また、create_install_diskスクリプトに --ins-file オプションを追加し、上記で生成した insファイルを取り込めるようにすること

https://:.com/wbrxcorp/walbrix/blob/master/wbui/src/cli2/create_install_disk.py#L272

32bit環境の ldconfigで生成された /etc/ld.so.cache が64bit環境に持ち越される（またはその逆）と、当然キャッシュの内容に互換性がないので各種 shared libraryのロードに失敗する。

(特に fbtermを起動しようとすると libstdc++.soがロードできないので WBUIからコンソールに抜けることができないという現象に至る)

よって毎回起動時にこれをリセットする必要がある。

rescue の意味合いを考えると、当然。
起動できないprofileになってしまった場合。

今はただWBUIが起動に失敗して init に respawning too fast って言われるはめになりユーザーからすれば何が起こっているかわからないので、動作要件をチェックしてもっとマシな挙動にする。

install.cfgでだけ対応していて、grub.cfgは決め打ちのままになっている

ここ
https://github.com/wbrxcorp/walbrix/blob/master/files/walbrix/grub.cfg#L42

これを参考に修正する
https://github.com/wbrxcorp/walbrix/blob/master/files/walbrix/install.cfg#L32

ブートパーティションはFATなので異常終了に強いとは言えず、リスクを極力減らすためrwでマウントする時間を短くする必要がある。

今はブートパーティションを rwで remountした後にアップデートのダウンロードをそこに直接行っている( https://github.com/wbrxcorp/walbrix/blob/master/wbui/src/cli2/update.py#L53 )が、一旦 /tmp などにダウンロードしてから rwでremountして短時間で書き込み処理を行うほうが良い。但し profile（システムイメージからの差分）ボリュームはデフォルトで1GBしかないため、400MBあるシステムイメージを一時的とはいえ保持するのには注意が必要かもしれない。

xenstoredが起動していない場合やxlコマンドが利用可能でない場合に get_running_domains() を呼び出した時は、単純に空の dictが返るようにする

https://github.com/wbrxcorp/walbrix/blob/master/wbui/src/cli2/list.py#L15

ownCloud 8.1.0

管理画面の最上部に「メモリキャッシュが設定されていません。パフォーマンスを向上するために、可能であれば memcache を設定してください。」という警告が出る。

関連しそうなドキュメント:
https://doc.owncloud.org/server/8.1/admin_manual/configuration_server/config_sample_php_parameters.html#memory-caching-backend-configuration

memcachedを立ちあげて memcached_serversをセットしても警告は消えない。

phpinfo()を表示させた限りではxcacheや apcuが有効になっているはずなので、このメッセージが出現する条件を調査する必要がある。

指定の仮想マシンの LVを一時マウントし、/etc/xen/config ファイルを $EDITORで編集させる機能。LVが使用中であればもちろんエラーとなる。

crontab -e のように、編集後に構文チェックが行われるとベスト (Pythonインタプリタに読ませてみる＆memory=だけは必須にする？)

実際には /etc/xen/configを直接編集させるのではなく、一時ファイルを編集させて構文チェック後に上書きコピーする形となる。

/etc/xen/configの読み出しと書き込みはそれぞれ単独でWBUIから呼べるように実装しておくこと
#39 https://github.com/wbrxcorp/walbrix/blob/master/wbui/src/domain/operate.py#L285

wb create -c /dev/VG/LV

のように論理ボリュームを直接指定して起動。論理ボリューム内には /etc/xen/config が存在する前提。

mount -o ro /dev/VG/LV /TMPDIR
cp /TMPDIR/etc/xen/config TMPFILE
# /TMPDIR以下を色々見て使用するpvgrubを選んだりする
umount /TMPDIR
xl create [-c] TMPFILE 'kernel="/usr/lib/xen/boot/pv-grub2-x86_32.gz"'
rm TMPFILE

disk= と vif= と uuid= は configファイルに記述がない場合のみ与える。（カスタマイズされている可能性があるため）

全体において /etc/xen以下を見て仮想マシン一覧を得ている箇所をなくす

lv名==仮想マシン名に決め打ち

lvs @wbvm @autostart
でリストアップされるものが自動起動の対象となる。/etc/init.d/xendomainsにはそういうパッチを当てる。

WBUIで仮想マシンの一覧を得るには lvs @wbvm -o vg_name,lv_name,lv_path,lv_tags したうえで対象lvをblkid

Windowsなど、LVをパーティションでなくディスクイメージとして使用するドメインについては対象外(WBUIにも表示しないようにし、裏でこっそり運用する)

現在はアップデートの際
/.overlay/boot/walbrix -> /.overlay/boot/walbrix.old
のようにsquashfsファイルをリネームすることで現在稼働中のシステムに影響がないようにしているが、複数回アップデート操作をすると結局 walbrix.oldも上書きされてしまうので対策したほうが良い。

例えば

• walbrix.cur が存在しない場合のみ walbrix -> walbrix.cur にリネームする
• /init にて、walbrix.curがある場合は walbrix.old にリネームする

のようにする。

https://github.com/wbrxcorp/walbrix/blob/master/wbui/src/cli2/update.py
https://github.com/wbrxcorp/walbrix/blob/master/files/walbrix/init

config.php の trusted_domainに書いてあるホスト名に対するHTTPアクセス以外弾かれてしまう

今は occ コマンドをシェルから呼び出すのも難しい状態なので、occコマンドのラッパと、ownCloudのアーカイブを展開して occ upgradeを呼び出すスクリプトを開発する

• 2TBを越える容量を持つ準仮想マシンを grubで起動するため
• 起動時にloopbackからカーネルとinitramfsをロードできるようにするため
  • 仮想マシンイメージの配布形式として squashfsを使う構想

これ
https://github.com/ukitiyan/zipstream_ja

を使うと良いらしいので、標準で仮想アプライアンスに収録するか検討する

VESA VGAモードへの切り替えは grubの方が得意なので、uvesafbはもう要らないと思われる。
（もともと、Xen dom0では v86d/uvesafbは機能しないためインストーラを動かすためだけに採用されていた）

現在、グラフィックスモードへの移行は KMS任せなので、LinuxカーネルによるDRMサポートのないグラフィックチップでは起動時にグラフィックモードへ移行されず WBUIを起動することができない。

詳しく言うと、intel, nvidia, amd, そして qemuの仮想グラフィックスであればグラフィックモードに移行できるが VirtualBoxではできない。すなわち現在 VirtualBoxでは Walbrix 4.1を利用できない。

（別の問題ではあるがKMSでブラックアウト＋ハングしてしまうようなバグ入りのハードウェアも世の中には多く、そのようなハードウェアではカーネルパラメータに nomodesetを付けたうえで VESA VGAを用いるよう対処してやる必要がある）

KMSに頼らずグラフィックモードへ移行するためには、Xenに vga= パラメータを渡してやる必要があるのだが、このパラメータを渡す時は必ずそのハードウェアが対応しているモードを指定してやらなければならない（Xenは適当に一番近い解像度やビット深度を自動的に選んでくれはしない）。多くのシステムでは vga=gfx-640x480-32 でグラフィックモードに移行できるが、そのモードに対応していないシステムでは起動時に止まってしまう。

従ってこの部分は決め打ちには出来ず（またブートローダー作動時という制約の多い状況なため何らかの自動判別を行うこともまず不可能）、ユーザーが判断して介入する余地を与える必要がある。

旧バージョンの Walbrixではインストーラが適当に自動判定していたが、品質の悪いBIOSでは必ずしも適切な判定ができなかったためいずれにせよ手動での対応を100%不要にすることはできなかった。

wb vpn VMNAME set HOSTNAME ID PASSWORD
wb vpn VMNAME get
wb vpn VMNAME delete

https://github.com/wbrxcorp/walbrix/blob/master/wbui/src/domain/operate.py#L412

LVMのコマンドで自分でやれば出来るが、Walbrixとしてこの機能を提供する価値はありそう

参考:
http://how-to.linuxcareer.com/create-and-restore-manual-logical-volume-snapshots#h4-logical-volume-snapshot

wb snapshot vmname [ssname] -s|--size
wb snapshot vmname [ssname] --delete [--yes]
wb snapshot vmname [ssname] --rollback [--yes]
wb snapshot vmname [ssname] --rollback --delete [--yes]

• ロールバックはLVが使用中の場合失敗する（自分でやらなくてもコマンドが自動で失敗してくれる？）
• スナップショットサイズは省略するとLVサイズの50% 但し1GBを下限、VGの残り容量を上限とする
• スナップショット作成時、ssnameを省略すると適当に付ける
• ロールバック・削除時は --yesオプションが指定されていない限り確認のプロンプトを表示
• ロールバック・削除時は、ssnameを省略するとスナップショットがひとつであればそれを選択、複数の場合は選択させるかエラー

コマンドラインオプション --boot-partition と --force を追加する。
https://github.com/wbrxcorp/walbrix/blob/master/wbui/src/cli2/update.py#L55

--forceを付けると既存のsquashfsイメージをチェックせずに強制的に書き込みを行う

ブートパーティション内の事故でインストール済みのインスタンスが起動できなくなった際にインストールディスクから起動してレスキューするシチュエーションを想定。

なお、ECS Livaはテキストモードを持っていないので EFI Xen で起動

レスキューは問題なく起動できる。

BIOSディスクに対してgrub2-installを実行すると unicode.pf2 もコピーされるが、EFI専用でのインストレーションだと grub2-installを実行しないのでフォントがコピーされない。

https://github.com/wbrxcorp/walbrix/blob/master/wbui/src/cli2/create_install_disk.py#L221

しかし
https://github.com/wbrxcorp/walbrix/blob/master/files/walbrix/install.cfg#L12
ではそこにフォントファイルがあることが期待されているので、EFIの場合でもフォントだけはインストールする必要がある。（loopbackからの読み込みはUEFI-CDブートの場合なぜか失敗するのでここでは出来ない）

もっとも、create_install_diskを2TB以上やビッグセクタなどの非BIOSディスクに適用するケースは稀であるし、フォントがロードできなくてもメニューの枠線表示がおかしくなるだけなのでこの問題はさほど重要ではない。

これらの値は秘匿するものなので本当は固有にしなければならない。
が、ownCloudの初期セットアッププログラムが一度これらの値を決定するとそれを後で変更する手段がない。ユーザーに初期セットアップから行わせると脱落者が必ず出る。

ローカルの差分だけバックアップする方が効率が良い
https://github.com/wbrxcorp/walbrix/blob/master/files/walbrix/backup#L32

現在はただ mountコマンドの失敗によるエラーが例外として投げられるだけだが、これだと何が起こったのかユーザーにはわかりにくい。

https://github.com/wbrxcorp/walbrix/blob/master/wbui/src/cli2/create.py#L96

それ用の Exceptionを cli2.create 内に作って投げるようにすれば WBUIからでもハンドルできそう

https://github.com/wbrxcorp/walbrix/blob/master/wbui/src/installer/__init__.py#L189
https://github.com/wbrxcorp/walbrix/blob/master/wbui/src/installer/install.py#L53

万一、forkしたプロセスが例外も出さずに異常終了した場合、プロセスは終了しているにもかかわらずキューにはメッセージがないので無限にブロックしてしまう。これらのケースでは get_nowait() にするべき。（キューに何らかのメッセージをputするはずのプロセスが終了しているのに get_nowait()で Empty例外が出るなら左記のような異常終了ケースが考えられるのでそれなりのエラー処理をする）

owncloud/files_texteditor#46
のパッチをまだ取り込んでいないので後で取り込む

Xenのコンフィグファイルに頼らずに仮想マシンを起動できるようにしたい。

当該ビデオチップにおいては、Xen環境でKSMが発動すると画面がブラックアウトするため。(非Xenのネイティブ Linuxでは発生しない)

主にHP社のサーバがこのチップを採用している。

lspciの結果
01:00.1 VGA compatible controller: Matrox Electronics Systems Ltd. MGA G200EH

確認したマザーボードは Gigabyte H97-D3H

Loading kernel...
error: failure reading sector 0x16a90 from 'cd0'.
Loading initramfs...
unaligned pointer 0x25
Aborted. Press any key to exit.

関係ありそうなポスト
http://savannah.gnu.org/bugs/?37067

sys-block/thin-provisioning-tools-0.3.2-r1 にて。

これと関係あるかも
jthornber/thin-provisioning-tools#18

0.4.1 ではビルドが通る模様

https://github.com/wbrxcorp/walbrix/blob/master/wbui/src/domain/operate.py#L331

cli2.editモジュールを使用してセットするか、wb duplicate ( #48 )のパラメータで指定できるようにするか、そもそも入力できないようにする