10年以上にわたって、私は小規模オフィス（現在、サーバー1台、ユーザー7人、デスクトップ3台、ノートパソコン4台）でDebian環境全体で働いてきました。認証はKerberosに基づいており、ユーザープロファイルはLDAPによって管理され、$ HOMEはpam_mountまたはautofsの助けを借りてNFSv4を介してすべてのクライアントに提供されます。この設定は、ローカルLANで作業しているデスクトップユーザーに最適です。
2年前、私はラップトップユーザーに同じ設定を使い始めました。 WiFi接続により追加の速度低下が発生し、間違いなくユーザーがオフィスの外でラップトップを使用しようとすると、非常に遅くなりました。 $XDG_{CACHE,DATA,CONFIG}_HOME を最適化し、NFS で Firefox の特定の最適化を調査した結果、状況は少し良くなりました。
私は今$ HOMESをラップトップ+デスクトップに移動することを検討しています。デバイスに障害が発生した場合、ユーザーがデバイスを切り替えることができることは良いですが、そのようなことは時々発生します。より速い日常的なユーザーエクスペリエンスのために、これらの柔軟性を犠牲にすることは良い決断のようです。開始および終了時にローカル$ HOMEを中央サーバーに双方向に同期できる場合は、まったく妥協がない可能性があります。
- "unison"はローカルの$ HOMEを中央のレプリカと同期させるのに適した候補のように見えますが、サーバーとクライアント間でまったく同じバージョンが必要なようです。これについては大胆ではありません。
- "lsyncd"は非常に良い候補だと思いますが、$ HOMEディレクトリにそのツールを使用するユーザーストーリーが見つからないようです。
- 「GlusterFS」もちょっと見ましたが、それほど重要な選択肢ではないようです。共有する経験やベストプラクティスがある人はいますか？いくつかの実験は関係ありませんが、上記の明らかな欠点のいくつかを見逃しているようです...ありがとう！
答え1
私は使う物事を同期このような設定では、ホームディレクトリ全体またはホームディレクトリのサブセットです。ファイルを双方向または一方向に同期できます。ユーザーが異なる2つの場所で同じファイルを変更しない場合、競合する変更があっても透明でうまく処理されます。データは失われません。
ある程度傾いたバージョンで動作します。さまざまな電話やコンピュータで動作します。電話機は自動的に最新バージョンを追跡し、コンピュータはディストリビューションにインストールされているすべてのバージョンを使用します。フルホームディレクトリ同期は、構成ファイルの変更により、展開が同じコンピュータでのみ実際に機能しますが、部分同期は異なる設定で機能します。
SyncthingはLAN上で非常にうまく動作しますが、インターネットを介した同期もサポートし、関心のある信頼レベルに合わせて調整できるように設定できます。
答え2
@marcus-müllerが指摘したように、この機能は「ローミングユーザープロファイル」として広く知られており、次の2つの主な要素を中心に構築されています。
- ユーザー資格情報
- ユーザー $HOME ディレクトリ
最初の問題は、通常、クライアントのLDAP + KerberosやSSSDなどの集中型システムで解決されます。 2番目の問題はNFSv4およびkrb5/krb5i/krb5pを使用して解決できますが、クライアントがWiFiを使用している場合、またはリモートの場所にいる場合は遅くなる可能性があります。
ユーザーのために集中型の $HOME を放棄したいが、集中型設定の柔軟性を完全に放棄したくない場合、回避策は次のとおりです。
- ログイン後にrsyncスクリプトを実行します（存在しない場合はローカル$ HOMEを生成します）。ローカルの $HOME を中央の $HOME と双方向に同期します。
- ログアウトしたら、rsyncスクリプトを実行してすべてのローカル変更を中央の$ HOMEにアップロードします。
- (オプション)間欠同期の実行
/etc/gdm/PostLogin/Defaultログイン（）およびログアウト（）時にスクリプトを実行するようにGDMを設定できます/etc/gdm/PostSession/Default。断続的な同期のためにcronjobまたはsystemdタイマーを設定できます。
心に浮かぶいくつかの注意事項：
- $HOME ディレクトリのサイズを制限してみてください。たとえば、ユーザーが共有文書を保存できる別のディレクトリとクォータを使用します（全体的な速度低下の問題なしにNFSを介して共有できます）。
- キャッシュとtmpディレクトリを省略するようにrsyncスクリプトを最適化します。 （または$ XDG_CACHE_HOMEと$ XDG_DATA_HOMEを$ HOMEの外に再配置することもできます。）
/編集：ローカル$ HOMEをリモート$ HOMEと同期させるのに役立つシェルスクリプトを公開しました。https://github.com/zenlord/vagabond.sh-コメント歓迎:)
答え3
ログイン中にセントラルサーバーからホームディレクトリをインポートし、ログアウト時に再同期することもPAMを介して実行できます。パムスクリプトモジュール - 適切な rsync コマンドを呼び出すために使用します。
答え4
"unison"はローカルの$ HOMEを中央のレプリカと同期させるのに適した候補のように見えますが、サーバーとクライアント間でまったく同じバージョンが必要なようです。これについては大胆ではありません。
サーバーに複数のバージョンをインストールできます。addversionno = trueサーバーで実行するようにUnison構成ファイルに設定を割り当てます。unison-VERSION
サーバーに複数のバージョンをインストールできます。自分で作る手間が欲しくないなら公式バイナリDebian パッケージは Glibc にのみ依存します。公式パッケージは現在Ubuntu 18.04に構築されていますが、実際には古いシステムでも動作します。
独自のバージョンをインストールする場合は、セキュリティの問題を監視する必要があります。私はDebianでセキュリティアドバイスを見たことを覚えておらず、（比較的新しい）内容もありません。Github問題トラッカーしかし、それはそのようなことが起こらないという意味ではありません。
Unisonのバージョンが一致する必要があるだけでなく、ビルドされたOCamlのバージョンも一致する必要があります。一方、オペレーティングシステムとCPUアーキテクチャは一致する必要はありません。
したがって、技術的な観点から見ると、ユニソンは大丈夫です。しかし、これがユーザーの観点から適切かどうかはわかりません。紛争が発生した場合、ユーザーは和解する方法を話す必要があります。これはすべての双方向同期システムに固有であるため、ここで問題はUnisonを使用するかどうかではなく、双方向同期を使用するかどうかです。ユーザーが複数のデバイスで交互に作業できるようにすることが目標である場合は、実際には双方向同期が必要です。ただし、デバイスが破損している場合に高速フェールオーバーを許可することが目標である場合、バックアップとリカバリはより良いアプローチです。