カテゴリー: 技術系

Windows10の21H1はデフォルトでWSL2になっている。

Windows10 21H1で、WSLをインストールすると、最初から規定のバージョンが2になっている（デフォルトでWSL2になっている）。

設定を変えなくても、WSL2の機能を使えるので楽。

2021年9月2日
分散仮想スイッチはvCenter Serverに設定されるリソース

分散仮想スイッチは、vCenter Serverに設定されるリソース。そのため、vCenter Serverをリプレイスするときに、前の設定を引きつながない場合には、再設定が必要になる。

分散仮想スイッチは、ESXiのホストやクラスタの設定ではないので、注意が必要。忘れるのでメモ。

2021年8月22日
SQL Serverの名前付きインスタンスはUDP 1434を使用する
SQL Serverへの接続に使用するポートは、通常、TCPの1433番ポート。デフォルトでインストールしたSQL Server（既定のインスタンス）しかなければ、これで接続できる。名前付きで、SQL Serverをインストールした場合は、SQL Server Browerサービスを使用することにより、1434番ポートで、UDPを使用する。

SQL Serverでポート番号を調べると、1433と1434が出てくるのだが、これをTCPだけで設定してしまうと、SQL Server Browerサービスを介した名前解決でエラーになる。エラー時には、エラー番号の26なので、SQL Server Browerサービスの起動を確認するのだが、これが起動されている場合には、UDPの1434番ポートが通信可能になっているかを通信経路上（SQL Serverのサーバと、経路のネットワークと、クライアント）で確認する。
```
Provider: SQL Network Interface, error: 26
```
さらに注意事項として、名前付きインスタンスが動的ポートで構成されるようになっている場合（デフォルトだと動的ポート）、1433番ポートを使用して、SQL Serverが起動していない。名前付きインスタンスの１つしかインストールされていない場合には、起動ポートを1433に固定することで、他のポートは空けなくてもよい。

参考：　https://docs.microsoft.com/ja-jp/troubleshoot/sql/connect/resolving-connectivity-errors
2021年8月22日
Cisco ASAシリーズで、アクティブなNAT件数を調べるコマンド
CiscoのASAシリーズで、現在のNATしている件数を調べるためのコマンド。コマンドは、Enableモードで。
```
show xlate count
```
NATだけでなく、セッション数（コネクション数）を調べる場合は、下記のコマンド。
```
show conn count
```
HTTP/3（QUIC）が使われ始めて、UDPのNATの数が増えた。ゲートウェイに使っている機器の負担もかなり増えている。HTTP/3って便利と思っていたけれど、こんなところに落とし穴があった。

UDPだから、終了がわからず、タイムアウトするまでファイアウォール上では、NATテーブル上に残りつづけるわけで、通信数が増えれば、その分使い終わったNATのセッションがゴミっぽく残って、リソースを使い果たすと。それを調べるには、コマンドをたたくのだろうな。

実行例
```
ciscoasa# show conn count
594 in use, 3455 most used
ciscoasa# 
ciscoasa# show xlate count 
448 in use, 4416 most used
```
また、NATテーブルの使用数のピークを知りたい場合には、下記のコマンドでリソースを調べる。
```
show resource usage
```
このコマンドの実行結果の「Xlates」の「Peak」が過去の最大値だ。

実行例
```
ciscoasa# show resource usage 
Resource                 Current        Peak      Limit        Denied Context 
Telnet                         1           1          5             0 System 
SSH Server                     0           1          5             0 System 
ASDM                           0           1         30             0 System 
Syslogs [rate]                17       13933        N/A             0 System 
Conns                        728        3455     100000             0 System 
Xlates                       564        4416        N/A             0 System 
Hosts                        299         787        N/A             0 System 
Conns [rate]                   8         536        N/A             0 System 
Inspects [rate]                2         535        N/A             0 System 
Routes                        58          91  unlimited             0 System 
ciscoasa#
```
2021年8月21日
IISで .NET5のアプリケーションが動作するように設定する

Windows Server 2019のIISで .NET5 （ASP.NET core）のアプリケーションが動作するように設定したので、そのメモ。

設定手順

1. 下記の .NETのダウンロードページにアクセスする。
https://dotnet.microsoft.com/do wnload/dotnet

2. 「.NET 5.0」のリンクをクリックする。

3. 「ASP.NET Core Runtime 5.0.x」のWindowsの「Hosting Bundle」をクリックする。インストーラーのダウンロードが始まる。「Hosting Bundle」には、IISのサポートが含まれるので、IISで動作させる場合には、これを選択する必要がある。

4. ダウンロードしたファイル（dotnet-hosting-5.0.9-win.exe）を実行して、インストールする。

5. IISのサービスを再起動する（Windowsなので、OSごと再起動できるのならば、OS再起動の方が安全）。

6. IISマネージャーを開く

7. アプリケーションプールを開いて、「アプリケーションプールの追加」をクリックする。

8. 「名前」はわかりやすければ、なんでもよい。「.Net CLR バージョン」は「マネージドコードなし」を選択。「マネージドパイプラインモード」は「統合」を選択する。「OK」をクリックして作成する。

9. ASP.NET coreのアプリを発行し、サーバ上に配置する。

10. IISマネージャーで、サイトからアプリケーションを追加するWebサイトを選択する。（Webサイトがない場合は追加する）

11. 右クリックから「アプリケーションの追加」を選択する。

12. 「エイリアス」を入力し、「物理パス」に発行したアプリケーションのフォルダを選択する。「アプリケーションプール」のところにある「選択」をクリックし、一覧の中から追加したアプリケーションプールの名前を選択する。

13. 「OK」をクリックして、追加する。

14. ブラウザでアクセスして、動作を確認する。

以上で設定は終わり。

2021年8月21日
vRealize Operations 8.5 のサイジングガイドライン

vROpsのサイジングのガイドライン。ガイドラインでの大きな指針は、CPU数とメモリサイズ。これが監視対象となるホストの数とゲストの数から、サイジングされる。データを保管するHDDサイズについては載っていない。HDDというかVMDKは追加できるから、ということだろう。

vRealize Operations 8.5 Sizing Guidelines (85062) (vmware.com)
https://kb.vmware.com/s/article/85062

2021年8月17日

Nginx上のPHPのページにアクセスすると「File not found.」と表示される

NginxにPHPを動作させるための設定をいれたのだが、アクセスすると、「File not found.」と表示されて、PHPの処理がされない。Nginxのエラーログを見てみると、下記の表示があった。

FastCGI sent in stderr: "Primary script unknown" while reading response header from upstream,

Nginxの「/etc/nginx/sites-available/default」のPHPに関連する設定は、下記のように設定していた。

     # pass PHP scripts to FastCGI server 
        # 
        location ~ \.php$ { 
                    include snippets/fastcgi-php.conf; 
        # 
        #       # With php-fpm (or other unix sockets): 
                fastcgi_pass unix:/var/run/php/php7.4-fpm.sock; 
        #       # With php-cgi (or other tcp sockets): 
        #       fastcgi_pass 127.0.0.1:9000; 
                fastcgi_param  SCRIPT_FILENAME  $document_root$fastcgi_script_name; 
        }

上記を、次のように修正したところ、正常にPHPの処理が行われた。

     # pass PHP scripts to FastCGI server 
        # 
        location ~ \.php$ { 
                 root     /var/www/html; 
                 include snippets/fastcgi-php.conf; 
        # 
        #       # With php-fpm (or other unix sockets): 
                fastcgi_pass unix:/var/run/php/php7.4-fpm.sock; 
        #       # With php-cgi (or other tcp sockets): 
        #       fastcgi_pass 127.0.0.1:9000; 
                fastcgi_param  SCRIPT_FILENAME  $document_root$fastcgi_script_name; 
                include fastcgi_params; 
        }

そもそものエラーが、ファイルの場所がわからないということなので、「root path」でドキュメントルートを指定したことにより、正常に処理ができるようになった。Nginxの設定は、何回やっても難解でどこからしらで躓く。

2021年8月17日

Nginxでファイルアップロードで「413 Request Entity Too Large」が表示される
Nginx上で、Wordpressを動作させるために、PHP-FPMやMariaDBを設定して「動作した」と思ったら、アップロードで、下記のエラーが表示された。
```
413 Request Entity Too Large
```
アップロードしたファイルは1MBちょっとのファイルなのだが。これを調べていくと、PHP側のアップロードサイズとポストサイズは問題なかった。Nginx側は、サイズ指定されていないようなので、デフォルトのサイズだった。このNginxのデフォルトサイズが問題で、デフォルトだと、1mしかない。これが原因なので、Nginxのパラメータを書き換える。

https://nginx.org/en/docs/http/ngx_http_core_module.html#client_max_body_size

`/etc/nginx/sites-available/default` を編集し、「server {}」のところに、「client_max_body_size 30m;」を追加し、最大サイズを30mにした。
```
# Default server configuration 
# 
server { 
        #listen 80 default_server; 
        #listen [::]:80 default_server; 
        listen 443 ssl default_server; 
        listen [::]:443 ssl default_server; 
        #listen 443 ssl; 
        ssl_certificate /etc/nginx/conf.d/server.crt; 
        ssl_certificate_key /etc/nginx/conf.d/server.key; 
        client_max_body_size 30m;
```
あとは、Nginxを再起動するか、Nginxでコンフィグをリロードする。

`sudo service nginx reload` でコンフィグのリロードか、` sudo service nginx restart` で再起動する。これでエラーがでなければOK。
2021年8月15日
リバースプロキシを使ったWordPressのアクセスでハマる
リバースプロキシの後ろにWordpressをおいて、リバースプロキシ経由でアクセスさせようとしたところ、ハマった。いろいろと試しているが、現在進行系で格闘中だ。

事象としては、
- インストール時に、Wordpressのホスト名が「127.0.0.1:8080」で登録されてしまい、ログインしようとすると、127.0.0.1にアクセスしようとしてしまい、アクセスできず。
- 上記の問題は、DBを直接書き換えることで対処するが、トップページにアクセスすると、「127.0.0.1」にリダイレクトされる。
- WordPressのCSSの一部と、画像が表示されない
という具合だ。前がNginxで、後ろがApache2.4。WordpressをCDNで配信するときの設定も試したが、うまく行かず。たぶん、根本的に何かが欠けていると思われる。簡単と思っていたけれど、思わぬところでハマるものだ。最初から考え直し。
2021年8月15日
インストールされているMariaDBが64ビットかどうかを確認する
64bitでインストールされているはずだが、念のため、MariaDBが64bitでインストールされているかどうかを調べる方法について。DBに接続した状態で、下記のコマンドを実施する。MySQLでも同じように調べることができる。
```
show variables like 'version_compile_machine';
```
これの結果が、「X86_64」になっていれば、64bitでインストールされている。「i386」や「i686」の場合は、32bitでインストールされている。
```
MariaDB [(none)]> show variables like 'version_compile_machine';
+-------------------------+--------+
| Variable_name           | Value  |
+-------------------------+--------+
| version_compile_machine | x86_64 |
+-------------------------+--------+
1 row in set (0.001 sec)
MariaDB [(none)]>
```
2021年8月9日