लिनक्स मशीन पर साझा निर्देशिका, v2

ऐसी स्थिति में जहां सर्वर पर कई उपयोगकर्ताओं के साथ एक साझा निर्देशिका होती है (उदाहरण के लिए, स्थानीय नेटवर्क पर फ़ाइल-वाइप पर), आपको सभी पंजीकृत उपयोगकर्ताओं को पढ़ने और लिखने की अनुमति देने के लिए समस्या का सामना करना पड़ सकता है। इस स्थिति पर पहले से ही हैबे की चर्चा की गई थी, इसलिए मैं खुद को उपयोगकर्ता करापुज से एक लेख को उद्धृत करने की अनुमति दूंगा :

यहां क्या किया जा सकता है? कई निर्णय तुरंत दिमाग में आते हैं:

1. साझा निर्देशिका के लिए इसी umask सेट करें;
2. उपयुक्त डिफ़ॉल्ट एसीएल स्थापित करें;
3. SGID बिट सेट करें।

ठीक है, उन्होंने एक ही बार, या सभी समाधानों को लागू किया। सब कुछ काम करने लगता है। दोनों उपयोगकर्ताओं के पास साझा निर्देशिका की संपूर्ण सामग्री तक पूरी पहुंच है, इस निर्देशिका में नई फाइलें इसके अधिकारों को प्राप्त करती हैं, लेकिन अब आपने कैमरे से इस निर्देशिका में फ़ोटो को फेंक दिया है। आपकी पत्नी अपने उपयोगकर्ता के तहत सिस्टम में प्रवेश करती है और इन तस्वीरों को थोड़ा बदलने का फैसला करती है, केवल तभी जब संदेश सहेजना अपर्याप्त अधिकारों के बारे में प्रकट होता है। यह आपके द्वारा कॉपी की गई फ़ाइलों को साझा निर्देशिका के अधिकारों को प्राप्त नहीं करता है। क्यों? हां, क्योंकि cp यूटिलिटी आपके umask और acl की परवाह नहीं करती है। यह मूल अधिकारों को बनाए रखते हुए फाइलों को कॉपी करता है, या अधिकार कम हो जाते हैं, यह सब उस निर्देशिका के अधिकारों पर निर्भर करता है जहां हम कॉपी कर रहे हैं।

समस्या के समाधान के रूप में, करापुज़ ने डेमों की निगरानी करने वाले दो फ़ैम या गैमिन फ़ाइल सिस्टम में से एक का उपयोग करने का सुझाव दिया और फाइल की उपयोगिता को दिखाया ।

लेकिन, जैसा कि अभ्यास दिखाया गया है, ये दोनों डेमॉन सर्वर को महत्वपूर्ण रूप से लोड करते हैं, खासकर जब उपयोगकर्ता सक्रिय निर्देशिका में फ़ाइलों के साथ सक्रिय रूप से काम कर रहे हों। नेटवर्क पर, आप उपयोगकर्ता की शिकायतों को देख सकते हैं कि gamin प्रोसेसर समय के 30% तक खपत करता है। मैं कह सकता हूं कि मुझे वही निराशाजनक परिणाम मिले। लोहे के टुकड़े पर भार को कम करने के लिए, मैंने उल्लिखित उपयोगिताओं के बजाय इनोटिफ़ाइ-टूल्स पैकेज से इनोटिफ़ाइट उपयोगिता का उपयोग करने का निर्णय लिया:

sudo apt-get install inotify-tools

inotifywait बड़ी चतुराई से इंटरफ़ेस और inotify इंटरफ़ेस का उपयोग करके फाइलों में परिवर्तन करता है।

और इसलिए, हमारे पास राज्य परिवर्तनों की निगरानी के लिए एक कार्यक्रम है, अब हमें इसे आवश्यक निर्देशिका को खिलाने और रिबूट के बाद इसे करने के लिए मजबूर करने की आवश्यकता है।

यहाँ मेरे सर्वर पर एक नमूना समाधान है। मान लीजिए कि आपको निर्देशिका / होम / शेयरज़ / में अधिकारों की निगरानी करने की आवश्यकता है

एक लांचर /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 किसी फ़ाइल या निर्देशिका के केवल इनोड की निगरानी करता है। और अगर, किसी निर्देशिका को कॉपी करते समय, ईवेंट ईवेंट सभी फ़ाइलों और उपनिर्देशिकाओं को प्रभावित करता है, तो एक ही भौतिक अनुभाग में जाने पर, स्थानांतरित_तो घटना केवल स्थानांतरित निर्देशिका को प्रभावित करती है (निर्देशिका इनोड के साथ संचालन के बारे में जानती है, लेकिन इसके अंदर इनोड अनछुए हुए हैं), और उपनिर्देशिकाओं को प्रभावित नहीं करता है। और इसमें फाइलें। नतीजतन, जब कदम संचालन करते हैं, तो हम सबसे महत्वपूर्ण चीज खो सकते हैं, जिसके कारण हमने यह सब शुरू किया - अधिकारों की विरासत। इसलिए, मैंने प्रदर्शन का बलिदान करने का फैसला किया, खासकर जब से एक ही समय में बड़ी संख्या में फ़ाइलों को स्थानांतरित करने का संचालन शायद ही कभी किया जाता है।
अब आपको 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


सभी की तरह, जंगली sagging प्रदर्शन जो मैंने समय-समय पर पकड़ा जब सर्वर पर उनकी फ़ाइलों के साथ काम करने वाले लोगों का एक गुच्छा गायब हो गया।

उसी समय, मैंने एक तरफ की समस्या को हल किया: जैसा कि आप देख सकते हैं, स्क्रिप्ट में एक्सेस अधिकारों के अलावा, मैं मालिक और समूह को भी नियुक्त करता हूं। वास्तव में, कई ऐसी स्क्रिप्ट्स एक ही बाइनरी अधिकारों पर कार्यालय में दस्तावेज़ प्रवाह का प्रबंधन करती हैं, बिना एसीएल का सहारा लिए। एक दस्तावेज़ विभाग द्वारा एक निश्चित तरीके से विभाग जाता है, और किसी भी समय केवल एक विभाग को संपादन (या यहां तक ​​कि पढ़ने) का अधिकार है।

UPD: नाम को थोड़ा बदल दिया, अब यह मूल कारापुज लेख के साथ कम सुसंगत है, बल्कि वास्तव में।