sudo, &, -b կամ --daemon. ինչպես OpenVPN հաճախորդը տեղափոխել ֆոնային ռեժիմ
Ամպերսանդը ազատում է տերմինալը, ոչ թե մուտքը։ Համեմատեք sudo -b-ը, --daemon-ը և ծառայության օրինակը՝ ըստ նրա, թե ով է տիրում գործընթացին և ով է պատասխանում հուշումներին։
«Գործարկիր այն ֆոնում» արտահայտության մեջ թաքնված են երկու հարց։ Առաջինը՝ կարող է այս օգտատերն ընդհանրապես արտոնյալ գործընթաց սկսել. երկրորդը՝ կարող է նստաշրջանը շարունակվել առանց որևէ մեկի տերմինալում մուտքագրելու։ Shell-ի ամպերսանդը ոչ մեկին չի պատասխանում, և sudo-ի գաղտնաբառը փոփոխականում պահող սկրիպտը վատ է պատասխանում առաջինին և անձեռնմխելի է թողնում երկրորդը։ Առանձնացրեք դրանք, և տարբերակները հեշտ կլինի համեմատել։
Համեմատեք երեք թեկնածուներին ըստ սեփականության, ոչ թե հարմարության։
Տերմինալը թողնելու երեք եղանակ, երեք տարբեր սեփականատեր
Հրամանին ամպերսանդ ավելացնելը shell-ից խնդրում է այն գործարկել որպես ֆոնային աշխատանք, և աշխատանքը դեռ պատկանում է այդ shell-ին։ sudo-ն կարող է հարցնել նույնիսկ մինչև ծրագրի մեկնարկը, և OpenVPN կարող է հետո հարցնել բանալու գաղտնաբառի կամ մուտքի մասին։ Մուտքագրում սպասող հրամանը ֆոն տեղափոխելը ստեղծում է գործընթաց, որը սպասում է տերմինալի, որը ոչ ոք չի դիտում։ Տերմինալը ազատվում է, փոխազդեցությունը՝ ոչ։
Սա ամենաէժան տարբերակն է և այն, որը ձախողվում է ամենաշփոթեցնող կերպով, որովհետև հուշումը հայտնվում է մի տեղում, որը օպերատորն արդեն լքել է։
sudo -b-ը հավատարմագրերի կառավարիչ չէ
sudo -b գործարկում է հրամանը ֆոնում հենց sudo-ի տեսանկյունից, ինչը հնչում է որպես բացակայող գործառույթ և այդպես չէ։ Ըստ sudo-ի ձեռնարկի՝ ինտերակտիվ հրամանները սովորաբար վատ են վարվում այդ ռեժիմում, և shell-ի աշխատանքի կառավարումը չի կարող կառավարել նրա ստեղծած գործընթացները։ Այն տեղափոխում է գործընթացը՝ չտալով նրան հարցերին պատասխանելու ձև։ Դրանում ոչինչ չի ապահովում մասնավոր բանալու գաղտնաբառ կամ դարպասի մուտք։
Եթե կապը փոխազդեցություն է պահանջում, լուծումը աջակցվող ոչ ինտերակտիվ նույնականացման կարգավորումն է, ոչ թե նույն հուշումը գործարկելու այլ եղանակ։
--daemon-ը փոխում է ծրագիրը, ոչ թե մուտքը
--daemon խնդրում է հենց OpenVPN-ին առանձնանալ նախաձեռնումից հետո։ 2.6-ի ձեռնարկը նշում է, որ syslog-ի վերահասցեավորումը տեղի է ունենում ընտրանքի վերլուծության պահին, թեև առանձնացումը տեղի է ունենում ավելի ուշ, այնպես որ հաղորդագրությունները կարող են ավելի վաղ անհետանալ տերմինալից, քան սպասվում էր։ Այդ պահից հետո լռությունը ոչինչ չի ապացուցում թունելի մասին։ Ավելացրեք բացահայտ --log կամ --log-append որպեսզի ելքը հասնի մի տեղ, որտեղ կարող եք կարդալ այն։
Դեմոնի ռեժիմը նաև ընդմիշտ հեռացնում է կոնսոլը։ Պաշտպանված մասնավոր բանալին այդ ռեժիմում պահանջում է askpass , և կոնսոլից մուտքագրված հավատարմագրերը՝ քեշավորման ընտրանքների հետ միասին, կարող են ավելի ուշ վերանույնականացումը թողնել առանց հարցնելու տեղ։ Ստուգեք նույնականացման մոդելը տեղադրված տարբերակի հետ նախքան ենթադրելը, որ ֆոնային մեկնարկը կդիմանա իր առաջին բանալու թարմացմանը։
Ինչ է տալիս sudo-ի վավերացումը և ինչ՝ ոչ
sudo -v վավերացնում կամ թարմացնում է քեշավորված տեղական հավատարմագիրը՝ նույնականանալով, եթե քաղաքականությունը պահանջում է։ Այն չի գործարկում OpenVPN-ը, չի նույնականանում դարպասի հետ և չի երաշխավորում, որ սկրիպտի հետագա հրամանը թույլատրված կլինի։ sudo -n նշանակում է հակառակը՝ մի հարցրու, ձախողվիր։ Դա տեղական լիազորման ձախողումը դարձնում է բացահայտ, ինչը օգտակար է, և ոչինչ չի ասում այն մասին, թե ինչ կհարցնի OpenVPN-ը հետագայում։
Տարբերակներից ոչ մեկը պատճառ չէ բոլորին առանց գաղտնաբառի հրամաններ տալու կամ ադմինիստրատորի գաղտնաբառը սկրիպտի մեջ մտցնելու համար։
Նախընտրեք սեփականատեր, որին կարելի է դիտել
Մեքենային պատկանող թունելի համար օգտագործեք այն ծառայության օրինակը, որն աջակցում է բաշխումը։ Այդպիսի սեփականատերը տալիս է մեկնարկ, կանգ, կարգավիճակ և մատյաններ, և այն վերապրում է ձեր նստաշրջանի ավարտը։ Shell-ի ֆոնային գործարկումը, դեմոնացումը և վերագործարկման հանգույցը միմյանց շուրջ հավաքելը մեկ թունելի համար ստեղծում է երեք սեփականատեր և հստակ պատասխան չկա, թե որն է աշխատում։
Ինչ էլ ընտրեք, ստուգեք այն ռեսուրսը, որի համար գոյություն ունի թունելը։ Հաջող մեկնարկի հարցումը գործընթացի իրադարձություն է, ոչ թե աշխատող կապի ապացույց։