投稿

10月, 2017の投稿を表示しています

OpenVPN を TAP(ブリッジ)→ TUN(ルーター)へ変更

イメージ
基本的に VPN と NFS を使った利用環境は構築できたので、最後に少しでも VPN を最適化しておきたくなり、OpenVPN のモードを TAP(ブリッジ)から TUN(ルーター)へ変更することにした。.ovpnまずはサーバー(DD-WRT)側と、クライアント側(Mac、Linux)双方で、.ovpn 中の dev 設定を tap から tun に変えることが基本となる。 dev tun クライアント側はこれだけで他にやることはない。一方、サーバー側ではルーターモード制に伴ういくつかの副作用的な状況を解決するための設定が必要となる。サーバー(DD-WRT)側設定中で tun にする以外に、VPN 専用のサブネットの設定が必要になる。DD-WRT の設定の、TUN / TAP を選択する直下の Network と Netmask の部分がそれである。ここの例では 192.168.11.0/24 としてみた。 ブリッジモードではクライアントはそのままサーバー側のサブネット(192.168.0.0/24 とする)に参加する形となり、VPN サーバーが DHCP サーバーとしてクライアントに IP プールの中から一つ割り当てる形だった。ルーターモードでは、VPN 用のサブネット(192.168.11.0/24)丸ごとが IP プールとなりそれをクライアントに割り当てる。なので、VPN クライアントはサーバー側の本来のサブネットには直接参加しない形となるので、VPN 用のサブネットからサーバー側の本来のサブネットへとアクセスするためのルーティング設定が必要となる。そのために、DD-WRT の Additional Config においてクライアントにプッシュする形でルーティング設定をセットする。 push "redirect-gateway def1 bypass-dhcp" ※ "route 192.168.11.0 255.255.255.0" を別途 push する必要はない。redirect-gateway でリダイレクトされる Gateway 設定に同じ route 情報は含まれている。さらに、これで VPN サブネット側のクライアントがサーバー側の本来のサブネットにアクセスできるようになったが、反対にサーバー側の本来のサ…

ローカルディスク ⇄ NFS ディスク間の rsync

イメージ
👉 前回で OpenVPN の接続と NFS のマウントまで自動化できたので、あとは特定のフォルダーをローカルディスク ⇄ NFS ディスク間における rsync をボタン一発でできるようにするだけだ。最新の rsyncmacOS 標準の rsync はバージョンが旧いので、Homebrew で最新バージョンにするのが常套のようだ。 brew install rsyncだけで ok。brew tap してからという情報は既に古いものなので注意。OS 標準の元から存在する rsync は /usr/bin/rsync に、brew でインストールされた新しい rsync は /usr/local/bin/rsync にある。ローカルディスク ⇄ NFS ディスク間における rsync下の例では、~/eclipse-workspace フォルダを丸ごと、NFS にマウントした NAS の共有フォルダにバックアップしている。また、NAS 側で NFS のオプションを ALL_SQUASH で自分のアカウント名に割り当てているため、ファイルの所有者などの情報は rsync 側のオプションで制御していない。rsync 自体の詳しいオプションについては別途詳細を調べて欲しい。また下の例では省略したが、実際には --exclude オプションなども指定して、キャッシュデータは一々バックアップしないように等している。 /usr/local/bin/rsync -ruv --delete ~/eclipse-workspace /Volumes/NFSAutomator によるアプリ化上記 rsync のコマンド内容のシェルスクリプトを Automator を使ってアプリ化する。 Automator の使い方自体については簡潔な解説があり参考になる。

VPN 接続(Tunnelblick)と NFS マウントの自動化

👉 先の記事で sudo がパスワード入力なしで実行できるようになったので、それを前提として VPN 接続に連動して NFS のマウント/アンマウントを自動化する方法を確立した。(Tunnelblick のベースである)OpenVPN 自体の仕様で .ovpn ファイルの設定で up / down 用のスクリプトを指定できるようになっている。この仕様に加えて、Tunnelblick では、connected.sh と pre-disconnect.sh という名前のスクリプトをそれぞれ up / down 用スクリプトとして割り当てることによって「接続後」「切断前」に実行するスクリプトとし扱ってくれるようだ。なので、connected.sh と pre-disconnect.sh を用意し、それぞれにおいて、NFS をマウント/切断する処理を記述しておいた。connected.sh #!/bin/sh sudo mkdir /Volumes/NFS sudo mount_nfs -P 192.168.0.1:/share /Volumes/NFS pre-disconnect.sh #!/bin/sh sudo umount /Volumes/NFS ※ umount 時に /Volumes/NFS は自動的に rmdir されるので、rmdir は明示的に行う必要はない。以上の 2 種のスクリプトを用意した上で、.ovpn に.ovpn up ~/OpenVPN/connected.sh down ~/OpenVPN/pre-disconnect.sh といったような形式の設定を追加する。最後に、Tunnelblick で .ovpn をインポートする。これだけである。※ .ovpn や .sh を修正した場合、都度 Tunnelblick にインポートし直す必要がある点に注意する。Tunnelblick はインポート時に自前で .ovpn や .sh をコピーしてそれを直接使うので、インポート元の .ovpn や .sh を修正しただけでは Tunnelblick の挙動に反映されない。Mac から NFS を使ってみた結果……iCloud ドライブや Google ドライブのような感覚で使いたいと思って、VPN を構築し、VPN 経由で NAS に接続して…

sudo のパスワード入力を省略できるようにする

OpenVPN で、接続確立後に自動で NFS をマウントし、接続切断時(直前)に NFS をアンマウントするシェルスクリプトを使おうと思った。ところが、mount / umount には root 権限が必要なので、通常では sudo するのにパスワード入力が求められてしまう。色々調べた結果、/etc/sudoers という設定ファイルによって制御が可能であり、さらに sudoers を編集するのには危険が伴うので、visudo を通じて編集するのが常識的だということがわかった。macOS / Linux のいずれにおいても、基本的には %admin ALL=(ALL) ALL となっている部分を %admin ALL=(ALL) NOPASSWD:ALL とすればよい。これは管理者グループに所属するユーザーを対象に、sudo コマンドの実行時にパスワードを不要とする設定である。(また、このようにグループの設定からアプローチするやり方ではなく、個々のユーザー単位で同様の設定をするアプローチでも可能である)注 1:エントリーの順番Mac では root と %admin しか元々エントリーがなかったので、気にする必要はなかったが、Linux(Ubuntu GNOME 16.04LTS)では root / %admin / %sudo となっていて、グループのエントリーが %admin と %sudo の 2 種類あった。この状態で %admin のエントリーを NOPASSWD にしても %sudo のエントリーで上書きされてしまうので、エントリーの順序を入れ替えて、%sudo の後に %admin のエントリーが来るように編集しなければならない。注 2:Ubuntu GNOME 16.04LTS での管理者グループ IDUbuntu GNOME 16.04LTS では管理者グループの ID が admin ではなく、adm であった。にもかかわらず、sudoer のエントリーは %admin となっていたため、%adm と修正する必要があった。注 3:visudovisudo はその名の通り、vi がベースになっているので、操作がよくわからない場合は vi の情報を調べてみるとよい。

SSH の公開鍵認証+IP制限

過去に NAS(QNAP)の SSH の設定を色々いじっている時にも SSH について触れたことがあったが、その時は rsync の環境を構築しようとしていた記事の中で SSH も含めていたため、なぜ SSH 単独の話題ではなかったのかという事情についてまでは忘れていた。その時の本目的はあくまでも NAS を使ったデータのバックアップ環境の確立だったので、SSH 自体は使っても使わなくてもよかったからだ。その当時においては、当初、VPN から NAS にアクセスして、NFS を使う方策を試みたが、VPN が PPTP を使ったセキュリティ的に脆弱なものであり、SSH によって rsync ができるようになったので、VPN も NFS も忘れていた。ところが、今現在、OpenVPN でセキュリティ的に十分な環境が整い、Mac から VPN 経由で NAS をクラウド的に利用する方法を模索し始めてみると、Samba よりも NFS の方がちゃんと動くし、Windows 抜きで Mac か Linux かで動かすのだから、よりによって(本来 Windows ちゃんと仲良く戯れるための)Samba など使わないに越したことはないのだ。ともかく、VPN 前提で考えてみると QNAP の SSH のセキュリティも改めてちゃんと見直したくなり、アクセスを LAN からのアクセスに制限できないかと調べてみると、ちゃんと方法があったので、早速そうした。方法はサーバー(QNAP)側 .ssh/authorized_keys のエントリーに、from="192.168.0.0/24" のような形式のオプションを追加することである。次のような感じで: from="192.168.0.0/24" ssh-rsa AAAAB3...AgRiOf my Ubuntu from="192.168.0.0/24" ssh-rsa AAAAB3...v17zrd my Macbook こうすることで、SSH は LAN 内からの接続しか受け付けなくなった。注 1: VPN 経由での接続OpenVPN を使ってアクセスする際、ssh admin@192.168.0.1 のように、IP アドレスで NAS にアクセスする必要がある。myqnap…

Mac の OpenVPN クライアント(Tunnelblick)

イメージ
Mac での OpenVPN クライアントとしては Tunnelblick というものがメジャーなようなので、これを使うことにした。設定ファイル自体は、Linux での OpenVPN の場合の .ovpn を使う点は全く同じなので、Linux 上で証明書類を作成し、それをベースに証明書の内容をコピー&ペーストで埋め込んだ形での .ovpn ファイルを作成した。Linux でのクライアント用の .ovpn との唯一の違いは、Mac では user nobody と group nobody の設定を使わずにコメントアウトした点のみである(Mac ではこの設定があるとエラーが出る)。それ以外は基本的にサーバー側設定に依存する設定なので、何ら Linux 用のものと変わる点はない。こうやって用意した .ovpn を Tunnelblick に読み込ませてしまえば、あとは Tunnelblick で接続ボタンを押すだけで自在に VPN に接続できるようになった。 補足VPN の接続の度にクライアントのグローバル IP が不明でどうのというメッセージが表示される。これは VPN 非接続時のグローバル IP から、VPN 接続時のプライベート IP へと IP が変化して VPN に接続したことを検知する機能に関するのなので、VPN 接続自体の問題は無関係である。僕の場合、VPN 非接続時の通常の通信状況においても、WiMAX ルーター経由でネットを利用しているので、Mac 自体は WiMAX ルーター下のプライベート IP が割り当てられている。なので、このメッセージを回避するには、グローバル IP の変化を検知する機能を off にすればよい。Tunnelblick の以下のチェックを on にすれば当該機能を off することができる。

VPN 環境の OpenVPN 化

イメージ
Mac をいじり出して、iCloud を軸にした標準アプリの設計思想が非常に気に入ってしまった。一般のユーザー視点なら無料 5GB で十分である。ところが、Mac をメイン機とするならば、僕の場合、エンジニア(プログラマー)的側面も、一般ユーザーとしての立場に加えて必要になってくる。外にも持ち歩く MacBook に、開発中のデータが入っているのは非常にリスクが高いから、データの保管場所が MacBook の実機に依存するのは避けたい。だが、アプリを開発するためのプロジェクトファイルを iCloud ドライブにぶち込んでしまうと、どうやってもすぐに無料で利用できる 5GB の限界に達してしまう。かといって課金までして iCloud を増量したいとも思わない。となると、せっかく実家で運用している QNAP 製の NAS があるので、それを使って iCloud のような運用ができないかと考えた。これまではデータを随時バックアップするという用途に NAS を使っていたのだが、クラウド的に、データ本体を常に NAS 側に置いておいて、それを端末側で参照するという形である。ところが、写真などのマルテメディアデータはそのような専用のアプリが存在するのだが、ファイル一般となると iCloud ドライブのような使い方のできるオープンなアプリが存在しない。iCloud ドライブは macOS 専用だし、Google Drive にしても専用アプリをインストールする必要があり、それも Windows と macOS のみで Linux では使えない。また、昔からある SMB の場合、LAN での利用を前提としていて、クラウドよりも一昔前のスタイルのまま停滞している感がある。WebDAV選択肢が限られていたので、まず最初に QNAP NAS で使える WebDAV を使ってみることにした。これは、macOS でも Linux でも標準で使えて、ネットワークドライブとして iCloud ドライブや Google Drive のようにアクセスが可能である。ところが、WebDAV にはバグがあり、それは WebDAV が依存している apache のバグに由来するようだが、フォルダに index.html のファイルが存在すると、そのフォルダが空っぽ状態でファイルのリストが見えなくなってしま…

Let's Encrypt がついに自動化される

StartSSL が使えなくなって以来代替として Let's Encrypt を使うしかなかったのだが、有効期間の短さのせいでこれまで深入りは避けどうしても SSL が必要なドメインだけで仕方なく使っていた。たった 2 つ、さくらインターネットで運用している自分のメインのホームページの独自ドメインと、もう一つは、QNAP の myqnapcloud.com のサブドメインである。ところが、ここ一ヶ月の間で、QNAP もさくらインターネットも両方とも、Let's Encrypt に公式対応し、自動更新機能を含んだ形となった。お陰で、ただボタンをポチポチ押しておけば、証明書がセットされて SSL レディな状態になり、今まで証明書云々という情報を収集していたのが、ほとんど無駄になるくらい簡単になってしまった。さくらインターネットの方では一つだけつっかかったところがあって、ドメインの管理はムームードメインのムームー DNS を使っており、blog は blogspot.com へ、www はさくらインターネットのサーバーの IP アドレスへと振り分ける形にしていた。このドメインにおいて Let's Encrypt の設定がエラーが出てしまった。原因は、www を付けないデフォルト状態に対する DNS 設定が存在しなかったせいである。さくらインターネットの Let's Encrypt では、www を付けないドメイン名も指定して証明書を発行しようとするので、デフォルトドメインに対する所有権のチェック時にエラーになる。なので、ムームー DNS の方で、何も付けない空欄の A レコード(www と同様にさくらのサーバーの IP に割り付ける)を追加して、しばらく時間が経過してから、さくら側で Let's Encrypt の登録と試すと今度は成功した。

カレンダー

カレンダーは Linux とは関係がなく Android で Google カレンダーを使っていたのみ(Linux ではブラウザ上で利用)。Mac に乗り換えたのでついでに macOS 標準のカレンダーアプリ(iCal)に、Google のカレンダーをセットしてみた。基本的には Google アカウントをセットするだけだが、同期設定で少々調整した。このような iCal 向けの設定がわざわざ用意されているのは、iCal でも祝日や連絡帳の誕生日の表示機能があるので、Google 側の表示と二重に表示されないように考慮されているのだろう。自分の場合は基本的に祝日・誕生日などの表示は iCal 側に任せて、Google カレンダーの方は同期設定で off にした。もちろん、iPhone と Mac の組み合わせなら、Google カレンダーを止めて、iCloud ベースのカレンダーにしてしまえる。自分の場合現状は MacBook と Android との組み合わせなので、Google カレンダーベースにしている。

FTP クライアント

macOS 用の FTP クライアントは他にもいくつかあるようだが、Linux でも共通して使えるので、FileZilla にした。Linux から macOS への設定データの移行は、Linux 側からエクスポートした FileZilla.xml を Mac 側の FileZilla でインポートするだけ。

Thunderbird (Linux) から Mail (macOS) へのデータの移行

イメージ
Thunderbird 同士であれば、Linux でも macOS でも(Windows でも)、基本的に Profiles ディレクトリ下にある XXX.default フォルダを移動すればいいので、データの移行に苦労することはない。今回は、Linux から macOS の移行に伴って、メーラーも Thunderbird から macOS 標準の Mail アプリに乗り換えてみることにしたため、多少記録に値する点はあった。まず、Linux から macOS には、Thunderbird の XXX.default を持ってくるだけでよい。macOS 側でわざわざ Thunderbird をインストールする必要はない。 次に、ここがネット上の情報では誰も触れていなかった点だが、Mail アプリで「ファイル > メールボックスを読み込む」によって XXX.default を読み込ませる時、Thunderbird 用のオプションが存在せず、「mboxフォーマットのファイル」を選ぶという点である。おそらく、Thuderbird 用のオプションがあったというのは古い情報なのだろう。以上で問題なくデータの移行が完了した。

Samba

元の Linux マシンと MacBook の間でファイルを移動するために、Linux 側に Samba を導入した。Linux 黎明期から異 OS 間でのファイル共有で定番だった Samba だが、今でも代替が出てきておらず、第一線で使われているということを知って少し驚いた。いくつか詰まった点としては、GUI で共有オプションなどを指定しても、何も機能せず、結局は /etc/samba/smb.conf を直接編集する必要があった。もしかしたらこれは権限の問題で、root 権限でログインしていたら、GUI でも直接操作できたのかもしれない。また、Samba の設定でいくらパーミッションを設定しても、それが実際のファイルに付与されている権限を変更するわけではないので、あくまでも Samba で設定した権限の範囲内で、実際のファイルへそのファイルの権限に基いたアクセスが行われるという扱いのようである。さらに、Samba を通じてアクセスするクライアント側で求められるユーザー認証は、Samba で独自に設定するユーザーとパスワードなのには注意する。Linux マシンにおけるユーザーアカウントとは関係がない。次のコマンドで設定する: sudo smbpasswd -a <user name>

FileVault

初代 MacBook のこのマシンで、暗号化に約 10 時間かかった。

Night Shift

イメージ
Sierra からだったと思うが、今は macOS も標準で Night Shift が使えるので、当然利用する。設定 > ディスプレイ > Night Shift > スケジュール:日の入から日の出まで Night Shift が自動で有効になっている時間帯に、一時的に Night Shift を切りたい場合は、「設定 > ディスプレイ > Night Shift > 手動:✅ 日の出までオンにする」のチェックを外せばよい。

ナチュラルスクロール

残念ながら(というか賢明でもあるのだが)、トラックパッドのジェスチャーと、マウスのホイールのスクロールの方向性をナチュラルスクロールにするか(リバーススクロールにするか)という設定は連動しており、別々に設定できない。現状では未だ完全に Mac に移行できていないので、Linux と Mac の両股をかけている状態なのだが、Linux の方はマウスのホイールの方向を設定する余地がなく(トラックパッドのみ設定可)、Windows と同じ、リバーススクロール一択なので、そちらとの関係上、当面は(トラックパッドとの間の操作性の一貫性に反するものの敢えて)マウスのホイールに関してはリバースにしたかったのだが、Mac は Mac で仕様的に不可能であった。

Mousecape(左利き用マウスポインター)

イメージ
Mac でマウスポインターを左利き用に表示するための定番は Mousecape(0.0.5)を使うことだが、以前の macOS で発生していなかった問題が、最近の OS では発生しているようである。Mac を再起動すると、自動で左利き用の .cape 設定に切り替ってくれないのである。同様の問題は公式 github でも issue #45 として報告されており、ghost 氏のコメントの詳述が当てはまることが確認できた。すなわち、Mousecape をインストール後、OS デフォルトのマウスポインターを dump し、その dump した .cape を左利き設定で適用する。起動時に自動的に適用されるようにするために、(Mousecape の中から)Helper Tool をインストールする。が、そもそも .cape を適用しても、実は適用されておらず、Applied Cape: None のままで選択した .cape に緑のチェックマークが付いていない。.cape を適用する処理で、左利き用に反転する処理は行われるものの、何らカスタム .cape が選ばれた状態になっていないのである。そのため、再起動時にカスタム .cape を適用する処理が走らず、そのために左利き用に反転する処理も行われないので、このような問題が発生する。ghost 氏は、dump の使用は諦め、.cape を新規作成してこの問題を回避したと述べている。ghost 氏のように新規作成するのはそれはそれで大変そうだったので、僕の場合、この MacBook を譲り受けた際、元々僕が頼まれて Mousecape の左利き設定なども行っていたという経緯があり、初期化前に .cape だけ旧いのをバックアップしてあった。それを持ってきて、Mousecape に .cape をインポートしたもの適用すると、上のような問題は起きず、Applied Cape: Cursor Dump という風に表示され緑のチェックマークも付く。再起動でも Helper Tool が適切に働く。 ただし、この Cursor Dump は旧い macOS での dump なので、サイズなどが違うせいなのか、微妙に色などが異なっていて、レインボーカーソルなどが白っぽい表示になってしまっている。これを解消しようとして、.cape の…

AquaSKK

イメージ
Mac で SKK と言えば、AquaSKK (4.4.5)OS 側の完璧な設定方法は次の通り:設定 > キーボード > 入力ソース入力ソースの設定1. 英語は [@] ASCII を追加 2. 日本語は [ア] カタカナ、[あ] ひらかな、[英] 全角英数、[カナ] 半角カナ、[あ] 日本語(※1)を追加(※2) 3. U.S. を削除 4. [あ] 日本語 を削除 5. 以上で、SKK のみの入力モード間での切り替えとなる。 ※1 [あ] 日本語 は macOS デフォルトの日本語変換システム(旧ことえり)※2 AquaSKK 統合は選択しないその他メニューバーに入力メニューを表示:ONcaps lock ⇄ control の入替:「設定 > キーボード」の右下の「修飾キー」において設定入力ソースの切り替えショートカットキー:(shift+)command+space

Apple ID の 2 ファクタ認証の落し穴(というか明確なバグ)

イメージ
Apple ID のアクティベーションにまつわる問題はようやくクリアされ、OS を High Sierra にアップデートし、色々と初期設定していた。その過程で、FileVault による暗号化処理を開始したのだが、いかんせん初代 MacBook のせいか、残り時間が「あと 1 日以上」と表示され、いつになったら終わるのかわからないような状況になっていた。FileVault による暗号化処理の進行中でも、並行して Mac は使える。ちょうどそのタイミングで、High Sierra の追加アップデートが配信された。それでそちらもアップデートしたら、再起動を伴うアップデートだった。これが、FileVault で中途半端に暗号化処理がされていたことと競合し、OS のアップデートの処理が再起動した後に進まなくなり、仕方ないので再度 HDD 初期化、OS の再インストールすることを余儀なくされた。ところが、iCloud の初期設定で Apple ID でログインしようとしたところ、2 ファクタ認証の、2 ステップ目、6 ケタの認証コードがスマートフォン(非 iOS デバイス)に届かないのである。音声通話で認証コードをリクエストしても同じ。OS の初期化以前は、MacBook 自体が信頼できるデバイスとして、MacBook に認証コードが届いていた。初期化によって MacBook は一旦削除されたので、残るはスマートフォンの SMS か音声通話しかない。ウェブから直接、Apple ID アカウントにログインしようとしても、やはり 2 ステップ目で進めなくなるのは同じである。アカウントのパスワードリセットをしようとしても、そのためにもまた 2 ファクタ認証となり埒が明かず、何度も繰り返していたら、今度は一時的なロック状態になり、サポートに相談したところ数時間待つようにと、言われた。しかし、これは短時間での連続ログインによるロックだから、どのみちそのロックが解除されても、やはり 2 ステップ目の問題は何も解消できていないのである。連続ログインによるロックの時限解除を待って、ウェブから Apple ID アカウントのパスワードリセットを試みられるようになっていたので、とりあえずパスワードリセットの手続を開始した。アカウントのリセットの場合、これは、セキュリティ上の仕様として、2、3…

この Apple ID は、App Store で使用されたことがありません

自分が買うつもりでスペックを見立てた MacBook Pro(13 インチ・タッチバー付)の購入計画を身内に取られた(?)ので、自分自身の Mac 購入計画は一旦流れた形になったが、その身内が元々使っていた MacBook(初代 2015 年モデル)をもらってひとまず使ってみることにした。メイン機として使う場合は、Android やゆくゆくは iOS アプリのプログラミングに使うつもりなので、処理能力的にはすぐに不満になってしかるべきスペックの iMac または MabBook Pro を購入する可能性はあるが、今はひとまず一通り使ってみて、様々な使い勝手を知り尽す目的でこの MacBook を使うことにした。まあ、元来 Linux ユーザーである身からすれば、macOS というのはエキスパートユーザーであっても、非エンジニア(プログラマー)人種、せいぜいシステムアドミニストレーター系の人種(ジーニアスバーとかサポートの人たちもこれに含まれるだろう)にとっての進化の最先端にある OS であって、Windows との比較で圧倒的な価値を持つものの、Linux のような、ユーザー層とエンジニア層の重なる度合いが高い世界とはベクトルが異次元であり、比較にならない。Linux ユーザーにとって、自分で OS をインストールすることのようなシスアド業務は、まず最初のスタートラインに過ぎないわけである。ちょいちょいとネットで情報を収集して、譲り受けた MacBook をおもむろにフォーマットして初期化し、OS の再インストールを行った。何一つ難しいことはなく、ほとんど勝手にインストールは終った。こういうのを怖がって、最初の一歩すら踏み出せない人って何なんだろう?──だが、非エンジニア人種という名の世間の一般ユーザーは、そういうものである。Apple 製品の主たるユーザー層に何を求めるというのだ?OS の再インストールで、OS のバージョンは古い、El Capitan あたりに戻ってしまうので、App Store から最近出たばかりの High Sierra をダウンロードして、アップデートしようとした。ここで問題が発生した。Apple ID によるサインインができないのである。もちろん、パスワードを紛失したとかの、素人レベルのミスではない。「この Apple ID は、App…