Manabii について

無気力です。

突発性難聴になってから1ヶ月後の状況

突発性難聴になってから、1 ヶ月後の検診をうけてきました。

いつものごとく聴力検査からです。検査を受けている感じでは、突発性難聴だった左耳は、検査のほとんどの音は聞こえるようになりました。ただ、一番高い音だけは聞き取れなかったです。

診察の結果、左耳の高音以外は左右差もほとんど無く良い感じでなおってきているとのことで、ホッとしました。とは言え、高音部が聞こえておらず、それに伴う耳鳴りもあるので、もう1ヶ月程度薬を飲みつつ様子を見るようです。

高音部が聞こえるようになれば耳鳴りも治まるだろうし、何とか頑張ってくれ、私の有毛細胞よ。

酷かったときのことを思えば、私の左耳よ、よくぞここまで復活してくれたという感じです。一時的にほとんど聞こえなかった左耳がここまで復活してくれたことの要因の一つとして、発症後比較的すぐに治療が開始できた事もあるのかなと思いました。

早期治療すれば必ず治ると言うことではないが、治る可能性が高まると言うことで、突発性難聴だと思ったらすぐに耳鼻咽喉科で診てもらうことは、発症後の聴力への影響を考えるととにかく重要だと改めて感じました。

突発性難聴になった

その病名どおり、突然に突発性難聴を発症しました。

幸いなことに、今の段階では生活に不自由のないレベルで聴力が戻っています。

実際にこの病気に罹ってみて、色々な人の記録に助けられた部分もあったので、私の場合もどのような経過をたどったか、記載しておこうと思います。

続きを読む

カーネルのケイパビリティ

自宅にある Linux マシンのうち一台で一般ユーザにおいて ping を実行すると「ping: socket: Operation not permitted」と表示され、ping が送信できない現象に気がついた。(root ユーザならちゃんと実行できる)

最初は setuid の問題かと思っていたのだけれど、一般ユーザで実行できる方のマシンの ping コマンドは

$ ls -la /bin/ping
-rwxr-xr-x 1 root root 65088 Jan 14  2020 /bin/ping

で、特に setuid されていないにもかかわらず ping が実行できる。

調べてみたところ、ケイパビリティという仕組みで制御されているらしく、先の一般ユーザで実行できるマシンの ping コマンドは

$ /sbin/getcap /bin/ping
/bin/ping = cap_net_raw+ep

となっていたが、実行できない方は設定が無かった。

と言うことで、実行できない方のマシンで、

# setcap cap_net_raw+ep /bin/ping

としたところ、一般ユーザでも実行できるようになった。

何で片方のマシンはケイパビリティが失われていたかと言うことなのだけれども、これはこのマシンで以前 root ファイルシステムを rsync でコピーしたことがあって、その時に -X オプションを設定しなかったので拡張属性が失われたためのようだ。(ケイパビリティは拡張属性で実装されている)

一つ賢くなったけれども、これは気がつかないわ・・・。安易に setuid しない方向なのだなぁ。

Linksys Wi-Fi 6 ルータ E8450 を購入

以前は Cisco の子会社で、今は Belkin の無線 LAN のブランドとなった Linksys E8450 Wi-Fi 6 ルータを購入しました。

私の環境では、ルータ機能は利用せず、ブリッジモード (いわゆるアクセスポイントモード) として昨日から運用しています。

今まで利用していた Wi-Fi 6 ルータがどうもファームアップ等で WPA3 に対応しないような感じなので、これからの買い換えで、WPA3 に対応していることと、外付け USB-HDD の共有がまともに使えそうなことが決め手でした。(※ただし、外付け USB-HDD 共有機能は結局のところ仕様による制限のため使用できていません。ここだけ惜しい。)

Wi-Fi のセキュリティとしては、先にも記載したとおり WPA3 に対応しており、WPA3 / WPA2 の混在モードでの設定も可能なので、WPA3 対応クライアントも、いままでの WPA2 のみ対応クライアントの両方とも接続が可能です。

Wi-Fi (5GHz 帯域) での接続は安定していると思います。今まで利用していた Wi-Fi 6 ルータでは、1 階下にある TV (Wi-Fi 5 接続) で YouTube の動画を再生する際に再生ビットレートが下がる現象が頻発していましたが、本機種にしてからそれらの頻度が明らかに下がったように感じます。

外見のデザインはルータの底面がかつての Linksys を思い出す鮮やかな青色です。アンテナは外部に露出していないタイプです。外部にアンテナが付いている方が良いという方もいるかと思いますが、私はアンテナ内蔵型の方が見た目がスッキリしていて好きです。

なお、本製品で注意すべき点としては、以下が挙げられます。

  • 5Ghz 帯は Wi-Fi 6 でタイプは W52 、チャンネル幅は 80MHz です。W53, W56 は利用できないです。
  • 2.4GHz 帯は Wi-Fi 4 であり、Wi-Fi 6 ではありません。
  • 外付け USB-HDD が接続できる USB 端子は USB 2.0 です。(本機種より下位モデルが USB 3.0 対応なのに謎です。)
  • ブリッジモードでは外付け USB-HDD の共有は利用出来ないです。

まだ使い始めて 2 日しかたっていませんが、全体的にはブリッジモードとして普通に使う分には問題ない印象です。ただ、本製品で唯一残念な点は、上記に記載したとおり、ブリッジモードでは外付け USB-HDD 共有ができないことにつきます。
これについては、メーカーページや公開されているマニュアルにも記載されておらず、実際に購入して初めて判明しました。この辺りは是非ともファームウェアの更新などで対応して欲しいところです。

MacBook Air (M1, 2020) を買いました

久々にわくわくする Mac が出たので購入しましたよ。M1 プロセッサ搭載の MacBook Air (GPU 8 コア / メモリ 16GB / SSD 500GB) を。

デスクトップピクチャは Yosemite 付属のこれが一番好き。

実に Mac を買うのが 8 年ぶりでして、最後に買ったのは iMac Late 2012 でした。

それからなんやかんやあって、心から欲しいと思う iMac も出ないまま 2020 年になったわけですが、その iMac も最新 OS のサポートから外れ、どうしてもモバイルしなければいけないときは、今となっては重量的にも動作的にもあらゆる意味で「重い」 MacBook Late 2008 Aluminum に Ubuntu インストールしたマシンで何とかやってきましたが、カバンに入れて持ち歩くと重すぎて肩が痛くてたまらない。

そろそろマシンどうしようかなぁと思っていたときに M1 プロセッサ搭載の MacBook Air ですよ! しかもそんなに高くない。(iMac 比)

発表されたその日の夕方頃、急に物欲が高まり発注、到着したのは 2020/11/22 でした。その間楽しみで凄くそわそわしてました。😊

Apple M1 って表示されてる。

プロセッサのアーキテクチャが全く変更になったので、今までの Intel プロセッサ向けアプリケーションは Rosseta 2 というレイヤーを通して実行されるので、若干パフォーマンスが悪くなっているはずなのですが、今の所それほどそれが重たい、と感じたことは無いですね。ATOK の最新版も動いていますし、今まで使っていたほとんどのアプリは実行できているようです。

これは買う前から分かっていたのですが、VMware Fusion などの x86 仮想化は動作しないようです。まぁ、Windows が必要なときは、iMac の仮想で動かせば良いだけだし。

なお、一番痛かったのは、MacPorts でビルドが失敗するパッケージがあったりすることでしょうか。これは時間がたてば無くなっていくのではと思っています。

あとは OS の Big Sur 。MacBook Air で使っていると、なんだかキーボードがある iPad を使っているような感覚に陥ります。それだけ macOS がどんどん iOS / iPadOS に近付いていると言うことでしょうか。そういえば、Big Sur では iOS / iPadOS アプリも動作しますしね。

液晶画面はとても綺麗です。余りに綺麗すぎて MacBook Air で作業をした後に iMac の画面を見るとなんだかぼやっとしているなあと感じ、早く Apple silicon 搭載の iMac 出ないかなと思ってしまうほどです。😅

MacBook Air には、USB-C ポートが 2 個しか無く Ethernet 端子もないので、とりあえず「Satechi Type-C 2-in-1 LANポート付き アルミニウム 3ポートUSB 3.0ハブ」を購入しました。近年 Wi-Fi が無いところも少なくなってきましたが、有線しか出来ないところでもこれでネットに接続できます。

小さいし、邪魔にならない。

ちなみにこれを使って有線でスピードテストを行った結果は以下のような感じです。

実用上十分な速度が出ていました。

使い始めてまだ 1 週間の MacBook Air 、久々に購入して凄く満足感を味わうことの出来る Mac です。

Debian 10 から 11 (Testing) へのアップグレード

現段階 (2020/11/07 現在) では、Testing の Debian 11 に Debian 10 からアップグレードしてみたテスト。

/etc/apt/sources.list を書き換え、apt-get update && apt-get upgrade を実行した。いくつか設定ファイルに変更が入るので、とりあえず今まで利用していた設定ファイルを残してアップグレードを続ける。

終わったら、変更が発生したファイルのデフォルトの設定ファイルと利用中の設定ファイルの差分を取って、適切に変更して再起動する。

起動したら、apt-get update && apt-get dist-upgrade をするのだが、libnss-nis の部分でなんかエラーが出ているようなので、エラーメッセージで検索し、まずは apt-get -o APT::Immediate-Configure=false install libnss-nis:amd64 の様にして libnss-nis と依存パッケージだけアップグレードした。

そのあと apt-get dist-upgrade して、やはりくつか設定ファイルに変更が入るので、こちらも今まで利用していた設定ファイルを残してアップグレードを続ける。

終わったら、変更が発生したファイルのデフォルトの設定ファイルと利用中の設定ファイルの差分を取って、適切に変更して再起動する。(php-fpm 構成だったのだが、なぜか Apache モジュール版 php が入ったりするので適当に設定変更をする。)

php は 7.4 になった。Debian 10 の php は 7.3 だったが、最近は WordPress とかで php 7.3 すら古いとか言われる始末でこれは嬉しい。まぁ、すぐに 7.4 でも古いとか言われてしまうのかもしれないけれど。

思いのほかスムーズに進んで、おおよそ 2 時間程度で作業が完了した。

プライムデーで、Echo Show 5 を買いました

6 ヶ月の Amazon Music Unlimited もついて 4,980 円で。こういうのを経験してしまうと、もう通常価格で Amazon デバイスを買う気が起こらないなぁ。

しかし、Echo Spot が壊れて以来、久しぶりのディスプレイ付きスマートスピーカー。コンパクトですが、スピーカーの音質も Echo Dot 第三世代とそれほど変わらず、しかも Echo Spot よりだいぶん安いという。

それはさておき、音声プロフィールの複数作成で難儀しました。

今回買った Echo Show 5 は自室に置いて、すでに持っている Echo dot は居間に移動して家族で使おうと考え、追加で家族の音声プロフィールも作成できるのか確認したところ、Alexa アプリに複数の音声プロフィールの作成方法の記載がありました。

と言うことで、音声プロフィールを追加すべく、Alexa アプリ記載どおり「Alexa アプリからログアウト・ログインして、最初の画面で追加する人の名前入力して進める」という方法で試したのですが、何回行っても

うまくいきませんでした Amazon のサーバーに接続できませんでした。後でもう一度試して下さい。

とメッセージが表示され、正常に進むことが出来ませんでした。

しかもなぜか手順を繰り返す度に、連絡先に追加しようとした人の氏名が複数表示されるという謎現象も発生。(そしてそれをどうやっても削除できない。なお、これはカスタマーサポートに連絡することで Amazon 側で削除してくれました。)

結果としては、シンプルに音声プロフィールを追加する人が Echo 端末に「私の声を覚えて」と呼びかけることで登録できました。

最初から難しく考える必要なんて無かった・・・。

Fusion Drive の解除と再構成

Fusion Drive のデータの完全消去に関するメモ。GUI からデータの完全消去が出来ないので・・・。

  1. Mac を内蔵 Fusion Drive 以外から起動する
  2. とりあえずディスクの情報を得る
    $ diskutil list
    /dev/disk0 (internal, physical):
       #:                       TYPE NAME                    SIZE       IDENTIFIER
       0:      GUID_partition_scheme                        *121.3 GB   disk0
       1:                        EFI EFI                     209.7 MB   disk0s1
       2:                 Apple_APFS Container disk2         121.1 GB   disk0s2
    
    /dev/disk1 (internal, physical):
       #:                       TYPE NAME                    SIZE       IDENTIFIER
       0:      GUID_partition_scheme                        *1.0 TB     disk1
       1:                        EFI EFI                     209.7 MB   disk1s1
       2:                 Apple_APFS Container disk2         1000.0 GB  disk1s2
    
    /dev/disk2 (synthesized):
       #:                       TYPE NAME                    SIZE       IDENTIFIER
       0:      APFS Container Scheme -                      +1.1 TB     disk2
                                     Physical Stores disk1s2, disk0s2
       1:                APFS Volume Internal HD             954.4 KB   disk2s1
  3. Internal HD としてマウントされている /dev/disk2 をアンマウントする。
    $ diskutil unmountDisk disk2
  4. APFS コンテナの情報を得る
    $ diskutil apfs list
    APFS Containers (1 found)
    |
    +-- Container disk2
        ====================================================
        APFS Container Reference:     disk2 (Fusion)
        Size (Capacity Ceiling):      1121118199808 B (1.1 TB)
        Capacity In Use By Volumes:   8817790976 B (8.8 GB) (0.8% used)
        Capacity Not Allocated:       1112300408832 B (1.1 TB) (99.2% free)
        |
        +-< Physical Store disk1s2
        |   -----------------------------------------------------------
        |   APFS Physical Store Disk:   disk1s2 (Secondary, Designated Aux Use)
        |   Size:                       999995129856 B (1000.0 GB)
        |
        +-< Physical Store disk0s2
        |   -----------------------------------------------------------
        |   APFS Physical Store Disk:   disk0s2 (Main, "Faster" Disk Use)
        |   Size:                       121123069952 B (121.1 GB)
        |
        +-> Volume disk2s1
            ---------------------------------------------------
            APFS Volume Disk (Role):   disk2s1 (No specific role)
            Name:                      Internal HD (Case-insensitive)
            Mount Point:               Not Mounted
            Capacity Consumed:         970752 B (970.8 KB)
            FileVault:                 No
  5. disk2 が Fusion Drive なのでこれのコンテナを削除する
    $ diskutil apfs deleteContainer disk2

    ※これを行うと、Fusion Drive が解除され、物理ディスク /dev/disk0 と /dev/disk1 となる。

  6. それぞれ Secure Erase を実行する。
    $ diskutil secureErase 0 disk0
    $ diskutil secureErase 0 disk1

    ※どちらも 0 消去。

  7. Fusion Drive を再構築する
    $ diskutil resetFusion
    
    Internally-located hardware disk devices known to the currently-running macOS:
    Solid State                              (disk0)
    Rotational                               (disk1)
    
    Volumes exported by partitions or storage systems hosted on the above devices:
    
    disk0 will be used as the "main" ("faster") device
    disk1 will be used as the "secondary" ("larger") device
    
    WARNING: All of the above will be erased
    Do you want to continue? (Enter "Yes" to proceed to erase) Yes
    
    Force-unmounting all volumes on the chosen "main" ("faster") disk device
    Started on disk0
    Error: -69886: Invalid request
    Ignoring the error during the above unmount; proceeding
    Force-unmounting all volumes on the chosen "secondary" ("larger") disk device
    Started on disk1
    Error: -69886: Invalid request
    Ignoring the error during the above unmount; proceeding
    Creating a new partition map on the "main" ("faster") disk device
    Started on disk0
    Unmounting disk
    Creating the partition map
    Waiting for partitions to activate
    Finished on disk0
    Partition disk0s2 will be the "main" ("faster") APFS Physical Store
    Creating a new partition map on the "secondary" ("larger") disk device
    Started on disk1
    Unmounting disk
    Creating the partition map
    Waiting for partitions to activate
    Finished on disk1
    Partition disk1s2 will be the "secondary" ("larger") APFS Physical Store
    Creating an APFS Fusion Container importing two partitions
    Started on disk0s2
    Creating a new empty APFS Container
    Unmounting Volumes
    Switching disk0s2 to APFS
    Switching disk1s2 to APFS
    Creating APFS Container
    FusionLC autodetect: regular Fusion
    Created new APFS Container disk8
    Finished on disk0s2
    The new APFS Container is disk8
    Adding a logical APFS Volume to the APFS Container
  8. macOS を再インストールする

421 Misdirected Request errors ではまる

macOS の Safari で、https://www.manabii.info/ のリンクから、https://ipv6.manabii.info/ へ遷移した時に「421 Misdirected Request errors」が表示されて、散々悩んだのだけれど、解決したメモ。

原因は、サーバ側で Apache において SNI と HTTP/2 とワイルドカード TLS 証明書の条件が重なっていたからのようだ。

具体的には、以下のような構成を取っていた。

  • サーバ側では HTTP/2 と HTTP/1.1 を利用可能としていた。
  • TLS パラメータは下記証明書を除き、全てのバーチャルホストで同じとしていた。
  • https://www.manabii.info/ ではコモンネーム「*.manabii.info」というワイルドカード証明書を利用。
  • https://ipv6.manabii.info/ では、https://6.ipv6.manabii.info/ というホストもあるので、コモンネームが「ipv6.manabii.info」で、SANsに「6.ipv6.manabii.info」が入ったマルチドメイン証明書を利用。

ところが、macOS の Safari (HTTP/2 対応) において、https://www.manabii.info/ を表示した後に https://ipv6.manabii.info/ を表示するパターンで、表題のエラーが発生していた。

つまり、ブラウザで https://www.manabii.info/ を表示した後で、https://ipv6.manabii.info/ を表示するとき、HTTP/2 では www.manabii.info で使用した既に開いている通信を利用するので、*.manabii.info のワイルドカード証明書での TLS 接続状態で ipv6.manabii.info にアクセスしようとするための模様だ。

解決方法としては、以下の通り。

  • https://ipv6.manabii.info/ のバーチャルホストでは、*.manabii.info のワイルドカード証明書を使い、6.ipv6.manabii.info の ServerAlias は削除する。
  • https://6.ipv6.manabii.info/ を別のバーチャルとして設定し、コモンネームが「6.ipv6.manabii.info」の証明書を使用する。

HTTP/2 の SNI では、SSL パラメータは全てのバーチャルホストで同一とする必要があるのは知っていたのだけれど、まさか上記のような罠があるとは。