サーバー上に複数のユーザー（たとえば、ローカルネットワーク上のファイルワイプ）を持つ共有ディレクトリがある状況では、すべての登録ユーザーに読み取りおよび書き込み権限を付与する必要がある場合に問題に直面する可能性があります。
この状況はすでにHabréで議論されているため
、ユーザー
karapuz からの記事を文字通り引用することができます。
ここで何ができますか？ いくつかの決定がすぐに思い浮かびます。
1.共有ディレクトリに対応するumaskを設定します。
2.適切なデフォルトaclをインストールします。
3. SGIDビットを設定します。
まあ、彼らは解決策の1つを適用した、または一度に適用した。 すべてが機能しているようです。 両方のユーザーは共有ディレクトリのコンテンツ全体へのフルアクセス権を持ち、このディレクトリの新しいファイルはその権限を継承しますが、カメラからこのディレクトリに写真をスローしました。 あなたの妻はユーザーの下でシステムに入り、不十分な権限についてのメッセージを保存するときにのみこれらの写真を少し変更することにします。 コピーしたファイルは共有ディレクトリの権限を継承していませんでした。 なんで？ はい、cpユーティリティはumaskとaclを考慮しないためです。 元の権利を保持したままファイルをコピーするか、権利が減らされます。すべてコピーするディレクトリの権利に依存します。
この問題の解決策として、
karapuzは2つの
famまたは
gaminファイルシステム監視
デーモンの1
つとfileschangedユーティリティを使用することを提案しました。
しかし、実際に示したように、これらのデーモンは両方とも、特にユーザーが制御されたディレクトリ内のファイルをアクティブに操作している場合、サーバーに大きな負荷をかけます。 ネットワークでは、
gaminがプロセッサ時間の最大30％を消費するというユーザーの苦情を見つけることができます。 私は同じ失望した結果を得たと言うことができます。 鉄片の負荷を軽減するために、前述のユーティリティの代わりに、
inotify-toolsパッケージの
inotifywaitユーティリティを使用することにしました。
sudo apt-get install inotify-toolsinotifywaitは、inotifyインターフェイスを使用して、ディレクトリとファイルへの変更を巧妙に追跡します。
したがって、状態の変化を監視するプログラムがあります。必要なディレクトリをフィードし、再起動後に強制的に実行する必要があります。
これが私のサーバー上のサンプルソリューションです。 ディレクトリ
/ home / sharez /の権限を監視する必要があるとしましょう
ランチャー/usr/local/bin/inotifywait.shを作成します
sudo nano /usr/local/bin/inotifywait.sh
#!/bin/sh
#
inotifywait -mrq -e close_write -e moved_to -e create --format "%w%f" "$1" | while read "FILE"
do
if [ -d "$FILE" ]; then
chown -R nobody:nogroup "$FILE"
chmod -R a+rwX "$FILE"
elif [ -f "$FILE" ]; then
chown nobody:nogroup "$FILE"
chmod a+rw-x "$FILE"
fi
done
:よく見ると、ディレクトリの権利と所有権が再帰的に設定されていることがわかります。 再帰アクションは追加の重要なオーバーヘッドであるため、なぜこれが行われるのですか？ 実際、
inotifywaitはファイルまたはディレクトリのiノードのみを監視します。 また、ディレクトリをコピーするときに
作成イベントがすべてのファイルとサブディレクトリに影響し、同じ物理パーティション内で移動する場合、
moved_toイベントは移動したディレクトリに
のみ影響し（ディレクトリiノードでの操作は知っていますが、その中のiノードは変更されません）、サブディレクトリには影響しませんそしてその中のファイル。 その結果、移動操作を実行すると、最も重要なものが失われる可能性があります。そのため、すべてを開始しました-権利の継承。 したがって、特に多数のファイルを同時に移動する操作がほとんど実行されないため、パフォーマンスを犠牲にすることにしました。
ここで、
init.dのスクリプトを作成する必要があります
rc.localの起動オプションが気に入らなかったので、
init.dで 実行中の
inotifywait.shスクリプトは次のようになります。
sudo nano /etc/init.d/inotifywait.sh
#! /bin/sh
case "$1" in
start|"")
rm -f /tmp/inotifywait.log
/usr/local/bin/inotifywait.sh /home/sharez/ >/tmp/inotifywait.log 2>&1 &
;;
restart|reload|force-reload)
echo "Error: argument '$1' not supported" >&2
exit 3
;;
stop)
# , inotifywait
;;
*)
echo "Usage: inotifywait.sh [start|stop]" >&2
exit 3
;;
esac
:
スクリプトを実行可能にします。
sudo chmod a+x /usr/local/bin/
sudo chmod a+x /etc/init.d/inotifywait.shブートスクリプトをランレベルに追加して実行します：
sudo update-rc.d inotifywait.sh defaults
sudo service inotifywait.sh start
すべての場合と同様に、サーバー上で多くの人が自分のファイルを操作したときに定期的にキャッチした、たるみのあるパフォーマンスは消えました。
同時に、一方の問題を解決しました。ご覧のとおり、スクリプトのアクセス権に加えて、所有者とグループも任命しています。 実際には、このようなスクリプトのいくつかは、aclに頼らずに、同じバイナリ権でオフィス内のドキュメントフローを管理します。 文書は部門ごとに特定の方法で処理され、常に1つの部門のみが編集（または読み取り）権限を持ちます。
UPD：名前を少し変更しました。現在は元の
karapuzの記事との一貫性が低くなりましたが、実際はそうではありません。