以下の内容を長く読んで申し訳ありません。これは誰かが私を助けるのに十分なコンテキストとトレースを提供することを願っています。
コンテキスト
一部のzfsデータセット(ユーザーごとに1つ)にユーザーのホームディレクトリを保存します。ここでは、各ユーザーは各Linuxディストリビューションとバージョン(Debian Busterなど)ごとに異なるホームディレクトリを持ちますが、実際にはすべてダウンロードまたはディレクトリのXDGディレクトリです。デスクトップはすべて同じディレクトリを指すため、ユーザーは実行中の端末からログインしているLinuxディストリビューションに関係なく、すべてのファイルにアクセスできます。私が家に保管しているバイナリも構造が同じです。以下の例を参照してください(下かっこ内の数字が何を意味するかを確認してください)。
/media/zfs/home/user1/XDG-DIRS/[1]Downloads
| /[2]Videos
| /<some more directories and files>
|
/homes/[3]debian_buster/<some files(1)>
| /[4]ubuntu_groovy/<some files(2)>
|
/[5]usr/share/<some files(3)>
| /include/<some files(4)>
|
/local/linux-x86_64/[6]bin
| /[7]lib
|
/linux-armhf/[8]bin
/[9]lib
上記の構造のポイントを修正するために、特定のマウントを使用すると、ディストリビューションとそのバージョンで提供されているデスクトップ環境に一致するすべてのユーザー設定ファイルを使用してホームディレクトリを再構築できますが、オペレーティングシステムでもまだすべての個人用ファイルにアクセスできます。システムホームインストール用の互換バイナリおよびユーザーログイン用のスキーマ。たとえば、ユーザーがx86_64アーキテクチャで実行されているLinux Debian Busterにログインするとき、ホームディレクトリ構造は次のようになります。ディレクトリ名の末尾の角カッコ内の数字は、そのディレクトリの内容が実際に上記の構造の名前の先頭に同じ数字を持つディレクトリの内容であることを示します。 ubuntu groovyを実行しているRaspberry Piにログインしたユーザーのホームディレクトリがどのように見えるかを考えてみましょう。
/home/AD.EXAMPLE.COM/user1[3]/Downloads[1]
/Videos[2]
/.local[5]/bin[6]
/lib[7]
これは、ターミナルシステムでautofsを実行し、必要な数のnfsをマウントする実行可能マップファイルを使用して達成できます(上記の例では、ユーザーごとに5つ、通常はそれ以上、XDGカタログ以上)。私が予想する問題は、ユーザーが「ダウンロード」から「ビデオ」にファイルを移動したい場合は、2つの異なるnfsマウントポイントなので、ファイルが実際に端末にダウンロードされてからサーバーに再アップロードされることです。実際、これがパフォーマンスの低下をもたらすかどうかをテストしていません。これについての洞察力があれば教えてください。
上記のパフォーマンスの問題を制限するために、実際にautofsを使用してサーバーの各展開/バージョン(片側)と各OS /アーキテクチャ(もう一方)のホームディレクトリを再構築し、NFSを介して結果をエクスポートします。これは、autofsバインドマウントを使用してサーバーに次の構造を構築することを意味します。
/media/user_data/unix/user1/home/[10]debian_buster/Downloads[1]
| | /Videos[2]
| | /.local/<empty>
| /ubuntu_groovy/Downloads[1]
| /Videos[2]
| /.local/<empty>
/[11]local/linux-x86_64[5]/bin[6]
| /lib[7]
/local/linux-armhf[5]/bin[8]
/lib[9]
/etc/auto.master.d/user_data.autofs
(サービス - 端末)
/media/user_data/unix/ /etc/auto.AD.EXAMPLE.COM.unix --ghost --timeout=120
/etc/auto.AD.EXAMPLE.COM.unix
(ugo用に設定されたサーバー側、実行可能および読み取りビット)
#!/bin/bash
key=$1
echo '- /home -fstype=bind :/media/zfs/home/'$key'/unix/ browse \'
for i in $(ls /media/zfs/home/$key/unix)
do
for j in $(ls /media/zfs/home/$key/XDG_DIRS)
do
echo ' /home/'$i'/'$j' -fstype=bind :/media/zfs/home/'$key'/XDG_DIRS/'$j' browse \'
done
done
for i in $(ls /media/zfs/home/$key/usr)
do
echo ' /local/'$i' -fstype=bind :/media/zfs/home/'$key'/local/ browse \'
for j in $(ls /media/zfs/home/$key/usr/$i)
do
echo ' /local/'$i'/'$j' -fstype=bind :/media/zfs/home/'$key'/usr/'$i'/'$j' browse \'
done
done
echo ''
以下は、上記のスクリプトの出力例です。
root@server:~# /etc/auto.AD.EXAMPLE.COM.unix user1
- /home -fstype=bind :/media/zfs/home/user1/unix/ browse \
/home/debian_buster/Downloads -fstype=bind :/media/zfs/home/user1/XDG_DIRS/Downloads browse \
/home/debian_buster/Videos -fstype=bind :/media/zfs/home/user1/XDG_DIRS/Videos browse \
/local/linux-armhf -fstype=bind :/media/zfs/home/user1/local/ browse \
/local/linux-armhf/bin -fstype=bind :/media/zfs/home/user1/usr/linux-armhf/bin browse \
/local/linux-armhf/lib -fstype=bind :/media/zfs/home/user1/usr/linux-armhf/lib browse \
/local/linux-armhf/sbin -fstype=bind :/media/zfs/home/user1/usr/linux-armhf/sbin browse \
/local/linux-x86_64 -fstype=bind :/media/zfs/home/user1/local/ browse \
/local/linux-x86_64/bin -fstype=bind :/media/zfs/home/user1/usr/linux-x86_64/bin browse \
/local/linux-x86_64/lib -fstype=bind :/media/zfs/home/user1/usr/linux-x86_64/lib browse \
root@server:~#
私にとっては少し遅いですが、これまでは完璧に動作します。/media/user_data/unix
次のエクスポートファイルを使用してNFS経由でエクスポートしました。
# <other exports of unrelated directories>
/media/user_data *(sec=krb5p,rw,crossmnt)
# <other exports of unrelated directories>
この時点で、このファイル階層に "user_data"ステップが存在する1つの理由は、エクスポート時に/media/user_data/unix
(/etc/exportfs
または/media/unix
以下に説明されていないがそれに対応する場合)、以下の警告が表示されるためであることに言及する価値があります。これは有益ではありませんが、エクスポートするレイヤーにインストールされているものをエクスポートするuser data
ために、とにかくレイヤーでこの追加のレイヤーを使用しようとします。crossmnt
システムはこの試みについて文句を言わないようです。
root@server:~# cat /etc/exports
# Other exports of unrelated directories
/media/user_data *(sec=krb5p,rw,crossmnt)
/media/user_data/unix *(sec=krb5p,rw,crossmnt)
# More unrelated exports
root@server:~# exportfs -ra; zfs share -a
exportfs: /etc/exports [5]: Neither 'subtree_check' or 'no_subtree_check' specified for export "*:/media/user_data".
Assuming default behaviour ('no_subtree_check').
NOTE: this default has changed since nfs-utils version 1.0.x
exportfs: /media/user_data/unix does not support NFS export
root@server:~# showmount -e
Export list for server:
/media/user_data *
/media/user_data/unix *
# <nfs exports of unrelated zfs datasets>
root@server:~#
以下のテキストでは、NFSサーバーがNFSエクスポートをサポートしていないディレクトリについて文句を言わないように、エクスポートを削除して実行し/media/user_data/unix
まし/etc/exports
た。最後に、ターミナルシステムのautofsは、実行中のディストリビューションとバージョンに対応するホームディレクトリと、オペレーティングシステムとアーキテクチャに対応するサブディレクトリだけをマウントする必要があるため、Linux Debian Buster x86_64のuser1の階層は次のとおりです。exportfs -ra
zfs share -a
local
/home/AD.EXAMPLE.COM/user1[10]/Downloads
/Videos
/.local[11]
次のautofs設定を使用してこれを達成しようとしました。
/etc/auto.master.d/home.autofs
(ターミナル、Linux Debian Buster、x86_64)
/media/AD.EXAMPLE.COM /etc/auto.AD.EXAMPLE.COM.home --timeout=120
/etc/auto.AD.EXAMPLE.COM.home
(ターミナル、Linux Debian Buster、x86_64、ugo用に設定された実行および読み取りビット)
#!/bin/bash
key=$1
distributor()
{
lsb_release -i | cut -f 2 -d : | xargs echo | tr '[:upper:]' '[:lower:]'
}
codename()
{
lsb_release -c | cut -f 2 -d : | xargs echo | tr '[:upper:]' '[:lower:]'
}
architecture()
{
uname -m | tr '[:upper:]' '[:lower:]'
}
os()
{
uname -s | tr '[:upper:]' '[:lower:]'
}
echo '- / -fstype=nfs,vers=4.2,sec=krb5p,fsc server.example.com:/media/user_data/unix/'$key'/home/'$(distributor)'_'$(codename)' \'
echo ' /.local -fstype=nfs,vers=4.2,sec=krb5p,fsc server.example.com:/media/user_data/local/'$key'/local/'$(os)'-'$(architecture)' \'
echo ''
以下は上記のスクリプトの出力例です。
root@terminal:~$ /etc/auto.AD.EXAMPLE.COM.exp user1
- / -fstype=nfs,vers=4.2,sec=krb5p,fsc server.example.com:/media/user_data/unix/user1/home/debian_buster \
/.local -fstype=nfs,vers=4.2,sec=krb5p,fsc server.example.com:/media/user_data/local/user1/local/linux-x86_64 \
root@terminal:~$
質問
ターミナルコンピュータのautofsは、サーバーからエクスポートされた再構成されたホームディレクトリをマウントできません。以下は、リストを一覧表示しようとしたときに自動マウントから取得したトレースです/home/AD.EXAMPLE.COM/user1
。
root@terminal:~# automount -d -f -v
... <lots of output>
get_nfs_info: called with host server.example.com(192.168.80.101) proto 17 version 0x30
get_nfs_info: nfs v3 rpc ping time: 0.000000
get_nfs_info: host server.example.com cost 0 weight 0
prune_host_list: selected subset of hosts that support NFS3 over TCP
mount_mount: mount(nfs): calling mkdir_path /media/AD.EXAMPLE.COM/user1
mount_mount: mount(nfs): calling mount -t nfs -s -o vers=4.2,sec=krb5p,fsc server.example.com:/media/user_data/unix/user1/home/debian_buster /media/AD.EXAMPLE.COM/user1
>> mount.nfs: mounting server.example.com:/media/user_data/unix/user1/home/debian_buster failed, reason given by server: No such file or directory
mount(nfs): nfs: mount failure server.example.com:/media/user_data/unix/user1/home/debian_buster on /media/AD.EXAMPLE.COM/user1
do_mount_autofs_offset: mount offset /media/AD.EXAMPLE.COM/user1/.local at /media/AD.EXAMPLE.COM/user1
mount_autofs_offset: calling mount -t autofs -s -o fd=16,pgrp=20379,minproto=5,maxproto=5,offset automount /media/AD.EXAMPLE.COM/user1/.local
mounted offset on /media/AD.EXAMPLE.COM/user1/.local with timeout 120, freq 30 seconds
mount_autofs_offset: mounted trigger /media/AD.EXAMPLE.COM/user1/.local at /media/AD.EXAMPLE.COM/user1/.local
dev_ioctl_send_ready: token = 114
mounted /media/AD.EXAMPLE.COM/user1
何もリストされていません/home/AD.EXAMPLE.COM/user1
。
root@terminal:~$ ls /home/AD.EXAMPLE.COM/user1
root@terminal:~$
サーバーのいわゆるマウントディレクトリがファイルでいっぱいであるにもかかわらず、
root@server:~# ls /media/user_data/unix/user1/home/debian_buster
file1 file2 file3
root@server:~#
上記の自動マウントトレースは、私がマウントしたいディレクトリがサーバーに存在しないことを意味しますが、奇妙です。まず、サーバーで正しいディレクトリを一覧表示しようとすると、ディレクトリが存在することを示し(上記を参照)、とにかくこのディレクトリをマウントできます。端末で次のように手動でマウントします。
root@terminal:~$ mount -vvvv -t nfs server.example.com:/media/user_data/unix/user1/home/debian_buster /mnt
mount.nfs: timeout set for Sat Feb 13 22:37:06 2021
mount.nfs: trying text-based options 'vers=4.2,addr=192.168.80.101,clientaddr=192.168.104.1'
mount.nfs: mount(2): No such file or directory
mount.nfs: trying text-based options 'addr=192.168.80.101'
mount.nfs: prog 100003, trying vers=3, prot=6
mount.nfs: trying 192.168.80.101 prog 100003 vers 3 prot TCP port 2049
mount.nfs: prog 100005, trying vers=3, prot=17
mount.nfs: trying 192.168.80.101 prog 100005 vers 3 prot UDP port 39874
root@terminal:~$ ls /mnt
file1 file2 file3
root@terminal:~$
解決策に対する私の試み
ターミナルのautofsがまだサーバーにインストールされていないため、インストールするディレクトリが見つからない可能性があると思い、オプションを試してみましたが--ghost
(browser
上記のサーバー/etc/auto.master.d/media.autofs
とファイルに表示されます/etc/auto.AD.EXAMPLE.COM.unix
)、それは機能しませんでした。永続的な解決策を探索して見つけるためのオプションが不足しています。
一時的な解決策
現在使用されている一時的な回避策は、サーバー側でautofsを使用するのではなく、すべてのディレクトリを手動でバインドしてエクスポートする正しいファイル階層を取得することです。永久に有効にするには、多くのインストールが必要で、サーバーを不安定な状態にしているように見えるため、このソリューションはあまり満足できません。理由は正確にはわかりませんが。
コメント
- 私のテストでは、サーバーと端末の両方がDebian Buster(Linux x86_64)を実行していて、上記のトレースを生成しました。
- NFSは、autofs-reconstitutionedディレクトリがNFSエクスポートをサポートしていないと文句を言います。これは、親ディレクトリを秘密にエクスポートしてまったくエクスポートしようとしないことを意味します。 autofsがマウントされたサブディレクトリを含むディレクトリをNFSにエクスポートできないという内容の参照が見つからないため、試してみる価値があります。また
mount --bind
、autofsを使用するのではなく、サーバー側でこれらのサブディレクトリを手動で設定すると正しく機能するため、少し希望があります。 - これはやや複雑で壊れやすい設定です。同じ機能を達成するためのより簡単でより強力な提案があれば、私も興味があるでしょう。 :)
ベストアンサー1
デフォルトでは、クライアントは最初にNFSv4を試しているようです。手動でインストールすると、NFSv3に置き換えられます。 Autofsは最初の失敗を放棄する可能性が高いです。
NFSv3 を最初に使用するようにデフォルトのクライアント動作を調整することもできます。