他のサーバーのノードを追加しようと思い、munin.conf に追加したまでは良いのですが、なぜかサイトに表示されない事態が発生しました。 telnet で 4949 に接続可能なので、基本的な設定は間違ってなさそうです。 ログ（/var/log/munin/munin-update.log）を確認してみると、
[WARNING] Config node xxxx listed no services for xxxx, (advertised as localhost.localdomain). Please see http://munin-monitoring.org/wiki/FAQ_no_graphs for further information.
というような警告が出ています。 どうやら、ホスト名が localhost.localdomain のままだったのが原因らしいです。 munin.conf とリモートサーバーの munin-node.conf のホスト名を一致させておく必要があるようです。
CentOS7 に EPEL リポジトリから munin を設定したところ、グラフの曜日部分が文字化けしているようでした。 このサイトの作成は、cron で定期実行されているので、そこから辿ったシェルスクリプトを修正して対応しました。
下記のコードを2行目くらいに記述するだけで OK です。
export LANG=C
サイトのドメイン移転で使われる「301リダイレクト」を設定してみて、あれって思ったことがあった今日この頃。 実は、このサイト自体のドメインを landhere.info から landhere.jp に移転することにして、mod_rewrite でリダイレクトを設定したんです。
いろんなサイトに紹介されている下記のような設定を記述してみました。 ちなみに、ドメイン移転だけなので .htaccess は使わずに、httpd.conf の VirtualHost に書いてみました。
RewriteEngine on RewriteRule (.*) http://landhere.jp/$1 [R=301,L]
実際にブラウザで確認してみると、「http://landhere.info/blog/」が「http://landhere.jp//blog/」にリダイレクトされるのを確認。 でも、よく見ると「/」がひとつ余計である。 前に設定したときは、こんなことは無かったと思うけど、最新バージョンでは挙動が異なるのか何なのか、とりあえず。
RewriteEngine on RewriteRule (.*) http://landhere.jp$1 [R=301,L]
このように変更して解決しました。 まあ、少し嵌ったんですが。
設定を変更した後、再びブラウザでテストしても同じリダイレクト先に飛ばされます。 正規表現を弄ったりしても、何しても結果は変わらず、しばらく悩んだ末。 大胆にリダイレクト先ドメイン名を www.yahoo.co.jp にしてみよう、というのを試してみてやっと分かった。 ブラウザがひと度、301リダイレクトを受け取ってしまうとキャッシュしてしまう、というのが真相らしい。 と言う訳で、キャッシュクリアを実行して正しいリダイレクトが行われるのを確認しました。 くだらない事で消費した時間を返して欲しいです。
USB メモリにセットアップすれば、サーバーをディスクレスにでき、環境のバックアップも簡単に行えます。
ハイパーバイザの容量が 150MB 程度しかないため、数百円で特売されているような USB メモリで十分です。
ただ、USB メモリが飛び出していると破損させてしまう心配があるので、RUF3-PS8G-BK のような出っ張らないタイプ
セットアップ対象の USB メモリ自身に、インストーラを作成できるため、光学メディアなどが無くても大丈夫です。 用意した ISO イメージは UNetbootin というツールで USB メモリに書き込みます。 ただ、今のバージョンではセットアップ途中でのドライバ追加はできないので、必要であれば ESXi-Customizer というツールで ISO に書き込んでおく必要があります。 基本的には、ネットワークインターフェイス（Intel 製が無難）に気を付けて、予め CPU の VT 関係の設定を UFIF（BIOS）で有効にしておけば良いです。
セットアップが終わった時点で、USB メモリをバックアップしておくと、トラブルのとき安心です。 バックアップには DD というディスクイメージをコピーできるツールを使います。 Windows 用には DD for Windows というツールがありますが、これで作った複製では起動しませんでした（BANK6: not a VMware boot bank, No hypervisor found となってしまう）。 動いた報告もありますが、無難に Linux の DD コマンドを使いましょう。 手元に適当な Linux が無い場合は、Ubuntu などの LiveCD で起動すれば良いでしょう。 具体的な手順は下記の通りです。
USB メモリは、読み込みは割と速くても書き込みが遅いので、気長に待ちましょう。
後にアクセス速度、安定性、耐久性などの面から、小容量の SSD のほうが適していると考えを改めました。 価格的にも 32GB 程度なら、Transcend や Sandisk 製でも 4,000 円程度で買えます。 少し大容量にして、高速なデータストアと共存させても良いですが、この値段なら分けておくのが良いと思います。
USB メモリーを Linux の USB ブートに使ったりすると、すべての容量が見えなくなることがあります。 例えば、8GB の容量があるはずが、Windows 上からは 512MB しか見えなくなり、フォーマットしても容量が回復したりしません。 このとき、PC（マイコンピュータ）を右クリックして〈コンピュータの管理＞ディスクの管理〉を開くと、パーテーションが2つに分かれていたりするかも知れません。 恐らく片方のパーテーションは、削除のメニューがグレーアウトされていて選択することができない状態では無いでしょうか。
要するに、削除不能な特殊なパーテーションが出来てしまっていて、そこを避けた領域しか利用できなくなってるのです。 削除不能なパーテーションも、Windows では見れないフォーマットになっている関係で、総容量があたかも 512MB しか無いというような表示になるのです。 強制的にパーテーションを削除してあげれば良いのですが Windows の GUI からは無理なようで、CUI コマンドの diskpart を使うか、サードパーティ製のツールを使って削除します。
基本的にはハードディスクの OEM パーテーションと同じやり方で削除しますので、「OEM パーテーションの削除方法」で書いた手順で OK です。 もちろん、削除するドライブ、パーテーションは間違わないよう、くれぐれも注意してください。 ただ、このままでは PC（マイコンピュータ）のドライブアイコンからは、容量が不明と表示されフォーマットすることができません。 先ほどのディスクの管理をもう一度開き、「未割り当て」になっているドライブのメニューから「新しいシンプルボリューム」を選択して、パーテーションの作成とフォーマットを行うことで使えるようになります。
環境を組み替えて、キャプチャーボードとPC自体も変えたところ、番組取得がうまくできないようになってしまい苦労しました。 基本的な設定は新しい環境に合わせて変更し、チャンネル情報も設定し直したのですが、番組情報を開始するとすぐに終了してしまいます。 番組情報取得スケジュールも、〈インテリジェント＞番組情報取得〉も最初のチャンネルが終わると、そこで終了してしまうような感じです。
結果的には、新しくTvRock作業フォルダを作り直したらOKになりました。 この作業フォルダには、設定ファイルや自動予約設定などが入っているので、新しく作り直すとそれらもリセットされてしまいます。 DTune.bat を再構築したり、自動予約も入力し直すのは大変なので色々と当たりを付けていたら、なんとか古いフォルダからコピーしてくることに成功しました。
ボール紙のような厚紙にインクジェットプリンタで印刷したくて、ネットで調べてみたのですが確証が得られず、いろいろと試行錯誤をしました。 印刷できるかどうかは、厚さの問題と、インクの定着具合の二点をクリアーする必要があります。 このうち、厚さについて Canon製プリンタは個別の仕様に記載が無く、Q&Aの中で「インクジェットプリンタで使用できる普通紙の坪量」に記載があるのみです。 ただし、坪量（重さ）の単位なので実際何mm程度までなのかはっきりしません。 この点、エプソン製プリンタでは仕様に厚さ（mm）での記載があり、EP-978A3 などは 0.6mm のかなり厚めの用紙も大丈夫なようです。 なので、このためにプリンタを用意できるのなら、エプソン製プリンタで仕様を確認して購入するのが良いと思います。
残念ながら、私の所有しているのは Canon iX6530 というプリンタですのでやってみないと分かりません。 背面の手差し給紙しか無い機種なので、割と厚めのボール紙でもいけるだろうとは思いましたが、結果 350g/m2 ぐらいまでが限界のようです。 それより厚い 400g/m2 は印刷可能ではあるものの、スタックして給紙させると稀に紙詰まりになることがありました（１枚ずつ手作業で給紙させれば詰まらない）。 従って複数枚の厚さから逆算すると、約 0.4～0.5mm 程度までが、このプリンタで印刷可能な限界値だと思われます。
インクの定着については、残念ながらインクジェット用のボール紙は無く、特に光沢のあるタイプはまったく向きません。 どのボール紙でもインクが乾くのが遅く、乾いた後でも擦ればインクが伸びて汚れてしまいますが、光沢の無いタイプは割とマシだと思います。 いずれにしても、定着や発色の悪さ、退色の心配がありますので、フィキサチフなどを塗布した方が良いかも知れません。
それと給紙位置ですが、紙が厚くなっていくと少しずつズレてくるようです。 試したプリンタでは、3mm 程度印刷開始位置が早くなりました。 同じ紙であれば一定のようでしたので、元のデータを微調整して対応しました。
前知識なしで鑑賞しましたが、近年にしては珍しい「2001年宇宙の旅」のようなハードSF作品でした。 この手の作品が好きなので2時間半という長編作品でも、最後までどっぷりその世界観に浸ることができました。 地球の終焉を救うミッションに旅立つ父親と、それを理解できずにすれ違い空いた娘との溝、それを天文学的な距離と相対論的な時間の遅れが容赦なく引き裂いていきます。 果たして、地球の危機を救うことができるのか、娘との再会の約束は守れるのか、超大な宇宙のスケールの中で描かれる人間ドラマの結末は...。
後で調べた情報によると、理論物理学者の協力でブラックホール等の映像は、物理計算によって作られているそうです。 本編中でもブラックホールや宇宙空間での無音表現などの天文知識、ワームホールといった実際に研究されている理論などを基に丁寧に作られているなと感じられました。 そういった光る点がある一方、残念な部分も少なからずあり、一流のハードSFかというと自分の中では多少落ちるかなという印象です。 他のレビューでは絶賛の声が多いので、ここではあえて変だなと思った点を書いていきます。 とはいっても、SF映画として大変面白かったので、些細な事だと思います。
これはきちんと設定して欲しかったと思います。 物語上では、食糧危機の発生としか分からない地球存亡の危機ですが、どのような理由で発生してどういう状況に置かれているのかが語られていません。 また、どうしてそれを救うミッションへ父親が参加しなければならないのかも適当にされています。 正直に言うと、地下組織化したNASAに潜入して、あのロボットが出てきた時点で「あ～あ、B級SFかよ」って思ったくらいです。 ご都合主義的なチープなSFが展開されるのかと思って冒頭部分を観ていたので、見終わってから損したなと思いました。 ここら辺が丁寧に描かれていれば、最初から作品の世界に引き込まれていったのに、とても残念です。
地球からの打ち上げは、多段式ロケットを使って軌道上の宇宙船まで向かいます。 しかし、移住先の惑星からは着陸船だけで軌道上の宇宙船まで上昇できてしまいます。 大気も無く重力も1/6の月とは違い、訪れた惑星は大気もあり1Gに近いように見えますので、そうであれば多段式ロケットの推力が必要なはずです。 もし、あの着陸船だけでそれができるのだったら、なぜ地球から離脱するときも使わないのでしょうか？
まあ、ワームホール自体が理論的予測に過ぎないので、どう描いてもいい対象ではあるのですが、もう少しうまく描いて欲しかった。 私だったら太陽系外か外縁部に置いて、土星はスイングバイの中継点として使いますね。 というか、SF作品で他の惑星に行くための軌道をまともに描いたものが皆無です。 たいてい直線的に向かっているように描かれていますが、本来であればスイングバイなどを使って軌道旋回速度を増すことで外惑星に向かうように描かなければ変です。
クーパーのミッションの前に、ワームホールを使った人類移住先を探す複数のミッションがあったという設定なのですが、クーパーらは地球の科学技術に毛が生えた程度の技術で恒星系を渡り歩いているように見えます。 いったん土星に戻って、ワームホールを使うような描写も見られないから、向こうで別の恒星系に移動するのに地球のテクノロジーしか無い訳です。 もし、恒星間航行が可能なテクノロジーがあるのならワームホールは要らないことになります。 ブラックホールを軌道旋回する複数の恒星系があるとか、恒星サイズのブラックホールとの連星系の中の惑星だったとか、理解しようとしましたが無理でした。
あの津波はどういう理由で発生したのでしょうか？ あまりにも唐突過ぎて説明も何もなく、科学考証をウリにしているなら無くてよいシーンでした。 百歩譲って巨大津波があったとしても、あれだけの高さの津波が押し寄せてくるのであれば、強力な引き波が発生するはずです。 降り立った水深20cmしかない大海原も違和感ありまくりですが、そんな水深しか無いなら海底が露出するほどの表現が無ければ変です。
物語上ブラックホールの必要性がありません。 そもそも移住可能な惑星を探すのであれば、ブラックホールのような未知の恒星系は避けるはずです。 ワームホールを維持するのにブラックホールが必要で、そこしか行けないというような必然性が必要でした。 ただ、物理計算によるブラックホールのイメージを見せたいだけだったのでしょう。
それと、ブラックホールを直接軌道旋回する複数の惑星が探査対象だったのでしょうか？ ブラックホールの影響があるのは最初の水の惑星だけ、というような表現だったと思いますし、そうであればどの惑星もブラックホールの影響下にあるはずなので辻褄が合いません。 ここら辺の世界観が想像できないのが最も残念な点であり、タイトルにインターステラーと付けるくらいですから、丁寧に描いて欲しかったです。
最初の惑星はブラックホールの影響下にあり、時間の流れが遅くなるということです。 おかしいのは、その惑星の軌道上の宇宙船と着陸船の間でそれが顕著に表れるということです。 どちらもブラックホールの影響下にあるはずなので、時間の遅れはその惑星の重力による影響しか差が無いはずです。 どうせ描くのだったら、終盤のブラックホールを使った重力ターンのところで、この軌道を取ると時間のずれが何万年にもなり今生の別れになる、みたいなスケールでお願いしたかったです。
現在の地球人を移民させるプランA、遺伝情報を使って文明再生をさせるプランB、プランAは重力理論の解決が絡んでたような話だったと思うが忘れてしまった。 探査前にはプランAとBが計画され、元々プランBしか実現性が無いと分かっており、プランAは重力理論の解が不可能だと分かってて他の人類に希望を持たせるだけに計画された、というような内容だったと思います。 後に高次元空間から届いたブラックホールの特異点の観測データを使って、重力理論の別解が分かりプランAが実行可能だと判明した、と無理やり理解しましたがどうでしょう。
あと、最後のシーンに出てくるスペースコロニーは、あれ何なんでしょうね。 移民船には見えなくて、コロニーで解決するんだったら、重力理論の下りもいらないように思うし、移民計画も必要無さそうに思うのです。 それに、クーパーにアメリアの元に行くように言うということは、あれは移民船で無いと言うことだと思います。 うーん。 整理すると、プランAは重力理論の解決が障害だったけど、それを解決しときながらコロニーを建設して太陽系に留まることにした、クーパーはアメリアと合流してプランBを実行するようにした、というのが結末という理解で良いのでしょうか。 ちょっとすっきりしませんね。
基本的な主軸は、父と娘の絆の物語であるのは良いのですが、そうであれば最後にアメリアの元へという部分は要らないと思います。 そもそもアメリアとクーパー(父)がロマンスがあったのか無かったのかも分からないくらい、印象に残った絡みがありませんでした。 もし描くのなら、父と娘が相対論的時間に引き裂かれるのに対し、アメリアとは天文学的な距離で引き裂かれる、とかにしたら面白かったでしょう。 まあ、マーフと再会したところでジ・エンドというのが綺麗だったと思います。
キャラクターとしては魅力あると思いますが、ターズやケースといったロボットがB級SFっぽさを出しています。 ゴールドライタンのような箱、中に人が入ってるような動き、不器用で実用性が無さそうな腕、チープなディスプレイ、どうしてこうなったんでしょう。 AI的なコンピュータは出てきてもいいですが、動かなくていいと思います。
どういう理由でワームホールが出来たのか、まったく説明が無かったと思います。 すべての設定を説明しなくても良いとは思いますが、物語の根幹部分については何らかの説明は付けて欲しかったです。 ワープ中に接触してきたのが異次元人だと思ってたら、結局クーパー自信だったし、高次元空間のシーンでも異次元人の存在を匂わせて無かったと思います。 あと、マーフの部屋の超常現象はクーパーの仕業だったまでは良くて、異次元人＝クーパーだったというのは上手いなと思いました。 そうだとすると、余計ワームホールを作ったのは誰か、クーパーを戻したのは誰か、気になってしまいます。 やはり異次元人はいて、我々とはコミュニケーションを取ることが出来なかったのだと解釈しておくことにします。
このレビューはあえてダメな点を書くという趣向ですので酷評しているように見えますが、総合評価は納得の高得点です。 久しぶりに重厚なSF映画を観させていただきました、ありがとうございます、というのが感想です。 ちょっと長いのですぐは無理ですが、もう一度観なおしたいと思いました。
Windows10 の共有フォルダに、WindowsXP から接続できない場合がありました。共有できているフォルダもあり、設定を見る限り違いはまったくありません。共有しようとするHDDが4TBなのが原因じゃないかとか、128ビットの暗号化を下げてみたりしましたが、見当違いだったようです。詳しい症状は下記の通り。
ネット検索に少し苦労しましたが、原因はスタックサイズが不足している、ということでレジストリを変更することで対応可能だと分かりました。これが原因の場合、アクセスに失敗した際、イベントビューアーの「Windowsログ＞システム」にイベントID=2011のエラーが出ているようです。設定方法はこちらにありましたので、引用しておきます。
久しぶりに VMware Player の環境を起動したら、ゲストOSからブリッジ接続できなくなっていました。 先だって、VMware Player のアップデートをしたのが原因かと思って、見当違いの試行錯誤をしてしまいました。 似たような症状で困っている人がいると悪いので、メモを残しておきます。
仮想マシンのネットワーク設定がブリッジになっているとか、そういう基本的な設定は出来ているすれば、ホスト側のネットワークアダプタを確認しましょう。 物理ネットワークアダプタ以外に、仮想ネットワークアダプタがインストールされている場合があります。 特に、他の仮想化ソフトウェア（Virtual BOX など）がインストールされていると、そういう状態になっています。 この場合、物理ネットワークアダプタ以外（要はインターネットに出れるアダプタ以外）のプロパティを開き、「VMware Bridge Protocol」のチェックを外してください。 これでゲストOSから、インターネットに出ていけるようになると思います。
あと、関係ないけど VMware Tools のアイコンが、通知エリアやプログラムメニューにも無いんですが、何かおかしいでしょうか。 とりあえず、使えているので問題は無いのですが、今まであったものが無くなると、何となく気になる。