Oracle Cloudでは使用状況レポートを有効にしないとVM内にアクセスエラーログがたまりまくるので注意

東京リージョンでOracle Cloud Always Freeインスタンスを作れないので、US West(Phoenix)リージョンでアカウントを作り直してOracle Linux 7インスタンスを作ってみたところ /var/log/oracle-cloud-agent/agent.log にスクリプトの実行エラーが毎秒出ている。

作り直し前の方ではagent.logは正常なのに何故?と思ったら、Oracle Cloudコンソールの「アカウント管理」の「使用状況レポート」が未設定なためだった。

上記にある様に「アイデンティティ」の「ポリシー」にて「ポリシーの作成」をクリックし、上記ページに書かれている「ステートメント1」「ステートメント2」を下記画面の「ポリシーステートメント」に貼り付ければOK。(名前と説明は適当につける)

なお、ステートメント2にある「<group>」は「Administrators」に置き換える必要がある。(「アイデンティティ」の「グループ」に登録済みのグループ名に置き換える)

この設定を行ったあと、agent.logへエラーを吐き出していたインスタンス上で「 systemctrl restart oracle-cloud-agent.service 」を実行することでエラーは収まりました。

Oracle CloudのAlways Freeインスタンスを作る際に誤って有料インスタンスを作ってしまいがちな件

他のよくある質問とその答え
・Always Freeインスタンスが作れない件→「Tokyoで作れないのは仕様
・ホームリージョンの変更できるの→「アカウント作成後の変更は不可能
・作ったOracle Linuxインスタンスにsshログインできない件→「インスタンス名に日本語入れてるから」)

Oracle CloudでAlways Freeインスタンスを作成する際、誤って有料のインスタンスを作ってしまうことがある。

例えば、下記の画面だとAlways Freeインスタンスではない。

どこを見ればそれがわかるのか?

上記の「シェイプとタイプ」のところに「常に無料の対象(Always Free対象)」という記載があるかどうかです。

「Always Free対象」である場合は、下記の様に「VM.Standard.E2.1.Micro(仮想マシン)」であることと、その横に「Alwasy Free対象」があります。

Always Free対象の表示が無いので変更するかと「シェイプ、ネットワークおよびストレージオプションの表示」を選択してみましょう。

次の罠が登場です。

「インスタンスタイプ」のところの「仮想マシン」は「Always Free対象」と書かれていますが、「インスタンスのシェイプ」には「Always Free対象」の表記がありません。

正しく「Always Free対象」が選択されている場合は、下記の様にインスタンスのシェイプでもAlways Free対象と表記されています。

Always Free対象となっていない場合は、「シェイプの変更」から変更しましょう。

・・・ないですか?

それは、いまいるリージョンがホームリージョンではないからですね。

右上にあるリージョン切り替えから「ホームリージョン」とかかれたものを選択しましょう。すると下記の様に「Always Free対象」が現れるはずです。

・・・え?

「Japan East(Tokyo)」リージョンだと「Out of host capacity」で作成できないから他のリージョンに変更したい?

残念ながらホームリージョンでしかAlways Free対象とならず、またホームリージョンの変更は不可能とのことです。 (ネタ元 Freedom to Build – Announcing Oracle Cloud Free Tier with New Always Free Services and Always Free Oracle Autonomous Database)

諦めてアカウントを作り直すか、運良く東京に空きができたタイミングで作成できることを期待してインスタンス作成を繰り返してみてください。

Oracle Cloud Always Free Tierはホームリージョンでのみ作成できるが、現在North AmericaとEMEAリージョンでしか作成できない

2021/08/24追記

ドキュメント上は相変わらずAlways Freeはホームリージョンで作成できる、とありますが、ARMプロセッサのインスタンスに関しての記述が緩いな?と思って試してみると、ホームリージョン:Tokyoなんですが、US WestでARMインスタンスが作成作成できてしまいました。


2019/10/04 追記
昨日から東京でもAlways Freeインスタンスの作成に成功するようになりました。
→その後、10/6には作れなくなる。10/8頃から作成可能。10/10には作れなくなる、と頻繁に状況が変わっています


Oracle Cloud Free Tier(“Always Free”,”Free Tier”といろいろ表記があって謎)を使って見ようと、ホームリージョンを日本で設定してみたところ、「Out of host capaticy」という表示で作成できない。

データリージョン一覧ページに「Free Oracle Cloud Promotion is only available in North America and EMEA data regions.」と書かれていたので、North AmericaかEMEAリージョンで作成すればいいのかな?と考えていた。(なお、「Free Oracle Cloud Promotion」と「Always Free」が同じモノを指しているかは不明です)

しかし、ホームリージョン以外では、Always Free(常に無料の対象)となる「VM.Standard.E2.1.Micro」が表示されない。


どういうことかと調べ回ったところ「Freedom to Build – Announcing Oracle Cloud Free Tier with New Always Free Services and Always Free Oracle Autonomous Database」に記載を発見。

「Alwasys Freeはホームリージョンでのみ提供」「アカウント作成時に指定したホームリージョンは変更できない」

twitterを検索すると、東京リージョンでも時々作成に成功することはあるようなので、空きが無くて作れないだけではあるようだ。

はたして東京リージョンで気軽にAlways Freeを使える日は来るのだろうか???

Oracle CloudでOracle Linux 7.xを作ると「Permission denied (publickey,gssapi-keyex,gssapi-with-mic).」でsshログインできない

Oracle Cloud Free Tierというものが登場したので、Oracle Cloudを使ってみたところ、Oralce Linux 7.7インスタンスにsshログインできない。
「Permission denied (publickey,gssapi-keyex,gssapi-with-mic).」 と言われる。

いろいろ調べたが原因が分からない。

試しにとUbuntu 18.10でやってみるとそちらではsshログインに成功、そして、Oracle Linux 6.10でやってみるとそちらもログイン成功。

・・・ん?ホスト名が「インスタンス-20190920-1006」?

実はここまでインスタンス作成時に指定するインスタンス名を標準状態の「インスタンス-日付-時刻」というもので作成していました。

そこがそのままホスト名になっているということは、もしや、日本語処理でバグって失敗しているのでは?ということで、Oracle Linux 7.7インスタンスのインスタンス名を「testvm」として新規作成してみた。

ログイン成功!

どうやらOracle Linux 7.xについてはインスタンス名に日本語が含まれていると正常に作成されないようです。

とりあえずこの件はサポートメールを送っておきましたがどうなることやら。

(2019/10/01現在、メールには何の応答もありません)

なお、Free tierについては、うまく作れていません。→ Tokyoは空きがなく作成できない。「Oracle Cloud Always Free Tierはホームリージョンでのみ作成できるが、現在North AmericaとEMEAリージョンでしか作成できない」→ よって、ホームリージョンを Tokyoで作ってしまったアカウントでFree Tierを試すのは絶望的

Hyper-V第2世代仮想マシンにWindows Server 2012R2をインストールしたらKB3000850適用に失敗する

Windows Server 2016を立てて、Hyper-V上にWindows Server 2012R2仮想マシンを作ろうとしたら、うまくいかない事例が発生。

オンラインのWindows Update実施ではなく、某社が用意した一括適用バッチファイルを実行して適用したところ、必ず適用に失敗し、元に戻す処理が発生するした。

提供されたバッチファイルを分割しまくり、原因を調査していったところ、KB3000850の適用に失敗していることを発見。

問題のKB「Windows RT 8.1、Windows 8.1 および Windows Server 2012 R2 用の 2014 年 11 月付け更新プログラムのロールアップ

既知の事例に第2世代仮想マシンで適用が失敗することが記載されている。

ベースの Windows Server 2012 R2 の HYPER-V ホストを実行して使用して UEFI ファームウェアをサポートする第 2 世代の仮想マシンのゲストを実行しているし、セキュリティで保護されたブート オプションを有効にしたがあります。さらに、ゲスト バーチャル マシンは、Windows Server 2012 R2 を実行しています。

対処方法としてKB2975061「月の 2014 年まで Windows 8.1 および Windows Server 2012 R2 の更新プログラムのサービスを提供」を事前に適用する、とある。

確認してみると、某社提供のパッチ集にKB2975061が含まれていない。

このため、別途KB2975061をダウンロード・適用した後、一度再起動し、そのあとKB3000850を適用したところ、正常に適用が成功した。

このことから、某社提供のパッチ適用スクリプトが問題だったということですね。

あとでWSUS Offline Updateと比較してみよう

モバイルバージョンを終了