ሊኑክስ ብዙ መልኮች አሉት-በማንኛውም ስርጭት ላይ እንዴት እንደሚሰራ

በማንኛውም ስርጭት ላይ የሚሰራ የመጠባበቂያ መተግበሪያ መፍጠር ቀላል ስራ አይደለም። Veeam Agent ለሊኑክስ ከ Red Hat 6 እና Debian 6 እስከ OpenSUSE 15.1 እና Ubuntu 19.04 ባሉት ስርጭቶች ላይ እንደሚሰራ ለማረጋገጥ በተለይ የሶፍትዌር ምርቱ የከርነል ሞጁሉን ያካተተ መሆኑን ከግምት በማስገባት የተለያዩ ችግሮችን መፍታት አለቦት።

ጽሑፉ የተዘጋጀው በኮንፈረንሱ ላይ ባደረጉት ንግግር ቁሳቁሶች ላይ በመመስረት ነው። ሊኑክስ ፒተር 2019.

ሊኑክስ በጣም ታዋቂ ከሆኑ ኦፕሬቲንግ ሲስተሞች አንዱ ብቻ አይደለም። በመሠረቱ, ይህ ልዩ የሆነ ነገር ማድረግ የሚችሉበት መድረክ ነው, የእራስዎ የሆነ ነገር. ለዚህም ምስጋና ይግባውና ሊኑክስ በሶፍትዌር ክፍሎች ስብስብ ውስጥ የሚለያዩ ብዙ ስርጭቶች አሉት። እና እዚህ አንድ ችግር ይፈጠራል-የሶፍትዌር ምርት በማንኛውም ስርጭት ላይ እንዲሰራ የእያንዳንዱን ገፅታዎች ግምት ውስጥ ማስገባት አለብዎት.

የጥቅል አስተዳዳሪዎች. ዴብ vs .rpm

ምርቱን በተለያዩ ስርጭቶች የማከፋፈል ግልጽ በሆነ ችግር እንጀምር።
የሶፍትዌር ምርቶችን ለማሰራጨት በጣም የተለመደው መንገድ ጥቅሉን በማጠራቀሚያ ላይ በማስቀመጥ በሲስተሙ ውስጥ የተገነባው የጥቅል አስተዳዳሪ ከዚያ መጫን ይችላል።
ሆኖም፣ ሁለት ታዋቂ የጥቅል ቅርጸቶች አሉን፦ ሪች и ዲ. ይህ ማለት ሁሉም ሰው መደገፍ አለበት.

በዴብ ፓኬጆች ዓለም ውስጥ የተኳኋኝነት ደረጃ በጣም አስደናቂ ነው። ተመሳሳዩ ፓኬጅ በዴቢያን 6 እና በኡቡንቱ 19.04 ላይም ተጭኖ በእኩልነት ይሰራል። በአሮጌው የዴቢያን ስርጭቶች ውስጥ የተቀመጡት ፓኬጆችን የመገንባት እና ከእነሱ ጋር አብሮ የመስራት ሂደት ደረጃዎች በአዲሱ ሊኑክስ ሚንት እና አንደኛ ደረጃ ስርዓተ ክወና ውስጥ ጠቃሚ እንደሆኑ ይቆያሉ። ስለዚህ የ Veeam Agent ለሊኑክስን በተመለከተ ለእያንዳንዱ የሃርድዌር መድረክ አንድ የደብዳቤ ጥቅል በቂ ነው።

ነገር ግን በ rpm ፓኬጆች ዓለም ውስጥ, ልዩነቶቹ በጣም ጥሩ ናቸው. በመጀመሪያ ፣ ሁለት ሙሉ በሙሉ ገለልተኛ አከፋፋዮች በመኖራቸው ፣ Red Hat እና SUSE ፣ ለዚህም ተኳሃኝነት ሙሉ በሙሉ አላስፈላጊ ነው። በሁለተኛ ደረጃ, እነዚህ አከፋፋዮች ከእነዚያ የማከፋፈያ ቁሳቁሶች አሏቸው. ድጋፍ እና ሙከራ. በመካከላቸውም ተኳሃኝነት አያስፈልግም. ኤል6፣ ኤል7 እና ኤል8 የራሳቸው ፓኬጆች አሏቸው። ለ Fedora የተለየ ጥቅል። የ SLES11 እና 12 እሽጎች እና የተለየ ለ openSUSE። ዋናው ችግር ጥገኛ እና የጥቅል ስሞች ናቸው.

የጥገኛነት ችግር

እንደ አለመታደል ሆኖ, ተመሳሳይ ፓኬጆች በተለያዩ ስርጭቶች ውስጥ በተለያዩ ስሞች ይጠናቀቃሉ. ከዚህ በታች የ veeam ጥቅል ጥገኞች ከፊል ዝርዝር አለ።

ለ EL7፡-
ለ SLES 12፡

• libblkid
• libgcc
• libstdc++
• ነቀፋ-libs
• ፊውዝ-libs
• ፋይል-libs
• veeamsnap = 3.0.2.1185

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

በውጤቱም, የጥገኛዎች ዝርዝር ለስርጭቱ ልዩ ነው.

በጣም የሚከፋው የተሻሻለው ስሪት በአሮጌው የጥቅል ስም መደበቅ ሲጀምር ነው።

ለምሳሌ:

ጥቅሉ በ Fedora 24 ውስጥ ተዘምኗል ncurses ከስሪት 5 እስከ ስሪት 6. ምርታችን ከአሮጌ ስርጭቶች ጋር መጣጣምን ለማረጋገጥ በስሪት 5 ተገንብቷል። በ Fedora 5 ላይ የድሮውን 24 ኛ የቤተ-መጽሐፍት ስሪት ለመጠቀም ጥቅሉን መጠቀም ነበረብኝ ncurses-compat-libs.

በውጤቱም, ለ Fedora ሁለት ጥቅሎች አሉ, የተለያዩ ጥገኛዎች.

የበለጠ አስደሳች። ከሚቀጥለው የስርጭት ዝመና በኋላ, እሽጉ ncurses-compat-libs በቤተ-መጽሐፍት ስሪት 5 የማይገኝ ሆኖ ተገኝቷል። አንድ አከፋፋይ የቆዩ ቤተ-መጻሕፍትን ወደ አዲስ የስርጭት ሥሪት መጎተት ውድ ነው። ከተወሰነ ጊዜ በኋላ ችግሩ በ SUSE ስርጭቶች ውስጥ እራሱን ደግሟል።

በዚህ ምክንያት አንዳንድ ስርጭቶች ግልጽ ጥገኝነታቸውን ማቋረጥ ነበረባቸው ነቀፋ-libs, እና ምርቱ ከማንኛውም የቤተ-መጽሐፍት ስሪት ጋር እንዲሰራ ያስተካክሉት.

በነገራችን ላይ በቀይ ኮፍያ ስሪት 8 ውስጥ የሜታ ጥቅል የለም። ጭረት, ይህም ጥሩ አሮጌውን ያመለክታል Python 2.7. አለ python2 и ጭረት3.

ከጥቅል አስተዳዳሪዎች ጋር ተለዋጭ

የጥገኛዎች ችግር አሮጌ እና ለረጅም ጊዜ ግልጽ ሆኖ ቆይቷል. ጥገኝነት ገሃነምን አስታውስ።
ሁሉም በተረጋጋ ሁኔታ እንዲሰሩ እና እንዳይጋጩ የተለያዩ ቤተ-መጻሕፍትን እና አፕሊኬሽኖችን ለማጣመር - በእርግጥ ይህ ማንኛውም የሊኑክስ አከፋፋይ ለመፍታት የሚሞክረው ተግባር ነው።

የጥቅል አስተዳዳሪው ይህንን ችግር ሙሉ ለሙሉ በተለየ መንገድ ለመፍታት ይሞክራል. ቆንጆ ከቀኖናዊ. ዋናው ሀሳብ: አፕሊኬሽኑ የሚሄደው በማጠሪያው ገለልተኛ እና ከዋናው ስርዓት የተጠበቀ ነው. አፕሊኬሽኑ ቤተ መፃህፍትን የሚፈልግ ከሆነ ከማመልከቻው እራሱ ጋር ነው የሚቀርበው።

Flatpak እንዲሁም የሊኑክስ ኮንቴይነሮችን በመጠቀም በማጠሪያ ውስጥ መተግበሪያዎችን እንዲያካሂዱ ይፈቅድልዎታል. የማጠሪያው ሃሳብም ጥቅም ላይ ይውላል ምስል.

እነዚህ መፍትሄዎች ለማንኛውም ስርጭት አንድ ጥቅል እንዲፈጥሩ ያስችሉዎታል. በዚህ ጊዜ Flatpak የመተግበሪያውን መጫን እና ማስጀመር ያለ አስተዳዳሪው እውቀት እንኳን ይቻላል.

ዋናው ችግር ሁሉም መተግበሪያዎች በአሸዋ ሳጥን ውስጥ ሊሰሩ አይችሉም. አንዳንድ ሰዎች ወደ መድረኩ ቀጥተኛ መዳረሻ ያስፈልጋቸዋል። እኔ እንኳን ስለ ከርነል ሞጁሎች እየተናገርኩ አይደለሁም ፣ እነሱ በከርነል ላይ በጥብቅ የተመሰረቱ እና ከማጠሪያው ጽንሰ-ሀሳብ ጋር የማይስማሙ።

ሁለተኛው ችግር በድርጅቱ አካባቢ ከ Red Hat እና SUSE ታዋቂ ስርጭቶች ለ Snappy እና Flatpak ድጋፍ እስካሁን አልያዙም።

በዚህ ረገድ የሊኑክስ የ Veeam ወኪል አይገኝም snapcraft.io አይደለም flathub.org.

ስለ ጥቅል አስተዳዳሪዎች ያለውን ጥያቄ ለመደምደም፣ ሁለትዮሽ ፋይሎችን እና እነሱን ለመጫን ስክሪፕት በማጣመር የጥቅል አስተዳዳሪዎችን ሙሉ በሙሉ የመተው አማራጭ እንዳለ ልብ ማለት እፈልጋለሁ።

እንዲህ ዓይነቱ ጥቅል ለተለያዩ ማከፋፈያዎች እና መድረኮች አንድ የተለመደ ጥቅል እንዲፈጥሩ ይፈቅድልዎታል, በይነተገናኝ የመጫን ሂደትን ያካሂዳሉ, አስፈላጊውን ማበጀት ያካሂዳሉ. እንደዚህ አይነት ፓኬጆችን ለሊኑክስ ከVMware ብቻ አጋጥሞኛል።

የማዘመን ችግር

ምንም እንኳን ሁሉም የጥገኝነት ጉዳዮች መፍትሄ ቢያገኙም, ፕሮግራሙ በተመሳሳዩ ስርጭት ላይ በተለየ መንገድ ሊሠራ ይችላል. ስለ ዝመናዎች ነው።

3 የማዘመን ስልቶች አሉ፡

• በጣም ቀላሉ ማለት በጭራሽ አለመዘመን ነው። አገልጋዩን አዘጋጅቼ ረሳሁት። ሁሉም ነገር የሚሰራ ከሆነ ለምን ማዘመን? ድጋፉን ለመጀመሪያ ጊዜ ሲያነጋግሩ ችግሮች ይጀምራሉ. የስርጭቱ ፈጣሪ የዘመነውን ልቀት ብቻ ይደግፋል።
• አከፋፋዩን ማመን እና ራስ-ሰር ዝመናዎችን ማቀናበር ይችላሉ። በዚህ አጋጣሚ የድጋፍ ጥሪ ካልተሳካ ዝመና በኋላ ወዲያውኑ ሊሆን ይችላል።
• በሙከራ መሠረተ ልማት ላይ ከተሰራ በኋላ ብቻ በእጅ የማዘመን አማራጭ በጣም አስተማማኝ ፣ ግን ውድ እና ጊዜ የሚወስድ ነው። ሁሉም ሰው ሊገዛው አይችልም.

የተለያዩ ተጠቃሚዎች የተለያዩ የማሻሻያ ስልቶችን ስለሚጠቀሙ የቅርብ ጊዜውን እና ቀደም ሲል የተለቀቁትን ሁለቱንም መደገፍ ያስፈልጋል። ይህ ሁለቱንም የእድገት እና የፈተና ሂደትን ያወሳስበዋል እና ለድጋፍ ቡድኑ ራስ ምታት ይጨምራል።

የተለያዩ የሃርድዌር መድረኮች

የተለያዩ የሃርድዌር መድረኮች በአብዛኛው ለአገርኛ ኮድ የተወሰነ ችግር ናቸው። ቢያንስ ለእያንዳንዱ የሚደገፍ መድረክ ሁለትዮሽ መሰብሰብ አለቦት።

በ Veeam ወኪል ለሊኑክስ ፕሮጀክት አሁንም እንደዚህ ያለ RISC ማንኛውንም ነገር መደገፍ አንችልም።

በዚህ ጉዳይ ላይ በዝርዝር አልቆይም። ዋና ዋናዎቹን ችግሮች ብቻ እገልጻለሁ: በመድረክ ላይ ጥገኛ የሆኑ ዓይነቶች, እንደ size_t, መዋቅር አሰላለፍ እና ባይት ቅደም ተከተል.

የማይንቀሳቀስ እና/ወይም ተለዋዋጭ ማገናኘት።

ግን ጥያቄው “ከቤተ-መጽሐፍት ጋር እንዴት ማገናኘት እንደሚቻል - በተለዋዋጭ ወይም በስታቲስቲክስ?” ነው። መወያየት ተገቢ ነው።

እንደ ደንቡ፣ በሊኑክስ ስር ያሉ የC/C++ መተግበሪያዎች ተለዋዋጭ ማገናኛን ይጠቀማሉ። አፕሊኬሽኑ ለተለየ ስርጭት ከተሰራ ይህ በጣም ጥሩ ይሰራል።

ስራው የተለያዩ ስርጭቶችን በአንድ ሁለትዮሽ ፋይል መሸፈን ከሆነ፣ በጣም ጥንታዊ በሆነው የተደገፈ ስርጭት ላይ ማተኮር አለብዎት። ለእኛ ይህ ቀይ ኮፍያ 6 ነው gcc 4.4 ይዟል፣ የC++11 መስፈርት እንኳን የማይደግፈው። ሙሉ.

ፕሮጀክታችንን የምንገነባው gcc 6.3 በመጠቀም ሲሆን ይህም C++14ን ሙሉ በሙሉ ይደግፋል። በተፈጥሮ፣ በዚህ አጋጣሚ፣ በቀይ ኮፍያ 6 ላይ libstdc++ ይዘው መሄድ እና ቤተ-መጻሕፍትን ከእርስዎ ጋር ማሳደግ አለብዎት። ቀላሉ መንገድ ከነሱ ጋር በስታቲስቲክስ ማገናኘት ነው.

ግን ወዮ፣ ሁሉም ቤተ-መጻሕፍት በስታቲስቲክስ ሊገናኙ አይችሉም።

በመጀመሪያ ፣ የስርዓት ቤተ-መጽሐፍት እንደ libfuse, libblkid ከከርነል እና ከሞጁሎቹ ጋር ያላቸውን ተኳሃኝነት ለማረጋገጥ በተለዋዋጭ መንገድ ማገናኘት አስፈላጊ ነው።

በሁለተኛ ደረጃ፣ ፈቃዶች ያሉት ረቂቅ ነገር አለ።

የGPL ፍቃዱ በመሠረቱ ላይብረሪዎችን በክፍት ምንጭ ኮድ ብቻ እንዲያገናኙ ይፈቅድልዎታል። MIT እና BSD የማይለዋወጥ ትስስር ይፈቅዳሉ እና ቤተ-መጻሕፍት በፕሮጀክት ውስጥ እንዲካተቱ ይፈቅዳሉ። ነገር ግን LGPL የማይንቀሳቀስ ግንኙነትን የሚቃረን አይመስልም፣ ነገር ግን ለማገናኘት አስፈላጊ የሆኑ ፋይሎች እንዲጋሩ ይፈልጋል።

በአጠቃላይ፣ ተለዋዋጭ ማገናኛን መጠቀም ማንኛውንም ነገር ከማቅረብ ይከለክላል።

የ C/C ++ አፕሊኬሽኖች ግንባታ

ለተለያዩ መድረኮች እና ስርጭቶች የC/C++ አፕሊኬሽኖችን ለመገንባት ተስማሚ የሆነ የጂሲሲ እትም መምረጥ ወይም መገንባት እና ለተወሰኑ አርክቴክቸር ማሻሻያዎችን መጠቀም እና አጠቃላይ የቤተ-መጻህፍት ስብስቦችን መሰብሰብ በቂ ነው። ይህ ሥራ በጣም የሚቻል ነው, ግን በጣም አስቸጋሪ ነው. እና የተመረጠው ማጠናከሪያ እና ቤተ-መጻሕፍት ሊሰራ የሚችል ስሪት እንደሚሰጡ ምንም ዋስትና የለም.

ግልጽ የሆነ ጥቅም: አጠቃላይ የግንባታ ሂደቱ በአንድ ማሽን ላይ ሊጠናቀቅ ስለሚችል መሠረተ ልማቱ በጣም ቀላል ነው. በተጨማሪም, ለአንድ አርክቴክቸር አንድ የሁለትዮሽ ስብስቦችን መሰብሰብ በቂ ነው እና ለተለያዩ ስርጭቶች ወደ ፓኬጆች ማሸግ ይችላሉ. ለ Veeam Agent ለሊኑክስ የቪም ፓኬጆች የሚገነቡት በዚህ መንገድ ነው።

ከዚህ አማራጭ በተቃራኒ በቀላሉ የግንባታ እርሻን ማለትም ብዙ ማሽኖችን ለመገጣጠሚያ ማዘጋጀት ይችላሉ. እያንዳንዱ እንደዚህ ዓይነት ማሽን ለአንድ የተወሰነ ስርጭት እና ለአንድ የተወሰነ አርክቴክቸር የመተግበሪያ ማጠናቀር እና የጥቅል ስብስብ ያቀርባል። በዚህ ሁኔታ, ማጠናቀር የሚከናወነው በአከፋፋዩ የተዘጋጀውን ዘዴ በመጠቀም ነው. ያም ማለት ማጠናከሪያውን የማዘጋጀት እና ቤተ-መጻሕፍትን የመምረጥ ደረጃ ይወገዳል. በተጨማሪም የግንባታ ሂደቱ በቀላሉ ሊመሳሰል ይችላል.

ይሁን እንጂ በዚህ አቀራረብ ላይ አሉታዊ ጎኖች አሉ-በተመሳሳይ አርክቴክቸር ውስጥ ላለው እያንዳንዱ ስርጭት የራስዎን የሁለትዮሽ ፋይሎች ስብስብ መሰብሰብ ይኖርብዎታል. ሌላው ጉዳቱ ይህን ያህል ብዛት ያላቸው ማሽኖች እንዲቆዩ እና ከፍተኛ መጠን ያለው የዲስክ ቦታ እና ራም መመደብ አለባቸው።

የ veeamsnap kernel module KMOD ፓኬጆች ለቀይ ኮፍያ ስርጭቶች የሚዘጋጁት በዚህ መንገድ ነው።

የግንባታ አገልግሎትን ይክፈቱ

የ SUSE ባልደረቦች አፕሊኬሽኖችን ለማጠናቀር እና ፓኬጆችን ለመሰብሰብ በልዩ አገልግሎት መልክ አንዳንድ መካከለኛ ቦታዎችን ለመተግበር ሞክረዋል - openbuildservice.

በመሠረቱ, ምናባዊ ማሽንን የሚፈጥር, ሁሉንም አስፈላጊ ፓኬጆችን የሚጭን, አፕሊኬሽኑን ያጠናቅራል እና ጥቅሉን በዚህ ገለልተኛ አከባቢ ውስጥ የሚገነባ ሃይፐርቪዥን ነው, ከዚያ በኋላ ቨርቹዋል ማሽኑ ይለቀቃል.

በOpenBuildService ውስጥ የተተገበረው የጊዜ ሰሌዳ አዘጋጅ ለተመቻቸ የጥቅል ግንባታ ፍጥነት ምን ያህል ምናባዊ ማሽኖችን ማስጀመር እንደሚችል ይወስናል። አብሮገነብ የመፈረሚያ ዘዴ ፓኬጆቹን ይፈርማል እና ወደ አብሮገነብ ማከማቻ ይሰቅላቸዋል። አብሮ የተሰራው የስሪት ቁጥጥር ስርዓት ለውጦችን እና ግንባታዎችን ታሪክ ይቆጥባል። የቀረው በቀላሉ የእርስዎን ምንጮች ወደዚህ ስርዓት ማከል ብቻ ነው። አገልጋዩን እራስዎ ማዋቀር እንኳን አያስፈልግም፤ ክፍት መጠቀም ይችላሉ።

ይሁን እንጂ አንድ ችግር አለ: እንዲህ ዓይነቱ ማጨጃ አሁን ባለው መሠረተ ልማት ውስጥ ለመግባት አስቸጋሪ ነው. ለምሳሌ፣ የስሪት ቁጥጥር አያስፈልግም፤ ቀደም ሲል የምንጭ ኮዶች የራሳችን አለን። የእኛ የፊርማ ዘዴ የተለየ ነው፡ ልዩ አገልጋይ እንጠቀማለን። ማከማቻም አያስፈልግም።

በተጨማሪም ፣ ለሌሎች ስርጭቶች ድጋፍ - ለምሳሌ ፣ ቀይ ኮፍያ - በጥሩ ሁኔታ ይተገበራል ፣ ይህ ለመረዳት የሚቻል ነው።

የእንደዚህ አይነት አገልግሎት ጥቅም ለቀጣዩ የ SUSE ስርጭት ስሪት ፈጣን ድጋፍ ነው. የመልቀቂያው ኦፊሴላዊ መግለጫ ከመደረጉ በፊት ለስብሰባ አስፈላጊ የሆኑ ፓኬጆች በሕዝብ ማከማቻ ላይ ይለጠፋሉ. በOpenBuildService ላይ ባሉ ስርጭቶች ዝርዝር ውስጥ አዲስ ይታያል። ሳጥኑ ላይ ምልክት እናደርጋለን እና በግንባታው እቅድ ውስጥ ተጨምሯል. ስለዚህ, አዲስ የስርጭት ስሪት ማከል በአንድ ጠቅታ ውስጥ ይከናወናል.

በእኛ መሠረተ ልማት፣ OpenBuildServiceን በመጠቀም፣ ለ SUSE ስርጭቶች የ veeamsnap kernel module of KMP ፓኬጆች በሙሉ ተሰብስበዋል።

በመቀጠል፣ ለከርነል ሞጁሎች ልዩ በሆኑ ጉዳዮች ላይ ማተኮር እፈልጋለሁ።

ከርነል ABI

የሊኑክስ ከርነል ሞጁሎች በታሪክ በምንጭ መልክ ተሰራጭተዋል። እውነታው ግን የከርነል ፈጣሪዎች የተረጋጋ ኤፒአይ ለከርነል ሞጁሎች እና በተለይም በሁለትዮሽ ደረጃ ፣በተጨማሪ እንደ kABI በመጥቀስ እራሳቸውን አይጫኑም።

ለቫኒላ ከርነል ሞጁል ለመገንባት በእርግጠኝነት የዚህ ልዩ ከርነል ራስጌዎች ያስፈልግዎታል ፣ እና በዚህ አስኳል ላይ ብቻ ይሰራል።

DKMS ኮርነሉን በሚያዘምኑበት ጊዜ ሞጁሎችን የመገንባት ሂደት በራስ-ሰር እንዲሰሩ ይፈቅድልዎታል። በዚህ ምክንያት የዴቢያን ማከማቻ ተጠቃሚዎች (እና ብዙ ዘመዶቹ) የከርነል ሞጁሎችን ከአከፋፋዩ ማከማቻ ወይም ከምንጩ የተቀናበረ DKMS ይጠቀማሉ።

ይሁን እንጂ, ይህ ሁኔታ በተለይ የድርጅት ክፍልን አይስማማም. የባለቤትነት ኮድ አከፋፋዮች ምርቱን እንደ የተቀናበረ ሁለትዮሽ ማሰራጨት ይፈልጋሉ።

አስተዳዳሪዎች ለደህንነት ሲባል የግንባታ መሳሪያዎችን በምርት አገልጋዮች ላይ ማስቀመጥ አይፈልጉም። እንደ Red Hat እና SUSE ያሉ የኢንተርፕራይዝ ሊኑክስ አከፋፋዮች የተረጋጋ kABIን ለተጠቃሚዎቻቸው መደገፍ እንደሚችሉ ወሰኑ። ውጤቱ የ KMOD ጥቅሎች ለ Red Hat እና KMP ጥቅል ለ SUSE ነበር።

የዚህ መፍትሔ ዋናው ነገር በጣም ቀላል ነው. ለአንድ የተወሰነ የስርጭት ስሪት፣ የከርነል ኤፒአይ ቀዝቅዟል። አከፋፋዩ ከርነል ለምሳሌ 3.10 እንደሚጠቀም እና የከርነል መገናኛዎችን የማይነኩ እርማቶችን እና ማሻሻያዎችን ብቻ እንደሚያደርግ ይገልፃል እና ለመጀመሪያው የከርነል የተሰበሰቡት ሞጁሎች ለቀጣዮቹ በሙሉ ሳይጠናከሩ ሊጠቀሙበት ይችላሉ ።

Red Hat በጠቅላላው የህይወት ዑደቱ ውስጥ የ kABI ተኳኋኝነትን ይናገራል። ማለትም፣ የተሰበሰበው ሞጁል ለrhel 6.0 (የተለቀቀው ህዳር 2010) እንዲሁም በስሪት 6.10 (የተለቀቀው ሰኔ 2018) ላይ መስራት አለበት። እና ይህ ወደ 8 ዓመት ገደማ ነው. በተፈጥሮ, ይህ ተግባር በጣም ከባድ ነው.
የ veeamsnap ሞጁል በKABI ተኳሃኝነት ችግሮች ምክንያት መስራት ያቆመባቸውን በርካታ አጋጣሚዎች መዝግበናል።

ለRHEL 7.0 ከተጠናቀረ የveeamsnap ሞጁል በኋላ ከ RHEL 7.5 ከርነል ጋር ተኳሃኝ ሆኖ አልተገኘም፣ ነገር ግን ተጭኖ አገልጋዩን እንደሚያበላሽ ዋስትና ተሰጥቶት፣ የKABI ተኳኋኝነትን ለ RHEL 7 ሙሉ በሙሉ መጠቀሙን ትተናል።

በአሁኑ ጊዜ የ KMOD ጥቅል ለ RHEL 7 ለእያንዳንዱ የተለቀቀ ስሪት እና ሞጁሉን የሚጭን ስክሪፕት ይዟል።

SUSE የKABI ተኳሃኝነትን ተግባር የበለጠ በጥንቃቄ ቀርቧል። የKABI ተኳኋኝነት በአንድ የአገልግሎት ጥቅል ውስጥ ብቻ ይሰጣሉ።

ለምሳሌ፣ የ SLES 12 መለቀቅ የተካሄደው በሴፕቴምበር 2014 ነው። እና SLES 12 SP1 በዲሴምበር 2015 ነበር ማለትም ከአንድ አመት ትንሽ በላይ አልፏል። ምንም እንኳን ሁለቱም የተለቀቁት 3.12 ከርነል ቢጠቀሙም፣ kABI ተኳሃኝ አይደሉም። በግልጽ ለማየት እንደሚቻለው ለአንድ አመት ብቻ የKABI ተኳሃኝነትን መጠበቅ በጣም ቀላል ነው። ዓመታዊው የከርነል ሞጁል ማሻሻያ ዑደት ለሞዱል ፈጣሪዎች ችግር መፍጠር የለበትም።

በዚህ የSUSE ፖሊሲ ምክንያት፣ በእኛ veeamsnap ሞዱል ውስጥ ከKABI ተኳኋኝነት ጋር አንድም ችግር አልመዘገብንም። እውነት ነው፣ ለ SUSE የጥቅሎች ብዛት ከሞላ ጎደል ከፍተኛ መጠን ያለው ነው።

መጋጠሚያዎች እና የኋላ ሽፋኖች

ምንም እንኳን አከፋፋዮች የKABI ተኳሃኝነትን እና የከርነል መረጋጋትን ለማረጋገጥ ቢሞክሩም፣ አፈፃፀሙን ለማሻሻል እና የዚህን የተረጋጋ የከርነል ጉድለቶች ለማስወገድ ይሞክራሉ።

በተመሳሳይ ጊዜ, ከራሳቸው "ስህተቶች" በተጨማሪ የድርጅቱ የሊኑክስ ኮርነል አዘጋጆች በቫኒላ ከርነል ውስጥ ለውጦችን ይቆጣጠሩ እና ወደ "የተረጋጋ" ያስተላልፉታል.

አንዳንድ ጊዜ ይህ ወደ አዲስ ይመራል ስህተቶች.

በቅርብ የተለቀቀው የቀይ ኮፍያ 6፣ ከትንንሽ ዝመናዎች በአንዱ ላይ ስህተት ተፈጥሯል። ቅጽበተ-ፎቶው በሚለቀቅበት ጊዜ የ veeamsnap ሞጁል ስርዓቱን ለመበላሸቱ ዋስትና ተሰጥቶታል። የከርነል ምንጮችን ከዝማኔው በፊት እና በኋላ ካነፃፅርን፣ ተጠያቂው የኋላ ፖርት መሆኑን ደርሰንበታል። በቫኒላ ከርነል ስሪት 4.19 ውስጥ ተመሳሳይ ማስተካከያ ተደረገ። ይህ ማስተካከያ በቫኒላ ከርነል ውስጥ በጥሩ ሁኔታ መስራቱ ብቻ ነው, ነገር ግን ወደ "የተረጋጋ" 2.6.32 ሲያስተላልፉ, በአከርካሪው ላይ ችግር ተፈጠረ.

በእርግጥ ሁሉም ሰው ሁል ጊዜ ስህተቶች አሉት ፣ ግን ኮዱን ከ 4.19 ወደ 2.6.32 መጎተት ጠቃሚ ነበር ፣ መረጋጋትን አደጋ ላይ ይጥላል? ... እርግጠኛ አይደለሁም ...

በጣም መጥፎው ነገር ግብይት በ"መረጋጋት" እና "ዘመናዊነት" መካከል ባለው ጦርነት ውስጥ ሲገባ ነው። የግብይት ዲፓርትመንቱ የተሻሻለው ስርጭቱ ዋና አካል እንዲረጋጋ ይፈልጋል ፣ በአንድ በኩል ፣ እና በተመሳሳይ ጊዜ በአፈፃፀም የተሻለ እና አዲስ ባህሪዎች አሉት። ይህ ወደ እንግዳ ስምምነት ያመራል.

ከ SLES 4.4 SP12 በከርነል 3 ላይ ሞጁል ለመስራት ስሞክር በውስጡ ያለውን ተግባር ከቫኒላ 4.8 ሳገኝ ተገረምኩ። በእኔ አስተያየት የ 4.4 ከርነል ከ SLES 12 SP3 የማገጃ I/O አተገባበር ከ SLES 4.8 SP4.4 የተረጋጋ 12 ከርነል ቀደም ሲል ከተለቀቀው 2 ከርነል ጋር ተመሳሳይ ነው። ምን ያህል መቶኛ ኮድ ከከርነል 4.8 ወደ SLES 4.4 ለ SP3 እንደተላለፈ መወሰን አልችልም ነገር ግን ከርነሉን ተመሳሳይ የተረጋጋ 4.4 መደወል አልችልም።

በዚህ ውስጥ በጣም ደስ የማይል ነገር በተለያዩ ከርነሎች ላይ በእኩልነት የሚሰራ ሞጁል ሲጽፉ ከአሁን በኋላ በከርነል ሥሪት ላይ መተማመን አይችሉም። እንዲሁም ስርጭቱን ግምት ውስጥ ማስገባት አለብዎት. አንዳንድ ጊዜ ከአዳዲስ ተግባራት ጋር በሚታየው ፍቺ ውስጥ መሳተፍ ቢችሉ ጥሩ ነው ፣ ግን ይህ ዕድል ሁል ጊዜ አይታይም።

በውጤቱም፣ ኮዱ በአስገራሚ ሁኔታዊ የማጠናቀር መመሪያዎች ይበቅላል።

በሰነድ የተያዘውን የከርነል ኤፒአይ የሚቀይሩ ፕላቶችም አሉ።
ስርጭቱን አገኘሁት KDE neon 5.16 እና በዚህ የከርነል ስሪት ውስጥ ያለው Lookup_bdev ጥሪ የግቤት መለኪያዎችን ዝርዝር እንደለወጠው በማየቴ በጣም ተገረመ።

አንድ ላይ ለማግኘት፣ የ Lookup_bdev ተግባር ጭምብል ግቤት እንዳለው ወይም አለመሆኑን የሚያረጋግጥ ስክሪፕት ወደ makefile ማከል ነበረብኝ።

የከርነል ሞጁሎችን መፈረም

ግን ወደ ጥቅል ስርጭት ጉዳይ እንመለስ።

የተረጋጋ የ kABI አንዱ ጠቀሜታ የከርነል ሞጁሎች እንደ ሁለትዮሽ ፋይል ሊፈረሙ መቻላቸው ነው። በዚህ አጋጣሚ ገንቢው ሞጁሉን በአጋጣሚ እንዳልተጎዳ ወይም ሆን ተብሎ እንዳልተለወጠ እርግጠኛ መሆን ይችላል። ይህንን በmodinfo ትዕዛዝ ማረጋገጥ ይችላሉ።

Red Hat እና SUSE ስርጭቶች የሞጁሉን ፊርማ እንዲያረጋግጡ እና ተጓዳኝ የምስክር ወረቀት በሲስተሙ ላይ ከተመዘገበ ብቻ እንዲጭኑት ያስችሉዎታል። የምስክር ወረቀቱ ሞጁሉ የተፈረመበት ይፋዊ ቁልፍ ነው። እንደ የተለየ ጥቅል እናሰራጫለን.

እዚህ ያለው ችግር የምስክር ወረቀቶች በከርነል ውስጥ ሊገነቡ ይችላሉ (አከፋፋዮች ይጠቀማሉ) ወይም መገልገያን በመጠቀም ወደ EFI ተለዋዋጭ ማህደረ ትውስታ መፃፍ አለባቸው። mokutil. መገልገያ mokutil የምስክር ወረቀት በሚጭኑበት ጊዜ ስርዓቱን እንደገና ማስጀመር ያስፈልግዎታል እና የስርዓተ ክወናው ኮርነል ከመጫንዎ በፊት እንኳን አስተዳዳሪው አዲስ የምስክር ወረቀት እንዲጭን ይጠይቅዎታል።

ስለዚህ የምስክር ወረቀት ማከል የአካል አስተዳዳሪ የስርዓቱን መዳረሻ ይፈልጋል። ማሽኑ በደመና ውስጥ የሆነ ቦታ ወይም በቀላሉ በሩቅ የአገልጋይ ክፍል ውስጥ የሚገኝ ከሆነ እና መዳረሻ በኔትወርኩ በኩል ብቻ (ለምሳሌ በ ssh በኩል) ከሆነ የምስክር ወረቀት ማከል አይቻልም።

EFI በምናባዊ ማሽኖች ላይ

ምንም እንኳን EFI ከሞላ ጎደል በሁሉም የእናትቦርድ አምራቾች የተደገፈ ቢሆንም, ስርዓቱን ሲጭኑ, አስተዳዳሪው ስለ EFI አስፈላጊነት ላያስብ ይችላል, እና ሊሰናከል ይችላል.

ሁሉም ሃይፐርቫይዘሮች EFIን አይደግፉም። VMWare vSphere ከስሪት 5 ጀምሮ EFIን ይደግፋል።
ማይክሮሶፍት Hyper-V ከ Hyper-V ለዊንዶውስ አገልጋይ 2012R2 ጀምሮ የEFI ድጋፍ አግኝቷል።

ነገር ግን፣ በነባሪ ውቅር ውስጥ ይህ ተግባር ለሊኑክስ ማሽኖች ተሰናክሏል፣ ይህ ማለት የምስክር ወረቀቱ መጫን አይቻልም።

በ vSphere 6.5 ውስጥ አማራጩን ያዘጋጁ Secure Boot በ Flash በኩል በሚሰራው የድሮው የድር በይነገጽ ስሪት ውስጥ ብቻ ይቻላል. በኤችቲኤምኤል-5 ላይ ያለው የድር UI አሁንም በጣም ወደ ኋላ ነው።

የሙከራ ስርጭቶች

እና በመጨረሻም, ያለ ኦፊሴላዊ ድጋፍ የሙከራ ስርጭቶችን እና ስርጭቶችን ጉዳይ እናስብ. በአንድ በኩል, እንደዚህ ያሉ ስርጭቶች በከባድ ድርጅቶች አገልጋዮች ላይ ሊገኙ አይችሉም. ለእንደዚህ አይነት ስርጭቶች ኦፊሴላዊ ድጋፍ የለም. ስለዚህ, እነዚያን ያቅርቡ. ምርቱ በእንደዚህ አይነት ስርጭት ላይ ሊደገፍ አይችልም.

ይሁን እንጂ እንዲህ ያሉት ስርጭቶች አዲስ የሙከራ መፍትሄዎችን ለመሞከር አመቺ መድረክ ይሆናሉ. ለምሳሌ፣ Fedora፣ OpenSUSE Tumbleweed ወይም ያልተረጋጉ የዴቢያን ስሪቶች። እነሱ በጣም የተረጋጉ ናቸው. ሁልጊዜ አዲስ የፕሮግራሞች ስሪቶች እና ሁልጊዜ አዲስ ከርነል አላቸው. በዓመት ውስጥ፣ ይህ የሙከራ ተግባር በተዘመነ RHEL፣ SLES ወይም Ubuntu ውስጥ ሊጠናቀቅ ይችላል።

ስለዚህ አንድ ነገር በሙከራ ስርጭት ላይ የማይሰራ ከሆነ, ይህ ችግሩን ለማወቅ እና ለመፍታት ምክንያት ነው. ይህ ተግባር በቅርቡ በተጠቃሚዎች የምርት አገልጋዮች ላይ ስለሚታይ ዝግጁ መሆን አለቦት።

ለሥሪት 3.0 አሁን ያለውን በይፋ የሚደገፉ ስርጭቶችን ዝርዝር ማጥናት ይችላሉ። እዚህ. ነገር ግን ምርታችን ሊሰራበት የሚችልበት ትክክለኛው የስርጭት ዝርዝር በጣም ሰፊ ነው።

በግሌ ከኤልብራስ ስርዓተ ክወና ጋር ባለው ሙከራ ላይ ፍላጎት ነበረኝ. የቪም ፓኬጁን ከጨረስን በኋላ ምርታችን ተጭኖ እየሰራ ነው። ስለዚህ ሙከራ በ Habré in ጽፌያለሁ ጽሑፍ.

ደህና፣ ለአዳዲስ ስርጭቶች የሚደረገው ድጋፍ ቀጥሏል። ስሪት 4.0 እስኪወጣ ድረስ እየጠበቅን ነው። ቤታ ሊመጣ ነው፣ ስለዚህ ይከታተሉት። ምን አዲስ ነገር አለ!

ምንጭ: hab.com