memo.

カテゴリー: 技術系memo

  • 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）にアップグレードができており、問題はなかった。

  • 「vixエラーコード＝21009」でVMware Tools のインストールが失敗。

    vCenter Serverから、VM（Windows Server）のVMware Toolsのバージョンアップをおこなったところ、「vixエラーコード＝21009」でVMware Tools のインストールが失敗した。その後、vCenter Serverの画面では、その仮想マシンは「VMware Toolsはインストールされていません」にかわった。

    アンインストールは成功しているようで、仮想マシン上もVMware Toolsは無くなっていた。

    対処方法

    1. 念のため、VM（Windows Server）のVMware Toolsのインストールで利用されていたフォルダを削除。下記のフォルダを中身ごと削除する。アクセス権がないと言われるはずなので、アクセス権を取得してから削除する。

    C:\Windows\Temp\vmware-SYSTEM

    2. vCenter Serverから、VMware Toolsのインストールを実行する（仮想サーバ上に、VMware Toolsのインストーラーをマウントする）。

    3. VMにログインして、VMware Toolsをインストールする。

  • SQL Server 2019からSQL Server 2005へのリンクサーバ経由でアクセスするプロシージャーがエラー

    SQL Server 2019からSQL Server 2005へのリンクサーバ経由でアクセスするプロシージャーでエラーが発生した。

    SQL ServerにSSMSでアクセスしてみると、リンクサーバーは存在する。リンクサーバーへの接続も問題なし。Select文でもリンクサーバー先のテーブルを参照できる。プロシージャーを実行すると、OLEDBのエラーが表示される。

    リンク サーバー "サーバ名" の OLE DB プロバイダー "MSOLEDBSQL" から、メッセージ "トランザクションは既に暗黙的または明示的に、コミットまたは中止されています。" が返されました。
メッセージ 7391、レベル 16、状態 2、プロシージャ dbo.プロシージャー名、行 99 [バッチ開始行 2]
リンク サーバー "サーバ名" の OLE DB プロバイダー "MSOLEDBSQL" で分散トランザクションを開始できなかったので、この操作を実行できませんでした。
    リンク サーバー "サーバ名" の OLE DB プロバイダー "MSOLEDBSQL" で分散トランザクションを開始できなかったので、この操作を実行できませんでした。

    状況をまとめると・・・

    • SQL Server 2005もSQL Server 2019も稼働している。
    • もともとはプロシージャーも正常に実行できていた。
    • リンクサーバーの接続確認は問題なし
    • Select文などを発行すると、正常にリンクサーバーのテーブルにアクセスできる。（Viewでも同様）
    • プロシージャーは、失敗する。
    • 分散トランザクションの設定はちゃんとできている（もともとは成功していた）。
    • リンクサーバーの接続で使用するユーザはアクティブであり、パスワードも問題なし。
    • 実行結果を見ていくと、ごくまれに成功しているときがある（SQL Serverへのコネクションは異なる）

    いろいろと切り分けた結果、認証先？のAD（Active Directory）のOSバージョンによって、プロシージャーの実行が成功するか失敗するかが分かれていた。古いWindowsOSのADに問い合わせがいくと成功する。新しいOS（Windows Server 2022）だと失敗する。

    Windows Server 2022のADに問い合わせされて、SQL Server 2005にアクセスされると、プロトコルとかセキュリティのキーセットの問題ではじかれて分散トランザクションが失敗して、タイムアウトになっているようだ。古いものは、互換性も無くなってきているので、きつい。

  • メモ：　「これdo台SAS (KD25/35SAS)」を使ってHDD消去をしたときの時間

    「これdo台SAS (KD25/35SAS)」を使って、HPEのサーバ用HDDを消去した。

    「HPE 900GB SAS 6G DP 10K」のディスクで、7回消去で14時間くらいで作業が終わった。

    アメリカ国防総省(DoD)規格のDoD消去なら、３回なので半分くらいの6～7時間で終わる。

    ログもUSBメモリに出力できるので、証明も残せる。消去はメニューを選んでボタンを押して、放置するだけ。機器廃棄のときに廃棄証明をとるにしても、事前の作業としてはちょうどいい。

  • Veeam Backupの使用ライセンスから不要なサーバを減らす

    Veeam Backupで取得するVMware vSphere環境の変更を行った。新しい環境のバックアップを行ったところ、別の仮想サーバとして認識され、使用されるライセンス数が2倍になった。

    Inventoryで不要なサーバを削除しても使用されるライセンスは減らない。（Inventoryで不要なサーバを削除するためには、利用されているバックアップタスクの削除も必要）

    不要なサーバで、使用されているライセンスを減らすには、以下の作業でライセンス割り当てを解除する。

    1. Veeam Backup の管理コンソールを開く

    2. メニューからライセンス（License）を開く

    3. 「Instances」のタブを開く

    4. 「Manage…」をクリックする

    5. ライセンスを使用しているサーバの一覧が表示されるので、NameとHostをみて、不要になったサーバを選択して、「 Revoke」をクリックする

    6. 「Revoke」のところ、不要な台数だけ繰り返す。

    7. 終わったら、OKで閉じていく。

  • 仮想基盤を移行したときのVeeam Backupの注意点

    Veeam Backupで仮想基盤のバックアップを取得している場合、vCenter Server や、ダイレクト登録しているESXiを入れ替えて、仮想マシンを移行すると、同じ仮想マシン名でもVeeam Backup上は別のVMとして認識される。そのため、既存のバックアップタスクでは、移行先のホストをVeeam Backupに登録しても、バックアップ対象の仮想マシンは切り替わらない。

    新しい仮想基盤にVMを移行させた場合は、Veeam Backupのバックアップタスクで、バックアップ対象となるVMを、指定しなおす必要がある。具体的には、個別のタスクで旧ホスト側のVMを削除して、新しいホストのVMを指定しなおす。このとき、別VM扱いになるので、バックアップ容量は気を付ける必要がある。

  • .NET アプリがどのランタイムバージョンで動作しているかを調べる

    現在、稼働している.NETのアプリが、どのバージョンのライタイムで、アプリケーションが動作するようになっているのかを調べてみる。この方法は、.NET5よりも後の.NETアプリについて、調べることができる。

    アプリのフォルダで、下記の名前のファイルがあるかを調べる。[appname]の部分には、そのアプリの名前がついている。

    [appname].runtimeconfig.json

    次のそのJSONファイルを開く。メモ帳などのテキストエディタで開けばよい。

    下のような中身になっているので、「tfm」や「version」の部分を確認し、どの.NETバージョンを利用するようになっているのかを確認する。

    {
  "runtimeOptions": {
    "tfm": "net8.0",
    "includedFrameworks": [
      {
        "name": "Microsoft.NETCore.App",
        "version": "8.0.5"
      },
      {
        "name": "Microsoft.AspNetCore.App",
        "version": "8.0.5"
      }
    ],
    "configProperties": {
      "System.GC.Server": true,
      "System.Reflection.Metadata.MetadataUpdater.IsSupported": false,
      "System.Reflection.NullabilityInfoContext.IsSupported": true,
      "System.Runtime.Serialization.EnableUnsafeBinaryFormatterSerialization": false
    }
  }
}

    参考：　https://learn.microsoft.com/en-us/dotnet/core/runtime-config/

  • Veeam Agent for Microsoft Windowsは64TBをこえるボリュームのバックアップを取得できない

    Veeam Agent for Microsoft Windows 6では、64TBをこえるボリュームのバックアップを取得できない。バックアップタスクは作成できるが、バックアップの取得時にエラーになる。ボリューム全体ではなくて、フォルダ指定でもエラーになる。

    これは、Veeam AgentがVSS（Volume Shadow Copy Service ）を利用してバックアップを行っているためである。VSSは、64TBをこえるとスナップショットの作成時にエラーが発生する。そのため、Veeam Agentでのバックアップもエラーになる。

    WindowsのOS側の制約なので、１つのボリュームで64TBにならないようにパーティションをわけて、そのボリュームのバックアップをVeeam Agentでとることになる。

    参考：

    https://helpcenter.veeam.com/docs/agentforwindows/userguide/system_requirements.html?ver=60

    https://learn.microsoft.com/ja-jp/troubleshoot/windows-server/backup-and-storage/usability-limit-volume-shadow-copy-service

  • .NET6から.NET8に変更して実行したらSQLServerとの接続でエラー

    .NET6のサポート終了が近づいているので、.NET8に変更して実行したところ、SQL Serverとの接続でエラーが発生した。

    An unhandled exception occurred while processing the request.
Win32Exception: 信頼されていない機関によって証明書チェーンが発行されました。
Unknown location

SqlException: A connection was successfully established with the server, but then an error occurred during the login process. (provider: SSL Provider, error: 0 - 信頼されていない機関によって証明書チェーンが発行されました。)
Microsoft.Data.SqlClient.SqlInternalConnection.OnError(SqlException exception, bool breakConnection, Action<Action> wrapCloseInAction)

    「Microsoft.Data.SqlClient パッケージ」の破壊的変更の影響だった。対処としては、ConnectionStringsの接続文字列の最後に、「TrustServerCertificate=True;」を追加した。下記みたいな感じ。

      "ConnectionStrings": {
       ～～～略～～～;Database=DBname;TrustServerCertificate=True
  },

    これでもう一度実行して、実行できることを確認した。

    参考：　https://learn.microsoft.com/ja-jp/ef/core/what-is-new/ef-core-7.0/breaking-changes?tabs=v7

  • 13世代のCore i7のノートPCが安定しない

    インテルの13世代のCore i7（Core i7-1360P）のノートPCが安定しない。BSODになったり、動作が重かったり、グラフィック部分で暗転するときがあったり、などなど、13世代Core i7のノートPCの不具合が多い。安定して動いているノートPCもあるので、個体差がある。

    BSODの原因ばかりを探っていたが、PCとしてのパフォーマンスが悪いのでパフォーマンスを強化する方向で調べ方を変えたところ、以下の記事を見つけた。

    Intel issues statement about CPU crashes, blames motherboard makers — BIOSes disable thermal and power protection, causing issues
    https://www.tomshardware.com/pc-components/cpus/intel-issues-statement-about-cpu-crashes-blames-motherboard-makers

    PC側の動作が遅いので、高パフォーマンスで使うようにしてもらっていたが、逆効果になっている可能性がある。BIOSの問題かどうかわからないが、電力消費が増えることによる劣化か安定しないか、その可能性が出てきた。パフォーマンスコアをうまく使えていないのかと思っていたけれど、そもそもCPUが外れか、制御が甘々でパフォーマンスが出ないのかも。14世代のCPUも似たような問題を抱えていそうなので、新モデルが出て、乗り換えるのも得策ではなさそうだ。

    とりあえず、ソフトウェア制御というかアップデートなどで安定してくれるといいのだけど。打つ手がないPCトラブルは大変なので。