რატომ აჩვენებს apt-cache თქვენი VPN პაკეტისთვის დაყენებული (არაფერი)

VPN პაკეტი, რომელიც იტყობინება Installed: (none), არ აკლია; ის უბრალოდ არ არის დაყენებული. სტრიქონი, რომელიც წყვეტს, შეგიძლიათ თუ არა მისი დაყენება, არის Candidate, რომელსაც APT იღებს ინდექსებიდან, suite-ის სახელიდან, არქიტექტურიდან და მოქმედი ჩამაგრების ნებისმიერი წესიდან. გაუჩინარებული VPN პაკეტის შესახებ შეტყობინებების უმეტესობა აღმოჩნდება კანდიდატის პრობლემად და არა პაკეტირების პრობლემად. წაიკითხეთ ორივე სტრიქონი, სანამ წყაროს რომელიმე ჩანაწერს შეეხებით.

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

რას გეუბნებათ apt-cache policy-ს გამოტანილი

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

apt-cache policy openvpn
apt-cache madison openvpn
apt list -a network-manager-openvpn

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

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

კანდიდატის გაქრობის ოთხი მიზეზი

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

თქვენს წყაროებში suite-ის სახელი უნდა შეესაბამებოდეს იმ დისტრიბუტივს, რომლისთვისაც პაკეტი აშენდა. trixie სარკეზე მიმართული Debian bookworm სისტემა, ან განახლების დროს sources.list.d ფაილში გადარქმეული Ubuntu გამოშვება, ვერაფერს წყვეტს მხოლოდ მეორე suite-ში არსებული პაკეტებისთვის. შეადარეთ lsb_release -cs ყოველი ჩანაწერის suite ველს.

APT ხედავს მხოლოდ იმ არქიტექტურებისთვის აშენებულ პაკეტებს, რომლებსაც dpkg იცნობს. 32-ბიტიანი კონტეინერი, arm64 გამოსახულება ან Raspberry Pi-ზე დაყენება, რომელიც ითხოვს მხოლოდ amd64-ისთვის მიწოდებულ პაკეტს, შეცდომის შეტყობინების ნაცვლად ცარიელ კანდიდატს იღებს. dpkg --print-architecture და dpkg --print-foreign-architectures გეტყვიან, რომელ კრებულში ხართ სინამდვილეში.

კომპონენტებიც მნიშვნელოვანია. contrib-ში ან non-free-ში მყოფი პაკეტი უხილავია, როცა მხოლოდ main არის ჩართული, და Ubuntu-ს universe იგივე გზით იქცევა. ინდექსი არსებობს და პაკეტი მასშია; უბრალოდ თქვენი ჩართული კომპონენტების სია არ მოიცავს მას.

ჩამაგრება ჩუმი მიზეზია. ფაილს /etc/apt/preferences.d-ში შეუძლია პაკეტი დაყენების ზღურბლს ქვემოთ შეზღუდოს, და მაშინ სრულიად კარგი კანდიდატი ქრება გამოტანილიდან, მაშინ როცა ინდექსი ჯერ კიდევ ჩამოთვლის მას. ვინაიდან policy ბეჭდავს პრიორიტეტებს ყოველი წყაროს გვერდით, პაკეტი, რომლის ყოველ წყაროს დაბალი ჩამაგრების ნომერი აქვს, არის ნიშანი.

მოძველებული ინდექსები დაკარგულ პაკეტებს ჰგავს

ქეში მომენტალური სურათია. თუ ბოლო apt update ერთ ინდექსზე ჩავარდა, მოთხოვნები კვლავ ძველი ასლიდან პასუხობს და შესაძლოა მოსალოდნელი პაკეტი იმ ასლში არ იყოს.

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

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

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

OpenVPN დემონია და ნაწილები, რომლებიც ადამიანებს ჩვეულებრივ სურთ, ცალკე პაკეტებია.

ძრავა, NetworkManager-ის დანამატი და სამუშაო მაგიდის რედაქტორი სამი პაკეტია სამი სახელით, და დანამატს აქვს GTK ვარიანტი, რომლის სახელი დისტრიბუტივების მიხედვით განსხვავდება. apt-cache search --names-only openvpn ემთხვევა სახელებსა და მოწოდებულ სახელებს და არა აღწერებს, და ეს არის ის, რაც გჭირდებათ, როცა დაახლოებით იცით, რა ჰქვია ამ რამეს.

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

წყაროები ბოლოს შეცვალეთ, შემდეგ შეამოწმეთ ოპერაცია

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

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

როცა კანდიდატი გამოჩნდება, მოდელირეთ დადასტურებამდე: apt-get install --simulate პაკეტის სახელით გვიჩვენებს, რა ჩაითრევა და რა წაიშლება. პაკეტის ხელმისაწვდომობა, დაყენება და მუშა გვირაბი რჩება სამ ცალკე ეტაპად და გვირაბს ჯერ კიდევ სჭირდება თავისი პროფილი, რწმუნებები, მარშრუტები და DNS, სანამ ტრაფიკს ატარებს.