Արդյո՞ք օգտվողի նստաշրջանը պետք է տիրապետի VPN-ի վրա SSHFS-ի միացմանը։

VPN-ի բարձրանալուց հետո ընդհանուր պանակի միացումը ներառում է երկու ինքնություն, որոնք հեշտ է շփոթել՝ ցանցը կարգավորելու թույլտվություն ունեցող բաղադրիչը և ֆայլերի սերվեր մուտք գործելու թույլտվություն ունեցող հաշիվը։ Նրանք հազվադեպ են նույնը։ Root-ի սեփականության տակ գտնվող VPN կեռիկը վատ տեղ է աշխատասեղանի օգտվողի SSHFS միացումը սկսելու համար, քանի որ այն չունի ոչ օգտվողի գործակալը, ոչ էլ նախատեսված միացման սեփականությունը։ Սեփականությունը սկզբում ճիշտ դնելը գործարկիչը դարձնում է պարզ։

Երկու ինքնություն, երկու առանձին թույլտվություն

VPN հաճախորդին արտոնություններ են պետք երթուղիներն ու ինտերֆեյսները փոխելու համար։ SSHFS միացմանը պետք է SSH ինքնություն, որն ընդունում է ֆայլերի սերվերը, և FUSE միացում, որը պատկանում է ֆայլերը կարդացող հաշվին։ Root-ով աշխատող մեկ սկրիպտ բավարարում է առաջին պահանջը և լուռ խախտում երկրորդը։

Root-ով միացնելը ֆայլերը թողնում է աշխատասեղանի նստաշրջանից դուրս և հնարավոր է՝ առանց օգտվողի բանալին պահող գործակալի հասանելիության։ Միացումը գոյություն ունի, օգտվողը չի կարող դրա միջով գրել, և ձախողումը նման է սերվերի կողմի թույլտվության խնդրի։ Այդ սխալ ախտորոշումը արժենում է կես օր և տոմս պահեստավորման թիմին։

Որոշեք, թե որ հաշիվն է տիրապետում միացմանը, նախքան որևէ ավտոմատացում գրելը, քանի որ այդ ընտրությունը որոշում է, թե որտեղ է ապրում գործարկիչը և ինչ հավատարմագրերի կարող է հասնել։

Սկզբում ձեռքով հաստատեք օգտվողին պատկանող միացում

Սկսեք մուտք գործած օգտվողից՝ դատարկ միացման կետով, լիազորված SSH հաշվով և թունելով դեպի սերվեր տանող աշխատող ուղով։ Ձեռքով միացումը հաստատում է այն հիմքը, որը պետք է վերարտադրի ցանկացած ավտոմատացում։

mkdir -p "$HOME/mnt/team"
sshfs [email protected]:/exports/team "$HOME/mnt/team"
mount | grep sshfs

Անունները օրինակներ են, ուստի փոխարինեք այն հոսթը և արտահանման ուղին, որոնք ձեր սերվերն իրականում առաջարկում է։ Ստուգեք հոսթի բանալին հաստատված գործընթացով այդ առաջին կապի ժամանակ։ Նկատեք, որ VPN հաշվի գաղտնաբառը ինքնաբերաբար պահեստավորման հաշվի հավատարմագիրը չէ, և դա ձախողված փորձերի սովորական պատճառ է։

Գործարկեք այն որպես սովորական օգտվող՝ միացման կետով, որը պատկանում է այդ օգտվողին։ Լռելյայն միայն միացնող հաշիվն է հասնում ֆայլերին, և allow_other-ը լայնացնում է այդ սահմանը յուրաքանչյուր տեղական օգտվողի համար։ Դա հասանելիության դիտավորյալ լայնացում է, ոչ թե ավտոմատացման շրջանցում։

Թող գործարկիչը գործի նույն նստաշրջանի համատեքստում

Թող աջակցվող VPN իրադարձությունների ինտեգրումը խնդրի օգտվողի նստաշրջանի գործողություն կատարել, փոխարենը ենթադրելու, որ արտոնյալ callback-ը կարող է փոխառել աշխատասեղանի հավատարմագիր։ Սահմանափակեք գործարկիչը նախատեսված կապի նույնացուցիչով, ոչ թե ցանկացած ինտերֆեյսով, որը պատահաբար կոչվում է 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 ընտրանքը վերականգնում է տրանսպորտը՝ առանց բռնակները վերականգնելու՝ վերամիացումից առաջ բացված ֆայլը կարող է ձախողվել հաջորդ գրառման ժամանակ, և ընդհատված գրառումը չի պահպանվում։ Այդ տարբերությունը ամենակարևորն է խմբագրիչների համար, որոնք մեկ ֆայլ բաց են պահում ժամերով։ Պլանավորեք վերաբացման քայլ՝ վերականգնում ենթադրելու փոխարեն։

Փորձարկեք վարքը մեկանգամյա ֆայլերով նախքան դրա վրա հույս դնելը։ Թունելի վերադարձից հետո նորից հայտնված պանակը չի ապացուցում, որ ավելի վաղ բռնակները կամ չպահպանված աշխատանքը վերապրել են։