Windowsはメモリが不足するとファイルのコピーに失敗する。そしてロールバックして、途中までのものも消える。
遅いネットワークで、別のサーバからのデータのコピーで、単一の大きなファイルだったので、時間がかかって、結果的にメモリが足りなくなって、失敗した。メモリも増えているので、レアケースになっているのかもしれないけれど。やはりメモリの空きは重要だ。
Windowsはメモリが不足するとファイルのコピーに失敗する。そしてロールバックして、途中までのものも消える。
遅いネットワークで、別のサーバからのデータのコピーで、単一の大きなファイルだったので、時間がかかって、結果的にメモリが足りなくなって、失敗した。メモリも増えているので、レアケースになっているのかもしれないけれど。やはりメモリの空きは重要だ。
イベントログに記録されていたログは下記。
イベント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 Management Studioを使っている場合は、該当のプロシージャーを選択して、プロパティを開いて、権限の部分で、ユーザやロールを指定して、権限を付与する。
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
注意としては、照合順を厳密に指定しておく必要がある場合には、指定が変わってしまう。その場合は、検索で一致させるものを変更するなどの対応が必要。
LTSの .NET Core 3.1が2022年12月3日に延長サポートが終了する。オンプレミスの環境ならば、自己責任で使い続けられるのだが、Azure上だとどうなるのかが気になり調べていた。それでやっと見つけたのが、下記の記事だ。
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への移行が推奨されている。
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 を仮想マシンに変換しようとしたところ、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のOauth2.0を連携させたときの注意点として、Oauthでの認証時にGoogle Cloudで設定したOauth2.0クライアント名が表示されてしまう。
これは、Google Cloud側の設定には、「OAuth 2.0 クライアントの名前。この名前はコンソールでクライアントを識別するためにのみ使用され、エンドユーザーには表示されません。」とあったところだ。

そのため、気軽に「何とか-test」で名前をつけて、設定したり、テストしていたのだが、Oauth2-Proxyからアクセスしたときの画面に、この「クライアントの名前」が表示されていた。
これを修正するには、
最初に、「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';
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');
}