status=200/CHDIR: systemd-ը երբեք չի գործարկել OpenVPN-ը

Ծառայությունը ձախողվում է, մատյանները հիշատակում են spawn և պանակ, և առաջին բնազդը՝ ստուգել VPN-ի կարգավորումները։ Այդ ֆայլից դեռ ոչինչ կարդացված չէ։ systemd-ը ձախողվել է պրոցեսը նախապատրաստելիս, նախքան գործարկվող ֆայլի աշխատելը, ուստի ոչ մի parser, ոչ մի վկայական և ոչ մի հեռավոր հոսթ չի հարցվել։ Կարգավիճակի կոդը systemd-ի, այլ ոչ OpenVPN-ի մասին հայտարարություն կարդալն է, որ սա դարձնում է կարճ հետաքննություն։

Կարդացեք կարգավիճակի կոդը մինչև հավելվածը

Ծառայության անունից հետո թվային կոդը նշում է այն փուլը, որը ձախողվել է։ Պանակի սխալը հաղորդվում է որպես CHDIR կարգավիճակ, մինչդեռ չգործարկվող գործարկվող ֆայլը բոլորովին այլ կոդ է։ Երկուսը նման են երևում ամփոփ տողում և ոչ մի ընդհանրություն չունեն իրենց պատճառներում։

Այդ տարբերությունը կարևոր է, որովհետև ուղղումները տարբեր ֆայլերում են։ CHDIR սխալը վերաբերում է ուղուն և այն, թե ինչպես է ծառայությունը տեսնում այն։ Exec սխալը վերաբերում է բինար ֆայլին, դրա մեկնաբանին կամ անկապ mount-ին։ VPN-ի հեռավոր կետը, ծածկագրերի ցանկը կամ վկայագրի ուղին փոխելը չի լուծի դրանցից ոչ մեկը։

Հաստատեք, որ սխալը տեղի է ունենում մեկնարկին, այլ ոչ հաջող աշխատանքից հետո։ Եթե ծառայությունը երեկ աշխատում էր, իսկ հիմա ձախողվում է նույն փուլում, ինչ-որ բան փոխվել է պանակում, դրա թույլտվություններում կամ հենց unit-ում, և այդ փոփոխությունը այն ապացույցն է, որ պետք է փնտրել։

Հարցրեք unit-ին, թե որտեղ է ուզում լինել

Կարդացեք գործող unit-ը, այլ ոչ այն ֆայլը, որը կարծում եք տեղադրված է, որովհետև drop-in-ները կարող են վերափոխել աշխատանքային պանակը՝ առանց երբևէ խմբագրելու հիմնական unit-ը։ Show-ի ելքը ուղղակիորեն պատասխանում է հարցին՝

systemctl cat [email protected]
systemctl show [email protected] -p WorkingDirectory -p RootDirectory -p User -p ProtectHome
journalctl -u [email protected] -b --no-pager | tail -30

Upstream սերվերի ձևանմուշի համար աշխատանքային պանակը սերվերի կազմաձևման պանակն է, և օրինակի անունը ընտրում է դրա ներսում գտնվող պրոֆիլը։ Այսպիսով branch անունով օրինակը սպասում է իր ֆայլին նույն պանակում, իսկ այլ տեղ դրված պրոֆիլը բոլորովին չի բավարարում աշխատանքային պանակի պահանջը։

Համեմատեք, թե unit-ը ինչ է պահանջում, ինչ կա։ Ուղին, որը նախկինում կար, սիմվոլիկ հղումը, որը հիմա ցույց է տալիս այլ տեղ, կամ օրինակի անունը, որը այլևս չի համապատասխանում պանակին, սովորական փոփոխություններ են, որոնք առաջացնում են հենց այս սխալը։

Ստուգեք ուղին այնպես, ինչպես ծառայությունն է տեսնում

Ձեր shell-ը և ծառայությունը չեն կիսում ֆայլային համակարգի նույն տեսքը։ Կարգավորված արմատային պանակը կամ root image-ը փոխում է բացարձակ ուղու իմաստը unit-ի ներսում, և հոսթի վրա ակնհայտորեն առկա ուղին կարող է բացակայել այդ անունների տարածքում։ Կարդացեք unit-ի կարգավորումները, նախքան ձեռքով փորձին վստահելը։

Թույլտվությունները բարդացնում են խնդիրը։ Ծառայությունն աշխատում է որոշակի օգտատիրոջ անունից, և այդ օգտատերը պետք է կարողանա անցնել յուրաքանչյուր ծնողական պանակով՝ թիրախին հասնելու համար, ոչ միայն կարդալ թիրախը։ Պանակը, որը հասանելի է root-ին և անանցանելի ծառայության օգտատիրոջը, առաջացնում է սխալ, որը նման է բացակայող ուղու։

namei -l /etc/openvpn/server
systemctl show [email protected] -p ProtectSystem -p ReadOnlyPaths

Կարծրացման կարգավորումները նույնպես այս պատկերի մասն են։ Unit-ը, որը թաքցնում է տնային պանակները կամ ֆայլային համակարգի մի մասը դարձնում է միայն կարդալու, անում է հենց այն, ինչի համար կարգավորվել է, և աշխատանքային պանակը պետք է լինի այնտեղ, որտեղ sandbox-ը դեռ ցույց է տալիս այն։

Ուղղեք սեփականատիրոջը, ապա սպասեք այլ սխալի

Ուղղեք դասավորությունը կամ unit-ը նրա միջոցով, ով տիրապետում է այդ կազմաձևին։ Պրոֆիլը սպասվող պանակ տեղափոխելը օրինական ուղղում է, երբ դասավորությունը սխալ է, բայց դա չի բացատրում պանակը, որ մտնել հնարավոր չէ, ուստի մի ընդունեք այն որպես ընդհանուր պատասխան։

Դիմացեք գայթակղությանը՝ ընդլայնել թույլտվությունները կազմաձևման ծառի վրա կամ հեռացնել sandbox-ը։ Երկուսն էլ վերացնում են ախտանիշը՝ միաժամանակ հեռացնելով այնտեղ դիտավորյալ դրված պաշտպանությունները, և հաջորդ սխալը ավելի դժվար կլինի մեկնաբանել։

Վերսկսեք օրինակը և կարդացեք հաջորդ իրադարձությունը՝ հաջողությունը ենթադրելու փոխարեն։ Հավանական հաջորդ սխալն այն է, որ OpenVPN-ը չի կարող բացել իր կազմաձևման ֆայլը, ինչը առաջընթաց է․ աշխատանքային պանակ մտել ենք և parser-ը հիմա աշխատում է։ Այնտեղից հետևեք unit-ի իրական ֆայլային քարտեզագրմանը՝ ցանցային խնդիրների լուծմանը վերադառնալու փոխարեն։

systemd-ի կատարման տեղեկատուն սահմանում է, թե ինչպես է աշխատանքային պանակը մեկնաբանվում արմատային պանակների և sandbox-ի հետ միասին։ Հիշելի ձևը պարզ է․ յուրաքանչյուր կարգավիճակի կոդ նշում է տարբեր փուլ, և միայն հավելվածի սեփական սխալներն են նկարագրում հավելվածը։