memo.

カテゴリー: 技術系

  • IISで .NET5のアプリケーションが動作するように設定する

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

    設定手順

    1. 下記の .NETのダウンロードページにアクセスする。
    https://dotnet.microsoft.com/download/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. ブラウザでアクセスして、動作を確認する。

    以上で設定は終わり。

  • 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

  • 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の設定は、何回やっても難解でどこからしらで躓く。

  • 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。

  • リバースプロキシを使ったWordPressのアクセスでハマる

    リバースプロキシの後ろにWordpressをおいて、リバースプロキシ経由でアクセスさせようとしたところ、ハマった。いろいろと試しているが、現在進行系で格闘中だ。

    事象としては、

    • インストール時に、Wordpressのホスト名が「127.0.0.1:8080」で登録されてしまい、ログインしようとすると、127.0.0.1にアクセスしようとしてしまい、アクセスできず。
    • 上記の問題は、DBを直接書き換えることで対処するが、トップページにアクセスすると、「127.0.0.1」にリダイレクトされる。
    • WordPressのCSSの一部と、画像が表示されない

    という具合だ。前がNginxで、後ろがApache2.4。WordpressをCDNで配信するときの設定も試したが、うまく行かず。たぶん、根本的に何かが欠けていると思われる。簡単と思っていたけれど、思わぬところでハマるものだ。最初から考え直し。

  • インストールされている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)]>

  • ChromebookとYamahaマイク／スピーカーの接続させた

    Chromebookでも、会議用のマイク・スピーカーでウェブ会議が円滑にできるのか、が気になって、Lenovo Ideapad Duetに、USB Type-Cのハブ経由で、YAMAHAのYVC-200をUSB接続させてみた。

    結果としては、問題なく接続できて、Chromebook上でもマイクとスピーカーとして認識される。イヤホンマイクのように、USB経由のマイクとスピーカーとして認識される。Google MeetやZoomでも使うことができた。YAMAHAのマイク・スピーカーなので、集音性もよく、ミーティングも問題なし。

    このときの次いでとして、Androidのスマートフォンにも同じように接続させてみた。Androidのスマートフォン（京セラ Digno J、Digno BX）でも、同じようにYAMAHA YVC-200はマイクとスピーカーとして認識された。USB Type-Cハブ経由での拡張性は高い。

  • Windows11のプレビュー版でも、AnyConnect 4.2は使えた

    Windows11（21H2）のプレビュー版をいれたので、CiscoのAnyConnectを試してみた。結構、古いバージョンなので、動作しないかも、と思っていたのだが、動作した。

    Windows11のUIに合わせて、ログインのところの見た目が少し変わった程度だった。VPNのコネクションもはれるし、OS内のスキャンもできている。とりあえず、秋になってWindows11へのアップデートが始まっても大丈夫そうだ。これからWindows11の仕様がかわらなければ、だが。

  • Panasonic Let’s Note SV8で20H2と21H1のアップデートが失敗する

    Panasonic Let’s Note SV8でWindows10の大型アップデートの20H2と21H1のアップデートが失敗する問題がある。使っているWindows10のバージョンが1903や1809だと、サポート切れになるため、大型アップデートを適用しないといけないが、これが失敗する。利用しているドライバが原因という可能性が高く、切り分けに時間がかかっていた。このアップデートに失敗する原因がやっとわかった。

    Let’s Note SV8の標準ドライバの「BayHub SDカードドライバー」のバージョンが「1.1.101.1029」の場合にWindows10の大型アップデートに失敗する。（ただし、100％失敗するわけではないのが厄介）

    この「BayHub SDカードドライバー」バージョンを「1.1.101.1033」に上げることで、Windows10を、20H2と21H1にアップデートすることができる。ドライバのダウンロードページは下記。インストール方法も一緒に載っている。

    https://faq.askpc.panasonic.co.jp/faq/docs/005039

    これの厄介なところは、SV8のドライバを検索すると、SV8シリーズの導入済みドライバーのページが最上位に表示されること。このページのドライバーは、「1.1.101.1029」なので、インストールしても意味がなく、最新ドライバーがまとまっているわけでもなく、不親切だ。このページに、大型アップデートに関する注意事項を書いておいてくれればよいのだが。大型アップデートに関するページは別ページになっていてリンクもないので、検索でたどり着くしかないく不便だった。

    デフォルトで導入されているドライバーでWindows10の大型アップデートに問題があると、本当に大変だ。ついでにいうと、他の人に任せていたのだが、なぜこれが発見できなかったのか。初期化状態からのアップデートの検証もやってもらっていたのだが。自分でやったら、わりとすぐに問題を特定できた。情シス系作業は向き不向きがある感じだ。

  • SynologyのActive Backup for Google Workspaceでのバックアップがエラーになっていた

    Google のContacts APIの利用停止によって、SynologyのActive Backup for Google Workspaceでのバックアップがエラーになっていた。「Google APIでアクションが必要」というエラーだけ表示されていた。

    対処方法としては、下記のURLの方法でできたので、よかった。わかりにくいが、手順通りにできたので簡単だった。自分がどの画面にいるのかの把握が一番大事だ。

    https://kb.synology.com/ja-jp/DSM/tutorial/ABG_Invalid_OAuth_scopes

    Google側で変更がある度に、バックアップがエラーになるので、結構、めんどくさい。一部が取れないのでなくて、今回のは全体のバックアップがエラーで取得できていなかったので、大変だった。

    Google のAPIの停止の記事は下記。

    https://developers.google.com/contacts/v3/announcement