Linux માં ઘણા ચહેરાઓ છે: કોઈપણ વિતરણ પર કેવી રીતે કાર્ય કરવું

કોઈપણ વિતરણ પર કામ કરતી બેકઅપ એપ્લિકેશન બનાવવી એ કોઈ સરળ કાર્ય નથી. Linux માટે Veeam Agent Red Hat 6 અને Debian 6 થી OpenSUSE 15.1 અને Ubuntu 19.04 સુધીના વિતરણો પર કામ કરે છે તેની ખાતરી કરવા માટે, તમારે ઘણી સમસ્યાઓ હલ કરવી પડશે, ખાસ કરીને સોફ્ટવેર ઉત્પાદનમાં કર્નલ મોડ્યુલનો સમાવેશ થાય છે તે ધ્યાનમાં લેવું.

આ લેખ કોન્ફરન્સમાં આપેલા ભાષણની સામગ્રીના આધારે બનાવવામાં આવ્યો હતો લિનક્સ પીટર 2019.

Linux એ માત્ર સૌથી વધુ લોકપ્રિય ઓપરેટિંગ સિસ્ટમોમાંની એક નથી. અનિવાર્યપણે, આ એક પ્લેટફોર્મ છે જેના આધારે તમે કંઈક અનોખું, તમારું પોતાનું કંઈક બનાવી શકો છો. આનો આભાર, Linux પાસે ઘણાં વિતરણો છે જે તેમના સોફ્ટવેર ઘટકોના સમૂહમાં અલગ પડે છે. અને અહીં એક સમસ્યા ઊભી થાય છે: સોફ્ટવેર ઉત્પાદન કોઈપણ વિતરણ પર કાર્ય કરવા માટે, તમારે દરેકની વિશેષતાઓને ધ્યાનમાં લેવી પડશે.

પેકેજ મેનેજરો. .deb વિ .rpm

ચાલો ઉત્પાદનને વિવિધ વિતરણોમાં વિતરિત કરવાની સ્પષ્ટ સમસ્યાથી પ્રારંભ કરીએ.
સૉફ્ટવેર ઉત્પાદનોનું વિતરણ કરવાની સૌથી લાક્ષણિક રીત એ છે કે પેકેજને રિપોઝીટરી પર મૂકવું જેથી કરીને સિસ્ટમમાં બનેલ પેકેજ મેનેજર તેને ત્યાંથી ઇન્સ્ટોલ કરી શકે.
જો કે, અમારી પાસે બે લોકપ્રિય પેકેજ ફોર્મેટ છે: RPM и દેબ. આનો અર્થ એ છે કે દરેકને ટેકો આપવો પડશે.

ડેબ પેકેજોની દુનિયામાં, સુસંગતતાનું સ્તર અદ્ભુત છે. સમાન પેકેજ ઇન્સ્ટોલ કરે છે અને ડેબિયન 6 અને ઉબુન્ટુ 19.04 બંને પર સમાન રીતે કાર્ય કરે છે. જૂના ડેબિયન ડિસ્ટ્રિબ્યુશનમાં નિર્ધારિત, પેકેજો બનાવવા અને તેમની સાથે કામ કરવાની પ્રક્રિયા માટેના ધોરણો, નવા લિનક્સ મિન્ટ અને પ્રાથમિક OSમાં સુસંગત રહે છે. તેથી, Linux માટે Veeam એજન્ટના કિસ્સામાં, દરેક હાર્ડવેર પ્લેટફોર્મ માટે એક ડેબ પેકેજ પૂરતું છે.

પરંતુ rpm પેકેજોની દુનિયામાં, તફાવતો મહાન છે. પ્રથમ, હકીકત એ છે કે ત્યાં બે સંપૂર્ણપણે સ્વતંત્ર વિતરકો છે, Red Hat અને SUSE, જેના માટે સુસંગતતા સંપૂર્ણપણે બિનજરૂરી છે. બીજું, આ વિતરકો પાસે તેમની પાસેથી વિતરણ કીટ છે. આધાર અને પ્રાયોગિક. તેમની વચ્ચે સુસંગતતાની પણ જરૂર નથી. તે બહાર આવ્યું છે કે el6, el7 અને el8 પાસે તેમના પોતાના પેકેજો છે. Fedora માટે અલગ પેકેજ. SLES11 અને 12 માટેના પેકેજો અને openSUSE માટે અલગ. મુખ્ય સમસ્યા નિર્ભરતા અને પેકેજ નામો છે.

નિર્ભરતાની સમસ્યા

કમનસીબે, સમાન પેકેજો ઘણીવાર અલગ-અલગ ડિસ્ટ્રિબ્યુશનમાં અલગ-અલગ નામો હેઠળ સમાપ્ત થાય છે. નીચે veeam પેકેજ અવલંબનની આંશિક સૂચિ છે.

EL7 માટે:
SLES 12 માટે:

• libblkid
• libgcc
• libstdc++
• ncurses-libs
• ફ્યુઝ-લિબ્સ
• ફાઇલ-લિબ્સ
• veeamsnap=3.0.2.1185

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

પરિણામે, ડિસ્ટ્રિબ્યુશન માટે નિર્ભરતાઓની સૂચિ અનન્ય છે.

જ્યારે અપડેટેડ સંસ્કરણ જૂના પેકેજ નામ હેઠળ છુપાવવાનું શરૂ કરે છે ત્યારે શું ખરાબ થાય છે.

ઉદાહરણ:

પેકેજ Fedora 24 માં અપડેટ કરવામાં આવ્યું છે શાપ સંસ્કરણ 5 થી સંસ્કરણ 6 સુધી. અમારા ઉત્પાદનને જૂના વિતરણો સાથે સુસંગતતા સુનિશ્ચિત કરવા માટે સંસ્કરણ 5 સાથે બનાવવામાં આવ્યું હતું. Fedora 5 પર લાઇબ્રેરીના જૂના 24મા સંસ્કરણનો ઉપયોગ કરવા માટે, મારે પેકેજનો ઉપયોગ કરવો પડ્યો ncurses-compat-libs.

પરિણામે, Fedora માટે બે પેકેજો છે, વિવિધ અવલંબન સાથે.

આગળ વધુ રસપ્રદ. આગામી વિતરણ અપડેટ પછી, પેકેજ ncurses-compat-libs પુસ્તકાલયના સંસ્કરણ 5 સાથે તે અનુપલબ્ધ હોવાનું બહાર આવ્યું છે. ડિસ્ટ્રિબ્યુટર માટે જૂની લાઇબ્રેરીઓને ડિસ્ટ્રિબ્યુશનના નવા વર્ઝનમાં ખેંચવું મોંઘું છે. થોડા સમય પછી, SUSE વિતરણોમાં સમસ્યાનું પુનરાવર્તન થયું.

પરિણામે, કેટલાક વિતરણોએ તેમની સ્પષ્ટ નિર્ભરતા છોડવી પડી ncurses-libs, અને ઉત્પાદનને ઠીક કરો જેથી કરીને તે લાઇબ્રેરીના કોઈપણ સંસ્કરણ સાથે કામ કરી શકે.

માર્ગ દ્વારા, Red Hat ની આવૃત્તિ 8 માં હવે મેટા પેકેજ નથી અજગર, જે સારા જૂનાનો ઉલ્લેખ કરે છે અજગર 2.7. ત્યાં છે python2 и અજગર3.

પેકેજ મેનેજરો માટે વૈકલ્પિક

નિર્ભરતાની સમસ્યા જૂની છે અને લાંબા સમયથી સ્પષ્ટ છે. માત્ર અવલંબન નરક યાદ રાખો.
વિવિધ લાઇબ્રેરીઓ અને એપ્લીકેશનોને જોડવા માટે જેથી તે બધા સ્થિર રીતે કાર્ય કરે અને સંઘર્ષ ન કરે - હકીકતમાં, આ તે કાર્ય છે જેને કોઈપણ Linux વિતરક હલ કરવાનો પ્રયાસ કરે છે.

પેકેજ મેનેજર આ સમસ્યાને સંપૂર્ણપણે અલગ રીતે હલ કરવાનો પ્રયાસ કરે છે. સ્નીપી કેનોનિકલમાંથી. મુખ્ય વિચાર: એપ્લિકેશન મુખ્ય સિસ્ટમથી અલગ અને સુરક્ષિત સેન્ડબોક્સમાં ચાલે છે. જો કોઈ એપ્લિકેશનને પુસ્તકાલયોની જરૂર હોય, તો તે એપ્લિકેશન સાથે જ પૂરી પાડવામાં આવે છે.

Flatpak તમને Linux કન્ટેનરનો ઉપયોગ કરીને સેન્ડબોક્સમાં એપ્લિકેશન ચલાવવા માટે પણ પરવાનગી આપે છે. સેન્ડબોક્સ વિચાર પણ વપરાય છે AppImage.

આ ઉકેલો તમને કોઈપણ વિતરણ માટે એક પેકેજ બનાવવાની મંજૂરી આપે છે. એ પરિસ્થિતિ માં Flatpak એડમિનિસ્ટ્રેટરની જાણ વિના પણ એપ્લિકેશનનું ઇન્સ્ટોલેશન અને લોન્ચ શક્ય છે.

મુખ્ય સમસ્યા એ છે કે બધી એપ્લિકેશનો સેન્ડબોક્સમાં ચાલી શકતી નથી. કેટલાક લોકોને પ્લેટફોર્મની સીધી ઍક્સેસની જરૂર છે. હું કર્નલ મોડ્યુલો વિશે પણ વાત કરી રહ્યો નથી, જે કર્નલ પર સખત રીતે નિર્ભર છે અને સેન્ડબોક્સ ખ્યાલમાં ફિટ થતા નથી.

બીજી સમસ્યા એ છે કે Red Hat અને SUSE માંથી એન્ટરપ્રાઇઝ પર્યાવરણમાં લોકપ્રિય વિતરણો હજુ સુધી Snappy અને Flatpak માટે સપોર્ટ ધરાવતા નથી.

આ સંદર્ભે, Linux માટે Veeam એજન્ટ ઉપલબ્ધ નથી snapcraft.io ચાલુ નથી flathub.org.

પેકેજ મેનેજરો વિશેના પ્રશ્નને સમાપ્ત કરવા માટે, હું એ નોંધવા માંગુ છું કે બાઈનરી ફાઇલો અને તેમને એક પેકેજમાં ઇન્સ્ટોલ કરવા માટેની સ્ક્રિપ્ટને જોડીને પેકેજ મેનેજરોને સંપૂર્ણપણે છોડી દેવાનો વિકલ્પ છે.

આવા બંડલ તમને વિવિધ વિતરણો અને પ્લેટફોર્મ્સ માટે એક સામાન્ય પેકેજ બનાવવા, જરૂરી કસ્ટમાઇઝેશન હાથ ધરવા, ઇન્ટરેક્ટિવ ઇન્સ્ટોલેશન પ્રક્રિયા હાથ ધરવા માટે પરવાનગી આપે છે. મને ફક્ત VMware માંથી Linux માટે આવા પેકેજો મળ્યા છે.

અપડેટ સમસ્યા

જો તમામ નિર્ભરતા મુદ્દાઓ ઉકેલાઈ ગયા હોય, તો પણ પ્રોગ્રામ સમાન વિતરણ પર અલગ રીતે ચાલી શકે છે. તે અપડેટ્સની બાબત છે.

ત્યાં 3 અપડેટ વ્યૂહરચના છે:

• સૌથી સરળ એ છે કે ક્યારેય અપડેટ ન કરવું. મેં સર્વર સેટ કર્યું અને તેના વિશે ભૂલી ગયો. જો બધું કામ કરે તો શા માટે અપડેટ કરવું? જ્યારે તમે પ્રથમ વખત સપોર્ટનો સંપર્ક કરો છો ત્યારે સમસ્યાઓ શરૂ થાય છે. વિતરણના નિર્માતા ફક્ત અપડેટ કરેલ પ્રકાશનને સમર્થન આપે છે.
• તમે વિતરક પર વિશ્વાસ કરી શકો છો અને સ્વચાલિત અપડેટ્સ સેટ કરી શકો છો. આ કિસ્સામાં, અસફળ અપડેટ પછી તરત જ સપોર્ટ માટે કૉલ સંભવ છે.
• તેને ટેસ્ટ ઈન્ફ્રાસ્ટ્રક્ચર પર ચલાવ્યા પછી જ મેન્યુઅલ અપડેટ કરવાનો વિકલ્પ સૌથી ભરોસાપાત્ર છે, પરંતુ ખર્ચાળ અને સમય માંગી લેતો છે. દરેક વ્યક્તિને તે પરવડી શકે તેમ નથી.

વિવિધ વપરાશકર્તાઓ અલગ-અલગ અપડેટ વ્યૂહરચનાનો ઉપયોગ કરતા હોવાથી, નવીનતમ પ્રકાશન અને અગાઉ પ્રકાશિત થયેલ તમામને સમર્થન આપવું જરૂરી છે. આ વિકાસ અને પરીક્ષણ પ્રક્રિયા બંનેને જટિલ બનાવે છે અને સપોર્ટ ટીમમાં માથાનો દુખાવો ઉમેરે છે.

હાર્ડવેર પ્લેટફોર્મની વિવિધતા

વિવિધ હાર્ડવેર પ્લેટફોર્મ એ એક સમસ્યા છે જે મોટાભાગે મૂળ કોડ માટે વિશિષ્ટ છે. ઓછામાં ઓછા, તમારે દરેક સપોર્ટેડ પ્લેટફોર્મ માટે દ્વિસંગી એકત્રિત કરવી પડશે.

Linux પ્રોજેક્ટ માટે Veeam Agent માં, અમે હજુ પણ આ RISC ને સમર્થન આપી શકતા નથી.

હું આ મુદ્દા પર વિગતવાર ધ્યાન આપીશ નહીં. હું ફક્ત મુખ્ય સમસ્યાઓની રૂપરેખા આપીશ: પ્લેટફોર્મ આધારિત પ્રકારો, જેમ કે size_t, માળખું સંરેખણ અને બાઈટ ક્રમ.

સ્થિર અને/અથવા ગતિશીલ લિંકિંગ

પરંતુ પ્રશ્ન એ છે કે "લાઇબ્રેરીઓ સાથે કેવી રીતે લિંક કરવું - ગતિશીલ અથવા સ્થિર રીતે?" ચર્ચા કરવા યોગ્ય.

નિયમ પ્રમાણે, Linux હેઠળ C/C++ એપ્લિકેશનો ડાયનેમિક લિંકિંગનો ઉપયોગ કરે છે. જો એપ્લિકેશન ચોક્કસ વિતરણ માટે ખાસ બનાવવામાં આવી હોય તો આ સરસ કામ કરે છે.

જો કાર્ય એક બાઈનરી ફાઇલ સાથે વિવિધ વિતરણોને આવરી લેવાનું છે, તો તમારે સૌથી જૂના સપોર્ટેડ વિતરણ પર ધ્યાન કેન્દ્રિત કરવું પડશે. અમારા માટે, આ Red Hat 6 છે. તેમાં gcc 4.4 છે, જેને C++11 સ્ટાન્ડર્ડ પણ સપોર્ટ કરતું નથી. સંપૂર્ણપણે.

અમે gcc 6.3 નો ઉપયોગ કરીને અમારો પ્રોજેક્ટ બનાવીએ છીએ, જે સંપૂર્ણપણે C++14 ને સપોર્ટ કરે છે. સ્વાભાવિક રીતે, આ કિસ્સામાં, Red Hat 6 પર તમારે તમારી સાથે libstdc++ અને લાઈબ્રેરીઓને બુસ્ટ કરવી પડશે. સૌથી સહેલો રસ્તો સ્થિર રીતે તેમની સાથે લિંક કરવાનો છે.

પરંતુ અફસોસ, બધી લાઇબ્રેરીઓ સ્થિર રીતે લિંક કરી શકાતી નથી.

પ્રથમ, સિસ્ટમ લાઇબ્રેરીઓ જેમ કે લિબફ્યુઝ, libblkid કર્નલ અને તેના મોડ્યુલો સાથે તેમની સુસંગતતા સુનિશ્ચિત કરવા માટે ગતિશીલ રીતે લિંક કરવું જરૂરી છે.

બીજું, લાઇસન્સ સાથે સૂક્ષ્મતા છે.

GPL લાઇસન્સ મૂળભૂત રીતે તમને લાઇબ્રેરીઓને ફક્ત ઓપનસોર્સ કોડ સાથે લિંક કરવાની મંજૂરી આપે છે. MIT અને BSD સ્ટેટિક લિંકિંગને મંજૂરી આપે છે અને લાઇબ્રેરીઓને પ્રોજેક્ટમાં સામેલ કરવાની મંજૂરી આપે છે. પરંતુ LGPL સ્ટેટિક લિન્કિંગનો વિરોધ કરતું નથી, પરંતુ તે જરૂરી છે કે લિંક કરવા માટે જરૂરી ફાઇલો શેર કરવામાં આવે.

સામાન્ય રીતે, ડાયનેમિક લિંકિંગનો ઉપયોગ તમને કંઈપણ પ્રદાન કરવાથી અટકાવશે.

C/C++ એપ્લીકેશન બનાવવી

વિવિધ પ્લેટફોર્મ્સ અને ડિસ્ટ્રિબ્યુશન માટે C/C++ એપ્લીકેશન બનાવવા માટે, તે gcc નું યોગ્ય સંસ્કરણ પસંદ કરવા અથવા બિલ્ડ કરવા અને ચોક્કસ આર્કિટેક્ચર માટે ક્રોસ-કમ્પાઈલર્સનો ઉપયોગ કરવા અને પુસ્તકાલયોના સંપૂર્ણ સેટને એસેમ્બલ કરવા માટે પૂરતું છે. આ કાર્ય તદ્દન શક્ય છે, પરંતુ તદ્દન મુશ્કેલીકારક છે. અને ત્યાં કોઈ ગેરેંટી નથી કે પસંદ કરેલ કમ્પાઈલર અને લાઈબ્રેરીઓ કાર્યક્ષમ સંસ્કરણ પ્રદાન કરશે.

એક સ્પષ્ટ ફાયદો: ઈન્ફ્રાસ્ટ્રક્ચર ખૂબ જ સરળ છે, કારણ કે સમગ્ર બિલ્ડ પ્રક્રિયા એક મશીન પર પૂર્ણ કરી શકાય છે. વધુમાં, એક આર્કિટેક્ચર માટે દ્વિસંગીનો એક સેટ એકત્રિત કરવા માટે તે પૂરતું છે અને તમે તેને વિવિધ વિતરણો માટે પેકેજોમાં પેકેજ કરી શકો છો. આ રીતે લિનક્સ માટે વીમ એજન્ટ માટે વીમ પેકેજો બનાવવામાં આવે છે.

આ વિકલ્પના વિરોધમાં, તમે ફક્ત બિલ્ડ ફાર્મ તૈયાર કરી શકો છો, એટલે કે, એસેમ્બલી માટે ઘણી મશીનો. આવા દરેક મશીન ચોક્કસ વિતરણ અને ચોક્કસ આર્કિટેક્ચર માટે એપ્લિકેશન સંકલન અને પેકેજ એસેમ્બલી પ્રદાન કરશે. આ કિસ્સામાં, વિતરક દ્વારા તૈયાર કરાયેલા માધ્યમોનો ઉપયોગ કરીને સંકલન હાથ ધરવામાં આવે છે. એટલે કે, કમ્પાઈલર તૈયાર કરવાનો અને લાઈબ્રેરીઓ પસંદ કરવાનો તબક્કો ખતમ થઈ ગયો છે. વધુમાં, બિલ્ડ પ્રક્રિયા સરળતાથી સમાંતર કરી શકાય છે.

જો કે, આ અભિગમમાં એક નુકસાન છે: સમાન આર્કિટેક્ચરમાં દરેક વિતરણ માટે, તમારે તમારી પોતાની દ્વિસંગી ફાઇલોનો સમૂહ એકત્રિત કરવો પડશે. અન્ય ગેરલાભ એ છે કે આટલી મોટી સંખ્યામાં મશીનોને જાળવવાની જરૂર છે અને મોટી માત્રામાં ડિસ્ક જગ્યા અને RAM ફાળવવી આવશ્યક છે.

આ રીતે veeamsnap કર્નલ મોડ્યુલના KMOD પેકેજો Red Hat વિતરણો માટે સંકલિત થાય છે.

બિલ્ડ સર્વિસ ખોલો

SUSE ના સહકાર્યકરોએ એપ્લીકેશન કમ્પાઈલ કરવા અને પેકેજો એસેમ્બલ કરવા માટે ખાસ સેવાના રૂપમાં કેટલાક મધ્યમ ગ્રાઉન્ડને અમલમાં મૂકવાનો પ્રયાસ કર્યો - ઓપનબિલ્ડ સર્વિસ.

અનિવાર્યપણે, તે એક હાઇપરવાઇઝર છે જે વર્ચ્યુઅલ મશીન બનાવે છે, તેમાં તમામ જરૂરી પેકેજો ઇન્સ્ટોલ કરે છે, એપ્લિકેશનને કમ્પાઇલ કરે છે અને આ અલગ વાતાવરણમાં પેકેજ બનાવે છે, જે પછી વર્ચ્યુઅલ મશીન રિલીઝ થાય છે.

OpenBuildService માં અમલમાં આવેલ શેડ્યૂલર એ નક્કી કરશે કે તે શ્રેષ્ઠ પેકેજ બિલ્ડિંગ સ્પીડ માટે કેટલી વર્ચ્યુઅલ મશીનો લોન્ચ કરી શકે છે. બિલ્ટ-ઇન સાઇનિંગ મિકેનિઝમ પેકેજો પર સહી કરશે અને તેમને બિલ્ટ-ઇન રિપોઝીટરીમાં અપલોડ કરશે. બિલ્ટ-ઇન સંસ્કરણ નિયંત્રણ સિસ્ટમ ફેરફારો અને બિલ્ડ્સના ઇતિહાસને સાચવશે. આ સિસ્ટમમાં ફક્ત તમારા સ્ત્રોતો ઉમેરવાનું બાકી છે. તમારે સર્વર જાતે સેટ કરવાની પણ જરૂર નથી; તમે ઓપનનો ઉપયોગ કરી શકો છો.

જો કે, ત્યાં એક સમસ્યા છે: આવા હાર્વેસ્ટર હાલના ઈન્ફ્રાસ્ટ્રક્ચરમાં ફિટ થવું મુશ્કેલ છે. ઉદાહરણ તરીકે, વર્ઝન કંટ્રોલની જરૂર નથી; સોર્સ કોડ માટે અમારી પાસે પહેલાથી જ છે. અમારી હસ્તાક્ષર પદ્ધતિ અલગ છે: અમે વિશિષ્ટ સર્વરનો ઉપયોગ કરીએ છીએ. રીપોઝીટરીની પણ જરૂર નથી.

વધુમાં, અન્ય વિતરણો માટે આધાર - ઉદાહરણ તરીકે, Red Hat - તેના બદલે ખરાબ રીતે અમલમાં મૂકવામાં આવે છે, જે સમજી શકાય તેવું છે.

આવી સેવાનો ફાયદો એ SUSE વિતરણના આગલા સંસ્કરણ માટે ઝડપી સમર્થન છે. રિલીઝની સત્તાવાર જાહેરાત પહેલાં, એસેમ્બલી માટે જરૂરી પેકેજો જાહેર ભંડાર પર પોસ્ટ કરવામાં આવે છે. OpenBuildService પર ઉપલબ્ધ વિતરણોની સૂચિમાં એક નવું દેખાય છે. અમે બૉક્સને ચેક કરીએ છીએ અને તે બિલ્ડ પ્લાનમાં ઉમેરવામાં આવે છે. આમ, વિતરણનું નવું સંસ્કરણ ઉમેરવાનું લગભગ એક ક્લિકમાં થાય છે.

અમારા ઈન્ફ્રાસ્ટ્રક્ચરમાં, OpenBuildService નો ઉપયોગ કરીને, SUSE વિતરણો માટે veeamsnap કર્નલ મોડ્યુલના KMP પેકેજોની સમગ્ર વિવિધતાને એસેમ્બલ કરવામાં આવે છે.

આગળ, હું કર્નલ મોડ્યુલો માટે વિશિષ્ટ મુદ્દાઓ પર ધ્યાન આપવા માંગુ છું.

કર્નલ ABI

Linux કર્નલ મોડ્યુલો ઐતિહાસિક રીતે સ્ત્રોત સ્વરૂપમાં વિતરિત કરવામાં આવ્યા છે. હકીકત એ છે કે કર્નલના નિર્માતાઓ કર્નલ મોડ્યુલો માટે સ્થિર API ને સમર્થન આપવાની ચિંતાથી પોતાને બોજ આપતા નથી, અને ખાસ કરીને દ્વિસંગી સ્તરે, જેને આગળ kABI તરીકે ઓળખવામાં આવે છે.

વેનીલા કર્નલ માટે મોડ્યુલ બનાવવા માટે, તમારે ચોક્કસપણે આ ચોક્કસ કર્નલના હેડરોની જરૂર પડશે, અને તે ફક્ત આ કર્નલ પર જ કામ કરશે.

DKMS તમને કર્નલ અપડેટ કરતી વખતે મોડ્યુલો બનાવવાની પ્રક્રિયાને સ્વચાલિત કરવાની પરવાનગી આપે છે. પરિણામે, ડેબિયન રીપોઝીટરીના વપરાશકર્તાઓ (અને તેના ઘણા સંબંધીઓ) કર્નલ મોડ્યુલોનો ઉપયોગ કાં તો ડિસ્ટ્રીબ્યુટરના રીપોઝીટરીમાંથી કરે છે અથવા ડીકેએમએસનો ઉપયોગ કરીને સ્ત્રોતમાંથી સંકલિત કરે છે.

જો કે, આ પરિસ્થિતિ ખાસ કરીને એન્ટરપ્રાઇઝ સેગમેન્ટને અનુકૂળ નથી. પ્રોપ્રાઇટરી કોડ વિતરકો ઉત્પાદનને સંકલિત દ્વિસંગી તરીકે વિતરિત કરવા માંગે છે.

પ્રબંધકો સુરક્ષાના કારણોસર ઉત્પાદન સર્વર પર વિકાસ સાધનો રાખવા માંગતા નથી. Enterprise Linux વિતરકો જેમ કે Red Hat અને SUSE એ નક્કી કર્યું કે તેઓ તેમના વપરાશકર્તાઓ માટે સ્થિર kABI ને સપોર્ટ કરી શકે છે. પરિણામ Red Hat માટે KMOD પેકેજો અને SUSE માટે KMP પેકેજો હતા.

આ ઉકેલનો સાર એકદમ સરળ છે. વિતરણના ચોક્કસ સંસ્કરણ માટે, કર્નલ API સ્થિર છે. વિતરક જણાવે છે કે તે કર્નલનો ઉપયોગ કરે છે, ઉદાહરણ તરીકે, 3.10, અને માત્ર સુધારાઓ અને સુધારાઓ કરે છે જે કર્નલ ઈન્ટરફેસને અસર કરતા નથી, અને ખૂબ જ પ્રથમ કર્નલ માટે એકત્રિત કરવામાં આવેલા મોડ્યુલોનો ઉપયોગ પુનઃસંકલન કર્યા વિના પછીના બધા માટે કરી શકાય છે.

Red Hat તેના સમગ્ર જીવનચક્ર દરમ્યાન વિતરણ માટે kABI સુસંગતતાનો દાવો કરે છે. એટલે કે, rhel 6.0 (નવેમ્બર 2010 રિલીઝ) માટે એસેમ્બલ કરેલ મોડ્યુલ સંસ્કરણ 6.10 (જૂન 2018માં રિલીઝ) પર પણ કામ કરવું જોઈએ. અને આ લગભગ 8 વર્ષ છે. સ્વાભાવિક રીતે, આ કાર્ય તદ્દન મુશ્કેલ છે.
અમે ઘણા કિસ્સાઓ નોંધ્યા છે જ્યાં veemsnap મોડ્યુલે kABI સુસંગતતા સમસ્યાઓને કારણે કામ કરવાનું બંધ કર્યું છે.

RHEL 7.0 માટે સંકલિત veeamsnap મોડ્યુલ, 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 ના નવીનતમ પ્રકાશનમાં, નાના અપડેટ્સમાંથી એકમાં ભૂલ થઈ હતી. તે હકીકત તરફ દોરી ગયું કે જ્યારે સ્નેપશોટ રીલીઝ કરવામાં આવ્યો ત્યારે veeamsnap મોડ્યુલ સિસ્ટમને ક્રેશ કરવાની ખાતરી આપી હતી. અપડેટ પહેલા અને પછી કર્નલ સ્ત્રોતોની સરખામણી કર્યા પછી, અમને જાણવા મળ્યું કે બેકપોર્ટ દોષિત હતો. વેનીલા કર્નલ સંસ્કરણ 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 ને બદલે છે.
હું વિતરણ તરફ આવ્યો KDE નિયોન 5.16 અને તે જોઈને ખૂબ જ આશ્ચર્ય થયું કે આ કર્નલ સંસ્કરણમાં lookup_bdev કૉલે ઇનપુટ પરિમાણોની સૂચિ બદલી છે.

તેને એકસાથે મેળવવા માટે, મારે મેકફાઈલમાં એક સ્ક્રિપ્ટ ઉમેરવાની હતી જે તપાસે છે કે lookup_bdev ફંક્શનમાં માસ્ક પેરામીટર છે કે નહીં.

કર્નલ મોડ્યુલો પર હસ્તાક્ષર

પરંતુ ચાલો પેકેજ વિતરણના મુદ્દા પર પાછા આવીએ.

સ્થિર kABI નો એક ફાયદો એ છે કે કર્નલ મોડ્યુલોને બાઈનરી ફાઈલ તરીકે સાઈન કરી શકાય છે. આ કિસ્સામાં, વિકાસકર્તા ખાતરી કરી શકે છે કે મોડ્યુલને આકસ્મિક રીતે નુકસાન થયું નથી અથવા ઇરાદાપૂર્વક સંશોધિત કરવામાં આવ્યું નથી. તમે આને મોડિનફો આદેશ વડે ચકાસી શકો છો.

Red Hat અને SUSE વિતરણો તમને મોડ્યુલની સહી તપાસવા અને તેને લોડ કરવાની પરવાનગી આપે છે જો અનુરૂપ પ્રમાણપત્ર સિસ્ટમ પર નોંધાયેલ હોય. પ્રમાણપત્ર એ જાહેર કી છે જેની સાથે મોડ્યુલ પર હસ્તાક્ષર કરવામાં આવે છે. અમે તેને અલગ પેકેજ તરીકે વિતરિત કરીએ છીએ.

અહીં સમસ્યા એ છે કે પ્રમાણપત્રો કાં તો કર્નલમાં બનાવી શકાય છે (વિતરકો તેનો ઉપયોગ કરે છે) અથવા ઉપયોગિતાનો ઉપયોગ કરીને EFI નોન-વોલેટાઇલ મેમરીમાં લખવામાં આવવી જોઈએ. મોકુટીલ. ઉપયોગિતા મોકુટીલ પ્રમાણપત્ર સ્થાપિત કરતી વખતે, તમારે સિસ્ટમ રીબૂટ કરવાની જરૂર છે અને, ઓપરેટિંગ સિસ્ટમ કર્નલ લોડ કરતા પહેલા પણ, એડમિનિસ્ટ્રેટરને નવું પ્રમાણપત્ર લોડ કરવાની મંજૂરી આપવા માટે પૂછે છે.

આમ, પ્રમાણપત્ર ઉમેરવા માટે સિસ્ટમમાં ભૌતિક વ્યવસ્થાપક ઍક્સેસની જરૂર છે. જો મશીન ક્યાંક ક્લાઉડમાં અથવા ફક્ત રિમોટ સર્વર રૂમમાં સ્થિત છે અને ઍક્સેસ ફક્ત નેટવર્ક દ્વારા જ છે (ઉદાહરણ તરીકે, ssh દ્વારા), તો પ્રમાણપત્ર ઉમેરવાનું અશક્ય હશે.

વર્ચ્યુઅલ મશીનો પર EFI

લગભગ તમામ મધરબોર્ડ ઉત્પાદકો દ્વારા EFI ને લાંબા સમયથી સમર્થન આપવામાં આવ્યું હોવા છતાં, સિસ્ટમ ઇન્સ્ટોલ કરતી વખતે, એડમિનિસ્ટ્રેટર EFI ની જરૂરિયાત વિશે વિચારી શકતા નથી, અને તે અક્ષમ થઈ શકે છે.

બધા હાઇપરવાઇઝર EFI ને સમર્થન આપતા નથી. VMWare vSphere આવૃત્તિ 5 થી શરૂ થતા EFI ને સપોર્ટ કરે છે.
Microsoft Hyper-V એ Windows Server 2012R2 માટે Hyper-V થી શરૂ કરીને EFI સપોર્ટ પણ મેળવ્યો.

જો કે, ડિફોલ્ટ રૂપરેખાંકનમાં આ કાર્યક્ષમતા Linux મશીનો માટે અક્ષમ છે, જેનો અર્થ છે કે પ્રમાણપત્ર ઇન્સ્ટોલ કરી શકાતું નથી.

vSphere 6.5 માં, વિકલ્પ સેટ કરો સુરક્ષિત બુટ વેબ ઈન્ટરફેસના જૂના સંસ્કરણમાં જ શક્ય છે, જે ફ્લેશ દ્વારા ચાલે છે. HTML-5 પર વેબ UI હજુ પણ ઘણું પાછળ છે.

પ્રાયોગિક વિતરણો

અને અંતે, ચાલો પ્રાયોગિક વિતરણો અને સત્તાવાર સમર્થન વિના વિતરણના મુદ્દાને ધ્યાનમાં લઈએ. એક તરફ, આવા વિતરણો ગંભીર સંસ્થાઓના સર્વર પર મળવાની શક્યતા નથી. આવા વિતરણો માટે કોઈ સત્તાવાર સમર્થન નથી. તેથી, તે પ્રદાન કરો. આવા વિતરણ પર ઉત્પાદનને સમર્થન આપી શકાતું નથી.

જો કે, આવા વિતરણો નવા પ્રાયોગિક ઉકેલો અજમાવવા માટે અનુકૂળ પ્લેટફોર્મ બની જાય છે. ઉદાહરણ તરીકે, Fedora, OpenSUSE Tumbleweed અથવા Debian ના અસ્થિર વર્ઝન. તેઓ એકદમ સ્થિર છે. તેમની પાસે હંમેશા પ્રોગ્રામની નવી આવૃત્તિઓ અને હંમેશા નવી કર્નલ હોય છે. એક વર્ષમાં, આ પ્રાયોગિક કાર્યક્ષમતા અપડેટેડ RHEL, SLES અથવા ઉબુન્ટુમાં સમાપ્ત થઈ શકે છે.

તેથી જો પ્રાયોગિક વિતરણ પર કંઈક કામ કરતું નથી, તો આ સમસ્યાને શોધવા અને તેને હલ કરવાનું એક કારણ છે. તમારે એ હકીકત માટે તૈયાર રહેવાની જરૂર છે કે આ કાર્યક્ષમતા ટૂંક સમયમાં વપરાશકર્તાઓના ઉત્પાદન સર્વર પર દેખાશે.

તમે સંસ્કરણ 3.0 માટે સત્તાવાર રીતે સમર્થિત વિતરણોની વર્તમાન સૂચિનો અભ્યાસ કરી શકો છો અહીં. પરંતુ વિતરણોની વાસ્તવિક સૂચિ કે જેના પર અમારું ઉત્પાદન કાર્ય કરી શકે છે તે ખૂબ વિશાળ છે.

અંગત રીતે, મને એલ્બ્રસ ઓએસ સાથેના પ્રયોગમાં રસ હતો. વીમ પેકેજને અંતિમ સ્વરૂપ આપ્યા પછી, અમારું ઉત્પાદન ઇન્સ્ટોલ થઈ ગયું અને કાર્ય કરી રહ્યું છે. મેં Habré માં આ પ્રયોગ વિશે લખ્યું હતું લેખ.

સારું, નવા વિતરણો માટે સમર્થન ચાલુ છે. અમે સંસ્કરણ 4.0 રિલીઝ થવાની રાહ જોઈ રહ્યા છીએ. બેટા દેખાવાનો છે, માટે નજર રાખો નવું શું છે!

સોર્સ: www.habr.com