லினக்ஸில் பல முகங்கள் உள்ளன: எந்த விநியோகத்திலும் எவ்வாறு வேலை செய்வது

எந்தவொரு விநியோகத்திலும் செயல்படும் காப்புப்பிரதி பயன்பாட்டை உருவாக்குவது எளிதான காரியமல்ல. Red Hat 6 மற்றும் Debian 6 இலிருந்து OpenSUSE 15.1 மற்றும் Ubuntu 19.04 வரையிலான விநியோகங்களில் Linux க்கான Veeam ஏஜென்ட் செயல்படுவதை உறுதிசெய்ய, மென்பொருள் தயாரிப்பில் கர்னல் தொகுதி உள்ளதா என்பதைக் கருத்தில் கொண்டு, நீங்கள் பல சிக்கல்களைத் தீர்க்க வேண்டும்.

மாநாட்டில் ஆற்றிய உரையின் அடிப்படையில் கட்டுரை உருவாக்கப்பட்டது லினக்ஸ் பீட்டர் 2019.

லினக்ஸ் மிகவும் பிரபலமான இயக்க முறைமைகளில் ஒன்று மட்டுமல்ல. அடிப்படையில், இது ஒரு தளமாகும், இதன் அடிப்படையில் நீங்கள் தனித்துவமான ஒன்றை உருவாக்கலாம், உங்களுடையது. இதற்கு நன்றி, லினக்ஸில் பல விநியோகங்கள் உள்ளன, அவை அவற்றின் மென்பொருள் கூறுகளின் தொகுப்பில் வேறுபடுகின்றன. இங்கே ஒரு சிக்கல் எழுகிறது: எந்தவொரு விநியோகத்திலும் ஒரு மென்பொருள் தயாரிப்பு செயல்பட, நீங்கள் ஒவ்வொன்றின் அம்சங்களையும் கணக்கில் எடுத்துக்கொள்ள வேண்டும்.

தொகுப்பு மேலாளர்கள். .deb vs .rpm

வெவ்வேறு விநியோகங்களில் தயாரிப்பை விநியோகிப்பதில் உள்ள வெளிப்படையான சிக்கலுடன் ஆரம்பிக்கலாம்.
மென்பொருள் தயாரிப்புகளை விநியோகிப்பதற்கான மிகவும் பொதுவான வழி, தொகுப்பை ஒரு களஞ்சியத்தில் வைப்பதாகும், இதனால் கணினியில் கட்டமைக்கப்பட்ட தொகுப்பு மேலாளர் அதை அங்கிருந்து நிறுவ முடியும்.
இருப்பினும், எங்களிடம் இரண்டு பிரபலமான தொகுப்பு வடிவங்கள் உள்ளன: ஆர்பிஎம் и டெப். இதன் பொருள் அனைவரும் ஆதரிக்க வேண்டும்.

டெப் தொகுப்புகளின் உலகில், பொருந்தக்கூடிய நிலை ஆச்சரியமாக இருக்கிறது. அதே தொகுப்பு Debian 6 மற்றும் Ubuntu 19.04 இரண்டிலும் சமமாக நிறுவப்பட்டு வேலை செய்கிறது. பழைய டெபியன் விநியோகங்களில் வகுக்கப்பட்ட தொகுப்புகளை உருவாக்குதல் மற்றும் அவற்றுடன் பணிபுரியும் செயல்முறைக்கான தரநிலைகள் புதிய லினக்ஸ் மின்ட் மற்றும் எலிமெண்டரி ஓஎஸ் ஆகியவற்றில் பொருத்தமானதாகவே இருக்கும். எனவே, Linux க்கான Veeam Agent விஷயத்தில், ஒவ்வொரு வன்பொருள் தளத்திற்கும் ஒரு deb தொகுப்பு போதுமானது.

ஆனால் rpm தொகுப்புகளின் உலகில், வேறுபாடுகள் அதிகம். முதலாவதாக, Red Hat மற்றும் SUSE ஆகிய இரண்டு முற்றிலும் சுயாதீனமான விநியோகஸ்தர்கள் இருப்பதால், இணக்கத்தன்மை முற்றிலும் தேவையற்றது. இரண்டாவதாக, இந்த விநியோகஸ்தர்கள் அவற்றிலிருந்து விநியோகக் கருவிகளைக் கொண்டுள்ளனர். ஆதரவு மற்றும் சோதனை. அவர்களுக்கிடையில் இணக்கத்தன்மையும் தேவையில்லை. el6, el7 மற்றும் el8 ஆகியவை அவற்றின் சொந்த தொகுப்புகளைக் கொண்டுள்ளன. ஃபெடோராவிற்கு தனி தொகுப்பு. SLES11 மற்றும் 12 க்கான தொகுப்புகள் மற்றும் openSUSE க்கு தனி ஒன்று. முக்கிய பிரச்சனை சார்புகள் மற்றும் தொகுப்பு பெயர்கள்.

சார்பு பிரச்சனை

துரதிர்ஷ்டவசமாக, ஒரே தொகுப்புகள் வெவ்வேறு விநியோகங்களில் வெவ்வேறு பெயர்களில் முடிவடையும். வீம் தொகுப்பு சார்புகளின் பகுதி பட்டியல் கீழே உள்ளது.

EL7க்கு:
SLES 12க்கு:

• libblkid
• libgcc
• libstdc++
• ncurses-libs
• உருகி-லிப்ஸ்
• கோப்பு-லிப்ஸ்
• veamsnap=3.0.2.1185

• libblkid1
• libgcc_s1
• libstdc++6
• libmagic1
• libfuse2
• veamsnap-kmp=3.0.2.1185

இதன் விளைவாக, சார்புகளின் பட்டியல் விநியோகத்திற்கு தனித்துவமானது.

புதுப்பிக்கப்பட்ட பதிப்பு பழைய தொகுப்பு பெயரில் மறைக்கத் தொடங்கும் போது மோசமானது.

உதாரணம்:

தொகுப்பு Fedora 24 இல் புதுப்பிக்கப்பட்டது சபிக்கிறது பதிப்பு 5 முதல் பதிப்பு 6 வரை. எங்கள் தயாரிப்பு பழைய விநியோகங்களுடன் இணக்கத்தன்மையை உறுதிப்படுத்த பதிப்பு 5 உடன் கட்டப்பட்டது. ஃபெடோரா 5 இல் நூலகத்தின் பழைய 24 வது பதிப்பைப் பயன்படுத்த, நான் தொகுப்பைப் பயன்படுத்த வேண்டியிருந்தது ncurses-compat-libs.

இதன் விளைவாக, ஃபெடோராவிற்கு வெவ்வேறு சார்புகளுடன் இரண்டு தொகுப்புகள் உள்ளன.

மேலும் சுவாரஸ்யமானது. அடுத்த விநியோக புதுப்பித்தலுக்குப் பிறகு, தொகுப்பு ncurses-compat-libs நூலகத்தின் பதிப்பு 5 இல் அது கிடைக்கவில்லை. ஒரு விநியோகஸ்தருக்கு பழைய நூலகங்களை விநியோகத்தின் புதிய பதிப்பிற்கு இழுப்பது விலை அதிகம். சிறிது நேரம் கழித்து, SUSE விநியோகங்களில் சிக்கல் மீண்டும் மீண்டும் வந்தது.

இதன் விளைவாக, சில விநியோகங்கள் அவற்றின் வெளிப்படையான சார்புநிலையைக் கைவிட வேண்டியிருந்தது ncurses-libs, மற்றும் நூலகத்தின் எந்தப் பதிப்பிலும் வேலை செய்யக்கூடிய வகையில் தயாரிப்பை சரிசெய்யவும்.

மூலம், Red Hat இன் பதிப்பு 8 இல் இனி மெட்டா தொகுப்பு இல்லை மலைப்பாம்பு, இது நல்ல பழையதைக் குறிக்கிறது பைதான் 2.7. அங்கு உள்ளது python2 и மலைப்பாம்பு3.

தொகுப்பு மேலாளர்களுக்கு மாற்று

சார்புகளின் சிக்கல் பழையது மற்றும் நீண்ட காலமாக தெளிவாக உள்ளது. சார்பு நரகத்தை நினைவில் கொள்ளுங்கள்.
பல்வேறு நூலகங்கள் மற்றும் பயன்பாடுகளை ஒன்றிணைக்க, அவை அனைத்தும் சீராக வேலை செய்யும் மற்றும் முரண்படாது - உண்மையில், எந்தவொரு லினக்ஸ் விநியோகஸ்தரும் தீர்க்க முயற்சிக்கும் பணி இது.

தொகுப்பு மேலாளர் இந்த சிக்கலை முற்றிலும் மாறுபட்ட வழியில் தீர்க்க முயற்சிக்கிறார். ஸ்னாப்பி நியமனத்திலிருந்து. முக்கிய யோசனை: பயன்பாடு தனிமைப்படுத்தப்பட்ட மற்றும் பிரதான அமைப்பிலிருந்து பாதுகாக்கப்பட்ட சாண்ட்பாக்ஸில் இயங்குகிறது. ஒரு பயன்பாட்டிற்கு நூலகங்கள் தேவைப்பட்டால், அவை பயன்பாட்டுடன் வழங்கப்படுகின்றன.

Flatpak லினக்ஸ் கொள்கலன்களைப் பயன்படுத்தி சாண்ட்பாக்ஸில் பயன்பாடுகளை இயக்கவும் உங்களை அனுமதிக்கிறது. சாண்ட்பாக்ஸ் யோசனையும் பயன்படுத்தப்படுகிறது AppImage.

எந்தவொரு விநியோகத்திற்கும் ஒரு தொகுப்பை உருவாக்க இந்த தீர்வுகள் உங்களை அனுமதிக்கின்றன. ஒரு வேளை Flatpak பயன்பாட்டை நிறுவுதல் மற்றும் தொடங்குதல் நிர்வாகியின் அறிவு இல்லாமல் கூட சாத்தியமாகும்.

முக்கிய பிரச்சனை என்னவென்றால், எல்லா பயன்பாடுகளும் சாண்ட்பாக்ஸில் இயங்க முடியாது. சிலருக்கு மேடையில் நேரடி அணுகல் தேவை. நான் கர்னல் தொகுதிகள் பற்றி கூட பேசவில்லை, அவை கர்னலை கண்டிப்பாக சார்ந்துள்ளது மற்றும் சாண்ட்பாக்ஸ் கருத்துக்கு பொருந்தாது.

இரண்டாவது பிரச்சனை என்னவென்றால், Red Hat மற்றும் SUSE இலிருந்து நிறுவன சூழலில் பிரபலமான விநியோகங்கள் இன்னும் Snappy மற்றும் Flatpak க்கான ஆதரவைக் கொண்டிருக்கவில்லை.

இது சம்பந்தமாக, லினக்ஸிற்கான வீம் ஏஜென்ட் கிடைக்கவில்லை snapcraft.io இல்லை flathub.org.

தொகுப்பு மேலாளர்கள் பற்றிய கேள்வியை முடிக்க, பைனரி கோப்புகள் மற்றும் அவற்றை ஒரு தொகுப்பில் நிறுவுவதற்கான ஸ்கிரிப்டை இணைப்பதன் மூலம் தொகுப்பு மேலாளர்களை முழுவதுமாக கைவிட ஒரு விருப்பம் உள்ளது என்பதை நான் கவனிக்க விரும்புகிறேன்.

இத்தகைய தொகுப்பு பல்வேறு விநியோகங்கள் மற்றும் தளங்களுக்கு ஒரு பொதுவான தொகுப்பை உருவாக்கவும், ஊடாடும் நிறுவல் செயல்முறையை மேற்கொள்ளவும், தேவையான தனிப்பயனாக்கத்தை மேற்கொள்ளவும் உங்களை அனுமதிக்கிறது. லினக்ஸிற்கான இத்தகைய தொகுப்புகளை VMware இலிருந்து மட்டுமே நான் சந்தித்தேன்.

புதுப்பிப்பு சிக்கல்

அனைத்து சார்பு சிக்கல்களும் தீர்க்கப்பட்டாலும், நிரல் ஒரே விநியோகத்தில் வேறுபட்டு இயங்கலாம். இது புதுப்பிப்புகளின் விஷயம்.

3 புதுப்பிப்பு உத்திகள் உள்ளன:

• எப்பொழுதும் புதுப்பிக்காமல் இருப்பதுதான் எளிமையானது. நான் சேவையகத்தை அமைத்து அதை மறந்துவிட்டேன். எல்லாம் வேலை செய்தால் ஏன் புதுப்பிக்க வேண்டும்? முதல் முறையாக நீங்கள் ஆதரவைத் தொடர்பு கொள்ளும்போது சிக்கல்கள் தொடங்கும். விநியோகத்தை உருவாக்கியவர் புதுப்பிக்கப்பட்ட வெளியீட்டை மட்டுமே ஆதரிக்கிறார்.
• நீங்கள் விநியோகஸ்தரை நம்பலாம் மற்றும் தானியங்கி புதுப்பிப்புகளை அமைக்கலாம். இந்த வழக்கில், தோல்வியுற்ற புதுப்பித்தலுக்குப் பிறகு உடனடியாக ஆதரவுக்கான அழைப்பு சாத்தியமாகும்.
• சோதனை உள்கட்டமைப்பில் இயக்கிய பின்னரே கைமுறையாக புதுப்பிப்பதற்கான விருப்பம் மிகவும் நம்பகமானது, ஆனால் விலை உயர்ந்தது மற்றும் நேரத்தை எடுத்துக்கொள்ளும். எல்லோராலும் வாங்க முடியாது.

வெவ்வேறு பயனர்கள் வெவ்வேறு புதுப்பிப்பு உத்திகளைப் பயன்படுத்துவதால், சமீபத்திய வெளியீடுகள் மற்றும் முன்பு வெளியிடப்பட்டவை இரண்டையும் ஆதரிக்க வேண்டியது அவசியம். இது வளர்ச்சி மற்றும் சோதனை செயல்முறை இரண்டையும் சிக்கலாக்கும் மற்றும் ஆதரவு குழுவிற்கு தலைவலி சேர்க்கிறது.

பல்வேறு வன்பொருள் தளங்கள்

வெவ்வேறு வன்பொருள் இயங்குதளங்கள் பெரும்பாலும் நேட்டிவ் குறியீட்டிற்குக் குறிப்பிட்ட ஒரு பிரச்சனை. குறைந்தபட்சம், ஒவ்வொரு ஆதரிக்கப்படும் தளத்திற்கும் நீங்கள் பைனரிகளை சேகரிக்க வேண்டும்.

Linux திட்டத்திற்கான வீம் ஏஜெண்டில், இந்த RISC போன்ற எதையும் எங்களால் இன்னும் ஆதரிக்க முடியாது.

இந்த பிரச்சினையில் நான் விரிவாக வாழ மாட்டேன். நான் முக்கிய சிக்கல்களை மட்டுமே கோடிட்டுக் காட்டுவேன்: தளம் சார்ந்த வகைகள், போன்றவை size_t, கட்டமைப்பு சீரமைப்பு மற்றும் பைட் வரிசை.

நிலையான மற்றும்/அல்லது மாறும் இணைப்பு

ஆனால் கேள்வி "நூலகங்களை எவ்வாறு இணைப்பது - மாறும் அல்லது நிலையானது?" விவாதிக்கத் தகுந்தது.

ஒரு விதியாக, லினக்ஸின் கீழ் C/C++ பயன்பாடுகள் டைனமிக் இணைப்பைப் பயன்படுத்துகின்றன. பயன்பாடு ஒரு குறிப்பிட்ட விநியோகத்திற்காக கட்டமைக்கப்பட்டிருந்தால் இது நன்றாக வேலை செய்கிறது.

ஒரு பைனரி கோப்புடன் பல்வேறு விநியோகங்களை உள்ளடக்குவது பணி என்றால், நீங்கள் பழைய ஆதரிக்கப்படும் விநியோகத்தில் கவனம் செலுத்த வேண்டும். எங்களைப் பொறுத்தவரை, இது Red Hat 6. இதில் gcc 4.4 உள்ளது, இது C++11 தரநிலை கூட ஆதரிக்காது. முழுமையாக.

C++6.3ஐ முழுமையாக ஆதரிக்கும் gcc 14ஐப் பயன்படுத்தி எங்கள் திட்டத்தை உருவாக்குகிறோம். இயற்கையாகவே, இந்த விஷயத்தில், Red Hat 6 இல் நீங்கள் libstdc++ ஐ எடுத்துச் செல்ல வேண்டும் மற்றும் உங்களுடன் நூலகங்களை அதிகரிக்க வேண்டும். அவற்றை நிலையான முறையில் இணைப்பதே எளிதான வழி.

ஆனால் அந்தோ, எல்லா நூலகங்களையும் நிலையான முறையில் இணைக்க முடியாது.

முதலாவதாக, கணினி நூலகங்கள் போன்றவை லிப்ஃபியூஸ், libblkid கர்னல் மற்றும் அதன் தொகுதிகளுடன் அவற்றின் பொருந்தக்கூடிய தன்மையை உறுதிசெய்ய, மாறும் வகையில் இணைக்க வேண்டியது அவசியம்.

இரண்டாவதாக, உரிமங்களில் ஒரு நுணுக்கம் உள்ளது.

ஜிபிஎல் உரிமம் அடிப்படையில் நீங்கள் திறந்த மூலக் குறியீட்டுடன் மட்டுமே நூலகங்களை இணைக்க அனுமதிக்கிறது. MIT மற்றும் BSD ஆகியவை நிலையான இணைப்பை அனுமதிக்கின்றன மற்றும் ஒரு திட்டத்தில் நூலகங்களை சேர்க்க அனுமதிக்கின்றன. ஆனால் எல்ஜிபிஎல் நிலையான இணைப்பிற்கு முரணாகத் தெரியவில்லை, ஆனால் இணைப்பிற்குத் தேவையான கோப்புகள் பகிரப்பட வேண்டும்.

பொதுவாக, டைனமிக் இணைப்பைப் பயன்படுத்துவது, எதையும் வழங்குவதைத் தடுக்கும்.

C/C++ பயன்பாடுகளை உருவாக்குதல்

வெவ்வேறு இயங்குதளங்கள் மற்றும் விநியோகங்களுக்கான C/C++ பயன்பாடுகளை உருவாக்க, gcc இன் பொருத்தமான பதிப்பைத் தேர்ந்தெடுத்து அல்லது உருவாக்கவும் மற்றும் குறிப்பிட்ட கட்டமைப்புகளுக்கு குறுக்கு-தொகுப்பாளர்களைப் பயன்படுத்தவும் மற்றும் நூலகங்களின் முழு தொகுப்பையும் ஒருங்கிணைக்கவும் போதுமானது. இந்த வேலை மிகவும் சாத்தியமானது, ஆனால் மிகவும் தொந்தரவாக உள்ளது. தேர்ந்தெடுக்கப்பட்ட கம்பைலர் மற்றும் நூலகங்கள் செயல்படக்கூடிய பதிப்பை வழங்கும் என்பதற்கு எந்த உத்தரவாதமும் இல்லை.

ஒரு வெளிப்படையான நன்மை: உள்கட்டமைப்பு மிகவும் எளிமைப்படுத்தப்பட்டுள்ளது, ஏனெனில் முழு கட்டுமான செயல்முறையும் ஒரு இயந்திரத்தில் முடிக்கப்படலாம். கூடுதலாக, ஒரு கட்டிடக்கலைக்கு ஒரு தொகுப்பு பைனரிகளை சேகரித்தால் போதும், அவற்றை வெவ்வேறு விநியோகங்களுக்கான தொகுப்புகளாக தொகுக்கலாம். லினக்ஸிற்கான வீம் ஏஜெண்டிற்கு வீம் தொகுப்புகள் இப்படித்தான் உருவாக்கப்படுகின்றன.

இந்த விருப்பத்திற்கு மாறாக, நீங்கள் ஒரு கட்டுமான பண்ணையை தயார் செய்யலாம், அதாவது சட்டசபைக்கு பல இயந்திரங்கள். அத்தகைய ஒவ்வொரு இயந்திரமும் ஒரு குறிப்பிட்ட விநியோகம் மற்றும் ஒரு குறிப்பிட்ட கட்டமைப்பிற்கான பயன்பாட்டுத் தொகுப்பு மற்றும் தொகுப்புகளை வழங்கும். இந்த வழக்கில், விநியோகஸ்தர் தயாரித்த வழிமுறைகளைப் பயன்படுத்தி தொகுத்தல் மேற்கொள்ளப்படுகிறது. அதாவது, தொகுப்பியைத் தயாரித்து நூலகங்களைத் தேர்ந்தெடுக்கும் நிலை ஒழிகிறது. கூடுதலாக, உருவாக்க செயல்முறை எளிதாக இணையாக முடியும்.

இருப்பினும், இந்த அணுகுமுறையில் ஒரு குறைபாடு உள்ளது: ஒரே கட்டமைப்பிற்குள் ஒவ்வொரு விநியோகத்திற்கும், உங்கள் சொந்த பைனரி கோப்புகளை நீங்கள் சேகரிக்க வேண்டும். மற்றொரு குறைபாடு என்னவென்றால், இவ்வளவு பெரிய எண்ணிக்கையிலான இயந்திரங்கள் பராமரிக்கப்பட வேண்டும் மற்றும் அதிக அளவு வட்டு இடம் மற்றும் ரேம் ஒதுக்கப்பட வேண்டும்.

இப்படித்தான் veeamsnap கர்னல் தொகுதியின் KMOD தொகுப்புகள் Red Hat விநியோகங்களுக்காக தொகுக்கப்படுகின்றன.

கட்டுமான சேவையைத் திறக்கவும்

SUSE இன் சக ஊழியர்கள், பயன்பாடுகளைத் தொகுப்பதற்கும் தொகுப்புகளை அசெம்பிள் செய்வதற்கும் ஒரு சிறப்புச் சேவையின் வடிவத்தில் சில நடுத்தர நிலத்தை செயல்படுத்த முயன்றனர் - openbuildservice.

அடிப்படையில், இது ஒரு மெய்நிகர் இயந்திரத்தை உருவாக்கும் ஒரு ஹைப்பர்வைசர் ஆகும், அதில் தேவையான அனைத்து தொகுப்புகளையும் நிறுவுகிறது, பயன்பாட்டை தொகுக்கிறது மற்றும் இந்த தனிமைப்படுத்தப்பட்ட சூழலில் தொகுப்பை உருவாக்குகிறது, அதன் பிறகு மெய்நிகர் இயந்திரம் வெளியிடப்படுகிறது.

OpenBuildService இல் செயல்படுத்தப்பட்ட அட்டவணையானது, உகந்த தொகுப்பு உருவாக்க வேகத்திற்கு எத்தனை மெய்நிகர் இயந்திரங்களைத் தொடங்கலாம் என்பதைத் தீர்மானிக்கும். உள்ளமைக்கப்பட்ட கையொப்பமிடும் பொறிமுறையானது தொகுப்புகளில் கையொப்பமிட்டு அவற்றை உள்ளமைக்கப்பட்ட களஞ்சியத்தில் பதிவேற்றும். உள்ளமைக்கப்பட்ட பதிப்பு கட்டுப்பாட்டு அமைப்பு மாற்றங்கள் மற்றும் உருவாக்கங்களின் வரலாற்றைச் சேமிக்கும். இந்த அமைப்பில் உங்கள் ஆதாரங்களைச் சேர்ப்பது மட்டுமே எஞ்சியுள்ளது. நீங்களே சேவையகத்தை அமைக்க வேண்டியதில்லை; நீங்கள் திறந்த ஒன்றைப் பயன்படுத்தலாம்.

இருப்பினும், ஒரு சிக்கல் உள்ளது: அத்தகைய அறுவடை இயந்திரம் தற்போதுள்ள உள்கட்டமைப்பில் பொருத்துவது கடினம். எடுத்துக்காட்டாக, பதிப்புக் கட்டுப்பாடு தேவையில்லை; மூலக் குறியீடுகளுக்கு எங்களிடம் ஏற்கனவே சொந்தமாக உள்ளது. எங்கள் கையொப்ப வழிமுறை வேறுபட்டது: நாங்கள் ஒரு சிறப்பு சேவையகத்தைப் பயன்படுத்துகிறோம். ஒரு களஞ்சியமும் தேவையில்லை.

கூடுதலாக, பிற விநியோகங்களுக்கான ஆதரவு - எடுத்துக்காட்டாக, Red Hat - மிகவும் மோசமாக செயல்படுத்தப்படுகிறது, இது புரிந்துகொள்ளத்தக்கது.

அத்தகைய சேவையின் நன்மை SUSE விநியோகத்தின் அடுத்த பதிப்பிற்கான விரைவான ஆதரவாகும். வெளியீட்டின் அதிகாரப்பூர்வ அறிவிப்புக்கு முன், அசெம்பிளிக்குத் தேவையான தொகுப்புகள் பொது களஞ்சியத்தில் வெளியிடப்படும். OpenBuildService இல் கிடைக்கும் விநியோகங்களின் பட்டியலில் புதியது தோன்றும். நாங்கள் பெட்டியை சரிபார்த்து, அது கட்டுமானத் திட்டத்தில் சேர்க்கப்பட்டது. எனவே, விநியோகத்தின் புதிய பதிப்பைச் சேர்ப்பது கிட்டத்தட்ட ஒரே கிளிக்கில் செய்யப்படுகிறது.

எங்கள் உள்கட்டமைப்பில், OpenBuildService ஐப் பயன்படுத்தி, SUSE விநியோகங்களுக்கான veeamsnap கர்னல் தொகுதியின் முழு வகை KMP தொகுப்புகளும் இணைக்கப்பட்டுள்ளன.

அடுத்து, கர்னல் தொகுதிக்கூறுகளின் குறிப்பிட்ட சிக்கல்களில் நான் வசிக்க விரும்புகிறேன்.

கர்னல் ஏபிஐ

லினக்ஸ் கர்னல் தொகுதிகள் வரலாற்று ரீதியாக மூல வடிவத்தில் விநியோகிக்கப்படுகின்றன. உண்மை என்னவென்றால், கர்னலை உருவாக்குபவர்கள் கர்னல் தொகுதிகளுக்கான நிலையான API ஐ ஆதரிக்கும் அக்கறையுடன் தங்களைச் சுமக்கவில்லை, குறிப்பாக பைனரி மட்டத்தில், மேலும் kABI என குறிப்பிடப்படுகிறது.

வெண்ணிலா கர்னலுக்கான தொகுதியை உருவாக்க, இந்த குறிப்பிட்ட கர்னலின் தலைப்புகள் உங்களுக்கு நிச்சயமாகத் தேவைப்படும், மேலும் இது இந்த கர்னலில் மட்டுமே வேலை செய்யும்.

கர்னலைப் புதுப்பிக்கும்போது தொகுதிகளை உருவாக்கும் செயல்முறையை தானியக்கமாக்க DKMS உங்களை அனுமதிக்கிறது. இதன் விளைவாக, டெபியன் களஞ்சியத்தின் பயனர்கள் (மற்றும் அதன் பல உறவினர்கள்) கர்னல் தொகுதிகளை விநியோகஸ்தரின் களஞ்சியத்தில் இருந்து அல்லது DKMS ஐப் பயன்படுத்தி மூலத்திலிருந்து தொகுக்கப்படுகின்றன.

இருப்பினும், இந்த நிலைமை குறிப்பாக எண்டர்பிரைஸ் பிரிவுக்கு பொருந்தாது. தனியுரிம குறியீடு விநியோகஸ்தர்கள் தயாரிப்பை தொகுக்கப்பட்ட பைனரிகளாக விநியோகிக்க விரும்புகிறார்கள்.

பாதுகாப்பு காரணங்களுக்காக உற்பத்தி சேவையகங்களில் மேம்பாட்டுக் கருவிகளை வைத்திருக்க நிர்வாகிகள் விரும்பவில்லை. Red Hat மற்றும் SUSE போன்ற Enterprise Linux விநியோகஸ்தர்கள் தங்கள் பயனர்களுக்கு நிலையான kABI ஐ ஆதரிக்கலாம் என்று முடிவு செய்தனர். இதன் விளைவாக Red Hat க்கான KMOD தொகுப்புகள் மற்றும் SUSE க்கான KMP தொகுப்புகள்.

இந்த தீர்வின் சாராம்சம் மிகவும் எளிமையானது. விநியோகத்தின் குறிப்பிட்ட பதிப்பிற்கு, கர்னல் API உறைந்திருக்கும். விநியோகஸ்தர் அவர் கர்னலைப் பயன்படுத்துகிறார், எடுத்துக்காட்டாக, 3.10, மேலும் கர்னல் இடைமுகங்களைப் பாதிக்காத திருத்தங்கள் மற்றும் மேம்பாடுகளை மட்டுமே செய்கிறார், மேலும் முதல் கர்னலுக்காக சேகரிக்கப்பட்ட தொகுதிகள் மீண்டும் தொகுக்கப்படாமல் அனைத்து அடுத்தடுத்தவற்றிற்கும் பயன்படுத்தப்படலாம்.

Red Hat அதன் முழு வாழ்நாள் முழுவதும் விநியோகத்திற்கான kABI இணக்கத்தன்மையைக் கோருகிறது. அதாவது, rhel 6.0 க்கான கூடியிருந்த தொகுதி (நவம்பர் 2010 வெளியீடு) பதிப்பு 6.10 இல் வேலை செய்ய வேண்டும் (வெளியீடு ஜூன் 2018). மேலும் இது கிட்டத்தட்ட 8 ஆண்டுகள். இயற்கையாகவே, இந்த பணி மிகவும் கடினம்.
kABI பொருந்தக்கூடிய சிக்கல்கள் காரணமாக veeamsnap தொகுதி வேலை செய்வதை நிறுத்திய பல நிகழ்வுகளை நாங்கள் பதிவு செய்துள்ளோம்.

RHEL 7.0 க்காக தொகுக்கப்பட்ட வீம்ஸ்னாப் தொகுதி, RHEL 7.5 இலிருந்து கர்னலுடன் பொருந்தாததாக மாறியது, ஆனால் அது ஏற்றப்பட்டது மற்றும் சேவையகத்தை செயலிழக்கச் செய்ய உத்தரவாதம் அளிக்கப்பட்டது, RHEL 7 க்கான kABI இணக்கத்தன்மையைப் பயன்படுத்துவதை நாங்கள் முற்றிலும் கைவிட்டோம்.

தற்போது, ​​RHEL 7 க்கான KMOD தொகுப்பில் ஒவ்வொரு வெளியீட்டு பதிப்பிற்கும் ஒரு அசெம்பிளி மற்றும் தொகுதியை ஏற்றும் ஸ்கிரிப்ட் உள்ளது.

SUSE ஆனது kABI இணக்கத்தன்மையின் பணியை மிகவும் கவனமாக அணுகியது. அவை ஒரு சேவைப் பொதிக்குள் மட்டுமே kABI இணக்கத்தன்மையை வழங்குகின்றன.

எடுத்துக்காட்டாக, SLES 12 இன் வெளியீடு செப்டம்பர் 2014 இல் நடந்தது. மேலும் SLES 12 SP1 ஏற்கனவே டிசம்பர் 2015 இல் இருந்தது, அதாவது ஒரு வருடத்திற்கும் மேலாக கடந்துவிட்டது. இரண்டு வெளியீடுகளும் 3.12 கர்னலைப் பயன்படுத்தினாலும், அவை kABI பொருந்தாது. வெளிப்படையாக, ஒரு வருடத்திற்கு kABI இணக்கத்தன்மையை பராமரிப்பது மிகவும் எளிதானது. வருடாந்திர கர்னல் தொகுதி புதுப்பித்தல் சுழற்சி தொகுதி உருவாக்குபவர்களுக்கு சிக்கல்களை ஏற்படுத்தக்கூடாது.

இந்த SUSE கொள்கையின் விளைவாக, எங்கள் veeamsnap தொகுதியில் kABI இணக்கத்தன்மையில் ஒரு சிக்கலையும் நாங்கள் பதிவு செய்யவில்லை. உண்மைதான், SUSEக்கான தொகுப்புகளின் எண்ணிக்கை ஏறக்குறைய அளவு அதிகமாக உள்ளது.

இணைப்புகள் மற்றும் பேக்போர்ட்கள்

விநியோகஸ்தர்கள் kABI இணக்கத்தன்மை மற்றும் கர்னல் நிலைத்தன்மையை உறுதிப்படுத்த முயற்சித்தாலும், அவர்கள் செயல்திறனை மேம்படுத்தவும் இந்த நிலையான கர்னலின் குறைபாடுகளை நீக்கவும் முயற்சி செய்கிறார்கள்.

அதே நேரத்தில், தங்கள் சொந்த "பிழைகளின் வேலை" க்கு கூடுதலாக, நிறுவன லினக்ஸ் கர்னலின் டெவலப்பர்கள் வெண்ணிலா கர்னலில் ஏற்படும் மாற்றங்களைக் கண்காணித்து அவற்றை "நிலையான" ஒன்றிற்கு மாற்றுகிறார்கள்.

சில நேரங்களில் இது புதியவற்றுக்கு வழிவகுக்கிறது தவறுகள்.

Red Hat 6 இன் சமீபத்திய வெளியீட்டில், சிறிய புதுப்பிப்புகளில் ஒன்றில் தவறு ஏற்பட்டது. ஸ்னாப்ஷாட் வெளியிடப்படும் போது வீம்ஸ்னாப் தொகுதி கணினி செயலிழக்க உத்தரவாதம் அளிக்கப்பட்டது. புதுப்பிப்புக்கு முன்னும் பின்னும் கர்னல் மூலங்களை ஒப்பிட்டுப் பார்த்ததில், பேக்போர்ட் தான் காரணம் என்று கண்டறிந்தோம். வெண்ணிலா கர்னல் பதிப்பு 4.19 இல் இதே போன்ற திருத்தம் செய்யப்பட்டது. இந்த பிழைத்திருத்தம் வெண்ணிலா கர்னலில் நன்றாக வேலை செய்தது, ஆனால் அதை "நிலையான" 2.6.32 க்கு மாற்றும்போது, ​​ஸ்பின்லாக்கில் ஒரு சிக்கல் எழுந்தது.

நிச்சயமாக, அனைவருக்கும் எப்போதும் பிழைகள் இருக்கும், ஆனால் குறியீட்டை 4.19 இலிருந்து 2.6.32 வரை இழுப்பது மதிப்புள்ளதா, நிலைத்தன்மையை ஆபத்தில் ஆழ்த்தியது?.. எனக்குத் தெரியவில்லை...

"நிலைத்தன்மை" மற்றும் "நவீனமயமாக்கல்" ஆகியவற்றுக்கு இடையேயான இழுபறியில் சந்தைப்படுத்தல் ஈடுபடும்போது மோசமான விஷயம். சந்தைப்படுத்தல் துறைக்கு புதுப்பிக்கப்பட்ட விநியோகத்தின் மையமானது ஒருபுறம் நிலையானதாக இருக்க வேண்டும், அதே நேரத்தில் செயல்திறனில் சிறப்பாகவும் புதிய அம்சங்களையும் கொண்டிருக்க வேண்டும். இது விசித்திரமான சமரசங்களுக்கு வழிவகுக்கிறது.

SLES 4.4 SP12 இலிருந்து கர்னல் 3 இல் ஒரு தொகுதியை உருவாக்க முயற்சித்தபோது, ​​அதில் வெண்ணிலா 4.8 இலிருந்து செயல்பாட்டைக் கண்டு நான் ஆச்சரியப்பட்டேன். எனது கருத்துப்படி, SLES 4.4 SP12 இலிருந்து 3 கர்னலின் தொகுதி I/O செயல்படுத்தல் SLES4.8 SP4.4 இலிருந்து நிலையான 12 கர்னலின் முந்தைய வெளியீட்டை விட 2 கர்னலைப் போலவே உள்ளது. SP4.8க்கான கர்னல் 4.4 இலிருந்து SLES 3 க்கு எந்த சதவீத குறியீடு மாற்றப்பட்டது என்பதை என்னால் தீர்மானிக்க முடியாது, ஆனால் கர்னலை அதே நிலையான 4.4 என்று கூட என்னால் அழைக்க முடியாது.

இதில் மிகவும் விரும்பத்தகாத விஷயம் என்னவென்றால், வெவ்வேறு கர்னல்களில் சமமாக வேலை செய்யும் ஒரு தொகுதியை எழுதும் போது, ​​நீங்கள் இனி கர்னல் பதிப்பை நம்ப முடியாது. நீங்கள் விநியோகத்தையும் கணக்கில் எடுத்துக்கொள்ள வேண்டும். சில நேரங்களில் நீங்கள் புதிய செயல்பாட்டுடன் தோன்றும் வரையறையில் ஈடுபடுவது நல்லது, ஆனால் இந்த வாய்ப்பு எப்போதும் தோன்றாது.

இதன் விளைவாக, குறியீடு வித்தியாசமான நிபந்தனை தொகுத்தல் உத்தரவுகளுடன் அதிகமாகிறது.

ஆவணப்படுத்தப்பட்ட கர்னல் API ஐ மாற்றும் இணைப்புகளும் உள்ளன.
நான் விநியோகத்தைக் கண்டேன் கேடி நியான் 5.16 மற்றும் இந்த கர்னல் பதிப்பில் உள்ள lookup_bdev அழைப்பு உள்ளீட்டு அளவுருக்களின் பட்டியலை மாற்றியதைக் கண்டு மிகவும் ஆச்சரியமடைந்தது.

அதை ஒன்றிணைக்க, lookup_bdev செயல்பாட்டில் முகமூடி அளவுரு உள்ளதா என்பதைச் சரிபார்க்கும் மேக்ஃபைலில் ஒரு ஸ்கிரிப்டைச் சேர்க்க வேண்டியிருந்தது.

கர்னல் தொகுதிகளில் கையொப்பமிடுதல்

ஆனால் தொகுப்பு விநியோக பிரச்சினைக்கு திரும்புவோம்.

நிலையான kABI இன் நன்மைகளில் ஒன்று, கர்னல் தொகுதிகள் பைனரி கோப்பாக கையொப்பமிடப்படலாம். இந்த வழக்கில், தொகுதி தற்செயலாக சேதமடையவில்லை அல்லது வேண்டுமென்றே மாற்றப்படவில்லை என்பதை டெவலப்பர் உறுதியாக நம்பலாம். இதை நீங்கள் modinfo கட்டளை மூலம் சரிபார்க்கலாம்.

Red Hat மற்றும் SUSE விநியோகங்கள் தொகுதியின் கையொப்பத்தைச் சரிபார்த்து, கணினியில் தொடர்புடைய சான்றிதழ் பதிவு செய்யப்பட்டிருந்தால் மட்டுமே அதை ஏற்ற அனுமதிக்கின்றன. சான்றிதழ் என்பது தொகுதி கையொப்பமிடப்பட்ட பொது விசையாகும். நாங்கள் அதை ஒரு தனி தொகுப்பாக விநியோகிக்கிறோம்.

இங்குள்ள சிக்கல் என்னவென்றால், சான்றிதழ்கள் கர்னலில் கட்டமைக்கப்படலாம் (விநியோகஸ்தர்கள் அவற்றைப் பயன்படுத்துகின்றனர்) அல்லது ஒரு பயன்பாட்டைப் பயன்படுத்தி EFI நிலையற்ற நினைவகத்தில் எழுதப்பட வேண்டும். மொகுடில். பயன்பாடு மொகுடில் ஒரு சான்றிதழை நிறுவும் போது, ​​நீங்கள் கணினியை மறுதொடக்கம் செய்ய வேண்டும், மேலும் இயக்க முறைமை கர்னலை ஏற்றுவதற்கு முன்பே, புதிய சான்றிதழை ஏற்ற அனுமதிக்க நிர்வாகியைத் தூண்டுகிறது.

எனவே, ஒரு சான்றிதழைச் சேர்ப்பதற்கு, கணினியில் இயற்பியல் நிர்வாகி அணுகல் தேவைப்படுகிறது. இயந்திரம் எங்காவது மேகக்கணியில் அல்லது தொலைதூர சேவையக அறையில் இருந்தால் மற்றும் அணுகல் நெட்வொர்க் வழியாக மட்டுமே இருந்தால் (எடுத்துக்காட்டாக, ssh வழியாக), சான்றிதழைச் சேர்க்க இயலாது.

மெய்நிகர் கணினிகளில் EFI

EFI நீண்ட காலமாக அனைத்து மதர்போர்டு உற்பத்தியாளர்களாலும் ஆதரிக்கப்பட்ட போதிலும், ஒரு அமைப்பை நிறுவும் போது, ​​நிர்வாகி EFI இன் தேவையைப் பற்றி சிந்திக்காமல் இருக்கலாம், மேலும் அது முடக்கப்படலாம்.

அனைத்து ஹைப்பர்வைசர்களும் EFI ஐ ஆதரிக்கவில்லை. VMWare vSphere பதிப்பு 5 இல் இருந்து EFI ஐ ஆதரிக்கிறது.
மைக்ரோசாப்ட் ஹைப்பர்-வி விண்டோஸ் சர்வர் 2012 ஆர்2க்கான ஹைப்பர்-வி உடன் தொடங்கி ஈஎஃப்ஐ ஆதரவைப் பெற்றது.

இருப்பினும், இயல்புநிலை கட்டமைப்பில் இந்த செயல்பாடு Linux இயந்திரங்களுக்கு முடக்கப்பட்டுள்ளது, அதாவது சான்றிதழை நிறுவ முடியாது.

vSphere 6.5 இல், விருப்பத்தை அமைக்கவும் பாதுகாப்பான தொடக்கம் ஃப்ளாஷ் வழியாக இயங்கும் வலை இடைமுகத்தின் பழைய பதிப்பில் மட்டுமே சாத்தியம். HTML-5 இல் இணைய UI இன்னும் பின்தங்கிய நிலையில் உள்ளது.

பரிசோதனை விநியோகங்கள்

இறுதியாக, உத்தியோகபூர்வ ஆதரவு இல்லாமல் சோதனை விநியோகங்கள் மற்றும் விநியோகங்களின் சிக்கலைக் கருத்தில் கொள்வோம். ஒருபுறம், இத்தகைய விநியோகங்கள் தீவிர நிறுவனங்களின் சேவையகங்களில் காணப்பட வாய்ப்பில்லை. அத்தகைய விநியோகங்களுக்கு அதிகாரப்பூர்வ ஆதரவு இல்லை. எனவே, அவற்றை வழங்கவும். அத்தகைய விநியோகத்தில் தயாரிப்பை ஆதரிக்க முடியாது.

இருப்பினும், இத்தகைய விநியோகங்கள் புதிய சோதனை தீர்வுகளை முயற்சிப்பதற்கான ஒரு வசதியான தளமாக மாறும். எடுத்துக்காட்டாக, Fedora, OpenSUSE Tumbleweed அல்லது Debian இன் நிலையற்ற பதிப்புகள். அவை மிகவும் நிலையானவை. அவை எப்போதும் நிரல்களின் புதிய பதிப்புகள் மற்றும் எப்போதும் புதிய கர்னலைக் கொண்டிருக்கும். ஒரு வருடத்தில், இந்த சோதனைச் செயல்பாடு புதுப்பிக்கப்பட்ட RHEL, SLES அல்லது Ubuntu இல் முடிவடையும்.

சோதனை விநியோகத்தில் ஏதாவது வேலை செய்யவில்லை என்றால், சிக்கலைக் கண்டுபிடித்து அதைத் தீர்க்க இது ஒரு காரணம். பயனர்களின் உற்பத்தி சேவையகங்களில் இந்த செயல்பாடு விரைவில் தோன்றும் என்பதற்கு நீங்கள் தயாராக இருக்க வேண்டும்.

பதிப்பு 3.0க்கான அதிகாரப்பூர்வமாக ஆதரிக்கப்படும் விநியோகங்களின் தற்போதைய பட்டியலை நீங்கள் படிக்கலாம் இங்கே. ஆனால் எங்கள் தயாரிப்பு வேலை செய்யக்கூடிய விநியோகங்களின் உண்மையான பட்டியல் மிகவும் விரிவானது.

தனிப்பட்ட முறையில், நான் Elbrus OS உடன் பரிசோதனையில் ஆர்வமாக இருந்தேன். வீம் தொகுப்பை இறுதி செய்த பிறகு, எங்கள் தயாரிப்பு நிறுவப்பட்டு வேலை செய்யப்பட்டது. இந்த பரிசோதனையை நான் Habré இல் எழுதினேன் கட்டுரை.

சரி, புதிய விநியோகங்களுக்கான ஆதரவு தொடர்கிறது. பதிப்பு 4.0 வெளியாகும் வரை காத்திருக்கிறோம். பீட்டா தோன்றவிருக்கிறது, எனவே கவனமாக இருங்கள் என்ன - புதியது!

ஆதாரம்: www.habr.com