カテゴリー: 技術系memo

  • SQL ServerがインストールされたサーバをP2Vしたら起動時にイベントログにエラーが記録される

    イベントログに記録されていたログは下記。

    イベントID 455
    ソース ESENT
    msmdsrv (1400) ログ ファイル C:\Windows\system32\LogFiles\Sum\Api.log を開いているときに、エラー -1032 (0xfffffbf8) が発生しました。
    
    イベントID 489
    ソース ESENT
    msmdsrv (1400) 読み取るためにファイル "C:\Windows\system32\LogFiles\Sum\Api.log" を開こうとしましたが、システム エラー 5 (0x00000005): "アクセスが拒否されました。 " が発生したため開けませんでした。ファイルを開く処理は、エラー -1032 (0xfffffbf8) のため失敗します。
    
    イベントID 490
    ソース ESENT
    msmdsrv (1400) 読み取りまたは書き込みのためにファイル "C:\Windows\system32\LogFiles\Sum\Api.chk" を開こうとしましたが、システム エラー 5 (0x00000005): "アクセスが拒否されました。 " が発生したため開けませんでした。ファイルを開く処理は、エラー -1032 (0xfffffbf8) のため失敗します。

    このエラーは、「C:\Windows\system32\LogFiles\Sum」のRead/Writeのアクセス権がないため、SQL Serverの起動時にログのフォルダを参照できずにエラーが記録されている。

    対応方法は下記。

    1. SQL Serverを実行しているユーザをサービスから調べる。

    2. 「C:\Windows\system32\LogFiles\Sum」のプロパティを開き、セキュリティからユーザを追加し、Read/Writeの権限を付ける。権限を付けるユーザが見つからない場合は、セキュリティを緩めた

    3. Windowsを再起動して、同じログがでるかを確認する。

    これで完了。

  • SQL Serverでプロシージャーの実行がエラーになる

    SQL Serverのプロシージャーの実行権限は、プロシージャーごとに、ロールまたはユーザに対して権限を付与する必要がある。権限を付与しておかないと、プロシージャーの実行ができない。(すっかり忘れていた)

    SQL Server Management Studioを使っている場合は、該当のプロシージャーを選択して、プロパティを開いて、権限の部分で、ユーザやロールを指定して、権限を付与する。

    https://docs.microsoft.com/ja-jp/sql/relational-databases/stored-procedures/grant-permissions-on-a-stored-procedure?view=sql-server-ver15

  • SQL ServerでViewの作成時に照合順序の競合エラーが出た

    SQL ServerでViewの作成時に照合順序の競合エラーが出た。Japanese_CS_ASとJapanese_CI_ASで照合順があわないとのこと。Select文を単体で実行するとエラーにはなっていない。

    equal to 操作の"Japanese_CS_AS"と"Japanese_CI_AS"間での照合順序の競合を解決できません。

    調べていくと、DB上のテーブルの照合順は、「Japanese_CI_AS」で統一されていた。Select文を見直していくと、Where句で照合順を指定しており、これがテーブルと異なっていたため、競合エラーが発生していた。VIEWのときは、テーブル側と照合順が合致している必要があり、これを見落としていたのが原因だった。WHERE句で指定していた照合順をDB上のテーブルで指定されているものに変更した。

    WHERE  項目名 = '値' COLLATE Japanese_CS_AS

    注意としては、照合順を厳密に指定しておく必要がある場合には、指定が変わってしまう。その場合は、検索で一致させるものを変更するなどの対応が必要。

  • .NET Core 3.1をAzure上でサポート期間後も使い続けられるのか?

    LTSの .NET Core 3.1が2022年12月3日に延長サポートが終了する。オンプレミスの環境ならば、自己責任で使い続けられるのだが、Azure上だとどうなるのかが気になり調べていた。それでやっと見つけたのが、下記の記事だ。

    https://azure.microsoft.com/ja-jp/updates/extended-support-for-microsoft-net-core-31-will-end-on-3-december-2022/

    https://azure.microsoft.com/ja-jp/updates/netcore31/

    2022年12月3日を過ぎても、Functions でホストされているアプリケーションは引き続き実行され、アプリケーションは影響を受けないとのこと。いきなり使えなくなるということはなさそうだ。サポート切れ後に、新しく.Net Core 3.1でデプロイできるのかどうかは不明だが、この書き方だと当面は大丈夫そうではある。

    しかし、Azure側の推奨としては、「潜在的なサービスの中断やセキュリティの脆弱性を回避するには、2022 年 12 月 3 日までに、Functions アプリケーションをランタイム バージョン 4.x (.NET 6 を使用する)に更新」することが求められている。何かセキュリティ的な問題が発生した場合には、短い期間で.NET Core 3.1のアプリケーションの実行が打ち切られるということもあり得るということ。さっさとLTSの.NET6に移行しろということだ。

    Azure App Serviceのインスタンスでも、App Service でホストされているアプリケーションは引き続き実行され、既存のワークロードには影響しないとのこと。ただし、同じように.NET6への移行が推奨されている。

  • ASP.NETでChrome対応したらJSでテキストボックスに値が入らなくなったときの対応

    IE用に作られたASP.NETのアプリを、Chrome対応(Chromium Edge対応)しているときに、JavaScriptでASP.NETのパーツのテキストボックス(type=text)に値をいれたところ、値が入らないということがおきた。「getElementById(“ID”).value」に、JavaScriptから値をいれたが、IE11では問題ないのに、Chromeだと値が入らなかった。

    document.getElementById("ID").value = "値";
    // ↑これだと、IE11は値が入るが、Chromeだと入らない。

    PostBackは発生させていない処理なのだが。いろいろと調べていき、Chromeの場合は「.defaultValue」を使って初期状態の値を書き換えれば、画面の表示が変わることを確認できた。

    document.getElementById("ID").defaultValue = "値";
    // ↑Chromeの場合は、defaultValueを書き換える。

    IE11も残しておく必要があったので、ブラウザの種類をみて、IF文でIEとそれ以外で分岐させるようにした。

    サンプル。

        // ブラウザを取得する
        var userAgent = window.navigator.userAgent.toLowerCase();
        if (userAgent.indexOf('msie') != -1) {
            // IEのときの処理を書く
            document.getElementById("ID").value = "aaaa";
        } else {
            // IE以外の処理。ChromeやChromium Edgeの想定
            // document.getElementById.value だと、画面上の表示が変わらないことがわかった。
            // そのため、document.getElementById.defaultValue に変更したところ、うまくいった。
            document.getElementById("ID").defaultValue = "aaaa";
        }
  • VMware vCenter Converter Standalone 6.2 でWindows Server 2003 の変換がエラーになる。

    VMware vCenter Converter Standalone 6.2 でWindows Server 2003 を仮想マシンに変換しようとしたところ、Agentのデプロイで「Error code: 1,603」でエラーになった。

    サポート範囲を調べてみると、Windows Server 2003は、Windows Server 2003 R2 SP2がサポート対象で、R2が付かないバージョンはサポート対象外だった。

    サポート外だが、無理やりP2Vできなかと、Converter Agentだけのインストールをためしてみたが、サービスをオンにするところで、失敗してロールバックした。

    調べてみると、VMware vCenter Converter Standalone 5.0 であれば、無印のWindows Server 2003にインストール可能。試してみたところ、5.0であればインストールはできた(過去にインストーラーを取得しておいてよかった)。しかし、VMware vCenter Converter Standalone 6.2からの接続は、接続経路の暗号化方式の不一致により、エラーになった。

    今度は、vCenter Converter Standalone 5.0 から、ESXi6.7に対して、P2V先を指定してみたが、これも通信時の暗号方式の問題で接続できずエラーになった。

    Veeam Backupのエージェントを、Windows Server 2003(無印)にいれて、イメージバックアップして、そのイメージを仮想マシンとして復元する方法も試した。Veeam BackupもVersion 9.5でも.net frameworkのバージョンが古すぎて、Windows Server 2003(無印)にエージェントのインストールができず。イメージバックアップを取得して、仮想マシンとしてリストアする方法についても失敗した。

    そのため、vCenter Converter Standalone 5.0を使って、Windows Server 2003(無印)を一度、VMware Workstation形式の仮想ファイルに変換した。次に、このVMware Workstation形式のファイルを、vCenter Converter Standalone 6.2で指定し、V2V(Virtual to Virtual)で、ESXi6.7に対して保存した。これで、なんとかP2Vは成功した。ネットワークの設定などは、変わっているため、仮想マシンの設定を編集して、新しくネットワークインターフェースの割り当てを行った。これで無事にWindows Server 2003(無印)のP2Vは完了した。

    仮想化すれば延命はできるが、物理サーバとして存在していると、そもそもP2Vでの仮想化の対象外になってしまう。延命するのであれば、早めに仮想化しておく必要がある。というのが、今回の教訓になった。

  • Oauth2-proxyとGoogle CloudのOauthを連携させるときの注意点

    Oauth2-Proxyで、Google CloudのOauth2.0を連携させたときの注意点として、Oauthでの認証時にGoogle Cloudで設定したOauth2.0クライアント名が表示されてしまう。

    これは、Google Cloud側の設定には、「OAuth 2.0 クライアントの名前。この名前はコンソールでクライアントを識別するためにのみ使用され、エンドユーザーには表示されません。」とあったところだ。

    そのため、気軽に「何とか-test」で名前をつけて、設定したり、テストしていたのだが、Oauth2-Proxyからアクセスしたときの画面に、この「クライアントの名前」が表示されていた。

    これを修正するには、

    1. Google Cloudでプロジェクトを開く。
    2. APIとサービスを開く。
    3. 認証情報を開き、修正するOAuth2.0クライアントIDを探す。
    4. その行の右側にあるペンマークをクリックして、編集する。
    5. 「名前」の部分を変更して、保存する。
  • MySQLでユーザを作り、DBの権限を割り当てる

    最初に、「create user」文で、ユーザを作る。その時にパスワードも設定する。

    次に、grant文で、DBの権限を割り当てる。grant文でユーザ作成も同時に行うこともできるけれど、個人的には、2文に分けた方が設定がわかりやすくて安心できる。

    例)DBとユーザを作り、DBにユーザの権限を付ける。

    create database dbname;
    create user 'user_name'@'localhost' IDENTIFIED BY 'password';
    grant all on 'dbname'.* TO 'user_name'@'localhost';
    • dbname は、データベース名を入れる
    • user_name は、ユーザ名を入れる
    • user_name は、ユーザ名を入れる
  • GASからCloud SQL(MySQL)にSSL接続するコード

    Google Apps Scripsから、Google Cloud SQLのMySQLにSSL(TLS)で通信を暗号化して接続するコードのサンプル。このとき、Cloud SQLのMySQLは、MySQL 5.7よりも古くないと接続できない。

    DBへの接続は、JDBCを使用する。このとき、JDBCの読み込みは必要なく、GASのエディタ上で直接記述してよい。このサンプルでは、SSL(TLS)を使用するバージョン。接続にPEMファイルを使うため、あらかじめGoogle Cloud SQL側で発行しておく必要がある。

    記載するPEMファイルの中身は、末尾に改行コードを表す”\n”をいれて、さらにコード上の改行を明示的にするために”\”を入れる必要があった。なので、PEMファイルの中身の末尾が”\n\”になっている。

    接続のチェックのため、コンソールログに、いろいろと書き出すようにしている。Logの部分はなくても、問題なし。

    サンプルコード。

    function myFunction() {
      dbConnection();
    }
    
    // --------------------------------
    // SSLで接続する
    // --------------------------------
    function dbConnectionSSL(){
    
      Logger.log('start dbConnection function.');
    
      // 接続先設定
      var connectionIp = 'xxx.xxx.xxx.xxx'; // 接続のMysqlのIPアドレス(ホスト名も可)
      var userName = 'user'; // 接続で使うユーザ名
      var passwd = 'pass'; // 接続で使うパスワード
      var databaseName = 'dbname'; // データベース名
    
      var addr = 'jdbc:mysql://' + connectionIp + '/' + databaseName + '?useSSL=true';
    
      // SSL用の証明書を変数に入れる
      var clientKey = '\
    -----BEGIN RSA PRIVATE KEY-----\n\
    MIIEowIBAAKCAQEAyDuIOE1t/ABFSMIz/2Ni4vIoaNvBkDLaeJdl6KmeK9iexl2D2d\n\
    ~~~中略~~~
    P8B5s7xmSbH4Yv/OeKrw8F6xAmoQmWVlnw686I0QqNHexlwIe3lss2LDEI3d\n\
    -----END RSA PRIVATE KEY-----';
    
      var clientCert = '\
    -----BEGIN CERTIFICATE-----\n\
    MIIDVzCCAj+gAwIBAgIEJD9I+TANBgkqhkiG9w0BAQsFADB7MS0wKwYDVQQuEyRl\n\
    ~~~中略~~~
    QNwLDry8Tk3DwnD07+dkQf+FFFu943GFUlY9d4Rv75S+Vwm2Ci2azIRR2Q==\n\
    -----END CERTIFICATE-----';
    
      var serverCa = '\
    -----BEGIN CERTIFICATE-----\n\
    MIIDfzCCAmegAwIBAgIBADANBgkqhkiG9w0BAB3MS0wKwDELW39xwSDyQ3ZjVm\n\
    ~~~中略~~~
    bfgDM8ARAAqMqECaXYC8+xHviva4ON6weeD/wsdessDP9K3ws3mGKbbjlLmc=\n\
    -----END CERTIFICATE-----';
    
      Logger.log('start mysql con');
      Logger.log(addr);
    
      var connectionInfo = {
        user: userName,
        password: passwd,
        _serverSslCertificate: serverCa,
        _clientSslCertificate: clientCert,
        _clientSslKey: clientKey
      }
      Logger.log(connectionInfo);
    
      var connection = Jdbc.getConnection(addr, connectionInfo);
      Logger.log(connection.getCatalog());
    
      // コネクションを閉じる
      connection.close();
      Logger.log('end');
    }

  • OpenSSLでCSRを発行したときに”.rnd”が開けないというエラーが出た

    OpenSSLでCSRを発行したときに”.rnd”が開けないというエラーが出た。エラーは出たが、CSRファイル自体は出力できた。

    Can't load /root/.rnd into RNG
    140466838241728:error:2406F079:random number generator:RAND_load_file:Cannot open file:../crypto/rand/randfile.c:88:Filename=/root/.rnd

    毎回エラーがでると、ドキッとするので、エラーが出ないようにした。

    `/etc/ssl/openssl.cnf `を開いて、下記の行をコメントアウトした。

    RANDFILE                = $ENV::HOME/.rnd

    これでコマンドを実行してもエラーが表示されなくなった。