u9fs

想定される読者

• 既に Plan9 サーバーを持っている
  
• 他に UNIX 系 OS を載せたコンピュータを持っている
  

Plan9 から unix ホストをマウントする

Plan9 からリモートの unix ホストに対して

• コマンドを実行したい
  
• ファイルシステム(FS)をマウントしたい
  

Plan9 からコマンド実行する

現在

• ssh
  
• vnc
  

単にコマンドの実行であれば、vnc は選択肢に入らない。
vnc が必要になるのは、コマンドの実行にグラフィックス環境が要求される場合だけである。(例えば QEMU や VirtualBox に Plan9 をインストールする場合が該当する)

ssh で unix にログインするときには必ずしも vt100 端末の環境は要求されない。むしろ vt コマンドを使わない方が遥かに使い勝手が良い。以下、それを「生の環境」と言う¹。 ssh で相手ホストに入り込むと、相手方のシェルが実行されている。ところが生の環境のままだとプロンプトを出さないので、面食らう。そういうものだと思ってそのまま使ってもよいが、嫌なら

bash -i

rc -i

• vt100 環境を前提としたテキストエディタは使えない
  
• パスワードの入力を求められるものも注意
  
• ctl-D の問題
  

unix ホストを Plan9 側にマウントする

• sshfs
  
• u9fs
  

• 1人だけの利用を想定している
  
• 通信路の暗号化を行っていない
  

Plan9 側からのアクセスの簡便性は u9fs が遥かに上である。factotum が使えるのでパスワードの手入力の必要はない。"maia" を unix ホストすれば

9fs maia

u9fs とは

u9fs とは、Plan9 と 9P プロトコルで通信する unix 側のファイルサーバーのソフト名である。u9fs を unix に組み込むと、その unix を Plan9 側からマウントできる。u9fs は Plan9 の配布の中に含まれている。

9fs コマンド

u9fs は UNIX のファイルシステムを Plan9 側にマウントしてくれる。sshfs も同様な機能を提供するが、u9fs の方が使いやすい。

以下に簡単な使用例を挙げる。
nx を UNIX システムとすると、

term% 9fs nx
post ...		# message
term%

term% ls /n/nx
term% ls /n/nx
...
/n/nx/bin
/n/nx/dev
/n/nx/etc
/n/nx/home
...
/n/nx/tmp
/n/nx/usr
term%

パスワードも入れずに認証されているのは、認証エージェント factotum が働いているからである。

9P プロトコル

9P プロトコルの名称

9P2000.u は風呂敷を広げすぎていると思う。多分挫折する。(挫折した?)
9P2000.u の後継として 9P2010 が提案されている[6,7]。

Plan9 以外では、現在ともかく動いているらしいのは 9P2000 のサブセットである[4]。主要な OS (macOS, Windows, Linux, FreeBSD) である程度使えるらしい¹。しかし僕は(現在のところ)論評するだけの材料を持ち合わせていない。

文献[1]が 9P に関する最も基本的な文献である。9P プロトコルの内容が解説されている。なおこの文献によると 9P は "Plan 9 File Protocol" の略語である。

9P は通信路に関しては何も定めていない。ここで言う「通信路」には、使用される暗号も含まれる。また認証の方式も定めていない。9P による接続が成功するためには認証の方式と暗号の選択に関するホストとクライアントとの交渉が成立しなければならず、それに応じた変種もまた発生し得る。例えば unix の 9P server である u9fs では「信頼できるホスト」による「認証」をも許している。

9P サービス

注: これらは同じものの別称(方言)である

Plan9 で使われた service ポートは 564 で、service 名は 9fs である。文献[2]によると 9fs は "Plan9 file service" の略語である。
Plan9 の中では 9fs の名称は現在も使われている。サービス名称としても、コマンド名称としても。
文献[2]によれば、u9fs で使用されるプロトコル名は 9fs にする予定だったらしい。しかし inetd のサービス名を数字から始められない unix システムが存在したために u9fs にしたとのことである。

文献

[1] man INTRO(5)
introduction to the Plan 9 File Protocol, 9P
http://man.cat-v.org/plan_9/5/

[2] U9FS(4)
http://man.cat-v.org/plan_9/4/u9fs

[3] E. Van Hensbergen: Plan 9 Remote Resource Protocol Unix Extension
https://ericvh.github.io/9p-rfc/rfc9p2000.u.html

[4] diod/protocol.md
https://github.com/chaos/diod/blob/master/protocol.md

[5] MOUNT_9P(8)
https://www.unix.com/man-page/mojave/8/mount_9p

[6] 9P2010
https://9p.io/wiki/plan9/9p2010/index.html

[7] 9P2010 Operations
https://9p.io/wiki/plan9/9P2010_Operations/index.html

u9fs のインストール

方針

• rhosts による「認証」(rlogin の方式と同じ)
  
• キーによる認証
  
• 認証不要
  

• /usr/local/sbin/u9fs # u9fs 本体
  
• /var/log/u9fs.log # log file
  
• /etc/u9fs.key # 認証情報を含むファイル
  

Ubuntu はクライアントとして初期設定されている。そのためにサービスに必要な inetd も xinetd も(多分)インストールされていない。インストールされて既に動いている可能性もあるので

ps aux | grep inetd

Mac は全く方法が異なるので、独立して解説する。

u9fs のインストール

unix$ make
unix$ su
root# cp u9fs /usr/local/sbin
root# touch /var/log/u9fs.log

Mac にインストールするなら筆者のをダウンロードするのが良いだろう。
理由は

• 古いコードの修正が終わっていること、
  
• 悪名高い Mac の UTF8-MAC 対策がされていること
  

次の図に UTF8-MAC 対策がされていないのと、いるのとの違いを示す。

u9fs	u9fs_mac

Mac の文字コードが抱える問題に関しては http:/p9p/#mac_nfd に簡単に解説されている。さらに詳しくは http://ar.nyx.link/unicode/ の「ダ問題」を見よ。

Mac 用のも
http:/netlib/u9fs/
に置かれている。

ネット情報によると macOS はバージョンアップして 10.x から 11.0 にさらに 12.0 に代わったとのことである。macOS が抱えていたファイル名の文字コードの問題は Apple がどこかで手を打つ必要があろうが、(筆者の環境は古く)今回改善されたかどうかは定かではない。

認証キーの設定

/etc/u9fs.key に利用者のキーを設定する。(この場所は u9fs の -A オプションで変更できる)
内容は例えば

blackcat
arisawa
poe

key proto=p9sk1 dom=poe user=arisawa !password=blackcat

sys=xxx
	dom=xxx.local
	auth=xxx
	ether=192.168.0.5
	ip=f02f74f8dc80

unix サーバーをいくつも持っている場合にも、共通の factotum キーで代用できる。

/etc/service

FreeBSD では /etc/services に

9pfs		564/tcp	   #plan 9 file service

inetd による設定

/etc/inetd.conf に

9pfs	stream	tcp	nowait	root	/usr/local/sbin/u9fs	u9fs -a p9any -l /var/log/u9fs.log

エッセンスは /usr/local/sbin/u9fs と tcp port 564 が関係づけられていることである。これは /etc/services の 9pfs と /etc/inetd の 9pfs で実現している。従って "9pfs" は原理的には何でもよいのであるが、他のサービス名と衝突してはならない。そうは言ってもあまりにも勝手な名前は好ましくはない。IANA 公認の名前は
http://www.iana.org/assignments/port-numbers
で手に入る。

xinetd による設定

今回は xinetd を使わなかったので、古い記事(2017/06/05)に対して最小限の修正を加える。内容が古くなっているかもしれない。

まず

ps -aux|grep inetd

次に /etc/xinetd.d/ に以下の内容のファイル 9pfs を追加する

service 9pfs
{
        disable         = no
        socket_type     = stream
        protocol        = tcp
        wait            = no
        user            = root
        server          = /usr/local/sbin/u9fs
        server_args     = -a p9any -l /var/log/u9fs.log
        groups          = yes
        flags           = REUSE
}

xinetd の設定を変更した場合には root 権限で

-bash$ sudo /etc/init.d/xinetd restart

注意 この辺の話は OS によって異なり、バージョンによっても異なる。
しかも最近は、コロコロ、コロコロと変わる。整理されたら改めて解説する。

netstat コマンド

Plan9 であれば netstat -n によってサービスが行われているポートが直ちに分かる。これに相当する macOSX あるいは FreeBSD のコマンドは netstat -anp tcp である¹。次に示すのはその出力例で

-bash$ netstat -anp tcp
Active Internet connections (including servers)
Proto Recv-Q Send-Q  Local Address          Foreign Address        (state)
tcp4       0      0  *.564                  *.*                    LISTEN
tcp6       0      0  *.564                  *.*                    LISTEN
tcp4       0      0  127.0.0.1.631          *.*                    LISTEN
tcp6       0      0  ::1.631                *.*                    LISTEN

netstat -ap tcp

netstat -ant tcp

OSX Leopard の plist による設定

OSX Leopard になって xinetd が無くなって launchd による plist に一本化された。設定例は次の通りである。

/Library/LaunchDaemons/com.bell-labs.plan9.u9fs.plist の内容

補注: Mac の場合、この古い(2008の)設定が、現在でもそのまま生きている。
/etc/services のサービス名は、あれから 9pfs に代わったが、どうやらこのファイルは使われていない。plist にサービスポート 564 が直接現れ、このポートと u9fs が結び付けられているのが解る。(2021/11/15 追加)

plist のロード

/Library/LaunchDaemons/ の com.bell-labs.plan9.u9fs.plist の設定を変更した後、それを Launchd に反映させるには

-bash$ sudo launchctl unload /Library/LaunchDaemons/
-bash$ sudo launchctl load /Library/LaunchDaemons/
-bash$

設定上の注意

僕はこれまで plist を設定した事がなかった。このために今回は大変手間取った。
C プログラミングの世界に住んでいる者にとって、plist における、実行されるプログラムとその引数の指定の方法は "???" になりやすい。つまり "ProgramArguments" を次のように書きやすいのである。

0	/usr/local/sbin/u9fs
1	u9fs
2	-l
3	/var/log/u9fs.log
4	-a
5	p9any

telnet loaclhost 564

initgroups (xinetd の groups) の値は YES でなくてはならない。Leopard でのデフォールトは YES であるが Tiger では NO なので、ここに上げた plist はそのまま Tiger では使えない。

参考になる文献

マニュアルによると plist の置き場所は次の 5 カ所である。

~/Library/LaunchAgents         Per-user agents provided by the user.
/Library/LaunchAgents          Per-user agents provided by the administrator.
/Library/LaunchDaemons         System wide daemons provided by the administrator.
/System/Library/LaunchAgents   Mac OS X Per-user agents.
/System/Library/LaunchDaemons  Mac OS X System wide daemons.

マニュアルは次の 3 つが基本的である。

• launchd(8)
  
• launchd.plist(5)
  
• launchctl(1)
  

• Getting Started with launchd
  http://developer.apple.com/macosx/launchd.html
  
• plist
  http://developer.apple.com/DOCUMENTATION/Darwin/Reference/ManPages/man5/launchd.plist.5.html
  
• launchctl(1)
  http://developer.apple.com/documentation/Darwin/Reference/ManPages/man1/launchctl.1.html
  

• 第1回 initを置き換えるlaunchd【前編】
  http://www.itmedia.co.jp/enterprise/articles/0704/26/news009.html
  

plist について

僕は Mac の plist のようなものは嫌いである。
マウスでの操作になるために、初心者は好むかもしれない。しかしそれは初心者の錯覚である。システムを管理する上で難しいのは操作ではなくて、設定の意味を理解することである。plist はそのために何の役にも立たない。

僕が好むのはテーブル形式の設定である。そのような例は /etc/inetd.conf に見られる。全体像が良く見え、豊富なコメントが含まれており、よく使われるものは、行頭のコメント記号を外せばよいだけである。テキストエディタの使い方さえ知っていれば苦労は要らない。

テーブル形式には欠点もある。よく設計されていないと、重要なフィールドが欠けていたと言うことになる。しかしフィールドの後追加は困難であり、後の祭りである。その点 xnetd で使われている形式は柔軟に対応できる。(面倒だけど... 解りにくいけど...)
しかし、(plist もそうだけど) 全体像が見えにくいのである。そのために設定を困難にする。
Plan9 のはうまくできている。非常に単純で、ポートごとにシェルスクリプトのファイルが指定され、それが実行されるだけである。シェルスクリプトであるから強力無比である。

sshnet

sshnet を使えば unix 側の u9fs と Plan9 の通信路が暗号で保護される。sshnet のアイデアは如何にも Plan9 らしいので紹介する。

hebe を Plan9 ホストとする。また maia を unix ホストとして u9fs が設定されているとする。すると hebe のコマンド

9fs maia

sshnet maia

種明かしをする。Plan9 では /net/cs と /net/tcp がネットアクセスに使われている。/net/cs は補助的である。tcp 通信には /net/tcp が使われる。これは仮想ネットワークデバイスのように働いている。従って、これを使わないと tcp 通信ができない。

sshnet を実行する前には

hebe% ls /net
/net/arp
/net/bootp
/net/cs
...
/net/tcp
/net/udp
hebe%

hebe% ls /net
/net/cs
/net/tcp
hebe%

このことを確認するために、実験をしてみる。sshnet を実行した window で

telnet hebe

hebe の IP アドレスは 192.168.0.6 である。hebe から hebe へのアクセスであるから、普通なら source アドレスは 192.168.0.6 となるはずである。ところが実際には telnet ポート 23 は

hebe% netstat -n
...
tcp  37   none       Established  23         48340      192.168.0.3
...
hebe%

maia$ netstat -nt tcp
...
tcp        0      0 192.168.0.3:48340       192.168.0.6:23          ESTABLISHED
...
maia$

hebe からのネットアクセスは全て maia を通り、hebe から maia へのルートは暗号化されたトンネルになっている。9fs による u9fs へのアクセスは、その特殊な形態である。

srvssh

次のような状況を考えてみよう。
alice は ホスト X のユーザーであるとともに、或る unix ホストの Y のユーザーでもある。どちらのホストにおいても alice はエンドユーザーであり、ホストに対する管理権は持たない。

alice は Y の自分のファイルを X にマウントして使いたい。

最近の unix ホストは sshd を動かしている。この場合、ユーザーは ssh でホスト Y にログインできるだけでない。sshfs で Y のファイルを X にマウントできるはずである。ただし X が sshfs をサポートしていれば... 現在 Linux、FreeBSD、macOS、Windows、Plan9 は sshfs によるマウントを許している。従って alice の要求は、現在では(特別なことをしなくても)実現していると考えてよい。

しかし alice は単に u9fs と言うものを使ってみたいのである。alice は既に u9fs をコンパイル済みである。しかしホスト Y の管理者は厳しくて、サービスポートを勝手に使わせてくれない。

ホスト Y が ssh によるログインを許していれば、そして X が Plan9 であれば、srvssh コマンドで、Y のファイルを X にマウントできる。この方法の利点は、ホスト X,Y の管理者権限を必要としない事にある。

以下を確認する:

1. X から Y に ssh でログインできる事を確認する
   
2. Y において u9fs へのパスが通っている事を確認する
   u9fs を $HOME/bin に置けば大丈夫なはずである(要確認)
   
3. X にて
   

term% srvssh Y
post...
term% mount /srv/Y /n/Y
term% ls /n/Y
/n/temp/.DS_Store
/n/temp/.Trashes
...

srvssh は、9fs ポート 564 を使わずに、ホスト X と ホスト Y を結ぶ(ssh が作った)私的な通信路を使った u9fs だと考えてよい。
この利点は、

• 認証系は ssh のを使える
  
• 独立して動くので、複数のユーザーが同時に u9fs を使用しても問題が発生しない
  
• 通信路が暗号化されている
  

/rc/bin/srvssh はシェルスクリプトであり、やっていることは容易に理解できる。大雑把に言えば以下のとおりである。Plan9 ホスト X で

srvssh Y

srv -e 'ssh Y u9fs -na none -u ''$''USER -l ''$''HOME/u9fs.log' Y /n/Y

ssh Y u9fs -na none -u '$'USER -l '$'HOME/u9fs.log

u9fs -na none -u $USER -l $HOME/u9fs.log

u9fs は alice のプロセスとして起動される。"$USER" は alice であり、"$HOME" は alice のホームディレクトリである。これを見ると srvssh で起動した場合の u9fs のログファイルの位置が判る。

さて alice はホームディレクトリ /home/alice に u9fs.log を作成し srvssh Y を実行したが

u9fs: cannot open log '$HOME/u9fs.log'

この問題は /rc/bin/srvssh の中の

-u ''$''USER -l ''$''HOME/u9fs.log

-u alice -l /home/alice/u9fs.log

-u $USER -l $HOME/u9fs.log

USER=alice HOME=/home/alice svssh Y

このやり方は相手方(Y)が Ubuntu の場合も FreeBSD の場合も問題なく働く¹。そこで僕は現在次のような rc スクリプト mnt を作って使っている。便利だから紹介しておく。

#!/bin/rc
rfork e
if(~ $#* 0){
  echo mnt hebe
  echo mnt hera
  echo mnt bsd
  echo mnt mbook
  echo mnt pi
  exit
}

switch($1){
case hera bsd	# FreeBSD
	sshfs -m /n/bsd -r / arisawa@hera
case maia	# Ubuntu
	USER=arisawa HOME=/home/$USER svssh maia
case mbook	# Macbook
	9fs mbook
case pi		# RasPi
  sshfs -r / -m /n/$1 pi@$1
}

mnt

汎用にはなっていない。このようなものは、各自の環境と好みに応じて内容を決めればよいだけである。
実は、使っている OS ごとに mnt コマンドを作っている。実際に実行される内容は X と Y に依存した最適な方法を採用している。

ssh ポートの入出力は、古い(RS232C)時代の通信と相手が人間であると想定しており、そのために byte 通過性が担保しずらい。通信路を byte 透過にする方法は相手 Y(unix) に依存する。旨く働くには多少の試行錯誤が要求されるかも知れない。その場合、やるべきことは

/rc/bin/srvssh

ダ問題

さて、このような嫌らしい Mac のファイル名が Plan9 に流れ込むのは嫌なので、パッチを当てることにしていた。今回、文字コードの対応を日本語文字だけではなく、全てのラテン系の文字、およびギリシャ文字に拡張した(2017/06/23)。

終わりに

Windows では?

僕は Windows を使わないので、個人的には興味は無い。

unix ホストを unix ホストにマウントする

現在は unix ホストを unix ホストにマウントする手段として sshfs が広く普及している。また sshfs は unix ホストを Plan9 ホストにマウントするのにも使える。従って sshfs は現在のマウント方式のスタンダードである。しかし近い将来に sshfs に代わって 9P によるマウントが普及する兆しがある。3大OS (Linux、Mac, Windows) が 9P を採用しだしたからである。

9P に基づく unix 側のサーバーとして u9fs を紹介したが、これは個人利用を想定したシンプルな認証メカニズムしか持っていない。Plan9 側から利用するにはこれでも上手くやっていける(srvssh)。unix が Plan9 の srvssh に相当する仕組みを持っていれば問題はないが、筆者はそのような仕組みが存在するか否かは知らない。

u9fs をサーバー仕様に作り変えた(と称する)フリーソフトとして spfs がある。

A multi-threaded replacement of u9fs

Ref[3] によると他にも多数あるようだが... 僕は動作を確認できていない。

References:
[1] https://github.com/nuxlli/spfs ? NO. latest version? No packages published.
[2] https://sourceforge.net/projects/npfs/ ? YES.
[3] http://9p.cat-v.org/implementations