memo.

カテゴリー: 技術系memo

  • AWSの教訓

    Amazon SES（Amazon Simple Email Service）で、サンドボックス環境から本番環境へのリクエストが却下されまくる、という状況になった。

    SESの本番化で、これの問い合わせ上限になり、どうにもならなくなり、問い合わせレベルをDeveloper（有料化）にしたら、さくっと、SESがサンドボックスから本番になった。

    そもそもAmazon SESの申請内容じゃなくて、サポートレベルから判断しているのではないかという疑念がうまれた。どちらにしても、いい教訓になった。

  • メモ：Amazon WorkmailのSMTPにメール送信するときの送り先

    Amazon Workmailのアカウントを使って、別のメールクライアントやスクリプトからメール送信したい。そのときの送信先のSMTPサーバの情報と、参照URLのメモ。

    • SMTPサーバー（エンドポイント）：　smtp..amazonaws.com
    • 例：東京リージョン（ap-northeast-1）の場合　smtp.ap-northeast-1.amazonaws.com
    • ポート：　465（TLS/SSL専用、STARTTLSは非対応）
    • 認証：　WorkMailユーザーのメールアドレスとパスワードを使用

    参考URL https://repost.aws/knowledge-center/workmail-on-premises-multifunction

  • MicrosoftよりPowershell 2.0の具体的な廃止のスケジュールが発表された

    Microsoftより、Powershell 2.0の具体的な廃止のスケジュールが発表された。これによると、2025年8月（今月）～9月（来月）には、Windows11 24H2から削除されるという。

    「PowerShell 2.0」は間もなく削除、今月～来月の更新で ～Windows 11 バージョン 24H2/Server 2025で
    https://forest.watch.impress.co.jp/docs/news/2039392.html

    基本的に、Powershell 5.1がWindows11 24H2にあるので、Powershellがなくなるということはない。けれど、Powershell2.0で明示的に動かしている場合や廃止されているコマンドレットを使っていると動かなくなる。

    Powershellを別のバージョンに移行するとして、候補がPowershell 5.1（Windows Powershell 5.1）か、Powershell 7系だ。２つの違いは、Windows Powershell 5.1が.NET Framework 4.8で動作、Powershell 7系が、.NET（.NET core）で動作、ベースになる環境が異なる。この先を考えるならば、Powershell 7系がいいのだろうけれど、ベースになる.NETはLTSで3年のサポートなので、LTSがリリースされる2年ごとにバージョンを上げていくことになる。互換性はあるから大丈夫なんだろうけれど、ベースの.NETの入れ替えは必要になる。

    Windows PowerShell 5.1 と PowerShell 7.x の相違点
    https://learn.microsoft.com/ja-jp/powershell/scripting/whats-new/differences-from-windows-powershell?view=powershell-7.5

    なんとも悩ましい。割り切って、Powershell 7系に乗り換えて、定期的にアップグレードしていくのがいいのだろうけれど。

  • そろそろPowerShell 2.0が削除されそう

    マイクロソフトが改めて、「Windows PowerShell 2.0」は非推奨であり、将来的に削除すると宣言している。改めて、ということは、本格的に削除する計画の段階にあるとみてよさそうだ。

    「Windows PowerShell 2.0」は非推奨、将来的に削除 ～Microsoftが改めて注意喚起

    https://forest.watch.impress.co.jp/docs/news/2026721.html

    影響は？ということで、ちょっと見てみたが、Windows Server 2019も2022も、PowerShell5系になっている。普通に使う分には、PowerShell5なので問題はなさそうだが、2.0系にしかないコマンドレットを使ってると使えなくなる、ということかな。

    それと、2008R2や2012については、PowerShell2系だが、OSのサポートが切れているので、削除されるとは思えない。そうすると影響は少ないのもかもしれない。

  • ウェブサイトで使う文字の基準

    ウェブサイトやウェブシステムに、レアな漢字を使っても大丈夫か、という話になった。どういう基準にする？というところから、なるべくシンプルにルールを考えてみた。

    ・UTF-8で定義されている、かつ使用するフォントセットに含まれている漢字または文字であれば、OK。（漢字は第2水準まで）

    ・環境依存文字として、Windowsまたは他のOSが認識しているのであれば、使用をさける。

    ほかにも制約はあるので完璧ではないが、まぁ、間違いはないはず。長くても、守りようがないので、このくらいがいい。

  • GASからMySQLへのアクセスにボトルネックがある

    GASからMySQL（Google Cloud SQL）へのアクセスにボトルネックがある。アクセス時に遅いので、調べてみると、GASが採用しているV8 Runtimeからの接続が遅いようだ。

    見つけたのは、以下の２つ。

    JDBC results.next iterator slower in V8
    https://issuetracker.google.com/issues/298658393

    Performance issues with JDBC
    https://issuetracker.google.com/issues/236832481

    多少待てるようなシステムであれば、いい。レスポンスが求められるのであれば、GAS自体のボトルネックもあり、DB接続のボトルネックもあり、別のものを考えたほうがいい。

  • TLS1.2で通信できるか確認するPowershell

    Chromeの開発者機能で確認したほうが確実ではあるのだけど、大量にホストがあると、大変なので、Powershellのスクリプトにしてみた。

    以下は、Powershellのスクリプト。

    # TLS 1.2のみを明示的に有効化
[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12

# 通信テスト先
$url = "https://ホスト名"

try {
    $response = Invoke-WebRequest -Uri $url -UseBasicParsing -ErrorAction Stop
    Write-Host "TLS 1.2 で $url に正常に接続できました。"
} catch {
    Write-Host "TLS 1.2 で $url への接続に失敗しました。"
    Write-Host $_.Exception.Message
}

    接続失敗すると、接続失敗したメッセージ、とともにエラーメッセージがでる。

    「[Net.SecurityProtocolType]::Tls12」の部分のTls12をTls11やTls13に変えることで、他のバージョンでのテストもできる。

  • 公式サンプルのソースコードであっても、信じてはいけないという話

    Microsoftの公式サンプルのソースコードであっても、信じてはいけないという話。サンプルコードを使うと、Windowsのメモリ不足を引き起こすかもしれないという。

    Windowsのメモリ不足、公式サンプルコードのコピーだけで発生する可能性 https://news.mynavi.jp/techplus/article/20250526-3333822/

    多くの場合、メモリ不足は無限にメモリを消費するプログラムのバグが原因で引き起こされる。今回の例もプログラムのバグを原因とするが、公式のサンプルコードをコピーしただけで発生するという。

    かなり無理に近いけれど、公式サンプルをコピペして使う場合でも、その設定内容や何を行っているのか、を理解した上（理解しょうとした上）で使わないといけないわけだ。昔は、そういうのを信じるな、と言われたものだが。公式のサンプルコードくらいは信用したかった。今後は、生成AIが生成したコードがそれにあたるのだろう。その場合は、別の複数のＡＩにチェックさせて、合議する感じだろうか。もしくは人でチェックか。どちらにしても、最終的には、採用した（そのコードを使った）人の責任なわけだ。

  • LLM系のクローラーのアクセスがふえている

    数か月分のアクセスログみていたところ、OpenAI（Chat GPT）やAnthropic（Claude）などのLLMを提供している企業のクローラーのアクセスが増えていた。突発的なアクセスの偏りがあるので、原因をみていたら、こいつらによるものだった。

    Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; GPTBot/1.2; +https://openai.com/gptbot)

    や

    Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)

    Chat GPTもClaude（クロード）も、AIを使ったウェブ検索に力をいれている。データ収集のためにクローラーが活動しているみたいだ。GoogleやBingのクローラーは定期的にいるが、急にふえたということはないので、地の利があるのだろう。とはいえ、情報の探し方もかわりつつあるので、この先はどうなるのかはわからない。ググるよりも、LLMにチャットで聞くほうが増えつつあるので。

  • Veeam Backup & Replicationからライセンスを抜いてみる。

    Veeam Backup & Replicationからライセンスを抜くとCommunity Editionになる。

    Community Editionでも、その範囲内であればバックアップを動作させることが可能。