Google Bloggerの独自ドメイン利用時のTLS/SSL証明書の発行者が変わっていた

このブログはGoogleのBloggerを使っていて、blog.onodera.asiaという独自ドメインを 設定していて、それに対してHTTPSでのアクセスを有効にしている。 独自ドメインでHTTPSを有効化した際のTLS/SSL証明書は、Turn on HTTPS for your blogに2022-03-20時点で、

Important: If you use CAA Records on your custom domain, add a record for letsencrypt.org, or Blogger won't create or renew your SSL certificate.

と記載のあるように、Let's Encryptの発行する電子証明書を使っていた記憶がある。

しかし、2022-03-20現在ではGoogle Trust Services LLCのGTS CA 1D4という中間CAの発行する3カ月間有効なDomain Validationな 電子証明書に切り替わっている。 Fri, 18 Feb 2022 09:11:14 GMTが開始日になっているので、少なくとも2022-02-18の時点ではLet's Encryptを利用しないように なっていたようだ。

Amazon Fire 7でUSB接続のキーボードとマウスを使う

使おうと思って使えていないWindows 10のインストールされたタブレットPCのために、USB micro-BなOTGケーブルを持っている。 Amazon Fire 7 (第5世代と第9世代)でキーボードでアルファベットを入力できると助かる用途があった。

まず第9世代だが、US配列なMajestouch Convertible 2というキーボードをつないでみると、正常に入力できた。 ついでにマウスも使えるのかとLogicool G304というマウスをつないでみたところ、マウスカーソルが表示され、正常に操作できた。 セルフパワーなUSBハブを使ってキーボードとマウスの両方を同時に使うことも可能だった。

第5世代の方は、Fire 7が供給する電力が不足しているようで、キーボードもマウスも使えなかった。OTGケーブルには給電する端子もあるので、 5V1Aを給電したところ、キーボードもマウスも正常に認識され使用できた。 セルフパワーなUSBハブを使って両方を同時に使うこともできた。

まあ、Androidなので基本的には使えて当然なのだろうが。

Apple Configurator 2

サポート期間が長いという理由でiPhoneを使っているのだが、Androidと違っていろいろ小回りがきかないので面倒で不便で仕方がない。 と言うことで、Androidのスマートフォンも持たざるを得ないのだが、そうなると本末転倒な気もする。 まあ、Androidなスマートフォンは、特定の用途にしか使わないようにして、iPhoneでほとんどの操作はしているのだが。

iPhoneで細かい設定がメニューからはできないので、Apple Configurator 2を使ってプロファイルを作ったら良いのではないかと考えた。 しかし、私の手元にあるMacは、既にサポートの終了したmacOS High Sierra (10.13.6)のインストールされたMac mini Mid 2011しかない。 Mac mini Mid 2011で利用できる最新のmacOSはHigh Sierraである。 これはiPhone 8 Plus、XR、XS、12の写真を安定して取り出すには十分だが、 Apple Configurator 2は新規インストールはできなかった。少なくともmacOS Catalina (10.15)である必要があるとのメッセージが表示された。

3度目のDell XPS 13 9300の修理をしてもらった

前回、訪問修理でファンを修理してもらったが、 また同様にファンが異音を出すようになってしまったため、今回は引取修理をしてもらった。

異音の発生と修理依頼

2022-02-03からファンがまた断続的に異音を発生させるようになってしまった。 音を聞いた感じでは、左側のファンがおかしいようだ。 前回も同様の問題が発生し、修理をする方に自宅に訪問してもらい、ファン2つを交換してもらい、解消していた。 www.dell.comで、購入時に使ったアカウントでログインして、いろいろ見ていたら、電話番号を案内されるルートがあったが、 そこには受付時間帯が記載されていなかった。遅い時間だとは思ったが、 受付時間外であれば、どの時間帯に電話すべきかアナウンスされるだろうと考え、 2022-02-04 23:20ころに電話した。すぐにオペレーターにつながった。 BIOSから自己診断を実施するように言われ、実施するが思ったより時間がかかった。 また、Video FanもProcessor Fanも異常という診断にはならなかった。この時には、異音は発生しなかった。 OSを起動して負荷を掛けてみて、異音が発生するか確認したが、すぐには再現できなかった。 一度電話を切り、15分間程度後にオペレーターから電話をもらうこととして様子を見た。だが、この15分間では異音の発生はなかった。 修理をして欲しい旨を伝えたところ、訪問修理と引き取り修理の2つの選択肢があり、 引き取り修理にして工場に送った方が総合的に診断してもらえるので良さそうと判断した。 他に気になる所があるかという話になり、左右いずれのUSB Type-CコネクターでもUSB-Ethernetアダプターなど USB接続機器が認識されないことがあるので、合わせて見て欲しいと伝えた。 発生頻度については、50%くらいで発生するようなイメージであり、OSは関係なく、BIOSでも認識されていない旨を伝えた。 引き取りは、ヤマト運輸を予定しており、最短で2022-02-08の回収になるとのことであった。 午前中と18:00-21:00を指定できるとのことだったので、18:00-21:00の間に回収してもらうこととした。 渡すのは本体のみで良いとのことだった。 また、内蔵のリチウムイオン電池が良くない状態の場合には、有償での交換になるとのことであった。 有償である場合には、事前に交換して欲しいと指定することはできず、作業前に連絡する必要があるとのことだったので、 電話でも電子メールでも良いので連絡をもらうこととした。

追加問い合わせが来た

2022-02-06 17:10ころに電話があったが取ることができなかった。 電子メールで、同梱のUSB Type-C to Aアダプターを使っていてUSBの問題が発生しているか、 そうであれば、同梱のUSB Type-C to Aアダプターも引き取りたいとの連絡があった。 私は同梱のUSB Type-C to Aアダプターは全く利用していないので、その旨電子メールで返信した。 電子メールで返信があり、本体のみ引き取りするとのことであった。

引取手配の完了

2022-02-07に、2022-02-08の引き取りの手配がされたとの電子メールが来た。

ヤマト運輸による引取の実施

2022-02-08 21:00ころに、ヤマト運輸がPC本体のみを引き取りに来たので引渡した。 伝票番号で到着予定日付を確認すると、2022-02-09到着予定日になっていた。

修理センターへの到着

2022-02-10 11:28に電子メールで、引き取り修理センターに到着したと言う連絡が来た。 「サービスリクエストの詳細」のウェブページを見ると、「システムは受領済み」というステータスになっていた。 しかし、この時点で、ヤマト運輸の荷物問い合わせシステムで見ると、まだ「作業店通過(南東京法人営業支店)」のステータスのままだった。

修理の実施

2022-02-10 11:43に、「サービスリクエストの詳細」のウェブページで「修理に向けて、お客様のシステムを診断中です。」 と言うステータスになっていた。 2022-02-10 12:48に、「サービスリクエストの詳細」のウェブページで「現在、ユニットの修理に必要なパーツの手配を行っております。」 というステータスになっていた。 2022-02-10 17:58に、「サービスリクエストの詳細」のウェブページで「現在、認定技術者がお客様の製品の修理を行っております。 このステップには、正常に動作できる状態にユニットを戻すための修理、テスト、および必要なパーツの交換が含まれます。」 というステータスになっていた。 2022-02-10 19:19に、ヤマト運輸の荷物問い合わせシステムで「配達完了」のステータスになった。

返却

2022-02-14 15:58に、「サービスリクエストの詳細」のウェブページで「返却の手続きを実行中。」というステータスになっていた。 2022-02-14 16:08に、「サービスリクエストの詳細」のウェブページで「お客様の製品はご返却先住所に出荷されております。 返送状況は、追跡番号xxxxxxxxxxxxを利用して追跡できます。」というステータスになっていた。 この時点で、2022-02-10 17:58の「現在、認定技術者がお客様の製品の修理を行っております。 このステップには、正常に動作できる状態にユニットを戻すための修理、テスト、および必要なパーツの交換が含まれます。」 というステータス表示は消えていた。 また、xxxxxxxxxxxxの部分は、http://toi.kuronekoyamato.co.jp/cgi-bin/tnekoへのリンクになっていた。 上部のワークオーダーアクティビティーの右側の配送状況の追跡の文字列も同じURIへのリンクになっていた。 2022-02-14 18:02の時点で、ヤマト運輸荷物お問い合わせシステムでは、xxxxxxxxxxxxの伝票番号は、「伝票番号未登録」のステータスだった。 2022-02-14 21:00頃に見ると、ヤマト運輸荷物お問い合わせシステムでは、 南東京法人営業支店で「荷物受付」と「発送済み」の2つのステータスが19:12に同時に更新されていた。 2022-02-15 08:36に、ヤマト運輸荷物お問い合わせシステムで、最寄りのセンターから配達中になっていた。 2022-02-15 13:03に、配達されて来た。 2022-02-15 17:04に、テクニカルサポートから電子メールで問題は解消したかの確認の電子メールが来ていた。

到着

報告したファンの異音もUSBポートの問題も、確認できなかったそうだが、 左右のファンとマザーボードの交換をしたとの修理報告書が同封されていた。 ファンの異音はなくなったが、USBポートは、手元のUSB Type-C接続のEthernetアダプターをBIOSで常に認識できるようにはなっていなかった。 おそらくハードウェアの問題ではないのだろう。問題は解決した旨をテクニカルサポートに返信しておいた。

plgarc/wip/llama.cppでpkgsrcのBLASサポートを探る

この記事は、 NetBSD Advent Calendar 2024 の13日目の記事です。 llama.cppを使ってみる 以前に、 NetBSD/amd64でllama.cppを使ってみる という記事で llama.cpp を使ってみていました。 あれか...