妻のマシンを Windows 7 化して (グラフィックス・カードは Aero が使えず、オンボードのオーディオは存在自体が認識されず、それぞれ必要最低限クラスのグラフィックス・カードとサウンド・カードを買ったりして少々手間取った) アレコレいじっていた先日、Windows 7 RC の強制シャットダウン措置が始まる 03/01 を過ぎていることに気が付いた。そこで 「どれ、どうシャットダウンされるのか体験してみるか」 と、VirtualBox 上の仮想マシン (以下 VM) の Windows 7 RC を起動した。
以前のエントリーで Windows 7 の C:\Program Fiels フォルダーを別ドライブに移動させる方法を紹介したが、本エントリーでは以前の加筆修正をまとめて 「x64 対応半自動化版」 とし、改めて 32ビット及び 64ビット環境双方でより汎用的に使える方法を紹介する。
我が家の VMware ESXi 4.0 で構築した仮想化環境は、ネットワークの冗長化は考慮しておらず、ESXi が稼働する Dell PowerEdge 830 の NIC はオンボードの 1枚 (?) だけだった。しかし普段利用するネットワークとは完全に分離されたテスト用ネットワークが作れると何かと都合がいいので、NIC を追加することにした。

この手の PC パーツのいいところは、増設作業を密かに行えば、「また余計なモノ買って!」 と妻に非難される恐れが少ないことだ。ケースの中に納めてしまえば存在が発覚することはまずないし、仮に 1本増えた LAN ケーブルに気付かれたとしても、最初から 2本だったと言い張ればいい。
デフォルト状態の Windows 7 は、LinkStation LS-WH2.0TGL/R1 (以下 LS-WHGL) の共有フォルダーのマウントに失敗する。と言うより LinkStation にアクセスすらできず、共有フォルダーを一覧することができない状態になる。

これは Vista と旧バージョンの Samba 間でも発生していた 「LAN Manager 認証レベル」 の設定値に起因する問題で、Windows 7 でもローカル セキュリティ ポリシーで設定を変更するかレジストリを直接編集して、認証レベルを下げる必要がある。BUFFALO でも当然この問題は認識されていて、「ファイル共有セキュリティレベル変更ツール」 が公開されている (昨年 10月にリリースされた Ver.1.10 からは Windows 7 にも対応)。

このツールで今回の不具合を解消できることは検証したが、デフォルト状態の Windows Vista/7 が接続できないのは、LS-WHGL と言うより、旧バージョンの Samba に対して。Samba をファイルサーバーにしている環境でも、Samba のバージョンによっては同様の現象が発生するはずなので、前述のツールは使わず、より汎用的な方法で解決してみる。
僕はキーボードで文字入力をする際、「親指シフト」 を長年愛用している。と言っても本物の親指 Shift キーボードを使う本格派ではなく、OS レベルでキーマップを変更し、通常のキーボードで右手の親指で押しやすい位置にある [変換] キーを [Shift] キーにしているだけだが。

サーバー (特に Case sensitive な UNIX 系) をいじったり、(X)HTML や CSS を手でタイプしたりプログラミング等をしていると、大文字・小文字が混在したアルファベットや記号をタイプする機会が多くなり、必然的に [Shift] キーの使用頻度が高くなる。そこで個人的には漢字変換には [スペース] キーを使うため全く無用の [変換] キーを [Shift] キーに変更すると、通常のキーマップではほとんど使わない右手の親指で [Shift] キーを押し続けながら他の指をフル活用することができるようになって、タイピング効率が格段に上がる。
少し前に自宅の CentOS 5.4 上に構築した Samba ドメイン (+ OpenLDAP 2.3.43) の PDC を 3.3.9 → 3.4.5 にバージョンアップしたので、実機の環境を移行する予行演習として、VirtualBox 3.1.4 上の仮想マシン (以下 VM) に素の Windows 7 Ultimate をインストールし、ドメイン参加させてみた。実機に搭載するグラフィックス・カードの Aero 対応がわかっていて、他に検証が必要なハードウェアがなければ、無理にデュアル・ブート等の環境を構築する必要はない。

尚、VirtualBox で VM を作成する際は、ネットワークがデフォルトで NAT になっていることを認識しておいた方がいい。意図して NAT のままにする場合は問題ないが、デフォルトがブリッジの VMware シリーズ等に慣れていて気付かないと、ハマる可能性がある。
オープンソースの CMS ツール concrete5 (5.3.3.1.ja) で使う MySQL ユーザーのパスワードに "@" が含まれていると、インストール時に 「データベースに接続出来ません」 とエラーになる。確かに "@" はユーザー名とサーバー名の区切り記号でもあるので微妙な文字と言えるが、phpMyAdmin では、同じユーザー名とパスワードで DB にアクセスできる。
■ 変更履歴
  1. 2010-03-02: より確実・汎用的な改訂版 「x64 対応半自動化版」 を公開。
  2. 2010-03-01: ProgramFiles フォルダーのコピー方法を変更 (xcopy コマンド)。
  3. 2010-02-28: 64ビット環境でのレジストリ置換方法を追加。
  4. 2010-02-20: ProgramFiles フォルダーのシンボリック・リンク作成を追加。

Windows 7 のシステム要件によると、インストール先ディスクの空き容量は 32ビット版で 16GB 以上、64ビット版で 20GB 以上とされている。Windows 7 Ultimate (32ビット版) をクリーン・インストールした直後の C: ドライブのディスク消費量は 7GB 程度 (ページファイルを除く) だが、このシステム要件は、様々なプログラムをインストールしたり、「ドキュメント」 以下にファイルを溜め込んで行く使い方を想定してのこと。大容量化が進んだ最近の HDD なら 「1.5TB の C: ドライブ一発」 と言うこともできるので、旧型 PC にインストールする場合以外では、ディスク容量が問題になることは少なそうだ。ただし 「1.5TB 一発」 は男らしさのアピールにはいいとして、ディスク障害発生時のリスク、OS の再インストール、デフラグ時のコスト等を考えると、あまり効率的とは言えない。

一方、ディスクを適切なサイズにパーティショニングしたり別ディスクを用意するなどして、システム以外のソフトウェアを別ドライブにインストールする方法は、Windows のパフォーマンス向上、と言うより低下防止やリスク軽減策としてよく見られる。しかし各プログラムのインストール時に毎回別ドライブの任意の場所を指定していては、うっかり C: ドライブにインストールしてしまうこともあるし、プログラム本体は別ドライブにインストールできても、付属品が C: ドライブ (Program Files\Common Files 等) に入ってしまうこともある。こうした事態を防ぐには、Windows がデフォルトのインストール先として認識している、環境変数 ProgramFiles で定義されたフォルダー (以下 「ProgramFiles フォルダー」) を移動させてしまえばいい。
今頃検証。Windows Server 2008 (Standard) は、デフォルト状態で普通に Samba 3.4.5 + OpenLDAP の Samba ドメインに参加できた。さすが Vista ベース。
先日より多くの変数が利用できると言うことで Ruby ライブラリ Facter のバージョンを上げたが、我が家で稼働する 2台の仮想マシン (以下 VM) で、lsb* で始まる全ての変数が参照できていなかった。特に lsbmajdistrelease はバージョンアップの目的の一つでもあったので、使えないのは困る。

lsb* が参照できない VM は、CentOS 5.4 と Debian/GNU Linux 5.0 が各 1台ずつ。実機を含む他のマシンでは問題ないので、どうせ何かのパッケージが足りないんだろうと、他の VM と rpm -qa | sort を diff してみると、あっさり見つかった。

Find recent content on the main index or look in the archives to find all content.

Recent Comments

  • Natz: Windows Vista Ultimate (x86) において、本エントリーの手順で ProgramFiles フォルダーを移動させられることを確認。 read more
  • Natz: 「x64 対応半自動化版」 として改訂。 http://www.natzworks.com/digital/entries/2010/000263.html read more

レンタルサーバーなら使えるねっと

レンタルサーバーなら使えるねっと