თქვენი VPN-ის ბინარი ამ პროცესორისთვისაა აწყობილი? წაიკითხეთ ELF-ის ჰედერი
ELF-ის კლასი და მანქანა სხვადასხვა ველებია, ხოლო ინტერპრეტატორი მესამეა. წაიკითხეთ სამივე, სანამ VPN-კლიენტს Pi-ზე ან სხვა დაფაზე დააყენებთ.
ორივე ფაილი 32-ბიტიანია და მათგან მხოლოდ ერთი მუშაობს თქვენს დაფაზე. Intel-ისთვის ELF32-ის აწყობა და ARM-ისთვის ELF32-ის აწყობა ერთმანეთს ეთანხმება კლასის ველში და არ ეთანხმება ყველაფერში, რაც მნიშვნელოვანია. ჩამოტვირთვის გვერდი, რომელიც 32-ბიტიან ვარიანტს გთავაზობთ, თითქმის არაფერი გითხრათ, სანამ არ წაიკითხავთ იმ ფაილის ჰედერს, რომელიც რეალურად ჩამოტვირთეთ. სახელის შეცვლა ერთ ინსტრუქციასაც არ ცვლის.
კლასი და მანქანა სხვადასხვა კითხვას პასუხობს
კლასის ველი ამბობს, იყენებს ფაილი 32-ბიტიან თუ 64-ბიტიან სტრუქტურებს. მანქანის ველი ასახელებს ინსტრუქციათა სიმრავლეს, რომლისთვისაც ფაილი შედგა. მხოლოდ პირველის წაკითხვა იმ გზით მიდის, რომ x86-ის აწყობა ARM-ის დაფაზე აღმოჩნდება სრულიად დამაჯერებლად მოსაჩენი ფაილის სახელით. ორივე მნიშვნელობა ერთი და იმავე ბრძანებიდან მოდის, ამიტომ ერთის გამოტოვება ასე ადვილია.
იგივე არეულობა ეხება 64-ბიტიან ეტიკეტებს, სადაც aarch64 და x86-64 სიტყვის ზომას იზიარებენ და არც ერთ ინსტრუქციას არ იზიარებენ. გამყიდველის გვერდი, რომელიც ერთ 64-ბიტიან ჩამოტვირთვას ჩამოთვლის, საკუთარ აწყობას აღწერს და არა თქვენს მანქანას. შეამოწმეთ ფაილის ჰედერი და არა გვერდზე სვეტის სათაური.
readelf -h ./vendor-vpn readelf -l ./vendor-vpn | head -20 file ./vendor-vpn
პირველი ბრძანება ჰედერს ბეჭდავს, კლასისა და მანქანის ჩათვლით. მეორე პროგრამის ჰედერებს აჩვენებს, სადაც ინტერპრეტატორის მოთხოვნა ზის. მესამე ერთ ხაზს გაძლევთ, როცა ცხრილი მეტია, ვიდრე გჭირდებათ.
შესრულების უფლების დამატება ან დისტრიბუტივის შემოწმების გასწორება არაფერს თარგმნის. ემულაცია, სადაც პლატფორმა მას მხარს უჭერს, განთავსების გადაწყვეტილებაა, საკუთარი წარმადობისა და დამოკიდებულებათა ხარჯით.
წაიკითხეთ ჰედერი, სანამ ინსტალატორს გაუშვებთ
შეამოწმეთ სანდო არტეფაქტი, სანამ მისგან რამეს შეასრულებთ. ნახევარ გზაზე წარუმატებელი ინსტალატორი შეიძლება ბიბლიოთეკები შეცვლილი და არაფერი მომუშავე დატოვოს, რაც უარესი საწყისი წერტილია, ვიდრე არქივი, რომლითაც დაიწყეთ. ჰედერის შემოწმება მხოლოდ კითხვითია და შექცევადი იმ გაგებით, რომ სისტემაში არაფერი იცვლება.
შეადარეთ მანქანის ველი მომუშავე სისტემის პაკეტების არქიტექტურას და არა დაფის მარკეტინგულ სახელს. 32-ბიტიანი მომხმარებლის სივრცის მქონე 64-ბიტიან პროცესორს 32-ბიტიანი აწყობა სჭირდება და ეს დეტალი წყვეტს, რომელი ჩამოტვირთვაა მშობლიური. დაფის შესაძლებლობა არ არის შეზღუდვა; დაყენებული მომხმარებლის სივრცეა.
dpkg --print-architecture uname -m getconf LONG_BIT
პირველი ბრძანება იტყობინება არქიტექტურას, რომლისთვისაც სისტემა პაკეტებს აყენებს და სწორედ ეს მნიშვნელობა უნდა დაემთხვეს. დანარჩენი ორი ბირთვსა და სიტყვის ზომას აღწერს და მრავალარქიტექტურულ დაყენებაზე შეიძლება მომხმარებლის სივრცეს არ დაემთხვეს.
როცა ეს პასუხები არ ემთხვევა, გადაწყვიტეთ, რომელს უჭერს მხარს გამყიდველი, სანამ სხვა არქივს ჩამოტვირთავთ. ვარაუდი ინსტალაციათა ციკლს ქმნის, რომელთაგან თითოეული სხვადასხვა ადგილას ვარდება და ყოველი მარცხი ახალ პრობლემას ჰგავს.
შეამოწმეთ ინტერპრეტატორი და არა მხოლოდ არქიტექტურა
დინამიკური შესრულებადი ფაილი პროგრამის ჰედერში იწერს ჩამტვირთავს, რომელსაც ელის. სხვა ჩამტვირთავის გზის მქონე სისტემაზე ბირთვი უარს ამბობს ფაილის გაშვებაზე, თუნდაც მანქანის ველი ზუსტად ემთხვეოდეს. სწორედ ეს მარცხი აგზავნის ხალხს დაკარგული ბიბლიოთეკების საძებნად.
შეცდომის შეტყობინება გეუბნებათ, რომელ შემთხვევაში ხართ და ორივე შემთხვევის არევა ადვილია. ფორმატის ან არქიტექტურის უარყოფა განსხვავდება დაკარგული ფაილისგან ან ინტერპრეტატორისგან, და მათგან მხოლოდ ერთი სწორდება სხვა პაკეტის დაყენებით.
readelf -l ./vendor-vpn | grep -A1 INTERP ls -l /lib64/ld-linux-x86-64.so.2
პირველი ბრძანება აჩვენებს ინტერპრეტატორის გზას, რომელსაც ბინარი ითხოვს. მეორე ამოწმებს, არსებობს თუ არა ეს გზა, რაც არასწორ აწყობას დაკარგული ჩამტვირთავისგან გამოჰყოფს.
ნუ გაუშვებთ დამოკიდებულებათა ჩამომთვლელს არასანდო ბინარზე, რადგან ზოგიერთ იმპლემენტაციას შეუძლია შეასრულოს ის ფაილი, რომელსაც ამოწმებს. შეინახეთ შემოწმება მხოლოდ კითხვით და წინააღმდეგობა გაუწიეთ ჩამტვირთავის სიმბოლური ბმების დამატებას, რომ მხარდაუჭერელი აწყობა გაეშვას.
მოითხოვეთ აწყობა ფაქტებით ხელში
გაუგზავნეთ გამყიდველს OS-ის გამოშვება, პაკეტების არქიტექტურა, კლასისა და მანქანის მნიშვნელობები და პირველი შეცდომის შეტყობინება. ეს კომბინაცია სასარგებლო პასუხს იმსახურებს, ხოლო ზოგადი მარცხის ეკრანის ასლი მხარდაჭერის შაბლონს იმსახურებს.
ბინარის საკითხი კონფიგურაციის საკითხისგან ცალკე შეინახეთ. როცა სწორი აწყობა ამუშავდება, პროფილები, რწმუნებები და მარშრუტები მაინც საკუთარი პრობლემებია და პროფილის რედაქტირების არც ერთი რაოდენობა არასწორი არქიტექტურის ბინარს არ ამუშავებს.