2018年12月アーカイブ

ユビキタスってことば、すーっかり聞かなくなりましたが、「いつでもどこでも」みたいな意味です。ある人は、八百万(やおよろず)コンピューティングって言ってて、凄い納得した記憶が

で、ユビキタスエロゲって？ってことなわけですが、いつでもどこでもお気楽にエロゲをプレイするには？というお話

ノートパソコンでエロゲするんでしょ？って思うでしょ？まぁ、そうなんですが、それだけじゃないんです。何が問題か？普段はデスクトップなり大型ノートなりの据え置き機でエロゲをプレイしているという前提で考えてみます。

まず、何が問題なのか、課題を明確にしましょう。

• Windowsアプリケーションなので、同じエロゲを別マシンで動かすには逐次インストールしないといけない
• インストール時のコピーサイズが大きいのでインストールに時間がかかる
• セーブデータの保存フォルダを変更できないので、セーブデータの管理ができない

エロゲとエロゲ以外のWindowsアプリケーションの動作環境の違いを考えてみましょう。

Office のような Windows アプリケーションの場合、Officeだ、Photoshopだのアプリケーションを一回インストールすれば、あとはユーザが作ったデータファイルのが増えるだけで、アプリケーションを次々インストールすることは少ないでしょう。ところがエロゲの場合、その作品をコンプリートしたら新たなアプリケーションとして次の作品をインストールする必要があります。

しかも、それぞれの作品がOP/EDの動画やキャラクターボイスのような大きいデータを抱えています。

さらに、エロゲには音楽とキャラクターボイスが重要、すなわちオーディオ機能が重要な役割を果たします。Officeなどのビジネスアプリケーションではオーディオのことはほとんど何も考えてませんから、あの手のソフトと同じような考え方はできません。

あと、なにげに重要なのが光学ドライブ。使うのはインストール時だけですが、プロテクトがあるので、これもビジネスアプリケーションとは考え方が変わります。

この話をすると、「え？VDIにすりゃいいんじゃないの？？」と言われるんですが、VDIはオーディオも動画もない、ファイルサーバさえあればマシン一台のストレージなんて128GBもあれば十分でしょ？っていうビジネスアプリケーションのことしか考えてない代物にしか通用しないことをご理解いただけるかと。

というわけで、どんなソリューションがあるかなぁと試行錯誤した結果をまとめておきます。

セーブデータのみをクラウドストレージで同期する

パソコンごとに逐次インストールしないといけない問題はあきらめます。デスクトップ機、ノート機各々にエロゲをインストールして、セーブデータだけを共通化することで、どのマシンを使っても、シナリオの続きをできるようにすることを考える方法です。

準備する必要があるのは

• クラウドストレージの仕組み (ownCloudとかDropBoxとか)
• オンプレのクラウドストレージ(ownCloud)を使う場合はそのサーバ
• 各作品のセーブデータ保存場所の情報

セーブデータの保存場所にはパターンがあって、作品ごとに異なります。候補となるフォルダをリストアップするので、作品ごとに探してください。

1. C:\Program Files\作品名\Data
2. C:\Users\ユーザ名\AppData\Local\VirtualStore\Program Files\作品名
3. C:\作品名\Data
4. C:\User\ユーザ名\AppData\Roamin\作品名
5. C:\User\ユーザ名\Documents\作品名
6. C:\User\ユーザ名\Saved Games

WinXP 時代以前の作品はほとんどが 1. です。ところが、WinVistaから C:\Program Files 以下への書き込みがシステムで制限されるようになりました。WinVista以降のマシンに、WinXP世代の作品をインストールすると、2. の場所にセーブデータが保存されます。

仮想化プラットホームにエロゲマシンを構築する

いわゆるVDI環境です

別に仮想化が必須なわけではありません。デスクトップのエロゲマシンを常時起動できるのであれば、それを使っても同様の環境が実現できます。

準備する必要があるのは

• 常時起動しているエロゲ環境 (仮想化でも物理でもよい)
• 画面転送プロトコルを実現できる仕組み

注意しないといけないのが、画面転送プロトコル。「え？リモートデスクトップでしょ？」と思うあなた。それで十分かどうか、確認してみてください。

リモートデスクトップはMS社製です。ヤツらはビジネスのことしか考えてません。ビジネスにはオーディオや動画はあまり重要じゃないのです。なので、リモートデスクトップではオーディオや動画再生はうまくいかない場合があります。コマ落ちしたり、音飛びしたり。

サーバやクライアント、ネットワークに十分な余裕があれば、リモートデスクトップでも大丈夫です。あと、リモートデスクトップはサーバ側がPro Edition以上でないと使えません。Win10時代になって、Pro Edtion 搭載マシンを買いにくくなってるので、これも難点です。

というわけで、画面転送プロトコルに別のものも検討しておきます。「動画をリモートで再生すること」を目的と唄ったフリーソフトです。

• brynhildr
• Mirror-DTC

昔からある、VNCは音声転送がそもそもできませんので、この要件には使えません。

ホスト型仮想環境にエロゲマシンを構築する

いまのところ、本命はこれ

実際の作品は各マシンのリソースを使って動くのですが、仮想マシンのイメージディスクをファイルサーバに置くことでインストールを1回で済ませることができます。モバイルマシンでプレイしたい場合は、イメージファイルをコピーすれば持ち出せます。ファイルは大きいですが、インストール処理は要らないので、マシン間移動が比較的楽なのがメリット。

ただし、この方法、大きな弱点があります。プロテクトに狙い撃ちされる場合があります。SecuROM は VMware を検知してインストーラに蹴られます。ういんどみるの作品はこの問題でインストールできません。

あと、ネットワークの影響も要確認です。VDI方式の場合は遅延が効きますが、こっちの方法だと帯域が効きます。

準備する必要があるのは

• 仮想化ソフトウェア (VMware Player や VirtualBOX)
• ファイルサーバやNAS(イメージをローカルにコピーするのであれば不要)

例によって、Hyper-Vは？というと、例のごとくヤツはMS品なのでビジネスのことしか考えてません。オーディオ機能が提供されていないので話になりません。

まとめ

これがベストだ！というのがないのが実情ですね

Windowsの仕様というか、歴代Windowsの仕様変更と、プロテクト対応がメンドクサイです。

ownCloud、便利です

Dropbox みたいな、クラウドストレージなんですが、オンプレで動かせる。つまり、サービス提供側が、やーめた（てへっ）とか言う心配がない。ストレージ容量も自分次第。WindowsもAndroidもいける。

完璧！！・・・と思ってたんですが。

Windows版のクライアントソフト、けっこー頻繁にアップデートが出ます。んで、クライアントが自身で勝手にアップデートします。それ自体はいいんですが・・・・・そのアップデートを止める設定がない。クライアントバージョンを塩漬けして使いたい。って思うと、勝手に走り出すインストーラを、UACに引っ掛けて、そこで止めるしかないのですよ。

んでまって、このクライアント、Windows版のVer.2.4.2あたりから旧バージョンのサーバへの接続を強制的に切るということを始めやがりました。Android版も、2018年12月初頭付近に出たバージョンから旧バージョンのサーバ、Ver.8系、Ver.9系への接続を切るということを始めやがりました。

いや、正しいとは思うですよ？その行為。旧Verのサーバのままにしておくのは悪いことですよ。だけどね、サーバ、クライアント含めて塩漬けする。って方針を潰すってどーなんかね？

Win10 でユーザの意向を無視して強制アップデートするっていうのを許す風潮、すげぇ嫌

とまぁ、ボヤいててもしょーがないので、ownCloudサーバのバージョンアップをして見ます。

occ コマンドでバージョンアップするんだよーっていうのは、よく出てくる話なんですが、いくつか補完情報をまとめておきます。

ポイントは2つ

1. pecl-intl というツールが必要
2. アップグレードパスに注意

まず pecl-intl ですが、初期インストール時に www/owncloud をインストールしただけでは依存性インストールされません。

なので、devel/pecl-intl がインストールされてるかを確認して入ってなければインストールしましょう。

次にアップグレードパス。

Ver.9.1 からは直接 Ver.10.0 にアップグレードできます。

Ver.8.2 からは Ver.9.0 を経由して Ver.10.0 にアップグレードします。

注意しないといけないのが、Ver.8.2 からは Ver.9.1 へアップグレードできないので、Ver.9.0 を経由するということ。

旧バージョンのインストールファイルは、公式サイトから取ってきましょう。

実際のコマンドラインはこんな感じ

# cd /usr/local/www/owncloud
# php ./occ maintenance:mode --on
# /usr/local/etc/rc.d/apache24 stop
# cd /usr/local/www
# mv owncloud owncloud.old
# bunzip2 -c owncloud-10.0.10.tar.bz2 | tar xvf -
# chown -R www:www owncloud
# mv owncloud.old/data owncloud/
# cp owncloud.old/config/config.php ownclud/config
# chown www owncloud/config/config.php
# cd /usr/local/www/owncloud
# php ./occ upgrade
# php ./occ maintenance:mode --off
# /usr/local/etc/rc.d/apache24 start

あとはクライアントからの接続テストをしておしまい

あ、書くの忘れてた。FreeBSD でのお話ですよん

そーいや、サーバもVer.10から、FreeBSDは動作保障しないとか言い出してたような。だったら、旧バージョンを使えなくする処置をするなよな・・・・・

エアコン設置完了

よーやくエアコン設置が終わりました。当初はエアコン設置も自前で行けるんでね？って思ってたんですが、真空ポンプが必要ってことで、こりゃームリ！ってことで、父親の友人の電気屋さんに工事依頼したんですが・・・・・この作業待ちで3週間くらい止まってました。

ラック設置

さーて、いよいよ本格的に機材の搬入をしましょう。まずはラック。

すでにUPSとか、サーバ機とか置いちゃってますが、ラックを起きます。

自宅ラックの人たちの間でも、「もうメタルラックは捨てて、19インチラックを入れるべき」っていう意見があるのですが、うちはメタルラックです。理由はラックマウント機器が少ないから。ストレージがQNAPのタワーというかボックス型NAS、サーバもほとんどがタワー機なので、19インチラックを入れたとしても、メタルラックなりが必要なんですね。

じゃあってことで、全部メタルラックです。

ちなみに、メタルラックシリーズといえば、奥行き 46cm しかなかったんですが、新たに奥行き 61cm シリーズが追加されました。19インチラックに収めるような機材の場合、奥行き 46cm だとはみ出しが多くて安定性に問題ありなんですが、奥行き 61cm の棚にすると安定して置けます。

というわけで、サーバ機器用として 610 × 1200 のラックを一台、ストレージ機器用として 460 × 1200 のラックを1台、L字型に置くことにしました。

全景を見渡すとこんな感じ

もーちょっと広い建物にしたかったなぁーと思わないでもないですが、まぁそう言い出すと際限なく広くなりそうなので、これくらいで。

電源配線

電源関係を配置していきます。

特に電源が2系統以上あったりする場合は、ラベリングが非常に重要。これは絶対にやらないとダメです。

「どうせ一人で管理するんだし、線なんてたどればいいんだよ」って思ってた過去の私、そこに正座。「え？この線ってどっち？」とか言って引っ張ったらコンセント抜けてぎゃー！！って叫ぶことになります。

ケーブルは両端にラベリングしましょう。

ケーブルにラベリングするときは、ラベル付きのタイラップが便利です。電気工事系の資材を扱ってる店の、タイラップコーナーにほぼあるので、探してみてください。

UPSも設置します。重いのと、ラック設計の慣例に習って、一番下の棚に。

メタルラックにそのまま置くと、ゴム足が棚板の隙間から下に落ちるので、硬質シートを敷いておくと良いです。

イバナ物置DCにすると、天井はそんなに高くありません。190cm くらいの天井高です。そして、断熱材を固定するために、金属の梁が入ってます。

つまり、こんな取り付け方ができます。案外これが便利。ちなみに、使ってるACタップはたのめーるオリジナルブランドのタップ。3Pコンセントでロック機能付きのACタップってけっこー高いんですが、たのめーるのこれ、安いんですよね。

機材搬入

ネットワーク機材を搬入して配線します。

ポート数、多すぎだろ？って気もしますが、気にしなーい

ストレージ装置。QNAPを全部で5台入れる予定ですが、3台は旧サーバ室で稼働中なので、まずは2台を搬入。稼動状態に入れて、Storage vMotion を使いながら、残り3台も順次搬入の予定です。

サーバ機は運用終了しているマシンも含めて6台を搬入予定ですが、こっちもまだ半分しか搬入できてません。vMotion で順次仮想マシンを空にして移設予定です。

Storage vMotionをちまちまやる必要があるので、全機器搬入には1ヶ月くらいはかかるかなぁと。

運用を開始して最初の夜。データセンタ内の証明を消すと、をを！！なんかデータセンターっぽい！

商用データセンターとかで仕事終わって退館するとき、証明を消すとマシンルーム全体がLEDの光だらけになるんですね。DC作業が無事に終わったあとにこれをみると、おぉ、綺麗だ！って気になるんですよ。まぁ、作業がうまく終わらず、宿題持ち帰りになった場合は、そんな余裕もまったくないんですけどね。

インシデント

機材搬入中に、部外者の侵入をゆるしてしまいました。インシデントです。

機材搬入中はドアを開けっ放しにするので、DC運用者の皆さん、注意しましょう。

Zabbix4が出ました。ちうても、もう1,2ヶ月前ですが・・・・・

いい加減、Ver.2.0 の Zabbix もどないかせんとなぁ、と思ってたのですが、思い切ってあげてみることに。とはいえ、切り替えなんてムリだしょ？ってことで、現行のVer.2.0と、Ver.4.0を並行運用します。

まぁ、仮想環境なんで、Zabbix サーバマシンをもう一個作るのはそんなに難しい話じゃない。Zabbix Agent 側も上位互換があるので、当面は今はいってるAgentのまま行けるっしょ

ちなみに、Agent 側は、zabbix_agentd.conf に Server=server1,server2 とコンマ接続でサーバを列挙すれば、両方から監視できます。

Zabbix Server Ver.4 から Agent Ver1 から Ver.4 まで監視できます。逆にServer Ver.2.0 では、Agent Ver.4 は監視できませんでした。

さてさて、Zabbix 4 なんですが、立ち上げてみたら一個問題が。

SNMP でスイッチを監視しようとしたら、ポートごとのインターフェーストラフィックが取得できない。

「そんなOIDねーよ」って言われちゃいます。

なんで・・・？と調べてみたところ、取得してるMIB値が net.if.in[ifHCInOctets.1] になってるんですね。

MIB 値 ifHCInOctets ちうのは、インターフェースごとの In 方向オクテット数なんですが、64-bit カウンタです。

SNMPって、もともと数値は 32-bit までだったのが、数年前（もう10年くらい経つ？)から64-bit カウンタが使えるように拡張されました。

なもんで、ifHCInOctets は必ず対応してるとは限りません。一方、32-bit カウンタはifInOctets という MIB で、こっちはまぁほぼ間違いなく対応してます。

ちうわけで、Zabbix 4 に 32-bit インターフェースカウンタを読ませましょう。という話です。

要約したら、「Zabbix のテンプレート弄って追加しろ」ってだけなんですが、

[テンプレート]-[Template Module Interfaces SNMPv1]-[ディスカバリールール]-[Network Interfaces Discovery]-[アイテムのプロトタイプ] を開きます。

[Interface {#IFNAME}({#IFALIAS}): Bits received] をクローンすると早いでしょう。32-bitカウンターを追加します。

変更するのは、名前(64-bitカウンタとかぶるとダメなので)、キー、SNMP OID。

 既存の 64-bit カウンターと並べて、こんな感じの監視キーを作ってあげます。

これで無事監視できるようになりました。