遠隔PCについて考える。
どうでもいいが、なぜか俺はタイムゾーン（以下、「TZ」と略）の異なる遠隔地(複数箇所)に、各所1台以上のいわゆる「PC」を保有管理している。
一体なぜそうなったのか、細かい説明は「安全管理上」省略するが、一番的を得た表現は「行きがかり上こうなった」だ。また、「一体何に使用しているのか」という疑問もあるかもしれないが、これも安全上詳細は述べないとしても、ハッキリ言って最早必要無いといってもよい。これもいまのところ、行きがかり上維持だ。
一応、物理的に異なる場所でのデータ保持とか、プロキシの代替とか、そこのロケーションが物理的に欲しい場合とか、必要な理由は（一応）あるが、それもクラウドとかVPNとか他の方法を用いれば解消可能だろうし、データ保持とかいっても自分のデータにどれだけ価値があるのか疑わしいし、また機器も古くなって来て維持管理更新の類のメンテも面倒、そうでなくても一々何かあったら面倒だし、早晩、「廃棄」の方向になるだろう。
それはいいとして、遠隔マシンというのはその場の作業が出来ないので、往々にして「自律的」な設定が必要である。
「自律的処理」といっても色々だが、スクリプト等のプログラムを自動で動かすといった処理は、何か問題があってもそれを「修正」出来ればそれほど問題では無い。
という事で、「修正」の為の「アクセス」の維持が、俺の場合は重要な問題となる。
PCの手前の「ネットワーク機器」が何らかの理由で動かなくなれば、それらはプロバイダの所有物であることも多く、ほぼどうしようもないが、そこは問題無い上での「PC自体へのアクセス」でいえば、Linuxのサーバで言えば即ち「openssh-server」が設定通り動いているかどうかである。
だが、仮にそれが動いて無くても、画面共有とか、他のアクセスが生きていてそこで仮想端末にアクセスできれば、sshd設定も修正可能かも知れない。とにかくsshにしても何にしても、PCが起動していれば一応、大体の場合はそこ（ssh等のアクセスを提供するためのサービスの起動）までたどり着くとして、では問題はPCの起動状態を維持するにはどうすれば良いかという事になる。
手っ取り早い方法は、一度起動したらそれを維持して常時動作中にすることだ。
だが、動かしっぱなしでも、往々にして落ちてしまうことが有る。例えば停電や落雷など電力系の問題は起きうる。
しかし、電力は問題無いにしても、あるいはバッテリー補助電源でそれをカバーしたとしても、矢張り常時動かしておくというのは気が進まない。容量や温度の問題で落ちるかもしれない。
また、そこに人が居れば、ファンやHDの音がうるさいので深夜はとめたいという場合もあるだろう。安全上もある程度の頻度の再起動が好ましい。そもそも何ヶ月も動かしっぱなしでは、ホコリも溜まり放題だし熱いままだし、いつか何らかの問題が発生しやすい。
という事で、あくまで俺の場合であるが、各PCは定期的にシャットダウンし、その後自律的に起動させて、そういう危険度を低くしようとしている。実際低くなっているのかは分からないが、一応これで上記のような「問題」は起きていない。
だが先日、以下のような問題が起きた。
原因は、CPUファンだ。
どのマザボかにも依るかも知れないが、CPUファンが動かないと、普通システムは起動しない。CPUが熱くなりすぎるかもしれないので、当然の動作だ。
そのCPUファンが、前触れも無く、動かなくなった。といっても、その場に居ないので、遠隔地からは「ん？このPCにアクセス出来ないな。どうしたんだろう」という感じである。先日物理的に調査できて、CPUファンが動かない事が判明した。最初の感想は「CPUファンって動かなくなる事があるのか‥」という素人の感想であった。どうでもよい。
クラウドサービスとかなら、バックアップが常に維持されていて、あるインスタンスで問題があれば第二候補を起動させるとかしてあるだろうからユーザはこの類の心配は無いのかもしれない。俺の場合は特殊な周辺機器を繋ぐ必要があってこのマシンはクラウドに置けないのだ。
ということで、ファンを注文し取り付けるハメになった。
まぁこういう不具合はこの遠隔運用を止めるまで悩まされるだろう。PC1台で何百何千もの部品があるから、どれがいつ壊れてもおかしくない。
それはいいとして、上にも書いたが「遠隔運用」をかなり長い間やっており、マシンの更新も面倒だし、また上記「特殊な機器」が挿せるマザボも少なくなってきたので、各PCはかなりの「年代モノ」となってきてしまった。
それ故に、BIOSやファームウエアの類も、更新自体が途絶えて久しく、また年々動作も怪しくなってくる事もある。
今回調査して新たに気がついたのは、自律起動というのはBIOSの機能であるが、その起動時間の設定で怪しい動作が見られた事である。全部のマシンではないが、BIOSのバグなのかそれ以外の問題なのか、時間の設定がしばしばクリアされてしまう。
このような事が複数の遠隔地で何回か起こったりして、UEFIでないPCがほとんどということもあり、各PCの時間設定で混乱してしまった。結局、全部のPCのBIOS時間を、GMTで統一するハメになった。そうでないと、俺の頭だと訳が分からなくなってしまう。GMTでなくても統一すれば良いが、時差計算でGMTからだと考えやすいかもとも思った。色々意見はあるだろうが、これも一つのやり方である。
以下古い情報かもしれないが、http://archive.linux.or.jp/JF/JFdocs/TimePrecision-HOWTO/set.html からの引用：
- Linux だけのマシン
- この場合は BIOS 時刻は UTC にしておくのがいいでしょう。 サマータイムの変更も タイムゾーン設定 によって動的に管理されます。
- Linux と MS Windows のデュアルブートマシン
- Windows は、Linux に比べ、時刻を原始的に扱います。 Windows では BIOS 時刻が常に地方時 (localtime) に等しく、 したがってサマータイムにおいては、 ハードウェアクロックが直接変更されるという、 より大きな変化が生じることになります。 Linux も Windows もブート時にはハードウェアから時刻を取得して設定するので、 両者を共存させるときには Linux でも同じやり方で時刻を扱わなければなりません。 したがって BIOS 時刻を 自分の地方時に合わせなければなりません。
俺の理解ではハードウエアクロックとシステムクロックは違っても良いし、ここの運用ではハードウエアクロックは自律的起動の時間設定でのみ使用されるから、とりあえずこうすることにした。とにかく、各マシンのハードウエアクロックはすべてGMTと、ここは少なくとも単純化できると考えた。
その上で、ここのTZだと居住地が何時に起動だから、でも遠隔地の時間も考慮して、GMTの何時何分に起動だ、という、「一気に3つのTZ」を参考にしなくては行けないハメ（自分の所為だが）になったのだ。
1つ時間を決めれば各TZの時間も決まるから、まぁ表を作れば良いのであるが、面倒なのでそれはやらず「えーと、TZ:A地点のX時Y分はTZ:B地点の何時何分だろう？」と何十回も考えるので、そういうのをコマンドでやりたい。Googleで聞いても良いが、ターミナルの方が早いし使い慣れている。
unixにはdateコマンドというのがあってそれを使うというのは分かっているが、問題はどういうオプションを送るかである。
例えば現在地は日本、サーバはアメリカの太平洋時間（PST）の有る場所にあって、そのハードウエアクロックはGMT。そのサーバを日本時間の都合でできればJSTの朝早く、だが現地時間でなるべく夕食や通勤で人々が忙しくなる時間帯前か、それより少し後にしたい。
BIOSの起動GMTは何時頃が良いのか？
まず日本である早い時間を例として取り出してPSTで何時か調べる。
> TZ=America/Los\ Angeles date -d "Jan 1 08:00 JST"
Tue Dec 31 23:00:00 America 2024
23時か、90分あとだとどうか？
TZ=America/Los\ Angeles date -d "Jan 1 08:00 JST + 90 minutes"
Wed Jan 1 00:30:00 America 2025
なるほど0時まわって0時半か。とりあえずこれで良い。で、それはGMTだと何時か？
TZ=Europe/London date -d "Jan 1 00:30:00 PST"
Wed Jan 1 08:30:00 GMT 2025
つまりPCの起動はGMTで08:30という事になる。これは一例だが何月何日とか、曜日とか、何日おきとか、複雑になるにつれて書くTZの対応時間をコマンドで聞ければ便利な事もあるだろう。どうだろうか。
