memo.

カテゴリー: 技術系

  • Web.configでASP.NETのPOSTサイズを設定する

    ASP.NETのアプリには、デフォルトの場合、POSTできるサイズが4MBに制限されている。POSTの制限なので、ファイルのアップロードをPOSTで行う場合も、このデフォルトの4MBの制限にかかる。（なお、IISのデフォルトは30MB）

    大きなファイルをアップロードするためには、Web.configに次の設定を行う。

    system.webセクションに、`<httpRuntime maxRequestLength=”サイズ指定” />` を追加し、サイズを指定する。単位はKbyteなので注意。

    system.webServerセクションに、` <requestLimits maxAllowedContentLength=”サイズ指定”/>` を追加し、サイズを指定する。単位はByteなので注意。

    今回指定しているのは、POSTなどでリクエストされるサイズなので、厳密のはアップロードされるファイルのサイズではない。他にも情報を送る場合には、MAXのファイルサイズ＋送信データ量にする必要があるので注意。厳密に指定しなくてもよければ、大き目のサイズを指定しておくのがよい。

    web.configの設定例）

      <system.web> 
    <httpRuntime maxRequestLength="20480" /><!--20MB 単位はKbyte--> 
  </system.web> 
  <system.webServer> 
    <security> 
      <requestFiltering> 
        <requestLimits maxAllowedContentLength="20971520"/><!--20MB 単位はByte--> 
      </requestFiltering> 
    </security> 
  </system.webServer>

    参考：

    https://zukucode.com/2018/06/aspnet-upload-size.html

    ※参考にしたところは、微妙にWeb.configの設定ミスがあるので注意。

  • dotNET6のアプリがIIS上だと原因不明の500エラーになる

    .NET6のアプリをIISにデプロイしたが、500エラーで動作せず。コンパイル自体はエラーになっていなかったが、IIS上にデプロイして、実行するとエラーになった。

    いろいろと調べていくと、「アプリケーションの発行」の設定の「Entity Frameworkの移行」のところにバツマークがついていた。内容は、「dotnet tool restore」だ。これが影響しており、正常にアプリケーションの発行ができていなかった。

    対処として、ソリューションのクリーンとリビルドを行ったが、改善せず。

    表示されていたパスにある「dotnet-tools.json」を別のファイル名にリネームして、再度発行を試したところ、正常に発行ができて、IIS上でも動作した。「dotnet-tools.json」のファイルの更新で問題があったことが原因だった。

  • Powershellでプロレスのスレッド数をカウントするコマンド

    Powershellでコマンドレットを組み合わせて、Windows上で実行されているスレッドの数を確認する。

    Get-Process だけを実行すると、プロセス名がわかるので、そのプロセス名で絞り込むこともできる。

    例） Windows上で動作しているスレッド数をカウントするコマンドレット

    (Get-Process|Select-Object -ExpandProperty Threads).Count

    例） Windows上で動作しているプロセスのJavaで起動されているスレッド数をカウントするコマンドレット

    (Get-Process Java |Select-Object -ExpandProperty Threads).Count

    例） Windows上で動作しているプロセスのTomcatで起動されているスレッド数をカウントするコマンドレット

    (Get-Process Tomcat9 |Select-Object -ExpandProperty Threads).Count

    おまけ：例）プロセスの数をカウントするコマンドレット

    (Get-Process).count

  • Veeam Backup ver.11aでWindows Server 2003上のSQL Serverのバックアップ指定でエラーになる

    Veeam Backup Ver.11a で、ESXi上の仮想マシンのバックアップを取るとき、Windows Server 2003（Windows Server 2003 R2）の仮想マシンで、SQL ServerやOracle Databaseのバックアップを行うオプションを指定している場合、Ver.11aではWindows Server 2003（2003 R2）は、サポート対象外になっているため失敗する。

    Veeam Backupで表示されていたエラーは下記。

    Failed to prepare guest for hot backup. Error: Unable to perform application-aware processing: Microsoft Windows Server 2003 (Standard) guest OS is not supported 
Error: Unable to perform application-aware processing: Microsoft Windows Server 2003 (Standard) guest OS is not supported

    Veeam Backup Ver.11aは、仮想マシンとしてはESXiで動作しているものはバックアップが正常に取得できる。Ver.11aでWindows Server 2003などのVeeam Backup 対象外のOSは、バックアップ設定で、「Enable application-aware processing」や「Enable guest file system indexing」のチェックを外し、設定を無効化することで、仮想マシンのイメージとしてのみ、バックアップがされるようになる。これでエラーは発生しない。

    仮想マシンのバックアップだが、バックアップの指定方法によっては、バックアップの対象外になるため、注意が必要。

  • Ubuntu Server を18.04から22.04までアップグレードしてみた。

    無料版のUbuntu Server 18.04のサポートが4月ごろに終わる可能性があるので、Ubuntu Server 20.04、Ubuntu Server 22.04 にアップグレードを試した。

    do-release-upgrade を実行して、ダイアログで聞かれる内容に答えていくことで、OSバージョンのアップグレードはできた。

    アップデートは、SSHからでもできるが、途中で再起動が入ることから、別ポートでSSHが立ち上がり、そこが非常用のアクセスで使われる。推奨は、されていないようなので、コンソールからやるのがよい。

    アップグレード中は、途中でダイアログでいろいろと聞かれる。それを答えていくことで、アップグレードされる。インストールされているパッケージも新しくなっていく。バージョン固定のパッケージのコマンドを使っていると、アップグレード後はエラーになるので、注意は必要。

    do-release-upgrade は、単純実行で１つ新しいLTSバージョンにしてくれる。18.04からは20.04になるので、22.04にするには、20.04にしてから、もう一度、実行すると、22.04にできた。

  • Visual Studio 2022でデバック実行したら”CreateHostBuilder(args).Build().Run();”でエラーが出た。

    Visual Studio 2022でデバック実行したら”CreateHostBuilder(args).Build().Run();”でエラーになった。もともと、動作していた環境なのだが、久しぶりに起動させたところ、デバック実行で起動できなくなっていた。環境は、Visual Studio 2022、.NET6。

    ■エラーになった個所：Program.CS

    CreateHostBuilder(args).Build().Run();

    ■表示されたエラーやログ

    'xxxxxxxxx.exe' (CoreCLR: clrhost): 'C:\Program Files\dotnet\shared\Microsoft.NETCore.App\6.0.13\System.Security.Cryptography.Csp.dll' が読み込まれました。シンボルの読み込みをスキップしました。モジュールは最適化されていて、デバッグ オプションの [マイ コードのみ] 設定が有効になっています。
例外がスローされました: 'System.InvalidOperationException' (System.Private.CoreLib.dll の中)
型 'System.InvalidOperationException' のハンドルされていない例外が System.Private.CoreLib.dll で発生しました
Unable to configure HTTPS endpoint. No server certificate was specified, and the default developer certificate could not be found or is out of date.
To generate a developer certificate run 'dotnet dev-certs https'. To trust the certificate (Windows and macOS only) run 'dotnet dev-certs https --trust'.
For more information on configuring HTTPS see https://go.microsoft.com/fwlink/?linkid=848054.

    いろいろと試した結果・・・

    次のコマンド（２つ）を、Visual Studio 2022 とは別にPowershellを開いて、実行した。そのあと、Visual Studioでデバック実行して正常にウェブアプリが起動することが確認できた。

    dotnet dev-certs https --clean
dotnet dev-certs https --trust

    “dotnet dev-certs https –trust”のみの実行だと、変らなくて、Cleanのオプションで使っていない証明書をきれいにすることで解消した。ここがわかるまで、結構時間を使ってしまった。

  • クラウドの障害は忘れかけたころにやってくる

    今日の夕方くらいから、Microsoft Azureで大規模な障害が発生した。原因は、AzureのWANの設定変更によるものだそうだ。詳細は、今後、ニュースサイトで掲載されるであろう。

    設定変更の確認を行っていないわけじゃないのだろうけど、巨大なパブリッククラウドのネットワークなので確認しきれなかった、ということなのだろう。ネットワーク系の障害はAWSもやっているし、そのほかのクラウドサービスもやっている。それにしても、Azureの上とそのネットワークでつながっているMicrosoft365系のサービスも一緒に止まったわけで、なかなか大きい障害だった。まぁ、復旧するまで見ているしかないわけだが。

    忘れたころに発生するというよりも、忘れそうになる前に、どこかしらの大手のパブリッククラウドがやらかしている気がする。結局、コントロールしようと思うと、オンプレで環境をもっておくのがいいというわけだ。経済的かどうかは、規模や体制にもよるけれど。

  • BCDMのBCAgentが暴走する

    MDMのBCDMのBCAgentが、ポリシー通りに設定しているのにかかわらず、設定を促す警告がずっと出てスマートフォンの操作ができなくなる。

    いろいろと試したところ、BCAgentのバージョンと、Android OSのバージョンと、開発ツールのバージョンの絡みで、ポリシー通りに設定されているのかを誤認しているようだ。BCAgentからポリシー設定の通知が出る場合は、次のことを試す。

    • スマートフォンを再起動する。
    • Androidのアップデートと、アプリケーションのアップデートを行う。

    今のところ、アップデートを行い、最新化することで、BCAgentの設定通知が落ち着くことが多い。

  • さくらのレンタルサーバのWordPress管理画面にアクセスすると403エラーがでる

    さくらインターネットのレンタルサーバに、Wordpressを入れたのだが、海外（ベトナム）から、Wordpressの管理画面にアクセスすると、Nginxが403エラーを返す。

    さくらインターネットのウェブサーバは、「Apache/2.4.54」と表示されているので、なぜNginxが403エラーを返すのが不思議で、いろいろと調べた。疑ったのは、どこか別のサーバにアクセスさせられているのではないかと（DNSサーバの汚染を心配していた）。

    Tracerouteや名前解決などを行っていった結果、正常にさくらインターネットのサーバにアクセスしようとしていることはわかった。管理画面は表示されなくても、通常のWordpressのコンテンツは正常に表示されていた。さくらインターネットのレンタルサーバの管理画面に、「国外IPアドレスフィルタ」の設定があり、これがデフォルトでオンになっていた。これが403エラーを返す原因だった。「国外IPアドレスフィルタ」の設定を無効にするか、許可アドレスリストに加えることで、海外からでもWordpressの管理画面にアクセスできるようになった。

    IPアドレスでのアクセスフィルタリングのために、Nginxによるリバースプロキシ的なものがかまされているようだ。

  • Veeam BackupをVer.9.5からVer.11aにアップグレードする

    Veeam Backup を、「Version 9.5.4.2866」から「Version 11a（Build 11.0.1.1261）」にアップグレードしたので、メモ。

    Ver.9.5.4から、Ver.11aへのアップグレードは、インストーラーで一気にアップグレードできる。

    ↓　Veeam Backupのサポートページ
    https://helpcenter.veeam.com/jp/docs/backup/vsphere/upgrade_vbr.html?ver=110

    サポートサイトから、Ver.11aのインストーラーをダウンロードして実行した。実行したところ、下記のエラーが発生し、インストールができない。

    Setup cannot be launched, as the computer is waiting for restart.

    エラーによると、サーバが再起動待ち状態のためセットアップの開始ができない、とのこと。OSを再起動して、再度、インストーラーを実行すると、ウィザードが正常に起動した。

    インストールのときに、足りないコンポーネント（.net framework 4.7とか、.NET Core Runtime 3.1.16とか）は、インストールを自動的に行ってくれる。ウィザードに沿って、進めていけば、問題なくVer.11aにアップグレードはできた。

    なお、物理サーバのバックアップで、Veeam Backup AgentがVer.3系の場合は、バックアップ取得時にエラーが発生する。そのため、Veeam Backup Agentは、最新のVer.5系にアップグレードする。