2017年10月28日土曜日

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 サブネット側のクライアントがサーバー側の本来のサブネットにアクセスできるようになったが、反対にサーバー側の本来のサブネット(192.168.0.0/24)の機器から VPN クライアントの属する VPN サブネット(192.168.11.0/24)側にアクセスできるようにもする必要がある。

このために、サーバー側のブロードバンドルーター(192.168.0.1 とする)の設定で、静的ルーティング設定として 192.168.11.0/24 のゲートウェイが DD-WRT の稼動する VPN サーバー(192.168.0.2 とする)であることを設定する。


以上で、ルーターモードで正常に稼動するようになった。OpenVPN では一般にルーターモード(TUN)が推奨されているように思われるが、まず体制を確立するのが簡単なのはブリッジモード(TAP)だと思うので、初めて挑戦する人にはブリッジモードで試すことをお勧めする。一方、レイヤー 2 の余計なパケットが流れなくなるので、トラフィック的にはルーターモードの方がより安定していることは確かである。

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

前回で OpenVPN の接続と NFS のマウントまで自動化できたので、あとは特定のフォルダーをローカルディスク ⇄ NFS ディスク間における rsync をボタン一発でできるようにするだけだ。

最新の rsync

macOS 標準の 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/NFS

Automator によるアプリ化

上記 rsync のコマンド内容のシェルスクリプトを Automator を使ってアプリ化する。

Automator の使い方自体については簡潔な解説があり参考になる。

2017年10月27日金曜日

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 に接続して NFS を使う──というのが元々の目的だった。これでできるようになったわけだが、実際に Eclipse で NAS にある作業ディレクトリーを使ってみたところ……重い。

というわけで、NAS を使ったクラウドドライブ化作戦は諦め、素直にローカルの作業ディレクトリーを使って、適宜 NAS にバックアップする体制にすることにした。つまり、rsync を使って、ローカル(Mac)のディレクトリとマウントした NFS の間でプットする。どの道、iCloud にせよ Google ドライブにせよ、クラウドストレージは実際そのような形式をとっているわけであって、常に NAS のストレージ上のファイル実体を直接読み書きしているわけではない(そうでないと、クラウドストレージはオフライン時に利用できない)。もちろん、クラウドストレージの場合はプットだけではなくプルも同程度行われることを前提としており、さらに他人との共有なども考えられている。しかし、僕が考えていた使い方に関しては、基本的にプッシュの一方通行だから、rsync だけ一発で行えるスクリプトなり、Automator アプリなりを用意しておけば済み、それが iCloud や Google ドライブで有料で大容量を使った場合と何ら差異はないという話である。

2017年10月26日木曜日

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 での管理者グループ ID

Ubuntu GNOME 16.04LTS では管理者グループの ID が admin ではなく、adm であった。にもかかわらず、sudoer のエントリーは %admin となっていたため、%adm と修正する必要があった。

注 3:visudo

visudo はその名の通り、vi がベースになっているので、操作がよくわからない場合は vi の情報を調べてみるとよい。

2017年10月25日水曜日

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 にアクセスする必要がある。myqnapcloud.com の方を使うと IP アドレスは当然グローバルアドレスになってしまうので、アクセスを拒絶される。

注 2: 公開鍵の作成

過去記事でも触れたが改めてここでもまとめておく。コマンドは:

ssh-keygen -t rsa -C "作成するキーペアに関するコメント情報"

どちらかというとパスフレーズは使わなくてもよい。

注 3: 公開鍵の QNAP NAS への配置

scp か sftp を使ってアップロードする。QNAP の場合、SSH や scp、sftp でログインした場合のホームは /root である。/share/homes/admin ではない。authorized_keys は /root/.ssh/authorized_keys として配置することになる。GUI の File Station で操作できる相手ではない点に留意する。

注 4: ssh/scp/sftp

ssh と scp/sftp とではポート(以下の例では 50022)の指定の指定方法に大文字小文字の違いがある。

ssh -p 50022 admin@192.168.0.1
scp -P 50022 (ローカルパス) admin@192.168.0.1:(サーバー側のパス)
scp -P 50022 admin@192.168.0.1:(サーバー側のパス) (ローカルパス) 
sftp -P 50022 admin@192.168.0.1

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 することができる。

2017年10月24日火曜日

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 のファイルが存在すると、そのフォルダが空っぽ状態でファイルのリストが見えなくなってしまうという問題が発生した。

また、反応速度のせいか、例えば Eclipse で work_space として WebDAV 経由のフォルダを指定すると、エラーが出て、使えないことが判明した。

以上から、WebDAV によるクラウドドライブの実現は諦めた。

VPN + SMB

こうなったらオーソドックスに SMB を使ってみるしかないと思い、そのために VPN を構築することにした。元々、実家のルーターの設定などをリモートでメンテナンスするために、PPTP を使った VPN サーバーは立てていた。古い Buffalo のルーターを DD-WRT 化したものを使っている。しかし、最近 PPTP がどうも不安定化しすぐに接続が切れる。それに PPTP は技術的に世間で非推奨であり、OpenVPN を使うべきなのはほとんど常識である。設定の手間があったので OpenVPN を避けてきたが、クラウドドライブ実現のためにはちゃんと OpenVPN 化するべきだと思って、今回チャレンジすることにした。

OpenVPN

基本的に作業は Ubuntu (16.04LTS) 上で行った。一般に Linux 用の OpenVPN についてネット上で見つけられる情報は、サーバー用とクライアント用がセットになった解説だが、僕の場合は、サーバー側は DD-WRT で運用するので、Linux についてはクライアントとしての使い方になる。とはいえ、認証局(CA)として各証明書ファイルを作成するのは同じ Ubuntu マシン上で行うので、openvpn パッケージをインストールしなければならないのはサーバーとして運用する場合と同じである。基本的に How To Set Up an OpenVPN Server on Ubuntu 16.04 という英語の解説の通りに従い上手く行った。

作業として必要なことは

  1. 認証局(CA)として各証明書ファイル(秘密鍵含む)を作成すること
  2. クライアント用の設定ファイルを作成すること

の 2 つである。サーバーは DD-WRT の機能を使うので、主に DD-WRT の GUI で各証明書ファイルの内容をセットすればいい。解説に従って作成したいくつかの証明書と秘密鍵の内容をコピー&ペーストした。また、ネットでは TUN を使う例が多かったが、TAP にした。DD-WRT では AES-512-CBC も選べるようになっていたが、Ubuntu 側が対応していないようだったので、AES-256-CBC で我慢することにした。

クライアント側としては、先程クライアントマシン上で作成したクライアント用各証明書ファイルを使った設定ファイルを作成をするスクリプトを解説ページが用意してくれているので、それを使って作成した。ただし、DD-WRT 側の設定に合わせて、dev tap や cipher、auth などは手動でカスタマイズする必要はあるだろう。

ポートマッピングを忘れずに

初めての作業だったので、解説ページに沿ってやったものの、最初は接続が失敗した。実は、OpenVPN サーバー(DD-WRT)側ネットワークのポートマッピングで、UDP 1194 を通す設定を行っていなかっただけであった。運良く、検索一発目でポートマッピングが原因で失敗するのが一番多いと書かれている OpenVPN の FAQ を見つけることができ、すんなり解決できた。

GNOME のネットワーク設定(Network Manager)

不安定化していた PPTP と比べて、OpenVPN で接続が確立されると非常に安定している。だが、ターミナルでコマンドを使って OpenVPN を動かしている形なので、PPTP の場合のように、GNOME の画面右上のネットワーク設定を使った GUI で使えるようにできないかと思って調べたら、流石は Linux、流石は GNOME。ありました。apt install network-manager-openvpn-gnome するだけ。これで新規のネットワーク接続設定を追加すると VPN ではファイルからのインポートを選べるので、上の作業で作成した .ovpn ファイルを選択すれば、あとは各種設定は自動でセットされる。流石!


Ubuntu 環境で安定に接続が確立できることは確認できた。これで Mac でも OpenVPN をセットアップし、さらに SMB でクラウド化した状態で、Eclipse などが使えるかどうかというチャレンジは、また次の機会に。


補足 1

VPN 経由で LAN にアクセスするには以上で十分だが、さらに LAN の内側からインターネットに出たい場合、DD-WRT 側で追加の設定が必要だった。Additional Config 欄に

push "redirect-gateway def1 bypass-dhcp"
push "dhcp-option DNS 192.168.0.1"
push "dhcp-option DNS 8.8.8.8"

という形で、クライアント側のネットワーク設定のデフォルトゲートウェイを(VPN 接続時に)上書きして必ず VPN 経由でインターネット側に出るようにし、さらに DNS サーバーのアドレスも指定しておく。

補足 2

OpenVPN のメッセージを見ていると、MTU の数値がサーバー⇔クライアント間で矛盾しているという警告が出ているので、色々と MTU 関係を調整した。

まず、実家は au ひかりであり、自分は WiMAX2+ なので、いずれも MTU は 1500 という理想的な環境である(ちなみに NTT の Flet's では PPPoE に加えて他にも余計なヘッダが入るため MTU は 1454 となる)。しかし、WiMAX ルーターの設定で MTU が設定できるようになっているが、なぜかデフォルトでは 1500 よりも低くしてあったので、ちゃんと 1500 にしておく必要があった。さらに、OpenVPN を運用するサーバー(DD-DRT)側もデフォルトで Tunnel MTU setting が 1400 にしてあったので、ちゃんと 1500 にする必要があった。Tunnel UDP Fragment は空欄(デフォルト)、Tunnel UDP MSS-Fix は無効(デフォルト)のままでよい。

以上で、OpenVPN をオンにしてもオフにしてもいずれも、ping コマンドで 1472 バイトのパケットがギリギリ通ることを確認した。

(ちなみに、Linux だけでなく Mac でも ping によるテストを行ったが、Linux と Mac では ping コマンドの仕様が違っていた。Linux では -M do オプションだったものが、Mac では -D オプションになっていた。)

2017年10月19日木曜日

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 用のオプションがあったというのは古い情報なのだろう。

以上で問題なくデータの移行が完了した。

2017年10月18日水曜日

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 時間かかった。

2017年10月15日日曜日

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 の中身を最新の dump にコピー&ペーストして置換してみたりもしてみたが、そのようにすると再び Applied Cape: None の扱いとなる。

通常の矢印のポインターについては特に支障ないので、仕方ないので、旧い Cursor Dump で運用している。

※別の対処方法としては、Automator を使って、Mousecape を起動し、Cursor Dump を適用する操作自体を記録し、それをログイン時の起動アプリとして登録する方法もある。ただしこちらはこちらで、なぜか、Bluetooth マウスを接続していると、起動アプリが実行されなかったりしても、不安定なところがあった。

AquaSKK

Mac で SKK と言えば、AquaSKK (4.4.5)

OS 側の完璧な設定方法は次の通り:

設定 > キーボード > 入力ソース

入力ソースの設定

1. 英語は [@] ASCII を追加

2. 日本語は [ア] カタカナ、[あ] ひらかな、[英] 全角英数、[カナ] 半角カナ、[あ] 日本語(※1)を追加(※2)

3. U.S. を削除

4. [あ] 日本語 を削除

5. 以上で、SKK のみの入力モード間での切り替えとなる。

※1 [あ] 日本語 は macOS デフォルトの日本語変換システム(旧ことえり)

※2 AquaSKK 統合は選択しない

その他

  • メニューバーに入力メニューを表示:ON
  • caps lock ⇄ control の入替:「設定 > キーボード」の右下の「修飾キー」において設定
  • 入力ソースの切り替えショートカットキー:(shift+)command+space

2017年10月11日水曜日

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 から解除を予告するメールが送信されてくるのだが、そのメールに記載された電話番号の表記を見て、ふと閃いたのである。

リセットの手続において、電話番号を以前の認証の受け取れない携帯の電話番号ではなく、IP 電話の番号にしておいたのだが、その番号が国際番号と合わせて +81 50XXXXXXXX という風にメールに記載されてあった。

ところが、2 ファクタ認証の画面で認証コードを送りましたと表記される携帯の電話番号は +81 070XXXXXXXX となっていたのである。「ああ、これのせいか!」と。

つまり、Apple ID(管理サーバー)のバグ。国内の電話番号の先頭に 0 を付けても付けなくても、登録を受け付けるようになっているわけだが、にもかかわず、実際は 0 を付けない、国際電話番号としての表記でしか、適切に扱えないという仕様上のバグである。

おそらく、2 ファクタ認証を使っている多くの人が、iOS デバイスを所有し、僕のように、非 iOS デバイスの携帯電話番号(SMS / 音声通話)のみというユーザーは稀なケースであり、かつ、国内と国際電話で 0 を付ける付けないという日本の電話の仕様がアメリカの電話の仕様と異なっているという事情から、このようなバグに Apple の中の人は未だ気付いていないのだろう。

Apple ID アカウント復旧後、念のために IP 電話の登録は残しておいて、改めて SMS 認証用に携帯電話番号を 0 抜きで登録し直しておいたのは、言うまでもない。

2017年10月10日火曜日

この 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 Store で使用されたことがありません」というエラー表示が出て、サインインを拒まれるのである。

ネット情報によると、クレジットカード情報を登録すればいいとか、iTunes アプリでサインインするといいなどといった情報が引っ掛かったのだが、すべて試したものの、依然として事態は打開できない。

まず、iTunes アプリでも、iBook アプリでも、App Store アプリと同じで「この Apple ID は、iTunes で使用されたことがありません」というエラー表示が出て同じ状態に陥る。Windows に iTunes アプリをインストールしても同じである。そもそもクレジットカード情報はウェブの Apple ID アカウントで入力して登録済。しかし、敢えてエラー表示からアカウントのレビュー表示へと進んで、改めて登録内容を入力し直そうとするが、クレジットカード情報を更新する画面で更新内容を確定できず、内容の説明なしに赤い文字で www.apple.com/support/itunes/ww/ を参照せよというエラー表示がフォーム脇に表示されるのみ。

これはもう、こちらのやり方が間違っているという次元の話ではなくて(そういう低次元の問題であれば、ウェブの情報と自分で試行錯誤すればどうにかできる)、Apple ID アカウントに関する Apple 側の管轄する問題であると判断し、サポートに電話した。

全体で連続 2 時間ほど要したが、あちこちの部署をリレーされ、最終的に、iTunes 担当のサポートの方で、アカウントのロックを解除。詳細は教えてくれなかったが、何らかのロックがかかっていたようだ。自分は、iPhone を所有したことがなく、今回、MacBook Pro を購入するにあたって初めて Apple ID アカウントを作成したので、そのあたりも関係したいたのだろうか? このロック解除で、クレジットカードの更新画面で出ていた www.apple.com/support/itunes/ww/ のエラー表示は出なくなったものの、依然として確定できない。

そこで、改めて、iTunes の担当から戻された Mac のサポート担当者に、iTunes アプリでのサインインを試すよう指示され、成功。ようやく、ネットで言われていた話へとつながり、App Store アプリでも「使用されたことがありません」エラーは解消されたのだった。

つまり、ネットの情報だけでは解決できなかった理由は、iTunes のアカウントのロックの問題と、「使用されたことがありません」エラーは App Store ではなくて iTunes アプリでしかアクティベーションが不可能である問題の、2 種の問題が重なっていたということのようだ。

Apple という会社は iPod (iTunes) → iPhone (iOS) を中心に会社が回ってきた経緯があるから、iTunes や iOS の利用を前提とせず、いきなり Apple ID アカウントを作って Mac だけを使い始めるユーザーのケースについて十分に設計が考慮されていない体制になってしまっていても、まあ不思議でない。しかし、1ユーザーの立場としては、Mac にはずっと憧れを持ってきたので(自分にとっては、あくまでも、今でも、iPhone は Mac の付属物的な位置付けである)、いきなり身に染み付いたエンジニア的習性による行為から、今回のようなハマリ事態に直面するとは、皮肉だ。すっかり Mac は、iPhone の(アプリをプログラミングするための)付属物の立場に、なり下りきっていたということを具体的に自分で身をもって思い知らされた形になったのだから。