શું વપરાશકર્તા સત્ર VPN પર SSHFS માઉન્ટનો માલિક હોવો જોઈએ?
રૂટ VPN હૂક ડેસ્કટોપ એજન્ટ ઉધાર લઈ શકતું નથી. સાઇન-ઇન કરેલા વપરાશકર્તા તરીકે માઉન્ટ કરો, ટ્રિગરને એક કનેક્શન સુધી મર્યાદિત કરો અને ફોર્સ કરતા પહેલા અનમાઉન્ટની યોજના બનાવો.
VPN ચાલુ થયા પછી શેર કરેલું ફોલ્ડર માઉન્ટ કરવામાં બે ઓળખ સામેલ છે જે સરળતાથી ભેળસેળ થાય છે: નેટવર્ક ગોઠવવાની પરવાનગી ધરાવતો ઘટક, અને ફાઇલ સર્વરમાં લોગ ઇન કરવાની પરવાનગી ધરાવતું ખાતું. તે ભાગ્યે જ સમાન હોય છે. રૂટની માલિકીનો VPN હૂક ડેસ્કટોપ વપરાશકર્તાનું SSHFS માઉન્ટ શરૂ કરવા માટે ખરાબ જગ્યા છે, કારણ કે તેની પાસે વપરાશકર્તાનો એજન્ટ કે ઇચ્છિત માઉન્ટ માલિકી બંને નથી. પહેલા માલિકી યોગ્ય રીતે નક્કી કરવાથી ટ્રિગર સરળ બને છે.
બે ઓળખ, બે અલગ પરવાનગીઓ
VPN ક્લાયંટને રૂટ અને ઇન્ટરફેસ બદલવા માટે વિશેષાધિકારો જોઈએ. SSHFS માઉન્ટને ફાઇલ સર્વર સ્વીકારે તેવી SSH ઓળખ અને ફાઇલો વાંચનારા ખાતાની માલિકીનું FUSE માઉન્ટ જોઈએ. રૂટ તરીકે ચાલતી એક સ્ક્રિપ્ટ પ્રથમ જરૂરિયાત પૂરી કરે છે અને બીજીને શાંતિથી તોડે છે.
રૂટ તરીકે માઉન્ટ કરવાથી ફાઇલો ડેસ્કટોપ સત્રની બહાર રહે છે અને કદાચ વપરાશકર્તાની ચાવી રાખતા એજન્ટ સુધી પહોંચ વિના. માઉન્ટ અસ્તિત્વમાં છે, વપરાશકર્તા તેના દ્વારા લખી શકતો નથી, અને નિષ્ફળતા સર્વર-બાજુની પરવાનગી સમસ્યા જેવી લાગે છે. તે ખોટું નિદાન એક બપોર અને સ્ટોરેજ ટીમને એક ટિકિટનો ખર્ચ કરે છે.
કોઈપણ ઓટોમેશન લખતા પહેલા નક્કી કરો કે કયું ખાતું માઉન્ટનો માલિક છે, કારણ કે તે પસંદગી નક્કી કરે છે કે ટ્રિગર ક્યાં રહે છે અને કયા ઓળખપત્રો સુધી પહોંચી શકે છે.
પહેલા હાથે વપરાશકર્તા-માલિકીનું માઉન્ટ સ્થાપિત કરો
ખાલી માઉન્ટપોઇન્ટ, અધિકૃત SSH ખાતું અને ટનલ દ્વારા સર્વર સુધી કાર્યકારી માર્ગ ધરાવતા સાઇન-ઇન કરેલા વપરાશકર્તાથી શરૂ કરો. મેન્યુઅલ માઉન્ટ તે આધાર સ્થાપિત કરે છે જે કોઈપણ ઓટોમેશનએ પુનરાવર્તિત કરવો પડે.
mkdir -p "$HOME/mnt/team" sshfs [email protected]:/exports/team "$HOME/mnt/team" mount | grep sshfs
નામો ઉદાહરણો છે, તેથી તમારું સર્વર ખરેખર જે હોસ્ટ અને એક્સપોર્ટ પાથ આપે છે તે બદલો. પહેલા કનેક્શન પર મંજૂર પ્રક્રિયા દ્વારા હોસ્ટ કી ચકાસો. નોંધ લો કે VPN ખાતાનો પાસવર્ડ આપમેળે સ્ટોરેજ ખાતાનું ઓળખપત્ર નથી, અને તે નિષ્ફળ પ્રયાસોનું સામાન્ય કારણ છે.
તેને સામાન્ય વપરાશકર્તા તરીકે ચલાવો જેની પાસે તે વપરાશકર્તાની માલિકીનો માઉન્ટપોઇન્ટ હોય. ડિફોલ્ટ રૂપે ફક્ત માઉન્ટ કરનારું ખાતું ફાઇલો સુધી પહોંચે છે, અને allow_other તે મર્યાદાને દરેક સ્થાનિક વપરાશકર્તા સુધી વિસ્તારે છે. તે પહોંચનું ઇરાદાપૂર્વક વિસ્તરણ છે, ઓટોમેશન માટે કોઈ વૈકલ્પિક ઉપાય નથી.
ટ્રિગરને એ જ સત્ર સંદર્ભમાં કાર્ય કરવા દો
સપોર્ટેડ VPN ઇવેન્ટ ઇન્ટિગ્રેશનને વપરાશકર્તા-સત્રની ક્રિયા ચલાવવા માટે કહેવા દો, એમ ધારવાને બદલે કે વિશેષાધિકાર પ્રાપ્ત કૉલબેક ડેસ્કટોપ ઓળખપત્ર ઉધાર લઈ શકે છે. ટ્રિગરને tun0 કહેવાતા કોઈપણ ઇન્ટરફેસને બદલે ઇચ્છિત કનેક્શન ઓળખકર્તા સુધી મર્યાદિત કરો. ખોટી વસ્તુ સાથે મેળ ખાતો ડિસ્પેચર નિયમ દરેક નેટવર્ક ફેરફાર પર સક્રિય થાય છે, જેમાં એ પણ સામેલ છે જેનો આ માઉન્ટ સાથે કોઈ સંબંધ નથી.
ક્રિયાએ અપેક્ષિત હોસ્ટનામની પુષ્ટિ કરવી, હાલના માઉન્ટને ધ્યાનમાં લેવો અને એક મર્યાદિત પ્રયાસ કરવો જોઈએ. દર થોડી સેકન્ડે નવી SSHFS પ્રક્રિયા શરૂ કરતો અથવા સર્વર બંધ હોય ત્યારે ઓળખપત્ર વિનંતીનું પુનરાવર્તન કરતો પોલ લૂપ ટૂંકા વિક્ષેપને અટકેલી પ્રક્રિયાઓના ઢગલામાં ફેરવે છે. પ્રયાસને ટાઇમઆઉટ અને એક પુનઃપ્રયાસ સાથે મર્યાદિત કરો.
nmcli -g UUID connection show --active systemctl --user list-units 'sshfs*' pgrep -a sshfs
પ્રથમ આદેશ તે કનેક્શન ઓળખકર્તા આપે છે જે ડિસ્પેચરએ મેળ ખાવો જોઈએ. બાકીના બે દર્શાવે છે કે પ્રયાસ પહેલેથી ચાલી રહ્યો છે કે નહીં, અને તે જ ડુપ્લિકેટ અટકાવતી તપાસ છે.
દેખરેખ વિનાની સેવાને તેના પોતાના અમલ સંદર્ભમાં પોતાના મંજૂર ઓળખપત્રો અને પોતાની હોસ્ટ ચકાસણીની ગોઠવણ જોઈએ. તે ધારી શકતી નથી કે ગ્રાફિકલ એજન્ટ અનલૉક છે, અને તેણે એકને અનલૉક કરવાનો પ્રયાસ પણ ન કરવો જોઈએ.
ફોર્સ ક્લીનઅપ પહેલા ડિસ્કનેક્ટની યોજના બનાવો
આયોજિત ડિસ્કનેક્ટ માટે, ફાઇલ ક્રિયાઓ પૂર્ણ કરો અને માઉન્ટ કરનારા વપરાશકર્તાના પોતાના વર્કફ્લોમાંથી અનમાઉન્ટ કરો. પ્રક્રિયાને બદલે માઉન્ટપોઇન્ટને લક્ષ્ય બનાવો, અને સફળતાની જાણ કરતા પહેલા પરિણામની પુષ્ટિ કરો.
fusermount3 -u "$HOME/mnt/team" mountpoint "$HOME/mnt/team"
ફક્ત આ વર્કફ્લોએ બનાવેલું માઉન્ટ અનમાઉન્ટ કરો. જો તે વ્યસ્ત હોય, તો તે એપ્લિકેશનનો નિર્ણય છે: હૂકને સફળતા પરત કરાવવા માટે અસ્તિત્વમાં રહેલું ફોર્સ્ડ ડિટેચ ડેટા નુકસાનને અટકાવવાને બદલે છુપાવે છે.
અણધાર્યું નુકસાન અલગ રીતે વર્તે છે. SSHFS દસ્તાવેજ કરે છે કે નેટવર્ક વિક્ષેપ ફાઇલસિસ્ટમ ક્રિયાને અવરોધી શકે છે, અને reconnect વિકલ્પ હેન્ડલ પુનઃસ્થાપિત કર્યા વિના ટ્રાન્સપોર્ટ પુનઃસ્થાપિત કરે છે: પુનઃકનેક્શન પહેલા ખોલેલી ફાઇલ આગલા લેખમાં નિષ્ફળ જઈ શકે છે, અને અટકાવેલો લેખ સાચવવામાં આવતો નથી. તે તફાવત એ સંપાદકો માટે સૌથી મહત્વપૂર્ણ છે જે એક ફાઇલ કલાકો સુધી ખુલ્લી રાખે છે. પુનઃપ્રાપ્તિ ધારવાને બદલે ફરી ખોલવાનું પગલું યોજો.
તેના પર આધાર રાખતા પહેલા નિકાલજોગ ફાઇલો સાથે વર્તનનું પરીક્ષણ કરો. ટનલ પાછી આવ્યા પછી ફરી દેખાતી ડિરેક્ટરી સાબિત કરતી નથી કે અગાઉના હેન્ડલ અથવા ન સાચવેલું કામ ટકી ગયું.