რატომ ახალი VPN-მალსახმობი დაკარგულ პარამეტრებს არ აბრუნებს
გამშვები განსაზღვრავს, როგორ იწყება პროგრამა და არა სად ინახავს ის თავის პრეფერენციებს. შეადარეთ შესრულებადი ფაილის, მომხმარებლისა და კონფიგურაციის კონტექსტი, სანამ ხატულას დაადანაშაულებთ.
მენიუს დაკარგული ჩანაწერები და ქრებადი პრეფერენციები ერთი და იმავე რეფლექსით სწორდება, თუმცა ეს დაუკავშირებელი პრობლემებია. ერთი სამუშაო მაგიდის ინტეგრაციაა, მეორე აპლიკაციის მდგომარეობა, და ახალი ხატულა არც ერთს არ ცვლის თავისით. მათი გამიჯვნა ერთ ექსპერიმენტს მოითხოვს და ხსნის ამ თემაზე ადამიანების არეულობის დიდ ნაწილს. გამშვები პროგრამას იწყებს; პროგრამა წყვეტს, რა დაიმახსოვროს.
ორი საქმე, რომლებიც მხოლოდ ერთს ჰგავს
სამუშაო მაგიდის ინტეგრაცია ნიშნავს, რომ გარემოს შეუძლია იპოვოს შესრულებადი ფაილი, წარმოადგინოს სახელი და ხატულა და გადასცეს სწორი არგუმენტები. აპლიკაციის მდგომარეობა ნიშნავს, რომ პროგრამა პროფილს წერს მდგრად ადგილას და მომდევნო გაშვებისას ისევ კითხულობს. არც ერთი არ გულისხმობს მეორეს, ამიტომ მომუშავე მალსახმობს შეუძლია გაუშვას კლიენტი, რომელმაც ყველაფერი დაივიწყა.
შეცვალეთ ერთი უვნებელი ჩვენების პრეფერენცია თავად აპლიკაციის კონტროლებით, შემდეგ დახურეთ და იმავე გზით ხელახლა გახსენით. თუ პრეფერენცია დაბრუნდა, შენახვა მუშაობს და დარჩენილი საჩივარი ფანჯრის პოვნას ეხება და არა მონაცემთა შენახვას. თუ გაქრა, მალსახმობი ყურადღების გადატანაა და ნამდვილი კითხვა ისაა, სად ინახავს ეს პროცესი თავის ფაილებს. გამოსცადეთ თითო პრეფერენცია ერთდროულად, რადგან პაროლს ხელახლა მომთხოვნი კლიენტი შესაძლოა საიდუმლოს იცავდეს და არა კონფიგურაციას კარგავდეს.
შეადარეთ გაშვების შეტანები ხელახალ ინსტალაციამდე
დაიწყეთ სამუშაო მაგიდის ჩანაწერიდან და წაიკითხეთ, რას აკეთებს ის სინამდვილეში, რადგან მენიუდან გაშვება ავტომატურად არ არის იგივე პროცესული გარემო, რაც ტერმინალიდან გაშვება. მნიშვნელოვანი გასაღებებია Exec, Path და ირიბად ის გარემო, რომელსაც სესია იძლევა. Exec -ში არსებულ შემოხვევის სკრიპტს შეუძლია ცვლადის დაყენება, დირექტორიის შეცვლა ან პრივილეგირებული დამხმარის გამოძახება, რომელსაც მენიუ არასდროს აჩვენებს. ხელახალი ინსტალაცია ანაცვლებს ფაილებს, რომლებიც აპლიკაციას უკვე ჰქონდა, და ეს იშვიათად არის ის ცვლადი, რომელიც შეიცვალა.
grep -h '^Exec=' ~/.local/share/applications/*.desktop
desktop-file-validate ~/.local/share/applications/client.desktop
შეხედეთ ~/.local/share/applications -ში არსებულ ფაილს /usr/share/applications -ში არსებულზე ადრე, რადგან მომხმარებლის ასლი სისტემის ასლს ფარავს. გაუშვით desktop-file-validate, როცა ჩანაწერი ცუდად იქცევა, და მოძებნეთ მოძველებული ასლი, რომელიც ჯერ კიდევ მიუთითებს წაშლილ გზაზე. არასწორი მომხმარებლის ასლს უმეტესი სამუშაო მაგიდები მაინც ანიჭებს უპირატესობას, ამიტომ გატეხილ ფაილს შეუძლია ჩანაწერი მენიუდან მოხსნას, სანამ პაკეტის ფაილი ძალაში რჩება. შემდეგ იგივე ბრძანება ხელით გაუშვით და შეადარეთ, რას იძლევა ორი გაშვება.
სად ცხოვრობს პრეფერენცია სინამდვილეში
აპლიკაციები, რომლებიც მიჰყვებიან XDG საბაზო დირექტორიების წესებს, კონფიგურაციას დებენ $XDG_CONFIG_HOME -ის ქვეშ, მდგრად მდგომარეობას $XDG_STATE_HOME -ის ქვეშ, ხოლო ერთჯერად მონაცემებს $XDG_CACHE_HOME -ის ქვეშ, და ნაგულისხმევად იყენებენ ~/.config, ~/.local/state და ~/.cache -ს, როცა ეს ცვლადები დაყენებული არ არის. სამივე როლია და არა დაპირება, ამიტომ კონკრეტულ VPN პროდუქტს შეუძლია სულ სხვა რამის დოკუმენტირება. მომწოდებლის საკუთარი დოკუმენტაციის კითხვა ჯობია დირექტორიის სახელიდან გზის გამოცნობას. როცა დოკუმენტაცია მწირია, დააკვირდით პროცესს და არა ფაილურ სისტემას.
ფაილის გახსნებზე გაფილტრული კვალი აჩვენებს ყველა კონფიგურაციის გზას, რომელსაც კლიენტი ცდის, მათ შორის იმას, რომელსაც გასვლისას წერს. გაუშვით ის იმავე მომხმარებლით და იმავე გარემოთი, შემდეგ შეადარეთ ეს გზები თქვენს მოსალოდნელ დირექტორიებს.
strace -f -e trace=openat,stat -o /tmp/vpn.log vpn-client
საიდუმლოებებსა და პროფილებს სხვადასხვა მესაკუთრე ჰყავს
შენახული პროფილი და შენახული რწმუნებები ცალკე ობიექტებია, ხშირად ცალკე საცავით. ერთი შეიძლება ცხოვრობდეს კონფიგურაციის ფაილში, სანამ მეორე ზის გასაღებების რგოლში, რომელიც ყოველ სესიაზე იხსნება, ამიტომ პაროლს ხელახლა მომთხოვნი კლიენტი შესაძლოა უბრალოდ აკეთებდეს იმას, რისთვისაც შეიქმნა. პროფილის წაშლა მოთხოვნის შესაჩერებლად ის გზაა, რომლითაც ადამიანები კარგავენ მომუშავე კონფიგურაციას.
პრივილეგირებული გაშვებები ამას კიდევ ართულებს, რადგან sudo-ით ან PolicyKit დამხმარით გაშვებამ შეიძლება წარმოადგინოს სხვა სახლის დირექტორია და შესაბამისად სხვა კონფიგურაციათა ნაკრები. გაასწორეთ მესაკუთრეობა კონკრეტულ ფაილზე, რომელსაც აპლიკაცია ადოკუმენტირებს, და არა რეკურსიულად მთელ სახლის დირექტორიაზე, შემდეგ გადაწყვიტეთ, რომელი იდენტობა უნდა ფლობდეს პროფილს შემდგომში, და მომავალი გაშვებები შეინარჩუნეთ მასთან შესაბამისობაში.
რა შეუძლია ხატულას გითხრათ და რა არა
ხატულა ამტკიცებს, რომ გამშვების ფაილი წყდება, და მეტს არაფერს. კავშირის მდგომარეობა კლიენტს ეკუთვნის, ამიტომ ერთადერთი საიმედო შემოწმება ინტერფეისი, მარშრუტი ან თავად კლიენტის სტატუსის გამოტანაა. სისტემური უჯრის აპლეტი, რომელიც არ გაშვებულა, შეიძლება მომუშავე გვირაბი გატეხილად აჩვენოს, ხოლო მოძველებულმა აპლეტმა გატეხილი შეიძლება კარგად აჩვენოს. გამოსცადეთ კავშირი და გამშვები ცალ-ცალკე, შემდეგ ჩაწერეთ, რომელი გაასწორეთ სინამდვილეში.
თუ ორივე გატეხილი იყო, წინააღმდეგობა გაუწიეთ ცდუნებას, გაასწოროთ როგორც ერთი ცვლილება. გაასწორეთ ჩანაწერი, დაადასტურეთ გაშვება, შემდეგ დაადასტურეთ გვირაბი და ჩაწერეთ ყოველი ნაბიჯის შედეგი. სწორედ ეს ჩანაწერი ხდის მომდევნო ცნობას დაკარგულ პარამეტრებზე დიაგნოსტირებადს და არა ამის გამეორებას, და ის ასევე ეუბნება შემდეგ ადამიანს, პრობლემის რომელი ნახევარი იყო ნამდვილი.