Kernel Oops VPN-ის გაშვებისას: მტკიცებულებები, რომლებიც ღირს შენახვად

VPN კლიენტის გაშვება მოხერხებული დროის ნიშანია და არა მიზეზი, და სწორედ ეს განსხვავება წყვეტს, რა მოხდება შემდეგ. როცა kernel Oops ამ მომენტთან ახლოს ხდება, არჩევანია გამოსადეგი ხარვეზის ანგარიშის შეგროვებასა და იმავე კრახის კიდევ ხუთჯერ გამოწვევას შორის საწარმოო მანქანაზე. გადატვირთვამდე შეინახეთ ოთხი რამ: kernel-ის ზუსტი build, ხარვეზის პირველი კვალი, taint-ის მდგომარეობა და მოკლე აღწერა ყველა დანარჩენისა, რაც იმავე წუთში შეიცვალა. დანარჩენი ინტერპრეტაციაა, და ინტერპრეტაცია შეიძლება დაელოდოს, სანამ მტკიცებულებები უსაფრთხო ადგილას იქნება.

დაიჭირეთ პირველი ხარვეზი, და არა ბოლო ხაზი

ჟურნალში პირველი Oops არის ის, რაც მნიშვნელოვანია, რადგან ყოველი შემდგომი ხარვეზი შეიძლება იყოს უკვე არაჯანსაღი kernel-ის გვერდითი ზიანი. დააკოპირეთ სათაური გამოძახებების კვალთან ერთად, რადგან სათაური ატარებს ხარვეზის გამომწვევ ინსტრუქციას და რეგისტრების მდგომარეობას, რომელიც კოდის გზას განსაზღვრავს. ანგარიში, რომელიც ბოლო ხაზიდან იწყება, ძალიან ცოტა ღირს მისთვის, ვინც კვირაში წაიკითხავს.

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

დააფიქსირეთ build-ი, სანამ რომელიმე სიმბოლოს წაიკითხავთ

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

ხის გარეთ არსებული მოდულები იმსახურებენ საკუთარ ხაზს ჩანაწერში, რადგან taint-ირებული kernel ზღუდავს, თუ რა დასკვნის გამოტანა შეუძლია მომსახურე პირს. წაიკითხეთ taint-ის მნიშვნელობა და ნუ გამოიტანთ მას მოდულების სიიდან.

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

გამოყავით გამომწვევი დეფექტისგან

გვირაბის გაშვება ჩვეულებრივ იყენებს უკვე არსებულ გზას: ქსელის დრაივერს, რიგის დისციპლინას, offload-ფუნქციას ან ენერგიის მდგომარეობას. გამომწვევი ხსნის, როდის ჩნდება ხარვეზი და არა რომელი კოდია არასწორი, და გამომწვევის მიზეზად მიჩნევა იწვევს კონფიგურაციის ცვლილებების სერიას, რომლებიც არაფერს არ ასწორებს.

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

შეამოწმეთ, რისი გამოყენება შეუძლია მომსახურე პირს სინამდვილეში

სანამ გააგზავნით, წაიკითხეთ ანგარიში ისე, როგორც უცხო წაიკითხავდა. თუ კონფიგურაცია, ზუსტი თანმიმდევრობა და build-ის იდენტობა არსებობს, ხოლო სერტიფიკატები წაშლილია, ანგარიში გამოსადეგია. თუ ეს სტეკის კვალის ეკრანის სურათია, ის დაბრუნდება იგივე ინფორმაციის მოთხოვნით. Kernel-ის შეცდომების ძიების სახელმძღვანელო აღწერს, როგორ გამოიყურება სასარგებლო კვალი და შესაბამისი სიმბოლოები.

uname -r
cat /proc/sys/kernel/tainted
journalctl -k -b -1 --no-pager | sed -n '/BUG:/,/Call Trace/p'
dmesg -T | grep -A 40 'RIP:'

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

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