რატომ მუშაობს openssl ბრძანება, მაგრამ VPN-ის აწყობა ვერ ხერხდება

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

გაშვების გარემო და აწყობის შეყვანა სხვადასხვა პაკეტია

დისტრიბუცია OpenSSL-ს ყოფს გაშვების პაკეტად, რომელიც იძლევა საერთო ბიბლიოთეკას და ბრძანების ხაზის ხელსაწყოს, და განვითარების პაკეტად, რომელიც იძლევა ჰედერებს, ვერსიის გარეშე ბმის სახელებს და pkg-config მეტამონაცემებს. პირველის დაყენება მეორეს არ აყენებს, და კომპილატორს მხოლოდ მეორე სჭირდება.

შეამოწმეთ, რა არის რეალურად არსებული და არა რა გახსოვთ, რომ დააყენეთ. Debian-ზე დაფუძნებულ სისტემებში განვითარების პაკეტი ჩვეულებრივ libssl-dev არის, ხოლო გაშვების დრო არის ვერსიონირებული ბიბლიოთეკის პაკეტი პლუს openssl ბინარული.

dpkg -l | grep -E 'libssl-dev|libssl3|openssl'
pkg-config --modversion openssl
openssl version

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

წაიკითხეთ თავად აწყობის აღმოჩენის გამოტანა

უმეტესი წარუმატებლობა კონფიგურაციის ჟურნალში ჩანს, თუ მას შეჯამებამდე წაიკითხავთ. CMake-ის FindOpenSSL მოდული იტყობინება, რომელი include დირექტორია და რომელი ბიბლიოთეკები იპოვა, და კონკრეტული შეტყობინებით მარცხდება, როცა საჭირო კომპონენტი არ არის.

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

cmake -S . -B build -DCMAKE_BUILD_TYPE=Release
grep -i -E 'openssl|ssl' build/CMakeCache.txt

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

მიმართეთ აწყობა სწორ დაყენებაზე, ვიწროდ

როცა დამტკიცებული OpenSSL ნაგულისხმევ ძიების გზის გარეთ ცხოვრობს, FindOpenSSL ადასტურებს OPENSSL_ROOT_DIR-ს, როგორც მინიშნებას სწორედ იმ აწყობისთვის. Unix-ის მსგავს სისტემებში ის pkg-config-საც ეკითხება, ამიტომ შესაბამისი PKG_CONFIG_PATH დაგეხმარებათ რაიმეს გლობალურად შეუცვლელად.

cmake -S . -B build -DOPENSSL_ROOT_DIR=/opt/openssl-3.2 -DCMAKE_BUILD_TYPE=Release
ldd build/vpn_client | grep -i ssl

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

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

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

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

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

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