შეესაბამება თუ არა ძველი openfortivpn .deb თქვენს Raspberry Pi-ს?

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

რას აფიქსირებს ფაილის სახელი ჩუმად

წაიკითხეთ სახელი, როგორიცაა openfortivpn_1.17.0-1_armhf.deb, მარჯვნიდან მარცხნივ. სუფიქსი არის არქიტექტურა, რომლისთვისაც ბინარული ფაილი კომპილირდა, შუა ველი არის upstream-ის და შეფუთვის რევიზია, და იმპლიციტური მეოთხე ველი არის იმ ნაკრების ბიბლიოთეკათა ნაკრები, რომელშიც ის აშენდა.

64-ბიტიან Raspberry Pi OS-ის ინსტალაციაზე სისტემის არქიტექტურა არის arm64, ამიტომ dpkg -i უარყოფს armhf პაკეტს არქიტექტურის შეუსაბამობის გამო. მაშინაც კი, სადაც multiarch ინსტალაციას შესაძლებელს ხდის, ბინარული ფაილი ელოდება ბიბლიოთეკის ვერსიებს იმ გამოშვებიდან, რომლის წინააღმდეგაც აშენდა, და უფრო ახალმა საბაზისო სისტემამ შეიძლება აღარ მოგვცეს ისინი. შედეგია ინსტალირებული პაკეტი, რომლის შესრულებადი ფაილი არ ირთვება, და ეს არის ის წარუმატებლობა, რომელსაც ადამიანები ჩვეულებრივ არასწორად განმარტავენ, თითქოს კლიენტი თავად გატეხილია.

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

ჰკითხეთ დისტრიბუციას, სანამ ჩამოტვირთვის ბმულს ითხოვთ

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

cat /etc/os-release
dpkg --print-architecture
apt-cache policy openfortivpn

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

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

რას ამოწმებს apt და რას არ იღებს ჩამოტვირთული ფაილი

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

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

ხელმოწერის შეცდომების ჩახშობა ან TLS-ის შემოწმების გამორთვა იმისთვის, რომ ძველი ინსტრუქცია მუშაობდეს, აშორებს პროცესის ერთადერთ ნაწილს, რომელიც რაღაცას ამოწმებდა. სამაგიეროდ აღადგინეთ წარუმატებელი შემოწმება.

დააინსტალირეთ კლიენტი, შემდეგ ცალკე გამართეთ კავშირი

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

თუ განლაგებას ნამდვილად სჭირდება აწყობა upstream-იდან, მიჰყევით პროექტის მიმდინარე აწყობის ინსტრუქციებს და მოეპყარით როგორც პროგრამას, რომელსაც ახლა თქვენ ინახავთ: განვითარების პაკეტები, pkg-config, TLS ბიბლიოთეკის სათაურები და PPP დემონი რეალური დამოკიდებულებებია, ისევე როგორც წაშლის პროცედურა, რომელიც მოგვიანებით დაგჭირდებათ.

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

გეგმა, რომელმაც უნდა შეცვალოს ძველი ფაილის სახელი

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

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

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