מדוע פקודת 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, והשלישית מדווחת על גרסת זמן הריצה. שורה חסרה בפלט הראשון מסבירה את השגיאה מיד. אי-התאמת גרסאות בין השנייה לשלישית היא בעיה אחרת, ובדרך כלל פירושה ששתי התקנות מתחרות.

קראו את פלט הגילוי של הבנייה עצמה

רוב הכשלים נראים ביומן התצורה אם קוראים אותו לפני הסיכום. מודול FindOpenSSL של CMake מדווח איזו ספריית 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 ישנה כהיסטוריה ולא כמפרט. בדקו את האפשרויות של מהדורת קוד המקור עצמה לגבי אילו ממשקים מופעלים כברירת מחדל. לאחר מכן בנו רק את מה שצריך, משום שכל תלות אופציונלית היא בעיית גילוי נוספת שממתינה לקרות.