memo.

カテゴリー: 技術系

  • Google AppSheetのアプリを共有しようとしたらエラー

    Google AppSheetで作成したアプリを共有しようとしたら、以下のエラーが出た。

    Error: Policy violation: Error: Workspace AppSheet Core security violation: The app cannot be shared externally.: Learn more: https://support.google.com/a/answer/10447197#core-security

    Google Workspaceの管理画面で、AppSheetの「AppSheet Core ライセンスのセキュリティ設定」を変更して無効にしないと、組織外への共有はできないとのこと。AppSheetを使い始めた時期によって、このセキュリティ設定のデフォルト値は異なるとのこと。

    設定変更は以下。

    1. Google Workspaceの管理画面にアクセスする（管理者である必要あり）。

    2. アプリ　→　Google Workspace　→　AppSheet　の順に開く。

    3. 「AppSheet Core ライセンスのセキュリティ設定」を選択する。

    4. 「AppSheet Core セキュリティを無効にする」を選択して、保存する。

    設定変更後は、反映されるまで時間がかかるので待つ。

    その後、Google AppSheetのアプリ側で、外部組織のユーザを招待して、利用できるのかを確認する。

  • vCenter Server Appilanceにパッチを適用する手順

    vCenter Server Appliance 8.0 u2にパッチをあてたので、その作業のメモ。

    1. ISOファイルをBroadcomのサポートページからダウンロードする。

    2. vcenter appliance  がアクセスできる領域にISOをアップロードする

    3. ISOファイルをvSphereの操作としてマウントする

    4. SSHで、vcenterにアクセスする（root権限のあるユーザを使う）

    5. パッチをステージングする（このコマンドはBashモードにはない。Bashは起動させずに、sshでログインした最初の状態で行う）

    software-packages stage --iso

    6. ステージングされたパッチのリストを確認する。見るだけなので、気にならなければ、手順を飛ばしても良い。

    software-packages list --staged

    7. ステージングされたパッチをインストールする。（ここは時間がかかった）

    software-packages install --staged

    8. 再起動を求められる場合は、vCenter Server Appliance を再起動する

    shutdown now -r "patch reboot"

    これで完了。

    参考： https://docs.vmware.com/jp/VMware-vSphere/8.0/vsphere-vcenter-upgrade/GUID-3E7C2187-42A4-4DD4-9EC8-80D8B0077F82.html?hWord=N4IghgNiBcIApgC4GMAWBLAdgcwASNQFNcA3AYUM0UICdcBlWk23AQQAd2J0xNlCQAXyA

  • CLIでvCenter Server Applianceのバージョンを調べるコマンド（APIコマンド）

    CLIでvCenter Server Applianceのバージョンを調べるコマンド（APIコマンド）は、下記。SSHでログインした後に実行する。

    com.vmware.appliance.version1.system.version.get

    実行例

    Command> com.vmware.appliance.version1.system.version.get
Version:
   Version: 8.0.2.00400
   Product: VMware vCenter Server
   Build: 23929136
   Type: vCenter Server with an embedded Platform Services Controller
   Summary: Patch for VMware vCenter Server 8.0
   Releasedate: June 13, 2024
   Installtime: 2024-07-11T02:22:34.170Z

Command>

    セッション切れでの失敗例

    Command> com.vmware.appliance.version1.system.version.get
Session expired.

Command>

  • Microsoft TeamsでWebhookが廃止に。

    MicrosoftがTeamsのOfficeコネクタの廃止を発表した。Officeコネクタの廃止により、Teamsで使っているWebhookが廃止になる。

    https://devblogs.microsoft.com/microsoft365dev/retirement-of-office-365-connectors-within-microsoft-teams

    ・2024年8月14日で新規のWebhookアドレスの発行は終了。

    ・2024年10月1日からは、Webhookが使えなくなる（Officeコネクタが機能しなくなる）。

    Webhook（Officeコネクタ）の廃止後は、実際には廃止前に、Power AutomateのWorkflowをTeamsに追加して、Teamsに投稿するワークフローを追加する。テンプレートから、Webhook要求をチャネル投稿するワークフローを追加すればよい。試してみたが、Webhook用のワークフローの作成は簡単だった。

    TeamsにWorkflow機能を追加することで、従来のwebhookの代わりが作れることはわかった。もしたくさんのWebhookをTeamsで使っているとしたら、変更していく作業だけでも大変だ。

  • OpenSSHの脆弱性　”regreSSHion”

    OpenSSHの脆弱性　”regreSSHion” (CVE-2024-6387 )。Linux系で新しいディストリビューションは、影響を受けてる。UbuntuやAmazon Linuxなどは対応されているので、アップデートを行えば対応される。 Ubuntuはapt updateでサクッと終わることは確認できた。脆弱性の先祖返りか。そういうこともあるよな。

    あっちこっちサイトを見たけれど、piyologがわかりやすい。

  • ESXi8.0u2をインストールしたときにKB82794のワーニングが出た

    VMware vSphere ESXi 6.7が動作していたサーバを初期化して、ESXi 8.0 u2 をクリーンインストールした。インストーラーを起動して、インストールを行ったときに、KB82794のWarningメッセージが表示された。Warningなので、Continueでインストールはできた（成功した）。

    確認してみると、利用しているサーバのCPUのXeon Silver 4110（Skylake-SP）が、 ESU (End of Servicing Update) / EOSL (End of Servicing Lifetime) と発表されたため、ESXi 8.0.u2で非推奨になったとのこと。KB82794は、そのことが書かれたナレッジだった。

    https://knowledge.broadcom.com/external/article?legacyId=82794

    SkylakeシリーズのCPUは vSphere 8.0系統がサポートされているうちは大丈夫。次のバージョンでは、vSphereが対応してこないので、バージョンアップはできないかもしれない。

  • GitLabをaptでアップデートしたらエラー（Gitlab 17.1.0-ce）

    今回のアップグレードは、Gitlab 17.0.1-ce から Gitlab 17.1.0-ce 。アップグレードパスとしては、問題はないはずだったのだが、下記のエラーが出た。

    Running handlers:
[2024-06-25T18:47:40+09:00] ERROR: Running exception handlers
There was an error running gitlab-ctl reconfigure:

redis_service[redis] (redis::enable line 19) had an error: RuntimeError: ruby_block[warn pending redis restart] (redis::enable line 88) had an error: RuntimeError: Execution of the command `/opt/gitlab/embedded/bin/redis-cli -s /var/opt/gitlab/redis/redis.socket INFO` failed with a non-zero exit code (1)
stdout:
stderr: Could not connect to Redis at /var/opt/gitlab/redis/redis.socket: No such file or directory



Running handlers complete
[2024-06-25T18:47:40+09:00] ERROR: Exception handlers complete
Infra Phase failed. 11 resources updated in 37 seconds
[2024-06-25T18:47:40+09:00] FATAL: Stacktrace dumped to /opt/gitlab/embedded/cookbooks/cache/cinc-stacktrace.out
[2024-06-25T18:47:40+09:00] FATAL: ---------------------------------------------------------------------------------------
[2024-06-25T18:47:40+09:00] FATAL: PLEASE PROVIDE THE CONTENTS OF THE stacktrace.out FILE (above) IF YOU FILE A BUG REPORT
[2024-06-25T18:47:40+09:00] FATAL: ---------------------------------------------------------------------------------------
[2024-06-25T18:47:40+09:00] FATAL: RuntimeError: redis_service[redis] (redis::enable line 19) had an error: RuntimeError: ruby_block[warn pending redis restart] (redis::enable line 88) had an error: RuntimeError: Execution of the command `/opt/gitlab/embedded/bin/redis-cli -s /var/opt/gitlab/redis/redis.socket INFO` failed with a non-zero exit code (1)
stdout:
stderr: Could not connect to Redis at /var/opt/gitlab/redis/redis.socket: No such file or directory


===
There was an error running gitlab-ctl reconfigure. Please check the output above for more
details.
===

dpkg: パッケージ gitlab-ce の処理中にエラーが発生しました (--configure):
 installed gitlab-ce package post-installation script subprocess returned error exit status 1
xxd (2:8.1.2269-1ubuntu5.23) を設定しています ...
vim-common (2:8.1.2269-1ubuntu5.23) を設定しています ...
vim-tiny (2:8.1.2269-1ubuntu5.23) を設定しています ...
dbus (1.12.16-2ubuntu2.3) のトリガを処理しています ...
desktop-file-utils (0.24-1ubuntu3) のトリガを処理しています ...
mime-support (3.64ubuntu1) のトリガを処理しています ...
hicolor-icon-theme (0.17-2) のトリガを処理しています ...
gnome-menus (3.36.0-1ubuntu1) のトリガを処理しています ...
man-db (2.9.1-1) のトリガを処理しています ...
処理中にエラーが発生しました:
 gitlab-ce
E: Sub-process /usr/bin/dpkg returned an error code (1)
zen@LAB:~$

    もう一度、sudo apt upgrade を実行したところ、正常に終了した。

    sudo gitlab-ctl restart　を実行するように出ていたので、実行した。

    GitLabのウェブ画面上からも確認したが、最新（17.1.0）にアップグレードができており、問題はなかった。

  • vSphere8.0でVMの自動起動設定を調べる方法

    vSphere8.0でESXiの起動時（電源ON時）にVMも起動させる設定がされているVMを調べる方法のメモ

    1. vCenter Server にログインする。

    2. 「ホストおよびクラスタ」のメニューを開く。

    3. 自動起動させたいホストを選択する。

    4. 「構成」タブを選択する。

    5. 「仮想マシンの起動およびシャットダウン」を選択する。

    6. 「仮想マシンの起動およびシャットダウン」のメニューに「自動順位付け」「自動」の選択項目があるので、それぞれを選択する。

    7. 起動の部分が「有効」になっているVMが自動起動するVM。起動遅延時間や起動順番を確認すると、どの順番でVMが起動してくるのかがわかる。

  • メモ：.NET8.0の対応Windows OS

    ちょっと検索で探しにくかったので、メモ。

    .NET8.0（.NET9.0も同じだった）が対応しているWindows OSは以下。

    • Windows server 2012以上（2012の場合は、Extended Security Updatesがインストールされていること。サポート無しならばランタイムは動く）
    • Windows server Core 2012以上（2012の場合は、Extended Security Updatesがインストールされていること。サポート無しならばランタイムは動く）
    • Windows10 バージョン1607以上
    • Windows11 バージョン22000以上

    参考：

    https://github.com/dotnet/core/blob/main/release-notes/8.0/supported-os.md

    https://github.com/dotnet/core/blob/main/release-notes/9.0/supported-os.md

  • vSphere8.0でESXiの起動時にVMも起動させる設定

    vSphere8.0でESXiの起動時（電源ON時）にVMも起動させる設定のメモ。

    自動起動は、「ホストがvSphere HAクラスタの一部である場合、仮想マシンの自動起動とシャットダウンが無効になります。」という仕様があるので注意すること。

    vSphere8でのホスト起動時の自動VM起動設定

    1. vCenter Server にログインする。

    2. 「ホストおよびクラスタ」のメニューを開く。

    3. 自動起動させたいホストを選択する。

    4. 「構成」タブを選択する。

    5. 「仮想マシンの起動およびシャットダウン」を選択する。

    6. 「仮想マシンの起動およびシャットダウン」のメニューに「自動順位付け」「自動」「手動での起動」の選択項目があるので、「手動での起動」を選択する。ここで表示されている仮想マシンは自動起動設定がされていないVMである。

    7. 「編集」をクリックする。

    8. 画面内のポップアップで「仮想マシンの起動/シャットダウン設定の編集」が開く。

    9. 「手動での起動」を選択し、一覧から自動起動させる仮想マシンを選択する。

    10. 「移動先」をクリックし、「自動」または「自動順位付け」を選択する。（移動先の場所はわかりにくいので注意）

    11. 上記で選択した「自動」／「自動順位付け」を選択し、選択した仮想マシンが表示されていることを確認する。

    12. 確認後、「OK」をクリックする。（クリック前の起動の表示は無効になっているが、これでよい）

    13. ポップアップが閉じるので、「仮想マシンの起動およびシャットダウン」で、「自動」／「自動順位付け」を選択し、選択した仮想マシンの起動が有効になっていることを確認する。

    もし、自動起動やシャットダウンのタイミングを変更する場合は、編集画面で、起動時間とシャットダウンの時間の秒数を変更する。