ვერსიის სტრიქონი არ ამტკიცებს VPN დანამატის ფუნქციას

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

ოფცია შეიძლება იცხოვროს NetworkManager-ში, მის VPN დანამატში, ქვედა ძრავში ან ცალკე სამუშაო მაგიდის ინტერფეისში. ეს ოთხი პროექტია ოთხი გამოშვების ისტორიით.

ოთხი კომპონენტი, ოთხი გამოშვების ისტორია

რედაქტორი, რომელსაც ხედავთ, ჩვეულებრივ დანამატია, და დანამატი იძახებს ძრავს, მაგალითად OpenVPN-ის ბინარს ან WireGuard-ის იმპლემენტაციას. თავად NetworkManager აძლევს კავშირის მოდელს, და სამუშაო მაგიდის ინტერფეისმა შეიძლება დაამატოს თავისი ველები ზემოდან. ფუნქცია შეიძლება გამოჩნდეს რომელიმეში, და ერთის განახლება არ აახლებს დანარჩენებს. უფრო ახალი ძრავა არ არის მტკიცებულება, რომ დაყენებულ რედაქტორს შეუძლია იმპორტი გააკეთოს ოფციისა, რომელსაც ძრავა მხარს უჭერს.

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

გააანალიზეთ ვერსია სანამ შეადარებთ

Debian-ის პაკეტების პოლიტიკა ფორმატს განსაზღვრავს როგორც epoch, upstream ვერსია და შეფუთვის revision. ჯერ epoch შედარდება, შემდეგ upstream ნაწილი, შემდეგ revision, პაკეტების მენეჯერის საკუთარი დალაგების წესებით და არა ათწილადი არითმეტიკით ან უბრალო ანბანური დალაგებით. ტილდა ყველაზე ადრე დალაგდება, მათ შორის ამ ნაწილის დასასრულზე ადრე, და ასე უსწრებს გამოშვების კანდიდატი საბოლოო გამოშვებას. ნაწილების ცალ-ცალკე წაკითხვაა ის, რაც შედარებას მნიშვნელოვანს ხდის.

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

იკითხეთ რა არის დაყენებული და რა იქნებოდა

apt-cache policy იტყობინება დაყენებულ ვერსიას, კანდიდატს და საცავს, საიდანაც თითოეული მოდის, თქვენ მიერ დასახელებული ყოველი პაკეტისთვის. წაიკითხეთ ის ძრავისთვისაც და დანამატისთვისაც, და ჩაწერეთ სრული სტრიქონები შემოკლებული ფორმების ნაცვლად. ლოკალური მეტამონაცემები შეიძლება მოძველებული იყოს, და კანდიდატი ვერსია არ ამტკიცებს, რომ მოქმედმა პროცესმა ეს ბილდი ჩატვირთა. თუ სერვისი განახლების შემდეგ არ გადატვირთულა, დისკზე არსებული ფაილი და თქვენ მიერ დაკვირვებული ქცევა შეიძლება არ დაემთხვეს.

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

დაამტკიცეთ ოფცია მფლობელ კომპონენტში

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

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

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