RAM-ում աշխատող VPN-ը ոչինչ չի ասում մատյանների մասին

Միայն կարդալու պատկերից գործարկվող և իր աշխատանքային վիճակը tmpfs-ում պահող VPN սերվերը իրական և օգտակար ձևավորում է։ Այն նաև հեշտ է նկարագրել որպես առանց մատյանների, ինչը ձևավորումը չի ապացուցում։ Պահոցի տեղը որոշում է, թե որտեղ է ապրում պատճենը. հավաքումն ու պահպանումը որոշում են՝ գրառում ընդհանրապես կա՞, և վերագործարկումը ազդում է միայն առաջինի վրա։ Այս երկուսն իրարից անջատելը հենց ամբողջ վերանայումն է։

Սկսեք թվարկել յուրաքանչյուր գործընթաց, որը կարող է վիճակ գրել՝ դեմոնը, նույնականացման ծառայությունը, մատյանը, ցանկացած մոնիտորինգի գործակալ և կառավարման գործիքները։

Պահոցը և հավաքումը տարբեր հարցեր են

Յուրաքանչյուր գրող ունի իր նպատակակետը և իր քաղաքականությունը։ VPN-ի դեմոնը գրում է վիճակի ֆայլեր, նույնականացման հետին մասը գրում է հաշվի իրադարձություններ, մատյանը հավաքում է ծառայությունների ելքը, իսկ մոնիտորինգի գործակալը չափիչները ուղարկում է բոլորովին այլ տեղ։ Ձևավորումը, որը վերագործարկման ժամանակ անհետացնում է դրանցից մեկը, ոչինչ չի ասել մյուս երեքի մասին։ Հետևեք յուրաքանչյուր գրողի մինչև նրա նպատակակետը և նշեք՝ արդյոք այդ նպատակակետն ընդհանրապես մեքենայի վրա է։

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

tmpfs-ը երաշխիք չէ

Linux tmpfs-ը ֆիզիկական RAM սկավառակ չէ։ Միջուկի փաստաթղթերը հստակ ասում են, որ էջերը կարող են գրվել swap-ում, երբ տեղադրումը դա թույլ է տալիս, ուստի tmpfs ֆայլը կարող է հասնել սկավառակի առանց այն բանի, որ ծրագիրը երբևէ պատճենի այն այնտեղ։ mount-ը ցույց է տալիս՝ արդյոք swap-ով ապահովված tmpfs-ը գործում է, և մյուս հիշողության ֆայլային համակարգերը այլ կերպ են վարվում։ Կարդացեք իրական տեղադրման ընտրանքները՝ փոխարենը ենթադրելու, որ /run-ի տակ գտնվող ուղին նշանակում է անկայունություն։

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

Journald-ն ունի երկու նպատակակետ և մեկ փոխանցիչ

Journald-ն լավ է ցույց տալիս բաժանումը։ Ցնդող պահոցը գրառումները պահում է /run/log/journal-ի տակ, մշտականը՝ /var/log/journal-ի տակ, և ավտոմատ ռեժիմը ընտրում է դրանց միջև. ուժի մեջ գտնվող ռեժիմը գալիս է աշխատող համակարգից, ոչ թե պատկերի նկարագրությունից։ Ցնդողին անցնելը չի ջնջում այն, ինչ արդեն մշտապես գրվել է։ Փոխանցումը նույնպես առանձին ալիք է. նույնիսկ տեղում ոչինչ չպահող պահոցի կարգավորումը կարող է հաղորդագրությունները փոխանցել այլ թիրախի։

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

Ինչ պետք է վերապրի վերագործարկումը

Առանց վիճակի գործարկման միջավայրը աջակցում է կրկնելի փոխարինմանը և կարիք ունի դիտավոր աղբյուրների՝ կարգավորման, լիազորման և վերականգնման նյութի համար, որը ծառայությունը չի կարող հորինել։ Միակ աշխատող գրանցման կամ չեղարկման վիճակը կորցնելը՝ տեղական գրառումները անհետացնելու համար, վատ գործարք է և սովորական։ Որոշեք, թե ինչ պետք է դիտավորությամբ վերապրի, ապա ստուգեք, որ վերապրում է։

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

Համեմատեք գործող պահոցի և փոխանցման կարգավորումը մի քանի անվնաս իրադարձությունների հետ, ապա վերագործարկեք կամ փոխարինեք մեքենան և նորից ստուգեք, թե ինչ մնաց և որտեղից ծառայությունը վերականգնեց իր վիճակը։