ലിനക്സിന് നിരവധി മുഖങ്ങളുണ്ട്: ഏത് വിതരണത്തിലും എങ്ങനെ പ്രവർത്തിക്കാം

ഏത് വിതരണത്തിലും പ്രവർത്തിക്കുന്ന ഒരു ബാക്കപ്പ് ആപ്ലിക്കേഷൻ സൃഷ്ടിക്കുന്നത് എളുപ്പമുള്ള കാര്യമല്ല. Red Hat 6, Debian 6 എന്നിവയിൽ നിന്നും OpenSUSE 15.1, Ubuntu 19.04 എന്നിവയിലേക്കുള്ള വിതരണങ്ങളിൽ Linux-നുള്ള Veeam ഏജന്റ് പ്രവർത്തിക്കുന്നുവെന്ന് ഉറപ്പാക്കാൻ, സോഫ്റ്റ്‌വെയർ ഉൽപ്പന്നത്തിൽ ഒരു കേർണൽ മൊഡ്യൂൾ ഉൾപ്പെട്ടിരിക്കുന്നതിനാൽ, നിങ്ങൾ നിരവധി പ്രശ്നങ്ങൾ പരിഹരിക്കേണ്ടതുണ്ട്.

കോൺഫറൻസിലെ പ്രസംഗത്തിൽ നിന്നുള്ള മെറ്റീരിയലുകളെ അടിസ്ഥാനമാക്കിയാണ് ലേഖനം സൃഷ്ടിച്ചത് ലിനക്സ് പീറ്റർ 2019.

ലിനക്സ് ഏറ്റവും ജനപ്രിയമായ ഓപ്പറേറ്റിംഗ് സിസ്റ്റങ്ങളിൽ ഒന്ന് മാത്രമല്ല. അടിസ്ഥാനപരമായി, ഇത് നിങ്ങൾക്ക് അദ്വിതീയമായ എന്തെങ്കിലും, നിങ്ങളുടേതായ എന്തെങ്കിലും ഉണ്ടാക്കാൻ കഴിയുന്ന ഒരു പ്ലാറ്റ്ഫോമാണ്. ഇതിന് നന്ദി, ലിനക്സിന് അവയുടെ സോഫ്റ്റ്വെയർ ഘടകങ്ങളിൽ വ്യത്യാസമുള്ള നിരവധി വിതരണങ്ങളുണ്ട്. ഇവിടെ ഒരു പ്രശ്നം ഉയർന്നുവരുന്നു: ഏതെങ്കിലും വിതരണത്തിൽ ഒരു സോഫ്റ്റ്വെയർ ഉൽപ്പന്നം പ്രവർത്തിക്കുന്നതിന്, ഓരോന്നിന്റെയും സവിശേഷതകൾ നിങ്ങൾ കണക്കിലെടുക്കണം.

പാക്കേജ് മാനേജർമാർ. .deb vs .rpm

വ്യത്യസ്ത വിതരണങ്ങളിലുടനീളം ഉൽപ്പന്നം വിതരണം ചെയ്യുന്നതിന്റെ വ്യക്തമായ പ്രശ്നത്തിൽ നിന്ന് നമുക്ക് ആരംഭിക്കാം.
സോഫ്‌റ്റ്‌വെയർ ഉൽപ്പന്നങ്ങൾ വിതരണം ചെയ്യുന്നതിനുള്ള ഏറ്റവും സാധാരണമായ മാർഗ്ഗം പാക്കേജ് ഒരു ശേഖരത്തിൽ സ്ഥാപിക്കുക എന്നതാണ്, അങ്ങനെ സിസ്റ്റത്തിൽ നിർമ്മിച്ച പാക്കേജ് മാനേജർക്ക് അത് അവിടെ നിന്ന് ഇൻസ്റ്റാൾ ചെയ്യാൻ കഴിയും.
എന്നിരുന്നാലും, ഞങ്ങൾക്ക് രണ്ട് ജനപ്രിയ പാക്കേജ് ഫോർമാറ്റുകൾ ഉണ്ട്: ആർപിഎം и deb. ഇതിനർത്ഥം എല്ലാവരും പിന്തുണയ്ക്കണം എന്നാണ്.

ഡെബ് പാക്കേജുകളുടെ ലോകത്ത്, അനുയോജ്യതയുടെ നിലവാരം അതിശയകരമാണ്. ഡെബിയൻ 6, ഉബുണ്ടു 19.04 എന്നിവയിൽ ഒരേ പാക്കേജ് ഇൻസ്റ്റാൾ ചെയ്യുകയും പ്രവർത്തിക്കുകയും ചെയ്യുന്നു. പഴയ ഡെബിയൻ വിതരണങ്ങളിൽ പറഞ്ഞിരിക്കുന്ന പാക്കേജുകൾ നിർമ്മിക്കുന്നതിനും അവയ്‌ക്കൊപ്പം പ്രവർത്തിക്കുന്നതിനുമുള്ള മാനദണ്ഡങ്ങൾ പുതിയ ലിനക്സ് മിന്റിലും എലിമെന്ററി ഒഎസിലും പ്രസക്തമായി തുടരുന്നു. അതിനാൽ, Linux-നുള്ള Veeam ഏജന്റിന്റെ കാര്യത്തിൽ, ഓരോ ഹാർഡ്‌വെയർ പ്ലാറ്റ്‌ഫോമിനും ഒരു deb പാക്കേജ് മതിയാകും.

എന്നാൽ rpm പാക്കേജുകളുടെ ലോകത്ത്, വ്യത്യാസങ്ങൾ വളരെ വലുതാണ്. ഒന്നാമതായി, Red Hat ഉം SUSE ഉം പൂർണ്ണമായും സ്വതന്ത്രമായ രണ്ട് വിതരണക്കാർ ഉള്ളതിനാൽ, അനുയോജ്യത പൂർണ്ണമായും ആവശ്യമില്ല. രണ്ടാമതായി, ഈ വിതരണക്കാർക്ക് അവരിൽ നിന്നുള്ള വിതരണ കിറ്റുകൾ ഉണ്ട്. പിന്തുണയും പരീക്ഷണാത്മകവും. അവർക്കിടയിൽ പൊരുത്തത്തിന്റെ ആവശ്യമില്ല. el6, el7, el8 എന്നിവയ്ക്ക് അവരുടേതായ പാക്കേജുകളുണ്ട്. ഫെഡോറയ്ക്ക് പ്രത്യേക പാക്കേജ്. SLES11, 12 എന്നിവയ്‌ക്കുള്ള പാക്കേജുകളും openSUSE-യ്‌ക്കുള്ള പ്രത്യേകവും. ഡിപൻഡൻസികളും പാക്കേജ് പേരുകളുമാണ് പ്രധാന പ്രശ്നം.

ആശ്രിതത്വ പ്രശ്നം

നിർഭാഗ്യവശാൽ, ഒരേ പാക്കേജുകൾ പലപ്പോഴും വ്യത്യസ്ത വിതരണങ്ങളിൽ വ്യത്യസ്ത പേരുകളിൽ അവസാനിക്കുന്നു. വീം പാക്കേജ് ഡിപൻഡൻസികളുടെ ഒരു ഭാഗിക ലിസ്റ്റ് ചുവടെയുണ്ട്.

EL7-ന്:
SLES 12-ന്:

• libblkid
• libgcc
• libstdc++
• ncurses-libs
• ഫ്യൂസ്-ലിബ്സ്
• ഫയൽ-ലിബ്സ്
• വീംസ്‌നാപ്പ്=3.0.2.1185

• libblkid1
• libgcc_s1
• libstdc++6
• ലിബ്മാജിക്1
• ലിബ്ഫ്യൂസ്2
• veeamsnap-kmp=3.0.2.1185

തൽഫലമായി, ഡിപൻഡൻസികളുടെ ലിസ്റ്റ് വിതരണത്തിന് അദ്വിതീയമാണ്.

പഴയ പാക്കേജിന്റെ പേരിൽ ഒരു അപ്‌ഡേറ്റ് ചെയ്ത പതിപ്പ് മറയ്ക്കാൻ തുടങ്ങുമ്പോഴാണ് കൂടുതൽ മോശമായത്.

ഉദാഹരണം:

ഫെഡോറ 24-ൽ പാക്കേജ് പരിഷ്കരിച്ചിരിക്കുന്നു ശപിക്കുന്നു പതിപ്പ് 5 മുതൽ പതിപ്പ് 6 വരെ. പഴയ വിതരണങ്ങളുമായി അനുയോജ്യത ഉറപ്പാക്കാൻ പതിപ്പ് 5 ഉപയോഗിച്ചാണ് ഞങ്ങളുടെ ഉൽപ്പന്നം നിർമ്മിച്ചിരിക്കുന്നത്. ഫെഡോറ 5-ൽ ലൈബ്രറിയുടെ പഴയ അഞ്ചാമത്തെ പതിപ്പ് ഉപയോഗിക്കുന്നതിന്, എനിക്ക് പാക്കേജ് ഉപയോഗിക്കേണ്ടി വന്നു ncurses-compat-libs.

തൽഫലമായി, ഫെഡോറയ്ക്ക് വ്യത്യസ്ത ഡിപൻഡൻസികളുള്ള രണ്ട് പാക്കേജുകൾ ഉണ്ട്.

കൂടുതൽ രസകരമായത്. അടുത്ത വിതരണ അപ്ഡേറ്റിന് ശേഷം, പാക്കേജ് ncurses-compat-libs ലൈബ്രറിയുടെ പതിപ്പ് 5-ൽ അത് ലഭ്യമല്ലെന്ന് മാറുന്നു. വിതരണത്തിന്റെ പുതിയ പതിപ്പിലേക്ക് പഴയ ലൈബ്രറികൾ വലിച്ചിടുന്നത് ഒരു വിതരണക്കാരന് ചെലവേറിയതാണ്. കുറച്ച് സമയത്തിന് ശേഷം, SUSE വിതരണങ്ങളിൽ പ്രശ്നം ആവർത്തിച്ചു.

തൽഫലമായി, ചില വിതരണങ്ങൾക്ക് അവയുടെ വ്യക്തമായ ആശ്രിതത്വം ഉപേക്ഷിക്കേണ്ടിവന്നു ncurses-libs, കൂടാതെ ഉൽപ്പന്നം ശരിയാക്കുക, അതുവഴി ലൈബ്രറിയുടെ ഏത് പതിപ്പിലും പ്രവർത്തിക്കാൻ കഴിയും.

വഴിയിൽ, Red Hat-ന്റെ പതിപ്പ് 8-ൽ ഇനി ഒരു മെറ്റാ പാക്കേജ് ഇല്ല പൈത്തൺ, അത് നല്ല പഴയതിനെ പരാമർശിക്കുന്നു പൈത്തൺ 2.7. ഉണ്ട് പൈത്തൺ 2 и പൈത്തൺ3.

പാക്കേജ് മാനേജർമാർക്ക് ബദൽ

ഡിപൻഡൻസികളുടെ പ്രശ്നം പഴയതും വളരെക്കാലമായി വ്യക്തവുമാണ്. ഡിപൻഡൻസി നരകത്തെ ഓർക്കുക.
വിവിധ ലൈബ്രറികളും ആപ്ലിക്കേഷനുകളും സംയോജിപ്പിക്കുക, അങ്ങനെ അവയെല്ലാം സ്ഥിരമായി പ്രവർത്തിക്കുകയും വൈരുദ്ധ്യം വരാതിരിക്കുകയും ചെയ്യുന്നു - വാസ്തവത്തിൽ, ഏതൊരു ലിനക്സ് വിതരണക്കാരനും പരിഹരിക്കാൻ ശ്രമിക്കുന്ന ടാസ്ക്കാണിത്.

പാക്കേജ് മാനേജർ ഈ പ്രശ്നം തികച്ചും വ്യത്യസ്തമായ രീതിയിൽ പരിഹരിക്കാൻ ശ്രമിക്കുന്നു. സ്നാപ്പി കാനോനിക്കലിൽ നിന്ന്. പ്രധാന ആശയം: ആപ്ലിക്കേഷൻ ഒറ്റപ്പെട്ടതും പ്രധാന സിസ്റ്റത്തിൽ നിന്ന് സംരക്ഷിക്കപ്പെട്ടതുമായ ഒരു സാൻഡ്ബോക്സിൽ പ്രവർത്തിക്കുന്നു. ഒരു ആപ്ലിക്കേഷന് ലൈബ്രറികൾ ആവശ്യമാണെങ്കിൽ, അവ ആപ്ലിക്കേഷനോടൊപ്പം തന്നെ നൽകും.

ഫ്ലാറ്റ്പാക്ക് Linux കണ്ടെയ്‌നറുകൾ ഉപയോഗിച്ച് ഒരു സാൻഡ്‌ബോക്‌സിൽ അപ്ലിക്കേഷനുകൾ പ്രവർത്തിപ്പിക്കാനും നിങ്ങളെ അനുവദിക്കുന്നു. സാൻഡ്ബോക്സ് ആശയവും ഉപയോഗിക്കുന്നു AppImage.

ഏത് വിതരണത്തിനും ഒരു പാക്കേജ് സൃഷ്ടിക്കാൻ ഈ പരിഹാരങ്ങൾ നിങ്ങളെ അനുവദിക്കുന്നു. കാര്യത്തിൽ ഫ്ലാറ്റ്പാക്ക് അഡ്മിനിസ്ട്രേറ്ററുടെ അറിവില്ലാതെ പോലും ആപ്ലിക്കേഷൻ ഇൻസ്റ്റാളേഷനും സമാരംഭിക്കലും സാധ്യമാണ്.

എല്ലാ ആപ്ലിക്കേഷനുകളും ഒരു സാൻഡ്‌ബോക്‌സിൽ പ്രവർത്തിക്കാൻ കഴിയില്ല എന്നതാണ് പ്രധാന പ്രശ്നം. ചില ആളുകൾക്ക് പ്ലാറ്റ്‌ഫോമിലേക്ക് നേരിട്ട് പ്രവേശനം ആവശ്യമാണ്. കേർണലിനെ കർശനമായി ആശ്രയിക്കുന്നതും സാൻഡ്‌ബോക്‌സ് ആശയവുമായി പൊരുത്തപ്പെടാത്തതുമായ കേർണൽ മൊഡ്യൂളുകളെ കുറിച്ച് പോലും ഞാൻ സംസാരിക്കുന്നില്ല.

Red Hat, SUSE എന്നിവയിൽ നിന്നുള്ള എന്റർപ്രൈസ് പരിതസ്ഥിതിയിൽ ജനപ്രിയമായ വിതരണങ്ങളിൽ Snappy, Flatpak എന്നിവയ്ക്കുള്ള പിന്തുണ ഇതുവരെ അടങ്ങിയിട്ടില്ല എന്നതാണ് രണ്ടാമത്തെ പ്രശ്നം.

ഇക്കാര്യത്തിൽ, Linux-നുള്ള Veeam ഏജന്റ് ലഭ്യമല്ല snapcraft.io ഒരിക്കലുമില്ല flathub.org.

പാക്കേജ് മാനേജർമാരെക്കുറിച്ചുള്ള ചോദ്യം അവസാനിപ്പിക്കാൻ, ബൈനറി ഫയലുകളും ഒരു പാക്കേജിലേക്ക് ഇൻസ്റ്റാൾ ചെയ്യുന്നതിനുള്ള ഒരു സ്ക്രിപ്റ്റും സംയോജിപ്പിച്ച് പാക്കേജ് മാനേജർമാരെ പൂർണ്ണമായും ഉപേക്ഷിക്കാനുള്ള ഒരു ഓപ്ഷൻ ഉണ്ടെന്ന് ഞാൻ ശ്രദ്ധിക്കാൻ ആഗ്രഹിക്കുന്നു.

വ്യത്യസ്‌ത വിതരണങ്ങൾക്കും പ്ലാറ്റ്‌ഫോമുകൾക്കുമായി ഒരു പൊതു പാക്കേജ് സൃഷ്‌ടിക്കാനും ഒരു സംവേദനാത്മക ഇൻസ്റ്റാളേഷൻ പ്രക്രിയ നടത്താനും ആവശ്യമായ ഇഷ്‌ടാനുസൃതമാക്കൽ നടത്താനും അത്തരമൊരു ബണ്ടിൽ നിങ്ങളെ അനുവദിക്കുന്നു. VMware-ൽ നിന്ന് Linux-ന് ഇത്തരം പാക്കേജുകൾ മാത്രമേ ഞാൻ നേരിട്ടിട്ടുള്ളൂ.

അപ്ഡേറ്റ് പ്രശ്നം

എല്ലാ ഡിപൻഡൻസി പ്രശ്നങ്ങളും പരിഹരിച്ചാലും, ഒരേ വിതരണത്തിൽ പ്രോഗ്രാം വ്യത്യസ്തമായി പ്രവർത്തിക്കാം. ഇത് അപ്‌ഡേറ്റുകളെക്കുറിച്ചാണ്.

3 അപ്‌ഡേറ്റ് തന്ത്രങ്ങളുണ്ട്:

• ഒരിക്കലും അപ്ഡേറ്റ് ചെയ്യരുത് എന്നതാണ് ഏറ്റവും ലളിതമായത്. ഞാൻ സെർവർ സജ്ജമാക്കി അതിനെക്കുറിച്ച് മറന്നു. എല്ലാം പ്രവർത്തിക്കുന്നുണ്ടെങ്കിൽ എന്തുകൊണ്ട് അപ്ഡേറ്റ് ചെയ്യണം? നിങ്ങൾ ആദ്യമായി പിന്തുണയുമായി ബന്ധപ്പെടുമ്പോൾ തന്നെ പ്രശ്നങ്ങൾ ആരംഭിക്കുന്നു. വിതരണത്തിന്റെ സ്രഷ്ടാവ് അപ്‌ഡേറ്റ് ചെയ്ത റിലീസിനെ മാത്രമേ പിന്തുണയ്ക്കൂ.
• നിങ്ങൾക്ക് വിതരണക്കാരനെ വിശ്വസിക്കാനും സ്വയമേവയുള്ള അപ്‌ഡേറ്റുകൾ സജ്ജീകരിക്കാനും കഴിയും. ഈ സാഹചര്യത്തിൽ, അപ്‌ഡേറ്റ് പരാജയപ്പെട്ടതിന് ശേഷം ഉടൻ തന്നെ പിന്തുണയ്‌ക്കുള്ള ഒരു കോൾ സാധ്യതയുണ്ട്.
• ഒരു ടെസ്റ്റ് ഇൻഫ്രാസ്ട്രക്ചറിൽ പ്രവർത്തിപ്പിച്ചതിനുശേഷം മാത്രം മാനുവൽ അപ്‌ഡേറ്റ് ചെയ്യാനുള്ള ഓപ്ഷൻ ഏറ്റവും വിശ്വസനീയവും എന്നാൽ ചെലവേറിയതും സമയമെടുക്കുന്നതുമാണ്. എല്ലാവർക്കും അത് താങ്ങാൻ കഴിയില്ല.

വ്യത്യസ്‌ത ഉപയോക്താക്കൾ വ്യത്യസ്‌ത അപ്‌ഡേറ്റ് സ്‌ട്രാറ്റജികൾ ഉപയോഗിക്കുന്നതിനാൽ, ഏറ്റവും പുതിയ പതിപ്പിനെയും മുമ്പ് റിലീസ് ചെയ്‌തവയെയും പിന്തുണയ്‌ക്കേണ്ടത് ആവശ്യമാണ്. ഇത് വികസനവും ടെസ്റ്റിംഗ് പ്രക്രിയയും സങ്കീർണ്ണമാക്കുകയും പിന്തുണാ ടീമിന് തലവേദന സൃഷ്ടിക്കുകയും ചെയ്യുന്നു.

ഹാർഡ്‌വെയർ പ്ലാറ്റ്‌ഫോമുകളുടെ വൈവിധ്യം

വ്യത്യസ്‌ത ഹാർഡ്‌വെയർ പ്ലാറ്റ്‌ഫോമുകൾ നേറ്റീവ് കോഡിന് പ്രത്യേകമായ ഒരു പ്രശ്‌നമാണ്. കുറഞ്ഞത്, പിന്തുണയ്ക്കുന്ന ഓരോ പ്ലാറ്റ്‌ഫോമിനും നിങ്ങൾ ബൈനറികൾ ശേഖരിക്കണം.

Linux പ്രോജക്‌റ്റിനായുള്ള Veeam ഏജന്റിൽ, ഞങ്ങൾക്ക് ഇപ്പോഴും ഈ RISC പോലെയുള്ളതൊന്നും പിന്തുണയ്ക്കാൻ കഴിയില്ല.

ഈ വിഷയത്തിൽ ഞാൻ വിശദമായി താമസിക്കില്ല. ഞാൻ പ്രധാന പ്രശ്‌നങ്ങളുടെ രൂപരേഖ മാത്രമേ നൽകൂ: പ്ലാറ്റ്‌ഫോമിനെ ആശ്രയിച്ചുള്ള തരങ്ങൾ size_t, ഘടന വിന്യാസവും ബൈറ്റ് ക്രമവും.

സ്റ്റാറ്റിക് കൂടാതെ/അല്ലെങ്കിൽ ഡൈനാമിക് ലിങ്കിംഗ്

എന്നാൽ ചോദ്യം "ലൈബ്രറികളുമായി എങ്ങനെ ലിങ്ക് ചെയ്യാം - ചലനാത്മകമോ സ്ഥിരമോ?" ചർച്ച ചെയ്യേണ്ടതാണ്.

ചട്ടം പോലെ, ലിനക്സിനു കീഴിലുള്ള C/C++ ആപ്ലിക്കേഷനുകൾ ഡൈനാമിക് ലിങ്കിംഗ് ഉപയോഗിക്കുന്നു. ഒരു നിർദ്ദിഷ്‌ട വിതരണത്തിനായി പ്രത്യേകമായി ആപ്ലിക്കേഷൻ നിർമ്മിച്ചതാണെങ്കിൽ ഇത് മികച്ച രീതിയിൽ പ്രവർത്തിക്കുന്നു.

ഒരു ബൈനറി ഫയൽ ഉപയോഗിച്ച് വിവിധ വിതരണങ്ങൾ കവർ ചെയ്യുക എന്നതാണ് ടാസ്‌ക് എങ്കിൽ, നിങ്ങൾ ഏറ്റവും പഴയ പിന്തുണയുള്ള വിതരണത്തിൽ ശ്രദ്ധ കേന്ദ്രീകരിക്കേണ്ടതുണ്ട്. ഞങ്ങളെ സംബന്ധിച്ചിടത്തോളം ഇത് Red Hat 6 ആണ്. ഇതിൽ gcc 4.4 അടങ്ങിയിരിക്കുന്നു, C++11 സ്റ്റാൻഡേർഡ് പോലും പിന്തുണയ്ക്കുന്നില്ല. പൂർണ്ണമായും.

C++6.3 പൂർണ്ണമായും പിന്തുണയ്ക്കുന്ന gcc 14 ഉപയോഗിച്ചാണ് ഞങ്ങൾ ഞങ്ങളുടെ പ്രോജക്റ്റ് നിർമ്മിക്കുന്നത്. സ്വാഭാവികമായും, ഈ സാഹചര്യത്തിൽ, Red Hat 6-ൽ നിങ്ങൾ libstdc++ കൊണ്ടുപോകുകയും ലൈബ്രറികൾ ബൂസ്റ്റ് ചെയ്യുകയും വേണം. അവയുമായി സ്ഥിരമായി ലിങ്ക് ചെയ്യുക എന്നതാണ് ഏറ്റവും എളുപ്പമുള്ള മാർഗം.

പക്ഷേ, അയ്യോ, എല്ലാ ലൈബ്രറികളും സ്ഥിരമായി ബന്ധിപ്പിക്കാൻ കഴിയില്ല.

ഒന്നാമതായി, പോലുള്ള സിസ്റ്റം ലൈബ്രറികൾ ലിബ്ഫ്യൂസ്, libblkid കേർണലിലും അതിന്റെ മൊഡ്യൂളുകളുമായും അവയുടെ അനുയോജ്യത ഉറപ്പാക്കാൻ ഡൈനാമിക് ആയി ലിങ്ക് ചെയ്യേണ്ടത് ആവശ്യമാണ്.

രണ്ടാമതായി, ലൈസൻസുകളിൽ ഒരു സൂക്ഷ്മതയുണ്ട്.

ഗ്രന്ഥശാലകളെ ഓപ്പൺ സോഴ്‌സ് കോഡുമായി മാത്രം ലിങ്ക് ചെയ്യാൻ GPL ലൈസൻസ് നിങ്ങളെ അനുവദിക്കുന്നു. എംഐടിയും ബിഎസ്ഡിയും സ്റ്റാറ്റിക് ലിങ്കിംഗ് അനുവദിക്കുകയും ഒരു പ്രോജക്റ്റിൽ ലൈബ്രറികൾ ഉൾപ്പെടുത്താൻ അനുവദിക്കുകയും ചെയ്യുന്നു. എന്നാൽ എൽജിപിഎൽ സ്റ്റാറ്റിക് ലിങ്കിംഗിന് വിരുദ്ധമാണെന്ന് തോന്നുന്നില്ല, എന്നാൽ ലിങ്കിംഗിന് ആവശ്യമായ ഫയലുകൾ പങ്കിടേണ്ടതുണ്ട്.

പൊതുവേ, ഡൈനാമിക് ലിങ്കിംഗ് ഉപയോഗിക്കുന്നത് ഒന്നും നൽകുന്നതിൽ നിന്ന് നിങ്ങളെ തടയും.

C/C++ ആപ്ലിക്കേഷനുകൾ നിർമ്മിക്കുന്നു

വ്യത്യസ്ത പ്ലാറ്റ്‌ഫോമുകൾക്കും വിതരണങ്ങൾക്കുമായി C/C++ ആപ്ലിക്കേഷനുകൾ നിർമ്മിക്കുന്നതിന്, gcc യുടെ അനുയോജ്യമായ ഒരു പതിപ്പ് തിരഞ്ഞെടുക്കുകയോ നിർമ്മിക്കുകയോ ചെയ്‌താൽ മാത്രം മതി, കൂടാതെ നിർദ്ദിഷ്ട ആർക്കിടെക്ചറുകൾക്കായി ക്രോസ്-കംപൈലറുകൾ ഉപയോഗിക്കുകയും ലൈബ്രറികളുടെ മുഴുവൻ സെറ്റ് കൂട്ടിച്ചേർക്കുകയും ചെയ്താൽ മതിയാകും. ഈ ജോലി തികച്ചും പ്രായോഗികമാണ്, പക്ഷേ വളരെ ബുദ്ധിമുട്ടാണ്. തിരഞ്ഞെടുത്ത കംപൈലറും ലൈബ്രറികളും പ്രവർത്തനക്ഷമമായ ഒരു പതിപ്പ് നൽകുമെന്നതിന് യാതൊരു ഉറപ്പുമില്ല.

വ്യക്തമായ ഒരു നേട്ടം: അടിസ്ഥാന സൗകര്യങ്ങൾ വളരെ ലളിതമാക്കിയിരിക്കുന്നു, കാരണം മുഴുവൻ നിർമ്മാണ പ്രക്രിയയും ഒരു മെഷീനിൽ പൂർത്തിയാക്കാൻ കഴിയും. കൂടാതെ, ഒരു ആർക്കിടെക്ചറിനായി ഒരു കൂട്ടം ബൈനറികൾ ശേഖരിക്കാൻ മതിയാകും, നിങ്ങൾക്ക് അവയെ വ്യത്യസ്ത വിതരണങ്ങൾക്കായി പാക്കേജുകളായി പാക്കേജുചെയ്യാനാകും. ലിനക്സിനുള്ള വീം ഏജന്റിന് വീം പാക്കേജുകൾ നിർമ്മിക്കുന്നത് ഇങ്ങനെയാണ്.

ഈ ഓപ്ഷന് വിപരീതമായി, നിങ്ങൾക്ക് ഒരു ബിൽഡ് ഫാം തയ്യാറാക്കാം, അതായത്, അസംബ്ലിക്കായി നിരവധി മെഷീനുകൾ. അത്തരത്തിലുള്ള ഓരോ മെഷീനും ഒരു നിർദ്ദിഷ്ട വിതരണത്തിനും ഒരു നിർദ്ദിഷ്ട ആർക്കിടെക്ചറിനും ആപ്ലിക്കേഷൻ സമാഹാരവും പാക്കേജ് അസംബ്ലിയും നൽകും. ഈ സാഹചര്യത്തിൽ, വിതരണക്കാരൻ തയ്യാറാക്കിയ മാർഗ്ഗങ്ങൾ ഉപയോഗിച്ചാണ് സമാഹാരം നടത്തുന്നത്. അതായത്, കമ്പൈലർ തയ്യാറാക്കി ലൈബ്രറികൾ തിരഞ്ഞെടുക്കുന്ന ഘട്ടം ഇല്ലാതാകുന്നു. കൂടാതെ, നിർമ്മാണ പ്രക്രിയ എളുപ്പത്തിൽ സമാന്തരമാക്കാം.

എന്നിരുന്നാലും, ഈ സമീപനത്തിന് ഒരു പോരായ്മയുണ്ട്: ഒരേ ആർക്കിടെക്ചറിനുള്ളിലെ ഓരോ വിതരണത്തിനും, നിങ്ങളുടേതായ ബൈനറി ഫയലുകൾ ശേഖരിക്കേണ്ടതുണ്ട്. മറ്റൊരു പോരായ്മ എന്തെന്നാൽ, ഇത്രയും വലിയ മെഷീനുകൾ പരിപാലിക്കേണ്ടതുണ്ട്, കൂടാതെ വലിയ അളവിൽ ഡിസ്ക് സ്ഥലവും റാമും അനുവദിക്കേണ്ടതുണ്ട്.

ഇങ്ങനെയാണ് വീംസ്‌നാപ്പ് കേർണൽ മൊഡ്യൂളിന്റെ KMOD പാക്കേജുകൾ Red Hat വിതരണങ്ങൾക്കായി കംപൈൽ ചെയ്യുന്നത്.

ബിൽഡ് സർവീസ് തുറക്കുക

ആപ്ലിക്കേഷനുകൾ കംപൈൽ ചെയ്യുന്നതിനും പാക്കേജുകൾ കൂട്ടിച്ചേർക്കുന്നതിനുമായി ഒരു പ്രത്യേക സേവനത്തിന്റെ രൂപത്തിൽ ചില മധ്യനിര നടപ്പിലാക്കാൻ SUSE- ൽ നിന്നുള്ള സഹപ്രവർത്തകർ ശ്രമിച്ചു - openbuildservice.

അടിസ്ഥാനപരമായി, ഇത് ഒരു വെർച്വൽ മെഷീൻ സൃഷ്ടിക്കുകയും അതിൽ ആവശ്യമായ എല്ലാ പാക്കേജുകളും ഇൻസ്റ്റാൾ ചെയ്യുകയും ആപ്ലിക്കേഷൻ കംപൈൽ ചെയ്യുകയും ഈ ഒറ്റപ്പെട്ട പരിതസ്ഥിതിയിൽ പാക്കേജ് നിർമ്മിക്കുകയും ചെയ്യുന്ന ഒരു ഹൈപ്പർവൈസർ ആണ്, അതിനുശേഷം വെർച്വൽ മെഷീൻ പുറത്തിറങ്ങുന്നു.

OpenBuildService-ൽ നടപ്പിലാക്കിയിരിക്കുന്ന ഷെഡ്യൂളർ, ഒപ്റ്റിമൽ പാക്കേജ് ബിൽഡിംഗ് വേഗതയ്ക്കായി എത്ര വെർച്വൽ മെഷീനുകൾ സമാരംഭിക്കാമെന്ന് നിർണ്ണയിക്കും. ബിൽറ്റ്-ഇൻ സൈനിംഗ് മെക്കാനിസം പാക്കേജുകൾ സൈൻ ചെയ്യുകയും ബിൽറ്റ്-ഇൻ റിപ്പോസിറ്ററിയിലേക്ക് അപ്‌ലോഡ് ചെയ്യുകയും ചെയ്യും. ബിൽറ്റ്-ഇൻ പതിപ്പ് നിയന്ത്രണ സംവിധാനം മാറ്റങ്ങളുടെയും നിർമ്മാണങ്ങളുടെയും ചരിത്രം സംരക്ഷിക്കും. ഈ സിസ്റ്റത്തിലേക്ക് നിങ്ങളുടെ ഉറവിടങ്ങൾ ചേർക്കുക മാത്രമാണ് അവശേഷിക്കുന്നത്. നിങ്ങൾ സ്വയം സെർവർ സജ്ജീകരിക്കേണ്ടതില്ല; നിങ്ങൾക്ക് തുറന്ന ഒന്ന് ഉപയോഗിക്കാം.

എന്നിരുന്നാലും, ഒരു പ്രശ്നമുണ്ട്: അത്തരമൊരു വിളവെടുപ്പ് നിലവിലുള്ള ഇൻഫ്രാസ്ട്രക്ചറിലേക്ക് ഉൾക്കൊള്ളാൻ പ്രയാസമാണ്. ഉദാഹരണത്തിന്, പതിപ്പ് നിയന്ത്രണം ആവശ്യമില്ല; സോഴ്സ് കോഡുകൾക്കായി ഞങ്ങൾക്ക് ഇതിനകം സ്വന്തമായുണ്ട്. ഞങ്ങളുടെ സിഗ്നേച്ചർ സംവിധാനം വ്യത്യസ്തമാണ്: ഞങ്ങൾ ഒരു പ്രത്യേക സെർവർ ഉപയോഗിക്കുന്നു. ഒരു സംഭരണിയും ആവശ്യമില്ല.

കൂടാതെ, മറ്റ് വിതരണങ്ങൾക്കുള്ള പിന്തുണ - ഉദാഹരണത്തിന്, Red Hat - വളരെ മോശമായി നടപ്പിലാക്കുന്നു, ഇത് മനസ്സിലാക്കാവുന്നതേയുള്ളൂ.

അത്തരമൊരു സേവനത്തിന്റെ പ്രയോജനം SUSE വിതരണത്തിന്റെ അടുത്ത പതിപ്പിനുള്ള വേഗത്തിലുള്ള പിന്തുണയാണ്. റിലീസിന്റെ ഔദ്യോഗിക പ്രഖ്യാപനത്തിന് മുമ്പ്, അസംബ്ലിക്ക് ആവശ്യമായ പാക്കേജുകൾ ഒരു പൊതു സംഭരണിയിൽ പോസ്റ്റ് ചെയ്യുന്നു. OpenBuildService-ൽ ലഭ്യമായ വിതരണങ്ങളുടെ പട്ടികയിൽ പുതിയൊരെണ്ണം ദൃശ്യമാകുന്നു. ഞങ്ങൾ ബോക്സ് പരിശോധിച്ച് അത് ബിൽഡ് പ്ലാനിലേക്ക് ചേർക്കുന്നു. അങ്ങനെ, വിതരണത്തിന്റെ ഒരു പുതിയ പതിപ്പ് ചേർക്കുന്നത് ഏതാണ്ട് ഒരു ക്ലിക്കിലൂടെയാണ്.

ഞങ്ങളുടെ ഇൻഫ്രാസ്ട്രക്ചറിൽ, OpenBuildService ഉപയോഗിച്ച്, SUSE വിതരണങ്ങൾക്കായുള്ള വീംസ്‌നാപ്പ് കേർണൽ മൊഡ്യൂളിന്റെ മുഴുവൻ കെഎംപി പാക്കേജുകളും കൂട്ടിച്ചേർക്കപ്പെടുന്നു.

അടുത്തതായി, കേർണൽ മൊഡ്യൂളുകളുടെ പ്രത്യേക പ്രശ്നങ്ങളെക്കുറിച്ച് ഞാൻ ചിന്തിക്കാൻ ആഗ്രഹിക്കുന്നു.

കേർണൽ ABI

ലിനക്സ് കേർണൽ മൊഡ്യൂളുകൾ ചരിത്രപരമായി ഉറവിട രൂപത്തിൽ വിതരണം ചെയ്തിട്ടുണ്ട്. കേർണൽ മൊഡ്യൂളുകൾക്കായി ഒരു സ്ഥിരതയുള്ള എപിഐയെ പിന്തുണയ്ക്കുന്നതിനുള്ള ആശങ്ക കേർണലിന്റെ സ്രഷ്‌ടാക്കൾ സ്വയം ഭാരപ്പെടുത്തുന്നില്ല എന്നതാണ് വസ്തുത, പ്രത്യേകിച്ചും ബൈനറി തലത്തിൽ, കെഎബിഐ എന്ന് വിളിക്കപ്പെടുന്നു.

ഒരു വാനില കേർണലിനായി ഒരു മൊഡ്യൂൾ നിർമ്മിക്കുന്നതിന്, നിങ്ങൾക്ക് തീർച്ചയായും ഈ പ്രത്യേക കേർണലിന്റെ തലക്കെട്ടുകൾ ആവശ്യമാണ്, അത് ഈ കേർണലിൽ മാത്രമേ പ്രവർത്തിക്കൂ.

കേർണൽ അപ്ഡേറ്റ് ചെയ്യുമ്പോൾ മൊഡ്യൂളുകൾ നിർമ്മിക്കുന്ന പ്രക്രിയ ഓട്ടോമേറ്റ് ചെയ്യാൻ DKMS നിങ്ങളെ അനുവദിക്കുന്നു. തൽഫലമായി, ഡെബിയൻ റിപ്പോസിറ്ററിയുടെ ഉപയോക്താക്കൾ (അതിന്റെ നിരവധി ബന്ധുക്കൾ) കേർണൽ മൊഡ്യൂളുകൾ വിതരണക്കാരന്റെ ശേഖരത്തിൽ നിന്നോ അല്ലെങ്കിൽ ഡികെഎംഎസ് ഉപയോഗിച്ച് ഉറവിടത്തിൽ നിന്ന് സമാഹരിച്ചതോ ആണ് ഉപയോഗിക്കുന്നത്.

എന്നിരുന്നാലും, ഈ സാഹചര്യം എന്റർപ്രൈസ് വിഭാഗത്തിന് പ്രത്യേകിച്ച് അനുയോജ്യമല്ല. പ്രൊപ്രൈറ്ററി കോഡ് ഡിസ്ട്രിബ്യൂട്ടർമാർ കംപൈൽ ചെയ്ത ബൈനറികളായി ഉൽപ്പന്നം വിതരണം ചെയ്യാൻ ആഗ്രഹിക്കുന്നു.

സുരക്ഷാ കാരണങ്ങളാൽ പ്രൊഡക്ഷൻ സെർവറുകളിൽ വികസന ഉപകരണങ്ങൾ സൂക്ഷിക്കാൻ അഡ്മിനിസ്ട്രേറ്റർമാർ ആഗ്രഹിക്കുന്നില്ല. Red Hat, SUSE പോലുള്ള എന്റർപ്രൈസ് ലിനക്സ് വിതരണക്കാർ തങ്ങളുടെ ഉപയോക്താക്കൾക്കായി സ്ഥിരതയുള്ള kABI പിന്തുണയ്ക്കാൻ തീരുമാനിച്ചു. Red Hat-നുള്ള KMOD പാക്കേജുകളും SUSE-നുള്ള KMP പാക്കേജുകളും ആയിരുന്നു ഫലം.

ഈ പരിഹാരത്തിന്റെ സാരാംശം വളരെ ലളിതമാണ്. വിതരണത്തിന്റെ ഒരു നിർദ്ദിഷ്‌ട പതിപ്പിന്, കേർണൽ API ഫ്രീസ് ചെയ്‌തിരിക്കുന്നു. വിതരണക്കാരൻ പറയുന്നത് താൻ കേർണൽ ഉപയോഗിക്കുന്നു, ഉദാഹരണത്തിന്, 3.10, കൂടാതെ കേർണൽ ഇന്റർഫേസുകളെ ബാധിക്കാത്ത തിരുത്തലുകളും മെച്ചപ്പെടുത്തലുകളും മാത്രം ചെയ്യുന്നു, കൂടാതെ ആദ്യത്തെ കേർണലിനായി ശേഖരിച്ച മൊഡ്യൂളുകൾ വീണ്ടും കംപൈൽ ചെയ്യാതെ തന്നെ തുടർന്നുള്ള എല്ലാത്തിനും ഉപയോഗിക്കാനാകും.

Red Hat അതിന്റെ മുഴുവൻ ജീവിതചക്രത്തിലും വിതരണത്തിന് kABI അനുയോജ്യത അവകാശപ്പെടുന്നു. അതായത്, rhel 6.0 (റിലീസ് നവംബർ 2010) എന്നതിനായുള്ള അസംബിൾ ചെയ്ത മൊഡ്യൂൾ 6.10 പതിപ്പിലും പ്രവർത്തിക്കണം (റിലീസ് ജൂൺ 2018). ഇത് ഏകദേശം 8 വർഷമാണ്. സ്വാഭാവികമായും, ഈ ജോലി വളരെ ബുദ്ധിമുട്ടാണ്.
kABI അനുയോജ്യത പ്രശ്‌നങ്ങൾ കാരണം വീംസ്‌നാപ്പ് മൊഡ്യൂൾ പ്രവർത്തിക്കുന്നത് നിർത്തിയ നിരവധി കേസുകൾ ഞങ്ങൾ രേഖപ്പെടുത്തിയിട്ടുണ്ട്.

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 നയത്തിന്റെ ഫലമായി, ഞങ്ങളുടെ വീംസ്‌നാപ്പ് മൊഡ്യൂളിൽ 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 ഫംഗ്‌ഷന് മാസ്‌ക് പാരാമീറ്റർ ഉണ്ടോ എന്ന് പരിശോധിക്കുന്ന ഒരു സ്‌ക്രിപ്റ്റ് എനിക്ക് makefile-ലേക്ക് ചേർക്കേണ്ടി വന്നു.

കേർണൽ മൊഡ്യൂളുകൾ ഒപ്പിടുന്നു

എന്നാൽ പാക്കേജ് വിതരണത്തിന്റെ പ്രശ്നത്തിലേക്ക് മടങ്ങാം.

കേർണൽ മൊഡ്യൂളുകൾ ഒരു ബൈനറി ഫയലായി സൈൻ ചെയ്യാം എന്നതാണ് സ്റ്റേബിൾ കെഎബിഐയുടെ ഒരു ഗുണം. ഈ സാഹചര്യത്തിൽ, മൊഡ്യൂളിന് ആകസ്മികമായി കേടുപാടുകൾ സംഭവിച്ചിട്ടില്ലെന്ന് അല്ലെങ്കിൽ മനഃപൂർവ്വം പരിഷ്കരിച്ചിട്ടില്ലെന്ന് ഡവലപ്പർക്ക് ഉറപ്പിക്കാം. modinfo കമാൻഡ് ഉപയോഗിച്ച് നിങ്ങൾക്ക് ഇത് പരിശോധിക്കാം.

Red Hat, SUSE ഡിസ്ട്രിബ്യൂഷനുകൾ മൊഡ്യൂളിന്റെ ഒപ്പ് പരിശോധിക്കാനും അനുബന്ധ സർട്ടിഫിക്കറ്റ് സിസ്റ്റത്തിൽ രജിസ്റ്റർ ചെയ്തിട്ടുണ്ടെങ്കിൽ മാത്രം ലോഡ് ചെയ്യാനും നിങ്ങളെ അനുവദിക്കുന്നു. മൊഡ്യൂൾ ഒപ്പിട്ട പൊതു കീയാണ് സർട്ടിഫിക്കറ്റ്. ഞങ്ങൾ ഇത് ഒരു പ്രത്യേക പാക്കേജായി വിതരണം ചെയ്യുന്നു.

സർട്ടിഫിക്കറ്റുകൾ കേർണലിലേക്ക് നിർമ്മിക്കാം (വിതരണക്കാർ അവ ഉപയോഗിക്കുന്നു) അല്ലെങ്കിൽ ഒരു യൂട്ടിലിറ്റി ഉപയോഗിച്ച് EFI നോൺ-വോലറ്റൈൽ മെമ്മറിയിലേക്ക് എഴുതണം എന്നതാണ് ഇവിടെയുള്ള പ്രശ്നം. മൊകുടിൽ. യൂട്ടിലിറ്റി മൊകുടിൽ ഒരു സർട്ടിഫിക്കറ്റ് ഇൻസ്റ്റാൾ ചെയ്യുമ്പോൾ, നിങ്ങൾ സിസ്റ്റം റീബൂട്ട് ചെയ്യേണ്ടതുണ്ട്, കൂടാതെ ഓപ്പറേറ്റിംഗ് സിസ്റ്റം കേർണൽ ലോഡുചെയ്യുന്നതിന് മുമ്പുതന്നെ, ഒരു പുതിയ സർട്ടിഫിക്കറ്റ് ലോഡുചെയ്യാൻ അനുവദിക്കുന്നതിന് അഡ്മിനിസ്ട്രേറ്ററെ പ്രേരിപ്പിക്കുന്നു.

അതിനാൽ, ഒരു സർട്ടിഫിക്കറ്റ് ചേർക്കുന്നതിന് സിസ്റ്റത്തിലേക്ക് ഫിസിക്കൽ അഡ്മിനിസ്ട്രേറ്റർ ആക്സസ് ആവശ്യമാണ്. മെഷീൻ ക്ലൗഡിൽ എവിടെയെങ്കിലും അല്ലെങ്കിൽ ഒരു വിദൂര സെർവർ റൂമിൽ സ്ഥിതിചെയ്യുകയും നെറ്റ്‌വർക്ക് വഴി (ഉദാഹരണത്തിന്, ssh വഴി) ആക്‌സസ്സ് മാത്രമാണെങ്കിൽ, ഒരു സർട്ടിഫിക്കറ്റ് ചേർക്കുന്നത് അസാധ്യമായിരിക്കും.

വെർച്വൽ മെഷീനുകളിൽ EFI

മിക്കവാറും എല്ലാ മദർബോർഡ് നിർമ്മാതാക്കളും EFI-യെ ദീർഘകാലമായി പിന്തുണയ്ക്കുന്നുണ്ടെങ്കിലും, ഒരു സിസ്റ്റം ഇൻസ്റ്റാൾ ചെയ്യുമ്പോൾ, അഡ്മിനിസ്ട്രേറ്റർ EFI- യുടെ ആവശ്യകതയെക്കുറിച്ച് ചിന്തിച്ചേക്കില്ല, അത് അപ്രാപ്തമാക്കിയേക്കാം.

എല്ലാ ഹൈപ്പർവൈസറുകളും EFI പിന്തുണയ്ക്കുന്നില്ല. VMWare vSphere പതിപ്പ് 5 മുതൽ EFI പിന്തുണയ്ക്കുന്നു.
വിൻഡോസ് സെർവർ 2012R2-നുള്ള ഹൈപ്പർ-വി മുതൽ മൈക്രോസോഫ്റ്റ് ഹൈപ്പർ-വി EFI പിന്തുണയും നേടി.

എന്നിരുന്നാലും, ഡിഫോൾട്ട് കോൺഫിഗറേഷനിൽ ഈ പ്രവർത്തനം Linux മെഷീനുകൾക്കായി പ്രവർത്തനരഹിതമാക്കിയിരിക്കുന്നു, അതായത് സർട്ടിഫിക്കറ്റ് ഇൻസ്റ്റാൾ ചെയ്യാൻ കഴിയില്ല.

vSphere 6.5 ൽ, ഓപ്ഷൻ സജ്ജമാക്കുക സുരക്ഷിത ബൂട്ട് ഫ്ലാഷ് വഴി പ്രവർത്തിക്കുന്ന വെബ് ഇന്റർഫേസിന്റെ പഴയ പതിപ്പിൽ മാത്രമേ സാധ്യമാകൂ. HTML-5-ലെ വെബ് യുഐ ഇപ്പോഴും വളരെ പിന്നിലാണ്.

പരീക്ഷണാത്മക വിതരണങ്ങൾ

അവസാനമായി, ഔദ്യോഗിക പിന്തുണയില്ലാതെ പരീക്ഷണാത്മക വിതരണങ്ങളുടെയും വിതരണങ്ങളുടെയും പ്രശ്നം പരിഗണിക്കാം. ഒരു വശത്ത്, അത്തരം വിതരണങ്ങൾ ഗുരുതരമായ സംഘടനകളുടെ സെർവറുകളിൽ കണ്ടെത്താൻ സാധ്യതയില്ല. ഇത്തരം വിതരണങ്ങൾക്ക് ഔദ്യോഗിക പിന്തുണയില്ല. അതിനാൽ, അവ നൽകുക. അത്തരമൊരു വിതരണത്തിൽ ഉൽപ്പന്നത്തെ പിന്തുണയ്ക്കാൻ കഴിയില്ല.

എന്നിരുന്നാലും, അത്തരം വിതരണങ്ങൾ പുതിയ പരീക്ഷണാത്മക പരിഹാരങ്ങൾ പരീക്ഷിക്കുന്നതിനുള്ള ഒരു സൗകര്യപ്രദമായ വേദിയായി മാറുന്നു. ഉദാഹരണത്തിന്, Fedora, OpenSUSE Tumbleweed അല്ലെങ്കിൽ Debian-ന്റെ അസ്ഥിര പതിപ്പുകൾ. അവ തികച്ചും സ്ഥിരതയുള്ളവയാണ്. അവർക്ക് എല്ലായ്‌പ്പോഴും പ്രോഗ്രാമുകളുടെ പുതിയ പതിപ്പുകളും എല്ലായ്പ്പോഴും ഒരു പുതിയ കേർണലും ഉണ്ട്. ഒരു വർഷത്തിനുള്ളിൽ, ഈ പരീക്ഷണാത്മക പ്രവർത്തനം ഒരു പുതുക്കിയ RHEL, SLES അല്ലെങ്കിൽ ഉബുണ്ടുവിൽ അവസാനിച്ചേക്കാം.

അതിനാൽ ഒരു പരീക്ഷണാത്മക വിതരണത്തിൽ എന്തെങ്കിലും പ്രവർത്തിക്കുന്നില്ലെങ്കിൽ, പ്രശ്നം കണ്ടെത്താനും അത് പരിഹരിക്കാനുമുള്ള ഒരു കാരണമാണിത്. ഉപയോക്താക്കളുടെ പ്രൊഡക്ഷൻ സെർവറുകളിൽ ഈ പ്രവർത്തനം ഉടൻ ദൃശ്യമാകുമെന്ന വസ്തുതയ്ക്കായി നിങ്ങൾ തയ്യാറാകേണ്ടതുണ്ട്.

പതിപ്പ് 3.0-നായി ഔദ്യോഗികമായി പിന്തുണയ്ക്കുന്ന വിതരണങ്ങളുടെ നിലവിലെ ലിസ്റ്റ് നിങ്ങൾക്ക് പഠിക്കാം ഇവിടെ. എന്നാൽ ഞങ്ങളുടെ ഉൽപ്പന്നത്തിന് പ്രവർത്തിക്കാൻ കഴിയുന്ന വിതരണങ്ങളുടെ യഥാർത്ഥ ലിസ്റ്റ് വളരെ വിശാലമാണ്.

വ്യക്തിപരമായി, എൽബ്രസ് ഒഎസിലുള്ള പരീക്ഷണത്തിൽ എനിക്ക് താൽപ്പര്യമുണ്ടായിരുന്നു. വീം പാക്കേജ് അന്തിമമാക്കിയ ശേഷം, ഞങ്ങളുടെ ഉൽപ്പന്നം ഇൻസ്റ്റാൾ ചെയ്യുകയും പ്രവർത്തിക്കുകയും ചെയ്തു. ഹബ്രെയിൽ ഈ പരീക്ഷണത്തെക്കുറിച്ച് ഞാൻ എഴുതി ലേഖനം.

ശരി, പുതിയ വിതരണങ്ങൾക്കുള്ള പിന്തുണ തുടരുന്നു. പതിപ്പ് 4.0 പുറത്തിറങ്ങുന്നതിനായി ഞങ്ങൾ കാത്തിരിക്കുകയാണ്. ബീറ്റ ദൃശ്യമാകാൻ പോകുന്നു, അതിനാൽ ശ്രദ്ധിക്കുക പുതിയതെന്താണ്!

അവലംബം: www.habr.com