RAM-ში მომუშავე VPN არაფერს ამბობს ჟურნალებზე

VPN სერვერი, რომელიც მხოლოდ-წაკითხვადი იმიჯიდან იტვირთება და სამუშაო მდგომარეობას tmpfs-ზე ინახავს, რეალური და სასარგებლო დიზაინია. მისი ჟურნალების გარეშე აღწერა ასევე ადვილია, რასაც დიზაინი არ ამტკიცებს. შენახვის ადგილი განსაზღვრავს, სად ცხოვრობს ასლი; შეგროვება და შენარჩუნება განსაზღვრავს, საერთოდ არსებობს თუ არა ჩანაწერი, და გადატვირთვა მხოლოდ პირველზე მოქმედებს. ამ ორის გამიჯვნა მთელი მიმოხილვაა.

დაიწყეთ ყველა პროცესის ჩამოთვლით, რომელსაც მდგომარეობის ჩაწერა შეუძლია: დემონი, ავთენტიფიკაციის სერვისი, ჟურნალი, ნებისმიერი მონიტორინგის აგენტი და მართვის ხელსაწყოები.

შენახვა და შეგროვება სხვადასხვა კითხვაა

თითოეულ მწერალს თავისი დანიშნულება და თავისი პოლიტიკა აქვს. VPN დემონი წერს მდგომარეობის ფაილებს, ავთენტიფიკაციის ბექენდი წერს ანგარიშის მოვლენებს, ჟურნალი აგროვებს სერვისების გამომავალს, ხოლო მონიტორინგის აგენტი მეტრიკებს სრულიად სხვა ადგილას აგზავნის. დიზაინი, რომელიც ერთ-ერთ მათგანს გადატვირთვისას აქრობს, დანარჩენ სამზე არაფერი თქვა. მიჰყევით თითოეულ მწერალს მის დანიშნულებამდე და აღნიშნეთ, საერთოდ არის თუ არა ეს დანიშნულება მანქანაზე.

აპლიკაციისთვის დამახასიათებელ ფაილებს, ატვირთულ დიაგნოსტიკას და გარე სერვისებს იგივე მოპყრობა სჭირდება. ნაცნობი ლოკალური ჟურნალის არარსებობა არ ამტკიცებს, რომ კავშირის ან ანგარიშის ჩანაწერები არსად არ არის; ის ამტკიცებს, რომ ჯერ არ გიპოვიათ, სად მიდიან.

tmpfs გარანტია არ არის

Linux tmpfs ფიზიკური RAM დისკი არ არის. ბირთვის დოკუმენტაცია ცხადად ამბობს, რომ გვერდები swap-ში იწერება, როცა მიმაგრება ამას ნებას რთავს, ამიტომ tmpfs ფაილმა შეიძლება დისკამდე მიაღწიოს აპლიკაციის მიერ იქ კოპირების გარეშე. mount გვიჩვენებს, მოქმედებს თუ არა swap-ით მხარდაჭერილი tmpfs, და სხვა მეხსიერების ფაილური სისტემები კიდევ სხვანაირად იქცევიან. წაიკითხეთ მიმაგრების რეალური პარამეტრები იმის ნაცვლად, რომ ჩათვალოთ, თითქოს /run-ის ქვეშ გზა არასტაბილურობას ნიშნავს.

შემდეგ ჩამოწერეთ ის რამ, რაც გადატვირთვას გადაურჩება იმ გზებით, რომლებსაც ადამიანები ივიწყებენ: მუდმივი ზედა ფენა, მიერთებული საცავი, ჰიბერნაციის იმიჯები, ავარიის დამპები და მთელი VM-ის ინფრასტრუქტურის სურათები. თითოეული მათგანი შესაძლო დანიშნულებაა იმ მდგომარეობისთვის, რომელსაც წარმავლად თვლიდით. ეს სია შესამოწმებელია და არა მტკიცება, რომ ყველა ჰოსტს ყველა მათგანი აქვს.

Journald-ს ორი დანიშნულება და ერთი გადამცემი აქვს

Journald კარგად აჩვენებს გაყოფას. არასტაბილური საცავი ჩანაწერებს /run/log/journal-ის ქვეშ ინახავს, მუდმივი /var/log/journal-ის ქვეშ, და ავტომატური რეჟიმი მათ შორის ირჩევს; მოქმედი რეჟიმი მოქმედი სისტემიდან მოდის და არა იმიჯის აღწერიდან. არასტაბილურზე გადასვლა არ შლის იმას, რაც უკვე მუდმივად დაიწერა. გადაგზავნა ასევე ცალკე არხია: ლოკალურად არაფრის შემნახველ საცავის პარამეტრსაც კი შეუძლია შეტყობინებები სხვა სამიზნეს გადასცეს.

წაიკითხეთ მოქმედი რეჟიმი თავად ჟურნალიდან ან მისი კონფიგურაციის ფაილიდან, შემდეგ ცალკე შეამოწმეთ გადაგზავნის სამიზნეები, რადგან ერთი პარამეტრი მეორეს არ მართავს.

რა უნდა გადაურჩეს გადატვირთვას

მდგომარეობის გარეშე გარემო მხარს უჭერს განმეორებად ჩანაცვლებას და სჭირდება განზრახი წყაროები კონფიგურაციისთვის, ავტორიზაციისთვის და აღდგენის მასალისთვის, რომელსაც სერვისი ვერ გამოიგონებს. ერთადერთი მოქმედი რეგისტრაციის ან გაუქმების მდგომარეობის დაკარგვა იმისთვის, რომ ლოკალური ჩანაწერები გაქრეს, ცუდი გარიგებაა და ჩვეულებრივი. გადაწყვიტეთ, რა უნდა გადარჩეს განზრახ, შემდეგ გადაამოწმეთ, რომ გადარჩება.

იგივე მსჯელობა ეხება ოპერაციულ ჩანაწერებს. გადაწყვიტეთ, რომელი მოვლენები ნამდვილად სჭირდება უსაფრთხოებას და სერვისის მართვას, გამართლებული ფარგლებითა და შენარჩუნებით, და დანარჩენი მინიმუმამდე შეამცირეთ. მინიმიზაცია არ ნიშნავს ყველა დიაგნოსტიკის გამორთვას.

შეადარეთ მოქმედი შენახვისა და გადაგზავნის კონფიგურაცია რამდენიმე უვნებელ მოვლენას, შემდეგ გადატვირთეთ ან შეცვალეთ მანქანა და ხელახლა შეამოწმეთ, რა დარჩა და საიდან აღადგინა სერვისმა თავისი მდგომარეობა.