地獄の事件

ロス・グラシアレス国立公園、アルゼンチン

地獄の事件でした。新しい記事が更新できない事件が起きました。WindowesのAIに聞いても改善されません、当日、新しく移行したプロバーダーに事情を伝えようと何べんも電話をかけまくりましたが、繋がりません。そしてある光の接続に詳しいところの電話で、Docomoショップから事務所の電話をかけてもらったらと提言を頂きDocomoショップに駆け込み、しばらくの間電話がつながるのを待ちました。そうですね30分後くらいしたら繋がりました。そこで聞いたのは標準のアプリを送りました、との発言でした。それはIPV6専用のアプリでした。これはIPV4でしか動かない私のサーバーが壊されたと感じました。早速そのアプリを削除できないかとお願いしましたら、削除できるということだったので早速お願いしました。15分から30分かかるということで家に戻りました。そして、光に繋げているモデムのPPPのランプが点灯しており、中の設定をみたら、事件前の設定に戻っていました。しかし記事の更新はまだできませんでした。追加でグローバルIPを更新し、それで、ようやく記事の更新が出来ました。これでブログ更新の連続記録録が途絶えることなく継続できました。朝夜中の2時からはじまり、修復は午後2時頃でしたから約12時間かかりました。

カテゴリー: その他 | コメントする

今朝の散歩


お早うございます。かぜはつめたかったですが、久しぶりに8時過ぎに散歩に行きました。白い浅間山がはっきり見えました。ヘリが轟音をたてて飛び立っていきました。利根川の水量はいつもの様に少ないままでした。歩いていると利根川の流れる音がごおーっと聞こえてきました。

カテゴリー: | コメントする

第4世代 AMD EPYC 9334 32-Core Processor 64Threads 384GB GT1030 ADATA SX8200PNP 256GBで構成されたUbuntu 22.04.5 LTS へ CUDA-toolkit 12.8.0をInstall してnvidia-smi nvcc -V cat /etc/os-release lsmem sensors nvme list nvme smart-log /dev/nvme0n1 lscpuを設定してみた


desktop

nvidia-smi nvcc -V cat /etc/os-release lemem 384GB

sensors nvme list nvme smart-log /dev/nvme0n1

lscpu AMD EPYC 9334 32-Core Processor 64Threads

カテゴリー: nvidia, ubuntu | コメントする

第4世代 AMD EPYC 9654P 96-Core Processor 192Threads 384GB RTX2080Ti EDILOCA EN605 256GB で構成された Ubuntu 22.04.5 LTS へ CUDA-toolkit 12.9.0をInstall して nvidia-smi nvcc -V cat /etc/os-release sensors lsmem nvme list nvme-smart-log /dev/nvme0n1 lscpuを設定してみた


BIOS
[chibi@rhel10 ~]$ sudo dmidecode -q
[sudo] chibi のパスワード:
BIOS Information
Vendor: GIGABYTE
Version: R19_F40
Release Date: 05/12/2025
Address: 0xF0000
Runtime Size: 64 kB
ROM Size: 16 MB
Characteristics:
desktop

nvidia-smi nvcc -V cat /etc/os-release

sensors lsmem 384GB

nvme list nvme-smart-log /dev/nvme0n1

lscpu AMD EPYC 9654P 96-Core Processor 192Threads

カテゴリー: nvidia, ubuntu | コメントする

新しいプロバイダに合わせたメール設定の苦労話

サーバーの移行やネットワーク環境の変更に伴い、
新しいプロバイダに応じたメール設定を一から見直すことになりました。
単純な差し替えで済むと思っていたものの、実際には細かな落とし穴がいくつもあり、
静かに、しかし確実に時間を奪われる作業となりました。
■ 1. プロバイダ固有の SMTP 制限に気づくまで
最初の壁は、プロバイダごとに異なる SMTP の仕様でした。
ポート番号、認証方式、暗号化方式、送信制限など、
“前の環境では当然のように動いていたもの” が、
新しい環境ではそのままでは通りません。
特に、認証方式の違いとポートの制限は見落としやすく、
設定が正しいのにメールが届かないという状態が続きました。
■ 2. ログを追っても原因が見えない時間
Postfix や Dovecot のログを追っても、
「拒否された」「接続できない」といった抽象的なメッセージばかりで、
根本原因にたどり着くまでに時間がかかりました。
最終的には、プロバイダ側の仕様書を細かく読み直し、
“前提が変わっている” ことに気づいてようやく突破口が開けました。
■ 3. 認証コードが届かない問題
Amazon の認証コードが届かないという現象も発生し、
メールサーバー側の問題か、プロバイダ側のフィルタか、
原因の切り分けに静かな根気が必要でした。
最終的には、SMTP の設定をプロバイダ仕様に合わせて調整し直すことで、
認証メールが正常に届くようになりました。
■ 4. Tripwire での確認と安堵
設定変更後、Tripwire の Integrity Check で
ログの追加・変更が正常に記録されていることを確認し、
不審な動きがないことに安堵しました。
メールが「帝國の三時」に無事届いた瞬間、
ようやく一連の作業が静かに終わったことを実感しました。
■ 5. 今回の教訓
• プロバイダが変わると、メールの前提条件もすべて変わる
• 仕様書を丁寧に読み直すことが最短ルート
• ログはヒントをくれるが、答えはくれない
• 最後は小さな成功(認証メールの到着)が確かな確認になる

カテゴリー: その他 | コメントする