以前Desk mini 110にVMWare ESXi インストール成功＆安定運用しているVMWare ESXi だが、今度はShuttleのXH110Vにインストールしてみた。
同じチップセットだから上手くいくだろうという見通し。
インストールにあたってはBIOSをUEFIブートにした。
インストール後にリブートして、IP V4の設定。しかしLANにつながらず
つながらない原因はNICが二つあって、右側だけを設定してたので右側につなぎなおした。
そしたら疎通確認完了。
LAN二つ設定もできるのかな？
定期購読時にキャンセルしたりアップグレードしたときに付与されるlinkedPurchaseTokenフィールド
発生するケースは以下の２パターン
サブスクリプションを購入後、期限前にキャンセルし、再び期限前に購入（１ヶ月のプランで、即日解約して、翌日買い直し）
サブスクリプションを購入後、別のプランにアップグレード
この場合にlinkedPurchaseTokenが以前のレシート情報を保持するtokenとなる（linkedPurchaseTokenは直訳すればつながれている購入履歴トークン)
以下GoogleのAPIページの意訳をしてみる。
For example, suppose a user originally signs up and you receive purchase token X, then the user cancels and goes through the resignup flow (before their subscription lapses) and you receive purchase token Y, and finally the user upgrades their subscription and you receive purchase token Z. If you call this API with purchase token Z, this field will be set to Y. If you call this API with purchase token Y, this field will be set to X. If you call this API with purchase token X, this field will not be set.
例えば、最初に購入したトークンをXとする。それをキャンセルしたのち、サブスクリプションの期限無いにもう一度購入するとトークンYが発行される。この後さらにプランをアップグレードするとトークンZが発行される。
トークンZでレシート検証APIを呼ぶと、linkedPurchaseTokenにはトークンYがセットされる。
トークンYでレシート検証APIを呼ぶと、linkedPurchaseTokenにはトークンXがセットされる。
トークンXでレシート検証APIを呼ぶと、linkedPurchaseTokenにはなにも設定されない。
キャリアモデルに遅ればせながら、SIMフリーモデルのSH-M05にもAndroid8.0が更新提供された。
8.0に出来る端末が少ない中で貴重なアップデートではあるが、しかしOSアップデートを繰り返すと間違いなくパフォーマンス劣化（Windowsもアップデートよりもクリーンインストールのほうがよい）となるので、あげるならついでに初期化かナーという気がする。
おそらく休眠アカウントと思われるアカウント乗っ取りが周囲で相次いでいる。
パスワードの使いまわしなどはしていないし、パスワードも相当複雑なので今のところ乗っ取りとは無縁なのだが、
念のためパスワードを変えておいた。
スマホの普及でパスワードが入力しずらく、複雑なパスワードを使わない人が増えているのが根本原因の気がするな。
自衛の策としてはログインアラートの設定と定期的なパスワード変更（最近変更を強制する動きは廃止されつつあるけど）と二段階認証の導入であろうか？
SH-M05は二年間のアップデート保障があり、結構頻繁にソフトウェアアップデートをしてくれるが、
その適用中が全く進捗が分からなくて困る。
再起動するのだが、再起動後の画面がずーと続いて、さらに本体が熱くなってくるのでフリーズしているのかと心配になるが、少なくとも１０分は放置しよう。そのうち上がってくる。
nexus6pをアップデートした場合は進捗状況がでるし、ほかの端末も大体そうだと思うのだが、
不安に思って電源OFFしちゃう人もいるかもしれないのに、なぜこのような作りにしたのかは謎である。
SIMフリーかつおサイフケータイ搭載ということで期待していたSH-M05だが、残念ながらガラケー時代に比べるとわけのわからないトラブルが多い。
最近は電源OFF状態で改札を通ったところピット反応したのに入場記録がないと出て改札で足止め。
本日は改札出るときに二枚あると出て足止め
いずれもやり直したらうまくいったのだが、過去使っていたT008やGRATINA2ではほぼ起きなかった事態。
購入して二日目に改札で引っかかったときは、タッチが離れすぎていたと思っていたが、
最近はきっちりタッチしても上記のトラブルが発生しているので、人の往来が激しい改札で使うのはためらわれるほど。
移動中の動画は画質にこだわるよりも途中で止まったりしないことが優先される。
その意味で画質の選択できるAndroidに比べて、iOSのyoutubeアプリは画質が自動選択になり、
通信状態が良い場合勝手に高画質に固定され、全力でパケットを消費する設定になっていた。
（これによりパケット不足が発生するので、通信キャリアと手を組んでいるのではというぐらい悪質な作りだった）
しかし最近のアップデートでは画質が選択できるようになっていた。
この変更はうれしい。特に混雑時に遅くなるMVNOでは重要。
しかしアプリを起動しなおすと大体480pxに戻っているという極悪なデフォルト設定となっているので注意。
Windows10は大型バージョンアップが半年ごとに降ってくる。
そのバージョンですら、２年でサポートが切れるので新しいのを入れ続けなければいけない。
CF-RZ5は工場リカバリー領域も誤って消してしまい、失うものがない状態であったので
1804をクリーンインストールしてみた。
ダウンロードツールでisoを作成後、rufusでUSBメモリに書き込んだ。
その時あえてUEFIではなくMBR形式にしてみた。
インストール自体は３０分もあれば終わる。勝手に裏でドライバーをダウンロードしてくれるので何もしなくてもほぼ大丈夫。
改元することは決まっているのに、新しい元号が発表されるのが一か月前になりそうとか。
そもそも不測の事態で元号が変わることが今度も発生しうることを考えると、和暦を使うメリットなどまったくないのだが、なぜかまだ使っているシステムが多いな（特に国が絡むシステム）
西暦に統一しておけば元号変わるたびに慌てることもないので、西暦に統一すべしといいたいところだが、公共のシステムが和暦ベースだとなかなかつらい。
国が率先して、コンピュータシステムを西暦に統一すべし！
通常運用しているサーバーであればいろいろライブラリが更新されるのでいきなりUpgradeはしないのだが、
VPSが複数運用できる体制であり、またAnsibleでセットアップできるように作っているのでyum upgradeしてみた。
だいたい300Mぐらいのダウンロードでパッケージもそのぐらい更新対象となる。
以下のコマンドで7.5相当になっていることが確認できた！
# cat /etc/redhat-release CentOS Linux release 7.5.1804 (Core)
おそらくほとんどのVPSでは古いイメージを使っていると思うので、インストール直後にyum upgradeしてしまうのがよいだろう。
