memo.

カテゴリー: 技術系memo

  • Veeam Backupの合成フルバックアップが便利

    Veeam Backup & Replication11（以降）の合成フルバックアップの機能が便利だ。毎週、フルバックアップの作成をしなくても、バックアップされているデータから、フルバックアップに相当するファイルが作成される。フルバックアップにかかる負荷が軽減されるので、結構、便利な機能だ。

    合成フルバックアップの説明については、下記のURLに載っている。

    https://helpcenter.veeam.com/jp/docs/backup/vsphere/synthetic_full_backup.html?ver=110

    合成フルバックアップには、次のような利点があります。

    合成フルバックアップは、既にディスクに保存されているバックアップファイルから作成されるため、ネットワークリソースを使用しません。

    合成フルバックアップはバックアップリポジトリに直接合成されるため、本番環境に対する負荷が軽減されます。

    合成フルバックアップの設定は下記。

    １．Veeam Backupのバックアップ設定のウィザードを開く

    ２．ウィザードを「Storage」に進める

    ３．「Advanced」のボタンをクリックする

    ４．「Create synthetic full backups periodically」オプションにチェックを入れて、OKをクリックする

    ５．他の設定を設定すれば終わり

    できれば、フルバックアップは月で採りたいのだが、現状では曜日しか選べないので週次での取得になってしまう。

  • WSL2のUbuntuのイメージ保存場所

    WSL2で、実際のデータがどこにあるのか気になって調べたので、メモ。

    デフォルト設定では、ユーザアカウントの「AppData¥Local¥Packages¥」の下に、フォルダ分けされて保存されていく。WSL2の場合は、「ext4.vhdx」で保存されるのだが、WSL1でLinuxを展開して、WSL2に変換した場合は、下記のように「rootfs」フォルダの下にファイルが展開される。WSL（WSL1）の場合も同じフォルダだ。

    C:\Users\%USER%\AppData\Local\Packages\CanonicalGroupLimited.UbuntuonWindows_79rhkp1fndgsc\LocalState\rootfs

    ※　%USER% の部分は、自分のユーザ名に置き換えてアクセスする。

    最初からWSL2の場合は、vhdxファイルで下記のフォルダに展開されているはず。

    C:\Users\%USER%\AppData\Local\Packages\CanonicalGroupLimited.UbuntuonWindows_79rhkp1fndgsc\LocalState\

    参考：　　https://learn.microsoft.com/en-us/windows/wsl/disk-space

  • PowerShell ISEでps1のファイルを開くと文字化けする

    Windows10のPowerShell ISEで、ps1ファイル（PowerShellのスクリプトファイル）を開くと、文字化けする。日本語のコメント部分が文字化けするので使いにくい。対処方法を調べてみたのだが。

    PowerShell ISEの読み込み時のデフォルトの文字コードは、ShiftJISである。この読み込み時のデフォルトの文字コードを変更することはできない。OSの文字コードではなくて、PowerShell ISEのデフォルト設定であるため。

    ps1ファイルに、BOM付でUTF-8指定されている場合には、開いても文字化けせず、UTF-8としてファイルを開いてくれる。

    Windows10は、現在はメモ帳などで作成したファイルにBOMを付けていない。デフォルトはUTF-8で、BOMなしはUTF-8解釈されるし、それで保存される。

    PowerShellのスクリプトファイルを作成するときは、保存するときに拡張子を .ps1 で保存するだけではなく、オプションとして、BOMで文字コードをUTF-8指定で保存する必要がある。もし、.ps1ファイルをPowerShell ISEで開くときに文字化けする場合は、一度、メモ帳などで開き、BOM付で保存しなおす必要がある。

    なんと厄介な。Powershell ISE は標準でインストールされているので実行時したりするときに便利だったのだけど。

  • SQL Serverで日付をyyyy/mm/ddで表示しようとしたら関数が認識されずエラーになった

    SQL Serverのバージョン違いによるTransact-SQLの差は、忘れたころに踏み抜く。SQL Server 2005で、yyyy/mm/dd形式で日付を出力しようとしたところ、下記のエラーが表示されて、実行できず。

    'format' は 組み込み関数名 として認識されません。

    formatは、SQL Server 2016以降はつかえるようだ。対象は、SQL Server 2005なので、format関数は追加されておらず、convert関数を使って、yyyy/mm/ddの形式にする。例としては下記。

    SQL Server 2005で、日付（datetime型、smalldatetime型など）を、yyyy/mm/dd の形式で表示する。

    select convert(nvarchar,GetDate(),111) AS 'yyyy/mm/ddフォーマット'

    SQL Server 2019で、日付（datetime型、smalldatetime型など）を、yyyy/mm/dd の形式で表示する。

    select format(GetDate(),'yyyy/MM/dd') AS 'yyyy/mm/ddフォーマット'

    SQL Server 2019は、convert関数でも動作する。

  • Google Bardを使ってみた

    Google WorkspaceでもGoogle Bardを使えるようになったので、ONにして使ってみた。個人アカウントもWorkspaceアカウントなので、使えるようになってよかった。

    https://bard.google.com/

    利用規約を読むと、入力内容を使って学習する可能性があるようなことが書かれていた。規約上も、機密情報やセンシティブ情報は入力しないように書かれている。

    Bard自身に問いかけてみると、正直にAIの学習に使用すると、答えてくれる。加えて、FAQには、入力した会話データを個人が特定できない形にしてサンプリングしたものを「トレーニングをうけたレビューアーのレビュー対象になる」ということが書かれている。個人情報などは消されるとしても、判別が難しい秘密の情報は学習に使われてしまうようだ。ちなみに、Bardでの会話データの削除依頼はできるとのこと。

    それから、入力したデータを学習に使わせないようにするためのオプトアウトの仕組みは、まだ無いとのこと。

    Google Bardを使ってみて、便利なのはBardとの会話で表示された文章を、Google ドキュメントの形式でエクスポートできるということ。一般的な内容であれば、活用シーンもいろいろとありそうだ。Googleスプレッドシートには、今はまだエクスポートができない。そのうち、アウトラインだけ書いたら、スライドとか作ってくれるようになりそうだが。

  • 急にNpgsqlからAzure Database for PostgreSQLへの接続ができなくなった

    急に.NET6（.NET 3.1～7も）のNpgsqlからAzure Database for PostgreSQLへの接続ができなくなった。

    アプリケーション側からみると、Azure側のPostgreSQLに強制切断されているようにみえるログが出ている。

     ---> Npgsql.NpgsqlException (0x80004005): Exception while writing to stream
 ---> System.IO.IOException: Unable to write data to the transport connection: 既存の接続はリモート ホストに強制的に切断されました。.
 ---> System.Net.Sockets.SocketException (10054): 既存の接続はリモート ホストに強制的に切断されました。
   at System.Net.Sockets.NetworkStream.Write(Byte[] buffer, Int32 offset, Int32 count)

    こうなると、通常考えるのは、AzureのPostgreSQLで、コネクション数があふれているとか、高負荷状態とか、DBaaSの制約（PostgreSQL設定の外側）が原因じゃないかということ。これを１つ１つ調べていくと、異常なし。Azure側には問題が見当たらず。DBのログをAzureの管理ページがダウンロードして確認してみると、下記のログがあり。

    could not receive data from client: An existing connection was forcibly closed by the remote host.

    AzureのPostgreSQLからみると、クライアント側が切断しているとのこと。

    調べてみると、「Azure Database for PostgreSQL Single server」は、ルート証明書が変更されていることがわかった。.NETで、Ngpsqlを使っている場合は、「Baltimore CyberTrust Root」と「DigiCert Global Root G2」が使うWindows（Windows Server含む）にインストールされている必要があるとのこと。ルート証明書の確認をすると、「DigiCert Global Root G2」が存在していなかった。これが原因なので、下記のマイクロソフトの内容に従い、確認して作業した。

    Understanding the changes in the Root CA change for Azure Database for PostgreSQL Single server
    https://learn.microsoft.com/en-us/azure/postgresql/single-server/concepts-certificate-rotation#what-do-i-need-to-do-to-maintain-connectivity

    今回足りていなかったのは、「DigiCert Global Root G2」なので、Digicertのサイトからルート証明書をダウンロードした。

    https://www.digicert.com/kb/digicert-root-certificates.htm#roots
    （「Download DER/CRT」をクリックして、CRTファイルをダウンロード）

    CRTファイルを、ルート証明書が足りていないサーバに持っていき、ダブルクリックして、ウィザードからルート証明書をインストールした。配置場所は自動選択させることでルートのところにインストールされた。

    なお、ルート証明書のインストール後のOS再起動はしなくても、ルート証明書を使い始めた。

  • SQL ServerのDBを読み取り専用にする方法

    SQL Serverのデータベースを読み取り専用（リードオンリー）する、または解除するには、次のことを行う。

    1. SQL Server Management Studio (SSMS) を使い、管理権限のあるユーザで接続する。

    2. 対象のDBを選択して、右クリックして、プロパティを開く。

    3. オプションを開く。

    4. 「状態」の中にある「読み取り専用データベース」の項目を探す。

    5. 「読み取り専用」にする場合は、プルダウンで「True」を選択する。読み取り専用を解除する場合は「False」を選択する。

    6. 「OK」をクリックする。これを行うと、一度、該当DBへのすべての接続が切断されるので注意すること。

  • Oracle DatabaseでSQLの結果表示する件数を制限する方法

    MySQLだと、limitを使うことで検索結果の表示件数の制御ができるが、Oracle Databaseだとlimitがないので、指定できない。そんなに使う機会がないので、調べる手間があるのでメモ。

    Oracle Databaseでやる場合には、「ROWNUM」を使うことで似たようなことができる。例えば、ROWNUMで、10以下に設定すると、最初から10行目まで表示される。これをうまく使うことで、いろいろとできる。

    例）

    SELECT EXTENDED_TIMESTAMP, DB_USER, SQL_TEXT  
FROM DBA_COMMON_AUDIT_TRAIL  
WHERE ROWNUM <= 10;

  • APT攻撃やマルウェアを防ぐツールをテストするときに使えるツールのメモ。

    APT攻撃やマルウェアを防ぐアンチウィルスやEDRツールなどをテストしたいときに、使えるツールのメモ。

    下記に公開されているツールを、コマンドで実行すれば検知されるかどうかがわかるとのこと。

    APTシミュレーター：システムが APT 攻撃の被害者であるかのように見せるためのツールセット
    https://github.com/NextronSystems/APTSimulator

    まだ、試せていないので、余裕ができたら試してみたい。

  • 企業用のMicrosoft 365でログイン時に2段階認証を求められるようになった。

    企業用のMicrosoft 365でログイン時に2段階認証を求められるようになったと、急に言われ始めた。もともとMFAのところは設定していないので、2段階認証が求められるはずはないはずだが。

    念のため調べてみると、Microsoft 365の画面の「ホーム　＞　セットアップ　＞　多要素認証 (MFA) の構成」で、「完了」のところに緑チェックマークがついている。

    ここの管理をクリックすると、Azure ADの管理画面が開く。概要のプロパティのタブを開くと、「お客様の組織は、セキュリティの既定値群で保護されています。」に緑チェックマークがついている。セキュリティの規定値で、MFAが有効化されているので、M365のログイン時に、2段階認証のMicrosoft Authenticatorの登録が促されていた。MFAを無効化する場合は、ここの「セキュリティの既定値の管理」をクリックして、設定を変更する。

    この規定値については、下記の「Japan Azure Identity Support Blog」にあるように、自動的に有効化されたため。

    2022 年 6 月末から「セキュリティの既定値群」の有効化が促されます (対象 : 一部のテナント)
    https://jpazureid.github.io/blog/azure-active-directory/security-default-2022/