今やAIで何でも調べてくれるが、言われたこと、起きたことの事象を鵜呑みにすると、間違った方法に進む。やはり人間のジャッジが必要。だいたいAIの言うことも60％くらいしか合っていないじゃないかと思う。なので、AIに聞いた時は、ロジックは何度でも聞くし、理解から出たロジックをぶつけることも必要。場合によっては、手を動かすことも。
ただ、あまり聞くと、それベースで答えが出てくることも。今、AIは、Pentium ProのP6バスのキャッシュ、MESIプロトコルが引き起こす問題、俗に言うP6バス化を例えにして答えてくれる。オブジェクトストレージがまさしく、Pentium Proで起きていた問題と同じ問題が起きるようで。今のCPUは、SMPではなく、NUMAだから起きない。（なんか死語が多いなw）
閑話休題
QNAPの証明書、神機能を前回書いたが、実は続きがあった。
コントロールパネルで入れた証明書は、Web UIでは使えるがQuObjectsだと使えない。
答えは単純で、コントロールパネルで、Certification, Private key, intermediate certificationを入れても、stunnel.pemには、intermediate certificationを含んでくれない。なぜちゃんと動くのか？QNAPのOS自体は他で補完できるし、ブラウザ側もそこらへんは上手くやってくれる。
ではなぜ、QuObjectsでひっかかるの？それは独立したアプリケーションだから。というわけで、QuObjectsをhttps通信させるには、コマンドラインでstunnel.pemを作る必要がある。
Lets Encryptでは、以下のファイルができる。
cert1.pem. : Certification
chain1.pem : Intermediate certification
fullchain1.pem : full chain certification
privkey1.pem : Private key
QuObjectsで動くstunnel.pemを作るには
cat fullchain.pem privkey.pem > stunnel.pem
できたファイルを以下におく
/etc/stunnel/stunnel.pem
その後
/etc/init.d/stunnel.sh restart
なんで気が付いたのかというと、証明書を入れても、minioのmcコマンドがチェーンを確認できないとエラーを言うし、opensslコマンドでチェーンの確認をすると、チェーンの中身がないと言ってくる。コントロールパネルで確かに入れているのだが。。。同じUIにあるが、stunnel.pemを作るための入力ではないと見た。もはやアンドキュメンテッドな世界。
解決方法を見つけたのも、実は、TS-464ではcertbotで定期的に持っている全ドメインの証明書を吐き出していて、それで作られた証明書をTS-464のstunnel.pemにしている。比較してみたら、見事、コントロールパネルで入力した証明書は、中間だけに中間証明書がスッぽぬていた。想像の通り、Lets Encrypt特有の問題ではなく、商用の証明書でも起きる。
なので、証明書の作成は、コントロールパネルではなく、コマンドラインで持っていたほうがいい。もちろん、このstunnel.pemは、QuObjectsだけでなく、Web UIでもちゃんと使ってくれる。